These pinctrls manage the low-speed PCIe signals:
- CLKREQ#: An output on the RK3588 (both RC or EP modes), used to
request that external clock-generation circuitry provide a clock.
- PERST#: An input on the RK3588 in EP mode, used to detect a reset
signal from the RC. In RC mode, the hardware does not use this signal:
Linux itself generates it by putting the pin in GPIO mode.
- WAKE#: In EP mode, this is an output; in RC mode, this is an input.
Each of these signals serves a distinct purpose, and more importantly,
PERST# should not be muxed when the RK3588 is in the RC role. Bundling
them together in pinctrl groups prevents proper use: indeed, almost none
of the current board-specific .dts files make any use of them.
(Exception: Rock 5A recently had a patch land that misuses _pins; this
patch corrects that.)
However, on some RK3588 boards, the PCIe 3 controller will indefinitely
stall the boot if CLKREQ# is not muxed (details in the next patch).
This patch unbundles the signals to allow them to be used.
Signed-off-by: Sam Edwards <CFSworks@gmail.com>
Link: https://lore.kernel.org/r/20240912025034.180233-2-CFSworks@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
[ upstream commit: 4294e32111781b3de4d73b944cbd1bc1662a9a7a ]
(cherry picked from commit 8713425fa162b61bcf5f7a6dcd171fddfb12be36)
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Typically any non-removable storage (emmc) is listed before removable
storage (sd-card) options. Also U-Boot will try to override and use
mmc0=sdhci and mmc1=sdmmc0 for all rk356x boards.
Fixes: 50decd493c83 ("arm64: dts: rockchip: Add FriendlyARM NanoPi R3S board")
Suggested-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Tianling Shen <cnsztl@gmail.com>
Link: https://lore.kernel.org/r/20241022193537.1117919-6-cnsztl@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
[ upstream commit: b7cd1115456d312f8c5e60c80fdc35fd35ea6eab ]
Signed-off-by: Tianling Shen <cnsztl@gmail.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
For new PowerPC developments, it will be useful to borrow devicetrees
from Linux. This patch makes it possible.
Signed-off-by: J. Neuschäfer <j.ne@posteo.net>
Reviewed-by: Sumit Garg <sumit.garg@linaro.org>
i.MX91 is a derived from i.MX93, and most clocks could be reused from
i.MX93. Also Update imx93-clock.h to sync with linux next.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
While I had thought this commit was a cherry-pick from upstream, it is
not. And so, this is not allowed here.
This reverts commit dfe5f16a33.
Signed-off-by: Tom Rini <trini@konsulko.com>
The R2S Plus is basically an R2S with additional eMMC.
The eMMC configuration for the DTS has been extracted and copied from
rk3328-nanopi-r2.dts, v2017.09 branch from the friendlyarm/uboot-rockchip
repository.
Signed-off-by: Sergey Bostandzhyan <jin@mediatomb.cc>
Link: https://lore.kernel.org/r/20240814170048.23816-2-jin@mediatomb.cc
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
[ upstream commit: b8c02878292200ebb5b4a8cfc9dbf227327908bd ]
(cherry picked from commit c9bf98827964441f4dd16faa45bd4046f472e693)
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Cool Pi CM5 GenBook works as a carrier board connect with CM5 [0].
Specification:
- Rockchip RK3588
- LPDDR5X 8/32 GB
- eMMC 64 GB
- HDMI Type A out x 1
- USB 3.0 Host x 1
- USB-C 3.0 with DisplayPort AltMode
- PCIE M.2 E Key for RTL8852BE Wireless connection
- PCIE M.2 M Key for NVME connection
- eDP panel with 1920x1080
This patch add basic support to bringup eMMC/USB HOST/WiFi/TouchPad/
Battery/PCIE NVME, and can also drive a HDMI output with out of tree
hdmi patches.
[0] https://www.crowdsupply.com/shenzhen-tianmao-technology-co-ltd/genbook-rk3588
Signed-off-by: Andy Yan <andyshrk@163.com>
Link: https://lore.kernel.org/r/20240730102433.540260-3-andyshrk@163.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
[ upstream commit: 4a8c1161b843c366776fc872a6fe45b743b2983e ]
(cherry picked from commit dc6316da23734d9321e09f8c8a7669f4b4cb9f75)
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Add support for the DH electronics i.MX6DL DHCOM SoM and a PDK2 evaluation
board. The evaluation board features three serial ports, USB OTG, USB host
with an USB hub, Fast or Gigabit ethernet, eMMC, uSD, SD, analog audio,
PCIe and HDMI video output.
All of the aforementioned features except for mSATA are supported, mSATA
is not available on i.MX6DL and is only available on DHCOM populated with
i.MX6Q SoC which is already supported upstream.
Backport from linux-next commit
c3f5d76a6e03 ("ARM: dts: imx6dl: Add support for i.MX6DL DHCOM SoM on PDK2 carrier board")
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Christoph Niedermaier <cniedermaier@dh-electronics.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
The device contains two i2c-connected eeproms holding some product-
specific values. One sitting on the mainboard and one on the statically
connected backplane.
While the eeprom chips themself have a size of 512 byte, the eeprom data
only uses 256 byte each, probably to stay compatible with other models.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20240810211438.286441-3-heiko@sntech.de
[ upstream commit: da6f4130234448122fe3e66c8116f7d9eea8a5c7 ]
(cherry picked from commit 0b3109708caf5002ba188ae28eae9ce46b2c39b4)
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Contrary to the vendor-kernel the pmu-io-domains are not enabled by
default. This resulted in the value not being set according to the
regulator, which in turn made the gmac0 interface that is connected
to the vccio4 supply inoperable.
Fixes: 64b7f16fb394 ("arm64: dts: rockchip: add 2 pmu_io_domain supplies for Qnap-TS433")
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20240805162052.3345768-1-heiko@sntech.de
[ upstream commit: 40cc4257169712f0ae3835820a4c5afbdd1a16ff ]
(cherry picked from commit f509fcb1fb82117e551b489592ac5714a6c5cd8d)
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
While it requires to have the right phy driver loaded (i.e. motorcomm)
to make the phy asserting the right delays, this is generally the
preferred way to define the MAC <-> PHY connection.
Signed-off-by: Uwe Kleine-König <ukleinek@debian.org>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://lore.kernel.org/r/20240304084612.711678-2-ukleinek@debian.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
[ upstream commit: e8d45544f806f3b55c30345de84262cbb9504902 ]
(cherry picked from commit e0bbe061fd537bd7b113c53eb046bbcbf0e6597d)
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
The TS433 doesn't provide display output, but the gpu nevertheless can be
used for compute tasks for example.
So there is no reason not to enable it.
Tested-by: Uwe Kleine-König <ukleinek@debian.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20240723195538.1133436-14-heiko@sntech.de
[ upstream commit: 9130eb62586f4cef0557d0378fb7e78d7397ab2d ]
(cherry picked from commit e324a9e8ea083ebdca207b5ca2ed86d2b5f862a0)
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Fill in the missing pieces for RK809 pmic used on the TS433.
The regulator setup comes from the vendor-devicetree, so without proper
schematics its accuracy is somewhat unclear, but it looks really similar
to all the other rk3568 boards, so follows the reference design it seems.
The one caveat is related to vcc3v3_sd. This regulator needs to stay on.
When turned off because of no users, access to both PCIe controllers
will stall. Maybe this rail does supply the 100MHz refclk generation
or so.
Tested-by: Uwe Kleine-König <ukleinek@debian.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20240723195538.1133436-13-heiko@sntech.de
[ upstream commit: ee078c7daa98353496410b715a5acbb41d7d3a90 ]
(cherry picked from commit 48951cb085998a5c8e3650351a794b136dac648f)
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
The TS433 seems to use a silergy,syr827 regulator for the cpu supply.
At least that is the compatible used in the vendor devicetree, though
it could very well also be another fan53555 clone.
Define the needed regulator node and hook up the cpu-supply to the
cpu cores.
Tested-by: Uwe Kleine-König <ukleinek@debian.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20240723195538.1133436-12-heiko@sntech.de
[ upstream commit: 99b36ba910d896bddbb9a190ca686c6d9cd0325f ]
(cherry picked from commit 2f0afd1a3cbf6f3192dc7a5c496affab718671b3)
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
The TS433 has 3 buttons, power and copy in the front as well as a reset
pinhole button on the back. The power-button is connected to the embedded
controller while the other two buttons are just gpio connected.
Add the gpio-keys definition for the two buttons we can handle right now.
Tested-by: Uwe Kleine-König <ukleinek@debian.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20240723195538.1133436-11-heiko@sntech.de
[ upstream commit: 9b682d31b24f1f70b5b4d0618095d46e0722b9d8 ]
(cherry picked from commit f0b858c751382ee9faf18f9b19b0817c6b50ac1c)
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Add the 4 gpio-controlled LEDs to the Qnap-TS433.
They are meant for individual disk activitivy, but I haven't found a
way for how to connect them to their individual sata slot yet.
Tested-by: Uwe Kleine-König <ukleinek@debian.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20240723195538.1133436-9-heiko@sntech.de
[ upstream commit: ea91aabf18bcad6f5eceae6848ea6570ea61f126 ]
(cherry picked from commit 5a11b1bb40ac7b39e04077c045c3e3409fa352e2)
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Add the aliases for the internal network interface as well as the emmc
on the board and make sure the dedicated RTC is always the first one.
The TS433 actually has two rtc devices. One coming from the rk809 pmic
without added functionality and also a dedicated RTC from Mycrocrystal
that is battery backed to keep the time.
Tested-by: Uwe Kleine-König <ukleinek@debian.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20240723195538.1133436-8-heiko@sntech.de
[ upstream commit: dadd4256e12360d3ff1f6481b2e4697f9d890caf ]
(cherry picked from commit cb53815764403f7f17967a32eec2aeb6625b396f)
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
The TS433 has 4 bays. The last two are accessed via a pci-connected
sata controller, while the first two are accessed via the rk3568's
sata controllers. Enable these two now.
Tested-by: Uwe Kleine-König <ukleinek@debian.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20240723195538.1133436-7-heiko@sntech.de
[ upstream commit: 673c1353b3d476b9c5df6b84a777ed171e5594f5 ]
(cherry picked from commit dfa45bbda057851d0c2167b4c311c0301637cc19)
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Enable usb controllers and phys and add regulator infrastructure for the
usb ports on the TS433.
Of course there are no schematics available for the device, so the
regulator information comes from the vendor-devicetree with unknown
accuracy.
Tested-by: Uwe Kleine-König <ukleinek@debian.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20240723195538.1133436-5-heiko@sntech.de
[ upstream commit: d992203f57c5caad0dbd4a9c669d79b315873c81 ]
(cherry picked from commit bb745ef13efb9f6589f9eda8f66664bf263a13f3)
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
The TS433 uses both pcie controllers for sata and the 2nd network
interface. Set the needed data-lanes in the pcie3 phy and enable
the second pcie controller, as well as remove the bifurcation comment.
Tested-by: Uwe Kleine-König <ukleinek@debian.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20240723195538.1133436-3-heiko@sntech.de
[ upstream commit: 0f5f87a1d602a33028522784eb005647fa1b5c11 ]
(cherry picked from commit 7d8f260e65cc84076ec9456954de0f136948a2c8)
Jan Kiszka <jan.kiszka@siemens.com> says:
This adds support for the new IOT2050 SM variant, introduces a sysinfo
driver which also permits SMBIOS support and switches the board to
OF_UPSTREAM. There are some further fixes for the boards included as well.
Not yet included is configuration support for DMA isolation via the PVU as
this depends on not yet merged DT bindings and another overlay.
[trini: This is just the first 10 patches in the series for now]
Link: https://lore.kernel.org/r/cover.1729577070.git.jan.kiszka@siemens.com
The U-Boot copy of the mpfs devicetree has, in general, been neglected
somewhat in comparison to the one in Linux. Moving to OF_UPSTREAM to
keep both in sync should serve to eliminate that discrepancy.
Additionally, moving to OF_UPSTREAM will let U-Boot automatically pick
up the devicetree rework that is in progress at [1].
Link: https://lore.kernel.org/all/20241002-private-unequal-33cfa6101338@spud/ [1]
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
Reviewed-by: Sumit Garg <sumit.garg@linaro.org>
To allow firmware to pick up all DTs from here, move the overlays that
are normally applied during DT fixup to the kernel source as well. Hook
then into the build nevertheless to ensure that regular checks are
performed.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Link: https://lore.kernel.org/r/91f8b825467651ebd51a4051f153ab136eeb1849.1724830741.git.jan.kiszka@siemens.com
Signed-off-by: Nishanth Menon <nm@ti.com>
[ upstream commit: dba27d026fc841d28a0ed373f617cc84ec0e4504 ]
(cherry picked from commit 741915246a92fc4c21537f9623a69612f7cef03a)
The PG1 A variant of the iot2050 series has been identified which
partially lacks support for lock-step mode. This implies that all
iot2050 boards can't support this mode. As a result, lock-step mode has
been disabled across all iot2050 boards for consistency and to avoid
potential issues.
Signed-off-by: Li Hua Qian <huaqian.li@siemens.com>
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Link: https://lore.kernel.org/r/d1f5f84db7a1597cd29628a0b503e578367b7b40.1724830741.git.jan.kiszka@siemens.com
Signed-off-by: Nishanth Menon <nm@ti.com>
[ upstream commit: e0133f883cf115d9e97e704169a9fb6003caefb2 ]
(cherry picked from commit 4b4872feb66a9043741819a57af280ffb4a96608)
In the LTS (2310) version the miniPCIe slot got removed and USB 2.0
setup has changed. There are two external accessible ports and two ports
on the internal header.
There is an on-board USB hub which provides:
- one external connector (bottom one)
- two internal ports on pin header
- one port for m.2 E connector
The top USB 2.0 connector comes directly from the SoC.
Signed-off-by: Marcin Juszkiewicz <marcin.juszkiewicz@linaro.org>
Link: https://lore.kernel.org/r/20240829-friendlyelec-nanopc-t6-lts-v6-4-edff247e8c02@linaro.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
[ upstream commit: db1dcbe5f752d423421f77d54d246398b196f670 ]
(cherry picked from commit f4a834fbc8cdb40fddd63d083e8d1c6189ba62dc)
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
The Hardkernel ODROID-M1S is a single-board computer based on Rockchip
RK3566 SoC. It features e.g. 4/8 GB LPDDR4 RAM, 64 GB eMMC, SD-card,
GbE LAN, HDMI 2.0, M.2 NVMe and USB 2.0/3.0.
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/20240827211825.1419820-5-jonas@kwiboo.se
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
[ upstream commit: 10dc64fe0f980c47c7e747885ddf7a8c12780337 ]
(cherry picked from commit f811548e758b52896f725753086c42b49dc42c0d)
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Acked-by: Sumit Garg <sumit.garg@linaro.org>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
The vendor prefix for Hardkernel ODROID-M1 is incorrectly listed as
rockchip. Use the proper hardkernel vendor prefix for this board, while
at it also drop the redundant soc prefix.
Fixes: fd3583267703 ("arm64: dts: rockchip: Add Hardkernel ODROID-M1 board")
Reviewed-by: Aurelien Jarno <aurelien@aurel32.net>
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Link: https://lore.kernel.org/r/20240827211825.1419820-3-jonas@kwiboo.se
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
[ upstream commit: 735065e774dcfc62e38df01a535862138b6c92ed ]
(cherry picked from commit e7259a2c4a6f2ebdfc96b8bbffc77fe67604b11f)
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Acked-by: Sumit Garg <sumit.garg@linaro.org>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
The Hardkernel ODROID-M2 is a single-board computer based on Rockchip
RK3588S2 SoC. It features e.g. 8/16 GB LPDDR5 RAM, 64 GB eMMC, SD-card,
GbE LAN, HDMI 2.0, M.2 NVMe and USB 2.0/3.0/Type-C.
Add initial support for eMMC, SD-card, Ethernet, PCIe and USB.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Link: https://lore.kernel.org/r/20240901112020.3224704-3-jonas@kwiboo.se
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
[ upstream commit: ce48b8c976ce439c336def6e06bf8224a8ff9125 ]
(cherry picked from commit 7ba62d8b4cb010c6fcb7077550b46d5f5fb5af6d)
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
CI: https://source.denx.de/u-boot/custodians/u-boot-imx/-/pipelines/22796
- Switch to using upstream DT on DH i.MX8MP DHCOM PDK2/PDK3.
- Add ability to build fallback DTBOs from arch/$(ARCH)/dts.
- Remove fdt_high and initrd_high env variables from imx6-dhcom.
- Add dummy clk for imx8.
- Fix DT corruption in imx8_cpu.
- Improve DDR stability on pico-imx7d.
Currently the enablement of OF_UPSTREAM results on the build system
searching for DTs only in dts/upstream/ . There are platforms which
use U-Boot specific DTBOs applied on top of U-Boot control DT during
SPL stage, and source DTs for these are located in arch/$(ARCH)/dtb.
Add dedicated 'dtbos' target which builds only .dtbos and not .dtbs and
in case CONFIG_OF_UPSTREAM_INCLUDE_LOCAL_FALLBACK_DTBOS is enabled, build
this target for arch/$(ARCH)/dtb to generate local U-Boot specific DTBOs.
Adjust top level Makefile so binman would search for .dtb and .dtbo in
both OF_UPSTREAM specific paths and arch/$(ARCH)/dtb for the .dtbo case
in case CONFIG_OF_UPSTREAM_INCLUDE_LOCAL_FALLBACK_DTBOS is enabled.
Reviewed-by: Sumit Garg <sumit.garg@linaro.org>
Signed-off-by: Marek Vasut <marex@denx.de>
Allow to use OF_OVERLAY_LIST also for the case that the overlays just
need be built, e.g. when they will be picked up by binman as artifacts
of the final U-Boot image. The IOT2050 boards have such a need when
switching to OF_UPSTREAM.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Reviewed-by: Sumit Garg <sumit.garg@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Sam EdwardsandTom Rini
Tianling ShenandTom Rini
J. NeuschäferandTom Rini
Peng FanandFabio Estevam
Udit KumarandTom Rini
Sergey BostandzhyanandKever Yang
Andy YanandKever Yang
Marek VasutandFabio Estevam
Heiko StuebnerandKever Yang
Uwe Kleine-KönigandKever Yang
Conor DooleyandLeo Yu-Chi Liang
Jan KiszkaandTom Rini
Li Hua QianandTom Rini
Marcin JuszkiewiczandKever Yang
Jonas KarlmanandKever Yang