• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 101 subscribers
  • Views 265 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Original question:

TMDSLCDK138: fw_printenv not able to read NAND flash parameters

TMDSLCDK138: OMAP-L138 Linux v4.19.94 Fails to Boot

Benjamin Michaud
Expert 1825 points
Part Number: TMDSLCDK138
Other Parts Discussed in Thread: OMAP-L138, DA8XX, OMAPL138

Hi,

I've recently been working with trying to build the kernel for the OMAP-L138 to run on the LCDK dev board.

There doesn't seem to be an issue with building the kernel, doing # make linux in the Linux SDK folder works fine.

The zImage is generated and I was able to figure out how to use mkimage to modify the zImage so U Boot can load the kernel, which is done.

However, I don't think that the config file for the hardware/peripherals being used to generate the Linux kernel is the correct one.

The SD card which shipped with the dev kit has kernel v3.3 on it and this works fine.

The machine in the Linux output during boot is the following:

Machine: AM18x/OMAP-L138 lcdk board

When I build the kernel on my machine it is version 4.19.94 and the machine is different:

Machine: AM18x/OMAP-L138 Hawkboard

When the version 4.19.94 kernel boots it gets stuck after interacting with the SD card (below is the output at boot time)

** Unable to read "boot.scr" from mmc 0:1 **
reading uImage

3472424 bytes read
## Booting kernel from Legacy Image at c0700000 ...
   Image Name:   Test Kernel v1.00
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    3472360 Bytes = 3.3 MiB
   Load Address: c0008000
   Entry Point:  c0008000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
Booting Linux on physical CPU 0x0
Linux version 4.19.94-gbe5389fd85 (root@ben-Inspiron-7773) (gcc version 8.2.0 (GCC)) #1 PREEMPT Tue Oct 27 15:45:16 EDT 2020
CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=0005317f
CPU: VIVT data cache, VIVT instruction cache
Machine: AM18x/OMAP-L138 Hawkboard
Memory policy: Data cache writethrough
da8xx_rproc_reserve_cma: 'rproc_mem=nn@address' badly specified
    'nn' and 'address' must both be non-zero
cma: Reserved 24 MiB at 0xc6400000
DaVinci da850/omap-l138/am18x variant 0x1
random: get_random_bytes called from start_kernel+0x88/0x424 with crng_init=0
Built 1 zonelists, mobility grouping on.  Total pages: 32480
Kernel command line: console=ttyS2,115200n8 root=/dev/mmcblk0p2 rw rootwait ip=off
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 95428K/131072K available (6772K kernel code, 349K rwdata, 2156K rodata, 256K init, 152K bss, 11068K reserved, 24576K cma-reserved)
Virtual kernel memory layout:
    vector  : 0xffff0000 - 0xffff1000   (   4 kB)
    fixmap  : 0xffc00000 - 0xfff00000   (3072 kB)
    vmalloc : 0xc8800000 - 0xff800000   ( 880 MB)
    lowmem  : 0xc0000000 - 0xc8000000   ( 128 MB)
    modules : 0xbf000000 - 0xc0000000   (  16 MB)
      .text : 0x(ptrval) - 0x(ptrval)   (6774 kB)
      .init : 0x(ptrval) - 0x(ptrval)   ( 256 kB)
      .data : 0x(ptrval) - 0x(ptrval)   ( 350 kB)
       .bss : 0x(ptrval) - 0x(ptrval)   ( 153 kB)
SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
rcu: Preemptible hierarchical RCU implementation.
    Tasks RCU enabled.
