From: Peter Tyser <ptyser@xes-inc.com>
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 10:45:32 -0500 [thread overview]
Message-ID: <1254843932.24664.2083.camel@localhost.localdomain> (raw)
In-Reply-To: <20091006152210.37EB2F15B3E@gemini.denx.de>
Hi Wolfgang,
> So far U-Boot is actually a 32 bit boot loader; address calculations
> like this "just wrap around". So far this has not caused problems yet;
> what has caused problems is that we can have overlapping sections on
> 4xx. Also it's probably overkill that each board has it's own linker
> script.
I added some debug and came to the same conclusion about the wrapping
math.
Full ack on the linker script consolidation.
> I would like to see this fixed in this process. Maybe Stefan finds
> some spare cycles to address this.
>
> > > Where is BSS on 44x boards? I dont see any reason we shouldn't be
> > > able to put it at the same location.
> >
> > >From the XPedite1000:
> >
> > [ 0] NULL 00000000 000000 000000 00 0 0 0
> > [ 1] .resetvec PROGBITS fffffffc 03f2e4 000004 00 AX 0 0 1
> > [ 2] .bootpg PROGBITS fffff000 03e2e8 000250 00 AX 0 0 1
> > [ 3] .text PROGBITS fff80000 000094 0303b0 00 AX 0 0 4
> > [ 4] .rodata PROGBITS fffb03b0 030444 00a14c 00 A 0 0 4
> > [ 5] .reloc PROGBITS fffba500 03a594 002280 00 WA 0 0 4
> > [ 6] .data PROGBITS fffbc780 03c814 00088c 00 WA 0 0 4
> > [ 7] .data.rel.local PROGBITS fffbd00c 03d0a0 000a98 00 WA 0 0 4
> > [ 8] .data.rel.ro.loca PROGBITS fffbdaa4 03db38 0000b0 00 WA 0 0 4
> > [ 9] .data.rel PROGBITS fffbdb54 03dbe8 000100 00 WA 0 0 4
> > [10] .u_boot_cmd PROGBITS fffbdc54 03dce8 000600 00 WA 0 0 4
> > [11] .bss NOBITS fffbe300 03e2e8 011c44 00 WA 0 0 4
> >
> > I shied away from this for the 2 reasons above - the bootpg section will
> > be wiped out when the bss is cleared for images near their maximum size
>
> I think it will not be needed any more by then.
Its not currently used (at least on 85xx), but I know using it had been
mentioned in the past. There's a >3K chunk that's sitting empty right
now that could be used. All things being equal I think it would be
ideal not to trash a section of U-Boot code - it could be useful and at
some point someone's going to be banging their head on the wall trying
to figure out why some chunk of assembly code isn't working.
> > If everyone is OK with the limitation of #1 above I can make the 85xx
> > act like the other PPC boards. The only downside I see is that we could
> > never put any non-reset related code in the bootpg.
>
> What about my suggestion to chose a fixed (random, non-zero) address?
I'd vote against this. It'd have to be some area in low memory and
people would be bound to accidentally stomp on it and cause all sorts of
odd errors- like overwriting the exception vectors, but harder to debug.
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.
I know ORing in 0x10 is a bit ugly, but what's the real downside of
doing it?
Best,
Peter
next prev parent reply other threads:[~2009-10-06 15:45 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 [this message]
2009-10-06 17:51 ` Wolfgang Denk
2009-10-06 18:08 ` Peter Tyser
2009-10-06 20:34 ` J. William Campbell
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=1254843932.24664.2083.camel@localhost.localdomain \
--to=ptyser@xes-inc.com \
--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