On Thu, May 14, 2020 at 08:21:57PM +0200, Daniel Glöckner wrote:
> From: Edmund Henniges <eh@xxxxxxxxx>
>
> This implements the UDP variant of the fastboot protocol. The only way to
> start the service for now is to compile with CONFIG_FASTBOOT_NET_ON_BOOT.
> The service will bind to the network interface that provides the IPv4
> gateway.
>
> Sending an OKAY packet before performing a restart is necessary since
> contrary to USB the host will not notice when a UDP server disappears.
>
> Signed-off-by: Edmund Henniges <eh@xxxxxxxxx>
> Signed-off-by: Daniel Glöckner <dg@xxxxxxxxx>
> ---
> common/fastboot.c | 3 +
> include/fastboot.h | 1 +
> include/fastboot_net.h | 12 +
> net/Kconfig | 18 ++
> net/Makefile | 1 +
> net/fastboot.c | 496 +++++++++++++++++++++++++++++++++++++++++
> 6 files changed, 531 insertions(+)
> create mode 100644 include/fastboot_net.h
> create mode 100644 net/fastboot.c
>
> diff --git a/common/fastboot.c b/common/fastboot.c
> index d50f61ff2..706547309 100644
> --- a/common/fastboot.c
> +++ b/common/fastboot.c
> +static int fastboot_write_net(struct fastboot *fb, const char *buf,
> + unsigned int n)
> +{
> + struct fastboot_net *fbn = container_of(fb, struct fastboot_net,
> + fastboot);
> + struct fastboot_header response_header;
> + uchar *packet;
> + uchar *packet_base;
> +
> + if (fbn->reinit)
> + return 0;
> +
> + while (fbn->may_send == MAY_NOT_SEND) {
> + poller_call();
> + if (fbn->reinit)
> + return 0;
> + }
This is a potentially endless loop I can reproducibly hit here. When I
do a "sleep 10" on the command line and at the same time start a
fastboot transfer then there's no progress. This is expected because
fastboot depends on the idle slice. However, when the "sleep 10" is over
then I get a prompt and then we are stuck in this loop.
I replaced this loop with a one second timeout loop. With this we are no
longer stuck in the loop, but the current transfer doesn't continue
anymore.
Afterwards I dropped everything around fbn->may_send completely and now
everything works fluently.
Removing these send restrictions seems the right thing to me. In the end
it's UDP, so the remote host shouldn't make any assumptions of how fast
and if at all packets arrive there.
Sascha
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
barebox mailing list
barebox@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/barebox
