• State
  • Locked Locked
  • Replies 8 replies
  • Subscribers 99 subscribers
  • Views 602 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.

Recent versions of boot-monitor fail when u-boot is loaded through Code Composer

Paul Barker @ Commagility
Expert 1490 points

We're seeing a failure to boot Linux on ARM core 0 of a K2K/K2H device.

When a the processor is placed in no-boot mode, brought out of reset and u-boot is loaded via code composer, the boot process hangs before Linux is booted. Building u-boot with 'DEBUG' defined and adding additional printf statements revealed that the function mon_install() is called but doesn't ever return. This function installs the boot monitor contained in the file 'skern.bin'. If the processor is paused at this stage and u-boot is reloaded the boot will then succeed. If the processor is power cycled and u-boot is reloaded the boot will fail again at the same point. So, cold boot fails and warm boot succeeds. This appears to be fairly consistent.

This problem occurs only with 'skern.bin' built using bitbake. 'skern.bin' provided by TI as part of MCSDK 3.00.03.15 works correctly. The SRCREV used by the boot-monitor bitbake recipe in MCSDK is 4b0287a3fa9c7a25c75bbe3a54f4ac2a92dc0aaa which is the latest git commit to this repo. This recipe was modified to use an older git commit and it was found that it is possible to build a working 'skern.bin' from git commit 51371402f979645478f2bc2be170279acee87be6 or earlier. Commit 6013a66b3ba1376a3de51c32d077c642fb0bf791 or later exhibits the failure. This suggests that commit 6013a66b3ba1376a3de51c32d077c642fb0bf791 introduced the error.

If the processor is placed in EMIF boot mode this failure is not seen - the latest version of 'skern.bin' consistently allows a successful boot. The issue is only seen when the processor is in no-boot mode and u-boot is loaded via Code Composer.

The commit which is suspected of introducing the error is shown below:

commit 6013a66b3ba1376a3de51c32d077c642fb0bf791
Author: Vitaly Andrianov <vitalya@ti.com>
Date: Mon Jun 9 09:51:12 2014 -0400

    boot-monitor: set NSACR.NS_SMP bit

    SMP Linux kernel sets the ACTRL.SMP bit. We need to set NSACR.NS_SMP bit
    to make the ACTRL.SMP writable form non-secure world.

    Signed-off-by: Vitaly Andrianov <vitalya@ti.com>

diff --git a/sec/skern.c b/sec/skern.c
index 58550bb..ec68847 100644
--- a/sec/skern.c
+++ b/sec/skern.c
@@ -248,6 +248,10 @@ void skern_setup_cp15(void)
        "mcr p15, 0, r0, c1, c0, 1\n"
        "isb\n"
        "dsb\n"
+       /* set NSACR.NS_SMP bit */
+       "mrc p15, 0, r0, c1, c1, 2\n"
+       "orr r0, r0, #(1 << 18)\n"
+       "mcr p15, 0, r0, c1, c1, 2\n"
        "mov r0, #0x00f00000\n"
        "mcr p15, 0, r0, c1, c0, 2\n"
        "isb\n"

This sequence of instructions has been mentioned as the cause of a processor hang in another post on E2E: e2e.ti.com/.../1321339.

Is the above instruction sequence known to cause a hang on K2K/K2H processors? Has the latest boot-monitor code been tested on these devices? And is there anything we can do to workaround or fix this issue?

Thanks,
Paul Barker

  • 0
    TI__Guru* 81335 points

    Hi Paul, We recommend you to use the latest MCSDK(03.01.01.04 Release notes) release tags mentioned in the release notes for usage.

    Thank you.

  • 0 in reply to Raja
    Expert 1490 points
    Tag K2_BM_14.09 corresponds to commit 4b0287a which exhibits the error I described. Commit 5137140 is the latest commit which doesn't exhibit the failure.

    Thanks,
  • 0 in reply to Paul Barker @ Commagility
    TI__Guru* 81335 points
    Hi Paul,
    Thank you. We will check and get back to you.
  • 0
    TI__Mastermind 43955 points

    Hi Paul,

    Could you try the attached "skern.bin"

    https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/791/skern.bin

    We may have to look into the "loadlin-evm-uboot.js" script which is responsible to load the skern and u-boot image to RAM.

  • 0 in reply to Shankari G
    Expert 1490 points
    Hi,

    I don't think I'm using the "loadlin-evm-uboot.js" script. We load u-boot onto ARM core 0 using Code Composer and this then downloads skern, uImage, dtb and the rootfs over tftp. Once u-boot is burnt into flash this gives us a quick turn-around for trying new versions of things. So skern.bin isn't loaded by Code Composer here.

    I'll place the skern.bin file on our tftp server though and give this a try.

    Thanks,
    Paul
  • 0 in reply to Paul Barker @ Commagility
    TI__Mastermind 43955 points
    Hi Paul,

    We have a TI wiki page that describe how to load u-boot,skern,uImage,dtb and ramdisk image using CCS IDE.

    Are you following this method ?
    If not, could you provide the steps that followed by you.

    processors.wiki.ti.com/.../MCSDK_UG_Chapter_Exploring

    I presume that you can boot the linux with older skern.bin right ?
  • 0 in reply to Shankari G
    Expert 1490 points
    Hi,

    I've not got test hardware today so I'll give this a try next week. I'll try the skern.bin file you posted with both our boot method and the boot method in the MCSDK documentation you linked and let you know what the outcome is.

    Our method is to launch the target configuration, connect to core 0 of the Cortex A15 and on the 'Run' menu select 'Load' -> 'Load Program...' and find our 'u-boot.elf' file. Our u-boot has been modified to support the hardware on our boards. U-boot then downloads the files it needs to boot from a tftp server. Once downloaded, u-boot can either boot Linux using these files or write them to flash so that the tftp server is not needed for subsequent boots. In this way we write u-boot to flash and then reset the processor in EMIF boot mode so that u-boot is loaded from flash and the Code Composer connection is no longer needed.

    With an older skern.bin file I can successfully boot Linux in all circumstances. Both the skern.bin file downloaded from MCSDK 3.00.03.15 and a skern.bin built using OpenEmbedded where the git commit of boot-monitor is 5137140 or earlier work. A skern.bin build using OpenEmbedded with a more recent git commit of boot-monitor fails. However as stated it's only when u-boot is loaded by Code Composer that the error occurs. Once we've flashed u-boot to the device and we're running in EMIF boot mode any skern.bin file seems to work.

    Thanks,
    Paul Barker
  • 0 in reply to Paul Barker @ Commagility
    Expert 1490 points
    I've tested the skern.bin file posted by Shankari G and it doesn't work.

    Our u-boot loader copies skern.bin from flash or from a tftp server to the address 0x5cf0000 which is effectively what the instructions in the MCSDK UG say that the javascript file does. If I follow those instructions exactly with our version of u-boot then it will just overwrite the skern.bin loaded by the js file with the version from flash or from the tftp server. I'll try to get our u-boot not to load skern.bin but it may take a bit of debugging and I'm pretty confident that we'll just see the same issue.

    Thanks,
    Paul Barker