Linux kernel not booting with self-built uImage, but boots with most of the prebuilt images.

Hi Ari,
I use a custom K2L board. The kernel versions I have tried so far:

I use a custom K2L board. The kernel versions I have tried so far: .......
...........
3.1.3 for K2H board:

First of all, as I understand you use K2L EVM, and you're trying to boot it with K2H SDK release, am I right? You should use the official K2L release:
www.ti.com/.../processor-sdk-k2l

Then, as I see in k2l_evm.h, I see that you need to use:
name_fdt=keystone-k2l-evm.dtb
while your u-boot env sets:
name_fdt=uImage-k2l-evm.dtb

Second, as far as I know latest TI proc SDK uses zImage, not uImage, so you may need to run
bootz ${loadaddr} - ${fdtaddr}

Best Regards,
Yordan

Hello Yordan,
thanks for quick reply.

I maybe expressed myself unclearly in my previous email. I try to correct the understanding here.

I have K2L board, a custom (self-manufactured), but still a K2L board. And I intend to boot it with K2L Linux kernel Image, not K2H like I tried for one time.

I downloaded the official release yesterday from the same link you provide above, but is just does not work. It compiles OK, but won't boot. The prebuilt images from earlier kernel versions like 3.10.72 boot OK.
I would be happy to live with an ancient kernel version like 3.10.10 as a prebuilt image, but unfortunately I have to change the network chip driver from Marvel to Micron, so I need to build my own kernel.

I will try the bootz as you suggest and let you know how it does.

BRS, Ari

Hi,
I tested the bootz right away. My u-boot does not recognize the bootz command at all, neither the zImage format, so I need to build also the u-boot from the 4.4 sources. What worries me is that also the prebuilt u-boot image of 4.4 fails to run. I dos not print anything onto the console, not a single character.

BRS, Ari

Hello, Titusrathinaraj!

Thanks for the reply.

I need to replace Marvel's network phy driver with PD83867 phy driver, and that cannot be done in the kernel 3.10. because the headers are incompatible. For this reason only I have to migrate to kernel 4.4.

For some reason the prebuilt u-boot binary of 4.4 does not work at all, so I have to recompile it from scratch. In the u-boot I also need to modify the DDR3 settings, but this I already did with the version 3.10, so it shoulb be not big a task to repeat in 4.4 u-boot.

I will let you know how this succeeds. Thanks for the help so far!

BRS, Ari

Hello, Titusrathinaraj!

I still cannot boot the kernel version 4.4.

Today I recompiled the u-boot and boot-monitor from the SDK sources (kernel 4.4).

After adjusting the DDR3 settings the u-boot seems running stably, so I bunt it to NOR flash where it boots nicely from.

So, here is what I did next:

1. powered on the K2L board and let the u-boot run until it suggested for stopping the autoboot, then stopped it

2. printed the environment variables, see them below

3. connected to the K2L board with CCS and halted the CPU

4. loaded boot-monitor (prebuilt binary taken from the SDK package) into 0x0c140000.

5. loaded zImage into 0x88000000

6. loaded dtb into 0x87000000

7. resumed running the u-boot with the CCS

8. entered in the console:

=> mon_install 0x0c140000

K2_BM_15.07-39-g035329c SoC:k2l built:18:44:24, Oct  3 2016

## installed monitor, freq [163840000], status 0

=> bootz 0x88000000 - 0x87000000

Kernel image @ 0x88000000 [ 0x000000 - 0x34d528 ]

## Flattened Device Tree blob at 87000000

  Booting using the fdt blob at 0x87000000

  Loading Device Tree to 8fff2000, end 8fffffbe ... OK

Starting kernel ...

Then nothing more ever appears.

If I halt the CPU with the CCS and look at the code the CPU is running, it looks reliable.

A question: Are the load address and the entry point for the kernel image still 0x88000000 and 0x80008000 like before in the kernel 3.10, or have they been changed?

The code at zImage load location just before issuing the "bootz" command looks like:

88000000:   E1A00000            mov        r0, r0

88000004:   E1A00000            mov        r0, r0

88000008:   E1A00000            mov        r0, r0

8800000c:   E1A00000            mov        r0, r0

88000010:   E1A00000            mov        r0, r0

88000014:   E1A00000            mov        r0, r0

88000018:   E1A00000            mov        r0, r0

8800001c:   E1A00000            mov        r0, r0

88000020:   EA000003            b          #0x88000034

88000024:   016F2818           .word       0x016f2818

88000028:   00000000            andeq      r0, r0, r0

8800002c:   0034D528            eorseq     sp, r4, r8, lsr #10

88000030:   04030201            streq      r0, [r3], #-0x201

88000034:   E10F9000            mrs        r9, apsr

88000038:   EB000730            bl         #0x88001d00

8800003c:   E1A07001            mov        r7, r1

88000040:   E1A08002            mov        r8, r2

