GSoC application for Cross platform USB boot

Google Summer of Code
1

This project is yet only a draft, any feedback would be appreciated.

https://docs.google.com/file/d/0B2X5xEf0CtIeZ0hyNTBfbnFKaHM/edit

I did the pull request as well.

2

Interesting, so you’re planning a front-end to writing existing ready-to-work images to the eMMC on the beaglebone black? Since you’ll be leveraging Vlad’s project from last year, are you expecting most of the time needed to be on the GUI and handling things once Linux is up and running?

3

Please submit your proposal to Melange ASAP.

as for the scope of the project, last year's is limited by the fact that all the image is loaded into RAM before flashing. I would like to have a way that can flash eMMC/SD that is larger than what fits into RAM.

4

I added some comments to the document:

  • Will you provide a simple mechanism to simply boot a Linux image rather than go as far as flashing the eMMC? How will your interface look such that we can boot to any various stage or replace the image used at any various point? In particular, a use-case I have is to ship a node-webkit executable for Mac/Linux/Windows that a user can run and provides them with the ability to load a Linux image containing BoneScript and node.js to run the tutorials athttp://beagleboard.org/support/BoneScript. They could also choose to reflash their boards using the images athttp://beagleboard.org/latest-images writing to either the on-board eMMC or an external uSD card.
  • Why use serial rather than TFTP to send the image to be flashed?
  • Do you have any familiarity with or access to a Mac? Any suggestions for getting the application implemented there?
  • Is there a strong desire to use .NET rather than a C compiler? Can you describe the value of that?
5

In this case I will use DFU to expose the eMMC/SD card to the host. In this way I can write only parts of the filesystem or a full image there. As i read on TI wiki there are patches in the mainline u-boot for AM335x to enable DFU mode. Vlad told me that last year he had problems with the usb transfer and that is why he shipped the image to the board and chose not to write the filesystem step by step. As I know from the announcements that the latest kernel version has rock solid USB and can be used.

6

The support of last years project was to flash both SD/eMMC but it could also boot from an image stored in the RAM. I think the first step on each of the platforms is to flash both eMMC/SD card with an image provided. After we have this stable we can proceed in making it modular as in just replacing u-boot, spl, kernel and filesystem. This can also be done via DFU because we will have exported the partitions over to our host machine.

I was thinking to stick with last years implementation but this can be changed easily, just the protocol differs. Using TFTP we would simulate an ethernet device over USB, what the ROM Bootloader, SPL, u-boot do.

Unfortunately I do not own a Mac and do not think that back home will have access to one. Here I am a bit strained.

Mainly using .NET would be easy to code the application, the .NET framework is really easy to use and they have a wrapper for WinUSB.

Also I have uploaded my proposal on Melange, can I get some feedback about the impact on the community part ?

7

Maybe I need to clarify things a bit here, especially the difficulties I faced last year. The main issue was the Android platform because not all devices had USB Host and RNDIS module in their kernel. This year there will be no issue like this. On Windows RNDIS is enabled by default and on Mac I know they have something there that works, at least all the 3G modems that use this work there. Another major issue was the USB communication, I was simulating serial transfer using g_serial and when I increased the speed of the transfer the USB bus on the Beagle side just crashed randomly with some Babble errors…still did not find out what it means. So I was doing flashing in like 20~ minutes of the eMMC but it can be done faster. Another restrain was the RAM size because I had the RAM as a middle buffer in which I stored data and then ship it to the eMMC/SD. I was looking into using DFU last year or exposing the storage with gadget_fs but I had some awkward errors and decided to stick with g_serial because I was kinda late in the timeline and needed to finish the project. Maybe this year the DFU approach or gadget_fs can be used. If I remember right Android did not like gadget_fs, can’t really recall correctly. trini told me last year that DFU is working on AM335x so u-boot has all the things working.