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>
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.
Jonas Karlman [Tue, 30 Jul 2024 14:51:42 +0000 (14:51 +0000)]
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.
Jonas Karlman [Tue, 30 Jul 2024 14:27:50 +0000 (14:27 +0000)]
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>
Jonas Karlman [Thu, 25 Jul 2024 09:46:04 +0000 (09:46 +0000)]
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>
Jonas Karlman [Thu, 25 Jul 2024 09:46:03 +0000 (09:46 +0000)]
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>
Jonas Karlman [Wed, 24 Jul 2024 06:58:15 +0000 (06:58 +0000)]
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>
Jonas Karlman [Wed, 24 Jul 2024 06:55:36 +0000 (06:55 +0000)]
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>
Tom Rini [Fri, 9 Aug 2024 00:37:11 +0000 (18:37 -0600)]
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.
Dhruva Gole [Mon, 5 Aug 2024 14:29:37 +0000 (19:59 +0530)]
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
Dhruva Gole [Mon, 5 Aug 2024 14:29:36 +0000 (19:59 +0530)]
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.
Dhruva Gole [Mon, 5 Aug 2024 14:29:35 +0000 (19:59 +0530)]
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.
Dhruva Gole [Mon, 5 Aug 2024 14:29:34 +0000 (19:59 +0530)]
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.
Dhruva Gole [Mon, 5 Aug 2024 14:29:32 +0000 (19:59 +0530)]
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
Tom Rini [Thu, 8 Aug 2024 13:59:47 +0000 (07:59 -0600)]
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
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.
Tom Rini [Tue, 6 Aug 2024 15:36:46 +0000 (09:36 -0600)]
Merge branch 'master' of https://source.denx.de/u-boot/custodians/u-boot-sunxi
This updates the "old style" DTs to that of Linux v6.10, matching what
OF_UPSTREAM is at now. Hopefully we won't need to do this (manually)
anymore. Since this brings in the DT for a new board (Tanix TX1), also
add the defconfig for that, which has just been waiting for that sync.
There are three more fixes: two for the SPI clock setup, which avoids
too high frequencies in some cases, and one fix to avoid a build warning
with GCC 14 for the sunxi TOC0 part of the mkimage tool.
The gitlab CI passed, and I tested the SPI flash on the OrangePi Zero 3
and also booted that into Linux.
Michael Walle [Thu, 18 Jul 2024 20:42:53 +0000 (22:42 +0200)]
spi: sunxi: fix clock divider calculation for max frequency setting
If the maximum frequency is requested, we still fall into the CDR2
handling. But there the minimal divider is 2. For the sun6i and sun8i we
can do better with the CDR1 setting where the minimal divider is 1:
SPI_CLK = MOD_CLK / 2 ^ cdr with cdr = 0
Thus, handle the div = 1 case specially.
While at it, correct the comment above the calculation.
Signed-off-by: Michael Walle <mwalle@kernel.org> Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Michael Walle [Thu, 18 Jul 2024 20:42:52 +0000 (22:42 +0200)]
spi: sunxi: fix CDR2 calculation
The CDR2 divider calculation always yield a frequency greater than the
requested one. Use DIV_ROUND_UP() to keep the frequency equal or below
the requested one. This way, we can also drop the "if div > 0" check
because we know for a fact that div cannot be zero.
FWIW, this aligns the CDR2 calculation with the linux driver.
Suggested-by: Andre Przywara <andre.przywara@arm.com> Signed-off-by: Michael Walle <mwalle@kernel.org> Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Andre Przywara [Mon, 25 Mar 2024 21:58:39 +0000 (21:58 +0000)]
sunxi: h616: add Tanix TX1 support
The Tanix TX1 is a tiny TV box, featuring the Allwinner H313 SoC with up
to 2GB of DRAM and 16GB of eMMC. There is no SD card or Ethernet port on
this small device, but it can be booted via the USB debug "FEL" mode.
The bootloader could then be written to the eMMC.
Add the defconfig for that board, and add the devicetree file to the
Makefile, for it to be built.
The DRAM parameters were taken from the vendor firmware on the eMMC.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Andre Przywara [Fri, 19 Apr 2024 16:59:52 +0000 (17:59 +0100)]
sunxi: dts: arm/arm64: update devicetree files from Linux-v6.10
Sync the devicetree files from the official Linux kernel tree, v6.10.
This is covering Allwinner SoCs with 32-bit and 64-bit ARM cores.
Besides mostly cosmectic changes, this adds cpufreq support to H616
boards, Nothing that U-Boot needs for itself, but helpful to pass on
to kernels. We also get the .dts files for the Tanix TX1 TV box and
three Anbernic handheld gaming devices.
As before, this omits the non-backwards compatible changes to the R_INTC
controller, to remain compatible with older kernels.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Seung-Woo Kim [Thu, 1 Aug 2024 01:01:00 +0000 (10:01 +0900)]
tools: imagetool: Remove unnecessary check from toc0_verify_cert_item()
C99 introduced the possibility to mark function parameters declared as
arrays with an extra keyword "static":
void foo(uint8_t digest[static SHA256_DIGEST_LENGTH]);
This requires the respective function argument to be at least as large
as specified. Passing in random pointers (like NULL) then becomes
undefined behaviour, and compilers warn about this.
Newer GCC compilers (starting with GCC 14) will also automatically mark
those parameters as "nonnull", and thus warn if a (redundant) NULL check
is done inside the function:
tools/sunxi_toc0.o tools/sunxi_toc0.c
tools/sunxi_toc0.c: In function 'toc0_verify_cert_item':
tools/sunxi_toc0.c:447:12: warning: 'nonnull' argument 'digest' compared to NULL [-Wnonnull-compare]
447 | if (digest && memcmp(&extension->digest, digest, SHA256_DIGEST_LENGTH)) {
| ^
Remove the unnecessary NULL check from toc0_verify_cert_item(), to avoid
the warning.
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com> Reviewed-by: Andre Przywara <andre.przywara@arm.com>
[Andre: extend commit message] Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Tom Rini [Mon, 5 Aug 2024 18:15:44 +0000 (12:15 -0600)]
Merge patch series "Bug-fixes for a few boards"
Simon Glass <sjg@chromium.org> says:
This series includes fixes to get some rockchip and nvidia boards
working again. It also drops the broken Beaglebone Black config and
provides a devicetree fix for coral (x86).
Simon Glass [Thu, 1 Aug 2024 12:47:23 +0000 (06:47 -0600)]
rockchip: Avoid #ifdefs in RK3399 SPL
The code here is confusing due to large blocks which are #ifdefed out.
Add a function phase_sdram_init() which returns whether SDRAM init
should happen in the current phase, using that as needed to control the
code flow.
This increases code size by about 500 bytes in SPL when the cache is on,
since it must call the rather large rockchip_sdram_size() function.
Simon Glass [Wed, 31 Jul 2024 14:49:05 +0000 (08:49 -0600)]
fdt: Correct condition for bloblist existing
On some boards, the bloblist is created in SPL once SDRAM is ready. It
cannot be accessed until that point, so is not available early in SPL.
Add a condition to avoid a hang in this case.
This fixes a hang in chromebook_coral
Fixes: 70fe2385943 ("fdt: Allow the devicetree to come from a bloblist") Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Raymond Mao <raymond.mao@linaro.org>
Michal Simek [Tue, 30 Jul 2024 10:42:43 +0000 (12:42 +0200)]
arm64: zynqmp: Remove PM firmware checking
Having zynqmp firmware is actually only one valid configuration. In QEMU
case for example there is no PMU that's why this checking can't end up in
panic that's why code remove this code completely.
The correct operating mode for the fan is inversed (1). The
previous pwm driver implementation had a bug and the polarity
information was propagated incorrectly to the kernel. The normal (0)
polarity specified in the device tree was incorrectly clearing the
polarity bit in the counter control register. After the bug fix,
setting the polarity to inversed (1) in the device tree will clear
the polarity bit.
arm64: zynqmp: dts: Add rts delay property for rs485 mode on KD240
Add "rs485-rts-delay" property to uartps node with delay_rts_before_send
and delay_rts_after_send values as 10ms for rs485 mode on KD240.
10ms rts delay values have been chosen based on testing with rs485
temperature sensor (which is part of the kit) as safe minimum value
for reliable operation at a baud rate of 9600.
Michal Simek [Mon, 15 Jul 2024 14:38:30 +0000 (16:38 +0200)]
arm64: versal-net: Align node names with dt-schema
dt-schema is forcing some rules for node names that's why align them with
it. Labels are not changing that's why this change is not breaking any
other board specific DTSes.
xilinx: versal-net: Handle spi seq number based on boot device
Versal NET boards has QSPI and OSPI and default bus set to 0
is not working when system is booting out of OSPI which is
controller 1, as fixed aliases are set for all the boards
i.e., QSPI to 0 and OSPI to 1. Add controller autodetection
via spi_get_env_dev().
env_spi: support overriding spi dev from board code
This enables boards to choose where to/from the environment
should be saved/loaded. They can then for example support using
the same device (dynamically) from which the bootloader was
launched to load and save env data and do not have to
define CONFIG_ENV_SPI_BUS statically.
In my use case, the environment needs to be on the same device I
booted from. It can be the QSPI or OSPI device.
I therefore would override spi_get_env_dev in the board code,
read the bootmode registers to determine where we booted from
and return the corresponding device index.
config: Enable the config CONFIG_MMC_SPEED_MODE_SET
Enable setting speed mode using mmc dev commands.
The speed mode is provided as the last argument in these commands
(ex: mmc dev 0 0 10) and is indicated using the index from enum
bus_mode in include/mmc.h. A speed mode can be set if it is enabled
from device tree or from capabilities register
clk: zynqmp: Add set_rate support for display clocks
If "assigned-clock-rates" property is included in the
device tree, display driver probe is getting failed, as dp_video_ref
till dp_stc_ref clocks are missing from set rate function, adding
them to fix the probe failure.
projects / u-boot.git / log
