On 4/9/25 14:35, Sumit Garg wrote:
On Tue, Apr 08, 2025 at 04:43:49PM +0200, Caleb Connolly wrote:
On 4/8/25 15:46, Sumit Garg wrote:
On Tue, Apr 08, 2025 at 02:17:29PM +0200, Caleb Connolly wrote:
On 4/7/25 15:28, Sumit Garg wrote:
From: Sumit Garg <sumit.g...@oss.qualcomm.com>
Add U-Boot override for RB1 to for USB in host mode as OTG mode isn't
supported. Also, disable sdhc_2 as it's currently not supported, sdhc_1
works fine though.
Signed-off-by: Sumit Garg <sumit.g...@oss.qualcomm.com>
---
arch/arm/dts/qrb2210-rb1-u-boot.dtsi | 11 +++++++++++
1 file changed, 11 insertions(+)
create mode 100644 arch/arm/dts/qrb2210-rb1-u-boot.dtsi
diff --git a/arch/arm/dts/qrb2210-rb1-u-boot.dtsi
b/arch/arm/dts/qrb2210-rb1-u-boot.dtsi
new file mode 100644
index 00000000000..1e136ee405a
--- /dev/null
+++ b/arch/arm/dts/qrb2210-rb1-u-boot.dtsi
@@ -0,0 +1,11 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/* This is usually OTG but U-Boot doesn't support that properly */
+&usb_dwc3 {
+ dr_mode = "host";
+};
+
+/* SDHC_2 isn't supported in U-Boot as of now */
I'd rather avoid disabling this here, I guess it's just missing clocks and
regulators which doesn't justify modifying DT. An error that mmc1 couldn't
be enabled seems fine to me?
I totally echo with your thinking that we should avoid modifying DT but
at the same point we shouldn't enable peripherals in U-Boot which throws
errors. It's also possible that U-Boot misconfiguring mmc1 which might
I disagree, DT isn't enabling or disabling peripherals, it's describing
hardware.
It would be helpful if you can describe the use-case for "status"
property then.
https://devicetree-specification.readthedocs.io/en/latest/chapter2-devicetree-basics.html#status
These all describe the functionality of hardware, since implementation
details of the software (U-Boot) which is parsing the DT has absolutely
nothing to do with it.>
U-Boot lacking proper support for that hardware isn't a good
justification to disable it. Especially since you might boot Linux with the
same DT and now have no working sdcard for seemingly no reason.
We shouldn't use same DT unless both U-Boot and Linux support that
without modifications and *not* being in a broken state. The similar argument
holds true for USB OTG mode too.
Well, the main difference with the OTG fixup is that we undo it later
on, so if we boot an OS with this DT it won't have the override -- our
hacks aren't exposed.
An error in U-Boot is exactly the behaviour we want to see, masking it only
created confusion.> turn as a problem for later stages.
IMO, our first priority should be to fix U-Boot issues and then see if
we can use unmodified DT.
I have been totally working with a remote lab to fix issues on RB1. I
will soon get one on my desk then I will be able to fix mmc1 too.
In that case we can surely land the proper fixes for 2025.07 anyway, so I'd
just keep the errors until then.
Fixing errors in mainline will help other people confidence who are
trying to boot U-Boot on RB1. If you still have a strong preference to
keep SD card support enabled in broken state then I can live with that
until I fix it for real.
I decided to just have a crack at it and managed to get everything
cleaned up. sdcard seems to work on my RB1 with these patches on top of
qcom-next and the u-boot specific DTS hacks are removed.
USB phy init seems to fail for me, but the board I'm testing on is some
super early DVT so I'm hoping it's a silicon issue....
Please give these a spin and let me know how it goes.
https://lore.kernel.org/u-boot/20250409-livetree-fixup-v1-0-76dfea80b...@linaro.org
Kind regards,>
-Sumit
--
Caleb (they/them)
