Linux: J6-DRA7xx- Load & Booting ipu1 xem4 image from A15linux - Required Device tree (dts) changes

Hi Yordon,

We are using custom ipu1 .xem4 from display dss application of VISION SDK.
How to check the timers used in this firmware ?


Best regards,
Gokul

Hi Gokul,

I am not familiar with the Vision SDK source code. I am checking this internally & will get back to you.

Best Regards,
Yordan

Hi Yordan,

Do you get response from SDK experts ?

Best regards
Gokul

Hi Gokul,

I've started an offline discussion with the Vision SDK team. I don't have any feedback yet.

Best Regards,
Yordan

Hello,

Timers and mailboxes are generic devices which can be used by any of DSP, IPU and other remote cores.
We have aligned on hardware usage of these in the IPC library across different varieties of Software TI wide.
So by default, the mailboxes as specified in the device tree DO NOT conflict with the ones used by Vision SDK

As such, if you have modified Vision SDK code for additional links, chains, etc, No need to change the mailbox, timer association.
you have already matched the IPU/DSP code/data section via the cma node
But, Vision SDK also uses shared memory regions. Plese make sure they are added as reserved memory nodes
This is already done in the infoadas DTSB source. Please refer to it

Regards,
Nikhil D

HI Nikhil,

We are using customized J6- DRA7xx board.

We are trying to load the display DSS application ( bsp_examples_displayDss_m4vpss_release.xem4 image -vision-sdk ) via linux .

We have attached the dts for the same.

We are getting the below log messages. From the logs, only ipu2 image is loaded & up. 

But for the customized image ipu1, it is not loaded .

What may be the problem ?  how to debug ?

calling omap_rproc_driver_init+0x0/0x24 [omap_remoteproc] @ 1116
[ 93.805765] omap-rproc 58820000.ipu: assigned reserved memory node ipu1_cma@9d000000
[ 93.818641] remoteproc0: 58820000.ipu is available
[ 93.824547] remoteproc0: Note: remoteproc is still under development and considered experimental.
[ 93.835868] remoteproc0: THE BINARY FORMAT IS NOT YET FINALIZED, and backward compatibility isn't yet guaranteed.
[ 93.854801] omap-rproc 55020000.ipu: assigned reserved memory node ipu2_cma@95800000
[ 93.863313] remoteproc1: 55020000.ipu is available
[ 93.868421] remoteproc1: Note: remoteproc is still under development and considered experimental.
[ 93.878906] remoteproc1: THE BINARY FORMAT IS NOT YET FINALIZED, and backward compatibility isn't yet guaranteed.
[ 93.892808] initcall omap_rproc_driver_init+0x0/0x24 [omap_remoteproc] returned 0 after 87297 usecs
[ 94.102447] remoteproc1: powering up 55020000.ipu
[ 94.107480] remoteproc1: Booting fw image dra7-ipu2-fw.xem4, size 4461564
[ 94.115454] omap-iommu 55082000.mmu: 55082000.mmu: version 2.1
[ 94.147449] remoteproc1: remote processor 55020000.ipu is now up
[ 94.154257] virtio_rpmsg_bus virtio0: rpmsg host is online
[ 94.154536] virtio_rpmsg_bus virtio0: creating channel rpmsg-proto addr 0x3d
[ 94.167880] remoteproc1: registered virtio0 (type 7)

#cat /sys/kernel/debug/remoteproc/remoteproc1/
name recovery state trace0 version
/trace0 2020-a879-b0:/lib/firmware# cat /sys/kernel/debug/remoteproc/remoteproc1/
[0][ 0.000] Watchdog enabled: TimerBase = 0x6803e000 SMP-Core = 0 Freq = 19200000
[0][ 0.000] Watchdog enabled: TimerBase = 0x68036000 SMP-Core = 1 Freq = 19200000
[0][ 0.000] Watchdog_restore registered as a resume callback
[0][ 0.000] 18 Resource entries at 0x3000
[0][ 0.000] messageq_single.c:main: MultiProc id = 1
[0][ 0.000] registering rpmsg-proto:rpmsg-proto service on 61 with HOST
[0][ 0.000] tsk1Fxn: created MessageQ: SLAVE_IPU2; QueueID: 0x10080
[0][ 0.000] Awaiting sync message from host..

#cat /sys/kernel/debug/remoteproc/remoteproc0/
offline (0)

With regards,

Gokul

6283.j6_dra7xx_ipu1.txt

From the log I can infer that the driver didn't even try to load the image
IPU1 device is probed but the firmware is not getting loaded.

