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

[Alex Kiernan]

On Wed, Apr 25, 2018 at 8:53 AM, Alex Kiernan <alex.kiernan at gmail.com> wrote:
> On Tue, Apr 24, 2018 at 6:10 PM, Jocelyn Bohr <bohr at verily.com> wrote:
>> Thanks so much for porting this, Alex!
>>

...

>>
>> You can select both network and USB fastboot to be enabled with the Kconfig,
>> but at runtime you have to select to wait on either USB or network by
>> running
>> "fastboot udp" or "fastboot usb <USB_controller>". When the Android
>> bootloader
>> gets the command to reboot back to fastboot, it will read the "fastbootcmd"
>> env
>> variable and run that as a command (common/android_bootloader.c:151).
>>
>
> Thanks for that (especially the detail on android_bootloader which I'd
> not read through). The bit that concerns me is in timed_send_info:
>
>   +/**
>   + * Send an INFO packet during long commands based on timer. If
>   + * CONFIG_UDP_FUNCTION_FASTBOOT is defined, an INFO packet is sent
>   + * if the time is 30 seconds after start. Else, noop.
>   + *
>   + * TODO: Handle the situation where both UDP and USB fastboot are
>   + *       enabled.
>   + *
>   + * @param start:  Time since last INFO packet was sent.
>   + * @param msg:    String describing the reason for waiting
>   + */
>   +void timed_send_info(ulong *start, const char *msg);
>
> The code in timed_send_info is guarded with an ifdef, rather than
> based on the transport that's been selected at runtime. Do we need to
> make timed_send_info work based on the runtime state, rather than the
> compile time, or can we drop the ifdef guard and remove the TODO? I
> guess I'm assuming the former, but with no way to test USB I don't
> want head off down the wrong road!
>

Having started digging through how we'd merge the two code paths, it's
clear if you had UDP and USB both enabled at compile time and then try
and run the USB path it'll try and do UDP things in timed_send_info,
which can't be good!

-- 
Alex Kiernan