Comments on device tree for pcm030

Comments on device tree for pcm030

[Jon Smirl]

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?

	lpb@ff000000 {
		compatible = "fsl,lpb";
		ranges = <0 ff000000 01000000>;
		
		flash@00000000 {
			compatible = "cfi-flash";
			reg = <00000000 01000000>;
			bank-width = <2>;
			#size-cells = <1>;
			#address-cells = <1>;
			partition@0 {
				label = "ubootl";
				reg = <00000000 00040000>;
			};
			partition@40000 {
				label = "kernel";
				reg = <00040000 001c0000>;
			};
			partition@200000 {
				label = "jffs2";
				reg = <00200000 00D00000>;
			};
			partition@f00000 {
				label = "uboot";
				reg = <00f00000 00040000>;
			};
			partition@f40000 {
				label = "oftree";
				reg = <00f40000 00040000>;
			};
			partition@f80000 {
				label = "space";
				reg = <00f80000 00080000>;
			};
		};
	};

-- 
Jon Smirl
jonsmirl@gmail.com

Re: Comments on device tree for pcm030

[Grant Likely]

On Sun, Jun 8, 2008 at 1:08 PM, Jon Smirl <jonsmirl@gmail.com> 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.
>
>        lpb@ff000000 {
>                compatible = "fsl,lpb";
>                ranges = <0 ff000000 01000000>;
>
>                flash@00000000 {
>                        compatible = "cfi-flash";
>                        reg = <00000000 01000000>;
>                        bank-width = <2>;
>                        #size-cells = <1>;
>                        #address-cells = <1>;
>                        partition@0 {
>                                label = "ubootl";
>                                reg = <00000000 00040000>;
>                        };
>                        partition@40000 {
>                                label = "kernel";
>                                reg = <00040000 001c0000>;
>                        };
>                        partition@200000 {
>                                label = "jffs2";
>                                reg = <00200000 00D00000>;
>                        };
>                        partition@f00000 {
>                                label = "uboot";
>                                reg = <00f00000 00040000>;
>                        };
>                        partition@f40000 {
>                                label = "oftree";
>                                reg = <00f40000 00040000>;
>                        };
>                        partition@f80000 {
>                                label = "space";
>                                reg = <00f80000 00080000>;
>                        };
>                };
>        };

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: Comments on device tree for pcm030

[Juergen Beisert]

On Monday 09 June 2008 01:28, Grant Likely wrote:
> On Sun, Jun 8, 2008 at 1:08 PM, Jon Smirl <jonsmirl@gmail.com> 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 =3D "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=
=20
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=20
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

=2D-=20
Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de
=A0Pengutronix - Linux Solutions for Science and Industry
=A0   Handelsregister: Amtsgericht Hildesheim, HRA 2686
=A0 =A0 =A0    Vertretung Sued/Muenchen, Germany
   Phone: +49-8766-939 228 |  Fax: +49-5121-206917-9

Re: Comments on device tree for pcm030

