From mboxrd@z Thu Jan 1 00:00:00 1970 From: York Sun Date: Wed, 16 Oct 2013 13:32:01 -0700 Subject: [U-Boot] powerpc/mpc85xx: Increase image size In-Reply-To: <1381955392.7979.740.camel@snotra.buserror.net> References: <52584386.7050104@freescale.com> <1381516790.7979.524.camel@snotra.buserror.net> <525849F0.60002@freescale.com> <525ECFD4.4080704@freescale.com> <1381952276.7979.737.camel@snotra.buserror.net> <525EF57A.2090105@freescale.com> <1381955392 Message-ID: <525EF7C1.9040908@freescale.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 10/16/2013 01:29 PM, Scott Wood wrote: > On Wed, 2013-10-16 at 13:22 -0700, York Sun wrote: >> On 10/16/2013 12:37 PM, Scott Wood wrote: >>> On Wed, 2013-10-16 at 10:41 -0700, York Sun wrote: >>>> On 10/11/2013 11:56 AM, York Sun wrote: >>>>> On 10/11/2013 11:39 AM, Scott Wood wrote: >>>>>> On Fri, 2013-10-11 at 11:29 -0700, York Sun wrote: >>>>>>> Scott, et al. >>>>>>> >>>>>>> I'd like to start the discussion to increase u-boot image size for some >>>>>>> mpc85xx targets. As we all know the reset vector is at the very end and >>>>>>> linking process start from the top. This gives us no good choice but to >>>>>>> use fixed image size. While we have more and more features, the size >>>>>>> increases inevitably. It's time to adjust the arbitrary size. We are now >>>>>>> using 512KB. Shall we go with 768KB, or even 1MB? >>>>>> >>>>>> 768K would affect fewer existing partition maps (many of which leave 1M >>>>>> for U-Boot and environment combined), but 1M might be better for new >>>>>> boards. And of course it would be nice if someone could spare some time >>>>>> to try to slim things down (finer-grained compile-time config, >>>>>> speed/size tradeoffs, etc). >>>>>> >>>>>>> For the first step, I think we don't have to increase size for all >>>>>>> targets. We can adjust those with CONFIG_SYS_TEXT_BASE=0xeff80000. Those >>>>>>> are the most recent used. There are other targets which don't use NOR >>>>>>> flash boot method. They should be considered as well. >>>>>>> >>>>>>> It is per board configuration. But it may be better if we keep them >>>>>>> consistent. >>>>>> >>>>>> I don't think it's worth trying to keep them consistent. Leave alone >>>>>> old boards that are not pushing the limit, and where testing and user >>>>>> education would be a hassle, and let newer boards where more features >>>>>> are wanted not be constrained by the past. >>>>>> >>>>> >>>>> I did a quick search for eff80000. Only these boards have it >>>>> >>>>> include/configs/B4860QDS.h >>>>> include/configs/C29XPCIE.h >>>>> include/configs/corenet_ds.h >>>>> include/configs/HWW1U1A.h >>>>> include/configs/MPC8536DS.h >>>>> include/configs/MPC8572DS.h >>>>> include/configs/P1010RDB.h >>>>> include/configs/P1022DS.h >>>>> include/configs/P1023RDB.h >>>>> include/configs/P1023RDS.h >>>>> include/configs/P1_P2_RDB.h >>>>> include/configs/p1_p2_rdb_pc.h >>>>> include/configs/p1_twr.h >>>>> include/configs/P2020DS.h >>>>> include/configs/P2041RDB.h >>>>> include/configs/T1040QDS.h >>>>> include/configs/t4qds.h >>>>> >>>> >>>> Scott, >>>> >>>> Are SPL and TPL boot methods immune from the size issue here? >>> >>> Sort of. We still need to fit inside existing partition tables. >>> >> >> PBL boot will be broken if the image size is bigger than 512KB, right? > > It has to be even smaller than that, to make room for early data. > So if we go with 768KB, do we have to convert all PBL boot to SPL boot? York