[RFC PATCH v1 0/4] Add upstream board Xunlong Orange Pi RV

[E Shattow]

On 11/26/25 14:34, Heinrich Schuchardt wrote:
> Am 26. November 2025 23:15:25 MEZ schrieb E Shattow <e at freeshell.de>:
>> Xunlong Orange Pi RV patches are now queued up for the next merge window
>> to Linux v6.19, so let's introduce support for this board.
>>
>> Note: The content of EEPROM is not known to be unique on this board, and
>> in this RFC there is a placeholder value of "XOPIRV".
> 
> If OrangePi is not providing a unique value, shouldn't we create a separate defconfig (including the vf2 one) and override the output of the eeprom reading function by a configuration value?
> 
> That way we can reuse most code and avoid that users have to update the EEPROM to "XOPIRV".
> 
> Best regards
> 
> Heinrich
> 
>>
>> E Shattow (4):
>>  riscv: dts: starfive: Add Orange Pi RV from upstream Linux for-next
>>  board: starfive: visionfive2: Add Orange Pi RV selection by product_id
>>  riscv: dts: Add placeholder files for pending upstream Orange Pi RV
>>  configs: starfive: Add Orange Pi RV to visionfive2
>>
>> arch/riscv/dts/jh7110-orangepi-rv-u-boot.dtsi | 76 +++++++++++++++++++
>> board/starfive/visionfive2/spl.c              |  3 +
>> .../visionfive2/starfive_visionfive2.c        |  2 +
>> configs/starfive_visionfive2_defconfig        |  2 +-
>> .../src/riscv/starfive/jh7110-orangepi-rv.dts |  0
>> 5 files changed, 82 insertions(+), 1 deletion(-)
>> create mode 100644 arch/riscv/dts/jh7110-orangepi-rv-u-boot.dtsi
>> create mode 100644 dts/upstream/src/riscv/starfive/jh7110-orangepi-rv.dts
>>
>>
>> base-commit: c5e6d2ab7eba68cbfb600cdc131c0c375ced2ec9
> 

Sure I'd like more testing data about these boards, I don't have the
board myself so I don't know the answer to that.

What is the content of EEPROM, for reference?

If it's all the same as VisionFive 2 and boots with dts from VisionFive
2 (1.3b?) then it might not be needed to do more than add documentation
for the board to reference the VisionFive 2 and explain how to properly
set fdtfile. Inventing a new board identifier when the manufacturer has
not provided one sounds convenient to me, and it is not to the exclusion
of a separate board config just for that special situation. The
documentation can explain either or both situations, expanding how to
compile for the board.

How does network and eMMC function with the series applied, not changing
the EEPROM content (remains what I was understood is the same as
VisionFive 2), and manually setting the fdtfile variable?

-E