Difference between revisions of "BeagleBoard/GSoC/Ideas-2021"

From eLinux.org
Jump to: navigation, search
m (Security and Privacy)
(93 intermediate revisions by 22 users not shown)
Line 7: Line 7:
  
 
=Welcome!=
 
=Welcome!=
BeagleBoard.org has been accepted as a mentoring organization in the [[BeagleBoard/GSoC|Google Summer of Code]] for 2017!  Below, we're collecting project ideas for the GSoC-2017.
+
BeagleBoard.org is applying to be a mentoring organization in the [[BeagleBoard/GSoC|Google Summer of Code]] for 2020!  Below, we're collecting project ideas for the GSoC-2020.
  
 
==What is Google Summer of Code?==
 
==What is Google Summer of Code?==
Spend your summer break writing code and learning about open source development while earning money! Accepted students work with a mentor and become a part of the open source community. Many become lifetime open source developers! The 2017 student application window is open March 20th 2017!
+
Spend your summer break writing code and learning about open source development while earning money! Accepted students work with a mentor and become a part of the open source community. Many become lifetime open source developers! The 2020 student application window is open March 16th 2020!
  
 
Google Summer of Code is open to post-secondary students, age 18 and older in most countries.
 
Google Summer of Code is open to post-secondary students, age 18 and older in most countries.
  
