[PATCH] powerpc/85xx: DTS - re-organize the SPI partitions property

[Hu Mingkai-B21284]

> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Wednesday, September 25, 2013 3:37 AM
> To: Hu Mingkai-B21284
> Cc: Wood Scott-B07421; linuxppc-dev at ozlabs.org
> Subject: Re: [PATCH] powerpc/85xx: DTS - re-organize the SPI partitions
> property
> 
> On Tue, 2013-09-24 at 05:27 -0500, Hu Mingkai-B21284 wrote:
> >
> > > -----Original Message-----
> > > From: Wood Scott-B07421
> > > Sent: Tuesday, September 24, 2013 7:03 AM
> > > To: Hu Mingkai-B21284
> > > Cc: Wood Scott-B07421; linuxppc-dev at 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:
> > > > Scott,
> > > > Sorry for the delayed response.
> > > > Please fine my comments.
> > > > Thanks,
> > > > Mingkai
> > > >
> > > > > -----Original Message-----
> > > > > From: Wood Scott-B07421
> > > > > Sent: Thursday, September 12, 2013 9:16 AM
> > > > > To: Hu Mingkai-B21284
> > > > > Cc: Wood Scott-B07421; linuxppc-dev at 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:
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Wood Scott-B07421
> > > > > > > Sent: Wednesday, September 11, 2013 7:33 AM
> > > > > > > To: Hu Mingkai-B21284
> > > > > > > Cc: linuxppc-dev at 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).
> 
> > > > > > > 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.
> > > > > 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,

I will submit a patch in U-Boot to fix this issue. Some quick questions:
1. Should we set the SPI flash as MTDPARTS_DEFAULT?
2. Should we consider the partition for NAND/NOR in mtdparts?
3. We need to remove the partition table in device tree, right?

Thanks,
Mingkai