m68k-linux.txt

Contents:

1. Introduction
1.1 Notation
2. Hatari issues
3. Building m68k kernel
4. Building root file system
4.1 As EXT2 HD image, from BusyBox
4.2 As EXT2 HD image, from klibc utils
5. Building initrd
6. Running Hatari
7. Native bootstrap
8. Debugging and profiling
8.1 Kernel debugging
8.2 User-space debugging
9. Debian m68k install
9.1 Debian installer
9.2 Running initrd as normal disk
9.3 Bootstrapping Debian installation on PC
10. Linux kernel issues
10.1 Known issues with workarounds
10.2 TODO / investigate more


1. Introduction
---------------

Here are instructions on building m68k Linux:
- kernel
- ramdisk
- root file system

And using them with Hatari.

Build instructions are for Debian as that is the only Linux distribution
still building latest SW package versions for m68k, in ports:
	http://ftp.ports.debian.org/debian-ports/pool-m68k/main/

But m68k gcc is available also on other distributions, along with
tools for building the images (from packages in Debian ports).


1.1 Notation
------------

In examples, different execution environments are indicated by prompts:
	$ -- shell prompt
	# -- root shell prompt
	> -- Hatari debugger prompt

"wget" examples do not give exact package names because versions in
them change frequently. Replace "*" in those file names with the
version available in the given remote directory!


2. Hatari issues
----------------

- LILO reset code has not yet been updated from Aranym's Falcon
  AfterBurner behavior to normal Falcon (they use different reset
  addresses), so "reboot" command fails with LILO

- PC address points to ST-RAM in debugger even for emulated Linux
  code running in TT-RAM, because it is not MMU-translated
  => workaround: load Linux to ST-RAM when debugging/profiling

- There are lot of ("--log-level debug" and profiler) warnings about
  memory accesses to >2GB range when programs do syscalls. An issue
  with Hatari high address memory setup, or another symptom of
  missing MMU-translation within Hatari?
  DEBUG: Your Atari program just did something terribly stupid: dummy_xlate($c00123ee)

- Incomplete SCSI emulation:
  => workaround: have root file system on IDE master or slave

  Rootfs mount from SCSI device fails after following debug output:
------------------------------------------------------------
...
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 2b 00 00 00
DEBUG: raw_scsi: arbitration initiator id 7 (80)
DEBUG: raw_scsi: arbitration
DEBUG: raw_scsi: selected id 0
DEBUG: raw_scsi_put_data got message c0 (1/1)
DEBUG: raw_scsi_put_data got message c0 (1 bytes)
DEBUG: raw_scsi: got command byte 1a (1/6)
DEBUG: raw_scsi: got command byte 00 (2/6)
DEBUG: raw_scsi: got command byte 08 (3/6)
DEBUG: raw_scsi: got command byte 00 (4/6)
DEBUG: raw_scsi: got command byte 04 (5/6)
DEBUG: raw_scsi: got command byte 00 (6/6)
TODO : HDC: Unsupported MODE SENSE mode page
DEBUG: raw_scsi: no data, status = 2
DEBUG: raw_scsi: status byte read 02. Next=1
DEBUG: raw_scsi: message byte read 00. Next=1
DEBUG: raw_scsi: arbitration initiator id 7 (80)
DEBUG: raw_scsi: arbitration
DEBUG: raw_scsi: selected id 0
DEBUG: raw_scsi_put_data got message 80 (1/1)
DEBUG: raw_scsi_put_data got message 80 (1 bytes)
DEBUG: raw_scsi: got command byte 03 (1/6)
DEBUG: raw_scsi: got command byte 00 (2/6)
DEBUG: raw_scsi: got command byte 00 (3/6)
DEBUG: raw_scsi: got command byte 00 (4/6)
DEBUG: raw_scsi: got command byte 60 (5/6)
DEBUG: raw_scsi: got command byte 00 (6/6)
WARN : HDC: *** Strange REQUEST SENSE ***!
DEBUG: raw_scsi: data in 22 bytes waiting
DEBUG: raw_scsi: data in finished, 22 bytes: status phase
DEBUG: DMA initiator recv PC=001c40ee
DEBUG: SCSI BUS reset
sd 0:0:0:0: Device offlined - not ready after error recovery
sd 0:0:0:0: [sda] Asking for cache data failed
sd 0:0:0:0: [sda] Assuming drive cache: write through
sd 0:0:0:0: rejecting I/O to offline device
sd 0:0:0:0: [sda] Attached SCSI disk
VFS: Cannot open root device "/dev/sda" or unknown-block(8,0): error -6
------------------------------------------------------------


3. Building m68k kernel
-----------------------

0. Install generic build tools:
   $ sudo apt install bc bison flex

1. Install compiler:
   $ sudo apt install gcc-m68k-linux-gnu

2. Get latest upstream kernel release sources (without history):
   $ git clone --depth 1 --branch v6.12 \
     git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
   $ cd linux

3. Apply Linux issue workaround patches:
   $ git am /path/to/hatari/tools/linux/000*.patch

4. Get Hatari compatible configuration:
   $ cp /path/to/hatari/tools/linux/kernel.config .config

5. Compile configured kernel:
   $ ARCH=m68k CROSS_COMPILE=m68k-linux-gnu- make -j4 vmlinux

Notes:

- You can fine-tune kernel config for your requirements with:
   $ ARCH=m68k CROSS_COMPILE=m68k-linux-gnu- make -j4 menuconfig

- Using "optimize for size" instead of "optimize for performance"
  reduced (stripped) kernel image by ~15%

- Normal Linux builds require 030 (or better) with MMU and FPU
  (only uCLinux would work on 68000 without MMU)

- Using included kernel.config file as-is, builds non-modular kernel
  that includes all relevant features for mounting root fs directly.
  It saves bootup time compared to using initramfs for loading the
  needed external modules

- Bootup works faster when kernel is uncompressed, as uncompression
  would happen in emulated code => do not compress kernel


4. Building root file system
----------------------------

This is common part for both examples below (if you already have
a directory named disk/, rename it, or use another name).

1. Create root file system directories:
   $ mkdir disk
   $ cd disk
   $ mkdir -p dev bin etc lib mnt proc root run sbin sys tmp usr/bin usr/sbin

2. Add minimal init script for mounting virtual file systems
   before starting shell:
   $ cp -a /path/to/hatari/tools/linux/init.sh init

3. Add a user:
   $ echo "root:x:0:0:root:/root:/bin/sh" > etc/passwd

4. And basic terminal descriptions:
   $ cp -ar /lib/terminfo/ lib/


4.1 As EXT2 HD image, from BusyBox
----------------------------------

This builds a minimal hard disk root file system with BusyBox.

BusyBox is a multi-call binary, which performs the same job as many
separate programs, based on the (symlink) name with which it is
invoked. For more info, see "man busybox" (after installing BusyBox to
host).

5. Fetch statically linked m68k BusyBox and extract it:
   $ wget http://ftp.ports.debian.org/debian-ports/pool-m68k/main/b/busybox/busybox-static_*_m68k.deb
   $ ar x busybox-static_*_m68k.deb
   $ tar xvf data.tar.xz --wildcards *bin/busybox

6. Install qemu user space emulation to query m68k busybox, so
   that symlinks can be added for the tools it lists:
   $ sudo apt install qemu-user
   $ /path/to/hatari/tools/linux/symlink-busybox.sh

7. Cleanup directory content:
   $ rm *.tar.* debian-binary

8. Make 4MB EXT2 HD image out of it:
   $ cd ..
   $ /sbin/mkfs.ext2 -t ext2 -L BUSYBOX -d disk/ rootfs.img 4M


4.2 As EXT2 HD image, from klibc utils
--------------------------------------

This builds a minimal hard disk root file system with kernel "libc"
utilities intended for initramfs.  These utilities are separate
binaries (not symlinks like with BusyBox) and they're much more
limited than BusyBox; they lack many of the standard options and shell
does not e.g. have file name completion. In total they take only few
hundred KB of space though.

5. Fetch klibc library and utility packages:
   $ wget http://ftp.ports.debian.org/debian-ports/pool-m68k/main/k/klibc/libklibc_*_m68k.deb
   $ wget http://ftp.ports.debian.org/debian-ports/pool-m68k/main/k/klibc/klibc-utils_*_m68k.deb

6. Extract them:
   $ ar x libklibc_*_m68k.deb
   $ tar xvf data.tar.xz
   $ ar x klibc-utils_*_m68k.deb
   $ tar xvf data.tar.xz

7. Move utilities to bin/ and clean directory:
   $ mv usr/lib/klibc/bin/ .
   $ rm -r *.tar.* debian-binary
   $ cd ..

8. Make 4MB EXT2 HD image out of it:
   $ /sbin/mkfs.ext2 -t ext2 -L KLIBC -d disk/ rootfs.img 4M

Notes:
- these utilities would fit even to a floppy image:
	$ zip2st disk/ klibc.st
  But FAT file system cannot be used for Linux root fs because it is
  lacking security features required from one.


5. Building initrd
------------------

After creating either of above root file systems, you can use the same
content also to create an example initrd / initramfs.

9. Package directory content with cpio and compress it with LZO:
   $ cd disk/
   $ find | cpio -R 0:0 -H newc --create | lzop -9 > ../initrd.img

Notes:

- *Initrd is unnecessary* when kernel includes everything needed for
  mounting the real root file system, like is the case *with the
  provided kernel.config*.  Initrd is required only if you e.g. need
  to enter password to decrypt the disk or load additional kernel
  module(s) before mounting the root file system.

- Initrd resides in / uses RAM, so you're better of mounting the real
  root fs directly.  if you're tight on memory, but still need initrd,
  minimize its size and make sure kernel can free it after pivoting
  to real root fs.

- Kernel will need to extract initrd contents from CPIO archive loaded
  to RAM.  Archive is freed after extraction, but before that a
  significant amount of extra RAM is needed for it.

- Kernel can handle both compressed and uncompressed initrd.
  Compressed initrd takes less RAM during CIO archive extraction, but
  its decompression slows boot significantly.

- Above used LZO compression provides faster decompression speed,
  gzip/deflate better compression ratio.  Both are enabled in included
  kernel.config. One can enable from kernel config extra compression
  algorithms with better compression ratios, but they are significantly
  slower.


6. Running Hatari
-----------------

1. Set suitable options in lilo.cfg, for example:
-------------------------------------
[LILO]
Kernel = vmlinux-v6.12
Symbols = System.map-v6.12
Ramdisk =
Args = video=atafb:sthigh console=tty
KernelToFastRam = FALSE
-------------------------------------
(See lilo.cfg in doc/ directory for more info.)

2. Start Hatari:
    $ hatari --log-level info \
      --fast-forward on --fastfdc on --timer-d on \
      --machine falcon --dsp off --fpu 68882 --cpuclock 32 \
      --mmu on -s 14 --ttram 64 --addr24 off \
      -c lilo.cfg --natfeats on \

2a) with root fs on disk:
      --ide-master rootfs.img \
      --lilo "debug=nfcon root=/dev/sda ro init=/init"

2b) with root fs being initrd specified in lilo.cfg:
      --lilo "debug=nfcon root=/dev/ram ro init=/init"


Options explanation (these can also be set in lilo.cfg):
- video=atafb:sthigh -- frame buffer starts in ST-high
  (mono is fastest mode with large enough resolution)
- console=tty -- console output goes to frame buffer
- debug=nfcon -- kernel debug messages go to Hatari console
- root=<device> -- what device is used for mounting root file system
- ro -- mount it read-only
- init=<path> -- run given executable / script as first process

Other notes:
- Keep "init=" last on "--lilo" option kernel command line,
  otherwise kernel may give arguments after it also to init!
- Kernel does not need DSP, and avoiding its emulation with
  "--dsp off" (about) doubles "--fast-forward on" speed


7. Native bootstrap
-------------------

Real HW does not have LILO, so a separate bootstrap program is needed
for loading the kernel into RAM and executing it from there. Following
shows easiest method to simulate that with Hatari.

1. Get bootstrap program:
   $ mkdir gemdos-hd
   $ cd gemdos-hd
   $ wget https://people.debian.org/~wouter/d-i/images/20130502-06:51/tools/atari/bootstra.tos

2. Tell bootstrap program to load kernel to ST-RAM and whole command
   line to give to the kernel:
   $ echo "-s -d -k vmlinux root=/dev/sda ro debug=nfcon video=atafb:sthigh console=tty init=/init" > bootargs
   $ cd ..

3. Get kernel to bootstrap:
   $ cp /path/to/m68k-kernel/vmlinux gemdos-hd/

