summaryrefslogtreecommitdiff
path: root/boot
Commit message (Collapse)AuthorAgeFilesLines
* net: dhcp6: pxe: Add DHCP/PXE commands for IPv6Sean Edmond2023-05-053-4/+5
| | | | | | | | | | | | | | | | | | Adds commands to support DHCP and PXE with IPv6. New configs added: - CMD_DHCP6 - DHCP6_PXE_CLIENTARCH - DHCP6_PXE_DHCP_OPTION - DHCP6_ENTERPRISE_ID New commands added (when IPv6 is enabled): - dhcp6 - pxe get -ipv6 - pxe boot -ipv6 Signed-off-by: Sean Edmond <seanedmond@microsoft.com> Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
* boot/Kconfig: fix comments syntax errorHugo Villeneuve2023-05-031-1/+1
| | | | | | | Fix comments syntax error in SPL_LOAD_FIT_APPLY_OVERLAY description. Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* boot: vbe_simple: Fix vbe_simple_read_bootflow() dependencyBin Meng2023-04-281-5/+7
| | | | | | | | | vbe_simple_read_bootflow() calls vbe_simple_read_bootflow_fw() which is only available when BOOTMETH_VBE_SIMPLE_FW is on. Signed-off-by: Bin Meng <bmeng@tinylab.org> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* bootstd: Use blk uclass device numbers to set efi bootdevMathew McBride2023-04-261-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When loading a file from a block device, efiload_read_file was using the seq_num of the device (e.g "35" of virtio_blk#35) instead of the block device id (e.g what you get from running the corresponding device scan command, like "virtio 0") This cause EFI booting from these devices to fail as an invalid device number is passed to blk_get_device_part_str: Scanning bootdev 'virtio-blk#35.bootdev': distro_efi_read_bootflow_file start (efi,fname=<NULL>) distro_efi_read_bootflow_file start (efi,fname=<NULL>) setting bootdev virtio, 35, efi/boot/bootaa64.efi, 00000000beef9a40, 170800 efi_dp_from_name calling blk_get_device_part_str dev=virtio devnr=35 path=efi/boot/bootaa64.efi blk_get_device_part_str (virtio,35) blk_get_device_by_str (virtio, 35) ** Bad device specification virtio 35 ** Using default device tree: dtb/qemu-arm.dtb No device tree available 0 efi ready virtio 1 virtio-blk#35.bootdev.par efi/boot/bootaa64.efi ** Booting bootflow 'virtio-blk#35.bootdev.part_1' with efi blk_get_device_part_str (virtio,0:1) blk_get_device_by_str (virtio, 0) No UEFI binary known at beef9a40 (image buf=00000000beef9a40,addr=0000000000000000) Boot failed (err=-22) Signed-off-by: Mathew McBride <matt@traverse.com.au> Signed-off-by: Simon Glass <sjg@chromium.org>
* bootstd: Adjust code ordering to work around compiler quirkSimon Glass2023-04-261-2/+3
| | | | | | | | | | | At present when debugging is off, bootdev_find_in_blk() sometimes fails to find a valid bootflow, e.g. with virtio. Accessing the 'blk' variable later in the function seems to correct it. Move the 'ret' check before the debug statement and set the block device again aftewards, to work around this. Signed-off-by: Simon Glass <sjg@chromium.org>
* bootstd: Report missing labels only when askedSimon Glass2023-04-261-7/+25
| | | | | | | | | | | | | | | | | | Use the -l flag to indicate whether to report missing uclasses. Also try to be more helpful when no devices are found. For example, when we see something 'scsi0' requested and nothing was found, this indicates that there are no SCSI devices, so show a suitable message. Move messages out of the low-level functions so that silent operation is possible. This means they are never reported unless BOOTSTD_FULL is enabled, since the -l flag cannot otherwise be set. Suggested-by: Tom Rini <trini@konsulko.com> Signed-off-by: Simon Glass <sjg@chromium.org>
* bootstd: Support booting EFI where multiple options existSimon Glass2023-04-261-7/+19
| | | | | | | | | | | | | | | | The current EFI implementation has a strange quirk where it watches loaded files and uses the last-loaded file to determine the device that is being booted from. This is confusing with bootstd, where multiple options may exist. Even loading a device tree will cause it to go wrong. There is no API for passing this information, since the only entry into booting an EFI image is the 'bootefi' command. To work around this, call efi_set_bootdev() for EFI images, if possible, just before booting. Signed-off-by: Simon Glass <sjg@chromium.org>
* bootstd: Tweak bootflow logic for device treeSimon Glass2023-04-261-11/+11
| | | | | | | | | | We should only store the FDT filename if we were able to determine one. Adjust the logic for this. This corrects the case where no FDT is needed to boot, such as with EFI using ACPI. Signed-off-by: Simon Glass <sjg@chromium.org>
* boot/image-board.c: Silence warning in select_ramdiskTom Rini2023-04-251-1/+1
| | | | | | | | | When building with clang we get a warning that rdaddr could be uninitialized in one case. While this cannot functionally happen, we can easily silence the warning. Signed-off-by: Tom Rini <trini@konsulko.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* image: Fix script execution from FIT images with external dataTobias Waldekranz2023-04-051-1/+2
| | | | | | | | Update the script loading code to recognize when script data is stored externally from the FIT metadata (i.e., built with `mkimage -E`). Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* android: boot: support bootconfigSafae Ouajih2023-04-041-2/+56
| | | | | | | | | | | | | | | | Support Bootconfig feature. - The bootconfig feature replaces the androidboot.* kernel cmdline options. This was adapted from downstream [1] commit : 7af0a0506d4d ("cuttlefish: support bootconfig parameters"). Link:[1] https://android.googlesource.com/platform/external/u-boot/ Signed-off-by: Safae Ouajih <souajih@baylibre.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com> Tested-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
* android: boot: support boot image header version 3 and 4Safae Ouajih2023-04-044-15/+58
| | | | | | | | | | | | | | | | | | | | | Enable the support for boot image header version 3 and 4 using abootimg command. In order to use version 3 or 4: 1- Vendor boot image address should be given to abootimg cmd. abootimg addr $1 $vendor_boot_load_addr 2- "ramdisk_addr_r" env variable (ramdisk address) should be set to host the ramdisk : generic ramdisk + vendor ramdisk Replace "struct andr_boot_img_hdr_v0*" by "void *" in some functions since v3 and v4 are now supported as well. Signed-off-by: Safae Ouajih <souajih@baylibre.com> Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com> Tested-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
* android: boot: update android_image_get_dtb_img_addr to support v3, v4Safae Ouajih2023-04-041-14/+33
| | | | | | | | | | | | | Add support for boot image version 3 and 4 in android_image_get_dtb_img_addr(). Since the dtb is now included in vendor_boot image instead of boot image, extract the dtb address from vendor_boot image when a v3 or v4 is used. Signed-off-by: Safae Ouajih <souajih@baylibre.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com> Tested-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
* android: boot: support extra command lineSafae Ouajih2023-04-041-0/+11
| | | | | | | | | | | In version 3 and 4 of boot image header, the vendor specific command line are located in vendor boot image. Thus, use extra command line to add those cmd to bootargs. Signed-off-by: Safae Ouajih <souajih@baylibre.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com> Tested-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
* android: boot: ramdisk: support vendor ramdiskSafae Ouajih2023-04-041-2/+11
| | | | | | | | | | | | | | | | Version 3 and 4 of boot image header introduced vendor boot ramdisk: Please check include/android_image.h for details. The ramdisk is now split into a generic ramdisk in boot image and a vendor ramdisk in vendor boot image. Support the new vendor ramdisk. Signed-off-by: Safae Ouajih <souajih@baylibre.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com> Tested-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
* android: boot: update android_image_get_data to support v3, v4Safae Ouajih2023-04-041-3/+77
| | | | | | | | | | | | | | | | Since boot image header version 3 and 4 introduced vendor boot image, use the following functions to fill the generic android structure : andr_image_data: - android_boot_image_v3_v4_parse_hdr() - android_vendor_boot_image_v3_v4_parse_hdr() Update android_image_get_data() to support v3 and v4 Signed-off-by: Safae Ouajih <souajih@baylibre.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com> Tested-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
* android: boot: add vendor boot image to prepare for v3, v4 supportSafae Ouajih2023-04-044-26/+42
| | | | | | | | | | | | | Introduce vendor boot image for version 3 and 4 of boot image header. The vendor boot image will hold extra information about kernel, dtb and ramdisk. This is done to prepare for boot image version 3 and 4 support. Signed-off-by: Safae Ouajih <souajih@baylibre.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com> Tested-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
* android: boot: boot image header v3, v4 do not support recovery DTBOSafae Ouajih2023-04-041-2/+2
| | | | | | | | | | | android_image_get_dtbo() is used to get recovery DTBO via abootimg cmd. This is not supported in boot image header v3 and v4. Thus, print an error message when v1,v2 header version are not used. Signed-off-by: Safae Ouajih <souajih@baylibre.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com> Tested-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
* android: boot: content print is not supported for v3, v4 header versionSafae Ouajih2023-04-041-1/+5
| | | | | | | | | | | | | Content print is not supported for version 3 and 4 of boot image header. Thus, only print that content when v2 is used. Update android_print_contents() to print an error message when trying to print boot image header version 3 or 4 content. Signed-off-by: Safae Ouajih <souajih@baylibre.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com> Tested-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
* android: boot: move to andr_image_data structureSafae Ouajih2023-04-041-56/+65
| | | | | | | | | Move from andr_boot_img_hdr_v0 to andr_image_data structure to prepare for boot image header version 3 and 4. Signed-off-by: Safae Ouajih <souajih@baylibre.com> Tested-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
* android: boot: kcomp: support andr_image_dataSafae Ouajih2023-04-041-1/+74
| | | | | | | | | | | | | | | | andr_image_data structure is used as a global representation of boot image header structure. Introduce this new structure to support all boot header versions : v0,v1.v2.v3.v4 and to support v3 and v4 while maitaining support for v0,v1,v2. The need of using andr_image_data comes from the change of header structure in both version 3 and 4. Rework android_image_get_kcomp() to support this new struct. Signed-off-by: Safae Ouajih <souajih@baylibre.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com> Tested-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
* android: boot: replace android_image_check_headerSafae Ouajih2023-04-042-14/+5
| | | | | | | | | | | | With the new vendor boot image introduced in versions 3 and 4 of boot image header, the header check must be done for both boot image and vendor boot image. Thus, replace android_image_check_header() by is_android_boot_image_header() to only refer to boot image header check. Signed-off-by: Safae Ouajih <souajih@baylibre.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com> Tested-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
* android: boot: rename andr_img_hdr -> andr_boot_img_hdr_v0Safae Ouajih2023-04-042-15/+24
| | | | | | | | | | | | | | | | Android introduced boot header version 3 or 4. The header structure change with version 3 and 4 to support the new updates such as: - Introducing Vendor boot image: with a vendor ramdisk - Bootconfig feature (v4) Change andr_img_hdr struct name to maintain support for version v0, v1 and v2 while introducing version 3 and 4. Signed-off-by: Safae Ouajih <souajih@baylibre.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com> Tested-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
* image: Fix potentially uninitialized data variableMarek Vasut2023-03-301-4/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In case fitImage support is disabled, and image_locate_script() is passed a fitImage, then the 'data' variable is used uninitialized. Drop into the default: branch of the switch-case statement and do not return the uninitialized data, and do not modify the return pointer either, just print an error message. Reported by clang build: " $ make HOSTCC=clang CC=clang KCFLAGS=-Werror sandbox64_defconfig && make HOSTCC=clang CC=clang KCFLAGS=-Werror ... boot/image-board.c:1006:7: error: variable 'data' is used uninitialized whenever switch case is taken [-Werror,-Wsometimes-uninitialized] case IMAGE_FORMAT_LEGACY: ^~~~~~~~~~~~~~~~~~~ include/image.h:608:29: note: expanded from macro 'IMAGE_FORMAT_LEGACY' ^~~~ boot/image-board.c:1128:19: note: uninitialized use occurs here *datap = (char *)data; ^~~~ boot/image-board.c:1001:11: note: initialize the variable 'data' to silence this warning u32 *data; ^ = NULL " Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* Merge branch 'master' into nextTom Rini2023-03-271-18/+40
|\
| * boot: Create a common BOOT_DEFAULTS for distro and bootstdSimon Glass2023-03-271-34/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | These two features use a lot of common options. Move them into a common CONFIG to reduce duplication. Use 'select' for most options since these are things that boards aren't supposed to override. For now it is not possible to disable BOOT_DEFAULTS but we may take another look later. Note that five options use 'imply' to match existing behaviour. Signed-off-by: Simon Glass <sjg@chromium.org> [trini: Rework a bit so we don't grow so many platforms unintentionally] Signed-off-by: Tom Rini <trini@konsulko.com>
| * lmb: Enable LMB if SYS_BOOT_RAMDISK_HIGHSimon Glass2023-03-271-0/+1
| | | | | | | | | | | | | | Ramdisk relocation requires LMB, so enable it automatically to avoid build errors. Signed-off-by: Simon Glass <sjg@chromium.org>
| * Move DISTRO_DEFAULTS into boot/Simon Glass2023-03-271-0/+27
| | | | | | | | | | | | | | This relates to booting so move it in to that Kconfig file, before changing it. Signed-off-by: Simon Glass <sjg@chromium.org>
* | bootstd: Replicate the dtb-filename quirks of distrobootSimon Glass2023-03-082-9/+64
| | | | | | | | | | | | | | | | | | | | | | | | | | | | For EFI, the distro boot scripts search in three different directories for the .dtb file. The SOC-based filename fallback is supported only for 32-bit ARM. Adjust the code to mirror this behaviour. Also some boards can use a prior-stage FDT if one is not found in the normal way. Support this and show a message in that case. Signed-off-by: Simon Glass <sjg@chromium.org> Suggested-by: Mark Kettenis <kettenis@openbsd.org>
* | bootflow: Rename bootflow_flags_tSimon Glass2023-03-082-18/+18
| | | | | | | | | | | | | | These flags actually relate to the iterator, not the bootflow struct itself. Rename them. Signed-off-by: Simon Glass <sjg@chromium.org>
* | bootstd: Correct 'VPL' typoSimon Glass2023-03-021-1/+1
| | | | | | | | | | | | Correct a 'VPL' typo in the Kconfig. Signed-off-by: Simon Glass <sjg@chromium.org>
* | Correct SPL use of DM_RNGSimon Glass2023-03-021-1/+1
| | | | | | | | | | | | | | This converts 1 usage of this option to the non-SPL form, since there is no SPL_DM_RNG defined in Kconfig Signed-off-by: Simon Glass <sjg@chromium.org>
* | boot: Add Kconfigs for BOOTMETH_VBE_REQUESTSimon Glass2023-03-022-1/+22
| | | | | | | | | | | | | | Allow this to be enabled separately in U-Boot proper and in SPL, since it is not needed in SPL. Signed-off-by: Simon Glass <sjg@chromium.org>
* | bootstd: Disable QFW bootmeth in SPLSimon Glass2023-03-021-1/+1
|/ | | | | | | Move this Makefile line into the non-SPL area so we don't have to repy on the SPL_TPL_ macro. Signed-off-by: Simon Glass <sjg@chromium.org>
* Correct SPL uses of CMD_BOOTEFI_BOOTMGRSimon Glass2023-02-101-1/+2
| | | | | | | | This converts 3 usages of this option to the non-SPL form, since there is no SPL_CMD_BOOTEFI_BOOTMGR defined in Kconfig Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
* Correct SPL uses of LMBSimon Glass2023-02-101-1/+1
| | | | | | | This converts 9 usages of this option to the non-SPL form, since there is no SPL_LMB defined in Kconfig Signed-off-by: Simon Glass <sjg@chromium.org>
* Correct SPL use of CMD_PSTORESimon Glass2023-02-091-1/+1
| | | | | | | This converts 1 usage of this option to the non-SPL form, since there is no SPL_CMD_PSTORE defined in Kconfig Signed-off-by: Simon Glass <sjg@chromium.org>
* Correct SPL uses of CMD_FDTSimon Glass2023-02-092-2/+2
| | | | | | | This converts 2 usages of this option to the non-SPL form, since there is no SPL_CMD_FDT defined in Kconfig Signed-off-by: Simon Glass <sjg@chromium.org>
* Correct SPL uses of CMD_BOOTM_PRE_LOADSimon Glass2023-02-091-2/+2
| | | | | | | This converts 2 usages of this option to the non-SPL form, since there is no SPL_CMD_BOOTM_PRE_LOAD defined in Kconfig Signed-off-by: Simon Glass <sjg@chromium.org>
* Correct SPL use of CMD_BOOTISimon Glass2023-02-091-1/+1
| | | | | | | This converts 1 usage of this option to the non-SPL form, since there is no SPL_CMD_BOOTI defined in Kconfig Signed-off-by: Simon Glass <sjg@chromium.org>
* qemu: Add a bootmeth for qfwSimon Glass2023-02-063-1/+104
| | | | | | | | | | | This supports reading a kernel and ramdisk from qfw, then loading it with either the booti or bootz commands. For now this uses the existing booti and bootz commands, rather than trying to call that functionality directly (e.g. do_bootm_states()). It does not require the HUSH parser though, which helps a little with size. Signed-off-by: Simon Glass <sjg@chromium.org>
* bootstd: Add some default filesystems and commandsSimon Glass2023-02-061-0/+27
| | | | | | | | | | | | | | | | | We need to support a basic set of filesystems for booting to work in most cases. Add these in via a new option, letting the board disable them individually (for space reasons) if desired. This enables the filesystem commands as well as the actual functionality, even though bootstd is quite happy to use ext4 without the ext4 command. Further work would be needed to disintangle this and reduce code size. Add several other options as well, providing sensible defaults. We cannot enable this by default, since it expands the size of many boards quite a lot. Signed-off-by: Simon Glass <sjg@chromium.org>
* bootstd: Probe the block device before useSimon Glass2023-02-062-0/+7
| | | | | | | | | | | | | In some cases the block device is obtained but is not probed, since it is a sibling of the bootdev. Make sure it is probed, so it can be used without any trouble. This fixes a bug with virtio, where the device is accessed before it has been set up by the virtio uclass. Signed-off-by: Simon Glass <sjg@chromium.org> Fixes: 201417d700a ("bootstd: Add the bootdev uclass") Reported-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
* bootstd: Allow enabling BOOTSTD_FULL without needing EXPOSimon Glass2023-02-062-2/+3
| | | | | | | | | | | It is sometimes useful to have one without the other, e.g. on a device without a display, since at present the expo feature requires CONFIG_VIDEO to be enabled. Update the Makefile and bootflow command to support this, as well as the EXPO dependency. Signed-off-by: Simon Glass <sjg@chromium.org>
* bootstd: Add a little more logging of bootflowsSimon Glass2023-01-232-0/+5
| | | | | | Add some logging to aid debugging of problems with bootflows. Signed-off-by: Simon Glass <sjg@chromium.org>
* bootstd: Record the bootdevs used during scanningSimon Glass2023-01-231-10/+19
| | | | | | | | | | | | | | | Add a way to record the bootdevs used when scanning for bootflows. This is useful for testing. Enable this only with BOOTSTD_FULL and do the same for the progress reporting. Re-enable and update the affected tests now that we have this feature. For bootdev_test_order_default() there is no-longer any support for using the bootdev aliases to specify an ordering, so drop that part of the test. Signed-off-by: Simon Glass <sjg@chromium.org>
* bootstd: Drop the old bootflow_scan_first()Simon Glass2023-01-231-15/+3
| | | | | | | This function is not used outside tests. Drop it and rename bootflow_scan_dev() since it is how we start a scan now. Signed-off-by: Simon Glass <sjg@chromium.org>
* bootstd: Allow scanning a single bootdev labelSimon Glass2023-01-232-13/+58
| | | | | | | | | | | | | We want to support scanning a single label, like 'mmc' or 'usb0'. Add this feature by plumbing the label through to the iterator, setting a flag to indicate that only siblings of the initial device should be used. This means that scanning a bootdev by its name is not supported anymore. That feature doesn't seem very useful in practice, so it is no great loss. Add a test for bootdev_find_by_any() while we are here. Signed-off-by: Simon Glass <sjg@chromium.org>
* bootstd: Switch bootdev scanning to use labelsSimon Glass2023-01-232-133/+81
| | | | | | | | | | | | | | | | | | | At present we set up the bootdev order at the start, then scan the bootdevs one by one. However this approach cannot be used with hunters, since the bootdevs may not exist until the hunter is used. Nor can we just run all the hunters at the start, since that violate's U-Boot's 'lazy init' requirement. It also increases boot time. So we need to adjust the algorithm to scan by labels instead. As a first step, drop the dev_order[] array in favour of a list of labels. Update the name of bootdev_setup_iter_order() to better reflect what it does. Update some related comments and log messages. Also disable a few tests until a later commit where we can use them. Signed-off-by: Simon Glass <sjg@chromium.org>
* bootstd: Allow iterating to the next bootdev priortiySimon Glass2023-01-231-0/+64
| | | | | | | | | Add a function which moves to the next priority to be processed. This works by storing the current priority in the bootflow iterator. The logic to set this up is included in a subsequent commit. Signed-off-by: Simon Glass <sjg@chromium.org>
View Lorry Controller Status