BeagleBoard/GSoC/2020 Projects/Cape Compatibility

= Proposal for Cape compatibility layer for BeagleBone Black and BeagleBone AI=

Student: Deepak Khatri Mentors: Jason Kridner Code: https://github.com/deepaklorkhatri007/linux/tree/4.14 Wiki: https://elinux.org/BeagleBoard/GSoC/2020Proposal/DeepakKhatri GSoC: https://summerofcode.withgoogle.com/projects/#5125259251941376

=Status= This project is currently just a proposal.

=Proposal= Completed all the requirements listed on the ideas page. the code for the cross-compilation task can be found here submitted through the pull request #130.

About you
IRC: lorforlinux Github: Deepak Khatri School: Netaji Subhas Univerity of Technology (NSUT) formely NSIT Country: India Primary language(s): Hindi,English Typical work hours: 9AM - 7PM IST Previous GSoC participation: I participated in GSoC2019 but i was not selected for the project. The project was to make a jekyll website for AIMA organization, Discussion on the project can be found here and the prototype i made can be found here. From the GSoC2019 I learnt the importance of communication.

About your project
Project name: Cape compatibility layer for BeagleBone Black and BeagleBone AI

Enabling overlay compatibility:
The BeagleBone boards use U-Boot as their Tertiary Program Loader (TPL). U-boot is responsible for loading the Linux kernel, Flattened Device Tree (FDT), Initial Ram File System (initramfs) into DRAM. U-Boot controls the boot time MUX_MODE for the GPIOs, symlinks for the peripherals and other hardware-specific device configurations by loading specific FDT. We can control the configuration(s) by updating the FDT for the hardware we want to support. We can enable the device compatibility in this case Cape compatibility using the boot-time device tree overlays. Overlays for most of the capes are available from the bb.org-overlays repo. A major task for achieving cape compatibility will be creating device tree overlays and loading at boot time. For loading the required driver for the hardware at boot time we have to edit uEnv.txt file. We can export the required overlays at boot time and the hardware will be compatible as soon as the board boots up. Most capes use an EEPROM for storing hardware related information about the CAPE and all of the individual pin configuration details can be imported out of the EEPROM, which makes things way better to handle.

Device tree overlays are a very important part of the main idea of this project which is to make the same user-space examples work with both BeagleBone Black and AI. the same references will be used in the drivers for peripherals assigned to the same pins between Black and AI. Main things to do for achieving that are assigning the same pin names and same aliases for both the boards.

For making the cape compatible, the device tree overlays code will be added to bb.org-overlays repo and changes will be made in the file am5729-beaglebone.dts and other related files to BeagleBoard-DeviceTrees repo for base pin naming and MUX_MODE selection upon which overlays will sit and will be able to use the properties assigned in am5729-beaglebone.dts device-tree source.


 * 1) For making the boards pin to pin compatible as in pin names, a new node will be created called cape-universal {...} which will hold child nodes like P8_03{...} for pin name assignment. Included the code for through pull request #13.
 * 2) Setting up the same default pin configuration in pin muxing nodes of board device tree files is required which will be achieved using nodes that use DRA7XX_CORE_IOPAD functions along with the pinctrl-single driver. I have included the required code through pull requests #8 #9 #10.
 * 3) I will also assign symlinks for the peripherals as discussed with rcn over pull requests #11 #12.I have already assigned some of the symlinks for currently active peripheral devices of BBB through the pull request #14. We might also require to assign the same aliases for peripherals in the device tree which is the easiest part after achieving the above goals. We need some assignments under aliases {...} nodes similar to what we have in the BeagleBone Black device tree file.

The file am335x-bone-common-univ.dtsi for BeagleBone Black and am335x-pocketbeagle.dts provides all the information for pin muxing and pin naming. The project will enable us to use serial ports and userspace I2C/spidev. In device trees, the aliases node can be seen as a quick lookup table, an index of another node. We can use find_node_by_aliases function to find a node by its alias. Interface buses like I2C, SPI, UART, CAN, etc will be aliases according to the BeagleBone cape interface spec. All the aliases defined in the device tree can be found in /sys/firmware/devicetree/base/aliases as files containing the full name/path for the peripheral device. For GPIOs, examples would work using pin names under libgpiod.

Pin MUX_MODE selection, pin naming and aliasing of P8 and P9 headers of BeagleBone AI will enable us to use different peripherals like GPIO, I2C, UART, SPI, qQEP, CAN, etc. BeagleBone cape interface spec shows further details on the active bus data of BeagleBone Black and BeagleBone AI. For the cape specific bus interface, the BeagleBone Cape Header Pins file gives us all the required information like which pins are used and also details on MUX_MODE are also provided there.

Enabling userspace and end-user compatibility
Looking at the symlink theory of operation with udev we see that for allowing userspace programs to use the devices with a custom name Symlinks allow us to define names/location of a peripheral. It’s very much like creating an alias for the peripheral but we can use this in userspace and it can be richer in information, for example, let’s look at this new symlink I created for the uart1 and submitted through pull request #14.

&uart1 { status = "okay"; pinctrl-names = "default"; pinctrl-0 = <>; symlink = "bone-uart1"; };

In this node, we assign the value of “bone-uart1” to the symlink property which we can call from userspace. Device tree creates an index of all the symlinks we define, In the device tree directory like for the SPI device for which we already have symlinks assigned in the current device tree.

When we look inside the /sys/firmware/devicetree/ of our BeagleBone we see all the folders created by the device tree. For SPI of BBB we see these folders.
 * ./sys/firmware/devicetree/base/ocp/spi@481a0000/channel@0/symlink
 * ./sys/firmware/devicetree/base/ocp/spi@481a0000/channel@1/symlink
 * ./sys/firmware/devicetree/base/ocp/spi@48030000/channel@0/symlink
 * ./sys/firmware/devicetree/base/ocp/spi@48030000/channel@1/symlink

These indexed folders can be searched and viewed through user space programs for example when we look in the 10-of-symlink.rules we see it uses these indexed folders for creating new devices under /dev. Looking at the code, first, we see ATTR{device/of_node/symlink} !=”” which checks if there are symlinks available. Then we create a variable for that symlink using ENV{OF_SYMLINK} and if it’s not empty and we have a device name we add it to the SYMLINK environment variable and we also add the systemd to TAG. In the end, we add an alias for the device using ENV{SYSTEMD_ALIAS}+="/dev/%E{OF_SYMLINK}".This way we can use the peripheral using the name assigned in the device tree through symlinks.

ATTR{device/of_node/symlink}!="", \ ENV{OF_SYMLINK}="%s{device/of_node/symlink}" ENV{OF_SYMLINK}!="", ENV{DEVNAME}!="", \ SYMLINK+="%E{OF_SYMLINK}", \ TAG+="systemd", ENV{SYSTEMD_ALIAS}+="/dev/%E{OF_SYMLINK}"

We have many peripherals available to use on AM5729 SoC but with different MUX_MODExx than AM3358. First let's see an example for /dev/bone/i2c/1 specs for which are :

AM3358 I2C1 AM5729 I2C5

P9.17 - SCL P9.18 - SDA

Let's see this code from my pull requests #8 #9 #10 in BeagleBoard-DeviceTrees repo. It is for the I2C peripiral on AM5729 based BeagleBone AI. The pin P9.17 has 2 GPIO pins of SoC attached to it and the code configures the pin to use the 2nd GPIO in MUX_MODE10 that enables the I2C on that pin. You see all that information and more insde the System Reference Manual for BeagleBone AI, info on P9.17 can be cound here.

P9_17_i2c_pin: pinmux_P9_17_i2c_pin { pinctrl-single,pins = < DRA7XX_CORE_IOPAD(0x36B8, PIN_OUTPUT_PULLUP | INPUT_EN | MUX_MODE10) >; };

Looking on the code for AM3358 for the same P9.17 pin on BeagleBone Black which can be found here. We see that it is using the MUX_MODE2 and only one GPIO pin of SoC is attached to this header pin.

P9_17_i2c_pin: pinmux_P9_17_i2c_pin { pinctrl-single,pins = < AM33XX_IOPAD(0x095c, PIN_OUTPUT_PULLUP | INPUT_EN | MUX_MODE2) >; };	/* spi0_cs0.i2c1_scl */

