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