Re: Comments on device tree for pcm030
Jon, hmm, I tried the same, but with a 32MiB flash instead. And Linux-2.6.26-rc5 and the dtc-1.1.0. On Monday 09 June 2008 23:30, Jon Smirl wrote: This is my boot log: ff00.flash: Found 1 x16 devices at 0x0 in 16-bit bank Intel/Sharp Extended Query Table at 0x0031 Using buffer write method cfi_cmdset_0001: Erase suspend on write enabled RedBoot partition parsing not available Creating 6 MTD partitions on ff00.flash: 0x-0x0004 : ubootl 0x0004-0x0020 : kernel 0x0020-0x00f0 : jffs2 0x00f0-0x00f4 : uboot 0x00f4-0x00f8 : oftree 0x00f8-0x0100 : space Here is mine (with DEBUG on in physmap_of.c): [...] mpc52xx MII bus: probed net eth0: Using PHY at MDIO address 0 of-flash fe00.flash: of_flash device: fe00-fdff of-flash: probe of fe00.flash failed with error -16 TCP cubic registered [...] I'm confused about the fe0-fdff. These are the return values from the of_address_to_resource() call (in of_flash_probe() ). It should be fe0- instead. Regards, Juergen -- Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Vertretung Sued/Muenchen, Germany Phone: +49-8766-939 228 | Fax: +49-5121-206917-9 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Comments on device tree for pcm030
Maybe everything in this small piece of my dts is wrong. But I don't know how
the correct way is. All I want is to define a 32MiB flash at the end if the
address space of my MPC5200B based system.
[...]
[EMAIL PROTECTED] {
model = fsl,lpb;
compatible = fsl,lpb;
ranges = 0x0 0xfe00 0x0200;
[EMAIL PROTECTED] {
compatible = cfi-flash;
reg = 0x 0x0200;
bank-width = 4;
};
};
The dtc gives me the follwing output:
Warning (reg_format): reg property in /[EMAIL PROTECTED]/[EMAIL PROTECTED]
has invalid length (8 bytes) (#address-cells == 2, #size-cells == 1)
Warning (ranges_format): ranges property in /[EMAIL PROTECTED] has invalid
length (12 bytes) (parent #address-cells == 1, child #address-cells == 2,
#size-cells == 1)
Warning (avoid_default_addr_size): Relying on default #address-cells value for
/[EMAIL PROTECTED]/[EMAIL PROTECTED]
Warning (avoid_default_addr_size): Relying on default #size-cells value for
/[EMAIL PROTECTED]/[EMAIL PROTECTED]
What does it mean?
At runtime I get:
[...]
of-flash fe00.flash: of_flash device: fe00-
CFI: Found no fe00.flash device at location zero
of-flash fe00.flash: do_map_probe() failed
[...]
What's going wrong? Any hint?
Regards,
Juergen
--
Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Vertretung Sued/Muenchen, Germany
Phone: +49-8766-939 228 | Fax: +49-5121-206917-9
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Comments on device tree for pcm030
On Tue, Jun 10, 2008 at 3:05 AM, Juergen Beisert [EMAIL PROTECTED] wrote:
Maybe everything in this small piece of my dts is wrong. But I don't know how
the correct way is. All I want is to define a 32MiB flash at the end if the
address space of my MPC5200B based system.
[...]
[EMAIL PROTECTED] {
model = fsl,lpb;
compatible = fsl,lpb;
ranges = 0x0 0xfe00 0x0200;
- You need #address-cells and #size-cells in bus nodes.
#address-cells should be 2 in fsl,lpb nodes. Your ranges property
is broken due to the missing #address/size-cells.
[EMAIL PROTECTED] {
compatible = cfi-flash;
reg = 0x 0x0200;
- since address cells will be '2', you need 2 cells to describe the
base address here; first cell is the chip select, second cell is the
address offset off that base address.
bank-width = 4;
};
};
The dtc gives me the follwing output:
Warning (reg_format): reg property in /[EMAIL PROTECTED]/[EMAIL PROTECTED]
has invalid length (8 bytes) (#address-cells == 2, #size-cells == 1)
Warning (ranges_format): ranges property in /[EMAIL PROTECTED] has invalid
length (12 bytes) (parent #address-cells == 1, child #address-cells == 2,
#size-cells == 1)
Warning (avoid_default_addr_size): Relying on default #address-cells value
for /[EMAIL PROTECTED]/[EMAIL PROTECTED]
Warning (avoid_default_addr_size): Relying on default #size-cells value for
/[EMAIL PROTECTED]/[EMAIL PROTECTED]
What does it mean?
At runtime I get:
[...]
of-flash fe00.flash: of_flash device: fe00-
CFI: Found no fe00.flash device at location zero
of-flash fe00.flash: do_map_probe() failed
[...]
What's going wrong? Any hint?
Regards,
Juergen
--
Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Vertretung Sued/Muenchen, Germany
Phone: +49-8766-939 228 | Fax: +49-5121-206917-9
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Comments on device tree for pcm030
On Monday 09 June 2008 01:28, Grant Likely wrote: On Sun, Jun 8, 2008 at 1:08 PM, Jon Smirl [EMAIL PROTECTED] wrote: Why not a compatible field in the top of the tree? Then you wouldn't need to list the boards in mpc5200_simple.c. compatible = phytec,pcm030,simple-mpc5200; Here's the problem; what does compatible really mean at the board level? Does it mean the board has 100% of the same capabilities? Does it mean that it uses the same chip? Does it mean that the chip is configured in a particular way? It is really hard to define what a compatible value means at the board level. The meaning of compatible at the device level is very well defined, but that meaning does not extend well to the board level. Therefore, it is best to be conservative here and require a specific list of supported boards in platform code. Besides, it is really a Linux specific thing that is trying to be described. In Linux, we've decided to support as many 5200 boards as possible using the same platform code, but that may not be true, or it may be a different set of boards, when a different OS is used. To attempt to encode those decisions is overreaching the intent of using the device tree. Device tree has an entry for AC97 on PSC1. I don't think the Phytec module or carrier board has AC97 hardware. Might be a bug NACK. The baseboard for the pcm030 CPU board has AC97 hardware connected to PSC1. And it plays audio... The RTC chip says pcf8563, phytec doc says it is a pcf8564. Sounds like a bug These devices are mostly the same. You can use the pcf8563 driver for the pcf8564. There should be an i2c entry for the eeprom but I don't know the part number for it. Yes, i2c devices should be described. Its a 24C32. I believe Wolfram has a newer OFtree for the pcm030 so I add him as CC. Regards, Juergen -- Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Vertretung Sued/Muenchen, Germany Phone: +49-8766-939 228 | Fax: +49-5121-206917-9 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Comments on device tree for pcm030
Hi,
On Sun, Jun 08, 2008 at 03:08:33PM -0400, Jon Smirl wrote:
Why not a compatible field in the top of the tree? Then you wouldn't
need to list the boards in mpc5200_simple.c.
compatible = phytec,pcm030,simple-mpc5200;
Device tree has an entry for AC97 on PSC1. I don't think the Phytec
module or carrier board has AC97 hardware.
The RTC chip says pcf8563, phytec doc says it is a pcf8564.
There should be an i2c entry for the eeprom but I don't know the part
number for it.
What about the flash on the local bus? Could we use something like
this, or the same without the partition data?
[EMAIL PROTECTED] {
compatible = fsl,lpb;
ranges = 0 ff00 0100;
[EMAIL PROTECTED] {
compatible = cfi-flash;
reg = 0100;
bank-width = 2;
The board comes with different flash sizes with different bank widths.
That's why I decided to no put the flash entries into the tree.
We used to detect the flash size/bankwidth using the bootcs config
register (which was previously set by U-Boot). We could change U-Boot to
adjust the device tree accordingly, but we haven't done this so far,
sorry.
#size-cells = 1;
#address-cells = 1;
[EMAIL PROTECTED] {
label = ubootl;
reg = 0004;
};
[EMAIL PROTECTED] {
label = kernel;
reg = 0004 001c;
};
[EMAIL PROTECTED] {
label = jffs2;
reg = 0020 00D0;
};
[EMAIL PROTECTED] {
label = uboot;
reg = 00f0 0004;
};
[EMAIL PROTECTED] {
label = oftree;
reg = 00f4 0004;
};
[EMAIL PROTECTED] {
label = space;
reg = 00f8 0008;
};
I think partitions shouldn't go into the default device tree, as people
may have different partitioning.
Sascha
--
Pengutronix e.K. - Linux Solutions for Science and Industry
---
Kontakt-Informationen finden Sie im Header dieser Mail oder
auf der Webseite - http://www.pengutronix.de/impressum/ -
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Comments on device tree for pcm030
On 6/9/08, Juergen Beisert [EMAIL PROTECTED] wrote: Device tree has an entry for AC97 on PSC1. I don't think the Phytec module or carrier board has AC97 hardware. Might be a bug NACK. The baseboard for the pcm030 CPU board has AC97 hardware connected to PSC1. And it plays audio... I'm staring at a baseboard for the pcm030 in my hand, I don't see any AC97 hardware. It has two serial, two CAN, ethernet and power. Where's the AC97? http://www.phytec.com/products/rdk/PowerPC/phyCORE-MPC5200B-tinyRDK.html -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Comments on device tree for pcm030
On 6/9/08, Juergen Beisert [EMAIL PROTECTED] wrote: On Monday 09 June 2008 01:28, Grant Likely wrote: On Sun, Jun 8, 2008 at 1:08 PM, Jon Smirl [EMAIL PROTECTED] wrote: Why not a compatible field in the top of the tree? Then you wouldn't need to list the boards in mpc5200_simple.c. compatible = phytec,pcm030,simple-mpc5200; Here's the problem; what does compatible really mean at the board level? Does it mean the board has 100% of the same capabilities? Does it mean that it uses the same chip? Does it mean that the chip is configured in a particular way? It is really hard to define what a compatible value means at the board level. The meaning of compatible at the device level is very well defined, but that meaning does not extend well to the board level. Therefore, it is best to be conservative here and require a specific list of supported boards in platform code. Besides, it is really a Linux specific thing that is trying to be described. In Linux, we've decided to support as many 5200 boards as possible using the same platform code, but that may not be true, or it may be a different set of boards, when a different OS is used. To attempt to encode those decisions is overreaching the intent of using the device tree. Device tree has an entry for AC97 on PSC1. I don't think the Phytec module or carrier board has AC97 hardware. Might be a bug NACK. The baseboard for the pcm030 CPU board has AC97 hardware connected to PSC1. And it plays audio... The RTC chip says pcf8563, phytec doc says it is a pcf8564. Sounds like a bug These devices are mostly the same. You can use the pcf8563 driver for the pcf8564. Let's put the right chip number in the tree. While these have the same drivers on Linux they may not on other OSes. There should be an i2c entry for the eeprom but I don't know the part number for it. Yes, i2c devices should be described. Its a 24C32. I believe Wolfram has a newer OFtree for the pcm030 so I add him as CC. Regards, Juergen -- Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Vertretung Sued/Muenchen, Germany Phone: +49-8766-939 228 | Fax: +49-5121-206917-9 -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Comments on device tree for pcm030
Jon, On Monday 09 June 2008 14:37, Jon Smirl wrote: On 6/9/08, Juergen Beisert [EMAIL PROTECTED] wrote: Device tree has an entry for AC97 on PSC1. I don't think the Phytec module or carrier board has AC97 hardware. Might be a bug NACK. The baseboard for the pcm030 CPU board has AC97 hardware connected to PSC1. And it plays audio... I'm staring at a baseboard for the pcm030 in my hand, I don't see any AC97 hardware. It has two serial, two CAN, ethernet and power. Where's the AC97? It seems you have an old development hardware. Here I have the PCM-030-02REI (=CPU card) and PCM-973-tiny (=baseboard). The PCM-973-tiny comes with a Wolfson AC97 sound device. This is the current combination everyone can buy. http://www.phytec.com/products/rdk/PowerPC/phyCORE-MPC5200B-tinyRDK.html Yes. This kit contains the PCM-973-tiny with AC97 sound. Regards, Juergen -- Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Vertretung Sued/Muenchen, Germany Phone: +49-8766-939 228 | Fax: +49-5121-206917-9 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Comments on device tree for pcm030
On Mon, Jun 9, 2008 at 1:56 AM, Juergen Beisert [EMAIL PROTECTED] wrote: On Monday 09 June 2008 01:28, Grant Likely wrote: On Sun, Jun 8, 2008 at 1:08 PM, Jon Smirl [EMAIL PROTECTED] wrote: Device tree has an entry for AC97 on PSC1. I don't think the Phytec module or carrier board has AC97 hardware. Might be a bug NACK. The baseboard for the pcm030 CPU board has AC97 hardware connected to PSC1. And it plays audio... Okay, I didn't know. The RTC chip says pcf8563, phytec doc says it is a pcf8564. Sounds like a bug These devices are mostly the same. You can use the pcf8563 driver for the pcf8564. Then compatible should be something 'compatible = nxp,pcf8564, nxp,pcf8563;' Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Comments on device tree for pcm030
On Sunday 08 June 2008 21:08, Jon Smirl wrote:
What about the flash on the local bus? Could we use something like
this, or the same without the partition data?
[EMAIL PROTECTED] {
compatible = fsl,lpb;
ranges = 0 ff00 0100;
[EMAIL PROTECTED] {
compatible = cfi-flash;
reg = 0100;
bank-width = 2;
#size-cells = 1;
#address-cells = 1;
[EMAIL PROTECTED] {
label = ubootl;
reg = 0004;
};
[EMAIL PROTECTED] {
label = kernel;
reg = 0004 001c;
};
[EMAIL PROTECTED] {
label = jffs2;
reg = 0020 00D0;
};
[EMAIL PROTECTED] {
label = uboot;
reg = 00f0 0004;
};
[EMAIL PROTECTED] {
label = oftree;
reg = 00f4 0004;
};
[EMAIL PROTECTED] {
label = space;
reg = 00f8 0008;
};
};
};
Hmm, I tried with these setting (and many others) to make the flash on my
board work again.
But the physmap_of.c driver always fails. It tries to request the region
0xfe00 to 0x (my flash is 32MiB in size at 0xfe0 to
0x) and fails badly. What are the correct settings in the OFTree to
make the physmap_of.c driver work?
Regards,
Juergen
--
Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Vertretung Sued/Muenchen, Germany
Phone: +49-8766-939 228 | Fax: +49-5121-206917-9
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Comments on device tree for pcm030
On Mon, Jun 09, 2008 at 11:13:35AM +0200, Sascha Hauer wrote: I think partitions shouldn't go into the default device tree, as people may have different partitioning. It is also a chicken-and-egg thing, because the oftree would describe the partition it is in. Robert -- Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Hannoversche Str. 2, 31134 Hildesheim, Germany Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Comments on device tree for pcm030
On Sun, Jun 08, 2008 at 03:08:33PM -0400, Jon Smirl wrote: There should be an i2c entry for the eeprom but I don't know the part number for it. Wolfram has oftree bindings for the new at24 driver which will be used in combination with this board. For patches, please see the i2c list. Robert -- Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Hannoversche Str. 2, 31134 Hildesheim, Germany Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Comments on device tree for pcm030
On 6/9/08, Juergen Beisert [EMAIL PROTECTED] wrote:
On Sunday 08 June 2008 21:08, Jon Smirl wrote:
What about the flash on the local bus? Could we use something like
this, or the same without the partition data?
[EMAIL PROTECTED] {
compatible = fsl,lpb;
ranges = 0 ff00 0100;
[EMAIL PROTECTED] {
compatible = cfi-flash;
reg = 0100;
bank-width = 2;
#size-cells = 1;
#address-cells = 1;
[EMAIL PROTECTED] {
label = ubootl;
reg = 0004;
};
[EMAIL PROTECTED] {
label = kernel;
reg = 0004 001c;
};
[EMAIL PROTECTED] {
label = jffs2;
reg = 0020 00D0;
};
[EMAIL PROTECTED] {
label = uboot;
reg = 00f0 0004;
};
[EMAIL PROTECTED] {
label = oftree;
reg = 00f4 0004;
};
[EMAIL PROTECTED] {
label = space;
reg = 00f8 0008;
};
};
};
Hmm, I tried with these setting (and many others) to make the flash on my
board work again.
But the physmap_of.c driver always fails. It tries to request the region
0xfe00 to 0x (my flash is 32MiB in size at 0xfe0 to
0x) and fails badly. What are the correct settings in the OFTree to
make the physmap_of.c driver work?
This is my boot log:
ff00.flash: Found 1 x16 devices at 0x0 in 16-bit bank
Intel/Sharp Extended Query Table at 0x0031
Using buffer write method
cfi_cmdset_0001: Erase suspend on write enabled
RedBoot partition parsing not available
Creating 6 MTD partitions on ff00.flash:
0x-0x0004 : ubootl
0x0004-0x0020 : kernel
0x0020-0x00f0 : jffs2
0x00f0-0x00f4 : uboot
0x00f4-0x00f8 : oftree
0x00f8-0x0100 : space
CONFIG_MTD=y
# CONFIG_MTD_DEBUG is not set
CONFIG_MTD_CONCAT=y
CONFIG_MTD_PARTITIONS=y
# CONFIG_MTD_REDBOOT_PARTS is not set
CONFIG_MTD_CMDLINE_PARTS=y
#
# User Modules And Translation Layers
#
CONFIG_MTD_CHAR=y
CONFIG_MTD_BLKDEVS=y
CONFIG_MTD_BLOCK=y
# CONFIG_FTL is not set
# CONFIG_NFTL is not set
# CONFIG_INFTL is not set
# CONFIG_RFD_FTL is not set
# CONFIG_SSFDC is not set
# CONFIG_MTD_OOPS is not set
#
# RAM/ROM/Flash chip drivers
#
CONFIG_MTD_CFI=y
# CONFIG_MTD_JEDECPROBE is not set
CONFIG_MTD_GEN_PROBE=y
# CONFIG_MTD_CFI_ADV_OPTIONS is not set
CONFIG_MTD_MAP_BANK_WIDTH_1=y
CONFIG_MTD_MAP_BANK_WIDTH_2=y
CONFIG_MTD_MAP_BANK_WIDTH_4=y
# CONFIG_MTD_MAP_BANK_WIDTH_8 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_16 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_32 is not set
CONFIG_MTD_CFI_I1=y
CONFIG_MTD_CFI_I2=y
# CONFIG_MTD_CFI_I4 is not set
# CONFIG_MTD_CFI_I8 is not set
CONFIG_MTD_CFI_INTELEXT=y
# CONFIG_MTD_CFI_AMDSTD is not set
# CONFIG_MTD_CFI_STAA is not set
CONFIG_MTD_CFI_UTIL=y
# CONFIG_MTD_RAM is not set
# CONFIG_MTD_ROM is not set
# CONFIG_MTD_ABSENT is not set
#
# Mapping drivers for chip access
#
# CONFIG_MTD_COMPLEX_MAPPINGS is not set
# CONFIG_MTD_PHYSMAP is not set
CONFIG_MTD_PHYSMAP_OF=y
# CONFIG_MTD_INTEL_VR_NOR is not set
# CONFIG_MTD_PLATRAM is not set
Regards,
Juergen
--
Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Vertretung Sued/Muenchen, Germany
Phone: +49-8766-939 228 | Fax: +49-5121-206917-9
--
Jon Smirl
[EMAIL PROTECTED]
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Comments on device tree for pcm030
Why not a compatible field in the top of the tree? Then you wouldn't
need to list the boards in mpc5200_simple.c.
compatible = phytec,pcm030,simple-mpc5200;
Device tree has an entry for AC97 on PSC1. I don't think the Phytec
module or carrier board has AC97 hardware.
The RTC chip says pcf8563, phytec doc says it is a pcf8564.
There should be an i2c entry for the eeprom but I don't know the part
number for it.
What about the flash on the local bus? Could we use something like
this, or the same without the partition data?
[EMAIL PROTECTED] {
compatible = fsl,lpb;
ranges = 0 ff00 0100;
[EMAIL PROTECTED] {
compatible = cfi-flash;
reg = 0100;
bank-width = 2;
#size-cells = 1;
#address-cells = 1;
[EMAIL PROTECTED] {
label = ubootl;
reg = 0004;
};
[EMAIL PROTECTED] {
label = kernel;
reg = 0004 001c;
};
[EMAIL PROTECTED] {
label = jffs2;
reg = 0020 00D0;
};
[EMAIL PROTECTED] {
label = uboot;
reg = 00f0 0004;
};
[EMAIL PROTECTED] {
label = oftree;
reg = 00f4 0004;
};
[EMAIL PROTECTED] {
label = space;
reg = 00f8 0008;
};
};
};
--
Jon Smirl
[EMAIL PROTECTED]
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Comments on device tree for pcm030
On Sun, Jun 8, 2008 at 1:08 PM, Jon Smirl [EMAIL PROTECTED] wrote:
Why not a compatible field in the top of the tree? Then you wouldn't
need to list the boards in mpc5200_simple.c.
compatible = phytec,pcm030,simple-mpc5200;
Here's the problem; what does compatible really mean at the board
level? Does it mean the board has 100% of the same capabilities?
Does it mean that it uses the same chip? Does it mean that the chip
is configured in a particular way? It is really hard to define what a
compatible value means at the board level. The meaning of compatible
at the device level is very well defined, but that meaning does not
extend well to the board level.
Therefore, it is best to be conservative here and require a specific
list of supported boards in platform code.
Besides, it is really a Linux specific thing that is trying to be
described. In Linux, we've decided to support as many 5200 boards as
possible using the same platform code, but that may not be true, or it
may be a different set of boards, when a different OS is used. To
attempt to encode those decisions is overreaching the intent of using
the device tree.
Device tree has an entry for AC97 on PSC1. I don't think the Phytec
module or carrier board has AC97 hardware.
Might be a bug
The RTC chip says pcf8563, phytec doc says it is a pcf8564.
Sounds like a bug
There should be an i2c entry for the eeprom but I don't know the part
number for it.
Yes, i2c devices should be described.
What about the flash on the local bus? Could we use something like
this, or the same without the partition data?
Yes, I believe there is code in place to support this.
[EMAIL PROTECTED] {
compatible = fsl,lpb;
ranges = 0 ff00 0100;
[EMAIL PROTECTED] {
compatible = cfi-flash;
reg = 0100;
bank-width = 2;
#size-cells = 1;
#address-cells = 1;
[EMAIL PROTECTED] {
label = ubootl;
reg = 0004;
};
[EMAIL PROTECTED] {
label = kernel;
reg = 0004 001c;
};
[EMAIL PROTECTED] {
label = jffs2;
reg = 0020 00D0;
};
[EMAIL PROTECTED] {
label = uboot;
reg = 00f0 0004;
};
[EMAIL PROTECTED] {
label = oftree;
reg = 00f4 0004;
};
[EMAIL PROTECTED] {
label = space;
reg = 00f8 0008;
};
};
};
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
