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 <[email protected]> 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.
