> Cool, thanks! The main thing you're trying to do -- pass a kernel on > the command line to qemu -- doesn't work on x86. It does work on > aarch64 (arm64), which is why I used that as the example here:
> https://www.netbsd.org/gallery/presentations/riastradh/eurobsdcon2023/getstarted.pdf#page=30 Whoops! Not sure how I missed that. Thanks! > It also works on riscv and alpha, and possibly some others -- but not > x86. So if you want to run x86, it's a little different. We should > really reduce these differences, but for now this is what you'll have > to do: This makes much more sense. Genuinely appreciate it! > netbsd-DEBUG_KERNEL.gz is just a kernel, not a whole disk image with > bootloader, userland, and so on. What you want is a live disk image. > > On aarch64, build.sh release leaves a live disk image in > $RELEASEDIR/evbarm-aarch64/binary/gzimg/arm64.img.gz, but on x86 the > live image works differently -- you need to do: > ./build.sh ... live-image > and then you'll find it at > $RELEASEDIR/images/NetBSD-10.99.XXX-amd64-live.img.gz > This you can just gunzip and pass as a raw disk image to qemu. This makes it much easier! Is there any reason that: ``` qemu-img create -f qcow2 disk.img 10G ``` > For amd64 we don't build netbsd.img -- the kernel image is just called > `netbsd'. (On aarch64, there is a netbsd.img as well as netbsd, and > some important difference between them that I don't remember the > details of.) Okie dokie! Might do my development in VMWare or Virtualbox. In that case, I might need to: ``` build.sh iso-image-source ``` And just to clarify, `iso-image-source` is needed to retuin the debug information when the kernel was compiled with `kernel.gdb=DEBUG_KERNEL` (`DEBUG_KERNEL` being my configuration for a debuggable kernel). Or am I misunderstanding `src/BUILDING`? > (Might want to use /bin/sh here, unless you really do have a > /urs/bin/sh?) Thanks for catching this! Promptly fixed > Right -- passing a kernel image on the command line isn't supported > yet on amd64. It does work on aarch64 (arm64), riscv, and alpha, but > not amd64, which is why I added this note: > > https://www.netbsd.org/gallery/presentations/riastradh/eurobsdcon2023/getstarted.pdf#page=32 > > When I'm doing kernel development under qemu, I usually use aarch64 or > alpha because of this, not x86. > > When I do use x86 under qemu, and I need to update the kernel, I serve > it from the host by serving the objdir via http, and download it into > the guest with the ftp(1) command, like: > > host$ cd ~/netbsd/current/obj.amd64 > host$ /usr/libexec/httpd -b -f -s -I 54321 -X . > > guest# ftp -o /netbsd.new > http://169.254.123.45:54321/sys/arch/amd64/compile/DEBUG/netbsd > guest# mv /netbsd /onetbsd > guest# mv /netbsd.new /netbsd Super helpful! Thanks so much! I genuinely appreciate the response! On Tue, Apr 23, 2024 at 11:39 AM Taylor R Campbell <[email protected]> wrote: > > > Date: Tue, 23 Apr 2024 10:52:41 -0400 > > From: Jared Barnak <[email protected]> > > > > I watched "How to get started hacking NetBSD" and it was great, I just > > noticed that some things didn't work when cross compiling for amd64. and > > frankly, I'm not sure what I did wrong. > > Cool, thanks! The main thing you're trying to do -- pass a kernel on > the command line to qemu -- doesn't work on x86. It does work on > aarch64 (arm64), which is why I used that as the example here: > > https://www.netbsd.org/gallery/presentations/riastradh/eurobsdcon2023/getstarted.pdf#page=30 > > It also works on riscv and alpha, and possibly some others -- but not > x86. So if you want to run x86, it's a little different. We should > really reduce these differences, but for now this is what you'll have > to do: > > > I unzipped the `netbsd-DEBUG_KERNEL.gz` file and redirected the output to > > `vm/disk.img` with: > > > > ``` > > gunzip -c <netbsd-DEBUG_KERNEL.gz > ~/Projects/netbsd/vm/disk.img > > ``` > > netbsd-DEBUG_KERNEL.gz is just a kernel, not a whole disk image with > bootloader, userland, and so on. What you want is a live disk image. > > On aarch64, build.sh release leaves a live disk image in > $RELEASEDIR/evbarm-aarch64/binary/gzimg/arm64.img.gz, but on x86 the > live image works differently -- you need to do: > > ./build.sh ... live-image > > and then you'll find it at > > $RELEASEDIR/images/NetBSD-10.99.XXX-amd64-live.img.gz > > This you can just gunzip and pass as a raw disk image to qemu. > > > And I cannot figure out why, but I don't have a `netbsd.img` under > > > > /home/jared/Projects/netbsd/obj/sys/arch/amd64/compile > > For amd64 we don't build netbsd.img -- the kernel image is just called > `netbsd'. (On aarch64, there is a netbsd.img as well as netbsd, and > some important difference between them that I don't remember the > details of.) > > > so the following does not work: > > > > ``` > > #!/urs/bin/sh > > (Might want to use /bin/sh here, unless you really do have a > /urs/bin/sh?) > > > /usr/bin/qemu-system-x86_64 \ > > -kernel netbsd.img \ # This file does not exist > > Right -- passing a kernel image on the command line isn't supported > yet on amd64. It does work on aarch64 (arm64), riscv, and alpha, but > not amd64, which is why I added this note: > > https://www.netbsd.org/gallery/presentations/riastradh/eurobsdcon2023/getstarted.pdf#page=32 > > When I'm doing kernel development under qemu, I usually use aarch64 or > alpha because of this, not x86. > > When I do use x86 under qemu, and I need to update the kernel, I serve > it from the host by serving the objdir via http, and download it into > the guest with the ftp(1) command, like: > > host$ cd ~/netbsd/current/obj.amd64 > host$ /usr/libexec/httpd -b -f -s -I 54321 -X . > > guest# ftp -o /netbsd.new > http://169.254.123.45:54321/sys/arch/amd64/compile/DEBUG/netbsd > guest# mv /netbsd /onetbsd > guest# mv /netbsd.new /netbsd > > > I'm also not sure what to substitute `-cpu` for when using `amd64`. > > No need, default should work fine.
