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

[Ilya Sorochan]

> 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? :)

Sorry, I'm not trying to be disrespectful. Yes, it's my first time. Kernel docs
bewarn of spamming therefore I trimmed CC based on the assumption that those who
interested in devicetrees are present in devicetree lists. I guess it is not
true which seems strange to me, but okay.

I'm not asking to support this feature properly. It would be nice to have but
it is hard and StarFive is not making it any easier. However I'm asking to keep
it working while you can if you can. It worked for me and other people and we
would appreciate if you can delay breaking it as long as possible.

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

Yes. However I'm implying the deprecated SDIO3.0 way. I agree that this would be
nice to have in the commit message - if this what are you talking about.

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

I'm glad to talk to competent people in this space, however I still hope that
the kernel will refrain from breaking this feature until it is really necessary.