< BeagleBoard‎ | GSoC
Revision as of 05:13, 21 March 2017 by Jkridner (talk | contribs)
Jump to: navigation, search



A short summary of the idea will go here.

Student: Ravi Kumar Prasad
Mentors: Jason Kridner
GSoC: [NA GSoC entry]


This project is currently just a proposal.


About you

IRC: ravikp7
School: Maharaja Agrasen Institute of Technology
Country: India
Primary language: English, Hindi
Typical work hours: (9AM-3PM and 7PM-12AM) IST or (11:30PM-5:30AM and 9:30AM-2:30PM) EST

About your project

Project name: BeagleBoot- BeagleBone USB based bootloader server in JavaScript (node.js)


The project is to port the BeagleBone bootloader server BBBlfs(currently written in c) to JavaScript(node.js) and make a cross platform GUI flashing tool utilising the project code. This will allow us to have single code base for a cross platform tool.
Some changes are to be made in the port regarding the method of exposing the storage of block device over USB
The c server (BBBlfs) after transferring u-boot through tftp, currently utilizes the Kernel/RAMDISK approach to boot the beaglebone in USB mass storage class mode.

Since u-boot has now the ums(USB Mass Storage) feature, it'll be utilized instead of Kernel/RAMDISK approach to boot it into USB mass storage class. To do this a PATCH for uboot is to be made which will run the ums command after loading u-boot.

Working of the new node.js server:
1. The AM335x ROM in usb boot mode exposes RNDIS interface which can be a virtual ethernet link over USB.
2. The client(BB) broadcasts BOOTP request message containing its hardware address.
3. The server receives the BOOTP request through an inendpoint bulk transfer over USB.
4. The server then sends BOOTP packet with IP addresses of client, server, UDP port numbers, SPL filename and hardware address of server through an outendpoint bulk transfer over USB.
5. The server then receives an ARP request through an inendpoint bulk transfer over USB.
6. The server makes an ARP response by acknowledging the IP and hardware addresses of client and server.
7. The server receives a TFTP request for the spl binary.
8. The SPL binary is transferred through tftp in blocks.
9. SPL runs on the ROM and now the rndis vip and pid changes to new spl ids as per PATCH in the uboot.
10. The server now finds device as per new ids and applies same procedure to transfer the u-boot binary.
11. U-boot runs on the client and ums command is run to get it into usb mass storage class mode.

Plans for integration into variant
The UI of will be modified to make it a BeagleBone Flasher.
A button will be added, whose click action would be to put BB into USB mass storage mode by running the above server.
Next flashing image selection option will only be enabled only after putting BB into USB mass storage mode.

Changes required in u-boot PATCH used in BBBlfs:
1. Changes in /drivers/usb/gadget/ether.c PATCH to specify just SPL vid & pid as U-boot ids won't be required as kernel/Ramdisk is not used.
2. Changes in /include/configs/am335x_evm.h PATCH , now no need of specifying serverip, ipaddr, tftp commands. Only ums command will be used to boot the bb into usb mass storage class mode.
3. No changes in /include/configs/ti_armv7_common.h


Provide a development timeline with a milestone each of the 11 weeks. (A realistic timeline is critical to our selection process.)

2017-06-06: Milestone #1 Testing binary parser modules for JavaScript, making strategy to use node modules or do the parsing manually. Write code for RNDIS header and verify hardware address of BB from BOOTP request data packet received by server.
2017-06-13: Milestone #2 Writing code for packet headers to implement all network protocols used BOOTP, UDP, TFTP, IP, ARP, ETHER and do their basic testing.
2017-06-20: Milestone #3 Writing code for BOOTP reply from server. Receive ARP request from client(BB) and ARP response from server.
2017-06-27: Milestone #4 Writing PATCH for u-boot for configuration. Transferring SPL binary to BB.
2017-07-04: Milestone #5 Transferring u-boot binary and booting BB hardware into mass storage class mode. Testing the server for different BB hardwares Black, Blue etc. Testing flashing different images on different platforms through tool.
2017-07-11: Milestone #6 Creating UI for the all in one BeagleBone flasher. Testing npm packages used in
2017-07-18: Milestone #7 Integrating the UI with flasher backend and the node-beaglebone-boot server including an option to download images directly from tool.
2017-07-25: Milestone #8 Testing the integrated tool on all target platforms. Building native electron based packages for all the target platforms and testing the native packages on all the platforms.
2017-08-01: Milestone #9 Asking people from community to test the tool and provide feedback. Fixing bugs.
2017-08-08: Milestone #10 Documentation
A buffer of one week has been kept for any unpredictable delays.
2017-08-15: Milestone #11

Experience and approach

I want to do this project out of my passion. I was always intrigued by linux, bootloader, kernel since I used my Nokia N900(pocket linux PC). I'm a good learner and self motivated. I've experience of doing projects with Arduino, Raspberry Pi2 and IC programming. I've made a chrome extension to solve one of my problems:
Chrome Web Store:
I did some basic testing of electron framework with node-usb and made a demo app
More about me and my electronics projects at , I've designed my website, so I can design the gui of flash tool.
I don't give up easily and make sure the problem gets solved.


1. Cross-compile and utilize version control software by creating a "Hello World" application and generating a pull request
2. Cross-compile u-boot
3. A pull request in BBBlfs project


What will you do if you get stuck on your project and your mentor isn’t around?
If I get stuck and mentor isn't around:
1. I'll seek help from BeagleBone community on IRC and mailing list.
2. I'll crawl the internet with google :) and stackoverflow community is always there to help.
3. I believe that since all the code and machines ever are made by humans, so there's no reason I being a human too can't solve the problem. Surely, it can take time, but it isn't impossible.


If successfully completed, what will its impact be on the community?
This project project will be really helpful for everybody especially newbies, who would have a nice experience with flashing images easily and faster, so that they can focus on the more important stuff be it their robotics project, kernel development or some new PRU hack.
Include quotes from community members who can be found on and
Steve Arnold (nerdboy) : It would be easier for newcomers and other community people. Smooth deployment is always good. If you can get it working smoothly/equivalently across 3 (desktop) platforms it would be even better than fsl mfgtool.


Is there anything else we should have asked you?
Yes, what help do I expect from mentor? I just want my mentor to answer my queries at mentor decided time. All the coding is my job :)
One more help, please send the hardware as soon as you decide to select my proposal. And even if this project is not taken by organisation in gsoc, please send me the hardware, I really want to do this project.