Linux booting stunk at starting Kernel

[hailiu]

Dear community members,

I am in the process to booting Linux L5.9.10 for imx6 solo processor. Right now, I have the u-boot running. the FDT is loaded to 0x18000000-0x1800EB8A. when the kernel begin to run, it stunk at starting kernel. I checked the processor mode by GDB, it is in data abort mode. When I debug the code with vmlinux step by step, it run to the point where r2 value is checked (__vet_atags routine). when the cpu run to the point where memory value pointed by R2 is going to be load, it goes to abort mode. The R2 value is 0xFFFFFFF8(which point to an invalid memory cell ), it seems that the dtb address or atags address is not passed to R2. What can be wrong? the u-boot does not pass the value to kernel? Is there any method to debug the issue?

thank you very much!

Hai 

[hailiu · Accepted solution]

It's my fault. I am lazy to initialize DDR, so I wanted to use the uboot initialization to debug vmlinux. After the uboot started the kernel, the MMU is enabled, R2 value was already changed by other code. I unplugged the SD card and use a DDR initialization script to initialize the DDR, then debug vmlinux, I can go further to the point where setup.c is executed. I hope this may help others to debug kernel by vmlinux. 

[hailiu]

the following is the log file for the linux booting. R2 has the correct value. It must be the switching process during which r2 value was modified. I need to debug step by step to find out the problem.

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 32C
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------this is due to the problem the fec crystal was not soldered on..

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
8584592 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!
Transferring control to Linux (at address 14000000)...
Using machid 0xf8c from environment

Starting kernel ...

r2=0x18000000

[igorpadykov]

Hi

may be recommended to run ddr test

https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX-6-7-DDR-Stress-Test-Tool/ta-p/11082...

and update dcd header with new ddr calibration coefficients found from test

https://source.codeaurora.org/external/imx/uboot-imx/tree/board/freescale/mx6sabresd/mx6solo_4x_mt41...

Best regards
igor

[hailiu]

Dear Igor,

Because the DDR stress test input problem, I did not run the DDR stress Test, but I did run my own DDR test code, and tested the whole 2GB cells for different data patterns, such as oxAAAAAAAA, 0x55555555, 0xCCCCCCCC, 0x33333333, 0xA5A5A5A5, etc. no error found. the parameters I got from calibration are very close to the reference board's coefficients. I did compare the data in memory from the u-boot code, they are the same. the vmlinux code downloadings are also verified by JLink, Ulink and eclipse, every verification is OK.

the possibility that DDR has problem seems to be small. I am afraid that the u-boot code modification has some problem. If I can know which part of u-boot code is used to pass atags, I can check that part of code to fix the problem quickly.

[hailiu]

I guess it is in bootm.c or bootm_fdt.c.