88000044:   E10F2000            mrs        r2, apsr

88000048:   E3120003            tst        r2, #3

8800004c:   1A000001            bne        #0x88000058

88000050:   E3A00017            mov        r0, #0x17

88000054:   EF123456            svc        #0x123456

88000058:   E10F0000            mrs        r0, apsr

8800005c:   E220001A            eor        r0, r0, #0x1a

88000060:   E310001F            tst        r0, #0x1f

The envirnoment variables are:

addr_mon=0x0c140000

addr_secdb_key=0xc000000

addr_ubi=0x82000000

arch=arm

args_all=setenv bootargs console=ttyS0,115200n8 rootwait=1

args_net=setenv bootargs ${bootargs} rootfstype=nfs root=/dev/nfs rw nfsroot=${s

erverip}:${nfs_root},${nfs_options} ip=dhcp

args_ramfs=setenv bootargs ${bootargs} rdinit=/sbin/init rw root=/dev/ram0 initr

d=0x808080000,80M

args_ubi=setenv bootargs ${bootargs} rootfstype=ubifs root=ubi0:rootfs rootflags

=sync rw ubi.mtd=ubifs,4096

baudrate=115200

board=ks2_evm

board_name=ks2_evm

boot=ubi

bootcmd=run init_${boot} init_fw_rd_${boot} get_fdt_${boot} get_mon_${boot} get_

kern_${boot} run_mon run_kern

bootdelay=2

bootdir=/boot

bootm_size=0x10000000

burn_ubi=nand erase.part ubifs; nand write ${addr_ubi} ubifs ${filesize}

burn_uboot_nand=nand erase 0 0x100000; nand write ${loadaddr} 0 ${filesize}

burn_uboot_spi=sf probe; sf erase 0 0x90000; sf write ${loadaddr} 0 ${filesize}

cpu=armv7

fdt_addr_r=0x88000000

fdtaddr=0x88000000

fdtcontroladdr=feee7fe0

get_fdt_net=dhcp ${fdtaddr} ${tftp_root}/${name_fdt}

get_fdt_nfs=nfs ${fdtaddr} ${nfs_root}/boot/${name_fdt}

get_fdt_ramfs=dhcp ${fdtaddr} ${tftp_root}/${name_fdt}

get_fdt_ubi=ubifsload ${fdtaddr} ${bootdir}/${name_fdt}

get_fs_ramfs=dhcp ${rdaddr} ${tftp_root}/${name_fs}

get_kern_net=dhcp ${loadaddr} ${tftp_root}/${name_kern}

get_kern_nfs=nfs ${loadaddr} ${nfs_root}/boot/${name_kern}

get_kern_ramfs=dhcp ${loadaddr} ${tftp_root}/${name_kern}

get_kern_ubi=ubifsload ${loadaddr} ${bootdir}/${name_kern}

get_mon_net=dhcp ${addr_mon} ${tftp_root}/${name_mon}

get_mon_nfs=nfs ${addr_mon} ${nfs_root}/boot/${name_mon}

get_mon_ramfs=dhcp ${addr_mon} ${tftp_root}/${name_mon}

get_mon_ubi=ubifsload ${addr_mon} ${bootdir}/${name_mon}

get_ubi_net=dhcp ${addr_ubi} ${tftp_root}/${name_ubi}

get_ubi_nfs=nfs ${addr_ubi} ${nfs_root}/boot/${name_ubi}

get_uboot_net=dhcp ${loadaddr} ${tftp_root}/${name_uboot}

get_uboot_nfs=nfs ${loadaddr} ${nfs_root}/boot/${name_uboot}

init_fw_rd_net=dhcp ${rdaddr} ${tftp_root}/${name_fw_rd}; run set_rd_spec

init_fw_rd_ramfs=setenv rd_spec -

init_fw_rd_ubi=ubifsload ${rdaddr} ${bootdir}/${name_fw_rd}; run set_rd_spec

init_net=run args_all args_net

init_nfs=setenv autoload no; dhcp; run args_all args_net

init_ramfs=run args_all args_ramfs get_fs_ramfs

init_ubi=run args_all args_ubi; ubi part ubifs; ubifsmount ubi:rootfs;

kernel_addr_r=0x82000000

loadaddr=0x82000000

mem_lpae=1

mtdparts=mtdparts=davinci_nand.0:1024k(bootloader)ro,512k(params)ro,-(ubifs)

name_fdt=keystone-k2l-evm.dtb

name_fs=arago-console-image-k2l-evm.cpio.gz

name_fw_rd=k2-fw-initrd.cpio.gz

name_kern=zImage

name_mon=skern-k2l.bin

name_ubi=k2l-evm-ubifs.ubi

name_uboot=u-boot-spi-k2l-evm.gph

nfs_options=v3,tcp,rsize=4096,wsize=4096

nfs_root=/export

