The "combined" image is actually a standard ELF file. You may load and 
parse it yourself using libelf. Here is an example for pru-gcc that loads 
an ELF image, extracts IMEM and DMEM sections, and feeds them to the UIO 

I have not tested it, but in theory it should also work with TI's toolchain.


On Friday, September 16, 2016 at 7:02:10 PM UTC+3, 
> Hi,
>   Wondering if anyone can help. I had the Remote Proc/RpMsg working 
> passing data to and fro. However I liked the functionality of uio_pruss so 
> I have updated my kernel to 4.4.20-ti-r44 following advice from some of the 
> guys on the board. Thanks to all who responded last time, uio_pruss is what 
> I need.
> So I have rebuilt my device tree to include am33xx-pruss-io.dtsi. and 
> installed under the kernel directory in /boot/dtbs. I reboot and when I run 
> lsmod I can see the three uio kernel objects. I am sure it is using the 
> rebuilt device tree because I turned off the heartbeat on the USR0 led as a 
> test in the am335x-common.dtsi. It isn't toggling anymore. 
> I have built an example PRU program, PRU_LED0. I have setup the hex 
> utility to run the following cmd file
> --b
> --image
> ROMS {
>                 PAGE 0:
>                 .text: o = 0x0, l = 0x2000, files={text.bin}
>                 PAGE 1:
>                 .data: o = 0x0, l = 0x2000, files={data.bin}
> }
> I have an error, if I use this it complains 'not enough files for ".text" 
> and ".data". So I removed the files command to make it like what I built 
> for Remotew Proc/RpMsg and it builds a _image.obj. Trouble is that it is 
> the test and data combined. The rp_proc loader I think can split the file 
> and load text and data. However I can't see a way to split them for using 
> with uio_pruss which calls prussdrv_exec_program and 
> prussdrv_load_datafile. 
> Is there a utility or macro I could use to find the data and text portions 
> of the image obj and split them ?
> I am pretty sure this is the problem. I took portions of the 
> prussdrv_exec_program function into my programm to see where the calls 
> fails. I seem to be able to run prussdrv_pru_disable. It is failing at 
> prussdrv_pru_write_memory, just before it calls prussdrv_pru_enable_at to 
> run the code.
> Fustrating... I am sure I am missing something obvious.
> Cheers,
> Paul

For more options, visit
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
To view this discussion on the web visit
For more options, visit

Reply via email to