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

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

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 1202 bytes --]

Hey folks,

Please pull a small fixes PR.

Cheers,
Conor.

The following changes since commit 0528a348b04b327a4611e29589beb4c9ae81304a:

  cache: ax45mp: Fix device node reference leak in ax45mp_cache_init() (2026-02-06 19:54:40 +0000)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux.git/ tags/riscv-dt-fixes-for-v7.0-rc6

for you to fetch changes up to 305f2865bd034146b2eebc77c27fc50d8d79778d:

  riscv: dts: starfive: jh7110-common: fix jh7110 SoC boot from SD-card. (2026-03-19 16:00:13 +0000)

----------------------------------------------------------------
RISC-V devicetrees fixes for v7.0-rc6

Starfive:
Two fixes for the SD cards on the Mars CM Lite.

Signed-off-by: Conor Dooley <conor.dooley@microchip.com>

----------------------------------------------------------------
Heinrich Schuchardt (1):
      riscv: dts: starfive: Milk-V Mars CM Lite broken-cd

Ilya Sorochan (1):
      riscv: dts: starfive: jh7110-common: fix jh7110 SoC boot from SD-card.

 arch/riscv/boot/dts/starfive/jh7110-common.dtsi           | 1 +
 arch/riscv/boot/dts/starfive/jh7110-milkv-marscm-lite.dts | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

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

[E Shattow]

On 3/26/26 04:13, Conor Dooley wrote:
> Hey folks,
> 
> Please pull a small fixes PR.
> 
> Cheers,
> Conor.
> 
> The following changes since commit 0528a348b04b327a4611e29589beb4c9ae81304a:
> 
>   cache: ax45mp: Fix device node reference leak in ax45mp_cache_init() (2026-02-06 19:54:40 +0000)
> 
> are available in the Git repository at:
> 
>   https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux.git/ tags/riscv-dt-fixes-for-v7.0-rc6
> 
> for you to fetch changes up to 305f2865bd034146b2eebc77c27fc50d8d79778d:
> 
>   riscv: dts: starfive: jh7110-common: fix jh7110 SoC boot from SD-card. (2026-03-19 16:00:13 +0000)
> 
> ----------------------------------------------------------------
> RISC-V devicetrees fixes for v7.0-rc6
> 
> Starfive:
> Two fixes for the SD cards on the Mars CM Lite.
> 
> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
> 
> ----------------------------------------------------------------
> Heinrich Schuchardt (1):
>       riscv: dts: starfive: Milk-V Mars CM Lite broken-cd
> 
> Ilya Sorochan (1):
>       riscv: dts: starfive: jh7110-common: fix jh7110 SoC boot from SD-card.
> 
>  arch/riscv/boot/dts/starfive/jh7110-common.dtsi           | 1 +
>  arch/riscv/boot/dts/starfive/jh7110-milkv-marscm-lite.dts | 2 +-
>  2 files changed, 2 insertions(+), 1 deletion(-)
> 
> 
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv

To be clear the "riscv: dts: starfive: jh7110-common: fix jh7110 SoC
boot from SD-card." commit does not affect Linux whatsoever, there is no
problem to boot Linux from SD Card impacted by having or not having this
commit. This also is not common, so should not be in jh7110-common, as
more JH-7110 SoC products by-the-numbers have transistor logic replacing
this signal selection to the StarFive loader in BootROM and so
precluding this from functioning.

This ignores the wider discussion about StarFive both deprecating this
capability (for Secondary Program Loader i.e. U-Boot SPL) of StarFive
Loader in JH-7110 BootROM loading from SD Card being deprecated
officially in the latest StarFive JH-7110 Technical Reference Manual and
StarFive JH-7110 Boot User Guide documentation, and the ongoing GPL
non-compliance by StarFive for use of GPL 2.0+ code in the JH-7110
BootROM; the latter being important if we want to accurately attempt to
support this deprecated feature set as a community (even when ignoring
for the moment this copyright license non-compliance).

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

-E

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

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 5015 bytes --]

On Thu, Mar 26, 2026 at 07:36:07AM -0700, E Shattow wrote:
> On 3/26/26 04:13, Conor Dooley wrote:
> > Hey folks,
> > 
> > Please pull a small fixes PR.
> > 
> > Cheers,
> > Conor.
> > 
> > The following changes since commit 0528a348b04b327a4611e29589beb4c9ae81304a:
> > 
> >   cache: ax45mp: Fix device node reference leak in ax45mp_cache_init() (2026-02-06 19:54:40 +0000)
> > 
> > are available in the Git repository at:
> > 
> >   https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux.git/ tags/riscv-dt-fixes-for-v7.0-rc6
> > 
> > for you to fetch changes up to 305f2865bd034146b2eebc77c27fc50d8d79778d:
> > 
> >   riscv: dts: starfive: jh7110-common: fix jh7110 SoC boot from SD-card. (2026-03-19 16:00:13 +0000)
> > 
> > ----------------------------------------------------------------
> > RISC-V devicetrees fixes for v7.0-rc6
> > 
> > Starfive:
> > Two fixes for the SD cards on the Mars CM Lite.
> > 
> > Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
> > 
> > ----------------------------------------------------------------
> > Heinrich Schuchardt (1):
> >       riscv: dts: starfive: Milk-V Mars CM Lite broken-cd
> > 
> > Ilya Sorochan (1):
> >       riscv: dts: starfive: jh7110-common: fix jh7110 SoC boot from SD-card.
> > 
> >  arch/riscv/boot/dts/starfive/jh7110-common.dtsi           | 1 +
> >  arch/riscv/boot/dts/starfive/jh7110-milkv-marscm-lite.dts | 2 +-

> To be clear the "riscv: dts: starfive: jh7110-common: fix jh7110 SoC
> boot from SD-card." commit does not affect Linux whatsoever, there is no
> problem to boot Linux from SD Card impacted by having or not having this
> commit. This also is not common, so should not be in jh7110-common, as
> more JH-7110 SoC products by-the-numbers have transistor logic replacing
> this signal selection to the StarFive loader in BootROM and so
> precluding this from functioning.

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.

> This ignores the wider discussion about StarFive both deprecating this
> capability (for Secondary Program Loader i.e. U-Boot SPL) of StarFive
> Loader in JH-7110 BootROM loading from SD Card being deprecated
> officially in the latest StarFive JH-7110 Technical Reference Manual and
> StarFive JH-7110 Boot User Guide documentation, and the ongoing GPL
> non-compliance by StarFive for use of GPL 2.0+ code in the JH-7110
> BootROM; the latter being important if we want to accurately attempt to
> support this deprecated feature set as a community (even when ignoring
> for the moment this copyright license non-compliance).

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!

> 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

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

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

[Heinrich Schuchardt]

On 3/26/26 16:14, Conor Dooley wrote:
> On Thu, Mar 26, 2026 at 07:36:07AM -0700, E Shattow wrote:
>> On 3/26/26 04:13, Conor Dooley wrote:
>>> Hey folks,
>>>
>>> Please pull a small fixes PR.
>>>
>>> Cheers,
>>> Conor.
>>>
>>> The following changes since commit 0528a348b04b327a4611e29589beb4c9ae81304a:
>>>
>>>    cache: ax45mp: Fix device node reference leak in ax45mp_cache_init() (2026-02-06 19:54:40 +0000)
>>>
>>> are available in the Git repository at:
>>>
>>>    https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux.git/ tags/riscv-dt-fixes-for-v7.0-rc6
>>>
>>> for you to fetch changes up to 305f2865bd034146b2eebc77c27fc50d8d79778d:
>>>
>>>    riscv: dts: starfive: jh7110-common: fix jh7110 SoC boot from SD-card. (2026-03-19 16:00:13 +0000)
>>>
>>> ----------------------------------------------------------------
>>> RISC-V devicetrees fixes for v7.0-rc6
>>>
>>> Starfive:
>>> Two fixes for the SD cards on the Mars CM Lite.
>>>
>>> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
>>>
>>> ----------------------------------------------------------------
>>> Heinrich Schuchardt (1):
>>>        riscv: dts: starfive: Milk-V Mars CM Lite broken-cd
>>>
>>> Ilya Sorochan (1):
>>>        riscv: dts: starfive: jh7110-common: fix jh7110 SoC boot from SD-card.
>>>
>>>   arch/riscv/boot/dts/starfive/jh7110-common.dtsi           | 1 +
>>>   arch/riscv/boot/dts/starfive/jh7110-milkv-marscm-lite.dts | 2 +-
> 
>> To be clear the "riscv: dts: starfive: jh7110-common: fix jh7110 SoC
>> boot from SD-card." commit does not affect Linux whatsoever, there is no
>> problem to boot Linux from SD Card impacted by having or not having this
>> commit. This also is not common, so should not be in jh7110-common, as
>> more JH-7110 SoC products by-the-numbers have transistor logic replacing
>> this signal selection to the StarFive loader in BootROM and so
>> precluding this from functioning.
> 
> 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.
> 
>> This ignores the wider discussion about StarFive both deprecating this
>> capability (for Secondary Program Loader i.e. U-Boot SPL) of StarFive
>> Loader in JH-7110 BootROM loading from SD Card being deprecated
>> officially in the latest StarFive JH-7110 Technical Reference Manual and
>> StarFive JH-7110 Boot User Guide documentation, and the ongoing GPL
>> non-compliance by StarFive for use of GPL 2.0+ code in the JH-7110
>> BootROM; the latter being important if we want to accurately attempt to
>> support this deprecated feature set as a community (even when ignoring
>> for the moment this copyright license non-compliance).
> 
> 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!
> 
>> 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.

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. 
My patch in the pull request does not stop your board from booting but 
re-enables mine.

Best regards

Heinrich

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

[Ilya Sorochan]

On Thu, Mar 26, 2026 at 07:36:07AM -0700, E Shattow wrote:
> To be clear the "riscv: dts: starfive: jh7110-common: fix jh7110 SoC
> boot from SD-card." commit does not affect Linux whatsoever, there is no
> problem to boot Linux from SD Card impacted by having or not having this
> commit. This also is not common, so should not be in jh7110-common, as
> more JH-7110 SoC products by-the-numbers have transistor logic replacing
> this signal selection to the StarFive loader in BootROM and so
> precluding this from functioning.

This commit affects U-Boot+Linux ability to boot from SD-card.
Tested on StarFive VisionFive 2 and Pine64 Star64.
I'm not aware if this is the same for other jh7110-based boards, but assumed so.
 
> This ignores the wider discussion about StarFive both deprecating this
> capability (for Secondary Program Loader i.e. U-Boot SPL) of StarFive
> Loader in JH-7110 BootROM loading from SD Card being deprecated
> officially in the latest StarFive JH-7110 Technical Reference Manual and
> StarFive JH-7110 Boot User Guide documentation, and the ongoing GPL
> non-compliance by StarFive for use of GPL 2.0+ code in the JH-7110
> BootROM; the latter being important if we want to accurately attempt to
> support this deprecated feature set as a community (even when ignoring
> for the moment this copyright license non-compliance).
>
> 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.

Appreciate the effort!
However I can't see how this is related.

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.

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

Re: [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

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.

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

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 3972 bytes --]

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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

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

[Krzysztof Kozlowski]

On 27/03/2026 10:45, Conor Dooley wrote:
> 
>> 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
> 
I saw the picture and it looked like it should never be a DTS, because
it is not usable on its own. You cannot run it.

Things which you cannot run, are not DTS. There is only one known to me
exception for SoM being a DTS - Renesas SMARC something - because Geert
explained to me that you can run that SoM without carrier board.

And because this was a DTS commit, then adding broken-cd because of
baseboard troubles is WRONG.

This is supposed to by DTSI included by carrier DTS or DTSO applied to
every carrier board.


Best regards,
Krzysztof

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

[Krzysztof Kozlowski]