4. If you do not have a TOS ROM image, download latest EmuTOS release from:
     https://sourceforge.net/projects/emutos/files/emutos/1.3/emutos-1024k-1.3.zip/download
   and extract it:
   $ unzip emutos-1024k-1.3.zip

5. Then run Hatari with them:
   $ hatari --trace os_base --log-level info \
      --tos emutos-1024k-1.3/etos1024k.img \
      --fast-forward on --fastfdc on --timer-d on \
      --machine falcon --dsp off --fpu 68882 --cpuclock 32 \
      --mmu on -s 14 --ttram 64 --addr24 off \
      --natfeats on --ide-master rootfs.img \
      gemdos-hd/bootstra.tos

Hatari notes:
- Because GEMDOS HD is specific to TOS, it is not accessible from Linux
- Because TOS does not have driver for the Linux disk, and GEMDOS HD
  is assigned to C:, IDE content is not accessible from TOS

On real HW:
- Linux rootfs would be put to a partition (e.g. "sda2"),
  it would not start from IDE drive first sector ("sda")
- NatFeats is not available, so debug option can be removed,
  or debug device set to a more suitable one (e.g. serial)


8. Debugging and profiling
--------------------------

8.1 Kernel debugging
--------------------

There are few ways to investigate what happens at boot:
- Asking kernel to give debug output for module initializations
  with "initcall_debug" kernel command line option
- Disabling individual init calls with "initcall_blacklist=<name>"
  to see whether boot proceeds (better) without them
- Tracing kernel function calls with Hatari "trace cpu_symbols"
  debugger command and the "--trace cpu_symbols" option
- Profiling what the kernel does

Tracing and "initcall_debug" will give a lot of output so save it
also to a file:
	$ hatari ... 2>&1 | tee output.txt

Tracing and profiling both require symbols file produced during kernel
build.  If that file is listed in lilo.cfg, symbols will be automatically
loaded before Linux boots.

For now, all debugging and profiling should be done with kernel loaded
to ST-RAM (see Hatari issues section).  For that, its size needs to be
<8MB uncompressed, otherwise it wo not work from ST-RAM.

Related lilo.cfg options are:
	KernelToFastRam = FALSE
	Symbols = Symbols.map

To verify that symbols loaded correctly, one can check in debugger
e.g. whether nf_call (NatFeats entry point) looks as expected:
----------------
> d nf_call
$00008230 : 7301      DC.W      $7301
$00008232 : 4e75      rts
----------------


To profile whole bootup, profiling needs to be enabled right
from the start, and stopped (e.g. by breakpoint) at appropriate
point.

This debugger command file does profiling until first brk() syscall
(i.e. shortly after kernel starts init and that does its first alloc):
--- profile-boot.ini ---
profile on
b pc = sys_brk
------------------------

Adding that to Hatari options with "--parse profile-boot.ini",
will start profiling from the very first executed instruction.

After debugger gets invoked on first brk() syscall function call /
breakpoint, one can save profile with:
	> profile save profile.txt

Resulting file can be post-processed with:
	$ hatari_profile -st -a System.map profile.txt

To see how much emulated time the profiled part took, and to get lists
of functions taking most cycles / time, using most instructions, and
being called most.

To debug and get back traces to where "die_if_kernel" bug handler gets
called, one can use following files:
---- bt-show.ini ----
profile stack
---- bt-init.ini ----
profile on
b pc=die_if_kernel :noinit :trace :file bt-show.ini
------------------------

And start hatari with "--parse bt-init.ini" option.  Backtraces to any
other functions listed in kernel symbol file can caught the same way.

Breakpoint options:
* :file -- execute debugger commands from given file when breakpoint is hit
* :trace -- continue running without dropping to debugger
* :noinit -- no reset for profile/caller info when breakpoint is hit

(Last option is needed only for the "profile stack" command.)

What symbols are in the symbol file dictates what one sees with many
of the debugger commands.  If one does just tracing and profiling, one
can reduce symbol warnings from Hatari by removing unnecessary symbols
from the used symbols file:
	$ grep ' [tT] ' Symbols.map > code-symbols.map

If one is interested only of e.g. tracing kernel syscalls, one should
load just those to debugger:
	$ grep ' [tT] sys_' Symbols.map > syscall-symbols.map
	...
	> symbols syscall-symbols.map
	> trace cpu_symbols

