I've been making progress in my PRU experiments. Things are looking
promising, but there are still a couple of loose ends.
I made a new friend on freenode #beagle who contributed this:
I have suggested that UIO_PDRV* be changed from 'y' to 'm' because I
really don't want those turned on unless I need them, and he agreed
that was probably a good idea. They don't take up much memory, but
they do register themselves as additional uio drivers, so if they're
not needed I think most people would prefer they be turned off.
Really, you could make the exact same argument about the UIO framework
(top level UIO driver) as well. To give a more concise view of what I
recommend, I'd like to see the default angstrom distribution set:
However, I want to be somewhat humble about recommending that the
community do what I want just because it's what I want, vs. what's
best for the masses. The thing is, there's a pretty steep learning
curve involved in figuring out how to take what comes out of bitbake
and modifying it, so I think there's value in just saying compile
these things as modules, let bitbake generate opkg packages out of
them, then the end user can decide what to do about installing those
packages and letting modprobe handle dependencies.
The second thing is a little more difficult. The current release of
uio_pruss.c seems to be doing some things right:
* PRUSS memories are turned on
* PRUSS clocks are turned on
* PRUSS subsystem is powered on
HOWEVER: the PRUSS subsystem is still held in reset, and in that
state, it's offline to the L3/L4 interconnects, meaning I can't talk
to it at all. A temporary workaround is to install devmem2 and do:
modprobe uio_pruss && devmem2 0x44E00C00 w 0
The address I'm setting there is RM_PER_RSTCTRL, and what I'm doing is
releasing the PRUSS from reset. For details see AM335x TRM section
126.96.36.199.1 (table 8-182).
If you want to verify that this is the problem, I suggest doing this.
Reboot the board, modprobe uio_pruss, then "devmem2 0x44E00C00 w" - in
my case ti told me it was "3" (not sure why it wasn't '2" but ok)
which means PRUSS local reset control = ASSERTED. Enabling the PRU
shouldn't make it run (can someone confirm I am right about this?) as
the run state is controlled by PRUSS_PRU_CTRL registers (there is one
for each PRU). The reset sstate of PRUSS_PRU_CTRL.CONTROL bi 1
(ENABLE) is 0, which means that even though the PRUSS is out of reset,
the individual PRUs should be disabled.
My question, then, is this: how do we get this code changed to take
the PRUSS out of reset when uio_pruss is loaded? Options:
1) Hack it into uio_pruss.c (probably not a good idea)
2) create the correct linkages so that enabling the PRUSS clock, which
enables the PER clock domain, which enables the PER power domain,
somewhere in there also takes the PRUSS out of reset. I THINK this is
the correct way to solve the problem, but this clock tree stuff is new
to me and I don't yet undersatnd all of the linkages -- so I'd like to
ask for help from someone on the mailing list who not only knows how
to do this but can actually make it happen and get it committed.
Tell me where I'm off target here, but be kind as I'm still in