Port-alpha archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: NetBSD/alpha on qemu-system-alpha



Op 19-08-2021 om 16:22 schreef Jason Thorpe:


On Aug 18, 2021, at 10:33 PM, Remy van Elst <relst%relst.nl@localhost> wrote:

Hi All,

Since there is so much exciting development on the QEMU side and since astr0baby's twitter is overflowing with NetBSD on all kinds of architectures at the moment, I thought, lets do a write up / guide on NetBSD for Alpha on QEMU. It is linked here:


https://raymii.org/s/articles/NetBSD_on_QEMU_Alpha.html

Hey, thanks for writing this up!  I’ve been meaning to write something up myself, but my roundtuits are in short supply at the moment.

- Why do I need to provide the kernel to QEMU as (two, one for install, one after) a seperate file? The kernel is installed on disk after installation right?

The Qemu “bios” (palcode-clipper) for its Alpha emulation does not contain any of the I/O callbacks implemented by real DEC SRM firmware.  Nor does it contain any of the CLI implemented by real DEC SRM firmware.  As such, there is no way to use a boot loader program to load the kernel from the file system in the emulated machines disks.

- What is the purpose of the two different kernel files? astr0baby just said, use them, but not why.

GENERIC.QEMU is exactly the same as GENERIC except that it has the kernel symbol table injected into it for use by the in-kernel debugger (and, eventually, the in-kernel linker for modules, once I finish implementing all of the necessary relocations for Alpha).

- How do I handle updates for the kernel (in regards to the seperate qemu file)?

Unfortunately, you must continue to update the kernel out-of-band by whatever mechanism is most convenient to you.  This is simply just a limitation forced by qemu-system-alpha.

- Installing any package that depends on GTK (like xfce4-wm or netsurf) takes long to install. xfce4-wm has been going for 18 hours now, either updating the gtk icon cache or some other post install process. Can I speed this up?

Yikes.  I’ll need pkg install experts to weigh in on this.  It’s entirely possible that it’s bottlenecked on the disk emulation.  I’m working on getting VirtIO to work on alpha so hopefully we can speed disk and network access up a little.

-- thorpej


Hi Jason, thanks for your response, it clears up my questions.

I like to write about these sorts of things. Most of the AXPbox documentation was written by me and my site has stuff from 2006 and
onwards. Legacy systems have a special place, especially DEC related.
I did a writeup of TSS/8, WPS-8 and more regarding the PDP-8, VAX, Alpha
and OpenVMS are in the same category. I do love playing with NetBSD, after installing the Alpha build, I also spun up a Virtualbox instance. Got XFCE and Clion running, so I might even consider switching my regular desktop over, since Clion and GCC are the only things I really need for my dayjob. pkgsrc seems to be a great system as well, I'm learning and discovering so much, just because of your work on the Alpha
emulation.

Would it be possible to provide an SRM to qemu, like with AXPbox? (http://raymii.org/s/inc/downloads/es40-srmon/cl67srmrom.exe) / (https://github.com/lenticularis39/axpbox/wiki/OpenVMS-installation-guide)? The wiki page of qemu is quite sparse on alpha information.

Regarding the disk IO, I can see with iostat that there is a lot of activity (when executing a gtk-update-icon-cache in another terminal),
but I'm not familiar enough with netbsd to do more extensive monitoring.
strace is not available as a binary package and pkgsrc source compilation needs kernel sources, I'm not sure how to get more information on what happening.

I do want to, again, say thank you for your effort regarding alpha and qemu. It's giving me a lot of pleasure, playing around and discovering NetBSD.

Cheers,
Remy


Home | Main Index | Thread Index | Old Index