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

Re: m68k kernel under Hatari (was: Current kernel for Atari Falcon install?)



On Wed, 3 Apr 2019, Eero Tamminen wrote:

> Hi,
> 
> 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.

> I'm using reduced kernel config with Geert's kernel m68k-v5.0 branch
> and a small rootfs made out of the latest m68k port busybox-static
> package, few symlinks and trivial init script:
> https://git.tuxfamily.org/hatari/hatari.git/tree/tools/linux/
> 
> Boot log is attached.
> 
> 
> 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.
> 
> 
> 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?

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

> 
> 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'.

> And ataboot & bootstra.prg programs sources?  There's something
> I'd like to check about LILO memory area config setups.
> 

No idea, sorry.

-- 

> 
> 	- Eero
> 
> [1]: debug console output:
> ----------------------------------------------------------
> ...
> Run /init as init process
> *** ILLEGAL INSTRUCTION ***   FORMAT=0
> Current process id is 30
> BAD KERNEL TRAP: 00000000
> PC: [<0012fca4>] strncpy_from_user+0x5c/0xe4
> SR: 2200  SP: (ptrval)  a2: 00877700
> d0: 00000000    d1: 2f737973    d2: 00000ff0    d3: 00000ff0
> d4: 00000000    d5: 00000000    a0: 00000ff0    a1: 80155c8c
> Process cttyhack (pid: 30, task=(ptrval))
> Frame format=0
> Stack from 009c1f1c:
>   80155c04 80155c8c 00000000 8017b201 ffffff49 00850000 009c1f60 0009aa56
>   00850010 80155c8c 00000ff0 80155c04 00020000 00000000 efe12d4d 80170f52
>   801712bc 009c1f74 0009ab5a 80155c8c 00000000 00000000 009c1fac 00091098
>   80155c8c 80155c8c 00020000 00000000 8017b201 efe12d4d 80170f52 efe10002
>   00000000 00000004 00000100 00000001 009c1fc4 000911ce ffffff9c 80155c8c
>   00020000 00000000 efe12d68 00002874 ffffff9c 80155c8c 00020000 00000000
> Call Trace: [<0009aa56>] getname_flags+0x42/0x134
>  [<00020000>] _I_CALL_TOP+0xd80/0x1900
>  [<0009ab5a>] getname+0x12/0x18
>  [<00091098>] do_sys_open+0xc2/0x1b0
>  [<00020000>] _I_CALL_TOP+0xd80/0x1900
>  [<000911ce>] sys_openat+0x22/0x26
>  [<00020000>] _I_CALL_TOP+0xd80/0x1900
>  [<00002874>] syscall+0x8/0xc
>  [<00020000>] _I_CALL_TOP+0xd80/0x1900
> Code: 9480 7203 b282 645a 2805 0eb1 1000 0800 <4a84> 664e 2781
> 0800 2801 0084 7f7f 7f7f 2c04 4686 2401 0682 fefe feff c486 6748
> Disabling lock debugging due to kernel taint
> ----------------------------------------------------------
> 
> 


Reply to: