| Re: [hatari-devel] Linux bootup issues in Hatari |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
Hi,
On 3/17/19 5:14 PM, Thorsten Otto wrote:
On Sonntag, 17. März 2019 14:52:51 CET Thomas Huth wrote:
Using buildroot should be faster to build your own kernel - no emulation
required here, everything is cross-compiled.
Thats true for the kernel, but to create the initrd image, you will need a lot
of native libraries & executables. And last time i tried, the scripts that are
used on debian for that, always want to use the ones from the current system.
That does not work when cross-compiling.
Now that Debian supports multi-arch, that shouldn't be as large problem
as it was decade ago [1].
At least there's nowadays m68k support in user-mode Qemu and according
to Debian m68k list it works fairly OK. Maybe it's enough just to
install m68k user-mode qemu and set binfmt-misc to transparently run
m68k binaries with qemu?
- Eero
[1] In a previous company I worked, we used (made) Scratchbox [2]
and Scratchbox2 [3] to cross-compile Debian, without doing
any modifications to the Debian source packages for this.
[2]
http://scratchbox.org/download/files/sbox-releases/legacy/doc/debiandevelopment.html
[3] https://packages.debian.org/jessie/scratchbox2
These used either user-qemu or sbrsh:
https://packages.debian.org/stable/sbrsh
to transparently run things that were compiled for the target system,
using kernel binfmt-misc support. Qemu with user-space emulation,
and sbrsh by running individual native binaries transparently across
network on a native machine (or e.g. inside qemu system emulation),
which NFS mounts same disk.
In our case, target was ARM. AFAIK those tools were used in doing
the initial ports of Debian to few of the "newer" ARM variants until
they were self-hosting.
Scratchbox2 isn't anymore in recent Debian versions, so I guess
it's not anymore needed with multi-arch.