gcc does not understand /* FALL TROUGH */ and emits a warning:
cmd/date.c: In function ‘do_date’:
cmd/date.c:62:20: warning:
this statement may fall through [-Wimplicit-fallthrough=]
62 | if (strcmp(argv[1],"reset") == 0) {
| ^
cmd/date.c:102:9: note: here
102 | case 1: /* get date & time */
| ^~~~
Use the fallthrough macro instead.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Tim Lee [Fri, 10 Feb 2023 09:05:39 +0000 (17:05 +0800)]
tools: env: use /run to store lockfile
According this issue https://github.com/ppp-project/ppp/issues/339.
Eventually, the dt-utils changed lock directory to fix missing /var/lock
directory error then make dt-utils can run normally.
We also have a similar issue with these two utilities fw_printenv and
fw_setenv will failed when the directory /var/lock is non-existent.
We have a custom linux distribution built with yocto (OpenBMC) that
use systemd and it deprecated the /var/lock directory.
More discussion in systemd/systemd#15668.
Thus, we sync with community's solution for uboot/tools/env utilities:
The current location /var/lock is considered legacy (at least by systemd).
Just use /run to store the lockfile and append the usual .lock suffix.
Tested:
Verified /run/lock is now present and fw_printenv can work in OpenBMC.
Signed-off-by: Tim Lee <timlee660101@gmail.com> Reviewed-by: Tom Rini <trini@konsulko.com>
Patrick Delaunay [Wed, 22 Mar 2023 18:12:25 +0000 (19:12 +0100)]
lmb: Fix LMB_MEMORY_REGIONS flag usage
Remove test on CONFIG_LMB_MEMORY_REGIONS introduced by commit 7c1860fce4e3 ("lmb: Fix lmb property's defination under struct lmb").
This code in lmb_init() is strange, because if CONFIG_LMB_USE_MAX_REGIONS
and CONFIG_LMB_MEMORY_REGIONS are not defined, the implicit #else is empty
and the required initialization is not done:
lmb->memory.max = ?
lmb->reserved.max = ?
But this setting is not possible:
- CONFIG_LMB_USE_MAX_REGIONS not defined
- CONFIG_LMB_MEMORY_REGIONS not defined
because CONFIG_LMB_MEMORY_REGIONS and CONFIG_LMB_RESERVED_REGIONS are
defined as soon as the CONFIG_LMB_USE_MAX_REGIONS is not defined.
This patch removes this impossible case #elif and I add some
explanation in lmb.h to explain why in the struct lmb {} the lmb
property is defined if CONFIG_LMB_MEMORY_REGIONS is NOT defined.
This patch also removes CONFIG_LMB_XXX dependency on CONFIG_LMB as these
defines are used in API file lmb.h and not only in library file.
Fixes: 5e2548c1d6e03 ("lmb: Fix LMB_MEMORY_REGIONS flag usage") Reported-by: Mark Millard <marklmi@yahoo.com> Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Acked-by: Michal Simek <michal.simek@amd.com>
To quote the author:
Block maps are a way of looking at various sources of data through the
lens of a regular block device. It lets you treat devices that are not
block devices, like RAM, as if they were. It also lets you export a
slice of an existing block device, which does not have to correspond to
a partition boundary, as a new block device.
This is primarily useful because U-Boot's filesystem drivers only
operate on block devices, so a block map lets you access filesystems
wherever they might be located.
The implementation is loosely modeled on Linux's "Device Mapper"
subsystem, see the kernel documentation [1] for more information.
The primary use-cases are to access filesystem images stored in RAM, and
within FIT images stored on disk. See doc/usage/blkmap.rst for more
details.
The architecture is pluggable, so adding other types of mappings should
be quite easy.
Add a frontend for the blkmap subsystem. In addition to the common
block device operations, this allows users to create and destroy
devices, and map in memory and slices of other block devices.
With that we support two primary use-cases:
- Being able to "distro boot" from a RAM disk. I.e., from an image
where the kernel is stored in /boot of some filesystem supported
by U-Boot.
- Accessing filesystems not located on exact partition boundaries,
e.g. when a filesystem image is wrapped in an FIT image and stored
in a disk partition.
Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Allow a slice of an existing block device to be mapped to a
blkmap. This means that filesystems that are not stored at exact
partition boundaries can be accessed by remapping a slice of the
existing device to a blkmap device.
Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Allow a slice of RAM to be mapped to a blkmap. This means that RAM can
now be accessed as if it was a block device, meaning that existing
filesystem drivers can now be used to access ramdisks.
Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com> Reviewed-by: Simon Glass <sjg@chromium.org>
blkmaps are loosely modeled on Linux's device mapper subsystem. The
basic idea is that you can create virtual block devices whose blocks
can be backed by a plethora of sources that are user configurable.
This change just adds the basic infrastructure for creating and
removing blkmap devices. Subsequent changes will extend this to add
support for actual mappings.
Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com> Reviewed-by: Simon Glass <sjg@chromium.org>
cmd: blk: Allow generic read/write operations to work in sandbox
Ensure that the memory destination/source addresses of block
read/write operations are mapped in before access. Currently, this is
only needed on sandbox builds.
Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com> Reviewed-by: Simon Glass <sjg@chromium.org>
To quote the author:
* This is based on Roman Stratiienko's work to support boot image header version 3 and 4.
* This supports the new boot image headers v3, v4 and bootconfig feature.
https://source.android.com/docs/core/architecture/bootloader/boot-image-header
https://source.android.com/docs/core/architecture/bootloader/implementing-bootconfig
- Tested on Amlogic Khadas vim3l, a reference board for Android Open Source Project
https://www.khadas.com/vim3l
And on AM625 Texas Instruments board with 5.10 linux kernel
Main changes :
- New partition : vendor boot, with a specific vendor ramdisk
- DTB is stored in the vendor boot partition
- The generic ramdisk is placed after the vendor ramdisk
- Bootconfig feature support
Here is a link to see the related android boot flow changes on KHADAS vim3l as an example:
https://gitlab.baylibre.com/baylibre/amlogic/atv/u-boot/-/commits/souajih/BootImagev4/
Safae Ouajih [Sun, 5 Feb 2023 23:50:20 +0000 (00:50 +0100)]
test/py: android: extend abootimg test
test_abootimg is extended to include the testing of boot images
version 4. For this, boot.img and vendor_boot.img have been
generated using mkbootimg tool with setting the header
version to 4.
This tests:
- Getting the header version using abootimg
- Extracting the load address of the dtb
- Extracting the dtb start address in RAM
Safae Ouajih [Sun, 5 Feb 2023 23:50:15 +0000 (00:50 +0100)]
android: boot: update android_image_get_dtb_img_addr to support v3, v4
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.
Safae Ouajih [Sun, 5 Feb 2023 23:50:14 +0000 (00:50 +0100)]
android: boot: support extra command line
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.
Safae Ouajih [Sun, 5 Feb 2023 23:50:12 +0000 (00:50 +0100)]
android: boot: update android_image_get_data to support v3, v4
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:
Safae Ouajih [Sun, 5 Feb 2023 23:50:10 +0000 (00:50 +0100)]
android: boot: boot image header v3, v4 do not support recovery DTBO
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.
Safae Ouajih [Sun, 5 Feb 2023 23:50:07 +0000 (00:50 +0100)]
android: boot: kcomp: support andr_image_data
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.
These definitions have been copied over from the AOSP documentation at
[1] and [2]
Boot arg sizes are taken from [3]:
commit: 35fb6262bc3f (ANDROID: Support for vendor boot)
This also adds documentation for boot image header v3/v4 structure
that was imported from [4], file: include/bootimg/bootimg.h
commit: 8d0922bfb932 (Adding GKI signature in boot.img v4)
Safae Ouajih [Sun, 5 Feb 2023 23:50:05 +0000 (00:50 +0100)]
android: boot: replace android_image_check_header
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.
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.
Tom Rini [Tue, 4 Apr 2023 18:36:43 +0000 (14:36 -0400)]
Merge branch '2023-04-04-update-to-clang-16'
- Update our CI to use clang-16 for tests. This also changes slightly
how we do linker lists so that we don't rely on undefined behavior
that lead to clang-15 and later failing to work (and in some cases
seemingly, earlier versions of clang would sometimes fail).
Tom Rini [Tue, 28 Mar 2023 18:54:51 +0000 (14:54 -0400)]
linker_lists: Rework start/end macros to not rely on undefined behavior
Per the GCC bug listed below, the way we do linker lists is relying on
undefined behavior that seems to work in gcc, but doesn't always work in
clang. Andrew suggests rewriting our start/end macros in a different way
(as implemented here, from what he said in comment 1) to avoid these
problems.
Reported-by: AdityaK <appujee@google.com> Suggested-by: Andrew Pinski <apinski@marvell.com> Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108915 Signed-off-by: Tom Rini <trini@konsulko.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Andrew Pinski <apinski@marvell.com>
Tom Rini [Thu, 23 Mar 2023 18:57:58 +0000 (14:57 -0400)]
Dockerfile: Populate a pip cache
Given the number of jobs in CI we have which use python and pip install
packages, we should do this once in the Dockerfile, in order to populate
the cache. We let each job continue to create and use the virtual
environments they need to facilitate making updates to these
environments easier.
Signed-off-by: Tom Rini <trini@konsulko.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Tom Rini [Thu, 23 Mar 2023 18:57:57 +0000 (14:57 -0400)]
pytest: Update requirements to match sphinx versions
In order to better make use of pip caches, and also for better overall
consistency, we should use the same versions of packages in each of our
python requirements files. Update pytest to use the newer versions of
packages we use in sphinx builds.
Signed-off-by: Tom Rini <trini@konsulko.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Ioana Ciornei [Wed, 15 Mar 2023 11:04:18 +0000 (13:04 +0200)]
board: freescale: lx2160a: remove the PL01X device instantiation
There is no need for the board file to instantiate a PL01X platform
device anymore. This is all taken care of by the DM code which now will
probe the device based on the DT node.
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com> Signed-off-by: Peng Fan <peng.fan@nxp.com>
Ioana Ciornei [Wed, 15 Mar 2023 11:04:16 +0000 (13:04 +0200)]
arch: arm: dts: fsl-lx2160a.dtsi: sync serial nodes with Linux
Sync the serial nodes of the LX2160A based boards with their
representation in Linux. We also imported the clockgen and sysclk nodes
which are dependencies.
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com> Signed-off-by: Peng Fan <peng.fan@nxp.com>
Ioana Ciornei [Wed, 15 Mar 2023 11:04:14 +0000 (13:04 +0200)]
arch: arm: dts: fsl-lx2160a.dtsi: add an 'soc' node
The u-boot dts for these boards do not have an soc node, unlike its
Linux counterpart. This patch just adds the soc node as seen in Linux,
the next patches will move some nodes under it.
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com> Signed-off-by: Peng Fan <peng.fan@nxp.com>
Ioana Ciornei [Wed, 15 Mar 2023 11:04:11 +0000 (13:04 +0200)]
arch: arm: dts: fsl-ls1088a.dtsi: sync serial nodes with Linux
Sync the serial nodes of the LS1088A based boards with their
representation in Linux. We also imported the clockgen and sysclk nodes
which are dependencies.
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com> Signed-off-by: Peng Fan <peng.fan@nxp.com>
Ioana Ciornei [Wed, 15 Mar 2023 11:04:09 +0000 (13:04 +0200)]
arch: arm: dts: fsl-ls1088a.dtsi: add an 'soc' node
The u-boot dts for these boards do not have an soc node, unlike its
Linux counterpart. This patch just adds the soc node as seen in Linux,
the next patches will move some nodes under it.
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com> Signed-off-by: Peng Fan <peng.fan@nxp.com>
Vladimir Oltean [Wed, 15 Mar 2023 11:01:16 +0000 (13:01 +0200)]
configs: convert NXP LS1028A RDB and QDS to DM_SERIAL
Since the device trees are more or less synchronized with Linux, the
only necessary changes are to enable CONFIG_DM_SERIAL and the DM_SERIAL
driver for ns16550 (ns16550.c rather than serial_ns16550.c).
ls1028aqds_tfa_lpuart_defconfig already uses DM_SERIAL for the LPUART
driver, so I didn't touch that.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Ioana Ciornei <ioana.ciornei@nxp.com> Signed-off-by: Peng Fan <peng.fan@nxp.com>
Adam Ford [Fri, 24 Mar 2023 03:06:16 +0000 (22:06 -0500)]
arm64: imx: Add support for imx8mp-beacon-kit
Beacon Embedded has an i.MX8M Plus development kit which consists
of a SOM + baseboard. The SOM includes Bluetooth, WiFi, QSPI, eMMC,
and one Ethernet PHY. The baseboard includes audio, HDMI, USB-C Dual
Role port, USB Hub with five ports, a PCIe slot, and a second Ethernet
PHY. The device trees are already queued for inclusion in Linux 6.3.
Signed-off-by: Adam Ford <aford173@gmail.com> Reviewed-by: Tom Rini <trini@konsulko.com>
Marek Vasut [Mon, 3 Apr 2023 23:07:43 +0000 (01:07 +0200)]
ARM: dts: imx: Add support for Data Modul i.MX8M Plus eDM SBC
Add support for Data Modul i.MX8M Plus eDM SBC board. This is an
evaluation board for various custom display units. Currently
supported are serial console, ethernet, eMMC, SD, SPI NOR, USB.
Add WDT reboot bindings on DH i.MX6 DHSOM to permit the platform
to reboot via WDT in U-Boot. These are custom U-Boot bindings,
hence they are placed in -u-boot.dtsi .
Reviewed-by: Fabio Estevam <festevam@denx.de> Signed-off-by: Marek Vasut <marex@denx.de>
board: verdin-imx8mp: update lpddr4 configuration and training
Update LPDDR4 configuration and training using updated spreadsheet and
tools from NXP using data from previous spreadsheet and verified
toward datasheet:
- MX8M_Plus_LPDDR4_RPA_v9.xlsx
- mscale_ddr_tool_v3.30.exe
Some register values differ due to these fixes/modifications:
- corrected calculation of T_CKPDX parameter (equal to tCKCKEH for LPDDR4)
- corrected ECC related items, none of which affect normal operation
when ECC is not enabled
- corrected formula for calculation of tRTP in cell D122
board: verdin-imx8mp: update ddrc config for different lpddr4 memories
Add support to Verdin IMX8MP V1.1B SKU which uses
MT53E1G32D2FW-046 WT:B memory.
Compared to the 8 GB memory (MT53E2G32D4NQ-046 WT:A) used on
Verdin IMX8MP V1.0A it has 16 row addresses instead of 17.
In fact, the new memory, is a 2 GB/rank memory. The 8 GB memory is a
4 GB/rank memory.
Manually tweaking Host Interface addresses vs LPDDR4 signals mapping it
is possible to have a single configuration working with both memories:
- Old configuration: HIF bit 30 -> rank, HIF bit 29 -> Row 16
- New configuration: HIF bit 29 -> rank, HIF bit 30 -> Row 16
With this change the memory space from the host processor is contiguous
for both the configurations and the correct memory size is computed
using get_ram_size() at runtime.
Support for single rank memories still works thanks to the fact
dual ranks training fails (ddr_init->ddr_cfg_phy) toward single rank
memories.
Luca Ceresoli [Fri, 10 Mar 2023 10:07:52 +0000 (11:07 +0100)]
arm: imx: add u-boot-nand.imx to boot from NAND without SPL
U-Boot can be booted from NAND without SPL by prepending the DCD header to
the actual U-Boot binary. However this requires prepending 1024 bytes to
u-boot.imx (DCD + u-boot.bin).
There is already a similar target to build spl/u-boot-nand-spl.imx, add the
same option for no-SPL boot.
Marek Vasut [Tue, 7 Mar 2023 07:51:05 +0000 (08:51 +0100)]
ARM: imx: Enable SDP download in SPL on DH i.MX6 DHSOM
Enable SDP protocol support in SPL for DH i.MX6 DHSOM, now that those
components fit into the SPL due to LTO.
To start U-Boot via SDP upload on i.MX6 DHSOM based board, proceed as follows:
- Compile imx_usb [1] .
- Power off the i.MX6 DHSOM based board.
- Connect both USB-serial console and USB-OTG miniB ports to host PC.
- Switch board to USB boot mode.
- Power on the board.
- Verify using '$ dmesg' that a new device has been detected as follows:
New USB device found, idVendor=15a2, idProduct=0054, bcdDevice= 0.01
New USB device strings: Mfr=1, Product=2, SerialNumber=0
Product: SE Blank ARIK
Manufacturer: Freescale SemiConductor Inc
The spl_board_prepare_for_boot() should be called before jump_to_image_no_args()
to perform board-specific deinitialization before jumping to the next stage.
This board-specific deinitialization can be very much anything, e.g. disable
dcache in case it was enabled, or such.
Add the missing spl_board_prepare_for_boot() call into f_sdp .
Sinthu Raja [Mon, 3 Apr 2023 17:03:12 +0000 (12:03 -0500)]
arm: dts: k3-j721e-sk-u-boot: fix boot on j721e SK
J721e SK has been broken since at least March 2022.
The main-navss and mcu-navss nodes were renamed and this caused the
A72 SPL to fail early in the boot even before the serial port was
enabled. Fix this.
A later patch series between v2022.07 and v2022.10 additionally broke
boot on this board by introducing hbmc nodes which are not present on
this board. The right fix is to disable these by default in the SOC
dtsi file, but for now we can also disable them in the u-boot dtsi.
With both these fixed, we can now boot the j721e SK board fully from
mainline u-boot.
Fabio Estevam [Wed, 15 Feb 2023 18:24:44 +0000 (15:24 -0300)]
pico-imx6: Pass the mmc alias to fix boot regression
Originally, the mmc aliases node was present in imx6qdl-pico.dtsi.
After the sync with Linux in commit d0399a46e7cd ("imx6dl/imx6qdl:
synchronise device trees with linux"), the aliases node is gone as
the upstream version does not have it.
This causes a boot regression in which the eMMC card cannot be found anymore.
Fix it by passing the alias node in the u-boot.dtsi file to
restore the original behaviour where the eMMC (esdhc3) was
mapped to mmc0.
Fixes: d0399a46e7cd ("imx6dl/imx6qdl: synchronise device trees with linux") Signed-off-by: Fabio Estevam <festevam@denx.de>
Peter Hoyes [Tue, 21 Mar 2023 13:01:16 +0000 (13:01 +0000)]
fdt: Make fdt addr -q quieter
64597346 "fdt: Add -q option to fdt addr for distro_bootcmd" introduced
the -q option for fdt addr, which sets the current working fdt address
without printing any output.
baf41410 "fdt: Show a message when the working FDT changes" made the
utility function set_working_fdt_addr (in cmd/fdt.c) output a message
on each invocation, even if called via fdt addr -q, in which case its
output is now slightly noisier.
To fix this, split out set_working_fdt_addr into set_working_fdt_addr
plus the static function set_working_fdt_addr_quiet.
set_working_fdt_addr_quiet can be called by "quiet" fdt cmd logic and
set_working_fdt_addr is exported (as before) to other boot logic. The
latter calls the former.
Remove the assertion from the fdt addr test case when calling with the
-q argument.
Signed-off-by: Peter Hoyes <Peter.Hoyes@arm.com> Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Reviewed-by: Simon Glass <sjg@chromium.org>
But the function pinctrl_gpio_get_pinctrl_and_offset can't handle this
case because the "index" argument passed to dev_read_phandle_with_args
is fixed to be "0". Use a loop to traverse the array to fix it.
Signed-off-by: Quanyang Wang <quanyang.wang@windriver.com>
Marek Vasut [Sat, 11 Mar 2023 16:29:21 +0000 (17:29 +0100)]
cmd: fdt: Use env_set_hex() for "get addr" and "get size"
The 'fdt get addr' and 'env get size' is always assumed to be hex
value, drop the prefix, and outright switch to env_set_hex(). Since
this might break existing users who depend on the existing behavior
with 0x prefix, this is a separate patch.
Revert if this breaks anything.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Reviewed-by: Simon Glass <sjg@chromium.org>
David Sebek [Thu, 30 Mar 2023 21:51:14 +0000 (17:51 -0400)]
rockchip: Fix incorrect constant name in RAM init code
A condition in the rk3399 RAM initialization code used the old
CONFIG_RAM_RK3399_LPDDR4 constant name. This commit changes the
condition to use the correct CONFIG_RAM_ROCKCHIP_LPDDR4 constant.
Roman Kopytin [Mon, 20 Mar 2023 03:28:13 +0000 (03:28 +0000)]
test_vboot.py: include test of fdt_add_pubkey tool
Add test_fdt_add_pubkey test which provides simple functionality test
which contains such steps:
create DTB and FIT files
add keys with fdt_add_pubkey to DTB
sign FIT image
check with fit_check_sign that keys properly added to DTB file
Signed-off-by: Roman Kopytin <Roman.Kopytin@kaspersky.com> Signed-off-by: Ivan Mikhaylov <fr0st61te@gmail.com> Cc: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Assigning the value of a variable to itself should be avoided.
Addresses-Coverity-ID: 451089 ("Evaluation order violation") Fixes: 180b7118bed8 ("efi_loader: fix device-path for USB devices") Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
We use short device-paths in boot options so that a file on a block device
can be found independent of the port into which the device is plugged.
Usb() device-path nodes only contain port and interface information and
therefore cannot identify a block device.
UsbWwi() device-path nodes contain the serial number of USB devices.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Fixes: edca8cf72130 ("Convert CONFIG_SCSI_AHCI_PLAT et al to Kconfig") Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Simon Glass <sjg@chromium.org>
projects / u-boot.git / log
