How to enable serial console during boot up process for Linux L5.10.9 imx6dl

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

How to enable serial console during boot up process for Linux L5.10.9 imx6dl

Jump to solution
5,406 Views
hailiu
Contributor IV

Dear community,

I am debugging the booting up problem. I am using Uart3 as serial console. During the u-boot process, the console can display all the messages. After displaying the "starting Kernel", the system hangs. If I use GDB and vmlinux to debug the kernel,  because there is no dtb file loaded into memory, when the kernel run setup_arch() function, it should print "invalid dtb and unrecognized/unsupported machine ID" and "r1=...,r2=....", but nothing was printed on the console. I did run step by step, and the two lines:

early_print("\nError: invalid dtb and unrecognized/unsupported machine ID\n");
early_print(" r1=0x%08x, r2=0x%08x\n", __machine_arch_type,__atags_pointer);

did executed, but no output to the console.

I also boot the system by a SD card, and add a dead loop before the setup_arch(), found that the system did stay in the dead loop. If printk works, the console should display "Booting Linux on physical CPU 0" ,the linux banner,cgroug initialization information, etc, but nothing was displayed. It seems that the serial console was not set correctly. I modified CONFIG_CMDLINE="noinitrd console=ttymxc2,115200". I also add CONFIG_DEBUG_IMX_UART_PORT=3 in defconfig file.  Do I need to modify other configurations to make the UART3 works during the kernel start process?

thank you very much.

Hai.

0 Kudos
1 Solution
5,394 Views
hailiu
Contributor IV

at __log_buf, I can see the following messages:

Booting.Linux.on.physical.CPU.0x0

Linux.version.5.10.9-1.0.0+g303f46919105.(oe-user@oe-host).(arm-poky-linux-gnueabi-gcc.(GCC).10.2.0,.GNU.ld.(GNU.Binutils.).2.35.0.20200730).#1.SMP.PREEMPT.Tue.Mar.9.02:17:18.UTC.2021.

It proves that the serial console is not set correctly.

some modifications needed?

thanks a lot!

Hai

View solution in original post

0 Kudos
7 Replies
5,395 Views
hailiu
Contributor IV

at __log_buf, I can see the following messages:

Booting.Linux.on.physical.CPU.0x0

Linux.version.5.10.9-1.0.0+g303f46919105.(oe-user@oe-host).(arm-poky-linux-gnueabi-gcc.(GCC).10.2.0,.GNU.ld.(GNU.Binutils.).2.35.0.20200730).#1.SMP.PREEMPT.Tue.Mar.9.02:17:18.UTC.2021.

It proves that the serial console is not set correctly.

some modifications needed?

thanks a lot!

Hai

0 Kudos
5,372 Views
hailiu
Contributor IV

Found solution, use early_print function to print message to console. the following is the logging message:

U-Boot 2020.04-5.10.9-1.0.0+gad7b74b415 (Mar 05 2021 - 07:05:56 +0000)

CPU: i.MX6SOLO rev1.3 996 MHz (running at 792 MHz)
CPU: Extended Commercial temperature grade (-20C to 105C) at 33C
Reset cause: POR
Model:
Board:
DRAM: 2 GiB
PMIC: PFUZE100! DEV_ID=0x10 REV_ID=0x21
MMC: FSL_SDHC: 1, FSL_SDHC: 3
Loading Environment from MMC... *** Warning - bad CRC, using default environment

No panel detected: default to Hannstar-XGA
Display: Hannstar-XGA (1024x768)
In: serial
Out: serial
Err: serial
switch to partitions #0, OK
mmc1 is current device
Net: Could not get PHY for FEC0: addr 1
Could not get PHY for FEC0: addr 1
No ethernet found.

Fastboot: Normal
Normal Boot
Hit any key to stop autoboot: 3 2 1 0
WARNING: Could not determine tee to use
switch to partitions #0, OK
mmc1 is current device
8585104 bytes read in 420 ms (19.5 MiB/s)
Booting from mmc ...
48011 bytes read in 18 ms (2.5 MiB/s)
1057212 bytes read in 64 ms (15.8 MiB/s)
## Booting kernel from Legacy Image at 20000000 ...
Image Name:
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 1057148 Bytes = 1 MiB
Load Address: 14000000
Entry Point: 14000000
Verifying Checksum ... OK
## Flattened Device Tree blob at 18000000
Booting using the fdt blob at 0x18000000
Loading Kernel Image
Using Device Tree in place at 18000000, end 1800eb8a
switch to ldo_bypass mode!

