The StarFive VisionFive 2 is a Single-Board Computer (SBC) that has recently gained a lot of attention in the tech industry due to its powerful processing capabilities and support for cutting-edge technologies. One of the latest developments in this regard is the addition of EDK II support to the StarFive VisionFive 2 SBC.
UEFI is a modern firmware interface that provides a more sophisticated interface for system initialization, firmware updates, and system management. It is replacing the traditional BIOS (Basic Input/Output System) that has been used for decades. UEFI offers a range of benefits over BIOS, including faster boot times, larger storage device support, and more advanced security features.
The EDK II firmware for the StarFive VisionFive 2 SBC is available on the StarFive GitHub repository. The repository includes a wiki with detailed instructions on how to build the firmware for the Vision Five 2 SBC. It also includes pre-built binaries on the release page for those who want to get started with UEFI right away.
Currently, EDK II support on the StarFive VisionFive 2 SBC allows developers to boot from SD Card, eMMC, and QSPI flash. This flexibility gives developers the option to choose the most suitable storage device for their specific application.For a visual demonstration of booting Linux from UEFI Shell, please refer to the snapshot below:
Overall, EDK II support on the StarFive VisionFive 2 SBC is a significant development that further enhances the board’s capabilities and makes it an even more attractive option for developers. With its powerful JH7110 quad-core RISC-V processor, flexible I/O options, and now EDK II support, the VisionFive 2 SBC is a versatile and powerful solution for a wide range of applications.
I like this. I like having the same boot process everywhere, by which I mean how to set it up and control it, so, unified kernel images on ESP partitions
This does already kind of work with U-Boot, but its EFI runtime doens’t support storing EFI variables, so things like setting NextBoot don’t work on U-Boot to just temporarily boot a different kernel once. (And sure, could do that with kexec, but that’s not the point :-P). But U-boot does already support systemd-boot & UKIs, and it does pass the updated memory map through correctly, so no need for an 8G memory DTBO
I’m definitely going to give EDK2 a shot as soon as I have the time. This should allow me to have the exact same setup as on my workstation.
That’s great to hear! I’m glad you’re excited to give EDK2 a try.
If you have any questions or need assistance along the way, feel free to reach out to us. Good luck, and enjoy your journey with VisionFive 2 SBC and EDK2!
At the moment, it does not have support for framebuffer utilization or direct reading of NVMe/USB devices yet.
However, we have plans to incorporate these functionalities in future updates. We encourage you to contribute to our GitHub page if you are interested in helping us develop and enhance these features.
In the meantime, we are actively working on enabling the QSPI Flashing driver.
I trully do not understand. UEFI is not better than ubiit ans UEFI was designed with the IBM PC in mine and all of its quirks, yes EFI is better than the old BIOS we’ve been dragging for decades but no it is not better than uboot, in fact it’s probably worse on a lot of aspect because it was design to replace something not from the ground up.
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
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.
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.
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.
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
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!
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.
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
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.
