Scratch that. I forgot I hard coded the vector table with 0x400 to test things. Restoring _start still results in 0x00000000 for the reset vector.
On Fri, Jul 26, 2024 at 1:16 PM Peter LaDow <pla...@gmail.com> wrote: > > I should mention I was using the gcc-m68k-linux-gnu package on Ubuntu > 22.04.4, which pulled in gcc-11-m68k-linux-gnu. > > I just downloaded the bootlin m68k-coldfire--uclibc--stable-2024.02-1, > and tried that. It generates the proper value in the vector table > (0x400 for _start). But the call to memset is still bad: > > 0000f5da <board_init_f_init_reserve>: > f5da: 2f02 movel %d2,%sp@- > f5dc: 242f 0008 movel %sp@(8),%d2 > f5e0: 4878 00c0 pea c0 <_vectors+0xc0> > f5e4: 42a7 clrl %sp@- > f5e6: 2f02 movel %d2,%sp@- > f5e8: 61ff 0001 4622 bsrl 23c0c <_etext+0x138> > f5ee: 2f02 movel %d2,%sp@- > f5f0: 61ff ffff ffd2 bsrl f5c4 <arch_setup_gd> > f5f6: 0682 0000 00c0 addil #192,%d2 > f5fc: 4fef 0010 lea %sp@(16),%sp > f600: 2047 moveal %d7,%a0 > f602: 2142 00a0 movel %d2,%a0@(160) > f606: 241f movel %sp@+,%d2 > f608: 4e75 rts > > Note "bsrl 23c0c" which points beyond _etext. > > On Fri, Jul 26, 2024 at 12:59 PM Fabio Estevam <feste...@gmail.com> wrote: > > > > Adding the Coldfire maintainers on Cc. > > > > On Fri, Jul 26, 2024 at 4:46 PM Peter LaDow <pla...@gmail.com> wrote: > > > > > > After some digging it appears that this is a toolchain issue. It seems > > > the > > > linker fixups are sometimes not computed correctly. For example, in > > > board_init_f_init_reserve, the object file disassembled has: > > > > > > 00000000 <board_init_f_init_reserve>: > > > 0: 2f02 movel %d2,%sp@- > > > 2: 242f 0008 movel %sp@(8),%d2 > > > 6: 4878 00c0 pea c0 <board_init_f_init_reserve+0xc0> > > > a: 42a7 clrl %sp@- > > > c: 2f02 movel %d2,%sp@- > > > e: 61ff 0000 0000 bsrl 10 <board_init_f_init_reserve+0x10> > > > 14: 2f02 movel %d2,%sp@- > > > 16: 61ff 0000 0000 bsrl 18 <board_init_f_init_reserve+0x18> > > > 1c: 0682 0000 00c0 addil #192,%d2 > > > 22: 4fef 0010 lea %sp@(16),%sp > > > 26: 2047 moveal %d7,%a0 > > > 28: 2142 00a0 movel %d2,%a0@(160) > > > 2c: 241f movel %sp@+,%d2 > > > 2e: 4e75 rts > > > > > > But when I disassemble the final linked u-boot output: > > > > > > 0000f646 <board_init_f_init_reserve>: > > > f646: 2f02 movel %d2,%sp@- > > > f648: 242f 0008 movel %sp@(8),%d2 > > > f64c: 4878 00c0 pea c0 <_vectors+0xc0> > > > f650: 42a7 clrl %sp@- > > > f652: 2f02 movel %d2,%sp@- > > > f654: 61ff 0001 44da bsrl 23b30 <_etext+0x138> > > > f65a: 2f02 movel %d2,%sp@- > > > f65c: 61ff ffff ffd2 bsrl f630 <arch_setup_gd> > > > f662: 0682 0000 00c0 addil #192,%d2 > > > f668: 4fef 0010 lea %sp@(16),%sp > > > f66c: 2047 moveal %d7,%a0 > > > f66e: 2142 00a0 movel %d2,%a0@(160) > > > f672: 241f movel %sp@+,%d2 > > > f674: 4e75 rts > > > > > > Note the pea c0 instruction. The object file has > > > board_init_f_init_reserve+0xc0 as the argument, but the final linker has > > > 0xc0, meaning board_init_f_init_reserve is being set to 0 after linking. > > > > > > Also, note the first bsrl instruction, which is not setup correctly > > > either. This is a call to memset. This points to _etext+0x138, which is > > > not a code region Note that 0x239f8 + 0x138 = 0x23b30. But in the final > > > uboot, memset is at 0x1f030. > > > > > > In the call to memset(), objdump shows the relocation: > > > > > > RELOCATION RECORDS FOR [.text.board_init_f_init_reserve]: > > > OFFSET TYPE VALUE > > > 00000010 R_68K_PLT32 memset > > > 00000018 R_68K_PLT32 arch_setup_gd > > > > > > So it seems only when linking outside the same compilation unit that the > > > relocations aren't set correctly. > > > > > > I'm not sure where to look for a solution. Or how to search for an > > > answer. I've done some digging on Google, but nothing points to a clear > > > answer. Anyone seen something similar? > > > > > > To love for the sake of being loved is human, but to love for the sake of > > > loving is angelic. -- Alphonse de Lamartine. > > > > > > > > > On Thu, Jul 25, 2024 at 14:35 Peter LaDow <pla...@gmail.com> wrote: > > > > > > > > I'm trying to add support for a custom Colfire based board. I have > > > > things building, but the final linked vectors in start.S do not point > > > > to _start. In start.S I have: > > > > > > > > _vectors: > > > > .long 0x00000000 /* Flash offset is 0 until we setup CS0 > > > > */ > > > > .long _START > > > > > > > > .long _FAULT, _FAULT, _FAULT, _FAULT, _FAULT, _FAULT, _FAULT, _FAULT > > > > .long _FAULT, _FAULT, _FAULT, _FAULT, _FAULT, _FAULT, _FAULT, _FAULT > > > > .long _FAULT, _FAULT, _FAULT, _FAULT, _FAULT, _FAULT, _FAULT, _FAULT > > > > > > > > Dumping the symbols in the final u-boot yields: > > > > > > > > $ m68k-linux-gnu-nm -n u-boot > > > > 00000000 A __fixup_entries > > > > 00000000 A __got2_entries > > > > 00000000 t _vectors > > > > 00000400 T _start > > > > 0000047e T relocate_code > > > > 000004ae t fixloop > > > > > > > > But then dumping the raw binary: > > > > > > > > u-boot: file format elf32-m68k > > > > > > > > Contents of section .text: > > > > 00000 00000000 00000000 00000516 00000516 ................ > > > > 00010 00000516 00000516 00000516 00000516 ................ > > > > 00020 00000516 00000516 00000516 00000516 ................ > > > > 00030 00000516 00000516 00000516 00000516 ................ > > > > > > > > Note at offset 4 it is 0x00000000, not 0x00000400 as I'd expect. > > > > > > > > The final linker script has: > > > > > > > > OUTPUT_ARCH(m68k) > > > > ENTRY(_start) > > > > SECTIONS > > > > { > > > > .text : > > > > { > > > > arch/m68k/cpu/mcf548x/start.o (.text*) > > > > . = DEFINED(env_offset) ? env_offset : .; env/embedded.o(.text*); > > > > *(.text*) > > > > } > > > > > > > > > > > > It is difficult to search the archives, and so far I haven't found > > > > anything. Any help would be appreciated. > > > > > > > > -- > > > > To love for the sake of being loved is human, but to love for the sake > > > > of loving is angelic. -- Alphonse de Lamartine. > > > > -- > To love for the sake of being loved is human, but to love for the sake > of loving is angelic. -- Alphonse de Lamartine. -- To love for the sake of being loved is human, but to love for the sake of loving is angelic. -- Alphonse de Lamartine.