Search

Technical Discussion Group Forum

This forum is provided for user discussion. While Beacon EmbeddedWorks support staff and engineers participate, Beacon EmbeddedWorks does not guarantee the accuracy of all information within in the Technical Discussion Group (TDG).

The "Articles" forums provide brief Articles written by Beacon EmbeddedWorks engineers that address the most frequently asked technical questions.

To receive email notifications when updates are posted for a Beacon EmbeddedWorks product download, please subscribe to the TDG Forum of interest.

TDG Forum

PrevPrev Go to previous topic
NextNext Go to next topic
Last Post 11 Jul 2016 08:17 AM by  Ryan Crowell
Intermittent freeze after "Starting kernel ..." at boot
 6 Replies
Sort:
You are not authorized to post a reply.
Author Messages
Ryan Crowell
New Member
New Member
Posts:15


--
30 Jun 2016 03:19 PM

    Here's the summary:

    We are using the SOMDM3730-32-1880AKIR in a Linux-based design and are having intermittent problems during the boot sequence.  Occasionally (infrequently - perhaps 1 out of 100 boot cycles) the system hangs right when u-boot should be handing control over to the Linux kernel.  No further console output is seen and the system never recovers on its own.  We know that the last few lines of u-boot code are executed, displaying "Starting kernel ...", right up to the call to kernel_entry().  After that, when the system freezes, we get no further output, including the "Linux version" message which is usually sent very early on during kernel boot.  We have seen identical behavior with multiple SOMs and on multiple carrier boards, including on the Logic PD development board.  Most of the time the system boots up fine; it's only occasionally that we see this behavior, and we see it after either a hard power cycle or a soft "reboot" command from the Linux prompt.

    Has anybody else seen this behavior?  Even though the problem is infrequent, we can't deliver a product that may fail to boot properly every so often!  I would greatly appreciate any suggestions!

    Some further details:

    We're using the following board support package: 1024334_LogicPD_Linux_BSP_2.4-2

    We have a custom compiled kernel, but haven't changed anything that should be significant.  Mostly, we've removed drivers for hardware that we know won't be used with our design.

    We have customized the network config and included applications, but when the system hangs it does so well before any network configuration or application code gets executed.

    We have set the u-boot environment variables as follows:

    otherbootargs has been appended with the ip= text to set our IP address, etc.

    bootdelay has been set to 0 for faster startup.

    We have used the u-boot command "run makenandboot" to prepare the system for booting from NAND FLASH.

    We have verified that, when the system hangs, kernel_entry points to the correct memory address (0x80008000) and that first 1024 bytes of data located at that address in RAM match the data at the same location during a successful startup.

    Thanks in advance for any help!

    Ryan

    Adam Ford
    Advanced Member
    Advanced Member
    Posts:794


    --
    30 Jun 2016 03:24 PM
    Are you able to reproduce this issue on the LPD Baseboard?

    Could you post the log so I can see it?

    adam
    Ryan Crowell
    New Member
    New Member
    Posts:15


    --
    30 Jun 2016 04:09 PM

    Hi Adam,

    Yes, this happens on the LPD Baseboard.  By log, I assume you mean the console output.  Here it is:

     

    Texas Instruments X-Loader 1.42 BSP-dm37x-2.4-2 for dm3730logic (2016-05-20 15:15:36)
    DRAM: 256MB (ProductID defined)
    Booting from NAND
    NAND: in-chip ECC
    SgnP image: 0x6f1f8 bytes read from NAND at offset 0x80000 to 80400000


    U-Boot 2011.06 BSP-dm37x-2.4-2 (Jun 30 2016 - 13:27:12)

    OMAP3630/3730-GP ES2.1, CPU-OPP2, L3-200MHz, Max CPU Clock 1 Ghz
    Logic DM37x/OMAP35x reference board + LPDDR/NAND
    I2C:   ready
    DRAM:  256 MiB
    Board: DM37xx Torpedo
    Enable battery backup charger (BB_CFG = 0x1c)
    NAND:  512 MiB
    NAND: Internal to NAND ECC selected
    Found '15' display panel
    In:    serial
    Out:   serial
    Err:   serial
    Product ID data cached to: 40200000
    Die ID #435200029ff800000168301019010008
    OTG_SYSCONFIG: 00001008 - needs to be 00002001

    ID data ROM  : Gen 2
    Model        : dm3730 Torpedo
    Version Code : -30
    Temp Grade   : Commercial
    Max Speed    : 1000MHz
    Part Number  : 1021711
    Model Name   : SOMDM3730-30-2780AKCR-B
    Serial Number: 3312M00809

    Data (writethrough) Cache is ON
    Net:   smc911x-0
    Hit any key to stop autoboot:  0

    == Checking mmc1 for alternate boot script boot.scr ==
    No MMC card found
    kernel_location: nand-part, rootfs_location: nand-part, rootfs_type: ramdisk

    == Loading kernel from nand partition kernel to 0x81000000 ==

    Loading from nand0, offset 0x280000
       Image Name:   Linux-3.0.0-BSP-dm37x-2.4-2
       Image Type:   ARM Linux Kernel Image (uncompressed)
       Data Size:    3395536 Bytes = 3.2 MiB
       Load Address: 80008000
       Entry Point:  80008000

    == Loading rootfs from nand partition ramdisk to 0x82000000 ==

    NAND read: device 0 offset 0x780000, size 0x1400000
     20971520 bytes read: OK

    == Kernel bootargs ==
    nand-ecc=chip console=ttyO0,115200n8 display=15 ignore_loglevel early_printk no_console_suspend ip=192.168.6.99::192.168.6.1:255.255.255.0:UGLY_99:: mtdparts=omap2-nand.0:512k(x-loader),1664k(u-boot),384k(u-boot-env),5m(kernel),20m(ramdisk),-(fs) root=/dev/ram rw ramdisk_size=64000

    bootm 0x81000000 0x82000000

    ## Booting kernel from Legacy Image at 81000000 ...
       Image Name:   Linux-3.0.0-BSP-dm37x-2.4-2
       Image Type:   ARM Linux Kernel Image (uncompressed)
       Data Size:    3395536 Bytes = 3.2 MiB
       Load Address: 80008000
       Entry Point:  80008000
       Verifying Checksum ... OK
    ## Loading init Ramdisk from Legacy Image at 82000000 ...
       Image Name:   uboot ext2 ramdisk rootfs
       Image Type:   ARM Linux RAMDisk Image (gzip compressed)
       Data Size:    9701561 Bytes = 9.3 MiB
       Load Address: 00000000
       Entry Point:  00000000
       Verifying Checksum ... OK
       Loading Kernel Image ... OK
    OK

    Starting kernel ...

    (After that, nothing.)

     

    Adam Ford
    Advanced Member
    Advanced Member
    Posts:794


    --
    05 Jul 2016 09:46 AM
    Have you made any changes to U-Boot? The 2.4-2 had some L2 caching issues which were fixed in 2.4-4. If you're enabling the L2 cache and trying to to initialize the LCD, it may cause issues.

    adam
    Ryan Crowell
    New Member
    New Member
    Posts:15


    --
    08 Jul 2016 02:03 PM
    We have updated our BSP to 2.4-4 and the problems seem to have gone away. We will perform further testing over the next week to verify, but initial indications are that the bug has been fixed.

    Thanks for your help, Adam.
    Adam Ford
    Advanced Member
    Advanced Member
    Posts:794


    --
    08 Jul 2016 02:17 PM
    I am glad it worked out for you. the 2.4-4 U-Boot caching will really help any floating point math using the NEON instruction. We found the benchmarks increased 3x.

    If you are booting from SD card, the U-boot SD driver is 9x faster than previously used.

    You should be able to use the U-Boot from 2.4-4 with the older Linux kernel if you've made a bunch of changes to the kernel that you don't want to port forward.

    adam
    Ryan Crowell
    New Member
    New Member
    Posts:15


    --
    11 Jul 2016 08:17 AM
    We have developed a few kernel drivers, but they ported over to 2.4-4 without any difficulty, so we've simply switched to the current BSP.

    Strangely, however, we actually had tried using the 2.4-4 U-Boot with the older BSP (kernel and all) without any luck. We still had the periodic startup failure in that setup. (We used the version of U-Boot in the Linux SD card image from the LogicPD website, rather than from our own compilation based on the 2.4-4 BSP.)

    It was only when we switched over to 2.4-4 entirely that the problems went away.
    You are not authorized to post a reply.