• State
  • Locked Locked
  • Replies 9 replies
  • Subscribers 98 subscribers
  • Views 1091 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.

No UART Ouput after Uncompressing on OMAPL138

Daniel Wayer
Intellectual 385 points
Other Parts Discussed in Thread: OMAPL138

I was successfully able to boot Linux on an OMAPL138 on a custom board using the TI MCSDK.

Now I am trying to upgrade to the latest davinci kernel (from https://git.kernel.org/cgit/linux/kernel/git/nsekhar/linux-davinci.git version 3.19.0-rc5) instead of the one from the MCSDK but I get no output on the uart after "Uncompressing LInux... done, booting the kernel."

In the kernel souce i have changed;

  1. in /arch/arm/mach-davinci
    1. added the board file i was using in the mcsdk, and edited said board file to work build with this kernel
  2. /arch/arm/mach-davinci/include/mach/uncompress.h
    1. added my custom board and have it using UART0 (which is the one i need it to use)
  3. /arch/arm/mach-davinci/include/mach/psc.h
    1. added 1 line from the mcsdk
  4. /arch/arm/mach-davinci/include/mach/mux.h
    1. used the davinci_da850_index_enum from the mcsdk instead of what was there
  5. /arch/arm/tools/mach-types
    1. added my board and gave it a machine type and had it mach uboot
  6. /arch/arm/mach-davinci/Kconfig
    1. added a config to select my custom board board in menuconfig
  7. /arch/arm/mach-davinci/Makefile
    1. added my custom board to the make file
  8. /arch/arm/mach-davinci/Makefile.boot
    1. changed the boot params to match my board and used the settings i was using in mcsdk

As a note, i have already tried to turn on CONFIG_DEBUG_LL via menuconfig. After I did this i got an error that said i have the wrong machine code, which i have since fixed and am now seeing just Uncompressing Linux.... done, booting the Kernel".

I have also tried changing my uboot bootargs from ....console=ttyS0,115200n8... to ....console=uart,io,0xe1020000,115200n8.... and got the same result.

How can I get more output/debug messages on UART0 to find out whats going on?

Thanks,

Dan

  • 0
    TI__Guru** 116100 points
    Hi Daniel,
    What EVM board you have ?
    Say OMAPL138 LCDK, OMAPL138 SDI EVM, LogicPD EVM ?
    Able to port latest linux kernel (3.19) on TI EVM ?
    Try to port latest linux first in TI EVM then try with your custom.
    I believe it is very simple step porting to latest linux for EVM board.
    I've done already linux 3.14 for OMAPL138 LCDK board.
  • 0 in reply to Titusrathinaraj Stalin
    Intellectual 385 points

    OK, I have an OMAPL138 LCDK i will try with...

    When you ported 3.14 to the LCDK board were you using uboot from the MCSDK or a newer version?

    Also, which board file did you use as a base for using the LCDK? da850-evm? mityomal138?

    Thanks,
    dan

  • 0 in reply to Daniel Wayer
    TI__Guru** 116100 points
    Hi Daniel,
    It was about 2 months ago.
    I used MCSDK u-boot only, it doesn't matter though.
    Forgot which board file had used, I hope, you can use "mityomapl138" since it was similar to LCDK board.
    P.S: LCDK board using the memory as DDR2 and other boards using the mDDR.
  • 0 in reply to Titusrathinaraj Stalin
    Intellectual 385 points

    I was able to get the kernel booted on the LCDK, however i still have no clues about getting uart output on my custom board.

    Why is there no menuconfig to support low level debugging on uart 0, I should have mentioned that i need to use uart0. Can i add this to one of the the kconfigs? If so which one.

    Because uart0 is usually not used for kernel uncompresing as you can see in uncompress.h I'm thinking i have missed a configuration.

  • 0 in reply to Daniel Wayer
    TI__Guru** 116100 points
    Yes, you can also add it for UART0 by looking into Kconfig and Makefile.
    I hope it is not used since it is muxed with MII (ethernet).
  • 0 in reply to Titusrathinaraj Stalin
    Intellectual 385 points

    I have made ZERO progress here. I can see no output after "Uncompressing Linux....done, booting the kernel".

    Is there a way via Jtag connection that i can debug or assembly step through the head.S files and see where the Kernel is crashing? Or another way to get more prints from the head.S file?

  • 0 in reply to Daniel Wayer
    TI__Guru** 116100 points
    Hi Daniel,
    Yes, you can debug the kernel through debugger/emulator.

    Please verify that you have given correct u-boot's boot parameters.

    processors.wiki.ti.com/.../Linux_Debug_in_CCSv5

    e2e.ti.com/.../347096
  • 0 in reply to Daniel Wayer
    TI__Guru** 116100 points
    Do you have any other driver modification in your custom kernel?
    What are the drivers ?
    Because it is booting fine with LCDK board right ?

    Could you comment out it everything and see since it is not important rather than booting.
  • 0 in reply to Titusrathinaraj Stalin
    Intellectual 385 points

    I will try this link,  , because the other one provided assumes we can boot the kernel which is not the case.

    As far as commenting out everything from my custom kernel... there is hardly any custom code. All i have done is added my board configuration to the kernel, i have not added any drivers.

    One thing i have tried, recompiled uboot using the mach ID of the LCDK and programmed to my custom board. This would tell the kernel running on the custom board that it is an LCDK and should boot the same as the LCDK, and should rule out any problems with my custom board file. It produced the same result and I had no output after .... done booting the kernel. I have tried this on both UART0 and UART2 just to be sure.

    The situation to boot linux on the custom board is very simple. The DSP is up and running, with all interrupts disabled, ubl runs on the PRU and loads uboot, the kernel (uImage) and the filesystem ramdisk from SPI flash into DDR. After it has done this and and verified the reads it jumps to uboot execution which does very little setup of pinmuxes, then jumps to the kernel address and decompression begins... Everything is already in DDR ram. I can stop with the debugger and see the images at their addresses, at least their headers in ascii. This is all working on the PSP release provided in the mcsdk which uses kernel version 3.11.0-15, which tells me the uboot arguments must be OK. Do you have any other thoughts?

    Thanks,

    Dan