Hi Simon, On 2/3/26 16:23, Simon Glass wrote: > Hi E, > > On Tue, 27 Jan 2026 at 17:36, E Shattow <[email protected]> wrote: >> >> Hi Simon, >> >> On 1/26/26 18:55, Simon Glass wrote: >>> Hi Heinrich, >>> >>> On Mon, 31 Mar 2025 at 05:14, Heinrich Schuchardt >>> <[email protected]> wrote: >>>> >>>> On 30.03.25 17:15, Heinrich Schuchardt wrote: >>>>> On 23.03.25 16:58, Marek Vasut wrote: >>>>>> Use clock-names property which is accessible via parent clock OF node >>>>>> to look up the parent clock by name instead of depending on unreliable >>>>>> global clock name to perform look up. >>>>>> >>>>>> Signed-off-by: Marek Vasut <[email protected]> >>>>> >>>>> This patch breaks booting starfive_visionfive2_defconfig in the SPL stage. >>>>> >>>>> To dig a bit deeper I enabled the debug UART for SPL with these setting >>>>> on origin/master (5e74863ad6613df): >>>>> >>>>> CONFIG_DEBUG_UART=y >>>>> CONFIG_DEBUG_UART_NS16550=y >>>>> CONFIG_DEBUG_UART_BASE=0x10000000 >>>>> CONFIG_DEBUG_UART_CLOCK=24000000 >>>>> CONFIG_SPL_DEBUG_UART_BASE=0x10000000 >>>>> CONFIG_DEBUG_UART_SHIFT=2 >>>>> >>>>> clk_register: failed to get pll0_out device (parent of perh_root) >>>>> clk_register: failed to get pll0_out device (parent of qspi_ref_src) >>>>> clk_register: failed to get pll0_out device (parent of usb_125m) >>>>> clk_register: failed to get pll0_out device (parent of gmac_src) >>>>> clk_register: failed to get pll0_out device (parent of gmac1_gtxclk) >>>>> clk_register: failed to get pll0_out device (parent of gmac0_gtxclk) >>>>> >>>>> Marek assumes that property bootph-pre-ram might be missing for some >>>>> clocks in arch/riscv/dts/jh7110-u-boot.dtsi. >>>> >>>> This change suggested by Marek resolves the issue: >>>> >>>> diff --git a/arch/riscv/dts/jh7110-u-boot.dtsi >>>> b/arch/riscv/dts/jh7110-u-boot.dtsi >>>> index ce7d9e16961..4ed764393bb 100644 >>>> --- a/arch/riscv/dts/jh7110-u-boot.dtsi >>>> +++ b/arch/riscv/dts/jh7110-u-boot.dtsi >>>> @@ -113,3 +113,7 @@ >>>> &sys_syscon { >>>> bootph-pre-ram; >>>> }; >>>> + >>>> +&pllclk { >>>> + bootph-pre-ram; >>>> +}; >>> >>> I just hit this as well, thanks for the post. >>> >>> However, -master still does not boot for me on vf2: >>> >>> U-Boot SPL 2026.04-rc1 (Jan 26 2026 - 19:52:48 -0700) >>> DDR version: dc2e84f0. >>> Trying to boot from MMC2 >>> spl: partition error >>> Error: -38 >>> SPL: Unsupported Boot Device! >>> SPL: failed to boot from all boot devices >>> ### ERROR ### Please RESET the board ### >>> >>> Regards, >>> Simon >> >> Is this to be expected? ref: >> https://docs.u-boot.org/en/latest/board/starfive/visionfive2.html#zero-stage-bootloader >> >> The JH-7110 has enough SRAM to contain the unfiltered devicetree if you >> would like to experiment without filtering to reduce size for the SPL. >> >> Meanwhile though the uses of "sd card image" for U-Boot SPL to access >> MMC are not anymore supported; transition to instead use the remaining >> supported methods SPI Flash or UART Serial. > > I'm not sure that I can make that work in my lab. I have a SPI-flash > emulator for some boards, but it requires a special probe. > > What is wrong with putting U-Boot on the SD card?
TL;DR recap the feature is retracted from newer official documentation, new board designs do not have this capability, and apparent lack of interest yet to press StarFive for GPL2.0+ compliance. The latter is necessary else you're depending on "mystery" feature that was dropped and is unsupported by the vendor for your testing fixture. I have ~100+ hours into the JH-7110 BootROM reverse-engineering effort that I'd like to hand off for peer review. > > Regards, > Simon Simon: You personally are one of the copyright holders I have identified whose code is being ripped off by StarFive. Concurrently the reverse-engineering of JH-7110 BootROM effort has a sizeable chunk ready for peer-review but that is another topic; there may or may not be enough usable there but I think it'd be worth your time to review to decide what you would like to do. Contact me off-list for discussion about the r/e effort specifically. -E
