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