• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 99 subscribers
  • Views 3152 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.

RTOS/AM5728: DSP firmware load error

Sandeep Pendharkar
Prodigy 50 points

Part Number: AM5728

Tool/software: TI-RTOS

Problem description:
====================

During loading of dsp firmware on dsp1 using remoteproc, im getting the
following error:

[ 70.405992] remoteproc2: Booting fw image dra7-dsp1-fw.xe66, size 5132952
[ 70.420358] omap_hwmod: mmu0_dsp1: _wait_target_disable failed
[ 70.426258] omap-iommu 40d01000.mmu: 40d01000.mmu: version 3.0
[ 70.432209] omap-iommu 40d02000.mmu: 40d02000.mmu: version 3.0
[ 70.446300] remoteproc2: bad phdr da 0x40300000 mem 0x1d20
[ 70.451924] remoteproc2: Failed to load program segments: -22


Application description:
========================

I've taken the big data IPC example that TI provides. Im trying to use this in
my project. The project requires usage of all other standard drivers that come
with the pdk (i2c, uart, gpio, osal) along with the am572x board initialization
as well. Since this an IPC example using cmem, there is a resource table as
well. My application has the typical board initialization function:

=========================
Board_initCfg boardCfg;

boardCfg = BOARD_INIT_PINMUX_CONFIG |
BOARD_INIT_MODULE_CLOCK |
BOARD_INIT_UART_STDIO;

Board_init(boardCfg);
=======================

As per TI pdk documentation from
processors.wiki.ti.com/.../Processor_SDK_RTOS_Board_Support :
code/data/stck during the IO delay setup must be within local internal memory -
specifically OCM_RAM1.

As a result, ive made the following additions to the project cfg file:

Program.sectMap["BOARD_IO_DELAY_DATA"] = "OCMC_RAM1";
Program.sectMap["BOARD_IO_DELAY_CODE"] = "OCMC_RAM1";

Note that OCMC_RAM1 is located at address: 0x40300000. BOARD_IO_DELAY_DATA and
BOARD_IO_DELAY_CODE become program segments that need to be allocated/placed
somewhere in memory during loading of the dsp firmware (elf file) using
remoteproc by the linux kernel. The function rproc_elf_load_segments reads the
elf file and for each segment tries to grap the kernel address corresponding to
the device address using rproc_da_to_va. This function looks up the resource
table to perform this task. Note that the resource table does not have any entry
for OCMC_RAM1 and hence rproc_elf_load_segments errors out.

So how do i solve this problem? I tried adding a dev_mem entry to the resource
table so that rproc_da_to_va finds this OCMC_RAM1 address but that did not work.

Not having the BOARD_IO_DELAY* sections in the cfg file does not help either.

Surely, Im not the first one to be encountering this problem. Looks like there
is something i might be missing. any help is highly appreciated

  • 0
    TI__Guru**** 393215 points
    The RTOS team have been notified. They will respond here.
  • 0 in reply to Biser Gatchev-XID
    Prodigy 50 points

    Thanks!

    I've been able to narrow down the problem further. I compared my elf file with the elf file generated from the  led_blink application presented in PDK_PATH/packages/ti/drv/gpio/test.

    Given below is the analysis:

    • The example application links with ti.board.ae666 present in PDK_PATH/packages/ti/board/lib/evmAM572x/c66/release. This library archive contains the some BOARD_IO_DELAY_DATA/CODE functions like BoardCtrlPadMux and boardPadGetSize and BoardCtrlPadIoDelayConfig. Note that these 3 functions never get executed from the application at all. They are present as relocatable sections in the elf file ti.board.ae666.
    • During the final linking phase to produce the final application elf file, these 3 functions get removed as in they are not present in the final elf file. I assume this is because they are not getting used at all.
    • I would expect the same behavior in my actual project where im trying to combine the Big DATA example and this simple example. But that is not the case. I see that big data library elf files and my application code gets linked to ti.board.ae666 in the same way but these 3 functions make their way in the final elf. This elf now has valid BOARD_IO_DELAY_CODE/DATA sections and hence the remoteproc fails  as described earlier.
    • I'm not able to find out what is being done diffferently in the two cases mentioned above.

  • 0 in reply to Sandeep Pendharkar
    TI__Guru 50170 points
    Hi, Sandeep,

    Are you trying to do the pinmux in the DSP code? If that is the case, the document you refer to is for RTOS application only and does not apply to Linux-RTOS. When doing ARM/Linux and DSP/RTOS communication, the Linux is the master. Pinmux should be done by Linux. If its RTOS only application, then yes, you need to call board_init to set up the pinmux.

    If you need help in AM572x pinmux, please create a new thread.

    Rex
  • 0 in reply to Rex Chang
    TI__Guru 50170 points
    HI, Sandeep,

    You haven't responded back for a while and I assume your problem is solved. If that is the case, please click "Resolved" button.

    If you have other issues, please submit a new thread. Thanks!

    Rex