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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.