2 About your project
2.1 What is the name of your project?
Cross platform USB boot
2.2 What is the timeline for development of your project?
The Summer of Code work period is about 11 weeks long; tell us what you will be working on each week.
22 April 18 May More research on the topic, preparing for the project.
19 May 3 June Modify and extend where needed last years code for Linux flashing system (of the image only), mainly switch to the use of DFU.
4 June 14 June Debugging and testing, consulting with the mentor regarding the quality of the code and used procedures as well as the implementation of the communication.
15 June 22 June Working on the modifications which might occur during the consultation with the mentor; debugging and testing those modifications.
23 June 3 July Working on the implementation of flashing not only the image but separate parts of the filesystem only
4 July 11 July Debugging and testing, consulting with the mentor regarding the quality of the code and used procedures as well as the general implementation.
13 July 19 July Working on the modifications which might occur during the consultation with the mentor; debugging and testing those modifications.
20 July 27 July Providing a GUI for the software.
28 July 3 August Debugging and testing the whole software peace under Linux.
4 August 14 August Testing the software under Windows and OS X, in case the last will be acquired; providing any needed modifications
15 August 22 August Documentation of the whole software piece.
2.3 Describe your project in 10-20 sentences. What are you making? For whom are you making it, and why do they need it? What technologies (programming languages, etc.) will you be using?
I have looked over the last years implementation of the Linux flashing system and will keep the same structure of operations with a small modification when it comes to u-boot and especially loading separate files to the filesystem, rather then the whole image. When the AM335 SoC does USB Booting it exposes an RNDIS network interface to the host machine. At this point using user-space USB libraries I will send the second stage boot-loader, mainly SPL to the board. The protocols used at this step are BOOTP for IP assignation and TFTP for file transfer. Vlad told me that he has a small patch to u-boot source code that tricks the board to think the network interface is already up without any communication with the host we already own the USB interface so data can flow freely over there. After SPL is up and running it will receive using the same protocols and flow of events the u-boot binary. At this point DFU can be used to write to a specific part of the memory, hence loading the image not to RAM as before, but to either eMMC or uSD card directly. This means as well that writing of either the whole image or of only some parts of the filesystem is possible in case the kernel exists already and u-boot is loaded in to the board. Assuming all the above, last years trick where after u-boot is loaded a daemon was sent to the board which loaded the rest on the image will not be need any more, hence a more simplified process with new features for flashing separate parts of the filesystem.
As a summary the protocols used will be RNDIS, BOOTP, TFTP. As USB user-space I will stick to Libusb because their windows port is strong. On top of this I will be needed to implement the IP/Ethernet/ARP headers for the RNDIS communication, so my networks knowledge will come in handy here.
All programming will be done in C. The GUI for both Windows and Linux will be implemented in QT, since the main C library for USB communication will be libusb which is cross-platform compatible and is supported on both Linux and Windows, the code for one platform can be easily ported to another. Since both libusb and QT are supported by OS X, I will be able to test my software on a Mac without acquiring the machine, which I don’t posses, for a long time.
The end software can be used by anyone who requires often flashing and hence is in need of a fast reliable and easy method to do it. The user can start from pupils and student who might use this for study purposes and will end with professionals who can use it for industrial purposes of testing the hardware or loading the target image. The software can be used for testing specific
2.4 Convince us, in 5-15 sentences, that you will be able to successfully complete your project in the timeline you described.
Since I have already very good knowledge in C programming and above basic knowledge in USB communication as well as network skills, the whole project will resolve to less time spent on research and more on coding.
None of my previous project can be related to this one in terms of content, but the fact that I complete all of them with success is relatable. The courses that I take now - Operating Systems and Operating System Lab have a good insight on the low level C programming and since I perform there with a high outcome, I am sure I will manage this project as well. I have knowledge of building GUIs in QT framework as well as Windows Forms, hence everything will boil down just to the matter of design.
I am sure that I will be able to complete the project in this timeline; time management, self learning and current experience are the key criteria here and I posses the needed skills. I am planning to set for myself earlier deadlines then those that are mentioned in the timetable so that I can be sure that I will keep with the schedule, and manage everything in time.
3 You and the community
3.1 If your project is successfully completed, what will its impact be on the BeagleBoard.org community?
The community will have a new (easier and faster) option to flash their images on to the board. I am sure that the ease of flashing the kernel on to the board might attract new people as well. Since the time of flashing the kernel will decrease drastic, new uses of the boards might emerge, this again will work towards an enlargement and is a general benefit for the community.
The fact that the project focuses on multi-platfrotming will give the community more freedom to work on their projects, hence not forcing them to stick to one or another platform. The community will be able to use their favourite software for coding and as a result leading to a better development experience.
Since during u-boot DFU will be used this will make the software flexible and hence give the end user more freedom in what he can do. For example the user will be available to ship only specific software peace he wants to run on the board while leaving the kernel unaltered. The use of DFU will add one more property and mainly flashing images greater then 512MB.
3.2 What will you do if you get stuck on your project and your mentor is not around?
First, eLinux.org and the BeagleBoard community wiki pages can be of help for the problems I might face as well as community blogs. BeagleBoards git repository might be of help as well (for example the u-boot repository). Since the community has both a mailing list and an IRC channel, those will come handy in case I can not find the solution on my own. But those for sure will not be the only resources I’d try to use, internet is wide, every problem has a solution, it just needs the right approach. In case the problem is not related to the board, I am sure I don’t have to explain in this answer how I will google the problem.