Starting kernel ...

after setup_machine_fdt
after dump_stack_set_arch_desc
parse_early_param

0 Kudos
5,332 Views
hailiu
Contributor IV

need to modify the optee configurations CFG_UART_BASE to UART3_BASE and CFG_DDR_SIZE in git/core/arch/arm/plat-imx/conf.mk to have the printf and booting process works.

0 Kudos
5,376 Views
hailiu
Contributor IV

Looked around the web, founded I am not alone. I guess that because the device tree is not used yet, the hardware is not initialized, so printk() can not print message to console at this point. Earlyprintk may be a solution, but I don't want to waste the time any more, just use __dbg_buf to debug it.

Founded the following message in the web:

The Nonrobustness of printk()

A **bleep** in the armor of printk()'s robustness does exist. It is unusable before a certain point in the kernel boot process, prior to console initialization. Indeed, if the console is not initialized, where is the output supposed to go?

This is normally not an issue, unless you are debugging issues very early in the boot process (for example, in setup_arch(), which performs architecture-specific initialization). Such debugging is a challenge to begin with, and the absence of any sort of print method only compounds the problem.

There is some hope, but not a lot. Hardcore architecture hackers use the hardware that does work (say, a serial port) to communicate with the outside world. Trust meth is not fun for most people. Some supported architectures do implement a sane solution, however and others (i386 included) have patches available that also save the day.

The solution is a printk() variant that can output to the console very early in the boot process: early_printk(). The behavior is the same as printk(), only the name and its capability to work earlier are changed. This is not a portable solution, however, because not all supported architectures have such a method implemented. It might become your best friend, though, if it does.

Unless you need to write to the console very early in the boot process, you can rely on printk() to always work.

 

 

0 Kudos
5,393 Views
Bio_TICFSL
NXP TechSupport
NXP TechSupport

Hello hailu,

 

Are you using the Yocto build system to generate the images?

If so then, you also need to change the value of the "SERIAL_CONSOLES" variable in the machine configuration file in yocto build. You need to assign ttymxc2 to the SERIAL_CONSOLES variable as well.

 

e.g. SERIAL_CONSOLES = "115200;ttymxc2"

or from dtb uart3 should be tty2,

serial0 = &uart1;
serial1 = &uart2;
serial2 = &uart3;
serial3 = &uart4;

or check this note:

https://community.nxp.com/t5/Blogs/How-to-Change-i-MX8MM-evk-Linux-Debug-UART/ba-p/1243938

 

 

Regards

0 Kudos
5,383 Views
hailiu
Contributor IV

It seems I did all the changes you suggested. The following were what I did in the dts file:

aliases{

            serial0 = &uart1;
             serial1 = &uart2;
             serial2 = &uart3;
             serial3 = &uart4;
            serial4 = &uart5;

}

uart3: serial@21ec000 {
compatible = "fsl,imx6q-uart", "fsl,imx21-uart";
reg = <0x021ec000 0x4000>;
interrupts = <0 28 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX6QDL_CLK_UART_IPG>,
<&clks IMX6QDL_CLK_UART_SERIAL>;
clock-names = "ipg", "per";
dmas = <&sdma 29 4 0>, <&sdma 30 4 0>;
dma-names = "rx", "tx";
status = "disabled";
};

&uart3 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_uart3>;
status = "okay";
};

 

Any other thing I need to modify?

thank you!

0 Kudos
5,387 Views
hailiu
Contributor IV

Dear Bio,

Forget to mention that I did modified the SERIAL_CONSOLES to the value you suggested. I did not patch the variable in imx6sabresd-common.inc, but add a new line in my machine configuration file as:

SERIAL_CONSOLES = "115200;ttymxc2"

I don't know whether this is a problem. I will go further as you suggested to modify the dts file.

will let you know the results.

Thank you a lot.

0 Kudos