[Sascha Hauer]

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?
> 
> 	lpb@ff000000 {
> 		compatible = "fsl,lpb";
> 		ranges = <0 ff000000 01000000>;
> 		
> 		flash@00000000 {
> 			compatible = "cfi-flash";
> 			reg = <00000000 01000000>;
> 			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>;
> 			partition@0 {
> 				label = "ubootl";
> 				reg = <00000000 00040000>;
> 			};
> 			partition@40000 {
> 				label = "kernel";
> 				reg = <00040000 001c0000>;
> 			};
> 			partition@200000 {
> 				label = "jffs2";
> 				reg = <00200000 00D00000>;
> 			};
> 			partition@f00000 {
> 				label = "uboot";
> 				reg = <00f00000 00040000>;
> 			};
> 			partition@f40000 {
> 				label = "oftree";
> 				reg = <00f40000 00040000>;
> 			};
> 			partition@f80000 {
> 				label = "space";
> 				reg = <00f80000 00080000>;
> 			};

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/ <-

Re: Comments on device tree for pcm030

[Jon Smirl]

On 6/9/08, Juergen Beisert <jbe@pengutronix.de> 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
jonsmirl@gmail.com

Re: Comments on device tree for pcm030

[Jon Smirl]

On 6/9/08, Juergen Beisert <jbe@pengutronix.de> wrote:
> On Monday 09 June 2008 01:28, Grant Likely wrote:
>  > On Sun, Jun 8, 2008 at 1:08 PM, Jon Smirl <jonsmirl@gmail.com> 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
jonsmirl@gmail.com

Re: Comments on device tree for pcm030

[Juergen Beisert]

Jon,

On Monday 09 June 2008 14:37, Jon Smirl wrote:
> On 6/9/08, Juergen Beisert <jbe@pengutronix.de> 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=20
the "PCM-030-02REI" (=3DCPU card) and "PCM-973-tiny" (=3Dbaseboard). The=20
PCM-973-tiny comes with a Wolfson AC97 sound device. This is the current=20
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

=2D-=20
Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de
=A0Pengutronix - Linux Solutions for Science and Industry
=A0   Handelsregister: Amtsgericht Hildesheim, HRA 2686
=A0 =A0 =A0    Vertretung Sued/Muenchen, Germany
   Phone: +49-8766-939 228 |  Fax: +49-5121-206917-9

Re: Comments on device tree for pcm030

[Grant Likely]

On Mon, Jun 9, 2008 at 1:56 AM, Juergen Beisert <jbe@pengutronix.de> wrote:
> On Monday 09 June 2008 01:28, Grant Likely wrote:
>> On Sun, Jun 8, 2008 at 1:08 PM, Jon Smirl <jonsmirl@gmail.com> 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.

Re: Comments on device tree for pcm030

[Juergen Beisert]

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?
>
> 	lpb@ff000000 {
> 		compatible =3D "fsl,lpb";
> 		ranges =3D <0 ff000000 01000000>;
>
> 		flash@00000000 {
> 			compatible =3D "cfi-flash";
> 			reg =3D <00000000 01000000>;
> 			bank-width =3D <2>;
> 			#size-cells =3D <1>;
> 			#address-cells =3D <1>;
> 			partition@0 {
> 				label =3D "ubootl";
> 				reg =3D <00000000 00040000>;
> 			};
> 			partition@40000 {
> 				label =3D "kernel";
> 				reg =3D <00040000 001c0000>;
> 			};
> 			partition@200000 {
> 				label =3D "jffs2";
> 				reg =3D <00200000 00D00000>;
> 			};
> 			partition@f00000 {
> 				label =3D "uboot";
> 				reg =3D <00f00000 00040000>;
> 			};
> 			partition@f40000 {
> 				label =3D "oftree";
> 				reg =3D <00f40000 00040000>;
> 			};
> 			partition@f80000 {
> 				label =3D "space";
> 				reg =3D <00f80000 00080000>;
> 			};
> 		};
> 	};

Hmm, I tried with these setting (and many others) to make the flash on my=20
board work again.
But the physmap_of.c driver always fails. It tries to request the region=20
0xfe000000 to 0x00000000 (my flash is 32MiB in size at 0xfe00000 to=20
0xffffffff) and fails badly. What are the correct settings in the OFTree to=
=20
make the physmap_of.c driver work?

Regards,
Juergen

=2D-=20
Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de
=A0Pengutronix - Linux Solutions for Science and Industry
=A0   Handelsregister: Amtsgericht Hildesheim, HRA 2686
=A0 =A0 =A0    Vertretung Sued/Muenchen, Germany
   Phone: +49-8766-939 228 |  Fax: +49-5121-206917-9

Re: Comments on device tree for pcm030

[Robert Schwebel]

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

Re: Comments on device tree for pcm030

[Robert Schwebel]

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

Re: Comments on device tree for pcm030

[Jon Smirl]

On 6/9/08, Juergen Beisert <jbe@pengutronix.de> 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?
>  >
>  >       lpb@ff000000 {
>  >               compatible = "fsl,lpb";
>  >               ranges = <0 ff000000 01000000>;
>  >
>  >               flash@00000000 {
>  >                       compatible = "cfi-flash";
>  >                       reg = <00000000 01000000>;
>  >                       bank-width = <2>;
>  >                       #size-cells = <1>;
>  >                       #address-cells = <1>;
>  >                       partition@0 {
>  >                               label = "ubootl";
>  >                               reg = <00000000 00040000>;
>  >                       };
>  >                       partition@40000 {
>  >                               label = "kernel";
>  >                               reg = <00040000 001c0000>;
>  >                       };
>  >                       partition@200000 {
>  >                               label = "jffs2";
>  >                               reg = <00200000 00D00000>;
>  >                       };
>  >                       partition@f00000 {
>  >                               label = "uboot";
>  >                               reg = <00f00000 00040000>;
>  >                       };
>  >                       partition@f40000 {
>  >                               label = "oftree";
>  >                               reg = <00f40000 00040000>;
>  >                       };
>  >                       partition@f80000 {
>  >                               label = "space";
>  >                               reg = <00f80000 00080000>;
>  >                       };
>  >               };
>  >       };
>
>
> 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
>  0xfe000000 to 0x00000000 (my flash is 32MiB in size at 0xfe00000 to
>  0xffffffff) and fails badly. What are the correct settings in the OFTree to
>  make the physmap_of.c driver work?

This is my boot log:

ff000000.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 "ff000000.flash":
0x00000000-0x00040000 : "ubootl"
0x00040000-0x00200000 : "kernel"
0x00200000-0x00f00000 : "jffs2"
0x00f00000-0x00f40000 : "uboot"
0x00f40000-0x00f80000 : "oftree"
0x00f80000-0x01000000 : "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
jonsmirl@gmail.com

Re: Comments on device tree for pcm030

[Juergen Beisert]

Jon,

hmm, I tried the same, but with a 32MiB flash instead. And Linux-2.6.26-rc5=
=20
and the dtc-1.1.0.

On Monday 09 June 2008 23:30, Jon Smirl wrote:
> This is my boot log:
>
> ff000000.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 "ff000000.flash":
> 0x00000000-0x00040000 : "ubootl"
> 0x00040000-0x00200000 : "kernel"
> 0x00200000-0x00f00000 : "jffs2"
> 0x00f00000-0x00f40000 : "uboot"
> 0x00f40000-0x00f80000 : "oftree"
> 0x00f80000-0x01000000 : "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 fe000000.flash: of_flash device: fe000000-fdffffff
of-flash: probe of fe000000.flash failed with error -16
TCP cubic registered
[...]

I'm confused about the "fe00000-fdffffff". These are the return values from=
=20
the of_address_to_resource() call (in of_flash_probe() ). It should=20
be "fe00000-ffffffff" instead.

Regards,
Juergen

=2D-=20
Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de
=A0Pengutronix - Linux Solutions for Science and Industry
=A0   Handelsregister: Amtsgericht Hildesheim, HRA 2686
=A0 =A0 =A0    Vertretung Sued/Muenchen, Germany
   Phone: +49-8766-939 228 |  Fax: +49-5121-206917-9

Re: Comments on device tree for pcm030

[Juergen Beisert]

Maybe everything in this small piece of my dts is wrong. But I don't know h=
ow
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.

	[...]
        lpb@fe000000 {
                model =3D "fsl,lpb";
                compatible =3D "fsl,lpb";
                ranges =3D <0x0 0xfe000000 0x02000000>;
                flash@0 {
                        compatible =3D "cfi-flash";
                        reg =3D <0x00000000 0x02000000>;
                        bank-width =3D <4>;
		};
	};

The dtc gives me the follwing output:

Warning (reg_format): "reg" property in /lpb@fe000000/flash@0 has invalid l=
ength (8 bytes) (#address-cells =3D=3D 2, #size-cells =3D=3D 1)
Warning (ranges_format): "ranges" property in /lpb@fe000000 has invalid len=
gth (12 bytes) (parent #address-cells =3D=3D 1, child #address-cells =3D=3D=
 2, #size-cells =3D=3D 1)
Warning (avoid_default_addr_size): Relying on default #address-cells value =
for /lpb@fe000000/flash@0
Warning (avoid_default_addr_size): Relying on default #size-cells value for=
 /lpb@fe000000/flash@0

What does it mean?

At runtime I get:

[...]
of-flash fe000000.flash: of_flash device: fe000000-ffffffff
CFI: Found no fe000000.flash device at location zero
of-flash fe000000.flash: do_map_probe() failed
[...]

What's going wrong? Any hint?

Regards,
Juergen

=2D-=20
Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de
=A0Pengutronix - Linux Solutions for Science and Industry
=A0   Handelsregister: Amtsgericht Hildesheim, HRA 2686
=A0 =A0 =A0    Vertretung Sued/Muenchen, Germany
   Phone: +49-8766-939 228 |  Fax: +49-5121-206917-9

Re: Comments on device tree for pcm030

[Grant Likely]

On Tue, Jun 10, 2008 at 3:05 AM, Juergen Beisert <jbe@pengutronix.de> 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.
>
>        [...]
>        lpb@fe000000 {
>                model = "fsl,lpb";
>                compatible = "fsl,lpb";
>                ranges = <0x0 0xfe000000 0x02000000>;

- 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.

>                flash@0 {
>                        compatible = "cfi-flash";
>                        reg = <0x00000000 0x02000000>;

- 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 /lpb@fe000000/flash@0 has invalid length (8 bytes) (#address-cells == 2, #size-cells == 1)
> Warning (ranges_format): "ranges" property in /lpb@fe000000 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 /lpb@fe000000/flash@0
> Warning (avoid_default_addr_size): Relying on default #size-cells value for /lpb@fe000000/flash@0
>
> What does it mean?
>
> At runtime I get:
>
> [...]
> of-flash fe000000.flash: of_flash device: fe000000-ffffffff
> CFI: Found no fe000000.flash device at location zero
> of-flash fe000000.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.

Re: Comments on device tree for pcm030

[Jon Smirl]

On 6/10/08, Grant Likely <grant.likely@secretlab.ca> wrote:
> On Tue, Jun 10, 2008 at 3:05 AM, Juergen Beisert <jbe@pengutronix.de> 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.

I adjusted my previous DTS for the current dtc compiler. This boots on
my pcm030.

If the uboot image for the pcm030 had a redboot compatible partition
table we wouldn't need to specify them in the device tree.

	lpb@ff000000 {
		compatible = "fsl,lpb";
		#address-cells = <2>;
		#size-cells = <1>;
		ranges = <0 0 0xff000000 0x01000000>;
		
		flash@0 {
			compatible = "cfi-flash";
			reg = <0 0 0x01000000>;
			bank-width = <2>;
			device-width = <2>;
			#size-cells = <1>;
			#address-cells = <1>;
			partition@0 {
				label = "ubootl";
				reg = <0x00000000 0x00040000>;
			};
			partition@40000 {
				label = "kernel";
				reg = <0x00040000 0x001c0000>;
			};
			partition@200000 {
				label = "jffs2";
				reg = <0x00200000 0x00D00000>;
			};
			partition@f00000 {
				label = "uboot";
				reg = <0x00f00000 0x00040000>;
			};
			partition@f40000 {
				label = "oftree";
				reg = <0x00f40000 0x00040000>;
			};
			partition@f80000 {
				label = "space";
				reg = <0x00f80000 0x00080000>;
			};
		};
	};
	
ff000000.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
Searching for RedBoot partition table in ff000000.flash at offset 0xfe0000
No RedBoot partition table detected in ff000000.flash
Creating 6 MTD partitions on "ff000000.flash":
0x00000000-0x00040000 : "ubootl"
0x00040000-0x00200000 : "kernel"
0x00200000-0x00f00000 : "jffs2"
0x00f00000-0x00f40000 : "uboot"
0x00f40000-0x00f80000 : "oftree"
0x00f80000-0x01000000 : "space"


-- 
Jon Smirl
jonsmirl@gmail.com