Custom kernel for T4240qds - boot issues

[vigneshwarensan]

Using yocto, I built a kernel for a T4240QDS machine. I customized the kernel, a kernel based on version 3.13

A root filesystem with the custom kernel was generated. I created a single ext2 filesystem for the root filesystem and copied the filesystem onto the SD card.

In the uboot prompt I ran:

setenv bootcmd 'setenv bootargs root=/dev/mmcblk0p1 rw rootdelay=5 console=$consoledev,$baudrate; mmcinfo; ext2load mmc 0:1 $loadaddr /boot/$bootfile; extl2load mmc 0:1 $fdtaddr $fdtfile; bootm $loadaddr - $fdtaddr'

I have set the variables, $bootfile,$fdtfile. $fdtaddr, $loadaddr etc. to their approproiate values.

The issues is, the board seems too boot the default 3.8.13-rt9-QorIQ-SDK-V1.4 kernel. The kernel never seems to be booting. The board seems to recognize my root filesystem, my kernel alone seems to have not booted. I checked using uname, and it doesnt show 3.13 kernel that I built. Why is it that the rootfs is being booted but not the custom kernel I built?

I am aware that the default boot mode for the T4240 machine is from the NOR flash, what switch settings should I have to change thee boot source to an SD card. Thanks in advance.

[scottwood]

What happens if you try the kernel ext2load command by itself, and compare what gets loaded into memory to the image you're expecting?  What value do you have in loadaddr?  Are you relying on autoboot, typing "boot", or doing something else to boot the board?

[vigneshwarensan]

I have shown all my parameters here, I havent included everything, only what is required:

bootargs=root=/dev/mmcblk0p1 rw rootdelay=5 console=ttyS0,115200

bootcmd=setenv bootargs root=/dev/mmcblk0p1 rw rootdelay=2 console=$consoledev,$baudrate;mmcinfo;ext2load mmc 0:1 $loadaddr /boot/$bootfile; ext2load mmc 0:1 $fdtaddr $fdtfile; bootm $loadaddr - $fdtaddr

bootdelay=10

bootfile=uImage

consoledev=ttyS0

fdtaddr=0xe8800000

fdtfile=uImage--1.0-r1-t4240qds-20140203110337.dtb

loadaddr=0xe8020000

uboot="u-boot.bin"

ubootaddr=0xeff80000

As you can see I set my bootcmd parameter to

          setenv bootargs root=/dev/mmcblk0p1 rw rootdelay=2 console=$consoledev,$baudrate;mmcinfo;ext2load mmc 0:1 $loadaddr /boot/$bootfile; ext2load mmc 0:1 $fdtaddr $fdtfile; bootm $loadaddr - $fdtaddr

My SD card has a single ext2 filesystem with the rootfs in it, and try to read load the kernel and fdt into memory using ext2load.

Then I type

=> boot

This is what I get:

Device: FSL_SDHC

Manufacturer ID: 3

OEM: 5344

Name: SU04G

Tran Speed: 50000000

Rd Block Len: 512

SD version 2.0

High Capacity: Yes

Capacity: 3.7 GiB

Bus Width: 4-bit

4569757 bytes read in 329 ms (13.2 MiB/s)

62049 bytes read in 113 ms (536.1 KiB/s)

WARNING: adjusting available memory to 30000000

## Booting kernel from Legacy Image at e8020000 ...

   Image Name:   Linux-3.8.13-rt9-QorIQ-SDK-V1.4

   Image Type:   PowerPC Linux Kernel Image (gzip compressed)

   Data Size:    4491674 Bytes = 4.3 MiB

   Load Address: 00000000

   Entry Point:  00000000

   Verifying Checksum ... OK

## Flattened Device Tree blob at e8800000

   Booting using the fdt blob at 0xe8800000

   Uncompressing Kernel Image ... OK

   Loading Device Tree to 03fdb000, end 03fffee0 ... OK

Using T4240 QDS machine description

MMU: Supported page sizes

         4 KB as direct

      1024 KB as direct

      2048 KB as direct

      4096 KB as direct

     16384 KB as direct

     65536 KB as direct

    262144 KB as direct

   1048576 KB as direct

These lines

4569757 bytes read in 329 ms (13.2 MiB/s)

62049 bytes read in 113 ms (536.1 KiB/s)

show that ext2load reads both files uImage and the fdt file.

The system boots, but as you can see, my kernel (which 3.13) is not shown to be booted. I verified with uname as well. However, my root filesystem works just fine. How is it that kernel isn't booting?

[scottwood]

You need to change $loadaddr and $fdtaddr to RAM addresses if you want to load something into them using ext2load.

[vigneshwarensan]

Thanks a lot!! Makes so much sense..

The addresses I gave were:

loadaddr - 0x1000000

fdtaddr -    0x17e0000

The memory map I referred here - doc/README.t4240qds - chromiumos/third_party/u-boot-next - Git at Google

The kernel booted fine, but the fdt blob stalled at:

Loading Device Tree to 03fdc000, end 03fff43f ... OK

I just have to make sure that my fdt build has no issues and is ready to boot.. Is my fdt blob faulty or should I choose suitable addresses?

[scottwood]

That doesn't necessarily indicate an fdt problem -- rather, it hung in the next step after loading the device tree, which is running the kernel.

Make sure the kernel you built includes support for t4240qds, including the exact board compatible string found in the device tree.  If there's no match for the board compatible, the kernel will hang with no output.

[vigneshwarensan]

Thanks a lot!! I have made the modifications, I used the kernel version from kernel.org (versions 3.10 and 3.12)

The kernel booted up fine.

I have a root filesystem on the SD card in which I have the kernel and DTB as well.

The kernel was not able to mount the root filesystem, The timeout error that I got was:

ata1: ATA_SRST issue failed

ata1: reset failed (errno=-5), retrying in 5 secs

mmc0: host doesn't support card's voltages

mmc0: error -22 whilst initialising SD card

The configuration file I used was the one from the SDK itself (e6500rev1_defconfig).

I am guessing, a few ATA drivers are not configured/built properly. Is there any config that I should enable/disable, or is there a kernel module itself that I need to replace in the newer kernel from the kernel in the freescale site.

[scottwood]

Upstream Linux does not and will not support rev1.  Please use rev2 silicon if at all possible.

For the ATA and MMC issues, there may be fixes missing from upstream.  If you still see this on the latest upstream kernel, please raise separate inquiries about those.

[RabbitHoleComp]

Scott,

Is there any particular reason why Freescale seems to be reticent to get their changes into upstream? I have a T5020 board, and am developing patchsets to get everything workign against a recent kernel, which I need for some particular functionality.

[scottwood]

I wish I had an answer to the general question...

For why we're not supporting e6500 rev1 upstream, the errata workarounds are too intrusive.  We don't support it on the latest SDK either.  It's not production-qualified silicon.

For ATA, please try with the following patches applied:

[1/4] powerpc: Dynamic DMA zone limits - Patchwork

[2/4] powerpc/64: Honor swiotlb limit in coherent allocations - Patchwork

[3/4] powerpc/64: Limit ZONE_DMA32 to 4GiB in swiotlb_detect_4g() - Patchwork

[4/4] powerpc/fsl-pci: Limit ZONE_DMA32 to 2GiB on 64-bit platforms - Patchwork

If your question is about things that are missing from upstream other than what this thread is already discussing, please raise a separate question about them.

[RabbitHoleComp]

scottwood

Many thanks for the links to the patches. They have fully resolved my SATA issues, and I suspect a couple of other DMA-realted issues I was experiencing.  I will start a new thread for any successive questions.