Re: 43p: Install kernel boots, generic not

[David Brownlee <abs%netbsd.org@localhost>]

On Mon, 15 Jul 2019 at 18:52, Ulrich Teichert <lists%ulrich-teichert.de@localhost> wrote:
> > Taking a quick dig into sys/arch/prep/stand.  boot/conf.c seems to indicate
> > the NetBSD/prep bootloader only supports booting from scsi, and
> > specifically from the copy of boot/siop.c which is driving the 53c810
> > chipset directly
>
> Yes, but that code isn't working and according to the commit message was
> only experimental. See the thread:
>
> "NetBSD 8.10 does not boot on 7043-140"
>
> My first mail to this group on the 31.5.... The solution is in:
> <201907011749.x61Hn5ea003050%valdese.nms.ulrich-teichert.org@localhost>
> same thread.
>
> BTW, should I mail the port-prep maintainer the patch? What would be
> the preferred process to get that one-line patch integrated into the code?

That would probably be fine - for the older ports activity tends to
run in infrequent short busts :)

> > If Kernels <2M can be booted from the NetBSD bootload prompt (is this the
> > case?) then that implies one of
> > - The NetBSD bootloader code has issues reading files >2MB
> > - Its loading into an area of memory which is only contiguous only up to 2M
> > - Something else is happening which I missed :)
> [del]
>
> It's something else ;-) The bootloader with the attached kernel gets loaded
> by the firmware and just unpacks the kernel to the start address. If that
> file (which is the product of mkbootimage) is over 2MB, the firmware seems
> to have a wrap-around and overwrites the already written bytes in memory.

<ah> understanding dawns... Thanks for your patience :)

> I've played with yaboot, but that code only builds on Linux and looks
> un-maintained. After fixing a few issues, I could get the grub2 build
> running, but I was too tired yesterday evening...

If grub2 runs on the platform and supports loading files then it would
be useful to fixup support for loading NetBSD kernels. Don't let any
random other ideas thrown at you distract you from the hacking you
want to do...

As for NetBSD bootloader scsi support. I strongly suspect the scsi
code in stand/boot is a simplified version of the kernel scsi driver
(or likely a copy of the another port's boot code which was itself a
simplified version of the kernel scsi driver :). Given the NetBSD
kernel can access the scsi device without issue it should be possible
to fixup, but is maybe not the most accessible coding challenge :)

Another (albeit relatively random) option might be to implement
kloader (as used on some other ports). This is the mechanism where a
running kernel can load and reboot into another kernel - so the
initial bootloader would be a minimal kernel with only enough drivers
to load the real kernel from disk and reboot into it.

Good hacking :)

David