BeagleBoard/GSoC/2022 Proposal/BeagleBone Cape add-on board compatibility layer

Jump to: navigation, search


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.

About you

Github: gpioblink
School: University of Aizu
Country: Japan
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".

Previous Work

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.

There are symbolic links that do not appear by default in the AI.

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)
  • SPI
  • PWM
  • CAN
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.

The first step is to create a device tree overlay based on Device Tree for Robotics Cape on BeagleBone Black, following the Device Tree Overlay Creation Article".

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 [1], or otherwise prepare documentation for developers and end users.

This will be done for all Capes listed at [2].

Prerequisite Knowledge

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
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 #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:

  1. 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.
  2. If possible, use an oscilloscope to check for correct waveforms, or use a debugger on Linux to determine the details of the problem.
  3. If the problem is likely to be component-dependent, consult the datasheet for the chip in question.
  4. Check the embedded Linux primer, Mastering Embedded Linux Programming Third Edition. Also, check BeagleBone Black Cookbook for similar symptoms on BeagleBone.
  5. 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 community? Include quotes from community members who can be found on and

  • 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?