M68K Vectors

Peter LaDow pladow at gmail.com
Fri Jul 26 21:46:02 CEST 2024


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 at -
  2:   242f 0008       movel %sp@(8),%d2
  6:   4878 00c0       pea c0 <board_init_f_init_reserve+0xc0>
  a:   42a7            clrl %sp at -
  c:   2f02            movel %d2,%sp at -
  e:   61ff 0000 0000  bsrl 10 <board_init_f_init_reserve+0x10>
 14:   2f02            movel %d2,%sp at -
 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 at +,%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 at -
   f648:       242f 0008       movel %sp@(8),%d2
   f64c:       4878 00c0       pea c0 <_vectors+0xc0>
   f650:       42a7            clrl %sp at -
   f652:       2f02            movel %d2,%sp at -
   f654:       61ff 0001 44da  bsrl 23b30 <_etext+0x138>
   f65a:       2f02            movel %d2,%sp at -
   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 at +,%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 <pladow at 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.


More information about the U-Boot mailing list