Posts
4505
Following
316
Followers
476
Linux kernel hacker and maintainer etc.

OpenPGP: 3AB05486C7752FE1

Jarkko Sakkinen

Edited 1 year ago
My online life started about then in the BBS world first and I've yet to meet a person who willingly uses xmodem or ymodem for anything. I would be more eager to try out stuff that promotes explicitly to support neither. they were already corpses when i first discovered of their existence.

you *literally* need to visit maybe a rest home to meet a living person who has ever had any profitalble use for them...

on the other hand zmodem is still a thing with SBC's and FPGA's.
1
0
1
Tbh, I don't really get why people have done new kermit/minicom style programs and promote X-modem and Y-modem, which nobody used even in 1993 when calling BBS's because they were so terrible. Why not then just use kermit. or minicom instead. I want to sort of well integrated "zmodem experience" :-)
1
0
0
And make it sort of maybe BufReader/Writer style thing so that it has no understanding of its surroundings... yea, i think i have a solid plan carved up
1
0
0
I.e. just ZCBIN ignoring all 16-bit legacy and other BBS'esque clutter. fun little exercise to accomplish i guess
1
0
0

Jarkko Sakkinen

it is 2023 and i'm implementing #zmodem just a sub-portion of it: 32-bit binary transfers. So ignoring 16-bit and alternative hex protocol. There's some non lively looking zmodem crate and of course lrzsz but neither of them feel too inspiring to contribute or build on top off.
1
0
1

Jarkko Sakkinen

Edited 1 year ago
Rust is robust in the sense how it can respond to different memory safety issues but it is robust to the limits "as long as you accept the default response". If you don't agree with the response, there's way to go around it but is sort of "not recommended for most". It is a bit like you would limit email only pre-defined template responses.

So the stimulus part of the safe systems programming language equation is gotten right but hard coded response as defaults is not a great thing tbh.
1
0
0
Unrobust meaning that you can do all of this but would have to put unrealistic amount of effort to accomplish any possible e,g. business or even academic goals.
1
0
1

Jarkko Sakkinen

all sort of glitch with #rustlang community comes to personally in the end how you look at a programming language: a language or purely just an opcode generator. one example of such glitch is IMHO unrobust handling of OOM conditions. So you end up getting safe but and super fat and resource wasteful user space programs. But still memory-safe in the language level, which does not provide safety for e.g. any possible DoS attack.
1
0
1

Jarkko Sakkinen

tonights jam, something in progress #bitwig
0
0
0
@laund implement even a PoC quality version of SBI on top of Embassy. Then I'm super interested. Even just bare bones baseline for development an something is provably in working condition. There's some dead looking SBI crate but I would see more future in implementing one top of this more or less accepted framework called Embassy I suppose. Not that I'm too familiar with that either. I just hack CPU's, that what I do in the end....
0
0
0
@laund AFAIK does not provide SBI implementation (could be wrong too) so not really what I was looking after.
1
0
0

Jarkko Sakkinen

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
0
0
2

Jarkko Sakkinen

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
2
3
6
@josh If I wanted something like I'd look how BuildRoot thing is implemented, and derive something more generic from that. The reason being that it is already pretty well field tested.
0
0
0
@josh BuildRoot can do graphs. It is based on kbuild so pretty close at least.
2
0
1

Jarkko Sakkinen

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

0
1
2

Jarkko Sakkinen

Edited 1 year ago
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
0
1
5

Jarkko Sakkinen

after years of using #voxengo #span i've started using #tokyodawnlab's new and free #prism: https://www.tokyodawn.net/tdr-prism/
0
0
0
@tommythorn yeah, my usage model for SBC"s is such that I most of the time have a new image per boot because I use the image just to test e.g. a code change to kernel or sometimes firmware. like e.g. with this one i have not ever even tried to connect it to a network or display, all comms through TTL-USB. if you test e.g. kernel on many different SBC's, then a workflow is required where you do not need to connect many cables. surviving with just USB power and TTL-USB with the whole range is optimal because all SBC's I know follow the same GPIO layout as RPi.
0
0
0
Show older