Read more on [https://developers.google.com/open-source/gsoc/ the GSoC site for next year] and [https://developers.google.com/open-source/gsoc/faq the FAQ].
+
Read more on [https://developers.google.com/open-source/gsoc/ the GSoC site] and [https://developers.google.com/open-source/gsoc/faq the FAQ].
  
 
==BeagleBoard.org Background==
 
==BeagleBoard.org Background==
BeagleBoard.org is a volunteer organization that seeks to advance the state of open-source software on [http://en.wikipedia.org/wiki/Open-source_hardware open-source hardware] platforms capable of running high-level languages and operating systems (primarily Linux) in embedded environments. Born from taking mobile phone processors and putting them on low-cost boards to build affordable desktop computers, BeagleBoard.org has evolved to focus on the needs of the "maker" community with greater focus on the I/O needed for controlling motors and reading sensors to build things like robots, 3d printers, flying drones, in-car computer systems and much more. Past BeagleBoard.org GSoC projects included [[BeagleBoard/GSoC/2014_Projects#Project:_BotSpeak_PRU_Firmware|creating an interpreter for tiny CPUs]], [[BeagleBoard/GSoC/2014_Projects#Project:_PyBBIO|adding SPI and sensor support to Python]], [[BeagleBoard/GSoC/2014_Projects#Project:_Bone101|an HTML and git based tutorial sharing environment]], [[BeagleBoard/GSoC/2014_Projects#Project:_BeaglePilot|porting autopilot software to Linux]], [[BeagleBoard/GSoC/2014_Projects#Project:_BeagleLogic|an open source 100MHz 14-channel logic analyzer]], [[BeagleBoard/GSoC/2014_Projects#Project:_Android_Remote_Display|using Android tablets as Linux displays]], [[BeagleBoard/GSoC/2013_Projects#Linux_ADC_IIO_Support|putting ADC support in Linux under the IIO framework]], [[BeagleBoard/GSoC/2013_Projects#Android-based_Boot|using Android phones as a network boot source]], [[BeagleBoard/GSoC/2013_Projects#Userspace_Arduino|Running Arduino code on Linux]], [[BeagleBoard/GSoC/2013_Projects#Robot_Operating_System|Robot Operating System support within the Yocto Project build system]], [[BeagleBoard/GSoC/2013_Projects#Minix_I2C|Minix I2C support]], [[BeagleBoard/GSoC/2010_Projects/C6Run|an RPC framework for heterogeneous processor communication]], [[BeagleBoard/GSoC/2010_Projects/USBSniffer|a transparent USB packet sniffer]], [[BeagleBoard/GSoC/2010_Projects/XBMC|ARM optimizations for XBMC]], [[BeagleBoard/GSoC/2010_Projects/FFTW|ARM optimizations for FFTs]], [[BeagleBoard/GSoC/2010_Projects/Pulse_Width_Modulation|make-shift pulse-width-modulation]] and [[BeagleBoard/GSoC/2010_Projects/OpenCV|RPC optimizations for OpenCV]]. BeagleBoard.org has benefited from sponsorship from Texas Instruments, [[CircuitCo]], Digi-Key, element14 and others, but avoids any dependence on that sponsorship for sustaining the effort. The project has evolved over the past few years with over 1,000,000 boards in circulation with developers worldwide and strong roots in the Linaro, Yocto Project, Angstrom Distribution, Debian and Linux communities---and support for running most major Linux distributions including Ubuntu, Android, Fedora, ArchLinux, Gentoo, Buildroot and many more.
+
BeagleBoard.org is a volunteer organization that seeks to advance the state of open-source software on [http://en.wikipedia.org/wiki/Open-source_hardware open-source hardware] platforms capable of running high-level languages and operating systems (primarily Linux) in embedded environments. Born from taking mobile phone processors and putting them on low-cost boards to build affordable desktop computers, BeagleBoard.org has evolved to focus on the needs of the "maker" community with greater focus on the I/O needed for controlling motors and reading sensors to build things like robots, 3d printers, flying drones, in-car computer systems and much more. Past BeagleBoard.org GSoC projects included [[BeagleBoard/GSoC/2014_Projects#Project:_BotSpeak_PRU_Firmware|creating an interpreter for tiny CPUs]], [[BeagleBoard/GSoC/2014_Projects#Project:_PyBBIO|adding SPI and sensor support to Python]], [[BeagleBoard/GSoC/2014_Projects#Project:_Bone101|an HTML and git based tutorial sharing environment]], [[BeagleBoard/GSoC/2014_Projects#Project:_BeaglePilot|porting autopilot software to Linux]], [[BeagleBoard/GSoC/2014_Projects#Project:_BeagleLogic|an open source 100MHz 14-channel logic analyzer]], [[BeagleBoard/GSoC/2014_Projects#Project:_Android_Remote_Display|using Android tablets as Linux displays]], [[BeagleBoard/GSoC/2013_Projects#Linux_ADC_IIO_Support|putting ADC support in Linux under the IIO framework]], [[BeagleBoard/GSoC/2013_Projects#Android-based_Boot|using Android phones as a network boot source]], [[BeagleBoard/GSoC/2013_Projects#Userspace_Arduino|Running Arduino code on Linux]], [[BeagleBoard/GSoC/2013_Projects#Robot_Operating_System|Robot Operating System support within the Yocto Project build system]], [[BeagleBoard/GSoC/2013_Projects#Minix_I2C|Minix I2C support]], [[BeagleBoard/GSoC/2010_Projects/C6Run|an RPC framework for heterogeneous processor communication]], [[BeagleBoard/GSoC/2010_Projects/USBSniffer|a transparent USB packet sniffer]], [[BeagleBoard/GSoC/2010_Projects/XBMC|ARM optimizations for XBMC]], [[BeagleBoard/GSoC/2010_Projects/FFTW|ARM optimizations for FFTs]], [[BeagleBoard/GSoC/2010_Projects/Pulse_Width_Modulation|make-shift pulse-width-modulation]] and [[BeagleBoard/GSoC/2010_Projects/OpenCV|RPC optimizations for OpenCV]]. BeagleBoard.org has benefited from sponsorship from Texas Instruments, Circuitco, Digi-Key, element14 and others, but avoids any dependence on that sponsorship for sustaining the effort. The project has evolved over the past few years with over 1,000,000 boards in circulation with developers worldwide and strong roots in the Linaro, Yocto Project, Angstrom Distribution, Debian and Linux communities---and support for running most major Linux distributions including Ubuntu, Android, Fedora, ArchLinux, Gentoo, Buildroot and many more.
  
BeagleBoard was inspiration for Raspberry Pi[http://www.linuxuser.co.uk/features/raspberry-pi-interview-eban-upton-reveals-all] and is available for about $50 through over 30 distributors world-wide (and is even available at Micro Center and Radio Shack in the USA), but is more than a throw-away computer. It is an instance of true open hardware, exposing users to the broader world of electronics, demystifying computers and fostering an environment of clones that have changed the industry for good.
+
BeagleBoard was inspiration for Raspberry Pi[https://web.archive.org/web/20120302232755/www.linuxuser.co.uk/features/raspberry-pi-interview-eban-upton-reveals-all] and PocketBeagle is available for about $25 through over 30 distributors world-wide (and is even available at Micro Center in the USA), but is more than a throw-away computer. It is an instance of true open hardware, exposing users to the broader world of electronics, demystifying computers and fostering an environment of clones that have changed the industry for good.
  
 
Students will be expected to demonstrate an understanding of cross-compiling before being accepted, but support for demonstration is available through the IRC channel that typically has approximately 150 online chatters logged on at any time, most with sufficient experience to explain the process.
 
Students will be expected to demonstrate an understanding of cross-compiling before being accepted, but support for demonstration is available through the IRC channel that typically has approximately 150 online chatters logged on at any time, most with sufficient experience to explain the process.
  
'''''<span style="color:red">Every accepted student will be sent a [https://bbb.io/wifi BeagleBone Black Wireless], [https://bbb.io/black BeagleBone Black], [https://bbb.io/blue BeagleBone Blue], [https://bbb.io/green SeeedStudio BeagleBone Green], [https://bbb.io/green-wireless SeeedStudio BeagleBone Green Wireless] or [https://bbb.io/x15 BeagleBoard-X15] before the first week of coding for testing their project.</span>'''''
+
'''''<span style="color:red">Every accepted student will be sent a [https://bbb.io/pocket PocketBeagle], TechLab or GamePup, and either a [https://bbb.io/ai BeagleBone AI], [https://bbb.io/wifi BeagleBone Black Wireless], [https://bbb.io/black BeagleBone Black], [https://bbb.io/blue BeagleBone Blue], [https://bbb.io/green SeeedStudio BeagleBone Green], [https://bbb.io/green-wireless SeeedStudio BeagleBone Green Wireless] or [https://bbb.io/x15 BeagleBoard-X15] before the first week of coding for testing their project.</span>'''''
  
 
Additional hardware will be provided depending on need and value.
 
Additional hardware will be provided depending on need and value.
  
For more information, check out http://beagleboard.org and http://beagleboard.org/brief.
+
For more information, check out https://beagleboard.org and https://beagleboard.org/brief.
  
 
==Students looking for ideas==
 
==Students looking for ideas==
Line 55: Line 55:
  
 
==Idea template==
 
==Idea template==
Description
+
Please place your idea in a suitable section.
 +
 
 +
===Summarizing project name===
 +
Longer summary of the project.
 
<br>
 
<br>
 
+
''Goal:'' Concise statement that describes completion.<br>
''Goal:'' <br>
 
 
''Hardware Skills:'' <br>
 
''Hardware Skills:'' <br>
 
''Software Skills:'' <br>
 
''Software Skills:'' <br>
Line 66: Line 68:
  
 
=Ideas=
 
=Ideas=
==BeagleBone Audio Platform==
+
Throughout all of these ideas, contributions specifically contributing to the Linux kernel will be given extra attention. The ability for the BeagleBoard.org community to leverage software created out of GSoC is greatly expanded when those contributions land in the upstream Linux kernel where they are shared across many platforms and maintained by the broadest possible support community. In each application area, consideration how a kernel module submitted upstream could be a central component should be considered. In lieu of contributing to the Linux kernel, finding an upstream project, like ArduPilot, RTEMS, DonkeyCar, etc., where there is already an active community, is strongly desired. Of course, some projects are very BeagleBone-specific, like Adafruit_BBIO and BoneScript, and those projects do have an active user community and contributions are welcome in those areas, but more weight is given the more broad the impact of the coding project is. We've seen bug fixing projects to be very productive as well.
  
''Goal'': [https://bbb.io/bone BeagleBone] and/or [https://bbb.io/x15 BeagleBoard-X15] as Audio Signal Processing Platform (e.g. effects box for musicians), possibly implementing Audio Video Broadcast protocol<br>
+
Feel free to look at [[BeagleBoard/GSoC/Ideas-2018|previous ideas]] and migrate some here.
''Hardware Skills'': Possibly design of highly accurate real-time clock cape<br>
 
''Software Skills'': User space for demo apps, possibly kernel space for network / PTP timestamping<br>
 
''Possible Mentors'': Robert Manzke, Henrik Langer, tbd<br>
 
''Upstream Repository'': [https://github.com/beagleboard/linux Beagle Kernel] or Use Case repo<br>
 
''References'': Audio Project from 2016 [[BeagleBoard/GSoC/2016_Projects]], [http://www.creative-technologies.de/linux-based-low-latency-multichannel-audio-system-2/ CTAG face2|4], http://bela.io/, [[CircuitCo:Audio_Cape_RevB|Beagle Audio Cape]]
 
  
==BeagleBone synchronous data collection==
+
==Kernel improvements==
''Goal'': Synchronous data collection via the PRU. This complements BeagleLogic which asynchronously acquires data.<br>
+
Improvements to the Linux kernel or kernel related projects in userspace that powers the basic infrastructure on which the BeagleBoard runs.  
''Hardware Skills'': Understanding of a synchronous signal<br>
 
''Software Skills'': C and assembly programming<br>
 
''Possible Mentors'': Hunyue Yau, Kumar Abhishek<br>
 
''Upstream Repository'': <br>
 
''References'': [http://beaglelogic.net/ BeagleLogic] from prior years.
 
  
==BeagleBone GPU offload==
+
===USB configfs in device tree===
''Goal'': Sample programs to utilize the GPU for computations. The GPU on most of the [https://bbb.io/bone BeagleBone]/[https://bbb.io/x15 Board] are limited to OpenGL ES 2; Goal is to provide sample programs to show using GLES2 for computations.<br>
+
To speed up the boot process by configuring USB statically in the device tree instead of it being conventionally done through a script at boot time.
''Hardware Skills'': N/A<br>
+
<br>
''Software Skills'': OpenGLES<br>
+
''Goal:'' USB configfs in device tree such that they can be configured statically in device tree ahead of boot and speed the boot process.<br>
''Possible Mentors'': Hunyue Yau, Robert Manzke<br>
+
''Hardware Skills:'' USB <br>
''Upstream Repository'': possibly [https://github.com/patriciogonzalezvivo/thebookofshaders thebookofshaders] <br>
+
''Software Skills:'' C, Linux kernel, USB configfs<br>
''References'': http://thebookofshaders.com/
+
''Possible Mentors:'' rcn-ee <br>
 +
''Upstream Repository:'' https://github.com/beagleboard/linux/tree/4.19 kernel.org <br>
 +
''References:'' https://events.static.linuxfound.org/sites/events/files/slides/USB%20Gadget%20Configfs%20API_0.pdf <br>
  
==BeagleBone/Beagle board PRU DMA ==
 
''Goal'': Create a sample program to demostrate using EDMA on the PRU to transfer data to and from the main (DDR) memory with a Linux host. Most existing code utilizes(wastes) the 2nd PRU on the PRUSS for data xfer. Using DMA can allow the PRU to be used for other purposes.<br>
 
''Hardware Skills'': Datasheet/specification reading<br>
 
''Software Skills'': Assembly language programming/Linux kernel programming<br>
 
''Possible Mentors'': Hunyue Yau<br>
 
''Upstream Repository'': N/A<br>
 
''References'': N/A
 
  
==BeagleBone Remote Seismometer Node ==
+
===mikroBus driver===
''Goal'': Working prototype remote seismometer, web-based control and display. Determine DAC bandwidth and accelerometer requirements, implement data acquisition code, integrate with control / display interface. Stretch goal: integrate device with BOINC/QCN.<br>
+
mikroBus is a mikroElektronkia developed standard with I2C, UART, SPI, ADC, PWM and GPIO. These embedded busses are non-probable,
''Hardware Skills'': Datasheet/specification reading, patch cables/breadboard/soldering<br>
+
so configuration today occurs via device tree. Even if the peripheral is described today, most device drivers using these busses require some additional GPIO resources, like an interrupt signal or reset line. A mikroBus implementation would provide all
''Software Skills'':C/assembly and python programming, basic understanding of serial buses, sensors and data, physical principles<br>
+
platform data necessary for drivers to successfully probe due to having all the resources assigned and by becoming probable through
''Possible Mentors'': Steve Arnold, Stephanie Lockwood-Childs<br>
+
the addition of an I2C EEPROM, much like Cape Bus was out-of-tree. The big differences are that mikroBus is a standard implemented
''Upstream Repository'': N/A<br>
+
on many boards, it is far more regular and it is constrained in its definition not requiring the loading of device tree fragments to complete configuration as the additional platform data can come from the additional provided GPIO resources.
''References'': [https://www.sparkfun.com/tutorials/235 generic project desc.] , [http://wiki.seeed.cc/BeagleBone_Green/ BeagleBone Green] , [http://qcn.stanford.edu/ quake catcher network] , [http://processors.wiki.ti.com/index.php/PRU-ICSS_Remoteproc_and_RPMsg PRU-ICSS]
+
<br>
 +
''Goal:'' With an added I2C identifier, any Click board for which drivers exist in Linux simply enumerates on PocketBeagle TechLab mikroBus port without any new device-tree entries.<br>
 +
''Hardware Skills:'' UART, I2C, SPI, ADC, GPIO and PWM <br>
 +
''Software Skills:'' C, Linux kernel <br>
 +
''Possible Mentors:'' jkridner <br>
 +
''Upstream Repository:'' https://github.com/beagleboard/linux/tree/4.19 kernel.org <br>
 +
''References:'' https://www.mikroe.com/mikrobus <br>
  
==BeagleBone Sonic Anemometer / Basic Weather Station==
+
===Cape compatibility layer for BeagleBone Black and BeagleBone AI===
''Goal'': Working prototype sonic anemometer using BeagleBone, PRUDAQ, and ultrasonic sensors.  Analyze methods for accuracy/sensitivity (eg, time-of-flight vs. phase difference) and implement "best" method. Use PRUs for independent real-time control of ultrasonics.  Example architecture and software on github (see repos and references below)<br>
+
''Goal:'' Use same references to drivers for peripherals assigned to the same pins between Black and AI.<br>
''Hardware Skills'': Datasheet/specification reading, patch cables/breadboard/soldering (at least two), serial/debug<br>
+
''Hardware Skills:'' UART, I2C, SPI, ADC, GPIO and PWM <br>
''Software Skills'': C/assembly and python programming, basic understanding of serial buses, sensors and data, physical principles<br>
+
''Software Skills:'' C, Linux kernel <br>
''Possible Mentors'': Steve Arnold, Stephanie Lockwood-Childs<br>
+
''Possible Mentors:'' jkridner <br>
''Upstream Repository'': [https://github.com/Visaoni/beagle-sonic-anemometer beagle-sonic] from prior years, also [https://github.com/herrera-luis-alberto/UChSonicAnemometer UChSonicAnemometer] from Univ of Chile.<br>
+
''Upstream Repository:'' https://github.com/beagleboard/linux/tree/4.19 kernel.org <br>
''References'': [http://processors.wiki.ti.com/index.php/PRU-ICSS_Remoteproc_and_RPMsg PRU-ICSS] , [http://www.cas.manchester.ac.uk/restools/instruments/meteorology/sonic/ sonic anemometer basics]  
+
''References:'' [[Beagleboard:BeagleBone cape interface spec]] <br>
  
==BeagleBone Cubesat Software/Platform Integration==
+
==Deep Learning==
''Goal'': Integrate BeagleSat "satellite" platform with existing MAVLink/autopilot framework, including previous GSoC BeagleSat magnetometer application.  Determine best autopilot platform for BeagleBone (mainly begalepilot vs. apm2) based on science experiment needs; using BeagleSat project magnetic field measurements as example, requirements include SPI burst data reads from 2 independent magnetometers (ie, use BBIO MPU9250 SPI driver for data acquisition).  Integrate navigation model with autopilot firmware and selected Beaglebone hardware and data acquisition example.<br>
+
BeagleBoard-X15 has accelerators for running deep learning tasks using TIDL ([https://training.ti.com/deep-learning-tidl-overview 1], [http://www.ti.com/lit/wp/spry314/spry314.pdf 2]). We'd love projects that enable people to do more deep learning application and end-nodes and leverage cloud-based training more easily. Goal here is to create tools that make learning about and applying AI and deep learning easier. Contributions to projects like ArduPilot and DonkeyCar (DIY Robocars and BlueDonkey) to introduce autonomous navigation to mobile robots are good possible candidates.
''Hardware Skills'': Datasheet/specification reading, soldering/prototyping, serial/debug<br>
 
''Software Skills'': high-level language skills (Python, C, etc), some knowledge of micro-controller compilers and targets, kernel config/programming and serial bus interfaces (some)<br>
 
''Possible Mentors'': Steve Arnold, Stephanie Lockwood-Childs<br>
 
''Upstream Repository'': [https://github.com/nvisnjic/BeagleSat BeagleSat] , [https://github.com/mavlink/mavlink MAVLink] , [https://github.com/BeaglePilot/ardupilot BeaglePilot]<br>
 
''References'': [http://www.strawsondesign.com/#!board-features BeagleBone Blue board features] , [http://dev.ardupilot.com/wiki/building-for-beaglebone-black-on-linux/ Building (ardupilot) for BeagleBone Black on Linux] , [http://dev.ardupilot.com/wiki/mavlink-commands/ MAVLink Commands]
 
  
==BeagleBone-based Serial Terminal Server==
+
===YOLO models on the X15/AI===
''Goal'': Often in embedded development it is valuable to have a serial terminal server which can retain a serial port connection along with buffered past I/O separate from a typical host PC, either for longer term logging of serial port data or to enable remote management of a device via serial port.  Commercial units which have this capability are very expensive. The BeagleBones have 4 highly capable UARTs exposed besides UART0 through the cape connectors and a simple cape hardware could easily enable a BeagleBone to physically have all the interfaces needed to be a serial terminal server. The cape hardware does not need to be created for this project to go forward, so long as other devices which connected to the BeagleBone terminal server used 3.3 V UARTs themselves.<br>
+
Port the YOLO model(s) to the X15/AI so the accelerator blocks can be leveraged. Currently, running a frame through YOLOv2-tiny takes anywhere from 35 sec to 15 second depending on the how the code is run on the ARM.35 second being a pure brute force compilation for ARM; 15 second utilizing NEON and tweaked algorithms. The goal is to get things down to 1 second or less using the onboard accelerators. Note, there are over 6 different variants of YOLO (YOLOv1, YOLOv2, YOLOv2 and each one has a full size and a tiny version). The main interest is in getting either the YOLOv2 or YOLOv3 versions running. Please discuss with potential mentors on the desired approach as there are many approaches. Just to name a few: Porting the YOLO model into TIDL; OpenCL directly; OpenCL integration with the acceleration library; Integrating TIDL support with an acceleration library.
 +
<br>
 +
''Goal:'' Run YOLOv2 or YOLOv3 with the onboard hardware acceleration.<br>
 +
''Hardware Skills:'' None <br>
 +
''Software Skills:'' C, C++, Linux kernel, Understanding of NNs and Convolution.<br>
 +
''Possible Mentors:'' Hunyue Yau <br>
 +
''Upstream Repository:'' Numerous <br>
 +
''References:'' https://pjreddie.com/darknet/yolo/ <br>
  
This project would begin with a survey of existing software which could be adapted to provide a terminal server experience (for example something as simple as using GNU screen with some adaptations over an SSH connection to the BeagleBone) and then proceed to create software changes needed to enable such operation in an easy to use and deploy way. This resulting (or found) software would likely end up being generic for Linux based serial terminal servers.  The end result of this project should likely be an easy to deploy SD card image to enable someone to setup a low cost serial terminal server based on a BeagleBone in only a few minutes.<br>
+
===OpenGLES acceleration for DL===
 +
Current acceleration on the X15/AI focuses on using the EVE and DSP hardware blocks. The SoC on those boards also feature an OpenGLES enabled GPU. The goal with this is to utilize shaders to perform computations. A possible frame work to utilize this on is the Darknet CNN framework.<br>
 +
''Goal:'' Accelerate as many layers types as possible using OpenGLES.<br>
 +
''Hardware Skills:'' None <br>
 +
''Software Skills:'' C, C++, Linux kernel, OpenGLES, Understanding of NNs and Convolution.<br>
 +
''Possible Mentors:'' Hunyue Yau <br>
 +
''Upstream Repository:'' Numerous <br>
 +
''References:'' https://pjreddie.com/darknet/ <br>
  
A reach goal would be to enable the cape hardware and also to potentially provide DC relays which could switch 5-12 V at 2-3 A such that development boards could be powered on and off through the same software interface as is used for the serial communications. Since hardware is not the focus of GSoC, actual development of such hardware should not be the focus of the project itself.<br>
+
==GPGPU with GLES==
''Hardware Skills'': Datasheet/specification reading<br>
+
The BeagleBone and related boards all have a built in GPU that is often unused. It would be useful to create samples showing how it can be used for GPGPU purposes.Since there is no OpenCL drivers, this would need to be done with OpenGLES 2.0. The samples should take data from a C style array and load it onto the GPU. The GPU would then perform the task using sample shader code. The processed data would be retrieved from the GPU back into another C style array. A few processing tasks can be shown - simple do nothing to illustrate moving data between the CPU and the GPU and a real processing task such as running the image against a small kernel (convolution). Sample programs should also have a way of showing the time costs in moving data between GPU and CPU.  
''Software Skills'': C programming/Linux kernel programming<br>
 
''Possible Mentors'': Michael Welling<br>
 
''Upstream Repository'': N/A<br>
 
''References'': N/A
 
  
[[Category: BeagleBoard]]
+
==Low-Power Wide Area Networking==
[[Category: GSoC]]
+
A number of wireless connectivity solutions to low-cost sensor nodes exist, including things built around TI CC13x, LoRa, narrow-band LTE and other [https://en.wikipedia.org/wiki/LPWAN low-power wide area networks]. Projects that create tools and learning around these technologies should find a large user and mentor community around BeagleBone.
[[Category: Beagle-Offloader]]
 
  
 +
===Greybus over 802.15.4===
 +
802.15.4-based Greybus (instead of Unipro as used by Project Ara), where every [http://www.ti.com/tool/LAUNCHXL-CC1352R1 CC1352 Launchpad] shows up as new SPI, I2C, UART, PWM, ADC, and GPIO controllers that can now be probed to load drivers for the sensors or whatever is connected to them.
 +
<br>
 +
''Goal:'' Upstream kernel patches to support USB-UART connected CC1352 Launchpad with a fixed host firmware load talking to a CC1352 Launchpad with a fixed client firmware load and exposing SPI, I2C, UART, PWM, ADC and GPIO controllers.<br>
 +
''Hardware Skills:'' I2C, SPI, UART, PWM, ADC, GPIO basic wiring<br>
 +
''Software Skills:'' C, Linux, BeagleBone, Launchpad<br>
 +
''Possible Mentors:'' jkridner<br>
 +
''Upstream Repository:'' TBD<br>
 +
''References:'' https://www.youtube.com/watch?v=7H50pv-4YXw, https://bitbucket.org/nuttx/nuttx/src/master/configs/launchxl-cc1312r1/README.txt?fileviewer=file-view-default<br>
  
=Proposal=
+
==Automation and Industrial I/O==
I have completed the task required as described on Ideas page, and created a pull request, as listed [https://github.com/Akshay9414/gsoc-application here].
+
BeagleBone gets used a lot in automation tasks, be they in industrial, building, home or otherwise. Software that helps enable individual hobbyists, but can bridge into professional automation tasks, is strongly desired.
  
==About me==
+
* MikroElectronika click board manifests for the Greybus simulator, instead of device tree overlays
''IRC'': Akki<br>
+
* learning tools like BlockyTalky3 and Makecode, but with a focus on making automation easy
''Github'': [https://github.com/Akshay9414 Akshay9414]<br>
+
* open source PLC software
''School'': [http://www.iitd.ac.in IIT Delhi] <br>
 
''Country'': India<br>
 
''Primary language'': English and Hindi<br>
 
''Typical work hours'': 11AM-5PM and 9PM-2AM Indian Standard Time(+5:30)<br>
 
''Previous GSoC participation'': No I haven't participated before. I am quiet fascinated by the power Beaglebone posses and want to exploit it to its full potential to make better and better real system (particularly robots). I believe working under the guidance of such helpful people I would be able learn better, and learn more, and would be able to contribute more to our Robotics Club.
 
  
==About your project==
+
===librobotcontrol support for BeagleBone AI and Robotics Cape===
''Title'': PRUs to offload processing of raw data from on-board Peripherals (Beagle-Offloader)<br>
+
''Goal:'' Complete implementation of librobotcontrol on BeagleBone AI.<br>
 +
''Hardware Skills:'' Basic wiring<br>
 +
''Software Skills:'' C, Linux<br>
 +
''Possible Mentors:'' jkridner<br>
 +
''Upstream Repository:'' https://github.com/jadonk/librobotcontrol/tree/bbai<br>
 +
''References:''http://www.strawsondesign.com/docs/librobotcontrol/index.html<br>
  
===Inspiration===
 
The Beaglebone is equipped with a number of peripherals to interact with surrounding systems like UART for Asynchronous Serial Communication, GPIO for receiving/sending signals from/to any other device , McSPI etc. Many hobbyists who want to perform heavy task with data of these peripherals, would like to have the MPU perform only the heavy task / calculation and a separate module which is capable of handling the task of the raw data processing and put down processed data to somewhere the MPU can easily access it, thus saving time. As a choice, hobbyists would like if the separate module is very fast in processing raw data and produces a better Real Time System than the one having MPU performing all the task.
 
  
===Solution===
+
===Makecode Arcade for PocketBeagle GamePup===
BeagleBone Black's AM335x SoC, has a subsystem called PRU-ICSS, with its two independent, 32 bit RISC cores, called PRUs, located in it. The cores are designed for low latency access to the GPIs and GPOs and have a rich memory arrangement to store the data. Also, having two such cores can be very useful, as both posses the power to sampling the data at very high frequency. The PRUSS subsystem fulfill the criteria of a fast separate module given the conditions it is configured / programmed to fetch data directly from the peripherals.
+
Makecode is a framework for creating special-purpose programming experiences for beginners, especially focused on computer science education. Makecode has a blockly based programming environment served on the browser along with an in-browser board simulator. MakeCode Arcade is a similar environment to MakeCode, but the environment has code blocks that are oriented towards building games. The goal of this project is to support the Makecode Arcade target for the Beaglebone boards and demonstration of example games on the Pocketbeagle Gamepup Cape.
 +
<br>
 +
<br>
 +
''Goal:'' Makecode target for Beaglebone boards with Breadboard simulator functionality making use of a UF2 daemon running in Beaglebone<br>
 +
''Hardware Skills:'' Basic breadboard prototyping skills<br>
 +
''Software Skills:'' Linux,Javascript,PXT<br>
 +
''Possible Mentors:'' TBD<br>
 +
''Upstream Repository:'' TBD<br>
 +
''References:'' https://github.com/microsoft/pxt-arcade , https://github.com/microsoft/uf2-linux , https://beagleboard.org/capes<br>
  
===Goal for the Project===
+
==Low latency and soft peripherals using co-processors==
The goal is to be able to access on-board peripherals like the McSPI, McASP etc from the PRUs and to be able to use fetch data directly from these peripherals. This will allow to offload processing of the Raw data onto the PRUs. This project will utilise two PRUs and perform the CPU’s intensive work of processing raw data, leaving the MPU with lot of time to perform heavy tasks on this data, the task for which a general purpose OS actually is.
+
The programmable real-time units are one of the coolest features of BeagleBone. Of course, the architecture of using a main processor running a high-level operating system and co-processors running without an operating system is a general architecture. Projects that help create tools and learning around this architecture can be rather successful around BeagleBone. See https://beagleboard.org/pru.
  
The project will involve developing the following :-
+
* low-latency audio (bela.io)
    1) Device Tree Overlays : Firstly, a device tree is essentially a text file that describes the hardware to the kernel. Since many architectures do not have self-describing hardware,  
+
* LED lighting (Falcon Player, PocketScroller, etc.)
        some sort of externally supplied description is needed for the kernel to understand the system it is running on.
 
    2) C libraries for the PRUs to connect to these peripherals
 
    3) Develop Drivers to reserver the device on behalf of the PRUs
 
  
===Available Software Resources===
+
Another approach is to add support for Verilog (or VHDL) to synthesis PRU code for the soft peripherals. This can be based on the open source verilog toolchains.
'''Pru software support package''' (git://git.ti.com/pru-software-support-package/pru-software-support-package.git)  :
 
The PRU Software Support Package is an add-on package that provides a framework and examples for developing software for the Programmable Real-time Unit subsystem and Industrial Communication Sub-System (PRU-ICSS) in the supported TI processors.  The PRU-ICSS achieves deterministic, real-time processing, direct access to I/Os and meets ultra-low-latency requirements. This software package contains example PRU firmware code as well as application loader code for the host OS. The examples demonstrate the PRU capabilities to interact with and control the system and its resources.  (Reference : http://www.ti.com/tool/pru-swpkg#descriptionArea)
 
                                         
 
===Approach===
 
I the alloted time I would have to build C library support for as many peripherals as possible. So I would like to define the preference of one over another and will follow the order while making C libraries(but this may alter depending on the situation or need).
 
  
    McSPI > UART > McASP > USB > I2C > eCAP > ePWM > eQEP > CAN > Ethernet Subsystem > LCD Controller > Touch Screen Controller > ..(if something left).
+
=== PRU User Space API ===
 +
''Goal'':  Provide a simple API across multiple programming languages to use with the PRUs to load binaries, and communicate with the PRUs from userspace.

<br>
 +
''Hardware Skills'':  Minimal<br>
 +
''
Software Skills'':  Linux, C and Python programming
<br>
 +
''Possible Mentors'': Kumar Abhishek, Zubeen Tolani<br>
 +
''Upstream Repository'': https://github.com/beagleboard/linux, https://github.com/beagleboard/pypruss<br>
 +
''References'':  https://bitbucket.org/intelligentagent/pypruss, https://beagleboard.org/latest-images
  
I will try to follow above order and will try to complete them in a proper way rather than rushing down and try to write something for all.
+
===Port am335x_pru_package to remoteproc===
With the help of clpru and remote_proc, I will write C code so that PRUs can fetch data from memory registers (both local and global).
+
The am335x_pru_package is a community supported set of tools and examples on using the PRU. It includes an assembler and a C library for managing the PRU over [https://www.kernel.org/doc/html/latest/driver-api/infrastructure.html?highlight=uio#userspace-io-devices UIO]. The BeagleBoard community mostly desires to migrate PRU development to [https://www.kernel.org/doc/Documentation/remoteproc.txt remoteproc] to give the Linux kernel greater knowledge of the cores.
 +
<br>
  
===Timeline===
+
''Goal'': Move all examples to remoteproc, including adding elf support to pasm, adding an option to build using clpru and updating the C library to use the remoteproc interface for basic PRU control and using mmap() for a limited set of communications functions.<br>
I would start working at my full pace from 6th May onwards (My Semester exams will be finished by 6th May). This phase
+
''Hardware Skills'': N/A<br>
 +
''Software Skills'': C, assembly, Linux kernel<br>
 +
''Possible Mentors'': Kumar Abhishek,  Zubeen Tolani<br>
 +
''Upstream Repository'': https://github.com/beagleboard/am335x_pru_package<br>
 +
''References'': [https://git.ti.com/pru-software-support-package v5 examples] [http://processors.wiki.ti.com/index.php/PRU_Training:_Hands-on_Labs TI Training Labs ]
  
'''Now - May 4 (Before Result Declaration):'''
+
===Create a PRU based soft-peripheral example===
 +
The PRU is a hard realtime co-processor with dedicated realtime pins. Previous GSoC have created an assortment of examples
 +
and foundation pieces. However, most of them have custom interfaces. This project is to tie things together to implement
 +
at least one example of using the PRU with a standard interface. For example, this can be a SPI master interface that
 +
can be bound with another peripheral via DT.
  
    1) Study the pru-software-support-package and write some basic code get more insight of its working.
+
''Goal'': Create at least one non trivial example that includes both the PRU firmware and the kernel driver interface. Utilization of remoteproc (other means of loading the firmware will be considered provided it is appropriately justified) to
    2) Start writing basic programs for PRUs using remoteproc
+
load the firmware and control the PRU. A device driver should expose the functionality using standard kernel APIs. The example
 
+
should NOT be a trivial one (i.e. GPIO controller, simple input events, plain on-off LEDs) unless proper justification
'''May 4 - May 30 ( Community Bonding Period):'''
+
is provided. Simple non trivial possible examples include SPI master, I2C master (potential HW issues), or UART. This project
To complete the project well in time I would utilize this time to improve my knowledge
+
includes creating the relevant PRU firmware.<br>
 
+
''Hardware Skills'': Some understanding of I/O is needed esp if the I2C master is choosen.<br>
    1) Study the work on PRUs in previous GSoC projects like PRU-Framework, this will help me broadening my scope of thinking about the implementation of my project.
+
''Software Skills'': C, assembly, Linux kernel<br>
    2) Study the architecture defined of all peripherals and listing out the details so as to save time during the final coding time.
+
''Possible Mentors'': Kumar Abhishek, Zubeen Tolani<br>
    3) During this period I will remain in constant touch with my mentor and the BB community. I will remain active on IRC to discuss and finalize on the modifications (if any)
+
''Upstream Repository'': N/A<br>
        that needs to be on existing schemas and design of new schemas (if needed).
+
''References'': BeagleLogic & BeagleScope from previous years.
    4) Thus with the help of my mentor I will become absolutely clear about my future goals,the final implementations that need to be done as well as the approach.
 
 
 
 
 
As the number of peripherals are good enough so I would be working for 55-60 hours per week or may be even more to complete as many as possible.I  be sharing my progress with the mentors and will regularly write blogs.
 
 
 
'''Week 1 :''' (Unpacking Week)
 
    1) Setup everything which includes flashing BB with required image and installing the required softwares.  
 
    2) Try a few basic examples like PRU_blinky to check the working of remote_proc.
 
    3) Start off with writing C code for first peripheral i.e McSPI .
 
'''Week 2 :'''
 
    1) Basic framework OF McSPI will be completed in the first week. Further improvisation of the code including writing DTS files.
 
    2) Start off with the second peripheral i.e UART.
 
'''Week 3 :'''     
 
    1) Basic framework of UART will be completed in the first week. Further improvisation of the code including writing DTS files
 
    2) Prepare example code with proper comments for other's understanding.
 
    3) A buffer will be kept for unpredictable delays but if situation is good then will start the work of writing the drivers.
 
'''Week 4 :'''  (First Evaluation)
 
    1) Complete the work of writing drivers for at least one of them.
 
    2) This week I would completely focus over testing my two subsystems / peripherals.
 
    3) Fixing the bugs and exception handling.
 
'''Week 5 :'''  Work of the previous weeks will decide the fate of what I will be doing this week. Good four weeks will shine their light on my future work as work will proceed much faster than before.  
 
    1) Start this week with writing C code for handling McASP peripheral.
 
    2) This time I will try to complete McASP C code along with DTS file and detailed example.
 
'''Week 6 :'''
 
    1) This week's work would focus on writing C code the handle USB subsystem using PRU along with its DTS file.
 
    2) This period has been kept for any unpredictable delay.
 
'''Week 7 :'''
 
    1) This week's work would focus on writing C code the handle I2C protcol using PRU along with its DTS file.
 
'''Week 8 :''' (Second Evaluation)
 
    1) This week I will focus on testing of the modules along with writing example code.
 
    2) Bugs fixing and exception handling.
 
    3) Start writing the drivers for all.
 
