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-AM437X: Custom board and SBL build

Expert 1700 points

Part Number: PROCESSOR-SDK-AM437X
Other Parts Discussed in Thread: AMIC110

Hi Team,

 we are working on a custom board bring up using the board porting document : "Board porting up using Processor SDK RTOS for AM335x/AMIC110"

per the recommendation in the document , custom board adaptation was done by modifying IDK related files in the SDK (custom board components are similar to the IDK).

after changing the files "am43xx_idkevm_pinmux_data.c" and "am43xx_pinmux.h" and compiling the SBL (boot from SD card) we were able to see SBL wakes up , and copying the program to the DDR as expected.

The next stage was to re-compile the PDK so that the application will adopt custom board pinmux files as well.

after this was done , when SBL is re-compiled , it hang on access to the SD Card : at file name SBL_mmcsd.c in the first line that access the fatfs

/* Open the file for reading. */
fResult = f_open(&gFileObject, pFileName, FA_READ);

we than tried to remove the "idkAM437x_icssPinMuxFlag" from the file idkAM437x_pinmux.c , re build the PDK and recompile the SBL , but result is the same.

if we replace the pinmux files "am43xx_idkevm_pinmux_data.c" and "am43xx_pinmux.h"  with the original files , rebuild the PDK and than replace the pinmux files "am43xx_idkevm_pinmux_data.c" and "am43xx_pinmux.h"  to the custom board ones and re-build the SBL boot seems to work and SBL does not hangs when accessing the FATFS

can you help us understand what's the issue with MMCSD boot and FATFS ?

for PDK build we use

gmake clean

gmake all

for SBL build we use 

gmake bootloader BUILDCFG=boot BOOTMODE=mmcsd PLATFORM=am43xx-evm PROFILE=release -s KW_BUILD=no

