Difference between revisions of "BeagleBoard/GSoC/2022 Proposal/BeagleBone Cape add-on board compatibility layer"

From eLinux.org
Jump to: navigation, search
Line 65: Line 65:
  
 
* GPIO (for gpio-leds and gpio-keys)
 
* GPIO (for gpio-leds and gpio-keys)
 +
* PWM
 
* SPI
 
* SPI
* PWM
 
 
* CAN
 
* CAN
  
Line 85: Line 85:
 
====Prerequisite Knowledge====
 
====Prerequisite Knowledge====
  
=====What is Device Tree=====
+
=====Device Tree and Device Tree Overlay=====
  
A device tree is data that tells the kernel about the configuration of hardware in ARM and other embedded Linuxes.
+
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.
 
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.
 
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.
 
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 allows you to change the pin assignments used without having to reboot Linux.
  
TODO: write more detail
+
This makes it easy to reconfigure everything from peripherals such as GPIO, SPI, and I2C to various components, including Cape.
  
=====What is Device Tree Overlay with Cape Universal=====
+
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.
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
 
  
 
===Timeline===
 
===Timeline===
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
 
  
 
{| class="wikitable"
 
{| class="wikitable"
 
| April 19 - 18:00 UTC || Proposal complete, Submitted to https://summerofcode.withgoogle.com
 
| April 19 - 18:00 UTC || Proposal complete, Submitted to https://summerofcode.withgoogle.com
 
|-
 
|-
| April 20 - May 19 || Indivisual Working
+
| April 20 - May 19 || Prework<br>
 +
* Request Hardware (BeagleBoard AI and the Capes listed in [https://github.com/beagleboard/capes])
 +
** 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
+
| May 20 - June 12  || Community Bonding Period<br>
 +
* 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 || Pre-work complete, Coding officially begins!
 
|-
 
|-
| June 13 - June 24 || Milestone #1, Introductory YouTube video
+
| June 13 || Milestone #1<br>
 +
* 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 27 - July 08 || Milestone #2
+
| June 20 || Milestone #2<br>
 +
* 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
 
|-
 
|-
| July 11 - July 22 || Milestone #3
+
| June 27 || Milestone #3<br>
 +
* 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 25 - July 29 || Milestone #4, Mentors and GSoC contributors can begin submitting Phase 1 evaluations
+
| July 4 || Milestone #4<br>
 +
* Add symlink PWM,SPI for all existing cape pins
 +
|-
 +
| July 11 || Milestone #5<br>
 +
* 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<br>
 +
* 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<br>
 +
* 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
 
| July 29 - 18:00 UTC || Phase 1 Evaluation deadline
 
|-
 
|-
| Aug 01 - Aug 12 || Milestone #5
+
| Aug 1 || Milestone #8<br>
 +
* Code modification for CAN portion, merge pull requests
 +
* Advance support for various RoboticsCape components and peripherals
 
|-
 
|-
| Aug 15 - Aug 26 || Milestone #6
+
| Aug 8 || Milestone #9<br>
 +
* Testing and debugging on actual equipment in RoboticsCape
 +
* Submit first pull request with device tree overlay for RoboticsCape and get review
 
|-
 
|-
| Aug 29 - Sept 9 || Milestone #7
+
| Aug 15 || Milestone #10<br>
 +
* Talking to mentor and working on RoboticsCape overlay
 
|-
 
|-
| Date || Milestone #7
+
| Aug 22 || Milestone #11<br>
 +
* 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.
 
|-
 
|-
| Date || Milestone #8, Completion YouTube video
+
| Aug 29 || Milestone #12<br>
 +
* Received feedback from mentors on tutorial documentation and revised it
 +
* Fixing other bugs, typos, etc. found during documentation
 
|-
 
|-
| Sept 5 - Sept 09 || Milestone #8, Completion YouTube video<br>Final week: Students submit their final work product and their final mentor evaluation
+
| Sept 5 || Final week: Students submit their final work product and their final mentor evaluation<br>
 +
* Completion YouTube video
 
|-
 
|-
 
| Sept 12 - Sept 19 - 18:00 UTC || Mentors submit final student evaluations
 
| 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.<br>
 +
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===
 
===Experience and approach===
Line 157: Line 200:
  
 
===Contingency===
 
===Contingency===
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:
 
Unexplained problems are common in doing hardware. In such cases, I will do the following:
  
Line 168: Line 209:
  
 
===Benefit===
 
===Benefit===
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.
+
* 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 librobotcontrol to help you understand how to use it.
+
* Various tutorials will be added to the Capes to help the user understand how to use it.
  
 
==Misc==
 
==Misc==

Revision as of 20:35, 18 April 2022


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.

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.

Suggestions

Is there anything else we should have asked you?