upl: Add basic tests

Add some unit tests to check that we can write a UPL handoff and read it
back.

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

upl: Add support for writing a upl handoff

Universal Payload provides a standard way of handing off control between
two firmware phases. Add support for writing the handoff information from
a structure.

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

upl: Add support for reading a upl handoff

Universal Payload provides a standard way of handing off control between
two firmware phases. Add support for reading the handoff information into
a structure.

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

sandbox: Set up global_data earlier

It is possible for U-Boot functions such as printf() to be called
within state_init(). This can end up checking gd->flags (e.g. in putc())
before global_data is set up.

Move the setup earlier to avoid this. This fixes the suppression of some
debug output in memory allocation (when enabled).

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

sandbox: Add ELF file to VPL u-boot.img

At present sandbox builds package up u-boot.bin in the .img file. This
cannot actually be executed, since it is not an ELF file.

For sandbox_vpl we want to be able to run the full boot flow.

Adjust the build rule for sandbox_vpl to package the ELF file and
thereby allow full testing of the sandbox transition from SPL to U-Boot
proper.

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

sandbox: Return error code from read/write/seek

The existing API for these functions is different from the rest of
U-Boot, in that any error code must be obtained from the errno variable
on failure. This variable is part of the C library, so accessing it
outside of the special 'sandbox' shim-functions is not ideal.

Adjust the API to return an error code, to avoid this. Update existing
uses to check for any negative value, rather than just -1.

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

sandbox: fdt: Avoid overwriting an existing fdt

Since the removal of OF_HOSTFILE logic in board_fdt_blob_setup(), the
logic for obtaining the DT is handled in the OF_BOARD option. If a
devicetree comes from a bloblist it is immediately overwritten by this
function.

Fix this by skipping the function if a devicetree is already present.

This is sort-of a fix for e7fb7896 ("sandbox: Remove OF_HOSTFILE") but
it has only come to light since bloblist was added, so I have not added
a Fixes tag.

Unfortunately it is not possible to report the correct FDT source with
the current code. It might be best to use an error-return code for
board_fdt_blob_setup() so that an error can be reported if the board
does not provide the DT.

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

fdt: Don't overwrite bloblist devicetree

When the devicetree comes from a bloblist, it is currently overwritten
by the appended one, if present. It should be preserved.

Adjust the logic to support this.

Fixes: 70fe2385943 ("fdt: Allow the devicetree to come from a bloblist")
Signed-off-by: Simon Glass <sjg@chromium.org>

test: Move some SPL-loading test-code into sandbox common

This code is useful for loading an image in sandbox_spl so move it into
a place where it can be called as needed.

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

sandbox: Fix a comment in os_find_u_boot()

Fix a missing dot in a comment, since '..' is confusing.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>

sandbox: Use const in os_jump_to_file()

The argument array is not changed by the callee, so mark it const.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>

Merge tag 'tpm-master-09082024' of https://source.denx.de/u-boot/custodians/u-boot-tpm.git

Back when the TPM subsystem was refactored tpm_tis_wait_init() ended up
being called after tpm_tis_init() which initializes values the former needs.

Since we added more TPM chipsets since then sitting on an i2c bus, this patch
folds in tpm_tis_wait_init into tpm_tis_init and makes sure it's called in the
right order regardless of the bus the TPM sits on.

Merge tag 'i2cupdates-for-v2024-10-next' of https://source.denx.de/u-boot/custodians/u-boot-i2c into next

i2c updates for v2024.10 next

- DM_I2C conversion for some remaining boards
  from Anatolij

Merge tag 'i2cfixes-v2-for-v2024-10-rc3' of https://source.denx.de/u-boot/custodians/u-boot-i2c

i2c updates for v2024.10-rc3 (second try)

- i2c: samsung: Support platforms other than EXYNOS4 and EXYNOS5
  from David

- imx_lpi2c: cleanups and support read transfers longer than 256 bytes
  from Fedor

- pca954x: Remove pointer to GD
  from Michal

- i2c: mux: Fix error path in i2c-arb-gpio
  from Michal

i2c: imx_lpi2c: Support read transfers longer than 256 bytes

The TXFIFO register of LPI2C only has one byte length, and if the length
of the data that needs to be read exceeds 256 bytes, it needs to be
written to TXFIFO multiple times.

Signed-off-by: Fedor Ross <fedor.ross@ifm.com>

i2c: imx_lpi2c: Replace hard-coded bus speed value with bus->speed_hz

Instead of using the hard-coded bus speed value I2C_SPEED_STANDARD_RATE,
use the actual configured bus speed. This way the bus speed doesn't
change suddenly after calling the imx_lpi2c_probe_chip() function for
example.

Signed-off-by: Fedor Ross <fedor.ross@ifm.com>

i2c: imx_lpi2c: Fix a typo in bus_i2c_receive

Fix a typo in a debug message. It should be 'for' not 'fot' .

Signed-off-by: Fedor Ross <fedor.ross@ifm.com>

i2c: samsung: Support platforms other than EXYNOS4 and EXYNOS5

Newer Samsung SoCs (including newer Exynos, ExynosAuto, Google Tensor)
still use these IPs, or slightly newer versions of it.

Make these drivers available on these platforms by guarding
EXYNOS4/EXYNOS5 specific code behind their configs, and using CCF for
clocks on other platforms.

Tested S3C I2C driver on Exynos7885.
This along with extended clock driver should enable S3C I2C on
Exynos850.

Signed-off-by: David Virag <virag.david003@gmail.com>
Tested-by: Henrik Grimler <henrik@grimler.se>
Reviewed-by: Heiko Schocher <hs@denx.de>

i2c: samsung: Drop s3c24x0 specific code.

This has been dead code for many years now. Remove it.

Signed-off-by: David Virag <virag.david003@gmail.com>
Reviewed-by: Heiko Schocher <hs@denx.de>

i2c: mux: Fix error path in i2c-arb-gpio

There is no reason to use goto and just call return. Better is to call
return directly which is done for some if/else parts.

Also make no sense to setup ret to -ETIMEDOUT and then to 0.
Return timeout directly.

Signed-off-by: Michal Simek <michal.simek@amd.com>
Reviewed-by: Heiko Schocher <hs@denx.de>

i2c: pca954x: Remove pointer to GD

There is no reason to have any pointer to GD that's why remove it.

