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

[Krzysztof Kozlowski]

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

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

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


Best regards,
Krzysztof