NR_IRQS: 245
clocksource: timer0_1: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 79635851949 ns
sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 89478484971ns
Console: colour dummy device 80x30
Calibrating delay loop... 227.32 BogoMIPS (lpj=1136640)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
CPU: Testing write buffer coherency: ok
Setting up static identity map for 0xc0008400 - 0xc0008458
rcu: Hierarchical SRCU implementation.
devtmpfs: initialized
VFP support v0.3: not present
clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
futex hash table entries: 256 (order: -1, 3072 bytes)
pinctrl core: initialized pinctrl subsystem
NET: Registered protocol family 16
DMA: preallocated 256 KiB pool for atomic coherent allocations
cpuidle: using governor ladder
cpuidle: using governor menu
EMAC: MII PHY configured
mux: initialized GPIO3_12
mux: Setting register GPIO3_12
mux:    PINMUX7 (0x0000001c) = 0x10110110 -> 0x10118110
mux: initialized GPIO3_13
mux: Setting register GPIO3_13
mux:    PINMUX7 (0x0000001c) = 0x10118110 -> 0x10118810
mux: initialized GPIO2_4
mux: Setting register GPIO2_4
mux:    PINMUX6 (0x00000018) = 0x00000000 -> 0x00008000
mux: initialized GPIO6_13
mux: Setting register GPIO6_13
mux:    PINMUX13 (0x00000034) = 0x00000000 -> 0x00000800
mux: initialized EMA_WAIT_1
mux: Setting register EMA_WAIT_1
mux:    PINMUX6 (0x00000018) = 0x00008000 -> 0x01008000
da8xx_register_rproc: memory not reserved for DSP, not registering DSP device
omapl138_hawk_init: dsp/rproc registration failed: -12
edma edma.0: Legacy memcpy is enabled, things might not work
edma edma.0: TI EDMA DMA engine driver
edma edma.1: Legacy memcpy is enabled, things might not work
edma edma.1: TI EDMA DMA engine driver
SCSI subsystem initialized
media: Linux media interface: v0.10
videodev: Linux video capture interface: v2.00
pps_core: LinuxPPS API ver. 1 registered
pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
PTP clock support registered
Advanced Linux Sound Architecture Driver Initialized.
clocksource: Switched to clocksource timer0_1
NET: Registered protocol family 2
tcp_listen_portaddr_hash hash table entries: 512 (order: 0, 4096 bytes)
TCP established hash table entries: 1024 (order: 0, 4096 bytes)
TCP bind hash table entries: 1024 (order: 0, 4096 bytes)
TCP: Hash tables configured (established 1024 bind 1024)
UDP hash table entries: 256 (order: 0, 4096 bytes)
UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
NET: Registered protocol family 1
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
workingset: timestamp_bits=14 max_order=15 bucket_order=1
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 248)
io scheduler noop registered (default)
io scheduler mq-deadline registered
io scheduler kyber registered
Serial: 8250/16550 driver, 10 ports, IRQ sharing disabled
serial8250.0: ttyS0 at MMIO 0x1c42000 (irq = 25, base_baud = 14250000) is a 16550A
serial8250.1: ttyS1 at MMIO 0x1d0c000 (irq = 53, base_baud = 9375000) is a 16550A
serial8250.2: ttyS2 at MMIO 0x1d0d000 (irq = 61, base_baud = 9375000) is a 16550A
console [ttyS2] enabled
brd: module loaded
libphy: Fixed MDIO Bus: probed
davinci_mdio davinci_mdio.0: davinci mdio revision 1.5, bus freq 2200000
davinci_mdio davinci_mdio.0: detected phy mask ffffff7f
libphy: davinci_mdio.0: probed
davinci_mdio davinci_mdio.0: phy[7]: device davinci_mdio-0:07, driver SMSC LAN8710/LAN8720
i2c /dev entries driver
davinci-wdt davinci-wdt: heartbeat 60 sec
sdhci: Secure Digital Host Controller Interface driver
sdhci: Copyright(c) Pierre Ossman
davinci_mmc da830-mmc.0: Using DMA, 4-bit mode
sdhci-pltfm: SDHCI platform and OF driver helper
NET: Registered protocol family 10
Segment Routing with IPv6
sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
NET: Registered protocol family 17
console [netcon0] enabled
netconsole: network logging started
davinci_emac davinci_emac.1: using random MAC addr: fe:a3:81:2b:47:3e
hctosys: unable to open rtc device (rtc0)
ALSA device list:
  No soundcards found.
Waiting for root device /dev/mmcblk0p2...
random: fast init done

Have I not specified the correct configuration file in the build for my dev board?

Or is there something else potentially going on?

Ben

  • 0
    TI__Guru 50170 points

    Hi, Ben,

    When you built the kernel, did you use the defconfig file for omapl138-lcdk by following the instruction in PLSDK Kernel User's Guide. http://software-dl.ti.com/processor-sdk-linux/esd/docs/latest/linux/Foundational_Components_Kernel_Users_Guide.html  ?

    In the guide, it also has instruction on how to build the kernel. It confused me when you mention that you need to issue mkimage during the build. That is a bit of out of what I understand how it is usually built. 

    You didn't mention how you prepare the SD card and what did you do with the zImage you built. I have the impression that you just copied your built zImage to the SD card shipped with the dev kit, and the SD card is shipped with kernel v3.3. If that is the case, Kernel 4.19 won't work with Kernel 3.3 filesystem. 

    I suggest that you create a SD card (<plsdk6.3>/bin/create_sdcard.sh) using the prebuilt images in PLSDK 6.3 (Kernel 4.19.x). In this way, the SD card will be created using filesystem and kernel in PLSDK 6.3, Then replace the zImage with the one you built. It will work this way.  More info on SD card creation can be found in PLSDK Getting Started Guide, 

    software-dl.ti.com/.../Processor_SDK_Linux_create_SD_card_script.html

    If you insist of using kenrel 3.3 filesystem on the SD card shipped, you will need to rebuild all kernel modules and those modules in extra_drivers folder. The instruction of building modules is also in PLSDK kernel User's Guide which is provide above. You may run into other problems that some files may be missing in the older filesystem. You can find more info about why modules need to rebuild in 

    www.linuxjournal.com/.../kbuild-linux-kernel-build-system

    Hope these info help.

    Rex

     

  • 0 in reply to Rex Chang
    Expert 1825 points

    Hi Rex,

    The zImage being generated was placed into the boot partition of the SD card.

    I found that U Boot is not able to load this file type (it is rejected at boot up with an error message about the format) as it needs header information which is generated using the mkimage tool.

    My findings were that this use to be standard behavior when generating the kernel, but the tool chains have now depreciated generating an image ready for U Boot.

    I didn't even think about the file system being different between the two kernels (rather obvious now).

    I will go through the steps to generate the SD card image with kernel v4.19.x as this is what we will want to use going forward.

    Thanks!

    Ben

  • 0 in reply to Benjamin Michaud
    TI__Guru 50170 points

    Hi, Ben,

    There are 2 partitions on the SD card, boot and rootfs. The zImage you built should be copied onto the rootfs partition under /boot. I believe if the SD card is created using PLSDK 6.3, you will see a symbolic link from zImage to the real kernel binary. You can copy your zImage to this folder and name it my-kernel. then change the link so zIMage->my-kernel. It will boot from your kernel image. In case that the kernel image is a bad one which prevents you to revert the zImage link back to the prebuilt good image, you can mount the sd card to the Linux host to change it which I think is too many processes. I usually don't change the zImage symbolic link in /boot. I change u-boot env variable, name_kern. It is set to zImage, but I'll do "setenv name_kern my-kernel". Then it will boot using my-kernel image instead. If the kernel isn't good, you can always change it back to zImage and back to baseline.

    Yes, if you noticed, the /lib/modules has directory associated with kernel version. Different version won't be able to load modules from another version.

    When create sd card, use tisdk-server-rootfs filesystem. 

    Rex

  • 0 in reply to Rex Chang
    Expert 1825 points

    Thanks for the help Rex.

    I was able to build the kernel, keep it as zImage, and place it in the boot folder for execution (which booted successfully now).

    The issue was that U Boot was booting from NAND prior, and was the older version of U Boot which I'm guessing was configured differently.

    Now U Boot is being booted from the SD card, which is the newer version of U Boot that was available with the SDK.

    I basically had a mismatch of a few different versions of software and file system which lead to the issues.

    Thanks again for the help.

    Ben