[PATCH 1/2] arm: dts: Add override for RB1

[Sumit Garg]

On Wed, Apr 09, 2025 at 07:23:09PM +0200, Caleb Connolly wrote:
> 
> 
> 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.garg at 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.garg at 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.

Generally in Linux, we don't enable complete hardware support in one go
but it is rather incremently enabled where people make use of this
"status" property. So IMHO, it shouldn't be anything different for
U-Boot too.

> > > 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.

It's really nice to see the fixups using OF_LIVE.

> 
> > 
> > > 
> > > 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.

Great, you beat me to that. I have dropped the RB1 DT override patch
from the v2 [1] in favour of your patch-set.

> 
> 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....

I repoduced it on my remote RB1 setup. The PHY power on was broken by
recent addition of SM660 platform support. I fixed that as part of v2 [1]
too.

> 
> Please give these a spin and let me know how it goes.
> 
> https://lore.kernel.org/u-boot/20250409-livetree-fixup-v1-0-76dfea80b07f@linaro.org

It really works fine for me without any pinctrl error for SD card,
thanks.

[1] https://patchwork.ozlabs.org/project/uboot/list/?series=452055

-Sumit