AM5728: EVM: Adding IPC to and existing TI RTOS application on the IPU

Hi Jon,

Please ensure the new firmware you built has the ".resource_table" section first and foremost. You can use "readelf -l" to inspect the loadable program segments and the section-to-segment mapping.

Jon Lake said:

I wasn't sure how to disable the uart3 node in the Linux kernel device tree.

You will need to be able to build the Linux kernel. The suggested modifications are to be made in the relevant <board>.dts file. An alternative would be to use "dtc" on your build machine to generate the dts file from your dtb, modify the dts file and regenerate the dtb.

regards

Suman 

Hi Suman,

It looks like the .resource_table section exists:

Elf file type is EXEC (Executable file)
Entry point 0x11
There are 8 program headers, starting at offset 4786616

Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x000034 0x00000000 0x00000000 0x000e0 0x000e0 R E 0x4
LOAD 0x000114 0x00000400 0x00000400 0x00140 0x00140 R 0x4
LOAD 0x001000 0x00003000 0x00003000 0x00500 0x00500 RW 0x1000
LOAD 0x001500 0x00004000 0x00004000 0x1d5a0 0x1d5a0 R E 0x8
LOAD 0x01eaa0 0x80000000 0x80000000 0x00000 0x7dd06 RW 0x8
LOAD 0x01eaa0 0x8007dd08 0x8007dd08 0x00064 0x00064 RW 0x4
LOAD 0x01f000 0x9f000000 0x9f000000 0x00000 0x08000 RW 0x1000
LOAD 0x01f000 0x9f070000 0x9f070000 0x00000 0x1027c RW 0x4

Section to Segment mapping:
Segment Sections...
00 .init_array .ARM.exidx .ARM.extab .ducatiPowerBoot
01 .resetVecs
02 .resource_table
03 .cinit .text .const
04 .stack .bss .neardata .rodata .data.1 .data.2
05 .args
06 .tracebuf
07 .ti_sysbios_family_arm_ducati_smp_Power

I found dts files in my SDK in board-support/linux-<version>/arch/arm/boot/dts, and it looks like there's a Makefile in the folder as well. Should I call make in this folder, or can I just call dtc on the modified dts file? The file I need to modify is am57xx-beagle-x15-common.dtsi which is included by am57xx-beagle-x15.dts, so I'm thinking I can just call "dtc am57xx-beagle-x15.dts" and maybe add "-o am57xx-beagle-x15.dtb" to overwrite the existing dtb file. At that point, can I just replace am57xx-beagle-x15.dtb on my EVM in the folder /boot/, or are there additional steps I need to take? I'm not sure if u-boot factors into this at all, since the SDK also has dts/dtsi files in board-support/u-boot-<version>/

-Jon

I tried regenerating the dtb and got the following error:

ubuntu@ubuntu:~/ti-processor-sdk-linux-am57xx-evm-06.03.00.106/board-support/linux-4.19.94+gitAUTOINC+be5389fd85-gbe5389fd85/arch/arm/boot/dts$ dtc am57xx-beagle-x15.dts
Error: am57xx-beagle-x15.dts:9.1-2 syntax error
FATAL ERROR: Unable to parse input tree

I reverted the changes I made to the included dtsi file and I still got the same error.

I also tried calling make in the directory and got an error as well:

ubuntu@ubuntu:~/ti-processor-sdk-linux-am57xx-evm-06.03.00.106/board-support/linux-4.19.94+gitAUTOINC+be5389fd85-gbe5389fd85/arch/arm/boot/dts$ make
make =/ti
make: *** empty variable name. Stop.
make: *** [Makefile:1267: TI_DTBOS] Error 2

I'm wondering if there is some environment configuration I'm missing, or a different build process that I'm not following.

I solved my uart3 issue with the help of this post: Unable to find which dtb file is in use. - Octavo Systems . It turns out the device tree blob file being used is am57xx-evm-reva3.dtb. I moved the file to my Linux host, then converted it to a dts file with "dtc -I dtb -O dts -o am57xx-evm-reva3_extract.dts am57xx-evm-reva3.dtb" I was then able to modify the serial@48020000 node according to the SDK guide, then recompile with "dtc -I dts -O dtb -o am57xx-evm-reva3.dtb am57xx-evm-reva3_extract.dts". After putting the new dtb file into /boot/ on the evm and rebooting, it no longer seems to be using uart3. However, 1. I'd still like to be able to compile the source and some point, and 2. My "UART example with IPC" binary is still crashing. I'll attach my CCS project to this post in case it helps.UART_BasicExample_evmAM572x_m4ExampleProject_ipc_Jon.zip

Hi Jon,

Regarding build, please refer to the following section for building kernel

https://software-dl.ti.com/processor-sdk-linux/esd/docs/06_03_00_106/linux/Foundational_Components_Kernel_Users_Guide.html

You can just re-build the dtb files after setting up the defconfig.

make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- dtbs

Ofcourse, the dtc back-and-forth conversion is easy if you already have a dtb and just want to make a minor change without going through the normal kernel build.

I will get back to you after Labor Day regarding the other main issue.

regards

Suman

Sounds good. I was able to rebuild the dtb from dts with the method you showed.

Thanks,

Jon

Hi Jon,

Sorry for the delay on getting back on this thread. Is this issue still open?

If it's open, please confirm that you are running this test with the official SDK 6.3 Kernel and U-Boot.

Jon Lake said:

omap-iommu 55082000.mmu: 55082000.mmu: errs:0x00000002 da:0x00000088 pgd:0x851ffc27 *pgd:px95a00002

The trace suggests an MMU Fault, but the decoded value in *pgd does point to the correct physical address 0x95a00000 for the IPU2 device address 0x0. So, it is strange to see this error.

Can you please try changing the firmware link in the FS and doing a reboot without using an unbind and bind.

Jon Lake said:

alloc_contig_range: [95804, 95807) PFNs busy

Want to also not see this trace.

regards

Suman

Hi Suman,

We've been working with one of the DSPs for a couple weeks, but we're going to come back to the M4 soon. I'm still having the same issue, I verified the Linux version 4.19.94-gbe5389fd85 and restarted the EVM (to avoid using unbind/bind), but I'm still seeing similar messages. Here's the printout from dmesg (UART3 is disabled now):

[ 8.426628] remoteproc remoteproc1: powering up 55020000.ipu
[ 8.426646] remoteproc remoteproc1: Booting fw image dra7-ipu2-fw.xem4, size 4788632
[ 8.426718] omap-iommu 55082000.mmu: 55082000.mmu: version 2.1
[ 8.544014] omap-iommu 55082000.mmu: iommu fault: da 0x0 flags 0x0
[ 8.544030] remoteproc remoteproc1: crash detected in 55020000.ipu: type mmufault
[ 8.544054] omap-iommu 55082000.mmu: 55082000.mmu: errs:0x00000002 da:0x00000000 pgd:0x39c2f063 *pgd:px95a00002
[ 8.556676] virtio_rpmsg_bus virtio1: rpmsg host is online
[ 8.556747] remoteproc remoteproc1: registered virtio1 (type 7)
[ 8.556758] remoteproc remoteproc1: remote processor 55020000.ipu is now up
[ 8.556793] remoteproc remoteproc1: handling crash #1 in 55020000.ipu
[ 8.556804] remoteproc remoteproc1: recovering 55020000.ipu
[ 8.583557] remoteproc remoteproc1: stopped remote processor 55020000.ipu
[ 8.583572] remoteproc remoteproc1: powering up 55020000.ipu
[ 8.605881] remoteproc remoteproc1: Booting fw image dra7-ipu2-fw.xem4, size 4788632
[ 8.605961] omap-iommu 55082000.mmu: 55082000.mmu: version 2.1
[ 8.675834] ata1: SATA link down (SStatus 0 SControl 300)
[ 8.677966] omap-iommu 55082000.mmu: iommu fault: da 0x0 flags 0x0
[ 8.677979] remoteproc remoteproc1: crash detected in 55020000.ipu: type mmufault
[ 8.677991] omap-iommu 55082000.mmu: 55082000.mmu: errs:0x00000002 da:0x00000000 pgd:0xd61b3f13 *pgd:px95a00002
[ 8.682643] virtio_rpmsg_bus virtio1: rpmsg host is online
[ 8.682697] remoteproc remoteproc1: registered virtio1 (type 7)
[ 8.682706] remoteproc remoteproc1: remote processor 55020000.ipu is now up

it doesn't seem to be very different from before.

- Jon

Hi Jon,

Can you confirm if you are seeing issues only on IPU2 but not on IPU1? And you are using the dtb from TI SDK right?

regards

Suman