Re: M68K Vectors

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

Hi Pete,

ok, so if you are running from flash, amcore is
also running from parallel nor flash, but is no-mmu mcf5397,
jfyi.

Regards,
angelo


On 30/07/24 9:09 PM, Peter LaDow wrote:
> A bit more digging.
>
> When I follow the chain through the PLT call to memset, it does some
> lookups in the .got.plt section.  And even on the MCF5445x, it seems
> to ultimately result in a lookup of 0x00000000.
>
> Here's the chain for the MCF5445x.  I did the manually using
> objdump/nm, but I think the math works out (I did a similar thing for
> my board).
>
> Here's the call in board_init_f_init_reserve:
>
>    47e0ad62:       61ff 0001 4ae0  bsrl 47e1f844 <_etext+0x2d0>
>
> Now, 0x47e1f844 is in .plt.  The code here:
>
>    47e1f844:       203c 0000 c046  movel #49222,%d0
>    47e1f84a:       207b 08fa       moveal %pc@(47e1f846 <.plt+0x2d2>,%d0:l),%a0
>    47e1f84e:       4ed0            jmp %a0@
>
> So, this does a lookup relative to PC:  0x47e1f84a + 2 (CF adds to for
> PC relative) - 6 (0xfa in the extension word) + 49222*1 (D0 register,
> scale of 1).  This PC relative lookup resolves to 0x47e2b88c, so it
> reads from this address, loads into A0, and jumps to that address.
> This address is in .got.plt:
>
>    Contents of section .got.plt:
>     ...
>     47e2b88c 47e1f850 47e1f868 47e1f880 47e1f898  G..PG..hG...G...
>
> So, the code jumps to 0x47e1f850.  The disassembly at 0x47e1f850:
>
>    47e1f850:       2f3c 0000 015c  movel #348,%sp@-
>    47e1f856:       61ff ffff fd1c  bsrl 47e1f574 <.plt>
>
> Which jumps to 0x47e1f574:
>
>    47e1f574 <.plt>:
>    47e1f574:       203c 0000 c29a  movel #49818,%d0
>    47e1f57a:       2ebb 08fa       movel %pc@(47e1f576 <.plt+0x2>,%d0:l),%sp@
>    47e1f57e:       203c 0000 c294  movel #49812,%d0
>    47e1f584:       207b 08fa       moveal %pc@(47e1f580 <.plt+0xc>,%d0:l),%a0
>    47e1f588:       4ed0            jmp %a0@
>
> Ultimately here we see it load more data from .got.plt (at
> 0x47e1f584):  PC relative = 0x47e1f584 + 2 - 6 + 49812 =  0x47e2b814.
> This resolves to 0x47e2b814, which again is in .got.plt:
>
>    Contents of section .got.plt:
>     47e2b80c 47e2b75c 00000000 00000000 47e1f598  G..\........G...
>
> And we see at 0x47e2b814 a value of 0x00000000.  Meaning the code
> jumps to address 0.  Which cannot be correct.
>
> And this is exactly the behavior I'm seeing with my build.  My build
> gets lost on the call to memset(), because the PLT code ultimately
> resolves to call address 0x00000000.
>
> So, the question is how could this fixup be done?  Now, I do see code
> in start.S that does fixups.  But this references the .rela.dyn
> section, neither .plt nor .got.plt.  And I see no other code that does
> any fixup of .got or .got.plt.  And further, .got.plt is largely
> populated with values other than 0.  There's just these two entries.
>
> I think I'm going to reach out on the binutils list to try and get
> some insight into what is occurring here.
>
> Thanks,
> Pete
>
>
> On Tue, Jul 30, 2024 at 8:43 AM Peter LaDow <pladow@gmail.com> wrote:
>> Thank you for the feedback.
>>
>> It looks like the mcf5441x executes from RAM.  At least looking at the
>> configuration for the stmark2, which defines CONFIG_SERIAL_BOOT and
>> CONFIG_SF_SBF.  This appears to copy from an external device using the
>> DSPI into RAM.  After loaded, _start finally executes.  Interestingly,
>> the offset to _start appears to be hard-coded.
>>
>> First, it forces _start to offset 0x400:
>>
>> .text
>> . = 0x400
>> .globl _start
>> _start:
>>
>> Then the call to start is by a fixed offset:
>>
>> /* jump to memory and execute */
>> move.l #(CONFIG_TEXT_BASE + 0x400), %a0
>> jmp (%a0)
>>
>> Where CONFIG_TEXT_BASE is set to 0x47e00000.  The code is odd in this
>> case as it appears to use the vector table for the DSPI boot,
>> squeezing all that functionality into less than 1kbyte of memory.
>>
>> However, once _start runs, the code is pretty much the same as the
>> other Coldfire variants.  It calls board_init_f_init_reserve, which
>> calls memset through the same PLT mechanism.  What isn't clear to me
>> (yet) is why that PLT mechanism works for you, but not for me.  But I
>> suspect it is because I'm trying to execute directly from flash.
>>
>> Thanks,
>> Pete
>>
>> On Tue, Jul 30, 2024 at 6:50 AM Angelo Dureghello
>> <angelo@kernel-space.org> wrote:
>>> Hi Peter,
>>>
>>> unfortunately i don't have any of such 548x boards, so cannot
>>> help that much, but if you can manage to have it working, it will
>>> be great.
>>>
>>> Considering 548x is with mmu, mcf5441x startup code may be helpful,
>>> even if it's isa_C (your is isa_B).
>>>
>>> mcf5441x is tested here, and it is actually doing an elf32 relocation,
>>> as you can see in start.S "fixloop". It is done after the "copy to ram".
>>>
>>> I would proceed with small steps, setting some debug output (or gpio output)
>>> to see where the startup code fails.
>>>
>>> Check also the makefile options in arch/m68k/cpu/Makefile, see the -fPIC.
>>>
>>> I follow the thread.
>>>
>>> Thanks,
>>> regards,
>>> angelo
>>>
>>>
>>> On 29/07/24 4:27 PM, Peter LaDow wrote:
>>>> It's not solved yet.  I forgot I had hard coded some items.
>>>>
>>>> I will give the flavors you suggest a try.
>>>>
>>>> I'm trying to add the MCF548x for a legacy board we have.  It's near
>>>> EOL, but we want to leverage uBoot from some in house work.
>>>>
>>>> Thanks,
>>>> Pete
>>>>
>>>> On Sun, Jul 28, 2024 at 2:04 PM Angelo Dureghello
>>>> <angelo@kernel-space.org> wrote:
>>>>> 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.
>>>>
>>
>>
>> --
>> 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.