I for one think u-boot and uefi are equally awful, but uefi makes it all work the same, which is just more convenient. But sure, strictly sepaking, it’s not really necessary, especially with u-boot supporting some minimal EFI stuff as well. But diversity and having options to choose from is also great on its own 
5 Likes
I agree with that. It’s completely awful, complexity multiplying solution which shall stay in x86 world where it was intended to be (take good notes about why complex software is harmful: All software sucks).
Still, despite that, I’m glad the new software is coming to the platform. I just hope U-Boot development for VF2 will not stall after that.
2 Likes
EFI provides one of the building blocks that be used to have a generic linux image boot on all riscv boards not just built for a specific board.Potentially we can have a generic linux os that works on all riscv boards instead of building for a specific board.
EFI there can be drivers and binaries that extend efi so potentially other file systems like ext4. EFI has a network stack so potentially you can have things like netboot.xyz where you can have a boot menu that downloads and runs any supported os. There are also silly things like zork, python and lisp as efi binaries.
You may be able to do the same kind of things with uboot but I’m not an expert.
5 Likes
Hi strlcat,
The development of U-Boot and EDK2 will be independent of each other, ensuring that both projects can progress and evolve separately based on their respective goals and requirements.
It is simply another alternative way to boot, offering users more options.
I hope this clarification addresses your concerns.
Regards,
John
8 Likes
Please ignore the (very misinformed) complaints. UEFI/EDK2 is a great alternative to u-boot, especially when it comes to code quality and extensibility. ARM already adopted it as a standard for their chips, and I’m very glad that RISC-V is following in their footsteps. I’m looking forward to using this port of EDK2 to load the Limine bootloader (when its port to RISC-V is complete), which is great for us who dabble in hobby osdev.
I do have one question, is Ethernet support for netboot on the roadmap?
P.S. is it possible for the documentation for the display controller and hdmi PHY to be released publicly? I wouldn’t be opposed to implementing a minimum viable GOP driver depending on the complexity of the hardware
4 Likes
Technically you can boot an client from the network already using U-Boot. I do not know if you can do the same with EDK2 (yet).
1 Like
Hi ChickeNES,
Yes, Ethernet support for Netboot is on the roadmap. While specific timelines may vary, you can expect to see improvements and additions in this area in future releases in our EDK2 GitHub repository.
Thank you for showing interest in implementing the GOP driver. Unfortunately, the documentation for the display controller and HDMI PHY is not available for public release.
If you have any more questions, feel free to reach out to us. Have a great day!
Regards,
John
5 Likes
Played a bit around with it, but seems like it still needs some work.
It can run systemd-boot, but if I want to run a unified kernel image from it I get errors.
I’ve tried with starfive’s 5.15 kernel turned into a UKI via systemd’s ukify.py after decompressing it first, and with a custom built 6.4rc2 with with CONFIG_EFI_ZBOOT, CONFIG_EFI_GENERIC_STUB.
Both of these work fine via u-boot’s bootefi (both directly as well as via systemd-boot)
With edk2 both of these produce this output instead:
FSOpen: Open '\EFI\Linux\debian-decomp-5.15.efi' Success
InvalidateDataCacheRange:RISC-V unsupported function.
WriteBackDataCacheRange:RISC-V unsupported function.
[Security] 3rd party image[0] can be loaded after EndOfDxe: VenHw(B549F005-4BD4-4020-A0CB-06F5478A68C3)/HD(4,GPT,7752FD58-066A-4DDD-97B9-1574C70EDF82,0x96000,0x800000)/\EFI\Linux\debian-decomp-5.15.efi.
InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B 7E9CA040
FS1:\> ateInstructionCacheRange:RISC-V unsupported function.
Loading driver at 0x0007A0D8000 EntryPoint=0x0007A0D9000
InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF 7E9CAE98
ProtectUefiImageCommon - 0x7E9CA040
- 0x000000007A0D8000 - 0x0000000001FEE000
Could not locate device tree fixup protocol, skipping.
[Security] 3rd party image[0] can be loaded after EndOfDxe: VenMedia(55C5D1F8-04CD-46B5-8A20-E56CBB3052D0).
InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B 7E9CA440
InvalidateInstructionCacheRange:RISC-V unsupported function.
Loading driver at 0x0007C93F000 EntryPoint=0x0007D572CF2
InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF 7E9CA318
ProtectUefiImageCommon - 0x7E9CA440
- 0x000000007C93F000 - 0x0000000001773000
InstallProtocolInterface: 09576E91-6D3F-11D2-8E39-00A0C969723B 7A0E3060
InstallProtocolInterface: 4006C0C1-FCB3-403E-996D-4A6C8724E06D 7E9CAD18
EFI stub: ERROR: /chosen/boot-hartid missing or invalid!
Error: Image at 0007C93F000 start failed: Unsupported
Error starting kernel image: Unsupported
CoreLoadedImageInfo: Not an ImageHandle 7E9CC298
Error: Image at 0007A0D8000 start failed: Unsupported
Failed to execute Debian GNU/Linux 12 (bookworm) (12 (bookworm)) (debian-decomp-5.15.efi) (\EFI\Linux\debian-decomp-5.15.efi): Unsupported
CoreLoadedImageInfo: Not an ImageHandle 7E9CC318
Error: Image at 0007E281000 start failed: Unsupported
FSOpen: Open '\' Success
With minicom, the FS1:\> prompt garbles one of those lines unfortunately.
Curiously if I don’t include the device tree in the UKI it does get a bit further, but still can’t run, though I only tried that with 6.4, I’m guessing it’ll get the 5.15-style device tree from EFI which won’t work with it…
But yeah anyway, this seems to still need some work and I’m not sure where to go with this now.
4 Likes
Just tried Release JH7110 VF2 JUNE 2023 · starfive-tech/edk2 · GitHub with NixOS.
It loads systemd-boot from nvme but then fails:
FSOpen: Open '\efi\nixos\jzcl1a7s6q4r63hrqiwhl3fl0piv5vsz-initrd-linux-6.4.0-rc6-vf2-initrd.efi' Success
FSOpen: Open '\efi\nixos\pgkd3qhgacpa9m5gv099bxn8y70dpgj1-linux-6.4.0-rc6-vf2-Image.efi' Success
[Security] 3rd party image[0] can be loaded after EndOfDxe: PcieRoot(0x0)/Pci(0x0,0x0)/Pci(0x0,0x0)/NVMe(0x1,58-F2-30-00-03-8E-E3-8C)/HD(1,GPT,16F049A8-EE25-5948-A02B-201D7CB5CF33,0x800,0x40000)/\efi\nixos\pgkd3qhgacpa9m5gv099bxn8y70dpgj1-linux-6.4.0-rc6-InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B 70
InvalidateInstructionCacheRange:RISC-V unsupported function.
Loading driver at 0x00079F1B000 EntryPoint=0x0007AB5F914
InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF 7EAC2A18
ProtectUefiImageCommon - 0x7EAC27C0
- 0x0000000079F1B000 - 0x0000000001ED5000
FSOpen: Open '\dtbs\starfive\jh7110-starfive-visionfive-2-v1.3b.dtb' Success
Could not locate device tree fixup protocol, skipping.
InstallProtocolInterface: 09576E91-6D3F-11D2-8E39-00A0C969723B 7E6BD8A8
InstallProtocolInterface: 4006C0C1-FCB3-403E-996D-4A6C8724E06D 7EAE1F98
EFI stub: Booting Linux Kernel...
ConvertPages: failed to find range 200000 - 20D4FFF
EFI stub: ERROR: Failed to get boot hartid!
Error: Image at 00079F1B000 start failed: Unsupported
Booting using u-boot in efi mode works fine.
3 Likes
I’ve tested the june release and booting ubuntu does not yet work.
ubuntu uses grub as a uefi binary and this binary now runs successfully.
Loading a custom kernel from nvme seems to work but it fails to boot.
Please try this patch
diff --git a/Platform/StarFive/JH7110SeriesPkg/JH7110Board/DeviceTree/starfive_visionfive2.dtsi b/Platform/StarFive/JH7110SeriesPkg/JH7110Board/DeviceTree/starfive_visionfive2.dtsi
index f4a1bc63…e4760439 100755
— a/Platform/StarFive/JH7110SeriesPkg/JH7110Board/DeviceTree/starfive_visionfive2.dtsi
+++ b/Platform/StarFive/JH7110SeriesPkg/JH7110Board/DeviceTree/starfive_visionfive2.dtsi
@@ -38,6 +38,7 @@
linux,initrd-end = <0x0 0x4c000000>;
stdout-path = “serial0:115200”;
#bootargs = “debug console=ttyS0 rootwait”;
-
boot-hartid = <1>; }; cpus {
diff --git a/Platform/StarFive/JH7110SeriesPkg/JH7110Board/DeviceTree/starfive_visionfive2.dtsi b/Platform/StarFive/JH7110SeriesPkg/JH7110Board/DeviceTree/starfive_visionfive2.dtsi
index f4a1bc63…e4760439 100755
— a/Platform/StarFive/JH7110SeriesPkg/JH7110Board/DeviceTree/starfive_visionfive2.dtsi
+++ b/Platform/StarFive/JH7110SeriesPkg/JH7110Board/DeviceTree/starfive_visionfive2.dtsi
@@ -38,6 +38,7 @@
linux,initrd-end = <0x0 0x4c000000>;
stdout-path = “serial0:115200”;
#bootargs = “debug console=ttyS0 rootwait”;
-
boot-hartid = <1>; }; cpus {
Does Grub2 support in EDK2 is added ?
I am trying to get EDK2 to boot from an SD card, /dev/sda . I set up the card as described from the wiki with partitions as follows:
/dev/sd1|4096|8191|4096|2M|HiFive BBL|
/dev/sd2|8192|40959|32769|16M|HiFive FSBL|
/dev/sd3|40960|245760|204800|100M|EFI System|
I copied the files to the partitions as follows
sudo dd if=u-boot-spl.bin.normal.out of=/dev/sd1 bs=4096 oflag=direct
sudo dd if=JH7110.fd of=/dev/sd2 bs=4096 oflag=direct
sudo dd if=linux.iso of=/dev/sd3 bs=4096 oflag=direct
However when I try to boot the sdcard, I get no response. the boot mode is set according to the wiki. Any suggestion?
When you say no response, do you mean the green LED next to the red power LED does not begin to flash?
Have you tried hooking up a USB-TTL-serial cable to the GPIO pins? That’s how you get messages from the early stages of the boot process before Linux is given control.
With the VF2 board facing you so “StarFive” is readable, Dip switch 1, top, is to the right and 2 is to the left for SDcard? That works on my version 1.2A VF2 board.
The green led doesn’t flash and I get nothing on the minicom terminal connected to the VF2 GPIO pins. I even switched the TX and RX pins and still got nothing. the boot mode switches are the same as when I boot 2102306 from a sdcard.
Do you see messages on the minicom terminal when you successfully boot 2102306?
If no - I’d want to check things related to that like the settings on the minicom, whether you have a ground connection, etc. And get that working prior to trying the EDK2 boot.
If yes - I’m stumped as to what to look at next.
No I don’t get messages on minicom when I successfully boot 202306. the red and green led’s on the USB-TTY board blink. my minicom settings are /dev/ttyUSB0, 115200 8N1, no lockfile location,
Modem and dialing parameters A-H are blank. I verified the /dev/ttyUSB0 with dmesg | grep tty
I have photos of the USB-TTY board and the VF2 pin connections (6,8,10).
Well @kengreen I think it would be worthwhile pursuing those messages for a good boot, because you should get them and once you do I think they could yield a clue on the failed boot.
Your settings seem right to me. I have some suggestions but they’re rather in the realm of “grasping at straws”:
-
Try a different terminal emulator-or even a whole different system if you have one, maybe putty (which is what’s used as an example in the “VisionFive 2 Single Board Computer Quick Start Guide Version 1.1 Date 2022-12-27 Doc ID VisionFive2-QSGEN-001” or TeraTerm on a Windows machine. Page 29 of the guide has some example output.
-
If you are hardware inclined and have a scope verify the signal coming out of the TX pin on the VF2 board.
OK - can we see them?
And may the force be with you.