| Re: [hatari-devel] NetBSD loader for Hatari |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
Hi,
On 24.7.2022 17.33, Thorsten Otto wrote:
attached is a loader for NetBSD, ported from AraNYM that i just wrote
yesterday ;)
Thanks!
It behaves similar like the ---lilo loader, taking the kernel name from the
configuration file, but it does not append any kernel commandline parameters
(since there basically aren't any; the arguments specified in the
configuration file are parsed manually and just reflect a few options of the
loadbsd program).
Now that there are two C-files doing similar things, I think elf.h stuff
could be split to a common header, instead of being inlined to both
loader files.
Symbols are available to the internal NetBSD debugger (DDB), but not yet to
the Hatari debugger. For that to work, i guess a separate tool would be needed
to extract a Symbol.map from the elf image. Or better yet, integrate that into
the loader, but that would need some work.
There's code that stuffs data to "symtab", but that does not appear to
be used anywhere?
There's copying done to Atari memory with memcpy() for segments and
symbols, but no checks whether that is valid memory range (= is there
enough RAM for it)?
I've done only a few tests with it so far, but it seems to behave almost the
same as running loadbsd from EmuTOS or TOS 4.04. That means, the kernel still
crashes at some point ;) But i think, having a loader in Hatari makes
debugging things easier, since you don't have to create a boot floppy, and
startup EmuTOS first. And of course decompressing the kernel is much faster on
the host than from emulated code.
It would be great if symbol data would work, as that's pretty much must
for debugging kernel issues (it helped hugely when debugging Linux
issues with Hatari). Rest of loader advantages are somewhat minor
compared to that.
Reset/reboot code isn't tested yet, since that would require to get at least
to some boot prompt. Maybe needs some rework compared to linux, since the
kernel relocates itself in memory, so you can't use the same entry point as
when initially loading it.
Reset code in lilo.c (copied from Aranym) does not work or Linux
either... IMHO it could be dropped from NetBSD loader until NetBSD
actually boots up in Hatari.
- Eero