Re: Committing code to evbmips?

Hi,

On 27.11.22 12:28, Havard Eidnes wrote:
>>> [...]
>> I don't know how to get the created userland into an image usable by
>> QEMU though, but I assume there are ways to accomplish that.
>
> Thanks for the hint & pointer.  What I was thinking of when I
> wrote the above was that since I'm using a "raw" image with qemu,
> I could probably just use vnconfig on the host, label the "disk",
> newfs and mount it, and extract the user-land from the host OS,
> since the kernel to boot in this case is supplied by the host
> directly to qemu, the disk image itself doesn't have to be
> "natively bootable".

Aha, I wasn't sure if that could just work. You found a good way to get
the partitioning into the virtual block device below.

> I have since done exactly that, and I'm using the MIPSSIM-MIPS64
> kernel from -current and the 9.3 user-land.  The sequence to get
> this going was roughly:
>
> # dd if=/dev/zero of=disk.img bs=1m count=<what-you-want-or-need>
> # vnconfig vnd0 disk.img
> # disklabel -I -e vnd0
> I labeled with a 'b' swap partition at the end, rest to the 'a'
> partition.
> # newfs -O 2 -V 2 /dev/rvnd0a
> # mount /dev/vnd0a /mnt
> # cd /mnt
> # for s in <list of set files>; do
> progress -f $s tar xfzpB -
> done
> # umount /mnt
> # vnconfig -u vnd0

Oh that's useful, too - I mean the `progress` command. I assume this is
similar to `pv` on GNU/Linux? I might include this in a future version
of nfsrb2 when extracting the sets.

> and this gives me an unconfigured user-land, so some manual work
> has to be done when booted.

Same with nfsrb2, NetBSD starts in single user mode per default, OpenBSD
needs a kernel switch. This because I can't create the device files from
GNU/Linux with `MAKEDEV`, so this has to be done on the actual target
machine. NetBSD seems to do that automatically (and dynamically I
assume) on startup.

>  Also, the kernel I'm using hasn't
> hardwired the root device, so I have to supply "ld0a" as root
> file system and default swap + init.

Isn't there a kernel command line argument to provide the root FS device
like with Linux?

>  I then end up having to
>
> # mount -u /dev/ld0a /
>
> due to a missing /etc/fstab.  So this needs fixing by creating
> /etc/fstab, edit /etc/rc.conf and set rc_configured=YES and set
> up to start any non-default daemons (ntp, ssh, dhcpcd etc.).
> After that it's more or less "standard NetBSD operations".
>
> I've noticed that "reboot" doesn't work, I get thrown into ddb
> when I try to do that, so I end up having to kill qemu before I
> spin up a new one.
>
> And I'm running qemu with
>
> MEM=2g
> qemu-system-mips64el \
>          -M mipssim-virtio \
>          -m $MEM  \
>          -cpu 5Kf \
>          -kernel netbsd-MIPSSIM64 \
>          -nographic \
>          -device virtio-rng-device \
>          -drive id=hda,format=raw,file=disk.img \
>          -device virtio-blk-device,drive=hda \
>          -netdev user,id=net0,hostfwd=tcp::2224-:22,ipv6=off \
>          -device virtio-net-device,netdev=net0,mac=00:11:1e:01:02:03
>
> BTW, the 2g is optimistic from my side, I end up getting 508MB
> from NetBSD because the emulator doesn't have a way to
> communicate the amount of memory to the kernel, so the kernel
> probes for memory up to the ISA i/o memory window.
>
> The above network config makes qemu do a dhcp server, and the
> emulated host therefore needs to do dhcpcd=YES, and once that's
> done, you can ssh in to 127.0.0.1 port 2224 to log in to the
> emulated host (once you've created a non-root user via the
> console, of course).  Not entirely sure if it makes any
> difference, but different emulated systems on the same host
> should probably have different MAC addresses.

Nice write-up, I might give it a try in the future, haven't used any
MIPS64 "hardware" apart from my SGI machines, yet. BTW, where can this
port (MIPSSIM) or kernel image be found?

Cheers,
Frank