• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 97 subscribers
  • Views 1305 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

66AK2G12: How to debug board booting process? Hangs at "Starting Kernel ..."

Luke Vassallo
Prodigy 180 points
Part Number: 66AK2G12

Hello, 

We have a custom board with a 66AK2G12 processor and are trying to get linux going. We used the iceK2G development kit to get familiar with the processor and are porting the key components from it. This is what we have done so far:

1. The key hardware was tested in CCS with JTAG.

2. u-boot was modified ( following this guide https://software-dl.ti.com/processor-sdk-linux/esd/docs/06_03_00_106/AM335X/linux/How_to_Guides/Board_Port/U-Boot.html ) and tested on our custom board. 

3. We are now trying to boot linux.  

To boot linux we are using an image developed on the iceK2G board that has its Device Tree Blob (.dtb) file replaced. We replace this with the one generated for our board through building uboot. The boot process hangs at "Starting Kernel ...". 

The following is what we observe during the board bring up: 

U-Boot 2019.01-gededbfb329-dirty (Feb 17 2021 - 12:15:31 +0100)

CPU: 66AK2Gx-60 SR1.0
Model: <model-name-was-here>
DRAM:
Clear entire DDR3 memory to enable ECC

Clear entire DDR3 memory to enable ECC
512 MiB
MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
Loading Environment from FAT... *** Warning - bad CRC, using default environment

Net:
Warning: netcp@4000000 using MAC address from ROM
eth0: netcp@4000000
Hit any key to stop autoboot: 2 1 0
switch to partitions #0, OK
mmc0 is current device
SD/MMC found on device 0
** Unable to read file boot.scr **
** Unable to read file uEnv.txt **
32832 bytes read in 6 ms (5.2 MiB/s)
K2_BM_15.07-53-ge1f885ab6dc5 SoC:k2g built:09:52:34, Oct 27 2020

## installed monitor @ 0xc0f7000, freq [25000000], status 202338304
33620 bytes read in 6 ms (5.3 MiB/s)
0 - Name:'pmmc@2900000' type:'internal memory mapped' supports: load start
Load Remote Processor 0 with data@addr=0x82000000 33620 bytes: Success!
4338176 bytes read in 207 ms (20 MiB/s)
** File not found /boot/k2-fw-initrd.cpio.gz **
8814 bytes read in 6 ms (1.4 MiB/s)
## Flattened Device Tree blob at 88000000
Booting using the fdt blob at 0x88000000
Loading Ramdisk to 8fbdc000, end 8ffff200 ... OK
Loading Device Tree to 8fbd6000, end 8fbdb26d ... OK

Starting kernel ...

These are some questions we have :

1. Can we drop in a linux image just like that or does it require modifications? How do we debug the hanging ?

2. Can we modify u-boot so as it generates debug information ?

3. How can we generate boot.scr and uEnv.txt ?

Thanks in advance

Luke

  • 0
    TI__Mastermind 40090 points

    Hi,

    The starting kernel message is a signoff message from u-boot right before it calls the kernel init code. Since the board is able to launch the kernel I am not sure adding debug code U-Boot will here. In this type of problem the kernel has tried to init but something has gone wrong and processor is mostly likely running in a data abort loop.

    Normally you should be able to use the kernel image provided with the SDK. How different is your board from the K2G EVM? If it is not too different you might try using the evm dtb in the prebuilt images. This might not work fully but it might help with pointing the issue is in the dtb file. 

    Best Regards,

    Schuyler

  • 0 in reply to Schuyler Patton
    Prodigy 180 points

    Hi Schuyler, thank you for your reply.

    Our board was developed based on the iceK2G, the major difference is in the boot procedure. We’re booting from an sd card physically connected to mmc0, whilst the iceK2G is booting from an sd card physically connected to mmc1.

    I’ve done a simple test on the iceK2G to hopefully narrow down the problem. I formatted the rootfs partition and inside I only created the boot folder with the following files inside:

    1. zImage,
    2. keystone-ice-k2g.dtb,
    3. skern-k2g.bin

    The iceK2G boots and starts loading the kernel successfully. Eventually it fails to source other files in the rootfs. This is what was expected.

    Using this minimal configuration, I’m trying to replicate the same behavior on the custom board. Based on the test, the only difference I can note is the Device Tree Blob, which I’ve re-compiled from the kernel repository.

    MLO and u-boot.img in the boot partition are not identical between the two boards, but based on your response it seemed logical to focus debugging efforts around the kernel rather than u-boot.

  • 0 in reply to Luke Vassallo
    Prodigy 180 points

    The issue had to do with the sdcard, it was somehow formatted incorrectly ( I am using a virtual machine ). After formatting and re populating the partitions linux booted. 

    However now I'm encountering a second issue during the booting of the kernel and it seems to be related to clocking. 

    I'm noticing that the keystone timer on the k2gice devkit is set to 100MHz, whilst on the custom board is set to 96MHz. The CPTS clock ( not shown for the custom board ) was also set to 96MHz as the gbe was disabled in the device tree to keep simply things. 

    Console output for k2gice development kit.

    Console output from custom board.

    Furthermore, the baudrate of the serial changes at some point and I start reading garbage. I verified two things at this point:

    1. With an oscilloscope I noticed that that baudrate changes from 115200 to 125000.

    2. The JTAG was hooked up and uart pll settings were read at two points: during u-boot and after the output has turned to garbage. The following were the results:

    According to the u-boot soruce files for configuring the keystone plls the setting values in column 2 are for an input clock of 25MHz whilst those in column 3 are for a 24MHz.

    We have clocksel tied high, are a providing a differential 25MHz clock on sysclk p/n pins, therefore I assumed that the clock wouldn't change and computed pllout accordingly. 

    What is a likely cause for this ? So far I’ve ruled out u-boot since the pll configuration is correct for the UART PLL. Inside the linux kernel, I do not know if I should change any settings related to clocking. Please provide assistance.

    Thanks in advance.