Hacker News Reader

Comment by teraflop | Hacker News Reader

Based on a brief bit of googling about this board's CPU (the Bouffalo Lab BL808), it seems to have one RV64 and two RV32 cores. The RV64 core may be capable of running RV32 machine code, if the OS sets various flags correctly, but the reverse isn't possible without emulation.

How does Linux handle this? Can you just run an executable and have it automatically scheduled onto whichever cores can execute it? Wouldn't the kernel itself have to be compiled for both architectures?

EDIT: Maybe I was overthinking this -- I found what looks like the devicetree file for the BL808, and it seems like only the single RV64 core is supported:

https://lore.kernel.org/lkml/20221127132448.4034-7-jszhang@k...

View on HN

Side note, but someone linked a great talk by OS researcher Timothy Roscoe the other day about a) the increasing heterogeneity of our computing devices, b) Linux's inability to really support same, and consequently c) Linux being used on the device, because the device has to "run Linux", but in increasingly smaller and more walled-off spaces, leaving board management which you'd normally think of as an "OS task" to device drivers or onboard firmware. The non-Linux-running processors on the board run an RTOS or whatever.

This would seem to be what's happened here with Linux running on, and really only in charge of, a small portion of the SOC. https://www.usenix.org/conference/osdi21/presentation/fri-ke...

To paraphrase what he says at the end of the talk, it would be a great idea to think about the kind of OS which could take these three cores properly into account.

Yet Windows ran 16-bit, 32-bit and 64-bit code on the same core for years. Huh.

Really folks. It doesn't take new research or exotic OS design ideas, to do something that has been common practice for a decade. Let's quit pretending linux is driving any innovation. It's followed behind in OS design, often by years.

Linux is, too. The thing being discussed here is supporting multiple pieces of _hardware_ in the same machine that have different instruction sets. I don't think Windows supports that either.

they do, using drivers, that is too novel idea for linux.

Linux has just as much native support for such things as Windows does, if not more.

I mean maybe you're right at this point but it's not like the reputation is undeserved

I mean, we're going on close to 30 years or so that Linux has had parity with Windows for the kind of driver we're talking about: loadable kernel driver for a weird accelerator core that takes firmware but doesn't really fit into a driver model otherwise.

On Linux this is a module that exposes a character device with one off ioctls.

On Windows this a kernel mode driver that exposes a Device object with one off DeviceIoControls.

I really don't think the reputation is deserved in this case, both kernels added equivalent support for this workflow back in the 90s.

> The RV64 core may be capable of running RV32 machine code

It's not, xlen is fixed on that core like most RISC-V cores.

> How does Linux handle this? Can you just run an executable and have it automatically scheduled onto whichever cores can execute it? Wouldn't the kernel itself have to be compiled for both architectures?

With asymmetric multiprocessing like you get with OpenAMP. The RV32 cores are more real time management cores. One core only has an MPU, no MMU. The other core doesn't even have that. So run something like freertos (or just a superloop) on those cores to babysit realtime tasks and either respond quicker and/or more deterministically than Linux can, or avoid waking up the Linux core.

One proposal I saw was to treat the RV32 core like a microcontroller or as a dedicated co-processor. https://www.robertlipe.com/bl808-not-symmetric/

Let me see if I have this straight ... it's a device that can run a general OS like Linux, but say, have a core that could be run real-time, with all the goodies like timers and stuff that we expect from microcontrollers?

If so, then that would be pretty awesome. I think that people have been trying to get real-time working on Raspberry Pis. It seems that they get kinda close, but never manage to get all the way.

This is actually a common pattern you get from multiple vendors.

The TI AM335x is a good example of that. An ARM core with 2 "PRU" microcontrollers, and they share access to the memory. The BeagleBone Black uses the AM335x, and there's various projects that make use of the PRUs. A list of some of them: https://beagleboard.org/static/prucookbook/

Also the TI AM6442. Its an awesome chip but the sdk and tooling for the evaluation board is a little rough around the edges.

Just as a semi-random example, NXP has the i.MX series[1] with one or more application-level cores alongside a microprocessor-level core. You can get something like the i.MX 8M Nano[2] with 4x Cortex-A53 and a single Cortex-M7.

Another "big-player" option is ST which has the STM32MP1[3], which features a single Cortex-A7 alongside a Cortex-M4.

[1]: https://www.nxp.com/products/processors-and-microcontrollers...

[2]: https://www.nxp.com/products/processors-and-microcontrollers...

[3]: https://www.st.com/en/microcontrollers-microprocessors/stm32...

NXP's software support for the heterogenous ARM cores is abysmal. I had to abandon an architecture on the iMX7 because their RPMSG drivers were simply broken. Documentation and examples were multiple-years old and their FAE support came down to "well, the examples work." Except they didn't.

Perhaps it's better with the newer BSPs on the 8, but I wouldn't be too quick to jump back into it.

I haven't worked with 'bigger' (application processors running Linux) yet, but with the small MCUs I always stick to an Open Source toolchain/RTOS. Sometimes you have to write a driver yourself, but if you can integrate it upstream it's not in vain.

But I imagine that the larger SoCs are a more complex beast where getting everything to play nice with upstream Linux would be a greater challenge.

Yikes that doesn't sound very promising. I've seen the i.MX 8 used in several different products, so clearly someone has made them work, or at least kinda work... but I can imagine that might be despite the "support".

The iMX line is totally solid for ARM/Linux application work. I've been shipping with them for over a decade. The automotive sector uses it heavily because of the onboard hardware codecs for video and camera.

It's just the coprocessor stuff they're weak on. It's easier to just link up to a Cortex-M3 offboard, but then again NXP has completely screwed up their supply chain and these parts are somewhat hard to get.

Most modern ARM SoCs capable of running Linux have one or more cortex M cores, down from M1s to M4s (I have yet to see M7s). It is precisely for what you describe.

M0. I’ve never seen an SoC with an M1, which is a core specifically designed to be implemented on an FPGA.

Cortex-R is also pretty common (R5 on Zynq-7000 and R7 on UltraScale MPSoC, for example)

Indeed, brainfart, thinking too much about the Apple M1. Thanks!

I think you need to think of the RV32 as what they were designed for as I/O processors, one in particular is for networking

Reply on news.ycombinator.com