From mboxrd@z Thu Jan 1 00:00:00 1970 From: J. William Campbell Date: Tue, 06 Oct 2009 13:34:02 -0700 Subject: [U-Boot] [PATCH 0/2] Make sure 85xx bss doesn't start at 0x0 In-Reply-To: <1254852529.24664.2383.camel@localhost.localdomain> References: <1254783670-21301-1-git-send-email-ptyser@xes-inc.com> <20091006073212.F1E664C021@gemini.denx.de> <1254830475.22896.43.camel@ptyser-laptop> <20091006140136.E9EE51824EB6@gemini.denx.de> <1DE23DE0-B901-4E15-845C-43889EE0B178@kernel.crashing.org> <1254839043.24664.1890.camel@localhost.localdomain> <20091006152210.37EB2F15B3E@gemini.denx.de> <1254843932.24664.2083.camel@localhost.localdomain> <20091006175100.B4C12F15B3E@gemini.denx.de> <1254852529.24664.2383.camel@localhost.localdomain> Message-ID: <4ACBA9BA.809@comcast.net> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Peter Tyser wrote: > On Tue, 2009-10-06 at 19:51 +0200, Wolfgang Denk wrote: > >> Dear Peter Tyser, >> >> In message <1254843932.24664.2083.camel@localhost.localdomain> you wrote: >> >>> I personally like the current implementation of putting the bss after >>> the entire U-Boot image. It keeps U-Boot's code, malloc pool, stack, >>> bss, etc all in the same general area which is nice, and has the side >>> benefit that the bootpg won't be overwritten. >>> >> OK, if you think so... >> >> >>> I know ORing in 0x10 is a bit ugly, but what's the real downside of >>> doing it? >>> >> Nothing. I just hate to allocate the bss at 0x0, because this is >> actually incorrect - it's the result of an address overflow / >> truncation, and pretty much misleading to someone trying to read and >> understand the code. For the linked image, it does not _look_ as if >> the bss was located _after_ the U-Boot image, it looks detached and >> allocated in low RAM. >> > > Do you have a preference Kumar? You're probably going to be the first > in line to have to deal with any resulting confusion:) > > I personally would rank the options: > 1. OR in an offset to the bss address and leave some good comments in > the linker script and commit message > > 2. Make the bss the last section like other PPC boards which would > result in the bootpg sometimes being overwritten > > 3. Put the bss at an arbitrary address > FWIW, I think an arbitrary address disjoint from the u-boot addresses is best. While u-boot is in ROM, you can't use the bss anyway. The bss will actually be located at an address selected by the u-boot code itself after memory is sized. All references to the bss will be re-located by subtracting the arbitrary start address and adding the run-time chosen start address. So the linked start address is not important, except that is cannot be NULL or it may confuse the relocation code that doesn't want to re-locate NULL pointers. Some of the confusion in this discussion probably stems from the fact that the linker scripts make the bss look like "part of u-boot", when it is really not. It is just a chunk of "zero'ed" ram, located anywhere the u-boot code decides to put it. An arbitrary strange address would make this more apparent. Best Regards, Bill Campbell > Best, > Peter > > _______________________________________________ > U-Boot mailing list > U-Boot at lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot > > >