AM437x could not boot PRU

Cindy Lin

Hi:

platform: AM437X-GP-EVM

SDK version: 1.00.00.03

kernel verison: 3.16.43

Due to we need to control the timing presicely, insdead of using C/C++ , we choose assembly code to development the code for PRU.

And according to the new architecture for PRU firmware downloading, the oldest API "prussdrv_exec_program" is not supported.

For the new architecture, remoteproc_pruss driver will check the existence for resource table, if the resource table is exist, then boot the PRU core.

We tried to add a fake .resource_table.h file to CCS project, and the tag "resource_table" are also appended to the SECTION which is located in AM437x.cmd file.

But the kernel log shows as the following:

root@am437x-evm:/lib/modules# insmod pruss_remoteproc.ko 
[   47.421051] pruss-rproc 54400000.pruss: memory    dram0: pa 0x54400000 size 0x2000 va f01f8000
[   47.430644] pruss-rproc 54400000.pruss: memory    dram1: pa 0x54402000 size 0x2000 va f01fc000
[   47.439736] pruss-rproc 54400000.pruss: memory shrdram2: pa 0x54410000 size 0x8000 va f0310000
[   47.448773] pruss-rproc 54400000.pruss: memory     intc: pa 0x54420000 size 0x2000 va f0304000
[   47.457794] pruss-rproc 54400000.pruss: memory      cfg: pa 0x54426000 size 0x2000 va f0308000
[   47.466978] pruss-rproc 54400000.pruss: creating platform devices for PRU cores
[   47.483000] pruss-rproc 54400000.pruss: creating platform devices for PRU cores ret = 0
[   47.508411] platform sound@0: Driver asoc-simple-card requests probe deferral
[   47.521168] pru-rproc 54434000.pru0: memory     iram: pa 0x54434000 size 0x3000 va f030c000
[   47.548528] pru-rproc 54434000.pru0: memory  control: pa 0x54422000 size 0x400 va f01f6000
[   47.558194] pru-rproc 54434000.pru0: memory    debug: pa 0x54422400 size 0x100 va f0302400
[   47.567127]  remoteproc1: 54434000.pru0 is available
[   47.572221]  remoteproc1: Note: remoteproc is still under development and considered experimental.
[   47.581245]  remoteproc1: THE BINARY FORMAT IS NOT YET FINALIZED, and backward compatibility isn't yet guaranteed.
[   47.594474]  remoteproc1: header-less resource table
[   47.599581] pru-rproc 54434000.pru0: booting the PRU core manually
[   47.606507]  remoteproc1: powering up 54434000.pru0
[   47.611988]  remoteproc1: table_ptr is NULL
[   47.616249]  remoteproc1: rproc_fw_boot ret = -12
[   47.621025] pru-rproc 54434000.pru0: rproc_boot failed
[   47.626954]  remoteproc1: releasing 54434000.pru0
[   47.632351] pru-rproc: probe of 54434000.pru0 failed with error -12

After checking the content of the PRU firmware which is indicates by the below list, we found that the size for resource table is zero.

So the log for " remoteproc1: header-less resource table" is quite reasonable, and it may give us a hint: to include the resouce_table_0.h to a assembly project is not the solution.

cindylin@linuxserver-OptiPlex-9020:~/img_sdcard_1.03$ readelf -S PTO_ICSS0_PRU0_v0.5.1_GP.out
There are 24 section headers, starting at offset 0x3100:

Section Headers:
[Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
[ 0]                   NULL            00000000 000000 000000 00      0   0 0
[ 1] .text:_c_int00    NOBITS          00000000 000d08 000000 00 AX 0   0 1
[ 2] .text             PROGBITS        00000000 000034 000cd4 00 AX 0   0 4
[ 3] .bss              NOBITS          00000000 000d08 000000 00 WA 0   0 1
[ 4] .data             NOBITS          00000000 000d08 000000 00 WA 0   0 1
[ 5] .rodata           NOBITS          00000000 000d08 000000 00   A 0   0 1
[ 6] .sysmem           NOBITS          00000000 000000 000000 00      0   0 1
[ 7] .stack            NOBITS          00000000 000000 000000 00      0   0 1
[ 8] .init_array       NOBITS          00000000 000d08 000000 00 WA 0   0 1
[ 9] .cinit            NOBITS          00000000 000000 000000 00      0   0 1
[10] .args             NOBITS          00000000 000000 000000 00      0   0 1
[11] .resource_table   NOBITS          00000000 000000 000000 00      0   0 1
[12] .debug_info       PROGBITS        00000000 000d08 00004d 00      0   0 1
[13] .debug_line       PROGBITS        00000000 000d55 000381 00      0   0 1
[14] .debug_abbrev     PROGBITS        00000000 0010d6 000033 00      0   0 0
[15] .debug_str        PROGBITS        00000000 001109 0000eb 00      0   0 0
[16] .debug_aranges    PROGBITS        00000000 0011f4 000038 00      0   0 0
[17] .debug_pubnames   PROGBITS        00000000 00122c 00005c 00      0   0 0
[18] __TI_build_attrib LOPROC+3        00000000 001288 00002d 00      0   0 0
[19] .symtab           SYMTAB          00000000 0012b8 000f60 10     22 243 0
[20] .TI.section.flags LOPROC+f000005 00000000 002218 00001d 00      0   0 0
[21] .TI.section.page LOPROC+f000007 00000000 002235 00001a 00      0   0 0
[22] .strtab           STRTAB          00000000 00224f 000d8b 01   S 0   0 0
[23] .shstrtab         STRTAB          00000000 002fda 000104 01   S 0   0 0

Please give me some advise, thanks,

over 10 years ago

0 Biser Gatchev-XID over 10 years ago

TI__Guru**** 393215 points

Hi Cindy,

I will ask the PRU experts to help on this.

0 Jason Reeder over 10 years ago in reply to Biser Gatchev-XID

TI__Genius 10440 points

Cindy,

It appears that the pruss_remoteproc loader found your resource_table section but that it did not contain the header it expected (most likely because it was empty). Try making your 'fake' resource_table.h file look like the one found in this link: https://git.ti.com/pru-software-support-package/pru-software-support-package/blobs/dev/examples/PRU_MAC_Multiply_Accum/resource_table_empty.h

Even when you don't need the resource table to request any resources it still needs to conform to the format that the loader expects. The empty resource table in the link will contain the header information that your error message is implying is not there.

Jason Reeder

0 Cindy Lin over 10 years ago in reply to Jason Reeder

Prodigy 160 points

Hi Jason:

Thank for your reply.

Q1:

We tried to build with the .h file as you provided.

And the size resource_table is 0.

According to the pdf : http://www.ti.com/lit/ug/spruhv6a/spruhv6a.pdf

It seems that the pragma have no effect for project built with asm. <-- If it is wrong, please correct me, thanks.

0 Jason Reeder over 10 years ago in reply to Cindy Lin

TI__Genius 10440 points

Cindy,

I used the attached assembly code with the attached command linker file and made a firmware that I could load into PRU0 or PRU1 using the pruss_remoteproc.ko module.

Basically, I grabbed the resource table section from a generated assembly file and put it as the top of my main.asm file.

main.asm

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/791/AM335x_5F00_PRU.cmd

Jason Reeder

0 Cindy Lin over 10 years ago in reply to Jason Reeder

Prodigy 160 points

Hi Jason:
I've modified the .dts file as the following
pruss_pins: pruss_pins {
pinctrl-single,pins = <
0x190 MUX_MODE5
0x194 MUX_MODE5
0x198 MUX_MODE5
0x19C MUX_MODE5
0x1D0 MUX_MODE3
0x1A0 MUX_MODE5
0x1DC 0x03
>;
};
&pruss {
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <&pruss_pins>;
};

and run the CCS project

the source code for the project is as below

void main(){

volatile uint32_t gpio;

CT_CFG.SYSCFG_bit.STANDBY_INIT = 0;
CT_CFG.GPCFG0 = 0x0000;

/* Toggle GPO pins TODO: Figure out which to use */
gpio = 0xFFFF;

/* TODO: Create stop condition, else it will toggle indefinitely */

while(1){
__R30 |= gpio;
__delay_cycles(100000000);
}

/* Halt the PRU core */
__halt();
}

but it is still failed to pull high the GPIOs.

0 Christian Gmeiner over 9 years ago in reply to Jason Reeder

Prodigy 40 points

Hello Jason,

I'm just working on a project for the PRU which is written in pure assembly, therefore I used your resource_table example which works fine.

But now I'm at the point where I need to port the interrupt channel map, but there are only examples of this channel map which are written in c.

I don't get it how to integrate the channel map to my assembly resource_table.

Could you post an example for an interrupt channel map?

Christian

0 Jason Reeder over 9 years ago in reply to Christian Gmeiner

TI__Genius 10440 points

Christian,

You can build one of the provided C examples that includes a channel mapping in the resource table and then look at the generated assembly. Use the -k flag during compilation and the compiler will keep the generated assembly code.

Jason Reeder

Processors

Processors forum

AM437x could not boot PRU