Hi Eero and Stefan,
Hi, On 3/6/19 12:04 AM, David Henderson wrote: I've not investigated how to load the initrd into alt RAM, though, as I've not resorted to that in Hatari yet.
Doesn't bootloader do that automatically or have some option for it?
Looking at the help text, it would appear you have to explicitly tell it to load to ST-RAM, so alt-ram is probably the default.
According to some other docs I read, things are loaded to TT-RAM, but *uncompressed* to ST-RAM. So it's better to use uncompressed vmlinuz and initrd files. That way they don't need to be uncompressed and load (much) faster.
Either way, I couldn’t get the Debian 10 ISO version to boot in Hatari. Obviously it was too big for the real Falcon.
Give Hatari "--trace os_base" option to get the TOS boot program output to terminal.
<snip detailed explanation of Hatari debugging>
Thanks, Eero, but kernel debugging via Hatari is a bit beyond me a the moment.
I installed Debian from that netinstall. Only thing to do to get it install was getting IDE port running by modprobe falconide or patafalcon. Don't And removing -s from the bootargs puts the kernel into TT ram which speeded up things a lot. I recorded the full uncut boot process: https://www.youtube.com/watch?v=8Sriz45Z4oMSo, a trimmed down version would probably be somewhat faster. My Falcon runs at 90 MHz and has 14MB/512MB ST/TT RAM.
Thanks Stefan,
That’s interesting and does suggest perhaps it’s a processor issue. Obviously I can’t address that sort of memory, but even adding AltRAM to Hatari when otherwise set to maximum Falcon compatibility hangs in the same way.
I’ve put together a video showing my experiments with Debian 10 too:-
I think changing my partition scheme and having a go with Debian 9 are next on my list.
(BTW, not shown on my videos was my other line of enquiry: putting Debian Potato on as well — that installed, but would frequently BUSERR out, often when just doing simple things [like ls -l]. Same on Hatari. Perplexing.)
Regards,
David.
|