BeagleBoard/GSoC/2022 Proposal/Building Bela Images
- 1 Proposal-Building Bela Images
- 2 Status
- 3 Proposal
- 3.1 About you
- 3.2 About your project
- 3.2.1 Description
- 3.2.2 Proposed method of Implementation
- 3.2.3 Timeline
- 3.2.4 Experience and approach
- 3.2.5 Contingency
- 3.2.6 Benefit
- 3.3 Misc
===== About =====
Student: Kurva Prashanth
Mentors: Giulio Moro, Vedant Paranjape, Vaishnav Achath
Code: https://github.com/BelaPlatform/bela-image-builder https://github.com/beagleboard/image-builder
GSoC: GSoC entry
This project proposal has been accepted as part of GSoC 2022.
IRC Nick: krvprashanth
School: Vidya Jyothi Institute of Technology
Primary language: English, Telugu
Typical work hours: 6AM-11AM, 4PM-10PM (GMT +5:30) IST
Previous GSoC participation: First time I am participating in GSoC.
About your project
Project name: Building Bela Images
- Semantic rebase of the functionalities in Bela-Image-builder repo to the Image-builder one.
- Debian package Bela required dependencies
- Add features of the Bela-Image-builder repo to Image-builder repo.
- Improve the maintainability of the Bela Image Development and minimise future development effort.
Bela is an open hardware and software platform for ultra-low latency audio and sensor processing. The main goal of this project is to Improve the maintainability of the Bela Image development by adding the functionalities of the Bela Image builder repo to the BeagleBoard Image builder repo.
Overview of Bela Platform
As given in the official website, Bela is a hardware and software platform for creating beautiful interaction with sensors, sound and it is designed for artists, musicians, researchers and makers, Bela brings the power of ultra-low latency interactive audio and sensors to digital systems.
Bela Platform uses the Bela software which is a customised Debian distribution including a custom xenomai kernel, minimal clutter, and custom systemd configurations and It takes advantage of features of the BeagleBone computers and can achieve extremely fast audio and sensor processing times.
Basic Overview of Building Embedded Linux Distributions
Building custom Linux systems for embedded devices is to use build systems such as Yocto/Open Embeded or Buildroot and using a more conventional binary distribution Debian rootfs has interesting benefits such as powerful package management system, a wide selection of available packages, excellent security updates and more.
There are different approaches to build an embedded Linux system. Here, in this project we will be using U-Boot, ARM cross compiler, Debian ARM based rootfs, custom kernal, Debootstrap and build scripts to generate systems for ARM targets such as Bela, BeagleBoards.
Why Building Bela Image again?
Bela Image development repo is heavily based and which was initially inspired by Beagleboard Image-builder scripts. Currently, the Beagle board Image development repo diverged greatly from a common functionalities of building Images.
Now, there is a requirement to "rebase" the functionalities of the Bela Image builder repo to the Beagleboard Image builder one. As the two codebases are drastically different we need to understand and “semantic rebase” the features of the Bela Image builder repo (xenomai kernel building scripts along with a bunch of other stuff) to Beagleboard Image builder repo. After these changes the Bela Image development will follow more closely with the Beagleboard Image development and as a result Bela Image will be updated more often and it minimizes future development effort.
Bash Scripting, Build Systems ( U-Boot ), Kernel building, Debian packaging, Linux Management( Primarily using linux distribution )
Proposed method of Implementation
In order to add the Bela Image builder features to BeagleBoard Image builder. Firstly, I try building Bela Image by using BeagleBoard Image builder scripts and making necessary changes in scripts to build Image. After this I'll be getting a clear idea to where to change and semantic rebase the features of Bela Image builder to BeagleBoard Image builder one.
Here are typical changes need to do in BeagleBoard Image builder repo
- Bela-specific changes will be made conditional in RootStock-NG.sh script in BeagleBoard Image builder repo
- Add Bela Image builder scripts features in RootStock-NG.sh script
- bootloader, kernel, xenomai, downloads, emmc-flasher-chroot and pre-chroot
- Add Bela Image builder scripts features in RootStock-NG.sh script
- Use config template and create bela-image.conf file and also add bela required packages list to it
- Make necessary changes in build scripts to Optimise boot times as Bela Image has fast boot time campared to BeagleBoard Image
- After building Bela Image using Beagleboard Image builder functionalities make changes to the Image-builder repo
- Workflow for building Bela Image with BeagleBoard Image builder scripts
Generate: Base Debian Bullseye Image:
git clone https://github.com/RobertCNelson/omap-image-builder cd ./omap-image-builder ./RootStock-NG.sh -c bb.org-debian-stretch-lxqt-v4.14
Archive will be added to "./deploy/"
Finalize: Bela specific version:
sudo ./setup_sdcard.sh --img-4gb bela-example --dtb bela --bootloader --enable-eemc-flasher --enable-uboot
- Hardware required
The hardware listed below will be necessary for testing after rebuilding Bela Image.
I plan to complete all the tasks before the GSoC 2022 coding period ends. Apart from this, I will write blogs weekly, reporting my progress and also the experiences I had while contributing this project.
During the GSoC 2022 coding period, I will do the following things:
- Discuss ideas with the mentors, take feedback and work on
- On an average i will be able to dedicate 30 to 35 hours per week
- I am ready to adapt whatever my mentor suggests me and I will try my best to complete proposed work
- Find other features to be added to the Bela Image
The GSoC official coding period begins on June 13, 2022, and ends on November 21, 2022.
NOTE : In view of my semester exams in June for a maximum period of two weeks, most of the work is scheduled in the second half of the coding period. I can’t work during the exam period. I would make sure to compensate for this by putting extra hours in the remaining period.
|April 04 - 18:00 UTC||Applications open, Students register with GSoC, work on proposal with mentors|
|April 19 - 18:00 UTC||Proposal complete, Submitted to https://summerofcode.withgoogle.com|
|May 20||Proposal accepted or rejected||
|Jun 13||Pre-work complete||
Coding officially begins!
|Jun 19||Milestone #1||
|Jun 26||Milestone #2||
|June 03||Final Exam||No Code|
|July 10||Final Exam||No Code|
|July 17||Milestone #3||
|July 24||Milestone #4||
|July 29 - 18:00 UTC||Phase 1 Evaluation deadline||
|July 31||Milestone #5||
|Aug 07||Milestone #6||
2 package/week (taking a comfortable room, if some package needs more work).
|Aug 14||Milestone #7||
|Aug 21||Milestone #8||
|Aug 28||Milestone #9||
|Sep 04||Milestone #10||
|September 04 - 11, 18:00 UTC||Final week: GSoC contributors submit their final work product and their final mentor evaluation||
|September 12 - 19, 18:00 UTC||Mentors submit final GSoC contributor evaluations|
|Nov 21 - 18:00 UTC||Final date for all GSoC contributors to submit their final work product|
Experience and approach
To work on this project, It requires experience with bash scripting, build systems and linux management. I have an experience with Debian live build system and customized my low end machine with robotics and networking packages in which it has 2GB RAM and 30GB hard disk installed Debian 11 "Bullseye" with XFCE Desktop environment on it and I'm just curious to work on low end hardware, optimise software to make run very well on resource constrained devices.
I am mostly into Systems Programming, Embedded Linux, and Robotics. I use programming languages such as Assembly (x86, RISC-V), C, Python and shell scripting for Installing different packages and applications which I use. I prefer to work in a terminal over GUI and also mostly I use robotics, networking, embedded linux development tools like cross-compiler toolchains, emulators, Assemblers, Debugger, mininet, ns3, ROS, OpenCV, Wireshark, etc.
I also write good reports and blogs, I’ve previously written some blogs about free software and open hardware and experiences I had. Check here
Here are technical and non-technical ways where I contributed.
- Hacktivist: Actively contributing to free software projects, gave talks on Free Software & Open Hardware, Git, Mobile & Desktop Freedom, Dark Patterns
- Speaker, International Debian Conference 2021
- Designed, optimized, and sliced 3D models and maintained production line of 3D printed projects and open hardware prototyping equipment.
- In Mobile Autonomous Cart project using ROS + Docker, development tools to advance robotic software design and deployment by utilizing advances in Linux containers.
- Organised Debian Bullseye Release event
- Course Manager and Teaching Assistant for Liberating Devices course ( Mobile & Desktop Freedom )
- Utilized Android Tools ( adb, fastboot ), Bash scripts and command-line tools to remove proprietary malware from mobiles/watches and desktops.
- Porting and Enabling the Government School Computer labs in our locality to specific use of free softwares and Installing BalaSwecha OS( A GNU/Linux distribution based on Debian ).
If I get stuck on my project and my mentor isn’t around, I will use the following resources:
- BelaPlatform and BeagleBoard Repositories:
- Documentation and Repositories on Building Images:
- Beagleboard: BeagleBoneBlack Rebuilding Software Image
- Mailing lists:
Upon successful completion of this project the Bela Image will follow more closely with BeagleBoard Images. I mean after Bela specific changes made conditional to the Image-builder repository. The Bela Image development will be updated more often, more easily in parallel with BeagleBoard Images.
Emulation is a necessary aspect of embedded system development and QEMU is the right tool to do so for linux based SBCs. As I tried some ways to boot Bela Image using QEMU emulator and that didn't worked out. After completion of this project I'll work on building qemu-bela-kernel. So, that the ready-made kernel can be used to emulate a Bela.