On 1/18/26 04:05, Heinrich Schuchardt wrote:
> While some boards have separate switch RGPIO0, RGPIO1 others only
> have a common switch.
>
> Describe the restriction.
>
> Signed-off-by: Heinrich Schuchardt <[email protected]>
> ---
> doc/board/starfive/jh7110_common.rst | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/doc/board/starfive/jh7110_common.rst
> b/doc/board/starfive/jh7110_common.rst
> index 77102fcc189..14ec556ab13 100644
> --- a/doc/board/starfive/jh7110_common.rst
> +++ b/doc/board/starfive/jh7110_common.rst
> @@ -237,6 +237,11 @@ RGPIO1 RGPIO0 StarFive loader function @ 0x2A00_0000
> 1 1 UART Serial XMODEM loader
> ====== ====== ======================================
>
> +While some boards have separate switches for RGPIO0 and RGPI01 (Milk-V Mars,
> +StarFive VisionFive 2, Pine64 Star64) other boards only offer a common
> +switch (Orange Pi RV, StarFive VisionFive 2 Lite) or control line
> +(Milk-V Mars CM). Here booting from SD-card or eMMC is not possible.
> +
> According to `JH-7110 Boot User Guide BootROM`_ the StarFive loader code
> reads
> content to SRAM @ 0x0800_0000 from different media selected by
> [RGPIO1,RGPIO0].
>
Repeating the names of specific boards to describe this concept
unambiguously is clearly good reason why this statement does not belong
in the common document.
Statements in the common snippet should describe the SoC, the logic of
BootROM (which we don't yet know 100%), and for want that we don't have
a U-Boot specific snippet then also any U-Boot common functionality.
Maybe the "Boot button" would be considered a common peripheral however
(for want of upstreaming) the Pine64 PineTab-V does not have consistency
with other boards in this regard, and Milk-V Mars CM is a
system-on-module so that's also going to be absent of a boot button, and
some boards never featured a boot button; it's just not common.
Aside, I'm about 70%+ through classifying a reverse engineering effort
of the BootROM, and it's full of StarFive's JH7100 GPL2.0+ code derived
from U-Boot code (circa v2015.10 or so). This is evidently in disregard
for the license requirements to publish or made available the
modifications. However there is a lesser chunk of code which is probably
original to StarFive, is that considered proprietary? I'm not clear on
what is permissible to post to the mailing list in this situation.
I'm sharing Ghidra project archives of the effort off-list for anyone
that wants to get involved, there's ~20 stdlib-like and cryptography
("secure boot" ? perhaps) function calls that remain to be identified.
It's on-topic for JH-7110 boot select signals but probably way off topic
for U-Boot mailing list to dive into reverse engineering discussion.
Anyways if I might direct this constructively into a suggestion for
improving per-board documents, for our reference, here are some draft
notes I have collected about Milk-V Mars, Milk-V Mars CM (and CM Lite),
and Pine64 Star64:
""
Milk-V Mars
===========
Revision V1.1
No schematic published
Revision V1.11
* MOSFET input
* BOOT_EN test point
* pull-down momentary switch SW2 (remove R320 to disconnect)
* pull-down bias R321 (n/c) || pull-up bias R322
* RGPIO0 pull-up bias input MOSFET inverted output
* RGPIO1 pull-up bias input MOSFET inverted output
Revision V1.2
No schematic published
Revision V1.21
* MOSFET input
* BOOT_EN test point
* pull-down momentary switch SW2 (remove R320 to disconnect)
* pull-down bias R321 (n/c) || pull-up bias R322
* RGPIO0 pull-up bias input S1 pins 1,3 to MOSFET inverted output
* RGPIO1 pull-up bias input S1 pins 2,4 to MOSFET inverted output
Photos of rev V1.1 and of rev V1.11 have boot button and there is not
any multi-selection DIP switch.
Photos of rev V1.2 and of rev V1.21 both have boot button and
multi-selection DIP switch.
Milk-V Mars CM (-Lite)
======================
Revision X1.0
https://pica.zhimg.com/v2-c573f43a562d3e375c6e5bfc448e2fd8_1440w.jpg front
https://pica.zhimg.com/v2-bb53dd24e15502b60b73ecd21a04f444_1440w.jpg back
https://www.techspot.com/images2/news/bigimage/2023/09/2023-09-06-image-7-j_1100.webp
front
Revision V1.0
https://milkv.io/components/buy-marscm-view.webp
Revision V1.01
schematic available
Revision V1.21
schematic available
Pine64 Star64
=============
Boot selection MSEL DIP switch is active-low.
V1.0 pull-up MSEL
V1.1 pull-up ?
""
Given a per-board logical switch "on" may be inverted by logic to the
high or low state on the RGPIO lines of JH-7110, then each per-board
document should contain a simple table of [RGPIO3:RGPIO0] values
referenced in jh7110_common.rst with the schematic and usage information.
Suggested for example of structure:
""
Hold boot button pressed on Mars during power-on and during U-Boot SPL
to ensure StarFive loader UART function and U-Boot SPL YMODEM loader
function. Mars rev V1.2 and V1.21 have an additional multi-selection DIP
switch not populated on rev V1.1 and V1.11, with some overlapping
functionality as the boot button.
rev V1.1, V1.11:
Button "GPIO1" "GPIO0" [RGPIO3:RGPIO0]
Release L L [0000]=0
Press H H [0011]=3
rev V1.2, V1.21:
Button "GPIO1" "GPIO0" [RGPIO3:RGPIO0]
Release L L [0000]=0
Release L H [0001]=1
Release H L [0010]=2
Release H H [0011]=3
Press L L [0011]=3
Press L H [0011]=3
Press H L [0011]=3
Press H H [0011]=3
Refer to vendor documentation for photos and usage with vendor board
support package:
https://milkv.io/docs/mars/getting-started/setup
""
I have not verified the accuracy of the above example idea for expanding
on Mars per-board document, it is suggested here for structure.
RGPIO2 is common between boards that we know of and likely does not
apply to users of upstream U-Boot so it can be assumed zero value for
the purpose of per-board documentation.
StarFive VisionFive 2 Lite vendor U-Boot has RGPIO3 (a user LED) as the
selection mechanism for fastboot feature; and perhaps upstream we might
do the same if it does not break other boards to do so. It may be useful
then to describe RGPIO2 and RGPIO3 connections (if any) per-board.
Changes to overall RGPIO3 behavior would belong in jh7110_common.rst
U-Boot description if it applies to all boards, and then per-board
describes any user-settable pin jumper configuration.
I have located and classified the mask ROM code in JH-7110 BootROM that
compares RGPIO state... and so there's a possibility of describing
secure boot closely related to OTP and RGPIO state. That would be
applicable to all boards and so is an example of what belongs in the
common snippet. While I'm not sure about the appropriateness of posting
reverse-engineered BootROM code to the mailing list inline here,
however, I can say that the mask 0xf is applied to retrieve from
register at 0x1702002c so that would be [RGPIO3:0] and then the return
value is masked off to 0x3 [RGPIO1:0] for comparison. There's also an
OTP register being compared... but I have not found yet what (or if)
there's RGPIO2 state effecting the boot vector selection. It's not clear
to me if the BootROM is involved in selection of the boot vector, or if
that is earlier so eventually when it is known this could be said or
ruled out about the BootROM and probably never will apply to U-Boot
users for boot vectors different than 2a000000.
Perhaps the common document would then get some U-Boot specific or
summary section with sixteen table rows numbered 0 through 15 for
[RGPIO3:RGPIO0] state, this seems unnecessary though it is only four
individual RGPIO tables that would need to be looked up by the user.
Having a short description of what a user needs to do "Hold boot
button..." ought to be sufficient, and more detail is there if a user
wants to look for it. Instead that might make sense to have as a
per-board summary.
What's the plan for reapplying the patch this depends on?
-E
