* [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