Latest Availability

Are there any official/preliminary dates set for production run availability?

Are there developer boards still available anywhere or are they all gone?

Very curious how long I need to wait to get my hands on one :D.

I can’t answer your questions, but I can distract you with shiny alternatives. :slight_smile:

For MOST development, the emulations provided by QEMU and Renode.io are sufficient. They’re fast. You can single step through every opcode, including boot and in the exception handlers (where you couldn’t debug without JTAG) and they’re easy to automate. Entire editions, including graphics, of Fedora and Debian and FreeBSD have been running in emulation for a long time.

GitHub - riscv/meta-riscv: OpenEmbedded/Yocto layer for RISC-V Architecture contains information on automating CI with a QEMU instance that emulates this specific hardware.

I’ve been using Renode.io for my own development. Emulation is just easier than fighting tftpboot or sd cards and JTAG pods and such for those early days of “the OS quit and I don’t know where it went” and “I can see the timer ticking, but I’m not getting any interrupts. Why?” saga.

See also:

for my personal success story bringing up an operating system with Renode. There will be parts that I will have to build on “real” hardware, but automating CI to build, boot, start a few threads to compute some prime numbers, etc. will be hugely handy.

Not all hardware is virtualized in high fidelity. When it comes time to do GPIO, for example, I’ll probably ping-pong between real hardware and then implementing the GPIO hardware in Renode. If you’re building apps instead of OSes, that probably doesn’t matter.

I’m “just” a volunteer developer and don’t control board distribution nor do I know how many are left. I don’t get the impression it’s a lot. I do know that Beagle has coordinated a hell of a team to get all the pieces of the various OSes and tools running on these boards so that when final boards DO hit, they should be quite usable - and awesome.

It’s exciting times for RISC-V - and my four month old article is already needing a follow-up.

1 Like

Wow thanks for your amazing, thoughtful reply! I learned a lot from it.

Very excited to try out an emulation environment that closer resembles the hardware.

If you have some documentation of your experiences on the hardware I would love to read more.

If you’re looking for juice on the quoted parts, the answer to both of these specific issues was "because the OS I was working on wasn’t completely ported yet " - it’s not like there’s some scandal that timer interrupts quit working. :slight_smile: ISTR I screwed something up like only saving SOME of the registers on a context switch.

A lot of the JH7100 work (and thus, BeagleV) work for the various OSes is done in public. Patches for Linux kernel and other software are being upstreamed on a very regular basis. Since StartechFive seems to have only one chip with one customer right now (startups gotta start up) their repos are pretty easy to trawl through. Even the SOC’s docs and schematics are already public, and have been for a while.

Running it on the emulator is both exciting (“Hey, this is a totally new architecture!”) and boring (“Hey, everything works exactly like it’s worked for for years.”).

1 Like

I am very new to the embedded/sbc/SoC world so more so looking for any quirks and general experiences than a scandal. So far things mostly run fine in the generic RISCV64 environment for my toy OS, but I am curious what is waiting for me at the next step, going from emulation to hardware. I can live vicariously through others experiences with the dev boards for now and keep emulating in the meantime. :smiley:

The problem with QEMU is that you’re limited in what you can/can’t do. It only lets you do RISC-V dev. I can already sort of do that with VexRiscv or Pulpino. What many of us are looking for is the extras there in the form of the NN accelerators COUPLED with a more than useful Linux-capable RISC-V coreplex.

We get that there’s delays…we just like to know where things stand on the boards being available. Some of us want to extend the ecosystem with meta-riscv and extend thier own metadata layers (meta-edgeml) and what you’re offering doesn’t help much on that score… :wink:

1 Like

I am very curious to see how people are using the CV and AI peripherals as well! It’s what makes the BeagleV particularly interesting compared to the competition. Right now my head is so full of specifications but I would love to see some real demos or documentation of people’s experiences with these particular components.

I read that the demo boards (JH7100) have some particular performance issues that the production boards are going to address for these domains but I still think seeing people’s use cases and application of the necessary pipelines would be very interesting none the less. Once the JH7110 hits we can then get better ideas of expected performance of the production units.

Performance measurement and optimization is seemingly a non-goal for the iteration of current developer boards. These are for bringing up operating systems and tools and support hardware (in another window, I’m working on a satellite board to bring the JTAG and GPIO off the board and into LEDs and a form factor where you can attach a protocol analyzer AND a daughter board…) and such.

The production boards are to have four cores at 1.5Ghz. The current ones have two cores at 1.0Ghz. The lines between what U74 can be built to do by a chip maker and what’s in 7100 vs 7110 can be a bit fuzzy in the Beagle V doc but it’s clear that 7110 will be higher performance based on the reality of what’s been learned in that 7100. Digging through the branch of Linux kernel that’s optimized for Beagle V Starlight/JH7100 you can see the kind of things being worked through for performance, reliability, and the ongoing addition of new drivers.

I’m trying hard to not say anything that I’m not supposed to say, but I’m pretty happy with the device as a productdevelopment vehicle, but more I’m more happy that both StarFive and Beagle are working through these things with a large audience and are coordinating the experts on all the relevant software to get these things landed in the best way and with the hints of what’s #TODO for silicon and fiberglass that we’re not yet holding. There have been cases on the boards where feedback from a mass of real-world external hardware have resulted in suggestions from the developers that will land in the production PCBs. It seems to be more of a partnership than just tossing a product over the wall with a frozen GCC + Linux snapshot and considering it done.

@VirtualMachine , If your toy OS has already survived a few different environments (for example, you’re using System/Machine mode and device tree and have the ability to move where the 16550 address and IRQs are) it’s probably not THAT different. I started with a C906 port and had the core of the NuttX OS up in a couple of evenings with more complete functionality in a few more. I could have probably implemented Device Tree more easily than the hours I spent mucking through the various #defines and dumb constants. (I still may…) I haven’t gotten to SPI/I2C/GPIO yet, but that’s the kind of thing your OS should probably abstract anyway. Of course, network drivers are going to require support at the bottom. So if your OS is already the code of code that works on, say, a K210 AND a SiFive Unleashed, I’d expect your porting effort to be minimal.

Finally, it’s true that if your speciality is in a subsystem that’s not emulated (and I don’t think the NN units are emulated anywhere) then that’s just not an option for you unless you wanted to be the one that implemented the emulator, too.

My experience has been pretty positive. I’ve learned a lot along the way from experts in adjacent and overlapping pools of expertise.

1 Like

Everytime you post, I learn so much, cheers!

I am actually not using Device Trees, but porting addresses by hand like you mentioned. Is Device Trees something the bootloader passes to the kernel or they are predefined headers you can include during compile time?

1 Like

You’re welcome. I’ve spent years learning from others and researching everything I can, so I’m glad to pass along what I can. Some day, you’ll be answering questions on RISC-VI for the next generation. :slight_smile:

In hip RISC-V (less so for Microcontroller-class hardware like GD32V) your operating system runs in System Mode, with a more power level, Machine Mode, running below that. (Then there’s hypervisor mode for Virtual Machines, but given your name, I won’t say too much about that…)

Machine Mode is usually implemented by OpenSBI. Since that 2009 slide, of course, JH-7100 has been added/is being added to OpenSBI. It also provides a handful of traps you can use to set that time (without caring where it is in memory, worrying about wraps cases, etc.) or get/put a character to a serial console, etc. Very, very limited functionality, but it takes care of that very very bottom layer of getting an OS started. The traps are computationally expensive, so this is really only useful for boot monitors or debuggers or bringup. Calling sbi_put_char() is really not how you want to implement your real runtime. Services don’t even try to be as ambitious as stubbing USB or networking, for example.

The next step to zen is Device Tree. It’s not strictly a RISC-V thing and it’s pretty common on the higher end ARM devices. (Think “chrome books” or other Beagles less than “$.37 holiday light controller”). Linux Is using it. In short, your entry point is called (from OpenBIOS in our case) with one of the registers pointing to a tree. This tree contains glorified key-value pairs that tell you how many cores you have, their relative mojo (i.e. the big U74s or the low-power others), the location of all the UARTs in memory, their types so you know that (example) UART3 is an 16550 for compatibility but UARTS0-2 are high-speed DMA devices of a different type.

BeagleV’s can be seen at the bottom of:

Now for the downside. These tables are provided by the boot SPI flash and may be extended/modified by other layers before they get to you. An OS can even provide their own and choose to layer it at the top, but I’ll admit that seems baffling to me - the whole idea is for the OS to NOT know these things, right? There is a bit of turf battling on who is responsible for which devices. The systick timer is clearly part of the U74 bits, but the interrupt associated with it needs to come out and into the PLIC/CLIC. Now, is that an SoC thing? Not really, because boards can implement it in different places so it belongs in the board DTS. Ugh.

Your code is now relying - for better and worse - on data tables of devices that you don’t know much about. Maybe your customer has a damaged image. Now you can’t find TIMER0 or you crash when trying to find it. Good luck figuring that one out in a tech support call.

Also, with all this flexibility comes some costs. These aren’t microscopic in code and data size. For a board like D1-EVB or BeagleV, it’s no big deal, but you’re just not going to do this on a Longan Nano, so if you target a variety of hardware, be prepared to live in both DT and #define/LinkerVoodoo/const int worlds.

Implementing DT in the Nuttx port would have been my next task, but I saw there was a year old discussion on the topic that flatlined after resistance from the “different is bad” crowd. I’m still intrigued by it, though, as it’s an important part of RISC-V for “real” computers as we move out of dime microcontrollers.

1 Like