M68K Vectors
Angelo Dureghello
angelo at kernel-space.org
Wed Jul 31 12:10:29 CEST 2024
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 at -
> 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 at 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 at 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 at 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 at 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 at -
>>>>>>> f5dc: 242f 0008 movel %sp@(8),%d2
>>>>>>> f5e0: 4878 00c0 pea c0 <_vectors+0xc0>
>>>>>>> f5e4: 42a7 clrl %sp at -
>>>>>>> f5e6: 2f02 movel %d2,%sp at -
>>>>>>> f5e8: 61ff 0001 4622 bsrl 23c0c <_etext+0x138>
>>>>>>> f5ee: 2f02 movel %d2,%sp at -
>>>>>>> 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 at +,%d2
>>>>>>> f608: 4e75 rts
>>>>>>>
>>>>>>> Note "bsrl 23c0c" which points beyond _etext.
>>>>>>>
>>>>>>> On Fri, Jul 26, 2024 at 12:59 PM Fabio Estevam <festevam at gmail.com> wrote:
>>>>>>>> Adding the Coldfire maintainers on Cc.
>>>>>>>>
>>>>>>>> On Fri, Jul 26, 2024 at 4:46 PM Peter LaDow <pladow at 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 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.
>>>>>>> --
>>>>>>> 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.
More information about the U-Boot
mailing list