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.

RTOS/AM3358: Bootloader with DMA enabled

Part Number: AM3358


Tool/software: TI-RTOS

I am using the AM3358 on the Beaglebone Black platform. My TI-RTOS application is ~ 1.2 MB in size. The default TI-RTOS bootloader project seems to take ~ 4 seconds to load then start my application.

My goal is to speed up this time. Keeping the code stock, it works consistently, but is slow. It appears that DMA is disabled by default for the bootloader. In the file hsmmcsd_app_pol.c in ~/ti/pdk_am335x_1_0_10/packages/ti/starterware/examples/mmcsd there is a function at the bottom HSMMCSDAppPolControllerSetup(), which has a line: 

pCtrl->dmaEnable = FALSE;

If I change the line to:

pCtrl->dmaEnable = TRUE;

The bootloader will build, but this doesn't seem to actually enable DMA. With this change, the program seems to hang on the f_open() call in sbl_mmcsd.c (~/ti/pdk_am335x_1_0_10/packages/ti/starterware/bootloader/src).

What is needed to get DMA to work?

  • The RTOS team have been notified. They will respond here.
  • Justin,

    this issue was reported by another user recently and we are tracking the issue. It appears there was a path for FAST boot that was integrated in the a previous starterware release which enabled Cache and MMU optimally in the bootloader which is the reason for the slow booting.

    This has been described in the application note here:
    www.ti.com/.../tidual8a.pdf

    We are working on integrating this fix and will update the thread. DMA implementation in bootloaders is custom development that we currently don`t plan to support. This will need to be implemented by users to meet their end application boot times.

    Regards,
    Rahul
  • I read through the app note. It appears the SPI frequency should be be to high frequency for SD boot, so that's not it.

    To the sbl_main.c, I added:

    #include "cache.h"
    #include "mmu.h"
    #include "example_utils_mmu.h"

    and then before the call to BOARDInit(), I added the lines:

    /* Enable cache memory and MMU */
    MMUConfigAndEnable();
    CACHEEnable(CACHE_IDCACHE, CACHE_INNER_OUTER);

    I modified the makefile as well. When I attempt to build I see the error:

    c:/ti/gcc-arm-none-eabi-6-2017-q1-update/bin/../lib/gcc/arm-none-eabi/6.3.1/../.
    ./../../arm-none-eabi/bin/ld.exe: C:/ti/pdk_am335x_1_0_10/packages/ti/starterwar
    e/binary/bootloader/bin/am335x-evm/gcc/bootloader_boot_mmcsd_a8host_debug.out se
    ction `.bss' will not fit in region `OCMCRAM'
    c:/ti/gcc-arm-none-eabi-6-2017-q1-update/bin/../lib/gcc/arm-none-eabi/6.3.1/../.
    ./../../arm-none-eabi/bin/ld.exe: region `OCMCRAM' overflowed by 4185 bytes
    collect2.exe: error: ld returned 1 exit status
    gmake[2]: *** [C:/ti/pdk_am335x_1_0_10/packages/ti/starterware/binary/bootloader
    /bin/am335x-evm/gcc/bootloader_boot_mmcsd_a8host_debug.out] Error 1
    gmake[1]: *** [bootloader] Error 2
    gmake: *** [starterware_boot] Error 2

    The build takes a while before it fails at this step.

  • Any advice how to get this to build? I am not sure where the .bss is even defined in the starterware? This is not resolved...
  • Justin,

    the linker error indicates that in the bootloader linker command file the .bss section is placed in OCMCRAM but based on the size the section sections exceeds the available size in OCMC. You can check the bootloader linker command file at the location:

    <PDK_INSTALL_DIR>\packages\ti\starterware\examples\gcc\am335x_boot.lds

    I am surprised that your bootloader size exceeds the 127 KB in OCMC. Can you check in your build link step if the build links to this .lds file.

    Regards,
    Rahul
  • I edited that file to increase the OCMC allocation to prevent the error in previous post. However, even though the firmware built successfully, it didn't work at all. No messages were displayed on UART0, and the bootloader didn't boot up the other firmware.

    I attempted to load an older version of the firmware as well (4.02, 4.01, 4.00). The older versions didn't all build the bootloader firmware, and the ones that did were not any faster than the 4.03 version.

    This is a little frustrating. I am getting more questions than any advice. The ultimate goal here is to get to a faster bootloader. The DMA apparently won't work in the bootloader for some unknown reason and enabling the cache/MMU now prevents the build from completing in 4.03.