Hi Shubangi,
> Hey,
>
> You'd be glad to know that I am working on the project "PRUSS support for
> newer kernels" under Google Summer of Code 2015 for Beagleboard.org .
This
> project aims to develop a communication framework between the ARM and PRU
> cores with the help of appropriate kernel modules and user interfaces.
>
> I am able to get pruss_remoteproc module up and running on BBB to load
> firmware and manage initial configuration. I am working on the module
code
> to align it with the framework's objectives. (eg - taking firmware name
> from userspace or booting PRU when user demands instead of boot at probe
> time).Whats the motivation for this? You probably want to check with your
mentors on this one. I accomplish the same using existing infrastructure.
1. Use the sysfs bind/unbind functionality on the PRUSS devices to
accomplish the boot/shutdown.
2. I use symbolic names for the driver expected firmware name to point
to a user expected image if different. This can be done at runtime if
needed between an unbind/bind sequence.
Thanks a ton for pointing me towards bind/unbind functionality. Such things
still
elude BBB users (like me) and new comers so I'll make this more accessible
to the community
through userspace python library.
I don't expect the driver to be built-in usually, as its not a core
driver. So, doing it as a module just performs what is needed
There are gonna be a few improvements, like fixing the bind/unbind for
individual PRU devices) the next time I do the driver on 2015 LTS kernel.>
> Could you please tell me if already have some ideas with you regarding
the
> direction in which the development of this driver should proceed since
the
> project aims to upstream the remoteproc driver.
>
> Also, could you please shed some light on the current status of mailbox
> framework implementation for PRUSS since ARM-PRU message-passing is the
> project's primary objective. How is mailbox different from rpmsg ?The mailbox framework is a framework API provided for clients to send
messages (can be in atomic context) to their remote peers. The platform
drivers/controllers are usually drivers for physical peripherals that
implement mailboxes (messages plus optional signalling mechanisms).rpmsg is a logical bus framework sitting on top of the virtio ring
transport. rpmsg reuses the virtio ring transport defined originally as
part of the virtualization framework. The virtio ring transport provides
the physical layer transport logistics using shared memory and some kick
notifications (can be implemented by any means - the OMAP mailbox was
one such usage). The bus infrastructure allows different rpmsg drivers
to be developed, exposing their own interfaces or staying at the kernel
level.
Had a talk with my mentors regarding existing IPC mechanisms and understood
that limited program code space and data space (IRAM & DRAM) on PRU make
these
abstraction layers (rpmsg or mailbox) too much of an overhead for PRU. They
too
expressed latency issues. So I am working on minimalistic data-passing
functions to circular buffers
with low level IO using iowrite32/writel_relaxed. Thanks a lot for your
help. Any comments from
your side would be appreciated.
Regards.