[U-Boot] New Oxford Semiconductor board with assertion fail in linker
Hi,
I am trying to port support for a board from Oxford Semiconductor to the current head of the git repository. Medion released GPL Sources of their P89626 NAS [1].
In these sources there are using an old version 1.1.2 of U-Boot with some modification a board from Oxford Semiconductor. The board is called ox820.
I made a clone of the git repo [2] and modified the source to get the compiliation working. The modifications I made, can be viewed here [3].
When I am trying to build, I get this error from the linker (I also tried the toolchain which is included in the download from Medion):
/home/michael/x-tools/arm-unknown-eabi/bin/arm-unknown-eabi-ld: BFD (crosstool-NG 1.13.2) 2.21.1 assertion fail /home/michael/tmp/x/.build/src/binutils-2.21.1a/bfd/elf32-arm.c:12478 /bin/bash: line 1: 5991 Segmentation fault /home/michael/x-tools/arm-unknown-eabi/bin/arm-unknown-eabi-ld -pie -T u-boot.lds -Bstatic -Ttext "-1" $UNDEF_SYM arch/arm/cpu/arm1136/start.o --start-group api/libapi.o arch/arm/cpu/arm1136/libarm1136.o arch/arm/lib/libarm.o common/libcommon.o disk/libdisk.o drivers/bios_emulator/libatibiosemu.o drivers/block/libblock.o drivers/dma/libdma.o drivers/fpga/libfpga.o drivers/gpio/libgpio.o drivers/hwmon/libhwmon.o drivers/i2c/libi2c.o drivers/input/libinput.o drivers/misc/libmisc.o drivers/mmc/libmmc.o drivers/mtd/libmtd.o drivers/mtd/nand/libnand.o drivers/mtd/onenand/libonenand.o drivers/mtd/spi/libspi_flash.o drivers/mtd/ubi/libubi.o drivers/net/libnet.o drivers/net/phy/libphy.o drivers/pci/libpci.o drivers/pcmcia/libpcmcia.o drivers/power/libpower.o drivers/rtc/librtc.o drivers/serial/libserial.o drivers/spi/libspi.o drivers/twserial/libtws.o drivers/usb/eth/libusb_eth.o drivers/usb/gadget/libusb_gadget.o drivers/usb/host/libusb_host.o drivers/usb/musb/libusb_musb.o drivers/usb/phy/libusb_phy.o drivers/usb/ulpi/libusb_ulpi.o drivers/video/libvideo.o drivers/watchdog/libwatchdog.o fs/cramfs/libcramfs.o fs/ext2/libext2fs.o fs/fat/libfat.o fs/fdos/libfdos.o fs/jffs2/libjffs2.o fs/reiserfs/libreiserfs.o fs/ubifs/libubifs.o fs/yaffs2/libyaffs2.o lib/libfdt/libfdt.o lib/libgeneric.o lib/lzma/liblzma.o lib/lzo/liblzo.o lib/zlib/libz.o net/libnet.o post/libpost.o board/ox820/libox820.o --end-group /home/michael/medion/u-boot-medion-p89626/arch/arm/lib/eabi_compat.o -L /home/michael/x-tools/arm-unknown-eabi/lib/gcc/arm-unknown-eabi/4.4.6 -lgcc -Map u-boot.map -o u-boot make: *** [u-boot] Error 139
Here is the code from binutils. The assertion fails in the line with the BFD_ASSERT case DT_PLTRELSZ: s = bfd_get_section_by_name (output_bfd, RELOC_SECTION (htab, ".plt")); BFD_ASSERT (s != NULL); dyn.d_un.d_val = s->size; bfd_elf32_swap_dyn_out (output_bfd, &dyn, dyncon); break;
What I am doing wrong? What is missing? Where should I look know? Is this a bug in binutils?
Michael
[1] http://www1.medion.de/downloads/download.pl?lang=de&filename=gpl_source_... [2] http://git.denx.de/u-boot.git/ [3] https://github.com/michaelkebe/u-boot-medion-p89626
Dear Michael Kebe,
In message CAKKM46savtNOR5qxGcnbJkz76AeSY-Lurh--iN4caPj_sbb1yQ@mail.gmail.com you wrote:
When I am trying to build, I get this error from the linker (I also tried the toolchain which is included in the download from Medion):
...
/home/michael/x-tools/arm-unknown-eabi/bin/arm-unknown-eabi-ld: BFD (crosstool-NG 1.13.2) 2.21.1 assertion fail
...
What I am doing wrong? What is missing? Where should I look know? Is this a bug in binutils?
Try a known to be working (with current code) tool chain?
Best regards,
Wolfgang Denk
On Mon, Dec 19, 2011 at 18:58, Wolfgang Denk wd@denx.de wrote:
Try a known to be working (with current code) tool chain?
Dear Wolfgang,
I can built other boards with the same toolchain.
I think I know what I did wrong:
#define CONFIG_SYS_UBOOT_BASE -1 #define CONFIG_SYS_TEXT_BASE -1
To get the preprocessor working I defined these two just with -1. These are used in the start.S of the arm1176 CPU. I have found the CONFIG_SYS_UBOOT_BASE address in the Medion source, but the CONFIG_SYS_TEXT_BASE is still missing. There is no documentation on this. Any hints?
Michael
Dear Michael Kebe,
In message CAKKM46tNid46GwNL_d+XuX-ga+wt-zg1PGt2-_0WJDkLNiLXuA@mail.gmail.com you wrote:
CONFIG_SYS_TEXT_BASE is still missing. There is no documentation on this. Any hints?
Check the old sources for a board specific config.mk file ...
Best regards,
Wolfgang Denk
On Mon, Dec 19, 2011 at 21:01, Wolfgang Denk wd@denx.de wrote:
Check the old sources for a board specific config.mk file ...
There is this in the old include/configs/ox820.h:
#define STATIC_CS0_BASE_PA 0x41000000 #define CFG_NAND_BASE STATIC_CS0_BASE_PA
Do you think that's the correct one?
Michael
Dear Michael Kebe,
In message CAKKM46scTp7XQgGo3F4hpd_sFgO1EoeirpyytBb4394xVfzPTQ@mail.gmail.com you wrote:
On Mon, Dec 19, 2011 at 21:01, Wolfgang Denk wd@denx.de wrote:
Check the old sources for a board specific config.mk file ...
There is this in the old include/configs/ox820.h:
#define STATIC_CS0_BASE_PA 0x41000000 #define CFG_NAND_BASE STATIC_CS0_BASE_PA
Do you think that's the correct one?
No. As I mentioned, look for a config.mk file in the board directory, i. e. probably board/ox820/config.mk or similar. This should contain the definition of TEXT_BASE.
Best regards,
Wolfgang Denk
On Mon, Dec 19, 2011 at 23:13, Wolfgang Denk wd@denx.de wrote:
No. As I mentioned, look for a config.mk file in the board directory, i. e. probably board/ox820/config.mk or similar. This should contain the definition of TEXT_BASE.
Thanks, for the hint! There is TEXT_BASE = 0x60d00000.
Here is the output from a bootup of the old U-Boot: -------------------- Stage-1 Bootloader Tue Aug 9 16:44:00 CST 2011 Attempting to set PLLA to 750MHz ... plla_ctrl0 : 0x0000000A plla_ctrl1 : 0x000F0000 plla_ctrl2 : 0x001D01A0 plla_ctrl3 : 0x00000017 PLLA Set
Setup memory, testing Reading NAND, Image 0 Hdr len: 0x0001A94C Hdr CRC: 0xF0019DAC OK
U-Boot 1.1.2 (Jun 24 2011 - 09:41:57)
U-Boot code: 60D00000 -> 60D1A94C BSS: -> 60D1F004 RAM Configuration: Bank #0: 60000000 128 MB SRAM Configuration: 64KB at 0x50000000 NAND:128 MiB In: serial Out: serial Err: serial Setting Linux mem= boot arg value Hit any key to stop autoboot: 0 --------------------
Is the "U-Boot code" the address CONFIG_SYS_UBOOT_BASE should be set to? If so, then both addresses are the same, is that ok?
However even if I try to build with these addresses, the linking crashes with even more assertion fails: -------------------- /home/michael/x-tools/arm-unknown-eabi/bin/arm-unknown-eabi-ld: BFD (crosstool-NG 1.13.2) 2.21.1 assertion fail /home/michael/tmp/x/.build/src/binutils-2.21.1a/bfd/elf32-arm.c:12241 /home/michael/x-tools/arm-unknown-eabi/bin/arm-unknown-eabi-ld: BFD (crosstool-NG 1.13.2) 2.21.1 assertion fail /home/michael/tmp/x/.build/src/binutils-2.21.1a/bfd/elf32-arm.c:12241 /home/michael/x-tools/arm-unknown-eabi/bin/arm-unknown-eabi-ld: BFD (crosstool-NG 1.13.2) 2.21.1 assertion fail /home/michael/tmp/x/.build/src/binutils-2.21.1a/bfd/elf32-arm.c:12241 /home/michael/x-tools/arm-unknown-eabi/bin/arm-unknown-eabi-ld: BFD (crosstool-NG 1.13.2) 2.21.1 assertion fail /home/michael/tmp/x/.build/src/binutils-2.21.1a/bfd/elf32-arm.c:12241 /home/michael/x-tools/arm-unknown-eabi/bin/arm-unknown-eabi-ld: BFD (crosstool-NG 1.13.2) 2.21.1 assertion fail /home/michael/tmp/x/.build/src/binutils-2.21.1a/bfd/elf32-arm.c:12241 /home/michael/x-tools/arm-unknown-eabi/bin/arm-unknown-eabi-ld: BFD (crosstool-NG 1.13.2) 2.21.1 assertion fail /home/michael/tmp/x/.build/src/binutils-2.21.1a/bfd/elf32-arm.c:12241 /home/michael/x-tools/arm-unknown-eabi/bin/arm-unknown-eabi-ld: BFD (crosstool-NG 1.13.2) 2.21.1 assertion fail /home/michael/tmp/x/.build/src/binutils-2.21.1a/bfd/elf32-arm.c:12241 /home/michael/x-tools/arm-unknown-eabi/bin/arm-unknown-eabi-ld: BFD (crosstool-NG 1.13.2) 2.21.1 assertion fail /home/michael/tmp/x/.build/src/binutils-2.21.1a/bfd/elf32-arm.c:12241 /home/michael/x-tools/arm-unknown-eabi/bin/arm-unknown-eabi-ld: BFD (crosstool-NG 1.13.2) 2.21.1 assertion fail /home/michael/tmp/x/.build/src/binutils-2.21.1a/bfd/elf32-arm.c:12241 /home/michael/x-tools/arm-unknown-eabi/bin/arm-unknown-eabi-ld: BFD (crosstool-NG 1.13.2) 2.21.1 assertion fail /home/michael/tmp/x/.build/src/binutils-2.21.1a/bfd/elf32-arm.c:12241 /home/michael/x-tools/arm-unknown-eabi/bin/arm-unknown-eabi-ld: BFD (crosstool-NG 1.13.2) 2.21.1 assertion fail /home/michael/tmp/x/.build/src/binutils-2.21.1a/bfd/elf32-arm.c:12241 /home/michael/x-tools/arm-unknown-eabi/bin/arm-unknown-eabi-ld: BFD (crosstool-NG 1.13.2) 2.21.1 assertion fail /home/michael/tmp/x/.build/src/binutils-2.21.1a/bfd/elf32-arm.c:12241 /home/michael/x-tools/arm-unknown-eabi/bin/arm-unknown-eabi-ld: BFD (crosstool-NG 1.13.2) 2.21.1 assertion fail /home/michael/tmp/x/.build/src/binutils-2.21.1a/bfd/elf32-arm.c:12241 /home/michael/x-tools/arm-unknown-eabi/bin/arm-unknown-eabi-ld: BFD (crosstool-NG 1.13.2) 2.21.1 assertion fail /home/michael/tmp/x/.build/src/binutils-2.21.1a/bfd/elf32-arm.c:12478 /bin/bash: line 1: 5198 Segmentation fault /home/michael/x-tools/arm-unknown-eabi/bin/arm-unknown-eabi-ld -pie -T u-boot.lds -Bstatic -Ttext 0x60d00000 $UNDEF_SYM arch/arm/cpu/arm1176/start.o --start-group api/libapi.o arch/arm/cpu/arm1176/libarm1176.o arch/arm/lib/libarm.o common/libcommon.o disk/libdisk.o drivers/bios_emulator/libatibiosemu.o drivers/block/libblock.o drivers/dma/libdma.o drivers/fpga/libfpga.o drivers/gpio/libgpio.o drivers/hwmon/libhwmon.o drivers/i2c/libi2c.o drivers/input/libinput.o drivers/misc/libmisc.o drivers/mmc/libmmc.o drivers/mtd/libmtd.o drivers/mtd/nand/libnand.o drivers/mtd/onenand/libonenand.o drivers/mtd/spi/libspi_flash.o drivers/mtd/ubi/libubi.o drivers/net/libnet.o drivers/net/phy/libphy.o drivers/pci/libpci.o drivers/pcmcia/libpcmcia.o drivers/power/libpower.o drivers/rtc/librtc.o drivers/serial/libserial.o drivers/spi/libspi.o drivers/twserial/libtws.o drivers/usb/eth/libusb_eth.o drivers/usb/gadget/libusb_gadget.o drivers/usb/host/libusb_host.o drivers/usb/musb/libusb_musb.o drivers/usb/phy/libusb_phy.o drivers/usb/ulpi/libusb_ulpi.o drivers/video/libvideo.o drivers/watchdog/libwatchdog.o fs/cramfs/libcramfs.o fs/ext2/libext2fs.o fs/fat/libfat.o fs/fdos/libfdos.o fs/jffs2/libjffs2.o fs/reiserfs/libreiserfs.o fs/ubifs/libubifs.o fs/yaffs2/libyaffs2.o lib/libfdt/libfdt.o lib/libgeneric.o lib/lzma/liblzma.o lib/lzo/liblzo.o lib/zlib/libz.o net/libnet.o post/libpost.o board/ox820/libox820.o --end-group /home/michael/medion/u-boot-medion-p89626/arch/arm/lib/eabi_compat.o -L /home/michael/x-tools/arm-unknown-eabi/lib/gcc/arm-unknown-eabi/4.4.6 -lgcc -Map u-boot.map -o u-boot make: *** [u-boot] Error 139 --------------------
Regard, Michael
On Mon, Dec 19, 2011 at 5:26 PM, Michael Kebe michael.kebe@gmail.com wrote:
Here is the output from a bootup of the old U-Boot:
[...]
U-Boot 1.1.2 (Jun 24 2011 - 09:41:57)
[...]
However even if I try to build with these addresses, the linking crashes with even more assertion fails:
Everyone always feels that they need to do a big uprev in one giant step. That is not an insult in any way -- I've also done the same thing. But even if you get it compiled, are you ready to debug silent-boot-death where you don't get a single byte out the UART? The probability of this happening is relatively high, since your origin tree is so old and predates the config.mk removal stuff.
I think in a case like this, you would be well served to start with smaller steps, since your origin is so old. Try moving it just to U-Boot-1_1_4 and see if you can make that work. THat will ensure your process, and your toolchain and your install are OK. Then maybe U-Boot-1_2_0 and then next to v1.3.0, then v1.3.4, then v2008.10 and so on.
In doing so, you'll have a chance to test your images along the way, and you'll eventually find the region in which the assertion failures appear for the 1st time. Sometimes you simply can't see the problems by staring at the code; you really need to know at what point they 1st appeared.
Your patches should be largely portable, since they mostly create new files, and should only make small changes to existing Makefiles, etc. So the task is not too hard to attack incrementally.
Using "git rebase" and enabling "git rerere" in your .gitconfig will be something you'll want to make use of. Once you've got a definitive "good" version, and a definitive "bad" version, you can even make use of git bisect, as long as you remember to layer on your patches at each bisection point before building.
It isn't an answer to your specific problem, but it is a process that will get you there by yourself, at your own pace. And once you have a more concrete focus on what change caused your problem, then when you do ask for help, you will most likely get better help.
Good luck! Paul.
/home/michael/x-tools/arm-unknown-eabi/bin/arm-unknown-eabi-ld: BFD (crosstool-NG 1.13.2) 2.21.1 assertion fail /home/michael/tmp/x/.build/src/binutils-2.21.1a/bfd/elf32-arm.c:12241 /home/michael/x-tools/arm-unknown-eabi/bin/arm-unknown-eabi-ld: BFD (crosstool-NG 1.13.2) 2.21.1 assertion fail /home/michael/tmp/x/.build/src/binutils-2.21.1a/bfd/elf32-arm.c:12241 /home/michael/x-tools/arm-unknown-eabi/bin/arm-unknown-eabi-ld: BFD (crosstool-NG 1.13.2) 2.21.1 assertion fail /home/michael/tmp/x/.build/src/binutils-2.21.1a/bfd/elf32-arm.c:12241 /home/michael/x-tools/arm-unknown-eabi/bin/arm-unknown-eabi-ld: BFD (crosstool-NG 1.13.2) 2.21.1 assertion fail /home/michael/tmp/x/.build/src/binutils-2.21.1a/bfd/elf32-arm.c:12241 /home/michael/x-tools/arm-unknown-eabi/bin/arm-unknown-eabi-ld: BFD (crosstool-NG 1.13.2) 2.21.1 assertion fail /home/michael/tmp/x/.build/src/binutils-2.21.1a/bfd/elf32-arm.c:12241 /home/michael/x-tools/arm-unknown-eabi/bin/arm-unknown-eabi-ld: BFD (crosstool-NG 1.13.2) 2.21.1 assertion fail /home/michael/tmp/x/.build/src/binutils-2.21.1a/bfd/elf32-arm.c:12241 /home/michael/x-tools/arm-unknown-eabi/bin/arm-unknown-eabi-ld: BFD (crosstool-NG 1.13.2) 2.21.1 assertion fail /home/michael/tmp/x/.build/src/binutils-2.21.1a/bfd/elf32-arm.c:12241 /home/michael/x-tools/arm-unknown-eabi/bin/arm-unknown-eabi-ld: BFD (crosstool-NG 1.13.2) 2.21.1 assertion fail /home/michael/tmp/x/.build/src/binutils-2.21.1a/bfd/elf32-arm.c:12241 /home/michael/x-tools/arm-unknown-eabi/bin/arm-unknown-eabi-ld: BFD (crosstool-NG 1.13.2) 2.21.1 assertion fail /home/michael/tmp/x/.build/src/binutils-2.21.1a/bfd/elf32-arm.c:12241 /home/michael/x-tools/arm-unknown-eabi/bin/arm-unknown-eabi-ld: BFD (crosstool-NG 1.13.2) 2.21.1 assertion fail /home/michael/tmp/x/.build/src/binutils-2.21.1a/bfd/elf32-arm.c:12241 /home/michael/x-tools/arm-unknown-eabi/bin/arm-unknown-eabi-ld: BFD (crosstool-NG 1.13.2) 2.21.1 assertion fail /home/michael/tmp/x/.build/src/binutils-2.21.1a/bfd/elf32-arm.c:12241 /home/michael/x-tools/arm-unknown-eabi/bin/arm-unknown-eabi-ld: BFD (crosstool-NG 1.13.2) 2.21.1 assertion fail /home/michael/tmp/x/.build/src/binutils-2.21.1a/bfd/elf32-arm.c:12241 /home/michael/x-tools/arm-unknown-eabi/bin/arm-unknown-eabi-ld: BFD (crosstool-NG 1.13.2) 2.21.1 assertion fail /home/michael/tmp/x/.build/src/binutils-2.21.1a/bfd/elf32-arm.c:12241 /home/michael/x-tools/arm-unknown-eabi/bin/arm-unknown-eabi-ld: BFD (crosstool-NG 1.13.2) 2.21.1 assertion fail /home/michael/tmp/x/.build/src/binutils-2.21.1a/bfd/elf32-arm.c:12478 /bin/bash: line 1: 5198 Segmentation fault /home/michael/x-tools/arm-unknown-eabi/bin/arm-unknown-eabi-ld -pie -T u-boot.lds -Bstatic -Ttext 0x60d00000 $UNDEF_SYM arch/arm/cpu/arm1176/start.o --start-group api/libapi.o arch/arm/cpu/arm1176/libarm1176.o arch/arm/lib/libarm.o common/libcommon.o disk/libdisk.o drivers/bios_emulator/libatibiosemu.o drivers/block/libblock.o drivers/dma/libdma.o drivers/fpga/libfpga.o drivers/gpio/libgpio.o drivers/hwmon/libhwmon.o drivers/i2c/libi2c.o drivers/input/libinput.o drivers/misc/libmisc.o drivers/mmc/libmmc.o drivers/mtd/libmtd.o drivers/mtd/nand/libnand.o drivers/mtd/onenand/libonenand.o drivers/mtd/spi/libspi_flash.o drivers/mtd/ubi/libubi.o drivers/net/libnet.o drivers/net/phy/libphy.o drivers/pci/libpci.o drivers/pcmcia/libpcmcia.o drivers/power/libpower.o drivers/rtc/librtc.o drivers/serial/libserial.o drivers/spi/libspi.o drivers/twserial/libtws.o drivers/usb/eth/libusb_eth.o drivers/usb/gadget/libusb_gadget.o drivers/usb/host/libusb_host.o drivers/usb/musb/libusb_musb.o drivers/usb/phy/libusb_phy.o drivers/usb/ulpi/libusb_ulpi.o drivers/video/libvideo.o drivers/watchdog/libwatchdog.o fs/cramfs/libcramfs.o fs/ext2/libext2fs.o fs/fat/libfat.o fs/fdos/libfdos.o fs/jffs2/libjffs2.o fs/reiserfs/libreiserfs.o fs/ubifs/libubifs.o fs/yaffs2/libyaffs2.o lib/libfdt/libfdt.o lib/libgeneric.o lib/lzma/liblzma.o lib/lzo/liblzo.o lib/zlib/libz.o net/libnet.o post/libpost.o board/ox820/libox820.o --end-group /home/michael/medion/u-boot-medion-p89626/arch/arm/lib/eabi_compat.o -L /home/michael/x-tools/arm-unknown-eabi/lib/gcc/arm-unknown-eabi/4.4.6 -lgcc -Map u-boot.map -o u-boot make: *** [u-boot] Error 139
Regard, Michael _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
On Mon, Dec 19, 2011 at 5:26 PM, Michael Kebe michael.kebe@gmail.com wrote:
Here is the output from a bootup of the old U-Boot:
[...]
U-Boot 1.1.2 (Jun 24 2011 - 09:41:57)
[...]
However even if I try to build with these addresses, the linking
crashes with even more assertion fails:
Everyone always feels that they need to do a big uprev in one giant step. That is not an insult in any way -- I've also done the same thing. But even if you get it compiled, are you ready to debug silent-boot-death where you don't get a single byte out the UART? The probability of this happening is relatively high, since your origin tree is so old and predates the config.mk removal stuff.
I think in a case like this, you would be well served to start with smaller steps, since your origin is so old. Try moving it just to U-Boot-1_1_4 and see if you can make that work. THat will ensure your process, and your toolchain and your install are OK. Then maybe U-Boot-1_2_0 and then next to v1.3.0, then v1.3.4, then v2008.10 and so on.
In doing so, you'll have a chance to test your images along the way, and you'll eventually find the region in which the assertion failures appear for the 1st time. Sometimes you simply can't see the problems by staring at the code; you really need to know at what point they 1st appeared.
Your patches should be largely portable, since they mostly create new files, and should only make small changes to existing Makefiles, etc. So the task is not too hard to attack incrementally.
Using "git rebase" and enabling "git rerere" in your .gitconfig will be something you'll want to make use of. Once you've got a definitive "good" version, and a definitive "bad" version, you can even make use of git bisect, as long as you remember to layer on your patches at each bisection point before building.
It isn't an answer to your specific problem, but it is a process that will get you there by yourself, at your own pace. And once you have a more concrete focus on what change caused your problem, then when you do ask for help, you will most likely get better help.
... or you can just snap in a JTAG debugger, connect GDB and throw some break/watch points here and there ;-)
M
On Mon, Dec 19, 2011 at 10:14 PM, Marek Vasut marek.vasut@gmail.com wrote:
On Mon, Dec 19, 2011 at 5:26 PM, Michael Kebe michael.kebe@gmail.com wrote:
Here is the output from a bootup of the old U-Boot:
[...]
It isn't an answer to your specific problem, but it is a process that will get you there by yourself, at your own pace. And once you have a more concrete focus on what change caused your problem, then when you do ask for help, you will most likely get better help.
... or you can just snap in a JTAG debugger, connect GDB and throw some break/watch points here and there ;-)
And how exactly is a JTAG going to help him resolve compile time issues he's currently having? Sure, JTAG is nice for things, and some are lucky enough to have access to one. But $ means it is not something everyone has, and it is not a substitute for thinking your way through a problem. I'm more apt to use one to restore a bad flash image than anything else more complicated.
P.
M _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Dear Paul Gortmaker,
In message CAP=VYLqd4kn7iQwwjDN3PMh3osBY4SsP+XXkzx2FBW=-xFyw9w@mail.gmail.com you wrote:
... or you can just snap in a JTAG debugger, connect GDB and throw some break/watch points here and there ;-)
And how exactly is a JTAG going to help him resolve compile time issues he's currently having? Sure, JTAG is nice for things, and
Obviously it does not help for compile time errors.
some are lucky enough to have access to one. But $ means it is not something everyone has, and it is not a substitute for thinking your way through a problem. I'm more apt to use one to restore a bad flash image than anything else more complicated.
Indeed there are people who rarely ever use a debugger; instead they use printf() or even plain LEDs (or other GPIOs) for debugging.
feel free to chose any method you feel comfortable with.
Fact is, that a good debugger like GDB is a powerful tool for the experienced user that can save _lots_ of time.
Best regards,
Wolfgang Denk
Dear Paul Gortmaker,
In message CAP=VYLr60CFQ0dBG_x0djGeT_3d9LaCEtUCapu0yk3DgAXNRpA@mail.gmail.com you wrote:
U-Boot 1.1.2 (Jun 24 2011 - 09:41:57)
...
Everyone always feels that they need to do a big uprev in one giant step. That is not an insult in any way -- I've also done the same thing. But even if you get it compiled, are you ready to debug silent-boot-death where you don't get a single byte out the UART? The probability of this happening is relatively high, since your origin tree is so old and predates the config.mk removal stuff.
The probability of this happening is non-negligible for each smaller step as well - there have been so many reorganizations and restructurings you will run into one of these any time.
I think in a case like this, you would be well served to start with smaller steps, since your origin is so old. Try moving it just to U-Boot-1_1_4 and see if you can make that work. THat will ensure your process, and your toolchain and your install are OK. Then maybe U-Boot-1_2_0 and then next to v1.3.0, then v1.3.4, then v2008.10 and so on.
Argh... sorry, but I don't think this is a good idea. This is just aprolongated way of continuous frustration, and a lot of completely wasted efforts.
Come on - porting U-Boot from scratch for a well-supported architecture is not that hard. The most efficient way to revive such an old port is to check what they changed by then ompared to their respective base version, collect all the information about device initialization parameters, and then forget that old code. Instead, restart with current code, and go through step by step.
Doing this gives you incremental success.
Getting all (or any number) of intermediate versions running is just incremental frustrations.
It's a matter of taste which one you prefer, but I rather chose the short and happy path.
Best regards,
Wolfgang Denk
On Mon, Dec 19, 2011 at 23:26, Michael Kebe michael.kebe@gmail.com wrote:
Thanks, for the hint! There is TEXT_BASE = 0x60d00000.
Here is the output from a bootup of the old U-Boot:
Stage-1 Bootloader Tue Aug 9 16:44:00 CST 2011 Attempting to set PLLA to 750MHz ... plla_ctrl0 : 0x0000000A plla_ctrl1 : 0x000F0000 plla_ctrl2 : 0x001D01A0 plla_ctrl3 : 0x00000017 PLLA Set
Setup memory, testing Reading NAND, Image 0 Hdr len: 0x0001A94C Hdr CRC: 0xF0019DAC OK
U-Boot 1.1.2 (Jun 24 2011 - 09:41:57)
U-Boot code: 60D00000 -> 60D1A94C BSS: -> 60D1F004 RAM Configuration: Bank #0: 60000000 128 MB SRAM Configuration: 64KB at 0x50000000 NAND:128 MiB In: serial Out: serial Err: serial Setting Linux mem= boot arg value Hit any key to stop autoboot: 0
Is the "U-Boot code" the address CONFIG_SYS_UBOOT_BASE should be set to? If so, then both addresses are the same, is that ok?
Thanks for the discussion about how to port a new board into U-Boot. But I think these questions are forgotten, any further hints?
Dear Michael Kebe,
In message CAKKM46u=4UrB9+9Sn3HDMvdOdtHvO9p6HWdzTY2WpNExXrD_=A@mail.gmail.com you wrote:
Is the "U-Boot code" the address CONFIG_SYS_UBOOT_BASE should be set to? If so, then both addresses are the same, is that ok?
Thanks for the discussion about how to port a new board into U-Boot. But I think these questions are forgotten, any further hints?
Not forgotten. But you must not expect that we solve all problems for you.
CONFIG_SYS_UBOOT_BASE is an undocumented and largely unused variable. Only very, very few boards define it, and the only plase it ever gets used is in arch/arm/cpu/arm1176/start.S, and then only if CONFIG_ENABLE_MMU is set.
We don't know your hardware, we don't know your code. You will have to figure out yourself if this is something that is imprtant to you.
Please note that the TEXT_BASE value you found looks a bit wrong for recent versions of U-Boot. One of the major changes we have in the past few years was that now U-Boot gets relocated to the end of physical RAM, and not just copied to a compile-time determined fix address as before. I speculate that this setting predates the relocation, so you need to change the related parts.
Best regards,
Wolfgang Denk
participants (4)
-
Marek Vasut -
Michael Kebe -
Paul Gortmaker -
Wolfgang Denk