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
