Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

There* is demonstrated switching between multiple running operating systems on the beagleboard. There's also little info on their wiki here.

I wonder what technology are they using for that..

It resembles some sort of virtualization, but it's not likely becase of the low performance of the CPU used. Only one system seems to be running at the same time. All the operating systems are linux based, so it might utilize the same running kernel and some sort of user space switching..

*) Warning: source is in French-English language

share|improve this question

The mention of RAM limitations making it difficult to run 3 operating systems at a time indicates that they are all loaded in to RAM. We also have this phrase: "So far, it's not possible to use the GPU of your beagleboard for both AIOS and Android when they are running at the same time. When starting Android from AIOS, we indeed need to unload the 3D kernel modules so that Android can use them full time."

So my suspicion is that the Beagleboard OS the device is running acts as a bare-metal hypervisor, virtualizing the guest operating systems. Specifically, the guest OS run under a mode called paravirtualization. In the case of PV, the hypervisor is not actually virtualizing computer hardware. Instead, the guest OS run a kernel that has been built to interact with the hypervisor directly instead of interacting with hardware as usual.

An example of such a system is the Xen Hypervisor, an open source project that (iirc) actually developed paravirtualization. Since Xen is a 'bare-metal hypervisor', it acts kind of like an OS itself, in that it boots directly (rather than running inside another OS). A Linux OS can be built with a domU kernel or guest kernel that then performs I/O with Xen instead of with hardware directly. The OS runs just fine because the kernel does everything that a kernel is supposed to do, but since there is no virtualized hardware this is not virtualization in a strict sense. Because Xen doesn't have to waste time pretending to be a motherboard (and all the things on one and attached to one), there is much less overhead than in a fully virtualized environment (therefore there is much less impact on performance).

Since the kernel needs to be built to work in such an environment, the guest OS is generally Linux-based. It is possible to do other OS, though, just more difficult. For example, a complete set of drivers has been developed to run Windows on Xen PV.

To tie this back in, because Xen is very popular and FOSS, I would not be surprised if the Beagleboard system is based directly on Xen or on components of Xen.

share|improve this answer
interesting info. unfortunately, it did not help much, it was just a speculation.. – mykhal Sep 1 '11 at 21:40
up vote 0 down vote accepted

OK, finally I had to dig into it by myself..

The "virtualization technology" used is just chroot.

The system can be chosen from the menu during boot. Each one has its own read-only squashfs image (including the kernel image and modules, all are the same version) and read-write aufs overlay on the separate directory on the disk.

Only one of the sytems, however, the primary OS - AI OS (Alwaysinnovating OS, derivative of Ångström distribution), has the ability to launch/switch-into another one. It can be done from "AI Multiple OS" menu, which is a simple Qt app, just an interface launching several shell scripts. Inspecting them reveals, that starting another system is just preparation of system's chroot directory, mountig its suqashfs image and aufs directory there, binding (mount --bind) necessary system dirs (like /dev, /proc, ..) and chrooting into it. For example, the Ubuntu system is launched creating its chroot structure, pasting an initialization script into it (which contains launching of services like like dbus, hal, ... ended by running Xsession). Then, another X11 server is launched with a specific display number (:2 in this case) is launched with xinit. Finally, it's chrooted in with the mentioned initialization script.

So those systems launched from the primary AI OS are just their chrooted environments running on top of the AI OS - it's different from when it was running by itself, selected during the boot.

Now, switching between the running systems (by multios menu app in AI OS, or by using the onboard hardware button) is just switching between systems' X11 virtual terminals (found by processing ps avx output) with chvt. Stopping the system is just killing all corresponding chroot processes (all base system's processes, whose /proc/$PID/root is matching the "virtual" system's chroot dir).

..hope I got it right, I was not in fact running the system, just inspecting the image and some source.

some reference links:

share|improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .