AmigaOS 3.2 kickstart ROM crashing with NetBSD boot blocks

[abs]

When 3.2 kickstart ROM sees a disk with a NetBSD boot block it crashes as in the attached image. 3.1 seems fine.



Apparently its related to a rom component which scans all drives for updated modules, and then crashes on a NetBSD partition.


Does anyone have any more insight into what is happening, and/or any thoughts on if something could be tweaked on the NetBSD side to avoid triggering this issue? (if someone has ideas I can push them back in on the NetBSD side



Thanks


David

[abs]

Alternatively - does anyone have permission to open a thread in https://forum.hyperion-entertainment...forum.php?f=62 to feed back there?

[coldacid]

I think enough of the 3.2 dev team hangs out here that a thread on the Hyperion boards isn't needed.

[Thomas Richter]

This alert is not generated by any of the kickstart components. It does not look as if it is even allocated or formatted correctly. For interpreting alert codes, please see exec/alerts.h.

Thus, I would instead assume that this alert is generated by the NetBSD boot code (probably by someone not aware of proper alert code allocation), and would check there why exactly it is thrown.

[Chain-Q]

According to this site:

https://wiki.amigaos.net/wiki/Unders...bers#BootStrap

0x30000001 Recoverable Boot code returned an error

It's generated by "bootstrap" and caused by the boot code returning an error. So while it's indeed the boot code causes this, the alert is surely generated outside the boot code itself, as the NetBSD boot code never calls exec.library/Alert().

Now, looking at the early startup of the NetBSD boot code, it makes some assumptions about register and stack layout at the point the boot code is called. Then goes ahead, and uses these to call various OS calls, among others a memory allocation and some IO stuff. If either of these fails, the boot block returns with an error code.

I guess if KS3.2.x no longer fulfills the stack/register layout expectations of the boot code, on entry, this might cause the issue. But of course this is entirely a speculation.

[abs]

Originally Posted by Chain-Q

[...]
Now, looking at the early startup of the NetBSD boot code, it makes some assumptions about register and stack layout at the point the boot code is called. Then goes ahead, and uses these to call various OS calls, among others a memory allocation and some IO stuff. If either of these fails, the boot block returns with an error code.

Excellent - so its most likely fixable by "just" updating the NetBSD boot code (which is built as a "normal" NetBSD binary using a set of stubs:
https://nxr.netbsd.org/xref/src/sys/...oot/libstubs.s
then adjusted to be suitable for loading by AmigaOS (full code at https://nxr.netbsd.org/xref/src/sys/...and/bootblock/ ) rather than needing any changes at the Kickstart end.



Now just need to find an Amiga/m68k coder who likes a little assembly challenge (though insight from someone familiar with the changes between KS 3.1 and 3.2 would be a big help)


Thanks

[Thomas Richter]

One of the things that did change (but already with 3.1.4) was that an entire 32K of low memory stays reserved, instead of just 4K or 1K as in previous kickstarts. If that should be an issue, you can run this tool:

https://aminet.net/package/util/boot/MoveLow

to make exec start at the same location as under 3.1 and before. It is at least worth a try.

[Chain-Q]

Actually, my initial hypothesis was wrong, on Kickstart 3.2.x the bootblock gets to the point where it wants to open console.device (it uses that to show its own messages, then optionally also read in kernel arguments from the user), but that OpenDevice seems to fail with -1.

Video:
https://twitter.com/chainq/status/1639581705332748291

Original source location:
https://nxr.netbsd.org/xref/src/sys/.../console.c#141

Patch to show the debug requester:
https://gist.github.com/chainq/0b1a6...3d9749de2d087c

Again, I'm not very good at debugging at this level, but with my basic tools I got this far showing where the issue comes from. I let the people actually good at this come up with a solution.

[Thomas Richter]

Does it work if you boot with ROM-Updates disabled (see the boot menu?) Do you have something in L: that is named con-handler or something in DEVS: that is named console.device? If so, which version and where did it come from? Edit: There is at least one defect in this code. The io->Length field is not filled in. See: https://amigadev.elowar.com/read/ADC.../node0084.html I suggest to fix that first.

[Chain-Q]

There's nothing on the disk, there is no AmigaOS partition/filesystem at all. There's a single HDF, that has a single RDB partition, with the NetBSD miniroot.fs written into it. Booting the miniroot bootblock is the first and only choice. If I only swap out the Kickstart ROM image to v40.68, it works.

Edit: I'm ahead of you still. If you look at my patch, it actually fills out the length field by the size of the window structure (that is 136 bytes, AFAICT). The name is different, because the code doesn't use the AmigaOS SDK to compile, but whatever, supplying the size did not make any difference. But yes, I'll propose this change anyway, going forward.

[Chain-Q]

If anyone feels like debugging this from the Kickstart side, I uploaded the same hardfile I made that Twitter-video with, see the URL below. It contains my debug-bootblock with the error-requester. I can also make custom builds with more debug, if that helps, just someone tell me what to modify.

http://charlie.amigaspirit.hu/temp/p...sd-hack.hdf.xz

[Toni Wilen]

It looks like console.device was moved to priority -120 in KS 3.2+. Previously it had priority +5 (=initialized before strap). This can be easily seen in UAE TR debugger command that lists all residents.

I traced it in emulation and OpenDevice() internally calls FindName() which returns zero because console.device is not yet initialized.

[Thomas Richter]

Ah, Toni, right, thank you. Indeed, console moved post-strap, the reason being that System-Startup can update it. It is actually not used before. What you can do is a FindResident() on the console.device, and an InitResident() on it, then you should be ready to go. Of course, booting off the boot block and thus bypassing System-Startup will disable the automatic ROM-Updates, but that probably does not matter for NetBSD.

[Chain-Q]

Thanks Toni for the analysis and Thomas for the workaround idea/proposal. I quickly patched together some code that does this, and it indeed seems to work. I will clean it up, then share the patch here and on the NetBSD ML.

Edit: Patch here: https://gist.github.com/chainq/c2ae1...2f6ea1f6fa88cc

[phx]

Good job! Thanks.
I was trying to set up a hardfile myself today for debugging, but ran into some problems (E-UAE needs a valid RDB in the image to recognize it).

Either abs or myself can commit your patch, as soon as you are happy with it.

[Chain-Q]

@phx
Yes, I also ran into this problem, so I used rdbtool from amitools[1] to generate me an RDB disk image quickly. From then on it was recognized as a HDD, not a partition image.

I'm good with the patch as-is, and don't intend to modify it any further, unless someone points out problems with it. If there are any other problems with the bootblock to be fixed, they should be a different patch. Review and criticism is welcomed as usual, I'm just a Pascal programmer, I have no idea what I'm doing with them curly braces.

[1]: https://github.com/cnvogelg/amitools

[a4k-oerx]

Originally Posted by Thomas Richter

This alert is not generated by any of the kickstart components.

@all: So do we know after all the debugging where exactly the alert is generated?

Thanks for all input, interesting read and solution, tried to install NetBSD yesterday to investigate a bit myself but time and skill were not sufficient.

[Chain-Q]

@a4k-oerx:
Yes. As I wrote at the start of post #5, the Alert was generated by bootstrap in the ROM after the bootblock's initialization code failed, and returned with a non-zero exit code. After the debugging we now know that it was unable to open console.device, and it was unable to open console.device because on "modern" Kickstarts it is not initialized at the time bootblock is invoked.

The patch adds a workaround for this, by trying to initialize console.device on its own, if opening it is unsuccessful, so this entire chain of events doesn't happen.

[Toni Wilen]

Is there any reason to fail booting if console.device open fails? Just keep booting normally (NetBSD takes over the system anyway) without showing any messages?

[Chain-Q]

It also provides a way to enter/modify kernel arguments and parameters. I mean, probably it can be made to just boot anyway, but there are other ways to boot NetBSD, if the bootblock fails - there's a loadbsd command that can load the kernel from an Amiga FS, and even a runbootblock[1], where one can run the bootblock from a shell, this also worked on v47 Kickstarts too, of course.

[1] https://cdn.netbsd.org/pub/NetBSD/Ne...allation/misc/