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>
Reviewed-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Link: https://lore.kernel.org/r/20240418100129.1691822-2-avromanov@salutedevices.com
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Simon Glass <sjg@chromium.org> says:
This series is the culmanation of the current line of refactoring
series. It adjusts pxe to call the booting functionality directly
rather than going through the command-line interface.
With this is is possible to boot using the extlinux bootmeth without
the command line enabled.
It also updates fastboot to do a similar thing.
It is possible to boot a kernel without CMDLINE being enabled. Update
the implementation to handle this, and drop the condition from the
FASTBOOT config.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Much of the functionality of fastboot relies on being able to run
commands as defined in the environment. This means it does depend on
CMDLINE being enabled.
Signed-off-by: Tom Rini <trini@konsulko.com>
It is not a parse error to have a default value of "0" for a "hex" type
entry, instead of "0x0". However, "0" and "0x0" are not treated the
same even by the tools themselves. Correct this by changing the default
value from "0" to "0x0" for all hex type questions that had the
incorrect default. Fix one instance (in two configs) of a default of "0"
being used on a hex question to be "0x0". Remove the cases where a
defconfig had set a value of "0x0" to be used as the default had been
"0".
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Known limitations are
1. fastboot reboot doesn't work (answering OK but not rebooting)
2. flashing isn't supported (TCP transport only limitation)
The command syntax is
fastboot tcp
Signed-off-by: Dmitrii Merkurev <dimorinny@google.com>
Cc: Ying-Chun Liu (PaulLiu) <paul.liu@linaro.org>
Cc: Simon Glass <sjg@chromium.org>
Сс: Joe Hershberger <joe.hershberger@ni.com>
Сс: Ramon Fried <rfried.dev@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This adds the UUU UCmd functionality as an OEM command. While the
fastboot tool allows sending arbitrary commands as long as they are
prefixed with "oem". This allows running generic U-Boot commands over
fastboot without UUU, which is especially useful when not using USB.
This is really the route we should have gone in the first place when
adding these commands.
While we're here, clean up the UUU Kconfig a bit.
Signed-off-by: Sean Anderson <sean.anderson@seco.com>
Reviewed-by: Heiko Schocher <hs@denx.de>
The fastboot protocol uses per default the UDP port 5554. In some cases
it might be needed to change the used port. The fastboot utility provides
a way to specifiy an other port number to use already.
fastboot -s udp:192.168.1.76:1234 boot fastboot.img
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Reviewed-by: Heiko Schocher <hs@denx.de>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
default n/no doesn't need to be specified. It is default option anyway.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
[trini: Rework FSP_USE_UPD portion]
Signed-off-by: Tom Rini <trini@konsulko.com>
add support for the UUU commands ACmd and UCmd.
Enable them through the Kconfig option
CONFIG_FASTBOOT_UUU_SUPPORT
base was commit in NXP kernel
9b149c2a2882: ("MLK-18591-3 android: Add FSL android fastboot support")
and ported it to current mainline. Tested this patch
on imx6ul based board.
Signed-off-by: Heiko Schocher <hs@denx.de>
Acked-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Add command oem bootbus which executes the command
``mmc bootbus <id> <arg>`` on the current fastboot mmc device
(<i> = CONFIG_FASTBOOT_FLASH_MMC_DEV) to set the eMMC boot
configuration on first update, with
<arg> = boot_bus_width reset_boot_bus_width boot_mode
$> fastboot oem bootbus:<boot_bus_width> <reset_boot_bus_width> <boot_mode>
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Add fastboot command oem partconf which executes the command
``mmc partconf <id> <arg> 0`` on the current <id> mmc device
to configure the eMMC boot partition with
<arg>: boot_ack boot_partition, so the command is:
$> fastboot oem partconf:<boot_ack> <boot_partition>
The partition_access argument is forced to 0 (userdata)
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
[lukma - Kconfig adjustments after merging this patch]
Update the code and the configs for eMMC boot and userdata
partitions acces
- FASTBOOT_MMC_BOOT_SUPPORT: boot partition 1 and 2 (erase/write)
- FASTBOOT_MMC_BOOT1_NAME: boot partition 1, default name="mmc0boot0"
- FASTBOOT_MMC_BOOT2_NAME: boot partition 2, default name="mmc0boot1"
This patch also removes the unnecessary dependency with
ARCH_MEDIATEK and EFI_PARTITION.
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Split userdata and boot partition support for eMMC update
and correct the description (update is supported).
The new configuration CONFIG_FASTBOOT_MMC_USER_SUPPORT
allows to activate support of userdata partition update,
based on target name=CONFIG_FASTBOOT_MMC_USER_NAME
This patch also removes the unnecessary dependency with
ARCH_MEDIATEK and EFI_PARTITION.
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
This reverts commit 0ebf9842e5.
Current generic implementation of fastboot_set_reboot_flag is somewhat
messy and requires some additional configuration option to be enabled
besides CMD_BCB, so it reverts that implementtion in order to bring a
new cleaner one.
Next commit introduces new generic implementation of
fastboot_set_reboot_flag.
Signed-off-by: Roman Kovalivskyi <roman.kovalivskyi@globallogic.com>
Default implementation of fastboot_set_reboot_flag function that depends
on "bcb" commands could be used in general case if there are no need to
make any platform-specific implementation, otherwise it could be
disabled via Kconfig option FASTBOOT_USE_BCB_SET_REBOOT_FLAG.
Please note that FASTBOOT_USE_BCB_SET_REBOOT_FLAG is mutually exclusive
with some platforms which already have their own implementation of this
function.
Signed-off-by: Roman Kovalivskyi <roman.kovalivskyi@globallogic.com>
This patch includes the following:
1. Add fastboot command to erase the whole EMMC_USER
2. Add fastboot command to flash image at EMMC_BOOT1
3. Add fastboot command to erase the whole EMMC_BOOT1
4. Enale CONFIG_FASTBOOT_MMC_BOOT1_SUPPORT for mt8518
Signed-off-by: mingming lee <mingming.lee@mediatek.com>
Add more clarity by changing the Kconfig entry name.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
[trini: Re-run migration, update a few more cases]
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Boris Brezillon <boris.brezillon@bootlin.com>
Technically the default mmc device for fastboot would
use eMMC if the board support for it.
Rockchip platform access device 0 for eMMC so, use the
same device number for rk3328.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Select CONFIG_FASTBOOT_FLASH, CONFIG_FASTBOOT_FLASH_MMC_DEV
for rockchip SoC plaforms in fastboot Kconfig file instead
of defined it in board defconfig.
This eventually drop the explicit configs defined in
supporting board defconfig files.
Tested-by: Levin Du <djw@t-chip.com.cn>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Enables cmd_avb and its dependencies need to run the AVB tests.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
[trini: Disable for sandbox_noblk]
Signed-off-by: Tom Rini <trini@konsulko.com>
Introduce 'oem format' which matches the USB implementation, guard this
with CONFIG_FASTBOOT_CMD_OEM_FORMAT so that you can configure it out.
Signed-off-by: Alex Kiernan <alex.kiernan@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Introduce CONFIG_IMAGE_SPARSE and CONFIG_CMD_MMC_SWRITE so the "mmc
swrite" command is separated from the fastboot code.
Move image-sparse from common to lib so it's clear it's library code.
Rename CONFIG_FASTBOOT_FLASH_FILLBUF_SIZE to CONFIG_IMAGE_SPARSE_FILLBUF_SIZE
and migrate it to Kconfig.
Signed-off-by: Alex Kiernan <alex.kiernan@gmail.com>
Acked-by: Jassi Brar <jaswinder.singh@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add FASTBOOT_FLASH_NAND_TRIMFFS to Kconfig; note there are no in-tree
users of it.
Signed-off-by: Alex Kiernan <alex.kiernan@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Ensure that when selecting FASTBOOT_FLASH you end up with a buildable
configuration. Prior to this you could select NAND without MTDPARTS
and end up with an image which (surprisingly) excluded NAND.
Also fix dependencies on FASTBOOT_GPT_NAME/FASTBOOT_MBR_NAME which require
you have EFI_PARTITION/DOS_PARTITION enabled.
Delete redundant FASTBOOT_FLASH_NAND_DEV from Kconfig - it was only ever
used as a guard and the value was ignored in all cases, we're using
FASTBOOT_FLASH_NAND as the guard now.
Signed-off-by: Alex Kiernan <alex.kiernan@gmail.com>
Reviewed-by: Joe Hershberger <joe.hershberger@ni.com>
Separate CMD_FASTBOOT from FASTBOOT and move code and configuration to
drivers/fastboot.
Switch dependencies on FASTBOOT to USB_FUNCTION_FASTBOOT as anyone who wants
FASTBOOT before this series wants USB_FUNCTION_FASTBOOT. Split
USB_FUNCTION_FASTBOOT from FASTBOOT so they retain their existing
behaviour.
Signed-off-by: Alex Kiernan <alex.kiernan@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>
