$6 Pine64 Ox64 SBC features BL808 64-bit/32-bit RISC-V multi-protocol WiSoC with 64MB RAM

Pine64 Ox64 is a single board computer powered by Bouffalo Lab BL808 dual-core 64-bit/32-bit RISC-V processor with up to 64MB embedded RAM, multiple radios for WiFi 4, Bluetooth 5.0, and 802.15.4 (Zigbee), as well as an AI accelerator.

The board also features up to 16MB XSPI NOR flash, a MicroSD card socket, a USB 2.0 OTG port with support for a 2-lane MIPI CSI camera module, and two 20-pin GPIO headers for expansion. It measures just 51 x 21mm, or in other words, is about the size of a Raspberry Pi Pico W.

Pine64 Ox64 SBC

Pine64 Ox64 specifications:

  • SoC – Bouffalo Lab BL808 with:
    • CPU
      • Alibaba T-head C906 64-bit RISC-V core @ 480MHz
      • Alibaba T-head E907 32-bit RISC-V core @ 320MHz
      • Alibaba T-head E902 32-bit RISC-V @ 150MHz
    • Memory – 728KB SRAM, 64MB embedded DRAM
    • AI accelerator – NPU BLAI-100 (Bouffalo Lab AI engine) for video/audio detection/recognition
    • Wireless
      • 2.4 GHz 802.11 b/g/n Wi-Fi  4
      • Bluetooth 5.x dual mode (classic + BLE)
      • IEEE 802.15.4 for Zigbee
      • 10/100M Ethernet through add-on board
    • Display
      • Up to 4-lane MIPI DSI
      • Up to 8-bit MIPI DBI
      • 16-bit MIPI DPI
      • QSPI
    • Audio Codec – 2x ADC, 1x DAC, sample rate: 8 to 192KHz, 24-bit
    • Camera
      • 2-lane MIPI CSI and DVP interfaces
      • MJPEG and H.264 encoder up to 1920×1080 @ 30fps + 640×480 @ 30fps
    • Package – 88-pin QFN
  • Storage
    • 16Mbit (2MB) or 128Mbit (16MB) XSPI NOR flash
    • MicroSD socket with support for SDHC and SDXC
  • Camera & audio – 2-lane MIPI CSI co-located with USB-C port for camera module including microphone and speaker
  • Antenna – 2.4GHz chip antenna soldered on board, footprint for u.FL connector
  • USB – 1x USB 2.0 OTG Type-C port with MIPI CSI “alternative” mode
  • Expansion – 2x 20-pin headers with castellated holes with GPIO, SPI, I2C, and UART, possible I2S and GMII expansion
  • Debugging – 5-pin JTAG header
  • Misc – BOOT button, red power LED
  • Power Supply – 5V/0.5A via USB Type-C port or micro USB port
  • Dimensions – 51 x 21 x 19mm
Bouffalo Lab BL808 Block Diagram
Bouffalo Lab BL808 Block Diagram

There have been several Arm processors with built-in 64MB to 128MB memory from Allwinner and SigmaStar in recent years, so it’s interesting to see Bouffalo Lab doing something similar with the BL808 RISC-V SoC. There are some more details including the Ox64 schematic and BL808 datasheet + TRM in the wiki.

The BL808 wireless processor is designed for low-power AIoT video/audio applications, notably two-way voice intercoms. The BL808 is supported by an RTOS SDK, and Linux is being worked on. That’s why there are two SKUs for the Ox64 board, one with 16Mbit flash suitable to run an RTOS and another one with 128 Mbit flash to run Linux.

Ox64 BL808 SBC prototypes

Pine64 Ox64 is available for purchase for just $6 for the 16Mb Ox64 and $8 for the 128Mb Ox64. You’ll find both on the Pine64 store. Note that at this early stage, I would not expect all features to work outside of the box.

Update: The post was initially published on October 10, 2022, and updated once the Pine64 Ox64 was up for sale.

Share this:
FacebookTwitterHacker NewsSlashdotRedditLinkedInPinterestFlipboardMeWeLineEmailShare

Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress

ROCK Pi 4C Plus

75 Replies to “$6 Pine64 Ox64 SBC features BL808 64-bit/32-bit RISC-V multi-protocol WiSoC with 64MB RAM”

  1. Very interesting! Would be nice to see a community develop around this so there is an easy to use SDK for this that runs all of the heavy and security critical bits like networking on the C906 with Linux and then a clean way to throw code over for the E907 to run while most of the system is powered down.

    1. The TRM even lists a third core in section “1.2.3 LP”, which is RISC-V RV32EMC and “ultra-low power”. The IPC unit seems to be connected to all three cores so communication between them should be possible in the usual ways. However, I haven’t seen the LP core in the bus-interconnect diagrams so I don’t know which memories and peripherals can be accessed by it.

  2. This would be interesting not just for yacto linux devices, but even with something more general purpose, like AlpineLinux. In fact, with 16 megs flash and 64-128 megs ram, it has more than enough to boot a practical Alpine rootfs to ramdisk that could carry app services of various kinds.

    1. There is MII port on the GPIO pins that can attached a 10/100Mbps PHY and for sure also PoE. PINE64 already has this add-on board in their plan. The other two add-on are 1) DAP (digital Audio Player) with i2s DAC and SPI LCD panel, 2) either USSB or MiPi SCI camera module.

  3. Even though I see all these elements positively, like a promise of a proper RTOS on a chip with 64MB of RAM, video output with basically all protocols that might be used with these chips, or video, AI accelerator and networking in one package, I do ponder about limits of this combined package. Let’s say that 8 pins are taken for basic power, clock and radio pins. Then take at least 10 pins for video out, 4 for JTAG, at least 4 for audio, 6 for QSPI, 4 for USB+Type-C control and so on, until dread sets when you are not sure whether some of these generous pin reserve assumptions can be skipped or is there really a multiplexing that prevents one from using all most on-package components in one package. Then I look into datasheet and see that almost a third of pins are power rails. So while I do admire capabilities of this chip and wish it to be better than multi-chip alternatives, one who would like to take it off this board and put into a larger system is likely to need separate microcontroller for I/O expansion, or use its design, since it seems to be a great breakout+support board.

    1. This situation is not specific to this chip.

      If it were a small BGA package with plenty of balls, one would complain about the non hacker-friendliness. If it were a large TQFP100+ pin package, one would complain about size. This package sits in the middle, and the fact that there are 2 different SKU (one for doorbell and one for IP camera) seems to indicate that they address a specific market, where the available pin count matches the needs.

      If you need more low-speed GPIOs, just add an I2C or SPI I/O expander, it will be cheaper than a separate MCU and does not require an extra firmware.

  4. xSPI seems to be a DDR extension to OSPI or Octal-SPI with data transfered on both edges of an up to 200MHz clock. That’s 800MB/s! Yikes! We’re getting into critical routing requirements on that PCB! Matched length traces with impedance control, etc. If you’re thinking of DIYing a design with one of these, beware of that xSPI routing, friend.

    1. Looking at the production schematic shows a QSPI memory, so that’s a signifigant step down from an xSPI chip. Maybe the x in this case was meant to be a wildcard so as to say it had *some kind of* SPI memory. It’s clearly not xSPI. The chip is a W25Q128JW/W25Q256FV which are 16MB and 32MB SPI/Dual-SPI.QSPI serial flash chips. Good for 52MB/s read/write down hill with the wind at their back and their fingers crossed.

  5. Amazingly interesting! That could quickly constitute a production-grade tiny linux-on chip, a-la breadbee except that if the manufacturer participates to the porting, it could be much less of a hassle and could quickly turn to something usable. The frequency is a bit on the low side but at those levels I suspect that there are good margins. My breadbees run remarkably stable and cool at 1.4 GHz for a theoretical limit of 1.0 🙂

    The power draw will be interesting to watch by the way. The breadbee runs fine at ~0.6W under load and ~0.5W idle. Maybe an SoC designed for low-power applications can do even better.

    1. There is no MMU in this chip, so you can forget about running Linux on it, unless you want to go the MMU-less path, which I don’t recommend (been there, done that).

          1. Looking at the Olimex page under the description of the T_head C906 480MHz 64-bit RISC-V CPU it lists: Sv39 memory management unit, realizing the conversion of virtual and real addresses and memory management. Sounds like an MMU to me.

            Nothing similar listed for the main 32 bit core. So, it may just use a physical mapping. The datasheet linked to from T-Head says that it has a PMP, so just basical 16 region protection/mapping. Not enough for VM, but plenty for an RTOS to have simple privelege separation.

          2. And that should draw the separation between these two cores, one for a real operating system and the other one for device and power management with no user code.

          3. I see it as 64 bit for user code/OS. 32 “big” core for low level programs that need realtime. 32 ‘litte’ core for power management and housekeeping.

  6. Extremely interesting. On paper at least it’s promising a lot of very good stuff. Bouffalo is known for lack/bad documentation/support, and I’ve avoided them completely. But that’s a hell of a great risc-v stuff they are working on. Even without linux, i can see a lot of things that could be done with that.

    1. Actually I’d rather see it with linux rather than with yet another totally insecure stack waiting for a widescale takeover, or just trivially hackable software suites that were never designed to run in hostile environments.

  7. Is it just me or a name containing “x64” as a substring is quite unfortunate for a RISC-V based design (and not an x86 one)?

    1. I think the name comes from Bouffalo = Buffalo, similar to an Ox, and the processor is 64-bit, so Ox64 it is.

  8. Oooh! Forget Linux! I’m super interested in this as a *bare metal* thing. The AI accelerator would be perfect for doing matrix transforms with high resolution RGB LED matrices for all kinds of cool special effects 👍

    1.  AI accelerator would be perfect for doing matrix transforms with high resolution RGB LED matrices for all kinds of cool special effects”
      true

        1. I think you might find many are thinking the opposite and very interested because such a device has a NPU and only wondering what can be expected and what layers might be supported in a SDK

  9. Reminds me of that Sigmastar chip announced a year or so ago that has gotten no attention since then. Maybe the 16MB board plus an SD card can run a “big” Linux? I’m pessimistic though, because of the mention of historically bad documentation from Bouffalo, plus Pine’s tendency to leave projects unfinished. Otherwise this seems like a nice alternative to the unobtanium and bigger Raspberry Pi Zero. Are they serious about the 2.5W power consumption though? Ouch.

  10. why the 32bit core anyway ? i guess it can’t be used together with the 64 to run linux, so why ? for the gpio ?

  11. I don’t know why so many commenters are so convinced it can’t run Linux. The big core is the same C906 block that’s in the D1 sold by Sipeed (Nezha) MangoPi and others. (It’s not totally clear if the V unit still has the pre-release 0.7.1 mess that shipped on D1.) It’s a single (big) core and it’s not a huge amount of memory, but if you pair it with an appropriate Linux build, it’s reasonable. You don’t want to run a desktop on it, but for process control or something, it’ll be fine.

    There absolutely is an MMU. Bouffalo has already published several hundred pages of doc on the SoC.

    This isn’t like ARM Big.LITTLE where the cores are highly compatible, though. See https://www.robertlipe.com/bl808-not-symmetric/ You really want to give the lower power cores something very specific to do, give them their own chunk of memory to live and execute code from, and just pass messages to and fro. You’re simply not going to migrate processes between them. Running something like two different Nuttx instances compiled two different ways could be another option to a full-on Linux, too. There you can choose whether you want address space isolation on the RV64G core or if you just want everything to be a global.

    As for the NPU, I haven’t checked, but most every part these days has SOMETHING on it you don’t need. Nobody’s screaming “That’s too many GPIOs and too many i2C busses! Take them off!.” Don’t enable the clock in that domain, leave that block in reset and while it might not consume zero, it’s not far off. They’re not really pitching this part into the coin cell market.

    There is another company that has a SBC shipping this year that I’m 99% sure is using the same BL808, but they haven’t actually called it out by name, I won’t do so, either. The chip is getting some inertia behind it.

  12. If it can be programed in RTOS mode in Arduino IDE it be the best board under the sun like teensy 4.1. but hugely better and cheaper. Like h264 codec in this is crazy. Please let this happen !!!
    Fastest board on Arduino IDE for 10$ here we GOOOO!!!!
    (I loseing my mind)

  13. EU Shipping seems to be 30$ and they then don’t include customs and tax, so that probably another 12$ customs tax, i hope some EU shop will also sell these, otherwise its a no go.

    1. Pine64 has an EU store (https://pine64eu.com/) with automatically calculated VAT and free shipping, but, unfortunatelly, this board is not available there.
      Let’s hope it will become available or maybe in Aliexpress store …

      1. Don’t they also have to provide a longer warranty in Europe? So they’ll probably want to wait a few more months before selling it there.

    2. I just ordered 2 boards, but I got an option for ‘EU Standard Shipping Method: $11.99’. No VAT so still not the best deal, but worth it for me.

  14. Thanks for mentioning that Pine64 module. I’ve ordered one. Also posted a link to one of the Raspberry Pico FB groups. It’ll be interesting to see what they make of it!

        1. The PSRAM is inside the CPU chip. There are two dies in the package. It won’t be shown on the schematic.

          1. Oh, thanks for the kick. I see it on the specs on the wiki, now. 64MB is a lot of PSRAM. I’ve not seen a chip that big before. I wonder how it’s connected? Why not just use cheaper DRAM? It requires a lot more wires for the parallel connection, but this is embedded, so that’s not as much of an issue as if it required package connections. And it would be a lot faster. (assuming the PSRAM is serially connected) But then again, maybe the PSRAM is xSPI–because the external flash clearly isn’t.

            The Wiki is still in disagreement with the schematic on the amount of external flash. The schematic says 16 or 32MB while the Wiki claims 2MB or 16MB. The 2MB value is super tiny by modern standards.

          2. In general PSRAM works like a page fault. You don’t directly run out of PSRAM. Instead the hardware catches an access to the page, fetches the page out of PSRAM and into SRAM. Code works the same way when executing out of SPI flash. When you run out of buffers the OS will decide to write a dirty page back to PSRAM. So for MCUs there isn’t a huge difference compared to DRAM. To compare DRAM to PSRAM you’d look at the 4KB burst speed.

          3. That’s how most XIP systems work, yes. But, if you look at devices like the Nintendo DS, they use a parallel PSRAM which just looks like a normal parallel SRAM, but used DRAM with hidden refresh and rewrite.

            So, I’d rather not confuse PSRAM’s behaviors and XIP.

            My question boils down to, are they connecting the *on package* PSRAM via SPI or parallel. If SPI, then that explains why they use PSRAM rather than DRAM–there isn’t SPI DRAM in common use (I am sure some freakish place makes it somewhere for *reasons*). If it’s a parallel PSRAM, then why not just use DRAM instead? It’s cheaper than PSRAM and easier to source.

          4. They very well may for a certain capacity range.

            Really looks like this is meant to replace parallel PSRAM and not serial, but it uses a serial-ish interface (just running really fast) so that it has the latency and bandwidth of a parallel interface. Neat.

            Thanks for the link.

            Oh, forgot to ask. From reading the data sheet, does the controller treat it like directly mapped memory or does it need to fake it like other XIP/SPI chips do?

          5. For MCUs, the power draw of memory at rest counts a lot, and DRAM needs constant refresh which eats a lot of power. PSRAM will only draw power during transfers, so that’s an important difference to consider, even if it costs more.

          6. PSRAM should take about as much power as DRAM for the same amount of access. Considering PSRAM *is* DRAM but with a controller wrapped around it to hide the DRAMness of it. It’s not SRAM, it’s *pseudo* SRAM which mean it fakes being SRAM when it’s not.

            What are you basing your arguement on?

  15. Could Pi-hole be run on this? I’m thinking RAM and storage might be too skimpy for it to be possible, but would be happy to be wrong.

Leave a Reply

Your email address will not be published. Required fields are marked *

Khadas VIM4 SBC
Khadas VIM4 SBC