Played around with the MILK-V Duo this morning. It certainly feels snappier than the Mango Pi, although that might be because it's running a buildroot image and not a full distro. Idle it uses about 75mA, running while true; do echo Hello; done over an ssh connection it pulls 100mA. #milkv#riscv#linux
Not that there’s anything particular about it but here’s the obligatory neofetch shot running Debian (provided image) on #VisionFive2 after installing everything suggested in QuickStart PDF.
In this context the experience isn’t very different from any ARM board but it’s nice to see #RISCV in real life.
The board still boots, still has GUI and network.. but anyway rather than being bitten by this later I’ll just reflash and avoid upgrading this time. It’s going to be hard to not do it by accident.
Not planning to use Debian much on this but it'll be a good tool / reference as I try to get #HaikuOS running on it.
So I ordered myself a Vision Five 2 last week because I thought after a month of delivery time I’d have free time to dedicate to it and #HaikuOS for #RISCV….
Turns out it wasn’t last week but February 4 and it’ll be here soon.
Guess I need to read all that because I have no idea how to do this right now.
🧲 Milk-V Duo S: Dual-Core RISC-V SBC Open for Pre-Order Starting at $11.00 | linuxgizmos.com
"This dual-core design offers flexibility and performance for embedded computing. Scheduled to ship in March 2024, this board has improved specifications and features compared to the Duo Classic, and it supports both Linux and FreeRTOS operating systems."
Does anyone understand #riscv traps and interrupts?
On interrupt I set mstatus.mpie to mstatus.mie and clear mstatus.mie to disable interrupts in the handler. Then mret copies the flag back again. That’s all fine and makes sense.
Trap entry (e.g. ebreak or illegal instruction) currently does the same, is that correct? If so how do I recover from a breakpoint in an interrupt handler? There’s only one level of prior interrupt enable so the enable gets lost.
This week on The Amp Hour we discussed relativistic time differences, building with #riscv components (the #ch32v003), RF modules (#nrf24), silly consumer hardware, underwater electronics, and more!
I'm not that into hardware details but when I can build in a #RISCV QEMU cross compile environment, but on native hardware it fails reproducible with exactly the same versions with:
gcc: internal compiler error: Segmentation fault signal terminated program cc1
I'm contemplating getting a #RISCV board for use at home. I ruled out the enterprise systems that are several thousand USD/EUR, as I plan to only use it for hobby capacity. Is there anything that is there to avoid? I recently learned that the SiFive boards have somewhat terrible memory performance, making them painfully slow for real world use. Any advice?
Do we see here the first ever #RISCV based #TOR node running? I just provided a TOR node for the #onion network on one of my #VisionFive boards. This one currently runs on #Debian#Linux (will be switched to #FreeBSD soon).