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

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



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

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


Could somebody give a pointer to latest v5.x based Debian
unified m68k kernel config I should test?

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


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


On 3/11/19 1:12 AM, Eero Tamminen wrote:
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)?


Linux version 5.0.0hatari-ge7c682ba6 (eero@sonata) (gcc version 6.3.0 20170516 (Debian 6.3.0-18)) #2 Wed Apr 3 00:24:55 EEST 2019
printk: console [nfcon0] enabled
Atari hardware found: VIDEL STDMA-SCSI ST_MFP YM2149 PCM CODEC DSP56K SCC ANALOG_JOY BLITTER IDE TT_CLK FDC_SPEED
On node 0 totalpages: 3584
  DMA zone: 32 pages used for memmap
  DMA zone: 0 pages reserved
  DMA zone: 3584 pages, LIFO batch:0
NatFeats found (Hatari, 1.0)
pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
pcpu-alloc: [0] 0 
Built 1 zonelists, mobility grouping off.  Total pages: 3552
Kernel command line: video=atafb:sthigh console=tty debug=nfcon console=tty ro root=/dev/hda init=/init BOOT_IMAGE=vmlinux
Dentry cache hash table entries: 2048 (order: 1, 8192 bytes)
Inode-cache hash table entries: 1024 (order: 0, 4096 bytes)
Sorting __ex_table...
Memory: 9828K/14336K available (2360K kernel code, 243K rwdata, 548K rodata, 116K init, 106K bss, 4508K reserved, 0K cma-reserved)
SLUB: HWalign=16, Order=0-3, MinObjects=0, CPUs=1, Nodes=8
NR_IRQS: 141
Console: colour dummy device 80x25
Linux version 5.0.0hatari-ge7c682ba6 (eero@sonata) (gcc version 6.3.0 20170516 (Debian 6.3.0-18)) #2 Wed Apr 3 00:24:55 EEST 2019
printk: console [nfcon0] enabled
Atari hardware found: VIDEL STDMA-SCSI ST_MFP YM2149 PCM CODEC DSP56K SCC ANALOG_JOY BLITTER IDE TT_CLK FDC_SPEED
On node 0 totalpages: 3584
  DMA zone: 32 pages used for memmap
  DMA zone: 0 pages reserved
  DMA zone: 3584 pages, LIFO batch:0
NatFeats found (Hatari, 1.0)
pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
pcpu-alloc: [0] 0 
Built 1 zonelists, mobility grouping off.  Total pages: 3552
Kernel command line: video=atafb:sthigh console=tty debug=nfcon console=tty ro root=/dev/hda init=/init BOOT_IMAGE=vmlinux
Dentry cache hash table entries: 2048 (order: 1, 8192 bytes)
Inode-cache hash table entries: 1024 (order: 0, 4096 bytes)
Sorting __ex_table...
Memory: 9828K/14336K available (2360K kernel code, 243K rwdata, 548K rodata, 116K init, 106K bss, 4508K reserved, 0K cma-reserved)
SLUB: HWalign=16, Order=0-3, MinObjects=0, CPUs=1, Nodes=8
NR_IRQS: 141
Console: colour dummy device 80x25
printk: console [tty0] enabled
Calibrating delay loop... 4.32 BogoMIPS (lpj=21632)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
devtmpfs: initialized
random: get_random_u32 called from bucket_table_alloc+0x140/0x166 with crng_init=0
clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
futex hash table entries: 256 (order: -1, 3072 bytes)
NET: Registered protocol family 16
random: fast init done
SCSI subsystem initialized
libata version 3.00 loaded.
NET: Registered protocol family 2
tcp_listen_portaddr_hash hash table entries: 512 (order: 0, 4096 bytes)
TCP established hash table entries: 1024 (order: 0, 4096 bytes)
TCP bind hash table entries: 1024 (order: 0, 4096 bytes)
TCP: Hash tables configured (established 1024 bind 1024)
UDP hash table entries: 256 (order: 0, 4096 bytes)
UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
NET: Registered protocol family 1
workingset: timestamp_bits=27 max_order=12 bucket_order=0
squashfs: version 4.0 (2009/01/31) Phillip Lougher
romfs: ROMFS MTD (C) 2007 Red Hat, Inc.
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 251)
io scheduler mq-deadline registered
atafb_init: start
atafb_init: initializing Falcon hw
atafb: screen_base (ptrval) phys_screen_base 35c000 screen_len 69632
Determined 640x400, depth 1
   virtual 640x870
Console: switching to mono frame buffer device 80x25
fb0: frame buffer device, using 68K of video memory
lp: driver loaded but no devices found
Non-volatile memory driver v1.3
parport0: Atari built-in port using irq
parport0: fix this legacy no-device port driver!
lp0: using parport0 (interrupt-driven).
Atari floppy driver: max. HD, track buffering
Probing floppy drive(s):
fd0
fd1
brd: module loaded
loop: module loaded
dummy-irq: no IRQ given.  Use irq=N
Uniform Multi-Platform E-IDE driver
ide: Falcon IDE controller
Probing IDE interface ide0...
hda: Hatari IDE disk 4M, ATA DISK drive
IDE: CMD to non-existant IDE device #1!
IDE: CMD to non-existant IDE device #1!
ide0 at 0xfff00000 on irq 15 (serialized)
ide-gd driver 1.18
hda: max request size: 1024KiB
hda: 8192 sectors (4 MB) w/256KiB Cache, CHS=8/255/63
hda: cache flushes supported
scsi host0: Atari native SCSI, irq 15, io_port 0x0, base 0x0, can_queue 1, cmd_per_lun 2, sg_tablesize 0, this_id 7, flags { }
pata_falcon: Atari Falcon PATA controller
pata_falcon: resources busy
blk_queue_max_segments: set to minimum 1
NET3 PLIP version 2.4-parport gniibe@mri.co.jp
plip0: Parallel port at 0xffff8802, using IRQ 8.
PPP generic driver version 2.4.2
PPP Deflate Compression module registered
blk_queue_max_segments: set to minimum 1
mousedev: PS/2 mouse device common for all mice
input: Atari Keyboard as /devices/virtual/input/input0
blk_queue_max_segments: set to minimum 1
input: Atari mouse as /devices/virtual/input/input1
input: m68k beeper as /devices/platform/m68kspkr/input/input2
blk_queue_max_segments: set to minimum 1
rtc-generic rtc-generic: registered as rtc0
softdog: initialized. soft_noboot=0 soft_margin=60 sec soft_panic=0 (nowayout=0)
Atari DMA sound driver rev 016 installed
Core driver edition 01.06 : FALCON driver edition 00.03
Write will use    4 fragments of   32768 bytes as default
NET: Registered protocol family 17
blk_queue_max_segments: set to minimum 1
rtc-generic rtc-generic: setting system clock to 2019-04-03T01:05:28 UTC (1554253528)
blk_queue_max_segments: set to minimum 1
blk_queue_max_segments: set to minimum 1
VFS: Mounted root (ext2 filesystem) readonly on device 3:0.
devtmpfs: mounted
Freeing unused kernel memory: 116K
This architecture does not have kernel memory protection.
Run /init as init process
WARN : Your system is too slow, some sound samples were not correctly emulated
random: crng init done

Reply to: