Re: [U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support
On 15 November 2010 15:09, Loïc Minier loic.min...@linaro.org wrote: On Mon, Nov 15, 2010, Albert ARIBAUD wrote: One last question: qemu: fatal: Trying to execute code outside RAM or ROM at 0x3400 Does this mean that qemu does not simulate data or instruction aborts? Not that it is required for u-boot, but it *could* be useful sometimes. I think the only thing it can do is halt :-) qemu does simulate data/insn aborts caused when the MMU is enabled and you try an access forbidden by the access permissions set up in the page table. That particular error message happens when you try to execute from a physical address which isn't RAM or ROM, so you'll only see it if you have not enabled the MMU or if you get your page tables wrong. There's no particular reason this couldn't be made to take a simulated fault instead, I think -- there's an #ifdef that means qemu for Sparc and MIPS will simulate a fault instead of aborting. (In theory I think the behaviour shouldn't necessarily always be to fault, but if there is a non-RAM non-ROM device at the address to simulate the effect of trying to fetch instructions from your serial device registers, for example :-)) This is an example of a general tendency in qemu-arm for the modelling to be a bit weak for situations which will never be triggered by a correct program/OS but which nonetheless have well defined failure behaviour. Other examples include execution of various opcode values which should UNDEF (may trigger qemu internal error warnings or decode to some other instruction), and execution of VFP or Neon when the CPACR is set to disable access to cp10/11 (should fault but won't). Mostly these things don't cause a problem in practice, which is why they haven't been corrected yet. -- PMM ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support
Le 14/11/2010 22:22, Wolfgang Denk a écrit : Dear Albert ARIBAUD, In message4cdba515.3050...@free.fr you wrote: Alright. I'll prepare a V5 patch set with fixes to all ARM cpus. Wolfgang, is a single *patch* for all cpus ok or do you want a single *patchset* with one patch per cpu? Please tell me the single patch approach is ok. :) It is. Thanks in advance. ATM on mainline master branch only five ARM cpus (arm926ejs, arm1136, arm1176, armv7 and pxa) have ELF relocation support. Others still use GOT relocation (or the older fixed-location scheme maybe), which IIUC means all boards using these other cpus are broken unless a maintainer gets patches pulled in to support ELF relocs. I therefore propose that V5 of my patch fixes arm926ejs, armv7, arm1136, arm1176 and pxa only, and leave the ten other ARM cpus untouched. Board maintainers who want to fix their board support for ELF relocs may have to also fix their cpu if it is not yet. Does everyone agree? Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support
Dear Albert ARIBAUD, Am 15.11.2010 12:01, schrieb Albert ARIBAUD: I therefore propose that V5 of my patch fixes arm926ejs, armv7, arm1136, arm1176 and pxa only, and leave the ten other ARM cpus untouched. Board maintainers who want to fix their board support for ELF relocs may have to also fix their cpu if it is not yet. Does everyone agree? arm920t/at91 is ongoing. I may need your help these days but first I need some time to get my last linker related issues fixed properly (segfault when linking empty weak symbol with -pie). regards Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support
Dear Albert ARIBAUD, In message 4ce11314.50...@free.fr you wrote: ATM on mainline master branch only five ARM cpus (arm926ejs, arm1136, arm1176, armv7 and pxa) have ELF relocation support. Others still use GOT relocation (or the older fixed-location scheme maybe), which IIUC means all boards using these other cpus are broken unless a maintainer gets patches pulled in to support ELF relocs. I therefore propose that V5 of my patch fixes arm926ejs, armv7, arm1136, arm1176 and pxa only, and leave the ten other ARM cpus untouched. Board maintainers who want to fix their board support for ELF relocs may have to also fix their cpu if it is not yet. Does everyone agree? I dislike having such a mix of different relocation methods. Let's face it: this discussion has been going on for so long already that every interested party could have adapted their code. I am afraid if we do not force the change now it will never happen. And I do not want to carry on such a bifurcation much longer. Do you think you could convert the remaining CPUs to ELF relocation as well? That would probably provide the best base for any further work. 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: w...@denx.de This is now. Later is later. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support
Dear Andreas,
On 2010-11-15 12:09:58, Andreas Bießmann wrote:
arm920t/at91 is ongoing. I may need your help these days but first I
need some time to get my last linker related issues fixed properly
(segfault when linking empty weak symbol with -pie).
Can you please try the attached patch? It fixed this problem for me.
--
Sebastien
From f4007bb3d05768bbe5c0903f856809618a89e921 Mon Sep 17 00:00:00 2001
From: Sebastien Carlier sebastien.carl...@gmail.com
Date: Wed, 10 Nov 2010 14:41:44 +0100
Subject: [PATCH] arm920t: add .plt and .rel.plt to the linker script
Signed-off-by: Sebastien Carlier sebastien.carl...@gmail.com
---
arch/arm/cpu/arm920t/u-boot.lds |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/cpu/arm920t/u-boot.lds b/arch/arm/cpu/arm920t/u-boot.lds
index d1babcc..dd62bdd 100644
--- a/arch/arm/cpu/arm920t/u-boot.lds
+++ b/arch/arm/cpu/arm920t/u-boot.lds
@@ -42,6 +42,8 @@ SECTIONS
arch/arm/cpu/arm920t/start.o (.text)
*(.text)
}
+ .plt : { *(.plt) }
+ .rel.plt : { *(.rel.plt) }
. = ALIGN(4);
.rodata : { *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata*))) }
--
1.7.3.2.161.g3089c
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support
Le 15/11/2010 12:13, Wolfgang Denk a écrit : Dear Albert ARIBAUD, In message4ce11314.50...@free.fr you wrote: ATM on mainline master branch only five ARM cpus (arm926ejs, arm1136, arm1176, armv7 and pxa) have ELF relocation support. Others still use GOT relocation (or the older fixed-location scheme maybe), which IIUC means all boards using these other cpus are broken unless a maintainer gets patches pulled in to support ELF relocs. I therefore propose that V5 of my patch fixes arm926ejs, armv7, arm1136, arm1176 and pxa only, and leave the ten other ARM cpus untouched. Board maintainers who want to fix their board support for ELF relocs may have to also fix their cpu if it is not yet. Does everyone agree? I dislike having such a mix of different relocation methods. Let's face it: this discussion has been going on for so long already that every interested party could have adapted their code. I am afraid if we do not force the change now it will never happen. And I do not want to carry on such a bifurcation much longer. Understood. Do you think you could convert the remaining CPUs to ELF relocation as well? That would probably provide the best base for any further work. I can make the changes for other cpus, but I cannot perform even basic testing beyond making sure it still builds. Besides, while I can reasonably provide a V5 patch by this evening for the five cpus which already support ELF, I won't be able to provide fixes for the whole of arch/arm/cpu/* until thursday evening/friday morning. Is that ok? Best regards, Wolfgang Denk Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support
On Mon, Nov 15, 2010, Albert ARIBAUD wrote: I can make the changes for other cpus, but I cannot perform even basic testing beyond making sure it still builds. Would qemu be of any help there? You could use e.g. versatile or integrator, and pretend that they use any CPU by changing their config and passing -cpu on the qemu command-line -- Loïc Minier ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support
Dear Albert ARIBAUD, ATM on mainline master branch only five ARM cpus (arm926ejs, arm1136, arm1176, armv7 and pxa) have ELF relocation support. Others still use GOT relocation (or the older fixed-location scheme maybe), which IIUC means all boards using these other cpus are broken unless a maintainer gets patches pulled in to support ELF relocs. I therefore propose that V5 of my patch fixes arm926ejs, armv7, arm1136, arm1176 and pxa only, and leave the ten other ARM cpus untouched. Board maintainers who want to fix their board support for ELF relocs may have to also fix their cpu if it is not yet. Does everyone agree? I dislike having such a mix of different relocation methods. Let's face it: this discussion has been going on for so long already that every interested party could have adapted their code. I am afraid if we do not force the change now it will never happen. And I do not want to carry on such a bifurcation much longer. Understood. Do you think you could convert the remaining CPUs to ELF relocation as well? That would probably provide the best base for any further work. I can make the changes for other cpus, but I cannot perform even basic testing beyond making sure it still builds. Besides, while I can reasonably provide a V5 patch by this evening for the five cpus which already support ELF, I won't be able to provide fixes for the whole of arch/arm/cpu/* until thursday evening/friday morning. Is that ok? Would it not be nice to take the ARM-universal identical code for relocate, clear bss and transfer to relocated code out of each ARM/CPU/*/start.S and move it to ARM/LIB/relocate.S ? You would not have to duplicate and maintain that code in every ARM CPU type. That would also pave the path to the relocation in C which I have started a while ago. Best Regards, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support
Dear Albert ARIBAUD, In message 4ce11e66.5060...@free.fr you wrote: Do you think you could convert the remaining CPUs to ELF relocation as well? That would probably provide the best base for any further work. I can make the changes for other cpus, but I cannot perform even basic testing beyond making sure it still builds. Understood. Eventually I can test on a small number of boards. The rest goes untested - but most of them are in a more or less broken state anyway. Besides, while I can reasonably provide a V5 patch by this evening for the five cpus which already support ELF, I won't be able to provide fixes for the whole of arch/arm/cpu/* until thursday evening/friday morning. Is that ok? That's OK. I will then try to get the recent changes in this night, and the others when the patch becomes available. 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: w...@denx.de The whole world is about three drinks behind. - Humphrey Bogart ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support
Dear =?iso-8859-1?Q?Lo=EFc?= Minier, In message 20101115115556.ga13...@bee.dooz.org you wrote: On Mon, Nov 15, 2010, Albert ARIBAUD wrote: I can make the changes for other cpus, but I cannot perform even basic = testing beyond making sure it still builds. Would qemu be of any help there? You could use e.g. versatile or integrator, and pretend that they use any CPU by changing their config and passing -cpu on the qemu command-line Do you have a working qemu setup and/or documentation how to run U-Boot on such an ARM config? 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: w...@denx.de Conscious is when you are aware of something, and conscience is when you wish you weren't. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support
Le 15/11/2010 13:02, Wolfgang Denk a écrit : Besides, while I can reasonably provide a V5 patch by this evening for the five cpus which already support ELF, I won't be able to provide fixes for the whole of arch/arm/cpu/* until thursday evening/friday morning. Is that ok? That's OK. I will then try to get the recent changes in this night, and the others when the patch becomes available. All right then. I'll push the V5 tonight with support for the first five cpus, and another patch for the remaining ones by end of week. Best regards, Wolfgang Denk Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support
On Mon, 15 Nov 2010 12:49:58 +0100, Albert ARIBAUD albert.arib...@free.fr wrote: Do you think you could convert the remaining CPUs to ELF relocation as well? That would probably provide the best base for any further work. I can make the changes for other cpus, but I cannot perform even basic testing beyond making sure it still builds. Besides, while I can reasonably provide a V5 patch by this evening for the five cpus which already support ELF, I won't be able to provide fixes for the whole of arch/arm/cpu/* until thursday evening/friday morning. Is that ok? I would suggest get those 5 done, reviewed and well tested first. Otherwise, you might find yourself doing the same fix to many cpu's instead of only 5. Then do the other ones and ask maintainers (or somebody else with access to a suitable board on his desk) to perform the test. If you could provide them with a few instructions, they can do the tests real quick and you get consistent reports. Regards, -- Bas ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support
On Mon, Nov 15, 2010, Wolfgang Denk wrote: Do you have a working qemu setup and/or documentation how to run U-Boot on such an ARM config? Sometimes I do ;-) I use either: * Ubuntu QEMU packages - qemu-kvm-extras package has qemu-system-arm; it's usually fairly old because it's built from the qemu-kvm trees/releases * Linaro QEMU packages - currently the qemu-maemo package in this PPA https://launchpad.net/~linaro-maintainers/+archive/tools/+packages provides the qemu-maemo-system-arm command; can be installed along qemu-kvm-extras; this has patches to support OMAP machines from the qemu-maemo/-meego projects, hence the name; in the future, this might be a qemu-linaro instead * upstream QEMU built from git While U-Boot supports integrator, versatile and vexpress, QEMU only supports the first two. I get varying success depending on the exact combination of emulated machine and version of QEMU. Today, I tried the binary u-boot downloads from http://arm.com/community/software-enablement/linux.php (Linux OS Downloads tab) with with qemu-maemo 0.0~20100921+871d996-0ubuntu1~linaro1 and qemu-kvm-extras 0.13.0+noroms-0ubuntu3: machine: | realview-eb realview-pbx-a9 versatilepb QEMU: | + qemu-maemo | partial[1] works works qemu-kvm-extras | partial[1] works crash[2] Unfortunately, these are not built from upstream u-boot sources; I tried building some ARM boards from upstream u-boot with v2010.09 and got these results: machine: | integratorcp versatilepb QEMU: | +- qemu-maemo | crash[3]partial[4] qemu-kvm-extras | crash[3]partial[4] So I'm afraid I couldn't find a fully working combination of U-Boot supported board + QEMU, but I didn't try QEMU tip; I'm Cc:ing Peter who cares for QEMU in Linaro, maybe he has more idea or is tempted to try a tip QEMU :-) If you want to reproduce, run something like: qemu-system-arm -M versatilepb -serial stdio \ -kernel u-boot_bin_u-boot_versatilepb.axf or: qemu-system-arm -nographic -M versatilepb \ -kernel u-boot_bin_u-boot_versatilepb.axf replace qemu-system-arm with qemu-maemo-system-arm if you use qemu-maemo [1] crashes while initializing the NIC; qemu: hardware error: smc91c111_write: Bad reg 0:6 [2] qemu: hardware error: arm_timer_write: Bad offset 101e1fe0 [3] qemu: hardware error: pl011_write: Bad offset 14 [4] crashes after detecting 0 Bytes of DRAM: DRAM: 0 Bytes qemu: fatal: Trying to execute code outside RAM or ROM at 0x3400 -- Loïc Minier ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support
Hi Eric, On 10.11.2010 00:43, Eric Cooper wrote: I have been periodically rebasing my patches for the Seagate DockStar on master. But ever since the elf_reloc changes were merged, I have been unable to get a working build. First I saw symptoms similar to what Alexander Holler reported (failing during NAND initialization due to incorrect BSS relocation), but the latest arm926ejs ld script patches did not fix it. The system would hang here: U-Boot 2010.12-rc1 (Nov 09 2010 - 17:52:38) Seagate FreeAgent DockStar SoC: Kirkwood 88F6281_A0 DRAM: 128 MiB NAND: This was built with the CodeSourcery 2010q1 toolchain. I also included Alexander's patch to double-check the relocation, and no error message gets printed. Did you locally fix arch/arm/cpu/arm926ejs/kirkwood/timer.c to not access uninitialized data (variables timestamp and lastdec) before relocation? Otherwise timer_init() will write into the relocation table which may lead to your problem. If you change unrelated code, timer_init() will overwrite some other relocation table entries and U-Boot seems to work. @Albert: If your patch is applied without fixing the accesses to BSS before relocation, some ARM ports will be broken even when compiling with ELDK 4.2. Best regards, Daniel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support
Le 15/11/2010 15:06, Loïc Minier a écrit : So I'm afraid I couldn't find a fully working combination of U-Boot supported board + QEMU, but I didn't try QEMU tip; I'm Cc:ing Peter who cares for QEMU in Linaro, maybe he has more idea or is tempted to try a tip QEMU :-) Not sure I get how this works. Do you need to build u-boot in a special way or with a special toolchain in order to run it in qemu? I'm asking because: If you want to reproduce, run something like: qemu-system-arm -M versatilepb -serial stdio \ -kernel u-boot_bin_u-boot_versatilepb.axf I assume that the -kernel option indicates the executable to run. Would it take an ELF executable? a binary? How would one go about testing running u-boot from RAM, NOR, NAND? Also: [1] crashes while initializing the NIC; qemu: hardware error: smc91c111_write: Bad reg 0:6 [2] qemu: hardware error: arm_timer_write: Bad offset 101e1fe0 [3] qemu: hardware error: pl011_write: Bad offset 14 [4] crashes after detecting 0 Bytes of DRAM: This seems to mean the HW is not 100% simulated, right? One last question: qemu: fatal: Trying to execute code outside RAM or ROM at 0x3400 Does this mean that qemu does not simulate data or instruction aborts? Not that it is required for u-boot, but it *could* be useful sometimes. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support
Le 15/11/2010 15:15, Daniel Hobi a écrit : @Albert: If your patch is applied without fixing the accesses to BSS before relocation, some ARM ports will be broken even when compiling with ELDK 4.2. Thanks for pointing this out. Indeed, my patch is actively based on the assumption that BSS is not used until after relocation, and I did this because not using BSS before relocation is already a known constraint. I'll add a note in the commit. Best regards, Daniel Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support
On Mon, Nov 15, 2010, Albert ARIBAUD wrote: I assume that the -kernel option indicates the executable to run. Correct, IOW u-boot.bin Would it take an ELF executable? a binary? You can pass an ELF as well How would one go about testing running u-boot from RAM, NOR, NAND? I guess you could only test from RAM with the way support for ARM boards is implemented Hmm another option would be OMAP emulation. It might allow you to test all of this; it's a bit more tricky to setup as you need to generate the flash contents, or some SD card. Also, things are a bit messier because this still uses x-loader. Problem is that x-loader probably requires armv7 itself ATM; this becomes quite far-fetched :-/ This seems to mean the HW is not 100% simulated, right? Well, these are either missing simulation or bugs; yes One last question: qemu: fatal: Trying to execute code outside RAM or ROM at 0x3400 Does this mean that qemu does not simulate data or instruction aborts? Not that it is required for u-boot, but it *could* be useful sometimes. I think the only thing it can do is halt :-) -- Loïc Minier ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support
On Mon, Nov 15, 2010 at 03:15:53PM +0100, Daniel Hobi wrote: Did you locally fix arch/arm/cpu/arm926ejs/kirkwood/timer.c to not access uninitialized data (variables timestamp and lastdec) before relocation? I didn't before, but now I have made that change (moved the static vars in timer.c to global_data and reference them via gd). But I get the same behavior (freezing after printing NAND: ). Then I rebuilt my branch with the partial-linking patch applied, but rebased on today's master, and now that fails in the same way. So there's some low-level thing going on that unrelated changes in the source code or build process seem to trigger. Different link order, code placement, phase of moon, ...? I have a JTAG setup, but so far I've only used it to re-load u-boot to RAM after a flashing a bad image. If anyone can give me a clue how to use it with gdb to debug what's going on, please let me know. -- Eric Cooper e c c @ c m u . e d u ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support
Dear Sebastien, Am 15.11.2010 um 12:43 schrieb Sebastien Carlier: Dear Andreas, On 2010-11-15 12:09:58, Andreas Bießmann wrote: arm920t/at91 is ongoing. I may need your help these days but first I need some time to get my last linker related issues fixed properly (segfault when linking empty weak symbol with -pie). Can you please try the attached patch? It fixed this problem for me. yes it works, the ASSERT/SEGFAULT are gone. I've never tested to place these two sections that early in the ELF. I used to place them between .rel.dyn and .bss (after applying Albert's approach of overloading .rel.dyn with .bss). At that place I still had ASSERT/SEGFAULT failures in linker. Thanks a lot, with this information I may get the arm920t elf relocation fixed. regards Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support
Dear Albert ARIBAUD, In message 4cdba515.3050...@free.fr you wrote: Alright. I'll prepare a V5 patch set with fixes to all ARM cpus. Wolfgang, is a single *patch* for all cpus ok or do you want a single *patchset* with one patch per cpu? Please tell me the single patch approach is ok. :) It is. Thanks in advance. 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: w...@denx.de There are three ways to get something done: (1) Do it yourself. (2) Hire someone to do it for you. (3) Forbid your kids to do it. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support
Le 10/11/2010 14:24, Daniel Hobi a écrit : On 10.11.2010 13:48, Albert ARIBAUD wrote: Le 10/11/2010 13:31, Daniel Hobi a écrit : But shouldn't this change be applied to all ARM linker scripts, ie arch/arm/cpu/*/u-boot.lds? Yes, it should. :) Can you please provide such a patch? I could, but I tend to provide patches only for boards that I can test, which basically covers only arm926ejs, or that I can get tested; I'd prefer not to provide patches for HW that I cannot test, and thus I would prefer that patches for other cpus be handled by people who actually own boards with these cpus and can test their patching. After all, this very bugfix is due to ELF relocations having been tested with too poor a range of toolchains. I prefer a single patch to solve one problem in all places. And since you probably have most experience with the new ARM relocation, that patch should come from you. Figures. :) The ARM architecture and board maintainers will test your patch during the current release cycle. Alright. I'll prepare a V5 patch set with fixes to all ARM cpus. Wolfgang, is a single *patch* for all cpus ok or do you want a single *patchset* with one patch per cpu? Please tell me the single patch approach is ok. :) Best regards, Daniel Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support
Hi Albert, On 09.11.2010 19:47, Albert ARIBAUD wrote: Le 09/11/2010 19:24, Daniel Hobi a écrit : Thank you. This patch is required to get Kirkwood-based boards working again when using the CodeSourcery 2009q3 toolchain. (can't find the 2010q3 Lite toolchain on CodeSourcery's site, latest is 2010q1 apparently... Can you tell me which gcc and which ld version is used in 2010q3?) Andreas is correct: I'm still using Sourcery G++ Lite 2009q3-67. I think this V4 of my patchset could be now committed to u-boot-arm/master, and if possible even on u-boot-arm for the december release of u-boot, as it is a bugfix. Since all ARM boards are broken when using a recent toolchain, the patch should go in as fast as possible. But shouldn't this change be applied to all ARM linker scripts, ie arch/arm/cpu/*/u-boot.lds? Yes, it should. :) Can you please provide such a patch? And on many ARM platforms (including Kirkwood), the timer implementation is still accessing BSS variables before relocation. Is someone working on this? Candidates are: $ git grep static ulong timestamp arch/arm/cpu/arm1136/mx31/timer.c:static ulong timestamp; arch/arm/cpu/arm1136/omap24xx/timer.c:static ulong timestamp; arch/arm/cpu/arm1176/tnetv107x/timer.c:static ulong timestamp; arch/arm/cpu/arm720t/interrupts.c:static ulong timestamp; arch/arm/cpu/arm920t/a320/timer.c:static ulong timestamp; arch/arm/cpu/arm920t/at91rm9200/timer.c:static ulong timestamp; arch/arm/cpu/arm920t/s3c24x0/timer.c:static ulong timestamp; arch/arm/cpu/arm926ejs/davinci/timer.c:static ulong timestamp; arch/arm/cpu/arm926ejs/kirkwood/timer.c:static ulong timestamp; arch/arm/cpu/arm926ejs/mx25/timer.c:static ulong timestamp; arch/arm/cpu/arm926ejs/mx27/timer.c:static ulong timestamp; arch/arm/cpu/arm926ejs/omap/timer.c:static ulong timestamp; arch/arm/cpu/arm926ejs/orion5x/timer.c:static ulong timestamp; arch/arm/cpu/arm926ejs/spear/timer.c:static ulong timestamp; arch/arm/cpu/arm926ejs/versatile/timer.c:static ulong timestamp; arch/arm/cpu/armv7/mx5/timer.c:static ulong timestamp; arch/arm/cpu/armv7/omap-common/timer.c:static ulong timestamp; arch/arm/cpu/lh7a40x/timer.c:static ulong timestamp; arch/arm/cpu/s3c44b0/timer.c:static ulong timestamp; Normally, the board maintainers should handle this during the window after next version... Dunno if that is practical, but OTOH it would easily show which boards are still maintained and which are not. :) Since accessing BSS variables before relocation is a severe bug, we should handle this now for all SoCs. But right now, there are two approaches: - Perform initialization of static variables after relocation, and thus forbid using functions which access such variables before relocation (reset_timer*, get_timer*, set_timer). You patched arch/arm/cpu/arm926ejs/orion5x/timer.c to use this approach. - Move static variables to struct global_data, so they can be used before relocation. Used by AT91 timers and proposed for A320 and S3C64xx in: http://article.gmane.org/gmane.comp.boot-loaders.u-boot/88095 http://article.gmane.org/gmane.comp.boot-loaders.u-boot/88160 I hope we can solve this problem in the same way for all ARM timers. And if we use the second approach, we probably can generalize the AT91 data in struct global_data as proposed by Andreas. Best regards, Daniel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support
Le 10/11/2010 13:31, Daniel Hobi a écrit : Since all ARM boards are broken when using a recent toolchain, the patch should go in as fast as possible. But shouldn't this change be applied to all ARM linker scripts, ie arch/arm/cpu/*/u-boot.lds? Yes, it should. :) Can you please provide such a patch? I could, but I tend to provide patches only for boards that I can test, which basically covers only arm926ejs, or that I can get tested; I'd prefer not to provide patches for HW that I cannot test, and thus I would prefer that patches for other cpus be handled by people who actually own boards with these cpus and can test their patching. After all, this very bugfix is due to ELF relocations having been tested with too poor a range of toolchains. Since accessing BSS variables before relocation is a severe bug, we should handle this now for all SoCs. But right now, there are two approaches: - Perform initialization of static variables after relocation, and thus forbid using functions which access such variables before relocation (reset_timer*, get_timer*, set_timer). You patched arch/arm/cpu/arm926ejs/orion5x/timer.c to use this approach. - Move static variables to struct global_data, so they can be used before relocation. Used by AT91 timers and proposed for A320 and S3C64xx in: http://article.gmane.org/gmane.comp.boot-loaders.u-boot/88095 http://article.gmane.org/gmane.comp.boot-loaders.u-boot/88160 I hope we can solve this problem in the same way for all ARM timers. And if we use the second approach, we probably can generalize the AT91 data in struct global_data as proposed by Andreas. Either way is ok with me. Best regards, Daniel Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support
On 10.11.2010 13:48, Albert ARIBAUD wrote: Le 10/11/2010 13:31, Daniel Hobi a écrit : But shouldn't this change be applied to all ARM linker scripts, ie arch/arm/cpu/*/u-boot.lds? Yes, it should. :) Can you please provide such a patch? I could, but I tend to provide patches only for boards that I can test, which basically covers only arm926ejs, or that I can get tested; I'd prefer not to provide patches for HW that I cannot test, and thus I would prefer that patches for other cpus be handled by people who actually own boards with these cpus and can test their patching. After all, this very bugfix is due to ELF relocations having been tested with too poor a range of toolchains. I prefer a single patch to solve one problem in all places. And since you probably have most experience with the new ARM relocation, that patch should come from you. The ARM architecture and board maintainers will test your patch during the current release cycle. Best regards, Daniel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support
On Wed, Nov 10, 2010 at 08:53:03AM +0100, Albert ARIBAUD wrote:
Can you make the ELF images available? I'll do the readlf/objdump
analysis and feed back on what I find.
I've uploaded them here:
http://www.cs.cmu.edu/~ecc/u-boot.{good,bad}
Thanks.
--
Eric Cooper e c c @ c m u . e d u
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support
Le 10/11/2010 15:20, Eric Cooper a écrit :
On Wed, Nov 10, 2010 at 08:53:03AM +0100, Albert ARIBAUD wrote:
Can you make the ELF images available? I'll do the readlf/objdump
analysis and feed back on what I find.
I've uploaded them here:
http://www.cs.cmu.edu/~ecc/u-boot.{good,bad}
Thanks.
I haven't found any obvious issue in the files for either good or bad
case: relocation tables are generated and correct with only types 23 and
2 records, and relocation symbols are produced and with the correct values.
the only one case I had where the code after correct relocation did not
function properly was with tx25 where the hard-coded binary size in the
config file was smaller than the actual binary size, causing only part
of the relocation table to be read back from NAND to RAM, thus skipping
a good deal of actual relocations. But here the bad case is smaller
than the good case, so even if you're using a hard-coded binary size,
*most probably* it is still ok.
Which means I cannot see why this code would not work with relocations,
all the more so since Sébastien's patches do not touch compiler or
linker flags unless I missed something. :/
However much I hate taking a let's pretend it did not happen stance, I
think the most effective approach here is to consider that if no-one has
issues with the ELF relocation V4 patch (Wolfgang? Alexander?) on
currently supported boards, then it only causes problems on a
not-yet-pulled-in board, so:
- V4 should be integrated now as a bug fix for existing supported boards;
- Dockstar support should be applied only after Sébastien's patches are.
Any comments?
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support
Le 04/11/2010 23:27, Albert ARIBAUD a écrit : Le 04/11/2010 23:22, Albert Aribaud a écrit : older ld emitted all ELF relocations in input sections named ..rel.dyn, whereas newer ld uses names of the form .rel*. The linker script only collected .rel.dyn input sections. Rewrite to collect all .rel* input sections and overlay with .bss. Signed-off-by: Albert Aribaudalbert.arib...@free.fr Tested on openrd_base, boots fine, works fine. Wolfgang, please test with tx25. Alexander, please test above your patches in place of previous patch v3. Others who are willing to test on other ARMs are welcome too. :) Did testers manage to try this patch set? I'd like to make sure it solves current issues with master for ARM relocation. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support
Le 09/11/2010 19:24, Daniel Hobi a écrit : Hi Albert, On 04.11.2010 23:22, Albert Aribaud wrote: older ld emitted all ELF relocations in input sections named .rel.dyn, whereas newer ld uses names of the form .rel*. The linker script only collected .rel.dyn input sections. Rewrite to collect all .rel* input sections and overlay with .bss. Tested-by: Daniel Hobidaniel.h...@schmid-telecom.ch Thanks Daniel for the test. Thank you. This patch is required to get Kirkwood-based boards working again when using the CodeSourcery 2009q3 toolchain. (can't find the 2010q3 Lite toolchain on CodeSourcery's site, latest is 2010q1 apparently... Can you tell me which gcc and which ld version is used in 2010q3?) I think this V4 of my patchset could be now committed to u-boot-arm/master, and if possible even on u-boot-arm for the december release of u-boot, as it is a bugfix. But shouldn't this change be applied to all ARM linker scripts, ie arch/arm/cpu/*/u-boot.lds? Yes, it should. :) And on many ARM platforms (including Kirkwood), the timer implementation is still accessing BSS variables before relocation. That is fixed in the orion5x code; a git blame on the timer.c file will tell you which commit of mine did the fix, and from then you can port to kirkwood as the orion5x code comes from the kirkwood one. Is someone working on this? Candidates are: $ git grep static ulong timestamp arch/arm/cpu/arm1136/mx31/timer.c:static ulong timestamp; arch/arm/cpu/arm1136/omap24xx/timer.c:static ulong timestamp; arch/arm/cpu/arm1176/tnetv107x/timer.c:static ulong timestamp; arch/arm/cpu/arm720t/interrupts.c:static ulong timestamp; arch/arm/cpu/arm920t/a320/timer.c:static ulong timestamp; arch/arm/cpu/arm920t/at91rm9200/timer.c:static ulong timestamp; arch/arm/cpu/arm920t/s3c24x0/timer.c:static ulong timestamp; arch/arm/cpu/arm926ejs/davinci/timer.c:static ulong timestamp; arch/arm/cpu/arm926ejs/kirkwood/timer.c:static ulong timestamp; arch/arm/cpu/arm926ejs/mx25/timer.c:static ulong timestamp; arch/arm/cpu/arm926ejs/mx27/timer.c:static ulong timestamp; arch/arm/cpu/arm926ejs/omap/timer.c:static ulong timestamp; arch/arm/cpu/arm926ejs/orion5x/timer.c:static ulong timestamp; arch/arm/cpu/arm926ejs/spear/timer.c:static ulong timestamp; arch/arm/cpu/arm926ejs/versatile/timer.c:static ulong timestamp; arch/arm/cpu/armv7/mx5/timer.c:static ulong timestamp; arch/arm/cpu/armv7/omap-common/timer.c:static ulong timestamp; arch/arm/cpu/lh7a40x/timer.c:static ulong timestamp; arch/arm/cpu/s3c44b0/timer.c:static ulong timestamp; Normally, the board maintainers should handle this during the window after next version... Dunno if that is practical, but OTOH it would easily show which boards are still maintained and which are not. :) Best regards, Daniel Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support
Le 09/11/2010 19:47, Albert ARIBAUD a écrit : I think this V4 of my patchset could be now committed to u-boot-arm/master, and if possible even on u-boot-arm for the december release of u-boot, as it is a bugfix. ... even on u-boot, not u-boot-arm, of course. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support
Dear Daniel Hobi, Am 09.11.2010 um 19:24 schrieb Daniel Hobi: And on many ARM platforms (including Kirkwood), the timer implementation is still accessing BSS variables before relocation. Is someone working on this? Candidates are: $ git grep static ulong timestamp arch/arm/cpu/arm1136/mx31/timer.c:static ulong timestamp; arch/arm/cpu/arm1136/omap24xx/timer.c:static ulong timestamp; arch/arm/cpu/arm1176/tnetv107x/timer.c:static ulong timestamp; arch/arm/cpu/arm720t/interrupts.c:static ulong timestamp; arch/arm/cpu/arm920t/a320/timer.c:static ulong timestamp; arch/arm/cpu/arm920t/at91rm9200/timer.c:static ulong timestamp; arch/arm/cpu/arm920t/at91rm9200/ is dead an will be removed soon. arch/arm/cpu/arm920t/at91/ still misses such an implementation but will be something like arch/arm/cpu/arm926ejs/at91/ BTW couldn't the stuff in #ifdef CONFIG_AT91FAMILY in global_data generalized in some way to be used for all arm boards? regards Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support
Dear Albert Ardibaud, Am 09.11.2010 um 19:47 schrieb Albert ARIBAUD: Thank you. This patch is required to get Kirkwood-based boards working again when using the CodeSourcery 2009q3 toolchain. (can't find the 2010q3 Lite toolchain on CodeSourcery's site, latest is 2010q1 apparently... Can you tell me which gcc and which ld version is used in 2010q3?) I think http://www.codesourcery.com/sgpp/lite/arm/portal/release1033 was meant ... regards Andreas Bießmann___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support
Le 09/11/2010 20:27, Andreas Bießmann a écrit : BTW couldn't the stuff in #ifdef CONFIG_AT91FAMILY in global_data generalized in some way to be used for all arm boards? Don't know for others, but regarding the timer, there is no need for timestamp before relocation, so it needs not join gd stuff. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support
I have been periodically rebasing my patches for the Seagate DockStar on master. But ever since the elf_reloc changes were merged, I have been unable to get a working build. First I saw symptoms similar to what Alexander Holler reported (failing during NAND initialization due to incorrect BSS relocation), but the latest arm926ejs ld script patches did not fix it. The system would hang here: U-Boot 2010.12-rc1 (Nov 09 2010 - 17:52:38) Seagate FreeAgent DockStar SoC: Kirkwood 88F6281_A0 DRAM: 128 MiB NAND: This was built with the CodeSourcery 2010q1 toolchain. I also included Alexander's patch to double-check the relocation, and no error message gets printed. Today, I decided to try out Sebastien Carlier's patch to change to partial linking, and to my surprise it now works. I have the two ELF images in case anyone can suggest what I should look for to see why one is working and the other isn't. But I don't know much about interpreting readelf or objdump output. Also, I'd like to resubmit the latest version of the DockStar patch to the list. Should I base it on the partial-linking patch, or on master (knowing that it may not produce a working build in this case)? -- Eric Cooper e c c @ c m u . e d u ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support
Le 10/11/2010 00:43, Eric Cooper a écrit : I have been periodically rebasing my patches for the Seagate DockStar on master. But ever since the elf_reloc changes were merged, I have been unable to get a working build. First I saw symptoms similar to what Alexander Holler reported (failing during NAND initialization due to incorrect BSS relocation), but the latest arm926ejs ld script patches did not fix it. The system would hang here: U-Boot 2010.12-rc1 (Nov 09 2010 - 17:52:38) Seagate FreeAgent DockStar SoC: Kirkwood 88F6281_A0 DRAM: 128 MiB NAND: This was built with the CodeSourcery 2010q1 toolchain. I also included Alexander's patch to double-check the relocation, and no error message gets printed. Today, I decided to try out Sebastien Carlier's patch to change to partial linking, and to my surprise it now works. I have the two ELF images in case anyone can suggest what I should look for to see why one is working and the other isn't. But I don't know much about interpreting readelf or objdump output. Can you make the ELF images available? I'll do the readlf/objdump analysis and feed back on what I find. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support
Dear Albert Aribaud, older ld emitted all ELF relocations in input sections named .rel.dyn, whereas newer ld uses names of the form .rel*. The linker script only collected .rel.dyn input sections. Rewrite to collect all .rel* input sections and overlay with .bss. Signed-off-by: Albert Aribaud albert.arib...@free.fr --- Thank you, works fine with: gcc 4.2.4 (binary size 258700) gcc 4.3.5 (binary size 251600 - nice!) (ARM9 AT91SAM9XE512, top9000, TOT u-boot-atmel at91cleanup-rework branch) Signed-off-by: Reinhard Meyer u-b...@emk-elektronik.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support
Le 05/11/2010 09:38, Reinhard Meyer a écrit : Dear Albert Aribaud, older ld emitted all ELF relocations in input sections named .rel.dyn, whereas newer ld uses names of the form .rel*. The linker script only collected .rel.dyn input sections. Rewrite to collect all .rel* input sections and overlay with .bss. Signed-off-by: Albert Aribaudalbert.arib...@free.fr --- Thank you, works fine with: gcc 4.2.4 (binary size 258700) gcc 4.3.5 (binary size 251600 - nice!) (ARM9 AT91SAM9XE512, top9000, TOT u-boot-atmel at91cleanup-rework branch) Thanks for testing. The size reduction is due to the gcc ARM backend which has obviously undergone many improvements since gcc 4.2.x. Openrd_base goes from 376 to 360k, and edminiv2 (untested yet, though) from 152 to 144k when using the CS arm-2010q1-202 toolchain (4.4.1) instead of the ELDK 4.2 one (gcc 4.2.2). Signed-off-by: Reinhard Meyeru-b...@emk-elektronik.de Did you mean 'Tested-by:'? Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support
Le 04/11/2010 23:22, Albert Aribaud a écrit : older ld emitted all ELF relocations in input sections named ..rel.dyn, whereas newer ld uses names of the form .rel*. The linker script only collected .rel.dyn input sections. Rewrite to collect all .rel* input sections and overlay with .bss. Signed-off-by: Albert Aribaudalbert.arib...@free.fr Tested on openrd_base, boots fine, works fine. Wolfgang, please test with tx25. Alexander, please test above your patches in place of previous patch v3. Others who are willing to test on other ARMs are welcome too. :) Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
