• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Subscribers 102 subscribers
  • Views 2553 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.

PROCESSOR-SDK-AM335X: AM335X kernel hangs at "starting kernel..." during booting

lance lee
Prodigy 190 points
Part Number: PROCESSOR-SDK-AM335X

I met a kernel booting issue during porting SDK06.03 on AM335X platform,  the u-boot-2019.01 works fine and can boot 3.14 kernel which I used before ( SDK8.0) , but when booting 4.19 kernel it hangs at "Starting kernel...", below are the boot logs on the console port with the two kernels, I have checked dts and configuration file and no obvious error was found, please give some suggestions for this issue, thanks! 

=======kernel 4.19 boot failure logs=============

Booting from nand ...

NAND read: device 0 offset 0x100000, size 0x40000
262144 bytes read: OK

NAND read: device 0 offset 0x2c0000, size 0x800000
8388608 bytes read: OK
## Flattened Device Tree blob at 80f80000
Booting using the fdt blob at 0x80f80000
Loading Device Tree to 9def7000, end 9df036e2 ... OK

Starting kernel ...

 

=======kernel 3.14 boot success logs=============

Booting from nand ...

NAND read: device 0 offset 0x100000, size 0x40000
262144 bytes read: OK

NAND read: device 0 offset 0x2c0000, size 0x800000
8388608 bytes read: OK
## Flattened Device Tree blob at 80f80000
Booting using the fdt blob at 0x80f80000
Loading Device Tree to 9def8000, end 9df03b35 ... OK

Starting kernel ...

[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 3.14.79 (lance@lance-virtual-machine) (gcc version 4.7.3 20130226 (prerelease) (crosstool-NG linaro-1.13.1-4.7-2013.03-20130313 - Linaro GCC 2013.03) ) #75 Sat Aug 17 13:55:45 HKT 2019
[ 0.000000] @IMMU kernel version V1.01T05 with LCD Power control
[ 0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c5387d
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[ 0.000000] Machine model: TI AM335x EVM
[ 0.000000] cma: CMA: reserved 24 MiB at 9e000000
[ 0.000000] Memory policy: Data cache writeback
[ 0.000000] CPU: All CPU(s) started in SVC mode.
[ 0.000000] AM335X ES2.1 (sgx neon )
[ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 129792
[ 0.000000] Kernel command line: console=ttyO0,115200n8 consoleblank=0 vt.global_cursor_default=0 root=ubi0:rootfs rw ubi.mtd=NAND.file-system,4096 rootfstype=ubifs rootwait=1
[ 0.000000] PID hash table entries: 2048 (order: 1, 8192 bytes)
[ 0.000000] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
[ 0.000000] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)

......

  • 0
    TI__Guru 60205 points

    Hi Lance,
    The u-boot log looks good to me.
    Is JTAG debugger accessible on your board?
    If yes, we can run a simple test on kernel boot-up process with help of JTAG debugger:
    - stop @u-boot prompt
    - "attach" JTAG to the board, "attach" is non-intrusive, or no power cycle of the running board
    - set-up two (HW)breakpoints at 0x82000000, 0x80008000
    - run "boot" @u-boot prompt
    - if the 1st bkpt @0x82000000 is hit, => u-boot loading zImage is ok
    - if the 2nd bkpt @0x80008000 is hit, => kernel decompression is ok. kernel is ready to run...
    I'm attaching a note on u-boot loading kernel start process for your reference.

    If the above mentioned 2nd bkpt is hit, one common scenario causing the issue "Starting kernel ..." is mismatch between kernel DT with the board.
    Some options for debug further:
    - minimize your kernel DT to bare-minimum to get kernel up-running, and then add-back "removed" device nodes.
    - use JTAG to debug what/how kernel start process lock-up is triggered...

    Best,

    -Hong

    4786.u-boot_kernel.pdf

  • 0
    Prodigy 190 points

    Hi Hong，

    Thanks，the kernel could boot-up when I disabled the RTC. but now the Nand Flash could not be probed correctly. Is there any error for the nand node in dts file:

    &gpmc {
     status = "okay";
     pinctrl-names = "default";
     pinctrl-0 = <&nandflash_pins>;
     ranges = <0 0 0x08000000 0x10000000>;
     nand@0,0 {
      compatible = "ti,omap2-nand";
      reg = <0 0 0>; /* CS0, offset 0 */
      interrupt-parent = <&gpmc>;
      interrupts = <0 IRQ_TYPE_NONE>, /* fifoevent */
            <1 IRQ_TYPE_NONE>; /* termcount */
      ti,nand-xfer-type = "prefetch-dma";
      ti,nand-ecc-opt = "bch16";
      ti,elm-id = <&elm>;
      nand-bus-width = <8>;
      gpmc,device-width = <1>;
      gpmc,sync-clk-ps = <0>;
      gpmc,cs-on-ns = <0>;
      gpmc,cs-rd-off-ns = <44>;
      gpmc,cs-wr-off-ns = <44>;
      gpmc,adv-on-ns = <6>;
      gpmc,adv-rd-off-ns = <34>;
      gpmc,adv-wr-off-ns = <44>;
      gpmc,we-on-ns = <0>;
      gpmc,we-off-ns = <40>;
      gpmc,oe-on-ns = <0>;
      gpmc,oe-off-ns = <54>;
      gpmc,access-ns = <64>;
      gpmc,rd-cycle-ns = <82>;
      gpmc,wr-cycle-ns = <82>;
      gpmc,wait-on-read = "true";
      gpmc,wait-on-write = "true";
      gpmc,bus-turnaround-ns = <0>;
      gpmc,cycle2cycle-delay-ns = <0>;
      gpmc,clk-activation-ns = <0>;
      gpmc,wait-monitoring-ns = <0>;
      gpmc,wr-access-ns = <40>;
      gpmc,wr-data-mux-bus-ns = <0>;
      /* MTD partition table */
      /* All SPL-* partitions are sized to minimal length
       * which can be independently programmable. For
       * NAND flash this is equal to size of erase-block */
      #address-cells = <1>;
      #size-cells = <1>;
        partition@0 {
         label = "NAND.SPL";
         reg = <0x00000000 0x000040000>;
        };
        partition@1 {
         label = "NAND.SPL.backup1";
         reg = <0x00040000 0x00040000>;
        };
        partition@2 {
         label = "NAND.SPL.backup2";
         reg = <0x00080000 0x00040000>;
        };
        partition@3 {
         label = "NAND.SPL.backup3";
         reg = <0x000C0000 0x00040000>;
        };
        partition@4 {
         label = "NAND.u-boot-spl-os";
         reg = <0x00100000 0x00040000>;
        };
        partition@5 {
         label = "NAND.u-boot";
         reg = <0x00140000 0x00100000>;
        };
        partition@6 {
         label = "NAND.u-boot-env";
         reg = <0x00240000 0x00040000>;
        };
        partition@7 {
         label = "NAND.u-boot-env.backup1";
         reg = <0x00280000 0x00040000>;
        };
        partition@8 {
         label = "NAND.kernel";
         reg = <0x002C0000 0x00800000>;
        };
        partition@9 {
         label = "NAND.file-system";
         reg = <0x00AC0000 0x1c200000>;  //FS: 450M
        };
        partition@10 {
         label = "NAND.data";
         reg = <0x1ccc0000 0x1f400000>;  //data: 500M
        };
        partition@11 {
         label = "NAND.syslog";
         reg = <0x3C0C0000 0x2700000>;  //syslogo: 39.25M
        };
            };
    };
  • 0 in reply to lance lee
    TI__Guru 60205 points

    Hi Lance,
    Thanks for your update that the kernel starts to boot up...on your board.
    From your original post, my understanding is you're able to boot u-boot from NAND...
    If this is the case, have you compared the "working" u-boot dts node for NAND "&gpmc" vs the "non-working" kernel one?
    Additionally, check the kernel dts node for "&nandflash_pins_s0" for NAND PINMUX.
    Best,
    -Hong

  • 0 in reply to Hong Guan64
    Prodigy 190 points

    Hi Hong，

    Sorry for late reply, now I can boot up the system with new kernel, thanks. 

    But I met a LCD driver issue with the new kernel when I use legacy LCDC fbdev display driver, below is the error log during the driver probe, can you give some comments about this issue, thanks.:

    " lcdc@4830e000 : Can not get platform data "

        

  • 0 in reply to lance lee
    TI__Guru 60205 points

    Hi Lance,
    Thanks for your update that the kernel boots up on your board.
    Have you looked at kernel LCD driver note?
    software-dl.ti.com/.../LCDC.html
    "Legacy AM335x LCDC fbdev Display Driver
    This driver is currently obsolete (has been since ti-linux-3.14.y), and is not actively maintained any more.
    Please use LCDC DRM driver instead."
    Best,
    -Hong

  • 0 in reply to Hong Guan64
    Prodigy 190 points

    Hi Hong，

    I have used the LCDC DRM driver. Just want to test the legacy LCDC fbdev driver on the 4.19 new kernel for I used this driver on SDK8( 3.14 kernel) before. now I understand this, thanks.

    by the way, I found the new 8250 serial driver in 4.19 kernel did not support RS485 function(Transceiver pin control),  the legacy OMAP serial driver can supprot RS485 function, I don`t konw why the two drivers are different for user, is this issue caused by incorrect kernel configuration or ...?

  • 0 in reply to lance lee
    TI__Guru 60205 points

    Hi Lance,
    I'll loop in my colleague on kernel, and he will respond on your new inquire on the new 8250 serial driver in 4.19 kernel...
    Best,
    -Hong

  • 0 in reply to lance lee
    TI__Guru*** 140686 points

    Hi Lance,

    lance lee said:
    by the way, I found the new 8250 serial driver in 4.19 kernel did not support RS485 function(Transceiver pin control),  the legacy OMAP serial driver can supprot RS485 function, I don`t konw why the two drivers are different for user, is this issue caused by incorrect kernel configuration or ...?

    The Legacy OMAP Serial driver is not longer maintained in newer kernels, the development has been moved to the new 8250 OMAP driver. It should support RS485 DE pin control. Can you please provide details if it doesn't work in your project?

  • 0 in reply to Bin Liu
    Prodigy 190 points

    Hi Bin,

    Below are the two RS485 UARTs DT I used in in 4.19 kernel(both RS485 work ok with this DT in 3.14 kernel ),  the two RS485 ports can not work when used 8250 OMAP driver and work ok when legacy OMAP Serial driver was used. I measure the 485 control pin waveform it always keep high voltage. 

    &uart1 {
    pinctrl-names = "default";
    pinctrl-0 = <&uart1_pins>;
    rs485-rts-active-high;
    rs485-rts-delay = <3 60>;
    rts-gpio = <&gpio3 18 GPIO_ACTIVE_HIGH>;
    linux,rs485-enabled-at-boot-time;
    status = "okay";
    };

    &uart4 {
    pinctrl-names = "default";
    pinctrl-0 = <&uart4_pins>;
    rs485-rts-active-high;
    rs485-rts-delay = <3 60>;
    rts-gpio = <&gpio3 19 GPIO_ACTIVE_HIGH>;
    linux,rs485-enabled-at-boot-time;
    status = "okay";
    };

  • +1 in reply to lance lee
    TI__Guru*** 140686 points

    Hi Lance,

    The 8250 OMAP driver in kernel v4.19 supports native RTS controlling RS485 DE, but not GPIO based RTS.

    Please use the kernel patch set (8250-rts-gpio-support-4.19.zip) in the e2e link below to add GPIO based RTS controlling RS485 DE.

    https://e2e.ti.com/support/processors/f/processors-forum/984506/am3354-strange-behavior-of-uart-with-omap-8250-serial-driver/3647726#3647726

    Please also note that rs485-rts-active-high and rs485-rts-delay are OMAP Serial driver specific DT bindings, which will not work with 8250 OMAP driver. Please set these attributes in your user space application when configuring the UART port RS485 config.