[PATCH 06/14] fastboot: Change fastboot_buf_addr to an address

Simon Glass sjg at chromium.org
Wed Dec 6 04:54:19 CET 2023


Hi Mattijs,

On Tue, 5 Dec 2023 at 02:16, Mattijs Korpershoek
<mkorpershoek at baylibre.com> wrote:
>
> Hi Simon,
>
> Thank you for your patch.
>
> On dim., déc. 03, 2023 at 17:31, Simon Glass <sjg at chromium.org> wrote:
>
> > Given the name of this variable, it should be an address, not a
> > pointer. Update this, to make it easier to use with sandbox.
> >
> > Signed-off-by: Simon Glass <sjg at chromium.org>
>
> Tested that I could reflash AOSP on the Khadas VIM 3 board.
>
> Tested-by: Mattijs Korpershoek <mkorpershoek at baylibre.com> # on vim3
>
> Reviewed-by: Mattijs Korpershoek <mkorpershoek at baylibre.com>
>
> Some small nit/question below.
>
> > ---
> >
> >  cmd/fastboot.c                |  2 +-
> >  drivers/fastboot/fb_command.c | 13 ++++++++-----
> >  drivers/fastboot/fb_common.c  | 15 ++++-----------
> >  include/fastboot-internal.h   |  2 +-
> >  include/fastboot.h            |  6 +++---
> >  5 files changed, 17 insertions(+), 21 deletions(-)
> >
> > diff --git a/cmd/fastboot.c b/cmd/fastboot.c
> > index c3c19231c988..792e83d372c3 100644
> > --- a/cmd/fastboot.c
> > +++ b/cmd/fastboot.c
> > @@ -159,7 +159,7 @@ NXTARG:
> >               return CMD_RET_USAGE;
> >       }
> >
> > -     fastboot_init((void *)buf_addr, buf_size);
> > +     fastboot_init(buf_addr, buf_size);
> >
> >       if (!strcmp(argv[1], "udp"))
> >               return do_fastboot_udp(argc, argv, buf_addr, buf_size);
> > diff --git a/drivers/fastboot/fb_command.c b/drivers/fastboot/fb_command.c
> > index 5fcadcdf503d..ec030886dbb8 100644
> > --- a/drivers/fastboot/fb_command.c
> > +++ b/drivers/fastboot/fb_command.c
> > @@ -10,6 +10,7 @@
> >  #include <fastboot-internal.h>
> >  #include <fb_mmc.h>
> >  #include <fb_nand.h>
> > +#include <mapmem.h>
> >  #include <part.h>
> >  #include <stdlib.h>
> >  #include <linux/printk.h>
> > @@ -252,7 +253,7 @@ void fastboot_data_download(const void *fastboot_data,
> >               return;
> >       }
> >       /* Download data to fastboot_buf_addr */
> > -     memcpy(fastboot_buf_addr + fastboot_bytes_received,
> > +     memcpy(map_sysmem(fastboot_buf_addr, 0) + fastboot_bytes_received,
> >              fastboot_data, fastboot_data_len);
>
> I'm a little confused on why there is no call of unmap_sysmem() here but
> that seems to be the case for plenty other callers of map_sysmem().
>
> From what I've seen, in the sandbox unmap_sysmem() is a no-oop, but what
> about other architectures ?

Yes it is always a nop. It is designed such that address 0 can be used
as RAM in sandbox.

For PCI the mapping can in fact do something special, so that
memory-mapped peripherals can expose their registers. See
drivers/misc/swap_case.c for an example of that. But we have not ended
up with lots of tests.

>
> >
> >       pre_dot_num = fastboot_bytes_received / BYTES_PER_DOT;
> > @@ -296,13 +297,15 @@ void fastboot_data_complete(char *response)
> >   */
> >  static void __maybe_unused flash(char *cmd_parameter, char *response)
> >  {
> > +     void *buf = map_sysmem(fastboot_buf_addr, 0);
> > +
> >       if (IS_ENABLED(CONFIG_FASTBOOT_FLASH_MMC))
> > -             fastboot_mmc_flash_write(cmd_parameter, fastboot_buf_addr,
> > -                                      image_size, response);
> > +             fastboot_mmc_flash_write(cmd_parameter, buf, image_size,
> > +                                      response);
> >
> >       if (IS_ENABLED(CONFIG_FASTBOOT_FLASH_NAND))
> > -             fastboot_nand_flash_write(cmd_parameter, fastboot_buf_addr,
> > -                                       image_size, response);
> > +             fastboot_nand_flash_write(cmd_parameter, buf, image_size,
> > +                                       response);
>
> Same here.
>
> >  }
> >

[..]

Regards,
Simon


More information about the U-Boot mailing list