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

ProposalTemplate

Student: Kai Yamada
Mentors: Not yet
Proposal: https://elinux.org/BeagleBoard/GSoC/2022_Proposal/

Status

This project is currently just a proposal.

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

Description

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

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

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.

Timeline

April 19 - 18:00 UTC	Proposal complete, Submitted to https://summerofcode.withgoogle.com
April 20 - May 19	Prework Request Hardware (BeagleBoard AI and the Capes listed in [3]) Discussion with potential mentors about my approaches Try running an existing device tree overlay (I already have a BBB.) Find out what happens with the I2C, SPI, and UART sensors I have Become familiar with device tree Try to switch GPIOs in the device tree to LEDs. Using my own FPGA with an ARM core from Xilinx, find out how changing peripherals affects the device tree.
May 20 - June 12	Community Bonding Period Setup Hardware (OS installation and Cape operation check) Play with the Capes and learn how to use them Create test code that can test a set of functions without a device tree overlay.
June 13	Pre-work complete, Coding officially begins!
June 13	Milestone #1 Make an introductory YouTube video Add one or more symlink gpio-leds to the existing AI device tree overlay For RoboticsCape, create a prototype device tree overlay based on BeagleBoneBlack.
June 20	Milestone #2 Add symlink gpio-leds and gpio-keys for all existing cape pins For RoboticsCape, write a device tree overlay to allow AI to light the power LEDs
June 27	Milestone #3 Check the operation of the LED part and record the test method. Submit the first pull request for the LED part and get it reviewed.
July 4	Milestone #4 Add symlink PWM,SPI for all existing cape pins
July 11	Milestone #5 Check the operation of the PWM, SPI part and record the test method. Submit first pull request for PWM and SPI portions for review Modification of the LED portion of the code and merging of pull requests
July 18	Milestone #6 Add symlink CAN for all existing cape pins check the operation of the CAN portion and record the test methods Code modification for PWM and SPI portions, merge pull requests
July 25	Milestone #7, Mentors and GSoC contributors can begin submitting Phase 1 evaluations Submit first pull request for CAM portion and get review Prepare a report on the work done so far Meet with the mentor for a detailed discussion on progress to this point and how to proceed.
July 29 - 18:00 UTC	Phase 1 Evaluation deadline
Aug 1	Milestone #8 Code modification for CAN portion, merge pull requests Advance support for various RoboticsCape components and peripherals
Aug 8	Milestone #9 Testing and debugging on actual equipment in RoboticsCape Submit first pull request with device tree overlay for RoboticsCape and get review
Aug 15	Milestone #10 Talking to mentor and working on RoboticsCape overlay
Aug 22	Milestone #11 Device tree overlay for RoboticsCape, merge pull requests Create end-user tutorial documentation for each Cape device based on the work done so far For each Cape, sample code and execution instructions are written in such a way that you can understand them without having to consult the source code.
Aug 29	Milestone #12 Received feedback from mentors on tutorial documentation and revised it Fixing other bugs, typos, etc. found during documentation
Sept 5	Final week: Students submit their final work product and their final mentor evaluation Completion YouTube video
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.

Contingency

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.

Benefit

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

Misc

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.

Suggestions

Is there anything else we should have asked you?