I have installed Windows 7 from isostick, and it works flawlessly. In fact the computer I am using to post this (Win7 x64) was installed from an isostick. It has also been used to install Windows XP, Ubuntu 10.10, and to boot SpinRite and memtest86+, among others, across quite a few machines in our preliminary testing.
As to how isostick works:
It contains an Atmel AVR32 microcontroller
which handles everything (USB, talking to internal flash, parsing the filesystem, etc etc).
The most commonly-used USB Mass Storage
subclass and protocol are SCSI Transparent
and Bulk-only Transport
SCSI Transparent is as it sounds: a limited wrapper for transporting SCSI commands. There are non-SCSI subclasses for Mass Storage devices, however they are rarely if ever used, and support is varied as a result.
A flash or hard disk speaks SCSI Block Commands (SBC), while an optical drive speaks SCSI MultiMedia Commands (MMC). Prettymuch all USB flash sticks or harddrives are SBC devices, and USB optical drives would be MMC devices.
Each USB Mass Storage device can present multiple LUNs (Logical Unit Numbers) to the host. Each LUN represents a different logical SCSI device.
The isostick reports two LUNs: one obeying SBC, the other obeying MMC. So, a generic block storage device and an optical drive.
It provides access to the flash memory through the SBC LUN -- when a SCSI read or write request comes in through the SBC LUN, the isostick firmware performs the requested action on the flash memory.
EDIT: I should point out also that some BIOSes only detect the first LUN, so to ensure bootability isostick presents the optical LUN first.
The isostick is aware of FAT32 and able to parse it, there is provision to support other filesystems later.
When it first starts up, it checks if the drive is formatted as one big FAT32 partition (a favorite trick of Windows OSes) or if it has an MBR partition table with any partition types it can parse. For all the partitions it can potentially read, it does some sanity checking and, if they appear valid, it flags them as "readable" in its RAM (this is all happening on the isostick, the host has no knowledge of this).
It then looks for a configuration file, which is currently "/config/iso_filename.txt", though this may change before the units ship.
This file is expected to contain the filename with full path to the ISO file you want to load.
If the contents of /config/iso_filename.txt specify a valid file that isostick can find on a readable partition, it caches some information about the file such as the extents list (list of contiguous chunks of the file, in case of fragmentation, to speed up operations -- otherwise isostick would have to churn through the FAT each time it wanted to read from the file, which is slowww).
If the config files, partitions, or loaded ISO file on the isostick change at any time, those writes must be done through isostick, and it updates itself in realtime.
For example, if you delete the ISO file or decide to reformat the drive, it will automatically force an eject of the disc, since its contents would be invalid. Likewise, if you change the config file, isostick will automatically check the new contents and load the newly-specified ISO file.
From then on, whenever the host reads from the MMC LUN, the isostick actually retrieves the relevant content from the specified ISO file and returns it as if it were a real optical drive reading from a real optical disc.
In this way, the host cannot tell the difference between isostick and a real physical optical drive. It is not relying on any
software on the host side -- it is, for all intents and purposes, an optical drive.
There will be some software to find all the ISO files on your isostick and let you drag'n'drop to load different ISOs, and to help by auto-splitting ISOs >4GB (a FAT32 limitation). Behind the scenes that software will just be modifying /config/iso_filename.txt though, and any other config files, to tell the isostick its intent. Another config file the isostick offers is /config/led_brightness.txt which can contain a number between 0 and 255, or a percentage from 0% to 100%, to control (or disable!) the LED, in case it is too bright or too dim for you.
As to how isosel works:
We call it "isosel" as short for ISO SELector. It's sort of like other boot managers, but all it's doing is talking to isostick.
At present I use a heuristic to detect if the user is attempting to boot from the isostick or is plugging it into a system already booted into an OS. That heuristic is to check if the first Read command sent to the MMC LUN is for sector 17, which contains the El Torito Boot Catalog, where El Torito
is the specification used for bootable CDs in most
cases. In my tests so far, BIOSes seem to read this first, whereas an OS does not care about this information and reads Sector 16 first instead (which contains relevant information in the ISO9660 filesystem)
As I'm sure many of you are aware, El Torito allows a BIOS a couple options for booting from a CD-ROM, the most common of which is by specifying a floppy image. If isostick sees Sector 17 as the first read, rather than going to the currently-loaded ISO file, it supplies a Boot Catalog of its own. The Boot Catalog specifies where the BIOS can find the boot floppy image for isosel. If the ISO already had a boot image it uses that location, otherwise it finds one that is not in use by the ISO's actual contents (in case the heuristic was wrong). When the host reads the sectors specified by the Boot Catalog for isosel, the isostick will return the contents of isosel's boot floppy image instead of going to see what the ISO file has at that location.
It's a bit tricky in the specifics, but I am very careful to avoid returning isosel-related data on any sectors that an OS would use. It's true that if you made an ISO image of the ISO loaded in the isostick optical drive (
), you would get bits of isosel in there. This was done as a compromise -- it is unlikely this would effect the functionality of any ISO you would use in an OS, and it allows much more flexibility in that you can switch ISOs on the fly even when booting from isostick.
In the event that you really do not want this to happen to a particular ISO, even if that means you can't boot into isosel when that ISO is loaded, I plan to add the option to disable isosel on a per-file basis soon.
Assuming you boot into isosel and make a selection, isosel communicates that selection back to the isostick, which remembers it. Then isosel reboots the computer (we're testing ways to avoid a full reboot, but this is the safest approach anyway)
, and this time isostick remembers not to do any isosel trickery, simply presenting the ISO you selected unmodified for the BIOS to boot from.
To summarize, I feel the biggest advantage of isostick is the ability to keep many ISO files on one stick and not have to modify them in any way to boot from them, while also providing an easy way to switch between them.
The second biggest advantage, I would say, is the read-only switch to protect the flash memory.
Many software solutions to this problem exist, but to the best of my knowledge none offer universal support for any ISO in the way that isostick can by virtue of appearing as a real optical drive.
Phew, I hope this adequately explains how and why isostick works!
Feel free to ask more questions or point out any gaps in my explanation, I will be sure to update it!
Edited by elegantinvention, 20 September 2011 - 03:08 AM.