Lot's of RISC-V posts but here's one more. I think it has a strong future in post-#quantum world. QPU is like GPU, i.e. it is great for certain types of computations but it sucks for branching binary logic that I/O relies on. In that world correctness of stuff that is done with semiconductors is hugely more important than now and that's where open, modular and within constraints formally verifiable CPU architecture shines.

#riscv

If most of firmware stack in RISC-V was rustified so that you could build compatible SBI implementation with cargo build, that would be the most effective embedded product creation platform that I could think of. You could move from product idea rapidly to a product PoC.

#riscv #rustlang

I wonder if #BeagleV has similar #DIP switch as #VisionFive2, which works as a selector for different boot modes?

In VisionFive2 you can choose to:

1. Boot from SPI flash.
2. Boot from SD (including U-boot and OpenSBI, assumes a particular partition layout).
3. Rescue UART boot mode.

These VisionFive2 e.g. pretty capable board for prototyping CPU extensions.

#riscv #sbc #uboot #opensbi

I like how easy it is with RISC-V to emulation ISA extensions by emulating privileged instructions in M-mode. that makes it pretty good production creation platform when you have something in-between FPGA and QEMU. I.e. you can take ASIC board and build a PoC with customized OpenSBI. #riscv #opensbi #fpga #qemu

after years of using #voxengo #span i've started using #tokyodawnlab's new and free #prism: https://www.tokyodawn.net/tdr-prism/

Nice, with the DIP switches Starfive VisionFive 2 SBC can be made to boot the full chain from SD card. Initially booting from SPI flash for any possible use for this never really makes sense. It is a badly chosen default for this sort of maker and/or developer product :-) #riscv #opensbi #uboot #starfive #visionfive2 #keystone

Log grabbing pattern for pretty_env_logger. when tracing #Rust #TUI applications;

RUST_LOG=debug target/debug/tior open /dev/ttyUSB0 2> log.txt

#rustlang

great, now #tior #serial #terminal tool has UTF-8/escape code encoder for most relevant key presses without modifier key. i guess now is a good time to look at #zmodem support. it is just disjoint state for the TTY session, and in the end might be easier part.

beginnings of an input encoder for my serial tool. it is probably better to have in-tool encoder because it also affects a lot to the user experience. next stop probably supporting also backspace :-) https://github.com/jarkkojs/tior/commit/08bc02c0acf8d3424eb35db44f49debc5394989a

#tior #serial #terminal

a public git for my serial port tool development aimed for mainly kernel testing with various SBC's: https://github.com/jarkkojs/tior. Just a skeleton I'll work on the user input part next, and later on zmodem.

For managing #terminal in #Rust the best option after trying a bunch is avt. The reason is that it has been thrown out a lot with the applications it has been used for. Not so easily found as not available in the #cargo repository. For framework like #ratatui it is pretty trivia to integrate as the the representation is just frame buffer as a byte array.

All various ratatui and tui-rs derived frameworks are pretty immature compared to its robustness. It is much better idea to just decorate avt as it feels quite rock solid with the streamed data.

#rustlang

moving from line editor world to the screen editor world #serial #terminal #vt100 #zmodem

My new CI environment for TPM, ARM TEE (TrustZone/SMC) and Linux keyring. Made itself useful within 5 minutes after power on: https://lore.kernel.org/linux-integrity/CX342W32D30U.330BVFC336MA8@kernel.org/T/#t.

Environment: https://github.com/jarkkojs/buildroot-tpmdd/tree/linux-6.6.y

Fix sudo in #OpenSUSE #Tumbleweed:

$ sudo cat /etc/polkit-1/rules.d/60-local.rules
polkit.addRule(function(action, subject) {
    if (subject.isInGroup("wheel")) {
        return polkit.Result.AUTH_SELF_KEEP;
    }
});
$ sudo systemctl restart polkit.service

I.e. when root login has been disabled earlier with:

# passwd -d root
# passwd -l root

#note

In #OpenSUSE, the package name you want to install is systemd-devel, not libudev-devel 🙂 #udev #linux

Installing #rustup:

alias rustup="curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | bash -s --"

E.g.

rustup --no-modify-path

Just though that good to write this up since I see some distributions packaging rustup, which makes no sense (for #rustc and #cargo it does for obvious reasons).

It is also totally safe to run rustup this way kudos to the amazing #TLS 1.2.

#rustlang

Installing #OpenSUSE #Tumbleweed to my desktop. Seems like a good sweet spot having latest packages and professional QA for a workstation.

Got #Arturia #Minifreak and it is my main #MIDI keyboard now. I was worried that it has the same problem as with #Microfreak, i.e. low audio signal but it is all good. I guess it has better DAC's or perhaps a built-in preamp. The low signal in Microfreak has been a real turnoff for me and have not used it that much, which is a shame.

The synth engine is capable of doing all the basic sounds, except it lacks wavetable oscillator but I'm 100% sure that it will land at some point in firmware update. Why I think it is great synth to use as starting point for any track is the matching #VST plugin. I'm planning to use that instead of #Serum to do placeholder sounds for first versions of new tracks and later phase replace some of them with other synths. Only thing I'm sticking to #Serum is bass because there the wave shape of the oscillator is too crucial to make compromises (as important as the filter).

I'd also like to have 18 dB filter for bass as it is sort of in the sweet spot but as the other engine can act as digital filter, the combination of analog and digital filter can probably be used to find the sweet spot (I some times use two 12 dB filters in series, if a synth lacks 18 dB slope filter).

If I did not have anything else to do I would reimplement this in Rust: https://github.com/microsoft/ms-tpm-20-ref. The code quality is not great in the original and it is not particularly complicated thing to do just time consuming. Looking how bad code quality is, I wonder why e.g. #OPTEE implementation is based on it (if I got this wrong please correct, 99% sure it is).

#tpm #arm #tee

Writing my own serial port tool in Rust that plays well with #tmux. I like #tio but I'm looking into later expanding mine with built-in #zmodem support. Also, this should give portability across all major operating systems (#Linux, #Windows, #macOS).

#rustlang