Re: Userspace Fastboot
1,862 views
Skip to first unread message
Jean-Baptiste Queru
Jul 3, 2012, 12:15:38 PM7/3/12
to android...@googlegroups.com
This is interesting, but I'm a bit surprised.
Like you noted, the point of fastboot is to be implemented in
bootloaders, and that's why its protocol is simple to the extreme.
As soon as you run in environments that are rich enough to run a
recovery-like system, why not simply run recovery? That's a far more
flexible approach than fastboot. It can handle signed packages that
can therefore be flashed safely without erasing all data. It can work
on a file-by-file basis.
Some notes:
-Starting with Galaxy Nexus (and present on Nexus 7), the bootloader
can return information about the data and cache partition. In Jelly
Bean, we've created "fastboot format" in addition to "fastboot erase",
that creates an appropriate filesystem in fastboot client and flashes
that. That way, the device-side doesn't need to know how to create a
filesystem.
-Also, starting with Jelly Bean, recovery supports flashing over adb,
so that it's much easier to sideload OTA packages.
JBQ
On Mon, Jul 2, 2012 at 11:18 AM, andrew boie <andre...@gmail.com> wrote:
> Fastboot up till now seems to be exclusively a bootloader feature, but in
> the process of working on several devices which either didn't have a
> traditional bootloader or had restricted functionality in bootloader space
> (such as legacy PC bootloaders which only can do BIOS calls) I implemented a
> device-side Fastboot mechanism which runs in userspace. For the moment I
> call it "Droidboot".
>
> I'm posting a brief brain dump of some of its features to see if there is
> any interest in upstreaming this into AOSP. It would be a new Apache 2
> project (bootable/droidboot or something similar) but doesn't have
> dependencies on anything that isn't already in AOSP. I think this might be
> useful to have as it de-couples the Fastboot stuff from whatever bootloader
> is in use, and since it's Android userspace you can do a lot more things,
> and extend it with plug-ins.
>
> - The fastboot client works with this unmodified.
>
> - It is constructed as an alternate boot image, similar to the Recovery
> Console. Users get at it by bootloader 'magic key', bootloader menu, or
> things like 'adb reboot bootloader'
>
> - The UI is the same libminui code as the Recovery Console. It just shows an
> animation and a progress bar most of the time, but in case of errors it will
> dump the error text on the screen.
>
> - Droidboot uses disk_layout.conf from Android libdiskconfig and also
> recovery.fstab to get the information it needs about the partitions (in
> disk_layout.conf) and the filesystems within them (in recovery.fstab). It's
> a bit clunky to use both of these files, but unifying these is outside the
> scope of what I'm trying to accomplish at the moment. It's possible to
> re-partition the disk.
>
> - Droidboot has a plug-in system. This lets you write platform-specific
> flash and OEM commands without having to hack up the base Droidboot code. So
> if I had some C library which implemented updating the modem firmware for a
> particular product, I'd encapsulate that in a plug-in and from the user's
> perspective "fastboot flash modem fw.bin" works as they would expect.
>
> - "fastboot flash foo bar" interprets the flash target (foo) in one of
> several ways:
> -- "disk" - write the image directly to the disk device node specified in
> disk_layout.conf
> -- "update" - Special case for OTA update zip files - mount the cache
> partition, write the image to it, set up the command file, and reboot into
> the Recovery Console to apply the update. This is different from "fastboot
> update" which has alternate logic but IMHO this is cleaner since Recovery
> Console does almost all the work.
> -- If a plug-in has registered a flash target matching the target name, use
> the plug-in's logic for what to do with it
> -- Otherwise, look in disk_layout.conf to match the flash target to the
> actual device node, and write the image there. If it's an ext4 filesystem
> image, it can get resized to fill the partition and fsck-ed for consistency.
> It honors the size argument in the recovery.fstab which is used to reserve
> space at the end of a partition for a crypto footer.
>
> - You can pass parameters when flashing stuff. The syntax is a little
> clunky, it basically gets stuffed into the flash target on the command line.
> Example "fastboot flash boot:foo=8192,bar=1 boot.img". Right now I have
> params to specify offsets, image type (raw, gzipped), etc. This lets me do
> fun things like flash images which are gzipped and decompress them on the
> fly while writing them out, or break up really large images into several
> chunks which are flashed in sequence...
>
> - "fastboot erase bar" currently only formats EXT4 but it shouldn't be too
> much hassle to add other fs support if someone wants it.
>
> - In addition to USB, Droidboot can also do Fastboot over Ethernet (useful
> for devices which have USB but not OTG)
>
--
Jean-Baptiste M. "JBQ" Queru
Technical Lead, Android Open Source Project, Google.
Questions sent directly to me that have no reason for being private
will likely get ignored or forwarded to a public forum with no further
warning.
Like you noted, the point of fastboot is to be implemented in
bootloaders, and that's why its protocol is simple to the extreme.
As soon as you run in environments that are rich enough to run a
recovery-like system, why not simply run recovery? That's a far more
flexible approach than fastboot. It can handle signed packages that
can therefore be flashed safely without erasing all data. It can work
on a file-by-file basis.
Some notes:
-Starting with Galaxy Nexus (and present on Nexus 7), the bootloader
can return information about the data and cache partition. In Jelly
Bean, we've created "fastboot format" in addition to "fastboot erase",
that creates an appropriate filesystem in fastboot client and flashes
that. That way, the device-side doesn't need to know how to create a
filesystem.
-Also, starting with Jelly Bean, recovery supports flashing over adb,
so that it's much easier to sideload OTA packages.
JBQ
On Mon, Jul 2, 2012 at 11:18 AM, andrew boie <andre...@gmail.com> wrote:
> Fastboot up till now seems to be exclusively a bootloader feature, but in
> the process of working on several devices which either didn't have a
> traditional bootloader or had restricted functionality in bootloader space
> (such as legacy PC bootloaders which only can do BIOS calls) I implemented a
> device-side Fastboot mechanism which runs in userspace. For the moment I
> call it "Droidboot".
>
> I'm posting a brief brain dump of some of its features to see if there is
> any interest in upstreaming this into AOSP. It would be a new Apache 2
> project (bootable/droidboot or something similar) but doesn't have
> dependencies on anything that isn't already in AOSP. I think this might be
> useful to have as it de-couples the Fastboot stuff from whatever bootloader
> is in use, and since it's Android userspace you can do a lot more things,
> and extend it with plug-ins.
>
> - The fastboot client works with this unmodified.
>
> - It is constructed as an alternate boot image, similar to the Recovery
> Console. Users get at it by bootloader 'magic key', bootloader menu, or
> things like 'adb reboot bootloader'
>
> - The UI is the same libminui code as the Recovery Console. It just shows an
> animation and a progress bar most of the time, but in case of errors it will
> dump the error text on the screen.
>
> - Droidboot uses disk_layout.conf from Android libdiskconfig and also
> recovery.fstab to get the information it needs about the partitions (in
> disk_layout.conf) and the filesystems within them (in recovery.fstab). It's
> a bit clunky to use both of these files, but unifying these is outside the
> scope of what I'm trying to accomplish at the moment. It's possible to
> re-partition the disk.
>
> - Droidboot has a plug-in system. This lets you write platform-specific
> flash and OEM commands without having to hack up the base Droidboot code. So
> if I had some C library which implemented updating the modem firmware for a
> particular product, I'd encapsulate that in a plug-in and from the user's
> perspective "fastboot flash modem fw.bin" works as they would expect.
>
> - "fastboot flash foo bar" interprets the flash target (foo) in one of
> several ways:
> -- "disk" - write the image directly to the disk device node specified in
> disk_layout.conf
> -- "update" - Special case for OTA update zip files - mount the cache
> partition, write the image to it, set up the command file, and reboot into
> the Recovery Console to apply the update. This is different from "fastboot
> update" which has alternate logic but IMHO this is cleaner since Recovery
> Console does almost all the work.
> -- If a plug-in has registered a flash target matching the target name, use
> the plug-in's logic for what to do with it
> -- Otherwise, look in disk_layout.conf to match the flash target to the
> actual device node, and write the image there. If it's an ext4 filesystem
> image, it can get resized to fill the partition and fsck-ed for consistency.
> It honors the size argument in the recovery.fstab which is used to reserve
> space at the end of a partition for a crypto footer.
>
> - You can pass parameters when flashing stuff. The syntax is a little
> clunky, it basically gets stuffed into the flash target on the command line.
> Example "fastboot flash boot:foo=8192,bar=1 boot.img". Right now I have
> params to specify offsets, image type (raw, gzipped), etc. This lets me do
> fun things like flash images which are gzipped and decompress them on the
> fly while writing them out, or break up really large images into several
> chunks which are flashed in sequence...
>
> - "fastboot erase bar" currently only formats EXT4 but it shouldn't be too
> much hassle to add other fs support if someone wants it.
>
> - In addition to USB, Droidboot can also do Fastboot over Ethernet (useful
> for devices which have USB but not OTG)
>
--
Jean-Baptiste M. "JBQ" Queru
Technical Lead, Android Open Source Project, Google.
Questions sent directly to me that have no reason for being private
will likely get ignored or forwarded to a public forum with no further
warning.
Pierre Tardy
Jul 3, 2012, 1:28:38 PM7/3/12
to android...@googlegroups.com
On Tue, Jul 3, 2012 at 6:15 PM, Jean-Baptiste Queru <j...@android.com> wrote:
This is interesting, but I'm a bit surprised.
Like you noted, the point of fastboot is to be implemented in
bootloaders, and that's why its protocol is simple to the extreme.
As soon as you run in environments that are rich enough to run a
recovery-like system, why not simply run recovery? That's a far more
flexible approach than fastboot. It can handle signed packages that
can therefore be flashed safely without erasing all data. It can work
on a file-by-file basis.
A simple reason for that is that google is requiring every device that wants to ship to support fastboot protocol.
On intel atom, we have very simple boot loader, and we dont want to implement fastboot in bootloader.
So the most straighforward solution is to implement in linux userspace, and as far as "adb reboot bootloader" is concerned, our bootloader is droidboot.
Our first version actually implemented fastboot in recovery (that is actually what ships on our GB phones)
But for upstream deviation reason, it looked more reasonable for us to implement this in a separate initrd.
Our droiboot can indeed flash ota packages directly using
fastboot flash update update.zip
It will actually copy the file in /cache and reboot in recovery for this.
Also, flashing ota.zip is a bit slow, and there is a need for manufacturing to optimize the flashing. This is why we also support flashing system.img.gz
-Starting with Galaxy Nexus (and present on Nexus 7), the bootloader
can return information about the data and cache partition. In Jelly
Bean, we've created "fastboot format" in addition to "fastboot erase",
that creates an appropriate filesystem in fastboot client and flashes
that. That way, the device-side doesn't need to know how to create a
filesystem.
We actually took the opposite way of enhancing android's fstab format in order to contain partitionning information.
So that the same configuration file is used to partition, format, and mount the filesystems.
This feature is probably not in the area of the generic part of droidboot.
Regards,
Pierre
abhimanyu kapur
Jun 17, 2013, 6:39:40 AM6/17/13
to android...@googlegroups.com
Hi Andrew
Can you share the source code for this application. Is it under GPLV2.
-Adam
Reply all
Reply to author
Forward
0 new messages