Re: M68K Vectors

[Angelo Dureghello <angelo@kernel-space.org>]

Hi Peter,

glad to hear you solved.

As a toolchain i use those provided by kernel.org:

/opt/toolchains/m68k/gcc-12.2.0-nolibc/m68k-linux/bin/m68k-linux-

https://cdn.kernel.org/pub/tools/crosstool/

Just out of curiosity, what's the cpu model you used ?


Regards,
Angelo Dureghello


On 26/07/24 10:22 PM, Peter LaDow wrote:
> 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 <pladow@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 <festevam@gmail.com> wrote:
>>> Adding the Coldfire maintainers on Cc.
>>>
>>> On Fri, Jul 26, 2024 at 4:46 PM Peter LaDow <pladow@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 <pladow@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.
>
>