wolfreiser

Sometimes people also confuse Vlad with Vladimir, but it's actually Vladislav. Vladimir would be Vova.

Time required depends on complexity of the target architecture, desired performance and debugging, which is probably the most time-consuming.

At the beginning when interpreter wasn't tested yet we had a problem of Linux kernel crashing at the early stages of boot, IIRC that was memory setup. However, the bootloader (OpenSBI) booted correctly. Initially we thought that there was something unimplemented in the emulator, but it turned out there was a bug in one compressed instruction. Debugging this was a nightmare. After the fix kernel booted right to the userspace startup. So booting Linux took us about 2 months of work in total.

If you want to go form scratch compilcations will start to appear when you go out of the CPU and start implementing devices. You'll going to need them anyway because you'll want to boot from disk image or move a cursor in X :). Devices are independent of the CPU architecture and have their own standards, so implementing them will take some time too.

There's no company behind, the work was done purely on enthusiasm. The main purpose was education and, because RISC-V boards are not widely available, software porting - including RVVM itself - I ran it on N900, but it was not so fast as I expected. Hopefully this will be resolved when JIT will be finished. As for other projects - Xash3D server was ported to RISC-V thanks to RVVM.

And saying that you've written a virtual machine sounds cool too :)

Yes of course. I've not tested modern DEs because the emulator is still RV32-only, but xterm with twm works very good.

It's still works with interpreter with 1/3 of QEMU performance. With JIT (which is still WIP) it'll be even faster.

I would like to warn you about signature checking.

My HP got a password after a faulty BIOS update (it just hanged up for 30 minutes on one block and I pulled the battery, never do this!)

So I had to fix this. However, my laptop will reset the BIOS if it fails the signature checking. Luckly for me, HP didn't used the BIOS Guard/Boot Guard technology and did the checking on the PEI stage with their own module. The checking part was in the same module as BIOS flasher (IIRC).

The password checking was easy to find because AMI BIOS sources are available on GitHub. Interestingly, HP has a "backdoor" feature that lets you generate a password from code displayed, so I easily unlocked my laptop without any patches. I could have released the generator utility, but, hell, this will let people unlock any other laptop with same kind of BIOS, so no.

As a bonus I had also unlocked hidden settings, which gave me a great control over my CPU and chipset. So I disabled hyperthreding thanks to my paranoia :)