Signed-off-by: Michal Simek <michal.simek@amd.com>
Reviewed-by: Heiko Schocher <hs@denx.de>

arm64: dts: rockchip: add ROCK 5 ITX board

The ROCK 5 ITX as the name suggests is made in the ITX form factor and
actually built in a form to be used in a regular case even providing
connectors for regular front-panel io.

It can be powered either by 12V, ATX power-supply or PoE.

Notable peripherals are the 4 SATA ports, M.2 M-Key slot, M.2 E-key slot,
2*2.5Gb PCIe-connected Ethernet NICs.

As of yet unsupported display options consist of 2*HDMI, DP via USB-c,
eDP + 2*DSI via PCB connectors.

USB ports are 4*USB3 + 2*USB2 on the back panel and 2-port front-panel
connector.

Schematics for the board can be found on
- https://dl.radxa.com/rock5/5itx/radxa_rock_5_itx_X1100_schematic.pdf
- https://dl.radxa.com/rock5/5itx/v1110/radxa_rock_5itx_v1110_schematic.pdf

Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20240704153815.837392-3-heiko@sntech.de
[ upstream commit: 31390eb8ffbf2b6be7d789708ec08b635d7a3eb8 ]

(cherry picked from commit 9cff9fef0a295e3b8feb7bc4116a297a842cad01)
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

arm64: dts: rockchip: add thermal zones information on RK3588

This includes the necessary device tree data to allow thermal
monitoring on RK3588(s) using the on-chip TSADC device, along with
trip points for automatic thermal management.

Each of the CPU clusters (one for the little cores and two for
the big cores) get a passive cooling trip point at 85C, which
will trigger DVFS throttling of the respective cluster upon
reaching a high temperature condition.

All zones also have a critical trip point at 115C, which will
trigger a reset.

Signed-off-by: Alexey Charkov <alchark@gmail.com>
Link: https://lore.kernel.org/r/20240617-rk-dts-additions-v5-1-c1f5f3267f1e@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
[ upstream commit: 510cd9e688453166b2bff3999ed21cac97385bb5 ]

(cherry picked from commit 33e7079543d5eee1415b937054e8634000d1bde4)
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

arm64: dts: rockchip: Prepare RK3588 SoC dtsi files for per-variant OPPs

Rename the Rockchip RK3588 SoC dtsi files and, consequently, adjust their
contents appropriately, to prepare them for the ability to specify different
CPU and GPU OPPs for each of the supported RK3588 SoC variants.

As already discussed, [1][2][3][4] some of the RK3588 SoC variants require
different OPPs, and it makes more sense to have the OPPs already defined when
a board dts(i) file includes one of the SoC variant dtsi files (rk3588.dtsi,
rk3588j.dtsi or rk3588s.dtsi), rather than requiring the board dts(i) file
to also include a separate rk3588*-opp.dtsi file.  The choice of the SoC
variant is already made by the inclusion of the SoC dtsi file into the board
dts(i) file, and it doesn't make much sense to, effectively, allow the board
dts(i) file to include and use an incompatible set of OPPs for the already
selected RK3588 SoC variant.

The new naming scheme for the RK3588 SoC dtsi files uses "-base" and "-extra"
suffixes to denote the DT data shared between all RK5588 SoC variants, and
the DT data shared between the unrestricted SoC variants, respectively.
For example, the DT data for the RK3588 includes both rk3588-base.dtsi and
rk3588-extra.dtsi, because it's an unrestricted SoC variant, while the DT
data for the RK3588S variant includes rk3588-base.dtsi only, because it's
a restricted SoC variant, feature- and interface-wise.  This achieves a more
logical naming of the RK3588 SoC dtsi files, which reflects the way DT data
for the SoC variants is built by "stacking" the SoC variant features made
available through the "-base" and "-extra" SoC dtsi files.  Additionally,
the SoC variant dtsi files (rk3588.dtsi, rk3588j.dtsi and rk3588s.dtsi) are
no longer parents to any other SoC variant dtsi files, which should help with
making the new "stacking" approach cleaner and easier to follow.

The RK3588 pinctrl dtsi files are also renamed in the same way, for the sake
of consistency.  This also keeps the "-base" and "-extra" groups of the dtsi
files together when looked at in a directory listing, which is helpful.

The per-SoC-variant OPPs should go directly into the SoC dtsi files, if no
more than one SoC variant uses those OPPs, or be put into a separate "-opp"
dtsi file that's shared between and included from two or more SoC variant
dtsi files.  An example for the former is the non-shared OPP data that should
go directly into the RK3588J SoC variant dtsi file (i.e. rk3588j.dtsi), and
an example for the latter is the shared OPP data that should be put into
rk3588-opp.dtsi and be included from the RK3588 and RK3588S SoC variant dtsi
files (i.e. rk3588.dtsi and rk3588s.dtsi, respectively).  Consequently, if
the OPPs for the RK3588 and RK3588S SoC variants are ever made different,
the shared rk3588-opp.dtsi file should be deleted and the new OPPs should
be put directly into rk3588.dtsi and rk3588s.dtsi. [4]

No functional changes are introduced, which was validated by decompiling and
comparing all affected dtb files before and after these changes.

As a side note, due to the nature of introduced changes, this commit is best
viewed using the --break-rewrites option for git-log(1).

[1] https://lore.kernel.org/linux-rockchip/646a33e0-5c1b-471c-8183-2c0df40ea51a@cherry.de/
[2] https://lore.kernel.org/linux-rockchip/CABjd4Yxi=+3gkNnH3BysUzzYsji-=-yROtzEc8jM_g0roKB0-w@mail.gmail.com/
[3] https://lore.kernel.org/linux-rockchip/035a274be262528012173d463e25b55f@manjaro.org/
[4] https://lore.kernel.org/linux-rockchip/673dcf47596e7bc8ba065034e339bb1bbf9cdcb0.1716948159.git.dsimic@manjaro.org/T/#u

Signed-off-by: Dragan Simic <dsimic@manjaro.org>
Link: https://lore.kernel.org/r/9ffedc0e2ca7f167d9d795b2a8f43cb9f56a653b.1717923308.git.dsimic@manjaro.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
[ upstream commit: def88eb4d8365a4aa064d28405d03550a9d0a3be ]

(cherry picked from commit bf8f631f62026a6b844d34c7e0549e4ec3fd4716)
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

arm: dts: rockchip: disable "usb_host0_ohci" to make boot faster for Radxa ROCK 3A

on-board USB 2.0 hub, FE1.1s, has Transaction Translator which can
handle USB 1.x devices via "usb_host0_ehci". so we can omit
"usb_host0_ohci" and make boot faster (a little).

=> usb start
starting USB...
Bus usb@fd000000: Register 2000140 NbrPorts 2
Starting the controller
USB XHCI 1.10
Bus usb@fd800000: USB EHCI 1.00
Bus usb@fd880000: USB EHCI 1.00
Bus usb@fd8c0000: USB OHCI 1.0
scanning bus usb@fd000000 for devices... 1 USB Device(s) found
scanning bus usb@fd800000 for devices... 2 USB Device(s) found
scanning bus usb@fd880000 for devices... 1 USB Device(s) found
scanning bus usb@fd8c0000 for devices... 3 USB Device(s) found
       scanning usb for storage devices... 1 Storage Device(s) found
=> usb tree
USB device tree:
  1  Hub (5 Gb/s, 0mA)
     U-Boot XHCI Host Controller

  1  Hub (480 Mb/s, 0mA)
  |  u-boot EHCI Host Controller
  |
  +-2  Hub (480 Mb/s, 100mA)
        USB 2.0 Hub

  1  Hub (480 Mb/s, 0mA)
     u-boot EHCI Host Controller

  1  Hub (12 Mb/s, 0mA)
  |   U-Boot Root Hub
  |
  +-2  Hub (12 Mb/s, 100mA)
    |  ALCOR Generic USB Hub
    |
    +-3  Mass Storage (12 Mb/s, 300mA)
         JetFlash Mass Storage Device 02K1RNH5MJFV4TX6

=> usb reset
resetting USB...
Host not halted after 16000 microseconds.
Bus usb@fd000000: Register 2000140 NbrPorts 2
Starting the controller
USB XHCI 1.10
Bus usb@fd800000: USB EHCI 1.00
Bus usb@fd880000: USB EHCI 1.00
Bus usb@fd8c0000: USB OHCI 1.0
scanning bus usb@fd000000 for devices... 1 USB Device(s) found
scanning bus usb@fd800000 for devices... 4 USB Device(s) found
scanning bus usb@fd880000 for devices... 1 USB Device(s) found
scanning bus usb@fd8c0000 for devices... 1 USB Device(s) found
       scanning usb for storage devices... 1 Storage Device(s) found
=> usb tree
USB device tree:
  1  Hub (5 Gb/s, 0mA)
     U-Boot XHCI Host Controller

  1  Hub (480 Mb/s, 0mA)
  |  u-boot EHCI Host Controller
  |
  +-2  Hub (480 Mb/s, 100mA)
    |   USB 2.0 Hub
    |
    +-3  Hub (12 Mb/s, 100mA)
      |  ALCOR Generic USB Hub
      |
      +-4  Mass Storage (12 Mb/s, 300mA)
           JetFlash Mass Storage Device 02K1RNH5MJFV4TX6

  1  Hub (480 Mb/s, 0mA)
     u-boot EHCI Host Controller

  1  Hub (12 Mb/s, 0mA)
      U-Boot Root Hub

Signed-off-by: FUKAUMI Naoki <naoki@radxa.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

board: rockchip: Add FriendlyElec CM3588 NAS

The CM3588 NAS by FriendlyElec pairs the CM3588 compute module, based
on the Rockchip RK3588 SoC, with the CM3588 NAS Kit carrier board.

Features tested on a CM3588 NAS Kit with 8GB RAM 64GB eMMC module:
- SD-card boot
- eMMC boot
- Ethernet
- PCIe/NVMe
- USB gadget
- USB host

Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

arm64: dts: rockchip: Add FriendlyElec CM3588 NAS board

The CM3588 NAS by FriendlyElec pairs the CM3588 compute module, based on
the Rockchip RK3588 SoC, with the CM3588 NAS Kit carrier board.
To reflect the hardware setup, add device tree sources for the SoM and
the NAS daughter board as separate files.

Hardware features:
    - Rockchip RK3588 SoC
    - 4GB/8GB/16GB LPDDR4x RAM
    - 64GB eMMC
    - MicroSD card slot
    - 1x RTL8125B 2.5G Ethernet
    - 4x M.2 M-Key with PCIe 3.0 x1 (via bifurcation) for NVMe SSDs
    - 2x USB 3.0 (USB 3.1 Gen1) Type-A, 1x USB 2.0 Type-A
    - 1x USB 3.0 Type-C with DP AltMode support
    - 2x HDMI 2.1 out, 1x HDMI in
    - MIPI-CSI Connector, MIPI-DSI Connector
    - 40-pin GPIO header
    - 4 buttons: power, reset, recovery, MASK, user button
    - 3.5mm Headphone out, 2.0mm PH-2A Mic in
    - 5V Fan connector, PWM beeper, IR receiver, RTC battery connector

PCIe bifurcation is used to handle all four M.2 sockets at PCIe 3.0 x1
speed. Data lane mapping in the DT is done like described in commit
f8020dfb311d ("phy: rockchip-snps-pcie3: fix bifurcation on rk3588").

This device tree includes support for eMMC, SD card, ethernet, all USB2
and USB3 ports, all four M.2 slots, GPU, beeper, IR, RTC, UART debugging
as well as the buttons and LEDs.
The GPIOs are labeled according to the schematics.

Reviewed-by: Space Meyer <git@the-space.agency>
Signed-off-by: Sebastian Kropatsch <seb-dev@mail.de>
Link: https://lore.kernel.org/r/20240616215354.40999-3-seb-dev@mail.de
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
[ upstream commit: e23819cf273c110662fdc392dcb55a75b3888609 ]

(cherry picked from commit c1a8bf31d96d890dd8328ae452fe62971ac555c2)
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

board: rockchip: Add Xunlong Orange Pi 3B

The Xunlong Orange Pi 3B is a single-board computer based on the
Rockchip RK3566 SoC.

The two hw revisions use different io-voltage for Ethernet PHY and can
be identified using GPIO4_C4:
- v1.1.1: x (internal pull-down)
- v2.1:   PHY_RESET (external pull-up)

Implement rk_board_late_init() to set correct fdtfile env var and
board_fit_config_name_match() to load correct FIT config based on what
board is detected at runtime so a single board target can be used for
both hw revisions.

Minimal DTs that includ DT from dts/upstream is added to support booting
from both hw revision and only set Ethernet PHY io-voltage when the hw
revision is detected at runtime. A side-affect of this is that defconfig
show OF_UPSTREAM=n, however dts/upstream DTs is used for this board.

Features tested on Orange Pi 3B 4GB (v1.1.1 and v2.1):
- SD-card boot
- eMMC boot
- SPI Flash boot
- Ethernet
- PCIe/NVMe
- USB host

Signed-off-by: Ricardo Pardini <ricardo@pardini.net>
Co-developed-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

arm64: dts: rockchip: Add Xunlong Orange Pi 3B

The Xunlong Orange Pi 3B is a single-board computer based on the
Rockchip RK3566 SoC.

Add initial support for eMMC, SD-card, Ethernet, HDMI, PCIe and USB.

Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Link: https://lore.kernel.org/r/20240626230319.1425316-3-jonas@kwiboo.se
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
[ upstream commit: d79d713d602e8b32cf935ddfdf61769cb74ba1dc ]

(cherry picked from commit 9defe71f2674f82c27a8d4593d8c5851ab5d51e7)
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

board: rockchip: Add Radxa ZERO 3W/3E

The Radxa ZERO 3W/3E is an ultra-small, high-performance single board
computer based on the Rockchip RK3566, with a compact form factor and
rich interfaces.

Implement rk_board_late_init() to set correct fdtfile env var and
board_fit_config_name_match() to load correct FIT config based on what
board is detected at runtime so a single board target can be used for
both board models.

Features tested on a ZERO 3W 8GB v1.11:
- SD-card boot
- eMMC boot
- USB gadget
- USB host

Features tested on a ZERO 3E 4GB v1.2:
- SD-card boot
- Ethernet
- USB gadget
- USB host

Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Tested-by: FUKAUMI Naoki <naoki@radxa.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

dm: adc: Add SPL_ADC Kconfig symbol for use of ADC in SPL

What model of Radxa ZERO 3W/3E board can be identified using ADC at
runtime, add a Kconfig symbol to allow use of ADC in SPL.

This will be used to identify board model in SPL to allow loading
correct FIT configuration and FDT for U-Boot proper at SPL phase.

Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

arm64: dts: rockchip: add gpio-line-names to radxa-zero-3

Add names to the pins of the general-purpose expansion header as given
in the Radxa documentation[1] following the conventions in the kernel[2]
to make it easier for users to correlate pins with functions when using
utilities such as 'gpioinfo'.

[1] https://docs.radxa.com/en/zero/zero3/hardware-design/hardware-interface
[2] https://www.kernel.org/doc/Documentation/devicetree/bindings/gpio/gpio.txt

Signed-off-by: Trevor Woerner <twoerner@gmail.com>
Link: https://lore.kernel.org/r/20240620013301.33653-1-twoerner@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
[ upstream commit: f7c742cbe664ebdedc075945e75443683d1175f7 ]

(cherry picked from commit 8b26cf42ba0c74a9c86cebe591a9195f75151d97)
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

arm64: dts: rockchip: fix mmc aliases for Radxa ZERO 3E/3W

align with other Radxa products.

- mmc0 is eMMC
- mmc1 is microSD

for ZERO 3E, there is no eMMC, but aliases should start at 0, so mmc0
is microSD as exception.

Fixes: 1a5c8d307c83 ("arm64: dts: rockchip: Add Radxa ZERO 3W/3E")
Signed-off-by: FUKAUMI Naoki <naoki@radxa.com>
Changes in v3:
- fix syntax error in rk3566-radxa-zero-3e.dts
Changes in v2:
- microSD is mmc0 instead of mmc1 for ZERO 3E

Link: https://lore.kernel.org/r/20240620224435.2752-1-naoki@radxa.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
[ upstream commit: 060c1950037e4c54ca4d8186a8f46269e35db901 ]

(cherry picked from commit 8324bc7493e4088013c62bc41f49d6d181575493)
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

arm64: dts: rockchip: Add Radxa ZERO 3W/3E

The Radxa ZERO 3W/3E is an ultra-small, high-performance single board
computer based on the Rockchip RK3566, with a compact form factor and
rich interfaces.

The ZERO 3W and ZERO 3E are basically the same size and model, but
differ only in storage and network interfaces.

- eMMC (3W)
- SD-card (both)
- Ethernet (3E)
- WiFi/BT (3W)

Add initial support for eMMC, SD-card, Ethernet, HDMI and USB.

Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Link: https://lore.kernel.org/r/20240521202810.1225636-3-jonas@kwiboo.se
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
[ upstream commit: 1a5c8d307c83c808a32686ed51afb4bac2092d39 ]

(cherry picked from commit 1476c5882f8a47b6f0f895c6424dacf6334487ae)
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

board: rockchip: Add Radxa ROCK 3B

The Radxa ROCK 3B is a single-board computer based on the Pico-ITX form
factor (100mm x 75mm). Two versions of the ROCK 3B exists, a community
version based on the RK3568 SoC and an industrial version based on the
RK3568J SoC.

Features tested on ROCK 3B 8GB v1.51 (both variants):
- SD-card boot
- eMMC boot
- SPI Flash boot
- Ethernet
- PCIe/NVMe
- USB gadget
- USB host

Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Tested-by: FUKAUMI Naoki <naoki@radxa.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

arm64: dts: rockchip: Add Radxa ROCK 3B

The Radxa ROCK 3B is a single-board computer based on the Pico-ITX form
factor (100mm x 75mm). Two versions of the ROCK 3B exists, a community
version based on the RK3568 SoC and an industrial version based on the
RK3568J SoC.

Add initial support for eMMC, SD-card, Ethernet, HDMI, PCIe and USB.

Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Link: https://lore.kernel.org/r/20240627211737.1985549-3-jonas@kwiboo.se
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
[ upstream commit: 846ef7748fa9124c8eea76e2d5e833fa69b3ef7c ]

(cherry picked from commit 5416329b387d3c13392f84ba35273a402c7010f8)
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

board: rockchip: add Radxa ROCK 3 Model C

Based on rock-3a-rk3568_defconfig.
Tested on v1.31 revision.

