[U-Boot] 85xx: MPC8536DS board does not build

[ksi at koi8.net]

On Mon, 10 Aug 2009, Peter Tyser wrote:

> On Mon, 2009-08-10 at 15:27 -0400, Jerry Van Baren wrote:
> > Kumar Gala wrote:
> > > On Aug 10, 2009, at 1:59 PM, Zang Roy-R61911 wrote:
> > > 
> > >>
> > >>> -----Original Message-----
> > >>> From: Kumar Gala [mailto:galak at kernel.crashing.org]
> > >>> Sent: Monday, August 10, 2009 13:41 PM
> > >>> To: Wolfgang Denk
> > >>> Cc: U-Boot-Users ML; Zang Roy-R61911
> > >>> Subject: Re: 85xx: MPC8536DS board does not build
> > >>>
> > >>>
> > >>> On Aug 10, 2009, at 1:22 PM, Wolfgang Denk wrote:
> > >>>
> > >>>> Dear Kumar Gala,
> > >>>>
> > >>>> In message <0EB7516A-2F14-42F7-
> > >>>> A6ED-555ADFAB3105 at kernel.crashing.org> you wrote:
> > >>>>>> Allocate more space for U-Boot?
> > >>>>> I might turn of BEDBUG as its never been properly enabled on
> > >>>>> e500/85xx
> > >>>>> platforms.
> > >>>> Is there any problem with the bigger image which I don't
> understand
> > >>>> yet? Normally we just move down the TEXT_BASE by a sector,
> > >>> and that's
> > >>>> it.
> > >>> Not specifically, its just that ever 85xx image to date has been
> > >>> 512k.  I'm just trying to avoid this being the first one that
> > >>> changes
> > >>> that historic fact.  Especially since compilers like gcc-4.3 seem
> to
> > >>> be able to fit the size in 512k.
> > >> We may have more requirements to support graphic in u-boot.
> > >> Sooner and later, the size will exceed 512K. Should we have some
> plan
> > >> for this?
> > > 
> > > So if we are going to increase the limit from 512k do we go to 768k
> or  
> > > 1M?  (Sector size on the board appears to 128k)
> > > 
> > > I would also like to know how big the flashes are on some of the
> other  
> > > 85xx boards that u-boot supports.
> > > 
> > > - k
> > 
> > Hi Kumar, Roy,
> > 
> > 512K is pretty big for u-boot (not unheard of, but still...).  Is it 
> > really 512K or is it using a full page to hold the boot page (top 4K
> of 
> > memory) and one page for the env (unavoidable):
> > 
> > +--------------------------------------------------------
> 0x1_0000_0000
> > | One sector dedicated for the power up page (only using 4K)
> > +--------------------------------------------------------
> 0x0_F800_0000
> > | One sector dedicated for the env
> > +--------------------------------------------------------
> 0x0_F000_0000
> > | Two sectors of u-boot
> > +----
> 0x0_E800_0000
> > |
> > +--------------------------------------------------------
> 0x0_E000_0000
> > 
> > 
> > If that is the case, you can gain a sector (less 4K) by rearranging
> your 
> > memory map:
> > +--------------------------------------------------------
> 0x1_0000_0000
> > | One page (4K) of power up vector, the rest is u-boot
> > +----
> 0x0_F800_0000
> > |
> > +----
> 0x0_F000_0000
> > | Three sectors (less 4K) of u-boot
> > +--------------------------------------------------------
> 0x0_E800_0000
> > | One sector dedicated for the env
> > +--------------------------------------------------------
> 0x0_E000_0000
> > 
> > This also makes reprogramming u-boot nicer because your power up
> vector 
> > and u-boot itself are contiguous.
> 
> Hi Jerry,
> Currently a sector shouldn't be wasted just for the 4K boot page.  Your
> second diagram above is similar to current operation - a chunk of the 4k
> bootpage is wasted/unused, but other u-boot code shares the same flash
> sector with the 4K boot page.  So a little space may be wasted, but not
> too much (ie less than 4K).

That is where top boot block flashes come handy... It is not just that 128K
sector is a huge waste for 4K boot block, the same is true for
environment...

---
******************************************************************
*  KSI at home    KOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
******************************************************************