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.

Linux/AM3358: Kernel hangs after u-boot message: Starting kernel ...

Part Number: AM3358


Tool/software: Linux

Hello,

I'm working with AM35XX starter kit with ti-processor-sdk-linux-am335x-evm-02.00.02.11.

After I updated and compiled the device tree (am335x-evmsk.dts) for our custom board, usually everything's working fine (Linux kernel + rootfs are loaded),

but occasionally (upon reset/power on/reboot) the kernel hangs as mentioned above.  (The problem with this updated DT happens both on our HW and on TI's AM35XX starter kit).

I enabled Low-level debug console UART + early printk (as mentioned in TI's document: "Kernel - Common Problems Booting Linux"), but no additional information is printed.

I suspect that it has something to do with the u-boot/DT/Kernel addresses:  do I need to update any u-boot variables or recompile u-boot ?

Here's the print logs from the new updated DT:  

U-Boot SPL 2015.07 (Apr 05 2016 - 19:26:40)
reading args
spl_load_image_fat_os: error reading image args, err - -1
reading u-boot.img
reading u-boot.img


U-Boot 2015.07 (Apr 05 2016 - 19:26:40 -0400)

Watchdog enabled
I2C: ready
DRAM: 256 MiB
NAND: 0 MiB
MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
reading uboot.env

** Unable to read "uboot.env" from mmc0:1 **
Using default environment

Net: <ethaddr> not set. Validating first E-fuse MAC
Phy 0 not found
cpsw, usb_ether
Hit any key to stop autoboot: 0
switch to partitions #0, OK
mmc0 is current device
SD/MMC found on device 0
switch to partitions #0, OK
mmc0 is current device
SD/MMC found on device 0
reading boot.scr
** Unable to read file boot.scr **
reading uEnv.txt
** Unable to read file uEnv.txt **
3317168 bytes read in 240 ms (13.2 MiB/s)
34511 bytes read in 41 ms (821.3 KiB/s)
Kernel image @ 0x82000000 [ 0x000000 - 0x329db0 ]
## Flattened Device Tree blob at 88000000
Booting using the fdt blob at 0x88000000
Loading Device Tree to 8ef22000, end 8ef2d6ce ... OK         /* As opposed to:   "Loading Device Tree to 8ef21000, end 8ef2d5df ... OK"    with the original DT   */

Starting kernel ...

BR,

Yehuda

  • Hi Yehuda,

    The addresses should be defined in u-boot (include/configs/ti_armv7_common.h):
    /*
    * Our DDR memory always starts at 0x80000000 and U-Boot shall have
    * relocated itself to higher in memory by the time this value is used.
    * However, set this to a 32MB offset to allow for easier Linux kernel
    * booting as the default is often used as the kernel load address.
    */
    #define CONFIG_SYS_LOAD_ADDR 0x82000000

    /*
    * We setup defaults based on constraints from the Linux kernel, which should
    * also be safe elsewhere. We have the default load at 32MB into DDR (for
    * the kernel), FDT above 128MB (the maximum location for the end of the
    * kernel), and the ramdisk 512KB above that (allowing for hopefully never
    * seen large trees). We say all of this must be within the first 256MB
    * as that will normally be within the kernel lowmem and thus visible via
    * bootm_size and we only run on platforms with 256MB or more of memory.
    */
    #define DEFAULT_LINUX_BOOT_ENV \
    "loadaddr=0x82000000\0" \
    "kernel_addr_r=0x82000000\0" \
    "fdtaddr=0x88000000\0" \
    "fdt_addr_r=0x88000000\0" \
    "rdaddr=0x88080000\0" \
    "ramdisk_addr_r=0x88080000\0" \
    "bootm_size=0x10000000\0"

    This is the default environment. Please double check your u-boot code.

    Best Regards,
    Yordan
  • Hi Yordan,

    Thanks for your quick reply.

    I haven't changed the original u-boot code since the size of the updated DT hasn't changed dramatically (it's now 47KB).

    I also see the same address values as you mentioned when I type "printenv" on the u-boot prompt.

    Do you have any other suggestions why the kernel occasionally hangs upon reset or power on?

    BR,

    Yehuda

  • Hello,

    In the custom BSP I deleted the below lines since most gpio0 signals have been removed in our new HW, but I hadn't noticed that gpio0_7 was still connected to the enable pin of VTT regulator.. After returning these lines, the kernel never hangs.

    &gpio0 {
    ti,no-reset-on-init;
    };