[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: m68k kernel under Hatari


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:

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
$00008230 : 7301                               DC.W      $7301
$00008232 : 4e75                               rts
$00008234 : 7000                               moveq     #0,d0
$00008236 : 4e75                               rts

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:

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().


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?


I unpacked the deb with 'ar' and found './boot/config-5.0.0-trunk-m68k'
in 'data.tar.xz'.


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

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.

Reply to: