[U-Boot] [RFC PATCH v2 11/20] fastboot: net: Change 'continue' so it matches USB fastboot
Alex Kiernan
alex.kiernan at gmail.com
Tue May 8 09:20:25 UTC 2018
On Thu, May 3, 2018 at 9:58 PM Joe Hershberger <joe.hershberger at ni.com>
wrote:
> On Mon, Apr 30, 2018 at 3:32 AM, Alex Kiernan <alex.kiernan at gmail.com>
wrote:
> > Change the behaviour of 'continue' so that we simply exit the fastboot
> > server and leave the caller to decide what to do next. This matches
> > the USB fastboot behaviour.
> Good, I was considering recommending this approach.
> Acked-by: Joe Hershberger <joe.hershberger at ni.com>
> >
> > Signed-off-by: Alex Kiernan <alex.kiernan at gmail.com>
> > ---
> >
> > Changes in v2: None
> >
> > net/fastboot.c | 13 +++----------
> > 1 file changed, 3 insertions(+), 10 deletions(-)
> >
> > diff --git a/net/fastboot.c b/net/fastboot.c
> > index cd09ada..ed13890 100644
> > --- a/net/fastboot.c
> > +++ b/net/fastboot.c
> > @@ -218,8 +218,6 @@ static void fastboot_send(struct fastboot_header
fb_header, char *fastboot_data,
> > if (!strncmp("OKAY", response, 4)) {
> > if (!strcmp("boot", cmd_string)) {
> > boot_downloaded_image();
> > - } else if (!strcmp("continue", cmd_string)) {
> > - run_command(env_get("bootcmd"), CMD_FLAG_ENV);
> > } else if (!strncmp("reboot", cmd_string, 6)) {
> > /* Matches reboot or reboot-bootloader */
> > do_reset(NULL, 0, 0, NULL);
> > @@ -313,20 +311,15 @@ static void fb_erase(char *response)
> > #endif
> >
> > /**
> > - * Continues normal boot process by running "bootcmd". Writes
> > + * Continues normal boot process by exiting fastboot server. Writes
> > * to response.
> > *
> > * @param repsonse Pointer to fastboot response buffer
> > */
> > static void fb_continue(char *response)
> > {
> > - char *bootcmd;
> > -
> > - bootcmd = env_get("bootcmd");
> > - if (bootcmd)
> > - fastboot_okay(NULL, response);
> > - else
> > - fastboot_fail("bootcmd not set", response);
> > + net_set_state(NETLOOP_SUCCESS);
> > + fastboot_okay(NULL, response);
> > }
> >
I'm struggling with this returning the final ACK to the client correctly.
If I add something like mdelay(5) before exiting the server, then I get the
final ACK, without that, I never see it hit the network, even though I can
see it traversing all the layers of the net code if I wind up the debug
(and of course it makes it out if I wind up the debug, presumably as it
then goes much slower).
Wild hand wavey speculation... it's getting lost in something like a DMA
buffer in the network driver which gets torn down before it makes it onto
the wire? This is using the TI CPSW on an am335x.
--
Alex Kiernan
More information about the U-Boot
mailing list