> -----Original Message----- > From: Wood Scott-B07421 > Sent: Wednesday, September 25, 2013 3:37 AM > To: Hu Mingkai-B21284 > Cc: Wood Scott-B07421; linuxppc-...@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-...@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-...@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-...@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 _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
