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

[E Shattow]

On 3/26/26 08:14, Conor Dooley wrote:
...
> All the patch does is tell bootloaders what stage of the boot they
> should should pay attention to the node, and the link was to a big
> mechanical deletion, with a reasonable comment from someone that
> has a track record.
>

Yes, there is nothing about this (bootph-pre-ram hint) to do with
booting Linux. All boards support the official recommended SPI Flash
location for StarFive Loader in BootROM to boot Secondary Program
Loader, which in the case of U-Boot SPL with filtered devicetree has all
it needs to load U-Boot Main from SPI Flash which has full devicetree
(and so boot from network, UART, SD/eMMC, USB, PCIe... whatever).

Only for a subset of board is it possible to set the RGPIO0 RGPIO1
signal lines to a configuration that will trigger the StarFive Loader in
BootROM code path to attempt to load from the VisionFive2 1.2a or 1.3b
reference board arrangement of mmc interfaces, which are hard-coded
configured as SD Card and MMC. The MMC hardware setup does not "flip"
based on the RGPIO0 RGPIO1 configuration, so boards with opposite
connection order of SD Card and MMC to what the VisionFive2 has are
unable to work with this even if they are able to set those signals.

All newer board designs than the VisionFive2 follow official StarFive
design advice that StarFive Loader in BootROM function to load Secondary
Program Loader from MMC is unreliable. It may work, it may not, there's
no further description published about this topic.

>
> I'm sorry, but I have only a passing familiarity with your work there
> (as in, I have seen you talk about it on IRC and paid no attention), and
> there's no way I would have associated it with this change.
> I definitely was not ignoring a wider conversation by merging this
> patch, I was not aware this was controversial at all!

For that, I'm disappointed to have missed an opportunity to participate,
but also want to know if I'm expected to also regularly scan the
linux-devicetree mailing list for this very situation where a starfive
devicetree "fix" is absent from the "open list:STARFIVE DEVICETREES"
linux-riscv mailing list?

If I had been asked to review this then I would have done so. If it was
mailed per scripts/get_maintainer.pl then I would have opted to at least
reply asking for a better commit message and clarification about what
specific hardware this has been tested for. As it is now I was not aware
of this until the PR.

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

I missed this entirely as there was not CC'd linux-riscv or lkml mailing
lists what I monitor for "starfive" in the subject.

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

On 3/26/26 08:44, Heinrich Schuchardt wrote:
...
> 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.
>

Okay, Heinrich:

https://freeshell.de/e/riscv64/hrv-jhre-JH-7110%20BootROM%20analysis_2026_02_22.gar

Load the project archive file (above) with Ghidra 12.x

https://github.com/NationalSecurityAgency/ghidra/releases

Tell us what you find about why this 'bootph-pre-ram' is needed, with
code excerpts. I want to believe...

>>
...
>>> "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.
>
> E. we know that by chance you have found a base board that ignores the
> standard.

Two of two base boards, here, are compatible with this CD signal (and
some others that I did find schematics for).

We did identify that the CM4 IO Compute carrier board follows the
official Raspberry Pi Foundation published standard.

Obviously this depends on the base board. I don't believe that disabling
a valid signal should be the default, that is dtb overlay subject matter.

>
> Your patch 4cce8b2503ab5 made my standard compliant baseboard unusable.
> My patch in the pull request does not stop your board from booting but
> re-enables mine.
>
> Best regards
>
> Heinrich

I don't want SD polled when there's a perfectly good card detect line in
the hardware as it was designed! Don't break my card detect due to your
hardware being non-compatible with radxa cm3, fix your broken (if
"standards compliant") board with an overlay.

On 3/26/26 12:27, Ilya Sorochan wrote:
> On Thu, Mar 26, 2026 at 07:36:07AM -0700, E Shattow 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
>> ... 
> Appreciate the effort!
> However I can't see how this is related.

Your patch was sent to a minimum audience which perhaps if you are a
first time contributor is understandable but I would have hoped between
you, Heinrich reviewing, and Conor accepting the patch someone would
have noticed that scripts/get_maintainer.pl was either not used or some
overzealous trimming of CC is going on! Also this is probably the
dozenth time I have explained at great length to Heinrich my concerns so
it is deeply disappointing to miss this opportunity for contributing, I
guess I consider it disrespectful though maybe no fault of your own
there Ilya for wanting your hardware to continue working as you
expected? I get that... there is in no way any desire to discourage
anyone from posting patches or fixes, this particular situation is a
headache for me... maybe I'm the problem okay because I cannot reverse
engineer a whole BootROM on my own, I only get to 80% and then people
have their own motivations and reasons for not wanting to spend any time
to do this properly? :)

> 
> I traced this property a little in the U-Boot repo:
> - 503fc8548197 Hal added it to VisionFive v1.3b (with mmc pins)
> - 6bbe95ef7208 Hal moved it (and other common things) into
>   jh7110-common-u-boot.dtsi
> - 27f617019dd0 E removed it with jh7110-common-u-boot.dtsi
> - 762f85bb2e36 Tom squash-updated upstream dts
> 
> New device trees did not contain this property. This is how they were introduced
> into the Linux: b127dbf9e1ebbfbcded4 ("riscv: dts: starfive: Add mmc nodes on
> VisionFive 2 board")
> 
> I do not know if this miss is intentional or not. However it would be nice to
> be able to boot from SD-card again.

There is already nothing to prevent you from booting Linux from SD-card,
with U-Boot SPL and U-Boot Main located in SPI Flash as is recommended
by StarFive officially.

I'm glad you sent a patch, but I still object for the other reasons
mentioned.

-E