• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Subscribers 101 subscribers
  • Views 1627 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.

AM5K2E fails to boot Keystone-Linux kernel from DDR

Samuel Smith
Intellectual 300 points

Ti,

My team has a custom board based on the K2E EVM, with a AM5K2E chip and changes to DDR3, and some other peripherals.

I have followed the wiki at http://processors.wiki.ti.com/index.php/MCSDK_UG_Chapter_Exploring/  and been successful at compiling the keystone-linux boot monitor, linux kernel, and u-boot. I compiled each using the "k2e" evm configs, but had to make changes in u-boot for DDR3 register settings.

I am doing this all manually instead of using the MCSDK Linux images because of the peripheral changes.

I boot a two stage u-boot from SPI Flash successfully. Then I run the following commands to try and boot Linux, but it no output appears:

  • tftp 82000000 arago-console-image.cpio.gz
  • tftp 88000000 uImage
  • tftp 87000000 k2e-evm.dtb
  • tftp 0c140000 skern-k2e.bin
  • mon_install 0c140000
  • setenv bootargs 'console=ttyS0,115200n8 rootwait=1 earlyprintk rdinit=/sbin/init rw root=/dev/ram0 initrd=0x802000000,9M'
  • bootm 88000000 - 87000000

Then u-boot runs its startup and finally prints "Starting Kernel ..." but nothing else prints out after that. How do I fix this?

Currently, NAND is not working on the board, so I have to do this just using MSMC and DDR.

Questions:

  1. I built u-boot using a branch of keystone-linux/u-boot called upstream/k2e_net (not master) for its legacy ethernet init. Is there a compatibility issue between this branch of u-boot and keystone-linux/linux?
  2. Our core clock is 100MHz. Do I need to make any changes to the Linux configs to reflect this?
  3. I built Linux from the master branch of keystone-linux/linux using make 'keystone2_defconfig' and 'make uImage' with no source changes. Is that correct?
  4. I made no changes to keystone-linux/boot-monitor and built using 'make k2e'. Is that correct?
  5. Your documentation uses 0x0c5f0000 for the boot monitor location, but that fails and 0c140000 seems to be the location for the k2e. Is that correct?
  6. Are my UART console settings messed up somehow?
  7. Do I need to make my own filesystem instead of using the canned image arago-console-image.cpio.gz from the mcsdk-linux project? (It's from 2013, and possibly outdated)

  • 0
    TI__Guru* 81335 points
    1. We recommend you to use tag mentioned in the release notes of the latest MCSDK/Processor SDK for building uboot, Linux and boot monitor.

    2 & 3. Any changes from EVM may need source update and rebuilding accordingly.

    4 & 5. I don't think you need to update boot monitor for your case. Let me check with and get back.

    6. As per my understanding u-boot console works for you. So need to check questions 2 & 3.

    7. Filesystem may not be the issue.

    Thanks.
  • 0
    TI__Guru** 116100 points

       tftp 82000000 arago-console-image.cpio.gz

       tftp 88000000 uImage

       tftp 87000000 k2e-evm.dtb

       tftp 0c140000 skern-k2e.bin

       mon_install 0c140000

       setenv bootargs 'console=ttyS0,115200n8 rootwait=1 earlyprintk rdinit=/sbin/init rw root=/dev/ram0 initrd=0x802000000,9M'

       bootm 88000000 - 87000000

    It seems you have used different DDR address in bootargs and filesystem images loaded location.

    Have you tried any other boot method ?

    NAND or NFS or SPI ?

    We need to make sure that kernel is built correctly for custom board.

  • 0 in reply to Titusrathinaraj Stalin
    Intellectual 300 points

    Understood. I will make sure initrd matches where I put the arago-console-image.

    The wiki shows sample output from the boot monitor and kernel as printing the following:

    Starting kernel ...
    >>>> skern_poweron_cpu >>>>
    Message2 from Secure Mode
    >>>> skern_poweron_cpu >>>>
    Message2 from Secure Mode
    >>>> skern_poweron_cpu >>>>
    Message2 from Secure Mode
    [ 0.000000] Booting Linux on physical CPU 0
    [ 0.000000] Linux version 3.6.6-rt17-01071-g898535d-dirty (a0868495@ares-ubun
    tu.am.dhcp.ti.com) (gcc version 4.7.2 20120701 (prerelease) (crosstool-NG linaro
    -1.13.1-2012.07-20120720 - Linaro GCC 2012.07) ) #1 SMP PREEMPT Mon Jan 28 11:17
    :38 EST 2013
    [ 0.000000] CPU: ARMv7 Processor [412fc0f4] revision 4 (ARMv7), cr=10c5387d
    ....

    I do not see even see the ">>>> skern_poweron_cpu >>>>" print out. Does this mean that the boot monitor is bad or the kernel?

  • 0 in reply to Samuel Smith
    TI__Guru** 116100 points
    1) I hope it won't be any problem.
    2) You may have to modify the "arch/arm/boot/dts/k23-clocks.dtsi" file
    3) Yes, its correct.
    4) Yes.
    5) Yes, you are using correct address for K2E. (0x0c140000)
    6) Nope, I don't think so, other wise you would have get problem in u-boot too.
    7) You can also try our TI SDK rootfs with NFS mode.

    Still you may need to change the device tree of K2E board for your custom board.
    Please look into some of the keystone related device tree files and change it.

    keystone.dtsi, k2e-evm.dts, k2e-clocks.dtsi, keystone-clocks.dtsi and k2e-net.dtsi
  • 0 in reply to Titusrathinaraj Stalin
    Intellectual 300 points
    I will look at the dts files.
    Any chance it's the boot monitor though?

    Also, is there a way to hard code the console information in the kernel, rather than passing bootargs?
  • 0 in reply to Samuel Smith
    TI__Guru* 81335 points
    Hi Samuel,
    Any chance it's the boot monitor though?

    If you would like to run SMP Linux on target then no need to modify the boot monitor.

    Also, is there a way to hard code the console information in the kernel, rather than passing bootargs?

    I think, it should be possible. We request you to explore on it however you can update the bootargs and save it using saveenv console command.

    Thank you.
  • 0 in reply to Raja
    Intellectual 300 points
    The more I think about this, the more i think it's simple, and the u-boot code may just be jumping to the wrong place in memory.

    Does the 0x0c140000 boot monitor address seem right? Shouldn't it be the 0x0c5f0000? What environment variables in u-boot affect this?

    Also, all the filenames that are statically configured in u-boot are not the filenames I have built. Would filenames matter at this point?
  • 0 in reply to Samuel Smith
    TI__Guru* 81335 points

    The mon_install for EVMK2E(0x0c140000) and EVMK2H(0x0c5f0000). Thank you. Please refer MCSDK explore wiki for more information.