M68K Vectors
Peter LaDow
pladow at gmail.com
Mon Jul 29 16:27:21 CEST 2024
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.
More information about the U-Boot
mailing list