(System call info is naturally interesting only after user-space
processes are running & calling them.)


If you see errors like these on Linux console:
	hda: possibly failed opcode: 0x39
	hda: possibly failed opcode: 0x30
(On Linux v5.4, IDE is on 'sda' instead of 'hda'.)

Those are IDE write command opcodes.  Make sure your IDE image
actually *is* writable and try again.


8.1 User-space debugging
------------------------

Linux user-space is best debugged with Linux user-space tools.

Some actions can be done with "Magic SysRq", for help, see:
	echo h > /proc/sysrq-trigger

To see what syscall and their arguments graphical program does,
install "strace" and forward its output to Hatari NatFeats output
device:
  $ strace -f -e execve -o /dev/nfcon0 wserver

To see what library calls programs dynamically linked to Glibc do,
use "latrace".

More indepth debugging is likely to require Gdb. Install "gdbserver"
to emulated system:
https://sourceware.org/gdb/current/onlinedocs/gdb.html/Server.html

TODO (test): Tell server to communicate over one of the serial ports
supported by Hatari, tell Gdb on host to attach to corresponding
Hatari device file, and point it to matching m68k ELF binary and
its debug symbols.

(There are several UIs that can be used with Gdb.)


9. Debian m68k install
----------------------

9.1 Debian installer
--------------------

These are setup instructions for testing Debian installer in Hatari.

0. Work directory:
   $ mkdir -p debian/installer
   $ cd debian/installer

1. Get latest Debian installer (kernel + initrd images):
   $ wget https://cdimage.debian.org/cdimage/ports/debian-installer/2024-02-25/m68k/debian-installer-images_202306XX_m68k.tar.gz
   $ tar xvf debian-installer-images*.gz

2. Set up lilo.cfg with a framebuffer mode supported by Debian installer
   (it needs at least 16 colors to be usable):
   $ cat > lilo.cfg
[LILO]
Kernel = installer-m68k/current/images/kernels/vmlinux
Args = video=atafb:vga16 console=tty
Ramdisk = installer-m68k/current/images/nativehd/initrd.gz
KernelToFastRam = FALSE
RamdiskToFastRam = TRUE
^D

3. Get ISO image release matching installer & kernel (checksum files are in same directory):
   $ wget https://cdimage.debian.org/cdimage/ports/snapshots/2024-02-25/debian-12.0.0-m68k-NETINST-1.iso

4. Try running Hatari with them:
    $ hatari --log-level debug \
      --fast-forward on --fastfdc on --timer-d on \
      --machine falcon --dsp off --fpu 68882 --cpuclock 32 \
      --mmu on -s 14 --ttram 128 --addr24 off \
      --monitor vga -c lilo.cfg --natfeats on \
      --ide-master debian-12.0.0-m68k-NETINST-1.iso \
      --lilo "debug=nfcon root=/dev/ram init=/init"

NOTE: Hatari does not support networking so network install obviously
does not work.  There are no ready made images of pre-installed and
up to date m68k Debian installs either.

TODO: kernel panics when init crashes.


9.2 Running initrd as normal disk
---------------------------------

If Debian boot has issues already in its initrd, you could try running
it as normal disk with monolithic kernel, or using modular kernel with
a working initrd.

Converting initrd to a normal EXT2 disk partition, and using
fakeroot session to retain file properties requiring root rights:
   $ mkdir initrd
   $ fakeroot /bin/bash
   # cd initrd
   # zcat ../installer-m68k/current/images/nativehd/initrd.gz | cpio -i
   # cd ..
   # /sbin/mkfs.ext2 -t ext2 -L INITRD -d initrd initrd.img 32M
   # exit

TODO: init is dynamically linked Busybox and crashes immediately.
If it's replaced with statically linked one, that crashes to first
"mkdir" (or "ls") call on just mounted "/run":
------------------------
tmpfs	/run	tmpfs	nosuid,size=10%,mode=755	0	0
------------------------


9.3 Bootstrapping Debian installation on PC
-------------------------------------------

Doing first stage of setting up minimal m68k Debian system image
(without package PGP signing checks), as root:
   # apt install debootstrap
   # debootstrap --foreign --arch=m68k --no-check-gpg sid debian-chroot http://ftp.ports.debian.org/debian-ports/
   # cp -a /path/to/hatari/tools/linux/init.sh debian-chroot/init
   # /sbin/mkfs.ext2 -t ext2 -L DEBIAN -d debian-chroot debian.img 512M
   # chown $USER.$USER debian.img

