* [PATCH v4 0/1] Introduce fastboot oem board command
@ 2024-04-10 10:58 Alexey Romanov
2024-04-10 10:58 ` [PATCH v4 1/1] fastboot: introduce 'oem board' subcommand Alexey Romanov
0 siblings, 1 reply; 6+ messages in thread
From: Alexey Romanov @ 2024-04-10 10:58 UTC (permalink / raw)
To: sjg, hs, sean.anderson, dimorinny, mkorpershoek, patrick.delaunay,
quentin.schulz
Cc: kernel, u-boot, Alexey Romanov
Changes V1 -> V2 [1]:
- Added an example of using the command as requested
by Sean Anderson [2].
Changes V2 -> V3 [3]:
- Rebase over uboot/master.
- Add documentation.
- Remove example added in V2 [1].
Changes V3 -> V4 [4]:
- Corrected documentation accroding to Quentin Schulz comments [5].
Links:
[1] https://lore.kernel.org/all/20231228152522.83291-1-avromanov@salutedevices.com/
[2] https://lore.kernel.org/all/72ac233d-c18d-4f57-bc66-451fe0bd2997@seco.com/
[3] https://lore.kernel.org/all/20240201092027.6258-1-avromanov@salutedevices.com/
[4] https://lore.kernel.org/all/20240408101552.539037-1-avromanov@salutedevices.com/
[5] https://lore.kernel.org/all/9efdf140-8da3-4b5e-b1c4-2f106067afd3@theobroma-systems.com/
Alexey Romanov (1):
fastboot: introduce 'oem board' subcommand
doc/android/fastboot.rst | 18 ++++++++++++++++++
drivers/fastboot/Kconfig | 7 +++++++
drivers/fastboot/fb_command.c | 30 ++++++++++++++++++++++++++++++
include/fastboot.h | 1 +
4 files changed, 56 insertions(+)
--
2.34.1
^ permalink raw reply [flat|nested] 6+ messages in thread* [PATCH v4 1/1] fastboot: introduce 'oem board' subcommand 2024-04-10 10:58 [PATCH v4 0/1] Introduce fastboot oem board command Alexey Romanov @ 2024-04-10 10:58 ` Alexey Romanov 2024-04-10 12:02 ` Quentin Schulz 2024-04-18 9:06 ` Mattijs Korpershoek 0 siblings, 2 replies; 6+ messages in thread From: Alexey Romanov @ 2024-04-10 10:58 UTC (permalink / raw) To: sjg, hs, sean.anderson, dimorinny, mkorpershoek, patrick.delaunay, quentin.schulz Cc: kernel, u-boot, Alexey Romanov Currently, fastboot protocol in U-Boot has no opportunity to execute vendor custom code with verifed boot. This patch introduce new fastboot subcommand fastboot oem board:<cmd>, which allow to run custom oem_board function. Default implementation is __weak. Vendor must redefine it in board/ folder with his own logic. For example, some vendors have their custom nand/emmc partition flashing or erasing. Here some typical command for such use cases: - flashing: $ fastboot stage bootloader.img $ fastboot oem board:write_bootloader - erasing: $ fastboot oem board:erase_env Signed-off-by: Alexey Romanov <avromanov@salutedevices.com> Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com> --- doc/android/fastboot.rst | 18 ++++++++++++++++++ drivers/fastboot/Kconfig | 7 +++++++ drivers/fastboot/fb_command.c | 30 ++++++++++++++++++++++++++++++ include/fastboot.h | 1 + 4 files changed, 56 insertions(+) diff --git a/doc/android/fastboot.rst b/doc/android/fastboot.rst index 1ad8a897c8..2a627f9890 100644 --- a/doc/android/fastboot.rst +++ b/doc/android/fastboot.rst @@ -29,6 +29,7 @@ The following OEM commands are supported (if enabled): with <arg> = boot_ack boot_partition - ``oem bootbus`` - this executes ``mmc bootbus %x %s`` to configure eMMC - ``oem run`` - this executes an arbitrary U-Boot command +- ``oem board`` - this executes a custom board function which is defined by the vendor Support for both eMMC and NAND devices is included. @@ -245,6 +246,23 @@ including multiple commands (using e.g. ``;`` or ``&&``) and control structures (``if``, ``while``, etc.). The exit code of ``fastboot`` will reflect the exit code of the command you ran. +Running Custom Vendor Code +^^^^^^^^^^^^^^^^^^^^^^^^^^ + +U-Boot allows you to execute custom fastboot logic, which can be defined +in board/ files. It can still be used for production devices with verified +boot, because the vendor define logic at compile time by implementing +fastboot_oem_board() function. The attacker will not be able to execute +custom commands / code. For example, this can be useful for custom flashing +or erasing protocols:: + + $ fastboot stage bootloader.img + $ fastboot oem board:write_bootloader + +In this case, ``cmd_parameter`` argument of the function ``fastboot_oem_board()`` +will contain string "write_bootloader" and ``data`` argument is a pointer to +fastboot input buffer, which contains the contents of bootloader.img file. + References ---------- diff --git a/drivers/fastboot/Kconfig b/drivers/fastboot/Kconfig index a4313d60a9..4d94391a76 100644 --- a/drivers/fastboot/Kconfig +++ b/drivers/fastboot/Kconfig @@ -241,6 +241,13 @@ config FASTBOOT_OEM_RUN this feature if you are using verified boot, as it will allow an attacker to bypass any restrictions you have in place. +config FASTBOOT_OEM_BOARD + bool "Enable the 'oem board' command" + help + This extends the fastboot protocol with an "oem board" command. This + command allows running vendor custom code defined in board/ files. + Otherwise, it will do nothing and send fastboot fail. + endif # FASTBOOT endmenu diff --git a/drivers/fastboot/fb_command.c b/drivers/fastboot/fb_command.c index 5fcadcdf50..da29211db1 100644 --- a/drivers/fastboot/fb_command.c +++ b/drivers/fastboot/fb_command.c @@ -40,6 +40,7 @@ static void reboot_recovery(char *, char *); static void oem_format(char *, char *); static void oem_partconf(char *, char *); static void oem_bootbus(char *, char *); +static void oem_board(char *, char *); static void run_ucmd(char *, char *); static void run_acmd(char *, char *); @@ -107,6 +108,10 @@ static const struct { .command = "oem run", .dispatch = CONFIG_IS_ENABLED(FASTBOOT_OEM_RUN, (run_ucmd), (NULL)) }, + [FASTBOOT_COMMAND_OEM_BOARD] = { + .command = "oem board", + .dispatch = CONFIG_IS_ENABLED(FASTBOOT_OEM_BOARD, (oem_board), (NULL)) + }, [FASTBOOT_COMMAND_UCMD] = { .command = "UCmd", .dispatch = CONFIG_IS_ENABLED(FASTBOOT_UUU_SUPPORT, (run_ucmd), (NULL)) @@ -490,3 +495,28 @@ static void __maybe_unused oem_bootbus(char *cmd_parameter, char *response) else fastboot_okay(NULL, response); } + +/** + * fastboot_oem_board() - Execute the OEM board command. This is default + * weak implementation, which may be overwritten in board/ files. + * + * @cmd_parameter: Pointer to command parameter + * @data: Pointer to fastboot input buffer + * @size: Size of the fastboot input buffer + * @response: Pointer to fastboot response buffer + */ +void __weak fastboot_oem_board(char *cmd_parameter, void *data, u32 size, char *response) +{ + fastboot_fail("oem board function not defined", response); +} + +/** + * oem_board() - Execute the OEM board command + * + * @cmd_parameter: Pointer to command parameter + * @response: Pointer to fastboot response buffer + */ +static void __maybe_unused oem_board(char *cmd_parameter, char *response) +{ + fastboot_oem_board(cmd_parameter, fastboot_buf_addr, image_size, response); +} diff --git a/include/fastboot.h b/include/fastboot.h index 296451f89d..06c1f26b6c 100644 --- a/include/fastboot.h +++ b/include/fastboot.h @@ -37,6 +37,7 @@ enum { FASTBOOT_COMMAND_OEM_PARTCONF, FASTBOOT_COMMAND_OEM_BOOTBUS, FASTBOOT_COMMAND_OEM_RUN, + FASTBOOT_COMMAND_OEM_BOARD, FASTBOOT_COMMAND_ACMD, FASTBOOT_COMMAND_UCMD, FASTBOOT_COMMAND_COUNT -- 2.34.1 ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH v4 1/1] fastboot: introduce 'oem board' subcommand 2024-04-10 10:58 ` [PATCH v4 1/1] fastboot: introduce 'oem board' subcommand Alexey Romanov @ 2024-04-10 12:02 ` Quentin Schulz 2024-04-10 12:43 ` Alexey Romanov 2024-04-18 9:06 ` Mattijs Korpershoek 1 sibling, 1 reply; 6+ messages in thread From: Quentin Schulz @ 2024-04-10 12:02 UTC (permalink / raw) To: Alexey Romanov, sjg, hs, sean.anderson, dimorinny, mkorpershoek, patrick.delaunay Cc: kernel, u-boot Hi Alexey, On 4/10/24 12:58, Alexey Romanov wrote: > Currently, fastboot protocol in U-Boot has no opportunity > to execute vendor custom code with verifed boot. This patch > introduce new fastboot subcommand fastboot oem board:<cmd>, > which allow to run custom oem_board function. > > Default implementation is __weak. Vendor must redefine it in > board/ folder with his own logic. > > For example, some vendors have their custom nand/emmc partition > flashing or erasing. Here some typical command for such use cases: > > - flashing: > > $ fastboot stage bootloader.img > $ fastboot oem board:write_bootloader > > - erasing: > > $ fastboot oem board:erase_env > > Signed-off-by: Alexey Romanov <avromanov@salutedevices.com> > Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com> > --- > doc/android/fastboot.rst | 18 ++++++++++++++++++ > drivers/fastboot/Kconfig | 7 +++++++ > drivers/fastboot/fb_command.c | 30 ++++++++++++++++++++++++++++++ > include/fastboot.h | 1 + > 4 files changed, 56 insertions(+) > > diff --git a/doc/android/fastboot.rst b/doc/android/fastboot.rst > index 1ad8a897c8..2a627f9890 100644 > --- a/doc/android/fastboot.rst > +++ b/doc/android/fastboot.rst > @@ -29,6 +29,7 @@ The following OEM commands are supported (if enabled): > with <arg> = boot_ack boot_partition > - ``oem bootbus`` - this executes ``mmc bootbus %x %s`` to configure eMMC > - ``oem run`` - this executes an arbitrary U-Boot command > +- ``oem board`` - this executes a custom board function which is defined by the vendor > > Support for both eMMC and NAND devices is included. > > @@ -245,6 +246,23 @@ including multiple commands (using e.g. ``;`` or ``&&``) and control structures > (``if``, ``while``, etc.). The exit code of ``fastboot`` will reflect the exit > code of the command you ran. > > +Running Custom Vendor Code > +^^^^^^^^^^^^^^^^^^^^^^^^^^ > + > +U-Boot allows you to execute custom fastboot logic, which can be defined > +in board/ files. It can still be used for production devices with verified > +boot, because the vendor define logic at compile time by implementing I think it should be "defines" here? Reviewed-by: Quentin Schulz <quentin.schulz@theobroma-systems.com> Thanks, Quentin ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v4 1/1] fastboot: introduce 'oem board' subcommand 2024-04-10 12:02 ` Quentin Schulz @ 2024-04-10 12:43 ` Alexey Romanov 2024-04-10 12:56 ` Mattijs Korpershoek 0 siblings, 1 reply; 6+ messages in thread From: Alexey Romanov @ 2024-04-10 12:43 UTC (permalink / raw) To: Quentin Schulz, mkorpershoek@baylibre.com Cc: sjg@chromium.org, hs@denx.de, sean.anderson@seco.com, dimorinny@google.com, patrick.delaunay@foss.st.com, kernel, u-boot@lists.denx.de Hi guys, On Wed, Apr 10, 2024 at 02:02:21PM +0200, Quentin Schulz wrote: > Hi Alexey, > > On 4/10/24 12:58, Alexey Romanov wrote: > > Currently, fastboot protocol in U-Boot has no opportunity > > to execute vendor custom code with verifed boot. This patch > > introduce new fastboot subcommand fastboot oem board:<cmd>, > > which allow to run custom oem_board function. > > > > Default implementation is __weak. Vendor must redefine it in > > board/ folder with his own logic. > > > > For example, some vendors have their custom nand/emmc partition > > flashing or erasing. Here some typical command for such use cases: > > > > - flashing: > > > > $ fastboot stage bootloader.img > > $ fastboot oem board:write_bootloader > > > > - erasing: > > > > $ fastboot oem board:erase_env > > > > Signed-off-by: Alexey Romanov <avromanov@salutedevices.com> > > Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com> > > --- > > doc/android/fastboot.rst | 18 ++++++++++++++++++ > > drivers/fastboot/Kconfig | 7 +++++++ > > drivers/fastboot/fb_command.c | 30 ++++++++++++++++++++++++++++++ > > include/fastboot.h | 1 + > > 4 files changed, 56 insertions(+) > > > > diff --git a/doc/android/fastboot.rst b/doc/android/fastboot.rst > > index 1ad8a897c8..2a627f9890 100644 > > --- a/doc/android/fastboot.rst > > +++ b/doc/android/fastboot.rst > > @@ -29,6 +29,7 @@ The following OEM commands are supported (if enabled): > > with <arg> = boot_ack boot_partition > > - ``oem bootbus`` - this executes ``mmc bootbus %x %s`` to configure eMMC > > - ``oem run`` - this executes an arbitrary U-Boot command > > +- ``oem board`` - this executes a custom board function which is defined by the vendor > > Support for both eMMC and NAND devices is included. > > @@ -245,6 +246,23 @@ including multiple commands (using e.g. ``;`` or ``&&``) and control structures > > (``if``, ``while``, etc.). The exit code of ``fastboot`` will reflect the exit > > code of the command you ran. > > +Running Custom Vendor Code > > +^^^^^^^^^^^^^^^^^^^^^^^^^^ > > + > > +U-Boot allows you to execute custom fastboot logic, which can be defined > > +in board/ files. It can still be used for production devices with verified > > +boot, because the vendor define logic at compile time by implementing > > I think it should be "defines" here? Yep. If there are no more comments, maybe Mattijs will correct this when he picks up a patch? So that I don't send a new series with typo fix :) > > Reviewed-by: Quentin Schulz <quentin.schulz@theobroma-systems.com> > > Thanks, > Quentin -- Thank you, Alexey ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v4 1/1] fastboot: introduce 'oem board' subcommand 2024-04-10 12:43 ` Alexey Romanov @ 2024-04-10 12:56 ` Mattijs Korpershoek 0 siblings, 0 replies; 6+ messages in thread From: Mattijs Korpershoek @ 2024-04-10 12:56 UTC (permalink / raw) To: Alexey Romanov, Quentin Schulz Cc: sjg@chromium.org, hs@denx.de, sean.anderson@seco.com, dimorinny@google.com, patrick.delaunay@foss.st.com, kernel, u-boot@lists.denx.de Hi Alexey, On mer., avril 10, 2024 at 12:43, Alexey Romanov <avromanov@salutedevices.com> wrote: > Hi guys, > > On Wed, Apr 10, 2024 at 02:02:21PM +0200, Quentin Schulz wrote: >> Hi Alexey, >> >> On 4/10/24 12:58, Alexey Romanov wrote: >> > Currently, fastboot protocol in U-Boot has no opportunity >> > to execute vendor custom code with verifed boot. This patch >> > introduce new fastboot subcommand fastboot oem board:<cmd>, >> > which allow to run custom oem_board function. >> > >> > Default implementation is __weak. Vendor must redefine it in >> > board/ folder with his own logic. >> > >> > For example, some vendors have their custom nand/emmc partition >> > flashing or erasing. Here some typical command for such use cases: >> > >> > - flashing: >> > >> > $ fastboot stage bootloader.img >> > $ fastboot oem board:write_bootloader >> > >> > - erasing: >> > >> > $ fastboot oem board:erase_env >> > >> > Signed-off-by: Alexey Romanov <avromanov@salutedevices.com> >> > Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com> >> > --- >> > doc/android/fastboot.rst | 18 ++++++++++++++++++ >> > drivers/fastboot/Kconfig | 7 +++++++ >> > drivers/fastboot/fb_command.c | 30 ++++++++++++++++++++++++++++++ >> > include/fastboot.h | 1 + >> > 4 files changed, 56 insertions(+) >> > >> > diff --git a/doc/android/fastboot.rst b/doc/android/fastboot.rst >> > index 1ad8a897c8..2a627f9890 100644 >> > --- a/doc/android/fastboot.rst >> > +++ b/doc/android/fastboot.rst >> > @@ -29,6 +29,7 @@ The following OEM commands are supported (if enabled): >> > with <arg> = boot_ack boot_partition >> > - ``oem bootbus`` - this executes ``mmc bootbus %x %s`` to configure eMMC >> > - ``oem run`` - this executes an arbitrary U-Boot command >> > +- ``oem board`` - this executes a custom board function which is defined by the vendor >> > Support for both eMMC and NAND devices is included. >> > @@ -245,6 +246,23 @@ including multiple commands (using e.g. ``;`` or ``&&``) and control structures >> > (``if``, ``while``, etc.). The exit code of ``fastboot`` will reflect the exit >> > code of the command you ran. >> > +Running Custom Vendor Code >> > +^^^^^^^^^^^^^^^^^^^^^^^^^^ >> > + >> > +U-Boot allows you to execute custom fastboot logic, which can be defined >> > +in board/ files. It can still be used for production devices with verified >> > +boot, because the vendor define logic at compile time by implementing >> >> I think it should be "defines" here? > > Yep. If there are no more comments, maybe Mattijs will correct this when > he picks up a patch? So that I don't send a new series with typo fix :) Yes, if there are no other review comments, I will fix this up locally when picking this up. > >> >> Reviewed-by: Quentin Schulz <quentin.schulz@theobroma-systems.com> >> >> Thanks, >> Quentin > > -- > Thank you, > Alexey ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v4 1/1] fastboot: introduce 'oem board' subcommand 2024-04-10 10:58 ` [PATCH v4 1/1] fastboot: introduce 'oem board' subcommand Alexey Romanov 2024-04-10 12:02 ` Quentin Schulz @ 2024-04-18 9:06 ` Mattijs Korpershoek 1 sibling, 0 replies; 6+ messages in thread From: Mattijs Korpershoek @ 2024-04-18 9:06 UTC (permalink / raw) To: Alexey Romanov, sjg, hs, sean.anderson, dimorinny, patrick.delaunay, quentin.schulz Cc: kernel, u-boot, Alexey Romanov Hi Alexey, On mer., avril 10, 2024 at 13:58, Alexey Romanov <avromanov@salutedevices.com> wrote: > Currently, fastboot protocol in U-Boot has no opportunity > to execute vendor custom code with verifed boot. This patch > introduce new fastboot subcommand fastboot oem board:<cmd>, > which allow to run custom oem_board function. > > Default implementation is __weak. Vendor must redefine it in > board/ folder with his own logic. > > For example, some vendors have their custom nand/emmc partition > flashing or erasing. Here some typical command for such use cases: > > - flashing: > > $ fastboot stage bootloader.img > $ fastboot oem board:write_bootloader > > - erasing: > > $ fastboot oem board:erase_env > > Signed-off-by: Alexey Romanov <avromanov@salutedevices.com> > Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com> After applying this patch on master, it seems that the CI broke: Building current source for 1 boards (1 thread, 64 jobs per thread) sandbox: + sandbox64 +drivers/fastboot/fb_command.c: In function ‘oem_board’: +drivers/fastboot/fb_command.c:580:43: error: passing argument 2 of ‘fastboot_oem_board’ makes pointer from integer without a cast [-Werror=int-conversion] + 580 | fastboot_oem_board(cmd_parameter, fastboot_buf_addr, image_size, response); + | ^~~~~~~~~~~~~~~~~ + | | + | ulong {aka long unsigned int} +drivers/fastboot/fb_command.c:567:59: note: expected ‘void *’ but argument is of type ‘ulong’ {aka ‘long unsigned int’} + 567 | void __weak fastboot_oem_board(char *cmd_parameter, void *data, u32 size, char *response) + | ~~~~~~^~~~ +cc1: all warnings being treated as errors +make[3]: *** [scripts/Makefile.build:256: drivers/fastboot/fb_command.o] Error 1 +make[2]: *** [scripts/Makefile.build:397: drivers/fastboot] Error 2 +make[1]: *** [Makefile:1892: drivers] Error 2 +make: *** [Makefile:177: sub-make] Error 2 0 0 1 /1 sandbox64 Completed: 1 total built, 1 newly), duration 0:00:08, rate 0.12 See: https://source.denx.de/u-boot/custodians/u-boot-dfu/-/pipelines/20398 Could you please have a look? If you fix it, can you please send another version on top of master? I will drop v4 and apply v5. Thanks ! > --- > doc/android/fastboot.rst | 18 ++++++++++++++++++ > drivers/fastboot/Kconfig | 7 +++++++ > drivers/fastboot/fb_command.c | 30 ++++++++++++++++++++++++++++++ > include/fastboot.h | 1 + > 4 files changed, 56 insertions(+) > > diff --git a/doc/android/fastboot.rst b/doc/android/fastboot.rst > index 1ad8a897c8..2a627f9890 100644 > --- a/doc/android/fastboot.rst > +++ b/doc/android/fastboot.rst > @@ -29,6 +29,7 @@ The following OEM commands are supported (if enabled): > with <arg> = boot_ack boot_partition > - ``oem bootbus`` - this executes ``mmc bootbus %x %s`` to configure eMMC > - ``oem run`` - this executes an arbitrary U-Boot command > +- ``oem board`` - this executes a custom board function which is defined by the vendor > > Support for both eMMC and NAND devices is included. > > @@ -245,6 +246,23 @@ including multiple commands (using e.g. ``;`` or ``&&``) and control structures > (``if``, ``while``, etc.). The exit code of ``fastboot`` will reflect the exit > code of the command you ran. > > +Running Custom Vendor Code > +^^^^^^^^^^^^^^^^^^^^^^^^^^ > + > +U-Boot allows you to execute custom fastboot logic, which can be defined > +in board/ files. It can still be used for production devices with verified > +boot, because the vendor define logic at compile time by implementing > +fastboot_oem_board() function. The attacker will not be able to execute > +custom commands / code. For example, this can be useful for custom flashing > +or erasing protocols:: > + > + $ fastboot stage bootloader.img > + $ fastboot oem board:write_bootloader > + > +In this case, ``cmd_parameter`` argument of the function ``fastboot_oem_board()`` > +will contain string "write_bootloader" and ``data`` argument is a pointer to > +fastboot input buffer, which contains the contents of bootloader.img file. > + > References > ---------- > > diff --git a/drivers/fastboot/Kconfig b/drivers/fastboot/Kconfig > index a4313d60a9..4d94391a76 100644 > --- a/drivers/fastboot/Kconfig > +++ b/drivers/fastboot/Kconfig > @@ -241,6 +241,13 @@ config FASTBOOT_OEM_RUN > this feature if you are using verified boot, as it will allow an > attacker to bypass any restrictions you have in place. > > +config FASTBOOT_OEM_BOARD > + bool "Enable the 'oem board' command" > + help > + This extends the fastboot protocol with an "oem board" command. This > + command allows running vendor custom code defined in board/ files. > + Otherwise, it will do nothing and send fastboot fail. > + > endif # FASTBOOT > > endmenu > diff --git a/drivers/fastboot/fb_command.c b/drivers/fastboot/fb_command.c > index 5fcadcdf50..da29211db1 100644 > --- a/drivers/fastboot/fb_command.c > +++ b/drivers/fastboot/fb_command.c > @@ -40,6 +40,7 @@ static void reboot_recovery(char *, char *); > static void oem_format(char *, char *); > static void oem_partconf(char *, char *); > static void oem_bootbus(char *, char *); > +static void oem_board(char *, char *); > static void run_ucmd(char *, char *); > static void run_acmd(char *, char *); > > @@ -107,6 +108,10 @@ static const struct { > .command = "oem run", > .dispatch = CONFIG_IS_ENABLED(FASTBOOT_OEM_RUN, (run_ucmd), (NULL)) > }, > + [FASTBOOT_COMMAND_OEM_BOARD] = { > + .command = "oem board", > + .dispatch = CONFIG_IS_ENABLED(FASTBOOT_OEM_BOARD, (oem_board), (NULL)) > + }, > [FASTBOOT_COMMAND_UCMD] = { > .command = "UCmd", > .dispatch = CONFIG_IS_ENABLED(FASTBOOT_UUU_SUPPORT, (run_ucmd), (NULL)) > @@ -490,3 +495,28 @@ static void __maybe_unused oem_bootbus(char *cmd_parameter, char *response) > else > fastboot_okay(NULL, response); > } > + > +/** > + * fastboot_oem_board() - Execute the OEM board command. This is default > + * weak implementation, which may be overwritten in board/ files. > + * > + * @cmd_parameter: Pointer to command parameter > + * @data: Pointer to fastboot input buffer > + * @size: Size of the fastboot input buffer > + * @response: Pointer to fastboot response buffer > + */ > +void __weak fastboot_oem_board(char *cmd_parameter, void *data, u32 size, char *response) > +{ > + fastboot_fail("oem board function not defined", response); > +} > + > +/** > + * oem_board() - Execute the OEM board command > + * > + * @cmd_parameter: Pointer to command parameter > + * @response: Pointer to fastboot response buffer > + */ > +static void __maybe_unused oem_board(char *cmd_parameter, char *response) > +{ > + fastboot_oem_board(cmd_parameter, fastboot_buf_addr, image_size, response); > +} > diff --git a/include/fastboot.h b/include/fastboot.h > index 296451f89d..06c1f26b6c 100644 > --- a/include/fastboot.h > +++ b/include/fastboot.h > @@ -37,6 +37,7 @@ enum { > FASTBOOT_COMMAND_OEM_PARTCONF, > FASTBOOT_COMMAND_OEM_BOOTBUS, > FASTBOOT_COMMAND_OEM_RUN, > + FASTBOOT_COMMAND_OEM_BOARD, > FASTBOOT_COMMAND_ACMD, > FASTBOOT_COMMAND_UCMD, > FASTBOOT_COMMAND_COUNT > -- > 2.34.1 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2024-04-18 9:06 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2024-04-10 10:58 [PATCH v4 0/1] Introduce fastboot oem board command Alexey Romanov 2024-04-10 10:58 ` [PATCH v4 1/1] fastboot: introduce 'oem board' subcommand Alexey Romanov 2024-04-10 12:02 ` Quentin Schulz 2024-04-10 12:43 ` Alexey Romanov 2024-04-10 12:56 ` Mattijs Korpershoek 2024-04-18 9:06 ` Mattijs Korpershoek
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox