From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Tyser Date: Mon, 10 Aug 2009 15:00:33 -0500 Subject: [U-Boot] 85xx: MPC8536DS board does not build In-Reply-To: <4A8074B2.2010403@ge.com> References: <20090810075631.B68EC833DBD2@gemini.denx.de> <0E1A5EEB-51E5-488D-9457-993F95553506@kernel.crashing.org> <20090810175934.5AB66833DBD2@gemini.denx.de> <0EB7516A-2F14-42F7-A6ED-555ADFAB3105@kernel.crashing.org> <20090810182222.70532833DBD2@gemini.denx.de> <3B2BBF16-F683-4711-9844-FF9D8BBBAEFE@kernel.crashing.org> <7DF0AF56456B8F4081E3C44CCCE311DE4E9B16@zch01exm23.fsl.freescale.net> <4A8074B2.2010403@ge.com> Message-ID: <1249934433.11514.633.camel@localhost.localdomain> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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). Best, Peter