[U-Boot] New Oxford Semiconductor board with assertion fail in linker

[U-Boot] New Oxford Semiconductor board with assertion fail in linker

[Michael Kebe]

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_md86407.exe&id=10636&type=software
[2] http://git.denx.de/u-boot.git/
[3] https://github.com/michaelkebe/u-boot-medion-p89626

[U-Boot] New Oxford Semiconductor board with assertion fail in linker

[Wolfgang Denk]

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

-- 
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
The human mind ordinarily operates at only ten percent of its capaci-
ty - the rest is overhead for the operating system.

[U-Boot] New Oxford Semiconductor board with assertion fail in linker

[Michael Kebe]

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

[U-Boot] New Oxford Semiconductor board with assertion fail in linker

[Wolfgang Denk]

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

-- 
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
In an infinite universe all things are possible, including the possi-
bility that the universe does not exist.
                        - Terry Pratchett, _The Dark Side of the Sun_

[U-Boot] New Oxford Semiconductor board with assertion fail in linker

[Michael Kebe]

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

[U-Boot] New Oxford Semiconductor board with assertion fail in linker

[Wolfgang Denk]

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

-- 
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
For every complex problem, there is a solution that is simple,  neat,
and wrong.                                           -- H. L. Mencken

[U-Boot] New Oxford Semiconductor board with assertion fail in linker

[Michael Kebe]

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

[U-Boot] New Oxford Semiconductor board with assertion fail in linker

[Paul Gortmaker]

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 at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] New Oxford Semiconductor board with assertion fail in linker

[Marek Vasut]

> 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

[U-Boot] New Oxford Semiconductor board with assertion fail in linker

[Paul Gortmaker]

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 at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] New Oxford Semiconductor board with assertion fail in linker

[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

-- 
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
Worlds may change, galaxies disintegrate, but a woman always  remains
a woman.
	-- Kirk, "The Conscience of the King", stardate 2818.9

[U-Boot] New Oxford Semiconductor board with assertion fail in linker

[Michael Kebe]

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?

[U-Boot] New Oxford Semiconductor board with assertion fail in linker

[Wolfgang Denk]

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

-- 
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
It is a good thing for an uneducated man to read books of quotations.
                        - Sir Winston Churchill _My Early Life_ ch. 9

[U-Boot] New Oxford Semiconductor board with assertion fail in linker

[Wolfgang Denk]

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

-- 
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
Wait!  You have not been prepared!
	-- Mr. Atoz, "Tomorrow is Yesterday", stardate 3113.2