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/SYSBIOS: DSP BIOS fails while creating Rpmsg / VirtQueue

Part Number: SYSBIOS

Tool/software: TI-RTOS

Hi,

I have successfully put together a working MessageQ + CMEM command-line built app on the AM572x that uses a custom resource table.

Now, I imported its config.bld and the resource table into an existing project that never had IPC or CMEM in it.

When executing the code on the DSP1, I reach to main() at which point I can debug the application.

But when I run the BIOS_start() function, I get the stack trace in the picture.

Please help me figure out what could be the root issue as I have no clue what BIOS does in the background.

I attached the resource table and config.bld and bios config fileupload.zip

Thanks

  • Hello,

    I'm assuming you are running Linux on the ARM. In your working application, was your DSP application running TI-RTOS? When you say you imported it's files into an existing project, does this project have different code on both the ARM and DSP or just the DSP?

    If you are just looking to add IPC to an existing DSP application, we have written a guide on how to do this, please take a look:

    software-dl.ti.com/.../How_to_Guides.html

    Also, for general IPC debugging guidance, please refer to the following guide:
    software-dl.ti.com/.../How_to_Guides.html

    Regards,
    Sahin
  • Hi Sahin,
    Yes, ARM is running Linux and DSP is running TI-RTOS in all cases.

    First link you listed is not very helpful because I know all that stuff, I based my work on precisely the same IPC example.
    Second link is useful in general but doesn't help me in this situation.

    My question is a rather generic one, I don't expect anyone to look into the details with me:
    - WHen VirtQueue_Create fails, what could be the reason ?

    Thanks
  • I managed to get a little bit further by making the following change to the resource table. I think the 0xB0000000 were wrong.

    diff --git a/resourcetable/rsc_table_dsp.h b/resourcetable/rsc_table_dsp.h
    index 2346bdc..a7e601c 100644
    --- a/resourcetable/rsc_table_dsp.h
    +++ b/resourcetable/rsc_table_dsp.h
    @@ -81,11 +81,11 @@
     #define DSP_MEM_HEAP            0x98400000
     
     #define DSP_MEM_IPC_DATA        0x9F000000
    -#define DSP_MEM_IPC_VRING       0xB0000000
    -#define DSP_MEM_RPMSG_VRING0    0xB0000000
    -#define DSP_MEM_RPMSG_VRING1    0xB0004000
    -#define DSP_MEM_VRING_BUFS0     0xB0040000
    -#define DSP_MEM_VRING_BUFS1     0xB0080000
    +#define DSP_MEM_IPC_VRING       0xA0000000
    +#define DSP_MEM_RPMSG_VRING0    0xA0000000
    +#define DSP_MEM_RPMSG_VRING1    0xA0004000
    +#define DSP_MEM_VRING_BUFS0     0xA0040000
    +#define DSP_MEM_VRING_BUFS1     0xA0080000
     
     #define DSP_MEM_IPC_VRING_SIZE  SZ_1M
     #define DSP_MEM_IPC_DATA_SIZE   SZ_1M

    Take a look at this picture, code now gets past VirtQueue_create calls and reaches VirtQueue_startup and hangs. I looked into what happens in Resource_getVdevStatus and it seems that after a cache invalidate, the DSP is waiting for the ARM to write 0x7 at a certain address and the ARM never does so. I am sure the ARM side is properly configured for IPC communication so this must be a misconfiguration on the DSP side.

  • Hello,

    What does the remoteproc trace say?

    cat /sys/kernel/debug/remoteproc/remoteproc2/trace0

    Are you loading the DSP image via remoteproc? If you're loading via CCS you will run into issues. Please see my response in the thread below about this.

    Otherwise there may be some mismatch in your CMA configuration. I'll take a look at your files and get back to you.

    Regards,
    Sahin

  • Hello,

    Did you make any changes to the default dts? If so, can you please attach it?

    Regards,
    Sahin
  • Thank you Sahin,

    First, trace0 only has this line printed because the code hangs. However I would expect, as per my last screenshot, to also see the output of those Log_print1 and Log_print0 calls because the execution goes through there.

    # cat /sys/kernel/debug/remoteproc/remoteproc2/trace0
    [      0.000] 18 Resource entries at 0x95000000
    

    As for how I load the DSP, I do it with CCS by loading everything not just the symbols. But I will try to do it the way you describe in the thread and report back.

    As for the dts, it is not modified, Or, rather, I tried with both unmodified and modified in the following way with the same result:

    # git clone https://git@stash.phytec.com/scm/pub/linux-phytec-ti.git
    # cd linux-phytec-ti/arch/arm/boot/dts
    
    # git diff
    diff --git a/arch/arm/boot/dts/am572x-pcm-057-41300111i.dtsi b/arch/arm/boot/dts/am572x-pcm-057-41300111i.dtsi
    index da0df94dfc86..f966e91fedf6 100644
    --- a/arch/arm/boot/dts/am572x-pcm-057-41300111i.dtsi
    +++ b/arch/arm/boot/dts/am572x-pcm-057-41300111i.dtsi
    @@ -17,7 +17,7 @@
    
            memory {
                    device_type = "memory";
    -               reg = <0x0 0x40000000 0x0 0x40000000>; /* 2GiB */
    +               reg = <0x0 0x80000000 0x0 0x80000000>; /* 2GiB */
            };
     };
    
    diff --git a/arch/arm/boot/dts/am57xx-phycore-common.dtsi b/arch/arm/boot/dts/am57xx-phycore-common.dtsi
    index a38b3b4a2437..9176ea97ba0c 100644
    --- a/arch/arm/boot/dts/am57xx-phycore-common.dtsi
    +++ b/arch/arm/boot/dts/am57xx-phycore-common.dtsi
    @@ -40,7 +40,7 @@
                    cmem_block_0: cmem_block@0 {
                            reg = <0>;
                            memory-region = <&cmem_block_mem_0>;
    -                       cmem-buf-pools = <1 0x0 0x0c000000>;
    +                       cmem-buf-pools = <6 0x0 0x02000000>;
                    };
            };
    
    

  • db said:
    As for how I load the DSP, I do it with CCS by loading everything not just the symbols.

    I suspect this is the issue. The DSP will need to be loaded via remoteproc.

    1. Modify the symbolic link in /lib/firmware of the default image name to point to the DSP binary. The image pointed to by the symbolic link will be downloaded to and executed on the DSP by remoteproc during Linux Kernel boot.

    ln –sfn "your_dsp_binary.xe66" /lib/firmware/dra7-dsp1-fw.xe66 

    2. Reboot or unbind/bind the DSP.

    3. ./app_host DSP1

    Once the DSP is running, you can connect to it and load symbols to debug. Make sure CCS does not run any GEL files when connecting.

    Hope this helps. If you have any questions please let me know.

    Regards,
    Sahin