Hi Paul,
I'm not entirely sure on whose side the issue is, but I didn't receive
your mails, either from the U-Boot mailing list or directly from the Cc
field. I however could find the patch on lore.kernel.org... and I also
received yours and Dragan's exchange on patch 4 (but not the patch
itself). Any chance you received something from my mail server? Does
anyone in Cc of this mail actually received the mail?
On 9/26/24 8:31 PM, Paul Kocialkowski wrote:
From: Paul Kocialkowski <cont...@paulk.fr>
The reset mechanism used by Linux to reset the SoC is known to only
partially reset the logic. A mechanism is implemented in
rk3399_force_power_on_reset to use a GPIO connected to the PMIC's
over-temperature (OTP) reset pin, which fully resets all logic.
Hook the associated GPIO where the function expects it to enable this
reset mechanism and avoid any possible side-effect of partially-reset
units.
Without this patch, reading from the micro sd slot fails after a reset.
With this mechanism, U-Boot is able to boot from it reliably.
Signed-off-by: Paul Kocialkowski <cont...@paulk.fr>
---
arch/arm/dts/rk3399-roc-pc-u-boot.dtsi | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm/dts/rk3399-roc-pc-u-boot.dtsi
b/arch/arm/dts/rk3399-roc-pc-u-boot.dtsi
index aecf7dbe383c..883d399a06a3 100644
--- a/arch/arm/dts/rk3399-roc-pc-u-boot.dtsi
+++ b/arch/arm/dts/rk3399-roc-pc-u-boot.dtsi
@@ -7,6 +7,10 @@
#include "rk3399-sdram-lpddr4-100.dtsi"
/ {
+ config {
+ sysreset-gpio = <&gpio1 RK_PA6 GPIO_ACTIVE_HIGH>;
I think this is the wrong pin to use.
The routing of GPIO1_A6 is similar on RK3399 Puma and Pine64 RockPro64,
but it differs massively for the Firefly Roc PC.
However, a similar routing is done for GPIO1_A5 on the Firefly, I
believe that one is more appropriate. What do you think?
Cheers,
Quentin
