Greg and Zach,
Check out the two tarballs in this drive link:
https://drive.google.com/drive/folders/0B_OVOhSEksP8MDFiT0x6YU1EZG8?usp=sharing
- PRU_Halt_Assembly.tar.gz
- Contains a project to drop into
/opt/source/pru-software-support-package/examples/am335x/ that is an
assembly only project
- There are only two parts to the main.asm file: an empty resource
table at the top (mandatory for RemoteProc loading) and a main function
that writes '0xdeadbeef' to address 0x4a310000 and then halts.
- I created this assembly file by first writing the program in C,
compiling it with the '-k' compiler option to keep the generated
assembly,
and then removing all the unnecessary generated comments
- Make it on target using the included Makefile (I modified the
Makefile to build both .c and .asm files before linking)
-
cd
/opt/source/pru-software-support-package/examples/am335x/PRU_Halt_Assembly/
- export PRU_CGT=/usr/share/ti/cgt-pru
- ln -s /usr/bin/ /usr/share/ti/cgt-pru/bin
- make
- (generated files will be in the 'gen' folder
- Add a symbolic link from /lib/firmware/am335x-pru1-fw
- cd /lib/firmware/
- rm am335x-pru1-fw
- ln -s
/opt/source/pru-software-support-package/examples/am335x/PRU_Halt_Assembly/gen/PRU_Halt_Assembly.out
am335x-pru1-fw
- Reload the firmware in PRU 1
- echo 4a338000.pru1 > /sys/bus/platform/drivers/pru-rproc/unbind
- echo 4a338000.pru1 > /sys/bus/platform/drivers/pru-rproc/bind
- Check that the firmware actually ran by seeing if '0xdeadbeef' has
been written to 0x4a310000 (I use devmem2 for this and I am logged in as
root)
- cd ~/
- wget http://free-electrons.com/pub/mirror/devmem2.c
- gcc devmem2.c -o devmem2
- ./devmem2 0x4a310000
- (output should say '0xdeadbeef' is at that address)
- PRU_Halt_Mixed.tar.gz
- Contains a project to drop into
/opt/source/pru-software-support-package/examples/am335x/ that is a C
program that calls a function that is defined in an assembly file
- main.c contains a C program that calls a function that takes an
integer as a parameter and returns an integer as a result
- assembly_loop.asm is an assembly file that contains a single
function which can be called by a C program (which is what main.c does)
- the loop is mostly nonsense but shows how to take a parameter in
an assembly function as well as how to return a result
- Make it on target using the included Makefile (I modified the
Makefile to build both .c and .asm files before linking)
-
cd
/opt/source/pru-software-support-package/examples/am335x/PRU_Halt_Mixed/
- export PRU_CGT=/usr/share/ti/cgt-pru
- ln -s /usr/bin/ /usr/share/ti/cgt-pru/bin
- make
- (generated files will be in the 'gen' folder
- Add a symbolic link from /lib/firmware/am335x-pru1-fw
- cd /lib/firmware/
- rm am335x-pru1-fw
- ln -s
/opt/source/pru-software-support-package/examples/am335x/PRU_Halt_Mixed/gen/PRU_Halt_Mixed.out
am335x-pru1-fw
- Reload the firmware in PRU 1
- echo 4a338000.pru1 > /sys/bus/platform/drivers/pru-rproc/unbind
- echo 4a338000.pru1 > /sys/bus/platform/drivers/pru-rproc/bind
- Check that the firmware actually ran by seeing if address
0x4a310000 contains the integer passed to the function in the C file
minus
1 (I use devmem2 for this and I am logged in as root)
- ./devmem2 0x4a310000
- (output should be the parameter passed to the C function in
main.c minus 1)
Let me know if any of this doesn't make sense. These two projects should
cover assembly only projects, as well as C programs where you want to write
one of the functions in assembly.
Jason Reeder
On Monday, November 28, 2016 at 7:52:16 PM UTC-6, Greg wrote:
>
> I believe asmpru is the assembler code compiler which is part of the PRU
> compilation system which is described in the C/C++ Compiler manual.
>
> pasm is the older assembler which existed prior to the C compiler.
> There are differences in the assembly instructions used with pasm versus
> the more recent asmpru.
>
> I believe clpru actually uses asmpru in the compilation process of C code.
>
> Check out this discussion, especially the link to the pasm to clpru
> porting guide:
>
>
> https://groups.google.com/forum/#!searchin/beagleboard/mark$20yoder$20pasm%7Csort:relevance/beagleboard/vuxsX_oMzkM/UjNIYWiKAQAJ
>
> On Monday, November 28, 2016 at 4:49:46 PM UTC-5, Zach B wrote:
>>
>> Greg,
>>
>> Thanks for the info. That linker primer helped a bit with what is exactly
>> going on inside of the linker, at least to the level that I can understand.
>> I'm still working through getting a single assembly file to work but for
>> now I figured out a workaround with an empty c file. What is asmpru? I only
>> know about "clpru" and "pasm".
>>
>>
>> Is it possible to load firmware into the PRU, start and stop it for
>> testing and then reload new software without having to reboot? Whenever I
>> stop the PRU and go to remove pru_rproc with "rmmod" or "modprobe -r" I get
>> a message that it is still in use. In order to get around that I just
>> restart the system after copying my new firmware file to /lib/firmware, but
>> is there another way around this? As far as I can tell the PRU is not
>> running when I try to unload/remove pru_rproc. Also when exactly is the pru
>> firmware loaded into the PRU, is it when the system boots or when "modprobe
>> pru_rproc" is called and the remoteproc is started?
>>
>
--
For more options, visit http://beagleboard.org/discuss
---
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/beagleboard/502e0a9a-ad29-444b-bb0b-d1ca274e320c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