On 27/03/2026 10:49, Krzysztof Kozlowski wrote:
> On 27/03/2026 10:45, Conor Dooley wrote:
>>
>>> 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
>>
> I saw the picture and it looked like it should never be a DTS, because
> it is not usable on its own. You cannot run it.


... although what I found earlier was different. I typed the model name
from DTS "Milk-V Mars CM Lite" and it gave me this:

https://milkv.io/mars-cm
which misses the "Lite" suffix.

What you pasted is called "Mini Base Board (A) Designed for Raspberry Pi
Compute Module 4" and it also does not have "Lite" in the name and
picture does not have the SoM.

I am confused now and I do not know what the DTS "Milk-V Mars CM Lite"
is. Answering to this is crucial, because it determines whether this
particular deviec has broken-cd or not.

Arguments that something else has broken-cd, thus you add such property
to "Milk-V Mars CM Lite" are obviously wrong.




Best regards,
Krzysztof

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

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 3076 bytes --]

On Fri, Mar 27, 2026 at 11:50:39AM +0100, Krzysztof Kozlowski wrote:
> On 27/03/2026 10:49, Krzysztof Kozlowski wrote:
> > On 27/03/2026 10:45, Conor Dooley wrote:
> >>
> >>> 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
> >>
> > I saw the picture and it looked like it should never be a DTS, because
> > it is not usable on its own. You cannot run it.
> 
> 
> ... although what I found earlier was different. I typed the model name
> from DTS "Milk-V Mars CM Lite" and it gave me this:
> 
> https://milkv.io/mars-cm
> which misses the "Lite" suffix.

Lite is the same thing without an emmc.

> 
> What you pasted is called "Mini Base Board (A) Designed for Raspberry Pi
> Compute Module 4" and it also does not have "Lite" in the name and
> picture does not have the SoM.
> 
> I am confused now and I do not know what the DTS "Milk-V Mars CM Lite"
> is. Answering to this is crucial, because it determines whether this
> particular deviec has broken-cd or not.

It's an Raspberry Pi compatible SoM, what you linked.
I was linking to the kind of base-board that Heinrich has, to show that
it pretty much is a connector to the SoM and the physical connectors for
ethernet etc and nothing else on the board.

The dts was done the way it was, IIRC, to permit using overlays on top
of the $som.dts file to describe the minor differences between the
pretty trivial I/O boards, such as the one I linked to or the standard
RPi one: https://www.raspberrypi.com/products/compute-module-4-io-board/

It's akin to having "jh7110-milkv-marscm-lite-generic-trivial-base-board.dts"
which I think isn't problematic. There's a jh7110-milkv-marscm.dtsi that
is what actually describes the bulk of the SoM.

> Arguments that something else has broken-cd, thus you add such property
> to "Milk-V Mars CM Lite" are obviously wrong.

The argument is that "broken-cd" is the standard for RPi compute module
baseboards, so the rare baseboard that doesn't do that is the one which
would have to use an overlay to function.
I think that that is the right approach to take, in a world where having
a dts for the SoM is permitted.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

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

[E Shattow]

On 3/27/26 05:16, Conor Dooley wrote:
> On Fri, Mar 27, 2026 at 11:50:39AM +0100, Krzysztof Kozlowski wrote:
>> On 27/03/2026 10:49, Krzysztof Kozlowski wrote:
>>> On 27/03/2026 10:45, Conor Dooley wrote:
>>>>
>>>>> 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
>>>>
>>> I saw the picture and it looked like it should never be a DTS, because
>>> it is not usable on its own. You cannot run it.
>>
>>
>> ... although what I found earlier was different. I typed the model name
>> from DTS "Milk-V Mars CM Lite" and it gave me this:
>>
>> https://milkv.io/mars-cm
>> which misses the "Lite" suffix.
> 
> Lite is the same thing without an emmc.
> 

The eMMC part is populated on Mars CM system-on-module and is absent on
Mars CM Lite system-on-module. Either has the same pin connections on
the high-density base board connector available for an optional SD Card
holder (or eMMC module) of any attached base board design; use of SD
Card conflicts with eMMC use when both are present on this connection to
the primary mmc interface.

The secondary mmc interface is (according to the VisionFive 2 1.3b
reference design) expected for connection to SD Card use and here
instead is routed for optioned on-board SDIO WiFi module. Mars CM or
Mars CM Lite are a derivative hybrid design of both Radxa CM3 and
VisionFive 2 1.3b, as evident in the earlier schematic revisions
containing copy+paste of those reference schematic. Radxa CM3 as a
reference design is the origin of Card Detect being routed to that pin
and not any Raspberry Pi CM4 specification.

The "Lite" suffix in the Mars CM model name refers to System-on-Module
onboard presence or absence of the eMMC part at the primary mmc
interface and independent of any optioned on-board SDIO WiFi module at
the secondary mmc interface. There is an additional "WiFi" product
naming suffix for that System-on-Module and the known AP6256 wireless
SDIO module populated that features additional serial data connections
for integrated Bluetooth radio routed to UART lines which are also
exposed as pins on the base board connector.

>>
>> What you pasted is called "Mini Base Board (A) Designed for Raspberry Pi
>> Compute Module 4" and it also does not have "Lite" in the name and
>> picture does not have the SoM.
>>
>> I am confused now and I do not know what the DTS "Milk-V Mars CM Lite"
>> is. Answering to this is crucial, because it determines whether this
>> particular deviec has broken-cd or not.
> 
> It's an Raspberry Pi compatible SoM, what you linked.
> I was linking to the kind of base-board that Heinrich has, to show that
> it pretty much is a connector to the SoM and the physical connectors for
> ethernet etc and nothing else on the board.

The description I authored for initial Mars CM and Mars CM Lite support
in Linux does repeat the marketing claim of compatibility with the
Raspberry Pi Compute Module CM4 IO Board. I missed then this detail
about card detect for the named base board in the same context as
describing to add Mars CM Lite support of SD Card.

My advice, questions, and changes requested to Heinrich's proposed patch:

https://lore.kernel.org/lkml/3225628d-2546-44c1-bc9d-1607aa3d6c90@freeshell.de/

The functionality of the proposed patch:

https://lore.kernel.org/lkml/3166f7d5-b526-411d-b337-27981a7ed14d@canonical.com/

I disapprove the above because it lacks the associated comments that I
asked for as changes requested. There is information loss in this
situation. The hardware is perfectly capable of card detect but we just
delete this in the hardware description without even a comment I have
asked for, that is wrong.

My review feedback remains as I wrote it, we should implement overlay
support and I personally have no clue how to do this but doing so is the
technically correct way to resolve these base board support concerns.

> 
> The dts was done the way it was, IIRC, to permit using overlays on top
> of the $som.dts file to describe the minor differences between the
> pretty trivial I/O boards, such as the one I linked to or the standard
> RPi one: https://www.raspberrypi.com/products/compute-module-4-io-board/
> 
> It's akin to having "jh7110-milkv-marscm-lite-generic-trivial-base-board.dts"
> which I think isn't problematic. There's a jh7110-milkv-marscm.dtsi that
> is what actually describes the bulk of the SoM.
> 

This should have had review questions and changes requested addressed
before applying. I'm not surprised that Heinrich would avoid if at all
possible the work of implementing overlays. At least put the comments in
like I requested though, it is postured like there's some kind of
standards violation which is made up nonsense or at best a bad inference
of my error in the commit for initial support for missing the
discrepancy of marketing materials versus the schematic.

>> Arguments that something else has broken-cd, thus you add such property
>> to "Milk-V Mars CM Lite" are obviously wrong.
> 
> The argument is that "broken-cd" is the standard for RPi compute module
> baseboards, so the rare baseboard that doesn't do that is the one which
> would have to use an overlay to function.
> I think that that is the right approach to take, in a world where having
> a dts for the SoM is permitted.

Logically as Mars CM or Mars CM Lite System-on-Module are not adhering
to the Raspberry Pi CM4 System-on-Module specification, there should be
written an overlay that implement the Raspberry Pi CM4 standard (and so,
"broken-cd") applied for use with base boards.

Overlays are not going to implement themselves. I have no idea how to do
this either, though. There's some UART line assignments for serial
console peripheral of the Home Assistant Yellow base board that I would
like to write an overlay for if that was something I would understand
how to do... it seems to need actual programmer though for the initial
effort.

-E

P.S. Possibly off-topic I was hopeful that for the broader JH-7110
support we would get some bare-minimum JH-7110 generic board dts with
EEPROM and USB Fastboot and USB/UART serial console supported, nothing
else, for use as a fail-safe in U-Boot or as a basis for overlays and
modular support. Presently for U-Boot we just halt and so the advice in
board documentation is to use the vendor BSP in recovery situations. The
utility of overlays with JH-7110 related board support is not restricted
to this system-on-module scenario.

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

[E Shattow]

Hi Ilya,

On 3/27/26 01:52, Ilya Sorochan wrote:
>> On 3/26/26 12:27, Ilya Sorochan wrote:
>>> On Thu, Mar 26, 2026 at 07:36:07AM -0700, E Shattow wrote:
>> ...
> 
> 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.

$ scripts/get_maintainer.pl arch/riscv/boot/dts/starfive/jh7110-common.dtsi
...Conor... (maintainer:STARFIVE DEVICETREES)
...linux-riscv... (open list:STARFIVE DEVICETREES)
...devicetree... (open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE
BINDINGS)
...linux-kernel... (open list)
RISC-V ARCHITECTURE status: Supported

Not all maintainers are subscribed to all lists or even any lists. Some
just occasionally search lore mailing list archives

https://lore.kernel.org/linux-riscv
https://lore.kernel.org/linux-devicetree
https://lore.kernel.org/lkml/

if there's not CC directly to them.

Additionally to making sure your patch reaches its audience for review,
there are automated testing "Patchwork" which for LKML RISC-V

https://patchwork.kernel.org/project/linux-riscv/list/

breaks if you are not CC at least linux-riscv mail list. Threading
breaks in multi-patch series or series with cover letter if any of the
messages have different recipient ordering. Broken threading and missing
automated testing equals confused reviewers.

Note that special for StarFive SoC is Conor has responsibility for this
whereas the more recent usual delegation of responsibility to SoC or
vendor specific mail lists and git trees. SpacemiT development as a
recent example following the new pattern of delegation has its own
spacemit mailing list and git repo whereas starfive development sits on
linux-devicetree mailing list and co-habitation of Conor's devicetree
git repo because Conor is both a devicetree maintainer and adopted this
responsibility years ago when the StarFive SoC's were new.

Congratulations on your first patch to Linux Kernel :)

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

I hope you'll continue on to review the BootROM r.e. effort and cite its
code snippets in patches so adding bootph-pre-ram hints covering the
eMMC SPL boot method from StarFive Loader, retrospectively describing
the SD Card SPL boot method from StarFive Loader, and/or secure boot
crypto accelerator functionality in the starfive crypto driver (what
does command=8 and command=9 do exactly?) The exact nature of the bug in
StarFive Loader UART XMODEM incompatibility could use a proper
description, and SPI Flash configuration parameter analysis, too.

-E

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

[Ilya Sorochan]

On Sat Mar 28, 2026 at 1:07 PM MSK, E Shattow wrote:
>>> 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.
>
> I hope you'll continue on to review the BootROM r.e. effort and cite its
> code snippets in patches so adding bootph-pre-ram hints covering the
> eMMC SPL boot method from StarFive Loader, retrospectively describing
> the SD Card SPL boot method from StarFive Loader, and/or secure boot
> crypto accelerator functionality in the starfive crypto driver (what
> does command=8 and command=9 do exactly?) The exact nature of the bug in
> StarFive Loader UART XMODEM incompatibility could use a proper
> description, and SPI Flash configuration parameter analysis, too.

Unfortunately this is beyond my competence. This exact issue was fixed without
any r.e. only using git bisect. And while it might be interesting diving into
learning how things are I'm not sure I will.