5 ms·

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

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@kernel.org/ https://lore.kernel.org/lkml/20221127132448.4034-7-jszhang@k...

boojums 4y ago
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/ https://www.robertlipe.com/bl808-not-symmetric/
- blippage 4y ago
  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.
  - pantalaimon 4y ago
    This is actually a common pattern you get from multiple vendors.
    - tyingq 4y ago
      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/ https://beagleboard.org/static/prucookbook/
      - aswanson 4y ago
        Also the TI AM6442. Its an awesome chip but the sdk and tooling for the evaluation board is a little rough around the edges.
    - magicalhippo 4y ago
      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/arm-processors/i-mx-applications-processors:IMX_HOME https://www.nxp.com/products/processors-and-microcontrollers... [2]: https://www.nxp.com/products/processors-and-microcontrollers/arm-processors/i-mx-applications-processors/i-mx-8-applications-processors/i-mx-8m-nano-family-arm-cortex-a53-cortex-m7:i.MX8MNANO https://www.nxp.com/products/processors-and-microcontrollers... [3]: https://www.st.com/en/microcontrollers-microprocessors/stm32mp1-series.html https://www.st.com/en/microcontrollers-microprocessors/stm32...
      - joezydeco 4y ago
        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.
        pantalaimon 4y ago
        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.
        magicalhippo 4y ago
        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".
  - tuetuopay 4y ago
    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.
    - repiret 4y ago
      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)
      - tuetuopay 4y ago
        Indeed, brainfart, thinking too much about the Apple M1. Thanks!
Taniwha 4y ago
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
monocasa 4y ago
> 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.
wzdd 4y ago
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-keynote 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.
- JoeAltmaier 4y ago
  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.
  - tomsmeding 4y ago
    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.
    - alexklarjr 4y ago
      they do, using drivers, that is too novel idea for linux.
      - monocasa 4y ago
        Linux has just as much native support for such things as Windows does, if not more.

boojums 4y ago

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/ https://www.robertlipe.com/bl808-not-symmetric/

blippage 4y ago
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.
- pantalaimon 4y ago
  This is actually a common pattern you get from multiple vendors.
  - tyingq 4y ago
    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/ https://beagleboard.org/static/prucookbook/
    - aswanson 4y ago
      Also the TI AM6442. Its an awesome chip but the sdk and tooling for the evaluation board is a little rough around the edges.
  - magicalhippo 4y ago
    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/arm-processors/i-mx-applications-processors:IMX_HOME https://www.nxp.com/products/processors-and-microcontrollers... [2]: https://www.nxp.com/products/processors-and-microcontrollers/arm-processors/i-mx-applications-processors/i-mx-8-applications-processors/i-mx-8m-nano-family-arm-cortex-a53-cortex-m7:i.MX8MNANO https://www.nxp.com/products/processors-and-microcontrollers... [3]: https://www.st.com/en/microcontrollers-microprocessors/stm32mp1-series.html https://www.st.com/en/microcontrollers-microprocessors/stm32...
    - joezydeco 4y ago
      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.
      - pantalaimon 4y ago
        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.
      - magicalhippo 4y ago
        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".
- tuetuopay 4y ago
  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.
  - repiret 4y ago
    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)
    - tuetuopay 4y ago
      Indeed, brainfart, thinking too much about the Apple M1. Thanks!

Taniwha 4y ago

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

monocasa 4y ago

> 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.

wzdd 4y ago

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-keynote 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.

JoeAltmaier 4y ago
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.
- tomsmeding 4y ago
  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.
  - alexklarjr 4y ago
    they do, using drivers, that is too novel idea for linux.
    - monocasa 4y ago
      Linux has just as much native support for such things as Windows does, if not more.