Oliver Gaskell [Thu, 12 Sep 2024 15:50:56 +0000 (16:50 +0100)]
arm: SC594-SOM-EZKIT initial support
Adds support for Analog Devices' SC594-SOM-EZKIT board. Includes:
- SoC specific configs in mach-sc5xx/Kconfig
- Memory Map for SPL
- SPL config options in common/spl/Kconfig
- Necessary board-specific init functions
- Board-specific Kconfig and environment in board/adi/
- Memory configuration
Co-developed-by: Greg Malysa <greg.malysa@timesys.com> Signed-off-by: Greg Malysa <greg.malysa@timesys.com> Co-developed-by: Trevor Woerner <twoerner@gmail.com> Signed-off-by: Trevor Woerner <twoerner@gmail.com> Co-developed-by: Nathan Barrett-Morrison <nathan.morrison@timesys.com> Signed-off-by: Nathan Barrett-Morrison <nathan.morrison@timesys.com> Co-developed-by: Ian Roberts <ian.roberts@timesys.com> Signed-off-by: Ian Roberts <ian.roberts@timesys.com> Signed-off-by: Oliver Gaskell <Oliver.Gaskell@analog.com>
Oliver Gaskell [Thu, 12 Sep 2024 15:50:55 +0000 (16:50 +0100)]
arm: SC598-SOM-EZLITE initial support
Adds support for Analog Devices' SC598-SOM-EZLITE board. Includes:
- Board specific configs in mach-sc5xx/Kconfig
- Board-specific Kconfig and environment in board/adi/
Signed-off-by: Oliver Gaskell <Oliver.Gaskell@analog.com>
Oliver Gaskell [Thu, 12 Sep 2024 15:50:54 +0000 (16:50 +0100)]
arm: SC598-SOM-EZKIT initial support
Adds support for Analog Devices' SC598-SOM-EZKIT board. Includes:
- CONFIG options common to all SC5xx SoCs
- SoC specific configs in mach-sc5xx/Kconfig
- SPL config options in common/spl/Kconfig
- Memory Map for SPL
- Necessary board-specific init functions
- Board-specific Kconfig and environment in board/adi/
- Memory configuration
Oliver Gaskell [Thu, 12 Sep 2024 15:50:53 +0000 (16:50 +0100)]
arm: mach-sc5xx: clean up Kconfig
Moves common options between all SC5xx series boards to the ARCH_SC5XX
option instead of duplicating them.
Also, it was possible to select multiple of the SoC support options.
Given a U-Boot binary can only support a single platform, this moves
the SoC selection to a `choice`, making them mutually exclusive.
Signed-off-by: Oliver Gaskell <Oliver.Gaskell@analog.com>
Brian Norris [Fri, 26 Jul 2024 19:02:33 +0000 (12:02 -0700)]
patman: Resolve python string vs. regex escaping syntax
Python strings have their own notion of backslash-escaping, and that can
conflict with the intentions for strings passed to the 're' module. In
particular, I get warnings like this:
Jerome Forissier [Wed, 28 Aug 2024 15:36:37 +0000 (17:36 +0200)]
mach-imx: do not use if_changed more than once per target
doc/develop/makefiles.rst has the following note:
if_changed should not be used more than once per target.
It stores the executed command in a corresponding .cmd
file and multiple calls would result in overwrites and
unwanted results when the target is up to date and only the
tests on changed commands trigger execution of commands.
The mach-imx Makefile does not follow this recommandation, so fix it
by implementing a single command that performs both the cpp_cfg
and imx9_check actions.
This change fixes an issue with "tools/buildman/buildman imx8ulp_evk"
failing every other time [1].
Jonas Karlman [Sat, 3 Aug 2024 12:41:44 +0000 (12:41 +0000)]
bootstage: Fix unstash of records from SPL
The commit b81e31a1e6c5 ("bootstash: Do not provide a default address
for all") changed a bootstage unstash call to bootstage stash, this
has resulted in bootstage records stashed in SPL no longer get unstaged
in U-Boot proper. Fix this by changing back to a unstage call.
Fixes: b81e31a1e6c5 ("bootstash: Do not provide a default address for all") Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
uint64_t is defined as unsigned long long on 32-bit ARM.
Use PRIX64 for printing uint64_t.
This avoid a build failure on 32-bit systems:
tools/mkeficapsule.c: In function 'dump_capsule_auth_header':
tools/mkeficapsule.c:694:66: warning: format '%lX' expects argument of
type 'long unsigned int', but argument 2 has type 'uint64_t'
{aka 'long long unsigned int'} [-Wformat=]
694 | printf("EFI_FIRMWARE_IMAGE_AUTH.MONOTONIC_COUNT\t\t: %08lX\n",
| ~~~~^
| |
| long unsigned int
| %08llX
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Reviewed-by: Mark Kettenis <kettenis@openbsd.org>
Ilias Apalodimas [Mon, 12 Aug 2024 20:57:59 +0000 (23:57 +0300)]
efi_loader: fix memory freeing in efi_get_dp_from_boot()
efi_get_var() allocates memory which must be freed after the variable is
used. Since the device path is duplicated after we deserialize the load
options free the memory used for the variable payload
- Fix crash in BCB on invalid block device (reported by coverity)
- Fix booting Android kernel without a ramdisk using fastboot
- Fix ux500 gadget driver ops based on CONFIG_USB_MUSB_HOST
Marek Vasut [Sun, 18 Aug 2024 20:04:15 +0000 (22:04 +0200)]
usb: gadget: ux500: Do not redefine ops if CONFIG_USB_MUSB_HOST set
In case CONFIG_USB_MUSB_HOST is set, the ux500_gadget_ops get overridden
to musb_usb_ops . Simply set the ops one way or the other depending on
whether CONFIG_USB_MUSB_HOST is set or not.
Michael Walle [Mon, 29 Jul 2024 21:36:57 +0000 (23:36 +0200)]
boot: android: fix booting without a ramdisk
android_image_get_ramdisk() will return an error if there is no ramdisk.
Using the android image without a ramdisk worked until commit 1ce8e10f3b4b ("image: Fix up ANDROID_BOOT_IMAGE ramdisk code") because
the return code wasn't checked until then. Return -ENOENT in case
there is no ramdisk and translate that into -ENOPKG in the calling
code, which will then indicate "no ramdisk" to its caller
(boot_get_ramdisk()).
This way, we can get rid of the "*rd_data = *rd_len = 0;" in the error
path, too.
With this, I'm able to boot a linux kernel using fastboot again:
Tom Rini [Mon, 19 Aug 2024 21:07:18 +0000 (15:07 -0600)]
pytest: requirements.txt: Resync with the rest of the project
In order to build the docker container, which contains a download cache
of python modules, we need to have our versions be in sync in each
requirements file. Update some of the cases where which are older than
the rest of the project.
Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com>
- Convert tqma6q_mba6 to watchdog DM to fix reset.
- Convert tqma6q_mba6 to PMIC and I2C DM.
- Convert tqma6q_mba6 to OF_UPSTREAM.
- Do not print the board name twice on tqma6.
- Enable CMD_ERASEENV for imx8mm/mp Phytec boards.
- Add imx8ulp binman support.
- Fix imx8 build when CONFIG_IMX_BOOTAUX is set.
Fabio Estevam [Fri, 9 Aug 2024 15:25:48 +0000 (12:25 -0300)]
imx6-tqma6: Convert to OF_UPSTREAM
Instead of using the local imx6-tqma6 devicetree copies from U-Boot,
convert the imx6-tqma6 target to OF_UPSTREAM so that the upstream
kernel devicetrees can be used instead.
Gary Bisson [Mon, 5 Aug 2024 21:25:10 +0000 (23:25 +0200)]
mach-imx: Add i.MX 8ULP binman support
- Re-use i.MX 93 Makefile target as similar boot process
- Create imx8ulp-u-boot.dtsi for binman image architecture
- Create both SPL and U-Boot containers configuration
Key differences between the 93 and 8ULP SPL container are:
- No LPDDR training library needed for 8ULP
- 8ULP requires a uPower binary (RISC-V core) for power management
- 8ULP also requires a M33 binary to work properly
Signed-off-by: Gary Bisson <bisson.gary@gmail.com> Reviewed-by: Peng Fan <peng.fan@nxp.com>
Gary Bisson [Mon, 5 Aug 2024 21:25:08 +0000 (23:25 +0200)]
tools: imx8image: add upower image support
Part of the upower management was included in a previous commit [1].
This patch only adds the bits required to properly parse a config file
that would include the binary as follows:
IMAGE PWR upower.bin
Gary Bisson [Mon, 5 Aug 2024 21:25:07 +0000 (23:25 +0200)]
tools: imx8image: fix soc variable for ULP
Currently the ULP token sets the soc as IMX9, making it impossible to
differentiate the two families of processors.
However, since the 8ULP requires specific binaries like upower which do
not exist in 93, they need to be separated.
Fixes: 6ec65c8558f (tools: image: support i.MX93) Signed-off-by: Gary Bisson <bisson.gary@gmail.com> Reviewed-by: Peng Fan <peng.fan@nxp.com>
Tom Rini [Mon, 12 Aug 2024 13:58:24 +0000 (07:58 -0600)]
Merge tag 'u-boot-rockchip-20240812' of https://source.denx.de/u-boot/custodians/u-boot-rockchip
Please pull the updates for rockchip platform:
- Add board support:
RK3566: Radxa ROCK 3 Model C
Radxa ZERO 3W/3E
Xunlong Orange Pi 3B
RK3568J: Radxa ROCK 3B
RK3308B: Radxa ROCK S0
RK3588: Radxa ROCK 5 ITX
FriendlyElec CM3588 NAS board
- dw-mmc: allow 4-bit mode;
- dts and config updates;
Tom Rini [Mon, 12 Aug 2024 13:57:34 +0000 (07:57 -0600)]
Merge tag 'efi-2024-10-rc3' of https://source.denx.de/u-boot/custodians/u-boot-efi
Pull request efi-2024-10-rc3
UEFI:
* efi_loader: use list_count_nodes() in efi_protocols_per_handle()
* efi_loader: correct description of efi_get_distro_fdt_name
* boot: set correct block device name in set_efi_bootdev()
* configs: enable efidebug and EFI http boot on QEMU aarch64
Other:
* Makefile: don't use CFLAGS for environment text file
FUKAUMI Naoki [Tue, 6 Aug 2024 03:47:59 +0000 (12:47 +0900)]
configs: rockchip: enable "ums" command for Radxa ROCK 5B
USB Type-C port is configured as "peripheral" port. so enable "ums"
command to use as USB Mass Storage device.
("rockusb" command is already enabled and working)
Signed-off-by: FUKAUMI Naoki <naoki@radxa.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Heiko Stuebner [Fri, 2 Aug 2024 21:00:28 +0000 (23:00 +0200)]
board: rockchip: Add Radxa ROCK 5 ITX
The Rock 5 ITX is a board in ITX form factor using the RK3588 SoC
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.
Display options are 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
The naming scheme with the dashes follows Dragan's comment on the mainline
devicetree commit:
"the name of this board deviates from the standard Radxa naming scheme,
which is something like "ROCK <number><letter>" thus, "rock-5a" is
fine, but it should be "rock-5-itx", simply because there's a space
between "5" and "ITX" in "ROCK 5 ITX"
Signed-off-by: Heiko Stuebner <heiko@sntech.de> Reviewed-by: Kever Yang <kever.yang@rock-chips.com> Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Makefile: don't use CFLAGS for environment text file
We use KCPPFLAGS to let the user set flags when invoking the C precompiler.
These should also be used when generating the environment text file.
Reported-by: Dave Jones <dave.jones@canonical.com> Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Simon Glass <sjg@chromium.org>
configs: enable efidebug and EFI http boot on QEMU aarch64
EFI HTTP is a useful option to have by default and is working reliably on
QEMU. Let's enable it by default, since we have no size limitations.
While at it enable 'efidebug' as well, which is currently needed to
configure the EFI HTTP boot options.
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
Alexander Dahl [Wed, 3 Jul 2024 10:12:58 +0000 (12:12 +0200)]
fs: ubifs: Add volume mounted check
Safety guard in the U-Boot filesystem glue code, because these functions
are called from different parts of the codebase. For generic filesystem
handling this should have been checked in blk_get_device_part_str()
already. Commands from cmd/ubifs.c should also check this before
calling those functions, but you never know?!
Alexander Dahl [Wed, 3 Jul 2024 10:12:57 +0000 (12:12 +0200)]
fs: ubifs: Make k(z)alloc/kfree symmetric
Although kfree() is in fact only a slim wrapper to free() in U-Boot, use
kfree() here, because those structs where allocated with kalloc() or
kzalloc().
Alexander Dahl [Wed, 3 Jul 2024 10:12:56 +0000 (12:12 +0200)]
fs: ubifs: Set pointers to NULL after free
Global superblock pointer 'ubifs_sb' and volume pointer 'ubi' of type
struct ubi_volume_desc in private member sb->s_fs_info of type struct
ubifs_info, can be allocated and freed at runtime, and allocated and
freed again, depending which console or script commands are run. In
some cases ubifs_sb is even tested to determine if the filesystem is
mounted. Reset those pointers to NULL after free to clearly mark them
as not valid. This avoids potential double free on invalid pointers.
(The ubifs_sb pointer was already reset, but that statement was moved
now to directly after the free() to make it easier to understand.)
Alexander Dahl [Wed, 3 Jul 2024 10:12:55 +0000 (12:12 +0200)]
fs: ubifs: Fix memleak and double free in u-boot wrapper functions
When mounting ubifs e.g. through command 'ubifsmount' one global static
superblock 'ubifs_sb' is used _and_ the requested volume is opened (like
in Linux). The pointer returned by 'ubifs_open_volume()' is stored in
that superblock struct and freed later on cmd 'ubifsumount' or another
call to 'ubifsmount' with a different volume, through ubifs_umount() and
ubi_close_volume().
In ubifs_ls(), ubifs_exists(), ubifs_size(), and ubifs_read() the volume
was opened again, which is technically no problem with regard to
refcounting, but here the still valid pointer in sb was overwritten,
leading to a memory leak. Even worse, when using one of those
functions and calling ubifsumount later, ubi_close_volume() was called
again but now on an already freed pointer, leading to a double free.
This actually crashed with different invalid memory accesses on a board
using the old distro boot and a rather long script handling RAUC
updates.
Example:
> ubi part UBI
> ubifsmount ubi0:boot
> test -e ubi ubi0:boot /boot.scr.uimg
> ubifsumount
The ubifs specific commands 'ubifsls' and 'ubifsload' check for a
mounted volume by themselves, for the generic fs variants 'ls', 'load',
(and 'size', and 'test -e') this is covered by special ubifs handling in
fs_set_blk_dev() and deeper down blk_get_device_part_str() then. So for
ubifs_ls(), ubifs_exists(), ubifs_size(), and ubifs_read() we can be
sure the volume is opened and the necessary struct pointer in sb is
valid, so it is not needed to open volume again.
Fixes: 9eefe2a2b37 ("UBIFS: Implement read-only UBIFS support in U-Boot") Fixes: 29cc5bcadfc ("ubifs: Add functions for generic fs use") Signed-off-by: Alexander Dahl <ada@thorsis.com>
Tom Rini [Fri, 9 Aug 2024 20:00:04 +0000 (14:00 -0600)]
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.
Fedor Ross [Wed, 7 Aug 2024 14:08:01 +0000 (16:08 +0200)]
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.
Fedor Ross [Wed, 7 Aug 2024 14:08:00 +0000 (16:08 +0200)]
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.
David Virag [Fri, 2 Aug 2024 19:19:16 +0000 (21:19 +0200)]
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>
Heiko Stuebner [Fri, 2 Aug 2024 21:00:27 +0000 (23:00 +0200)]
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
Alexey Charkov [Fri, 2 Aug 2024 21:00:26 +0000 (23:00 +0200)]
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.
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).
FUKAUMI Naoki [Fri, 2 Aug 2024 02:49:49 +0000 (11:49 +0900)]
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
=> 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
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.
(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>
Jonas Karlman [Fri, 2 Aug 2024 22:12:23 +0000 (22:12 +0000)]
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>
Trevor Woerner [Fri, 2 Aug 2024 22:12:21 +0000 (22:12 +0000)]
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'.
(cherry picked from commit 8b26cf42ba0c74a9c86cebe591a9195f75151d97) Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
FUKAUMI Naoki [Fri, 2 Aug 2024 22:12:20 +0000 (22:12 +0000)]
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
(cherry picked from commit 8324bc7493e4088013c62bc41f49d6d181575493) Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Jonas Karlman [Fri, 2 Aug 2024 22:12:19 +0000 (22:12 +0000)]
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.
(cherry picked from commit 1476c5882f8a47b6f0f895c6424dacf6334487ae) Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Jonas Karlman [Wed, 31 Jul 2024 07:28:54 +0000 (07:28 +0000)]
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>
Jonas Karlman [Wed, 31 Jul 2024 07:28:53 +0000 (07:28 +0000)]
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.
projects / u-boot.git / log