Yes, you peruse that right... for $8 you can run linux on a RISC-V computer. And not fair a stripped downward kernel without an MMU. No, the Ox64 comes alongside capable RISC-V cores. Heck, and not fair one core, but three cores (all different.) Exciting times!
Caveat Emptor! At the period of writing, ethernet, wifi and SD-Card are not working. It's fine to acknowledge this before jumping into this.
It looks akin a microcontroller, but behaves akin a UNIX machine. Sweet, or what? Getting it up and running, though, is far from trivial. There are so many hurdles to take!
Hurdle 1: You cannot program it using USB, akin you would an Arduino, ESP32, Stamp-C3 or rPi Pico. Nope... this needs to be programmed via the UART TX/RX pins. In the image above, you can see them hooked up to GPIO14 / GPIO15 and GND.
Hudle 2: The flashing tool Dev Cube volition collision on initiate whenever using Ubuntu on Wayland: you have to toggle to Xorg instead.
$ ./BLDevCube-ubuntu Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use QT_QPA_PLATFORM=wayland to run on Wayland anyway. /usr/lib/x86_64-linux-gnu/gio/modules/libdconfsettings.so: undefined symbol: g_log_structured_standard Failed to burden module: /usr/lib/x86_64-linux-gnu/gio/modules/libdconfsettings.so GLib-GIO-Message: Using the 'memory' GSettings backend. Your settings volition not be saved or shared alongside another applications. (BLDevCube-ubuntu:54646): GLib-GIO-ERROR **: Settings schema 'org.gnome.settings-daemon.plugins.xsettings' does not merge a key named 'antialiasing' Trace/breakpoint trap (core dumped)
So, UART programming then... fine, we'll fair use one of those small CH340G dongles. I got one off Amazon, but it would not work... all period the handshake would neglect in Dev Cube (hurdle 3).
Luckily, some people established out that you can program it alongside an RP2040 device, akin the rPi Pico. I had a KB2040 from Adafruit lying around, so used that.
Which puts us at hurdle 4: How to rotate a KB2040 into a serial extend between PC and Ox64? Hook up GPIO-4 of the RP2040 to GPIO-15 of the Ox64. Hook up GPIO-5 of the RP2040 to GPIO-14 of the Ox64. Also, nexus the grounds, of course. See below how to hook up for flashing the M0.\
Then we need to burden our RP2040 alongside picoprobe which we can do by holding BOOT during powering up, and feeding it the uf2 document alongside picoprobe.
Ok, so now we can flash it then? Unfortunately, no, hurdle 5: DevCube is motionless not capable to flash the Ox64, but we can use bflb-mcu-tool instead.
Ok, but alongside bflb-mcu-tool, we are all set! Are we? Introducing hurdle 6: we need to modify the tool before it volition activity for us. This method stripping DTR and RTS material from the tool by editing the ~/.local/lib/python3.10/site-packages/bflb_mcu_tool/libs/bflb_interface_uart.py file. Here is my copy.
So alongside the Ox64 powered via MicroUSB, and the RP2040 connected to my PC using USB-C, I can eventually flash something. For that, I took the low_load_bl808_m0.bin from the bl808 linux guide and flashed it with: $ bflb-mcu-tool --chipname=bl808 --port=/dev/ttyACM2 --baudrate=2000000 --firmware=out/low_load_bl808_m0.bin
After which I now get output from my Ox64, via my KB2040 to my PC: dynamic recollection init success,heap size = 156 Kbyte E907 start... mtimer clk:1000000 psram clk init ok!
Ok, a humble start, but the Ox64 is talking to my PC now! Yay! Come rear to my blog at a afterward period to see if I volition oversee to run Linux on the Ox64! Because as I comprehend it, I additionally need to flash item to the D0 and afterward flash the genuine OS as well.
UPDATE: Here is PART 2.
