StarFive VisionFive 2 SBC Now Supports TianoCore EDK II (UEFI) | Hacker News Reader

StarFive VisionFive 2 SBC Now Supports TianoCore EDK II (UEFI)

forum.rvspace.org

41 pointssnvzz32 comments

UEFI is a terribly designed system, with a lot of x86-specific quirks. It's really sad other architectures picking it up. While general idea of it is good, a lot of design details and implementation specifics are just meh. Take, for example, the need of using PE format. Everywhere outside x86 world it doesn't make any sense. Some vendors invented TE (Terse Executable) which is more appropriate for a firmware, without unnecessary legacy, but it didn't become a standard, and even have multiple incompatible versions without easy way to distinguish them.

Regarding standards, the Terse Executable (TE) is part of the UEFI Platform Initialization Specification https://uefi.org/specs/PI/1.8/V1_TE_Image.html now.

From "Beyond BIOS" https://www.degruyter.com/document/doi/10.1515/9781501505690...:

"The advantages of having TE as a subset of PE include the ability to use standard, available tools, such as linkers, which can be used during the development process. Only during the final phases of the FV image creation does the tool chain need to convert the PE image into a TE. This similarity extends to the headers and the relocation records. In order to have an in-situ agent, such as a debugger nub, distinguish between the PE and TE images, the signature field has been slightly modified. For the PE, the signature is “MZ” for Mark Zbikowski, the designer of the Microsoft DOS† image format, the origin of the PE/COFF image. For the TE image, the signature is “VZ”, as found at the end of Volume 1 of the UEFI PI specification:

    #define EFI_TE_IMAGE_HEADER_SIGNATURE 0x5A56      // "VZ"

This one character difference allows for sharing of debug scripts and code that only need to distinguish between the PE and TE via this one character of the signature field. Although the development and design team eschewed use of proper names in code or the resultant binaries, the “VZ” and “Vincent Zimmer” association appeared harmless, especially given the interoperability advantages."

Probably would be more accurate to say that TianoCore now supports the board. UEFI could be ported to more systems, but there's little incentive. Also, the main power of UEFI is the ability for an OS to get an early framebuffer and nice interface to USB/PCI/etc. without knowing the low-level details of the system you're booting, and that's a lot of work, especially in the embedded ecosystem where SoC vendors just rearrange memory layout and blocks between chip revisions (hey, we'll just update the Linux driver with the latest mappings, that's fine, right?)

>especially in the embedded ecosystem where SoC vendors just rearrange memory layout and blocks between chip revisions (hey, we'll just update the Linux driver with the latest mappings, that's fine, right?)

This would not be compliant with RISC-V specifications.

There's no boards in the market that I am aware of which run Linux and yet do not follow the boot specifications, which among other things require the use of device trees.

>there's little incentive

... to deviate from the specifications, and opt out of all the benefits of being a compliant implementation.

There's severe costs incurred by not leveraging the ecosystem.

> require the use of device trees

I think that's the case where it's easy for a vendor to do so; see, for example:

- https://elixir.bootlin.com/linux/latest/source/arch/arm64/bo...

> This would not be compliant with RISC-V specifications

What?

> the boot specifications

Where?

> There's severe costs incurred by not leveraging the ecosystem

How?

It's really depressing that no Risc-V hardware currently in production has completely open-source firmware.

In this respect Risc-V is much, much more closed than Arm64, where we have the totally-blobless RK3399.

Ultimately Risc-V is about vendor-freedom at all costs, even at the cost of owner-freedom.

I agree with your sentiment, but I am more optimistic about the future of RISC-V. It considerably lowered the barrier of entry for vendors, and so there are more of them! Higher competition usually means that users win: they get lower prices, open-source toolchains and firmware, etc.

For one, I am very excited about the tiny CH32V003 ([1], [2]), a RISC-V 48 MHz microcontroller that costs ~$0.10 and can be programmed with completely open-source tools, see [3] and [4].

I am reasonably sure the higher end of the spectrum of RISC-V chips will also get better in terms of user-friendliness.

1. https://www.youtube.com/watch?v=L9Wrv7nW-S8

2. http://www.wch-ic.com/products/CH32V003.html

3. https://github.com/cnlohr/ch32v003fun

4. https://github.com/aappleby/PicoRVD

Regarding the VisionFive 2 this is about, there's some non-open firmware, but it is the GPU's and it is not required to boot.

It is not even required for litting up the screen, as the HDMI controller is a separate hardware block, not is it required for video decoding acceleration, another separate hardware block.

Only reason rk3399 ended up blobless was because ChromiumOS team holds that standard. Any ARM SoC used in a Chromebook has to have open firmware.

Tap that market, and doors will open!

Un/fortunately nobody don't want a riscv laptop. The (currently available) cores just aren't good.

I believe the Qualcomm and Mediatek-based ARM Chromebooks have binary blobs.

For WiFi or in the boot sequence?

https://github.com/ARM-software/arm-trusted-firmware/tree/ma...

I guess Qualcomm has some pull.? Although they do have some code in Coreboot.

https://doc.coreboot.org/soc/qualcomm/sc7180/index.html

https://elixir.bootlin.com/coreboot/latest/source/src/soc/qu...

I was looking just at the boot code. Rockchip has all open source silicon and board code, including the RK3399 https://github.com/coreboot/coreboot/blob/master/src/soc/roc... for memory init. This is the logic typically held back by many other ARM vendors, like Mediatek and Qualcomm, as blobs. There's a pretty interesting diagram showing the blobs in Intel, AMD, Qualcomm, and Mediatek coreboot implementations in figure 5-4 of https://link.springer.com/chapter/10.1007/978-1-4842-7939-7_.... A more cartoonish variant of the figure (but one that's not behind a paywall) can be found in slide 2 of https://osfw.foundation/slides/SiliconInterfaceDesign/OSFF-W.... You're right. Coreboot has open source board code and some open source silicon code for all of the vendors w/ binary boot blobs. So it's not so completely closed. The blobs are usually SOC-specific, board-independent code flows that 'should' just drop in and work.

Note that ram init in VisionFive 2 is done within u-boot SPL, which is loaded into cache-as-ram from the selected (microswitches on the board) boot device.

The non-rewritable ROM inside the SoC does just take care of reading the microswitches and fetching u-boot SPL (or oreboot, an alternative early bootloader in the works).

Remarkably, the boot selection can be UART. This small ROM has an XMODEM implementation for receiving the early bootloader.

u-boot SPL does then check the microswitches again for where to fetch the next stage, which is usually opensbi with u-boot as bundled payload.

What if any other RISC-V systems are UEFI capable? Major boon to usability.

This is why RISC-V put a lot of effort on the boot process, and put it early.

Relevant specifications include but aren't limited to SBI[0], UEFI protocol[1] and the ongoing platform specification[2].

RISC-V is quite ready to take over the datacenter, workstation and laptop markets, while dodging the issues derived from bespoke everything which other architectures challenging x86 suffer from.

0. https://github.com/riscv-non-isa/riscv-sbi-doc/releases

1. https://github.com/riscv-non-isa/riscv-uefi/releases/

2. https://github.com/riscv/riscv-platform-specs

> RISC-V is quite ready to take over the datacenter

The only thing missing: fast power-efficient core designs. Eh, how hard could that be? Other than that one little thing, totally ready to take over the datacenter.

>Eh, how hard could that be?

Really hard.

>Other than that one little thing

Not a little thing at all, but it is being taken care of by competent architects, who have succeeded at making very competitive high performing micro-architectures in the past.

We know about Ventana Veyron, TBA before end of year, and Tenstorrent's Ascalon, TBA 2024, led by Wei-han Lien, previously lead architect of Apple M1.

Ascalon is 8-wide, but also has smaller siblings at lesser decoder width, to cover a range of uses. According to a recent presentation by Jim Keller, it is expected to be competitive with projected Zen5 (also TBA 2024) performance but using considerably less power.

There's also strong teams at Rivos, MIPS and SiFive working on very high performance cores, but we know less about these efforts.

Sorry, i forgot the "/s"

I know it is hard, which is why i am skeptical. XYZ is "working on" fast cores is years to decades away from "Server with XYZ cores now available to buy from vendor ABC"

Personally I think the fast power efficient core is on of the most solved issues.

PDKs and un-core stuff (PCIe & USB IP) is I think the main constraint keeping these chips from doing great already.

And yet ALL the existing buyable RISC-V chips out there now perform worse than even a half-decade-old ARM chip per MHz and per mW

They're very competitive when comparing in the same gate count/process niche. It just takes more time for more complex designs to be verified.

We're working on that across all horizontally integrated platforms (i.e. datacenter class systems). I'm working on making sure that the vertical integration platforms see the value (as opposed to a requirement on das uBoot).

https://archive.is/Sz6fU

That's going to be a hard NOPE for me dawg; UEFI is an atrocity, go look at the tianocore source if you want to think otherwise. Just because it replaces traditional boot loaders does not make it better or easier. Hopefully the chinese risc-v offerings are less subserviant to the wintel agenda than this.

Feel free to use u-boot as payload embedded or loaded after opensbi; Nobody forces you to use EDK2.

Tangential: Did anyone order from Ameridroid and actually get a VisionFive 2 promptly? I ordered back in February. I got the shipping insurance but that insurance still just says "order received; unable to process a claim yet." Are they just backlogged or have I been bamboozled?

Neither actually. I ordered a fully specced one in February as well. I been successful with purchasing from Ameridroid in the past; an Odroid N2 I had ordered came really quickly. It looks like the manufacturer wants customer data (https://snipboard.io/CE7SIM.jpg) and Ameridroid doesn't want to comply. I decided to keep my order in to support their efforts.

Very helpful information. Thank you.

Mine from waveshare was delivered within two weeks of ordering, in late January/early February.

Today there's several shops offering them, including many options in aliexpress.

Hello, This is Brandon!

We were having issues with the manufacturer but luckily we have been able to deal with those without compromising our customers data. We were supposed to receive all the boards that we needed to fulfill all pre-orders, but the manufacturer sent us just half of the items. We have already started shipping the ones that we received this week, we are hoping to continue to fulfill those during this week and receive the reminder of boards in the next few weeks.

If you want to check the status of your particular order please email us to orders@ameridroid.com and I will be happy to check that out for you.

Headline is only 20% words.

Reply on news.ycombinator.com