ARM: uniphier: remove support for NOR Flash on support card

I actually do not see this used these days because eMMC or NAND is used
for non-volatile devices. Dump the burden to maintain this crappy code.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

ARM: uniphier: remove unused uniphier_sbc_init_admulti()

This was used by the old sLD3 SoC, the support of which was removed
by commit 00aa453ebf56 ("ARM: uniphier: remove sLD3 SoC support").

There is no more user of this function.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

ARM: uniphier: fix build error when CONFIG_MICRO_SUPPORT_CARD=n

If CONFIG_MICRO_SUPPORT_CARD is unset, the build fails due to
function redefinition.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

ARM: uniphier: sync with Linux 5.8-rc4

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

ARM: uniphier: consolidate SoC select menu

Currently, the supports for the following two ARMv7 SoC groups
are exclusive, because the boot ROM loads the SPL to a different
address:

 - LD4, sLD8                 (SPL is loaded at 0x00040000)
 - Pro4, Pro5, PXs2, LD6b    (SPL is loaded at 0x00100000)

This limitation exists only when CONFIG_SPL=y.

Instead of using crappy CONFIG options, checking SPL and SPL_TEXT_BASE
is cleaner.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

ARM: uniphier: increase CONFIG_SYS_MONITOR_LEN to 2MB

I increased the maximum U-Boot proper size from time to time, but
configs/uniphier_v7_defconfig hit the current limit 832KB.

Some historical info:

In the initial support, the max size was 512MB.

