An open source online assembler and disassembler for x86, ARM, RISC-V and PowerPC. It's a useful learning resource that comes with other tools and can run offline.
Canonical Gets Flutter Up And Running On RISC-V For Ubuntu // @phoronix
「 Canonical engineer Valentin Haudiquet has been working on getting Flutter on RISC-V. A Flutter pull request this week seeks to upstream support for the Flutter tool on RISC-V. Another patch adds the RISC-V 64-bit desktop Linux engine support so that you can cross-compile a Flutter engine for RISC-V Linux from x86_64 Linux hosts 」
Update: The BPI-CM6 compute module with a SpacemiT K1 RISC-V processor is now available for $67 + shipping (or $84 for a bundle that includes a carrier board). https://liliputing.com/banana-pi-bpi-cm6-is-a-compute-module-with-a-spacemit-k1-risc-v-processor/ #RISCV #SpaceMiTK1 #BananaPi #ComputeModule #BananaPiBPI-CM6
La Catalana OpenChip, tanca acords amb la Japonesa NEC per fabricar xips RISC-V amb extensions vectorials dissenyades per accelerar la IA. https://www.hpcwire.com/2025/11/13/openchip-and-nec-moving-ahead-with-risc-v-vpus-for-aurora/ #riscv
La Catalana OpenChip, tanca acords amb la Japonesa NEC per fabricar xips RISC-V amb extensions vectorials dissenyades per accelerar la IA. https://www.hpcwire.com/2025/11/13/openchip-and-nec-moving-ahead-with-risc-v-vpus-for-aurora/ #riscv
For folks who missed my #KISV keynote or #CHERITech talk, I wanted to pull out the two key points.
The first is that CHERI solves memory safety, but that’s almost incidental. I don’t want to downplay addressing the root cause of 70% of vulnerabilities but that’s not the goal. CHERI was originally designed to support scalable fine-grained compartmentalisation. To do that well, you need a programmer model. You need to be able to share things programmers understand (objects, in object graphs) not pages. And that means you need to be able to trivially map your protection up to language-level constructs like pointers / references and protect both them and the objects that they refer to. And so you need to build memory safety. And, it turns out, making an entire program memory safe is much easier than making just an exposed API memory safe. So we have memory-safe C/C++ and we can use those from languages like Java or Rust to ensure that the C/C++ doesn’t violate the guarantees that the safe language’s security depends on. And then we can use that for easy to use compartmentalisation, safe FFI, supply-chain security, and many more things.
The second is that CHERI is still quite young. I gave a talk about how CHERI impacted OS design. That’s like, in 1985, asking someone from IBM to give a talk about how MMUs impacted OS design. They would tell you you could create VMs to consolidate multiple minicomputers onto a single mainframe. They would tell you that you could enforce process isolation. And, just like the things we can do with CHERI today, these are hugely valuable. But they wouldn’t tell you about using Zygote models to speed up process creation. They wouldn’t tell you about how memory-mapped files could enable new I/O models. They wouldn’t tell you about how IOMMUs could enable kernel-bypass storage and networking. They wouldn’t tell you about how MMUs can introduce lightweight GC barriers. They wouldn’t tell you about how MMUs enable lightweight CoW snapshots for time-trace debugging. Because, although a lot of the hardware existed for these things (and the rest was a fairly small incremental tweak on existing ideas), most of these software uses hadn’t been invented.
CHERI is exactly the same. We have barely scratched the surface of what CHERI can let you build. The BLACKOUT work (presented at CCS and again at CHERITech) is another great example of this. I had never thought of using CHERI as a building block for providing a clean programmer model for avoiding side channels, but some other smart people did and proposed a really interesting model for doing so. I hope future CHERI systems will incorporate something based on this work.
As with MMUs in the early ‘80s, we have no idea what people will be building on top of CHERI in ten or twenty years. Many of these things will be possible on existing implementations, some will require hardware changes. This is why it’s very important for the RISC-V CHERI standard to be designed with agility in mind, so that future hardware can continue to add new and exciting features without breaking backwards compatibility for software. I think we’re on a good path to that.
I was looking at some RISC-V crypto code and learned about data-independent execution latency (DIEL)
https://riscv-software-src.github.io/riscv-unified-db/manual/html/isa/isa_20240411/chapters/vector-crypto.html#zvkt
It's #RISCV's equivalent to
👉 ARM's Cortex-A DIT
https://developer.arm.com/documentation/ddi0601/2022-06/AArch64-Registers/DIT--Data-Independent-Timing
Related talk excellent talk by Markku-Juhani Saarinen https://www.youtube.com/watch?v=sZKbZfMj0Ek
I was looking at some RISC-V crypto code and learned about data-independent execution latency (DIEL)
https://riscv-software-src.github.io/riscv-unified-db/manual/html/isa/isa_20240411/chapters/vector-crypto.html#zvkt
It's #RISCV's equivalent to
👉 ARM's Cortex-A DIT
https://developer.arm.com/documentation/ddi0601/2022-06/AArch64-Registers/DIT--Data-Independent-Timing
Related talk excellent talk by Markku-Juhani Saarinen https://www.youtube.com/watch?v=sZKbZfMj0Ek
hmmmm, not many reviews out there of the Banana Pi BPI-F3 board based on the 8-core SpaceMIT K1 SoC ... @geerlingguy doesn't have one, and @chipsandcheese hasn't looked at the CPU
given My price range (which, let's be honest, is $0 so I'd have to get one donated) and available shelf space, if I was gonna get a #RISCV board to tinker with and potentially offer access to devs online for purposes of building & testing software on the platforM, it'd alMost certainly be the @bananapi BPI-F3.
hmmmm, not many reviews out there of the Banana Pi BPI-F3 board based on the 8-core SpaceMIT K1 SoC ... @geerlingguy doesn't have one, and @chipsandcheese hasn't looked at the CPU
given My price range (which, let's be honest, is $0 so I'd have to get one donated) and available shelf space, if I was gonna get a #RISCV board to tinker with and potentially offer access to devs online for purposes of building & testing software on the platforM, it'd alMost certainly be the @bananapi BPI-F3.
Compiler Explorer is a great way to understand the effect of #riscv extensions or compare CPU arch. You can even compare rv32 and armv7 to a 486. 🤔
For example, an endian swap takes 11 instructions with the base RISC-V ISA, but only 1 instruction (rev8) with the Zbb extension.
Today in #RISCV:
Register mtval (optionally) holds the fault address of a data fault, is specified to hold “all valid virtual addresses and the value zero. It need not be capable of holding all possible invalid addresses.”
Hit an invalid virtual address? Good luck debugging it. 🤡
Today in #RISCV:
Register mtval (optionally) holds the fault address of a data fault, is specified to hold “all valid virtual addresses and the value zero. It need not be capable of holding all possible invalid addresses.”
Hit an invalid virtual address? Good luck debugging it. 🤡
New semester, new version of the xv6 educational OS for RISC-V from MIT! This is accompanied by a new revision 5 of the xv6 book and–for the first time, I think–a Lions' Commentary-style code reader booklet!
A previous version switched to using the stimecmp extension instead of the regular CLINT timer, that was a bit of a surprise. So let's see what the changes in this new version are...
https://pdos.csail.mit.edu/6.1810/2025/xv6/book-riscv-rev5.pdf
https://pdos.csail.mit.edu/6.1810/2025/xv6/xv6-src-booklet-rev5.pdf
https://github.com/mit-pdos/xv6-riscv
New semester, new version of the xv6 educational OS for RISC-V from MIT! This is accompanied by a new revision 5 of the xv6 book and–for the first time, I think–a Lions' Commentary-style code reader booklet!
A previous version switched to using the stimecmp extension instead of the regular CLINT timer, that was a bit of a surprise. So let's see what the changes in this new version are...
https://pdos.csail.mit.edu/6.1810/2025/xv6/book-riscv-rev5.pdf
https://pdos.csail.mit.edu/6.1810/2025/xv6/xv6-src-booklet-rev5.pdf
https://github.com/mit-pdos/xv6-riscv
💡 The future of open computing is built together.
Join the conversation and connect with the RISC-V community right here on Mastodon!
Follow @riscv to explore the latest advancements, community projects, and technical insights.
Our lead relay engineer @alexhaydock has increased our stateless #Tor exit relay deployment to 96! (+1 because of the new #RISCV bare-metal node, +1 other we redeployed due to a silly spelling error). We're stress testing our three AMD Epyc 7402P servers that use #Proxmox.
Each one of the 96 Tor exit nodes are diskless Unified Kernel Images, 56MB in total size, using @alpinelinux's alpine-make-rootfs with an absolutely bare minimum number of packages. We'll be publishing more about our new architecture and configuration soon.
#AlpineLinux #privacy #anonymity#AntiCensorship#AccessToInformation#TorOps#TorOperators