* Kernel Image Format Issue - Coldfire mcf54418 CPU Failing to Boot
@ 2024-05-14 19:11 Jean-Michel Hautbois
2024-05-14 20:16 ` Michael Schmitz
0 siblings, 1 reply; 20+ messages in thread
From: Jean-Michel Hautbois @ 2024-05-14 19:11 UTC (permalink / raw)
To: linux-m68k; +Cc: geert, gerg
Hello,
I have been on this for a long time now, and I think it is time to ask
for some help as the answer might be "easy" :-).
I'm trying to boot an upstream Linux kernel (version 6.1.83 from CIP) on
a custom board which already runs an old one (3.0.12).
I'm encountering an issue where the CPU fails to boot with an
"Unexpected exception" error when u-boot calls bootm.
-> bootm
## Booting kernel from Legacy Image at 41000000 ...
Image Name: Linux-6.1.83-cip18-rt10
Created: 2024-04-17 5:42:32 UTC
Image Type: M68K Linux Kernel Image (uncompressed)
Data Size: 5684872 Bytes = 5.4 MB
Load Address: 40001000
Entry Point: 40001000
Checksum: 6bc7660a
Verifying Checksum ... OK
Loading Kernel Image ... OK
OK
*** Unexpected exception ***
Vector Number: 5 Format: 04 Fault Status: 0
PC: 40001002 SR: 00002700 SP: 4fd5fcdc
D0: 00000000 D1: 00000003 D2: 4fdfa71c D3: 00000000
D4: 00000000 D5: 00000001 D6: 00000000 D7: 00000001
A0: 00000000 A1: 4fd71494 A2: 40001000 A3: 4fdfa690
A4: 4fd91b30 A5: 4fdf3600 A6: 4fd5fd64
*** Please Reset Board! ***
I tried to use different Load and Entry adress but this is not having
any effect.
Sadly, I can't use the (very) old toolchain to build my kernel, and I
can't build the old kernel with the toolchain I generated. It has been
done with buildroot and I can provide some information if this is relevant.
To summarize:
- It has MMU enabled
- The cpu is passed with -mcpu=54418
- The architecture is passed with -march=isac
As the u-boot version I have can't be updated (at least not easily) I
need to provide a uImage, so I call mkimage for this when the vmlinux
file is generated.
I've compared the kernel image format with an older working kernel
image, and it seems the issue is related to the kernel image format.
```
$> hexdump -C uImage-3.0.12 |head
00000000 27 05 19 56 c6 4d 40 59 62 ac 6a be 00 2f a2 00
|'..V.M@Yb.j../..|
00000010 40 02 00 00 40 02 00 00 74 e8 ca f4 05 0c 02 00
|@...@...t.......|
00000020 4c 69 6e 75 78 2d 33 2e 30 2e 31 32 2d 72 74 33
|Linux-3.0.12-rt3|
00000030 33 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|3...............|
00000040 60 08 42 49 56 1a 00 00 00 00 4e f9 40 30 20 00
|`.BIV.....N.@0 .|
00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|................|
*
00001040 4e f9 40 30 20 00 4e 56 00 00 9f fc 00 00 00 04 |N.@0
.NV........|
00001050 48 d7 00 01 20 2f 00 0c 4e 7b 00 03 4c d7 00 01 |H...
/..N{..L...|
00001060 df fc 00 00 00 04 4e 5e 4e 75 00 00 4e 75 4e 75
|......N^Nu..NuNu|
```
```
hexdump -C output/images/uImage |head
00000000 27 05 19 56 ab 1d 06 74 66 1f 61 48 00 56 be 88
|'..V...tf.aH.V..|
00000010 40 00 10 00 40 00 10 00 6b c7 66 0a 05 0c 02 00
|@...@...k.f.....|
00000020 4c 69 6e 75 78 2d 36 2e 31 2e 38 33 2d 63 69 70
|Linux-6.1.83-cip|
00000030 31 38 2d 72 74 31 30 00 00 00 00 00 00 00 00 00
|18-rt10.........|
00000040 7f 45 4c 46 01 02 01 00 00 00 00 00 00 00 00 00
|.ELF............|
00000050 00 02 00 04 00 00 00 01 40 00 20 00 00 00 00 34 |........@.
....4|
00000060 00 56 bb b8 00 00 00 26 00 34 00 20 00 04 00 28 |.V.....&.4.
...(|
00000070 00 12 00 11 00 00 00 01 00 00 00 00 40 00 00 00
|............@...|
00000080 40 00 00 00 00 39 d3 d0 00 39 d3 d0 00 00 00 05
|@....9...9......|
00000090 00 00 20 00 00 00 00 01 00 39 e0 00 40 39 e0 00 |..
......9..@9..|
```
I am a bit surprised by the information at offset 0x40. My kernel is an
ELF file, but the old one is a BIV file I don't even know what it can be
-_- !
I'm happy to provide any additional information or details that might be
helpful in resolving this issue.
Thanks in advance for any help !
JM
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Kernel Image Format Issue - Coldfire mcf54418 CPU Failing to Boot
2024-05-14 19:11 Kernel Image Format Issue - Coldfire mcf54418 CPU Failing to Boot Jean-Michel Hautbois
@ 2024-05-14 20:16 ` Michael Schmitz
2024-05-15 7:56 ` Jean-Michel Hautbois
0 siblings, 1 reply; 20+ messages in thread
From: Michael Schmitz @ 2024-05-14 20:16 UTC (permalink / raw)
To: Jean-Michel Hautbois, linux-m68k; +Cc: geert, gerg
Jean-Michel,
'BIV' is probably a bootinfo tag (Boot Info Version).
Cheers,
Michael
On 15/05/24 07:11, Jean-Michel Hautbois wrote:
> Hello,
>
> I have been on this for a long time now, and I think it is time to ask
> for some help as the answer might be "easy" :-).
>
> I'm trying to boot an upstream Linux kernel (version 6.1.83 from CIP)
> on a custom board which already runs an old one (3.0.12).
>
> I'm encountering an issue where the CPU fails to boot with an
> "Unexpected exception" error when u-boot calls bootm.
>
> -> bootm
> ## Booting kernel from Legacy Image at 41000000 ...
> Image Name: Linux-6.1.83-cip18-rt10
> Created: 2024-04-17 5:42:32 UTC
> Image Type: M68K Linux Kernel Image (uncompressed)
> Data Size: 5684872 Bytes = 5.4 MB
> Load Address: 40001000
> Entry Point: 40001000
> Checksum: 6bc7660a
> Verifying Checksum ... OK
> Loading Kernel Image ... OK
> OK
>
>
> *** Unexpected exception ***
> Vector Number: 5 Format: 04 Fault Status: 0
>
> PC: 40001002 SR: 00002700 SP: 4fd5fcdc
> D0: 00000000 D1: 00000003 D2: 4fdfa71c D3: 00000000
> D4: 00000000 D5: 00000001 D6: 00000000 D7: 00000001
> A0: 00000000 A1: 4fd71494 A2: 40001000 A3: 4fdfa690
> A4: 4fd91b30 A5: 4fdf3600 A6: 4fd5fd64
>
> *** Please Reset Board! ***
>
> I tried to use different Load and Entry adress but this is not having
> any effect.
>
> Sadly, I can't use the (very) old toolchain to build my kernel, and I
> can't build the old kernel with the toolchain I generated. It has been
> done with buildroot and I can provide some information if this is
> relevant.
> To summarize:
> - It has MMU enabled
> - The cpu is passed with -mcpu=54418
> - The architecture is passed with -march=isac
>
> As the u-boot version I have can't be updated (at least not easily) I
> need to provide a uImage, so I call mkimage for this when the vmlinux
> file is generated.
>
> I've compared the kernel image format with an older working kernel
> image, and it seems the issue is related to the kernel image format.
>
> ```
> $> hexdump -C uImage-3.0.12 |head
> 00000000 27 05 19 56 c6 4d 40 59 62 ac 6a be 00 2f a2 00
> |'..V.M@Yb.j../..|
> 00000010 40 02 00 00 40 02 00 00 74 e8 ca f4 05 0c 02 00
> |@...@...t.......|
> 00000020 4c 69 6e 75 78 2d 33 2e 30 2e 31 32 2d 72 74 33
> |Linux-3.0.12-rt3|
> 00000030 33 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> |3...............|
> 00000040 60 08 42 49 56 1a 00 00 00 00 4e f9 40 30 20 00
> |`.BIV.....N.@0 .|
> 00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> |................|
> *
> 00001040 4e f9 40 30 20 00 4e 56 00 00 9f fc 00 00 00 04 |N.@0
> .NV........|
> 00001050 48 d7 00 01 20 2f 00 0c 4e 7b 00 03 4c d7 00 01 |H...
> /..N{..L...|
> 00001060 df fc 00 00 00 04 4e 5e 4e 75 00 00 4e 75 4e 75
> |......N^Nu..NuNu|
> ```
>
> ```
> hexdump -C output/images/uImage |head
> 00000000 27 05 19 56 ab 1d 06 74 66 1f 61 48 00 56 be 88
> |'..V...tf.aH.V..|
> 00000010 40 00 10 00 40 00 10 00 6b c7 66 0a 05 0c 02 00
> |@...@...k.f.....|
> 00000020 4c 69 6e 75 78 2d 36 2e 31 2e 38 33 2d 63 69 70
> |Linux-6.1.83-cip|
> 00000030 31 38 2d 72 74 31 30 00 00 00 00 00 00 00 00 00
> |18-rt10.........|
> 00000040 7f 45 4c 46 01 02 01 00 00 00 00 00 00 00 00 00
> |.ELF............|
> 00000050 00 02 00 04 00 00 00 01 40 00 20 00 00 00 00 34 |........@.
> ....4|
> 00000060 00 56 bb b8 00 00 00 26 00 34 00 20 00 04 00 28
> |.V.....&.4. ...(|
> 00000070 00 12 00 11 00 00 00 01 00 00 00 00 40 00 00 00
> |............@...|
> 00000080 40 00 00 00 00 39 d3 d0 00 39 d3 d0 00 00 00 05
> |@....9...9......|
> 00000090 00 00 20 00 00 00 00 01 00 39 e0 00 40 39 e0 00 |..
> ......9..@9..|
> ```
>
> I am a bit surprised by the information at offset 0x40. My kernel is
> an ELF file, but the old one is a BIV file I don't even know what it
> can be -_- !
>
> I'm happy to provide any additional information or details that might
> be helpful in resolving this issue.
>
> Thanks in advance for any help !
> JM
>
>
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Kernel Image Format Issue - Coldfire mcf54418 CPU Failing to Boot
2024-05-14 20:16 ` Michael Schmitz
@ 2024-05-15 7:56 ` Jean-Michel Hautbois
2024-05-15 10:29 ` Greg Ungerer
2024-06-03 10:54 ` m54418: ELF execution issues Jean-Michel Hautbois
0 siblings, 2 replies; 20+ messages in thread
From: Jean-Michel Hautbois @ 2024-05-15 7:56 UTC (permalink / raw)
To: Michael Schmitz, linux-m68k; +Cc: geert, gerg
Hi Michael,
On 14/05/2024 22:16, Michael Schmitz wrote:
> Jean-Michel,
>
> 'BIV' is probably a bootinfo tag (Boot Info Version).
Thanks, it helped me, as I read the head.S file and finally progressed :-).
When dumping my vmlinux, I can see the entry point is *not* the load
address (it was in the old one):
vmlinux: file format elf32-m68k
Disassembly of section .text:
40001000 <_stext>:
40001000: 4ef9 4000 2000 jmp 40002000 <_start>
...
40002000 <_start>:
40002000: 4e71 nop
40002002: 46fc 2700 movew #9984,%sr
40002006: 203c 0104 0100 movel #17039616,%d0
4000200c: 4e7b 0002 movec %d0,%cacr
40002010: 4e71 nop
Now, when uboot starts the kernel, it is not doing anything (not sure if
it hangs or does not display anything on the console. And EARLY_PRINTK
is not valid for coldfire :-(. Not sure why, so any guidance here would
be appreciate too !
I will now check my platform file but at least I am not trying to
execute an instruction "0" :-).
Thanks,
JM
>
> Cheers,
>
> Michael
>
> On 15/05/24 07:11, Jean-Michel Hautbois wrote:
>> Hello,
>>
>> I have been on this for a long time now, and I think it is time to ask
>> for some help as the answer might be "easy" :-).
>>
>> I'm trying to boot an upstream Linux kernel (version 6.1.83 from CIP)
>> on a custom board which already runs an old one (3.0.12).
>>
>> I'm encountering an issue where the CPU fails to boot with an
>> "Unexpected exception" error when u-boot calls bootm.
>>
>> -> bootm
>> ## Booting kernel from Legacy Image at 41000000 ...
>> Image Name: Linux-6.1.83-cip18-rt10
>> Created: 2024-04-17 5:42:32 UTC
>> Image Type: M68K Linux Kernel Image (uncompressed)
>> Data Size: 5684872 Bytes = 5.4 MB
>> Load Address: 40001000
>> Entry Point: 40001000
>> Checksum: 6bc7660a
>> Verifying Checksum ... OK
>> Loading Kernel Image ... OK
>> OK
>>
>>
>> *** Unexpected exception ***
>> Vector Number: 5 Format: 04 Fault Status: 0
>>
>> PC: 40001002 SR: 00002700 SP: 4fd5fcdc
>> D0: 00000000 D1: 00000003 D2: 4fdfa71c D3: 00000000
>> D4: 00000000 D5: 00000001 D6: 00000000 D7: 00000001
>> A0: 00000000 A1: 4fd71494 A2: 40001000 A3: 4fdfa690
>> A4: 4fd91b30 A5: 4fdf3600 A6: 4fd5fd64
>>
>> *** Please Reset Board! ***
>>
>> I tried to use different Load and Entry adress but this is not having
>> any effect.
>>
>> Sadly, I can't use the (very) old toolchain to build my kernel, and I
>> can't build the old kernel with the toolchain I generated. It has been
>> done with buildroot and I can provide some information if this is
>> relevant.
>> To summarize:
>> - It has MMU enabled
>> - The cpu is passed with -mcpu=54418
>> - The architecture is passed with -march=isac
>>
>> As the u-boot version I have can't be updated (at least not easily) I
>> need to provide a uImage, so I call mkimage for this when the vmlinux
>> file is generated.
>>
>> I've compared the kernel image format with an older working kernel
>> image, and it seems the issue is related to the kernel image format.
>>
>> ```
>> $> hexdump -C uImage-3.0.12 |head
>> 00000000 27 05 19 56 c6 4d 40 59 62 ac 6a be 00 2f a2 00
>> |'..V.M@Yb.j../..|
>> 00000010 40 02 00 00 40 02 00 00 74 e8 ca f4 05 0c 02 00
>> |@...@...t.......|
>> 00000020 4c 69 6e 75 78 2d 33 2e 30 2e 31 32 2d 72 74 33
>> |Linux-3.0.12-rt3|
>> 00000030 33 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>> |3...............|
>> 00000040 60 08 42 49 56 1a 00 00 00 00 4e f9 40 30 20 00
>> |`.BIV.....N.@0 .|
>> 00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>> |................|
>> *
>> 00001040 4e f9 40 30 20 00 4e 56 00 00 9f fc 00 00 00 04 |N.@0
>> .NV........|
>> 00001050 48 d7 00 01 20 2f 00 0c 4e 7b 00 03 4c d7 00 01 |H...
>> /..N{..L...|
>> 00001060 df fc 00 00 00 04 4e 5e 4e 75 00 00 4e 75 4e 75
>> |......N^Nu..NuNu|
>> ```
>>
>> ```
>> hexdump -C output/images/uImage |head
>> 00000000 27 05 19 56 ab 1d 06 74 66 1f 61 48 00 56 be 88
>> |'..V...tf.aH.V..|
>> 00000010 40 00 10 00 40 00 10 00 6b c7 66 0a 05 0c 02 00
>> |@...@...k.f.....|
>> 00000020 4c 69 6e 75 78 2d 36 2e 31 2e 38 33 2d 63 69 70
>> |Linux-6.1.83-cip|
>> 00000030 31 38 2d 72 74 31 30 00 00 00 00 00 00 00 00 00
>> |18-rt10.........|
>> 00000040 7f 45 4c 46 01 02 01 00 00 00 00 00 00 00 00 00
>> |.ELF............|
>> 00000050 00 02 00 04 00 00 00 01 40 00 20 00 00 00 00 34 |........@.
>> ....4|
>> 00000060 00 56 bb b8 00 00 00 26 00 34 00 20 00 04 00 28
>> |.V.....&.4. ...(|
>> 00000070 00 12 00 11 00 00 00 01 00 00 00 00 40 00 00 00
>> |............@...|
>> 00000080 40 00 00 00 00 39 d3 d0 00 39 d3 d0 00 00 00 05
>> |@....9...9......|
>> 00000090 00 00 20 00 00 00 00 01 00 39 e0 00 40 39 e0 00 |..
>> ......9..@9..|
>> ```
>>
>> I am a bit surprised by the information at offset 0x40. My kernel is
>> an ELF file, but the old one is a BIV file I don't even know what it
>> can be -_- !
>>
>> I'm happy to provide any additional information or details that might
>> be helpful in resolving this issue.
>>
>> Thanks in advance for any help !
>> JM
>>
>>
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Kernel Image Format Issue - Coldfire mcf54418 CPU Failing to Boot
2024-05-15 7:56 ` Jean-Michel Hautbois
@ 2024-05-15 10:29 ` Greg Ungerer
2024-05-15 11:10 ` Jean-Michel Hautbois
2024-06-03 10:54 ` m54418: ELF execution issues Jean-Michel Hautbois
1 sibling, 1 reply; 20+ messages in thread
From: Greg Ungerer @ 2024-05-15 10:29 UTC (permalink / raw)
To: Jean-Michel Hautbois, Michael Schmitz, linux-m68k; +Cc: geert
Hi Jean-Michel,
On 15/5/24 17:56, Jean-Michel Hautbois wrote:
> Hi Michael,
>
>
> On 14/05/2024 22:16, Michael Schmitz wrote:
>> Jean-Michel,
>>
>> 'BIV' is probably a bootinfo tag (Boot Info Version).
>
> Thanks, it helped me, as I read the head.S file and finally progressed :-).
>
> When dumping my vmlinux, I can see the entry point is *not* the load
> address (it was in the old one):
> vmlinux: file format elf32-m68k
>
>
> Disassembly of section .text:
>
> 40001000 <_stext>:
> 40001000: 4ef9 4000 2000 jmp 40002000 <_start>
> ...
>
> 40002000 <_start>:
> 40002000: 4e71 nop
> 40002002: 46fc 2700 movew #9984,%sr
> 40002006: 203c 0104 0100 movel #17039616,%d0
> 4000200c: 4e7b 0002 movec %d0,%cacr
> 40002010: 4e71 nop
>
> Now, when uboot starts the kernel, it is not doing anything (not sure if
> it hangs or does not display anything on the console. And EARLY_PRINTK
> is not valid for coldfire :-(. Not sure why, so any guidance here would
> be appreciate too !
>
> I will now check my platform file but at least I am not trying to
> execute an instruction "0" :-).
Can you post your kernel .conig file?
Did you just start with your original 3.0.12 config and use that for 6.1.83?
Regards
Greg
> Thanks,
> JM
>
>>
>> Cheers,
>>
>> Michael
>>
>> On 15/05/24 07:11, Jean-Michel Hautbois wrote:
>>> Hello,
>>>
>>> I have been on this for a long time now, and I think it is time to
>>> ask for some help as the answer might be "easy" :-).
>>>
>>> I'm trying to boot an upstream Linux kernel (version 6.1.83 from CIP)
>>> on a custom board which already runs an old one (3.0.12).
>>>
>>> I'm encountering an issue where the CPU fails to boot with an
>>> "Unexpected exception" error when u-boot calls bootm.
>>>
>>> -> bootm
>>> ## Booting kernel from Legacy Image at 41000000 ...
>>> Image Name: Linux-6.1.83-cip18-rt10
>>> Created: 2024-04-17 5:42:32 UTC
>>> Image Type: M68K Linux Kernel Image (uncompressed)
>>> Data Size: 5684872 Bytes = 5.4 MB
>>> Load Address: 40001000
>>> Entry Point: 40001000
>>> Checksum: 6bc7660a
>>> Verifying Checksum ... OK
>>> Loading Kernel Image ... OK
>>> OK
>>>
>>>
>>> *** Unexpected exception ***
>>> Vector Number: 5 Format: 04 Fault Status: 0
>>>
>>> PC: 40001002 SR: 00002700 SP: 4fd5fcdc
>>> D0: 00000000 D1: 00000003 D2: 4fdfa71c D3: 00000000
>>> D4: 00000000 D5: 00000001 D6: 00000000 D7: 00000001
>>> A0: 00000000 A1: 4fd71494 A2: 40001000 A3: 4fdfa690
>>> A4: 4fd91b30 A5: 4fdf3600 A6: 4fd5fd64
>>>
>>> *** Please Reset Board! ***
>>>
>>> I tried to use different Load and Entry adress but this is not having
>>> any effect.
>>>
>>> Sadly, I can't use the (very) old toolchain to build my kernel, and I
>>> can't build the old kernel with the toolchain I generated. It has
>>> been done with buildroot and I can provide some information if this
>>> is relevant.
>>> To summarize:
>>> - It has MMU enabled
>>> - The cpu is passed with -mcpu=54418
>>> - The architecture is passed with -march=isac
>>>
>>> As the u-boot version I have can't be updated (at least not easily) I
>>> need to provide a uImage, so I call mkimage for this when the vmlinux
>>> file is generated.
>>>
>>> I've compared the kernel image format with an older working kernel
>>> image, and it seems the issue is related to the kernel image format.
>>>
>>> ```
>>> $> hexdump -C uImage-3.0.12 |head
>>> 00000000 27 05 19 56 c6 4d 40 59 62 ac 6a be 00 2f a2 00
>>> |'..V.M@Yb.j../..|
>>> 00000010 40 02 00 00 40 02 00 00 74 e8 ca f4 05 0c 02 00
>>> |@...@...t.......|
>>> 00000020 4c 69 6e 75 78 2d 33 2e 30 2e 31 32 2d 72 74 33
>>> |Linux-3.0.12-rt3|
>>> 00000030 33 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>> |3...............|
>>> 00000040 60 08 42 49 56 1a 00 00 00 00 4e f9 40 30 20 00
>>> |`.BIV.....N.@0 .|
>>> 00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>> |................|
>>> *
>>> 00001040 4e f9 40 30 20 00 4e 56 00 00 9f fc 00 00 00 04 |N.@0
>>> .NV........|
>>> 00001050 48 d7 00 01 20 2f 00 0c 4e 7b 00 03 4c d7 00 01 |H...
>>> /..N{..L...|
>>> 00001060 df fc 00 00 00 04 4e 5e 4e 75 00 00 4e 75 4e 75
>>> |......N^Nu..NuNu|
>>> ```
>>>
>>> ```
>>> hexdump -C output/images/uImage |head
>>> 00000000 27 05 19 56 ab 1d 06 74 66 1f 61 48 00 56 be 88
>>> |'..V...tf.aH.V..|
>>> 00000010 40 00 10 00 40 00 10 00 6b c7 66 0a 05 0c 02 00
>>> |@...@...k.f.....|
>>> 00000020 4c 69 6e 75 78 2d 36 2e 31 2e 38 33 2d 63 69 70
>>> |Linux-6.1.83-cip|
>>> 00000030 31 38 2d 72 74 31 30 00 00 00 00 00 00 00 00 00
>>> |18-rt10.........|
>>> 00000040 7f 45 4c 46 01 02 01 00 00 00 00 00 00 00 00 00
>>> |.ELF............|
>>> 00000050 00 02 00 04 00 00 00 01 40 00 20 00 00 00 00 34
>>> |........@. ....4|
>>> 00000060 00 56 bb b8 00 00 00 26 00 34 00 20 00 04 00 28
>>> |.V.....&.4. ...(|
>>> 00000070 00 12 00 11 00 00 00 01 00 00 00 00 40 00 00 00
>>> |............@...|
>>> 00000080 40 00 00 00 00 39 d3 d0 00 39 d3 d0 00 00 00 05
>>> |@....9...9......|
>>> 00000090 00 00 20 00 00 00 00 01 00 39 e0 00 40 39 e0 00 |..
>>> ......9..@9..|
>>> ```
>>>
>>> I am a bit surprised by the information at offset 0x40. My kernel is
>>> an ELF file, but the old one is a BIV file I don't even know what it
>>> can be -_- !
>>>
>>> I'm happy to provide any additional information or details that might
>>> be helpful in resolving this issue.
>>>
>>> Thanks in advance for any help !
>>> JM
>>>
>>>
>
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Kernel Image Format Issue - Coldfire mcf54418 CPU Failing to Boot
2024-05-15 10:29 ` Greg Ungerer
@ 2024-05-15 11:10 ` Jean-Michel Hautbois
2024-05-16 12:43 ` Greg Ungerer
0 siblings, 1 reply; 20+ messages in thread
From: Jean-Michel Hautbois @ 2024-05-15 11:10 UTC (permalink / raw)
To: Greg Ungerer, Michael Schmitz, linux-m68k; +Cc: geert
Hi Greg,
On 15/05/2024 12:29, Greg Ungerer wrote:
> Hi Jean-Michel,
>
>
> On 15/5/24 17:56, Jean-Michel Hautbois wrote:
>> Hi Michael,
>>
>>
>> On 14/05/2024 22:16, Michael Schmitz wrote:
>>> Jean-Michel,
>>>
>>> 'BIV' is probably a bootinfo tag (Boot Info Version).
>>
>> Thanks, it helped me, as I read the head.S file and finally progressed
>> :-).
>>
>> When dumping my vmlinux, I can see the entry point is *not* the load
>> address (it was in the old one):
>> vmlinux: file format elf32-m68k
>>
>>
>> Disassembly of section .text:
>>
>> 40001000 <_stext>:
>> 40001000: 4ef9 4000 2000 jmp 40002000 <_start>
>> ...
>>
>> 40002000 <_start>:
>> 40002000: 4e71 nop
>> 40002002: 46fc 2700 movew #9984,%sr
>> 40002006: 203c 0104 0100 movel #17039616,%d0
>> 4000200c: 4e7b 0002 movec %d0,%cacr
>> 40002010: 4e71 nop
>>
>> Now, when uboot starts the kernel, it is not doing anything (not sure
>> if it hangs or does not display anything on the console. And
>> EARLY_PRINTK is not valid for coldfire :-(. Not sure why, so any
>> guidance here would be appreciate too !
>>
>> I will now check my platform file but at least I am not trying to
>> execute an instruction "0" :-).
>
> Can you post your kernel .conig file?
> Did you just start with your original 3.0.12 config and use that for
> 6.1.83?
No, I used a very simplified one to start.
CONFIG_NAMESPACES=y
CONFIG_EMBEDDED=y
CONFIG_COLDFIRE=y
CONFIG_M5441x=y
CONFIG_ADVANCED=y
# CONFIG_SINGLE_MEMORY_CHUNK is not set
CONFIG_CLOCK_FREQ=240000000
CONFIG_STMARK2=y
CONFIG_UBOOT=y
CONFIG_RAMBASE=0x40000000
CONFIG_RAMSIZE=0x8000000
CONFIG_VECTORBASE=0x40000000
CONFIG_KERNELBASE=0x40001000
CONFIG_BINFMT_FLAT=y
CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
CONFIG_NETDEVICES=y
CONFIG_SERIAL_MCF=y
CONFIG_SERIAL_MCF_BAUDRATE=115200
CONFIG_SERIAL_MCF_CONSOLE=y
CONFIG_HID_A4TECH=y
CONFIG_HID_BELKIN=y
CONFIG_HID_CHERRY=y
CONFIG_HID_CYPRESS=y
CONFIG_HID_EZKEY=y
CONFIG_HID_ITE=y
CONFIG_HID_KENSINGTON=y
CONFIG_HID_REDRAGON=y
CONFIG_HID_MICROSOFT=y
CONFIG_HID_MONTEREY=y
CONFIG_VMLINUX_MAP=y
CONFIG_DEBUG_MEMORY_INIT=y
CONFIG_BOOTPARAM=y
CONFIG_BOOTPARAM_STRING="console=ttyS1,115200"
My serial console is on UART6, so I suppose I will have to modify the
MCFGPIO_PAR_UART2 register in arch/m68k/coldfire/m5441x.c at the very least.
JM
>
> Regards
> Greg
>
>
>
>> Thanks,
>> JM
>>
>>>
>>> Cheers,
>>>
>>> Michael
>>>
>>> On 15/05/24 07:11, Jean-Michel Hautbois wrote:
>>>> Hello,
>>>>
>>>> I have been on this for a long time now, and I think it is time to
>>>> ask for some help as the answer might be "easy" :-).
>>>>
>>>> I'm trying to boot an upstream Linux kernel (version 6.1.83 from
>>>> CIP) on a custom board which already runs an old one (3.0.12).
>>>>
>>>> I'm encountering an issue where the CPU fails to boot with an
>>>> "Unexpected exception" error when u-boot calls bootm.
>>>>
>>>> -> bootm
>>>> ## Booting kernel from Legacy Image at 41000000 ...
>>>> Image Name: Linux-6.1.83-cip18-rt10
>>>> Created: 2024-04-17 5:42:32 UTC
>>>> Image Type: M68K Linux Kernel Image (uncompressed)
>>>> Data Size: 5684872 Bytes = 5.4 MB
>>>> Load Address: 40001000
>>>> Entry Point: 40001000
>>>> Checksum: 6bc7660a
>>>> Verifying Checksum ... OK
>>>> Loading Kernel Image ... OK
>>>> OK
>>>>
>>>>
>>>> *** Unexpected exception ***
>>>> Vector Number: 5 Format: 04 Fault Status: 0
>>>>
>>>> PC: 40001002 SR: 00002700 SP: 4fd5fcdc
>>>> D0: 00000000 D1: 00000003 D2: 4fdfa71c D3: 00000000
>>>> D4: 00000000 D5: 00000001 D6: 00000000 D7: 00000001
>>>> A0: 00000000 A1: 4fd71494 A2: 40001000 A3: 4fdfa690
>>>> A4: 4fd91b30 A5: 4fdf3600 A6: 4fd5fd64
>>>>
>>>> *** Please Reset Board! ***
>>>>
>>>> I tried to use different Load and Entry adress but this is not
>>>> having any effect.
>>>>
>>>> Sadly, I can't use the (very) old toolchain to build my kernel, and
>>>> I can't build the old kernel with the toolchain I generated. It has
>>>> been done with buildroot and I can provide some information if this
>>>> is relevant.
>>>> To summarize:
>>>> - It has MMU enabled
>>>> - The cpu is passed with -mcpu=54418
>>>> - The architecture is passed with -march=isac
>>>>
>>>> As the u-boot version I have can't be updated (at least not easily)
>>>> I need to provide a uImage, so I call mkimage for this when the
>>>> vmlinux file is generated.
>>>>
>>>> I've compared the kernel image format with an older working kernel
>>>> image, and it seems the issue is related to the kernel image format.
>>>>
>>>> ```
>>>> $> hexdump -C uImage-3.0.12 |head
>>>> 00000000 27 05 19 56 c6 4d 40 59 62 ac 6a be 00 2f a2 00
>>>> |'..V.M@Yb.j../..|
>>>> 00000010 40 02 00 00 40 02 00 00 74 e8 ca f4 05 0c 02 00
>>>> |@...@...t.......|
>>>> 00000020 4c 69 6e 75 78 2d 33 2e 30 2e 31 32 2d 72 74 33
>>>> |Linux-3.0.12-rt3|
>>>> 00000030 33 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>> |3...............|
>>>> 00000040 60 08 42 49 56 1a 00 00 00 00 4e f9 40 30 20 00
>>>> |`.BIV.....N.@0 .|
>>>> 00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>> |................|
>>>> *
>>>> 00001040 4e f9 40 30 20 00 4e 56 00 00 9f fc 00 00 00 04 |N.@0
>>>> .NV........|
>>>> 00001050 48 d7 00 01 20 2f 00 0c 4e 7b 00 03 4c d7 00 01 |H...
>>>> /..N{..L...|
>>>> 00001060 df fc 00 00 00 04 4e 5e 4e 75 00 00 4e 75 4e 75
>>>> |......N^Nu..NuNu|
>>>> ```
>>>>
>>>> ```
>>>> hexdump -C output/images/uImage |head
>>>> 00000000 27 05 19 56 ab 1d 06 74 66 1f 61 48 00 56 be 88
>>>> |'..V...tf.aH.V..|
>>>> 00000010 40 00 10 00 40 00 10 00 6b c7 66 0a 05 0c 02 00
>>>> |@...@...k.f.....|
>>>> 00000020 4c 69 6e 75 78 2d 36 2e 31 2e 38 33 2d 63 69 70
>>>> |Linux-6.1.83-cip|
>>>> 00000030 31 38 2d 72 74 31 30 00 00 00 00 00 00 00 00 00
>>>> |18-rt10.........|
>>>> 00000040 7f 45 4c 46 01 02 01 00 00 00 00 00 00 00 00 00
>>>> |.ELF............|
>>>> 00000050 00 02 00 04 00 00 00 01 40 00 20 00 00 00 00 34
>>>> |........@. ....4|
>>>> 00000060 00 56 bb b8 00 00 00 26 00 34 00 20 00 04 00 28
>>>> |.V.....&.4. ...(|
>>>> 00000070 00 12 00 11 00 00 00 01 00 00 00 00 40 00 00 00
>>>> |............@...|
>>>> 00000080 40 00 00 00 00 39 d3 d0 00 39 d3 d0 00 00 00 05
>>>> |@....9...9......|
>>>> 00000090 00 00 20 00 00 00 00 01 00 39 e0 00 40 39 e0 00 |..
>>>> ......9..@9..|
>>>> ```
>>>>
>>>> I am a bit surprised by the information at offset 0x40. My kernel is
>>>> an ELF file, but the old one is a BIV file I don't even know what it
>>>> can be -_- !
>>>>
>>>> I'm happy to provide any additional information or details that
>>>> might be helpful in resolving this issue.
>>>>
>>>> Thanks in advance for any help !
>>>> JM
>>>>
>>>>
>>
>
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Kernel Image Format Issue - Coldfire mcf54418 CPU Failing to Boot
2024-05-15 11:10 ` Jean-Michel Hautbois
@ 2024-05-16 12:43 ` Greg Ungerer
2024-05-16 13:31 ` Jean-Michel Hautbois
0 siblings, 1 reply; 20+ messages in thread
From: Greg Ungerer @ 2024-05-16 12:43 UTC (permalink / raw)
To: Jean-Michel Hautbois, Michael Schmitz, linux-m68k; +Cc: geert
Hi Jean-Michel,
On 15/5/24 21:10, Jean-Michel Hautbois wrote:
> Hi Greg,
>
> On 15/05/2024 12:29, Greg Ungerer wrote:
>> Hi Jean-Michel,
>>
>>
>> On 15/5/24 17:56, Jean-Michel Hautbois wrote:
>>> Hi Michael,
>>>
>>>
>>> On 14/05/2024 22:16, Michael Schmitz wrote:
>>>> Jean-Michel,
>>>>
>>>> 'BIV' is probably a bootinfo tag (Boot Info Version).
>>>
>>> Thanks, it helped me, as I read the head.S file and finally
>>> progressed :-).
>>>
>>> When dumping my vmlinux, I can see the entry point is *not* the load
>>> address (it was in the old one):
>>> vmlinux: file format elf32-m68k
>>>
>>>
>>> Disassembly of section .text:
>>>
>>> 40001000 <_stext>:
>>> 40001000: 4ef9 4000 2000 jmp 40002000 <_start>
>>> ...
>>>
>>> 40002000 <_start>:
>>> 40002000: 4e71 nop
>>> 40002002: 46fc 2700 movew #9984,%sr
>>> 40002006: 203c 0104 0100 movel #17039616,%d0
>>> 4000200c: 4e7b 0002 movec %d0,%cacr
>>> 40002010: 4e71 nop
>>>
>>> Now, when uboot starts the kernel, it is not doing anything (not sure
>>> if it hangs or does not display anything on the console. And
>>> EARLY_PRINTK is not valid for coldfire :-(. Not sure why, so any
>>> guidance here would be appreciate too !
>>>
>>> I will now check my platform file but at least I am not trying to
>>> execute an instruction "0" :-).
>>
>> Can you post your kernel .conig file?
>> Did you just start with your original 3.0.12 config and use that for
>> 6.1.83?
>
> No, I used a very simplified one to start.
>
> CONFIG_NAMESPACES=y
> CONFIG_EMBEDDED=y
> CONFIG_COLDFIRE=y
> CONFIG_M5441x=y
> CONFIG_ADVANCED=y
> # CONFIG_SINGLE_MEMORY_CHUNK is not set
> CONFIG_CLOCK_FREQ=240000000
> CONFIG_STMARK2=y
> CONFIG_UBOOT=y
> CONFIG_RAMBASE=0x40000000
> CONFIG_RAMSIZE=0x8000000
> CONFIG_VECTORBASE=0x40000000
> CONFIG_KERNELBASE=0x40001000
> CONFIG_BINFMT_FLAT=y
> CONFIG_NET=y
> CONFIG_PACKET=y
> CONFIG_UNIX=y
> CONFIG_INET=y
> CONFIG_DEVTMPFS=y
> CONFIG_DEVTMPFS_MOUNT=y
> CONFIG_NETDEVICES=y
> CONFIG_SERIAL_MCF=y
> CONFIG_SERIAL_MCF_BAUDRATE=115200
> CONFIG_SERIAL_MCF_CONSOLE=y
> CONFIG_HID_A4TECH=y
> CONFIG_HID_BELKIN=y
> CONFIG_HID_CHERRY=y
> CONFIG_HID_CYPRESS=y
> CONFIG_HID_EZKEY=y
> CONFIG_HID_ITE=y
> CONFIG_HID_KENSINGTON=y
> CONFIG_HID_REDRAGON=y
> CONFIG_HID_MICROSOFT=y
> CONFIG_HID_MONTEREY=y
> CONFIG_VMLINUX_MAP=y
> CONFIG_DEBUG_MEMORY_INIT=y
> CONFIG_BOOTPARAM=y
> CONFIG_BOOTPARAM_STRING="console=ttyS1,115200"
>
> My serial console is on UART6, so I suppose I will have to modify the
> MCFGPIO_PAR_UART2 register in arch/m68k/coldfire/m5441x.c at the very
> least.
Was the older 3.0.12 code base a mainline kernel, or is it a modified
vendor version?
Regards
Greg
> JM
>
>>
>> Regards
>> Greg
>>
>>
>>
>>> Thanks,
>>> JM
>>>
>>>>
>>>> Cheers,
>>>>
>>>> Michael
>>>>
>>>> On 15/05/24 07:11, Jean-Michel Hautbois wrote:
>>>>> Hello,
>>>>>
>>>>> I have been on this for a long time now, and I think it is time to
>>>>> ask for some help as the answer might be "easy" :-).
>>>>>
>>>>> I'm trying to boot an upstream Linux kernel (version 6.1.83 from
>>>>> CIP) on a custom board which already runs an old one (3.0.12).
>>>>>
>>>>> I'm encountering an issue where the CPU fails to boot with an
>>>>> "Unexpected exception" error when u-boot calls bootm.
>>>>>
>>>>> -> bootm
>>>>> ## Booting kernel from Legacy Image at 41000000 ...
>>>>> Image Name: Linux-6.1.83-cip18-rt10
>>>>> Created: 2024-04-17 5:42:32 UTC
>>>>> Image Type: M68K Linux Kernel Image (uncompressed)
>>>>> Data Size: 5684872 Bytes = 5.4 MB
>>>>> Load Address: 40001000
>>>>> Entry Point: 40001000
>>>>> Checksum: 6bc7660a
>>>>> Verifying Checksum ... OK
>>>>> Loading Kernel Image ... OK
>>>>> OK
>>>>>
>>>>>
>>>>> *** Unexpected exception ***
>>>>> Vector Number: 5 Format: 04 Fault Status: 0
>>>>>
>>>>> PC: 40001002 SR: 00002700 SP: 4fd5fcdc
>>>>> D0: 00000000 D1: 00000003 D2: 4fdfa71c D3: 00000000
>>>>> D4: 00000000 D5: 00000001 D6: 00000000 D7: 00000001
>>>>> A0: 00000000 A1: 4fd71494 A2: 40001000 A3: 4fdfa690
>>>>> A4: 4fd91b30 A5: 4fdf3600 A6: 4fd5fd64
>>>>>
>>>>> *** Please Reset Board! ***
>>>>>
>>>>> I tried to use different Load and Entry adress but this is not
>>>>> having any effect.
>>>>>
>>>>> Sadly, I can't use the (very) old toolchain to build my kernel, and
>>>>> I can't build the old kernel with the toolchain I generated. It has
>>>>> been done with buildroot and I can provide some information if this
>>>>> is relevant.
>>>>> To summarize:
>>>>> - It has MMU enabled
>>>>> - The cpu is passed with -mcpu=54418
>>>>> - The architecture is passed with -march=isac
>>>>>
>>>>> As the u-boot version I have can't be updated (at least not easily)
>>>>> I need to provide a uImage, so I call mkimage for this when the
>>>>> vmlinux file is generated.
>>>>>
>>>>> I've compared the kernel image format with an older working kernel
>>>>> image, and it seems the issue is related to the kernel image format.
>>>>>
>>>>> ```
>>>>> $> hexdump -C uImage-3.0.12 |head
>>>>> 00000000 27 05 19 56 c6 4d 40 59 62 ac 6a be 00 2f a2 00
>>>>> |'..V.M@Yb.j../..|
>>>>> 00000010 40 02 00 00 40 02 00 00 74 e8 ca f4 05 0c 02 00
>>>>> |@...@...t.......|
>>>>> 00000020 4c 69 6e 75 78 2d 33 2e 30 2e 31 32 2d 72 74 33
>>>>> |Linux-3.0.12-rt3|
>>>>> 00000030 33 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>>> |3...............|
>>>>> 00000040 60 08 42 49 56 1a 00 00 00 00 4e f9 40 30 20 00
>>>>> |`.BIV.....N.@0 .|
>>>>> 00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>>> |................|
>>>>> *
>>>>> 00001040 4e f9 40 30 20 00 4e 56 00 00 9f fc 00 00 00 04 |N.@0
>>>>> .NV........|
>>>>> 00001050 48 d7 00 01 20 2f 00 0c 4e 7b 00 03 4c d7 00 01 |H...
>>>>> /..N{..L...|
>>>>> 00001060 df fc 00 00 00 04 4e 5e 4e 75 00 00 4e 75 4e 75
>>>>> |......N^Nu..NuNu|
>>>>> ```
>>>>>
>>>>> ```
>>>>> hexdump -C output/images/uImage |head
>>>>> 00000000 27 05 19 56 ab 1d 06 74 66 1f 61 48 00 56 be 88
>>>>> |'..V...tf.aH.V..|
>>>>> 00000010 40 00 10 00 40 00 10 00 6b c7 66 0a 05 0c 02 00
>>>>> |@...@...k.f.....|
>>>>> 00000020 4c 69 6e 75 78 2d 36 2e 31 2e 38 33 2d 63 69 70
>>>>> |Linux-6.1.83-cip|
>>>>> 00000030 31 38 2d 72 74 31 30 00 00 00 00 00 00 00 00 00
>>>>> |18-rt10.........|
>>>>> 00000040 7f 45 4c 46 01 02 01 00 00 00 00 00 00 00 00 00
>>>>> |.ELF............|
>>>>> 00000050 00 02 00 04 00 00 00 01 40 00 20 00 00 00 00 34
>>>>> |........@. ....4|
>>>>> 00000060 00 56 bb b8 00 00 00 26 00 34 00 20 00 04 00 28
>>>>> |.V.....&.4. ...(|
>>>>> 00000070 00 12 00 11 00 00 00 01 00 00 00 00 40 00 00 00
>>>>> |............@...|
>>>>> 00000080 40 00 00 00 00 39 d3 d0 00 39 d3 d0 00 00 00 05
>>>>> |@....9...9......|
>>>>> 00000090 00 00 20 00 00 00 00 01 00 39 e0 00 40 39 e0 00 |..
>>>>> ......9..@9..|
>>>>> ```
>>>>>
>>>>> I am a bit surprised by the information at offset 0x40. My kernel
>>>>> is an ELF file, but the old one is a BIV file I don't even know
>>>>> what it can be -_- !
>>>>>
>>>>> I'm happy to provide any additional information or details that
>>>>> might be helpful in resolving this issue.
>>>>>
>>>>> Thanks in advance for any help !
>>>>> JM
>>>>>
>>>>>
>>>
>>
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Kernel Image Format Issue - Coldfire mcf54418 CPU Failing to Boot
2024-05-16 12:43 ` Greg Ungerer
@ 2024-05-16 13:31 ` Jean-Michel Hautbois
2024-05-21 13:46 ` Greg Ungerer
0 siblings, 1 reply; 20+ messages in thread
From: Jean-Michel Hautbois @ 2024-05-16 13:31 UTC (permalink / raw)
To: Greg Ungerer, Michael Schmitz, linux-m68k; +Cc: geert
Hello Greg,
On 16/05/2024 14:43, Greg Ungerer wrote:
> Hi Jean-Michel,
>
> On 15/5/24 21:10, Jean-Michel Hautbois wrote:
>> Hi Greg,
>>
>> On 15/05/2024 12:29, Greg Ungerer wrote:
>>> Hi Jean-Michel,
>>>
>>>
>>> On 15/5/24 17:56, Jean-Michel Hautbois wrote:
>>>> Hi Michael,
>>>>
>>>>
>>>> On 14/05/2024 22:16, Michael Schmitz wrote:
>>>>> Jean-Michel,
>>>>>
>>>>> 'BIV' is probably a bootinfo tag (Boot Info Version).
>>>>
>>>> Thanks, it helped me, as I read the head.S file and finally
>>>> progressed :-).
>>>>
>>>> When dumping my vmlinux, I can see the entry point is *not* the load
>>>> address (it was in the old one):
>>>> vmlinux: file format elf32-m68k
>>>>
>>>>
>>>> Disassembly of section .text:
>>>>
>>>> 40001000 <_stext>:
>>>> 40001000: 4ef9 4000 2000 jmp 40002000 <_start>
>>>> ...
>>>>
>>>> 40002000 <_start>:
>>>> 40002000: 4e71 nop
>>>> 40002002: 46fc 2700 movew #9984,%sr
>>>> 40002006: 203c 0104 0100 movel #17039616,%d0
>>>> 4000200c: 4e7b 0002 movec %d0,%cacr
>>>> 40002010: 4e71 nop
>>>>
>>>> Now, when uboot starts the kernel, it is not doing anything (not
>>>> sure if it hangs or does not display anything on the console. And
>>>> EARLY_PRINTK is not valid for coldfire :-(. Not sure why, so any
>>>> guidance here would be appreciate too !
>>>>
>>>> I will now check my platform file but at least I am not trying to
>>>> execute an instruction "0" :-).
>>>
>>> Can you post your kernel .conig file?
>>> Did you just start with your original 3.0.12 config and use that for
>>> 6.1.83?
>>
>> No, I used a very simplified one to start.
>>
>> CONFIG_NAMESPACES=y
>> CONFIG_EMBEDDED=y
>> CONFIG_COLDFIRE=y
>> CONFIG_M5441x=y
>> CONFIG_ADVANCED=y
>> # CONFIG_SINGLE_MEMORY_CHUNK is not set
>> CONFIG_CLOCK_FREQ=240000000
>> CONFIG_STMARK2=y
>> CONFIG_UBOOT=y
>> CONFIG_RAMBASE=0x40000000
>> CONFIG_RAMSIZE=0x8000000
>> CONFIG_VECTORBASE=0x40000000
>> CONFIG_KERNELBASE=0x40001000
>> CONFIG_BINFMT_FLAT=y
>> CONFIG_NET=y
>> CONFIG_PACKET=y
>> CONFIG_UNIX=y
>> CONFIG_INET=y
>> CONFIG_DEVTMPFS=y
>> CONFIG_DEVTMPFS_MOUNT=y
>> CONFIG_NETDEVICES=y
>> CONFIG_SERIAL_MCF=y
>> CONFIG_SERIAL_MCF_BAUDRATE=115200
>> CONFIG_SERIAL_MCF_CONSOLE=y
>> CONFIG_HID_A4TECH=y
>> CONFIG_HID_BELKIN=y
>> CONFIG_HID_CHERRY=y
>> CONFIG_HID_CYPRESS=y
>> CONFIG_HID_EZKEY=y
>> CONFIG_HID_ITE=y
>> CONFIG_HID_KENSINGTON=y
>> CONFIG_HID_REDRAGON=y
>> CONFIG_HID_MICROSOFT=y
>> CONFIG_HID_MONTEREY=y
>> CONFIG_VMLINUX_MAP=y
>> CONFIG_DEBUG_MEMORY_INIT=y
>> CONFIG_BOOTPARAM=y
>> CONFIG_BOOTPARAM_STRING="console=ttyS1,115200"
>>
>> My serial console is on UART6, so I suppose I will have to modify the
>> MCFGPIO_PAR_UART2 register in arch/m68k/coldfire/m5441x.c at the very
>> least.
>
> Was the older 3.0.12 code base a mainline kernel, or is it a modified
> vendor version?
The kernel came from the Tower system module and it has been adapted to
the custom board. I suppose (but it was a long time ago and not me ;-))
that it was a downstream kernel.
https://www.nxp.com/products/no-longer-manufactured/coldfire-mcf5441x-tower-system-module:TWR-MCF5441X
Right now, when load addr is set to 0x40001000 and entry addr is set to
0x40002000 the 6.1 seems to start but nothing is going on my console.
I added a local patch for my uart to be set, but still nothing yet:
diff --git a/arch/m68k/coldfire/m5441x.c b/arch/m68k/coldfire/m5441x.c
index 1e5259a652d1..1bcabef82851 100644
--- a/arch/m68k/coldfire/m5441x.c
+++ b/arch/m68k/coldfire/m5441x.c
@@ -154,8 +154,8 @@ static struct clk * const enable_clks[] __initconst = {
&__clk_0_23, /* dspi.0 */
&__clk_0_24, /* uart0 */
&__clk_0_25, /* uart1 */
- &__clk_0_26, /* uart2 */
&__clk_0_27, /* uart3 */
+ &__clk_1_26, /* uart 6 */
&__clk_0_33, /* pit.1 */
&__clk_0_37, /* eport */
@@ -171,6 +171,7 @@ static struct clk * const disable_clks[] __initconst = {
&__clk_0_14, /* i2c.1 */
&__clk_0_22, /* i2c.0 */
&__clk_0_23, /* dspi.0 */
+ &__clk_0_26, /* uart2 */
&__clk_0_28, /* tmr.1 */
&__clk_0_29, /* tmr.2 */
&__clk_0_30, /* tmr.2 */
@@ -198,7 +199,6 @@ static struct clk * const disable_clks[] __initconst = {
&__clk_1_7, /* i2c.5 */
&__clk_1_24, /* uart 4 */
&__clk_1_25, /* uart 5 */
- &__clk_1_26, /* uart 6 */
&__clk_1_27, /* uart 7 */
&__clk_1_28, /* uart 8 */
&__clk_1_29, /* uart 9 */
@@ -234,7 +234,9 @@ static void __init m5441x_uarts_init(void)
{
__raw_writeb(0x0f, MCFGPIO_PAR_UART0);
__raw_writeb(0x00, MCFGPIO_PAR_UART1);
- __raw_writeb(0x00, MCFGPIO_PAR_UART2);
+ /* TODO: Make it a dedicated file ! */
+ /* UART6 is our console */
+ __raw_writeb(0xaf, MCFGPIO_PAR_UART2);
}
static void __init m5441x_fec_init(void)
Thanks !
JM
> Regards
> Greg
>
>
>> JM
>>
>>>
>>> Regards
>>> Greg
>>>
>>>
>>>
>>>> Thanks,
>>>> JM
>>>>
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Michael
>>>>>
>>>>> On 15/05/24 07:11, Jean-Michel Hautbois wrote:
>>>>>> Hello,
>>>>>>
>>>>>> I have been on this for a long time now, and I think it is time to
>>>>>> ask for some help as the answer might be "easy" :-).
>>>>>>
>>>>>> I'm trying to boot an upstream Linux kernel (version 6.1.83 from
>>>>>> CIP) on a custom board which already runs an old one (3.0.12).
>>>>>>
>>>>>> I'm encountering an issue where the CPU fails to boot with an
>>>>>> "Unexpected exception" error when u-boot calls bootm.
>>>>>>
>>>>>> -> bootm
>>>>>> ## Booting kernel from Legacy Image at 41000000 ...
>>>>>> Image Name: Linux-6.1.83-cip18-rt10
>>>>>> Created: 2024-04-17 5:42:32 UTC
>>>>>> Image Type: M68K Linux Kernel Image (uncompressed)
>>>>>> Data Size: 5684872 Bytes = 5.4 MB
>>>>>> Load Address: 40001000
>>>>>> Entry Point: 40001000
>>>>>> Checksum: 6bc7660a
>>>>>> Verifying Checksum ... OK
>>>>>> Loading Kernel Image ... OK
>>>>>> OK
>>>>>>
>>>>>>
>>>>>> *** Unexpected exception ***
>>>>>> Vector Number: 5 Format: 04 Fault Status: 0
>>>>>>
>>>>>> PC: 40001002 SR: 00002700 SP: 4fd5fcdc
>>>>>> D0: 00000000 D1: 00000003 D2: 4fdfa71c D3: 00000000
>>>>>> D4: 00000000 D5: 00000001 D6: 00000000 D7: 00000001
>>>>>> A0: 00000000 A1: 4fd71494 A2: 40001000 A3: 4fdfa690
>>>>>> A4: 4fd91b30 A5: 4fdf3600 A6: 4fd5fd64
>>>>>>
>>>>>> *** Please Reset Board! ***
>>>>>>
>>>>>> I tried to use different Load and Entry adress but this is not
>>>>>> having any effect.
>>>>>>
>>>>>> Sadly, I can't use the (very) old toolchain to build my kernel,
>>>>>> and I can't build the old kernel with the toolchain I generated.
>>>>>> It has been done with buildroot and I can provide some information
>>>>>> if this is relevant.
>>>>>> To summarize:
>>>>>> - It has MMU enabled
>>>>>> - The cpu is passed with -mcpu=54418
>>>>>> - The architecture is passed with -march=isac
>>>>>>
>>>>>> As the u-boot version I have can't be updated (at least not
>>>>>> easily) I need to provide a uImage, so I call mkimage for this
>>>>>> when the vmlinux file is generated.
>>>>>>
>>>>>> I've compared the kernel image format with an older working kernel
>>>>>> image, and it seems the issue is related to the kernel image format.
>>>>>>
>>>>>> ```
>>>>>> $> hexdump -C uImage-3.0.12 |head
>>>>>> 00000000 27 05 19 56 c6 4d 40 59 62 ac 6a be 00 2f a2 00
>>>>>> |'..V.M@Yb.j../..|
>>>>>> 00000010 40 02 00 00 40 02 00 00 74 e8 ca f4 05 0c 02 00
>>>>>> |@...@...t.......|
>>>>>> 00000020 4c 69 6e 75 78 2d 33 2e 30 2e 31 32 2d 72 74 33
>>>>>> |Linux-3.0.12-rt3|
>>>>>> 00000030 33 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>>>> |3...............|
>>>>>> 00000040 60 08 42 49 56 1a 00 00 00 00 4e f9 40 30 20 00
>>>>>> |`.BIV.....N.@0 .|
>>>>>> 00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>>>> |................|
>>>>>> *
>>>>>> 00001040 4e f9 40 30 20 00 4e 56 00 00 9f fc 00 00 00 04 |N.@0
>>>>>> .NV........|
>>>>>> 00001050 48 d7 00 01 20 2f 00 0c 4e 7b 00 03 4c d7 00 01 |H...
>>>>>> /..N{..L...|
>>>>>> 00001060 df fc 00 00 00 04 4e 5e 4e 75 00 00 4e 75 4e 75
>>>>>> |......N^Nu..NuNu|
>>>>>> ```
>>>>>>
>>>>>> ```
>>>>>> hexdump -C output/images/uImage |head
>>>>>> 00000000 27 05 19 56 ab 1d 06 74 66 1f 61 48 00 56 be 88
>>>>>> |'..V...tf.aH.V..|
>>>>>> 00000010 40 00 10 00 40 00 10 00 6b c7 66 0a 05 0c 02 00
>>>>>> |@...@...k.f.....|
>>>>>> 00000020 4c 69 6e 75 78 2d 36 2e 31 2e 38 33 2d 63 69 70
>>>>>> |Linux-6.1.83-cip|
>>>>>> 00000030 31 38 2d 72 74 31 30 00 00 00 00 00 00 00 00 00
>>>>>> |18-rt10.........|
>>>>>> 00000040 7f 45 4c 46 01 02 01 00 00 00 00 00 00 00 00 00
>>>>>> |.ELF............|
>>>>>> 00000050 00 02 00 04 00 00 00 01 40 00 20 00 00 00 00 34
>>>>>> |........@. ....4|
>>>>>> 00000060 00 56 bb b8 00 00 00 26 00 34 00 20 00 04 00 28
>>>>>> |.V.....&.4. ...(|
>>>>>> 00000070 00 12 00 11 00 00 00 01 00 00 00 00 40 00 00 00
>>>>>> |............@...|
>>>>>> 00000080 40 00 00 00 00 39 d3 d0 00 39 d3 d0 00 00 00 05
>>>>>> |@....9...9......|
>>>>>> 00000090 00 00 20 00 00 00 00 01 00 39 e0 00 40 39 e0 00 |..
>>>>>> ......9..@9..|
>>>>>> ```
>>>>>>
>>>>>> I am a bit surprised by the information at offset 0x40. My kernel
>>>>>> is an ELF file, but the old one is a BIV file I don't even know
>>>>>> what it can be -_- !
>>>>>>
>>>>>> I'm happy to provide any additional information or details that
>>>>>> might be helpful in resolving this issue.
>>>>>>
>>>>>> Thanks in advance for any help !
>>>>>> JM
>>>>>>
>>>>>>
>>>>
>>>
>
^ permalink raw reply related [flat|nested] 20+ messages in thread
* Re: Kernel Image Format Issue - Coldfire mcf54418 CPU Failing to Boot
2024-05-16 13:31 ` Jean-Michel Hautbois
@ 2024-05-21 13:46 ` Greg Ungerer
2024-05-27 13:19 ` Jean-Michel Hautbois
0 siblings, 1 reply; 20+ messages in thread
From: Greg Ungerer @ 2024-05-21 13:46 UTC (permalink / raw)
To: Jean-Michel Hautbois, Michael Schmitz, linux-m68k; +Cc: geert
Hi Jean-Michel,
On 16/5/24 23:31, Jean-Michel Hautbois wrote:
> On 16/05/2024 14:43, Greg Ungerer wrote:
>> On 15/5/24 21:10, Jean-Michel Hautbois wrote:
>>> On 15/05/2024 12:29, Greg Ungerer wrote:
>>>> On 15/5/24 17:56, Jean-Michel Hautbois wrote:
>>>>> On 14/05/2024 22:16, Michael Schmitz wrote:
>>>>>> 'BIV' is probably a bootinfo tag (Boot Info Version).
>>>>>
>>>>> Thanks, it helped me, as I read the head.S file and finally progressed :-).
>>>>>
>>>>> When dumping my vmlinux, I can see the entry point is *not* the load address (it was in the old one):
>>>>> vmlinux: file format elf32-m68k
>>>>>
>>>>>
>>>>> Disassembly of section .text:
>>>>>
>>>>> 40001000 <_stext>:
>>>>> 40001000: 4ef9 4000 2000 jmp 40002000 <_start>
>>>>> ...
>>>>>
>>>>> 40002000 <_start>:
>>>>> 40002000: 4e71 nop
>>>>> 40002002: 46fc 2700 movew #9984,%sr
>>>>> 40002006: 203c 0104 0100 movel #17039616,%d0
>>>>> 4000200c: 4e7b 0002 movec %d0,%cacr
>>>>> 40002010: 4e71 nop
>>>>>
>>>>> Now, when uboot starts the kernel, it is not doing anything (not sure if it hangs or does not display anything on the console. And EARLY_PRINTK is not valid for coldfire :-(. Not sure why, so any guidance here would be appreciate too !
>>>>>
>>>>> I will now check my platform file but at least I am not trying to execute an instruction "0" :-).
>>>>
>>>> Can you post your kernel .conig file?
>>>> Did you just start with your original 3.0.12 config and use that for 6.1.83?
>>>
>>> No, I used a very simplified one to start.
>>>
>>> CONFIG_NAMESPACES=y
>>> CONFIG_EMBEDDED=y
>>> CONFIG_COLDFIRE=y
>>> CONFIG_M5441x=y
>>> CONFIG_ADVANCED=y
>>> # CONFIG_SINGLE_MEMORY_CHUNK is not set
>>> CONFIG_CLOCK_FREQ=240000000
>>> CONFIG_STMARK2=y
>>> CONFIG_UBOOT=y
>>> CONFIG_RAMBASE=0x40000000
>>> CONFIG_RAMSIZE=0x8000000
>>> CONFIG_VECTORBASE=0x40000000
>>> CONFIG_KERNELBASE=0x40001000
>>> CONFIG_BINFMT_FLAT=y
>>> CONFIG_NET=y
>>> CONFIG_PACKET=y
>>> CONFIG_UNIX=y
>>> CONFIG_INET=y
>>> CONFIG_DEVTMPFS=y
>>> CONFIG_DEVTMPFS_MOUNT=y
>>> CONFIG_NETDEVICES=y
>>> CONFIG_SERIAL_MCF=y
>>> CONFIG_SERIAL_MCF_BAUDRATE=115200
>>> CONFIG_SERIAL_MCF_CONSOLE=y
>>> CONFIG_HID_A4TECH=y
>>> CONFIG_HID_BELKIN=y
>>> CONFIG_HID_CHERRY=y
>>> CONFIG_HID_CYPRESS=y
>>> CONFIG_HID_EZKEY=y
>>> CONFIG_HID_ITE=y
>>> CONFIG_HID_KENSINGTON=y
>>> CONFIG_HID_REDRAGON=y
>>> CONFIG_HID_MICROSOFT=y
>>> CONFIG_HID_MONTEREY=y
>>> CONFIG_VMLINUX_MAP=y
>>> CONFIG_DEBUG_MEMORY_INIT=y
>>> CONFIG_BOOTPARAM=y
>>> CONFIG_BOOTPARAM_STRING="console=ttyS1,115200"
>>>
>>> My serial console is on UART6, so I suppose I will have to modify the MCFGPIO_PAR_UART2 register in arch/m68k/coldfire/m5441x.c at the very least.
>>
>> Was the older 3.0.12 code base a mainline kernel, or is it a modified vendor version?
>
> The kernel came from the Tower system module and it has been adapted to the custom board. I suppose (but it was a long time ago and not me ;-)) that it was a downstream kernel.
>
> https://www.nxp.com/products/no-longer-manufactured/coldfire-mcf5441x-tower-system-module:TWR-MCF5441X
It is probably more likely that it used Freescales own development package
(LTIB, or maybe something newer). It was most likely their own modified kernel
sources, so probably not strictly a mainline kernel.
> Right now, when load addr is set to 0x40001000 and entry addr is set to 0x40002000 the 6.1 seems to start but nothing is going on my console.
>
> I added a local patch for my uart to be set, but still nothing yet:
> diff --git a/arch/m68k/coldfire/m5441x.c b/arch/m68k/coldfire/m5441x.c
> index 1e5259a652d1..1bcabef82851 100644
> --- a/arch/m68k/coldfire/m5441x.c
> +++ b/arch/m68k/coldfire/m5441x.c
> @@ -154,8 +154,8 @@ static struct clk * const enable_clks[] __initconst = {
> &__clk_0_23, /* dspi.0 */
> &__clk_0_24, /* uart0 */
> &__clk_0_25, /* uart1 */
> - &__clk_0_26, /* uart2 */
> &__clk_0_27, /* uart3 */
> + &__clk_1_26, /* uart 6 */
>
> &__clk_0_33, /* pit.1 */
> &__clk_0_37, /* eport */
> @@ -171,6 +171,7 @@ static struct clk * const disable_clks[] __initconst = {
> &__clk_0_14, /* i2c.1 */
> &__clk_0_22, /* i2c.0 */
> &__clk_0_23, /* dspi.0 */
> + &__clk_0_26, /* uart2 */
> &__clk_0_28, /* tmr.1 */
> &__clk_0_29, /* tmr.2 */
> &__clk_0_30, /* tmr.2 */
> @@ -198,7 +199,6 @@ static struct clk * const disable_clks[] __initconst = {
> &__clk_1_7, /* i2c.5 */
> &__clk_1_24, /* uart 4 */
> &__clk_1_25, /* uart 5 */
> - &__clk_1_26, /* uart 6 */
> &__clk_1_27, /* uart 7 */
> &__clk_1_28, /* uart 8 */
> &__clk_1_29, /* uart 9 */
> @@ -234,7 +234,9 @@ static void __init m5441x_uarts_init(void)
> {
> __raw_writeb(0x0f, MCFGPIO_PAR_UART0);
> __raw_writeb(0x00, MCFGPIO_PAR_UART1);
> - __raw_writeb(0x00, MCFGPIO_PAR_UART2);
> + /* TODO: Make it a dedicated file ! */
> + /* UART6 is our console */
> + __raw_writeb(0xaf, MCFGPIO_PAR_UART2);
> }
>
> static void __init m5441x_fec_init(void)
I think you are going to need to get some raw UART trace in there to really
see where it is getting too. It is relatively easy to push characters out
a UART, see the drivers/tty/serial/mcf.c uart driver to see how.
Regards
Greg
>>>>>> On 15/05/24 07:11, Jean-Michel Hautbois wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> I have been on this for a long time now, and I think it is time to ask for some help as the answer might be "easy" :-).
>>>>>>>
>>>>>>> I'm trying to boot an upstream Linux kernel (version 6.1.83 from CIP) on a custom board which already runs an old one (3.0.12).
>>>>>>>
>>>>>>> I'm encountering an issue where the CPU fails to boot with an "Unexpected exception" error when u-boot calls bootm.
>>>>>>>
>>>>>>> -> bootm
>>>>>>> ## Booting kernel from Legacy Image at 41000000 ...
>>>>>>> Image Name: Linux-6.1.83-cip18-rt10
>>>>>>> Created: 2024-04-17 5:42:32 UTC
>>>>>>> Image Type: M68K Linux Kernel Image (uncompressed)
>>>>>>> Data Size: 5684872 Bytes = 5.4 MB
>>>>>>> Load Address: 40001000
>>>>>>> Entry Point: 40001000
>>>>>>> Checksum: 6bc7660a
>>>>>>> Verifying Checksum ... OK
>>>>>>> Loading Kernel Image ... OK
>>>>>>> OK
>>>>>>>
>>>>>>>
>>>>>>> *** Unexpected exception ***
>>>>>>> Vector Number: 5 Format: 04 Fault Status: 0
>>>>>>>
>>>>>>> PC: 40001002 SR: 00002700 SP: 4fd5fcdc
>>>>>>> D0: 00000000 D1: 00000003 D2: 4fdfa71c D3: 00000000
>>>>>>> D4: 00000000 D5: 00000001 D6: 00000000 D7: 00000001
>>>>>>> A0: 00000000 A1: 4fd71494 A2: 40001000 A3: 4fdfa690
>>>>>>> A4: 4fd91b30 A5: 4fdf3600 A6: 4fd5fd64
>>>>>>>
>>>>>>> *** Please Reset Board! ***
>>>>>>>
>>>>>>> I tried to use different Load and Entry adress but this is not having any effect.
>>>>>>>
>>>>>>> Sadly, I can't use the (very) old toolchain to build my kernel, and I can't build the old kernel with the toolchain I generated. It has been done with buildroot and I can provide some information if this is relevant.
>>>>>>> To summarize:
>>>>>>> - It has MMU enabled
>>>>>>> - The cpu is passed with -mcpu=54418
>>>>>>> - The architecture is passed with -march=isac
>>>>>>>
>>>>>>> As the u-boot version I have can't be updated (at least not easily) I need to provide a uImage, so I call mkimage for this when the vmlinux file is generated.
>>>>>>>
>>>>>>> I've compared the kernel image format with an older working kernel image, and it seems the issue is related to the kernel image format.
>>>>>>>
>>>>>>> ```
>>>>>>> $> hexdump -C uImage-3.0.12 |head
>>>>>>> 00000000 27 05 19 56 c6 4d 40 59 62 ac 6a be 00 2f a2 00 |'..V.M@Yb.j../..|
>>>>>>> 00000010 40 02 00 00 40 02 00 00 74 e8 ca f4 05 0c 02 00 |@...@...t.......|
>>>>>>> 00000020 4c 69 6e 75 78 2d 33 2e 30 2e 31 32 2d 72 74 33 |Linux-3.0.12-rt3|
>>>>>>> 00000030 33 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |3...............|
>>>>>>> 00000040 60 08 42 49 56 1a 00 00 00 00 4e f9 40 30 20 00 |`.BIV.....N.@0 .|
>>>>>>> 00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
>>>>>>> *
>>>>>>> 00001040 4e f9 40 30 20 00 4e 56 00 00 9f fc 00 00 00 04 |N.@0 .NV........|
>>>>>>> 00001050 48 d7 00 01 20 2f 00 0c 4e 7b 00 03 4c d7 00 01 |H... /..N{..L...|
>>>>>>> 00001060 df fc 00 00 00 04 4e 5e 4e 75 00 00 4e 75 4e 75 |......N^Nu..NuNu|
>>>>>>> ```
>>>>>>>
>>>>>>> ```
>>>>>>> hexdump -C output/images/uImage |head
>>>>>>> 00000000 27 05 19 56 ab 1d 06 74 66 1f 61 48 00 56 be 88 |'..V...tf.aH.V..|
>>>>>>> 00000010 40 00 10 00 40 00 10 00 6b c7 66 0a 05 0c 02 00 |@...@...k.f.....|
>>>>>>> 00000020 4c 69 6e 75 78 2d 36 2e 31 2e 38 33 2d 63 69 70 |Linux-6.1.83-cip|
>>>>>>> 00000030 31 38 2d 72 74 31 30 00 00 00 00 00 00 00 00 00 |18-rt10.........|
>>>>>>> 00000040 7f 45 4c 46 01 02 01 00 00 00 00 00 00 00 00 00 |.ELF............|
>>>>>>> 00000050 00 02 00 04 00 00 00 01 40 00 20 00 00 00 00 34 |........@. ....4|
>>>>>>> 00000060 00 56 bb b8 00 00 00 26 00 34 00 20 00 04 00 28 |.V.....&.4. ...(|
>>>>>>> 00000070 00 12 00 11 00 00 00 01 00 00 00 00 40 00 00 00 |............@...|
>>>>>>> 00000080 40 00 00 00 00 39 d3 d0 00 39 d3 d0 00 00 00 05 |@....9...9......|
>>>>>>> 00000090 00 00 20 00 00 00 00 01 00 39 e0 00 40 39 e0 00 |.. ......9..@9..|
>>>>>>> ```
>>>>>>>
>>>>>>> I am a bit surprised by the information at offset 0x40. My kernel is an ELF file, but the old one is a BIV file I don't even know what it can be -_- !
>>>>>>>
>>>>>>> I'm happy to provide any additional information or details that might be helpful in resolving this issue.
>>>>>>>
>>>>>>> Thanks in advance for any help !
>>>>>>> JM
>>>>>>>
>>>>>>>
>>>>>
>>>>
>>
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Kernel Image Format Issue - Coldfire mcf54418 CPU Failing to Boot
2024-05-21 13:46 ` Greg Ungerer
@ 2024-05-27 13:19 ` Jean-Michel Hautbois
2024-05-28 6:32 ` Jean-Michel Hautbois
0 siblings, 1 reply; 20+ messages in thread
From: Jean-Michel Hautbois @ 2024-05-27 13:19 UTC (permalink / raw)
To: Greg Ungerer, Michael Schmitz, linux-m68k; +Cc: geert
Hello Greg,
On 21/05/2024 15:46, Greg Ungerer wrote:
> Hi Jean-Michel,
>
> On 16/5/24 23:31, Jean-Michel Hautbois wrote:
>> On 16/05/2024 14:43, Greg Ungerer wrote:
>>> On 15/5/24 21:10, Jean-Michel Hautbois wrote:
>>>> On 15/05/2024 12:29, Greg Ungerer wrote:
>>>>> On 15/5/24 17:56, Jean-Michel Hautbois wrote:
>>>>>> On 14/05/2024 22:16, Michael Schmitz wrote:
>>>>>>> 'BIV' is probably a bootinfo tag (Boot Info Version).
>>>>>>
>>>>>> Thanks, it helped me, as I read the head.S file and finally
>>>>>> progressed :-).
>>>>>>
>>>>>> When dumping my vmlinux, I can see the entry point is *not* the
>>>>>> load address (it was in the old one):
>>>>>> vmlinux: file format elf32-m68k
>>>>>>
>>>>>>
>>>>>> Disassembly of section .text:
>>>>>>
>>>>>> 40001000 <_stext>:
>>>>>> 40001000: 4ef9 4000 2000 jmp 40002000 <_start>
>>>>>> ...
>>>>>>
>>>>>> 40002000 <_start>:
>>>>>> 40002000: 4e71 nop
>>>>>> 40002002: 46fc 2700 movew #9984,%sr
>>>>>> 40002006: 203c 0104 0100 movel #17039616,%d0
>>>>>> 4000200c: 4e7b 0002 movec %d0,%cacr
>>>>>> 40002010: 4e71 nop
>>>>>>
>>>>>> Now, when uboot starts the kernel, it is not doing anything (not
>>>>>> sure if it hangs or does not display anything on the console. And
>>>>>> EARLY_PRINTK is not valid for coldfire :-(. Not sure why, so any
>>>>>> guidance here would be appreciate too !
>>>>>>
>>>>>> I will now check my platform file but at least I am not trying to
>>>>>> execute an instruction "0" :-).
>>>>>
>>>>> Can you post your kernel .conig file?
>>>>> Did you just start with your original 3.0.12 config and use that
>>>>> for 6.1.83?
>>>>
>>>> No, I used a very simplified one to start.
>>>>
>>>> CONFIG_NAMESPACES=y
>>>> CONFIG_EMBEDDED=y
>>>> CONFIG_COLDFIRE=y
>>>> CONFIG_M5441x=y
>>>> CONFIG_ADVANCED=y
>>>> # CONFIG_SINGLE_MEMORY_CHUNK is not set
>>>> CONFIG_CLOCK_FREQ=240000000
>>>> CONFIG_STMARK2=y
>>>> CONFIG_UBOOT=y
>>>> CONFIG_RAMBASE=0x40000000
>>>> CONFIG_RAMSIZE=0x8000000
>>>> CONFIG_VECTORBASE=0x40000000
>>>> CONFIG_KERNELBASE=0x40001000
>>>> CONFIG_BINFMT_FLAT=y
>>>> CONFIG_NET=y
>>>> CONFIG_PACKET=y
>>>> CONFIG_UNIX=y
>>>> CONFIG_INET=y
>>>> CONFIG_DEVTMPFS=y
>>>> CONFIG_DEVTMPFS_MOUNT=y
>>>> CONFIG_NETDEVICES=y
>>>> CONFIG_SERIAL_MCF=y
>>>> CONFIG_SERIAL_MCF_BAUDRATE=115200
>>>> CONFIG_SERIAL_MCF_CONSOLE=y
>>>> CONFIG_HID_A4TECH=y
>>>> CONFIG_HID_BELKIN=y
>>>> CONFIG_HID_CHERRY=y
>>>> CONFIG_HID_CYPRESS=y
>>>> CONFIG_HID_EZKEY=y
>>>> CONFIG_HID_ITE=y
>>>> CONFIG_HID_KENSINGTON=y
>>>> CONFIG_HID_REDRAGON=y
>>>> CONFIG_HID_MICROSOFT=y
>>>> CONFIG_HID_MONTEREY=y
>>>> CONFIG_VMLINUX_MAP=y
>>>> CONFIG_DEBUG_MEMORY_INIT=y
>>>> CONFIG_BOOTPARAM=y
>>>> CONFIG_BOOTPARAM_STRING="console=ttyS1,115200"
>>>>
>>>> My serial console is on UART6, so I suppose I will have to modify
>>>> the MCFGPIO_PAR_UART2 register in arch/m68k/coldfire/m5441x.c at the
>>>> very least.
>>>
>>> Was the older 3.0.12 code base a mainline kernel, or is it a modified
>>> vendor version?
>>
>> The kernel came from the Tower system module and it has been adapted
>> to the custom board. I suppose (but it was a long time ago and not me
>> ;-)) that it was a downstream kernel.
>>
>> https://www.nxp.com/products/no-longer-manufactured/coldfire-mcf5441x-tower-system-module:TWR-MCF5441X
>
>
> It is probably more likely that it used Freescales own development package
> (LTIB, or maybe something newer). It was most likely their own modified
> kernel
> sources, so probably not strictly a mainline kernel.
>
>
>> Right now, when load addr is set to 0x40001000 and entry addr is set
>> to 0x40002000 the 6.1 seems to start but nothing is going on my console.
>>
>> I added a local patch for my uart to be set, but still nothing yet:
>> diff --git a/arch/m68k/coldfire/m5441x.c b/arch/m68k/coldfire/m5441x.c
>> index 1e5259a652d1..1bcabef82851 100644
>> --- a/arch/m68k/coldfire/m5441x.c
>> +++ b/arch/m68k/coldfire/m5441x.c
>> @@ -154,8 +154,8 @@ static struct clk * const enable_clks[]
>> __initconst = {
>> &__clk_0_23, /* dspi.0 */
>> &__clk_0_24, /* uart0 */
>> &__clk_0_25, /* uart1 */
>> - &__clk_0_26, /* uart2 */
>> &__clk_0_27, /* uart3 */
>> + &__clk_1_26, /* uart 6 */
>>
>> &__clk_0_33, /* pit.1 */
>> &__clk_0_37, /* eport */
>> @@ -171,6 +171,7 @@ static struct clk * const disable_clks[]
>> __initconst = {
>> &__clk_0_14, /* i2c.1 */
>> &__clk_0_22, /* i2c.0 */
>> &__clk_0_23, /* dspi.0 */
>> + &__clk_0_26, /* uart2 */
>> &__clk_0_28, /* tmr.1 */
>> &__clk_0_29, /* tmr.2 */
>> &__clk_0_30, /* tmr.2 */
>> @@ -198,7 +199,6 @@ static struct clk * const disable_clks[]
>> __initconst = {
>> &__clk_1_7, /* i2c.5 */
>> &__clk_1_24, /* uart 4 */
>> &__clk_1_25, /* uart 5 */
>> - &__clk_1_26, /* uart 6 */
>> &__clk_1_27, /* uart 7 */
>> &__clk_1_28, /* uart 8 */
>> &__clk_1_29, /* uart 9 */
>> @@ -234,7 +234,9 @@ static void __init m5441x_uarts_init(void)
>> {
>> __raw_writeb(0x0f, MCFGPIO_PAR_UART0);
>> __raw_writeb(0x00, MCFGPIO_PAR_UART1);
>> - __raw_writeb(0x00, MCFGPIO_PAR_UART2);
>> + /* TODO: Make it a dedicated file ! */
>> + /* UART6 is our console */
>> + __raw_writeb(0xaf, MCFGPIO_PAR_UART2);
>> }
>>
>> static void __init m5441x_fec_init(void)
>
> I think you are going to need to get some raw UART trace in there to really
> see where it is getting too. It is relatively easy to push characters out
> a UART, see the drivers/tty/serial/mcf.c uart driver to see how.
>
Thanks for this suggestion, it really helped me !
Even if it is a very bad way to do it :-).
So, I basically did:
+static void __init uart6_putc(const char c)
+{
+ /* MCFUART_BASE6 is the base address */
+ int i;
+ unsigned char __iomem *membase = (unsigned char __iomem
*)MCFUART_BASE6;
+
+ for (i = 0; (i < 0x10000); i++) {
+ if (readb(membase + MCFUART_USR) & MCFUART_USR_TXREADY)
+ break;
+ }
+ writeb(c, membase + MCFUART_UTB);
+ for (i = 0; (i < 0x10000); i++) {
+ if (readb(membase + MCFUART_USR) & MCFUART_USR_TXREADY)
+ break;
+ }
+}
+
+static void __init uart6_console_write(struct console *co, const char
*s, unsigned int count)
+{
+ for (; (count); count--, s++) {
+ uart6_putc(*s);
+ if (*s == '\n')
+ uart6_putc('\r');
+ }
+}
+
+static struct console uart6_console = {
+ .name = "uart6",
+ .write = uart6_console_write,
+ .flags = CON_PRINTBUFFER,
+ .index = -1,
+};
In the arch/m68k/coldfire/m5441x.c file and called
register_console(&uart6_console); in the config_BSP() function.
I can now see the messages ! And I can also say that when CONFIG_UBOOT
is activated, it does not even enter in the config_BSP() function !
When I unset it, I go really far, but I can see that the command line is
empty in the pr_notice call of start_kernel. This means that
saved_command_line is empty, but as I won't get it from uboot, it might
be expected :-).
I now need to get why the _init_sp does not have the proper value :-(.
JM
> Regards
> Greg
>
>
>
>>>>>>> On 15/05/24 07:11, Jean-Michel Hautbois wrote:
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> I have been on this for a long time now, and I think it is time
>>>>>>>> to ask for some help as the answer might be "easy" :-).
>>>>>>>>
>>>>>>>> I'm trying to boot an upstream Linux kernel (version 6.1.83 from
>>>>>>>> CIP) on a custom board which already runs an old one (3.0.12).
>>>>>>>>
>>>>>>>> I'm encountering an issue where the CPU fails to boot with an
>>>>>>>> "Unexpected exception" error when u-boot calls bootm.
>>>>>>>>
>>>>>>>> -> bootm
>>>>>>>> ## Booting kernel from Legacy Image at 41000000 ...
>>>>>>>> Image Name: Linux-6.1.83-cip18-rt10
>>>>>>>> Created: 2024-04-17 5:42:32 UTC
>>>>>>>> Image Type: M68K Linux Kernel Image (uncompressed)
>>>>>>>> Data Size: 5684872 Bytes = 5.4 MB
>>>>>>>> Load Address: 40001000
>>>>>>>> Entry Point: 40001000
>>>>>>>> Checksum: 6bc7660a
>>>>>>>> Verifying Checksum ... OK
>>>>>>>> Loading Kernel Image ... OK
>>>>>>>> OK
>>>>>>>>
>>>>>>>>
>>>>>>>> *** Unexpected exception ***
>>>>>>>> Vector Number: 5 Format: 04 Fault Status: 0
>>>>>>>>
>>>>>>>> PC: 40001002 SR: 00002700 SP: 4fd5fcdc
>>>>>>>> D0: 00000000 D1: 00000003 D2: 4fdfa71c D3: 00000000
>>>>>>>> D4: 00000000 D5: 00000001 D6: 00000000 D7: 00000001
>>>>>>>> A0: 00000000 A1: 4fd71494 A2: 40001000 A3: 4fdfa690
>>>>>>>> A4: 4fd91b30 A5: 4fdf3600 A6: 4fd5fd64
>>>>>>>>
>>>>>>>> *** Please Reset Board! ***
>>>>>>>>
>>>>>>>> I tried to use different Load and Entry adress but this is not
>>>>>>>> having any effect.
>>>>>>>>
>>>>>>>> Sadly, I can't use the (very) old toolchain to build my kernel,
>>>>>>>> and I can't build the old kernel with the toolchain I generated.
>>>>>>>> It has been done with buildroot and I can provide some
>>>>>>>> information if this is relevant.
>>>>>>>> To summarize:
>>>>>>>> - It has MMU enabled
>>>>>>>> - The cpu is passed with -mcpu=54418
>>>>>>>> - The architecture is passed with -march=isac
>>>>>>>>
>>>>>>>> As the u-boot version I have can't be updated (at least not
>>>>>>>> easily) I need to provide a uImage, so I call mkimage for this
>>>>>>>> when the vmlinux file is generated.
>>>>>>>>
>>>>>>>> I've compared the kernel image format with an older working
>>>>>>>> kernel image, and it seems the issue is related to the kernel
>>>>>>>> image format.
>>>>>>>>
>>>>>>>> ```
>>>>>>>> $> hexdump -C uImage-3.0.12 |head
>>>>>>>> 00000000 27 05 19 56 c6 4d 40 59 62 ac 6a be 00 2f a2 00
>>>>>>>> |'..V.M@Yb.j../..|
>>>>>>>> 00000010 40 02 00 00 40 02 00 00 74 e8 ca f4 05 0c 02 00
>>>>>>>> |@...@...t.......|
>>>>>>>> 00000020 4c 69 6e 75 78 2d 33 2e 30 2e 31 32 2d 72 74 33
>>>>>>>> |Linux-3.0.12-rt3|
>>>>>>>> 00000030 33 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>>>>>> |3...............|
>>>>>>>> 00000040 60 08 42 49 56 1a 00 00 00 00 4e f9 40 30 20 00
>>>>>>>> |`.BIV.....N.@0 .|
>>>>>>>> 00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>>>>>> |................|
>>>>>>>> *
>>>>>>>> 00001040 4e f9 40 30 20 00 4e 56 00 00 9f fc 00 00 00 04
>>>>>>>> |N.@0 .NV........|
>>>>>>>> 00001050 48 d7 00 01 20 2f 00 0c 4e 7b 00 03 4c d7 00 01
>>>>>>>> |H... /..N{..L...|
>>>>>>>> 00001060 df fc 00 00 00 04 4e 5e 4e 75 00 00 4e 75 4e 75
>>>>>>>> |......N^Nu..NuNu|
>>>>>>>> ```
>>>>>>>>
>>>>>>>> ```
>>>>>>>> hexdump -C output/images/uImage |head
>>>>>>>> 00000000 27 05 19 56 ab 1d 06 74 66 1f 61 48 00 56 be 88
>>>>>>>> |'..V...tf.aH.V..|
>>>>>>>> 00000010 40 00 10 00 40 00 10 00 6b c7 66 0a 05 0c 02 00
>>>>>>>> |@...@...k.f.....|
>>>>>>>> 00000020 4c 69 6e 75 78 2d 36 2e 31 2e 38 33 2d 63 69 70
>>>>>>>> |Linux-6.1.83-cip|
>>>>>>>> 00000030 31 38 2d 72 74 31 30 00 00 00 00 00 00 00 00 00
>>>>>>>> |18-rt10.........|
>>>>>>>> 00000040 7f 45 4c 46 01 02 01 00 00 00 00 00 00 00 00 00
>>>>>>>> |.ELF............|
>>>>>>>> 00000050 00 02 00 04 00 00 00 01 40 00 20 00 00 00 00 34
>>>>>>>> |........@. ....4|
>>>>>>>> 00000060 00 56 bb b8 00 00 00 26 00 34 00 20 00 04 00 28
>>>>>>>> |.V.....&.4. ...(|
>>>>>>>> 00000070 00 12 00 11 00 00 00 01 00 00 00 00 40 00 00 00
>>>>>>>> |............@...|
>>>>>>>> 00000080 40 00 00 00 00 39 d3 d0 00 39 d3 d0 00 00 00 05
>>>>>>>> |@....9...9......|
>>>>>>>> 00000090 00 00 20 00 00 00 00 01 00 39 e0 00 40 39 e0 00 |..
>>>>>>>> ......9..@9..|
>>>>>>>> ```
>>>>>>>>
>>>>>>>> I am a bit surprised by the information at offset 0x40. My
>>>>>>>> kernel is an ELF file, but the old one is a BIV file I don't
>>>>>>>> even know what it can be -_- !
>>>>>>>>
>>>>>>>> I'm happy to provide any additional information or details that
>>>>>>>> might be helpful in resolving this issue.
>>>>>>>>
>>>>>>>> Thanks in advance for any help !
>>>>>>>> JM
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Kernel Image Format Issue - Coldfire mcf54418 CPU Failing to Boot
2024-05-27 13:19 ` Jean-Michel Hautbois
@ 2024-05-28 6:32 ` Jean-Michel Hautbois
2024-05-28 7:47 ` John Paul Adrian Glaubitz
2024-05-28 13:59 ` Greg Ungerer
0 siblings, 2 replies; 20+ messages in thread
From: Jean-Michel Hautbois @ 2024-05-28 6:32 UTC (permalink / raw)
To: Greg Ungerer, Michael Schmitz, linux-m68k; +Cc: geert
Hi Greg, all,
On 27/05/2024 15:19, Jean-Michel Hautbois wrote:
> Hello Greg,
>
> On 21/05/2024 15:46, Greg Ungerer wrote:
>> Hi Jean-Michel,
>>
>> On 16/5/24 23:31, Jean-Michel Hautbois wrote:
>>> On 16/05/2024 14:43, Greg Ungerer wrote:
>>>> On 15/5/24 21:10, Jean-Michel Hautbois wrote:
>>>>> On 15/05/2024 12:29, Greg Ungerer wrote:
>>>>>> On 15/5/24 17:56, Jean-Michel Hautbois wrote:
>>>>>>> On 14/05/2024 22:16, Michael Schmitz wrote:
>>>>>>>> 'BIV' is probably a bootinfo tag (Boot Info Version).
>>>>>>>
>>>>>>> Thanks, it helped me, as I read the head.S file and finally
>>>>>>> progressed :-).
>>>>>>>
>>>>>>> When dumping my vmlinux, I can see the entry point is *not* the
>>>>>>> load address (it was in the old one):
>>>>>>> vmlinux: file format elf32-m68k
>>>>>>>
>>>>>>>
>>>>>>> Disassembly of section .text:
>>>>>>>
>>>>>>> 40001000 <_stext>:
>>>>>>> 40001000: 4ef9 4000 2000 jmp 40002000 <_start>
>>>>>>> ...
>>>>>>>
>>>>>>> 40002000 <_start>:
>>>>>>> 40002000: 4e71 nop
>>>>>>> 40002002: 46fc 2700 movew #9984,%sr
>>>>>>> 40002006: 203c 0104 0100 movel #17039616,%d0
>>>>>>> 4000200c: 4e7b 0002 movec %d0,%cacr
>>>>>>> 40002010: 4e71 nop
>>>>>>>
>>>>>>> Now, when uboot starts the kernel, it is not doing anything (not
>>>>>>> sure if it hangs or does not display anything on the console. And
>>>>>>> EARLY_PRINTK is not valid for coldfire :-(. Not sure why, so any
>>>>>>> guidance here would be appreciate too !
>>>>>>>
>>>>>>> I will now check my platform file but at least I am not trying to
>>>>>>> execute an instruction "0" :-).
>>>>>>
>>>>>> Can you post your kernel .conig file?
>>>>>> Did you just start with your original 3.0.12 config and use that
>>>>>> for 6.1.83?
>>>>>
>>>>> No, I used a very simplified one to start.
>>>>>
>>>>> CONFIG_NAMESPACES=y
>>>>> CONFIG_EMBEDDED=y
>>>>> CONFIG_COLDFIRE=y
>>>>> CONFIG_M5441x=y
>>>>> CONFIG_ADVANCED=y
>>>>> # CONFIG_SINGLE_MEMORY_CHUNK is not set
>>>>> CONFIG_CLOCK_FREQ=240000000
>>>>> CONFIG_STMARK2=y
>>>>> CONFIG_UBOOT=y
>>>>> CONFIG_RAMBASE=0x40000000
>>>>> CONFIG_RAMSIZE=0x8000000
>>>>> CONFIG_VECTORBASE=0x40000000
>>>>> CONFIG_KERNELBASE=0x40001000
>>>>> CONFIG_BINFMT_FLAT=y
>>>>> CONFIG_NET=y
>>>>> CONFIG_PACKET=y
>>>>> CONFIG_UNIX=y
>>>>> CONFIG_INET=y
>>>>> CONFIG_DEVTMPFS=y
>>>>> CONFIG_DEVTMPFS_MOUNT=y
>>>>> CONFIG_NETDEVICES=y
>>>>> CONFIG_SERIAL_MCF=y
>>>>> CONFIG_SERIAL_MCF_BAUDRATE=115200
>>>>> CONFIG_SERIAL_MCF_CONSOLE=y
>>>>> CONFIG_HID_A4TECH=y
>>>>> CONFIG_HID_BELKIN=y
>>>>> CONFIG_HID_CHERRY=y
>>>>> CONFIG_HID_CYPRESS=y
>>>>> CONFIG_HID_EZKEY=y
>>>>> CONFIG_HID_ITE=y
>>>>> CONFIG_HID_KENSINGTON=y
>>>>> CONFIG_HID_REDRAGON=y
>>>>> CONFIG_HID_MICROSOFT=y
>>>>> CONFIG_HID_MONTEREY=y
>>>>> CONFIG_VMLINUX_MAP=y
>>>>> CONFIG_DEBUG_MEMORY_INIT=y
>>>>> CONFIG_BOOTPARAM=y
>>>>> CONFIG_BOOTPARAM_STRING="console=ttyS1,115200"
>>>>>
>>>>> My serial console is on UART6, so I suppose I will have to modify
>>>>> the MCFGPIO_PAR_UART2 register in arch/m68k/coldfire/m5441x.c at
>>>>> the very least.
>>>>
>>>> Was the older 3.0.12 code base a mainline kernel, or is it a
>>>> modified vendor version?
>>>
>>> The kernel came from the Tower system module and it has been adapted
>>> to the custom board. I suppose (but it was a long time ago and not me
>>> ;-)) that it was a downstream kernel.
>>>
>>> https://www.nxp.com/products/no-longer-manufactured/coldfire-mcf5441x-tower-system-module:TWR-MCF5441X
>>
>>
>> It is probably more likely that it used Freescales own development
>> package
>> (LTIB, or maybe something newer). It was most likely their own
>> modified kernel
>> sources, so probably not strictly a mainline kernel.
>>
>>
>>> Right now, when load addr is set to 0x40001000 and entry addr is set
>>> to 0x40002000 the 6.1 seems to start but nothing is going on my console.
>>>
>>> I added a local patch for my uart to be set, but still nothing yet:
>>> diff --git a/arch/m68k/coldfire/m5441x.c b/arch/m68k/coldfire/m5441x.c
>>> index 1e5259a652d1..1bcabef82851 100644
>>> --- a/arch/m68k/coldfire/m5441x.c
>>> +++ b/arch/m68k/coldfire/m5441x.c
>>> @@ -154,8 +154,8 @@ static struct clk * const enable_clks[]
>>> __initconst = {
>>> &__clk_0_23, /* dspi.0 */
>>> &__clk_0_24, /* uart0 */
>>> &__clk_0_25, /* uart1 */
>>> - &__clk_0_26, /* uart2 */
>>> &__clk_0_27, /* uart3 */
>>> + &__clk_1_26, /* uart 6 */
>>>
>>> &__clk_0_33, /* pit.1 */
>>> &__clk_0_37, /* eport */
>>> @@ -171,6 +171,7 @@ static struct clk * const disable_clks[]
>>> __initconst = {
>>> &__clk_0_14, /* i2c.1 */
>>> &__clk_0_22, /* i2c.0 */
>>> &__clk_0_23, /* dspi.0 */
>>> + &__clk_0_26, /* uart2 */
>>> &__clk_0_28, /* tmr.1 */
>>> &__clk_0_29, /* tmr.2 */
>>> &__clk_0_30, /* tmr.2 */
>>> @@ -198,7 +199,6 @@ static struct clk * const disable_clks[]
>>> __initconst = {
>>> &__clk_1_7, /* i2c.5 */
>>> &__clk_1_24, /* uart 4 */
>>> &__clk_1_25, /* uart 5 */
>>> - &__clk_1_26, /* uart 6 */
>>> &__clk_1_27, /* uart 7 */
>>> &__clk_1_28, /* uart 8 */
>>> &__clk_1_29, /* uart 9 */
>>> @@ -234,7 +234,9 @@ static void __init m5441x_uarts_init(void)
>>> {
>>> __raw_writeb(0x0f, MCFGPIO_PAR_UART0);
>>> __raw_writeb(0x00, MCFGPIO_PAR_UART1);
>>> - __raw_writeb(0x00, MCFGPIO_PAR_UART2);
>>> + /* TODO: Make it a dedicated file ! */
>>> + /* UART6 is our console */
>>> + __raw_writeb(0xaf, MCFGPIO_PAR_UART2);
>>> }
>>>
>>> static void __init m5441x_fec_init(void)
>>
>> I think you are going to need to get some raw UART trace in there to
>> really
>> see where it is getting too. It is relatively easy to push characters out
>> a UART, see the drivers/tty/serial/mcf.c uart driver to see how.
>>
>
> Thanks for this suggestion, it really helped me !
> Even if it is a very bad way to do it :-).
>
> So, I basically did:
> +static void __init uart6_putc(const char c)
> +{
> + /* MCFUART_BASE6 is the base address */
> + int i;
> + unsigned char __iomem *membase = (unsigned char __iomem
> *)MCFUART_BASE6;
> +
> + for (i = 0; (i < 0x10000); i++) {
> + if (readb(membase + MCFUART_USR) & MCFUART_USR_TXREADY)
> + break;
> + }
> + writeb(c, membase + MCFUART_UTB);
> + for (i = 0; (i < 0x10000); i++) {
> + if (readb(membase + MCFUART_USR) & MCFUART_USR_TXREADY)
> + break;
> + }
> +}
> +
> +static void __init uart6_console_write(struct console *co, const char
> *s, unsigned int count)
> +{
> + for (; (count); count--, s++) {
> + uart6_putc(*s);
> + if (*s == '\n')
> + uart6_putc('\r');
> + }
> +}
> +
> +static struct console uart6_console = {
> + .name = "uart6",
> + .write = uart6_console_write,
> + .flags = CON_PRINTBUFFER,
> + .index = -1,
> +};
>
> In the arch/m68k/coldfire/m5441x.c file and called
> register_console(&uart6_console); in the config_BSP() function.
>
> I can now see the messages ! And I can also say that when CONFIG_UBOOT
> is activated, it does not even enter in the config_BSP() function !
>
> When I unset it, I go really far, but I can see that the command line is
> empty in the pr_notice call of start_kernel. This means that
> saved_command_line is empty, but as I won't get it from uboot, it might
> be expected :-).
>
> I now need to get why the _init_sp does not have the proper value :-(.
>
For the record, I found the issue, which is already corrected latest
kernel by [1].
When I get into my kernel after u-boot jsr, the SP is [2].
I don't have any initrd, and it is deactivated in my defconfig now, but
we still try to access the address, which is 0x00000000 !
I think this patch should probably be reported to the stable kernels too ?
[1]:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/m68k/kernel/uboot.c?h=v6.10-rc1&id=3b4497668f721513eb7287f6bb0c4d651759c7c4
[2]: https://pasteboard.co/nVEC0bjTS5Ke.png
Thanks,
JM
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Kernel Image Format Issue - Coldfire mcf54418 CPU Failing to Boot
2024-05-28 6:32 ` Jean-Michel Hautbois
@ 2024-05-28 7:47 ` John Paul Adrian Glaubitz
2024-05-28 8:04 ` Jean-Michel Hautbois
2024-05-28 13:59 ` Greg Ungerer
1 sibling, 1 reply; 20+ messages in thread
From: John Paul Adrian Glaubitz @ 2024-05-28 7:47 UTC (permalink / raw)
To: Jean-Michel Hautbois, Greg Ungerer, Michael Schmitz,
Geert Uytterhoeven
Cc: linux-m68k
Hi Jean-Michel,
On Tue, 2024-05-28 at 08:32 +0200, Jean-Michel Hautbois wrote:
> For the record, I found the issue, which is already corrected latest
> kernel by [1].
That's great. Since I have a similar problem with my SH7785LCR which hangs
when u-boot tries to start the kernel, maybe we can debug the issue in a similar
way?
If I understand this correctly, you hacked in serial output at a very early
bootstage so you could see what was going on?
> When I get into my kernel after u-boot jsr, the SP is [2].
> I don't have any initrd, and it is deactivated in my defconfig now, but
> we still try to access the address, which is 0x00000000 !
>
> I think this patch should probably be reported to the stable kernels too ?
Such patches are normally backported to stable patches automatically.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Kernel Image Format Issue - Coldfire mcf54418 CPU Failing to Boot
2024-05-28 7:47 ` John Paul Adrian Glaubitz
@ 2024-05-28 8:04 ` Jean-Michel Hautbois
0 siblings, 0 replies; 20+ messages in thread
From: Jean-Michel Hautbois @ 2024-05-28 8:04 UTC (permalink / raw)
To: John Paul Adrian Glaubitz, Greg Ungerer, Michael Schmitz,
Geert Uytterhoeven
Cc: linux-m68k
Hello Adrian,
On 28/05/2024 09:47, John Paul Adrian Glaubitz wrote:
> Hi Jean-Michel,
>
> On Tue, 2024-05-28 at 08:32 +0200, Jean-Michel Hautbois wrote:
>> For the record, I found the issue, which is already corrected latest
>> kernel by [1].
>
> That's great. Since I have a similar problem with my SH7785LCR which hangs
> when u-boot tries to start the kernel, maybe we can debug the issue in a similar
> way?
>
> If I understand this correctly, you hacked in serial output at a very early
> bootstage so you could see what was going on?
I did two things, as this hangs even before the uart is configured. So I
used a trace32 jtag to see where it was really hanged.
I don't really know about sh architecture so I can't really help you
sorry :-(.
The command line seems to be set in arch/sh/kernel/setup.c:setup_arch()
so you should probably try to set CONFIG_CMDLINE and
CONFIG_CMDLINE_OVERWRITE as it should then be able to go on but without
a jtag, I am not sure you can easily debug it...
JM
>
>> When I get into my kernel after u-boot jsr, the SP is [2].
>> I don't have any initrd, and it is deactivated in my defconfig now, but
>> we still try to access the address, which is 0x00000000 !
>>
>> I think this patch should probably be reported to the stable kernels too ?
>
> Such patches are normally backported to stable patches automatically.
>
> Adrian
>
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Kernel Image Format Issue - Coldfire mcf54418 CPU Failing to Boot
2024-05-28 6:32 ` Jean-Michel Hautbois
2024-05-28 7:47 ` John Paul Adrian Glaubitz
@ 2024-05-28 13:59 ` Greg Ungerer
1 sibling, 0 replies; 20+ messages in thread
From: Greg Ungerer @ 2024-05-28 13:59 UTC (permalink / raw)
To: Jean-Michel Hautbois, Michael Schmitz, linux-m68k; +Cc: geert
Hi Jean-Michel,
On 28/5/24 16:32, Jean-Michel Hautbois wrote:
> Hi Greg, all,
>
> On 27/05/2024 15:19, Jean-Michel Hautbois wrote:
>> Hello Greg,
>>
>> On 21/05/2024 15:46, Greg Ungerer wrote:
>>> Hi Jean-Michel,
>>>
>>> On 16/5/24 23:31, Jean-Michel Hautbois wrote:
>>>> On 16/05/2024 14:43, Greg Ungerer wrote:
>>>>> On 15/5/24 21:10, Jean-Michel Hautbois wrote:
>>>>>> On 15/05/2024 12:29, Greg Ungerer wrote:
>>>>>>> On 15/5/24 17:56, Jean-Michel Hautbois wrote:
>>>>>>>> On 14/05/2024 22:16, Michael Schmitz wrote:
>>>>>>>>> 'BIV' is probably a bootinfo tag (Boot Info Version).
>>>>>>>>
>>>>>>>> Thanks, it helped me, as I read the head.S file and finally progressed :-).
>>>>>>>>
>>>>>>>> When dumping my vmlinux, I can see the entry point is *not* the load address (it was in the old one):
>>>>>>>> vmlinux: file format elf32-m68k
>>>>>>>>
>>>>>>>>
>>>>>>>> Disassembly of section .text:
>>>>>>>>
>>>>>>>> 40001000 <_stext>:
>>>>>>>> 40001000: 4ef9 4000 2000 jmp 40002000 <_start>
>>>>>>>> ...
>>>>>>>>
>>>>>>>> 40002000 <_start>:
>>>>>>>> 40002000: 4e71 nop
>>>>>>>> 40002002: 46fc 2700 movew #9984,%sr
>>>>>>>> 40002006: 203c 0104 0100 movel #17039616,%d0
>>>>>>>> 4000200c: 4e7b 0002 movec %d0,%cacr
>>>>>>>> 40002010: 4e71 nop
>>>>>>>>
>>>>>>>> Now, when uboot starts the kernel, it is not doing anything (not sure if it hangs or does not display anything on the console. And EARLY_PRINTK is not valid for coldfire :-(. Not sure why, so any guidance here would be appreciate too !
>>>>>>>>
>>>>>>>> I will now check my platform file but at least I am not trying to execute an instruction "0" :-).
>>>>>>>
>>>>>>> Can you post your kernel .conig file?
>>>>>>> Did you just start with your original 3.0.12 config and use that for 6.1.83?
>>>>>>
>>>>>> No, I used a very simplified one to start.
>>>>>>
>>>>>> CONFIG_NAMESPACES=y
>>>>>> CONFIG_EMBEDDED=y
>>>>>> CONFIG_COLDFIRE=y
>>>>>> CONFIG_M5441x=y
>>>>>> CONFIG_ADVANCED=y
>>>>>> # CONFIG_SINGLE_MEMORY_CHUNK is not set
>>>>>> CONFIG_CLOCK_FREQ=240000000
>>>>>> CONFIG_STMARK2=y
>>>>>> CONFIG_UBOOT=y
>>>>>> CONFIG_RAMBASE=0x40000000
>>>>>> CONFIG_RAMSIZE=0x8000000
>>>>>> CONFIG_VECTORBASE=0x40000000
>>>>>> CONFIG_KERNELBASE=0x40001000
>>>>>> CONFIG_BINFMT_FLAT=y
>>>>>> CONFIG_NET=y
>>>>>> CONFIG_PACKET=y
>>>>>> CONFIG_UNIX=y
>>>>>> CONFIG_INET=y
>>>>>> CONFIG_DEVTMPFS=y
>>>>>> CONFIG_DEVTMPFS_MOUNT=y
>>>>>> CONFIG_NETDEVICES=y
>>>>>> CONFIG_SERIAL_MCF=y
>>>>>> CONFIG_SERIAL_MCF_BAUDRATE=115200
>>>>>> CONFIG_SERIAL_MCF_CONSOLE=y
>>>>>> CONFIG_HID_A4TECH=y
>>>>>> CONFIG_HID_BELKIN=y
>>>>>> CONFIG_HID_CHERRY=y
>>>>>> CONFIG_HID_CYPRESS=y
>>>>>> CONFIG_HID_EZKEY=y
>>>>>> CONFIG_HID_ITE=y
>>>>>> CONFIG_HID_KENSINGTON=y
>>>>>> CONFIG_HID_REDRAGON=y
>>>>>> CONFIG_HID_MICROSOFT=y
>>>>>> CONFIG_HID_MONTEREY=y
>>>>>> CONFIG_VMLINUX_MAP=y
>>>>>> CONFIG_DEBUG_MEMORY_INIT=y
>>>>>> CONFIG_BOOTPARAM=y
>>>>>> CONFIG_BOOTPARAM_STRING="console=ttyS1,115200"
>>>>>>
>>>>>> My serial console is on UART6, so I suppose I will have to modify the MCFGPIO_PAR_UART2 register in arch/m68k/coldfire/m5441x.c at the very least.
>>>>>
>>>>> Was the older 3.0.12 code base a mainline kernel, or is it a modified vendor version?
>>>>
>>>> The kernel came from the Tower system module and it has been adapted to the custom board. I suppose (but it was a long time ago and not me ;-)) that it was a downstream kernel.
>>>>
>>>> https://www.nxp.com/products/no-longer-manufactured/coldfire-mcf5441x-tower-system-module:TWR-MCF5441X
>>>
>>>
>>> It is probably more likely that it used Freescales own development package
>>> (LTIB, or maybe something newer). It was most likely their own modified kernel
>>> sources, so probably not strictly a mainline kernel.
>>>
>>>
>>>> Right now, when load addr is set to 0x40001000 and entry addr is set to 0x40002000 the 6.1 seems to start but nothing is going on my console.
>>>>
>>>> I added a local patch for my uart to be set, but still nothing yet:
>>>> diff --git a/arch/m68k/coldfire/m5441x.c b/arch/m68k/coldfire/m5441x.c
>>>> index 1e5259a652d1..1bcabef82851 100644
>>>> --- a/arch/m68k/coldfire/m5441x.c
>>>> +++ b/arch/m68k/coldfire/m5441x.c
>>>> @@ -154,8 +154,8 @@ static struct clk * const enable_clks[] __initconst = {
>>>> &__clk_0_23, /* dspi.0 */
>>>> &__clk_0_24, /* uart0 */
>>>> &__clk_0_25, /* uart1 */
>>>> - &__clk_0_26, /* uart2 */
>>>> &__clk_0_27, /* uart3 */
>>>> + &__clk_1_26, /* uart 6 */
>>>>
>>>> &__clk_0_33, /* pit.1 */
>>>> &__clk_0_37, /* eport */
>>>> @@ -171,6 +171,7 @@ static struct clk * const disable_clks[] __initconst = {
>>>> &__clk_0_14, /* i2c.1 */
>>>> &__clk_0_22, /* i2c.0 */
>>>> &__clk_0_23, /* dspi.0 */
>>>> + &__clk_0_26, /* uart2 */
>>>> &__clk_0_28, /* tmr.1 */
>>>> &__clk_0_29, /* tmr.2 */
>>>> &__clk_0_30, /* tmr.2 */
>>>> @@ -198,7 +199,6 @@ static struct clk * const disable_clks[] __initconst = {
>>>> &__clk_1_7, /* i2c.5 */
>>>> &__clk_1_24, /* uart 4 */
>>>> &__clk_1_25, /* uart 5 */
>>>> - &__clk_1_26, /* uart 6 */
>>>> &__clk_1_27, /* uart 7 */
>>>> &__clk_1_28, /* uart 8 */
>>>> &__clk_1_29, /* uart 9 */
>>>> @@ -234,7 +234,9 @@ static void __init m5441x_uarts_init(void)
>>>> {
>>>> __raw_writeb(0x0f, MCFGPIO_PAR_UART0);
>>>> __raw_writeb(0x00, MCFGPIO_PAR_UART1);
>>>> - __raw_writeb(0x00, MCFGPIO_PAR_UART2);
>>>> + /* TODO: Make it a dedicated file ! */
>>>> + /* UART6 is our console */
>>>> + __raw_writeb(0xaf, MCFGPIO_PAR_UART2);
>>>> }
>>>>
>>>> static void __init m5441x_fec_init(void)
>>>
>>> I think you are going to need to get some raw UART trace in there to really
>>> see where it is getting too. It is relatively easy to push characters out
>>> a UART, see the drivers/tty/serial/mcf.c uart driver to see how.
>>>
>>
>> Thanks for this suggestion, it really helped me !
>> Even if it is a very bad way to do it :-).
>>
>> So, I basically did:
>> +static void __init uart6_putc(const char c)
>> +{
>> + /* MCFUART_BASE6 is the base address */
>> + int i;
>> + unsigned char __iomem *membase = (unsigned char __iomem *)MCFUART_BASE6;
>> +
>> + for (i = 0; (i < 0x10000); i++) {
>> + if (readb(membase + MCFUART_USR) & MCFUART_USR_TXREADY)
>> + break;
>> + }
>> + writeb(c, membase + MCFUART_UTB);
>> + for (i = 0; (i < 0x10000); i++) {
>> + if (readb(membase + MCFUART_USR) & MCFUART_USR_TXREADY)
>> + break;
>> + }
>> +}
>> +
>> +static void __init uart6_console_write(struct console *co, const char *s, unsigned int count)
>> +{
>> + for (; (count); count--, s++) {
>> + uart6_putc(*s);
>> + if (*s == '\n')
>> + uart6_putc('\r');
>> + }
>> +}
>> +
>> +static struct console uart6_console = {
>> + .name = "uart6",
>> + .write = uart6_console_write,
>> + .flags = CON_PRINTBUFFER,
>> + .index = -1,
>> +};
>>
>> In the arch/m68k/coldfire/m5441x.c file and called register_console(&uart6_console); in the config_BSP() function.
>>
>> I can now see the messages ! And I can also say that when CONFIG_UBOOT is activated, it does not even enter in the config_BSP() function !
>>
>> When I unset it, I go really far, but I can see that the command line is empty in the pr_notice call of start_kernel. This means that saved_command_line is empty, but as I won't get it from uboot, it might be expected :-).
>>
>> I now need to get why the _init_sp does not have the proper value :-(.
>>
>
> For the record, I found the issue, which is already corrected latest kernel by [1].
>
> When I get into my kernel after u-boot jsr, the SP is [2].
> I don't have any initrd, and it is deactivated in my defconfig now, but we still try to access the address, which is 0x00000000 !
Does u-boot on your 54418 platform support the passing of values
as laid out in arch/m68k/kernel/uboot.c?
I am guessing not based on what you see in SP.
Was CONFIG_UBOOT enabled in your original 3.0.12 kernel config?
> I think this patch should probably be reported to the stable kernels too ?
I am guessing it probably was not considered a bug fix that would
affect existing kernels.
I guess a good rule of thumb would be to go to the very newest
mainline kernel when up-porting :-)
Regards
Greg
> [1]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/m68k/kernel/uboot.c?h=v6.10-rc1&id=3b4497668f721513eb7287f6bb0c4d651759c7c4
> [2]: https://pasteboard.co/nVEC0bjTS5Ke.png
>
> Thanks,
> JM
^ permalink raw reply [flat|nested] 20+ messages in thread
* m54418: ELF execution issues
2024-05-15 7:56 ` Jean-Michel Hautbois
2024-05-15 10:29 ` Greg Ungerer
@ 2024-06-03 10:54 ` Jean-Michel Hautbois
2024-06-06 14:33 ` Greg Ungerer
2024-06-07 6:57 ` Geert Uytterhoeven
1 sibling, 2 replies; 20+ messages in thread
From: Jean-Michel Hautbois @ 2024-06-03 10:54 UTC (permalink / raw)
To: linux-m68k; +Cc: geert, Michael Schmitz
Hi there !
I managed to get really far in my boot process, as I can now try to
execute bash. I had to change the elf.h file because if I don't do that,
it is not working.
Here is the diff (on v6.9.1):
diff --git a/arch/m68k/include/asm/elf.h b/arch/m68k/include/asm/elf.h
index 2def06a99b08..38acb928fa81 100644
--- a/arch/m68k/include/asm/elf.h
+++ b/arch/m68k/include/asm/elf.h
@@ -78,8 +78,10 @@ typedef struct user_m68kfp_struct elf_fpregset_t;
the loader. We need to make sure that it is out of the way of the
program
that it will "exec", and that there is sufficient room for the brk. */
-#ifndef CONFIG_SUN3
+#if !defined(CONFIG_SUN3) && !defined(CONFIG_COLDFIRE)
#define ELF_ET_DYN_BASE 0xD0000000UL
+#elif defined(CONFIG_COLDFIRE)
+#define ELF_ET_DYN_BASE (TASK_UNMAPPED_BASE + 0x10000000)
#else
#define ELF_ET_DYN_BASE 0x0D800000UL
#endif
Without the patch:
[ 3.020000] Freeing unused kernel image (initmem) memory: 96K
[ 3.030000] This architecture does not have kernel memory protection.
[ 3.030000] Run /bin/bash as init process
[ 3.320000] Kernel panic - not syncing: Requested init /bin/bash
failed (error -12).
[ 3.320000] CPU: 0 PID: 1 Comm: bash Not tainted
6.9.2stmark2-001-00013-gcf0217bae3ae #285
[ 3.320000] Stack from 41845f70:
[ 3.320000] 41845f70 413bccd1 413bccd1 00000001 413f2700
41008a68 413151f2 413bccd1
[ 3.320000] 4130e630 41845fb0 413f2700 00000003 00000001
4130eeda 00000000 00000000
[ 3.320000] 41315a2e 413b303d 4febbf1e fffffff4 4131598e
410033f4 00000000 00000000
[ 3.320000] 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000
[ 3.320000] 00000000 00000000 00002000 00000000
[ 3.320000] Call Trace: arch_local_irq_disable
(./arch/m68k/include/asm/irqflags.h:20)
[ 3.320000] dump_stack (lib/dump_stack.c:124)
[ 3.320000] panic (kernel/panic.c:267 kernel/panic.c:369)
[ 3.320000] _printk (kernel/printk/printk.c:2368)
[ 3.320000] kernel_init (init/main.c:1500)
[ 3.320000] kernel_init (init/main.c:1436)
[ 3.320000] ret_from_kernel_thread (arch/m68k/kernel/entry.S:142)
[ 3.320000]
[ 3.320000] ---[ end Kernel panic - not syncing: Requested init
/bin/bash failed (error -12). ]---
With the patch, the /bin/bash file is executed, but then any command
will fail with a segfault:
[ 3.000000] Freeing unused kernel image (initmem) memory: 96K
[ 3.010000] This architecture does not have kernel memory protection.
[ 3.020000] Run /bin/bash as init process
bash: cannot set terminal process group (-1): Inappropriate ioctl for device
bash: no job control in this shell
bash-5.2# ls
bin home linuxrc opt run tmp
dev lib media 7.250000] Unable to handle kernel NULL
pointer dereference at virtual address 00000000
[ 7.250000] Oops: 00000000
[ 7.250000] PC: 0x0
[ 7.250000] SR: 2000 SP: (ptrval) a2: 41c58000
[ 7.250000] d0: 00000028 d1: 00000003 d2: 6017a000 d3: 414d9419
[ 7.250000] d4: 41b5c800 d5: 4fed3730 a0: 00000000 a1: 413227a0
[ 7.250000] Process ls (pid: 27, task=(ptrval))
[ 7.250000] Frame format=4 eff addr=41055826 pc=420516cc
[ 7.250000] Stack from 41b85dfc:
[ 7.250000] 4fed3730 41b85f1e 4106e3ac 4fed3730 00000000
ffffffff fffffffe 41b85ea2
[ 7.250000] 6017e000 00000001 412fbafc 4106dfe4 412fbafc
4fed3730 00000001 41b85ea2
[ 7.250000] 41b90600 6017e000 41b90600 41b6c340 6017dfff
41b84000 41b6c36c 00000000
[ 7.250000] 00000000 00000000 00000000 41b85f60 4106e5ea
41b85f1e 41b5c800 6017a000
[ 7.250000] 6017e000 41b85ea2 41b6c36c 41b85efa 41b85f1e
4102a3e8 41b6c344 41b5c4c0
[ 7.250000] 41b6c340 41b50000 00000100 00000003 41073130
41b85f1e 41b85efa 41b5c4c0
[ 7.250000] Call Trace: unmap_page_range (mm/memory.c:1482
mm/memory.c:1563 mm/memory.c:1605 mm/memory.c:1722 mm/memory.c:1751
mm/memory.c:1772 mm/memory.c:1793)
[ 7.250000] mas_find (lib/maple_tree.c:6061)
[ 7.250000] unmap_page_range (mm/memory.c:1782)
[ 7.250000] mas_find (lib/maple_tree.c:6061)
[ 7.250000] unmap_vmas (mm/memory.c:1839 mm/memory.c:1883)
[ 7.250000] up_read (kernel/locking/rwsem.c:1620)
[ 7.250000] exit_mmap (./include/linux/mmap_lock.h:173 mm/mmap.c:3268)
[ 7.250000] arch_local_irq_enable
(./arch/m68k/include/asm/irqflags.h:35)
[ 7.250000] arch_local_irq_disable
(./arch/m68k/include/asm/irqflags.h:20)
[ 7.250000] __mmput (kernel/fork.c:1348)
[ 7.250000] do_exit (./arch/m68k/include/asm/thread_info.h:46
kernel/exit.c:570 kernel/exit.c:865)
[ 7.250000] sys_exit_group (kernel/exit.c:1038 kernel/exit.c:1036)
[ 7.250000] do_group_exit (kernel/exit.c:1008)
[ 7.250000] pid_child_should_wake (kernel/exit.c:1503)
[ 7.250000] system_call (arch/m68k/coldfire/entry.S:80)
[ 7.250000]
[ 7.250000] Code: ffff ffff ffff ffff ffff ffff ffff ffff Bad PC value.
m68k-buildroot-linux-gnu-objdump: '/tmp/tmp.vO4KvxtnKV.o': No such file
Code starting with the faulting instruction
===========================================
[ 7.250000] Disabling lock debugging due to kernel taint
[ 7.250000] note: ls[27] exited with irqs disabled
Is there a compiler to use ? I built one with buildroot, but maybe is
there a gcc version somewhere to use for the Coldfire 54418 ? Could it
be related ?
Thanks,
JM
^ permalink raw reply related [flat|nested] 20+ messages in thread
* Re: m54418: ELF execution issues
2024-06-03 10:54 ` m54418: ELF execution issues Jean-Michel Hautbois
@ 2024-06-06 14:33 ` Greg Ungerer
2024-06-07 5:27 ` Jean-Michel Hautbois
2024-06-07 6:57 ` Geert Uytterhoeven
1 sibling, 1 reply; 20+ messages in thread
From: Greg Ungerer @ 2024-06-06 14:33 UTC (permalink / raw)
To: Jean-Michel Hautbois, linux-m68k; +Cc: geert, Michael Schmitz
Hi Jean-Michel,
On 3/6/24 20:54, Jean-Michel Hautbois wrote:
> Hi there !
>
> I managed to get really far in my boot process, as I can now try to execute bash. I had to change the elf.h file because if I don't do that, it is not working.
>
> Here is the diff (on v6.9.1):
> diff --git a/arch/m68k/include/asm/elf.h b/arch/m68k/include/asm/elf.h
> index 2def06a99b08..38acb928fa81 100644
> --- a/arch/m68k/include/asm/elf.h
> +++ b/arch/m68k/include/asm/elf.h
> @@ -78,8 +78,10 @@ typedef struct user_m68kfp_struct elf_fpregset_t;
> the loader. We need to make sure that it is out of the way of the program
> that it will "exec", and that there is sufficient room for the brk. */
>
> -#ifndef CONFIG_SUN3
> +#if !defined(CONFIG_SUN3) && !defined(CONFIG_COLDFIRE)
> #define ELF_ET_DYN_BASE 0xD0000000UL
> +#elif defined(CONFIG_COLDFIRE)
> +#define ELF_ET_DYN_BASE (TASK_UNMAPPED_BASE + 0x10000000)
Thats interesting. How did you determine this value to use?
> #else
> #define ELF_ET_DYN_BASE 0x0D800000UL
> #endif
>
> Without the patch:
> [ 3.020000] Freeing unused kernel image (initmem) memory: 96K
> [ 3.030000] This architecture does not have kernel memory protection.
> [ 3.030000] Run /bin/bash as init process
> [ 3.320000] Kernel panic - not syncing: Requested init /bin/bash failed (error -12).
> [ 3.320000] CPU: 0 PID: 1 Comm: bash Not tainted 6.9.2stmark2-001-00013-gcf0217bae3ae #285
> [ 3.320000] Stack from 41845f70:
> [ 3.320000] 41845f70 413bccd1 413bccd1 00000001 413f2700 41008a68 413151f2 413bccd1
> [ 3.320000] 4130e630 41845fb0 413f2700 00000003 00000001 4130eeda 00000000 00000000
> [ 3.320000] 41315a2e 413b303d 4febbf1e fffffff4 4131598e 410033f4 00000000 00000000
> [ 3.320000] 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> [ 3.320000] 00000000 00000000 00002000 00000000
> [ 3.320000] Call Trace: arch_local_irq_disable (./arch/m68k/include/asm/irqflags.h:20)
> [ 3.320000] dump_stack (lib/dump_stack.c:124)
> [ 3.320000] panic (kernel/panic.c:267 kernel/panic.c:369)
> [ 3.320000] _printk (kernel/printk/printk.c:2368)
> [ 3.320000] kernel_init (init/main.c:1500)
> [ 3.320000] kernel_init (init/main.c:1436)
> [ 3.320000] ret_from_kernel_thread (arch/m68k/kernel/entry.S:142)
> [ 3.320000]
> [ 3.320000] ---[ end Kernel panic - not syncing: Requested init /bin/bash failed (error -12). ]---
>
> With the patch, the /bin/bash file is executed, but then any command will fail with a segfault:
>
> [ 3.000000] Freeing unused kernel image (initmem) memory: 96K
> [ 3.010000] This architecture does not have kernel memory protection.
> [ 3.020000] Run /bin/bash as init process
> bash: cannot set terminal process group (-1): Inappropriate ioctl for device
> bash: no job control in this shell
> bash-5.2# ls
> bin home linuxrc opt run tmp
> dev lib media 7.250000] Unable to handle kernel NULL pointer dereference at virtual address 00000000
> [ 7.250000] Oops: 00000000
> [ 7.250000] PC: 0x0
> [ 7.250000] SR: 2000 SP: (ptrval) a2: 41c58000
> [ 7.250000] d0: 00000028 d1: 00000003 d2: 6017a000 d3: 414d9419
> [ 7.250000] d4: 41b5c800 d5: 4fed3730 a0: 00000000 a1: 413227a0
> [ 7.250000] Process ls (pid: 27, task=(ptrval))
> [ 7.250000] Frame format=4 eff addr=41055826 pc=420516cc
> [ 7.250000] Stack from 41b85dfc:
> [ 7.250000] 4fed3730 41b85f1e 4106e3ac 4fed3730 00000000 ffffffff fffffffe 41b85ea2
> [ 7.250000] 6017e000 00000001 412fbafc 4106dfe4 412fbafc 4fed3730 00000001 41b85ea2
> [ 7.250000] 41b90600 6017e000 41b90600 41b6c340 6017dfff 41b84000 41b6c36c 00000000
> [ 7.250000] 00000000 00000000 00000000 41b85f60 4106e5ea 41b85f1e 41b5c800 6017a000
> [ 7.250000] 6017e000 41b85ea2 41b6c36c 41b85efa 41b85f1e 4102a3e8 41b6c344 41b5c4c0
> [ 7.250000] 41b6c340 41b50000 00000100 00000003 41073130 41b85f1e 41b85efa 41b5c4c0
> [ 7.250000] Call Trace: unmap_page_range (mm/memory.c:1482 mm/memory.c:1563 mm/memory.c:1605 mm/memory.c:1722 mm/memory.c:1751 mm/memory.c:1772 mm/memory.c:1793)
> [ 7.250000] mas_find (lib/maple_tree.c:6061)
> [ 7.250000] unmap_page_range (mm/memory.c:1782)
> [ 7.250000] mas_find (lib/maple_tree.c:6061)
> [ 7.250000] unmap_vmas (mm/memory.c:1839 mm/memory.c:1883)
> [ 7.250000] up_read (kernel/locking/rwsem.c:1620)
> [ 7.250000] exit_mmap (./include/linux/mmap_lock.h:173 mm/mmap.c:3268)
> [ 7.250000] arch_local_irq_enable (./arch/m68k/include/asm/irqflags.h:35)
> [ 7.250000] arch_local_irq_disable (./arch/m68k/include/asm/irqflags.h:20)
> [ 7.250000] __mmput (kernel/fork.c:1348)
> [ 7.250000] do_exit (./arch/m68k/include/asm/thread_info.h:46 kernel/exit.c:570 kernel/exit.c:865)
> [ 7.250000] sys_exit_group (kernel/exit.c:1038 kernel/exit.c:1036)
> [ 7.250000] do_group_exit (kernel/exit.c:1008)
> [ 7.250000] pid_child_should_wake (kernel/exit.c:1503)
> [ 7.250000] system_call (arch/m68k/coldfire/entry.S:80)
> [ 7.250000]
> [ 7.250000] Code: ffff ffff ffff ffff ffff ffff ffff ffff Bad PC value.
> m68k-buildroot-linux-gnu-objdump: '/tmp/tmp.vO4KvxtnKV.o': No such file
>
> Code starting with the faulting instruction
> ===========================================
> [ 7.250000] Disabling lock debugging due to kernel taint
> [ 7.250000] note: ls[27] exited with irqs disabled
>
> Is there a compiler to use ? I built one with buildroot, but maybe is there a gcc version somewhere to use for the Coldfire 54418 ? Could it be related ?
I would expect you could use any modern version of gcc targeted for m68k-linux.
For the past few years to generate code for 5475 based platform I use a gcc-8.3.0
toolchain.
I have never had any of the 5441x based devices, so I couldn't say for sure on that.
Regards
Greg
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: m54418: ELF execution issues
2024-06-06 14:33 ` Greg Ungerer
@ 2024-06-07 5:27 ` Jean-Michel Hautbois
2024-06-08 2:15 ` Michael Schmitz
0 siblings, 1 reply; 20+ messages in thread
From: Jean-Michel Hautbois @ 2024-06-07 5:27 UTC (permalink / raw)
To: Greg Ungerer, linux-m68k; +Cc: geert, Michael Schmitz
Hi Greg !
On 06/06/2024 16:33, Greg Ungerer wrote:
> Hi Jean-Michel,
>
> On 3/6/24 20:54, Jean-Michel Hautbois wrote:
>> Hi there !
>>
>> I managed to get really far in my boot process, as I can now try to
>> execute bash. I had to change the elf.h file because if I don't do
>> that, it is not working.
>>
>> Here is the diff (on v6.9.1):
>> diff --git a/arch/m68k/include/asm/elf.h b/arch/m68k/include/asm/elf.h
>> index 2def06a99b08..38acb928fa81 100644
>> --- a/arch/m68k/include/asm/elf.h
>> +++ b/arch/m68k/include/asm/elf.h
>> @@ -78,8 +78,10 @@ typedef struct user_m68kfp_struct elf_fpregset_t;
>> the loader. We need to make sure that it is out of the way of
>> the program
>> that it will "exec", and that there is sufficient room for the
>> brk. */
>>
>> -#ifndef CONFIG_SUN3
>> +#if !defined(CONFIG_SUN3) && !defined(CONFIG_COLDFIRE)
>> #define ELF_ET_DYN_BASE 0xD0000000UL
>> +#elif defined(CONFIG_COLDFIRE)
>> +#define ELF_ET_DYN_BASE (TASK_UNMAPPED_BASE + 0x10000000)
>
> Thats interesting. How did you determine this value to use?
Let's be honest :-) I used the one found in the NXP kernel I have as a
reference (2.6 based). I finally found this is the root cause but I
don't know exactly why this value is used.
>
>
>> #else
>> #define ELF_ET_DYN_BASE 0x0D800000UL
>> #endif
>>
>> Without the patch:
>> [ 3.020000] Freeing unused kernel image (initmem) memory: 96K
>> [ 3.030000] This architecture does not have kernel memory protection.
>> [ 3.030000] Run /bin/bash as init process
>> [ 3.320000] Kernel panic - not syncing: Requested init /bin/bash
>> failed (error -12).
>> [ 3.320000] CPU: 0 PID: 1 Comm: bash Not tainted
>> 6.9.2stmark2-001-00013-gcf0217bae3ae #285
>> [ 3.320000] Stack from 41845f70:
>> [ 3.320000] 41845f70 413bccd1 413bccd1 00000001 413f2700
>> 41008a68 413151f2 413bccd1
>> [ 3.320000] 4130e630 41845fb0 413f2700 00000003 00000001
>> 4130eeda 00000000 00000000
>> [ 3.320000] 41315a2e 413b303d 4febbf1e fffffff4 4131598e
>> 410033f4 00000000 00000000
>> [ 3.320000] 00000000 00000000 00000000 00000000 00000000
>> 00000000 00000000 00000000
>> [ 3.320000] 00000000 00000000 00002000 00000000
>> [ 3.320000] Call Trace: arch_local_irq_disable
>> (./arch/m68k/include/asm/irqflags.h:20)
>> [ 3.320000] dump_stack (lib/dump_stack.c:124)
>> [ 3.320000] panic (kernel/panic.c:267 kernel/panic.c:369)
>> [ 3.320000] _printk (kernel/printk/printk.c:2368)
>> [ 3.320000] kernel_init (init/main.c:1500)
>> [ 3.320000] kernel_init (init/main.c:1436)
>> [ 3.320000] ret_from_kernel_thread (arch/m68k/kernel/entry.S:142)
>> [ 3.320000]
>> [ 3.320000] ---[ end Kernel panic - not syncing: Requested init
>> /bin/bash failed (error -12). ]---
>>
>> With the patch, the /bin/bash file is executed, but then any command
>> will fail with a segfault:
>>
>> [ 3.000000] Freeing unused kernel image (initmem) memory: 96K
>> [ 3.010000] This architecture does not have kernel memory protection.
>> [ 3.020000] Run /bin/bash as init process
>> bash: cannot set terminal process group (-1): Inappropriate ioctl for
>> device
>> bash: no job control in this shell
>> bash-5.2# ls
>> bin home linuxrc opt run tmp
>> dev lib media 7.250000] Unable to handle kernel NULL
>> pointer dereference at virtual address 00000000
>> [ 7.250000] Oops: 00000000
>> [ 7.250000] PC: 0x0
>> [ 7.250000] SR: 2000 SP: (ptrval) a2: 41c58000
>> [ 7.250000] d0: 00000028 d1: 00000003 d2: 6017a000 d3:
>> 414d9419
>> [ 7.250000] d4: 41b5c800 d5: 4fed3730 a0: 00000000 a1:
>> 413227a0
>> [ 7.250000] Process ls (pid: 27, task=(ptrval))
>> [ 7.250000] Frame format=4 eff addr=41055826 pc=420516cc
>> [ 7.250000] Stack from 41b85dfc:
>> [ 7.250000] 4fed3730 41b85f1e 4106e3ac 4fed3730 00000000
>> ffffffff fffffffe 41b85ea2
>> [ 7.250000] 6017e000 00000001 412fbafc 4106dfe4 412fbafc
>> 4fed3730 00000001 41b85ea2
>> [ 7.250000] 41b90600 6017e000 41b90600 41b6c340 6017dfff
>> 41b84000 41b6c36c 00000000
>> [ 7.250000] 00000000 00000000 00000000 41b85f60 4106e5ea
>> 41b85f1e 41b5c800 6017a000
>> [ 7.250000] 6017e000 41b85ea2 41b6c36c 41b85efa 41b85f1e
>> 4102a3e8 41b6c344 41b5c4c0
>> [ 7.250000] 41b6c340 41b50000 00000100 00000003 41073130
>> 41b85f1e 41b85efa 41b5c4c0
>> [ 7.250000] Call Trace: unmap_page_range (mm/memory.c:1482
>> mm/memory.c:1563 mm/memory.c:1605 mm/memory.c:1722 mm/memory.c:1751
>> mm/memory.c:1772 mm/memory.c:1793)
>> [ 7.250000] mas_find (lib/maple_tree.c:6061)
>> [ 7.250000] unmap_page_range (mm/memory.c:1782)
>> [ 7.250000] mas_find (lib/maple_tree.c:6061)
>> [ 7.250000] unmap_vmas (mm/memory.c:1839 mm/memory.c:1883)
>> [ 7.250000] up_read (kernel/locking/rwsem.c:1620)
>> [ 7.250000] exit_mmap (./include/linux/mmap_lock.h:173 mm/mmap.c:3268)
>> [ 7.250000] arch_local_irq_enable
>> (./arch/m68k/include/asm/irqflags.h:35)
>> [ 7.250000] arch_local_irq_disable
>> (./arch/m68k/include/asm/irqflags.h:20)
>> [ 7.250000] __mmput (kernel/fork.c:1348)
>> [ 7.250000] do_exit (./arch/m68k/include/asm/thread_info.h:46
>> kernel/exit.c:570 kernel/exit.c:865)
>> [ 7.250000] sys_exit_group (kernel/exit.c:1038 kernel/exit.c:1036)
>> [ 7.250000] do_group_exit (kernel/exit.c:1008)
>> [ 7.250000] pid_child_should_wake (kernel/exit.c:1503)
>> [ 7.250000] system_call (arch/m68k/coldfire/entry.S:80)
>> [ 7.250000]
>> [ 7.250000] Code: ffff ffff ffff ffff ffff ffff ffff ffff Bad PC value.
>> m68k-buildroot-linux-gnu-objdump: '/tmp/tmp.vO4KvxtnKV.o': No such file
>>
>> Code starting with the faulting instruction
>> ===========================================
>> [ 7.250000] Disabling lock debugging due to kernel taint
>> [ 7.250000] note: ls[27] exited with irqs disabled
>>
>> Is there a compiler to use ? I built one with buildroot, but maybe is
>> there a gcc version somewhere to use for the Coldfire 54418 ? Could it
>> be related ?
>
> I would expect you could use any modern version of gcc targeted for
> m68k-linux.
> For the past few years to generate code for 5475 based platform I use a
> gcc-8.3.0
> toolchain.
>
> I have never had any of the 5441x based devices, so I couldn't say for
> sure on that.
Well I found the root cause here too. But again, I don't know exactly why:
diff --git a/mm/page-writeback.c b/mm/page-writeback.c
index 12c9297ed4a7..c2a48592c258 100644
--- a/mm/page-writeback.c
+++ b/mm/page-writeback.c
@@ -2857,7 +2857,9 @@ bool folio_mark_dirty(struct folio *folio)
*/
if (folio_test_reclaim(folio))
folio_clear_reclaim(folio);
- return mapping->a_ops->dirty_folio(mapping, folio);
+ if (mapping->a_ops->dirty_folio)
+ return mapping->a_ops->dirty_folio(mapping, folio);
+ return noop_dirty_folio(mapping, folio);
}
return noop_dirty_folio(mapping, folio);
I intend to propose a few patches as RFC in order to know more and have
the correct solution (I suspect this is not the good one :-p).
Now, this is working correctly, with the toolchain I built. I have a few
issues like in NFC (I had to modify the vf610_nfc driver for it to take
the driver_data) or the FEC (this is not buildable for M5441x while it
should be AFAIK).
I will try to send a few patches shortly.
Thanks,
JM
^ permalink raw reply related [flat|nested] 20+ messages in thread
* Re: m54418: ELF execution issues
2024-06-03 10:54 ` m54418: ELF execution issues Jean-Michel Hautbois
2024-06-06 14:33 ` Greg Ungerer
@ 2024-06-07 6:57 ` Geert Uytterhoeven
1 sibling, 0 replies; 20+ messages in thread
From: Geert Uytterhoeven @ 2024-06-07 6:57 UTC (permalink / raw)
To: Jean-Michel Hautbois; +Cc: linux-m68k, Michael Schmitz
Hi Jean-Michel,
On Mon, Jun 3, 2024 at 12:54 PM Jean-Michel Hautbois
<jeanmichel.hautbois@yoseli.org> wrote:
> I managed to get really far in my boot process, as I can now try to
> execute bash. I had to change the elf.h file because if I don't do that,
> it is not working.
>
> Here is the diff (on v6.9.1):
> diff --git a/arch/m68k/include/asm/elf.h b/arch/m68k/include/asm/elf.h
> index 2def06a99b08..38acb928fa81 100644
> --- a/arch/m68k/include/asm/elf.h
> +++ b/arch/m68k/include/asm/elf.h
> @@ -78,8 +78,10 @@ typedef struct user_m68kfp_struct elf_fpregset_t;
> the loader. We need to make sure that it is out of the way of the
> program
> that it will "exec", and that there is sufficient room for the brk. */
>
> -#ifndef CONFIG_SUN3
> +#if !defined(CONFIG_SUN3) && !defined(CONFIG_COLDFIRE)
> #define ELF_ET_DYN_BASE 0xD0000000UL
> +#elif defined(CONFIG_COLDFIRE)
> +#define ELF_ET_DYN_BASE (TASK_UNMAPPED_BASE + 0x10000000)
> #else
> #define ELF_ET_DYN_BASE 0x0D800000UL
> #endif
If you end up needing to make a change here, please reshuffle the logic,
so it becomes more streamlined:
#ifdef CONFIG_COLDFIRE
...
#elif defined(CONFIG_SUN3)
...
#else
...
#endif
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: m54418: ELF execution issues
2024-06-07 5:27 ` Jean-Michel Hautbois
@ 2024-06-08 2:15 ` Michael Schmitz
2024-06-08 6:58 ` Jean-Michel Hautbois
2024-06-08 7:37 ` Andreas Schwab
0 siblings, 2 replies; 20+ messages in thread
From: Michael Schmitz @ 2024-06-08 2:15 UTC (permalink / raw)
To: Jean-Michel Hautbois, Greg Ungerer, linux-m68k; +Cc: geert
Jean-Michel,
Am 07.06.2024 um 17:27 schrieb Jean-Michel Hautbois:
> Hi Greg !
>
> On 06/06/2024 16:33, Greg Ungerer wrote:
>> Hi Jean-Michel,
>>
>> On 3/6/24 20:54, Jean-Michel Hautbois wrote:
>>> Hi there !
>>>
>>> I managed to get really far in my boot process, as I can now try to
>>> execute bash. I had to change the elf.h file because if I don't do
>>> that, it is not working.
>>>
>>> Here is the diff (on v6.9.1):
>>> diff --git a/arch/m68k/include/asm/elf.h b/arch/m68k/include/asm/elf.h
>>> index 2def06a99b08..38acb928fa81 100644
>>> --- a/arch/m68k/include/asm/elf.h
>>> +++ b/arch/m68k/include/asm/elf.h
>>> @@ -78,8 +78,10 @@ typedef struct user_m68kfp_struct elf_fpregset_t;
>>> the loader. We need to make sure that it is out of the way of
>>> the program
>>> that it will "exec", and that there is sufficient room for the
>>> brk. */
>>>
>>> -#ifndef CONFIG_SUN3
>>> +#if !defined(CONFIG_SUN3) && !defined(CONFIG_COLDFIRE)
>>> #define ELF_ET_DYN_BASE 0xD0000000UL
>>> +#elif defined(CONFIG_COLDFIRE)
>>> +#define ELF_ET_DYN_BASE (TASK_UNMAPPED_BASE +
>>> 0x10000000)
>>
>> Thats interesting. How did you determine this value to use?
>
> Let's be honest :-) I used the one found in the NXP kernel I have as a
> reference (2.6 based). I finally found this is the root cause but I
> don't know exactly why this value is used.
What does that kernel use for TASK_SIZE?
TASK_SIZE, TASK_UNMAPPED_BASE and ELF_ET_DYN_BASE all appear related
according to rules that I haven't found spelled out anywhere.
Cheers,
Michael
>
>>
>>
>>> #else
>>> #define ELF_ET_DYN_BASE 0x0D800000UL
>>> #endif
>>>
>>> Without the patch:
>>> [ 3.020000] Freeing unused kernel image (initmem) memory: 96K
>>> [ 3.030000] This architecture does not have kernel memory protection.
>>> [ 3.030000] Run /bin/bash as init process
>>> [ 3.320000] Kernel panic - not syncing: Requested init /bin/bash
>>> failed (error -12).
>>> [ 3.320000] CPU: 0 PID: 1 Comm: bash Not tainted
>>> 6.9.2stmark2-001-00013-gcf0217bae3ae #285
>>> [ 3.320000] Stack from 41845f70:
>>> [ 3.320000] 41845f70 413bccd1 413bccd1 00000001 413f2700
>>> 41008a68 413151f2 413bccd1
>>> [ 3.320000] 4130e630 41845fb0 413f2700 00000003 00000001
>>> 4130eeda 00000000 00000000
>>> [ 3.320000] 41315a2e 413b303d 4febbf1e fffffff4 4131598e
>>> 410033f4 00000000 00000000
>>> [ 3.320000] 00000000 00000000 00000000 00000000 00000000
>>> 00000000 00000000 00000000
>>> [ 3.320000] 00000000 00000000 00002000 00000000
>>> [ 3.320000] Call Trace: arch_local_irq_disable
>>> (./arch/m68k/include/asm/irqflags.h:20)
>>> [ 3.320000] dump_stack (lib/dump_stack.c:124)
>>> [ 3.320000] panic (kernel/panic.c:267 kernel/panic.c:369)
>>> [ 3.320000] _printk (kernel/printk/printk.c:2368)
>>> [ 3.320000] kernel_init (init/main.c:1500)
>>> [ 3.320000] kernel_init (init/main.c:1436)
>>> [ 3.320000] ret_from_kernel_thread (arch/m68k/kernel/entry.S:142)
>>> [ 3.320000]
>>> [ 3.320000] ---[ end Kernel panic - not syncing: Requested init
>>> /bin/bash failed (error -12). ]---
>>>
>>> With the patch, the /bin/bash file is executed, but then any command
>>> will fail with a segfault:
>>>
>>> [ 3.000000] Freeing unused kernel image (initmem) memory: 96K
>>> [ 3.010000] This architecture does not have kernel memory protection.
>>> [ 3.020000] Run /bin/bash as init process
>>> bash: cannot set terminal process group (-1): Inappropriate ioctl for
>>> device
>>> bash: no job control in this shell
>>> bash-5.2# ls
>>> bin home linuxrc opt run tmp
>>> dev lib media 7.250000] Unable to handle kernel NULL
>>> pointer dereference at virtual address 00000000
>>> [ 7.250000] Oops: 00000000
>>> [ 7.250000] PC: 0x0
>>> [ 7.250000] SR: 2000 SP: (ptrval) a2: 41c58000
>>> [ 7.250000] d0: 00000028 d1: 00000003 d2: 6017a000 d3:
>>> 414d9419
>>> [ 7.250000] d4: 41b5c800 d5: 4fed3730 a0: 00000000 a1:
>>> 413227a0
>>> [ 7.250000] Process ls (pid: 27, task=(ptrval))
>>> [ 7.250000] Frame format=4 eff addr=41055826 pc=420516cc
>>> [ 7.250000] Stack from 41b85dfc:
>>> [ 7.250000] 4fed3730 41b85f1e 4106e3ac 4fed3730 00000000
>>> ffffffff fffffffe 41b85ea2
>>> [ 7.250000] 6017e000 00000001 412fbafc 4106dfe4 412fbafc
>>> 4fed3730 00000001 41b85ea2
>>> [ 7.250000] 41b90600 6017e000 41b90600 41b6c340 6017dfff
>>> 41b84000 41b6c36c 00000000
>>> [ 7.250000] 00000000 00000000 00000000 41b85f60 4106e5ea
>>> 41b85f1e 41b5c800 6017a000
>>> [ 7.250000] 6017e000 41b85ea2 41b6c36c 41b85efa 41b85f1e
>>> 4102a3e8 41b6c344 41b5c4c0
>>> [ 7.250000] 41b6c340 41b50000 00000100 00000003 41073130
>>> 41b85f1e 41b85efa 41b5c4c0
>>> [ 7.250000] Call Trace: unmap_page_range (mm/memory.c:1482
>>> mm/memory.c:1563 mm/memory.c:1605 mm/memory.c:1722 mm/memory.c:1751
>>> mm/memory.c:1772 mm/memory.c:1793)
>>> [ 7.250000] mas_find (lib/maple_tree.c:6061)
>>> [ 7.250000] unmap_page_range (mm/memory.c:1782)
>>> [ 7.250000] mas_find (lib/maple_tree.c:6061)
>>> [ 7.250000] unmap_vmas (mm/memory.c:1839 mm/memory.c:1883)
>>> [ 7.250000] up_read (kernel/locking/rwsem.c:1620)
>>> [ 7.250000] exit_mmap (./include/linux/mmap_lock.h:173
>>> mm/mmap.c:3268)
>>> [ 7.250000] arch_local_irq_enable
>>> (./arch/m68k/include/asm/irqflags.h:35)
>>> [ 7.250000] arch_local_irq_disable
>>> (./arch/m68k/include/asm/irqflags.h:20)
>>> [ 7.250000] __mmput (kernel/fork.c:1348)
>>> [ 7.250000] do_exit (./arch/m68k/include/asm/thread_info.h:46
>>> kernel/exit.c:570 kernel/exit.c:865)
>>> [ 7.250000] sys_exit_group (kernel/exit.c:1038 kernel/exit.c:1036)
>>> [ 7.250000] do_group_exit (kernel/exit.c:1008)
>>> [ 7.250000] pid_child_should_wake (kernel/exit.c:1503)
>>> [ 7.250000] system_call (arch/m68k/coldfire/entry.S:80)
>>> [ 7.250000]
>>> [ 7.250000] Code: ffff ffff ffff ffff ffff ffff ffff ffff Bad PC value.
>>> m68k-buildroot-linux-gnu-objdump: '/tmp/tmp.vO4KvxtnKV.o': No such file
>>>
>>> Code starting with the faulting instruction
>>> ===========================================
>>> [ 7.250000] Disabling lock debugging due to kernel taint
>>> [ 7.250000] note: ls[27] exited with irqs disabled
>>>
>>> Is there a compiler to use ? I built one with buildroot, but maybe is
>>> there a gcc version somewhere to use for the Coldfire 54418 ? Could
>>> it be related ?
>>
>> I would expect you could use any modern version of gcc targeted for
>> m68k-linux.
>> For the past few years to generate code for 5475 based platform I use
>> a gcc-8.3.0
>> toolchain.
>>
>> I have never had any of the 5441x based devices, so I couldn't say for
>> sure on that.
>
> Well I found the root cause here too. But again, I don't know exactly why:
> diff --git a/mm/page-writeback.c b/mm/page-writeback.c
> index 12c9297ed4a7..c2a48592c258 100644
> --- a/mm/page-writeback.c
> +++ b/mm/page-writeback.c
> @@ -2857,7 +2857,9 @@ bool folio_mark_dirty(struct folio *folio)
> */
> if (folio_test_reclaim(folio))
> folio_clear_reclaim(folio);
> - return mapping->a_ops->dirty_folio(mapping, folio);
> + if (mapping->a_ops->dirty_folio)
> + return mapping->a_ops->dirty_folio(mapping, folio);
> + return noop_dirty_folio(mapping, folio);
> }
>
> return noop_dirty_folio(mapping, folio);
>
> I intend to propose a few patches as RFC in order to know more and have
> the correct solution (I suspect this is not the good one :-p).
>
> Now, this is working correctly, with the toolchain I built. I have a few
> issues like in NFC (I had to modify the vf610_nfc driver for it to take
> the driver_data) or the FEC (this is not buildable for M5441x while it
> should be AFAIK).
>
> I will try to send a few patches shortly.
>
> Thanks,
> JM
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: m54418: ELF execution issues
2024-06-08 2:15 ` Michael Schmitz
@ 2024-06-08 6:58 ` Jean-Michel Hautbois
2024-06-08 7:37 ` Andreas Schwab
1 sibling, 0 replies; 20+ messages in thread
From: Jean-Michel Hautbois @ 2024-06-08 6:58 UTC (permalink / raw)
To: Michael Schmitz, Greg Ungerer, linux-m68k; +Cc: geert
Hi Michael,
On 08/06/2024 04:15, Michael Schmitz wrote:
> Jean-Michel,
>
> Am 07.06.2024 um 17:27 schrieb Jean-Michel Hautbois:
>> Hi Greg !
>>
>> On 06/06/2024 16:33, Greg Ungerer wrote:
>>> Hi Jean-Michel,
>>>
>>> On 3/6/24 20:54, Jean-Michel Hautbois wrote:
>>>> Hi there !
>>>>
>>>> I managed to get really far in my boot process, as I can now try to
>>>> execute bash. I had to change the elf.h file because if I don't do
>>>> that, it is not working.
>>>>
>>>> Here is the diff (on v6.9.1):
>>>> diff --git a/arch/m68k/include/asm/elf.h b/arch/m68k/include/asm/elf.h
>>>> index 2def06a99b08..38acb928fa81 100644
>>>> --- a/arch/m68k/include/asm/elf.h
>>>> +++ b/arch/m68k/include/asm/elf.h
>>>> @@ -78,8 +78,10 @@ typedef struct user_m68kfp_struct elf_fpregset_t;
>>>> the loader. We need to make sure that it is out of the way of
>>>> the program
>>>> that it will "exec", and that there is sufficient room for the
>>>> brk. */
>>>>
>>>> -#ifndef CONFIG_SUN3
>>>> +#if !defined(CONFIG_SUN3) && !defined(CONFIG_COLDFIRE)
>>>> #define ELF_ET_DYN_BASE 0xD0000000UL
>>>> +#elif defined(CONFIG_COLDFIRE)
>>>> +#define ELF_ET_DYN_BASE (TASK_UNMAPPED_BASE +
>>>> 0x10000000)
>>>
>>> Thats interesting. How did you determine this value to use?
>>
>> Let's be honest :-) I used the one found in the NXP kernel I have as a
>> reference (2.6 based). I finally found this is the root cause but I
>> don't know exactly why this value is used.
>
> What does that kernel use for TASK_SIZE?
>
> TASK_SIZE, TASK_UNMAPPED_BASE and ELF_ET_DYN_BASE all appear related
> according to rules that I haven't found spelled out anywhere.
This commit explains how it has been changed on x86 a few years ago [1].
Most of the architectures define ELF_ET_DYN_BASE as 2/3rd of TASK_SIZE.
On the coldfire, TASK_SIZE is 0xC0000000. 2/3rd of it would be 0x80000000.
Still on coldfire, TASK_UNMAPPED_BASE is 0x60000000.
But for now, I can't tell exactly why using 0x70000000 is the chosen
solution of the old NXP BSP.
[1]:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=9b1bbf6ea9b2b596ba271bec23b93c48181ad896
JM
> Cheers,
>
> Michael
>
>
>>
>>>
>>>
>>>> #else
>>>> #define ELF_ET_DYN_BASE 0x0D800000UL
>>>> #endif
>>>>
>>>> Without the patch:
>>>> [ 3.020000] Freeing unused kernel image (initmem) memory: 96K
>>>> [ 3.030000] This architecture does not have kernel memory
>>>> protection.
>>>> [ 3.030000] Run /bin/bash as init process
>>>> [ 3.320000] Kernel panic - not syncing: Requested init /bin/bash
>>>> failed (error -12).
>>>> [ 3.320000] CPU: 0 PID: 1 Comm: bash Not tainted
>>>> 6.9.2stmark2-001-00013-gcf0217bae3ae #285
>>>> [ 3.320000] Stack from 41845f70:
>>>> [ 3.320000] 41845f70 413bccd1 413bccd1 00000001 413f2700
>>>> 41008a68 413151f2 413bccd1
>>>> [ 3.320000] 4130e630 41845fb0 413f2700 00000003 00000001
>>>> 4130eeda 00000000 00000000
>>>> [ 3.320000] 41315a2e 413b303d 4febbf1e fffffff4 4131598e
>>>> 410033f4 00000000 00000000
>>>> [ 3.320000] 00000000 00000000 00000000 00000000 00000000
>>>> 00000000 00000000 00000000
>>>> [ 3.320000] 00000000 00000000 00002000 00000000
>>>> [ 3.320000] Call Trace: arch_local_irq_disable
>>>> (./arch/m68k/include/asm/irqflags.h:20)
>>>> [ 3.320000] dump_stack (lib/dump_stack.c:124)
>>>> [ 3.320000] panic (kernel/panic.c:267 kernel/panic.c:369)
>>>> [ 3.320000] _printk (kernel/printk/printk.c:2368)
>>>> [ 3.320000] kernel_init (init/main.c:1500)
>>>> [ 3.320000] kernel_init (init/main.c:1436)
>>>> [ 3.320000] ret_from_kernel_thread (arch/m68k/kernel/entry.S:142)
>>>> [ 3.320000]
>>>> [ 3.320000] ---[ end Kernel panic - not syncing: Requested init
>>>> /bin/bash failed (error -12). ]---
>>>>
>>>> With the patch, the /bin/bash file is executed, but then any command
>>>> will fail with a segfault:
>>>>
>>>> [ 3.000000] Freeing unused kernel image (initmem) memory: 96K
>>>> [ 3.010000] This architecture does not have kernel memory
>>>> protection.
>>>> [ 3.020000] Run /bin/bash as init process
>>>> bash: cannot set terminal process group (-1): Inappropriate ioctl for
>>>> device
>>>> bash: no job control in this shell
>>>> bash-5.2# ls
>>>> bin home linuxrc opt run tmp
>>>> dev lib media 7.250000] Unable to handle kernel NULL
>>>> pointer dereference at virtual address 00000000
>>>> [ 7.250000] Oops: 00000000
>>>> [ 7.250000] PC: 0x0
>>>> [ 7.250000] SR: 2000 SP: (ptrval) a2: 41c58000
>>>> [ 7.250000] d0: 00000028 d1: 00000003 d2: 6017a000 d3:
>>>> 414d9419
>>>> [ 7.250000] d4: 41b5c800 d5: 4fed3730 a0: 00000000 a1:
>>>> 413227a0
>>>> [ 7.250000] Process ls (pid: 27, task=(ptrval))
>>>> [ 7.250000] Frame format=4 eff addr=41055826 pc=420516cc
>>>> [ 7.250000] Stack from 41b85dfc:
>>>> [ 7.250000] 4fed3730 41b85f1e 4106e3ac 4fed3730 00000000
>>>> ffffffff fffffffe 41b85ea2
>>>> [ 7.250000] 6017e000 00000001 412fbafc 4106dfe4 412fbafc
>>>> 4fed3730 00000001 41b85ea2
>>>> [ 7.250000] 41b90600 6017e000 41b90600 41b6c340 6017dfff
>>>> 41b84000 41b6c36c 00000000
>>>> [ 7.250000] 00000000 00000000 00000000 41b85f60 4106e5ea
>>>> 41b85f1e 41b5c800 6017a000
>>>> [ 7.250000] 6017e000 41b85ea2 41b6c36c 41b85efa 41b85f1e
>>>> 4102a3e8 41b6c344 41b5c4c0
>>>> [ 7.250000] 41b6c340 41b50000 00000100 00000003 41073130
>>>> 41b85f1e 41b85efa 41b5c4c0
>>>> [ 7.250000] Call Trace: unmap_page_range (mm/memory.c:1482
>>>> mm/memory.c:1563 mm/memory.c:1605 mm/memory.c:1722 mm/memory.c:1751
>>>> mm/memory.c:1772 mm/memory.c:1793)
>>>> [ 7.250000] mas_find (lib/maple_tree.c:6061)
>>>> [ 7.250000] unmap_page_range (mm/memory.c:1782)
>>>> [ 7.250000] mas_find (lib/maple_tree.c:6061)
>>>> [ 7.250000] unmap_vmas (mm/memory.c:1839 mm/memory.c:1883)
>>>> [ 7.250000] up_read (kernel/locking/rwsem.c:1620)
>>>> [ 7.250000] exit_mmap (./include/linux/mmap_lock.h:173
>>>> mm/mmap.c:3268)
>>>> [ 7.250000] arch_local_irq_enable
>>>> (./arch/m68k/include/asm/irqflags.h:35)
>>>> [ 7.250000] arch_local_irq_disable
>>>> (./arch/m68k/include/asm/irqflags.h:20)
>>>> [ 7.250000] __mmput (kernel/fork.c:1348)
>>>> [ 7.250000] do_exit (./arch/m68k/include/asm/thread_info.h:46
>>>> kernel/exit.c:570 kernel/exit.c:865)
>>>> [ 7.250000] sys_exit_group (kernel/exit.c:1038 kernel/exit.c:1036)
>>>> [ 7.250000] do_group_exit (kernel/exit.c:1008)
>>>> [ 7.250000] pid_child_should_wake (kernel/exit.c:1503)
>>>> [ 7.250000] system_call (arch/m68k/coldfire/entry.S:80)
>>>> [ 7.250000]
>>>> [ 7.250000] Code: ffff ffff ffff ffff ffff ffff ffff ffff Bad PC value.
>>>> m68k-buildroot-linux-gnu-objdump: '/tmp/tmp.vO4KvxtnKV.o': No such file
>>>>
>>>> Code starting with the faulting instruction
>>>> ===========================================
>>>> [ 7.250000] Disabling lock debugging due to kernel taint
>>>> [ 7.250000] note: ls[27] exited with irqs disabled
>>>>
>>>> Is there a compiler to use ? I built one with buildroot, but maybe is
>>>> there a gcc version somewhere to use for the Coldfire 54418 ? Could
>>>> it be related ?
>>>
>>> I would expect you could use any modern version of gcc targeted for
>>> m68k-linux.
>>> For the past few years to generate code for 5475 based platform I use
>>> a gcc-8.3.0
>>> toolchain.
>>>
>>> I have never had any of the 5441x based devices, so I couldn't say for
>>> sure on that.
>>
>> Well I found the root cause here too. But again, I don't know exactly
>> why:
>> diff --git a/mm/page-writeback.c b/mm/page-writeback.c
>> index 12c9297ed4a7..c2a48592c258 100644
>> --- a/mm/page-writeback.c
>> +++ b/mm/page-writeback.c
>> @@ -2857,7 +2857,9 @@ bool folio_mark_dirty(struct folio *folio)
>> */
>> if (folio_test_reclaim(folio))
>> folio_clear_reclaim(folio);
>> - return mapping->a_ops->dirty_folio(mapping, folio);
>> + if (mapping->a_ops->dirty_folio)
>> + return mapping->a_ops->dirty_folio(mapping,
>> folio);
>> + return noop_dirty_folio(mapping, folio);
>> }
>>
>> return noop_dirty_folio(mapping, folio);
>>
>> I intend to propose a few patches as RFC in order to know more and have
>> the correct solution (I suspect this is not the good one :-p).
>>
>> Now, this is working correctly, with the toolchain I built. I have a few
>> issues like in NFC (I had to modify the vf610_nfc driver for it to take
>> the driver_data) or the FEC (this is not buildable for M5441x while it
>> should be AFAIK).
>>
>> I will try to send a few patches shortly.
>>
>> Thanks,
>> JM
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: m54418: ELF execution issues
2024-06-08 2:15 ` Michael Schmitz
2024-06-08 6:58 ` Jean-Michel Hautbois
@ 2024-06-08 7:37 ` Andreas Schwab
1 sibling, 0 replies; 20+ messages in thread
From: Andreas Schwab @ 2024-06-08 7:37 UTC (permalink / raw)
To: Michael Schmitz; +Cc: Jean-Michel Hautbois, Greg Ungerer, linux-m68k, geert
On Jun 08 2024, Michael Schmitz wrote:
> TASK_SIZE, TASK_UNMAPPED_BASE and ELF_ET_DYN_BASE all appear related
> according to rules that I haven't found spelled out anywhere.
There is only one rule: TASK_UNMAPPED_BASE and ELF_ET_DYN_BASE must be
smaller than TASK_SIZE.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2024-06-08 7:43 UTC | newest]
Thread overview: 20+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-05-14 19:11 Kernel Image Format Issue - Coldfire mcf54418 CPU Failing to Boot Jean-Michel Hautbois
2024-05-14 20:16 ` Michael Schmitz
2024-05-15 7:56 ` Jean-Michel Hautbois
2024-05-15 10:29 ` Greg Ungerer
2024-05-15 11:10 ` Jean-Michel Hautbois
2024-05-16 12:43 ` Greg Ungerer
2024-05-16 13:31 ` Jean-Michel Hautbois
2024-05-21 13:46 ` Greg Ungerer
2024-05-27 13:19 ` Jean-Michel Hautbois
2024-05-28 6:32 ` Jean-Michel Hautbois
2024-05-28 7:47 ` John Paul Adrian Glaubitz
2024-05-28 8:04 ` Jean-Michel Hautbois
2024-05-28 13:59 ` Greg Ungerer
2024-06-03 10:54 ` m54418: ELF execution issues Jean-Michel Hautbois
2024-06-06 14:33 ` Greg Ungerer
2024-06-07 5:27 ` Jean-Michel Hautbois
2024-06-08 2:15 ` Michael Schmitz
2024-06-08 6:58 ` Jean-Michel Hautbois
2024-06-08 7:37 ` Andreas Schwab
2024-06-07 6:57 ` Geert Uytterhoeven
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).