Re: Current kernel for Atari Falcon install?
Hi,
On 3/9/19 2:34 AM, Stefan Niestegge wrote:
Am 05.03.19 um 22:08 schrieb David Henderson:
A Debian 10 ISO is available here:
https://cdimage.debian.org/cdimage/ports/10.0/m68k/iso-cd/
Booting involves copying an appropriate initrd and kernel onto your HD
and running BOOTSTRAP.PRG, either taking its arguments from BOOTARGS
file.
I've not investigated how to load the initrd into alt RAM, though, as
I've not resorted to that in Hatari yet.
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.
The point where kernel I tested (4.9 m68k build I found by googling)
seems stuck, is running completely within ST-RAM despite:
- removing "-s" from bootargs, and
- uncompressing kernel before use [1]
[1] I found some really old mails that say uncompressing to happen
to ST-RAM, and using uncompressed kernel makes loading of it to
happen much faster.
I recorded the full uncut boot process:
https://www.youtube.com/watch?v=8Sriz45Z4oM
So, a trimmed down version would probably be somewhat faster.
My Falcon runs at 90 MHz and has 14MB/512MB ST/TT RAM.
Could you provide your "bootargs" file, kernel and initrd?
And if your bootstra.tos is 060 build, that too?
I'd like to try to reproduce your results with Hatari
(unlike 030 emulation, its 060 emulation is fairly untested,
but both are taken from WinUAE, so it could be good enough.)
- Eero
PS. In Hatari console doing:
symbols <kernel symbols file>
trace cpu_symbols
continue
Gives a trace of called kernel functions.
Doing:
profile on
continue
And then entering debugger again gives kernel function
callstack and all kind of profiling stats of what code
was being run, starting from in which memory area it
was running.
Callstack handling seems to be confused by something that
kernel IRQ handlers do though, as it doesn't unwind properly
(callstack looks way too deep and repetitive).
I wonder whether something in there manipulates BSR/JSR
return addresses pushed to stack (as that's one of the things
I know to confuse Hatari profiler callstack handling)?
Reply to: