The Allwinner R528/T113-s/D1/D1s SoCs all share the same die, so use the
same DRAM initialisation code.
Make use of prior art here and lift some code from awboot[1], which
carried init code based on earlier decompilation efforts, but with a
GPL2 license tag.
This code has been heavily reworked and cleaned up, to match previous
DRAM routines for other SoCs, and also to be closer to U-Boot's coding
style and support routines.
The actual DRAM chip timing parameters are included in the main file,
since they cover all DRAM types, and are protected by a new Kconfig
CONFIG_SUNXI_DRAM_TYPE symbol, which allows the compiler to pick only
the relevant settings, at build time.
The relevant DRAM chips/board specific configuration parameters are
delivered via Kconfig, so this code here should work for all supported
SoCs and DRAM chips combinations.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Tested-by: Sam Edwards <CFSworks@gmail.com>
At the moment all Allwinner DRAM initialisation routines are stored in
arch/arm/mach-sunxi, even though those "drivers" are just a giant
collection of writel's, without any architectural dependency.
The R528/T113-s SoC (with ARM cores) and the D1/D1s Soc (with RISC-V
cores) share the same die, so should share the same DRAM init routines as
well.
To prepare for this, add a new sunxi directory inside drivers/ram, and
add some stub entries to prepare for the addition of the share DRAM code
for those SoCs.
The RISC-V D1(s) SoCs will probably use SPL_DM, so for that SoC this
would be the right directory anyway.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
The PLL_PERIPH0 clock changed a bit in the D1/R528/T113s SoCs: there is
new P0 divider at bits [18:16], and the M divider is 1.
Add code to support this version of "PLL6".
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
The D1/R528/T113s SoCs introduce a new "LDO enable" bit in the CPUX_PLL.
Just enable that when we program that PLL.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Since the D1 CCU binding is defined, we can add support for its
gates/resets, following the pattern of the existing drivers.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Sean Anderson <seanga2@gmail.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Apart from using the new pinctrl MMIO register layout, the Allwinner D1
and related SoCs still need to usual set of mux values hardcoded in
U-Boot's pinctrl driver.
Add the values we need so far to this list, so that DM based drivers
will just work without further ado.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Allwinner seems to typically stick to a common MMIO memory map for
several SoCs, but from time to time does some breaking changes, which
also introduce new generations of some peripherals. The last time this
happened with the H6, which apart from re-organising the base addresses
also changed the clock controller significantly. We added a
CONFIG_SUN50I_GEN_H6 symbol back then to mark SoCs sharing those traits.
Now the Allwinner D1 changes the memory map again, and also extends the
pincontroller, among other peripherals.
To mark this generation of SoCs, add a CONFIG_SUNXI_GEN_NCAT2 symbol,
this name is reportedly used in the Allwinner BSP code, and prevents us
from inventing our own name.
Add this new symbol to some guards that were already checking for the H6
generation, since many features are shared between the two (like the
renovated clock controller).
This paves the way to introduce a first user of this generation.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Tested-by: Samuel Holland <samuel@sholland.org>
For the first time since at least the Allwinner A10 SoCs, the D1 (and
related cores) use a new pincontroller MMIO register layout, so we
cannot use our hardcoded, fixed offsets anymore.
Ideally this would all be handled by devicetree and DM drivers, but for
the DT-less SPL we still need the legacy interfaces.
Add a new Kconfig symbol to differenciate between the two generations of
pincontrollers, and just use that to just switch some basic symbols.
The rest is already abstracted enough, so works out of the box.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Sam Edwards <CFSworks@gmail.com>
Tested-by: Sam Edwards <CFSworks@gmail.com>
Tested-by: Samuel Holland <samuel@sholland.org>
On the Allwinner platform we were describing a quite comprehensive
memory map in a per-SoC header unser arch/arm.
In the old days that was used by every driver, but nowadays it should
only be needed by SPL drivers (not using the DT). Many addresses in
there were never used, and some are not needed anymore.
To avoid a dependency on CPU specific headers in an arch specific
directory, move the definition of the pinctroller MMIO base address into
the sunxi_gpio.h header, because the SPL routines for GPIO should be the
only one needing this address.
This is a first step towards getting rid of cpu_sun[x]i.h completely,
and allows to remove the inclusion of that file from the sunxi_gpio.h
header.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
U-Boot's generic GPIO_EXTRA_HEADER is a convenience symbol to allow code
to more easily include platform specific GPIO headers. This should not
be needed in a DM world anymore, since the generic GPIO framework
handles that nicely.
For Allwinner boards we still need to deal with non-DM GPIO in the SPL,
but this should become the exception, not the rule.
Make this more obvious by removing the definition of GPIO_EXTRA_HEADER,
and just force every legacy user of platform specific GPIO to include
the new sunxi_gpio.h header explicitly. Everyone doing so should feel
ashamed and should find a way to avoid it from now on.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Tested-by: Samuel Holland <samuel@sholland.org>
So far every Allwinner SoC used the same basic pincontroller/GPIO
register frame, and just differed by the number of implemented banks and
pins, plus some special functionality from time to time. However the D1
and successors use a slightly different pinctrl register layout.
Use that opportunity to drop "struct sunxi_gpio", that described that
MMIO frame in a C struct. That approach is somewhat frowned upon in the
Linux world and rarely used there, though still popular with U-Boot.
Switching from a C struct to a "base address plus offset" approach allows
to switch between the two models more dynamically, without reverting to
preprocessor macros and #ifdef's.
Model the pinctrl MMIO register frame in the usual "base address +
offset" way, and replace a hard-to-parse CPP macro with a more readable
static function.
All the users get converted over. There are no functional changes at
this point, it just prepares the stages for the D1 and friends.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Samuel Holland <samuel@sholland.org>
Tested-by: Samuel Holland <samuel@sholland.org>
So far we were open-coding the pincontroller's GPIO output/input access
in each function using that.
Provide functions that wrap that nicely, and follow the existing pattern
(set/get_{bank,}), so users don't need to know about the internals, and
we can abstract the new D1 pinctrl more easily.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Samuel Holland <samuel@sholland.org>
Move the existing sunxi-specific low level pinctrl routines from
arch/arm/mach-sunxi into the existing GPIO code under drivers/gpio, so
that the common code can be shared outside of arch/arm.
This also takes the opportunity to move some definitions from our
header file into the driver C file, as they are private to the driver
and are not needed elsewhere.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Samuel Holland <samuel@sholland.org>
Tested-by: Samuel Holland <samuel@sholland.org>
The CONFIG_MACPWR Kconfig symbol is used to point to a GPIO that enables
the power for the Ethernet "MAC" (mostly PHY, really).
In the DT this is described with the phy-supply property in the MAC DT
node, pointing to a (GPIO controlled) regulator. Since we need Ethernet
only in U-Boot proper, and use a DM driver there, we should use the DT
instead of hardcoding this.
Add code to the sun8i_emac and sunxi_emac drivers to check the DT for
that regulator and enable it, at probe time. Then drop the current code
from board.c, which was doing that job before.
This allows us to remove the MACPWR Kconfig definition and the respective
values from the defconfigs.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Sam Edwards <CFSworks@gmail.com>
At the moment the sun4i EMAC driver relies on hardcoded CONFIG_MACPWR
Kconfig symbols to enable potential PHY regulators. As we want to get rid
of those, we need to find the regulator by chasing up the DT.
The sun4i-emac binding puts the PHY regulator into the MDIO node, which
is the parent of the PHY device. U-Boot does not have (and does not
need) an MDIO driver, so we need to chase down the regulator through the
EMAC node: we follow the "phy-handle" property to find the PHY node,
then go up to its parent, where we find the "phy-supply" link to the
regulator. Let U-Boot find the associated regulator device, and put that
into the private device struct, so we can find and enable the regulator
at probe time, later.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Sam Edwards <CFSworks@gmail.com>
Reviewed-by: Samuel Holland <samuel@sholland.org>
The CONFIG_SATAPWR Kconfig symbol was used to point to a GPIO that
enables the power for a SATA harddisk.
In the DT this is described with the target-supply property in the AHCI
DT node, pointing to a (GPIO controlled) regulator. Since we need SATA
only in U-Boot proper, and use a DM driver for AHCI there, we should use
the DT instead of hardcoding this.
Add code to the sunxi AHCI driver to check the DT for that regulator and
enable it, at probe time. Then drop the current code from board.c, which
was doing that job before.
This allows us to remove the SATAPWR Kconfig definition and the
respective values from the defconfigs.
We also select the generic fixed regulator driver, which handles those
GPIO controlled regulators.
Please note that the OrangePi Plus is a bit special here, it's a H3
board without native SATA, but with a USB-to-SATA bridge. The DT models
the SATA power via a VBUS supply regulator, which we don't parse yet in
the USB PHY driver. Use the hardcoded CONFIG_USB3_VBUS_PIN for that
board meanwhile.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Sam Edwards <CFSworks@gmail.com>
Reviewed-by: Samuel Holland <samuel@sholland.org>
This copies in some devicetree files from the official Linux kernel tree,
v6.6-rc6. It covers a board with the Allwinner T113s SoC, which shares
many devices with its RISC-V sibling, the Allwinner D1(s). This is the
reason for the core .dtsi files landing in the arch/riscv directory.
We are only adjusting the include path to accommodate for the differences
in the U-Boot build system.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Sync the devicetree files from the official Linux kernel tree, v6.6-rc6.
This is covering Allwinner SoCs with 32-bit ARM cores, minus the T113s
board and related .dtsi files, which come separately.
Only small changes: Bluetooth got enabled on the C.H.I.P., and a clock
got renamed. More interesting is the addition of a board, for which
U-Boot enablement patches are pending.
As before, this omits the non-backwards compatible changes to the R_INTC
controller, to remain compatible with older kernels.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Sync the devicetree files from the official Linux kernel tree, v6.6-rc6.
This is covering Allwinner SoCs with 64-bit ARM cores.
Only small cosmetic changes (clock name fixed), but we add the DT for
the new OrangePi Zero 3 board, for which U-Boot enablement patches are
pending.
As before, this omits the non-backwards compatible changes to the R_INTC
controller, to remain compatible with older kernels.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Enable building Pogo V4 u-boot image with LTO, which results in about 30K
reduction in size.
Rebased to latest master and resend.
Signed-off-by: Tony Dinh <mibodhi@gmail.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Extend the existing driver to support the SCIF serial ports on the
Renesas RZ/G2L (R9A07G044) SoC. This also requires us to ensure that if
there is a reset signal defined in the device tree, it is de-asserted
before we try to talk to the SCIF module.
Signed-off-by: Paul Barker <paul.barker.ct@bp.renesas.com>
Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Tested-by: Marek Vasut <marek.vasut+renesas@mailbox.org> # R-Car H3 Salvator-XS
The current SCIF error handling is broken for the RZ/G2L. After a break
condition has been triggered, the current code is unable to clear the
error and serial port output never resumes.
The RZ/G2L datasheet says that most error conditions are cleared by
resetting the relevant error bits in the FSR & LSR registers to zero.
To clear framing errors on SCIF ports, the invalid data also needs to be
read out of the receive FIFO.
After reviewing datasheets for RZ/G2{H,M,N,E}, R-Car Gen4, R-Car Gen3
and even SH7751 SoCs, it's clear that this is the way to clear errors
for all of these SoCs.
While we're here, annotate the handle_error() function with a couple of
comments as the reads and writes themselves don't immediately make it
clear what we're doing.
Signed-off-by: Paul Barker <paul.barker.ct@bp.renesas.com>
Tested-by: Chris Paterson <chris.paterson2@renesas.com> # HiHope RZ/G2M board
Tested-by: Marek Vasut <marek.vasut+renesas@mailbox.org> # R-Car H3 Salvator-XS
This patch adds ISA string to the -march to generate zbb instructions
for U-Boot binaries, along with optimized string functions introduced
from Linux kernel.
Signed-off-by: Yu Chien Peter Lin <peterlin@andestech.com>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
Originally, u-boot SPL will place the DTB directly after the kernel,
but the size of the kernel does not include the BSS section, This
means that u-boot SPL places the DTB in the kernel BSS section causing
the DTB to be cleared by the kernel BSS initialisation.
Moving the DTB in front of the kernel can avoid this error.
Signed-off-by: Randolph <randolph@andestech.com>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
Fork from ae350_rv[32/64]_spl_[xip]_defconfig and
append CONFIG_SPL_LOAD_FIT_OPENSBI_OS_BOOT=y
Signed-off-by: Randolph <randolph@andestech.com>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
If SPL_LOAD_FIT_OPENSBI_OS_BOOT is enabled, the function
spl_invoke_opensbi should change the target OS type to IH_OS_LINUX.
OpenSBI will load the Linux image as the next boot stage.
The os_takes_devicetree function returns a value of true or false
depending on whether or not SPL_LOAD_FIT_OPENSBI_OS_BOOT is enabled.
Signed-off-by: Randolph <randolph@andestech.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add condition for OpenSBI OS boot mode, by default it is not enabled.
By default, binman creates the output file u-boot.itb.
If SPL_OPENSBI_OS_BOOT is enabled, linux.itb will be created
after compilation instead of the default u-boot.itb.
Signed-off-by: Randolph <randolph@andestech.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Introduce common Kconfig symbol for riscv architecture.
This symbol SPL_LOAD_FIT_OPENSBI_OS_BOOT is like falcon mode on ARM,
the Falcon boot is a shortcut boot method for SD/eMMC targets. It
skips the loading the RAM version U-Boot. Instead, it will loads
the FIT image and boots directly to Linux.
When SPL_OPENSBI_OS_BOOT is enabled, linux.itb is created after
compilation instead of the default u-boot.itb. It initialises memory
with the U-Boot SPL at the first stage, just as a normal boot process
does at the beginning. Instead of jumping to the U-Boot proper from
OpenSBI before booting the Linux kernel, the RISC-V falcon mode
process jumps directly to the Linux kernel to gain shorter booting time.
Signed-off-by: Randolph <randolph@andestech.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
In order to introduce the Opensbi OS boot mode, the next stage boot
image of OpenSBI should be configurable.
Signed-off-by: Randolph <randolph@andestech.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Source hart information is not necessary in IPI, so we could
use single-bit-per-hart strategy to rearrange PLICSW mapping.
Bit 0 of Interrupt Pending Bits is hardwired to 0.
Therefore, we use bit 1 to send IPI to hart 0,
bit 2 to hart 1, ..., and so on.
Signed-off-by: Randolph <randolph@andestech.com>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
Some platforms may not have any DDR memory below 4G and for such platforms
the TEXT_BASE and LOAD addresses etc are all 64 bit addresses due to
which the u-boot build fails with below error:
u-boot/arch/riscv/dts/binman.dtsi:30.14-25
Value out of range for 32-bit array element
u-boot/arch/riscv/dts/binman.dtsi:43.14-25
Value out of range for 32-bit array element
u-boot/arch/riscv/dts/binman.dtsi:44.15-26
Value out of range for 32-bit array element
FATAL ERROR: Syntax error parsing input tree
Fix by setting the address-cells property to 2 and converting load
addresses to 64 bit values.
Signed-off-by: Mayuresh Chitale <mchitale@ventanamicro.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Remove dram_init_banksize() on the architecture level.
Limiting used RAM to under 4 GiB is only necessary for CPUs which have a
DMA issue. SoC specific code already exists for FU540, FU740, JH7110.
Not all RISC-V boards will have memory below 4 GiB.
A weak implementation of dram_init_banksize() exists in common/board_f.c.
See the discussion in
https://lore.kernel.org/u-boot/545fe813-cb1e-469c-a131-0025c77aeaa2@canonical.com/T/
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Anup Patel <anup@brainfault.org>
Fix npcm845 watchdog halt for reset function and expire function.
Reset function is restart wdt.
Signed-off-by: Jim Liu <JJLIU0@nuvoton.com>
Reviewed-by: Stefan Roese <sr@denx.de>
For some time now running sandbox with -T produces an error:
Core: 270 devices, 95 uclasses, devicetree: board
WDT: Not starting wdt-gpio-toggle
wdt_gpio wdt-gpio-level: Request for wdt gpio failed: -16
WDT: Not starting wdt@0
MMC: mmc2: 2 (SD), mmc1: 1 (SD), mmc0: 0 (SD)
Use an unallocated GPIO to avoid this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Fixes: 1fc45d6483 ("watchdog: add pulse support to gpio watchdog driver")
Reviewed-by: Stefan Roese <sr@denx.de>
To quote the author:
This series adds some tests for various SPL load methods, with the
intent of helping debug v6 of [1]. With that in mind, notable omissions
include NAND and ROMAPI, which both lack sandbox implementations, and
OS_BOOT, which I have deferred due to its complexity. Semihosting is
also omitted, but I think we can test that with qemu.
In order to test all of these methods, we must first generate suitable
images, possibly on filesystems. While other tests have historically
generated these images using external tools (e.g. mkimage, mkfs, etc.),
I have chosen to generate them on the fly. This is for a few reasons:
- By removing external dependencies on pytest to create certain files,
the tests become self-contained. This makes them easier to iterate on
and debug.
- By generating tests at runtime, we can dynamically vary the content.
This helps detect test failures, as even if tests are loaded to the
same location, the expected content will be different.
- We are not testing the image parsers themselves (e.g.
spl_load_simple_fit or fs_read) but rather the load methods (e.g.
spl_mmc_load_image). It is unnecessary to exercise full functionality
or generate 100% correct images.
- By reducing functionality to only what is necessary, the complexity of
various formats can often be greatly reduced.
This series depends on [2-3], which are small fixes identified through
this patch set. The organization of patches in this series is as
follows:
- General fixes for bugs which are unlikely to be triggered outside of
this series
- Changes to IMX8 container images to facilitate testing
- General prep. work, particularly regarding linker issues
- The tests themselves
Passing CI at [4].
[1] https://lore.kernel.org/all/20230731224304.111081-1-sean.anderson@seco.com/
[2] https://lore.kernel.org/all/20230930204246.515254-1-seanga2@gmail.com/
[3] https://lore.kernel.org/all/20231008014748.1987840-1-seanga2@gmail.com/
[4] https://source.denx.de/u-boot/custodians/u-boot-clk/-/pipelines/18128
Add test for the SPI load method. This one is pretty straightforward. We
can't enable FIT_EXTERNAL with LOAD_FIT_FULL because spl_spi_load_image
doesn't know the total image size and has to guess from fdt_totalsize. This
doesn't include external data, so loading it will fail.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add a test for the NOR load method. Since NOR is memory-mapped we can
substitute a buffer instead. The only major complication is testing LZMA
decompression. It's too complex to implement LZMA compression in a test, and we
have no in-tree compressor, so we just include some pre-compressed data. This
data was generated through something like
generate_data(plain, plain_size, "lzma")
cat plain.dat | lzma | hexdump -C
and was cleaned up further in my editor.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add a test for loading U-Boot over TFTP. As with other sandbox net
routines, we need to initialize our packets manually since things like
net_set_ether and net_set_udp_header always use "our" addresses. We use
BOOTP instead of DHCP, since DHCP has a tag/length-based format which is
harder to parse. Our TFTP implementation doesn't define as many constants
as I'd like, so I create some here. Note that the TFTP block size is
one-based, but offsets are zero-based.
In order to avoid address errors, we need to set up/define some additional
address information settings. dram_init_banksize would be a good candidate
for settig up bi_dram, but it gets called too late in board_init_r.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add a test for the MMC load method. This shows the general shape of tests
to come: The main test function calls do_spl_test_load with an appropriate
callback to write the image to the medium.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add a test for spl_blk_load_image, currently used only by NVMe. Because
there is no sandbox NVMe driver, just use MMC instead. Avoid falling back
to raw images to make failures more obvious.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add some functions for creating fat/ext2 filesystems with a single file and
a test for them. Filesystems require block devices, and it is easiest to
just use MMC for this. To get an MMC, we must also pull in the test device
tree. SPL_TIMER is necessary for SPL_MMC, perhaps because it uses a timeout.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This add some basic functions to create images, and a test for said
functions. This is not intended to be a test of the image parsing
functions, but rather a framework for creating minimal images for testing
load methods. That said, it does do an OK job at finding bugs in the image
parsing directly.
Since we have two methods for loading/parsing FIT images, add LOAD_FIT_FULL
as a separate CI run.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Returning a negative value from a unit test doesn't automatically fail the
test. We have to fail an assertion. Modify the test to do so.
This now causes the test to count as a failure on VPL. This is because the
fname of SPL (and U-Boot) is generated with make_exec in os_jump_to_image.
The original name of SPL is gone, and we can't determine the name of U-Boot
from the generated name.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
In order to make adding new spl unit tests easier, especially when they may
have many dependencies, add some Kconfigs for the existing image test.
Split it into the parts which are generic (such as callbacks) and the
test-specific parts.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
