DTC arch/arm/boot/dts/dra72-evm-lcd-osd.dtb DTC arch/arm/boot/dts/dra72-evm-revc.dtb ----------------------------- ‘arch/arm/boot/zImage’ -> ‘/home/zeekhuge/Projects/OpenSource/yakbuild/deploy/4.4.8-ti-r22.zImage’ ‘.config’ -> ‘/home/zeekhuge/Projects/OpenSource/yakbuild/deploy/config-4.4.8-ti-r22’ -rwxrwxr-x 1 zeekhuge zeekhuge 7.5M May 25 02:34 /home/zeekhuge/Projects/OpenSource/yakbuild/deploy/4.4.8-ti-r22.zImage ----------------------------- Building modules archive... Compressing 4.4.8-ti-r22-modules.tar.gz... -rw-rw-r-- 1 zeekhuge zeekhuge 58M May 25 02:34 /home/zeekhuge/Projects/OpenSource/yakbuild/deploy/4.4.8-ti-r22-modules.tar.gz ----------------------------- Building firmware archive... Compressing 4.4.8-ti-r22-firmware.tar.gz... -rw-rw-r-- 1 zeekhuge zeekhuge 1.2M May 25 02:34 /home/zeekhuge/Projects/OpenSource/yakbuild/deploy/4.4.8-ti-r22-firmware.tar.gz ----------------------------- Building dtbs archive... Compressing 4.4.8-ti-r22-dtbs.tar.gz... -rw-rw-r-- 1 zeekhuge zeekhuge 909K May 25 02:34 /home/zeekhuge/Projects/OpenSource/yakbuild/deploy/4.4.8-ti-r22-dtbs.tar.gz ----------------------------- Script Complete eewiki.net: [user@localhost:~$ export kernel_version=4.4.8-ti-r22] ----------------------------- zeekhuge@zeekhuge:~/Projects/OpenSource/yakbuild$
diff linux-bb-4.4.11-ti-r28/include/linux/remoteproc.h linux-bb-4.4.8-ti-r22/include/linux/remoteproc.h
104,107d103
< * @RSC_INTMEM: (deprecated) dummy place-holder to provide near-term
< * backward compatibility.
< * @RSC_CUSTOM: a custom resource type that needs to be handled outside
< * remoteproc core.
123,125c119
< RSC_INTMEM = 4,
< RSC_CUSTOM = 5,
< RSC_LAST = 6,
---
> RSC_LAST = 4,
316,327d309
< * struct fw_rsc_custom - custom resource definition
< * @sub_type: implementation specific type
< * @size: size of the custom resource
< * @data: label for the start of the resource
< */
< struct fw_rsc_custom {
< u32 sub_type;
< u32 size;
< u8 data[0];
< } __packed;
<
< /**
366d347
< * @handle_custom_rsc: hook to handle device specific resource table entries
373,374d353
< int (*handle_custom_rsc)(struct rproc *rproc,
< struct fw_rsc_custom *rsc);
On May 31, 2016 9:02 PM, "Zubeen Tolani" <me.zu...@gmail.com> wrote:
>
> REPORT - WEEK 2
>
> Hello Everyone,
>
> As per the last report, I had to do some tasks by this time. No all of them have been completed successfully by now, but I have progressed in most of them.
>
> Last week :
>
> 1. Kernel Version and Kernel Source code and remoteproc drivers:
>
> So, It was really a pain to find the exact kernel source that are being used to build the distribution kernel images, but i am now able to reproduce the exact source code (yakbuild repo at Robert's github being the key).
> I have been using kernel version 4.4.9-ti-r22, and as per Jason's instructions all the kernel images needed to be picked up from http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Jessie_Snapshot_iot, and the latest one is 4.4.9-ti-r22, which do not has PRU remoteproc driver being distributed with it. I tried to dig in and find that its the 4.4.11 release that will have PRU remoteproc drivers in it. So I downloaded the 4.4.-11-ti-r28 source and tried to port the remoteproc drivers from 4.4.11 to 4.4.8-ti-r22, but wasnt able to do this. The was of-course with the versioning_symbol. The header file include/linux/remoteproc.h in the 2 releases is different, which results in the change in the versioning_symbol.
You can just apt get update the kernel, they'll be more remoteproc stuff coming from ti.com
Otherwise here is A fresh iot image for you..
https://rcn-ee.net/rootfs/bb.org/testing/2016-05-31/iot/
With 4.4.11-ti-r29...
Btw, a few more remoteproc patches where merged today..
They'll be part of r30 pushed out Thursday-ish..
> --
> You received this message because you are subscribed to the Google Groups "BeagleBoard GSoC" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard-gs...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
[ 19.628388] virtio_rpmsg_bus virtio1: rpmsg host is online
[ 19.628440] virtio_rpmsg_bus virtio1: creating channel rpmsg-pru addr 0x1f
[ 19.666121] rpmsg_pru rpmsg0: new rpmsg_pru device: /dev/rpmsg_pru30
[ 19.666929] rpmsg_pru rpmsg1: new rpmsg_pru device: /dev/rpmsg_pru31
[ 69.758596] rpmsg_pru rpmsg0: Message length table is full
[ 69.773082] rpmsg_pru rpmsg0: Message length table is full
[ 69.789052] rpmsg_pru rpmsg0: Message length table is full
[ 69.801003] rpmsg_pru rpmsg0: Message length table is full
[ 69.816916] rpmsg_pru rpmsg0: Message length table is full
[ 69.829907] rpmsg_pru rpmsg0: Message length table is full
[ 69.844918] rpmsg_pru rpmsg0: Message length table is full
[ 69.860527] rpmsg_pru rpmsg0: Message length table is full
[ 69.876931] rpmsg_pru rpmsg0: Message length table is full
[ 69.887789] rpmsg_pru rpmsg0: Message length table is full
http://postimg.org/image/6eysheu9j/Out of the two pictures, one of them is showing the approx frequency that was achieved by using as __delay_cycles(1) command between __R30 toggle commands.
http://postimg.org/image/lhb0s3et3/
About the
remote procedure call - I didn't dive deep into it. But now I think its
not needed. The RPC approach is pretty complex and uses up more
resource on PRUs. It would involve defining functions and various calls,
which will again use those registers as indicated in the above link.
And I think it will be better to keep PRU0 free from other complex
tasks, so that we could use it to transfer data to the ARM. Also, why to
use such a complex approach (though it looks interesting) when 2 x 32
bit messages do the required task (it can further be converted into 1 x
64 bit long message).
As far as the current state of the driver is concerned, it actually took me time to understand the IIO data structures and how to relate it with the ADC device that I have. I have got some understanding but its still not completely clear to me. I had some doubt and Michael helped me with it. I will keep asking as I move along.
As of now, The
driver gets probed, registers itself to the IIO subsystem and the iio
sysfs bindings do appear according the channel specifications (https://gist.github.com/ZeekHuge/c0334c14d33ce62d6d27552a18073b01).
I am working to add the read raw methods to the driver. I have already
added the read_raw methods actually, but it isnt working and was getting
late to write the report so I left it there.
The
driver IIO also exposes in_voltage0_sampling_frequency and the driver
supports sending variable frequency to the PRUs, but this part needs
some improvement. The configuration data that is sent to the PRUs
actually contains 'number of PRU cycles to delay' , and not the
frequency, so, I need to improve the calculations part in the conversion
process, it is mostly working, but the resulting frequency is not
actually the given one, this is probably because we only have fixed
point calculations, so I need to increase the accuracy by improving the
multiplication factor.
Further, though the pru firmware supports variable clock duty cycle, for the sampling, I have used ~50% duty cycle. Actually I haven't been able to find a way to expose this feature to the userspace. Can it be like a different driver that manages the clock ? Not sure what to do, so just used 50% duty cycle.
REPORT - WEEK 13
Hello Everyone,
So the last weekly report. That brings tears :) it was a routine to write weekly reports ( Okay, sometimes not reports but at least something ;) ) for last 12 weeks.
So the current status :
Drivers :
After reading a lot of code, documentation and ldd3, finally have
understood how the device and driver bindings actually work, straight
from the core ,right up-to the device-driver.
This has been challenging and really difficult. I have been asking for
help everywhere and been doing lot of testing, trials and debugging
through kernel oops.
Doing this in the device driver model was important. That is, having different parts of the whole software stack, on different drivers and registering themselves through APIs. It was difficult as it required precise and in depth knowledge of what is going on inside, for example - missing a single instruction that 'gets' a kobj or 'puts' a kobj can generate long long oops and you do not know what the APIs do internally. Then, tracking it down is again another challenge.
So as of now I have :
2. Completed Work:
3. Things not done :
There was nothing that was completely left out. Each and every feature task/feature had some progress and was implemented with leaving some limitations. As of now:
4. Things done out of the proposal :
There were not a lot of things I could do out of the proposal, but I managed to develop some PRU programming examples and posts on it. Further, I was able to make some noted out of the remote-proc driver and the usage of PRU compiler 'clpru'.
8. Final Words:
Hmmm
(Hunyue, just borrowing this for a while :) ), so the last report. It
has been a journey, at times pleasant and at times adventurous, at times
learning as at times teaching, at times motivated at times depressed.
No more words to describe it.
Thanks
to all the member of the Beagleboard community for helping in each and
every possible way. I really truly believe that you people know
everything. :)
Thank you
[1] https://github.com/ZeekHuge/BeagleScope/blob/port_to_4.4.12-ti-r31%2B/docs/clpru_and_C_usage.notes
[2] https://github.com/ZeekHuge/BeagleScope/blob/port_to_4.4.12-ti-r31%2B/docs/current_remoteproc_drivers.notes
[3] https://github.com/ZeekHuge/BeagleScope/tree/port_to_4.4.12-ti-r31%2B/firmware
[4] https://github.com/ZeekHuge/BeagleScope/tree/port_to_4.4.12-ti-r31%2B/examples/firmware_exmples/pru_blinky
[5] https://github.com/ZeekHuge/BeagleScope/tree/port_to_4.4.12-ti-r31%2B/examples/firmware_exmples/pru_logic_replicate
[6] https://github.com/ZeekHuge/BeagleScope/tree/port_to_4.4.12-ti-r31%2B/examples/firmware_exmples/pru1_to_pru0_to_arm
[7] https://github.com/ZeekHuge/BeagleScope/tree/port_to_4.4.12-ti-r31%2B/examples/firmware_exmples/PRU_inline_asm_blinky
[8] https://github.com/ZeekHuge/BeagleScope/tree/port_to_4.4.12-ti-r31%2B/examples/firmware_exmples/pru_pin_state_reader
[9] https://github.com/ZeekHuge/BeagleScope/tree/port_to_4.4.12-ti-r31%2B/examples/kernel_examples/n-blinky
[10] https://github.com/ZeekHuge/BeagleScope/blob/port_to_4.4.12-ti-r31%2B/driver/beaglescope_driver.c
[11] https://github.com/ZeekHuge/BeagleScope/blob/wip_parallel_interface_take2/driver/pi_bus.c
[12] https://github.com/ZeekHuge/BeagleScope/blob/wip_parallel_interface_take2/driver/parallel_interface.c
[13] https://github.com/ZeekHuge/BeagleScope/blob/wip_parallel_interface_take2/driver/beaglescope_driver.c