[U-Boot] [RFC PATCH v1 0/5] Add fastboot UDP support

[Alex Kiernan]

On Tue, Apr 24, 2018 at 11:24 AM, Alex Deymo <deymo+ at 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 at 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!

-- 
Alex Kiernan