Hi,
On 4/3/19 9:23 AM, Finn Thain wrote:
On Wed, 3 Apr 2019, Eero Tamminen wrote:
I've added LILO support to Hatari (based on Aranym) and instructions
how get a working m68k Linux setup that works with Hatari:
https://git.tuxfamily.org/hatari/hatari.git/tree/doc/m68k-linux-for-hatari.txt
Thanks for this! It's great to finally be able to boot Linux in an
emulated '030. I do have a need for that from time to time.
If you have any questions about Hatari usage, just mail me.
While Hatari could have run Linux earlier with bootstra.prg, I think
the main convenience with the lilo functionality is automatic loading
of kernel symbols for debugging (when symbol file is specified in
lilo config).
Just remember to build kernel with NF console for debug output, as
it's also easy way to check that symbols got loaded to correct address:
------------------
> d nf_call
nf_call:
$00008230 : 7301 DC.W $7301
$00008232 : 4e75 rts
$00008234 : 7000 moveq #0,d0
$00008236 : 4e75 rts
nf_get_id:
...
------------------
I haven't yet debugged why full, modularized Debian kernel with
initrd doesn't boot, until that it's better to use minimal kernel
with everything built in.
[...]>> So far there there are a couple of minor issues I've noticed on
Hatari
side, but most of the issues seem to be on the kernel side.
For example, a crash [1] triggered by Busybox setsid, when I tried
"setsid cttyhack sh" hack recommended for getting job control working in
init console.
That particular issue happens *only* when 030 cache emulation is
enabled, so it cannot be reproduced with Aranym or qemu, only with
WinUAE, Hatari or real HW.
I'd be interested if somebody can reproduce that on real 030 Falcon HW.
This tarball contains 4MB EXT-2 rootfs which has just busybox-static:
http://eerott.mbnet.fi/hatari/packages/m68k-linux-v5.tar.gz
One doesn't need to boot with it, it's enough just to mount and
chroot to it (no need even to mount proc & dev to chroot),
and then run:
setsid cttyhack sh
As an example of Hatari profiling, this is kernel profile from
Busybox shell idling:
----------------------------------------------------------
...
Time spent in profile = 17.00207s.
...
Used cycles:
77.29% 210826296 arch_cpu_idle (aka "stop #$2200")
2.35% 6422992 update_wall_time
1.96% 5336780 memcpy
1.42% 3863404 add_interrupt_randomness
...
Very interesting... Can the CPU be under-/over-clocked in Hatari?
To an extent, but Hatari supports only 8, 16 and 32Mhz
(this restriction is due to accuracy).
One can specify any CPU type with any of the machine types.
E.g. Linux boots fine using ST with any of 030/040/060 CPUs.
:-)
TT boot hanged (I'm going to look into that next), as did
trying to boot Falcon with anything else than 030.
=> I'm wondering whether kernel code makes some assumptions
about Falcon with 040 / 060 being e.g. AfterBurner instead
of "original" Falcon.
Executed instructions:
11.90% 555273 memcpy
10.11% 471490 update_wall_time
6.94% 323800 add_interrupt_randomness
4.55% 212375 __ashldi3
3.68% 171599 ktime_get_update_offsets_now
3.24% 151187 __do_softirq
...
Instruction cache misses:
10.54% 180714 update_wall_time (*)
6.84% 117300 add_interrupt_randomness
5.04% 86457 memcpy
3.67% 62863 ktime_get_update_offsets_now
3.50% 59948 __do_softirq
...
Data cache hits:
14.34% 108409 __ashldi3
10.12% 76539 update_wall_time
7.28% 55038 add_interrupt_randomness
7.17% 54201 memcpy
...
----------------------------------------------------------
(*) besides being huge (due to static functions GCC inlines?),
this jumps around the memory a lot.
BTW, Geert's tree now has some patches I wrote to drop
ARCH_USES_GETTIMEOFFSET for m68k, which will affect update_wall_time().
Thanks!
I'll update my source tree once 5.2 is tagged and re-profile.
Could somebody give a pointer to latest v5.x based Debian
unified m68k kernel config I should test?
http://ftp.kr.debian.org/debian-ports//pool-m68k/main/l/linux/linux-image-5.0.0-trunk-m68k_5.0.2-1%7eexp1_m68k.deb
I unpacked the deb with 'ar' and found './boot/config-5.0.0-trunk-m68k'
in 'data.tar.xz'.
Thanks.
I tried that config with 's/=m/=y/' which failed miserably.
It produced 16MB (stripped) kernel [1], which on boot didn't
output anything, even with initcall_debug.
When I profiled it, it was spending large part of its time in
lib/mpi/ crypto code. How crypto code can get called before
kernel does any debug output (to nfcon)?
After looking into TT boot issue with minimal config, I will
continue by checking modular version of the full config
(whether that can boot to minimal initrd shell).
- Eero
[1]
After disabling WLAN, BT and FS crypto options, and all crypto
options that can be disabled after that (= about half of them),
kernel size got down to 12MB. It still didn't boot when loaded
to ST-RAM though.
When loaded to TT-RAM, it actually does something. After outputting
for many minutes [2] initcall_debug stuff (doesn't repeat same things),
it panic'd.
[2] Minimal kernel boots to shell in 20s.
And ataboot & bootstra.prg programs sources? There's something
I'd like to check about LILO memory area config setups.
No idea, sorry.
