FDT incorrectly claims JH7110 hart 0 is a U74

[jrtc27]

https://github.com/starfive-tech/u-boot/blob/1539c1fb5a498fd7d20c2cffc84c187d703c8b66/arch/riscv/dts/jh7110.dtsi#L22-L47

This says it's a U74 with a modified ISA string, but that is not correct, it is an S7, which in particular means it does not have an MMU (it doesn't even have supervisor mode). Moreover, since U-Boot is providing the jh7110-u-boot.dtsi-based FDT via EFI, the status = "disabled"; gets overridden to status = "okay";. Combined, these two mean FreeBSD believes that it should be attempting to start the S7 hart 0 as an AP, which is clearly nonsense. Attempting to make an SBI HSM call to do so eventually leads to firmware dying with a fatal load access fault on hart 0, and I have to run fdt prop /cpus/cpu@0/status disabled at the FreeBSD loader prompt to correct this in order to boot.

Please fix all three of these issues; the FDT should have the correct properties for the S7 core (including no MMU), the FDT provided to the EFI application should not indicate that the S7 core has an okay status, and any attempt to make an SBI HSM call to start hart 0 should gracefully return an error code.

[martin-zs]

Are you certain that CPU0 is the E24 and not the S7 (which is part of the u74-mc but without the Sv39 Virtual Memory support) ?
ref: https://doc-en.rvspace.org/JH7110/Datasheet/JH7110_DS/c_u74_quad_core.html

[jrtc27]

Uh yes you’re right, S7 not E24, not sure where I got that one. Point is it’s not a U74.

EDIT: Ah right, the JH7110 has both a U74-MC and an E24, and when I skimmed the TRM I didn't appreciate they were separate (despite knowing the U74-MC is U74s with an S7), assuming it was just documenting the U74 and non-U74 cores of the U74-MC. SiFive did themselves no favours with that naming though...

[LekKit]

@X547, this might also be the reason why Haiku OS EFI crashes in my tests without any proper trace, so I will keep an eye on this. Might be useful to patch the FDT & rebuild U-Boot when I'll return to it.

[X547]

@LekKit, Which U-Boot image/branch are you using? Default Debian U-Boot EFI seems not working at all.

In:    serial
Out:   serial
Err:   serial
Model: StarFive VisionFive V2
Net:   eth0: ethernet@16030000, eth1: ethernet@16040000
bootmode sd device 1
Card did not respond to voltage select! : -110
Hit any key to stop autoboot:  2 ��� 1 ��� 0 
Failed to load 'vf2_uEnv.txt'
Importing environment from mmc1 ...
## Info: input data size = 482 = 0x1E2
## Error: "boot2" not defined
385 bytes read in 5 ms (75.2 KiB/s)
## Warning: defaulting to text format
48366 bytes read in 9 ms (5.1 MiB/s)
48366 bytes written in 11 ms (4.2 MiB/s)
Retrieving file: /extlinux/extlinux.conf
Failed to load '/extlinux/extlinux.conf'
Error reading config file
switch to partitions #0, OK
mmc1 is current device
Scanning mmc 1:3...
�7�[r�[999;999H�[6n�8Card did not respond to voltage select! : -110
** Unable to read file ubootefi.var **
Failed to load EFI variables
Found EFI removable media binary efi/boot/bootriscv64.efi
401629 bytes read in 24 ms (16 MiB/s)
No UEFI binary known at 0x44000000
EFI LOAD FAILED: continuing...
Scanning mmc 1:4...
starfive_pcie pcie@2C000000: Starfive PCIe bus probed.
PCI: Failed autoconfig bar 10
ethernet@16030000 Waiting for PHY auto negotiation to complete......... TIMEOUT !
phy_startup() failed: -110FAILED: -110ethernet@16040000 Waiting for PHY auto negotiation to complete......... TIMEOUT !
phy_startup() failed: -110FAILED: -110ethernet@16030000 Waiting for PHY auto negotiation to complete......... TIMEOUT !
phy_startup() failed: -110FAILED: -110ethernet@16040000 Waiting for PHY auto negotiation to complete......... TIMEOUT !
phy_startup() failed: -110FAILED: -110StarFive # 

UPDATE: was corrupted EFI executable.

[LekKit]

@LekKit, Which U-Boot image/branch are you using?

https://github.com/starfive-tech/u-boot

If you mean the EFI payload, I tried to run GRUB (worked? but didn't try to progress further) and Haiku EFI bootloader which got stuck in random places and debugging was a nightmare
For running Linux I use the patched vf2 kernel booted directly via boot/extlinux.conf, userspace part doesn't matter much (you may use whatever distro rootfs) but prop drivers for the onboard PVR GPU are practically unusable on anything except the stock Debian image (and are not stable). I build radeon module and used M.2->PCIe riser with an external GPU for now, much like we would do on an Unmatched. I recommend doing the same unless the EFIFB that U-Boot brings is usable by Haiku.