Hi,
On 3/5/19 11:08 PM, David Henderson wrote:
On Tue, 5 Mar 2019, Eero Tamminen wrote:
Have Debian kernels really grown that much?
I've been looking into exactly this today. I compiled a kernel from
commit 616d4cf8ea1c370198f548a7e84f1fe90b09921b (a bit arbitrary, it was
the last atari_defconfig commit) and tried various combinations.
I established the majority of dead ends I came up with were memory
related, but indirectly. The hang in BOOTSTRAP.PRG, filling the screen
with noise, related to kernels with an initrd, but mostly CPIO variants,
suggesting there's an overhead to those.
Dropping the initial ramdisk did mean the kernel started coming up, but
sure enough it ran out of memory quite early on in the process.
I'm currently in the process of building the lightest current kernel I can.
Many years ago I tried Debian stable in Aranym with just 14MB of memory.
Kernel itself wasn't the problem, but Debian user-space was. After
logging in, there was only 1-2MB free RAM. Replacing Bash with
something leaner, removing *everything* from boot that's not absolutely
needed (logging etc), and building more minimal kernel config could
help.
Yes, I had a functioning install with a 2.x kernel, but yes, it was
slow. I can't recall if it was etch, potato or even earlier than that.
=> I would suggest preparing suitable stripped down / configured Debian
installation in emulator before trying it on real (16Mhz/14MB) HW.
Latest Hatari 2.2.x version in Debian "should" have good enough
TT & Falcon / 030 / MMU emulation to run Linux, and it supports
TT-RAM also with Falcon:
hatari --tos tos404.img --machine falcon -s 14 --ttram 32 --addr24 off
--ide-master <IDE image> <linux boot floppy image>
Yes, cheers. I've moved over to Hatari to carry out these tests.
Interestingly one of the old kernels gets further on Hatari than on my
actual Falcon when set up the same and booting from the same media, but
that's an investigation for another day!
Few other comments:
* Hatari 2.2 has regression in UNPK instruction emulation, but I
think it's mainly used when dealing with BCD numbers, so hopefully
not relevant for Linux booting. I've filed bug about upgrading
Debian Hatari version to v2.2.1 where this is fixed, but until
that you might want to build your own Hatari version:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923833
* I'm assuming that Linux doesn't use DSP for anything. Hatari
fast-forward [1] works much faster if you disable Falcon DSP
(--dsp none/dummy)
[1] "--fast-forward yes" option and AltGr-X keyboard shortcut.
If somebody can provide links to suitable images for latest debian m68k
images & kernels and short instructions how to boot them, I could
debug things a bit with Hatari.
A Debian 10 ISO is available here:
https://cdimage.debian.org/cdimage/ports/10.0/m68k/iso-cd/
While that should be fine for bootup testing, I don't think install
itself would work with 14MB, as packaging tools can require very
large amounts of RAM. :-)
(And net install would require networking i.e. Aranym.)
Booting involves copying an appropriate initrd and kernel onto your HD
and running BOOTSTRAP.PRG, either taking its arguments from BOOTARGS file.
Thanks!
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?
In Hatari you can profile where the code is running.
Use AltGr-Pause to invoke console debugger, and type:
profile on
c # for continue
After a while, invoke debugger again and profiler tells
(among other things) in which memory areas code had been running.
- Eero
PS. To get bootloader itself to alt-RAM, its program header needs
to have flag set that tells TOS it should be loaded there.
"gst2ascii" utility installed with Hatari shows Atari program
header flags. I think the relevant flag is TTRAMLOAD.
(Atari GCC installs include "flags" program to change the flags,
but if it's not set for program already, it probably won't work
from there.)