If there is any memory map conflict, The driver would thrpugh error like failed to parse resources.
Check if the firmware file is properly present in the /lib/firmware (The name should be retained if overwriting with different image)

Also, try to load the FW manually through sysfs.
Refer to kernel documentation for manual loading of remoteprocs via sysfs

Nikhil D

Hi Nikhil

We have build the ipc_3_42_00_02 package.We have installed the  IPC test executables and libraries into the target as shown below.

root:~/install_package/bin# ls

MessageQApp         MessageQMultiMulti  fault

MessageQBench       Msgq100             lad_dra7xx

MessageQMulti       NameServerApp       ping_rpmsg

root:~/install_package/bin# cd ..

root:~/install_package# ls

bin      include  lib

We have renamed the messageq_single.xem4 file  from the below path to dra7-ipu2-fw.xem4 and copied to /lib/firmware.

./packages/ti/ipc/tests/bin/ti_platforms_evmDRA7XX_ipu2/messageq_single.xem4.

We renamed the messageq_single.xem4 file  from the below path to dra7-ipu1-fw.xem4 and copied to /lib/firmware.

./packages/ti/ipc/tests/bin/ti_platforms_evmDRA7XX_ipu1/messageq_single.xem4.

Observation:

After loading modules

modprobe omap_remoteproc

[   25.652303] omap-rproc 58820000.ipu: assigned reserved memory node ipu1_cma@9d000000

[   25.661413]  remoteproc0: 58820000.ipu is available

[   25.667139]  remoteproc0: Note: remoteproc is still under development and considered experimental.

[   25.677035]  remoteproc0: THE BINARY FORMAT IS NOT YET FINALIZED, and backward compatibility isn't yet guaranteed.

[   25.689756] omap-rproc 55020000.ipu: assigned reserved memory node ipu2_cma@95800000

[   25.698424]  remoteproc1: 55020000.ipu is available

[   25.704213]  remoteproc1: Note: remoteproc is still under development and considered experimental.

[   25.714012]  remoteproc1: THE BINARY FORMAT IS NOT YET FINALIZED, and backward compatibility isn't yet guaranteed.

root@mmt2020-a879-b0:~# [   26.075220]  remoteproc0: powering up 58820000.ipu

[   26.080880]  remoteproc0: Booting fw image dra7-ipu1-fw.xem4, size 4461564

[   26.089112] omap-iommu 58882000.mmu: 58882000.mmu: version 2.1

[   26.096637]  remoteproc0: remote processor 58820000.ipu is now up

[   26.107268] virtio_rpmsg_bus virtio0: rpmsg host is online

[   26.113219]  remoteproc0: registered virtio0 (type 7)

[   26.120250]  remoteproc1: powering up 55020000.ipu

[   26.125273]  remoteproc1: Booting fw image dra7-ipu2-fw.xem4, size 4461564

[   26.132807] omap-iommu 55082000.mmu: 55082000.mmu: version 2.1

[   26.164857]  remoteproc1: remote processor 55020000.ipu is now up

[   26.171615] virtio_rpmsg_bus virtio1: rpmsg host is online

[   26.171881] virtio_rpmsg_bus virtio1: creating channel rpmsg-proto addr 0x3d

[   26.185122]  remoteproc1: registered virtio1 (type 7)

#export LD_LIBRARY_PATH=/home/root/install_package/lib:$LD_LIBRARY_PATH

#./lad_dra7xx -l log.txt

Opened log file: log.txt

numProcessors = 5 id = 0 baseId = 0

Spawned daemon: ./lad_dra7xx

#/MessageQApp 1 1

[  308.902428] NET: Registered protocol family 41

[  308.908657] omap-iommu 55082000.mmu: 55082000.mmu: version 2.1

Using numLoops: 1; procId : 1

Entered MessageQApp_execute

Local MessageQId: 0x80

Remote queueId  [0x10080]

Exchanging 1 messages with remote processor IPU2...

MessageQ_get #1 Msg = 0xb6600468

Exchanged 1 messages with remote processor IPU2

Sample application successfully completed!

Leaving MessageQApp_execute

#/MessageQApp 1 2

[  384.694383] omap-iommu 55082000.mmu: 55082000.mmu: version 2.1

Using numLoops: 1; procId : 2

Entered MessageQApp_execute

Local MessageQId: 0x80

For IPU2, there is  response from the remote core.

But for IPU1, there is no response from the remote core. What may be the problem ?  

Regards,

Gokul

You can get the remoteproc logs in the sysfs (cat /sys/kernel/debug/remoteproc/remoteprocX/trace0)
Also, check the IRQ count for the mailboxes used for IPU1 and IPU2 (I guess they are different) before and after the handshake

