From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wolfgang Denk Date: Tue, 06 Oct 2009 17:22:10 +0200 Subject: [U-Boot] [PATCH 0/2] Make sure 85xx bss doesn't start at 0x0 In-Reply-To: <1254839043.24664.1890.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> Message-ID: <20091006152210.37EB2F15B3E@gemini.denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Dear Peter Tyser, In message <1254839043.24664.1890.camel@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_