[U-Boot] [PATCH 0/2] Make sure 85xx bss doesn't start at 0x0

[Wolfgang Denk]

Dear Peter Tyser,

In message <1254839043.24664.1890.camel at localhost.localdomain> you wrote:
> 
> > > But bss is NOLOAD, and the actual location in the flash is just a
> > > fiction - we never use anything of this but the start address.
> 
> My concern was that we use __bss_start and _end to calculate the size of
> the bss to zero out.  If the bss wraps, I'd be concerned about what gets
> cleared as _end would be truncated to a low memory address while
> __bss_start would be a high memory address.  Or other similar problems -
> I didn't investigate what would really happen, I was just worried what
> could happen:)

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 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.

> and I wasn't sure if there were any ramifications about the bss wrapping
> around to 0.  Other arches must have a similar issue which would
> somewhat imply:
> 1. No one cares if their bootpg/reset vector is cleared

I think this is only relevant while running from flash, but not after
relocation.

> 2. U-Boot works even if the bss wraps around to 0.

This is indeed the case.

> 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?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
I've got to get something inside me. Some coffee  or  something.  And
then the world will somehow be better.
                                     - Terry Pratchett, _Men at Arms_