• State Resolved
  • Locked Locked
  • Replies 17 replies
  • Subscribers 102 subscribers
  • Views 1338 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.

PROCESSOR-SDK-AM65X: remoteproc boot failed and crash the kernel module

michael huang1
Prodigy 140 points
Part Number: PROCESSOR-SDK-AM65X

Hi,

I am use the Linux sdk version 07.01.00， when use the "echo start > state" to the remoteproc1. The remoteproc module crashed. The PRU filrmware can be loaded and run by the CCS debug. below is the crash log.  So what is the possible reason for the crash? 

 echo start > state
[   82.937676] remoteproc remoteproc1: powering up b034000.pru
[   82.950590] remoteproc remoteproc1: Booting fw image am65x-pru0_0-fw, size 272824
[   82.958409] Unable to handle kernel paging request at virtual address ffff8000158304a4
[   82.966367] Mem abort info:
[   82.969158]   ESR = 0x96000061
[   82.972287]   EC = 0x25: DABT (current EL), IL = 32 bits
[   82.977628]   SET = 0, FnV = 0
[   82.980673]   EA = 0, S1PTW = 0
[   82.983842] Data abort info:
[   82.986735]   ISV = 0, ISS = 0x00000061
[   82.990578]   CM = 0, WnR = 1
[   82.993563] swapper pgtable: 64k pages, 48-bit VAs, pgdp=0000000082df0000
[   83.000352] [ffff8000158304a4] pgd=00000000dfff0003, pud=00000000dfff0003, pmd=00000000dffe0003, pte=006800000b000707
[   83.010973] Internal error: Oops: 96000061 [#1] PREEMPT SMP
[   83.016533] Modules linqed in: xhci_plat_hcd xhci_hcd usbcore dwc3 udc_core usb_common icssg_prueth icss_iep crct10dif_ce pru_rproc irq_pruss_intc t6
[   83.048164] CPU: 1 PID: 1013 Comm: sh Tainted: G           O      5.4.74-g259a26efa0 #1
[   83.056149] Hardware name: PHYTEC phyCORE-AM65x Carrier Board (DT)
[   83.062318] pstate: 80000005 (Nzcv daif -PAN -UAO)
[   83.067106] pc : __memcpy+0xc0/0x180
[   83.070677] lr : rproc_start+0x8c/0x248
[   83.074502] sp : ffff80001362fc50
[   83.077806] x29: ffff80001362fc50 x28: ffff000058a09b18
[   83.083108] x27: ffff000058a09b38 x26: 00000000ffffffff
[   83.088408] x25: ffff00005339e680 x24: ffff00002255f180
[   83.093709] x23: ffff000058a09838 x22: ffff00002255f180
[   83.099010] x21: ffff000058a09838 x20: ffff8000158304a4
[   83.104310] x19: ffff000058a09800 x18: 0000000000000001
[   83.109611] x17: 0000000000000000 x16: 0000000000000000
[   83.114911] x15: 0000000000000000 x14: ffff00005ef521d0
[   83.120211] x13: ffff00005339e340 x12: 0000000000000007
[   83.125512] x11: 0000000000000038 x10: 0101010101010101
[   83.130812] x9 : 0000000000000520 x8 : 0000000000000000
[   83.136112] x7 : 0000000200000001 x6 : ffff8000158304a4
[   83.141413] x5 : 0000000000002000 x4 : 0000000000000000
[   83.146713] x3 : ffff000050212a80 x2 : fffffffffffffffc
[   83.152013] x1 : ffff00005339ea90 x0 : ffff8000158304a4
[   83.157314] Call trace:
[   83.159756]  __memcpy+0xc0/0x180
[   83.162975]  rproc_boot+0x470/0x510
[   83.166456]  state_store+0x60/0x168
[   83.169940]  dev_attr_store+0x14/0x28
[   83.173598]  sysfs_kf_write+0x40/0x50
[   83.177253]  kernfs_fop_write+0xf8/0x210
[   83.181169]  __vfs_write+0x18/0x40
[   83.184562]  vfs_write+0xdc/0x1c8
[   83.187869]  ksys_write+0x68/0xf0
[   83.191177]  __arm64_sys_write+0x18/0x20
[   83.195095]  el0_svc_common.constprop.0+0x68/0x160
[   83.199876]  el0_svc_handler+0x20/0x80
[   83.203618]  el0_svc+0x8/0x204
[   83.206670] Code: 14000028 f1020042 5400024a a8c12027 (a88120c7)
[   83.212753] ---[ end trace 9fefb3a5f7dfae21 ]---

Thanks and best regards,

Michael

  • 0
    TI__Mastermind 37435 points

    Hi,

    Are you able to use remoteproc to load other modules ? Or is the issue with just PRU firmware ?

    Regards

    Vineet

  • 0 in reply to Vineet Roy
    Prodigy 140 points

    Hi Vineet,

    Thanks for your reply. The remoteproc can load the TI office PRU firmware, like the rpmsg echo demo, but failed to load the firmware that modified from the rpmsg echo demo. I only added some code for my application. And the CCS debug with XDS100 can load the firmware successfully. I have not change the CMD file and resource table file. Now i do not knowm how to find out the root cause for remoteproc crash.

    Best Regards
    Michael

  • 0 in reply to michael huang1
    TI__Expert 5970 points

    Hi Michael,

    If I understand correctly, you are able to load the default PRU firmware coming from SDK.

    However, you are observing crash while loading the PRU firmware that you had built. Is this correct?

    Thanks & Regards,

    Sunita.

  • 0 in reply to Sunita Nadampalli
    Prodigy 140 points

    Hi Sunita,

    Thanks for your reply.

    If i build the the TI demo firmware, it will not crash. Only build my own firmware, it crashed.


    And i have done some try. I found if i define the "struct pru_rpmsg_transport transport;" as a global variable as below, it will crash the remoteproc when be loaded. 

    struct pru_rpmsg_transport transport;

void main(void)
{
	
	uint16_t src, dst, len;
	volatile uint8_t *status;

	/* Clear the status of the PRU-ICSS system event that the ARM will use to 'kick' us */
	CT_INTC.STATUS_CLR_INDEX_REG_bit.STATUS_CLR_INDEX = FROM_ARM_HOST;

	/* Make sure the Linux drivers are ready for RPMsg communication */
	status = &resourceTable.rpmsg_vdev.status;
	while (!(*status & VIRTIO_CONFIG_S_DRIVER_OK));

	/* Initialize the RPMsg transport structure */
	pru_rpmsg_init(&transport, &resourceTable.rpmsg_vring0, &resourceTable.rpmsg_vring1, TO_ARM_HOST, FROM_ARM_HOST);

	/* Create the RPMsg channel between the PRU and ARM user space using the transport structure. */
	while (pru_rpmsg_channel(RPMSG_NS_CREATE, &transport, CHAN_NAME, CHAN_DESC(CHAN_PORT), CHAN_PORT) != PRU_RPMSG_SUCCESS);
	while (1) {
		/* Check bit 30 of register R31 to see if the ARM has kicked us */
		if (__R31 & HOST_INT) {
			/* Clear the event status */
			CT_INTC.STATUS_CLR_INDEX_REG_bit.STATUS_CLR_INDEX = FROM_ARM_HOST;
			/* Receive all available messages, multiple messages can be sent per kick */
			while (pru_rpmsg_receive(&transport, &src, &dst, payload, &len) == PRU_RPMSG_SUCCESS) {
				/* Echo the message back to the same address from which we just received */
				pru_rpmsg_send(&transport, dst, src, payload, len);
			}
		}
	}
}

    Best Regards,
    Michael

  • 0 in reply to michael huang1
    Prodigy 140 points

    HI Sunita,

    I have found if i add the initialize for the variable like below, it can be load successfully.

    struct pru_rpmsg_transport rpmsg_transport = {0};

    So for my firmware, i have try to add initialize for all the global variables. The crash not happened. But failed to load the firmware with return code -22. The error message is :

    /sys/class/remoteproc/remoteproc4# echo start > state
[ 2921.183033] remoteproc remoteproc4: powering up b038000.pru
[ 2921.189716] remoteproc remoteproc4: Booting fw image am65x-pru0_1-fw, size 517888
[ 2921.199058] remoteproc remoteproc4: PRU memory copy failed for da 0x0 memsz 0x30a
[ 2921.206703] remoteproc remoteproc4: Failed to load program segments: -22
[ 2921.213659] remoteproc remoteproc4: Boot failed: -22

     The output map file have data section with below items.

    .data      1    00000000    0000030a     
                  00000000    0000022c     ser.object (.data:ser_rt)
                  0000022c    00000050     ax_ctl.object (.data:ax_rt)
                  0000027c    0000003c     rpmsg.object (.data:rpmsg_transport)
                  000002b8    00000028     ser.object (.data:in_data)
                  000002e0    00000014     ser.object (.data:last_pos$1)
                  000002f4    00000012     ser.object (.data:uva_in_data)
                  00000306    00000004     rpmsg.object (.data:pru_intc_map)

    Do the PRU firmware have some limit to load from linux remoteproc?

    Thanks

    Best Regards,

    Michael

  • 0 in reply to michael huang1
    Prodigy 60 points

    Hi Sunita,

    I also meet the same issue.

    In some of my case, I even initialize the variable, it will also make Linux kernel crash.

    I also meet the returned code -22 issue while loading PRU firmware.

    After traced the kernel code, I found there is a limitation to load PRU firmware.

    static int pru_rproc_memcpy(void *dest, const void *src, size_t count)
{
    ...
    /* limited to 4-byte aligned addresses and copy sizes */
    if ((long)dest % 4 || count % 4)
        return -EINVAL;
    ...
}

    So I declare each struct with "__attribute__ ((aligned (4)))".

    It can solve returned code -22 issue.

  • 0 in reply to Stamp Huang
    Prodigy 140 points

    Hi,

    Thanks for the information to aligned the variables. i think we have the same issues.

    I have align the variables with 4 and solved the return -22 issue.  But also still make the kernel crash.

    Best Regards,

    Michael

  • 0 in reply to michael huang1
    TI__Genius 14775 points

    Hi TI Champs:

    may I have your support regarding this issue?

    BR Rio

  • 0 in reply to Rio Chan
    Prodigy 140 points

    Hi Rio

    Thanks for you reply.

    Yes, what can i do for you ?

    Best Regards,

    Michael

  • 0 in reply to michael huang1
    TI__Mastermind 37435 points

    Hi,

    Sorry for the delay. How are you creating the firmware ELF which is loaded by Remote Proc ?

    Regards

    Vineet

  • 0 in reply to Vineet Roy
    TI__Guru** 111745 points

    Hi Michael,

    Yes, A53 being a 64-bit processor, there are some alignment and size restrictions in using the ARM64 memcpy when writing into PRU IRAMs and Data RAMs, as pointed above by the snippet.

    Are you still seeing a kernel crash after the alignment changes above, and is the signature the same?

    Can you give the output from the command  'readelf -l <firmware>'.

    regards

    Suman 

  • 0 in reply to Suman Anna
    Prodigy 60 points

    Hi Suman,

    In my case, I build my firmware by CCS.

    The compiler version is v2.3.3.

    Below is the output of 'readelf -l <firmware>' from my firmware.

    Elf file type is EXEC (Executable file)

Entry point 0x0

There are 6 program headers, starting at offset 115536



Program Headers:

  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align

  LOAD           0x000034 0x00000000 0x00000000 0x00394 0x00394 R E 0x4

  LOAD           0x0003c8 0x00001000 0x00001000 0x00144 0x00244 RW  0x4

  LOAD           0x00050c 0x00001244 0x00001244 0x00020 0x00020 R   0x1

  LOAD           0x00052c 0x00001264 0x00001264 0x00014 0x00014 RW  0x1

  LOAD           0x000540 0x00010000 0x00010000 0x00000 0x00be8 RW  0x1

  LOPROC+0       0x000540 0x00000000 0x00000000 0x00028 0x00000 R   0



 Section to Segment mapping:

  Segment Sections...

   00     .text:_c_int00* .text .bss

   01     .stack .data

   02     .rodata

   03     .resource_table

   04     .creg.PRU_SHAREDMEM.near

   05     .bss .cio .switch .sysmem .cinit .rofardata .farbss .fardata .creg.PRU0_DMEM_0.noload.near .creg.PRU0_DMEM_0.near .creg.PRU0_DMEM_0.noload.far .creg.PRU0_DMEM_0.far .creg.PRU0_DMEM_1.noload.near .creg.PRU0_DMEM_1.near .creg.PRU0_DMEM_1.noload.far .creg.PRU0_DMEM_1.far .creg.PRU_RTU_RAT0.noload.near .creg.PRU_RTU_RAT0.near .creg.PRU_RTU_RAT0.noload.far .creg.PRU_RTU_RAT0.far .creg.PRU_SHAREDMEM.noload.near .creg.PRU_SHAREDMEM.noload.far .creg.PRU_INTC.noload.near .creg.PRU_INTC.near .creg.PRU_INTC.noload.far .creg.PRU_INTC.far .creg.RTU0_CTRL.noload.near .creg.RTU0_CTRL.near .creg.RTU0_CTRL.noload.far .creg.RTU0_CTRL.far .creg.ICSSG_PROTECT.noload.near .creg.ICSSG_PROTECT.near .creg.ICSSG_PROTECT.noload.far .creg.ICSSG_PROTECT.far .creg.PRU_CFG.noload.near .creg.PRU_CFG.near .creg.PRU_CFG.noload.far .creg.PRU_CFG.far .creg.PRU_CFG_0x100.noload.near .creg.PRU_CFG_0x100.near .creg.PRU_CFG_0x100.noload.far .creg.PRU_CFG_0x100.far .creg.PA_STATS_QRAM.noload.near .creg.PA_STATS_QRAM.near .creg.PA_STATS_QRAM.noload.far .creg.PA_STATS_QRAM.far .creg.PRU_UART.noload.near .creg.PRU_UART.near .creg.PRU_UART.noload.far .creg.PRU_UART.far .creg.TM_CFG_RTU0.noload.near .creg.TM_CFG_RTU0.near .creg.TM_CFG_RTU0.noload.far .creg.TM_CFG_RTU0.far .creg.PA_STATS_CRAM.noload.near .creg.PA_STATS_CRAM.near .creg.PA_STATS_CRAM.noload.far .creg.PA_STATS_CRAM.far .creg.PRU_IEP0.noload.near .creg.PRU_IEP0.noload.far .creg.PRU_IEP0_0x100.noload.near .creg.PRU_IEP0_0x100.near .creg.PRU_IEP0_0x100.noload.far .creg.PRU_IEP0_0x100.far .creg.PRU_IEP1.noload.near .creg.PRU_IEP1.near .creg.PRU_IEP1.noload.far .creg.PRU_IEP1.far .creg.PRU_IEP1_0x100.noload.near .creg.PRU_IEP1_0x100.near .creg.PRU_IEP1_0x100.noload.far .creg.PRU_IEP1_0x100.far .creg.PRU_ECAP.noload.near .creg.PRU_ECAP.near .creg.PRU_ECAP.noload.far .creg.PRU_ECAP.far .creg.MII_RT.noload.near .creg.MII_RT.near .creg.MII_RT.noload.far .creg.MII_RT.far .creg.MII_MDIO.noload.near .creg.MII_MDIO.near .creg.MII_MDIO.noload.far .creg.MII_MDIO.far .creg.MII_G_RT.noload.near .creg.MII_G_RT.near .creg.MII_G_RT.noload.far .creg.MII_G_RT.far .creg.RSVD15.noload.near .creg.RSVD15.near .creg.RSVD15.noload.far .creg.RSVD15.far .creg.RSVD16.noload.near .creg.RSVD16.near .creg.RSVD16.noload.far .creg.RSVD16.far .creg.RSVD17.noload.near .creg.RSVD17.near .creg.RSVD17.noload.far .creg.RSVD17.far .creg.RSVD18.noload.near .creg.RSVD18.near .creg.RSVD18.noload.far .creg.RSVD18.far .creg.RSVD19.noload.near .creg.RSVD19.near .creg.RSVD19.noload.far .creg.RSVD19.far .creg.RSVD20.noload.near .creg.RSVD20.near .creg.RSVD20.noload.far .creg.RSVD20.far .creg.RSVD23.noload.near .creg.RSVD23.near .creg.RSVD23.noload.far .creg.RSVD23.far .creg.RSVD29.noload.near .creg.RSVD29.near .creg.RSVD29.noload.far .creg.RSVD29.far .creg.RSVD30.noload.near .creg.RSVD30.near .creg.RSVD30.noload.far .creg.RSVD30.far .creg.RSVD31.noload.near .creg.RSVD31.near .creg.RSVD31.noload.far .creg.RSVD31.far .TI.phattrs

    Elf file type is EXEC (Executable file)Entry point 0x0There are 6 program headers, starting at offset 115536
    Program Headers:  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align  LOAD           0x000034 0x00000000 0x00000000 0x00394 0x00394 R E 0x4  LOAD           0x0003c8 0x00001000 0x00001000 0x00144 0x00244 RW  0x4  LOAD           0x00050c 0x00001244 0x00001244 0x00020 0x00020 R   0x1  LOAD           0x00052c 0x00001264 0x00001264 0x00014 0x00014 RW  0x1  LOAD           0x000540 0x00010000 0x00010000 0x00000 0x00be8 RW  0x1  LOPROC+0       0x000540 0x00000000 0x00000000 0x00028 0x00000 R   0
     Section to Segment mapping:  Segment Sections...   00     .text:_c_int00* .text .bss   01     .stack .data   02     .rodata   03     .resource_table   04     .creg.PRU_SHAREDMEM.near   05     .bss .cio .switch .sysmem .cinit .rofardata .farbss .fardata .creg.PRU0_DMEM_0.noload.near .creg.PRU0_DMEM_0.near .creg.PRU0_DMEM_0.noload.far .creg.PRU0_DMEM_0.far .creg.PRU0_DMEM_1.noload.near .creg.PRU0_DMEM_1.near .creg.PRU0_DMEM_1.noload.far .creg.PRU0_DMEM_1.far .creg.PRU_RTU_RAT0.noload.near .creg.PRU_RTU_RAT0.near .creg.PRU_RTU_RAT0.noload.far .creg.PRU_RTU_RAT0.far .creg.PRU_SHAREDMEM.noload.near .creg.PRU_SHAREDMEM.noload.far .creg.PRU_INTC.noload.near .creg.PRU_INTC.near .creg.PRU_INTC.noload.far .creg.PRU_INTC.far .creg.RTU0_CTRL.noload.near .creg.RTU0_CTRL.near .creg.RTU0_CTRL.noload.far .creg.RTU0_CTRL.far .creg.ICSSG_PROTECT.noload.near .creg.ICSSG_PROTECT.near .creg.ICSSG_PROTECT.noload.far .creg.ICSSG_PROTECT.far .creg.PRU_CFG.noload.near .creg.PRU_CFG.near .creg.PRU_CFG.noload.far .creg.PRU_CFG.far .creg.PRU_CFG_0x100.noload.near .creg.PRU_CFG_0x100.near .creg.PRU_CFG_0x100.noload.far .creg.PRU_CFG_0x100.far .creg.PA_STATS_QRAM.noload.near .creg.PA_STATS_QRAM.near .creg.PA_STATS_QRAM.noload.far .creg.PA_STATS_QRAM.far .creg.PRU_UART.noload.near .creg.PRU_UART.near .creg.PRU_UART.noload.far .creg.PRU_UART.far .creg.TM_CFG_RTU0.noload.near .creg.TM_CFG_RTU0.near .creg.TM_CFG_RTU0.noload.far .creg.TM_CFG_RTU0.far .creg.PA_STATS_CRAM.noload.near .creg.PA_STATS_CRAM.near .creg.PA_STATS_CRAM.noload.far .creg.PA_STATS_CRAM.far .creg.PRU_IEP0.noload.near .creg.PRU_IEP0.noload.far .creg.PRU_IEP0_0x100.noload.near .creg.PRU_IEP0_0x100.near .creg.PRU_IEP0_0x100.noload.far .creg.PRU_IEP0_0x100.far .creg.PRU_IEP1.noload.near .creg.PRU_IEP1.near .creg.PRU_IEP1.noload.far .creg.PRU_IEP1.far .creg.PRU_IEP1_0x100.noload.near .creg.PRU_IEP1_0x100.near .creg.PRU_IEP1_0x100.noload.far .creg.PRU_IEP1_0x100.far .creg.PRU_ECAP.noload.near .creg.PRU_ECAP.near .creg.PRU_ECAP.noload.far .creg.PRU_ECAP.far .creg.MII_RT.noload.near .creg.MII_RT.near .creg.MII_RT.noload.far .creg.MII_RT.far .creg.MII_MDIO.noload.near .creg.MII_MDIO.near .creg.MII_MDIO.noload.far .creg.MII_MDIO.far .creg.MII_G_RT.noload.near .creg.MII_G_RT.near .creg.MII_G_RT.noload.far .creg.MII_G_RT.far .creg.RSVD15.noload.near .creg.RSVD15.near .creg.RSVD15.noload.far .creg.RSVD15.far .creg.RSVD16.noload.near .creg.RSVD16.near .creg.RSVD16.noload.far .creg.RSVD16.far .creg.RSVD17.noload.near .creg.RSVD17.near .creg.RSVD17.noload.far .creg.RSVD17.far .creg.RSVD18.noload.near .creg.RSVD18.near .creg.RSVD18.noload.far .creg.RSVD18.far .creg.RSVD19.noload.near .creg.RSVD19.near .creg.RSVD19.noload.far .creg.RSVD19.far .creg.RSVD20.noload.near .creg.RSVD20.near .creg.RSVD20.noload.far .creg.RSVD20.far .creg.RSVD23.noload.near .creg.RSVD23.near .creg.RSVD23.noload.far .creg.RSVD23.far .creg.RSVD29.noload.near .creg.RSVD29.near .creg.RSVD29.noload.far .creg.RSVD29.far .creg.RSVD30.noload.near .creg.RSVD30.near .creg.RSVD30.noload.far .creg.RSVD30.far .creg.RSVD31.noload.near .creg.RSVD31.near .creg.RSVD31.noload.far .creg.RSVD31.far .TI.phattrs

  • 0 in reply to Suman Anna
    Prodigy 140 points

    HI Suman,

    The kernel will be still crash when i load the firmware as the alignment changed.

    Below is the output of the readelf -l 

    Elf file type is EXEC (Executable file)
Entry point 0x0
There are 6 program headers, starting at offset 267256

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x000034 0x00000000 0x00000000 0x009e0 0x009e0 R E 0x4
  LOAD           0x000a14 0x000009e0 0x000009e0 0x00000 0x0001c RW  0x1
  LOAD           0x000a14 0x00000000 0x00000000 0x00248 0x00448 RW  0x4
  LOAD           0x000c5c 0x00000448 0x00000448 0x0007c 0x000f4 RW  0x1
  LOAD           0x000cd8 0x0000053c 0x0000053c 0x0003c 0x0003c R   0x4
  LOPROC+0       0x000d14 0x00000000 0x00000000 0x00020 0x00000 R   0

 Section to Segment mapping:
  Segment Sections...
   00     .text:_c_int00* .text .stack .bss 
   01     .share_buff 
   02     .stack .data 
   03     .bss .resource_table 
   04     .rodata 
   05     .cio .switch .sysmem .cinit .rofardata .farbss .fardata .creg.PRU0_DMEM_0.noload.near .creg.PRU0_DMEM_0.near .creg.PRU0_DMEM_0.noload.far .creg.PRU0_DMEM_0.far .creg.PRU0_DMEM_1.noload.near .creg.PRU0_DMEM_1.near .creg.PRU0_DMEM_1.noload.far .creg.PRU0_DMEM_1.far .creg.PRU_RTU_RAT0.noload.near .creg.PRU_RTU_RAT0.near .creg.PRU_RTU_RAT0.noload.far .creg.PRU_RTU_RAT0.far .creg.PRU_SHAREDMEM.noload.near .creg.PRU_SHAREDMEM.near .creg.PRU_SHAREDMEM.noload.far .creg.PRU_SHAREDMEM.far .creg.PRU_INTC.noload.near .creg.PRU_INTC.noload.far .creg.PRU0_CTRL.noload.near .creg.PRU0_CTRL.near .creg.PRU0_CTRL.noload.far .creg.PRU0_CTRL.far .creg.ICSSG_PROTECT.noload.near .creg.ICSSG_PROTECT.near .creg.ICSSG_PROTECT.noload.far .creg.ICSSG_PROTECT.far .creg.PRU_CFG.noload.near .creg.PRU_CFG.near .creg.PRU_CFG.noload.far .creg.PRU_CFG.far .creg.PRU_CFG_EXT.noload.near .creg.PRU_CFG_EXT.near .creg.PRU_CFG_EXT.noload.far .creg.PRU_CFG_EXT.far .creg.PA_STATS_QRAM.noload.near .creg.PA_STATS_QRAM.near .creg.PA_STATS_QRAM.noload.far .creg.PA_STATS_QRAM.far .creg.PRU_UART.noload.near .creg.PRU_UART.near .creg.PRU_UART.noload.far .creg.PRU_UART.far .creg.TM_CFG_PRU0.noload.near .creg.TM_CFG_PRU0.near .creg.TM_CFG_PRU0.noload.far .creg.TM_CFG_PRU0.far .creg.PA_STATS_CRAM.noload.near .creg.PA_STATS_CRAM.near .creg.PA_STATS_CRAM.noload.far .creg.PA_STATS_CRAM.far .creg.PRU_IEP0.noload.near .creg.PRU_IEP0.near .creg.PRU_IEP0.noload.far .creg.PRU_IEP0.far .creg.PRU_IEP0_EXT.noload.near .creg.PRU_IEP0_EXT.near .creg.PRU_IEP0_EXT.noload.far .creg.PRU_IEP0_EXT.far .creg.PRU_IEP1.noload.near .creg.PRU_IEP1.near .creg.PRU_IEP1.noload.far .creg.PRU_IEP1.far .creg.PRU_IEP1_EXT.noload.near .creg.PRU_IEP1_EXT.near .creg.PRU_IEP1_EXT.noload.far .creg.PRU_IEP1_EXT.far .creg.PRU_ECAP.noload.near .creg.PRU_ECAP.near .creg.PRU_ECAP.noload.far .creg.PRU_ECAP.far .creg.MII_RT.noload.near .creg.MII_RT.near .creg.MII_RT.noload.far .creg.MII_RT.far .creg.MII_MDIO.noload.near .creg.MII_MDIO.near .creg.MII_MDIO.noload.far .creg.MII_MDIO.far .creg.MII_G_RT.noload.near .creg.MII_G_RT.near .creg.MII_G_RT.noload.far .creg.MII_G_RT.far .creg.RSVD15.noload.near .creg.RSVD15.near .creg.RSVD15.noload.far .creg.RSVD15.far .creg.RSVD16.noload.near .creg.RSVD16.near .creg.RSVD16.noload.far .creg.RSVD16.far .creg.RSVD17.noload.near .creg.RSVD17.near .creg.RSVD17.noload.far .creg.RSVD17.far .creg.RSVD18.noload.near .creg.RSVD18.near .creg.RSVD18.noload.far .creg.RSVD18.far .creg.RSVD19.noload.near .creg.RSVD19.near .creg.RSVD19.noload.far .creg.RSVD19.far .creg.RSVD20.noload.near .creg.RSVD20.near .creg.RSVD20.noload.far .creg.RSVD20.far .creg.RSVD23.noload.near .creg.RSVD23.near .creg.RSVD23.noload.far .creg.RSVD23.far .creg.RSVD29.noload.near .creg.RSVD29.near .creg.RSVD29.noload.far .creg.RSVD29.far .creg.RSVD30.noload.near .creg.RSVD30.near .creg.RSVD30.noload.far .creg.RSVD30.far .creg.RSVD31.noload.near .creg.RSVD31.near .creg.RSVD31.noload.far .creg.RSVD31.far .TI.phattrs

    Best Regards,

    Michael

  • 0 in reply to Vineet Roy
    Prodigy 140 points

    HI Vineet,

    I use the Makefile from the TI demo to create the firmware ELF.

    Your can re-generate this issue by set the "struct pru_rpmsg_transport transport;" to a global variable in the PRU echo demo in the example directory.

    Best Regards,

    Michael

  • 0 in reply to michael huang1
    TI__Guru** 111745 points

    Hi Michael,

    Thanks for the repro scenario. I am able to reproduce the error, and a quick check shows that the issue is not with the ELF segments themselves. They were copied fine, and the crash is happening afterwards during the copying of the resource table into the actual firmware address in rproc_start.

    You can avoid the crash by ensuring the .resource_table section is aligned on 8-byte addresses. Just adjust the linker command file for the alignment, something like

    .resource_table : ALIGN (8) > PRO0_DMEM_0, PAGE 1

    regards

    Suman

       

  • 0 in reply to Suman Anna
    Prodigy 140 points

    Hi Suman,

    Thanks so much.  It solved my issue.

    Best Regards,

    Michael

  • 0 in reply to Suman Anna
    Prodigy 60 points

    Hi Suman,

    It also solved my issue.

    Thanks!