* M68K Vectors
@ 2024-07-25 21:35 Peter LaDow
2024-07-26 19:46 ` Peter LaDow
0 siblings, 1 reply; 15+ messages in thread
From: Peter LaDow @ 2024-07-25 21:35 UTC (permalink / raw)
To: u-boot
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.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: M68K Vectors
2024-07-25 21:35 M68K Vectors Peter LaDow
@ 2024-07-26 19:46 ` Peter LaDow
2024-07-26 19:59 ` Fabio Estevam
0 siblings, 1 reply; 15+ messages in thread
From: Peter LaDow @ 2024-07-26 19:46 UTC (permalink / raw)
To: u-boot
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.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: M68K Vectors
2024-07-26 19:46 ` Peter LaDow
@ 2024-07-26 19:59 ` Fabio Estevam
2024-07-26 20:16 ` Peter LaDow
0 siblings, 1 reply; 15+ messages in thread
From: Fabio Estevam @ 2024-07-26 19:59 UTC (permalink / raw)
To: Peter LaDow, Angelo Dureghello, Huan Wang; +Cc: u-boot
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.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: M68K Vectors
2024-07-26 19:59 ` Fabio Estevam
@ 2024-07-26 20:16 ` Peter LaDow
2024-07-26 20:22 ` Peter LaDow
0 siblings, 1 reply; 15+ messages in thread
From: Peter LaDow @ 2024-07-26 20:16 UTC (permalink / raw)
To: Fabio Estevam; +Cc: Angelo Dureghello, Huan Wang, u-boot
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.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: M68K Vectors
2024-07-26 20:16 ` Peter LaDow
@ 2024-07-26 20:22 ` Peter LaDow
2024-07-28 21:03 ` Angelo Dureghello
0 siblings, 1 reply; 15+ messages in thread
From: Peter LaDow @ 2024-07-26 20:22 UTC (permalink / raw)
To: Angelo Dureghello, Huan Wang, u-boot
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.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: M68K Vectors
2024-07-26 20:22 ` Peter LaDow
@ 2024-07-28 21:03 ` Angelo Dureghello
2024-07-29 14:27 ` Peter LaDow
2024-07-29 14:58 ` Peter LaDow
0 siblings, 2 replies; 15+ messages in thread
From: Angelo Dureghello @ 2024-07-28 21:03 UTC (permalink / raw)
To: Peter LaDow, Huan Wang, u-boot
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.
>
>
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: M68K Vectors
2024-07-28 21:03 ` Angelo Dureghello
@ 2024-07-29 14:27 ` Peter LaDow
2024-07-30 13:49 ` Angelo Dureghello
2024-07-29 14:58 ` Peter LaDow
1 sibling, 1 reply; 15+ messages in thread
From: Peter LaDow @ 2024-07-29 14:27 UTC (permalink / raw)
To: Angelo Dureghello; +Cc: Huan Wang, u-boot
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.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: M68K Vectors
2024-07-28 21:03 ` Angelo Dureghello
2024-07-29 14:27 ` Peter LaDow
@ 2024-07-29 14:58 ` Peter LaDow
2024-07-29 22:27 ` Peter LaDow
1 sibling, 1 reply; 15+ messages in thread
From: Peter LaDow @ 2024-07-29 14:58 UTC (permalink / raw)
To: Angelo Dureghello; +Cc: Huan Wang, u-boot
I tried both the gcc-12.2 and the gcc-14.1, and both exhibit the same
problem I am seeing. And I tried it with the M5373EVB which is
included w/ u-boot.
From the arch/m68k/cpu/mcf530x/start.S:
_vectors:
.long 0x00000000
#if defined(CONFIG_M5307) && \
(CONFIG_TEXT_BASE == CFG_SYS_INT_FLASH_BASE)
.long _start - CONFIG_TEXT_BASE
#else
.long _START
#endif
.long _FAULT, _FAULT, _FAULT, _FAULT, _FAULT, _FAULT, _FAULT, _FAULT
$ m68k-linux-objdump -s u-boot
u-boot: file format elf32-m68k
Contents of section .text:
00000 00000000 00000000 0000050c 0000050c ................
00010 0000050c 0000050c 0000050c 0000050c ................
Note the reset vector at offset 0x4 is 0x00000000, when it should be
0x00000400. This is true in both cases. But _start (and _START which
is #defined to _start above)
$ m68k-linux-nm -n u-boot
00000000 A __fixup_entries
00000000 A __got2_entries
00000000 t INITSP
00000000 t _vectors
00000004 t INITPC
00000008 t vector02_0F
00000040 t vector10_17
00000060 t vector18_1F
00000080 t vector20_2F
000000c0 t vector30_3F
00000100 t vector64_127
00000200 t vector128_191
00000300 t vector192_255
00000400 T _start
So even here we see the _start relocation not set correctly.
However, I do notice something very different in how board_init.c is
compiled. The M5373EVB compiles with what appear to be some sort of
trampolines.
From the 5373 (compiled with -mcpu=5329):
000114fe <board_init_f_init_reserve>:
114fe: 2f0d movel %a5,%sp@-
11500: 206d 00a0 moveal %a5@(160),%a0
11504: 2f02 movel %d2,%sp@-
11506: 242f 000c movel %sp@(12),%d2
1150a: 4878 00c0 pea c0 <vector30_3F>
1150e: 42a7 clrl %sp@-
11510: 2f02 movel %d2,%sp@-
11512: 4e90 jsr %a0@
Notice at 0x11500 it loads %a0 with an offset from %a5. And in
_start, it loads %a5 with __got_start. So some sort of global
relocation table is used to call memset.
But for my board, compiled with the exact same options except -mcpu=548x, I get:
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>
Which is a relative branch (bsrl).
The compilation command line is identical except for -mcpu. Even the
linker command line is identical except for paths to the object files.
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.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: M68K Vectors
2024-07-29 14:58 ` Peter LaDow
@ 2024-07-29 22:27 ` Peter LaDow
0 siblings, 0 replies; 15+ messages in thread
From: Peter LaDow @ 2024-07-29 22:27 UTC (permalink / raw)
To: Angelo Dureghello; +Cc: Huan Wang, u-boot
A bit more digging.
I compiled common/init/board_init.c with -S to look at the generated
assembly. I note the calls to memset are generated very differently.
For the -mcpu=5329 case:
move.l memset@GOT(%a5),%a0
... (trimmed)
jsr (%a0)
But for the -mcpu=548x case:
bsr.l memset@PLTPC
So the 5329 is using the global offsets table, but the 548x is using
the procedure linkage table. Now, my understanding of the GOT vs PLT
is not the best. But IIRC, the PLT is a small trampoline to the
actual function, whereas the GOT is a list of offsets. And it seems
the generated code for the 5329 is correct. The final assembly loads
A5 with 0x40500, which maps to __got_start.
But the 548x is using the PLT. But from what I remember about the PLT
trampoline code, it needs to be writable in order to write fixups as
the symbols are finalized. Of course, this in flash, so that won't
work. I tried using -fno-plt, but it still emits PLT relocations.
For some reason, the 548x uses only PLT32 relocations.
I also tried the M5272C3, M5235EVB, and amcore (MCF530x based), which
generate GOT160 relocations. But the stmark2 (which uses the MCF5441x
cpu), does generate PLT32 relocations. I do note, however, that
INITPC is populated with the correct offset, so the vectors here are
correct. But I have no way to validate if the PLT link code works, as
I don't know about the system architecture.
On Mon, Jul 29, 2024 at 7:58 AM Peter LaDow <pladow@gmail.com> wrote:
>
> I tried both the gcc-12.2 and the gcc-14.1, and both exhibit the same
> problem I am seeing. And I tried it with the M5373EVB which is
> included w/ u-boot.
>
> From the arch/m68k/cpu/mcf530x/start.S:
>
> _vectors:
> .long 0x00000000
> #if defined(CONFIG_M5307) && \
> (CONFIG_TEXT_BASE == CFG_SYS_INT_FLASH_BASE)
> .long _start - CONFIG_TEXT_BASE
> #else
> .long _START
> #endif
>
> .long _FAULT, _FAULT, _FAULT, _FAULT, _FAULT, _FAULT, _FAULT, _FAULT
>
> $ m68k-linux-objdump -s u-boot
> u-boot: file format elf32-m68k
>
> Contents of section .text:
> 00000 00000000 00000000 0000050c 0000050c ................
> 00010 0000050c 0000050c 0000050c 0000050c ................
>
> Note the reset vector at offset 0x4 is 0x00000000, when it should be
> 0x00000400. This is true in both cases. But _start (and _START which
> is #defined to _start above)
>
> $ m68k-linux-nm -n u-boot
> 00000000 A __fixup_entries
> 00000000 A __got2_entries
> 00000000 t INITSP
> 00000000 t _vectors
> 00000004 t INITPC
> 00000008 t vector02_0F
> 00000040 t vector10_17
> 00000060 t vector18_1F
> 00000080 t vector20_2F
> 000000c0 t vector30_3F
> 00000100 t vector64_127
> 00000200 t vector128_191
> 00000300 t vector192_255
> 00000400 T _start
>
> So even here we see the _start relocation not set correctly.
>
> However, I do notice something very different in how board_init.c is
> compiled. The M5373EVB compiles with what appear to be some sort of
> trampolines.
>
> From the 5373 (compiled with -mcpu=5329):
>
> 000114fe <board_init_f_init_reserve>:
> 114fe: 2f0d movel %a5,%sp@-
> 11500: 206d 00a0 moveal %a5@(160),%a0
> 11504: 2f02 movel %d2,%sp@-
> 11506: 242f 000c movel %sp@(12),%d2
> 1150a: 4878 00c0 pea c0 <vector30_3F>
> 1150e: 42a7 clrl %sp@-
> 11510: 2f02 movel %d2,%sp@-
> 11512: 4e90 jsr %a0@
>
> Notice at 0x11500 it loads %a0 with an offset from %a5. And in
> _start, it loads %a5 with __got_start. So some sort of global
> relocation table is used to call memset.
>
> But for my board, compiled with the exact same options except -mcpu=548x, I get:
>
> 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>
>
> Which is a relative branch (bsrl).
>
> The compilation command line is identical except for -mcpu. Even the
> linker command line is identical except for paths to the object files.
>
> 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.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: M68K Vectors
2024-07-29 14:27 ` Peter LaDow
@ 2024-07-30 13:49 ` Angelo Dureghello
2024-07-30 15:43 ` Peter LaDow
0 siblings, 1 reply; 15+ messages in thread
From: Angelo Dureghello @ 2024-07-30 13:49 UTC (permalink / raw)
To: Peter LaDow; +Cc: Huan Wang, u-boot
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.
>>>
>
>
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: M68K Vectors
2024-07-30 13:49 ` Angelo Dureghello
@ 2024-07-30 15:43 ` Peter LaDow
2024-07-30 19:09 ` Peter LaDow
0 siblings, 1 reply; 15+ messages in thread
From: Peter LaDow @ 2024-07-30 15:43 UTC (permalink / raw)
To: Angelo Dureghello; +Cc: Huan Wang, u-boot
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.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: M68K Vectors
2024-07-30 15:43 ` Peter LaDow
@ 2024-07-30 19:09 ` Peter LaDow
2024-07-31 10:10 ` Angelo Dureghello
0 siblings, 1 reply; 15+ messages in thread
From: Peter LaDow @ 2024-07-30 19:09 UTC (permalink / raw)
To: Angelo Dureghello; +Cc: Huan Wang, u-boot
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.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: M68K Vectors
2024-07-30 19:09 ` Peter LaDow
@ 2024-07-31 10:10 ` Angelo Dureghello
2024-07-31 14:47 ` Peter LaDow
0 siblings, 1 reply; 15+ messages in thread
From: Angelo Dureghello @ 2024-07-31 10:10 UTC (permalink / raw)
To: Peter LaDow; +Cc: Huan Wang, u-boot
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.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: M68K Vectors
2024-07-31 10:10 ` Angelo Dureghello
@ 2024-07-31 14:47 ` Peter LaDow
2024-08-13 16:02 ` Peter LaDow
0 siblings, 1 reply; 15+ messages in thread
From: Peter LaDow @ 2024-07-31 14:47 UTC (permalink / raw)
To: Angelo Dureghello; +Cc: Huan Wang, u-boot
Sure. But this is using GOT160 relocations, not PLT. The issue seems
to be with the PLT relocations. I'm not sure why the work on the
MCF5445x, but not on my MCF548x. The compile the same, but seem to
operate differently.
I'm on binutils trying to learn why.
Thanks,
Pete
On Wed, Jul 31, 2024 at 3:11 AM Angelo Dureghello
<angelo@kernel-space.org> wrote:
>
> 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.
--
To love for the sake of being loved is human, but to love for the sake
of loving is angelic. -- Alphonse de Lamartine.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: M68K Vectors
2024-07-31 14:47 ` Peter LaDow
@ 2024-08-13 16:02 ` Peter LaDow
0 siblings, 0 replies; 15+ messages in thread
From: Peter LaDow @ 2024-08-13 16:02 UTC (permalink / raw)
To: Angelo Dureghello; +Cc: Huan Wang, u-boot
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@-
47e0acbe: 242f 0008 movel %sp@(8),%d2
47e0acc2: 4878 00d0 pea d0 <__fixup_entries+0xd0>
47e0acc6: 42a7 clrl %sp@-
47e0acc8: 2f02 movel %d2,%sp@-
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@-
47e0ac1c: 242f 0008 movel %sp@(8),%d2
47e0ac20: 4878 00d0 pea d0 <__fixup_entries+0xd0>
47e0ac24: 42a7 clrl %sp@-
47e0ac26: 2f02 movel %d2,%sp@-
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.
^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2024-08-13 16:02 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-07-25 21:35 M68K Vectors Peter LaDow
2024-07-26 19:46 ` Peter LaDow
2024-07-26 19:59 ` Fabio Estevam
2024-07-26 20:16 ` Peter LaDow
2024-07-26 20:22 ` Peter LaDow
2024-07-28 21:03 ` Angelo Dureghello
2024-07-29 14:27 ` Peter LaDow
2024-07-30 13:49 ` Angelo Dureghello
2024-07-30 15:43 ` Peter LaDow
2024-07-30 19:09 ` Peter LaDow
2024-07-31 10:10 ` Angelo Dureghello
2024-07-31 14:47 ` Peter LaDow
2024-08-13 16:02 ` Peter LaDow
2024-07-29 14:58 ` Peter LaDow
2024-07-29 22:27 ` Peter LaDow
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox