Re: Creating a hackable kernel for AMD64

[Jared Barnak <jared.j.barnak%gmail.com@localhost>]

> 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
<campbell+netbsd-tech-kern%mumble.net@localhost> wrote:
>
> > Date: Tue, 23 Apr 2024 10:52:41 -0400
> > From: Jared Barnak <jared.j.barnak%gmail.com@localhost>
> >
> > 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.