I believe most likely this might an application related issue.

Regards,
Nikhil D

Hi Nikhil

1.  We tried to  take logs from trace0, but the information is not clear.

cat /sys/kernel/debug/remoteproc/remoteproc0/trace0

òs'Îõ¬fÊßk?"»m¯öoçöcôYù[ìw¯Í{ï]÷§cuÿýþ±¾Kês?ßH?åùÃÿþë=òâó¿ï¯;Å{Sûî÷ýjÞþoëòïÿµ·üÞõ??Ëo*mo?>$:ºõ[·£O{¹gÁïô§í«ëúãÏÏWvq¿©Ïçéÿ:þìê~(ëÉ.vOþ÷»cÿéËoßïkÌíæOÝïyîMí|¯±ðýÛÞìþ|¾¹þßÿ?rÓê÷¡Ï¸Ô¯»Öþôí·/îówþÏZa?¯"ß·ï´F¯þîîxsýwæ,ÿÛM»;ÿëvκ¿ØÇ[Ú9ÿs®;ìª[ýùÿgÖèíèïn£ä|n÷üZ/ûòöÿË\ÖÁ£ßéë8ù

      úe®jù:Ô÷oívÕüöö~ºç×~3Ùmcþ[6~ïzwqkþ'Fsãßëx¯æ~ë¸?¼o'«ìÏï{k¨gø~Þ»ÿüó}Uí÷'µ=?sÿCöWëG­é'Þþ»!Þ÷áûçìßÿëØûN®Êÿ»N.?ü¿ïËAùîþýüên?Uvý«ï®ÿÿÎýëÿçóÕºouv?ðûþnïóôøe¯ïû½÷aþÅ$}ºõÿ÷¡÷õúÆïJj]^ãöüÿ½ï)_î®M]?'uÿÝû_Åüú}½­þºø×ø¹ûývúN|s    ÿjºë¦þö_¿ÿíæ§{zË/F½~¯Ìóú>¥ÿz    ë8þ[ýêÙÿÞqîþ¾pc¾[¯3þàBù&rìÑlCòóL?×ûëÜQúx

2. What about problem in loading the vision sdk , dss application image ?

Since we able to load the ./packages/ti/ipc/tests/bin/ti_platforms_evmDRA7XX_ipu1/messageq_single.xem4, I guess there is no problem in dts.

Regards

Gokul

                                                                                                       ï

Hello Gokul


DTS file has info about the CMA pool that is used for loading the code and data sections of the image.
These addresses need to match with the addresses used at build time.

Typically some memory config xs file defines the code & data address & sizes.
The driver only makes sure that the entries put in the resource table match with the reserved memory pool in DTS

If not matched, it thows error saying "Failed to handle resources"
As part of hadnling the resources, it also creates sysfs entries where the LOG from remoteprocs will be stored.
Again, this is in sync with the resource table.


From the dumps you have providede, it looks to me that the logbuf is setup correctly, but no-one has initialized it or written to it.
Check the mailbox IRQs to confirm the handshake

Regards,
Nikhil D

Gokul,

Are you using the vision sdk linux build or bios build? Do you have a resource table section in the binary? Resource table is necessary for loading binaries via Linux kernel.

you can run objdump -h dra7-ipu1-fw.xem4 and look for a resource_table section in your binary.

29 .resource_table 00000410 00003000 00003000 00001000 2**12
CONTENTS, ALLOC, LOAD, DATA

regards,
Venkat

Hi Venkat,

We are able to load the  Customized Vision sdk-M4-Core IPU1 image via IPL.

Now we are trying to load the same image from the linux  kernel (via modprobe omap_remoteproc).

attached the objump of the same image. 

objdump -h dra7-ipu1-fw.xem4.  

We don't find resource_table section in this binary.

1563.displaydss_visionsdk-ipu1.txt

Regards,

Gokul

Gokul,

If you need to load the M4 image via kernel, it needs to have a resource table for handling memory allocation and MMU setup.

Vision SDK has two build configurations BIOS and Linux based on the HLOS running on A15. To load M4 binaries via kernel, you need to use the Linux build configuration. Linux build configuration will pull in the necessary IPC changes to include a resource table in the binary and allow for loading via the kernel. Please check the vision sdk documentation.

Once you pull in the resource table into the M4 binary, make sure your IPL code handles the resource table. You can use u-boot code as reference. Please see the link below.

review.omapzoom.org/gitweb

regards,
Venkat

Hi Venkat,

I  got little bit confused.

Let me list the tasks completed so far.