NOTE: debootstrap needs to be done on a partition that is not mounted
with "noexec" or "nodev" option, otherwise it fails!

To finish bootstrapping, one would need to boot it on m68k system
and run "debootstrap --second-stage".

TODO: test again whether there are improvements to last status:
- Hatari:
  debootstrap fails to kernel oops
- m68k system-qemu:
  does not support required HW
- m68k user-qemu (from Debian Bookworm):
  does support m68k binaries
- Aranym:
------------------------------------------------------------
$ cat > linux.config
# NOTE, run with: aranym-mmu -l <conffile>
[GLOBAL]
FastRAM = 64

[LILO]
Kernel = vmlinux
Args = video=atafb:vga16 console=tty debug=nfcon root=/dev/sda ro
init=/init

# 512MB EXT2 image with mkfs.ext2 (Cylinders = 2 * size in MB)
[IDE0]
Cylinders = 1024
Heads = 16
SectorsPerTrack = 64
Present = Yes
IsCDROM = No
ByteSwap = Yes
ReadOnly = Yes
Path = debian.img
ModelName = Debian-m68k
^D
$ aranym-mmu -l linux.config
------------------------------------------------------------


10. Linux kernel issues
-----------------------

10.1 Known issues with workarounds
----------------------------------

- Old (4.x?) Linux versions do not work if kernel is loaded to TT-RAM

  Workaround: Load kernel to ST-RAM or use more recent kernel version

- Hatari debug output shows IDE and DSP reset messages on Falcon at
  2Hz (from floppy media change detection) if Linux is started with
  --lilo, instead of from TOS.  This is because TOS initializes PSG
  port-A register bits to sensible values and Linux does not.

  Workaround: included kernel patch

- Atari TT boot freezes with constant "unexpected interrupt from 112"
  messages, due to Linux SCU register setup regression.

  Workaround: use >=6.11 kernel, or kernel patch:
  https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=f70065a9fd988983b2c693631b801f25a615fc04

- Hatari prefetch was earlier working incorrectly on bus errors.  This
  caused user-space program crashes if either (or both) cycle-exact or
  prefetch emulation is enabled for 030 (with MMU).

  This problem was very visible with the tools included to statically
  linked Busybox, but those issues cannot be reproduced any more.

  Fix: Use latest Hatari Git version, commit 06fc93b021c38 (Oct 20 2024),
  or newer.


10.2 TODO / investigate more
----------------------------

- Kernel does not recognize ACSI drives at all, although kernel
  reports finding Atari ACSI HW:
------------------------------------------------------------
Atari hardware found: TT_SHIFTER ST_MFP TT_MFP TT_SCSI_DMA TT_SCSI YM2149 PCM SCC_DMA SCC MICROWIRE TT_CLK FDC_SPEED ACSI
...
scsi host0: Atari native SCSI, irq 39, io_port 0x0, base 0x0, can_queue 16, cmd_per_lun 2, sg_tablesize 128, this_id 7, flags { }
...
Core driver edition 01.06 : TT driver edition 00.03
Write will use    4 fragments of   32768 bytes as default
NET: Registered PF_PACKET protocol family
VFS: Cannot open root device "/dev/sda" or unknown-block(0,0): error -6
Please append a correct "root=" boot option; here are the available
partitions:
0200            3280 fd0
 (driver?)
0201            3280 fd1
 (driver?)
0100            4096 ram0
 (driver?)
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
------------------------------------------------------------
  Only SCSI & IDE drives are recognized

- with Hatari 2.5, Linux works again[1] on 040 & 060, when CPU data
  cache emulation is disabled (--data-cache off).

  However, when data cache is enabled, 060 boot crashes to double bus
  error, and 040 boot freezes early on.  Although screen is black, CPU
  trace indicates latter being a panic.

  [1] In previous Hatari versions, there was panic on reaching user-space.

  These did not happen with 2019 v2.3-dev Git version (and Linux
  version of that time). Linux also boots fine on real 060 Falcon:
	https://www.youtube.com/watch?v=8Sriz45Z4oM

- Busybox "halt" & "reboot" do nothing, although klibc versions work fine