no_post=1

pxefile_addr_r=0x80100000

ramdisk_addr_r=0x88080000

rdaddr=0x88080000

run_kern=bootz ${loadaddr} ${rd_spec} ${fdtaddr}

run_mon=mon_install ${addr_mon}

scriptaddr=0x80000000

set_rd_spec=setenv rd_spec ${rdaddr}:${filesize}

soc=keystone

stderr=serial@02530c00

stdin=serial@02530c00

stdout=serial@02530c00

tftp_root=/

vendor=ti

ver=U-Boot 2016.05-00118-gada2933-dirty (Nov 14 2016 - 14:37:44 +0200)

Environment size: 3288/262140 bytes

What am I missing or doing wrong?

Best regards,

Ari

Hi,

could somebody please tell me if I am using a right procedure for booting the kernel version 4.4 for a K2L board from DDR3 memory or not. What is the load address and entry point for the zImage of the kernel 4.4 for K2L board and how can I make the u-boot to jump into the kernel entry with the zImage + bootz command? With a uImage + bootm it is simple and works.

My board fails to boot the prebuilt zImage of the kernel version 4,4, but succeeds booting all the older images, like uImage for kernels 3.10.10 and 3.10.72.

All images compiled myself fail to boot regardless of kernel version.

I can build a working u-boot from the sources of any kernel version which proves, from my opinion, that my tool chain is correctly working.

BTW, what role has the boot-monitor in the boot sequence? Must it be running or installed with the "mon_install" command before giving the commend "bootm" or "bootz"?

According to the observations above it seems that my board is working and my tool chain is working, but there is something wrong in my self built images and in the bootz procedure of the zImage or in the zImage itself.

Best regards,

Ari

I am still waiting for a reply. Any piece of advice is greatly valuated. I am really lost with this issue,

Thanks in advance!

Best regards,

Ari

Hi Ari,

You use:
bootz 0x88000000 - 0x87000000

When in your u-boot environment the kernel address is:
kernel_addr_r=0x82000000

loadaddr=0x82000000

And the dtb address is:
fdt_addr_r=0x88000000

fdtaddr=0x88000000

Can you try executing:
bootz ${loadaddr} - ${fdtaddr}

Best Regards,
Yordan

Hello Yordan,
I did what you suggested, but still no booting.

The procedure:
1. power on the board
2. stop autoboot of the u-boot
3. connect target + halt the CPU
4. with CCS load "zImage-k2l-evm.bin" ---> 0x82000000
5. with CCS load "keystone-k2l-evm.dtb" ---> 0x88000000
6. with CCS load "skern-k2l.bin" ---> 0x0c140000
7. resume the CPU running
8. on the console type:
K2L EVM # mon_install 0x0c140000
K2_BM_15.07-39-g035329c SoC:k2l built:18:44:24, Oct 3 2016

## installed monitor, freq [199680000], status 0
K2L EVM # setenv kernel_addr_r 0x82000000
K2L EVM # setenv loadaddr 0x82000000
K2L EVM # setenv fdt_addr_r 0x88000000
K2L EVM # setenv fdtaddr 0x88000000
K2L EVM # bootz ${loadaddr} - ${fdtaddr}
ERROR: Did not find a cmdline Flattened Device Tree
Could not find a valid device tree
K2L EVM # bootz ${loadaddr} - ${fdtaddr}
ERROR: Did not find a cmdline Flattened Device Tree
Could not find a valid device tree
K2L EVM # bootz ${loadaddr} - ${fdtaddr}
ERROR: Did not find a cmdline Flattened Device Tree
Could not find a valid device tree
K2L EVM # bootz 0x82000000 - 0x88000000
## Flattened Device Tree blob at 88000000
Booting using the fdt blob at 0x88000000
Using Device Tree in place at 88000000, end 8800dfbe

Starting kernel ...

Then nothing more.
All the .bin files used above are from the SDK binary package. The u-boot I have built myself because of different DDR3 settings. I also removed the net support from my u-boot since my K2L board has no Marvell chip. These changes make my u-boot be stable.

Best regards,
Ari

Hi Ari,

The error message suggests that you're not using the correct .dtb file.
This is because your u-boot environment tries to find the fdt file on your filesystem in the /boot directory, see
bootdir=/boot

I just realized that you're trying to boot over CCS, without booting the linux filesystem. I am not sure this will work.

See the following guide:

processors.wiki.ti.com/.../Processor_SDK_Linux_Software_Developer’s_Guide

In the Guetting Started guide (processors.wiki.ti.com/.../Processor_SDK_Linux_Getting_Started_Guide, you have a wiki for programming your board:
processors.wiki.ti.com/.../Program_EVM_UG

You should boot your board as described in the Program_EVM_UG wiki.

Best Regards,
Yordan

Hi Ari,

Thanks for updating the thread.

Best Regards,
Yordan