On Tue, 2013-09-24 at 05:27 -0500, Hu Mingkai-B21284 wrote:

quoted

-----Original Message-----
From: Wood Scott-B07421
Sent: Tuesday, September 24, 2013 7:03 AM
To: Hu Mingkai-B21284
Cc: Wood Scott-B07421; linuxppc-dev@ozlabs.org
Subject: Re: [PATCH] powerpc/85xx: DTS - re-organize the SPI partitions
property

On Tue, 2013-09-17 at 06:06 -0500, Hu Mingkai-B21284 wrote:

quoted

Scott,
Sorry for the delayed response.
Please fine my comments.
Thanks,
Mingkai

quoted

-----Original Message-----
From: Wood Scott-B07421
Sent: Thursday, September 12, 2013 9:16 AM
To: Hu Mingkai-B21284
Cc: Wood Scott-B07421; linuxppc-dev@ozlabs.org
Subject: Re: [PATCH] powerpc/85xx: DTS - re-organize the SPI
partitions property

On Tue, 2013-09-10 at 21:07 -0500, Hu Mingkai-B21284 wrote:

quoted

quoted

-----Original Message-----
From: Wood Scott-B07421
Sent: Wednesday, September 11, 2013 7:33 AM
To: Hu Mingkai-B21284
Cc: linuxppc-dev@ozlabs.org
Subject: Re: [PATCH] powerpc/85xx: DTS - re-organize the SPI
partitions property

What happens to exsting users whose flash is laid out the
existing way, when they upgrade to these device trees?

The SPI flash layout should be mapping the new device tree.

If the existing device tree is used to deploy the SPI flash, the
following issues must be run into as the commit message described:

1. Kernel images would be overlapped with U-Boot image.
2. Kernel images would be overlapped with FMAN ucode.
3. Saving environment variables will crash the kernel image.

Has the SPI U-Boot image always been larger than 512K for all these
platforms?  Why, given that we're under 512K for other boot modes?

For DPAA platform, the ld script used to link the u-boot image is
"./arch/powerpc/cpu/mpc85xx/u-boot.lds" which will generate the 512K
u-boot Image. This image will be split into 64bytes and appended PBL
command for Each 64bytes pieces, so the size of final image must be

greater than 512K.

What is the entry point in SRAM when you load from PBL?  If it is (or can
be made to be) the beginning of the image rather than the end, then turn
off the resetvec and the fixed image size that results.

1. Thus a special ld script need to be provided.

This is already supported.  See CONFIG_SYS_MPC85XX_NO_RESETVEC.

2. Now the spi image size is about 540KB, that's to say the PBL needs about ~30K
   for PBL commands. It's hard to save such a big space even we turn off the
   resetvec.

Turning off the resetvec doesn't just eliminate the resetvec code; it
eliminates the padding to 512K (or if it doesn't, that's a bug to be
fixed).

quoted

quoted

quoted

quoted

quoted

We really should not be putting partition layout info in the
device tree to begin with...

OK, I will remove the layout diagram in the commit message.

That's not what I meant.  I meant that the dts should be describing
hardware, and this is the sort of trouble we run into when we
deviate from that.  A better way would be to use the mtdparts command

line option.

quoted

quoted

Even better would be some sort of on-flash partition table.

You're right, but maybe some customer has already used the device tree

partition table...

My main point was to encourage us to shift away from this rather than to
rip it out right this instant.

Yes, that's the correct way we should go.
Would you please pick up this patch first to resolve current issue we faced?
And we can consider to use the mtdparts or on-flash partition table for long term.

Fixing U-Boot would make the problem go away without any issues with
partition compatibility.  Are you sure nobody's using these SPI
partitions without booting from SPI?  Even if nobody's using this, it
seems a wasteful solution.  These are pretty small flashes.

-Scott