Software required and Programming Languages:
The project requires the use of the device tree compiler (dtc) for compiling the device tree source (ex. *.dts, *.dtsi) files. The c programming language will be used for kernel-level programming and the gcc compiler along with other build tools will be used for compiling the C source code (*.c).

Hardware required:

 * 1) BeagleBone Black.
 * 2) BeagleBone AI.
 * 3) BeagleBone capes:
 * 4) Load Cape.
 * 5) Motor Cape.
 * 6) Relay Cape.
 * 7) Robotics Cape.
 * 8) Servo Cape.
 * 9) Comms cape.
 * 10) 4.3"Display Cape.
 * 11) 7.0" Primary gen4 Display CAPE.
 * 12) Additional hardware for using capes:
 * 13) JST SH Jumper 4 Wire and 6 Wire.
 * 14) Grove Universal 4 Pin to Beaglebone® 6 Pin Female.
 * 15) Grove Universal 4 Pin to Beaglebone® Blue 4 Pin Female.
 * 16) Servo motor.
 * 17) DC Motor.
 * 18) Groove Modules:
 * 19) Grove - Servo.
 * 20) Grove - Vibration Motor.
 * 21) Grove - Line Finder v1.1.
 * 22) Grove - I2C Color Sensor V2.
 * 23) Grove - Rotary Angle Sensor.
 * 24) Grove - Adjustable PIR Motion Sensor.
 * 25) Grove - 6-Position DIP Switch.
 * 26) Grove - 16x2 LCD (White on Blue).
 * 27) Grove - Speaker.
 * 28) Grove - Buzzer.
 * 29) Grove - GPS Module.
 * 30) Grove - Digital Light Sensor - TSL2561.
 * 31) Grove - Temperature Humidity Sensor (High-Accuracy & Mini).
 * 32) FTDI Serial TTL-232 USB Cable.
 * 33) Barcode reader.
 * 34) Must have lab tools like:
 * 35) Solder, flux, and soldering iron.
 * 36) Screwdriver set.
 * 37) Tweezers and pliers.

Experience and approach
I have a good understanding of C, C++, and python. I have done an internship on Embedded Electronics using BeagleBoneBlack. I completed this project called "Mausam national" during my internship. Mausam national is an air quality cum multiple gases ppm level acquisition system. The interesting part of the project is that it can connect to the internet and fetch the air quality data from my university's pollution center that they provide for everyone to use. we used that data for the calibration of the MQ sensors on-board.

I was one of the quarter-finalists in IICDC2017 and during that period I worked with ARM cortex M4 based MSP432. I participated in Electronics Maker contest '17 there I presented a low-cost biopotential amplifier based on TL074 and won Ti's C2000 DSP for the project. I have worked on both hardware and software-based projects, hardware projects can be found on my youtube channel here and software projects can be found on my GitHub here.

Contingency
I believe that if I get stuck on my project and my mentor isn’t around, I will use the resources that are available to me. Some of those information portals are listed below.


 * 1) Derek Molly's beagle bone guide provides all the information needed for getting up and running with my beagle.
 * 2) Content on e-ALE.org is very useful for information that ranges from tutorials and walkthroughs to the level of very advanced stuff.
 * 3) BeagleBone cookbook from Mark A. Yoder & Jason Kridner is the best source for test projects during the prototyping period.
 * 4) The technical reference manuals provided by TI on am3358 and am5729 are the best source for getting the insights on the SoC used in Black and Ai.

Benefit
I believe that the project is very important for the adoption of the BeagleBone AI. It will bring support for BeagleBone Black capes on BeagleBone AI and also for the execution of same user space examples written for BeagleBone black. - Deepak Khatri aka lorforlinux

Quotes from BeagleBone community member(s): Me, personally, I would find this very interesting. I love add-ons, Capes, sensors, and actuators. Making an Upward Working Cape would be successful for many people looking to use the AI. Now, easy? I do not know. It is like upward mobility in life. Instead of making things updated, one makes the old work w/ the new. That is a success. - Set_ on #beagle