On Mon, 2009-09-28 at 16:41 +0200, Joakim Tjernlund wrote:
Peter Tyser ptyser@xes-inc.com wrote on 28/09/2009 14:45:46:
On Mon, 2009-09-28 at 09:34 +0200, Joakim Tjernlund wrote:
Peter Tyser ptyser@xes-inc.com wrote on 28/09/2009 06:31:28:
On Sun, 2009-09-27 at 15:15 +0200, Joakim Tjernlund wrote:
Wolfgang Denk wd@denx.de wrote on 23/09/2009 20:23:14:
Dear Peter Tyser,
In message 1253710639.3968.19.camel@ptyser-laptop you wrote: > > My "fix" to the linker script was to change: > __bss_start = .; > into: > __bss_start = . | 4; > > ie, a big hack, but it did work:) I'll take a peek at a more proper > link script workaround.
32 bit alignment of the BSS segment might not be sufficient. Be careful!
Any progress on this ?
I've been swamped the last few days, but think I have a workaround. I hope to test it tomorrow or tues. I'll send an email when I have a more definitive answer.
> Nice! It'd be great to have the magical 20 lines of assembly put into > some semi-understandable c.
:-)
I have worked some more on this but all boards need to be converted to use the new C-variants.
Great!
Anyhow, I have also been thinking/working on making U-boot fully PIC and reached a important conclusion. The GOT holds absolute ptr values and there is not much one can do about it sans modifying gcc. So before u-boot is relocated to RAM one must manually add any offset to all global/static data and string literals. The majority of strings are passed directly to printf and friends so the offset can be added inside printf. The remaining few data accesses needs to be dealt with directly, example:
for (init_fnc_ptr = init_sequence; *init_fnc_ptr; ++init_fnc_ptr) {
for (init_fnc_ptr = got_off(init_sequence); *init_fnc_ptr; ++init_fnc_ptr) {
Only code called before relocation to RAM needs this, mostly the _f() functions. Would this be an acceptable change?
Could you describe the advantages of generating a fully PIC U-Boot image? I understand you could execute the image from different places in flash, but on the boards I've worked with this isn't a huge concern. For example, its possible to have a preliminary flash mapping that U-Boot executes from, then after relocation to RAM that flash mapping can be modified. So where U-Boot initially executes from isn't all that important for me. Is there some killer feature that a fully PIC U-Boot provides to make adding the got_off() workarounds you mention worthwhile?
For me, it is mainly to be to have two u-boot partitions and be able to select one to boot from. This makes it safer to update u-boot in the field.
Peter, I just discovered that my gcc 3.4.6 allows me to use -mrelocatable with -fpie -fpie is about the same as -fpic and -fPIE is similar to -fPIC -fpie generates smaller code so one could consider using -fpie and -mrelocatable However -fpic/-fpie needs some fixes to the relocation code, but a quick hack by me works on my board.
Does -fpie and -mrelocatable compile for you and do you have a non zero fixup section?
-fpie and -mrelocatable does compile for me (tested on the XPedite5370 with gcc 4.2.2) and has a non-zero fixup section. However, the -fpie U-Boot image is slightly larger:
ptyser@petert u-boot $ size u-boot.PIC text data bss dec hex filename 304300 28644 33156 366100 59614 u-boot.PIC
ptyser@petert u-boot $ size u-boot.pie text data bss dec hex filename 304508 28624 33156 366288 596d0 u-boot.pie
Let me know if I can provide any additional detail.
Best, Peter