Commit 58d702274c09 ("ARM: uniphier: increase CONFIG_SYS_MONITOR_LEN")
increased it to 576KB, and commit 3ce5b1a8d86d ("ARM: uniphier: move
SPL stack address") moved the SPL stack location to avoid the memory
map conflict. It was the solution to increase the size without changing
the NOR boot image map.

commit 1a4bd3a095b2 ("ARM: uniphier: increase CONFIG_SYS_MONITOR_LEN
again") ended up with increasing the max size again, breaking the NOR
boot image map. The limit was set to 832KB, otherwise the SPL stack
would overwrite the U-Boot proper image:
 CONFIG_SPL_STACK - CONFIG_SYS_UBOOT_BASE + sizeof(struct image_header) = 0xd0000

To increase CONFIG_SYS_MONITOR_LEN even more, the SPL stack must be
moved somewhere. I put it back to the original location prior to
commit 3ce5b1a8d86d.

With this change, there is no more practical size limit.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

Revert "ARM: uniphier: add weird workaround code for LD20"

This reverts commit 45f41c134baf5ff1bbf59d33027f6c79884fa4d9.

This weird workaround was the best I came up with at that time
to boot U-Boot from TF-A.

I noticed U-Boot successfully boots on LD20 (i.e. CA72 CPU) by using
the latest TF-A.

Specifically, since the following TF-A commit, U-Boot runs at EL2
instead of EL1, and this issue went away as a side-effect.

|commit f998a052fd94ea082833109f25b94ed5bfa24e8b
|Author: Masahiro Yamada <yamada.masahiro@socionext.com>
|Date:   Thu Jul 25 10:57:38 2019 +0900
|
|    uniphier: run BL33 at EL2
|
|    All the SoCs in 64-bit UniPhier SoC family support EL2.
|
|    Just hard-code MODE_EL2 instead of using el_implemented() helper.
|
|    Change-Id: I7ab48002c5205bc8c013e1b46313b57d6c431db0
|    Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

However, if I reverted that, this problem would come back, presumably
because some EL1 code in U-Boot triggers this issue.

Now that commit f8ddd8cbb513 ("arm64: issue ISB after updating system
registers") fixed this issue properly, this weird workaround is no
longer needed irrespective of the exception level at which U-Boot runs.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

Merge tag 'rpi-next-2020.10' of https://gitlab.denx.de/u-boot/custodians/u-boot-raspberrypi

- add support for PCI and XHCI for RPi4 (64 bit only)
- optionally reset XHCI device on registration
- enable USB_KEYBOARD for rpi_4_defconfig

Merge branch '2020-08-10-arbitrary-virt-phys-mappings'

- Bring in Marek Szyprowski's series to allow for arbitrary
  virtual-physical address mappings.

config: Enable support for the XHCI controller on RPI4 board

This requires enabling BRCMSTB PCIe and XHCI_PCI drivers as well as PCI
and USB commands. To get it working one has to call the following commands:
"pci enum; usb start;", thus such commands have been added to the default
"preboot" environment variable. One has to update their environment if it
is already configured to get this feature working out of the box.

Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>

rpi4: add a mapping for the PCIe XHCI controller MMIO registers (ARM 32bit)

Create a non-cacheable mapping for the 0x600000000 physical memory region,
where MMIO registers for the PCIe XHCI controller are instantiated by the
PCIe bridge. Due to 32bit limit in the CPU virtual address space in ARM
32bit mode, this region is mapped at 0xff800000 CPU virtual address.

Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>

mmc: bcm283x: fix int to pointer cast

On build with 32 bit, there is a warning for int-to-pointer-cast.
Fix the int to pointer cast by using uintptr_t.

Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>

arm: provide a function for boards init code to modify MMU virtual-physical map

Provide function for setting arbitrary virtual-physical MMU mapping
and cache settings for the given region.

Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

arm: update comments to the common style

Update the comments in include/asm/system.h to the common style.

Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

powerpc: move ADDR_MAP to Kconfig

Move ADDR_MAP related config options from include/configs/*.h to the
proper place in lib/Kconfig. This has been done using
./tools/moveconfig.py and manual inspection of the generated changes.
This is a preparation to use ADDR_MAP helper on ARM 32bit Raspberry Pi4
board for mapping the PCIe XHCI MMIO, which is above the 4GiB identity
mapping limit.

Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

config: Enable USB Keyboard support on RPi4

Supporting USB keyboards out of the box is both handy for development
and production. Notably if u-boot is used to boot into GRUB.

Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
[mb: drop rpi_4_32b_defconfig hunk]
Signed-off-by: Matthias Brugger <mbrugger@suse.com>

usb: xhci: Add reset controller support

Some atypical users of xhci might need to manually reset their xHCI
controller before starting the HCD setup. Check if a reset controller
device is available to the PCI bus and trigger a reset.

Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
[mb: squash fix to only build xhci_reset_hw() if CONFIG_DM_BUS]
Signed-off-by: Matthias Brugger <mbrugger@suse.com>

configs: Enable support for reset controllers on RPi4

This is required in order to access the reset controller used to
initialize the board's xHCI chip.

Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Signed-off-by: Matthias Brugger <mbrugger@suse.com>

reset: Add Raspberry Pi 4 firmware reset controller

Raspberry Pi 4's co-processor controls some of the board's HW
initialization process, but it's up to Linux to trigger it when
relevant. Introduce a reset controller capable of interfacing with
RPi4's co-processor that models these firmware initialization routines as
reset lines.

Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Signed-off-by: Matthias Brugger <mbrugger@suse.com>

arm: rpi: Add function to trigger VL805's firmware load

On the Raspberry Pi 4, after a PCI reset, VL805's (a xHCI chip) firmware
may either be loaded directly from an EEPROM or, if not present, by the
SoC's VideCore (the SoC's co-processor). Introduce the function that
informs VideCore that VL805 may need its firmware loaded.

Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Signed-off-by: Matthias Brugger <mbrugger@suse.com>

configs: Enable support for the XHCI controller on RPI4 board (ARM 64-bit)

This requires enabling BRCMSTB PCIe and XHCI_PCI drivers as well as PCI
and USB commands. To get it working one has to call the following commands:
"pci enum; usb start;", thus such commands have been added to the default
"preboot" environment variable. One has to update their environment if it
is already configured to get this feature working out of the box.

Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Matthias Brugger <mbrugger@suse.com>

pci: Add driver for Broadcom BCM2711 SoC PCIe controller

This patch adds basic driver PCI Express controller found on Broadcom
set-top-box SoCs, e.g. BCM2711.
The code is based on Linux upstream driver (pcie-brcmstb.c) with MSI
handling removed. The inbound access memory region is not currently
parsed from dma-ranges DT property and a fixed 3GB region is used.

The patch has been tested on RPI4 board, i.e. on BCM2711 SoC with VL805
USB Host Controller.

Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Matthias Brugger <mbrugger@suse.com>

pci: Add some PCI Express capability register offset definitions

Add PCI Express capability definitions required by the Broadcom
STB PCIe controller driver.

Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Signed-off-by: Matthias Brugger <mbrugger@suse.com>

linux/bitfield.h: Add primitives for manipulating bitfields both in host- and fixed-endian

Imports Al Viro's original Linux commit 00b0c9b82663a, which contains
an in depth explanation and two fixes from Johannes Berg:
 e7d4a95da86e0 "bitfield: fix *_encode_bits()",
 37a3862e12382 "bitfield: add u8 helpers".

Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
[s.nawrocki: added empty lines between functions and macros]
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
[mb: squash fix including byteorder.h]
Signed-off-by: Matthias Brugger <mbrugger@suse.com>

Merge https://gitlab.denx.de/u-boot/custodians/u-boot-x86

- Add two- and three-argument versions of CONFIG_IS_ENABLED in
  linux/kconfig.h
- Adds a new feature which supports copying modified parts of
  the frame buffer to the uncached hardware buffer
- Enable the copy framebuffer on various x86 targets

rpi4: add a mapping for the PCIe XHCI controller MMIO registers (ARM 64bit)

Create a non-cacheable mapping for the 0x600000000 physical memory region,
where MMIO registers for the PCIe XHCI controller are instantiated by the
PCIe bridge.

Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Reviewed-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Signed-off-by: Matthias Brugger <mbrugger@suse.com>

rpi4: shorten a mapping for the DRAM

Remove the overlap between DRAM and device's IO area.

Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Reviewed-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Signed-off-by: Matthias Brugger <mbrugger@suse.com>

pci: Move some PCIe register offset definitions to a common header

Some PCI Express register offsets are currently defined in multiple
drivers, move them to a common header to avoid re-definitions and
as a pre-requisite for adding new PCIe driver.
While at it replace some spaces with tabs.

Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Signed-off-by: Matthias Brugger <mbrugger@suse.com>

usb: xhci: Use only 32-bit accesses in xhci_writeq/xhci_readq

There might be hardware configurations where 64-bit data accesses
to XHCI registers are not supported properly.  This patch removes
the readq/writeq so always two 32-bit accesses are used to read/write
64-bit XHCI registers, similarly as it is done in Linux kernel.

This patch fixes operation of the XHCI controller on RPI4 Broadcom
BCM2711 SoC based board, where the VL805 USB XHCI controller is
connected to the PCIe Root Complex, which is attached to the system
through the SCB bridge.

Even though the architecture is 64-bit the PCIe BAR is 32-bit and likely
the 64-bit wide register accesses initiated by the CPU are not properly
translated to a sequence of 32-bit PCIe accesses.
xhci_readq(), for example, always returns same value in upper and lower
32-bits, e.g. 0xabcd1234abcd1234 instead of 0x00000000abcd1234.

Cc: Sergey Temerkhanov <s.temerkhanov@gmail.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Signed-off-by: Matthias Brugger <mbrugger@suse.com>

usb: xhci: Add missing cache flush in the scratchpad array initialization

In current code there is no cache flush after initializing the scratchpad
buffer array with the scratchpad buffer pointers. This leads to a failure
of the "slot enable" command on the rpi4 board (Broadcom STB PCIe
controller + VL805 USB hub) - the very first TRB transfer on the command
ring fails and there is a timeout while waiting for the command completion
event. After adding the missing cache flush everything seems to be working
as expected.

Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Signed-off-by: Matthias Brugger <mbrugger@suse.com>

Merge tag 'for-v2020.10' of https://gitlab.denx.de/u-boot/custodians/u-boot-i2c

i2c changes for v2020.10
- Add support for I2C controllers found on Octeon II/III and Octeon TX
  TX2 SoC platforms.
- Add I2C controller support for Cortina Access CAxxxx SoCs
- new rtc methods, rtc command, and tests
- imx_lpi2c: Improve the codes to use private data
- stm32f7_i2c.c: Add new compatible "st,stm32mp15-i2c"
- stm32f7_i2c.c: Add Fast Mode Plus support
- pwm: Add PWM driver for SiFive SoC

Merge https://gitlab.denx.de/u-boot/custodians/u-boot-marvell

- Armada 38x DDR3 fixes, enhancements (Chris)
- Armada 38x UTMI PHY SerDes fix (Chris)
- Helios4 update - sync with clearfog (Dennis)
- LaCie Kirkwood board rework - enable DM (Simon)
- net/mvpp2 memory init fix (Sven)

net: mvpp2: fix second cp110 initialization

Since the mdio code got upstreamed it is not possible
to activate network ports on CP110 Master and Slave.

The problem is in mvpp2_base_probe which is called for each
CP110 and it initializes the buffer area for descs and rx_buffers.

This should only happen once though and the bd space is actually
set to 0 after the first run of the function.

This leads to an error when the second CP110 tries the initialization
again and disables all network ports on this CP110.

This patch adds a static variable to check if the buffer area is
initialized only once globally.

Signed-off-by: Sven Auhagen <sven.auhagen@voleatech.de>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: kirkwood: enable DM_ETH for LaCie board

This patch enables DM_ETH for the following Kirkwood-based LaCie boards:

- d2 Network v2
- Internet Space v2
- 2Big Network v2
- Network Space v2
- Network Space Lite v2
- Network Space Max v2
- Network Space Mini v2

Signed-off-by: Simon Guinot <simon.guinot@sequanux.org>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: kirkwood: enable DM_USB for LaCie board

This patch enables DM_USB and USB_STORAGE for the following
Kirkwood-based LaCie boards:

- d2 Network v2
- Internet Space v2
- 2Big Network v2
- Network Space v2
- Network Space Lite v2
- Network Space Max v2

Signed-off-by: Simon Guinot <simon.guinot@sequanux.org>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: kirkwood: switch LaCie boards to sata_mv driver

This patch switches the SATA driver from mvsata_ide to sata_mv for the
following Kirkwood-based LaCie boards:

- d2 Network v2
- Internet Space v2
- 2Big Network v2
- Network Space v2
- Network Space Lite v2
- Network Space Max v2
- Network Space Mini v2

Signed-off-by: Simon Guinot <simon.guinot@sequanux.org>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: kirkwood: convert LaCie boards to DM_SPI_FLASH

This patch converts the following Kirkwood-based LaCie boards to DM,
DM_SPI and DM_SPI_FLASH:

- d2 Network v2
- Internet Space v2
- 2Big Network v2
- Network Space v2
- Network Space Lite v2
- Network Space Max v2
- Network Space Mini v2

Signed-off-by: Simon Guinot <simon.guinot@sequanux.org>
Reviewed-by: Stefan Roese <sr@denx.de>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>

arm: kirkwood: add DT spi0 alias to LaCie boards

The spi0 alias is needed by the environment code to retrieve the SPI
flash. This patch adds some -u-boot.dtsi files, providing the spi0
aliases, for all the following Kirkwood-based LaCie boards:

- d2 Network v2
- Internet Space v2
- 2Big Network v2
- Network Space v2
- Network Space Lite v2
- Network Space Max v2
- Network Space Mini v2

Note that this -u-boot.dtsi files will be removed as soon as the spi0
aliases will be available in the upstream Linux dtsi files.

Signed-off-by: Simon Guinot <simon.guinot@sequanux.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>

arm: mvebu: helios4: sync helios4 config to clearfog and dts to kernel

The helios4 is built on the same microsom as the clearfog, by syncing the config
we enable the same featureset that exists in the som on the helios4. The current
config does not boot as some of the clearfog changes needed to be made on the
helios4 also, generally speaking most changes for the clearfog should also be
made on the helios4.

Signed-off-by: Dennis Gilmore <dennis@ausil.us>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: mvebu: a38x: Adjust UTMI PHY parameters

When running USB compliance tests on our Armada-385 hardware platforms
we have seen some eye mask violations. Marvell's internal documentation
says: Based on silicon test results, it is recommended to change the
impedance calibration threshold setting to 0x6 prior to calibration.

Port changes from Marvell's u-boot fork[1] to address this.

[1] - https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/commit/a6221551

Signed-off-by: Chris Packham <judge.packham@gmail.com>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: mvebu: a38x: Fix typo

Fix spelling of Alignment.

Signed-off-by: Chris Packham <judge.packham@gmail.com>
Reviewed-by: Stefan Roese <sr@denx.de>

mv_ddr: ddr3: Update {min,max}_read_sample calculation

Measurements on actual hardware shown that the read ODT is early by 3
clocks. Adjust the calculation to avoid this.

Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
[upstream https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell/pull/22]
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Tested-by: Baruch Siach <baruch@tkos.co.il>
Reviewed-by: Stefan Roese <sr@denx.de>

mv_ddr: ddr3: Use correct bitmask for read sample delay

In the Armada 385 functional spec (MV-S109094-00 Rev. C) the read sample
delay fields are 5 bits wide. Use the correct bitmask of 0x1f when
extracting the value.

Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
[upstream https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell/pull/22]
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Reviewed-by: Stefan Roese <sr@denx.de>

x86: apl: Re-enable loading of SPL

At present the SPL loader is not included in the TPL image so SPL cannot
be loaded. Fix it by including this file for both SPL and TPL.

Signed-off-by: Simon Glass <sjg@chromium.org>
Fixes: c87f9ce2273 ("x86: Don't build some unused objects in TPL")
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

spi: Remove unnecessary #ifdefs in header file

These prevent use of compile-time checks such as:

    if (CONFIG_IS_ENABLED(DM_SPI))

since, for example, if CONFIG_SPL_DM_SPI is not enabled then the
definitions are not included by spi.h and the C code will not build.

The #ifdefs are unnecessary since there are no conflicts with the pre-DM
code. In any case we have almost switched over to driver model for SPI.

Drop these #ifdefs from spi.h to fix a build warning on chromebook_coral
in the following patch.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

bootstage: Fix 'stacked' typo

This should be 'stashed'. Fix it.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

linux/kconfig.h: create two- and three-argument versions of CONFIG_IS_ENABLED

This adds a bunch of preprocessor magic to extend the capabilities of
CONFIG_IS_ENABLED. The existing semantics of

  CONFIG_IS_ENABLED(FOO)

expanding to a 1 or 0 (depending on build context and the defined-ness
or not of the appropriate CONFIG_FOO/CONFIG_SPL_FOO/CONFIG_TPL_FOO)
are of course preserved. With this, one is also allowed a two-argument
form

  CONFIG_IS_ENABLED(FOO, (something))

which expands to something precisely when CONFIG_IS_ENABLED(FOO) would
expand to 1, and expands to nothing otherwise. It is, in other words,
completely equivalent to the three lines

  #if CONFIG_IS_ENABLED(FOO)
  something
  #endif

The second argument must be parenthesized in order to allow any
tokens, including a trailing comma, to appear - one use case for this
is precisely to make it a bit more ergonomic to build an array and
only include certain items depending on .config. That should increase
both readability and not least "git grep"ability.

A third variant is also introduced,

  CONFIG_IS_ENABLED(FOO, (xxx), (yyy))

which corresponds to

  #if CONFIG_IS_ENABLED(FOO)
  xxx
  #else
  yyy
  #endif

Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>

linux/kconfig.h: remove unused helper macros

U-Boot does not have loadable modules, and nothing currently uses any
of the (CONFIG_)?IS_(BUILTIN|MODULE) macros - only
the (CONFIG_)?IS_ENABLED variants are ever used.

While I understand the desire to keep this somewhat synchronized with
linux, we've already departed by the introduction of the
CONFIG_IS_ENABLED extra logic, and deleting these makes the next patch
much simpler, since I won't have to duplicate a lot of logic for no
real gain (as there are no users).

Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>

linux/kconfig.h: simplify logic for choosing CONFIG_{SPL_, TPL_, }*

Instead of using the arg1_or_junk trick to pick between two choices,
with a bit of duplication between the branches (and most of the
CONFIG_TPL_BUILD case being redundant, as _IS_TPL is known to be
defined to 1 in that case), simply define a prefix that we inject
between CONFIG_ and the given config symbol.

This only requires one level of indirection (to get the
_CONFIG_PREFIX macro expanded before the token concatenation takes
place), and makes it easy to, say, introduce a CONFIG_HOSTTOOL_
prefix. [I would expect most HOSTTOOL_ symbols to just be def_bool y,
but it would allow us to clean up some of the ifdef HOSTCC mess in the
sources shared between U-Boot and host tools.]

Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>

arm: cmd_stm32prog: Fix the CONFIG_IS_ENABLED() usage

Add parentheses around CONFIG_IS_ENABLED() in the if statement, to
fix potential build failures.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@st.com>

x86: minnowmax: Drop screen resolution to 1024x768

This seems like a more reasonable resolution for this board, since it is
quite slow. It also allows it to work with a 5" LCD display in my lab.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>

minnowmax: Enable the copy framebuffer

Update the video driver to support this feature and enable it on
minnowmax to speed up the display.

With this change, the time taken to print the environment to the display
without CONFIG_CONSOLE_SCROLL_LINES is reduced from over 13 seconds to
300ms, at 1280x1024.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Anatolij Gustschin <agust@denx.de>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>

chromebook_link: Enable the copy framebuffer

Update the video driver to support this feature and enable it on link.
Also remove the multi-line scrolling since normal scrolling is fast enough
now.

With this change, the time taken to print the environment to the display
without CONFIG_CONSOLE_SCROLL_LINES is reduced from about 930ms to 29ms.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Anatolij Gustschin <agust@denx.de>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

chromebook_samus: Enable the copy framebuffer

Update the video driver to support this feature and enable it on samus.
Also remove the multi-line scrolling since normal scrolling is fast enough
now.

With this change, the time taken to print the environment to the display
without CONFIG_CONSOLE_SCROLL_LINES is reduced from about 430ms to 12ms.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Anatolij Gustschin <agust@denx.de>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

x86: video: Support copy framebuffer with probed devices

For PCI video devices that are not mentioned in the devicetree, U-Boot
does not bind a driver before relocation, since PCI is not fully probed
at that point. Furthermore it is possible for the video device to be on
a secondary bus which is not even scanned.

This is fine if the framebuffer is allocated in fixed memory, as it
normally is on x86. But when using this as a copy framebuffer, we also
need U-Boot to allocate its own cached framebuffer for working in. Since
the video driver is never bound before relocation, the framebuffer size
is never set and U-Boot does no allocation.

Add a new CONFIG option to reserve 16MB of memory for this eventuality.
This allows vesa devices to use the copy framebuffer.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Anatolij Gustschin <agust@denx.de>
Tested-by: Bin Meng <bmeng.cn@gmail.com>

video: Correctly handle multiple framebuffers

At present video_bottom is set to the bottom of each framebuffer when it
is allocated. This is not correct, since it should hold the bottom of the
entire area available for framebuffers.

Fix this by adding a private address in the uclass which keeps track of
the next available spot for a framebuffer.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Anatolij Gustschin <agust@denx.de>
Tested-by: Bin Meng <bmeng.cn@gmail.com>

x86: fsp: video: Allocate a frame buffer when needed

When the copy framebuffer is in use, we must also have the standard U-Boot
framebuffer available. Update the FSP driver to support this.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Anatolij Gustschin <agust@denx.de>
Tested-by: Bin Meng <bmeng.cn@gmail.com>

video: pci: Set up the copy framebuffer

When using a copy framebuffer we need to tell the video subsystem its
address. U-Boot's normally allocated framebuffer is used as the working
buffer, but nothing is displayed until it is copied to the copy
framebuffer.

For this to work the video driver must request that a framebuffer be
allocated separately from the hardware framebuffer, so add a check for
that.

Also add a log category so that logging appears correctly.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Anatolij Gustschin <agust@denx.de>
Tested-by: Bin Meng <bmeng.cn@gmail.com>

video: sandbox: Add support for the copy framebuffer

Enable this feature on sandbox by updating the SDL driver to have two
framebuffers.

Update the video tests to check that the copy framebuffer is kept in sync.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Anatolij Gustschin <agust@denx.de>

video: Add comments to struct sandbox_sdl_plat

This struct is not commented but needs it. Also fix the comment in
check_vidconsole_output() about the encoding for the rotation value.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Anatolij Gustschin <agust@denx.de>

video: Update the copy framebuffer when writing bitmaps

Adjust the bitmap code to sync to the copy framebuffer when done.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Anatolij Gustschin <agust@denx.de>
Tested-by: Bin Meng <bmeng.cn@gmail.com>

video: Update rotated console to support copy buffer

Update the implementation to keep a track of what it changes in the frame
buffer and then tell the copy buffer about it. Use the special
vidconsole_memmove() helper so that memmove() operations are also
reflected in the copy buffer.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Anatolij Gustschin <agust@denx.de>
Tested-by: Bin Meng <bmeng.cn@gmail.com>

video: Update truetype console to support copy buffer

Update the implementation to keep a track of what it changes in the frame
buffer and then tell the copy buffer about it. Use the special
vidconsole_memmove() helper so that memmove() operations are also
reflected in the copy buffer.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Anatolij Gustschin <agust@denx.de>
Tested-by: Bin Meng <bmeng.cn@gmail.com>

video: Update normal console to support copy buffer

Update the implementation to keep a track of what it changes in the frame
buffer and then tell the copy buffer about it. Use the special
vidconsole_memmove() helper so that memmove() operations are also
reflected in the copy buffer.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Anatolij Gustschin <agust@denx.de>
Tested-by: Bin Meng <bmeng.cn@gmail.com>

video: Add helpers for vidconsole for the copy framebuffer

Add a convenience function to call video_sync_copy() for a vidconsole.
Also add a memmove() helper, which does the memmove() as well as the sync.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Anatolij Gustschin <agust@denx.de>
Tested-by: Bin Meng <bmeng.cn@gmail.com>

video: Clear the copy framebuffer when clearing the screen

Update video_clear() to also sync to the copy framebuffer.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Anatolij Gustschin <agust@denx.de>
Tested-by: Bin Meng <bmeng.cn@gmail.com>

video: Set up the copy framebuffer when enabled

This framebuffer is separately mapped. Update the video post-probe
function to set this up.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Anatolij Gustschin <agust@denx.de>
Tested-by: Bin Meng <bmeng.cn@gmail.com>

video: Add support for copying to a hardware framebuffer

Some architectures use a cached framebuffer and flush the cache as needed
so that changes are visible. This is supported by U-Boot.

However x86 uses an uncached framebuffer with a 'write-combining' feature
to speed up writes.  Reads are permitted but they are extremely expensive.

Unfortunately, reading from the frame buffer is quite common, e.g. to
scroll it. This makes scrolling very slow.

Add a new feature which supports copying modified parts of the frame
buffer to the uncached hardware buffer. This speeds up scrolling by at
least 10x on x86 so the extra complexity cost seems worth it.

As a starting point, add the Kconfig, update the video structures to keep
track of the buffer and add a function to do the copy.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Anatolij Gustschin <agust@denx.de>
Tested-by: Bin Meng <bmeng.cn@gmail.com>

video: Add a comment for struct video_uc_platdata

Add a few notes to explain the purpose of each member of this struct.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Anatolij Gustschin <agust@denx.de>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

video: Drop unnecessary #ifdef around vid_console_color()

All of the functions in this file only apply if DM_VIDEO is enabled. Drop
the #ifdef as it just clutters things up. Add the needed forward
declaration.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Anatolij Gustschin <agust@denx.de>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

video: Adjust rotated console to start at right edge

At present when the console is rotated 180 degrees it starts almost a
whole character to the left of the right edge (typically 7 pixels with
an 8-pixel-wide font). On a display which aligns with the font width,
this just wastes space. On a display that does not this can result in
x_frac going negative for the final character (the one on the left
side) and the overflow -EAGAIN check at the start of the function
failing.

Change the function to start at the rightmost pixel to fix these
problems.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Anatolij Gustschin <agust@denx.de>
Tested-by: Bin Meng <bmeng.cn@gmail.com>

video: Split out expression parts into variables

The functions in this file do similar things but not always in the same
way. To make the code easier to read and compare, use a separate 'linenum'
variable in every function. This is then multiplied by the line length to
get the offset within the frame buffer to modify. Also use an 'x' variable
to hold the pixel position within that line. This is multipled by the
pixel size and added to the offset.

Also move the pbytes declaration up a little with the other long lines.

A side effect of splitting out these variables is that they are promoted
to int, i.e. a signed type, from the unsigned short used in the
vidconsole_priv struct. This would be necessary should any of the
variables go negative. At present this can actually happen in
console_putc_xy_2(), if the display width is not a multiple of the
character size (see next patch).

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Anatolij Gustschin <agust@denx.de>
Tested-by: Bin Meng <bmeng.cn@gmail.com>

sandbox: video: Allow selection of rotated console

Add a devicetree property to select a rotated console. This uses the same
encoding as vidconsole itself: 0=normal; 1=90 degrees clockwise, 2=upside
down, 3=90 degrees anticlockwise.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Anatolij Gustschin <agust@denx.de>

video: Show an error when a vidconsole function fails

At present these functions fail silently even when debugging, which is not
very helpful. Add a way to print a message to the serial output when an
error is detected.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Anatolij Gustschin <agust@denx.de>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

console: Add a way to output to serial only

In the video drivers it is useful to print errors while debugging but
doing so risks an infinite loop as the debugging info itself may go
through the video drivers.

Add a new console function that prints information only to the serial
device, thus making it safe for use in debugging.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

x86: fsp: Reinit the FPU after FSP meminit

The APL FSP appears to leave the FPU in a bad state in that it has
registers in use. This causes an error when the next FPU operation is
performed.

Work around this by re-resetting the FPU after calling FSP-M. This allows
the freetype console to work correctly.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

pwm: Add PWM driver for SiFive SoC

Adds a PWM driver for PWM chip present in SiFive's HiFive Unleashed SoC
This driver is simple port of Linux pwm sifive driver from Linux v5.6

commit: 9e37a53eb051 ("pwm: sifive: Add a driver for SiFive SoC PWM")

Signed-off-by: Yash Shah <yash.shah@sifive.com>
Reviewed-by: Heiko Schocher <hs@denx.de>

pwm: Add DT documentation for SiFive PWM Controller

DT documentation for PWM controller added from Linux v5.6

commit: daa78cc3408e
("pwm: sifive: Add DT documentation for SiFive PWM Controller")

Signed-off-by: Yash Shah <yash.shah@sifive.com>
Reviewed-by: Heiko Schocher <hs@denx.de>

i2c: stm32f7: SYSCFG Fast Mode Plus support for I2C STM32F7

Read SYSCFG bindings to set Fast Mode Plus bits if Fast Mode Plus
speed is selected.

Handle the stm32mp15 specific compatible to handle FastMode+
registers handling which is different on the stm32mp15 compared
to the stm32f7 or stm32h7.
Indeed, on the stm32mp15, the FastMode+ set and clear registers
are separated while on the other platforms (F7 or H7) the control
is done in a unique register.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
Reviewed-by: Heiko Schocher <hs@denx.de>

i2c: stm32f7: add stm32mp15 compatible

Add a new compatible "st,stm32mp15-i2c" introduced in Linux kernel v5.8

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
Reviewed-by: Heiko Schocher <hs@denx.de>

test: dm: rtc: add tests of rtc shell command

Add tests of the "list", "read" and "write" subcommands of the rtc
shell command.

Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heiko Schocher <hs@denx.de>
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>

sandbox: add rtc command to defconfigs

In order to allow adding unit tests of the rtc command, add it to the
various sandbox defconfigs.

Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>

test: dm: rtc: add test of dm_rtc_read, dm_rtc_write

Define a few aux registers and check that they can be read/written
individually. Also check that one can access the time-keeping
registers directly and get the expected results.

Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heiko Schocher <hs@denx.de>
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>

rtc: i2c_rtc_emul: catch any write to the "reset" register

It's more natural that any write that happens to touch the reset
register should cause a reset, rather than just a write that starts at
that offset.

Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heiko Schocher <hs@denx.de>
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>

rtc: sandbox-rtc: fix set method

The current set method is broken; a simple test case is to first set
the date to something in April, then change the date to 31st May:

=> date 040412122020.34
Date: 2020-04-04 (Saturday)    Time: 12:12:34
=> date 053112122020.34
Date: 2020-05-01 (Friday)    Time: 12:12:34

or via the amending of the existing rtc_set_get test case similarly:

$ ./u-boot -T -v
=> ut dm rtc_set_get
Test: dm_test_rtc_set_get: rtc.c
expected: 31/08/2004 18:18:00
actual: 01/08/2004 18:18:00

The problem is that after each register write,
sandbox_i2c_rtc_complete_write() gets called and sets the internal
time from the current set of registers. However, when we get to
writing 31 to mday, the registers are in an inconsistent state (mon is
still 4), so the mktime machinery ends up translating April 31st to
May 1st. Upon the next register write, the registers are populated by
sandbox_i2c_rtc_prepare_read(), so the 31 we just wrote to mday gets
overwritten by a 1.

Fix it by writing all registers at once, and for consistency, update
the get method to retrieve them all with one "i2c transfer".

Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heiko Schocher <hs@denx.de>
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>

rtc: add rtc command

Mostly as an aid for debugging RTC drivers, provide a command that can
be used to read/write arbitrary registers (assuming the driver
provides the read/write methods or their single-register-at-a-time
variants).

Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heiko Schocher <hs@denx.de>
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>

rtc: pcf2127: provide ->write method

Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heiko Schocher <hs@denx.de>
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>

rtc: pcf2127: provide ->read method

This simply consists of renaming the existing pcf2127_read_reg()
helper to follow the naming of the other
methods (i.e. pcf2127_rtc_<method name>) and changing the type of its
"len" parameter.

Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heiko Schocher <hs@denx.de>
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>

rtc: fall back to ->{read, write} if ->{read, write}8 are not provided

Similar to how the dm_rtc_{read,write} functions fall back to using
the {read,write}8 methods, do the opposite in the rtc_{read,write}8
functions.

This way, each driver only needs to provide either ->read8 or ->read
to make both rtc_read8() and dm_rtc_read() work - without this, a
driver that provides ->read() would most likely just duplicate the
logic here for implementing a ->read8() method in term of its ->read()
method. The same remarks of course apply to the write case.

Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heiko Schocher <hs@denx.de>
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>

rtc: add dm_rtc_write() helper

Similar to dm_rtc_read(), introduce a helper that allows the caller to
write multiple consecutive 8-bit registers with one call. If the
driver provides the ->write method, use that, otherwise loop using
->write8.

Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heiko Schocher <hs@denx.de>
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>

rtc: add dm_rtc_read helper and ->read method

Some users may want to read multiple consecutive 8-bit
registers. Instead of each caller having to implement the loop,
provide a dm_rtc_read() helper. Also, allow a driver to provide a
->read method, which can be more efficient than reading one register
at a time.

Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heiko Schocher <hs@denx.de>
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>

i2c: imx_lpi2c: Improve the codes to use private data

Current driver calls the devfdt_get_addr to get the base address
of lpi2c controller in each sub-functions. Since the devfdt_get_addr
accesses the DTB and translate the address, it introduces much
overhead.
Improve the codes to use private variable which has recorded the
base address from probe.

Signed-off-by: Ye Li <ye.li@nxp.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>

board: presidio-asic: Add I2C support

Add I2C board support for Cortina Access Presidio Engineering Board

Signed-off-by: Alex Nemirovsky <alex.nemirovsky@cortina-access.com>
CC: Heiko Schocher <hs@denx.de>
Reviewed-by: Heiko Schocher <hs@denx.de>

i2c: i2c-cortina: added CAxxxx I2C support

Add I2C controller support for Cortina Access CAxxxx SoCs

Signed-off-by: Arthur Li <arthur.li@cortina-access.com>
Signed-off-by: Alex Nemirovsky <alex.nemirovsky@cortina-access.com>
CC: Heiko Schocher <hs@denx.de>
Reviewed-by: Heiko Schocher <hs@denx.de>
hs: fixed build error, add include log.h

i2c: octeon_i2c: Add I2C controller driver for Octeon

Add support for I2C controllers found on Octeon II/III and Octeon TX
TX2 SoC platforms.

Signed-off-by: Aaron Williams <awilliams@marvell.com>
Signed-off-by: Suneel Garapati <sgarapati@marvell.com>
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Heiko Schocher <hs@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Cc: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Cc: Aaron Williams <awilliams@marvell.com>
Cc: Chandrakala Chavva <cchavva@marvell.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heiko Schocher <hs@denx.de>
Reviewed-by: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com>

Merge branch '2020-07-08-misc-features-and-fixes'

- mem cmd improvements
- TPM fixes
- SPL/NAND/FIT fixes
- RSA improvements

lib: rsa: function to verify a signature against a hash

rsa_verify() expects a memory region and wants to do the hashing itself,
but there may be cases where the hashing is done via other means,
like hashing a squashfs rootfs.

So add rsa_verify_hash() to allow verifiying a signature against
an existing hash. As this entails the same verification routines
we can just move the relevant code over from rsa_verify() and also
call rsa_verify_hash() from there.

Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com>

cmd: Add a memory-search command

It is useful to be able to find hex values and strings in a memory range.
Add a command to support this.

cmd: Fix 'md' and add a memory-search command
At present 'md.q' is broken. This series provides a fix for this. It also
implements a new memory-search command called 'ms'. It allows searching
memory for hex and string data.
END

Signed-off-by: Simon Glass <sjg@chromium.org>

command: Drop #ifdef for MEM_SUPPORT_64BIT_DATA

This is defined only when __lp64__ is defined. That means that ulong is
64 bits long. Therefore we don't need to use a separate u64 type on those
architectures.

Fix up the code to take advantage of that, removing the preprocessor
conditions.

Also include the header file that defines MEM_SUPPORT_64BIT_DATA. It is
included by env.h in this file, but that might not last forever.

Signed-off-by: Simon Glass <sjg@chromium.org>

display_options: Drop #ifdef for MEM_SUPPORT_64BIT_DATA

This is defined only when __lp64__ is defined. That means that ulong is
64 bits long. Therefore we don't need to use a separate u64 type on those
architectures.

Fix up the code to take advantage of that, removing the preprocessor
conditions.

Also include the missing header file that defines MEM_SUPPORT_64BIT_DATA

Fixes: 09140113108 ("command: Remove the cmd_tbl_t typedef")
Signed-off-by: Simon Glass <sjg@chromium.org>