Better Android support, plus a bit of improvements

[me-cafebabe]

Please check out each commits for details.

[stephan-gh]

Thanks a lot for working on this! I have already pushed 5 of your commits that look good to me. Please rebase to drop them from the branch.

I haven't fully understood the "big picture" here. Could you maybe add a short "design document" to Documentation/android.md (or something like this) and describe:

• Motivation (Boot Android with mainline through lk2nd)
• How to set this up (flash lk2nd to both boot and recovery)
• How do the expected flows look like? Android sets up the recovery message, reboots to recovery, the stock bootloader reads the recovery message, boots the recovery partition (= lk2nd) and then lk2nd does the same again?

I think understanding this better would help me to review the rest of the changes.

[stephan-gh]

Have you tried

if (IS_ENABLED(ABOOT_STANDALONE))
	goto out;

(Not sure if that code causes compile errors...)

Rule of thumb: Avoid macros where possible, this improves compile testing. I'm not saying goto is great, but the jump label is there already, so not our fault. >:D

[me-cafebabe]

yep, some of those code should cause compilation errors...

as far as I can see, reset_device_info() and set_device_root() functions are already excluded by macro !ABOOT_STANDALONE in commit app: aboot: Avoid using special partitions using ABOOT_STANDALONE=1, and those code is calling that two functions

[me-cafebabe]

Thanks a lot for working on this! I have already pushed 5 of your commits that look good to me. Please rebase to drop them from the branch.

I haven't fully understood the "big picture" here. Could you maybe add a short "design document" to Documentation/android.md (or something like this) and describe:

* Motivation (Boot Android with mainline through lk2nd)

* How to set this up (flash lk2nd to both boot and recovery)

* How do the expected flows look like? Android sets up the recovery message, reboots to recovery, the stock bootloader reads the recovery message, boots the recovery partition (= lk2nd) and then lk2nd does the same again?

I think understanding this better would help me to review the rest of the changes.

Sorry, I'm unlikely able to write a decent document, but I can explain my "big picture" to you:

Honestly, I have to use lk2nd only because of the mainline kernel ports relies on it. Integrating lk2nd in Android and inserting lk2nd to the boot flow is breaking Android standards and is making the things a bit complicated.

I'm trying to make lk2nd transparent to the end user. Ideally, the end user doesn't have to worry about the existence of lk2nd.

In my own Android device tree configuration, I have added build rules to build lk2nd inline, and have overridden boot.img build rule to have it placing lk2nd.img at 0 offset and the real Android boot.img at 512KB offset.

lk2nd is integrated into recovery.img too, in the same way as boot.img. When booting into recovery, the boot flow is:

stock bootloader detects boot mode is recovery -> stock bootloader boots recovery partition at 0 offset -> lk2nd is loaded because it's at 0 offset -> lk2nd keeps detecting boot mode is recovery -> lk2nd boots the virtual partition named "recovery" which is actually 512KB offset of the real recovery partition -> Android recovery image is loaded

There's two ways to set the boot mode for the next boot: writing string to misc partition (standard Android way), and the stuff inside #if USE_PON_REBOOT_REG.

When the users wants to install android with mainline kernel, they could either get partition images for flashing with fastboot, or standard Android OTA package for flashing in recovery mode, either ones have {boot,recovery}.img with lk2nd embedded in.

The only things that still haven't got dealt are:

• Flashing {boot,recovery}.img through lk2nd's fastboot. The data on the real recovery partition will be like "lk2nd + lk2nd + recovery".
• Booting {boot,recovery}.img through fastboot boot. The device will boot lk2nd from fastboot client, however then the lk2nd will not load the real Android boot image from memory correspondingly, but loading from mmc instead.