From: J. William Campbell <jwilliamcampbell@comcast.net>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 0/2] Make sure 85xx bss doesn't start at 0x0
Date: Tue, 06 Oct 2009 13:34:02 -0700 [thread overview]
Message-ID: <4ACBA9BA.809@comcast.net> (raw)
In-Reply-To: <1254852529.24664.2383.camel@localhost.localdomain>
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
>
>
>
next prev parent reply other threads:[~2009-10-06 20:34 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-05 23:01 [U-Boot] [PATCH 0/2] Make sure 85xx bss doesn't start at 0x0 Peter Tyser
2009-10-05 23:01 ` [U-Boot] [PATCH 1/2] 85xx: Preprocess link scripts Peter Tyser
2009-10-06 7:28 ` Wolfgang Denk
2009-10-06 11:13 ` Peter Tyser
2009-10-05 23:01 ` [U-Boot] [PATCH 2/2] 85xx: Ensure BSS segment doesn't start at address 0x0 Peter Tyser
2009-10-06 8:54 ` Wolfgang Denk
2009-10-06 12:10 ` Peter Tyser
2009-10-06 7:32 ` [U-Boot] [PATCH 0/2] Make sure 85xx bss doesn't start at 0x0 Wolfgang Denk
2009-10-06 12:01 ` Peter Tyser
2009-10-06 14:01 ` Wolfgang Denk
2009-10-06 14:07 ` Kumar Gala
2009-10-06 14:24 ` Peter Tyser
2009-10-06 15:22 ` Wolfgang Denk
2009-10-06 15:45 ` Peter Tyser
2009-10-06 17:51 ` Wolfgang Denk
2009-10-06 18:08 ` Peter Tyser
2009-10-06 20:34 ` J. William Campbell [this message]
2009-10-06 20:53 ` Peter Tyser
2009-10-06 22:34 ` J. William Campbell
2009-10-06 23:10 ` Peter Tyser
2009-10-06 23:25 ` Wolfgang Denk
2009-10-06 23:43 ` Peter Tyser
2009-10-07 0:09 ` Peter Tyser
2009-10-07 1:24 ` Graeme Russ
2009-10-07 6:55 ` Wolfgang Denk
2009-10-07 9:56 ` Graeme Russ
2009-10-07 10:07 ` Graeme Russ
2009-10-07 10:32 ` Joakim Tjernlund
2009-10-07 14:37 ` J. William Campbell
2009-10-07 6:53 ` Wolfgang Denk
2009-10-07 11:57 ` Peter Tyser
2009-10-07 12:19 ` Wolfgang Denk
2009-10-06 23:07 ` Wolfgang Denk
2009-10-06 23:29 ` Peter Tyser
2009-10-07 6:51 ` Wolfgang Denk
2009-10-06 20:46 ` Kumar Gala
2009-10-06 21:13 ` Peter Tyser
2009-10-06 16:53 ` Stefan Roese
2009-10-06 15:04 ` Wolfgang Denk
2009-10-06 15:20 ` Peter Tyser
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4ACBA9BA.809@comcast.net \
--to=jwilliamcampbell@comcast.net \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox