The pi pico is in no way almost a full fledged computer, it is just an MCU. This board is different though since it has a RV64 processor, a RV32 processor and another RV32 processor that is apparently used for WiFi. This chip also has a built in NPU. It is very different from the pi pico.
@conorstewart2214 You are absolutely right my friend! With this one there is the RV64 D0 core, which does most of the heavy lifting, then there is an RV32 M0 core which does most of the GPIO, wifi, ethernet, etc, but the code running on this is primarily an IRQ message bus so that D0 can access it, and then there is the LP core which is just a RV32 160MHz but this is currently unused and mostly undocumented. Bouffalo Labs are working on releasing the LP SDK, wifi spec, and a few other things, but it's all currently under NDA until complete. Hopefully not long!
The PDP-11 ran UNIX v6, programmed in C. Its 16-bit single-core CPU clocked between 500 kHz to 1.25 MHz, supporting a maximum memory size of 4 MB. Hard drives varied from several megabytes to tens of megabytes, spinning at speeds of 2400 to 3600 RPM. To match the processing power and efficiency of a single RP2040, you'd require a thousand PDP-11 units or more. The processing power of an RP2040 would have set you back $10 million in 1975 to start. At MIT, they teach xv6, a rewrite of the original Unix 6 code, which they run on tiny RISC-V microcontrollers. The RP2040 possesses the processing power necessary to drive groundbreaking advancements in weather forecasting, space exploration, molecular modeling, astrophysics, and nuclear physics. The problem isn't with the hardware, but lack of programming skils.
The benefit of a full OS, in my mind, is the relative ease of reprogramming it. With ESP32 and Pico W, unless you do something clever like the UI Flow system from M5stack, you need to flash the ROM for every iteration. But if you get the firmware to fulfill all your needs for a project, then all that flexibility will not be useful until you scrap the project and reclaim the parts.
On the store's accessories page they have stacking headers which might cover less of the pin labels (haven't got any yet as waiting for software support to mature).
pretty cool device! Hopefully they flesh out a bit more documentation so there's less hunting to get what needs done. I'm in the US though, and our picos are $4/$6 for regular and wirele4ss respectively, so these are a bit pricier than that. that being said, pine64 is definitely an organization worth investing in as far as open source goes.
Pico's are that cheap there? I was seeing them $8 US, which is about $11 AU. At least your shipping is cheaper 😅 Either way yeah some more English doco would be good hah.
Looks like soon (once EthX and camera are driven) this will be the perfect node for a chain of low-power and affordable ethernet security cameras. Can anyone assess whether they would have sufficient compute to do local image processing - like face or human detection?
Maybe but the Ingenic-based cameras are like $20 USD running full Linux 96MB+ RAM, 1GHz, with SD card, hardware video encoding, WiFi, and you can add USB Ethernet/PoE. Really hard to beat that. The only caveat is you have to hack the camera to remove the default Linux (spyware) and install your own firmware.
I was on the fence re: the Ox as read flashing Linux was super complicated but your video convinced me to give it a go and I await my order and look forward to following this guide so cheers!
Glad to hear! Good luck on the backorders haha. I keep hitting refresh, but have also emailed their wholesale team about warehousing some here in AU. If you get stuck at all feel free to reach out!
@@PlatimaTinkers So I managed to get Linux flashed using a Pico as didn't have CP2104 handy and its awesome to see it boot up so fast. The process was fairly easy and I hope to see development come along as the thought of using it for Home Automation with Zigbee is exciting. I agree its cheaper than the Sipeed M1s Dock but I didn't pay too much for mine on Aliexpress as having a camera and screen makes up for the added cost... 👍
Amazing device! I can imagine using this SCB to make a portable SDR that can process much larger bandwidth than those made by ESP32 and STM32H4. (H7 I am not sure but H7 is crazily expensive).
Yeah quite possibly - the high MHZ and apparently wide band ADC would certainly do the trick! I've never used a H7, all my STM32's are F series. But yeah this is about 1/10th the cost of a H7 devboard it seem haha.
@@Danil-intl He's talking about making one :P Or if you meant the H7 then here's an example devboard for you au.mouser.com/ProductDetail/STMicroelectronics/NUCLEO-H723ZG?qs=zW32dvEIR3v%252BApBMtkRmgg%3D%3D
Yeah I think that comes down to either the exact image, or the hardware revision! When I did the update video more recently, I think they were both Block 0. From what I understand, this is because they managed to move more binaries into the image, rather than it being on SPI flash, so can be updated by the OS etc. Good to mention though! Cheers
Nice! Thanks for sharing this! I'll probably be picking up a few to play around with. It's cool that they come with ZigBee, they should be great for automation.
Hey mate sorry just on the road, but glad you liked it. Sorry I don't have that data on me now, but I think I checked it in a shorts I did? Else I can measure it when I get home. I recall it being around 30mA but that could be completely wrong or another product!
Now what I _really_ want to do is run Rust on this thing bare-metal. 64MB of RAM _all to myself_ and whatever protocols I can bit bang from however-fast-that-thing's-GPIO-is without an OS in my way sounds really fun.
Saw your comment at work. Googled it - its doable! It looks like RV64GCV is about 100% complete within LLVM, and the Bouffalo Labs SDK has everything you'd need if you can interop with C libraries or link to them as OBJs. Ref github.com/bouffalolab/bl_mcu_sdk/tree/master/examples
@@PlatimaTinkers Similar configuration app like System76 Launch has. Or QMK app. But for this Ox64 sbc and written in Rust. Sorry for being misunderstandable.
there is probably a pine64 wiki for this item but it needs a volunteer to write up some documentation. I sent you a message in the red dit post for how to join the pine live chat on this very item since I can't figure out how to be invisible to the YT delete bot.
Amazing tiny device! I can't believe it could be possible to run actual Linux kernel on a board with the Arduino Nano form factor. Is Zigbee embedded version 2 or 3?
Yeah I've reviewed a few of these now, and they're all pretty damn good! The 803.11/802.15.4 (Wifi/ZigBee) implementation is not complete, but it is working in the upstream repo (bl808) in bits and bobs, and currently being merged into OpenBouffalo which this uses. The ZigBee standard is implemented at the software layer though, so I'd expect V3 to be supported IE meshing.
Absolutely, especially when the NPU module and CSI connectivity is functional!
11 หลายเดือนก่อน +1
This thing seems quite interesting. I wonder if this thing is powerful enough to build a remote RTL-SDR receiver or at least do some direct sampling stuff with a RTL2832U.
this board looks VERY interesting, but I think I'll wait for some proper documentation, and to see how they do expansions, audio in particular, because if that 2 ADC 1 DAC @ 8-192kHz claim is true, then I have some nice use-case scenarios for this little fella... do post more videos, this looks promising...
@@PlatimaTinkers That's one of the reasons I got some of these boards too, outside of the Teensy there are not many boards for audio applications (synthesizers, samplers etc) that have decent DACs and ADC's and USB host (eg MIDI) support, though the RP2040's are getting there slowly now. And thanks for posting this video, getting the 0x64 setup is hard work compared to other boards so your video really helped my out! Thanks mate!
@@mksln Hey you're more than welcome and I am glad it helped! I cannot wait to see how well the DAC performs once complete, as apparently its capabilities are pretty decent!
Ok, here's a question: with Linux on there, can it act as a USB host? Does it have access to the USB with that kind of control? That's the main issue I have with the PICO, that it does not support USB host mode.
Hey yeah if you refer to the datasheet, the USB 2.0 implementation is for Host and Device mode. The RM PDF then expands on that in section 25.1. It's just up to the drivers to be finished, which is making some great progress both with the open source community, and with Bouffalo Labs team.
The Linux Kernel is actually hilariously efficient if you strip it down for your hardware. It's just such a nightmare to do, and it completely ruins portability, so nobody bothers.
@@KiraSlith Yeah so true, but I think we just forget it with modern apps these days. Like how is Balena Etcher a 213MB application that needs 100MB of RAM? God damn Electron framework that's how. I was so very happy the other week when I saw the WinDirStat installed size was 733KB - that's how applications should be made!
The RISCV architecture has always interested me. Good to more and more devices on the market. Will definitely grab a couple. Also, is that a Cooper Pale?
Yeah there is a LOT of good RISC-V stuff coming out, and I'm even making my own 😅 If you're in AU I've got some local stock; shop.plati.ma Damn right it's a Coopers Pale mate 🤘Good spotting, I just think I was using a Bush Chook stubbie holder hah.
Question: I had a crash with M0S board (Boufallo's BL616 single core RV32). * They require custom GCC10, * Zigbee is walled by NDA, * Flash programming is via a custom, unintuitive software * a vast majority of How-tos are in Chinese. How does Ox64/C906 stack against that?
There is definitely way more available around BL808/C906 due to the Ox64, but I think BL just need a bit of time. They are a small team, creating something awesome, and not all things happen overnight. That being said, given the popularity I don't think we're going to be waiting too much longer thankfully!
There is another board with the same chip, it is the sipeed M1S dock and it has a LCD and camera interface as well as two usb C ports, it also allows you to flash the chip over USB as it has a chip or microcontroller built in to handle that, it may be more useful for some people than this board. Since it uses the same chip it should just be programmed the same.
Oh yeah good thought - I did forget to mention that this will be flash-able by USB eventually. As this is an open-source and community-driven project compared to the M1s, the development lifecycle is just a tad different. But that is also reflected in the awesome price tag.
@@PlatimaTinkers the M1S isn’t expensive, especially considering how much more difficult and expensive it is to get pine products in the UK and Europe. You can get the M1S as a bare module for embedding in your own designs for £6.08 or the dock for £9.40, the full kit with a usb cable, header pins, camera and lcd with the M1S dock is only £17.33. So the pine 0x64 doesn’t have that much of a price advantage on it especially if you go with just the dock board itself with no extras, like the pine 0x64 comes. There is no reason that most of the developments for the pine 0x64 wouldn’t apply to the M1S dock and the M1S already has working examples for the lcd and camera. The main advantage for me anyway is how easy and cheap it is to get compared to the pine 0x64.
@@conorstewart2214 makes sense re the region. Probably varies quite a lot! For me if I get 3x Ox64 they cost $12 AUD ea inc shipping. For the M1s module the best I could find is $20.93 AUD ea inc shipping. I am working with Pine64 on warehousing some here at one of my locations so we can include some cheaper shipping options, but not sure how long that will take. The ease of use is definitely a huge advantage, but I think if we give the Pine64 team some time, they'll definitely get there. Thanks for the info!
Yeah I'm aware of that, but I feel 'five' is longer to say, plus they refer to the ISA as RV64 so just kind of follows. Who knows, maybe by pure public influence I could change that 🤣
@@PlatimaTinkers The stuff you burn ... that is to the flash memory on the Ox64? And then you "just" let it boot from Linux on the SD-card? If so, could the supplier take care of the flashing, so that buyers can just write a Linux to an SD card, and ... voila?
@@blablamannetje Hey yeah so this is actually quite an interesting one! Group 'M0' is the 32bit processor, and D0 is the 64-bit processor, both of which have a tiny bit of on-chip zero-delay SRAM. It then has the 8-pin external Winbond xSPI chip. The datasheet (files.pine64.org/doc/datasheet/ox64/BL808_DS_en_1.1(open).pdf) has all of the base addresses for all of these. I also believe there is 'LP' which is a lower power E902 32-bit core but I cannot find anything about that in the BL808 datasheet! While not immediately clear there other than in some of the function maps, if you have a read of the code for these images we're flashing with (github.com/openbouffalo/OBLFR/tree/master/apps) you can see both boot and handle different aspects of the chip. D0 though is what does the heavy lifting, and you can see in its main.c that it loads the DTB (Device Tree Binary that the kernel uses to know about the hardware under it), OpenSBI (supervisor binary interface - RISC-V middleware that executes the kernel), and then the Kernel (which is actually the Kernel and those last two compressed into a single binary). That single Kernel binary is what we are flashing on the IOT tab, which is the SPI memory, and includes the drivers and boot args to talk to the SD card. So that means it goes Power On -> D0 and M0 start executing -> D0 loads the kernel et al from flash -> Kernel loads the OS itself from SD card. Note I believe the initial GPIO14/15 we used are connected to the C906 32-bit core, and then 16/17 are connected to the E907 64-bit core. I may have also gotten piles of this wrong!
@@PlatimaTinkers I just ordered the CP2104. As soon as I get it I will give it a try. I've been trying to translate the manuals that are in Chinese with no luck. I did finally get the DevCube running but need the CP2104 to communicate. Which img did you use? the sdcard-pine64_0x64_defconfig or sdcard-pine64_0x64_full_defconfig?
@@christianskovly8831 Hey yeah I used the full image. Honestly not sure the difference, but I can only assume the smaller one is for the 2MB SPI flash board!
@@platima You live a charmed life. I've been banging on this lil thing for a week and haven't been able to get it all the way. I've made it through the flashing but now I'm trying to get it to boot the linux sdcard. What are the pins that I need to change my CP2104 connections to? I'm I supposed to use GPIO22/MOSI/MISO (physical pin 15) and GPIO25/MISO/MOSI (Physical pin 16)?
@@christianskovly8831 Hey this can change depending on what you're flashing it with. Are you using the same binaries I did? If so flash it using GPIO 14/15 at 2 million baud, then after flashing change it to GPIO 16/17 for boot. Note that these are pin numbers 1/2 and 32/31 respectively! Refs: github.com/openbouffalo/buildroot_bouffalo Didn't realise I replied with the wrong account last time haha
Seems like that fills a gap between a RP2040 and a Pi zero I didn't even realise was there.. might snag me a couple, already got some ideas on what that could do.
@@conorstewart2214 Yeah was looking at the M1s Dock, but it's a bit pricey comparatively. This supports LCD and camera, but the MIPS CSI interface and USB protocols are not quite complete yet. The community developers have been working with Bouffalo Labs on getting this across, and it's very close!
I really do not see why not! Once more of the drivers are completed you could use an e-ink display, or possibly even VGA or DVI with a custom header for it.
"Package cannot be shipped to your country due to logistical reasons." Is there other way to get from other stores or without using some random dropshipping services?
Really good stuff, I'm getting a couple for myself. I had been using OpenWRT on Pi Zero W's for lean Linux apps where a console is not needed and I can use SSH to access. It's not just for access points, with Opkg I can get a lot of standard tools, and it has worked really well since it doesn't rewrite flash and thus no wear. But this is even tighter on resources. Exciting.
@@PlatimaTinkers will do! I've been looking at the official and community repo's, there are quite a few options under development. Hopefully a chip this powerful will get some good development support.
@@BrodieFairhall I think it will! It's less than a year old and is going this hard. Compare to RP2040 which is less powerful and even older, and you see a faster adoption rate IMHO. Jump in and contribute would ya! Hah
According to the documentation, after flashing, pins IO5 (RX) and IO8 (TX) are UART3. But GPIO5 and GPIO8 dont't exist and pin is RXD pin 8 is GND. Which pins did you connect?
Hey yeah it can be confusing; there are 3 cores and their UARTs are connected to different default pins. For flashing the D0 and M0 cores plus SPI you want GPIOs 14 and 15, then once booted the output is on GPIO 16 and 17.
@@PlatimaTinkers In the bl808_linux project there is a `patch/m1sdock/m1sdock_uart_pin_def.patch` and I had to do `patch -Np1 < patch/m1sdock/m1sdock_uart_pin_def.patch` to apply it. Btw what do you get, if you `cat /proc/cpuinfo`. Mine says it's a C910, not a C906. I think it's a bug. Edit: to be precise: processor : 0 hart : 0 isa : rv64imafdcvsu mmu : sv39 model name : T-HEAD C910 freq : 1.2GHz icache : 64kB dcache : 64kB l2cache : 2MB tlb : 1024 4-ways cache line : 64Bytes address sizes : 40 bits physical, 39 bits virtual vector version : 0.7.1
@@therealchonk Ah okay you might be using the wrong source then! Use arm_000's fork at github.com/arm000/bl808_linux and specifically the irq-forward tree. URL: github.com/arm000/bl808_linux/tree/irq-forward. You'll see opensbi-0.6-808/platform/thead/c910/platform.c has those pins set, plus that tree/branch has heaps of other changes and improvements, namely GPIO support!
Sorry if you do not understand the requirements for Klipper, then I do not think this product is going to be a good option for you. Thank you for watching though!
Problem is there that Ali take too much of a cut I think. Want to email me your address (email on my About page) and I'll see if it's cheaper for me to ship it from here?
Yo, depends what you're doing! Pico W has wifi, so uses power... Not sure the Ox64 wifi is working yet 😅 But no, by default this pulls ~80-90mA idle, Pi Pico W is 40-50mA from memory. May have changed since then - I've not re-tested in ages!
Thank you for this video :). This looks promising :). I prefer a Linux kernel and Linux based with Bash to be true. Maybe you could do a simple programming with some I/O devices as a part 2? :) Sub went your way :). My YT is about the electronics repairs and if I've got any spare time, I try to learn programming simple I/O devices. If I can stick to Linux, that's even better :).
I use PUTTY and FLASHED BL808. system runs but the 2000000 on the CP2102 I use just will not work. Nothing but garbage coming out the serial port. It will suck if I have to rebuild the OS just to change the baud rate to something normal. Even 921600 would be good. But 2000000 is just stupid to me.
I just checked the datasheet and unfortunately the CP2102 only supports up to 1,000,000. I'll ask the devs about what can be changed to get stdout at 921600 and get back to you!
I used the USB/Uart port on the ESP32S3 Devkit-C1 (Uart0TX and Uart0RX- marked TX and RX on the board), set BLDevCube to 2000000 for the bit rate and it worked great. I look forward to WiFi, BLE, etc. support coming soon.
Currently looking for a good board to be brains for autonomous rover using computer vision AI (opencv), Lidar, odometry and ultrasonic sensors. If I need a couple of these boards running ROS that would be fine as the price is awesome.
Hey I'd actually look at the SoEdge instead: pine64.com/product-category/soedge/. That and the baseboard (I have one, future video plans) would kill it, as you've got all the Raspberry Pi headers, 3TOPS of AI power, and a PCIe slot for any expansion or even an NVMe card!
Please don't use baud for serial communications unless there is a good reason for it. Bits per second is what you should use to avoid confusion. Bits per second is exactly what it says. Baud is symbols per second, where the number of bits per symbol varies based on protocol used. It can be 1, 2, 4 or many times higher. 4096 has been common with cable modems, as an example, for several years. UARTs use 1 bit per symbol, so 200K baud is the same as 200Kbps. Way back in the past, telephone modems were initially described as 110 baud, 300 baud, 1200 baud, and 2400 baud. As technology improved it became apparant that using baud was outdated and confusing. After all is a 2400 baud modem able to run at 2400 bps or 9600 bps. Plus modems started offering hardware compression. This lead to having a modem to modem connection speed much less than the modem to computer (UART) speed. With a 9600 bps modem, you might set the UART to 19200 bps, allowing for a maximum 2 to 1 compression ratio. A 14.4kbps modem could have the UART set at 19.2kbps, 38.4kbps or 57.6kbps. What speed you used would depend on the capabilities of the UART, the modem and CPU speed. As modems became faster the UARTS couldn't keep up. When early UARTS were designed 9600 bps was considered high speed. Most computers built up until the early 1990's used an 8250 UART. The first major upgrade was the 16450 UART, which could operate up to 38.4kbps. Then the 16550 UART was released, which included a 16 byte send and 16 byte receive buffer, unfortunately the buffers didn't work. The 16550a UART was released with working buffers and a maximum speed of 115.2kbps; these were needed for the 56k modems and ISDN modems. The final major UART was the 16650 which doubled the size of the buffers to 32 bytes each. Newer models including the 16750 and 16850 (128 byte buffers) were made but much less common. One of the biggest issues during the 1990-2000's era came about because of the UARTS. The 16550a and 16650 were significantly more expensive than the 16450. This meant most computers (and many modems) used the 16450 UART combined with a 14.4k, 28.8k or 56k modem. Many times the UART speed was set at 57.6kbps (or 115.2kbps). After all faster is better and the modems did hardware compression. This lead to dropped packets and retransmissions. This made real transmission speeds drop by a large amount. The people in this situation didn't know that dropping the UART speed to 38.4kbps (and for some unlucky people that had really slow computers and/or 8250 UARTs 19.2kbps may have been faster). Many people in this situation blamed their telephone company, but not all was the telephone company's fault (I'm not saying that they didn't suck). There was the UART issue, there was the issue of ancient telephone lines and equipment, then there was the issue that many modems lied. So many of the El cheapo 28.8k and 57.6k modems would purposelu connect at speeds faster than the phone line could handle. A 57k modem might say CONNECT 38400, but within seconds drop down to 21k (maybe a bit faster or a bit slower). This made users think the speed was much better than it really was, then combined with retransmissions due to an under powered UART and the real speed could be 10kbps or lower. Trying to get someone to speed $30-50 on a new serial board with 16550a/16650 UARTs and $200+ for a good external modem was usually impossible. After all a $250 upgrade to their new $1200-1500 computer that already has an internal 57.6k modem was a hard sell. Trying to explain that their junky 57.6k internal modem can only work at 19.2k was almost as difficult. Even showing how they were only downloading a file at 1KBps before my changes and 1.5KBps to 2.4KBps with the UART set at 19.2kbps wasn't a long lasting change. It always seemed that the next time I came over they'd have the UART set at 56.6k or 115.2k. They'd always say that that is what the ISP, their neighbor, co-worker, friend, or family told them to do for faster speed. Some would even talk about how the modem compressed data. I so rarely won these battles, even when I owned an ISP. Most people couldn't grasp that most data that they cared about were already compressed (zip, JPEG,mp3) and that the ISP used software compression on compressible data. In fact the software compression was better than hardware compression in many cases. This meant that a text file might have a 4x compression. Being limited to 19.2kbps because of the UART would still allow that text file to download at about 9.6KBps. Using hardware compression (probably 2-3x compression) and 115.2kbps UART speed would Max out at 14.4KBps assuming everything works right. Most people at that time rarely had a stable modem connection at 38.4k. Usually it was between 20-30k or 7.5 to 11.2KBps with 3x hardware compression, but only if you had the expensive 16450a/16550 UART. Sorry about my rambling down history's lane.
@Slackware1995 Oh my god that took me down history lane, and also bought back PTSD from doing comms in the 90's / 2000's. All valid information too! Hoping it helps someone out reading this, and I'll definitely refer to it as bits per second instead of baud when referring to computer serial comms going forward. Thank you for that awesome and historic message, it was genuinely excellent. One further pain point to that old-timey stress of fixing things that shouldn't be busted, and nearly related; having to have the modem/sound/video cards in a specific order so that they were allocated the correct IRQs and could function together! From memory, that was the order.
Docker for sure as long as you've got a compiler. Balena you'd need to do some reading. This bloke seem to have a good write-up: carlosedp.medium.com/docker-containers-on-risc-v-architecture-5bc45725624b
I think once the software is stable they'll probably ship versions pre-flashed with a bootloader, and versions barebone. That being said, as long as you have a serial flasher like my CP2104, you can probably knock this out in under 5 mins
@@PlatimaTinkers Yeah that's a fair point right there. I'm still pretty new to esp* land. A board I can drop something that even behaves a bit like an OS on would really bridge the gap for some sensor and logging projects I'm fiddling with.
@@madwilliamflint That's where I think it's getting REALLY blurred due to the RISC ISA and ARM (or similar) processors. You originally had computers and SBCs that ran a full OS, and then MCU's that run custom firmware. Now you've got SBCs the size of MCUs that can run stripped version of Linux like this, alternate Linux's like what STM have produced from their STM32, or Fuzix which is very close for RP2040 chipsets. Further to that you then have MicroPython and Mongoose for ESP32 which is almost a framework turned into an OS for an MCU. It's insane, complex, and awesome I think
@@qbitsday3438 Saw your unedited - I think that's kind of their model, eg community designed, and they just have an ODM that builds and warehouse them for the store? Not 100% sure TBH. Enjoy either way!
It's on my list mate! Got one on my desk. Problem is, it's slightly boring. Repo's appear stale for months. Anything interesting about it you want to see? Cheers
FTDI232 diddnt work for me thought you mentioned it would, although mine is the 232RL and i think others are ok. others reporting the same even at slow speeds. putty console works fine as per your ping/pong demo so the standard ttl protocol should be fine. only an issue when flashing with the "bouffalo dev cube" software. smells like more very intentional dodgy bouffalo behavior (payback for FTDI bricking knockoff Chinese chips ide imagine). in the end got it working with the modified picoprobe provided in the wiki. edit: i should add, for a sanity check after it was flashed and the bouffalo software wasnt needed any more, the linux terminal works fine with the genuine FTDI232RL at 2Mbps again and the picoprobe can go back in the box. the exact one that was knocked off in chena [intentionally misspelled since previous addition got blocked].
Hahaha nice update and thanks for letting us know! With FTDI in general I've had some random hit and misses. I still have two, but I am not a can of them. Glad yours is going now!
Comes out to $19.99 when you add the crazy shipping fee. This comes from China direct? But I am positive that this is well worth $20, it's just that it would be better to go ahead and charge more for the device and less for the shipping. Perception.
Yeah worth it with shipping if you get a few I think. I usually order about $100 of stuff from them every now and then, and just pay $12 Standard Shipping
Yes, shipping is insanely expensive. The unit is US$8, however, the DHL shipping is US$30. Plus tax entering my country plus DHL addition $17.50 Duty handling charge and tax on the top of this fee. No shipping and handling fees are too expensive for me. I rather go to Aliexpress and order others RISC-V board with the same money but with better spec.
@@chipling7367 Yeah you can get the M1s on AliExpress which also uses the BL808 - have you looked at the price of that? Else which country? It looks like I can post an envelope to China from here (Australia) for $3! I am tempted to buy a pile of Ox64's for people that want them in countries with expensive defualt shipping.
@@PlatimaTinkers You guys are lucky. I'm in Canada, if I purchase 1 ox64, I need to pay CAD$72.5, i.e. USD$54. With CAD$39, I can get a Lichee RV Dock Allwinner D1 Development Board with Xuan Tie C906 and 512MByte DRAM. The down side is the board has a larger footprint and shipping take more time to arrive. I know it is not an apple to apple comparison but it is the nearest one I can get to have Linux on RISC-V board.
@@chipling7367 Ouch that hurts! Want me to let you know when I've got stock here? AU-CA shipping for it looks to be about $5 AUD for economy air (15+ days) or $20 for standard which is about 5-15 days.
Correctamundo my good friend. I accidentally said that D0 was dual core though, which I corrected in my description. I'm super curious about using LP for something fun. Right now M0 is just doing interop with D0 as so much of the peripherals route through it.
@@PlatimaTinkers I had a look at this thing a month ago. It seems a lot of progress has been made, as last month, no peripherals, no sd card, nothing was supported, except for the UART, so it was in a state "it boots linux" and that's all there was to see. Wow, things go fast. When I bootled linux last month, it seemed the rv32i core was copying the image from flash to RAM, while the rv64i was delaying, then the rv64i would jump into the kernel.
@@AndreDeLimburger Oooh that is also an interesting way of doing it! I would guess then that they did not have the message bus between the D0 and M0 cores, as the M0 (RV32) is the one connected to the SD card, but of course the D0 does the heavy lifting. Now that there is more interop with IRQ forwarding etc it's running SO much smoother.
@@PlatimaTinkers They didn't implement any intercore communication. But I am under the impression last month was an early proof of concept. No SD card support, all from internal flash.
@@AndreDeLimburger Hey yep they run a 'mailbox' that relays IRQs back and forth. Alex Horner has been working with arm000, pokey and some others on this pretty hard last few months and it was only a few weeks ago this was released working. That is the code uploaded to M0 in the video which you can find here: github.com/arm000/bl808_linux/blob/irq-forward/bl_mcu_sdk_bl808/examples/low_load/main.c. Not it's not in 'main' branch yet. It's not a full implementation of M0 yet either, but enough to access the SD card and some other required features. This is booting from the SD card, as I demonstrated, and works well! Next step is ethernet and/or wifi. WOo
Yeah mate once some more drivers are released, OctoPrint would run fine I think! Could not use the OctoPi image though, as the hardware is quite different.
@MalachiBurke Hey thank you very kindly. Isn't it? I just had a RPi Pico W turn up yesterday, so I can test that if you want! I think one difference there may be the Pico is not running a full multitasking multiuser kernel haha.
@@PlatimaTinkers you're welcome! Yes that's the general idea. ESP32 "modern sleep" averages around 40ma and I expect pico is similar. Way, way less with radios off. As I write this, it hits me 90ma isn't really so bad if all the radios are on ...
@@MalachiBurke Yeah I expect this would be way less if it was sleeping. The code running on M0 is not optimised yet, and just loops passing data to D0, so that can probably be made a bit more power efficient, and without the 802.11 drivers functional yet who knows what the wifi/BLE hardware is doing while idle. If you were to compare this to an ESP32 though, you could either use just M0 or LP, leaving D0 unpowered, and I expected the power usage would be WAY lower. That 90mA is with three cores all executing their own code, and I have no idea what code LP is flashed with out of the box. It might just be looping 'Hello world' to GPIO pins that aren't functionally attached to it any more. Only time will tell, and I'll definitely test again. If you want to go hyper-effective power consumption though you could always wire up an ATtiny85 as a watchdog that turns the Ox64 on and off at required times to do its job, eg if it's reporting periodically. Some bloke got an ESP8266 running for 3 months on 2x AA batteries using a similar method (homecircuits.eu/blog/battery-powered-esp8266-iot-logger/)
@@MalachiBurke Just tested; fresh Ox64 with Boufallo Labs SDK on it 57mA, fresh RPi Pico 6mA, so yeah there is definitely some disparity there, by a whole order of magnitude even, but they are still quite different. The Pi Zero W comparatively comes in at 260mA idle though, so that's half a magnitude again just to catch up to the Ox64.... really hard to compare!
@@PlatimaTinkers sounds about right! I wager the pico numbers are with radio asleep,I never see radios drop below 10mA active in my tests. Pi Zero kinda power hungry!
The ram is the problem why RPI pico and most other micro can't have a Linux port, kernel needs I think 8MB(or 16MB) at least to run. RISC-V is not a powerful instruction set, comparable with attiny, RV32I set has about 50 basic instruction if it doesn't have any of the extensions.
Yeah it's a shame about the RPi Pico, but I think RISC-V is quite powerful and it can be easy to forget sometime that ARM64, Amtel Attiny, RP2040 and BL808 are all RISC processors, just of different generations with different design goals. I am assuming you've got a fair bit of knowledge on it here but for others reading; RISC in general aims to have a _R_educed amount of instructions and allow more complex instructions to be built on those, which ARM does well, as opposed CISC like an Intel x86 or AMD64 CPU which implements everything under the sun as _C_omplex instruction sets, but alas chews up a bucket load more power and in my opinion is actually a tad less flexible for that reason. Most complex instructions are just pre-assembled packages of other instructions anyway, or even complex versions of add/sub/mul/div if you get down to it! You do have a point though that the AVR ISA that Amtel made is pretty damn awesome, but again it is still RISC. Not really comparing apples to apples here when you've got an 8-bit RISC ISA from 1996 designed for embedded systems (Amtel AVR) vs a 64-bit RISC ISA from 2010 designed for modern light weight computing. Or as they all say; it's not how big it is, it's how you use it 🤣🤣
And as Platima said, RISC-V boards with one core outperformed arm based boards with multipe cores in certain tasks, plus R-V is much more flexible and openS
@@PlatimaTinkers I was rewatching some 0x64 videos today and noticed your reply to my post. I tend to miss notifications, so my response is one year late. 😋 When I mentioned the instruction set not being as powerful, I meant that it requires more instructions to perform the same tasks/math compared to some ARM processors that have a more powerful instruction set for executing complex instructions very quickly, that was the tradeoff they made for riscv. For example, multiplying on RISC-V without the M extension would require more cycles due to its simpler instruction set. A 144MHz WHC CH32V203 with the RISC-V core V4B is notably slower than a 120MHz STM32 M4 when handling tasks beyond basic arithmetic, but it can keep up with simple integer math. Having instruction sets that can perform complex math in hardware(often in one instruction) can easily be 10-30 times faster than doing it with less complex instructions, as it requires the CPU to get more involved and run many more cycles. For example, performing math with SIMD instruction sets can be 20 times faster than doing the same math on the same M4 but with general instruction sets, where the CPU needs to be more involved and run many more cycles for the same math. Not all RISC CPUs are made the same; it all depends on how they're implemented. The term 'RISC' doesn't mean much beyond indicating a certain philosophy behind it. RISC-V is designed to minimize costs and handle basic tasks efficiently, riscv is designed to be in your appliances and not to be concutent of desktop cpu's or to compete with ARM higher smart phone market. If you want to push RISC-V beyond its basic capabilities, you'll need custom extensions tailored to RISC-V cores. While everyone can design their own extensions for their RISC-V CPUs, these won't be part of the RISC-V ecosystem and likely won't be open-source or free.
@@PeetHobby Hahaha that's all good mate. Fair reply and some great information there too! Good explanation of the instructions and extensions for new users too. That all being said, I think RISC-V is beginning to compete with ARM in low/mid-market, and likely to be seen more and more in common products like phones etc. Ref Western Digital, XuanTie, Qualcomm, Google, IBM, all being involved. And that's ignoring the more bespoke players like SiFive, Espressif, Lattice, etc. Just my opinion though.
@@zenmaster24 oooooh hahahaha okay got you. Sorry, the sun has not even risen yet - took me a minute. Yep you can, but again it's using BlDevCube, just the Linux CLI version. Ref: wiki.pine64.org/wiki/Ox64#Flash_Ox64
@@khashmeshab In Australia there are small particles in the air called "boganism" that permeate the skin and get into the bloodstream. Most places the concentration is really low, but you'll find suburbs like Rockingham, Frankston, Ipswitch, Kalgoorlie, etc where the concentration is really high. It's pretty good here where I am, but the problem is when it gets quite hot, eg that day was over 33C/92F your pores open up to persperate, and the boganism just soaks in without any resistance. Eventually at the right concentration the urge to "crack a tinny" is no longer something controlled by the conscience and just happens. This is why in hotter areas like Broome you'll find people drink a lot more - hard not to finish work in a 42C/108F day and not crack six tinnies back to back.
@@PlatimaTinkers I thank your other you for the explanation. It seems that you also liked what your other you said. That's so brave of you to be able to sleep in that situation.
@@ahmedmoustafa6829 True! What is your country - I will be shipping some soon from Australia, can check pricing. I expect ~$12 AUD for 1-3 units off the top of my head (it's night time here)
How would you define them as different? The Pico can run Fuzix. I'd say the only reason it cannot run Linux is because there is not as dedicated of a community that'll port it themselves; they all rely on the foundation to provide the software.
@@PlatimaTinkers > I'd say the only reason it cannot run Linux is because there is not as dedicated of a community that'll port it themselves I'm not a professional, but I do not think so. mainly the two m0 cortex cores at 133MHz are too slow and pico only has 264kB's of RAM, compare to ox64's 64MB.
@@TheMlg556 Yeah okay I completely forgot about those points haha. That is definitely not enough RAM, however, it could possibly reside in swap? It'd be painfully slow, but surely possible. The question is if you can load enough kernel with only 256KB to then initialise swap. Not sure TBH. 133MHz is not an issue - that'll still run quite fast.
@@PlatimaTinkers I think the 64bit Core on the 0x64 inc a MMU, FP & Vector ops etc, does put it in more the low-end SBC class vs the ucontroller class of the Pico, though I agree the lines between the classes of devices are getting more blurred these days.
Yeah WTH? I've seen some comment emails, gone to reply, and it was deleted. You didn't delete it? I've checked the "held for review" section but it's not there either! Feel free to post it again, then email me too. If this keeps happening I'll raise a support ticket with TH-cam
@@PlatimaTinkers ive had several removed. i have to breath and try to reserve finger pointing. it was related to a trojan being flagged on the English boufallo website which i think is a massive red flag to any (less than flaming) criticisms.
Very good point my friend, but the Pi Zero is so much more expensive and draws a lot more power. Essentially the Zero has the same core as the other Raspberry Pi's (BCM28 series) but is just more compact. I feel the RP2040 is a closer analogy as they are the same size, same price, etc. I think both sides can definitely be argued though!
Bugger. 1) How far did you get? 2) Did you use 2,000,000 baud? 3) Which release in the repo did you use? Had a few repo builds fail from what I know, so I was using 0.0.2 (github.com/openbouffalo/buildroot_bouffalo/releases/tag/v0.0.2) but I think 1.0.0 should be solid too!
can you make a linux board run on a fart.... ? sounds like a good project for small pc's like this, , maybe not for farts but, body heat , body movment, other small electricity generating "operations"
@@PlatimaTinkers i want a iron man helmet with wifi and googles with screen, powered by farts.... not too many people walk around with sterling engines in they'r pockets but. farts we have lots of. static electricity is in air all around us all the time. we move our feet and use \ can generate, "a lot" of energy like this i think.
@@QuadDerrick The most bogan Aussie iron man, cold can of beer in hand haha. I mean yeah asses are essentially small combustion engines when used correctly... right? That's science for you
Yep sorry definitely has I2S - that table was not quite filled out with every detail. Here's the functional block diagram as a reference for you: wiki.pine64.org/images/thumb/d/de/BL808_Block_Diagram.jpg/600px-BL808_Block_Diagram.jpg
@@PlatimaTinkers Cool, I've got a ton of boards sitting around already, but I'll have to check these out as well. Edit: How hard is it to add device tree overlays for the GPIO devices when you're running a full Linux kernel?
@@butsukete1806 Hah yeah same here, SOCs building up like a bad itch, but these are so far my favs and SUPER cost effective compared to even an ESP32 IMHO. GPIO is already working my friend. I just did not demo it in this video as it was long enough! Pt 2 coming in following weeks.
Sounds like a new contender then. Right now my gotos are ESP32 for wireless and Pico for anything else, really like the PIO feature. Looking forward to your next video.
@@butsukete1806 Pretty much what I've been doing mate; 3x RPi4 running all my docker containers for local services such as control, monitoring, alerting, then some Pi Zero's for GPIO control eg retic etc, and ESP32's for endpoints such as lights, switches, etc. Cheers
It is for a Linux kernel, let alone one that isn't yet optimised! Consider the ESP8266 which is a tiny MCU that can't even run a first class (multi-user, multi-task) OS such as this, is not dealing with SD storage, and has an average current consumption of 70mA from what I've found. So yeah, it's not battery capable, but it's still the best I've seen for something with an OS! Leaving Hello World on it instead would have been < 10mA from what I recall. Will test today and advise!
@@helson-vlog Ah yep looks like unfortunately it falls under export restrictions :( You'll need to try AliExpress perhaps - the SiSpeed M1s Dock is quite similar and also has a BL808 chip
Platima Cooks 1 second ago Huuuuuu. Maybe reach out to their team and see if they can have multiple shipping options? Else it might be cheaper for me to order it here and ship it to you haha
Well we need to wait for network drivers to be finished, but ethernet is close! Webserver would not be hard; I expect Webmin would run without issue if you want a config UI, else nginx would fly on this. Someone pretty much sums it up here: www.reddit.com/r/RISCV/comments/w2adax/nginx_php81_simple_web_server_on_riscv_visionfive/
It's got wifi built in mate, just need to attach an antenna and get the drivers going! I am tempted to use an ESP32 as serial wifi for remote debugging though!
Yeah hence I say both - a lot of the crowd I associate with say RISC-V, so I'm used to that, but I correct myself to RISC-Five for video as I did in this haha.
The pi pico is in no way almost a full fledged computer, it is just an MCU. This board is different though since it has a RV64 processor, a RV32 processor and another RV32 processor that is apparently used for WiFi. This chip also has a built in NPU. It is very different from the pi pico.
@conorstewart2214 You are absolutely right my friend!
With this one there is the RV64 D0 core, which does most of the heavy lifting, then there is an RV32 M0 core which does most of the GPIO, wifi, ethernet, etc, but the code running on this is primarily an IRQ message bus so that D0 can access it, and then there is the LP core which is just a RV32 160MHz but this is currently unused and mostly undocumented. Bouffalo Labs are working on releasing the LP SDK, wifi spec, and a few other things, but it's all currently under NDA until complete. Hopefully not long!
If it's Turing complete, it's good enough to be considered a full fledged computer! /s
The PDP-11 ran UNIX v6, programmed in C. Its 16-bit single-core CPU clocked between 500 kHz to 1.25 MHz, supporting a maximum memory size of 4 MB. Hard drives varied from several megabytes to tens of megabytes, spinning at speeds of 2400 to 3600 RPM. To match the processing power and efficiency of a single RP2040, you'd require a thousand PDP-11 units or more. The processing power of an RP2040 would have set you back $10 million in 1975 to start. At MIT, they teach xv6, a rewrite of the original Unix 6 code, which they run on tiny RISC-V microcontrollers. The RP2040 possesses the processing power necessary to drive groundbreaking advancements in weather forecasting, space exploration, molecular modeling, astrophysics, and nuclear physics. The problem isn't with the hardware, but lack of programming skils.
@@sam-e8c2f classic skill issue
Once the WiFi is working, this will be really interesting. MicroPython is great on Pico W, but it is not a full OS. Really like the full OS aspect.
There’s always FreeRTOS for pico, and recently a full on VGA boot to basic retro style computer as well using the rp2040
@JibunnoKage-cj2kz @tylerdean980 Seconded my friend!
@@tylerdean980 True, but this device at least for me, seems more flexible than most of the ESP or RP2040 form factors I have seen.
The benefit of a full OS, in my mind, is the relative ease of reprogramming it. With ESP32 and Pico W, unless you do something clever like the UI Flow system from M5stack, you need to flash the ROM for every iteration. But if you get the firmware to fulfill all your needs for a project, then all that flexibility will not be useful until you scrap the project and reclaim the parts.
I’ve been hoping for a video like this! I got one too but haven’t gotten to okay around with it, so I didn’t know what to expect.
Hey glad to hear! Feel free to ask anything that comes to mind!
Glad I stumbled across your channel! You explain things very well!
Hey you're very welcome! I don't think so, but I am trying to constantly improve, and I'm glad you think so! Cheers
Aah oops wrong acct. Right message at least haha.
On the store's accessories page they have stacking headers which might cover less of the pin labels (haven't got any yet as waiting for software support to mature).
Yeah I've got a pile of stackable headers too, just didn't consider using them 😅
pretty cool device! Hopefully they flesh out a bit more documentation so there's less hunting to get what needs done. I'm in the US though, and our picos are $4/$6 for regular and wirele4ss respectively, so these are a bit pricier than that. that being said, pine64 is definitely an organization worth investing in as far as open source goes.
Pico's are that cheap there? I was seeing them $8 US, which is about $11 AU. At least your shipping is cheaper 😅
Either way yeah some more English doco would be good hah.
Where did you find them that cheap?
@@ArtemisKitty I bought a handful at microcenter last year. Also, check vilros for a shipping alternative
@@familypve4029 Ah, thanks!
@@ArtemisKitty pine64.com/product/128mb-ox64-sbc-available-on-december-2-2022/
Looks like soon (once EthX and camera are driven) this will be the perfect node for a chain of low-power and affordable ethernet security cameras.
Can anyone assess whether they would have sufficient compute to do local image processing - like face or human detection?
@Man0f5cience Oh absolutely! They have a 0.1TOPS NPU built in which I expect would handle that perfectly fine.
Maybe but the Ingenic-based cameras are like $20 USD running full Linux 96MB+ RAM, 1GHz, with SD card, hardware video encoding, WiFi, and you can add USB Ethernet/PoE. Really hard to beat that. The only caveat is you have to hack the camera to remove the default Linux (spyware) and install your own firmware.
@@_droid oh that sounds tasty - can you send me a link? I want to check out these cameras!
Full-fledged IPCCTV security cameras with NPU image processing, in an Arduino Pro Micro form factor, with 2.5W power draw.
What a time to be alive.
@@amateurprogrammer25 want want want want want.
I was on the fence re: the Ox as read flashing Linux was super complicated but your video convinced me to give it a go and I await my order and look forward to following this guide so cheers!
Glad to hear! Good luck on the backorders haha. I keep hitting refresh, but have also emailed their wholesale team about warehousing some here in AU.
If you get stuck at all feel free to reach out!
@@PlatimaTinkers So I managed to get Linux flashed using a Pico as didn't have CP2104 handy and its awesome to see it boot up so fast. The process was fairly easy and I hope to see development come along as the thought of using it for Home Automation with Zigbee is exciting. I agree its cheaper than the Sipeed M1s Dock but I didn't pay too much for mine on Aliexpress as having a camera and screen makes up for the added cost... 👍
@@Razor_Burn That's really great too hear!
Amazing device! I can imagine using this SCB to make a portable SDR that can process much larger bandwidth than those made by ESP32 and STM32H4. (H7 I am not sure but H7 is crazily expensive).
Yeah quite possibly - the high MHZ and apparently wide band ADC would certainly do the trick!
I've never used a H7, all my STM32's are F series. But yeah this is about 1/10th the cost of a H7 devboard it seem haha.
Could you please send a link to such SDR? Very interesting.
@@Danil-intl He's talking about making one :P Or if you meant the H7 then here's an example devboard for you au.mouser.com/ProductDetail/STMicroelectronics/NUCLEO-H723ZG?qs=zW32dvEIR3v%252BApBMtkRmgg%3D%3D
Just one tweak, when I was flashing the d0/m0 lowload binaries I had both at Block 0 as opposed to 0 and 1
Yeah I think that comes down to either the exact image, or the hardware revision!
When I did the update video more recently, I think they were both Block 0. From what I understand, this is because they managed to move more binaries into the image, rather than it being on SPI flash, so can be updated by the OS etc.
Good to mention though! Cheers
"This is basically running on a fart" - Possibly the most Aussie thing every said.
Haha cheers!
Nice! Thanks for sharing this! I'll probably be picking up a few to play around with. It's cool that they come with ZigBee, they should be great for automation.
Hey mate you're very welcome. I'd definitely recommend it, and cannot wait till the ZB drivers are done - I've actually never used it 🤣🤣
Excellent. Liked and subscribed. Looking forward to more of your stuff : )
Hey thanks mate! There is certainly more coming, but life has just taken a bit of priority recently! Cheers
Thanks for the video, really interesting.
What is the current draw (I assume at 5V) running full Linux?
Hey mate sorry just on the road, but glad you liked it. Sorry I don't have that data on me now, but I think I checked it in a shorts I did? Else I can measure it when I get home. I recall it being around 30mA but that could be completely wrong or another product!
Now what I _really_ want to do is run Rust on this thing bare-metal.
64MB of RAM _all to myself_ and whatever protocols I can bit bang from however-fast-that-thing's-GPIO-is without an OS in my way sounds really fun.
Saw your comment at work. Googled it - its doable!
It looks like RV64GCV is about 100% complete within LLVM, and the Bouffalo Labs SDK has everything you'd need if you can interop with C libraries or link to them as OBJs. Ref github.com/bouffalolab/bl_mcu_sdk/tree/master/examples
Would you be able to create a mechanical keyboard configurator for this Ox64 using Rust?
There isn't Rust nor Risc-V sbcs available for that use.
@@vicmac3513 could you elaborate a bit? I am not sure what you mean "mechanical keyboard configurator"?
@@PlatimaTinkers Similar configuration app like System76 Launch has. Or QMK app. But for this Ox64 sbc and written in Rust.
Sorry for being misunderstandable.
@@vicmac3513 Oh wow interesting - that is all new to me. Thanks for the info and showing me something new! Cheers
Nice video. A few of these would be really nice for building up a home automation system.
Ain't wrong! The ZigBee is exactly fitting for that use case, but you could stick a LoRa radio on there too.
there is probably a pine64 wiki for this item but it needs a volunteer to write up some documentation. I sent you a message in the red dit post for how to join the pine live chat on this very item since I can't figure out how to be invisible to the YT delete bot.
Hahah yeah that's super annoying, am going to check out Reddit shortly. Cheers!
Amazing tiny device! I can't believe it could be possible to run actual Linux kernel on a board with the Arduino Nano form factor. Is Zigbee embedded version 2 or 3?
Yeah I've reviewed a few of these now, and they're all pretty damn good!
The 803.11/802.15.4 (Wifi/ZigBee) implementation is not complete, but it is working in the upstream repo (bl808) in bits and bobs, and currently being merged into OpenBouffalo which this uses. The ZigBee standard is implemented at the software layer though, so I'd expect V3 to be supported IE meshing.
A good choice for robotics and automation.
Absolutely, especially when the NPU module and CSI connectivity is functional!
This thing seems quite interesting. I wonder if this thing is powerful enough to build a remote RTL-SDR receiver or at least do some direct sampling stuff with a RTL2832U.
Hey mate sorry nearly missed this comment! Yeah I would assume so, but I honestly don't know enough about SDR!
Nice one! Those could be super handy.
Yeah once they get some networking going it'll be amazing. That'll be Pt 2 for sure!
this board looks VERY interesting, but I think I'll wait for some proper documentation, and to see how they do expansions, audio in particular, because if that 2 ADC 1 DAC @ 8-192kHz claim is true, then I have some nice use-case scenarios for this little fella... do post more videos, this looks promising...
Yeah that is a VERY large range. I'll have to look into the audio and see if the GPIO functions are available to even enable that mode yet.
@@PlatimaTinkers That's one of the reasons I got some of these boards too, outside of the Teensy there are not many boards for audio applications (synthesizers, samplers etc) that have decent DACs and ADC's and USB host (eg MIDI) support, though the RP2040's are getting there slowly now.
And thanks for posting this video, getting the 0x64 setup is hard work compared to other boards so your video really helped my out! Thanks mate!
@@mksln Hey you're more than welcome and I am glad it helped!
I cannot wait to see how well the DAC performs once complete, as apparently its capabilities are pretty decent!
Ok, here's a question: with Linux on there, can it act as a USB host? Does it have access to the USB with that kind of control? That's the main issue I have with the PICO, that it does not support USB host mode.
Hey yeah if you refer to the datasheet, the USB 2.0 implementation is for Host and Device mode. The RM PDF then expands on that in section 25.1.
It's just up to the drivers to be finished, which is making some great progress both with the open source community, and with Bouffalo Labs team.
Great video, very well explained!
Thank you very kindly, and you're welcome!
For that money it's incredible ! Also having linux kernel and prompt run on just 9MB !
I know right!
The Linux Kernel is actually hilariously efficient if you strip it down for your hardware. It's just such a nightmare to do, and it completely ruins portability, so nobody bothers.
@@KiraSlith Yeah so true, but I think we just forget it with modern apps these days. Like how is Balena Etcher a 213MB application that needs 100MB of RAM? God damn Electron framework that's how. I was so very happy the other week when I saw the WinDirStat installed size was 733KB - that's how applications should be made!
The RISCV architecture has always interested me. Good to more and more devices on the market. Will definitely grab a couple. Also, is that a Cooper Pale?
Yeah there is a LOT of good RISC-V stuff coming out, and I'm even making my own 😅 If you're in AU I've got some local stock; shop.plati.ma
Damn right it's a Coopers Pale mate 🤘Good spotting, I just think I was using a Bush Chook stubbie holder hah.
I'd completely missed this board's existence! Thank you for fixing that.
Hah you're very welcome my friend!
There is the sipeed M1S Dock that uses the same chip and has interfaces for a lcd and camera.
@@conorstewart2214 ain't wrong re the chip, but that's a slightly different beast with what I'd call a different use case. Thanks for sharing though!
Is it simple as us swapping the Flash chip for another? If so what limits might I hit when it comes to size of storage chip in this form factor?
Sorry I don't fully understand your question. I show how to flash it in this video. They come in 16Mb (2MB) and 128Mb (8MB) flash versions.
Question: I had a crash with M0S board (Boufallo's BL616 single core RV32).
* They require custom GCC10,
* Zigbee is walled by NDA,
* Flash programming is via a custom, unintuitive software
* a vast majority of How-tos are in Chinese.
How does Ox64/C906 stack against that?
There is definitely way more available around BL808/C906 due to the Ox64, but I think BL just need a bit of time. They are a small team, creating something awesome, and not all things happen overnight.
That being said, given the popularity I don't think we're going to be waiting too much longer thankfully!
I didn't even finish the video before I started looking for one.
Hahah awesome!
There is another board with the same chip, it is the sipeed M1S dock and it has a LCD and camera interface as well as two usb C ports, it also allows you to flash the chip over USB as it has a chip or microcontroller built in to handle that, it may be more useful for some people than this board. Since it uses the same chip it should just be programmed the same.
Oh yeah good thought - I did forget to mention that this will be flash-able by USB eventually. As this is an open-source and community-driven project compared to the M1s, the development lifecycle is just a tad different. But that is also reflected in the awesome price tag.
@@PlatimaTinkers the M1S isn’t expensive, especially considering how much more difficult and expensive it is to get pine products in the UK and Europe. You can get the M1S as a bare module for embedding in your own designs for £6.08 or the dock for £9.40, the full kit with a usb cable, header pins, camera and lcd with the M1S dock is only £17.33. So the pine 0x64 doesn’t have that much of a price advantage on it especially if you go with just the dock board itself with no extras, like the pine 0x64 comes. There is no reason that most of the developments for the pine 0x64 wouldn’t apply to the M1S dock and the M1S already has working examples for the lcd and camera.
The main advantage for me anyway is how easy and cheap it is to get compared to the pine 0x64.
@@conorstewart2214 makes sense re the region. Probably varies quite a lot! For me if I get 3x Ox64 they cost $12 AUD ea inc shipping. For the M1s module the best I could find is $20.93 AUD ea inc shipping.
I am working with Pine64 on warehousing some here at one of my locations so we can include some cheaper shipping options, but not sure how long that will take.
The ease of use is definitely a huge advantage, but I think if we give the Pine64 team some time, they'll definitely get there. Thanks for the info!
Cracks tinny in the middle of recording….
Subscribed 👍
Hah yeah mate. Cheers
It's not "Risk Vee" it's "Risk Five"
Yeah I'm aware of that, but I feel 'five' is longer to say, plus they refer to the ISA as RV64 so just kind of follows. Who knows, maybe by pure public influence I could change that 🤣
WOW, the ZigBee part is super exciting..we got a new player beside xtensa!
I cannot wait to see this in commercial products!
Wow. Impressive. Both the result, and path to it. Alas too difficult for me with all those cables and images. I can use Balena, and that's about it.
Hah thanks yeah that's where I used to be, but persistence and only wanting to pay $8 pushed me a bit further 😅
@@PlatimaTinkers The stuff you burn ... that is to the flash memory on the Ox64? And then you "just" let it boot from Linux on the SD-card? If so, could the supplier take care of the flashing, so that buyers can just write a Linux to an SD card, and ... voila?
@@blablamannetje sure in theory. That might be a good opportunity for a value-added reseller to add a couple of bucks to the price.
@@blablamannetje Hey yeah so this is actually quite an interesting one! Group 'M0' is the 32bit processor, and D0 is the 64-bit processor, both of which have a tiny bit of on-chip zero-delay SRAM. It then has the 8-pin external Winbond xSPI chip. The datasheet (files.pine64.org/doc/datasheet/ox64/BL808_DS_en_1.1(open).pdf) has all of the base addresses for all of these. I also believe there is 'LP' which is a lower power E902 32-bit core but I cannot find anything about that in the BL808 datasheet!
While not immediately clear there other than in some of the function maps, if you have a read of the code for these images we're flashing with (github.com/openbouffalo/OBLFR/tree/master/apps) you can see both boot and handle different aspects of the chip. D0 though is what does the heavy lifting, and you can see in its main.c that it loads the DTB (Device Tree Binary that the kernel uses to know about the hardware under it), OpenSBI (supervisor binary interface - RISC-V middleware that executes the kernel), and then the Kernel (which is actually the Kernel and those last two compressed into a single binary).
That single Kernel binary is what we are flashing on the IOT tab, which is the SPI memory, and includes the drivers and boot args to talk to the SD card. So that means it goes Power On -> D0 and M0 start executing -> D0 loads the kernel et al from flash -> Kernel loads the OS itself from SD card.
Note I believe the initial GPIO14/15 we used are connected to the C906 32-bit core, and then 16/17 are connected to the E907 64-bit core. I may have also gotten piles of this wrong!
Nice! Thanks for this. I have a couple myself and eager to give them a go.
You're very welcome and that's great! Please do let me know if you get anything else running on them, eg ESPHome.
@@PlatimaTinkers I just ordered the CP2104. As soon as I get it I will give it a try. I've been trying to translate the manuals that are in Chinese with no luck. I did finally get the DevCube running but need the CP2104 to communicate. Which img did you use? the sdcard-pine64_0x64_defconfig or sdcard-pine64_0x64_full_defconfig?
@@christianskovly8831 Hey yeah I used the full image. Honestly not sure the difference, but I can only assume the smaller one is for the 2MB SPI flash board!
@@platima You live a charmed life. I've been banging on this lil thing for a week and haven't been able to get it all the way. I've made it through the flashing but now I'm trying to get it to boot the linux sdcard. What are the pins that I need to change my CP2104 connections to? I'm I supposed to use GPIO22/MOSI/MISO (physical pin 15) and GPIO25/MISO/MOSI (Physical pin 16)?
@@christianskovly8831 Hey this can change depending on what you're flashing it with. Are you using the same binaries I did? If so flash it using GPIO 14/15 at 2 million baud, then after flashing change it to GPIO 16/17 for boot. Note that these are pin numbers 1/2 and 32/31 respectively! Refs: github.com/openbouffalo/buildroot_bouffalo
Didn't realise I replied with the wrong account last time haha
Seems like that fills a gap between a RP2040 and a Pi zero I didn't even realise was there.. might snag me a couple, already got some ideas on what that could do.
Yeah I'd say! Any ideas you intend on sharing? :P
The sipeed M1S dock is another board that uses the same chip, you can get one with a camera, LCD screen and case.
@@conorstewart2214 Yeah was looking at the M1s Dock, but it's a bit pricey comparatively. This supports LCD and camera, but the MIPS CSI interface and USB protocols are not quite complete yet. The community developers have been working with Bouffalo Labs on getting this across, and it's very close!
Awesome video!
Can it handle Scratch app with some screen attached?
I really do not see why not! Once more of the drivers are completed you could use an e-ink display, or possibly even VGA or DVI with a custom header for it.
"Package cannot be shipped to your country due to logistical reasons." Is there other way to get from other stores or without using some random dropshipping services?
Really? Dang that's a pain.
What country? I might be able to ship you one
Great overview, may have to pick your brain when I get 1.
Absolutely not a problem! Enjoy
I own something similar. It's the Milk V Duo
Ooooh, like this one? th-cam.com/video/YqUtGk0DHbQ/w-d-xo.html 😋 (yeah it's way better hey haha)
Finally! A non-bloated Linux installation for me..
@devrim-oguz Hah yep!
Really good stuff, I'm getting a couple for myself. I had been using OpenWRT on Pi Zero W's for lean Linux apps where a console is not needed and I can use SSH to access. It's not just for access points, with Opkg I can get a lot of standard tools, and it has worked really well since it doesn't rewrite flash and thus no wear. But this is even tighter on resources. Exciting.
@jmzji Interesting! I've never thought of using OpenWRT in a non-networking way. Really good to know!
could anyone confirm if the USB MIDI host mode is functional? just pluggin a USB controller/keyboard
Not that I know of yet. You'd need to go to wiki.pine64.org/wiki/Ox64 and have a look at the different repos.
Just had 4 of these show up, keen to see everything I can do with it, both on the Linux side and running code on bare metal.
Let me know what bare metal code you end up doing, I'd be super keen to do a bit myself too.
@@PlatimaTinkers will do! I've been looking at the official and community repo's, there are quite a few options under development. Hopefully a chip this powerful will get some good development support.
@@BrodieFairhall I think it will! It's less than a year old and is going this hard. Compare to RP2040 which is less powerful and even older, and you see a faster adoption rate IMHO.
Jump in and contribute would ya! Hah
What's nice is from my understanding, you don't even need to use Linux. You can write your own programs on bare metal.
So very true, the SDK has example code for the two main cores!
According to the documentation, after flashing, pins IO5 (RX) and IO8 (TX) are UART3.
But GPIO5 and GPIO8 dont't exist and pin is RXD pin 8 is GND.
Which pins did you connect?
Hey yeah it can be confusing; there are 3 cores and their UARTs are connected to different default pins. For flashing the D0 and M0 cores plus SPI you want GPIOs 14 and 15, then once booted the output is on GPIO 16 and 17.
@@PlatimaTinkers Well I found out, that I had to apply a random patch to the firmware, and now it works on 16 & 17. Thanks.
@@therealchonk Very odd! Can I ask what patch?
@@PlatimaTinkers In the bl808_linux project there is a `patch/m1sdock/m1sdock_uart_pin_def.patch` and I had to do `patch -Np1 < patch/m1sdock/m1sdock_uart_pin_def.patch` to apply it.
Btw what do you get, if you `cat /proc/cpuinfo`. Mine says it's a C910, not a C906. I think it's a bug.
Edit: to be precise:
processor : 0
hart : 0
isa : rv64imafdcvsu
mmu : sv39
model name : T-HEAD C910
freq : 1.2GHz
icache : 64kB
dcache : 64kB
l2cache : 2MB
tlb : 1024 4-ways
cache line : 64Bytes
address sizes : 40 bits physical, 39 bits virtual
vector version : 0.7.1
@@therealchonk Ah okay you might be using the wrong source then! Use arm_000's fork at github.com/arm000/bl808_linux and specifically the irq-forward tree. URL: github.com/arm000/bl808_linux/tree/irq-forward. You'll see opensbi-0.6-808/platform/thead/c910/platform.c has those pins set, plus that tree/branch has heaps of other changes and improvements, namely GPIO support!
Can this run klipper and be used on a 3d printer?
Sorry if you do not understand the requirements for Klipper, then I do not think this product is going to be a good option for you. Thank you for watching though!
The price of shipping is stopping me from getting one. I really with they make Aliexpress shop or something like it.
Problem is there that Ali take too much of a cut I think.
Want to email me your address (email on my About page) and I'll see if it's cheaper for me to ship it from here?
Wait, did you say that this Ox64 uses less power than the RPi Pico W?
Yo, depends what you're doing!
Pico W has wifi, so uses power... Not sure the Ox64 wifi is working yet 😅
But no, by default this pulls ~80-90mA idle, Pi Pico W is 40-50mA from memory.
May have changed since then - I've not re-tested in ages!
Great stuff! Thanks for sharing.
You're very welcome, thanks for the feedback!
Thank you for this video :). This looks promising :). I prefer a Linux kernel and Linux based with Bash to be true.
Maybe you could do a simple programming with some I/O devices as a part 2? :)
Sub went your way :). My YT is about the electronics repairs and if I've got any spare time, I try to learn programming simple I/O devices. If I can stick to Linux, that's even better :).
That is literally already the plan! Hah. Glad you enjoyed it
I use PUTTY and FLASHED BL808. system runs but the 2000000 on the CP2102 I use just will not work. Nothing but garbage coming out the serial port. It will suck if I have to rebuild the OS just to change the baud rate to something normal. Even 921600 would be good. But 2000000 is just stupid to me.
I just checked the datasheet and unfortunately the CP2102 only supports up to 1,000,000.
I'll ask the devs about what can be changed to get stdout at 921600 and get back to you!
Hey so there are three bits of code to modify to make it work at
I used the USB/Uart port on the ESP32S3 Devkit-C1 (Uart0TX and Uart0RX- marked TX and RX on the board), set BLDevCube to 2000000 for the bit rate and it worked great. I look forward to WiFi, BLE, etc. support coming soon.
@@billwinston5146 Oh excellent! Using another MCU as a flasher is always a great backup, and bit of a pro move!
Could you do a find in /sys/class/gpio ?
Yep mate that'll be in my next video!
Nice video of nice hardware.
Thank you kindly!
I am really interesed in the ZigBee side of things!
Likewise brother!
Currently looking for a good board to be brains for autonomous rover using computer vision AI (opencv), Lidar, odometry and ultrasonic sensors. If I need a couple of these boards running ROS that would be fine as the price is awesome.
Hey I'd actually look at the SoEdge instead: pine64.com/product-category/soedge/. That and the baseboard (I have one, future video plans) would kill it, as you've got all the Raspberry Pi headers, 3TOPS of AI power, and a PCIe slot for any expansion or even an NVMe card!
Please don't use baud for serial communications unless there is a good reason for it. Bits per second is what you should use to avoid confusion.
Bits per second is exactly what it says. Baud is symbols per second, where the number of bits per symbol varies based on protocol used. It can be 1, 2, 4 or many times higher. 4096 has been common with cable modems, as an example, for several years.
UARTs use 1 bit per symbol, so 200K baud is the same as 200Kbps.
Way back in the past, telephone modems were initially described as 110 baud, 300 baud, 1200 baud, and 2400 baud. As technology improved it became apparant that using baud was outdated and confusing.
After all is a 2400 baud modem able to run at 2400 bps or 9600 bps.
Plus modems started offering hardware compression. This lead to having a modem to modem connection speed much less than the modem to computer (UART) speed.
With a 9600 bps modem, you might set the UART to 19200 bps, allowing for a maximum 2 to 1 compression ratio. A 14.4kbps modem could have the UART set at 19.2kbps, 38.4kbps or 57.6kbps. What speed you used would depend on the capabilities of the UART, the modem and CPU speed.
As modems became faster the UARTS couldn't keep up. When early UARTS were designed 9600 bps was considered high speed. Most computers built up until the early 1990's used an 8250 UART.
The first major upgrade was the 16450 UART, which could operate up to 38.4kbps. Then the 16550 UART was released, which included a 16 byte send and 16 byte receive buffer, unfortunately the buffers didn't work.
The 16550a UART was released with working buffers and a maximum speed of 115.2kbps; these were needed for the 56k modems and ISDN modems.
The final major UART was the 16650 which doubled the size of the buffers to 32 bytes each. Newer models including the 16750 and 16850 (128 byte buffers) were made but much less common.
One of the biggest issues during the 1990-2000's era came about because of the UARTS. The 16550a and 16650 were significantly more expensive than the 16450. This meant most computers (and many modems) used the 16450 UART combined with a 14.4k, 28.8k or 56k modem. Many times the UART speed was set at 57.6kbps (or 115.2kbps). After all faster is better and the modems did hardware compression. This lead to dropped packets and retransmissions. This made real transmission speeds drop by a large amount. The people in this situation didn't know that dropping the UART speed to 38.4kbps (and for some unlucky people that had really slow computers and/or 8250 UARTs 19.2kbps may have been faster).
Many people in this situation blamed their telephone company, but not all was the telephone company's fault (I'm not saying that they didn't suck).
There was the UART issue, there was the issue of ancient telephone lines and equipment, then there was the issue that many modems lied. So many of the El cheapo 28.8k and 57.6k modems would purposelu connect at speeds faster than the phone line could handle. A 57k modem might say CONNECT 38400, but within seconds drop down to 21k (maybe a bit faster or a bit slower).
This made users think the speed was much better than it really was, then combined with retransmissions due to an under powered UART and the real speed could be 10kbps or lower.
Trying to get someone to speed $30-50 on a new serial board with 16550a/16650 UARTs and $200+ for a good external modem was usually impossible. After all a $250 upgrade to their new $1200-1500 computer that already has an internal 57.6k modem was a hard sell.
Trying to explain that their junky 57.6k internal modem can only work at 19.2k was almost as difficult. Even showing how they were only downloading a file at 1KBps before my changes and 1.5KBps to 2.4KBps with the UART set at 19.2kbps wasn't a long lasting change.
It always seemed that the next time I came over they'd have the UART set at 56.6k or 115.2k.
They'd always say that that is what the ISP, their neighbor, co-worker, friend, or family told them to do for faster speed. Some would even talk about how the modem compressed data.
I so rarely won these battles, even when I owned an ISP. Most people couldn't grasp that most data that they cared about were already compressed (zip, JPEG,mp3) and that the ISP used software compression on compressible data. In fact the software compression was better than hardware compression in many cases.
This meant that a text file might have a 4x compression. Being limited to 19.2kbps because of the UART would still allow that text file to download at about 9.6KBps. Using hardware compression (probably 2-3x compression) and 115.2kbps UART speed would Max out at 14.4KBps assuming everything works right. Most people at that time rarely had a stable modem connection at 38.4k. Usually it was between 20-30k or 7.5 to 11.2KBps with 3x hardware compression, but only if you had the expensive 16450a/16550 UART.
Sorry about my rambling down history's lane.
@Slackware1995 Oh my god that took me down history lane, and also bought back PTSD from doing comms in the 90's / 2000's. All valid information too! Hoping it helps someone out reading this, and I'll definitely refer to it as bits per second instead of baud when referring to computer serial comms going forward.
Thank you for that awesome and historic message, it was genuinely excellent.
One further pain point to that old-timey stress of fixing things that shouldn't be busted, and nearly related; having to have the modem/sound/video cards in a specific order so that they were allocated the correct IRQs and could function together! From memory, that was the order.
Very interesting
That's cool, but where can I buy that SBC? It is out of stock!
Yeah just have to wait unfortunately - I usually check weekly, just leaving the tab open in my browser. Good luck!
@@PlatimaTinkers as I don't want to wait, I ordered a 16 Mb version, and will replace Flash chip by myself)
@@kotnitro2076 Just be aware no SD card reader! You can possible solder one on though. Enjoy!
とてもわかりやすかった
Unlike your comment for an English speaker :P (Google translate to the rescue!). And thank you :)
Likely not, but could belena / docker run on this?
Docker for sure as long as you've got a compiler. Balena you'd need to do some reading. This bloke seem to have a good write-up: carlosedp.medium.com/docker-containers-on-risc-v-architecture-5bc45725624b
Okay this is a really cool piece of kit. But the amount of fiddling required to program it seems to be a bit much.
I think once the software is stable they'll probably ship versions pre-flashed with a bootloader, and versions barebone.
That being said, as long as you have a serial flasher like my CP2104, you can probably knock this out in under 5 mins
@@PlatimaTinkers Yeah that's a fair point right there. I'm still pretty new to esp* land. A board I can drop something that even behaves a bit like an OS on would really bridge the gap for some sensor and logging projects I'm fiddling with.
@@madwilliamflint That's where I think it's getting REALLY blurred due to the RISC ISA and ARM (or similar) processors. You originally had computers and SBCs that ran a full OS, and then MCU's that run custom firmware. Now you've got SBCs the size of MCUs that can run stripped version of Linux like this, alternate Linux's like what STM have produced from their STM32, or Fuzix which is very close for RP2040 chipsets. Further to that you then have MicroPython and Mongoose for ESP32 which is almost a framework turned into an OS for an MCU. It's insane, complex, and awesome I think
my 4 pieces arriving today !
Wooo! And nice username!
@@PlatimaTinkers Thank you , !
@@PlatimaTinkers Hi igot all 4 pieces FedEx
@@qbitsday3438 Woooo 🎉
@@qbitsday3438 Saw your unedited - I think that's kind of their model, eg community designed, and they just have an ODM that builds and warehouse them for the store? Not 100% sure TBH. Enjoy either way!
Can you also review sipeed m1s dock
It's on my list mate! Got one on my desk. Problem is, it's slightly boring. Repo's appear stale for months. Anything interesting about it you want to see? Cheers
FTDI232 diddnt work for me thought you mentioned it would, although mine is the 232RL and i think others are ok. others reporting the same even at slow speeds. putty console works fine as per your ping/pong demo so the standard ttl protocol should be fine. only an issue when flashing with the "bouffalo dev cube" software. smells like more very intentional dodgy bouffalo behavior (payback for FTDI bricking knockoff Chinese chips ide imagine).
in the end got it working with the modified picoprobe provided in the wiki.
edit: i should add, for a sanity check after it was flashed and the bouffalo software wasnt needed any more, the linux terminal works fine with the genuine FTDI232RL at 2Mbps again and the picoprobe can go back in the box. the exact one that was knocked off in chena [intentionally misspelled since previous addition got blocked].
Hahaha nice update and thanks for letting us know!
With FTDI in general I've had some random hit and misses. I still have two, but I am not a can of them.
Glad yours is going now!
looks great for a ginormous nerdy linux smartwatch
Hahah do it!
does it have a phy to connect to ethernet?
There is a module coming that some devs are currently testing!
Comes out to $19.99 when you add the crazy shipping fee. This comes from China direct? But I am positive that this is well worth $20, it's just that it would be better to go ahead and charge more for the device and less for the shipping. Perception.
Yeah worth it with shipping if you get a few I think. I usually order about $100 of stuff from them every now and then, and just pay $12 Standard Shipping
Yes, shipping is insanely expensive. The unit is US$8, however, the DHL shipping is US$30. Plus tax entering my country plus DHL addition $17.50 Duty handling charge and tax on the top of this fee. No shipping and handling fees are too expensive for me. I rather go to Aliexpress and order others RISC-V board with the same money but with better spec.
@@chipling7367 Yeah you can get the M1s on AliExpress which also uses the BL808 - have you looked at the price of that?
Else which country? It looks like I can post an envelope to China from here (Australia) for $3! I am tempted to buy a pile of Ox64's for people that want them in countries with expensive defualt shipping.
@@PlatimaTinkers You guys are lucky. I'm in Canada, if I purchase 1 ox64, I need to pay CAD$72.5, i.e. USD$54. With CAD$39, I can get a Lichee RV Dock Allwinner D1 Development Board with Xuan Tie C906 and 512MByte DRAM. The down side is the board has a larger footprint and shipping take more time to arrive. I know it is not an apple to apple comparison but it is the nearest one I can get to have Linux on RISC-V board.
@@chipling7367 Ouch that hurts! Want me to let you know when I've got stock here? AU-CA shipping for it looks to be about $5 AUD for economy air (15+ days) or $20 for standard which is about 5-15 days.
It got one rv64i core (D0) , one rv32i core (M0) and a rv32e core (LP).
Correctamundo my good friend. I accidentally said that D0 was dual core though, which I corrected in my description.
I'm super curious about using LP for something fun. Right now M0 is just doing interop with D0 as so much of the peripherals route through it.
@@PlatimaTinkers I had a look at this thing a month ago. It seems a lot of progress has been made, as last month, no peripherals, no sd card, nothing was supported, except for the UART, so it was in a state "it boots linux" and that's all there was to see. Wow, things go fast.
When I bootled linux last month, it seemed the rv32i core was copying the image from flash to RAM, while the rv64i was delaying, then the rv64i would jump into the kernel.
@@AndreDeLimburger Oooh that is also an interesting way of doing it! I would guess then that they did not have the message bus between the D0 and M0 cores, as the M0 (RV32) is the one connected to the SD card, but of course the D0 does the heavy lifting. Now that there is more interop with IRQ forwarding etc it's running SO much smoother.
@@PlatimaTinkers They didn't implement any intercore communication. But I am under the impression last month was an early proof of concept. No SD card support, all from internal flash.
@@AndreDeLimburger Hey yep they run a 'mailbox' that relays IRQs back and forth. Alex Horner has been working with arm000, pokey and some others on this pretty hard last few months and it was only a few weeks ago this was released working.
That is the code uploaded to M0 in the video which you can find here: github.com/arm000/bl808_linux/blob/irq-forward/bl_mcu_sdk_bl808/examples/low_load/main.c. Not it's not in 'main' branch yet. It's not a full implementation of M0 yet either, but enough to access the SD card and some other required features.
This is booting from the SD card, as I demonstrated, and works well! Next step is ethernet and/or wifi. WOo
Cool. I'm most interested in Ethernet
Yeah SHOULD be fairly straight forward. From what I understand the drivers are nearly done!
Can this run klipper firmware?
Yeah I don't see why not - might just need some porting, else you can use the Linux build of it without issue!
Good platform for running OctoPrint/OctoPi?
Yeah mate once some more drivers are released, OctoPrint would run fine I think! Could not use the OctoPi image though, as the hardware is quite different.
The main problem with OctoPrint is going to be that it's written in Python. The server alone uses about 64MB RAM. Lua would be much better here.
@@_droid Hey that is actually a really good point. This does have swap of course, but not sure how fast it is.
Good video! I love how fast it boots, that's a big deal. Also 90mA power draw while idle isn't all that great compared to a rpi pico
@MalachiBurke Hey thank you very kindly.
Isn't it? I just had a RPi Pico W turn up yesterday, so I can test that if you want! I think one difference there may be the Pico is not running a full multitasking multiuser kernel haha.
@@PlatimaTinkers you're welcome! Yes that's the general idea. ESP32 "modern sleep" averages around 40ma and I expect pico is similar. Way, way less with radios off. As I write this, it hits me 90ma isn't really so bad if all the radios are on ...
@@MalachiBurke Yeah I expect this would be way less if it was sleeping. The code running on M0 is not optimised yet, and just loops passing data to D0, so that can probably be made a bit more power efficient, and without the 802.11 drivers functional yet who knows what the wifi/BLE hardware is doing while idle.
If you were to compare this to an ESP32 though, you could either use just M0 or LP, leaving D0 unpowered, and I expected the power usage would be WAY lower. That 90mA is with three cores all executing their own code, and I have no idea what code LP is flashed with out of the box. It might just be looping 'Hello world' to GPIO pins that aren't functionally attached to it any more.
Only time will tell, and I'll definitely test again. If you want to go hyper-effective power consumption though you could always wire up an ATtiny85 as a watchdog that turns the Ox64 on and off at required times to do its job, eg if it's reporting periodically. Some bloke got an ESP8266 running for 3 months on 2x AA batteries using a similar method (homecircuits.eu/blog/battery-powered-esp8266-iot-logger/)
@@MalachiBurke Just tested; fresh Ox64 with Boufallo Labs SDK on it 57mA, fresh RPi Pico 6mA, so yeah there is definitely some disparity there, by a whole order of magnitude even, but they are still quite different. The Pi Zero W comparatively comes in at 260mA idle though, so that's half a magnitude again just to catch up to the Ox64.... really hard to compare!
@@PlatimaTinkers sounds about right! I wager the pico numbers are with radio asleep,I never see radios drop below 10mA active in my tests. Pi Zero kinda power hungry!
NodeRED will work?
Yeah mate would not be an issue! Just need to get networking going first, which is not far off!
The ram is the problem why RPI pico and most other micro can't have a Linux port, kernel needs I think 8MB(or 16MB) at least to run. RISC-V is not a powerful instruction set, comparable with attiny, RV32I set has about 50 basic instruction if it doesn't have any of the extensions.
Yeah it's a shame about the RPi Pico, but I think RISC-V is quite powerful and it can be easy to forget sometime that ARM64, Amtel Attiny, RP2040 and BL808 are all RISC processors, just of different generations with different design goals.
I am assuming you've got a fair bit of knowledge on it here but for others reading; RISC in general aims to have a _R_educed amount of instructions and allow more complex instructions to be built on those, which ARM does well, as opposed CISC like an Intel x86 or AMD64 CPU which implements everything under the sun as _C_omplex instruction sets, but alas chews up a bucket load more power and in my opinion is actually a tad less flexible for that reason. Most complex instructions are just pre-assembled packages of other instructions anyway, or even complex versions of add/sub/mul/div if you get down to it!
You do have a point though that the AVR ISA that Amtel made is pretty damn awesome, but again it is still RISC. Not really comparing apples to apples here when you've got an 8-bit RISC ISA from 1996 designed for embedded systems (Amtel AVR) vs a 64-bit RISC ISA from 2010 designed for modern light weight computing.
Or as they all say; it's not how big it is, it's how you use it 🤣🤣
And as Platima said, RISC-V boards with one core outperformed arm based boards with multipe cores in certain tasks, plus R-V is much more flexible and openS
@@giorgio_giovanni I think it might all be personal preference in the end
@@PlatimaTinkers I was rewatching some 0x64 videos today and noticed your reply to my post. I tend to miss notifications, so my response is one year late. 😋
When I mentioned the instruction set not being as powerful, I meant that it requires more instructions to perform the same tasks/math compared to some ARM processors that have a more powerful instruction set for executing complex instructions very quickly, that was the tradeoff they made for riscv.
For example, multiplying on RISC-V without the M extension would require more cycles due to its simpler instruction set. A 144MHz WHC CH32V203 with the RISC-V core V4B is notably slower than a 120MHz STM32 M4 when handling tasks beyond basic arithmetic, but it can keep up with simple integer math. Having instruction sets that can perform complex math in hardware(often in one instruction) can easily be 10-30 times faster than doing it with less complex instructions, as it requires the CPU to get more involved and run many more cycles. For example, performing math with SIMD instruction sets can be 20 times faster than doing the same math on the same M4 but with general instruction sets, where the CPU needs to be more involved and run many more cycles for the same math.
Not all RISC CPUs are made the same; it all depends on how they're implemented. The term 'RISC' doesn't mean much beyond indicating a certain philosophy behind it. RISC-V is designed to minimize costs and handle basic tasks efficiently, riscv is designed to be in your appliances and not to be concutent of desktop cpu's or to compete with ARM higher smart phone market. If you want to push RISC-V beyond its basic capabilities, you'll need custom extensions tailored to RISC-V cores. While everyone can design their own extensions for their RISC-V CPUs, these won't be part of the RISC-V ecosystem and likely won't be open-source or free.
@@PeetHobby Hahaha that's all good mate.
Fair reply and some great information there too! Good explanation of the instructions and extensions for new users too.
That all being said, I think RISC-V is beginning to compete with ARM in low/mid-market, and likely to be seen more and more in common products like phones etc. Ref Western Digital, XuanTie, Qualcomm, Google, IBM, all being involved. And that's ignoring the more bespoke players like SiFive, Espressif, Lattice, etc.
Just my opinion though.
can you flash with linux?
... you didn't watch the video did you?
@@PlatimaTinkers not flash linux ONTO the 0x64 - i mean do the flashing FROM linux, instead of the bouffalo lab bldevcube executable
@@zenmaster24 oooooh hahahaha okay got you. Sorry, the sun has not even risen yet - took me a minute. Yep you can, but again it's using BlDevCube, just the Linux CLI version. Ref: wiki.pine64.org/wiki/Ox64#Flash_Ox64
@@PlatimaTinkers awesome - thanks for the link!
@@zenmaster24Any time mate, good luck!
You really could wait and not drink for this 15 minutes and burp into the microphone.
@khashmeshab It was scientifically impossible. Thank you
@@PlatimaTinkers Do explain the science please.
@@khashmeshab In Australia there are small particles in the air called "boganism" that permeate the skin and get into the bloodstream. Most places the concentration is really low, but you'll find suburbs like Rockingham, Frankston, Ipswitch, Kalgoorlie, etc where the concentration is really high. It's pretty good here where I am, but the problem is when it gets quite hot, eg that day was over 33C/92F your pores open up to persperate, and the boganism just soaks in without any resistance. Eventually at the right concentration the urge to "crack a tinny" is no longer something controlled by the conscience and just happens. This is why in hotter areas like Broome you'll find people drink a lot more - hard not to finish work in a 42C/108F day and not crack six tinnies back to back.
Oops wrong Chrome profile, but yeah what other-me said!
@@PlatimaTinkers I thank your other you for the explanation. It seems that you also liked what your other you said. That's so brave of you to be able to sleep in that situation.
How can i order it?
Hey pine64.com/product-category/ox64/ is the ticket!
@@PlatimaTinkers it is cheap but if you add the shiping costs, it become very expensive :(
@@ahmedmoustafa6829 True! What is your country - I will be shipping some soon from Australia, can check pricing. I expect ~$12 AUD for 1-3 units off the top of my head (it's night time here)
@@PlatimaTinkers I live in Germany.
@@ahmedmoustafa6829 Ah my good man, I'm hoping to be there later this year! Economy Air from Australia to Germany looks to be about $5 AUD!
nice! though I don't think calling it a Pico competitor would be fair, since this is a whole SBC and the Pico is just a microcontroller
How would you define them as different? The Pico can run Fuzix. I'd say the only reason it cannot run Linux is because there is not as dedicated of a community that'll port it themselves; they all rely on the foundation to provide the software.
@@PlatimaTinkers > I'd say the only reason it cannot run Linux is because there is not as dedicated of a community that'll port it themselves
I'm not a professional, but I do not think so. mainly the two m0 cortex cores at 133MHz are too slow and pico only has 264kB's of RAM, compare to ox64's 64MB.
@@TheMlg556 Yeah okay I completely forgot about those points haha. That is definitely not enough RAM, however, it could possibly reside in swap? It'd be painfully slow, but surely possible. The question is if you can load enough kernel with only 256KB to then initialise swap. Not sure TBH. 133MHz is not an issue - that'll still run quite fast.
@@PlatimaTinkers I think the 64bit Core on the 0x64 inc a MMU, FP & Vector ops etc, does put it in more the low-end SBC class vs the ucontroller class of the Pico, though I agree the lines between the classes of devices are getting more blurred these days.
@@PlatimaTinkers Also I think swap impl for Linux kernel will be a struggle without a MMU ?
Anyone else have their comment(s) deleted? I made a comment earlier and I don't see it here anymore.
Yeah WTH? I've seen some comment emails, gone to reply, and it was deleted. You didn't delete it?
I've checked the "held for review" section but it's not there either!
Feel free to post it again, then email me too. If this keeps happening I'll raise a support ticket with TH-cam
@@PlatimaTinkers ive had several removed. i have to breath and try to reserve finger pointing. it was related to a trojan being flagged on the English boufallo website which i think is a massive red flag to any (less than flaming) criticisms.
@@justinnewman5533 Oh that is super jank. But also good to know. Were they all comments on this video, or TH-cam in general?
@@PlatimaTinkers Nope didn't delete. Will try again here and email you.
@@PrimalNaCl So odd!
Ripper - saw your email, will reply to it this arvo just heading out for a few meetings.
Cheers
Very nice
Thank you kindly!
I'd rather compare it to the Pi Zero instead of the Pico because the Zero runs Linux which the Pico doesn't.
Very good point my friend, but the Pi Zero is so much more expensive and draws a lot more power. Essentially the Zero has the same core as the other Raspberry Pi's (BCM28 series) but is just more compact. I feel the RP2040 is a closer analogy as they are the same size, same price, etc. I think both sides can definitely be argued though!
How to serial MIDI port suport? And i2s audio dac for standallone MIDI sampler (fluidsynth)under linux
Live and learn my friend.
Here is all the info you need: wiki.pine64.org/wiki/Ox64
Didn't work for me.
Bugger.
1) How far did you get?
2) Did you use 2,000,000 baud?
3) Which release in the repo did you use?
Had a few repo builds fail from what I know, so I was using 0.0.2 (github.com/openbouffalo/buildroot_bouffalo/releases/tag/v0.0.2) but I think 1.0.0 should be solid too!
Guessing that Buffulo maybe an homage to Gnu.
Good call!
Interesting but out of stock -_-
Yeah they are selling hard and fast. Currently seems like they manage to restock every 2-3 months so just keep smashing that F5!
can you make a linux board run on a fart.... ?
sounds like a good project for small pc's like this, , maybe not for farts but,
body heat , body movment, other small electricity generating "operations"
@QuadDerrick
Oooh yes it would be great to see this run on a Stirling Engine! I think that would be pushing it, but surely possible if big enough hah.
@@PlatimaTinkers
i want a iron man helmet with wifi and googles with screen,
powered by farts....
not too many people walk around with sterling engines in they'r pockets but. farts we have lots of. static electricity is in air all around us all the time. we move our feet and use \ can generate, "a lot" of energy like this i think.
@@QuadDerrick The most bogan Aussie iron man, cold can of beer in hand haha.
I mean yeah asses are essentially small combustion engines when used correctly... right? That's science for you
@@PlatimaTinkers it could be a real asset
th-cam.com/video/-FMDJDlYb3o/w-d-xo.html&ab_channel=USAMilitaryChannel
You should do internet radio with 1.8 inch display
Link?
@@PlatimaTinkers th-cam.com/video/Vw4_S3sb8Is/w-d-xo.html
@@PlatimaTinkers th-cam.com/video/KM4n2OtwGl0/w-d-xo.html
@@juizel8008 Oh neat, cheers for that!
No I2S?
Yep sorry definitely has I2S - that table was not quite filled out with every detail. Here's the functional block diagram as a reference for you: wiki.pine64.org/images/thumb/d/de/BL808_Block_Diagram.jpg/600px-BL808_Block_Diagram.jpg
@@PlatimaTinkers Cool, I've got a ton of boards sitting around already, but I'll have to check these out as well.
Edit: How hard is it to add device tree overlays for the GPIO devices when you're running a full Linux kernel?
@@butsukete1806 Hah yeah same here, SOCs building up like a bad itch, but these are so far my favs and SUPER cost effective compared to even an ESP32 IMHO.
GPIO is already working my friend. I just did not demo it in this video as it was long enough! Pt 2 coming in following weeks.
Sounds like a new contender then. Right now my gotos are ESP32 for wireless and Pico for anything else, really like the PIO feature. Looking forward to your next video.
@@butsukete1806 Pretty much what I've been doing mate; 3x RPi4 running all my docker containers for local services such as control, monitoring, alerting, then some Pi Zero's for GPIO control eg retic etc, and ESP32's for endpoints such as lights, switches, etc.
Cheers
90mA is not running on a fart. That isn't battery capable.
It is for a Linux kernel, let alone one that isn't yet optimised!
Consider the ESP8266 which is a tiny MCU that can't even run a first class (multi-user, multi-task) OS such as this, is not dealing with SD storage, and has an average current consumption of 70mA from what I've found.
So yeah, it's not battery capable, but it's still the best I've seen for something with an OS! Leaving Hello World on it instead would have been < 10mA from what I recall. Will test today and advise!
@@platima Ah crap wrong account. Close enough though hah
I can't help but read this as Hex64...
Hahah yeah I think that's intentional. I've seen so many places, even people in these comments, refer to it as 0x64
How to buy one in china
@helson-vlog Hi, can you not buy from pine64.com/product-category/ox64?
@@PlatimaTinkers Country option without China
@@helson-vlog Ah yep looks like unfortunately it falls under export restrictions :( You'll need to try AliExpress perhaps - the SiSpeed M1s Dock is quite similar and also has a BL808 chip
@@PlatimaTinkers thanks
@helson-vlog I've got these in stock now shop.plati.ma/collections/all?filter.p.vendor=Pine64
and they have a 30$ shipping quote for Europe.
Platima Cooks
1 second ago
Huuuuuu.
Maybe reach out to their team and see if they can have multiple shipping options?
Else it might be cheaper for me to order it here and ship it to you haha
On the site. Board $6. Shipping $11.99. Lol.
Haha yeah that sucks so bad. They need international warehouses
Pico is pronounced "Peeko"
Not in 'strayla :P
LOLZ @ RISC-"VEE"
Just how I do. Haha
Wifi and can run Linux.. hm.
Webserver time!
Well we need to wait for network drivers to be finished, but ethernet is close!
Webserver would not be hard; I expect Webmin would run without issue if you want a config UI, else nginx would fly on this. Someone pretty much sums it up here: www.reddit.com/r/RISCV/comments/w2adax/nginx_php81_simple_web_server_on_riscv_visionfive/
5:38 uff
I know. It hurts so bad -_-
Just like Raspberry Pi.. Out of Stock
You in Australia? I've got stock here
Just needs an esp32 for wifi 😂
It's got wifi built in mate, just need to attach an antenna and get the drivers going! I am tempted to use an ESP32 as serial wifi for remote debugging though!
It's not a "V" it's a Roman 5. So it is pronounced Risc 5, mate.
Yeah hence I say both - a lot of the crowd I associate with say RISC-V, so I'm used to that, but I correct myself to RISC-Five for video as I did in this haha.