BeagleBoard/GSoC/2022 Proposal/BeagleBone Cape add-on board compatibility layer
- 1 ProposalTemplate
- 2 Status
- 3 Proposal
- 3.1 About you
- 3.2 About your project
- 3.2.1 Description
- 18.104.22.168 Previous Work
- 22.214.171.124 Problems and Solutions
- 126.96.36.199 Prerequisite Knowledge
- 3.2.2 Timeline
- 3.2.3 Experience and approach
- 3.2.4 Contingency
- 3.2.5 Benefit
- 3.2.1 Description
- 3.3 Misc
Student: Kai Yamada
Mentors: Not yet
This project is currently just a proposal.
Please complete the requirements listed on the ideas page and fill out this template.
School: University of Aizu
Primary language (We have mentors who speak multiple languages): Japanese
Typical work hours (We have mentors in various time zones): 10AM-7PM Japan Standard Time
Previous GSoC participation: This is my first time attending GSoC.
Reason for participation: I have a strong interest in the Linux kernel's low-layer mechanism for abstracting devices on hardware and providing them to applications. Therefore, I would like to be involved in Linux BSP development in the future. I have been playing around with rewriting the GPL source code for embedded Linux in an attempt to learn a bit about BSP development. However, my knowledge of BSP development was lacking and I was limited to small modifications. I would like to hone my BSP development skills by participating in GSoC and taking the time to participate in its development. I would also like to be involved with the community through GSoC as a starting point for ongoing contribution activities.
About your project
Project name: BeagleBone Cape add-on board compatibility layer
BeagleBone has sold a module called Cape, which connects to the BeagleBoard. This Cape was designed for past BeagleBoard and could not be handled directly by BeagleBoneAI, which has a different SoC. Deepak Khatri, a 2020 GSoC contributor, had created a Cape compatibility layer for the BeagleBoneAI that can use the script for other BeagleBoard like BeaglBboneBlack. However, some implementations are incomplete and some Capes do not yet have a compatibility layer.
In this proposal, I propose to implement "imcomplete symlink impletentation" and "device tree overlays for robotics cape".
Until now, thanks to the work of Deepak Khatri, a mechanism has been put in place to allow the P8 and P9 connectors to work from AI (am572x) with the same pin assignments as Black (am335x).
What is being done here is the following three things:
- Set up a symlink in AI's device tree that corresponds to other BeagleBones such as Black.
- Use this symlink attribute in udev rules to create the actual symbolic link
- Configure pinmux to change the behavior of peripherals depending on the application.
Here, a universal device tree overlay is used to select the actual peripheral to be used from the multiple choices in pinmux. By changing the device tree overlay used, the user can select the peripheral needed for each Cape.
Problems and Solutions
However, the current implementation has the following problems This proposal will address these issues.
As you can see in bbai-bone-buses.dtsi, here are symbolic links that do not yet appear in the device tree. For example, SPI, PWM, and CAN peripherals have no symlink. If you use this device tree as it is, these peripherals are not available in the standard state.
The work is to create a corresponding udev rule, for example, and put it on the symlink so that it can be handled by BeagleBone AI's file system.
The symlink we want to create is as follows:
- GPIO (for gpio-leds and gpio-keys)
Need device tree overlay for Robotics Cape.
Currently, Compatible Overlays are available for the various types of Capes offered by BeagleBone. However, no overlays are yet available for the Robotics Cape. These will need to be created.
No demo code explaining how to use each Cape.
Currently we do not yet have demo code for each Cape to see how it works with the device tree overlay for each Cape. I need to add demo code for each Cape to , or otherwise prepare documentation for developers and end users.
This will be done for all Capes listed at .
What is Device Tree
A device tree is data that tells the kernel about the configuration of hardware in ARM and other embedded Linuxes. For each component in the hardware, you can set its name, memory address, label, and interrupt, etc.
The device tree must be specified at Linux boot time, and it is basically impossible to change the configuration during boot.
TODO: write more detail with my experience
What is Device Tree Overlay
Device tree overlay is a device tree mechanism that allows configuration changes in user space during boot. This allows you to change the pin assignments used without having to reboot Linux.
TODO: write more detail
What is Device Tree Overlay with Cape Universal
Cape additionally has a mechanism called Universal Cape Overlay. This allows pin assignments to be managed with a simple command line call.
TODO: write more detail
Provide a development timeline with a milestone each of the 11 weeks and any pre-work. (A realistic timeline is critical to our selection process.)
TODO: write the table when I decide on specifics
|April 19 - 18:00 UTC||Proposal complete, Submitted to https://summerofcode.withgoogle.com|
|April 20 - May 19||Indivisual Working|
|May 20 - June 12||Community Bonding Period|
|June 13||Pre-work complete, Coding officially begins!|
|June 13 - June 24||Milestone #1, Introductory YouTube video|
|June 27 - July 08||Milestone #2|
|July 11 - July 22||Milestone #3|
|July 25 - July 29||Milestone #4, Mentors and GSoC contributors can begin submitting Phase 1 evaluations|
|July 29 - 18:00 UTC||Phase 1 Evaluation deadline|
|Aug 01 - Aug 12||Milestone #5|
|Aug 15 - Aug 26||Milestone #6|
|Aug 29 - Sept 9||Milestone #7|
|Date||Milestone #8, Completion YouTube video|
|Sept 5 - Sept 09||Milestone #8, Completion YouTube video|
Final week: Students submit their final work product and their final mentor evaluation
|Sept 12 - Sept 19 - 18:00 UTC||Mentors submit final student evaluations|
Experience and approach
In 5-15 sentences, convince us you will be able to successfully complete your project in the timeline you have described.
Experience: To achieve my goal of porting BSP for embedded Linux, I modified the GPL source code to change the behavior during init and I have been using eBPF to check USB sending and receiving. I have also participated in a board design internship and developed hardware. These tasks have been basically done by myself, with some help from the community. I intend to run the project on my own this time as well as in the past.
Approach: From our experience, hardware requires considerably more time for debugging than software. Since there is little information available as a tutorial, I have also set aside a generous amount of time to read the relevant data sheets and specifications to understand how it works. I believe that this content can be completed without any problems.
What will you do if you get stuck on your project and your mentor isn’t around?
Unexplained problems are common in doing hardware. In such cases, I will do the following:
- If the problem is with the Compatible Layer, first try with the BeagleBone Black or try with the regular device tree to roughly isolate where the problem occurs.
- If possible, use an oscilloscope to check for correct waveforms, or use a debugger on Linux to determine the details of the problem.
- If the problem is likely to be component-dependent, consult the datasheet for the chip in question.
- Check the embedded Linux primer, Mastering Embedded Linux Programming Third Edition. Also, check BeagleBone Black Cookbook for similar symptoms on BeagleBone.
- If the problem is likely to be Soc-dependent, refer to the datasheets for AM5729 on BeagleBone AI and AM3358 on BeagleBone Black and many other boards.
If successfully completed, what will its impact be on the BeagleBoard.org community? Include quotes from BeagleBoard.org community members who can be found on http://beagleboard.org/discuss and http://bbb.io/gsocchat.
- A Compatibility Layer for BeagleBoe AI will be added to librobotcontrol, allowing Robotics Cape to be handled by AI. Also, librobotcontrol code written for BeagleBone Black will work on BeagleBone AI without modification.
- Various tutorials will be added to librobotcontrol to help you understand how to use it.
Please complete the requirements listed on the ideas page. Provide link to pull request.
Is there anything else we should have asked you?