From: Lukasz Majewski <lukma@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [RFC PATCH v1 0/5] Add fastboot UDP support
Date: Wed, 25 Apr 2018 17:19:10 +0200 [thread overview]
Message-ID: <20180425171910.26a944a5@jawa> (raw)
In-Reply-To: <CAO5Uq5TNB6tBGVGQbi+EesL6X8g44xHQ8k4wPKMvYsrPRK-iMg@mail.gmail.com>
On Wed, 25 Apr 2018 13:50:50 +0100
Alex Kiernan <alex.kiernan@gmail.com> wrote:
> On Wed, Apr 25, 2018 at 8:53 AM, Alex Kiernan
> <alex.kiernan@gmail.com> wrote:
> > On Tue, Apr 24, 2018 at 6:10 PM, Jocelyn Bohr <bohr@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!
>
I think that we can assume operation of only one medium in a time - i.e.
when you issue fastboot usb then no UDP support (and opposite).
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180425/d9c5972a/attachment.sig>
next prev parent reply other threads:[~2018-04-25 15:19 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-24 9:37 [U-Boot] [RFC PATCH v1 0/5] Add fastboot UDP support Alex Kiernan
2018-04-24 9:37 ` [U-Boot] [RFC PATCH v1 1/5] dfu: Refactor fastboot_okay/fail to take response Alex Kiernan
2018-04-25 7:27 ` Lukasz Majewski
2018-04-25 8:10 ` Alex Kiernan
2018-04-24 9:37 ` [U-Boot] [RFC PATCH v1 2/5] dfu: Extract fastboot_okay/fail to fb_common.c Alex Kiernan
2018-04-25 7:32 ` Lukasz Majewski
2018-04-25 8:15 ` Alex Kiernan
2018-04-24 9:37 ` [U-Boot] [RFC PATCH v1 3/5] net: dfu: Merge AOSP UDP fastboot Alex Kiernan
2018-04-24 9:37 ` [U-Boot] [RFC PATCH v1 4/5] dfu: Resolve Kconfig dependency loops Alex Kiernan
2018-04-25 7:53 ` Lukasz Majewski
2018-04-25 8:55 ` Alex Deymo
2018-04-24 9:37 ` [U-Boot] [RFC PATCH v1 5/5] net: dfu: Support building without MMC Alex Kiernan
2018-04-24 10:24 ` [U-Boot] [RFC PATCH v1 0/5] Add fastboot UDP support Alex Deymo
2018-04-24 11:58 ` Alex Kiernan
2018-04-24 17:10 ` Jocelyn Bohr
2018-04-25 7:53 ` Alex Kiernan
2018-04-25 12:50 ` Alex Kiernan
2018-04-25 15:19 ` Lukasz Majewski [this message]
2018-04-26 3:27 ` Kever Yang
2018-04-27 8:04 ` Lukasz Majewski
2018-04-27 12:20 ` Alex Kiernan
2018-04-30 8:37 ` Alex Kiernan
2018-05-01 6:16 ` Jocelyn Bohr
2018-04-25 7:40 ` Lukasz Majewski
2018-04-25 7:52 ` Lukasz Majewski
2018-04-25 7:57 ` Lukasz Majewski
2018-04-25 8:43 ` Alex Kiernan
2018-04-25 8:46 ` Alex Deymo
2018-04-27 19:10 ` Sam Protsenko
2018-04-27 19:23 ` Alex Kiernan
2018-04-30 8:56 ` Alex Deymo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180425171910.26a944a5@jawa \
--to=lukma@denx.de \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox