Hi Christopher,
I've been wondering myself about this implementation too. If you look at
this code (and at an older version) you'll see that the second (mem[1])
region used to point to on-chip SRAM, for which there is no
implementation for the 335x (yet?). It looks like someone just removed
the line with the p->mem[1].addr assignment and a leading blank line. So
I'm not sure about the state of this driver...
FYI: If you tweak the right registers the PRUSS can be used and the old
pasm produces working code. I've been able to modulate ('glow') one of
the user leds, depending on the system load. So communcation from user
space to a PRU and from that PRU to GPIO can be done. But beware, the
PRU - like a DMA controller - has access to almost the entire memory
map, and it's very easy to overwrite kernel code or other data by mistake.
--- Bas
No, the old pasm just works. You'll need to tweak some settings to
enable the PRUSS submodule, give it a clock, clock the outgoing bus, set
some power management options. It's a steep learning curve but it can be
done ;-)
>
> I'm really happy to know somebody besides me is thinking about these
> things.
>
There are more. I can't image all the others have given up already, so
ask your questions and you might get an answer.
--- Bas
First of all, it's (uio_pruss.c) not really a driver. The only thing it
does is to make the PRUSS I/O space available for a userspace driver.
The latter has to be written by you and takes complete control over the
PRUSS (i.e. both PRUs). You should also be able to get events from the
PRUSS to userspace, but I haven't tried that yet.
So yes, you should be able to run two independent userspace drivers, but
you might run into problems accessing the parts that are shared by both
PRUs (locking, atomic access, synchronization etc.).
--- Bas
There are several bits that need to be set correctly. This may solve the
clock issue, but I just tried with a recent the 3.2.0+ kernel and the
PRUSS is left with the reset asserted, so you'll only get bus errors
accessing the PRUSS I/O map. Also, if you want to access peripherals
that are not connected to the PRU, you'll have to enable the clock for
the outgoing bus first.
>
> On the PRU wiki exists a kernel patch that touches these files (just
> the source files)
>
> * arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
> * arch/arm/mach-davinci/devices-da8xx.c
> * arch/arm/mach-davinci/include/mach/da8xx.h
> * drivers/uio/uio_pru.c
>
> However, those are all for different devices - I'm working on AM3359
> whose arch is I believe mach-omap2. What I'm not sure of is whether
> or not that machine type somehow inherits from davinci.
>
> Looking at that patch in detail a lot of what it does is add platform
> resources. I don't see that in my kernel, and I'm going to have to
> figure that out.
>
> $ grep -R platform_device_register arch/arm/* | grep -i pru
>
> returns nothing, making me think the support isn't there, and I may
> have to make my own patch that does what the davinci one does.
>
> Does this sound like the right track?
There's a lot of work in progress wrt the arm port. But little
documentation and it's a moving target.
If you have a schedule to meet I suggest you skip all the nice clock
setting schemes that are being implemented and do direct access to the
corresponding registers from a kernel driver.
--- Bas
--- Bas
-- To join: http://beagleboard.org/discuss
To unsubscribe from this group, send email to:
beagleboard...@googlegroups.com
Frequently asked questions: http://beagleboard.org/faq
1) Am I even on the right track?
3) Is this code even compatible with the uio_pruss kernel module that is available via opkg?
2) Or is there a better way to approach this thing?
3) Is this code even compatible with the uio_pruss kernel module that is available via opkg?
# opkg list | grep prukernel-module-uio-pruss - 3.2-r9a+gitr09e9651bcf2ee8d86685f2a8075bc6557b1d3b91 - linux-ti33x-psp version 3.2-r9a+gitr09e9651bcf2ee8d86685f2a8075bc6557b1d3b91uio-pruss kernel module
Thanks for your input.Jerrill
--C
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.
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.
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
"
###################
I will ask about this on E2E.
--Chris
> Frequently asked questions: http://beagleboard.org/faq
>> > beagleboard...@googlegroups.com
>> > Frequently asked questions: http://beagleboard.org/faq
>
>
> 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
>
> -- To join: http://beagleboard.org/discuss
> To unsubscribe from this group, send email to:
> beagleboard...@googlegroups.com
>> > Frequently asked questions: http://beagleboard.org/faq
>
>
> 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
>
> -- To join: http://beagleboard.org/discuss
> To unsubscribe from this group, send email to:
Here is the response I received from TI:
> Hi Chris,
>
> The TRM has been updated to better reflect the supported PRUSSv2 feature set (the Industrial communications protocols included in the Industrial SDK: http://www.ti.com/tool/sysbiossdk-ind-sitara). > This included both renaming the PRUSS to PRU-ICSS (Industrial Communication SubSystem) and removing PRU technical details.
>
> However, these PRU technical details will still be provided to the open-source community . The PRU assembler will be released to the open-source community as part of a PRU support package. This package will also include a PRU-ICSS chapter addendum to the TRM (containing all PRU technical details), a PRU application driver, and several basic PRU examples.
>
> I apologize for any concerns generated by rev. D of the TRM.
>
> Regards,
>
> Melissa
Hi all,Here is the response I received from TI:
> Hi Chris,
>
> The TRM has been updated to better reflect the supported PRUSSv2 feature set (the Industrial communications protocols included in the Industrial SDK: http://www.ti.com/tool/sysbiossdk-ind-sitara). > This included both renaming the PRUSS to PRU-ICSS (Industrial Communication SubSystem) and removing PRU technical details.
>
> However, these PRU technical details will still be provided to the open-source community . The PRU assembler will be released to the open-source community as part of a PRU support package. This package will also include a PRU-ICSS chapter addendum to the TRM (containing all PRU technical details), a PRU application driver, and several basic PRU examples.
>
> I apologize for any concerns generated by rev. D of the TRM.
>
> Regards,
>
> Melissa
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! :-)Jerrill