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
- 220.127.116.11 Previous Work
- 18.104.22.168 Problems and Solutions
- 22.214.171.124 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 .
Device Tree and Device Tree Overlay
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.
Also, many pins in a SoC may have multiple uses in a single pin. Here, duplicate pins must be disabled or the pin's use must be specified, and the device tree is also responsible for deciding which use to make of the pin. For example, a GPIO pin can be used as a basic general-purpose input/output or as an LED that can be used as a heartbeat for storage access, etc.
The device tree must be specified at Linux boot time, and it is basically impossible to change the configuration during boot.
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.
This makes it easy to reconfigure everything from peripherals such as GPIO, SPI, and I2C to various components, including Cape.
Moreover, BeagleBoard additionally has a mechanism called Universal Cape Overlay. This allows pin assignments to be managed with a simple command line call. A GUI tool is also available.
PRU is the "Programmable Real-Time Units And Industrial Controller Subsystem", also known by names such as PRU-ICSS, which is also implemented in the AM335x and AM57x used in the BeagleBone.
The PRU is independent of the ARM core running Linux and can control hardware regardless of what the OS does. PRUs are controlled by writing assembly, but a kernel module for Linux is also provided, from which the PRUs can be controlled.
PRUs can be used from the Linux User Space using the PRU Linux Loader, which also requires editing the device tree when accessing peripherals and devices controlled via PRUs from Linux.
Absorption of differences between kernel versions
Currently, the device tree overlay is built for kernel v4.19, which needs to be ported to the latest kernel.
Basically, existing codes can be used without modification in the new kernel version, but sometime we need to modify them.
For example, memory addresses in the device tree may have changed due to new updates. Since there is a possibility of address conflicts with the code as it is, it is necessary to compile and verify the code with the new kernel version.
The work in this proposal will basically be developed and ported using v5.10, which is the latest stable kernel at this time. If any missing device trees are needed, they will be copied from the older kernel like v4.19 after verification.
|April 19 - 18:00 UTC||Proposal complete, Submitted to https://summerofcode.withgoogle.com|
|April 20 - May 19||Prework|
|May 20 - June 12||Community Bonding Period|
|June 13||Pre-work complete, Coding officially begins!|
|June 13||Milestone #1|
|June 20||Milestone #2|
|June 27||Milestone #3|
|July 4||Milestone #4|
|July 11||Milestone #5|
|July 18||Milestone #6|
|July 25||Milestone #7, Mentors and GSoC contributors can begin submitting Phase 1 evaluations|
|July 29 - 18:00 UTC||Phase 1 Evaluation deadline|
|Aug 1||Milestone #8|
|Aug 8||Milestone #9|
|Aug 15||Milestone #10|
|Aug 22||Milestone #11|
|Aug 29||Milestone #12|
|Sept 5||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|
Note: I consider the work to be my job until I have created the documentation so that many people can use it.
Therefore, I should take photos and videos of the results frequently and keep a log of the results to ensure reproducibility and stability.
Note: Japan is not in summer vacation period until mid-August. However, 30 hours per week will be allocated for this program, using the days of the week when there are no classes or research, as well as weekends.
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.
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.
- A Compatibility Layer for BeagleBone AI will be added, allowing Robotics Cape to be handled by AI. Also, librobotcontrol code written for BeagleBone Black will work on BeagleBone AI.
- Various tutorials will be added to the Capes to help the user understand how to use it.
Please complete the requirements listed on the ideas page. Provide link to pull request.
- All prerequisite tasks have been completed.
- Pull request is here: #167.
Is there anything else we should have asked you?