M68K Vectors

[Peter LaDow]

Ok, I worked through the binutils team and identified a few changes to
get things to link correctly.

The 548x cpu target creates PLT relocations (so does the 53015 target,
as used on the stmark2 and amcore configs).  Apparently, these rely
upon the loader to resolve the entries in the PLT table.  Other
targets (such as 5272) do not use PLT.  This is unclear to me, but
sounds like it is GCC related.

So, they suggested the following changes.  They work and I get proper
linking (sort of, see below).  There are two changes:

arch/m68k/Makefile:
-cpuflags-$(CONFIG_MCF5441x)    := -mcpu=54418 -fPIC
+cpuflags-$(CONFIG_MCF5441x)    := -mcpu=54418 -fPIE -fvisibility=hidden

include/asm-generic/sections.h:
-extern void _start(void);
+extern void _start(void) __attribute__((visibility("hidden")));

This works well for my setup with my board booting via the FlexBus
with Flash mapped at address 0x0.  I get the vectors properly mapped
and the calls to functions correctly linked (not through the PLT).

For the stmark2 and amcore, I don't think things are quite right;
either with or without the above tweaks.

The builds for amcore, this uses the 5307 target.  This creates GOT160
relocations, which work.It sets up A5 and uses GOT160 relocations.
However, the _start vector is incorrect.  The build on master for
amcore produces:

u-boot:     file format elf32-m68k

Contents of section .text:
ffc00000 00000000 00000000 ffc0051a ffc0051a  ................

Note that at 0xfc000004, the reset vector, points to 0x00000000.  That
can't be right.  But if I put the hidden visibility attribute on
_start in sections.h, I get:

u-boot:     file format elf32-m68k

Contents of section .text:
ffc00000 00000000 ffc00400 ffc0051a ffc0051a  ................
ffc00010 ffc0051a ffc0051a ffc0051a ffc0051a  ................

Which looks correct; _start is indeed at 0xfc000400:

$ /opt/toolchains/m68k/gcc-14.1.0-nolibc/m68k-linux/bin/m68k-linux-nm -n u
-boot
...
ffc00400 t _start

This solution works for all Coldfire platforms.

But the 548x has the other issue of the PLT table.   But the stmark2
is closer to the 548x in this regard.  If I compile the stmark2 from
master, and look at board_init_f_init_reserve:

47e0acbc <board_init_f_init_reserve>:
47e0acbc:       2f02            movel %d2,%sp at -
47e0acbe:       242f 0008       movel %sp@(8),%d2
47e0acc2:       4878 00d0       pea d0 <__fixup_entries+0xd0>
47e0acc6:       42a7            clrl %sp at -
47e0acc8:       2f02            movel %d2,%sp at -
47e0acca:       61ff 0001 4e4c  bsrl 47e1fb18 <.plt+0x2d0>

Note the branch to .plt + 0x2d0.  This is the PLT table.  But the PLT
table hasn't been fixed up, nor does it contain a call to the loader.
This can't work without the PLT table fixed up.

But if I turn on -fvisibility=hidden:

47e0ac1a <board_init_f_init_reserve>:
47e0ac1a:       2f02            movel %d2,%sp at -
47e0ac1c:       242f 0008       movel %sp@(8),%d2
47e0ac20:       4878 00d0       pea d0 <__fixup_entries+0xd0>
47e0ac24:       42a7            clrl %sp at -
47e0ac26:       2f02            movel %d2,%sp at -
47e0ac28:       61ff 0001 29f6  bsrl 47e1d620 <memset>

Note here the call is directly to memset:

$ /opt/toolchains/m68k/gcc-14.1.0-nolibc/m68k-linux/bin/m68k-linux-nm -n u
-boot
47e1d620 t memset

So, while I'm happy to contribute support for the 548x, I'm not sure
how to reconcile this with the other Coldfire boards.

I can't find the vendor for STMark2 or AMCore.  I'd like to look at
their documentation.  I don't know how these boot or how these
generated binaries could work.

Thanks,
Pete

--
To love for the sake of being loved is human, but to love for the sake
of loving is angelic. -- Alphonse de Lamartine.