uio_pruss.c question

Baas: the PRU core needs to notify the Cortex-A8 and Linux that something has happened. There is no other way to do this other then to poll the PRU RAM or some other memory space. The UIO driver allows a block reading that blocks until a interrupt occurs, you’d have to poll here instead. Communicating with userspace isn’t really the issue.

Someone starting with PRU coding can postpone the trouble of getting the interrupt system working. That’s why I suggested using another approach, e.g. polling first. If needed, the polling (of shared memory) can be done in a separate thread, just as the blocking wait probably would. Depending on you application, the interrupt passing may be necessary or not at all.

– Bas

I was able to find the PRUSS reset bit documentation working backward from address 0x44E00C00.
What's the best way to figure these addresses out?

The AM335x Technical Resource Manual. Be prepared to do some math, though:

PRUSS1's base address is 0x4A300000. You know this from the L4 map in
chapter 2 (see table 2-4 and look for PRUSS1).

Chapter 4 section 2 has a table "Global Memory Map" that tells you
that the PRU0 DEBUG is offset 0x00022400 (for PRU1 it would be
0x00024400).

Next go to chapter 4 section 5 and look for the table "PRUSS_PRU_DEBUG
Registers" -- I'm looking at Rev C and it's table 4.5.5. That tells
you that GPREG1 (which is the debug register that shows you what's in
R1) is offset 4.

Putting those all together, PRU1's r1 register can be read at 0x4a322404.

At one point in time I had written a shell script that sets up aliases
for these registers as commands, so you can just type "r0" at a prompt
and it will show you. I will try to find that.

Christopher,

Thank you for the information about how to read the manual! :slight_smile: And if you find that shell script it sounds very useful!

Here’s how far I’ve gotten this evening…

sandbox.p

I’m forwarding this email to the list as requested by the sender. Lots of useful information! Thanks, Rob!

If your code appears like it might be running or it might not, someone else’s suggestion that the code is really loaded (when the pru is not in reset) is the right place to start. If the code appears to be loaded, my next troubleshooting tip is this:

The PRU has a “single step” mode in it, and it can be helpful. You access it through the CONTROL register, see section 4.5.4 under “Control Register.” In order to run your program you must have taken it out of reset by setting the ENABLE bit to 1. If instead you write both enable AND the SINGLE_STEP bits at the same time then the PRU should advance one instruction. You can look at the next register up (STATUS) and watch that PCOUNTER has moved.

I mentioned earlier that I wrote a script I found helpful for this sort of thing. It’s simple and obvious, but maybe I can save you the time of figuring it out by pasting it below. Save it as a file, and then use the shell import:

. pruAliases.sh

and it will make a bunch of aliases. I use bash; if you use something else, YMMV. There are aliases for looking at imem as well, at least the first few instructions.

For interested kibitzers, the base address here is for the AM335x … if you use something else this will likely be wrong.

Someone suggested playing some games with grep, etc. to clean up the devmem2 output. Good idea.

Guys I’m sorry I haven’t made much progress on my PRU debugger. I’ll try to spend some time on it this week to get it at least functional for displaying registers.

################### AM335x ###################

alias control0=“devmem2 0x4a322000 w”

alias status0=“devmem2 0x4a322004 w”
alias wakeup_en0=“devmem2 0x4a322008 w”
alias cycle0=“devmem2 0x4a32200C w”
alias stall0=“devmem2 0x4a322010 w”
alias r0-0=“devmem2 0x4a322400 w”
alias r1-0=“devmem2 0x4a322404 w”
alias r2-0=“devmem2 0x4a322408 w”
alias r3-0=“devmem2 0x4a32240C w”
alias r4-0=“devmem2 0x4a322410 w”
alias r30-0=“devmem2 0x4a322478 w”
alias r31-0=“devmem2 0x4a32247C w”

alias control1=“devmem2 0x4a324000 w”

alias status1=“devmem2 0x4a324004 w”
alias wakeup_en1=“devmem2 0x4a324008 w”
alias cycle1=“devmem2 0x4a32400C w”
alias stall1=“devmem2 0x4a324010 w”
alias r0-1=“devmem2 0x4a324400 w”
alias r1-1=“devmem2 0x4a324404 w”
alias r2-1=“devmem2 0x4a324408 w”
alias r3-1=“devmem2 0x4a32440C w”
alias r4-1=“devmem2 0x4a324410 w”
alias r30-1=“devmem2 0x4a324478 w”
alias r31-1=“devmem2 0x4a32447C w”

alias imem0="
devmem2 0x4a334000
devmem2 0x4a334004
devmem2 0x4a334008
devmem2 0x4a33400C
devmem2 0x4a334010
devmem2 0x4a334014
devmem2 0x4a334018
devmem2 0x4a33401C
"
alias dmem0="
devmem2 0x4a300000
devmem2 0x4a300004
devmem2 0x4a300008
devmem2 0x4a30000C
"
alias imem1="
devmem2 0x4a338000
devmem2 0x4a338004
devmem2 0x4a338008
devmem2 0x4a33800C
devmem2 0x4a338010
devmem2 0x4a338014
devmem2 0x4a338018
devmem2 0x4a33801C
"
alias dmem1="
devmem2 0x4a302000
devmem2 0x4a302004
devmem2 0x4a302008
devmem2 0x4a30200C
"

Hi guys, have been following these PRU threads closely.

Thanks to Jerril for forwarding my post… and thanks Christopher for confirming i’m checking the PRU’s instruction memory contents correctly.

Using my own “test” code very similar to Jerril’s, and also the TI demos (eg. PRU_memCopy etc) I dont seem to be able to load code into the PRU’s instruction memory. In all cases using TI’s app_loader/interface/prussdrv.c library.

I did some more investigations that might help others.

Using the uio_pruss kernel module from Anstrom kernel uImage-3.2-r9a+gitr09e9651bcf2ee8d86685f2a8075bc6557b1d3b91-beaglebone-20120415071250.bin

Firstly a bash definition to clean up devmem2’s output:

dm(){ devmem2 $1 w $2 | sed -n 3p | awk ‘{ print $6 }’ ;}
I’ve added that to ~/.bashrc
The first parameter is the global address, the second optional one is the value to set it to.

Remove the PRU from reset:
dm 0x44E00C00 0

To simplify things, i created test.p very similar to Jerrils, compiled with PASM.

“Changed PRUSS to Programmable Real-Time Unit and Industiral Communication Subsystem (PRU-ICSS).”

Woah!!!

I will ask about this on E2E.

--Chris

Those interested can follow the E2E discussion here:

http://e2e.ti.com/support/dsp/sitara_arm174_microprocessors/f/416/t/163158.aspx

I’ve also contacted TI through my day job contacts to see if I can get any information as well.

Jerrill

I have received word to not panic, an addendum is forthcoming -- PRU
docs may have simple been relocated.

Good to hear :slight_smile:

The only thing that’s missing from the pasm v1 AFAIK is support for SXIN/SXOUT/SXCHG, NOP0-F and XFR bus ID-s for the scratch registers and the multiplier unit.
All other instructions are supported.

Hi all,

Here is the response I received from TI:

My contact said that the new documentation isn’t expected to be released until the May 1 to June 1 time frame.

So, I guess I’ll hold on to my Rev C TRM and press on! :slight_smile:

Jerrill

Well it looks like the __prussdrv.h included in prussdrv.c is the culprit. Apparently, the included library is configured for another device. I was able to make the following changes for the BeagleBone (AM3558) in app_loader/interface/__prussdrv.h and get my code loaded into the PRUSS correctly:

Here is some additional information from TI: