Now that sandbox_vpl supports UPL, add a test that checks that the
payload can be loaded by SPL and the handoff information passed through
to U-Boot proper.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add support for loading a UPL image from SPL. This uses the simple FIT
implementation, but also loads the full FIT just to permit more testing.
Signed-off-by: Simon Glass <sjg@chromium.org>
UPL significantly alters the boot flow for sandbox. Add a flag to enable
this so that it can be enabled only on tests which need it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Use the sandbox_vpl build to test UPL since it supports a real devicetree
in SPL. The sandbox_spl build uses OF_PLATDATA.
Enable writing the UPL handoff in SPL and reading it in U-Boot proper.
Provide a test to check that this handoff works.
Note that the test uses the standard devicetree rather than the test one,
since it is a lot smaller and fits in the existing bloblist.
Signed-off-by: Simon Glass <sjg@chromium.org>
Specify the FIT and include information about each loaded image, as
required by the UPL handoff.
Write the UPL handoff into the bloblist before jumping to the next phase.
Control this using a runtime flag to avoid conflicting with other
handoff mechanisms.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add the basic code to create a handoff structure in SPL, so it can be
passed to the next phase. For now this is not plumbed in.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add a 'upl' command to work with Universal Payload features. For now it
only supports reading and writing a handoff structure.
Signed-off-by: Simon Glass <sjg@chromium.org>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEgWII69YpahbL5iK5gS8AYozs+qIFAma18twACgkQgS8AYozs
+qKUxQ/+N15BctMTOVyrZ/wtYMle/ulox/drtrNKmDtSxKtaz1prfk/b1Z9YX9jD
oXU6DBku6gsSLwQlUOPQoOkWIeKxta5v8GLIn1BgMP12GCLLf+0stZ0haYPpig0p
zZCyLFQIa82on655xopIc9MdRW3s0m3AlepoPcjh5LoK/IauodQntBknrc2H93El
AArwDIMhTV0D5zevbUQpVr98G2GsSsJ9P44YTG97+s7mjFq/2/qqNL2N692UvAlm
B54FhgnqDzamSGpZsLGTQCDpwDm6WXVErA4Ta4Zd3FnTAMOGivB0+WxBR1fi/RSr
mcm0Rq+OMCLvzHZJITpe21R9xadmZ4pdOlPRLeiAw90htJ65981j+mdXW7XI/ZEc
fcGDyUS8+RrO+u+5T2AxhTcuJ4HcH9/vbn/ADyrcZ3wR89bRqAOj71v7utDL2JT1
OSYYGfWLJYQ850HMdap6zv4Fh0FBuZ1dnp3Z/GDfiLQgDYLD+oO/CY/R72al+U65
HjaAzSp3SbBDbEjRmlyopa0Vc5jGzPN7jXPuA/0YN20gLxcb819NnhbGmxTplaHp
38LFlheflYLXizGpK0Lq9a4D3fCgFE7gSM7RTBB/G6cN+ADz49SLPkLYKv8O5fRl
X/f991nrDw+pBtSECa3TdtoVnY9TZdPNHUkuAfSgKqoC9l/OW/k=
=aq79
-----END PGP SIGNATURE-----
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.
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
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
