On Tue, Apr 24, 2018 at 11:24 AM, Alex Deymo deymo+@google.com wrote:
+Jocelyn.
Thanks Alex for taking the time to port this!!
It turned out to be a great opportunity to play with coccinelle on something trivial, which I'd been meaning to do for ages... the refactor to add response into the fastboot_okay/fail call chain was a breeze with it.
2018-04-24 11:37 GMT+02:00 Alex Kiernan alex.kiernan@gmail.com:
This series merges the fastboot UDP support from AOSP into mainline U-Boot.
Open questions:
- what's the correct way of attributing the original authors? I've added Co-authored-by, is that right? checkpatch doesn't seem to know any of the co- tags
- currently there's no NAND support and I've no way of testing that, so my inclination is towards leaving it like that until someone with that particular itch to scratch can look at it
Fastboot uses partition names, like "system" and "boot" which have a meaning in the Android partition scheme. For GPT, we just use the partition names as the android names; but if you are booting from some other storage like NAND where you don't have that then you need some mapping glue ("system" --> device and partition number). I've seen U-Boot modifications for several devices where they just stick a table hard-coded in the U-Boot code; which works great for that device but it isn't really a generic approach. Other than handling the names issue, I don't see any problem with supporting NAND here, but a generic way to set global names / alias would be needed for this.
With the fastboot NAND support in mainline it looks like we end up in mtdparts to deliver that mapping through environment variables. No actual idea what that looks like when you're driving it.
- you can select both USB and UDP fastboot, but the comments in the AOSP code suggest that needs fixing - again, I've no board I can test USB fastboot on
I thought we checked in the Kconfig that you couldn't enable both. I don't remember the details now but yeah you can't wait for network or USB traffic on the current code.
The version I picked from (o-mr1-iot-preview-8) has them as independent symbols, but making them a choice would resolve the issue for now.
I've not tested all the code paths yet, but the obvious stuff works (basic interaction, download, boot) - every interaction elicits a `WARNING: unknown variable: slot-count` on the console; I'm guessing that my local end is sending a getvar for that, but I've not investigated.
Yes, there's a bit of different handling of partitions for A/B android devices. Instead of "system" you have two partitions: "system_a" and "system_b" (potentially more although 2 is the most common case) so to know whether you have an old device or a newer device the fastboot client checks the "slot-count" variable. Undefined means of course that you have an old-style device, but if you return something like "2" you would be able to flash "system" on the "slot A" which is translated (again in the fastboot client) to flash "system_a" partition. This is useful when using the higher level operations like flashall/update and you want to specify to flash only "slot A", "slot B" or even both of them. There are other fastboot variables that require some plumbing, such as "has-slot:<partition>" to tell whether "system" is a partition that indeed has the two versions _a and _b. Typically some partitions are twice (like "system" and "boot") and some other are not (like "misc" or "userdata"). Anyway, this as is should work for either old-style partition schemes or by force flashing "system_a" with the system.img.
Cool, thanks... that saves me a bunch of investigation!