• State TI Thinks Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 1 answer
  • Subscribers 100 subscribers
  • Views 2169 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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/DRA750: J6 boot up stucking in kernel

Ren Bowei
Intellectual 650 points
Part Number: DRA750
Other Parts Discussed in Thread: DRA752

Tool/software: Linux

We have custom daughter board  + custom  DRA752 CPU module board  with  uboot  2014.07  in glsdk 7.03.00.00.3 , but some our CPU modules which  filter out by our MP line  are bad.

Because those CPU modules  can not boot up successfully ,  stucking in "starting kernel ..." during boot up, the log as below:

U-Boot 2014.07 (Apr 26 2017 - 16:16:36)

CPU  : DRA752-GP ES2.0
Board: DRA7xx
I2C:   ready
DRAM:  2 GiB
MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1, OMAP SD/MMC: 2
Using default environment

serial# not set, setting...
SATA link 0 timeout.
AHCI 0001.0300 32 slots 1 ports 3 Gbps 0x1 impl SATA mode
flags: 64bit ncq stag pm led clo only pmp pio slum part ccc apst 
scanning bus for devices...
Found 0 device(s).
SCSI:  Net:   Phy not found
cpsw
Hit any key to stop autoboot:  0 
J6 ...
Card did not respond to voltage select!
Card did not respond to voltage select!
switch to partitions #0, OK
mmc1(part 0) is current device
SD/MMC found on device 1
reading j6_uenv.txt
206 bytes read in 3 ms (66.4 KiB/s)
Loaded environment from j6_uenv.txt
Importing environment from mmc1 ...
5178640 bytes read in 121 ms (40.8 MiB/s)
101700 bytes read in 8 ms (12.1 MiB/s)
Booting from mmc1 ...
Kernel image @ 0x82000000 [ 0x000000 - 0x4f0510 ]
## Flattened Device Tree blob at 88000000
   Booting using the fdt blob at 0x88000000
   Loading Device Tree to 8ffe4000, end 8ffffd43 ... OK

Starting kernel ...

Could you give us some direction to debug it ?  ( it should be h/w issue , but we want to know which part is NG  )

BTW, I have increased debug level (loglevel=8) in the j6_uenv.txt.

Best Regards,

Bowei Ren

  • 0
    TI__Expert 4885 points

    Hi, Bowei,

    This thread is the same as:

    I will close it, please, do not start several threads on the same topic.

    Regards,

    Mariya

  • 0 in reply to Mariya Petkova
    Intellectual 650 points
    Dear Mariya,

    Maybe they are different. One is stucking in "starting kernel" and the other is kernel panic.
    So they are different, right?

    Best Regards,
    Bowei Ren
  • 0 in reply to Ren Bowei
    TI__Mastermind 42515 points
    Hi Bowei,

    the description in both thread looks the same but in one case you get kernel panic and in the other you get stuck after "Starting kernel ...".

    Can you clarify what is the difference in your setup when you get different errors?

    Regards,
    Yordan
  • 0 in reply to Yordan Kamenov
    Intellectual 650 points
    Dear Yordan,

    The setup is the same. These two CPU modules are filter out form our production line. So we would like to know what happened on this CPU module.
    Could you give me some direction to debug it? or where we need to add debug messages?

    Best Regards,
    Bowei Ren
  • 0 in reply to Ren Bowei
    TI__Expert 4230 points

    Hi Bowei,

    Usually a wrong dtb results in Boot stuck at "Starting Kernel.." but as you might be using same SW setup across all boards I doubt it's a different issue.

    There are a couple of way to check what's going on

    1. Connecting a debugger if JTAG is available - CCS or Lauterbach

    2. Use the log_buf, kernel prints are stored in a location pointed by "__log_buf" the address can be found in "System.map" file in the kernel build directory.

    • Once you have the address, you can reset the board and stop at u-boot
    • Dump the memory contents at the location pointed by __log_buf, convert the virt address to phys , usually it's 0xc*** just change this to 0x8**** , then using "md 0x<phys address> #objects"  you can read the contents.
    • for example if the __log_buf address is 0xcda00000 then dump "md 0x8da00000 0x1000"

    Regards,

    RK

  • 0 in reply to Ravikumar Kattekola
    Intellectual 650 points

    Hi RK,

    First, thank you for your support.

    But could you describe more detail? or could you share relative document to me?

    1. Where I need to print "log_buf"?

    2. The contents are address or not in "System.map"? (The System.map fragment as below)

    00000000 t __vectors_start
00000018 A cpu_v6_suspend_size
00000024 A cpu_v7_suspend_size
00001000 t __stubs_start
00001004 t vector_rst
00001020 t vector_irq
000010a0 t vector_dabt
00001120 t vector_pabt
000011a0 t vector_und
00001220 t vector_addrexcptn
00001224 t vector_fiq
00001224 T vector_fiq_offset
c0004000 A swapper_pg_dir
c0008000 T _text
c0008000 T stext
c0008084 t __create_page_tables
c0008130 t __turn_mmu_on_loc
c000813c t __fixup_pv_table
c000818c t __vet_atags
c0008200 T __exception_text_start
c0008200 T _stext
c0008200 T asm_do_IRQ
c0008214 T do_undefinstr
c0008384 T do_IPI
c0008398 T do_DataAbort
c0008434 T do_PrefetchAbort
c00084d0 T omap2_intc_handle_irq
c0008574 T omap3_intc_handle_irq
c0008618 t gic_handle_irq
c000867c T __exception_text_end

    3. What is the parameter "#objects"? How do I know the correct value of "#objects"?

    Many thanks for you help!

    Best Regards,

    Bowei

  • 0 in reply to Ren Bowei
    TI__Expert 4230 points

    Hi Bowei,

     I just remembered that Method 2 may not directly work on DRA75x as all resets are re-routed to cold reset which erases DDR.

    But you can read the __log_buf contents using CCS without resetting the board.

    DId you not find "__log_buf" in your System.map file? See below sample from my System.map file.

    c0996438 b exclusive_console
c099643c b text.34688
c099683c b __log_buf
c09b6840 b syslog_seq
c09b6848 b syslog_idx

    Once CCS is connected , open memory browser and enter the address "0x<log_buf address>" to view the contents.

    Regards,

    RK

  • 0 in reply to Ravikumar Kattekola
    Intellectual 650 points

    Hi RK,

    I found out the __log_buf contents in my System.map

    c0a5c47c b syslog_prev
c0a5c480 b syslog_partial
c0a5c484 b __log_buf
c0a6c484 b always_kmsg_dump
c0a6c488 b dump_stack_arch_desc_str

    And I dumped the value of __log_buf address, they are different.

    The value is "D09E56FC" on working board, but we got the value is "00000000" on non-working board.

    From the above information, what conclusions can be drawn? Do you have any idea that is failed in CPU module or SoC?

    Best Regards,

    Bowei

  • 0 in reply to Ren Bowei
    TI__Expert 4230 points
    Hi Bowei,
    It's start poin of a ring buffer. Not just one value but it can hold upto 128K bytes of data.
    If you dump next 4K bytes starting from __log_buf you should be able to see the kernel prints that were queued to be printed out to console at a later point of time.


    Regards,
    RK