Re: [GIT PULL] ~RISC-V~Starfive devicetrees fixes for v7.0-rc6

[Conor Dooley]

On Fri, Mar 27, 2026 at 09:19:37AM +0100, Krzysztof Kozlowski wrote:
> On 26/03/2026 16:44, Heinrich Schuchardt wrote:
> >>
> >>> I have done an ~80%+ analysis on Ghidra decompilation of the JH-7110
> >>> BootROM, and openly invite anyone that would like to help get this
> >>> effort to 100% is welcome to so that we may publish and refer to this
> >>> for technical competence. I do not object to the community supporting
> >>> this deprecated capability if there is any real documentation not based
> >>> on rumors and memes; but no one has offered to do take a moment to do
> >>> this most basic of fact finding. Evidently the StarFive maintainer(s)
> >>> have refused to support this, GPL non-compliance persists and only a
> >>> rough description from Hal has been written to the U-Boot developer mail
> >>> list that does not match my analysis, all while complaining about the
> >>> capability not being supported going forward.
> >>>
> >>> I object to this PR it is NAK from me on the basis of stuffing this in
> >>> sideways without technical justification or review. Also I do object to
> > 
> > Concerning technical justification it is clear:
> > 
> > Distro images have been supplied with U-Boot on SD-card for years and 
> > the recent work in Linux and U-Boot broke booting them. This needs to be 
> > fixed.
> > 
> >>
> >> The technical justification seemed to me to be multiple people saying "we
> >> need this added so that u-boot can use the sd-card". The patch has been
> >> on the list for over three weeks at this point, so there was definitely
> >> opportunity to comment on it. I don't think I have been unreasonable
> >> here. If current U-Boot needs it, then I'd still like to have it merged.
> >> If you work pulls through and this becomes no-longer required, then I'd
> >> be happy to take it back out again.
> >>




> >>> "riscv: dts: starfive: Milk-V Mars CM Lite broken-cd" as this goes the
> >>> wrong way around, it does not describe the hardware; if some external
> >>> carrier boards cannot deal with the capability of the Mars CM
> >>> system-on-module having card detect line then that should be dealt with
> >>> as a dtbo per-carrier board and not be replaced in the dts by a
> >>> broken-cd, although at least we had this discussion and Conor made a
> >>> decision with all the facts and discussion available.
> >>>
> > 
> > As my patch points out the CD line is broken because it does not conform 
> > to the standard established by Raspberry.
> 
> Initial E Shattow answer is not placed under specific commit, so I can
> only guess that it is about "riscv: dts: starfive: Milk-V Mars CM Lite
> broken-cd".

This part is about about that patch, everything else in this chain is
about "riscv: dts: starfive: jh7110-common: fix jh7110 SoC boot from
SD-card" that adds a bootph to a shared dtsi.

> The commit touches only DTS, not DTSO, so how can you claim that a DTS
> file change breaks some completely other board (Raspberry)?
> 
> This DTS file is nowhere included (and should not be).
> 
> Of course maybe the true question would be why anyone described a hat as
> DTS file...
> 
> > 
> > E. we know that by chance you have found a base board that ignores the 
> > standard.
> > 
> > Your patch 4cce8b2503ab5 made my standard compliant baseboard unusable. 
> 
> DTS of some board is a final product, so it cannot be applied to a
> baseboard, that's pretty messed DTS tree...

The cm-lite is a rpi compute module compatible device, the base boards
don't have any devices on them in a lot of cases and just provide
physical connectors, so there's no point having a distinct dts for every
baseboard of that type.
https://www.waveshare.com/product/cm4-io-base-a.htm

> 
> > My patch in the pull request does not stop your board from booting but 
> > re-enables mine.
> > 
> > Best regards
> > 
> > Heinrich
> 
> 
> Best regards,
> Krzysztof

Attachment: signature.asc
Description: PGP signature