Board Specifications:
- Rockchip RK3566
- 1/2/4GB LPDDR4 2112MT/s
- eMMC socket
- uSD card slot
- M.2 2230 Connector
- GbE LAN with POE
- 3.5mm jack with mic
- HDMI 2.0, MIPI DSI/CSI
- USB 3.0 Host, USB 2.0 Host/OTG
- 40-pin GPIO expansion ports

Signed-off-by: Maxim Moskalets <maximmosk4@gmail.com>
Suggested-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Jonas Karlman <jonas@kwiboo.se>
Tested-by: FUKAUMI Naoki <naoki@radxa.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

board: rockchip: Add Radxa ROCK S0

Radxa ROCK S0 is a single-board computer based on the Rockchip RK3308B
SoC in an ultra-compact form factor. Add a board target for the board.

Features tested on a ROCK S0 v1.2 with 512 MiB RAM and 8 GiB eMMC:
- SD-card boot
- eMMC boot
- Ethernet
- USB gadget
- USB host

Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

arm64: dts: rockchip: Add Radxa ROCK S0

Radxa ROCK S0 is a single-board computer based on the Rockchip RK3308B
SoC in an ultra-compact form factor.

Add initial support for eMMC, SD-card, Ethernet, WiFi/BT and USB.

Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Link: https://lore.kernel.org/r/20240521212247.1240226-3-jonas@kwiboo.se
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
[ upstream commit: adeb5d2a4ba47910238b3c4f5fd960cc0c26a98b ]

(cherry picked from commit e291d457b0378f2cb3d3ebb597032ca862cdb973)
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

rockchip: rk3308-rock-pi-s: Enable LED and IO Domain driver

Add LED=y and LED_GPIO=y to support the onboard leds.

Add ROCKCHIP_IODOMAIN=y to configure correct io voltage domains.

Add DM_MDIO=y now that the DT contain a Ethernet phy node.

Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

rockchip: rk3308-rock-pi-s: Remove unnecessary u-boot dtsi overrides

With the emmc and uart0 DT nodes updated to v6.11-rc1 in dts/upstream
there is no longer any need to keep overrides in board u-boot dtsi.

Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

arm64: dts: rockchip: Update WIFi/BT related nodes on rk3308-rock-pi-s

Update WiFi SDIO and BT UART related props to better reflect details
about the optional onboard RTL8723DS WiFi/BT module.

Also correct the compatible used for bluetooth to match the WiFi/BT
module used on the board.

Fixes: bc3753aed81f ("arm64: dts: rockchip: rock-pi-s add more peripherals")
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Link: https://lore.kernel.org/r/20240521211029.1236094-14-jonas@kwiboo.se
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
[ upstream commit: 12c3ec878cbe3709782e85b88124abecc3bb8617 ]

(cherry picked from commit caba73747c927b4fdccea3aeb16e077b4e6af006)
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

arm64: dts: rockchip: Add io-domains to rk3308-rock-pi-s

The VCCIO4 io-domain used for WiFi/BT is using 1v8 IO signal voltage.

Add io-domains node with the VCCIO supplies connected on the board.

Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Link: https://lore.kernel.org/r/20240521211029.1236094-13-jonas@kwiboo.se
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
[ upstream commit: 100b3bdee6035192f6d4a1847970fe004bb505fb ]

(cherry picked from commit f93b224359278728f01767a4701678ada9c25570)
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

arm64: dts: rockchip: Add mdio and ethernet-phy nodes to rk3308-rock-pi-s

Be explicit about the Ethernet port and define mdio and ethernet-phy
nodes in the device tree for ROCK Pi S.

Fixes: bc3753aed81f ("arm64: dts: rockchip: rock-pi-s add more peripherals")
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Link: https://lore.kernel.org/r/20240521211029.1236094-8-jonas@kwiboo.se
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
[ upstream commit: 4b64ed510ed946a4e4ca6d51d6512bf5361f6a04 ]

(cherry picked from commit 703b8eae20eec5dbb0e52f0e1fb71e712c007dae)
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

arm64: dts: rockchip: Add pinctrl for UART0 to rk3308-rock-pi-s

UAR0 CTS/RTS is not wired to any pin and is not used for the default
serial console use of UART0 on ROCK Pi S.

Override the SoC defined pinctrl props to limit configuration of the
two xfer pins wired to one of the GPIO pin headers.

Fixes: 2e04c25b1320 ("arm64: dts: rockchip: add ROCK Pi S DTS support")
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Link: https://lore.kernel.org/r/20240521211029.1236094-6-jonas@kwiboo.se
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
[ upstream commit: 7affb86ef62581e3475ce3e0a7640da1f2ee29f8 ]

(cherry picked from commit 9c72cd5fa9f971be8ebbc1f43bd74a72e33db2fa)
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

arm64: dts: rockchip: Add sdmmc related properties on rk3308-rock-pi-s

Add cap-mmc-highspeed to allow use of high speed MMC mode using an eMMC
to uSD board. Use disable-wp to signal that no physical write-protect
line is present. Also add vcc_io used for card and IO line power as
vmmc-supply.

Fixes: 2e04c25b1320 ("arm64: dts: rockchip: add ROCK Pi S DTS support")
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Link: https://lore.kernel.org/r/20240521211029.1236094-5-jonas@kwiboo.se
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
[ upstream commit: fc0daeccc384233eadfa9d5ddbd00159653c6bdc ]

(cherry picked from commit 39110e4bec51c9ce6bbd342234b288dbfccb9f80)
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

arm64: dts: rockchip: Add rk3308 IO voltage domains

Add a disabled RK3308 IO voltage domains node to SoC DT.

Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Link: https://lore.kernel.org/r/20240521211029.1236094-12-jonas@kwiboo.se
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
[ upstream commit: d1829ba469d5743734e37d59fece73e3668ab084 ]

(cherry picked from commit cebde305971e33a76efc3280e09814499ef89f54)
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

arm64: dts: rockchip: Add OTP device node for RK3308

The RK3308 SoC contains a controller for one-time-programmable memory,
add a device node for it.

Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Link: https://lore.kernel.org/r/20240521211029.1236094-9-jonas@kwiboo.se
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
[ upstream commit: 36d3bbc8cdbef2f83391f7708888265ac4c37a99 ]

(cherry picked from commit db11d284200d0f811a8f8238dbc9c63daf4e6131)
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

rockchip: rk3308: Remove OTP device node from soc u-boot dtsi

