GSoC Android boot system

Hello community!

My name is Vlad Ungureanu, curently student at Jacobs University, Bremen. My major is Computer Science and I’m class of 2015. I was more active on the #beagle-gsoc under the nickname vvu. I worked on my proposal for the Android boot based system. The goal is to partially boot a BeagleBoard from an Android device and afterwards use the Android device(tablet/phone) as a touchscreen/monitor to have some video output.

The system will work like this:

  • On the MMC/eMMC there will be the x-loader, u-boot,a linux kernel and a binary which will serve as communication between the board and the android device via ADK. The booting procedure works until the kernel from the internal storage is loaded.

  • At this point the binary is ran and the final kernel that will be ran on the board and the filesystem are requested from the phone.

  • The new kernel is exchanged using kexec with the new one and then it finished the booting procedure using the fs that was copied at the previous step.

If there is a requirement to have a kernel and application already on the board, what is the real point of downloading a new kernel to kexec? What is the additional functionality that’d be enabled that couldn’t/shouldn’t be preloaded?

  • Until now we have a fully functionally BeagleBoard but with no video output. To overcome this issue the Beagle will run a daemon that will get the ouput of the framebuffer and will send it to the Android device over ADK.

This does sound like a nice feature. Running X11 on a phone doesn’t seem like it’d have a great user experience. Would you be running a framebuffer without X11 and able to run something like Qt apps? What type of applications would you really create? Personally, I’d find simply using a web server on the board and running a UI in the web browser on the phone to be a simpler UI development solution.

  • On the phone there will be an app that will render on the screen the data received over ADK. The next step is to capture the touches and send them back to the Beagle to turn them into clicks.

Cool. What types of interfaces would be provided?

      * On the MMC/eMMC there will be the x-loader, u-boot,a linux
        kernel and a binary which will serve as communication between
        the board and the android device via ADK. The booting procedure
        works until the kernel from the internal storage is loaded.
      * At this point the binary is ran and the final kernel that will
        be ran on the board and the filesystem are requested from the phone.
      * The new kernel is exchanged using kexec with the new one and
        then it finished the booting procedure using the fs that was
        copied at the previous step.

If there is a requirement to have a kernel and application already on
the board, what is the real point of downloading a new kernel to kexec?
  What is the additional functionality that'd be enabled that
couldn't/shouldn't be preloaded?

this is to overcome the ADK limitation that the android device has to be a USB "device" and not all support host. As said in the comments to the proposal, if we can live with the fact that only a subset of Android devices supports host features, we can make full ROM boot the first target of this project.

      * Until now we have a fully functionally BeagleBoard but with no
        video output. To overcome this issue the Beagle will run a
        daemon that will get the ouput of the framebuffer and will send
        it to the Android device over ADK.

This does sound like a nice feature. Running X11 on a phone doesn't
seem like it'd have a great user experience. Would you be running a
framebuffer without X11 and able to run something like Qt apps? What
type of applications would you really create? Personally, I'd find
simply using a web server on the board and running a UI in the web
browser on the phone to be a simpler UI development solution.

running a web browser or a full blown remote frame buffer would both be
based on the underlying USB connection between the bone and the Android
device.

if we go with host mode booting then of course further communication between Bone and Android could be host based as well, the other option is to use ADK here as this has a supported API in Android and not all users would need the "boot" feature

Regards,

Vladimir