(note the is PROFILE is debug , build fails)

 

  • Some more data that may be useful :

     we noticed when PDK build is invoked according to https://software-dl.ti.com/processor-sdk-rtos/esd/docs/latest/rtos/index_overview.html#building-pdk-using-gmake-in-windows-environment 

    it uses the debug build profile

    when we use SBL we use the relase debug profile , since when the debug build profile is used the following error is generated

    C:/ti/pdk_am437x_1_0_17/packages/ti/starterware/binary/soc/lib/am43xx-evm/a9/debug/gcc\libsoc_boot.a(sbl_init_boot.o): In function `Enter_BootLoader':
    C:\ti\pdk_am437x_1_0_17\packages\ti\starterware\soc/armv7a/gcc/sbl_init.S:159: undefined reference to `_data_start_ldr'
    C:\ti\pdk_am437x_1_0_17\packages\ti\starterware\soc/armv7a/gcc/sbl_init.S:160: undefined reference to `_data_start'
    C:\ti\pdk_am437x_1_0_17\packages\ti\starterware\soc/armv7a/gcc/sbl_init.S:161: undefined reference to `_data_end'
    collect2.exe: error: ld returned 1 exit status
    gmake[1]: *** [C:/ti/pdk_am437x_1_0_17/packages/ti/starterware/build/makerules/rules_a9.mk:193: C:/ti/pdk_am437x_1_0_17/packages/ti/starterware/binary/bootloader/bin/am43xx-evm/gcc/bootloader_boot_mmcsd_a9host_debug.out] Error 1
    gmake: *** [Makefile:152: bootloader] Error 2

  • Hi ,

    Rebuilding PDK will rebuild the Starterware MMCSD SBL in debug mode. Have you tested this SBL after changing to your custom pinmux files?

    Starterware shouldn't have any dependencies on PDK components besides itself, but PDK has dependencies on Starterware. I think it should be possible to find the problem by focusing on Starterware builds.

    I'm able to rebuild the SBL in debug and release mode (PDK 1.0.17):

    • debug   : gmake bootloader BUILDCFG=boot BOOTMODE=mmcsd PLATFORM=am43xx-evm PROFILE=release KW_BUILD=no
    • release : gmake bootloader BUILDCFG=boot BOOTMODE=mmcsd PLATFORM=am43xx-evm PROFILE=debug KW_BUILD=no

    I'm using the slightly modified Starter makefile attached below.

    After updating your pinmux files, can you try cleaning Starterware, and then building Starterware and the SBL?

    Update pinmux files

    Manually delete folder pdk_am437x_1_0_17\packages\ti\starterware\binary

    For debug build, issue the following from pdk_am437x_1_0_17\packages\ti\starterware:

    • gmake clean PLATFORM=am43xx-evm PROFILE=debug
    • gmake bootloader_clean BUILDCFG=boot BOOTMODE=mmcsd PLATFORM=am43xx-evm PROFILE=debug KW_BUILD=no
    • gmake PLATFORM=am43xx-evm PROFILE=debug > sw_debug_build_log.txt 2>&1
    • gmake bootloader BUILDCFG=boot BOOTMODE=mmcsd PLATFORM=am43xx-evm PROFILE=debug KW_BUILD=no > sw_sbl_debug_build_log.txt 2>&1

    For release build, issue the following from pdk_am437x_1_0_17\packages\ti\starterware:

    • gmake clean PLATFORM=am43xx-evm PROFILE=release
    • gmake bootloader_clean BUILDCFG=boot BOOTMODE=mmcsd PLATFORM=am43xx-evm PROFILE=release KW_BUILD=no
    • gmake PLATFORM=am43xx-evm PROFILE=release > sw_release_build_log.txt 2>&1
    • gmake bootloader BUILDCFG=boot BOOTMODE=mmcsd PLATFORM=am43xx-evm PROFILE=release KW_BUILD=no > sw_sbl_release_build_log.txt 2>&1

    I suggest capturing the build logs so you can see which libraries include am43xx_idkevm_pinmux_data.c.

    Regards,
    Frank

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

  • I have replaced the make file at C:\ti\pdk_am437x_1_0_17\packages\ti\starterware with the one attached , but 

    but the debug build still fails on the same error when invoking the build command for the boot loader without the following steps in your post

    I than followed your instructions (below), for the debug and release builds (logs attached). while I was able to complete the build with no errors, 

    when using the resultant MLO, custom hangs on the first fatfs command as before.

    can you review the logs and suggest how to continue ?

    sw_release_build_log.txtsw_sbl_release_build_log.txt

    I than did the same with the release build

    Update pinmux files

    Manually delete folder pdk_am437x_1_0_17\packages\ti\starterware\binary

    For debug build, issue the following from pdk_am437x_1_0_17\packages\ti\starterware:

    • gmake clean PLATFORM=am43xx-evm PROFILE=debug
    • gmake bootloader_clean BUILDCFG=boot BOOTMODE=mmcsd PLATFORM=am43xx-evm PROFILE=debug KW_BUILD=no
    • gmake PLATFORM=am43xx-evm PROFILE=debug > sw_debug_build_log.txt 2>&1
    • gmake bootloader BUILDCFG=boot BOOTMODE=mmcsd PLATFORM=am43xx-evm PROFILE=debug KW_BUILD=no > sw_sbl_debug_build_log.txt 2>&1

    sw_debug_build_log.txtsw_sbl_debug_build_log.txt

  • any leads on this one? its been a while and I could not any answers. appreciate any insight you may have on this issue

  • Hi inno,

    I've been delayed in looking into this further. I'll investigate further early next week.

    Regards,
    Frank

  • Hi ,

    My apologies, I've been delayed in further investigating this issue. I'll pursue it further next week.

    Regards,
    Frank

  • Hi Inno,

    Sorry for the delayed response. I don't have much more insight to provide on this.

    According the my build logs, am43xx_idkevm_pinmux_data.o is only included in:

    • starterware/binary/board/lib/am43xx-evm/a9/debug/gcc/libboard.a : built from "gmake PLATFORM=am43xx-evm"
    • starterware/binary/board/lib/am43xx-evm/a9/debug/gcc/libboard_boot.a : built from "gmake bootloader_clean BUILDCFG=boot BOOTMODE=mmcsd PLATFORM=am43xx-evm"

    However, only libboard_boot.a is linked in the MMCSD SBL .out file. Hence it appears the SBL doesn't have more than one dependency on am43xx_idkevm_pinmux_data.c.

    I suggest you build the MMCSD SBL in debug mode, and step through f_open() to see where the hang occurs (and compare this to the working case). The FAT file system uses a "glue code" layer to use MMCSD, please see <PDK>\packages\ti\starterware\library\third_party\ff9b\port\fatfs_port_mmcsd.c. Perhaps the hang occurs in the MMCSD operations because of pinmux changes.

    Locate the file containing the source code where the hang occurs. Then see how the associated object file & archive are included in the SBL by inspecting your build logs and the SBL .map file.

    Regards,
    Frank