The Kconfig symbols SYS_ARCH, SYS_CPU, SYS_SOC, SYS_VENDOR and
SYS_BOARD are defined in arch/Kconfig as having type string, and most
board files simply amend those definition with suitable
default "foo"
or
default "foo" if BAR
stanzas. But some also include a redundant repetition of the type.
Homogenize the code base by removing those lines.
Generated by
find arch/*/ board -name Kconfig | xargs perl -i -g -pe 's/(config SYS_(ARCH|CPU|SOC|VENDOR|BOARD)\n)\s*string\n/\1/gs'
with the trailing slash in arch/*/ ensuring that arch/Kconfig itself
is not found.
This does not change boards which add a prompt string, e.g.
string "Board name"
because I think those change the semantics of the symbol into being
user-settable.
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Reviewed-by: Tom Rini <trini@konsulko.com>
As per the maintainers at egnite GmbH, they are no longer interested in
supporting this board. Go and remove the platform here. Furthermore,
this is the only AT91SAM9XE platform in-tree so remove supporting code
for that as well.
Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
Various improvements to Snapdragon support:
* Bumped up the pagetable size to handle newer SoCs with much more RAM
* Made memory map parsing more robust, fixing chainloading on
SM8550/SM8650
* Populate fdt_addr_r with U-Boot's FDT by default, and set $loadaddr to
prevent
crashes with some commands which expect it
* Added initial support for SC7280/QCM6490 and the new RB3 Gen 2 board
* Add debug config fragments to enable debug UART on some SoCs.
* Enable RPMh regulators on SM8550/SM8650
* Map the cmd-db memory explicitly since it may not be in the memory map
CI: https://source.denx.de/u-boot/custodians/u-boot-snapdragon/-/pipelines/22255
Implement trivial extension to the sandbox PHY, which makes it pretend
to support selecting USB Host mode and nothing else. Any other mode is
rejected with -EINVAL. Any submode except for default submode 0 is
rejected with -EOPNOTSUPP . The implementation behaves in this trivial
way to permit easy unit testing using test which is also added in this
commit.
To run the test, use e.g. sandbox64_defconfig and run U-Boot as follows:
$ ./u-boot -Tc 'ut dm phy_setup'
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
The current init operation also sets the PHY into USB host mode.
Split the mode configuration into set_mode callback instead and
implement support for device and OTG modes as well.
The OTG mode performs auto-detection and selects either host or
device mode. In case the OTG mode is configured, submode field
can be used to select full PHY (re)initialization or only mode
auto-detection. The full (re)initialization is only necessary
once, on start up.
Since the OTG mode may enable IRQ generation in the PHY, disable
that IRQ generation in the exit callback again.
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Extend generic_setup_phy() parameter list with PHY mode and submode and
call generic_phy_set_mode() in generic_setup_phy(), so the generic PHY
setup function can configure the PHY into correct mode before powering
the PHY up.
Update all call sites of generic_setup_phy() as well, all of which are
USB host related, except for DM test which now behaves as a USB host
test.
Note that if the PHY driver does not implement the .set_mode callback,
generic_phy_set_mode() call returns 0 and does not error out, so this
should not break any existing systems.
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
The Python virtualenv tool sets up a few things in the environment,
putting its path first in the PATH environment variable and setting up
a sys.prefix different from the sys.base_prefix value.
At present buildman puts the toolchain path first in PATH so that it can
be found easily during the build. For sandbox this causes problems since
/usr/bin/gcc (for example) results in '/usr/bin' being prepended to the
PATH variable. As a result, the venv is partially disabled.
The result is that sandbox builds within a venv ignore the venv, e.g.
when looking for packages.
Correct this by detecting the venv and adding the toolchain path after
the venv path.
Signed-off-by: Simon Glass <sjg@chromium.org>
We already have some documentation describing how to enable debug UART
for Qualcomm SoCs. However the UART address varies per-soc... Add some
config fragments to enable debug UART for few well supported SoCs.
These can be used like:
$ make qcom_defconfig debug-sdm845.config
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
The process here is almost identical to the Dragonboard 410c, we've come
full circle!
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
Introduce a defconfig for the RB3 Gen 2 and other QCM6490 boards with a
dedicated uefi partition. These can replace EDK2 entirely with U-Boot.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
Adjust DTS so USB runs in host mode. The type-c port is the only
supported port (since the others need PCIe). Booting from USB is
possible with a powered type-c dock.
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
Add the PM8550 & related regulators found on the SM8550 and SM8650 platforms.
The tables are imported from the Linux driver.
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Reviewed-by: Caleb Connolly <caleb.connolly@linaro.org>
The TCS writes has no effect after the removal of the __tcs_set_trigger()
call, obviously it seems the RSC version 3 requires it to complete the transactions.
Fixes: 80c5be164a ("soc: qcom: rpmh-rsc: drop unused multi-threading and non-active TCS support")
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Tested-by: Caleb Connolly <caleb.connolly@linaro.org> # sm8250 rb5
Reviewed-by: Caleb Connolly <caleb.connolly@linaro.org>
Some newer boards end up with a bunch of holes in the memory map due to
how Qualcomm's hypervisor and ABL work. The end result is 14+ memory
regions.
Bump CONFIG_NR_DRAM_BANKS to 24 so we can handle these and any future
expansion easily.
Yes, this is ridiculous, but there is no other way.
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
On at least SM8650 this region might not be included in the memory map.
Use the new mmu_map_region() helper to map it during bind().
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
memcmp() can cause aborts on some platforms and generally seems to be
the wrong approach here. Use strncmp() instead which is more correct.
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
In some cases we might want to map some memory region after enabling
caches. Introduce a new helper for this.
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
This variable is used by default in some commands, set it to the same as
kernel_addr_r.
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
Set the fdt_addr_r environment variable to a region of LMB allocated
memory, and populate it by default with a copy of U-Boots FDT. This will
be used for Linux if no other DT is provided.
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
We don't know at build time where a sensible place for this is, allocate
it at runtime like the other variables.
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
In the typical case where we chainload from ABL, the serial number is
available in the DT bootargs. Read it out and set the serial#
environment variable so that it can be used by fastboot.
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
With 14+ entries in the memory map, we need quite a bit more space for
the page tables.
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
The generic memory parsing code in U-Boot lacks a few things that we
need on Qualcomm:
1. It sets gd->ram_size and gd->ram_base to represent a single memory
block.
2. setup_dest_addr() later relocates U-Boot to ram_base + ram_size, the
end of that first memory block.
This results in all memory beyond U-Boot being unusable in Linux when
booting with EFI.
Since the ranges in the memory node may be out of order, the only way
for us to correctly determine the relocation address for U-Boot is to
parse all memory regions and find the highest valid address.
We can't use fdtdec_setup_memory_banksize() since it stores the result
in gd->bd which is not yet allocated.
Hence, this commit, which implements an optimised parser to read the
memory blocks and store them in the .data section where they will
survive relocation.
We set ram_base and ram_size to describe the entire address space of
memory, with the assumption that the last memory region is big enough
for U-Boot, its DTB, and heap. On all boards tested so far this seems
to be a reasonable assumption.
As a nice side effect, our fdt parsing also winds up being faster since
we avoid the overhead of checking address/size-cells or populating
struct resource. We can safely make these optimisations since we only
support ARM64, and trust the reg property to be populated correctly.
After relocation, we then populate gd->bd->bi_dram with the data we
parsed earlier.
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
If U-Boot has a DTB built in (appended to the image directly) then this
was likely intentional, we should prioritise it over one provided by ABL
(if there was one).
Make this behaviour explicit, and panic if no valid DTB could be found
anywhere. Returning an error is not useful in this case as U-Boot would
just crash later in a more confusing way.
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
For regulator-fixed-clock, the device's private data is never set so in
fixed_clock_regulator_set_enable() is null and the function cannot
complete successfully.
Rename the _plat structure to _priv to better represent its role and set
this as the private data. As shown by the set_enable() function and by
using the same .of_to_plat hook as regulator-fixed, the platform data is
regulator_common_plat so also set .plat_auto correctly.
Finally, set up the private data by adding a .probe function to look up
the clock and set the member variable.
Fixes: f3b5100aff ("regulator: fixed: add possibility to enable by clock")
Signed-off-by: John Keeping <jkeeping@inmusicbrands.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The JH7110 SoC uses a GPIO for card detect.
* In the of_to_plat function check if a cd-gpios definition exists and
request the GPIO.
* In the getcd function return the GPIO value in this case.
Reported-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
After resetting the host controller, program in the POR val for this
register just like the Linux driver does.
This seems to help with initialization when running U-Boot as the primary
bootloader on some boards.
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
Per JESD84-B51 P47, host need to change frequency to <=52MHz
after setting HS_TIMING to 0x1, and host need to set the
8-bit DDR buswidth. Currently setting the frequency to 26MHz
and trying to switch 8-bit DDR buswidth resulting timeouts.
mmc dev 1 0
Select HS400 failed -110
switch to partitions #0, OK
mmc1(part 0) is current device
Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
Tim Harvey <tharvey@gateworks.com> says:
Modern eMMC v4+ devices have multiple hardware partitions per the JEDEC
specification described as:
Boot Area Partition 1
Boot Area Partition 2
RPMB Partition
General Purpose Partition 1
General Purpose Partition 2
General Purpose Partition 3
General Purpose Partition 4
User Data Area
These are referenced by fields in the PARTITION_CONFIG register
(Extended CSD Register 179) which is defined as:
bit 7: reserved
bit 6: BOOT_ACK
0x0: No boot acknowledge sent (default
0x1: Boot acknowledge sent during boot operation Bit
bit 5:3: BOOT_PARTITION_ENABLE
0x0: Device not boot enabled (default)
0x1: Boot Area partition 1 enabled for boot
0x2: Boot Area partition 2 enabled for boot
0x3-0x6: Reserved
0x7: User area enabled for boot
bit 2:0 PARTITION_ACCESS
0x0: No access to boot partition (default)
0x1: Boot Area partition 1
0x2: Boot Area partition 2
0x3: Replay Protected Memory Block (RPMB)
0x4: Access to General Purpose partition 1
0x5: Access to General Purpose partition 2
0x6: Access to General Purpose partition 3
0x7: Access to General Purpose partition 4
Note that setting PARTITION_ACCESS to 0x0 results in selecting the User
Data Area partition.
You can see above that the two fields BOOT_PARTITION_ENABLE and
PARTITION_ACCESS do not use the same enumerated values.
U-Boot uses a set of macros to access fields of the PARTITION_CONFIG
register:
EXT_CSD_BOOT_ACK_ENABLE (1 << 6)
EXT_CSD_BOOT_PARTITION_ENABLE (1 << 3)
EXT_CSD_PARTITION_ACCESS_ENABLE (1 << 0)
EXT_CSD_PARTITION_ACCESS_DISABLE (0 << 0)
EXT_CSD_BOOT_ACK(x) (x << 6)
EXT_CSD_BOOT_PART_NUM(x) (x << 3)
EXT_CSD_PARTITION_ACCESS(x) (x << 0)
EXT_CSD_EXTRACT_BOOT_ACK(x) (((x) >> 6) & 0x1)
EXT_CSD_EXTRACT_BOOT_PART(x) (((x) >> 3) & 0x7)
EXT_CSD_EXTRACT_PARTITION_ACCESS(x) ((x) & 0x7)
There are various places in U-Boot where the BOOT_PARTITION_ENABLE field
is accessed via EXT_CSD_EXTRACT_PARTITION_ACCESS and converted to a
hardware partition consistent with the definition of the
PARTITION_ACCESS field used by the various mmc_switch incarnations.
To add some sanity to the distinction between BOOT_PARTITION_ENABLE
(used to specify the active device on power-cycle) and PARTITION_ACCESS
(used to switch between hardware partitions) create two enumerated types
and use them wherever struct mmc * part_config is used or the above
macros are used.
Additionally provide arrays of the field names and allow those to be
used in the 'mmc partconf' command and in board support files.
The first patch adds enumerated types and makes use of them which
represents no compiled code change.
The 2nd patch adds the array of names and uses them in the 'mmc
partconf' command.
The 3rd patch uses the array of hardware partition names in a board
support file to show what emmc hardware partition U-Boot is being loaded
from.
To aid in understanding what emmc hardware partition is being
used to boot on power-up, display the hardware partition name in the
SPL.
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
eMMC v4+ devices have hardware partitions that are accessed via the
PARTITION_CONFIG (Extended CSD Register 179) PARTITION_ACCESS
and BOOT_PARTITION_ENABLE fields defined as:
bit 5:3: BOOT_PARTITION_ENABLE
0x0: Device not boot enabled (default)
0x1: Boot Area partition 1 enabled for boot
0x2: Boot Area partition 2 enabled for boot
0x3-0x6: Reserved
0x7: User area enabled for boot
bit 2:0 PARTITION_ACCESS
0x0: No access to boot partition (default)
0x1: Boot Area partition 1
0x2: Boot Area partition 2
0x3: Replay Protected Memory Block (RPMB)
0x4: Access to General Purpose partition 1
0x5: Access to General Purpose partition 2
0x6: Access to General Purpose partition 3
0x7: Access to General Purpose partition 4
Add char arrays to provide names for these values.
Use these names which displaying or setting the PARTITION_CONFIG
register via the 'mmc partconf' command.
Before:
u-boot=> mmc partconf 2 1 1 0 && mmc partconf 2
EXT_CSD[179], PARTITION_CONFIG:
BOOT_ACK: 0x1
BOOT_PARTITION_ENABLE: 0x2
PARTITION_ACCESS: 0x0
After:
u-boot=> mmc partconf 2 1 1 0 && mmc partconf 2
EXT_CSD[179], PARTITION_CONFIG:
BOOT_ACK: 0x1
BOOT_PARTITION_ENABLE: 0x1 (boot0)
PARTITION_ACCESS: 0x0 (user)
u-boot=> mmc partconf 2 1 boot1 0 && mmc partconf 2
EXT_CSD[179], PARTITION_CONFIG:
BOOT_ACK: 0x1
BOOT_PARTITION_ENABLE: 0x2 (boot1)
PARTITION_ACCESS: 0x0 (user)
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
Modern eMMC v4+ devices have multiple hardware partitions per the JEDEC
specification described as:
Boot Area Partition 1
Boot Area Partition 2
RPMB Partition
General Purpose Partition 1
General Purpose Partition 2
General Purpose Partition 3
General Purpose Partition 4
User Data Area
These are referenced by fields in the PARTITION_CONFIG register
(Extended CSD Register 179) which is defined as:
bit 7: reserved
bit 6: BOOT_ACK
0x0: No boot acknowledge sent (default
0x1: Boot acknowledge sent during boot operation Bit
bit 5:3: BOOT_PARTITION_ENABLE
0x0: Device not boot enabled (default)
0x1: Boot Area partition 1 enabled for boot
0x2: Boot Area partition 2 enabled for boot
0x3-0x6: Reserved
0x7: User area enabled for boot
bit 2:0 PARTITION_ACCESS
0x0: No access to boot partition (default)
0x1: Boot Area partition 1
0x2: Boot Area partition 2
0x3: Replay Protected Memory Block (RPMB)
0x4: Access to General Purpose partition 1
0x5: Access to General Purpose partition 2
0x6: Access to General Purpose partition 3
0x7: Access to General Purpose partition 4
Note that setting PARTITION_ACCESS to 0x0 results in selecting the User
Data Area partition.
You can see above that the two fields BOOT_PARTITION_ENABLE and
PARTITION_ACCESS do not use the same enumerated values.
U-Boot uses a set of macros to access fields of the PARTITION_CONFIG
register:
There are various places in U-Boot where the BOOT_PARTITION_ENABLE field
is accessed via EXT_CSD_EXTRACT_PARTITION_ACCESS and converted to a
hardware partition consistent with the definition of the
PARTITION_ACCESS field which is also the value used to specify the
hardware partition of the various mmc_switch incarnations.
To add some sanity to the distinction between BOOT_PARTITION_ENABLE
(used to specify the active device on power-cycle) and PARTITION_ACCESS
(used to switch between hardware partitions) create two enumerated types
and use them wherever struct mmc * part_config is used or the above
macros are used.
This represents no code changes.
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
Sughosh Ganu <sughosh.ganu@linaro.org> says:
This is a follow-up from an earlier RFC series [1] for making the LMB
and EFI memory allocations work together. This is a non-rfc version
with only the LMB part of the patches, for making the LMB memory map
global and persistent.
This is part one of a set of patches which aim to have the LMB and EFI
memory allocations work together. This requires making the LMB memory
map global and persistent, instead of having local, caller specific
maps. This is being done keeping in mind the usage of LMB memory by
platforms where the same memory region can be used to load multiple
different images. What is not allowed is to overwrite memory that has
been allocated by the other module, currently the EFI memory
module. This is being achieved by introducing a new flag,
LMB_NOOVERWRITE, which represents memory which cannot be re-requested
once allocated.
The data structures (alloced lists) required for maintaining the LMB
map are initialised during board init. The LMB module is enabled by
default for the main U-Boot image, while it needs to be enabled for
SPL. This version also uses a stack implementation, as suggested by
Simon Glass to temporarily store the lmb structure instance which is
used during normal operation when running lmb tests. This does away
with the need to run the lmb tests separately.
The tests have been tweaked where needed because of these changes.
The second part of the patches, to be sent subsequently, would work on
having the EFI allocations work with the LMB API's.
[1] - https://lore.kernel.org/u-boot/20240704073544.670249-1-sughosh.ganu@linaro.org/T/#t
Notes:
1) These patches are on next, as the alist patches have been
applied to that branch.
2) I have tested the boot on the ST DK2 board, but it would be good to
get a T-b/R-b from the ST maintainers.
3) It will be good to test these changes on a PowerPC platform
(ideally an 85xx, as I do not have one).
Instead of printing the LMB flags as numerical values, print them as
strings. This makes it easier to understand what flags are associated
with the lmb region. Also make corresponding changes to the bdinfo
command's test code.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
The value of ram_top address currently gets computed in an indirect
manner. The boot_fdt_add_mem_rsv_regions() function gets called first
to reserve the memory region occupied by OP-TEE in the LMB memory
map. This is followed by a call to the lmb_alloc() API, which returns
an address which is below the OP-TEE base address. This address is the
value of ram_top returned by the board_get_usable_ram_top() function.
This has now changed, as the LMB memory map, which is no longer local,
gets set up after relocation. Get the OP-TEE base address by reading
the device tree, and set the ram_top from this value.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
The optee_get_reserved_memory() function returns the OP-TEE base
address and size. The function gets these values from the
FDT. Currently, this function is defined only to be called in the SPL
phase. Move this function to a place where it can be invoked from the
main U-Boot phase, where it will be used to compute the ram_top
address.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
The LMB memory is typically not needed very early in the platform's
boot. Do not add memory to the LMB map before relocation. Reservation
of common areas and adding of memory is done after relocation.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
The sandbox iommu driver uses the LMB module to allocate a particular
range of memory for the device virtual address(DVA). This used to work
earlier since the LMB memory map was caller specific and not
global. But with the change to make the LMB allocations global and
persistent, adding this memory range has other side effects. On the
other hand, the sandbox iommu test expects to see this particular
value of the DVA. Use the DVA address directly, instead of mapping it
in the LMB memory map, and then have it allocated.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Enable the LMB config in SPL. This helps in testing the LMB code in
SPL on sandbox.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Initialise the ram bank information for sandbox in SPL. The ram bank
information gets initialised as part of the SPL initialisation
sequence in board_init_r(), which is then used for adding available
memory to the LMB memory map.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
The spl_board_init() function on sandbox invokes the unit
tests. Invoking the tests should be done once the rest of the system
has been initialised. Call the spl_board_init() function at the very
end, once the rest of the initilisation functions have been called,
including the setting up of the LMB memory map.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
The TCG event log buffer is being set at the end of ram memory. This
region of memory is to be reserved as LMB_NOMAP memory in the LMB
memory map. The current location of this buffer overlaps with the
memory region reserved for the U-Boot image, which is at the top of
the usable memory. This worked earlier as the LMB memory map was not
global but caller specific, but fails now because of the overlap.
Move the TCG event log buffer to the start of the ram memory region
instead. Move the location of the early trace buffer and the load
buffer for U-Boot(spl boot) accordingly.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