The merged upstream DT node for OTP differs in nodename and will cause
following build errors once rk3308.dtsi in dts/upstream is updated:

  ERROR (duplicate_label): /nvmem@ff210000: Duplicate label 'otp' on /nvmem@ff210000 and /efuse@ff210000
  ERROR (duplicate_label): /nvmem@ff210000/id@7: Duplicate label 'cpu_id' on /nvmem@ff210000/id@7 and /efuse@ff210000/id@7

Remove the OTP device node from soc u-boot dtsi in preparation for
replacing it with the merged upstream DT node in dts/upstream.

Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

rockchip: configs: puma-rk3399: disable VIDEO support that breaks Linux

RK3399 Puma has support for driving multiple displays at the same time,
the most notable scenario being HDMI+DSI since there exists a devkit
with both DSI display and HDMI output.

While HDMI seems to work fine in U-Boot, as the U-Boot logo is shown
whenever the EFI bootmeth is used, it messes up DSI in HDMI+DSI setup in
the Linux kernel. There are some ways to work around this bug but no
known appropriate fix for now, so let's rather not trigger this bug.

Since there isn't any client of ours that seems to be using this
feature, let's disable it for now. Users can re-enable this feature in
the event they have HDMI-only products.

Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

rockchip: dts: rk3568: Sync the evb board name with kernel

The name of rk3568 evb in mainline kernel is rk3568-evb1-v10.

Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>

rockchip: Use files from dts/upstream

Most Rockchip aarch64 targets have now migrated to use OF_UPSTREAM,
however a few of the old dtsi and dt-bindings files still remain.

Remove remaining common dtsi and header files that can be included
directly from dts/upstream to prevent possible issues when future tags
from devicetree-binding is merged. No changes is expected with this.

Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>

rockchip: px30/rk3326: Use soc dtsi files from dts/upstream