'''Week 9 :'''
 
    1) First priority would be complete the drivers and test them.
 
    2) Writing scripts with proper instructions to make life easier for others.
 
'''Week 10:'''  
 
    1) More testing and basic documentation.
 
    2) Will improvise the prepared modules until the mentor satisfies there is no more need or scope.
 
    3) Will start working on more peripherals depending upon the situation and what mentor suggest.
 
'''Week 11:'''
 
    1) This period has been kept for avoiding any unpredictable delay and if situation seems to fine then start the work of a new peripheral possibly eCAP.
 
'''Week 12:''' (Final Evaluation)
 
    1) Finalize the work and make proper documentation.
 
    2) Update my repository with final modules.
 
    3) Making the youtube installation and tutorial videos.
 
    4) Submit my work for final evaluation.
 
 
 
=Experience and approach=
 
I am a core team member of ROBOTICS CLUB IITD and represented my college for ABU NATIONAL ROBOCON INDIA 2017. During this period one of my tasks was to create an easy and user friendly platform like Arduino for BBB (so that anyone could code easily without worrying much about the backend details). Current Wiring Bone library (https://github.com/AbhraneelBera/wiringBone) supports almost all core actions and functions but is slow in terms of pin toggling. My work included integration of basic Arduino features from Wiring Bone along with addition of features of Libpruio (http://beagleboard.org/project/libpruio/) for fast pin control. I also extended my work and built new C libraries for using pins in eQEP mode for reading values of quadrature encoder and customising DTO according to my need.
 
 
 
In my "Digital Logic and System Design" course final project I wrote a UART protocol for Xilinx Atlys FPGA and demonstrated the working by finding the frequency components of an input audio signal using transforms and plotting them in MATLAB using the above mentioned serial communication protocol.
 
 
 
In my “Design Practices” I have learned various tools like Lexer , Parser , Debuggers, Multithreading.
 
 
 
In my “Data Structures and Algorithms” I learned various algorithms,organisation and computation of data using well defined structures.
 
 
 
In my “Computer Architecture” course I am currently working on a semester project to implement ARM-RISC instruction set on a BASYS-3 FPGA in VHDL programming. This has greatly improvised my understanding of working and design of ARM processor in a great detail. I have also learnt about assembly language to quiet a good extent.
 
  
I am an enthusiastic and hardworking student and have been able to prove myself on every occasion provided. I am a good learner and quite confident that I would be able to learn the required and complete my project in the allotted time.
+
===Reference Design For A GPIO-based Parallel Bi-Directional Bus===
 +
While the BeagleBone family has a large number of pins available on their P8/P9 headers, projects requiring a large amount of GPIO I/O may still be infeasible due to pinmux conflicts with other interfaces (SPI, UARTs, etc.). The newer PocketBeagle platform is even more restricted in the number of available GPIOs for interfacing. In addition, bi-directional bus communication using GPIOs is infeasible, as each GPIO is configured for either input or output. This project will combine your hardware and software skills to address these limitations by creating a shift register-based hardware design that will allow serial streams of data going in/out of the PocketBeagle or BeagleBone family GPIOs to be mapped into a bi-directional communications bus. Some practical uses of this are for GPIO-based game controller inputs (using *lots of buttons*), communication address/data buses for interfacing with older microcontrollers and microprocessors, and providing large numbers of logical bi-directional GPIOs.
  
 +
''Goal'': Create a hardware/software design will incorporate shift registers (and potentially logic level converter solutions as appropriate) to allow BB.org hardware to communicate with hardware via a parallel, bi-directional bus. Create a software design that incorporates both a kernel driver to communicate with the parallel bus and a user space application/library using ioctl() calls to communicate with this kernel driver. Using the PRU to implement the low-level details of the bus (clock/latch signalling, reading/writing data) is encouraged! The kernel device tree fragment associated with the kernel driver shall configure it by specifying the number of parallel lines to use, the input/output/both direction of each bus signal, and the GPIOs allocated to the serial input/output/clock/latch signals.<br>   
 +
''Hardware Skills'': Basic digital logic (i.e. comfortable prototyping IC-based circuits on a breadboard, understanding of buses and signals, able to read/write/understand schematics), use of logic analyzer/multimeter/oscilloscope as needed for troubleshooting, ability to read component data sheets.<br>
 +
''Software Skills'': C, kernel driver development, kernel device tree, PRU programming, interfacing with kernel drivers using ioctl() calls from user space.<br>
 +
''Possible Mentors'': Andrew Henderson, Zubeen Tolani<br>
 +
''Upstream Repository'': TBD<br>
 +
''References'': http://www.ti.com/lit/ds/sdfs071b/sdfs071b.pdf , https://www.arduino.cc/en/Tutorial/ShiftOut
  
=Contingency=
+
==PocketBeagle Stepwise Mathematics==
In case of problem, I would search for it on google,stack-overflow,BB community or consult someone over IRC. But in bad cases as I am a member of Robotics Club IIT Delhi. Head of our Robotics club Prof. Kolin Paul (http://www.cse.iitd.ernet.in/~kolin/Kolins_Web_Home/My_Home.html), whose field of study is Hardware and Embedded System Security will always be eager to help me along with some other seniors of our club. Also we have an Assistech Lab in our department ,headed by Prof. M Balakrishnan (http://www.cse.iitd.ernet.in/~mbala/) in which research scholars are available round the clock.  
+
Goal: The big picture goal is a stealth Step wise solution prompting Scientific Calculator based on the Pocket Beagle Residing in a Popular Brand Casing.The examinar should not be able to figure out any changes made to the approved exam Calc/Machine.The Calculator takes input from the User in terms of a completely formed mathematical problem and gives the step wise output on the display. Something similar to Sympolab or Wolfgram Alpha.
 +
   
 +
Hardware Skills: Medium. Ability to Interface/Integrate a Membrane/Capacitive Keyboard and a 
 +
Matrix display.Ability to Get the Beagle running on a Lithium Ion thin Battery.  
  
 +
Software Skills: Python, C/C++, Linux, Knowledge of Compiler's     
  
=Benefit=
+
Possible Mentors: 
In a system with many input/output peripherals, it is a good practice to distribute the work among different cores (in case of multi core processor) or use two or more MCU communicating with each other and sharing the load rather than one doing all the task. In our case offloading raw data processing is helping in same manner by sharing the work of MPU. This project will help many BB developers to easily configure peripherals according to their needs and focus their time other things.
 
  
    ***Mentors!!! please add your Quote here.***
+
Upstream Repository: N/A
 +
 +
Refrences: N/A
  
=Suggestions=
+
==Security and Privacy==
Nothing for now.
+
The BeagleBoard.org community cares a lot about understanding how information is managed. Projects that open up technology for more personal control and help secure data from external manipulation are generally well accepted. Consider how you can make contributions to existing projects in this area.
  
Thanks.
+
* penetration testing (The Deck, Kali)
 +
* security appliance (Pangolin, ZeroTier Edge device)
 +
* self-hosted services (Freedombone)
 +
* car hacking (Macchina)
  
==Port BeagleBone USB-based bootloader server from C to JavaScript (node.js)==
+
Example idea, a portable/plugable security appliance for use anywhere:
The BBBlfs project is capable of booting a BeagleBone into USB mass storage class mode. This will eventually be integrated into a variant of http://etcher.io to make an all-in-one BealgeBone flasher/updater.
 
<br>
 
  
''Goal:'' Booting BeagleBone into USB mass storage class mode should be as easy as 'npm install beaglebone-boot; cd node_modules/beaglebone-boot; npm start' and connecting the board with the BOOT button pressed via USB.<br>
+
* hardware: beaglebone with ethernet or beaglebone wireless, pocketbone + USB ethernet/wifi
''Hardware Skills:'' understanding bootloaders, knowledge of USB<br>
+
* OS: openwrt
''Software Skills:'' C, JavaScript (node.js)<br>
+
* configuration UI: bonescript/other
''Possible Mentors:'' Jason Kridner<br>
+
* PRU accelerators...
''Upstream Repository:'' TBD (https://github.com/beagleboard/node-beaglebone-boot)<br>
+
* privacy and safety tools...
''References:'' https://github.com/ungureanuvladvictor/BBBlfs, https://boundarydevices.com/u-boot-usb-mass-storage-gadget/, https://github.com/tessel/node-usb<br>
 
  
==Re-purpose PiTop Power Interface for BeagleBone==
+
=== Make port of Xen on BeagleBoard-x15 ===
Port power monitor and backlight software to Beaglebone SPI interface (using prototype power cable) and integrate with standard desktop power interface (upower/pm-utils dbus abstraction). Replace existing UI with desktop integration (ie, LXQT and XFCE power managers).
+
The project idea is to make Xen hypervisor available and easy to use on beagleboard-x15. To achieve this, it is planned to write Xen-supporting code and tutorials for Xen setup on the board. Another project goal is to improve user experience by working on optimizations for Beagleboard's kernel virtualization support code and/or on user-space tools. <br>
 +
Previously, the problem was discussed in [https://lists.xen.org/archives/html/xen-users/2018-01/msg00119.html xen mailing list] and in [https://groups.google.com/forum/#!msg/beagleboard/HVZ7kpVM_bE/vxsa2SvPCAAJ beagleboard mailing list]. The general solution wasn't provided and it seems that the problem still does exist. <br>
 +
The virtualization will make prototyping of virtualization-based security solutions easier in such areas like automotive computing and mobile privacy (BYOD problems).
 
<br>
 
<br>
  
''Goal'': Battery status, power/backlight control on BeagleTop running standard Debian desktop.<br>
+
''Goal'': to make virtualization available for end-users on Beagleboard-x15.<br>
''Hardware Skills'': Datasheet/specification reading, wiring.<br>
+
''Hardware Skills'': basic electronics.<br>
''Software Skills'': C and Python, some knowledge of XDG desktop specification<br>
+
''Software Skills'': C, C++, Linux kernel, Xen.<br>
''Possible Mentors'': Michael Welling, Stephen Arnold, Stephanie Lockwood-Childs<br>
+
''Possible Mentors'': Andrew Henderson, Michael Welling. <br>
''Upstream Repository'': [https://github.com/rricharz/pi-top-install pi-top-install]<br>
+
''Possible Co-mentors'': Stefano Stabellini, Julien Grall, Iain Hunter. <br>
''References'': [https://www.freedesktop.org/wiki/Specifications/ freedesktop.org specs] [https://learn.adafruit.com/pi-top-assembly/raspberry-pi-to-base hub assembly]
+
''Upstream Repository'': N/A. <br>
 +
''References'': [https://lists.xen.org/archives/html/xen-users/2018-01/msg00119.html xen mailing list] [https://groups.google.com/forum/#!msg/beagleboard/HVZ7kpVM_bE/vxsa2SvPCAAJ beagleboard mailing list]
  
==Fix bugs in BoneScript==
+
==Beagle Bone Audio Network Streaming==
Run through the issues list at http://github.com/jadonk/bonescript/issues and fix them!
+
Goal: Building on a Beagle GSoC project of 2017, the idea is to extend / add audio network streaming capabilities using the AVB and / or the SMPTE2110/30 (and SMPTE2022/7) standards.
<br>
 
  
''Goal'': Close all issues.<br>
+
Background / References: https://elinux.org/BeagleBoard/GSoC/BeagleBoneAVB
''Hardware Skills'': Wiring LEDs and simple sensors<br>
 
''Software Skills'': JavaScript and Linux<br>
 
''Possible Mentors'': Jason Kridner<br>
 
''Upstream Repository'': https://github.com/beagleboard/bonescript<br>
 
''References'': http://beagleboard.org/bonescript
 
  
==Port am335x_pru_package to remoteproc==
+
Software Skills: C/C++, Linux, Kernel
The am335x_pru_package is a community supported set of tools and examples on using the PRU. It includes an assembler and a C library for managing the PRU over [https://www.kernel.org/doc/html/latest/driver-api/infrastructure.html?highlight=uio#userspace-io-devices UIO]. The BeagleBoard community mostly desires to migrate PRU development to [https://www.kernel.org/doc/Documentation/remoteproc.txt remoteproc] to give the Linux kernel greater knowledge of the cores.
 
<br>
 
  
''Goal'': Move all examples to remoteproc, including adding elf support to pasm, adding an option to build using clpru and updating the C library to use the remoteproc interface for basic PRU control and using mmap() for a limited set of communications functions.<br>
+
Possible Mentors: rma
''Hardware Skills'': N/A<br>
 
''Software Skills'': C, assembly, Linux kernel<br>
 
''Possible Mentors'': Jason Kridner, Kumar Abhishek<br>
 
''Upstream Repository'': https://github.com/beagleboard/am335x_pru_package<br>
 
''References'': [https://git.ti.com/pru-software-support-package v5 examples] [http://processors.wiki.ti.com/index.php/PRU_Training:_Hands-on_Labs TI Training Labs ]
 
  
 
=Mentors=
 
=Mentors=
Line 334: Line 298:
 
| JavaScript, C, u-boot
 
| JavaScript, C, u-boot
 
| wiring, timing diagrams, basic debug
 
| wiring, timing diagrams, basic debug
| BoneScript development
+
| BoneScript development, deep learning, long-range wireless mesh networking
 +
|-
 +
| Hunyue Yau
 +
| ds2
 +
| English
 +
|
 +
| Pacific
 +
| C, PASM
 +
| Any
 +
| No specific focus/any
 +
|-
 +
| Kumar Abhishek
 +
| Abhishek_
 +
| Hindi
 +
| English
 +
| IST
 +
| C, PRU Assembly, bit of JS
 +
| Almost everything
 +
| PRU- or kernel- based projects, but could help with any project
 +
|-
 +
| Ravi Kumar Prasad
 +
| ravikp7
 +
| Hindi
 +
| English
 +
| IST
 +
| JavaScript, C
 +
| Wiring, Basic debugging
 +
| BeagleBoot
 
|-
 
|-
 
| Michael Welling
 
| Michael Welling
Line 340: Line 331:
 
| English
 
| English
 
| -
 
| -
| US Central
+
| US Pacific
 
| C, Linux kernel
 
| C, Linux kernel
 
| schematics, PCB, FPGA, Robotics
 
| schematics, PCB, FPGA, Robotics
| Kernel development
+
| kernel development
 
|-
 
|-
| Robert Manzke
+
| Patryk Mezydlo
| rma
+
| pmezydlo
| German
+
| Polish
| English, Spanish
+
| English
 
| CET
 
| CET
| C, C++, JavaScript, Audio Processing, OpenGLES, GLSL
+
| C, kernel development
| Cape Design, Audio Codecs, SPI
+
| datasheets, schematic review, debug, kicad
| Audio FX Project, OpenGLES on Beaglebone
+
|
 
|-
 
|-
| Henrik Langer
+
| Cathy Wicks
| henrix_
+
| cwicks
| German
+
| English
 +
| -
 +
| US Central
 +
| -
 +
| -
 +
| GSoC Admin, Organizational
 +
|-
 +
| Henderson, Andrew
 +
| hendersa
 
| English
 
| English
| CET
+
| -
| Linux kernel, C, C++, Audio Processing, OpenCL, JavaScript
+
| EST/EDT (UTC-5)
| Audio Codecs, I2S, SPI, I2C
+
| C/C++, PRU, Linux userspace/kernel
| Audio FX Project
+
| Prototyping, Eagle PCB
 +
| PRU/Kernel projects, Linux userspace multimedia, Security
 
|-
 
|-
| Hunyue Yau
+
| Drew Fustini
| ds2
+
| pdp7
 
| English
 
| English
|
+
| -
| Pacific
+
| CET and US CDT
| C, PASM
+
| C, Python, Linux
| Any
+
| schematics, PCB layout, KiCad
| No specific focus/any
+
| Python libraries (Adafruit_BBIO & Blinka), Linux drivers
 
|-
 
|-
 
| Zubeen Tolani
 
| Zubeen Tolani
Line 377: Line 377:
 
| English
 
| English
 
| IST
 
| IST
| C, PASM
+
| C, C++, Java, JS, PRU assembly
| PRU, basic debug, wiring
+
| Basic
| PRU based projects
+
| PRU, Kernel, Deep learning
 
|-
 
|-
| Stephen Arnold
+
| Robert Manzke
| nerdboy
+
| rma
| English
+
| German
| Math
+
| English, Spanish
| PST8PDT
 
| kernels, toolchains, libraries, Python, sensor buses, yocto/OE
 
| Components/Data sheets, wiring/breadboard, debug
 
| Data acquisition, earth science, other fun stuff
 
|-
 
| Vladimir Pantelic
 
| av500
 
| English, German
 
| Math
 
 
| CET
 
| CET
| C, kernel, Android, embedded computing
+
| C, C++
| Components/Data sheets, wiring/breadboard, debug
+
| PCB, mixed mode design
| electronic music, microcontrollers
+
| Audio, media network streaming protocols
 
|-
 
|-
| Jonathan Cameron
+
| Stefano Stabellini
| Jic23
+
| sstabellini
 +
| Italian
 
| English
 
| English
|
+
| PST
| GMT
+
| Xen, C, kernel development
| Kernel
+
| -
|  
+
| Xen on Beagleboard
|
 
 
|-
 
|-
| Matt Porter
+
| Julien Grall
| mdp
+
| julieng
 +
| French
 
| English
 
| English
| C
+
| GMT/BST
| EST5EDT
+
| Xen, C, kernel development
| U-Boot, kernel, USB, DMA, performance
+
| -
| data sheets, schematic review, debug
+
| Xen on Beagleboard
|  
 
 
|-
 
|-
| Trevor Woerner
+
| Iain Hunter
| tlwoerner
+
| driain
 
| English
 
| English
|
+
|  
| EST
+
| GMT/BST
| C, userspace/app development, embedded development, real-time, OE/Yocto/build/CI
+
| C, kernel,yocto
|
+
| Cape design
|
 
|-
 
| Anuj Deshpande
 
| anujdeshpande
 
| English
 
|
 
| GMT+530
 
| C, Python, JavaScript. Userspace, web app.
 
| debug, schematic
 
 
|  
 
|  
 
|-
 
|-
| Kumar Abhishek
+
| Steve Arnold
| Abhishek_
+
| nerdboy
| Hindi, English
 
| -
 
| IST (+0530)
 
| PRU assembly
 
| Yes
 
| BeagleLogic
 
|-
 
| Henderson, Andrew
 
| hendersa
 
 
| English
 
| English
|
+
| Applied Math
| EST/EDT (UTC-5)
+
| PST8PDT
| C/C++, ARM asm, Linux, Linux kernel, Android
+
| Python, toolchains, OS integration, architecture
| Prototyping, Eagle PCB
+
| beaglebones, sensors
| BeagleBone Black, Android, Linux userspace multimedia
+
| Networking, security/privacy tools, Yocto/Gentoo
 
|-
 
|-
 
| Name
 
| Name
Line 462: Line 435:
 
| Focus projects
 
| Focus projects
 
|}
 
|}
[[BeagleBoard/GSoC/Ideas-2016#Mentors|Previous mentors]]
+
[[BeagleBoard/GSoC/Ideas-2018#Mentors|Previous mentors]]

Revision as of 16:30, 17 February 2020


Welcome!

BeagleBoard.org is applying to be a mentoring organization in the Google Summer of Code for 2020! Below, we're collecting project ideas for the GSoC-2020.

What is Google Summer of Code?

Spend your summer break writing code and learning about open source development while earning money! Accepted students work with a mentor and become a part of the open source community. Many become lifetime open source developers! The 2020 student application window is open March 16th 2020!

Google Summer of Code is open to post-secondary students, age 18 and older in most countries.

Read more on the GSoC site and the FAQ.

BeagleBoard.org Background

BeagleBoard.org is a volunteer organization that seeks to advance the state of open-source software on open-source hardware platforms capable of running high-level languages and operating systems (primarily Linux) in embedded environments. Born from taking mobile phone processors and putting them on low-cost boards to build affordable desktop computers, BeagleBoard.org has evolved to focus on the needs of the "maker" community with greater focus on the I/O needed for controlling motors and reading sensors to build things like robots, 3d printers, flying drones, in-car computer systems and much more. Past BeagleBoard.org GSoC projects included creating an interpreter for tiny CPUs, adding SPI and sensor support to Python, an HTML and git based tutorial sharing environment, porting autopilot software to Linux, an open source 100MHz 14-channel logic analyzer, using Android tablets as Linux displays, putting ADC support in Linux under the IIO framework, using Android phones as a network boot source, Running Arduino code on Linux, Robot Operating System support within the Yocto Project build system, Minix I2C support, an RPC framework for heterogeneous processor communication, a transparent USB packet sniffer, ARM optimizations for XBMC, ARM optimizations for FFTs, make-shift pulse-width-modulation and RPC optimizations for OpenCV. BeagleBoard.org has benefited from sponsorship from Texas Instruments, Circuitco, Digi-Key, element14 and others, but avoids any dependence on that sponsorship for sustaining the effort. The project has evolved over the past few years with over 1,000,000 boards in circulation with developers worldwide and strong roots in the Linaro, Yocto Project, Angstrom Distribution, Debian and Linux communities---and support for running most major Linux distributions including Ubuntu, Android, Fedora, ArchLinux, Gentoo, Buildroot and many more.

BeagleBoard was inspiration for Raspberry Pi[1] and PocketBeagle is available for about $25 through over 30 distributors world-wide (and is even available at Micro Center in the USA), but is more than a throw-away computer. It is an instance of true open hardware, exposing users to the broader world of electronics, demystifying computers and fostering an environment of clones that have changed the industry for good.

Students will be expected to demonstrate an understanding of cross-compiling before being accepted, but support for demonstration is available through the IRC channel that typically has approximately 150 online chatters logged on at any time, most with sufficient experience to explain the process.

Every accepted student will be sent a PocketBeagle, TechLab or GamePup, and either a BeagleBone AI, BeagleBone Black Wireless, BeagleBone Black, BeagleBone Blue, SeeedStudio BeagleBone Green, SeeedStudio BeagleBone Green Wireless or BeagleBoard-X15 before the first week of coding for testing their project.

Additional hardware will be provided depending on need and value.

For more information, check out https://beagleboard.org and https://beagleboard.org/brief.

Students looking for ideas

Student proposals can encompass projects inspired from the following list of ideas or can include personal project ideas. Previous Google Summer of Code projects show that the key to success is being passionate about your project, so propose something that is extremely interesting to you, even if it is not on this list. We will be glad to help students develop ideas into projects via the BeagleBoard GSoC IRC or the BeagleBoard-GSoC mailing list. There are many potential project ideas and we will match students to projects based on their interests and help scope the proposals to something that can be completed in the Summer of Code timeframe.

There are more than 500 existing projects listed at http://beagleboard.org/project. If you are interested in any of the projects listed on the BeagleBoard.org projects page, contact the project members to see if there are any aspects of their projects that can be enhanced to create a GSoC project. There are also several ideas on the ECE497 class project idea list. You can also check out last year's idea page.

Mentors wondering where to help

Please start by registering your ideas for student projects below by following the template provided with the existing ideas. Furthermore, scroll down to the bottom and give everyone a bit of information about your expertise and availability by adding yourself to the table. Jason will make final approvals for mentor assignments based on if we first get accepted as a mentoring organization and best matching mentor skill sets with student project ideas deemed valuable to the community.

You will also need be invited by an administrator to register on the GSoC site and request to be a mentor for BeagleBoard.org.

General requirements

All projects have the following basic requirements:

  1. Students must create accounts on Github, eLinux, Freenode and Google Groups prior to creating their application.
  2. All newly generated materials must be released under an open source license.
  3. Individual students shall retain copyright on their works.
  4. Students will demonstrate their ability to cross-compile and utilize version control software by creating a "Hello World" application and generating a pull request to https://github.com/jadonk/gsoc-application/tree/master/ExampleEntryJasonKridner. For assistance, please visit http://bbb.io/gsocchat or utilize the beagleboard-gsoc Google Group. The "Hello World" application must print your name and the date out in an ARM Linux environment. Freely available emulators may be used to test your application or you can ask anyone on the chat or mailing list to help you test.
  5. All projects will produce reusable software components and will not be "what–I-built-over-my-summer-vacation" projects. Including a hardware component is welcome, but the project *deliverable* will be software that may be utilized by a wide audience of the BeagleBoard.org community.
  6. Students will demonstrate their ability to collaborate by creating an eLinux wiki page for their proposal and utilizing Freenode to collect quotes regarding the usefulness of their proposal to the BeagleBoard.org community. The wiki timestamp will help mentors recognize the provenance of ideas from prospective students. Use of Google Docs for proposal development is discouraged due to insufficient revision control and extensive use of computing resources having numerous documents open simultaneously.
  7. Source code generated during the project must be released on Github (to be cloned to github.com/beagleboard or merged with appropriate upstream project upon successful completion).
  8. To help you to break your project down into manageable chunks and also to help the project's mentors to better support your efforts, weekly project status reports should be e-mailed to the the beagleboard-gsoc Google Group. Each status report should outline:
    1. what was accomplished that week,
    2. any issues that prevented that week's goals from being completed and
    3. your goals for the next week.
  9. Students will provide two recorded audio/video presentations uploaded to Youtube or Vimeo (screencasts are appropriate), one near the beginning of the project summarizing their project goals and another in the wrap-up phase to summarize their accomplishments. Examples can be found on http://beagleboard.org/gsoc. There is no requirement to show your faces or use English.

Idea template

Please place your idea in a suitable section.

Summarizing project name

Longer summary of the project.
Goal: Concise statement that describes completion.
Hardware Skills:
Software Skills:
Possible Mentors:
Upstream Repository:
References:

Ideas

Throughout all of these ideas, contributions specifically contributing to the Linux kernel will be given extra attention. The ability for the BeagleBoard.org community to leverage software created out of GSoC is greatly expanded when those contributions land in the upstream Linux kernel where they are shared across many platforms and maintained by the broadest possible support community. In each application area, consideration how a kernel module submitted upstream could be a central component should be considered. In lieu of contributing to the Linux kernel, finding an upstream project, like ArduPilot, RTEMS, DonkeyCar, etc., where there is already an active community, is strongly desired. Of course, some projects are very BeagleBone-specific, like Adafruit_BBIO and BoneScript, and those projects do have an active user community and contributions are welcome in those areas, but more weight is given the more broad the impact of the coding project is. We've seen bug fixing projects to be very productive as well.

Feel free to look at previous ideas and migrate some here.

Kernel improvements

Improvements to the Linux kernel or kernel related projects in userspace that powers the basic infrastructure on which the BeagleBoard runs.

USB configfs in device tree

To speed up the boot process by configuring USB statically in the device tree instead of it being conventionally done through a script at boot time.
Goal: USB configfs in device tree such that they can be configured statically in device tree ahead of boot and speed the boot process.
Hardware Skills: USB
Software Skills: C, Linux kernel, USB configfs
Possible Mentors: rcn-ee
Upstream Repository: https://github.com/beagleboard/linux/tree/4.19 kernel.org
References: https://events.static.linuxfound.org/sites/events/files/slides/USB%20Gadget%20Configfs%20API_0.pdf


mikroBus driver

mikroBus is a mikroElektronkia developed standard with I2C, UART, SPI, ADC, PWM and GPIO. These embedded busses are non-probable, so configuration today occurs via device tree. Even if the peripheral is described today, most device drivers using these busses require some additional GPIO resources, like an interrupt signal or reset line. A mikroBus implementation would provide all platform data necessary for drivers to successfully probe due to having all the resources assigned and by becoming probable through the addition of an I2C EEPROM, much like Cape Bus was out-of-tree. The big differences are that mikroBus is a standard implemented on many boards, it is far more regular and it is constrained in its definition not requiring the loading of device tree fragments to complete configuration as the additional platform data can come from the additional provided GPIO resources.
Goal: With an added I2C identifier, any Click board for which drivers exist in Linux simply enumerates on PocketBeagle TechLab mikroBus port without any new device-tree entries.
Hardware Skills: UART, I2C, SPI, ADC, GPIO and PWM
Software Skills: C, Linux kernel
Possible Mentors: jkridner
Upstream Repository: https://github.com/beagleboard/linux/tree/4.19 kernel.org
References: https://www.mikroe.com/mikrobus

Cape compatibility layer for BeagleBone Black and BeagleBone AI

Goal: Use same references to drivers for peripherals assigned to the same pins between Black and AI.
Hardware Skills: UART, I2C, SPI, ADC, GPIO and PWM
Software Skills: C, Linux kernel
Possible Mentors: jkridner
Upstream Repository: https://github.com/beagleboard/linux/tree/4.19 kernel.org
References: Beagleboard:BeagleBone cape interface spec

Deep Learning

BeagleBoard-X15 has accelerators for running deep learning tasks using TIDL (1, 2). We'd love projects that enable people to do more deep learning application and end-nodes and leverage cloud-based training more easily. Goal here is to create tools that make learning about and applying AI and deep learning easier. Contributions to projects like ArduPilot and DonkeyCar (DIY Robocars and BlueDonkey) to introduce autonomous navigation to mobile robots are good possible candidates.

YOLO models on the X15/AI

Port the YOLO model(s) to the X15/AI so the accelerator blocks can be leveraged. Currently, running a frame through YOLOv2-tiny takes anywhere from 35 sec to 15 second depending on the how the code is run on the ARM.35 second being a pure brute force compilation for ARM; 15 second utilizing NEON and tweaked algorithms. The goal is to get things down to 1 second or less using the onboard accelerators. Note, there are over 6 different variants of YOLO (YOLOv1, YOLOv2, YOLOv2 and each one has a full size and a tiny version). The main interest is in getting either the YOLOv2 or YOLOv3 versions running. Please discuss with potential mentors on the desired approach as there are many approaches. Just to name a few: Porting the YOLO model into TIDL; OpenCL directly; OpenCL integration with the acceleration library; Integrating TIDL support with an acceleration library.
Goal: Run YOLOv2 or YOLOv3 with the onboard hardware acceleration.
Hardware Skills: None
Software Skills: C, C++, Linux kernel, Understanding of NNs and Convolution.
Possible Mentors: Hunyue Yau
Upstream Repository: Numerous
References: https://pjreddie.com/darknet/yolo/

OpenGLES acceleration for DL

Current acceleration on the X15/AI focuses on using the EVE and DSP hardware blocks. The SoC on those boards also feature an OpenGLES enabled GPU. The goal with this is to utilize shaders to perform computations. A possible frame work to utilize this on is the Darknet CNN framework.
Goal: Accelerate as many layers types as possible using OpenGLES.
Hardware Skills: None
Software Skills: C, C++, Linux kernel, OpenGLES, Understanding of NNs and Convolution.
Possible Mentors: Hunyue Yau
Upstream Repository: Numerous
References: https://pjreddie.com/darknet/

GPGPU with GLES

The BeagleBone and related boards all have a built in GPU that is often unused. It would be useful to create samples showing how it can be used for GPGPU purposes.Since there is no OpenCL drivers, this would need to be done with OpenGLES 2.0. The samples should take data from a C style array and load it onto the GPU. The GPU would then perform the task using sample shader code. The processed data would be retrieved from the GPU back into another C style array. A few processing tasks can be shown - simple do nothing to illustrate moving data between the CPU and the GPU and a real processing task such as running the image against a small kernel (convolution). Sample programs should also have a way of showing the time costs in moving data between GPU and CPU.

Low-Power Wide Area Networking

A number of wireless connectivity solutions to low-cost sensor nodes exist, including things built around TI CC13x, LoRa, narrow-band LTE and other low-power wide area networks. Projects that create tools and learning around these technologies should find a large user and mentor community around BeagleBone.

Greybus over 802.15.4

802.15.4-based Greybus (instead of Unipro as used by Project Ara), where every CC1352 Launchpad shows up as new SPI, I2C, UART, PWM, ADC, and GPIO controllers that can now be probed to load drivers for the sensors or whatever is connected to them.
Goal: Upstream kernel patches to support USB-UART connected CC1352 Launchpad with a fixed host firmware load talking to a CC1352 Launchpad with a fixed client firmware load and exposing SPI, I2C, UART, PWM, ADC and GPIO controllers.
Hardware Skills: I2C, SPI, UART, PWM, ADC, GPIO basic wiring
Software Skills: C, Linux, BeagleBone, Launchpad
Possible Mentors: jkridner
Upstream Repository: TBD
References: https://www.youtube.com/watch?v=7H50pv-4YXw, https://bitbucket.org/nuttx/nuttx/src/master/configs/launchxl-cc1312r1/README.txt?fileviewer=file-view-default

Automation and Industrial I/O

BeagleBone gets used a lot in automation tasks, be they in industrial, building, home or otherwise. Software that helps enable individual hobbyists, but can bridge into professional automation tasks, is strongly desired.

  • MikroElectronika click board manifests for the Greybus simulator, instead of device tree overlays
  • learning tools like BlockyTalky3 and Makecode, but with a focus on making automation easy
  • open source PLC software

librobotcontrol support for BeagleBone AI and Robotics Cape

Goal: Complete implementation of librobotcontrol on BeagleBone AI.
Hardware Skills: Basic wiring
Software Skills: C, Linux
Possible Mentors: jkridner
Upstream Repository: https://github.com/jadonk/librobotcontrol/tree/bbai
References:http://www.strawsondesign.com/docs/librobotcontrol/index.html


Makecode Arcade for PocketBeagle GamePup

Makecode is a framework for creating special-purpose programming experiences for beginners, especially focused on computer science education. Makecode has a blockly based programming environment served on the browser along with an in-browser board simulator. MakeCode Arcade is a similar environment to MakeCode, but the environment has code blocks that are oriented towards building games. The goal of this project is to support the Makecode Arcade target for the Beaglebone boards and demonstration of example games on the Pocketbeagle Gamepup Cape.

Goal: Makecode target for Beaglebone boards with Breadboard simulator functionality making use of a UF2 daemon running in Beaglebone
Hardware Skills: Basic breadboard prototyping skills
Software Skills: Linux,Javascript,PXT
Possible Mentors: TBD
Upstream Repository: TBD
References: https://github.com/microsoft/pxt-arcade , https://github.com/microsoft/uf2-linux , https://beagleboard.org/capes

Low latency and soft peripherals using co-processors

The programmable real-time units are one of the coolest features of BeagleBone. Of course, the architecture of using a main processor running a high-level operating system and co-processors running without an operating system is a general architecture. Projects that help create tools and learning around this architecture can be rather successful around BeagleBone. See https://beagleboard.org/pru.

  • low-latency audio (bela.io)
  • LED lighting (Falcon Player, PocketScroller, etc.)

Another approach is to add support for Verilog (or VHDL) to synthesis PRU code for the soft peripherals. This can be based on the open source verilog toolchains.

PRU User Space API

Goal: Provide a simple API across multiple programming languages to use with the PRUs to load binaries, and communicate with the PRUs from userspace.


Hardware Skills: Minimal

Software Skills: Linux, C and Python programming

Possible Mentors: Kumar Abhishek, Zubeen Tolani
Upstream Repository: https://github.com/beagleboard/linux, https://github.com/beagleboard/pypruss
References: https://bitbucket.org/intelligentagent/pypruss, https://beagleboard.org/latest-images

Port am335x_pru_package to remoteproc

The am335x_pru_package is a community supported set of tools and examples on using the PRU. It includes an assembler and a C library for managing the PRU over UIO. The BeagleBoard community mostly desires to migrate PRU development to remoteproc to give the Linux kernel greater knowledge of the cores.

Goal: Move all examples to remoteproc, including adding elf support to pasm, adding an option to build using clpru and updating the C library to use the remoteproc interface for basic PRU control and using mmap() for a limited set of communications functions.
Hardware Skills: N/A
Software Skills: C, assembly, Linux kernel
Possible Mentors: Kumar Abhishek, Zubeen Tolani
Upstream Repository: https://github.com/beagleboard/am335x_pru_package
References: v5 examples TI Training Labs

Create a PRU based soft-peripheral example

The PRU is a hard realtime co-processor with dedicated realtime pins. Previous GSoC have created an assortment of examples and foundation pieces. However, most of them have custom interfaces. This project is to tie things together to implement at least one example of using the PRU with a standard interface. For example, this can be a SPI master interface that can be bound with another peripheral via DT.

Goal: Create at least one non trivial example that includes both the PRU firmware and the kernel driver interface. Utilization of remoteproc (other means of loading the firmware will be considered provided it is appropriately justified) to load the firmware and control the PRU. A device driver should expose the functionality using standard kernel APIs. The example should NOT be a trivial one (i.e. GPIO controller, simple input events, plain on-off LEDs) unless proper justification is provided. Simple non trivial possible examples include SPI master, I2C master (potential HW issues), or UART. This project includes creating the relevant PRU firmware.
Hardware Skills: Some understanding of I/O is needed esp if the I2C master is choosen.
Software Skills: C, assembly, Linux kernel
Possible Mentors: Kumar Abhishek, Zubeen Tolani
Upstream Repository: N/A
References: BeagleLogic & BeagleScope from previous years.

Reference Design For A GPIO-based Parallel Bi-Directional Bus

While the BeagleBone family has a large number of pins available on their P8/P9 headers, projects requiring a large amount of GPIO I/O may still be infeasible due to pinmux conflicts with other interfaces (SPI, UARTs, etc.). The newer PocketBeagle platform is even more restricted in the number of available GPIOs for interfacing. In addition, bi-directional bus communication using GPIOs is infeasible, as each GPIO is configured for either input or output. This project will combine your hardware and software skills to address these limitations by creating a shift register-based hardware design that will allow serial streams of data going in/out of the PocketBeagle or BeagleBone family GPIOs to be mapped into a bi-directional communications bus. Some practical uses of this are for GPIO-based game controller inputs (using *lots of buttons*), communication address/data buses for interfacing with older microcontrollers and microprocessors, and providing large numbers of logical bi-directional GPIOs.

Goal: Create a hardware/software design will incorporate shift registers (and potentially logic level converter solutions as appropriate) to allow BB.org hardware to communicate with hardware via a parallel, bi-directional bus. Create a software design that incorporates both a kernel driver to communicate with the parallel bus and a user space application/library using ioctl() calls to communicate with this kernel driver. Using the PRU to implement the low-level details of the bus (clock/latch signalling, reading/writing data) is encouraged! The kernel device tree fragment associated with the kernel driver shall configure it by specifying the number of parallel lines to use, the input/output/both direction of each bus signal, and the GPIOs allocated to the serial input/output/clock/latch signals.
Hardware Skills: Basic digital logic (i.e. comfortable prototyping IC-based circuits on a breadboard, understanding of buses and signals, able to read/write/understand schematics), use of logic analyzer/multimeter/oscilloscope as needed for troubleshooting, ability to read component data sheets.
Software Skills: C, kernel driver development, kernel device tree, PRU programming, interfacing with kernel drivers using ioctl() calls from user space.
Possible Mentors: Andrew Henderson, Zubeen Tolani
Upstream Repository: TBD
References: http://www.ti.com/lit/ds/sdfs071b/sdfs071b.pdf , https://www.arduino.cc/en/Tutorial/ShiftOut

PocketBeagle Stepwise Mathematics

Goal: The big picture goal is a stealth Step wise solution prompting Scientific Calculator based on the Pocket Beagle Residing in a Popular Brand Casing.The examinar should not be able to figure out any changes made to the approved exam Calc/Machine.The Calculator takes input from the User in terms of a completely formed mathematical problem and gives the step wise output on the display. Something similar to Sympolab or Wolfgram Alpha.

Hardware Skills: Medium. Ability to Interface/Integrate a Membrane/Capacitive Keyboard and a Matrix display.Ability to Get the Beagle running on a Lithium Ion thin Battery.

Software Skills: Python, C/C++, Linux, Knowledge of Compiler's

Possible Mentors:

Upstream Repository: N/A

Refrences: N/A

Security and Privacy

The BeagleBoard.org community cares a lot about understanding how information is managed. Projects that open up technology for more personal control and help secure data from external manipulation are generally well accepted. Consider how you can make contributions to existing projects in this area.

  • penetration testing (The Deck, Kali)
  • security appliance (Pangolin, ZeroTier Edge device)
  • self-hosted services (Freedombone)
  • car hacking (Macchina)

Example idea, a portable/plugable security appliance for use anywhere:

  • hardware: beaglebone with ethernet or beaglebone wireless, pocketbone + USB ethernet/wifi
  • OS: openwrt
  • configuration UI: bonescript/other
  • PRU accelerators...
  • privacy and safety tools...

Make port of Xen on BeagleBoard-x15

The project idea is to make Xen hypervisor available and easy to use on beagleboard-x15. To achieve this, it is planned to write Xen-supporting code and tutorials for Xen setup on the board. Another project goal is to improve user experience by working on optimizations for Beagleboard's kernel virtualization support code and/or on user-space tools.
Previously, the problem was discussed in xen mailing list and in beagleboard mailing list. The general solution wasn't provided and it seems that the problem still does exist.
The virtualization will make prototyping of virtualization-based security solutions easier in such areas like automotive computing and mobile privacy (BYOD problems).

Goal: to make virtualization available for end-users on Beagleboard-x15.
Hardware Skills: basic electronics.
Software Skills: C, C++, Linux kernel, Xen.
Possible Mentors: Andrew Henderson, Michael Welling.
Possible Co-mentors: Stefano Stabellini, Julien Grall, Iain Hunter.
Upstream Repository: N/A.
References: xen mailing list beagleboard mailing list

Beagle Bone Audio Network Streaming

Goal: Building on a Beagle GSoC project of 2017, the idea is to extend / add audio network streaming capabilities using the AVB and / or the SMPTE2110/30 (and SMPTE2022/7) standards.

Background / References: https://elinux.org/BeagleBoard/GSoC/BeagleBoneAVB

Software Skills: C/C++, Linux, Kernel

Possible Mentors: rma

Mentors

Name IRC nickname Native language Other languages Timezone Software help Hardware help Focus projects
Jason Kridner jkridner English - US Eastern JavaScript, C, u-boot wiring, timing diagrams, basic debug BoneScript development, deep learning, long-range wireless mesh networking
Hunyue Yau ds2 English Pacific C, PASM Any No specific focus/any
Kumar Abhishek Abhishek_ Hindi English IST C, PRU Assembly, bit of JS Almost everything PRU- or kernel- based projects, but could help with any project
Ravi Kumar Prasad ravikp7 Hindi English IST JavaScript, C Wiring, Basic debugging BeagleBoot
Michael Welling m_w English - US Pacific C, Linux kernel schematics, PCB, FPGA, Robotics kernel development
Patryk Mezydlo pmezydlo Polish English CET C, kernel development datasheets, schematic review, debug, kicad
Cathy Wicks cwicks English - US Central - - GSoC Admin, Organizational
Henderson, Andrew hendersa English - EST/EDT (UTC-5) C/C++, PRU, Linux userspace/kernel Prototyping, Eagle PCB PRU/Kernel projects, Linux userspace multimedia, Security
Drew Fustini pdp7 English - CET and US CDT C, Python, Linux schematics, PCB layout, KiCad Python libraries (Adafruit_BBIO & Blinka), Linux drivers
Zubeen Tolani zeekhuge Hindi English IST C, C++, Java, JS, PRU assembly Basic PRU, Kernel, Deep learning
Robert Manzke rma German English, Spanish CET C, C++ PCB, mixed mode design Audio, media network streaming protocols
Stefano Stabellini sstabellini Italian English PST Xen, C, kernel development - Xen on Beagleboard
Julien Grall julieng French English GMT/BST Xen, C, kernel development - Xen on Beagleboard
Iain Hunter driain English GMT/BST C, kernel,yocto Cape design
Steve Arnold nerdboy English Applied Math PST8PDT Python, toolchains, OS integration, architecture beaglebones, sensors Networking, security/privacy tools, Yocto/Gentoo
Name IRC nickname Native language Other languages Timezone Software help Hardware help Focus projects

Previous mentors