Hi,
Last month I set about to develop a hotspot solution that would make the Pi0 a viable solution again. That's a project I might discuss at a later time. But it was while looking for some different SBC's to pick up for development and testing; I came across this:
The Milk V Duo S. It's a very odd board. It has a dedicated 700 MHz RISC-V for FreeRTOS to run...microcontroller stuff. The vendor pushes it for IP Cameras...so you can do things like run a video encoder and image classification models. It's got a .5 TOPS TPU for image processing. None of it we need and played no part in me getting this board. It boiled down to "it's yours for shipping"...and it runs Linux. In that regard, it's got a 1GHz RISC-V core and 512MB ram; onboard wifi and bluetooth (it even has an external wifi antenna), ethernet, USB-A for data, USB-C for power (and data if you're not using A), and full size ethernet. The portion of the GPIO header on the board matches the "standard" the MMDVM hat uses. So...let's get some header extensions to get over the ethernet port...and a new duplex hat so I can actually test all that stuff.
Okay....it's plugged in, it's lit up. Now this is the part where I mention this board has absolutely no real mainstream Linux support and we're not going to be getting a distribution on it. Okay...there's a user-made Debian distro out there that...works. Fedora v-force has support for it as well. And I did...in fact...go the Debian route to start.
I started off using a DM-1701 running OpenGD77 as a test while waiting for header extensions to come in; and I started off using the Debian build. What you don't see is the load being reported as a constant 3. It was actually a quirk in how that was calculated; the three processes responsible for communicating between the host and the "little core" never sleep and never actually idle. They consume no CPU, contribute no actual load, but they appear as 3 processes that are always waiting.
MMDVM-Host and DMRGateway were actually cross-compiled; because I'm pretty sure trying to build those on the device would be painful. However I was pretty lazy about it after the horrors of trying to get armv6l cross-compilation going on x86_64; so I just use qemu-bin-fmt and a few utilities so I can just chroot in to SBC images, set them up as a build environment, and build using emulation. As you can see, memory usage was pretty lean; most of it being the OS itself. But I was about to jump down a rabbit-hole I actually didn't want to. I started poking around the vendor's supplied buildroot...found out how to cut out all the camera drivers, insert some packages, and claim some RAM back from the FreeRTOS core.
64.5MB. And I'm pretty sure I could get the dashboard to use less if I poke Go properly. I also got "Illegal Instruction" on binaries that had been running on this same hardware. This turned out to be the kernel lacking the patches to handle fence.ts0 instructions...which came from the static MUSL and libstdc libraries I linked against when I built the binaries...so I just patched the binaries as I wasn't about to spend 2 days letting those compile under emulated RISC-V. No...the display doesn't work. In fact I couldn't even get it to show up on the I2C bus scan...so it's either faulty or not setup correctly. I'll pull it at some point.
73,
Jay/NQ4T
Last month I set about to develop a hotspot solution that would make the Pi0 a viable solution again. That's a project I might discuss at a later time. But it was while looking for some different SBC's to pick up for development and testing; I came across this:
The Milk V Duo S. It's a very odd board. It has a dedicated 700 MHz RISC-V for FreeRTOS to run...microcontroller stuff. The vendor pushes it for IP Cameras...so you can do things like run a video encoder and image classification models. It's got a .5 TOPS TPU for image processing. None of it we need and played no part in me getting this board. It boiled down to "it's yours for shipping"...and it runs Linux. In that regard, it's got a 1GHz RISC-V core and 512MB ram; onboard wifi and bluetooth (it even has an external wifi antenna), ethernet, USB-A for data, USB-C for power (and data if you're not using A), and full size ethernet. The portion of the GPIO header on the board matches the "standard" the MMDVM hat uses. So...let's get some header extensions to get over the ethernet port...and a new duplex hat so I can actually test all that stuff.
Okay....it's plugged in, it's lit up. Now this is the part where I mention this board has absolutely no real mainstream Linux support and we're not going to be getting a distribution on it. Okay...there's a user-made Debian distro out there that...works. Fedora v-force has support for it as well. And I did...in fact...go the Debian route to start.
I started off using a DM-1701 running OpenGD77 as a test while waiting for header extensions to come in; and I started off using the Debian build. What you don't see is the load being reported as a constant 3. It was actually a quirk in how that was calculated; the three processes responsible for communicating between the host and the "little core" never sleep and never actually idle. They consume no CPU, contribute no actual load, but they appear as 3 processes that are always waiting.
MMDVM-Host and DMRGateway were actually cross-compiled; because I'm pretty sure trying to build those on the device would be painful. However I was pretty lazy about it after the horrors of trying to get armv6l cross-compilation going on x86_64; so I just use qemu-bin-fmt and a few utilities so I can just chroot in to SBC images, set them up as a build environment, and build using emulation. As you can see, memory usage was pretty lean; most of it being the OS itself. But I was about to jump down a rabbit-hole I actually didn't want to. I started poking around the vendor's supplied buildroot...found out how to cut out all the camera drivers, insert some packages, and claim some RAM back from the FreeRTOS core.
64.5MB. And I'm pretty sure I could get the dashboard to use less if I poke Go properly. I also got "Illegal Instruction" on binaries that had been running on this same hardware. This turned out to be the kernel lacking the patches to handle fence.ts0 instructions...which came from the static MUSL and libstdc libraries I linked against when I built the binaries...so I just patched the binaries as I wasn't about to spend 2 days letting those compile under emulated RISC-V. No...the display doesn't work. In fact I couldn't even get it to show up on the I2C bus scan...so it's either faulty or not setup correctly. I'll pull it at some point.
73,
Jay/NQ4T