1. we have downloaded Vision -SDK 2.12 version.exe  & installed in Windows.

2. Build  displayDSS -SYSBIOS based m4 core-IPU1  application image. (from ti_components\drivers\bsp_01_07_01_17 ).

3.  We have tested this image via CCS.

4. Then we  have tested with this image via IPL.

5. Now we are trying to load the same image via Linux kernel.

what is  Linux build configuration and BIOS build cfg ?  As per my understanding ,  In Linux build configuration, A15 core running on linux  and m4 core image running on SYS- BIOS. is it correct ?

In Bios build configuration, both M4 and a15 runs on SYSBIOS. is it correct ?

Whether i need to build displaydss  ( ti_components\drivers\bsp_01_07_01_17 ) application again for linux -build configuration for  including resource table ?

I am not clear on the above things. I am searching documents.

Please support for linux -build configuration.

I never build complete vision-sdk complete source.  For our  VPS application  I  have build only inside  the bsp_01_07_01_17 directory.

Regards

Gokul

6378.0001-Add-IPC-to-the-build.txt7635.0002-Change-proxy-to-sysmin.txtGokul,

Thanks. This clarifies things.

>

> 1. we have downloaded Vision -SDK 2.12 version.exe  & installed in*Windows.*

>

> 2. Build  displayDSS -SYSBIOS based m4 core-IPU1  application image. (from ti_components\drivers\bsp_01_07_01_17 ).

>

> 3.  We are tested this image via CCS.

>

> 4. Then we tested with this image via IPL.

>

> 5. Now we are trying to load the same image via Linux kernel.

The bsp sample applications do not have an IPC component and are expected to be loaded via CCS.You cannot load them via Linux kernel as they lack a resource table.

> *Whether i need to build displaydss  ( ti_components\drivers\bsp_01_07_01_17 ) application again for linux -build configuration for  including resource table ?*

Yes. If you are only working with bsp, you need to include resource table in your build. There is no separate linux build configuration.

Attached are two patches I used to enable resource table on loopback application. I was working on DSP at that time. Please customize for your sample application.

regards,

Venkat

 Thanks Venkat for sharing the patches. We will look on these patches. 

Regards

Gokul

Hi Venkat,

We don't find  loopbackDSP.cfg in my Vision_SDK source. We have  loopback.cfg and loopbackM3.cfg.

Both the files internally use bspCommonBIOS.cfg & bspCommonBIOSM3.cfg.

We don't exactly, where the  below changes need to apply in my  bspCommonBIOS.cfg

+

+

+var SysMin      = xdc.useModule('ti.trace.SysMin');

+System.SupportProxy = SysMin;

+SysMin.bufSize  = 0x8000;

+Program.sectMap[".tracebuf"] = "VPSS_M4_CODE_MEM";

+Program.sectMap[".errorbuf"] =  "VPSS_M4_CODE_MEM";

+/* Enable Memory Translation module that operates on the BIOS Resource Table */

+var Resource = xdc.useModule('ti.ipc.remoteproc.Resource');

+Resource.loadSegment = "VPSS_M4_CODE_MEM";

3618.bspCommonBIOS.cfg

Regards

Gokul

Gokul,

Please add this to the cfg file of the sample application you are building. If you are using displayDss example, you should used displayDss.cfg. To find the cfg file for other examples, please refer to Makefile in the example source folder. The section name "VPSS_M4_CODE_MEM" should be replaced by the appropriate section name per your code.

regards,
Venkat

Hi Venkat,

We are able to include the resource table.

26 .resource_table 0000044c  90000000  90000000  00001000  2**12

                 CONTENTS, ALLOC, LOAD, DATA

 

There is problem in booting the image as below.

eproc1: Note: remoteproc is still under development and considered experimental.

[ 2627.286781]  remoteproc1: THE BINARY FORMAT IS NOT YET FINALIZED, and backward compatibility isn't yet guaranteed.

root@mmt2020-a879-b0:/lib/firmware# [ 2627.311833]  remoteproc0: powering up 58820000.ipu

[ 2627.316863]  remoteproc0: Booting fw image dra7-ipu1-fw.xem4, size 7205336

[ 2627.326817] omap-iommu 58882000.mmu: 58882000.mmu: version 2.1

[ 2627.338185]  remoteproc0: erroneous trace resource entry

[ 2627.343868]  remoteproc0: Failed to process resources: -22

[ 2627.352058]  remoteproc0: rproc_boot() failed -22

[ 2627.357119] virtio_rpmsg_bus: probe of virtio0 failed with error -22

Regards

Gokul

4336.j6_advplus.txt7416.rsc_table_vayu_ipu.h