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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
participants (3)
-
Angelo Dureghello -
Fabio Estevam -
Peter LaDow