[U-Boot] [PATCH 6/6] cmd: Add "boot_android" command.

[Alex Deymo]

Regarding the boot_android command, U-Boot supports loading Android-format
kernel images to memory and booting them. That's not the main purpose of
boot_android, it actually does that by just calling bootm.

The part that U-Boot doesn't support is all the flows around booting an
Android device that are expected in AOSP. A big one is reading and honoring
the Boot Control Block (BCB), normally the first 4KiB of the "misc"
partition. See
https://android.googlesource.com/platform/bootable/recovery/+/master/bootloader_message/include/bootloader_message/bootloader_message.h
for a definition.

BCB is used for factory reset (from the Settings UI in Android), which will
write a message in the BCB saying "boot-recovery":
https://android.googlesource.com/platform/bootable/recovery/+/master/recovery.cpp#135

On boot, the bootloader must read the BCB and decide whether to boot the
normal kernel or instead boot to "recovery" mode. During the Factory Reset,
it is important that this is stored somewhere on the emmc, otherwise if you
just rely on a memory flag to tell the bootloader to boot to "recovery"
mode and complete the factory reset; a cold start boot might forget that
value. There are other cases where the bootloader should enter recovery,
for example when you run "boot recovery" from adb, or whit a multi-stage
non-A/B update (needs to reboot multiple times to recovery).

There's the "bootonce-bootloader" message too, in bootloader_message.cpp in
AOSP as well which tells to boot in bootloader mode (essentially, fastboot
mode), which can be triggered by "reboot bootloader" from userspace.
Deciding this means changing the kernel command line in the bootloader, so
that also must be done somewhere.

On top of that there's all the A/B logic flow, to decide which slot to boot
from; which is also defined in the bootloader_message.h, explained here:
https://source.android.com/devices/tech/ota/ab/ (See "Implementing A/B
Updates" too).

All this is what the boot_android command is taking care of. I'm sorry that
I don't have a better self-contained documentation link about this flow.

I should note that these flows are not *required* for all Android devices.
Android partners are free to use their own format for A/B metadata, not use
the AOSP "recovery" program/updates at all, and I think that even
"fastboot" is not mandatory for some devices (but I really don't know). Of
course, if you don't use this, you have to implement your own (updates, A/B
flow, factory reset...). That said, in my opinion if you take the latest
AOSP, U-Boot and kernel and put them together in a reasonable unlocked
device they should all work with these features and flows. You shouldn't
need to write code to make that work, just enable them, so that's why I
think U-Boot should have these Android-specific flows in it, given that it
already supports loading Android-format kernels.

Best regards,
Alex

2018-04-27 0:41 GMT+02:00 Stanislas BERTRAND <sbertrand at witekio.com>:

> Hi Sam,
>
> > Can I ask you some questions about this code?
> >  1. Do I understand correctly that this is just some old patch hanging
> > in mailing list [1]?
>
> Yes, it is from an old post to the mailing list.
>
> >  2. What is the motivation of adding this command? We already have
> > Android boot image support in bootm command, which we successfully use
> > in TI just by loading needed images to RAM and then passing them to
> > bootm, like this: [2].
>
> I am working to get a Android A/B System implementation on my board.
> I was looking to reuse existing implementation. Aiming to stay close to
> the mainline.
>
> The command boot_android performs the different loading and checks
> required before calling bootm.
>
> Like Alex mentioned [4], those patch series are not recent but it was good
> starting point of implementation.
> I had to perform some customization to have a functional boot flow adapted
> to my system ( Android 7.1.1, Linux 4.4.45, U-Boot 2017.0 ).
>
> I am not pushing to have this particular implementation mainline.
> However having a mainline implementation for Android A/B system,
> would be nice. I was giving feedback from my particular system usage.
>
> >  3. Can you provide more information about how this code works? And
> > probably show some relevant link from Android documentation where it
> > says about boot flow implemented here?
>
> >  [1] https://lists.denx.de/pipermail/u-boot/2017-April/285847.html
> > [2] http://git.denx.de/?p=u-boot.git;a=blob;f=include/
> environment/ti/boot.h;h=24b7783f88947db07480d814c798e5
> 1197c07ce2;hb=HEAD#l38
> <https://lists.denx.de/listinfo/u-boot>
> More information was posted by Alex in his original patch series [3].
>
> Alex, I did add loading of the FDT in the boot_android command. How did
> you load your at 'fdt_addr' ?
>

This was done for the raspberry pi and I was using the FDT that the
bootloader code in the Pi loads and assembles. This is so all the boot.txt
configs and overlays that people expect to work on the pi are used, plus
the cmdline.txt (u-boot.img would be a "kernel" for the rpi, which then
loads android). In that case, the "fdt_addr" is populated from the
board/raspberrypi/rpi/rpi.c, so all you need to do is to load it from
memory and change the FDT if needed. I wasn't loading it from emmc.