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:
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.
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/
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.
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.
> 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.
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.
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.
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.
There's another post on HN several days back with similarly price Sipeed M1s that's based on the same Bouffalo Lab BL808 RISC-V SoC module including NPU providing support for WiFi/BL, 802.15.4 Zigbee connectivity and interfaces such as UART, I2C, SPI, etc:
The ultimate "wireless sensor" experience would probably be something like an ESP32 size, power, and price that provides a nice Node-RED interface on the sensor.
I have a pie zero w doing things with its GPIO. It’s super nice to ssh right to the board to update src code without having to go through the flash dance. I know Linux is not “hard real-time” but it’s close enough. All the real-time reqs I have get offloaded to a dedicated pwm breakout and communicated with over i2c anyway.
I think his point was something to sense zigbee? Would be nice to set it in your house and bridge your power meter, water meter, whatever, onto your wifi. Could have it incorporated into your budget app live. "huh, no dinner out this week, better turn down the heat!".
And if anyone figures outbhow to use that NPU you could even do some inference to get some trends or something. Or even a classifier that could detect a short or water leak perhaps.
I dunno radios (skipped that class way back in college). I'm guessing that although 802.11 and Zigbee use 2.4 Ghz, you might need 2x radios physically tuned for the correct frequencies, and listening at the same time.
Looks like channel 1 802.11 is different than channel 15 Zigbee for instance, so bridging the two might need two different radios.
So you'd need a 802.11 radio + Zigbee Radio working as a team (even if ESP32 has enough CPU power to handle both, there are likely physical limitations to radio designs).
And I'm pretty sure that the radios use more power than the microcontroller in any case.
------
In any case, there seem to be many 802.11 to Zigbee bridges already available. So you should only attempt the project as a learning experience.
I have a few ESP boards. I still try to go for everything-Zigbee in my smart home setup. It's much less chatty, uses much less power and works with a standard protocol (no need for flashing TasmOTA etc). So much easier to integrate than anything WiFi.
AFAICT your home-grade wireless router / AP will start having trouble when you have dozens of Wi-Fi devices actively working in your home. ZigBee is somehow more resilient. It's also much lower energy, more comparable to Bluetooth, but much longer range: the sweet spot for smaller battery-powered devices.
OTOH I remember that ZigBee is somehow more buttoned-up than BT and even wi-fi, so it's not commonly seen on likes of ESP32 and other small MCUs.
I think zigbee is more "resilient" because it piggybacks off all the other zigbee devices via mesh instead of each device talking to the central router.
Zigbee is also far lower data rate than even first-gen WiFi, which makes it more resilient. Radio protocols are usually a compromise between 1) range 2) power efficiency 3) throughput 4) robustness. Zigbee prioritizes 2, achieves 1 through meshing, 4 through error correction and other stuff, and mostly writes off 3. Point being it's not just meshing doing the work here, it is overall designed differently from Wifi and tuned for the purpose in multiple ways.
Note that 802.11 (original) is specified with 50% error correction at MCS 1 aka 1 Mbit/second rate. That is, for 1000 bits transmitted, 500 were data, and 500 were error correction. (Plus all the error detection codes like CRC32 on top of that).
This is a good example of tradeoffs: slower and less throughput, but way more robustness.
Higher MCS levels of 802.11 cut down on error correction to 25% or 10%, achieving more throughput but less robustness.
I dunno how Zigbee does it, but I assume it has more error correction at slower (ie: more reliable) speeds than even WiFi MCS 1.
You don't need to connect dozens of devices. Esp32 can communicate as a server or a client so you can directly connect them without getting the router involved.
There's a protocol called ESP MESH, with which multiple ESP32 (and ESP8266) can talk to each other.
> ESP-WIFI-MESH is a wireless communication network with nodes organized in a mesh topology using the simultaneous AP-STA feature on Espressif SoCs. It provides a self-forming and self-healing network, with ease of deployment. The network topology of ESP-WIFI-MESH can scale up to 1000 nodes in large areas.
I didn't know that home WiFi routers have difficulty with more than a dozen connections, but I imagine ESP MESH could be a way around it, where a few devices connect to your router and act as access points for the rest of them.
In addition to ESP-Mesh protocol as mentioned in the sibling's comment, alternatively ESP-Now protocol also enabled lightweight support for direct networking without AP:
There are some mesh protocols (ESP-Link i believe) but tasmota doesnt support them. It doesn't even support SoftAP for anything but initial configuration. However there are some wifi repeater projects for the ESP series that might be of use.
No. It has MIPI DSI, but I'd be surprised if you could clock it very fast across these board layouts.
The very similar Allwinner D1 can push HDMI though. It's got the same main core (T-Head c906) and is about the same price point. That SoC doesn't have the nice wireless interfaces builtin though.
Not directly but it seems to be able to generate video out over the MIPI, at least. Not so convenient though, converter chips are probably small and not super hobbyist-friendly (like the one from Analog a siblibg comment dug up).
It has an RGB interface (basically parallel bus for pixels + clock), for which multiple bridges exist to HDMI. However, those are like QFN-88 packages so for soldering here be dragons. On the plus side, it avoids the mess that MIPI-DSI is...
The difference is that with RTOSes you typically link the application together with the OS, whereas with Linux you can dynamically load applications at run-time.
This is a big deal to me. What's stopping normal microcontroller platforms like Zephyr from providing dynamic loading of programs?
It'd be great for iteration to have a solid OS that cares about networking and updates and a an application layer you can move fast and break things with without risking soft-bricking your device.
I'm currently finding this with interpreted platforms like Espruino and Micropython, but don't understand at all why they have to be the only ones making this possible.
Where would you even load to program to and where from?
Typical microcontroller platforms only have a few kB of ROM and RAM, you can't load your application to RAM to run it, it's directly run from Flash.
But the internal flash of a MCU can only be erased in pages that can range up to 4k or 8k depending on the platform. So that already limits how many free pages you might have that you could dedicate to an application.
What usually is done is to partition the flash into two areas, so you have two firmware slots. This allows you do do OTA updates: While you run from slot A you can write the new firmware to slot B, once you verified the firmware in slot B you set a flag that tell the bootloader to boot from slot B next time. (Oh and you need different firmware images for slot A and slot B as ROM addresses will be different and there is no address translations. Some bootloaders will avoid this always copying slot B to slot A if it's newer than slot A, but IMHO that's unnecessarily complex/inefficient. You might as well always generate both slot images and let the firmware decide which one to request).
Another question is, why would you even want to dynamically load applications?
Those systems are not interactive, if you have some sensor monitoring the water level of your pot plant or the vibrations on some industrial equipment, it will only ever run that single application. It might get updates if it's doing some networking, but that will just be an update of the whole firmware.
Very weird seeing the Zephyr booting message I've seen so many times followed by the micropython repl startup message I've seen so many times.
Hard to think of a good app for that topology. In the sense that I could stick circuitpython or micropython on a ESP32, or zephyr on a ESP32, so an app running both would get me ... ?
Conceptually, the *python people "could in theory" give up on porting to infinite number of new boards and focus really hard on working under Zephyr, and let Zephyr worry about porting to infinite number of new boards.
The idea of upgrading my MicroPython under Zephyr under MCUboot under Eclipse hawkBit over the wifi is pretty intriguing sounding challenge.
I have not dug into this technology stack other than recreationally. I'm a little unclear how interop works beyond the existing example of passing simple hardware pins thru. For example if MicroPython had a library that interop directly with the Zephyr RTOS features, that would be quite handy. Another thing I notice is the interop in the docs is simple pin pass thru, hard to even imagine how Zephyr's wide variety of networking stacks would pass thru for Python to use. It looks like there is nothing developed at this point where the uC could run a RTOS thread to "do stuff" while a MicroPython thread handled a wifi UI or UI in general or handled the non-RTOS tasks, although that would be cool.
This chip has 4 cores, and I believe they all share the same memory bus ie. Each core can access the 64GB ram directly. There is also 768K sram for low power use. Only the RV64 large core has an mmu, the two RV32 cores don't. I think the chip's main use could be robotics- the lowest power core for networking, npu for image processing, the mid core for simple tasks and the large core for Linux and complex tasks eg. Navigation.
With the shared memory bus, you can hand over tasks between the cores. You may not have the same software running on each core, but the data can be the same.
For your use then, you could just use the lowest power microcontroller with 64GB ram. You can't get that ability anywhere else.
Not yet- I have a maix M1s dock full package on order, so hope to try it shortly. Sipeed supply a connector to be able to flash their board easily, and they seem to have an IDE for various use cases.
I'm hoping the MCU in the chip is the same as the BL602 chip- the 602 has a fully opensource firmware for the radio and cpu, can run zig and lora:
https://lupyuen.github.io/
For me, I'm looking forward to using a riscV MCU with a decent amount of ram, as a fixed platform to build an OS on.
> For your use then, you could just use the lowest power microcontroller with 64GB ram. You can't get that ability anywhere else.
I don't think the LP core has access to PSRAM. So most of the networking would run on the mid core, and the LP core just makes decisions to wake up a bigger core based on the events it sees.
I'm counting the NPU :)
I couldn't find anything in the datasheet about the LP core PSRAM access - do you have a confirmation on that? It'd be a shame if it didn't, but kinda makes sense with the 768K sram.
I was hoping it had access to both.
It allows you to use Linux, which is a sellable bullet point. Might also be useful sometimes, and allow knowledge sharing, increase portability and so on.
Ok fair enough, Linux can't run normally without an MMU. It kind of defeats the purpose of using a UNIX, but yes, you get all the Linux drivers and the UNIX API for free.
You still have processes and mutual protection between them and the kernel with no-MMU, they just get less options about where they can mmap(2) and you have to vfork(2) instead of fork(2).
The MPU gives you an equivalent of page fault exceptions. You can't remap virtual addresses to physical, but you can change their permissions, trap into the kernel when those permissions are violated, and restart execution of processes after the trap (to deliver signals or what have you).
Does it support UEFI with an updateable open source firmware (e.g. u-boot)? With enough kernel mainlining happening this would allow to use any distro image instead of always having to fiddle with custom images.
Well, that was the UEFI part of the question: With UEFI you don't need special images built, you can use the generic arm64 image and it will boot as long as things are in the mainline Linux kernel.
The form factor is similar to the old Onion SBC, but more expensive and less capable.
The Onion was $5, and included a proper serial interface, an SD card slot and wifi. It might have also had Bluetooth, but I'm not sure as this was seven years ago.
It was a great little machine. Very promising to have an entire Linux machine the size and shape of a 6502.
Alas, the company that made it put out a firmware update that made them act unpredictably, then another that ended up bricking machines. And at a cost of $5, there was no margin for customer support. The last time I looked into it, several years ago, the company appeared to be in pivot mode.
There was a vibrant emerging market of tiny SBCs in the years before COVID. Now everything is Raspberry Pi and Arduino. If you can get one.
I'm a bit over Raspberry Pis at this point. They're impossible to find, and their performance is terrible. I tried getting back into one of my Raspberry Pis from scratch just earlier today, and even with setting up the OS from scratch and the most up to date version, it was unbearably slow. So slow as to be unusable for even the most simple tasks. So that kickstarts forum hopping trying to figure why, and there's laundry lists. It's just a massive time sync. I've decided to upgrade to a Dell or Lenovo mini PC for some desktop Linux needs, where I need a GUI, and go with other embedded solutions over Raspberry Pis or relegate them to headless only uses.
By the time you get a Rpi 4, a decent power supply and an external SSD, it's usually around the same price as a mini PC which you can get with a 7th/8th/9th Gen i3 or even i5 with everything included.
I get that the Rpi will use less power, but I imagine many people will be like me and have it overclocked to 2.1ghz, and my heatsink was pretty warm all day long.
I've recently picked up a Optiplex 3070 with a i5 9500t for $120 and bought 32gb of ram off ebay for another $40. Considering a Rpi 4 is going for $100 on eBay, it's not a bad deal at all.
RPis are used as embedded controllers and such instead of a custom solution, which is why they are so hard to get right now -- many companies based their products on them when they were plentiful and now get priority over end-users for distribution. It is (or was) kind of a scandal as RPi's self-mandate was to provide cheap computing devices for learning, not for businesses to make products.
I've heard a rumor too that the rpi foundation is having a legal spat about that part with Broadcom right now too. Broadcom is pissed that their chips they were using as a tax right off are being sold for profit. That's why you can get RP2040 boards like the Pico no problem; they don't contain Broadcom IP blocks.
The difference in availability is certainly related to Brcm's involvement but that could just as easily be Brcm's capacity problem, rather than a spat for which there's no official word on (and it makes no difference to consumers anyway).
This is almost exactly where I'm at. Amazon has quite a few ridiculously cheap refurbished units of Dell OptiPlex Micro, Lenovo M series, and Intel Nuc products. The Raspberry Pis I have (3 and 4) are impossible to use as a desktop, and they are actually ill-suited for embedded cases due to their power draw.
I bought a $9 C.H.I.P computer many years back which had pretty decent specs. They might have been too cheap though, because they sadly went out of business.
And didn't require a PhD in UART to get an OS running on it. Seriously, who the hell thought the process described in that blog makes any kind of practical sense at all.
I mean the thing has two USB ports, TWO! And you can't use either, hahaha!
it is quite interesting that it actually has an sdcard slot but doesn't use it as a boot device? Like wtf? With only 128 MB of flash what kind of OS can one even fit on that...
Stay tuned, according to the Bouffalo Lab BL808 SoC datasheet (page 90) series numbering system that the board is based on, they will probably have more RAM and ROM capacity in the later versions of the SoC:
The cheap ARM boards you see typically have some economic reason that involve a deal for millions of SoCs falling through at the last minute and the SoC manufacturer selling them off at below cost just to get anything back from the run.
The BCM2835 was destined for a cheap set top box but for reasons not known publicly the manufacturer of that box didn't take those chips.
No it's not, you can run lots of useful applications in 64 MiB. Things we are running:
- processing data from a marine radar (it streams individual A-scopes as UDP stream), aggregating the sweeps into a .png image, denoising and uploading and handling some related logic (antenna tilt, gain settings)
- weather station pulling in data via serial/GPIO/... and publishing them as a webserver (lighttpd) and uploading them via OpenVPN to a cloud storage; firmware in the sensors can be easily updated and debugged remotely because the system runs avrdude and openocd
- emergency serial console - connected via USB to serial adapter to server, and you can SSH into it (again through OpenVPN/Wireguard), open a serial terminal or power-cycle the machine
- LoRaWAN gateway
And the best thing is that all this was written in Python! (with occasional C functions where native performance is required) So you have all the comfort of a high-level language and a full comfort of a standard Linux stack (though a bit limited because it is Busybox).
Better embedded GPIO. RPi Zero is a great little board/computer but the capabilities of the GPIO pins are lacking in a lot of ways. Speed being the biggest problem.
This little $8 board will run circles around even an RPi 4 when it comes to doing something like controlling a long strip of ws2812b RGB LEDs, as an example.
Linux and it's lack of hard real time functionality. ws2812b's don't have a clock signal and instead rely on relatively tight timing of the data to seperate the bits. So you end up having to write a kernel driver to either disable interrupts as you bit bang GPIO, or take over a SPI device and set it up with nasty parameters to get a ws2812b waveform out of the MOSI data line. This chip can simply dedicate one of the MCU cores to the task of babysitting that interface.
Currently, RPis are quite difficult to obtain and have been since 2020. I was just looking at a project design that required 2 RPi Zero 2 Ws and I'm currently considering alternatives. Unfortunately, the software stack is Java, so I don't think this will work.
Does anyone know of cheap touch screens to hook up to this. I feel a lot of cheap computers are available by now but the expensive pieces are displays which would 100X the value of these boards.
Yes, for small systems, I think of the processor as free, with the cost and bulk being in the peripherals these days.
As processors become more powerful, voice I/O becomes the cheapest way to interact - microphones and speakers, or even just a Bluetooth link, are much less expensive and less bulky than a screen and keyboard.
You can find used monitors really cheap these days, at least in N. America. $40 gets you something decent, but not touch screen. I'm sure you could get a used mouse, keyboard and screen for $50.
The Ox64 takes 3.3V power. That's the same as ESP32, which is in a similar category of "system on a chip". From what I read, two AA batteries in a series can supply that (~1.5V each) but their total current is weak (50 mA) compared to what the ESP32 requires, 300~500 mA. This type of Alkaline batteries is also rather unsuitable due to the profile of how the voltage is reduced as it discharges. I imagine the same applies to Ox64, that AA batteries won't work at all or only for a short time.
Typically recommended are lithium iron phosphate (LiFePO4) or lithum polymer (LiPo) batteries, both of which have higher capacity, better discharge profile, and can be recharged (the latter while the device is in operation).
Unfortunately it has no sleep mode (the supported power-down modes erase the main RAM, leaving only 64KiB region, so it's unusable for suspending of the booted-up Linux), so it will last a few hours at most.
This is a common problem with almost all of such boards. And we see great power management is definitely possible: Android phones can suspend to milliwatts for a decade. But there is no support in this hardware, where you can run "normal" Linux, not Android :(
The interesting thing about this is that it's a RISC-V machine, at least for me. A few years ago RISC-V dev boards were much more expensive than their ARM counterparts, nowadays they still are but are getting closer in price parity.
The NanoPi Duo has 4 cores and 512MB of RAM which is super usable. Includes WiFi etc. I'm not sure why RISC-V is such a draw here, considering the boards limitations.
Show me one with an integrated serial adapter and I'll buy it. I know how to generally program things via UART, but really would prefer not having to bother with it. It's not a great development experience.
Pine64 keep making these silly little mistakes limiting their products' appeal.
I don't want to bother. Manually creating a serial connection means it's more effort to hook up and the whole thing is larger, more fragile and less portable than necessary.
Might just be me, but I value the ability to quickly get started without a lot of setup and debugging hardware before getting to the software aspect. I don't want to keep the thing fully set up on my desk, I'd like to put it in a bag and get it out whenever I feel like it.
The WiFi capability may make this easier after the initial setup, but it's still an unnecessary hurdle.
As a Pine64 fan... yeah. I think their thinking is that the hard core devs who are needed to get these things off the ground are comfortable with UART and have the tools to program them externally, but IMO that really misses the mark when you need community-critical mass to get anywhere close to the popularity of something like Arduino or Raspberry Pi. Both of those companies/products make programming stupid easy for professionals and hobbyists alike, so they get a lot of attention and sales. The RP2040 is also superbly documented, unlike basically anything Pine64 has put out.
We could have pretty decent $8 Linux machines, with USB, screen, touch, audio, MBs or even GBs RAM, if there would be some standard way to sideload fresh GNU/Linux onto billions of retired Android devices.
The Termux app provides a pretty good fraction of the useful Linux stuff. It's basically a userspace chroot environment. You can run a lot of Linux distributions this way, though some of the features don't work. Can even have a desktop environment and run things like desktop Chromium. Or things like FTP servers, etc etc.
Basically you get most of the useful functionality from installing Linux, without needing root.
I use Termux as my daily driver, but I never thought it can run desktop stuff.
Still HW (Samsung) is locked down a bit as it doesn't allow autostart after power failure or can't power up without battery.
I have manjaro installed on my note 9 under termux, with vnc viewer to loopback to display x-windows stuff.
With the Dex functionality I can plug in a mouse, keyboard and monitor to use it as a Linux desktop.
Is it really chroot? As far as I can tell termux is just a terminal emulator +shell, and if given proper permissions it can very well access regular root without doing anything special.
It also has MCU cores in addition to the application core.
In fact I don't think there's anything stopping you from just running on the larger MCU cores and simply disabling the large core if you really wanted to for some reason.
> You cannot program it using USB, like you would an Arduino, ESP32, Stamp-C3 or rPi Pico. Nope... this needs to be programmed via the UART TX/RX pins.
I think it should be possible to use another ESP32 or ESP8266 for programming.
165 comments
[ 3.4 ms ] story [ 225 ms ] threadHow 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...
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.
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...
Perhaps it's better with the newer BSPs on the 8, but I wouldn't be too quick to jump back into it.
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.
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.
Cortex-R is also pretty common (R5 on Zynq-7000 and R7 on UltraScale MPSoC, for example)
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.
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.
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.
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.
$10.80 RISC-V AIoT module supports Linux:
https://news.ycombinator.com/item?id=33874032
EDIT: This is the official website for the Sipeed M1s showcasing the specs and application video for AIoT:
https://wiki.sipeed.com/hardware/zh/maix/m1s/m1s_dock.html
My man, ESP32 boards get you 802.11 WiFi for like $5 these days.
Zigbee is the kind of protocol designed for even simpler, more power efficient microcontrollers. Think closer to a $1 microcontroller instead.
There is a reason we have lol WiFi light bulbs. The uC that powers the smarts are really cheap these days.
And if anyone figures outbhow to use that NPU you could even do some inference to get some trends or something. Or even a classifier that could detect a short or water leak perhaps.
I dunno radios (skipped that class way back in college). I'm guessing that although 802.11 and Zigbee use 2.4 Ghz, you might need 2x radios physically tuned for the correct frequencies, and listening at the same time.
Looks like channel 1 802.11 is different than channel 15 Zigbee for instance, so bridging the two might need two different radios.
So you'd need a 802.11 radio + Zigbee Radio working as a team (even if ESP32 has enough CPU power to handle both, there are likely physical limitations to radio designs).
And I'm pretty sure that the radios use more power than the microcontroller in any case.
------
In any case, there seem to be many 802.11 to Zigbee bridges already available. So you should only attempt the project as a learning experience.
OTOH I remember that ZigBee is somehow more buttoned-up than BT and even wi-fi, so it's not commonly seen on likes of ESP32 and other small MCUs.
This is a good example of tradeoffs: slower and less throughput, but way more robustness.
Higher MCS levels of 802.11 cut down on error correction to 25% or 10%, achieving more throughput but less robustness.
I dunno how Zigbee does it, but I assume it has more error correction at slower (ie: more reliable) speeds than even WiFi MCS 1.
Do they all talk to each other in a mesh network, or do they all connect to your router in WIFI infrastructure mode?
> ESP-WIFI-MESH is a wireless communication network with nodes organized in a mesh topology using the simultaneous AP-STA feature on Espressif SoCs. It provides a self-forming and self-healing network, with ease of deployment. The network topology of ESP-WIFI-MESH can scale up to 1000 nodes in large areas.
https://www.espressif.com/en/products/sdks/esp-wifi-mesh/ove...
https://randomnerdtutorials.com/esp-mesh-esp32-esp8266-painl...
---
I didn't know that home WiFi routers have difficulty with more than a dozen connections, but I imagine ESP MESH could be a way around it, where a few devices connect to your router and act as access points for the rest of them.
https://www.espressif.com/en/products/software/esp-now/overv...
https://github.com/espressif/esp-now
The very similar Allwinner D1 can push HDMI though. It's got the same main core (T-Head c906) and is about the same price point. That SoC doesn't have the nice wireless interfaces builtin though.
I couldn't find any info on this from its datasheet.
While a great achievement and very interesting article, the same can be said from many RTOS that offer POSIX compatibility.
It'd be great for iteration to have a solid OS that cares about networking and updates and a an application layer you can move fast and break things with without risking soft-bricking your device.
I'm currently finding this with interpreted platforms like Espruino and Micropython, but don't understand at all why they have to be the only ones making this possible.
But the internal flash of a MCU can only be erased in pages that can range up to 4k or 8k depending on the platform. So that already limits how many free pages you might have that you could dedicate to an application.
What usually is done is to partition the flash into two areas, so you have two firmware slots. This allows you do do OTA updates: While you run from slot A you can write the new firmware to slot B, once you verified the firmware in slot B you set a flag that tell the bootloader to boot from slot B next time. (Oh and you need different firmware images for slot A and slot B as ROM addresses will be different and there is no address translations. Some bootloaders will avoid this always copying slot B to slot A if it's newer than slot A, but IMHO that's unnecessarily complex/inefficient. You might as well always generate both slot images and let the firmware decide which one to request).
Another question is, why would you even want to dynamically load applications? Those systems are not interactive, if you have some sensor monitoring the water level of your pot plant or the vibrations on some industrial equipment, it will only ever run that single application. It might get updates if it's doing some networking, but that will just be an update of the whole firmware.
https://docs.micropython.org/en/latest/zephyr/quickref.html
Very weird seeing the Zephyr booting message I've seen so many times followed by the micropython repl startup message I've seen so many times.
Hard to think of a good app for that topology. In the sense that I could stick circuitpython or micropython on a ESP32, or zephyr on a ESP32, so an app running both would get me ... ?
Conceptually, the *python people "could in theory" give up on porting to infinite number of new boards and focus really hard on working under Zephyr, and let Zephyr worry about porting to infinite number of new boards.
The idea of upgrading my MicroPython under Zephyr under MCUboot under Eclipse hawkBit over the wifi is pretty intriguing sounding challenge.
I have not dug into this technology stack other than recreationally. I'm a little unclear how interop works beyond the existing example of passing simple hardware pins thru. For example if MicroPython had a library that interop directly with the Zephyr RTOS features, that would be quite handy. Another thing I notice is the interop in the docs is simple pin pass thru, hard to even imagine how Zephyr's wide variety of networking stacks would pass thru for Python to use. It looks like there is nothing developed at this point where the uC could run a RTOS thread to "do stuff" while a MicroPython thread handled a wifi UI or UI in general or handled the non-RTOS tasks, although that would be cool.
https://github.com/bouffalolab/bl_docs/blob/main/BL808_DS/en...
https://github.com/bouffalolab/bl_docs/blob/main/BL808_RM/en...
With the shared memory bus, you can hand over tasks between the cores. You may not have the same software running on each core, but the data can be the same.
For your use then, you could just use the lowest power microcontroller with 64GB ram. You can't get that ability anywhere else.
It's 64 MB RAM
I'm hoping the MCU in the chip is the same as the BL602 chip- the 602 has a fully opensource firmware for the radio and cpu, can run zig and lora: https://lupyuen.github.io/
For me, I'm looking forward to using a riscV MCU with a decent amount of ram, as a fixed platform to build an OS on.
It's not, but it's similar. The BL602 has a SiFive E24, the cores in the BL602 are all T-Head cores (the mid core is a T-Head e907).
3 cores
> For your use then, you could just use the lowest power microcontroller with 64GB ram. You can't get that ability anywhere else.
I don't think the LP core has access to PSRAM. So most of the networking would run on the mid core, and the LP core just makes decisions to wake up a bigger core based on the events it sees.
Otherwise it feels like a pretty standard Linux.
That is all that needs to be said about this...
That was about 10x as expensive but probably more bang per buck.
I am hoping it gets first class support from some distro! Definitely don't want to rely on starfive support.
The Onion was $5, and included a proper serial interface, an SD card slot and wifi. It might have also had Bluetooth, but I'm not sure as this was seven years ago.
It was a great little machine. Very promising to have an entire Linux machine the size and shape of a 6502.
Alas, the company that made it put out a firmware update that made them act unpredictably, then another that ended up bricking machines. And at a cost of $5, there was no margin for customer support. The last time I looked into it, several years ago, the company appeared to be in pivot mode.
There was a vibrant emerging market of tiny SBCs in the years before COVID. Now everything is Raspberry Pi and Arduino. If you can get one.
Oh, I see, they produce satirical news now
https://www.raspberrypi.com/news/supply-chain-update-its-goo...
I get that the Rpi will use less power, but I imagine many people will be like me and have it overclocked to 2.1ghz, and my heatsink was pretty warm all day long.
I've recently picked up a Optiplex 3070 with a i5 9500t for $120 and bought 32gb of ram off ebay for another $40. Considering a Rpi 4 is going for $100 on eBay, it's not a bad deal at all.
https://en.wikipedia.org/wiki/CHIP_(computer)
I mean the thing has two USB ports, TWO! And you can't use either, hahaha!
I wrote up part 2 here: http://thelittleengineerthatcould.blogspot.com/2022/12/the-8...
But yeah, not plug-n-play. I still have to find out how to get network or SD-Card.
Nothing about this board makes any sense lol.
https://github.com/bouffalolab/bl_docs/blob/main/BL808_DS/en...
The BCM2835 was destined for a cheap set top box but for reasons not known publicly the manufacturer of that box didn't take those chips.
My first linux computer was a 33Mhz i386. I can't remember the amount of RAM, but it must have been 2MB or maybe 4MB.
This thing has 64MByte of RAM, after login, 44MB of it is free.
- processing data from a marine radar (it streams individual A-scopes as UDP stream), aggregating the sweeps into a .png image, denoising and uploading and handling some related logic (antenna tilt, gain settings)
- weather station pulling in data via serial/GPIO/... and publishing them as a webserver (lighttpd) and uploading them via OpenVPN to a cloud storage; firmware in the sensors can be easily updated and debugged remotely because the system runs avrdude and openocd
- emergency serial console - connected via USB to serial adapter to server, and you can SSH into it (again through OpenVPN/Wireguard), open a serial terminal or power-cycle the machine
- LoRaWAN gateway
And the best thing is that all this was written in Python! (with occasional C functions where native performance is required) So you have all the comfort of a high-level language and a full comfort of a standard Linux stack (though a bit limited because it is Busybox).
This little $8 board will run circles around even an RPi 4 when it comes to doing something like controlling a long strip of ws2812b RGB LEDs, as an example.
Why would a Raspberry Pi have any issue with this?
Do you have a suggestion for a better platform?
As processors become more powerful, voice I/O becomes the cheapest way to interact - microphones and speakers, or even just a Bluetooth link, are much less expensive and less bulky than a screen and keyboard.
Typically recommended are lithium iron phosphate (LiFePO4) or lithum polymer (LiPo) batteries, both of which have higher capacity, better discharge profile, and can be recharged (the latter while the device is in operation).
Unfortunately it has no sleep mode (the supported power-down modes erase the main RAM, leaving only 64KiB region, so it's unusable for suspending of the booted-up Linux), so it will last a few hours at most.
This is a common problem with almost all of such boards. And we see great power management is definitely possible: Android phones can suspend to milliwatts for a decade. But there is no support in this hardware, where you can run "normal" Linux, not Android :(
https://wiki.friendlyelec.com/wiki/index.php/NanoPi_Duo
I think they are positioned to be the new low-cost esp32 variant.
Pine64 keep making these silly little mistakes limiting their products' appeal.
Might just be me, but I value the ability to quickly get started without a lot of setup and debugging hardware before getting to the software aspect. I don't want to keep the thing fully set up on my desk, I'd like to put it in a bag and get it out whenever I feel like it.
The WiFi capability may make this easier after the initial setup, but it's still an unnecessary hurdle.
https://gist.github.com/lupyuen/7a0c697b89abccda8e38b33dfe5e...
I guess after the restock this won't be a problem since it'll be the second batch?
Soon enough, it will be the even smaller $1 Linux computer.
And then, the even smaller $0.10 Linux computer.
In the future, even toilet paper will be running Linux.
https://youtube.com/watch?v=lE4UXdJSJM4
But yeah, we need to recycle these phones by making them home servers, etc.
Basically you get most of the useful functionality from installing Linux, without needing root.
It runs blender and gcc pretty well!
https://wiki.termux.com/wiki/PRoot
64MByte RAM, (45MByte of it free after logging in.)
In fact I don't think there's anything stopping you from just running on the larger MCU cores and simply disabling the large core if you really wanted to for some reason.
I think it should be possible to use another ESP32 or ESP8266 for programming.