BeagleBoard/GSoC/node-beaglebone-boot

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


node-beaglebone-boot

{{#ev:}}

A short summary of the idea will go here.

Student: Ravi Kumar Prasad
Mentors: Jason Kridner
Code: https://github.com/beagleboard/node-beaglebone-boot
Wiki: http://elinux.org/BeagleBoard/GSoC/node-beaglebone-boot
GSoC: [NA GSoC entry]

Status

This project is currently just a proposal.

Proposal

About you

IRC: ravikp7
Github: https://github.com/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)

Description

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 etcher.io 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 etcher.io variant
The UI of etcher.io 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

Timeline

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 etcher.io tool.
2017-07-11: Milestone #6 Creating UI for the all in one BeagleBone flasher. Testing npm packages used in etcher.io
2017-07-18: Milestone #7 Integrating the UI with etcher.io 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: https://goo.gl/YiWIH4
Source: https://github.com/ravikp7/Snap-Tabs
I did some basic testing of electron framework with node-usb and made a demo app https://goo.gl/554gt2
More about me and my electronics projects at https://ravikp7.github.io , 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.

Tasks

1. Cross-compile and utilize version control software by creating a "Hello World" application and generating a pull request https://github.com/jadonk/gsoc-application/pull/60
2. Cross-compile u-boot https://gist.github.com/ravikp7/770ff7df85f0e0588d3b112b32403697
3. A pull request in BBBlfs project https://github.com/ungureanuvladvictor/BBBlfs/pull/31

Contingency

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.

Benefit

If successfully completed, what will its impact be on the BeagleBoard.org 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 BeagleBoard.org community members who can be found on http://beagleboard.org/discuss and http://bbb.io/gsocchat.
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.

Suggestions

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.