The commit f087f7fd277d ("rockchip: px30/rk3326: migrate to
OF_UPSTREAM") migrated px30/rk3326 boards to use OF_UPSTREAM, however
the soc dtsi and dt-bindings files remained.

Remove the remaining px30/rk3326 soc dtsi and dt-bindings to ensure the
files from dts/upstream is used.

The gpio-ranges props is moved to u-boot.dtsi files and a ethernet0
alias is added to px30-firefly, they are missing in the dts/upstream
files. No changes are expected with this.

Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>

rockchip: rk3588-toybrick-x0: Migrate to OF_UPSTREAM

The device tree for Rockchip Toybrick TB-RK3588X has been merged into
dts/upstream with devicetree-rebasing v6.10-dts, migrate board to
OF_UPSTREAM.

Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

rockchip: rk3566-pinetab2: Migrate to OF_UPSTREAM

The device tree for Pine64 PineTab2 has been merged into dts/upstream
with devicetree-rebasing v6.10-dts, migrate board to OF_UPSTREAM.

Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

rockchip: io-domain: Add support for RK3308

Port the RK3308 part of the Rockchip IO Domain driver from linux.

This differs from linux version in that vccio3 iodomain bit is enabled
in the write ops instead of in an init ops as in linux, this way we can
avoid keeping a full state of all supply that have been configured.

Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

mmc: rockchip_dw_mmc: Allow 4-bit mode when 8-bit mode is supported

Hosts capable of 8-bit can also do 4 bits, fix use of 4-bit mode when
8-bit mode is supported.

This fixes use of 1-bit mode with SD NAND on ROCK Pi S using the DT in
v6.11-rc1 that chage to use 8-bit bus to also support eMMC. With this
4-bit mode is used with SD NAND and 8-bit mode with eMMC, same as in
Linux kernel.

Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

phy: rockchip: naneng-combphy: Introduce PHY-IDs to fix RK3588 muxing

Fix multiplex configuration for PCIe1L0 and PCIe1L1 in PCIESEL_CON for
RK3588 to correctly select between Combo PHYs and PCIe3 PHY.
Currently, the code incorrectly muxes both ports to Combo PHYs,
interfering with PCIe3 PHY settings.
Introduce PHY identifiers to identify the correct Combo PHY and set
the necessary bits accordingly.

This fix is adapted from the upstream Linux commit by Sebastian Reichel:
d16d4002fea6 ("phy: rockchip: naneng-combphy: Fix mux on rk3588")

Fixes: b37260bca1aa ("phy: rockchip: naneng-combphy: Use signal from comb PHY on RK3588")
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Signed-off-by: Sebastian Kropatsch <seb-dev@mail.de>

board: vining_2000: convert to DM_I2C

Conversion to DM_I2C is mandatory, enable DM_I2C
to disable board removal warning.

Signed-off-by: Anatolij Gustschin <agust@denx.de>

board: cm_fx6: convert to DM_I2C

Conversion to DM_I2C is mandatory, enable DM_I2C to fix board
removal warning. Convert EEPROM access to use DM_I2C API.

Signed-off-by: Anatolij Gustschin <agust@denx.de>
Reviewed-by: Fabio Estevam <festevam@gmail.com>

board: vf610twr: convert to DM_I2C

Conversion to DM_I2C is mandatory, enable DM_I2C
to disable board removal warning.

Signed-off-by: Anatolij Gustschin <agust@denx.de>

board: novena: convert to DM_I2C

Conversion to DM_I2C is mandatory, enable DM_I2C
to disable board removal warning. Convert EEPROM
and IT6251 access to use DM_I2C API.

Signed-off-by: Anatolij Gustschin <agust@denx.de>
Reviewed-by: Marek Vasut <marex@denx.de>

board: rut: convert to DM_I2C

Conversion to DM_I2C is mandatory, enable DM_I2C
to disable board removal warning.

Signed-off-by: Anatolij Gustschin <agust@denx.de>

board: sl50: convert to DM_I2C

Conversion to DM_I2C is mandatory, enable DM_I2C
to disable board removal warning.

Signed-off-by: Anatolij Gustschin <agust@denx.de>

board: igep003x: convert to DM_I2C

Conversion to DM_I2C is mandatory, enable DM_I2C
to disable board removal warning.

Signed-off-by: Anatolij Gustschin <agust@denx.de>

board: cm-t43: convert to DM_I2C

Conversion to DM_I2C is mandatory, enable DM_I2C
to disable board removal warning.

Signed-off-by: Anatolij Gustschin <agust@denx.de>

board: chiliboard: convert to DM_I2C

Conversion to DM_I2C is mandatory, enable DM_I2C
to disable board removal warning.

Signed-off-by: Anatolij Gustschin <agust@denx.de>

board: shc: convert to DM_I2C

Conversion to DM_I2C is mandatory, rework to remove
use of legacy I2C API.

Signed-off-by: Anatolij Gustschin <agust@denx.de>
Reviewed-by: Heiko Schocher <hs@denx.de>

Merge patch series "Low Power Mode: Package TIFS Stub in BeaglePlay"

Dhruva Gole <d-gole@ti.com> says:

This series aims to add documentation around the boot flow and tispl
packaging details regarding the TIFS Stub. While at it, also refactors the
k3 common docs to add more labels to provide more granularity on how we
include chunks from common docs into SoC specific docs.

This series also includes the binman related changes required to package
TIFS Stub to support Low Power Modes on BeaglePlay and phycore-am625 SOM.

arm: dts: phycore-am62x: Package TIFS Stub

Add support for packaging the TIFS Stub as it's required for basic Low
Power Modes like Deep Sleep.
The reason it is packaged using binman and not inherently as part of the
DM firmware is because for HS devices, customer owns the customer key
and only customer has access to it.
DM is release by TI, Since TI doesn't have access to the customer key it
cannot have a component that is signed by customer key.
Hence, it's left as part of binman to be signed and packaged.

While at it, also make sure it's documented in phycore-am62x

Reviewed-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Wadim Egorov <w.egorov@phytec.de>
Signed-off-by: Dhruva Gole <d-gole@ti.com>

doc: beagle: am62x_beagleplay: Document the use of TIFS Stub

* Include the actual common documentation about the TIFS Stub and role
  it plays to enable Low Power Modes in the platform.
* Add the AM62x boot flow to show at which point the TIFS Stub actually
  gets loaded.
* Mention the TIFS Stub in the TISPL image format.

Reviewed-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Dhruva Gole <d-gole@ti.com>

arm: dts: k3-am625-beagleplay: Package TIFS Stub

Add support for packaging the TIFS Stub as it's required for basic Low
Power Modes like Deep Sleep.
The reason it is packaged using binman and not inherently as part of the
DM firmware is because for HS devices, customer owns the customer key
and only customer has access to it.
DM is release by TI, Since TI doesn't have access to the customer key it
cannot have a component that is signed by customer key.
Hence, it's left as part of binman to be signed and packaged.

Reviewed-by: Nishanth Menon <nm@ti.com>
Acked-by: Neha Malcom Francis <n-francis@ti.com>
Signed-off-by: Dhruva Gole <d-gole@ti.com>

doc: ti: am62*: Mention TIFS Stub in img fmts and boot flow

Since AM62x, AM62P and AM62A all use similar boot flows and their low
power mode s/w ARCH is also similar in the way that they make use of the
TIFS Stub, update their documentation to show where TIFS Stub is.

Reviewed-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Dhruva Gole <d-gole@ti.com>

doc: board: ti: Update to use the new boot firmware labels

Use the new boot_firmwares labels that help make documentation more
specific as to which firmwares are used in which devices

Signed-off-by: Dhruva Gole <d-gole@ti.com>

doc: ti: k3: Add TIFS Stub documentation

* Add documentation to briefly explain the role of TIFS Stub in relevant
  K3 SoC's.
* Shed light on why TIFS Stub isn't package with the DM firmware itself.
* Modify the platform docs wherever the TIFS Stub documentation applies.
* Also, refactor and add a few new labels to help split the firmware
  documentation chunks. This will make it easier to include them one by
  one wherever applicable

Reviewed-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Dhruva Gole <d-gole@ti.com>
Acked-by: Francesco Dolcini <francesco.dolcini@toradex.com> # verdin-am62

MAINTAINERS: Include the TI docs under ARM TI

Add entry for the TI boards documentation under ARM TI

Reviewed-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Dhruva Gole <d-gole@ti.com>

Merge tag 'u-boot-nand-20240808' of https://source.denx.de/u-boot/custodians/u-boot-nand-flash

This series adds support for the UBI block device, which allows to read/write
data block by block. The series was tested by Alexey Romanov on SPI NAND.

The patches pass the pipeline CI:
https://source.denx.de/u-boot/custodians/u-boot-nand-flash/-/pipelines/21933

spinand: bind UBI block

UBI block is virtual block device, which is an abstraction
over MTD layer. Therefore it is logical to use it in combination
with MTD drivers.

Signed-off-by: Alexey Romanov <avromanov@salutedevices.com>
Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>

disk: support UBI partitions

UBI partition is abstraction over UBI volumes.
Can be used by UBI block device.

Signed-off-by: Alexey Romanov <avromanov@salutedevices.com>
Reviewed-by: Heiko Schocher <hs@denx.de>
Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>

disk: don't try search for partition type if already set

Block devices can already set partition type at initialization
stage, so, in this case is no point in searching for partition type.

Signed-off-by: Alexey Romanov <avromanov@salutedevices.com>
Reviewed-by: Heiko Schocher <hs@denx.de>
Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>

drivers: introduce UBI block abstraction

UBI block is an virtual device, that runs on top
of the MTD layer. The blocks are UBI volumes.
Intended to be used in combination with other MTD
drivers.

Despite the fact that it, like mtdblock abstraction,
it used with UCLASS_MTD, they can be used together
on the system without conflicting. For example,
using bcb command:

  # Trying to load bcb via mtdblock:
  $ bcb load mtd 0 mtd_partition_name

  # Trying to load bcb via UBI block:
  $ bcb load ubi 1 ubi_volume_name

User always must attach UBI layer (for example, using
ubi_part()) before using UBI block device.

Signed-off-by: Alexey Romanov <avromanov@salutedevices.com>
Reviewed-by: Heiko Schocher <hs@denx.de>
Acked-by: Heiko Schocher <hs@denx.de>
Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>

ubi: allow to write to volume with offset

Introduce ubi_volume_offset_write() helper, which
allow to write to ubi volume with specified offset.

Signed-off-by: Alexey Romanov <avromanov@salutedevices.com>
Reviewed-by: Heiko Schocher <hs@denx.de>
Acked-by: Heiko Schocher <hs@denx.de>
Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>

ubi: allow to read from volume with offset

Now user can pass an additional parameter 'offset'
to ubi_volume_read() function.

Signed-off-by: Alexey Romanov <avromanov@salutedevices.com>
Reviewed-by: Heiko Schocher <hs@denx.de>
Acked-by: Heiko Schocher <hs@denx.de>
Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>

spinand: bind mtdblock

Bind SPI-NAND driver to MTD block driver.

Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Signed-off-by: Alexey Romanov <avromanov@salutedevices.com>
Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>

drivers: introduce mtdblock abstraction

MTD block - abstraction over MTD subsystem, allowing
to read and write in blocks using BLK UCLASS.

Signed-off-by: Alexey Romanov <avromanov@salutedevices.com>
Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>

disk: support MTD partitions

Add new MTD partition driver, which can be useful with
mtdblock driver combination.

Signed-off-by: Alexey Romanov <avromanov@salutedevices.com>
Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>

Merge patch series "alist: Implement a pointer list / array of structs"

Simon Glass <sjg@chromium.org> says:

This data structure provides a list of pointers / array of structures.
I was planning to use it for the lmb restructure, to allow it to
support any number of entries, but then I gave up on it.

There are quite a few places in U-Boot where such a list would be
useful, since it supports growing the array.

[...]
Example:

 struct my_struct obj;
 struct my_struct *ptr = alist_add(&lst, &obj, struct my_struct);

 // now ptr is in the list

[trini: Reword the cover letter slightly, do not merge the RFC portion]

alist: Add support for an allocated pointer list

In various places it is useful to have an array of structures, but allow
it to grow. In some cases we work around it by setting maximum number of
entries, using a Kconfig option. In other places we use a linked list,
which does not provide for random access and can complicate the code.

Introduce a new data structure, which is a variable-sized list of structs
each of the same, pre-set size. It provides O(1) access and is reasonably
efficient at expanding linearly, since it doubles in size when it runs out
of space.

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

lib: Handle a special case with str_to_list()

The current implementation can return an extra result at the end when
the string ends with a space. Fix this by adding a special case.

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

malloc: Support testing with realloc()

At present in tests it is possible to cause an out-of-memory condition
with malloc() but not realloc(). Add support to realloc() too, so code
which uses that function can be tested.

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

omap3: sniper: Convert to device-tree control and DM I2C

This converts the sniper board (LG P970) to device-tree control
and DM I2C, both for SPL and U-Boot.

Note that we lose the call to board_mmc_power_init to enable power
for MMC2. This is now expected to take place through proper
regulators, which are not yet available with the twl4030 driver.
The call to twl4030_power_mmc_init is moved to spl_board_init for now.

Signed-off-by: Paul Kocialkowski <contact@paulk.fr>

am33xx: Use regular spl_board_init instead of am33xx_spl_board_init

The am33xx_spl_board_init function was introduced as a way to add
board-specific SPL init for AM33xx devices since the spl_board_init
function was already used for SoC-specific init.

Now that the SoC-specific SPL init was moved to spl_soc_init, we can
use spl_board_init for this purpose and get rid of
am33xx_spl_board_init.

Rename the function in board files and enable the related config
option for concerned boards.

Signed-off-by: Paul Kocialkowski <paulk@sys-base.io>
Reviewed-by: Tom Rini <trini@konsulko.com>

omap: Use spl_soc_init instead of spl_board_init

Both spl_board_init and spl_soc_init are available as ways to run
specific code in the SPL's board_init_r. Use the former for init
code that is specific to the SoC and leave spl_board_init available
for boards to use.

Signed-off-by: Paul Kocialkowski <paulk@sys-base.io>
Reviewed-by: Tom Rini <trini@konsulko.com>

Merge patch series "omap configuration cleanups"

Paul Kocialkowski <paulk@sys-base.io> says:

Here is a bunch of configuration cleanups for OMAP boards, mostly
unifying and moving common configuration from board-specific defconfigs
to Kconfig definitions.

There's also a cleanup of the sniper (LG Optimus Black) defconfig,
prior to migrating it to DM/DT in a future follow-up series.

omap3: sniper: Streamline defconfig

Remove custom config options that are not particularly necessary.
Align them with OMAP3 defaults used on other boards (especially for
memory locations).

Also enable Thumb build to reduce the SPL size and remove the custom
prompt text.

This makes the config a lot more minimalistic, maintainable and easier
to read.

Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-by: Tom Rini <trini@konsulko.com>
Tested-by: Derald D. Woods <woods.technical@gmail.com>

dra7xx: Remove explicit DRAM banks number from defconfigs

The common EMIF init code used for DRA7xx does not explicitly fill
the gd->bd->bi_dram entries (like OMAP3 does), so there is no reason
to set an explicit number of DRAM banks which doesn't correspond to
anything in particular.

Remove the CONFIG_NR_DRAM_BANKS option from the concerned defconfigs.
The dram_init_banksize default implementation will be fine with the
default value for the config option.

Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-by: Tom Rini <trini@konsulko.com>
Tested-by: Derald D. Woods <woods.technical@gmail.com>

omap3: Define DRAM banks number in Kconfig instead of defconfigs

The number of DRAM banks was defined to the same value in each OMAP3
board defconfig, which is expected and hardcoded in the code. Move the
common definition to the Kconfig option declaration instead.

Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-by: Tom Rini <trini@konsulko.com>
Tested-by: Derald D. Woods <woods.technical@gmail.com>

omap3: Define maximum SPL size in Kconfig instead of defconfigs

The maximum SPL size was defined to the same value in each OMAP3
board defconfig. Move the common definition to the Kconfig option
declaration instead.

Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-by: Tom Rini <trini@konsulko.com>
Tested-by: Derald D. Woods <woods.technical@gmail.com>

omap3: Define maximum U-Boot size in Kconfig instead of defconfigs

The maximum U-Boot size was defined to the same value in each OMAP3
board defconfig. Move the common definition to the Kconfig option
declaration instead.

Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-by: Tom Rini <trini@konsulko.com>
Tested-by: Derald D. Woods <woods.technical@gmail.com>

dra7xx: Define common init stack pointer address in Kconfig

The init stack pointer was defined to the same value in each DRA7xx
board defconfig. Move the common definition to the Kconfig option
declaration instead.

Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-by: Tom Rini <trini@konsulko.com>
Tested-by: Derald D. Woods <woods.technical@gmail.com>