| Re: [hatari-devel] Linux bootup issues in Hatari |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
Hi,
On 3/17/19 11:33 AM, Thorsten Otto wrote:
On Sonntag, 17. März 2019 08:59:46 CET Eero Tamminen wrote:
I was thinking of adding separate fastram flags for kernel & initrd
to Hatari lilo code
You should maybe check the debian-m68k mailing list first before doing so. The
LoadToFastRam option was once added by Andreas Schwab, because apparently some
kernels only worked when loaded to FastRam, some others only when loaded to
STRAM.
Well, if some work with it and some don't, that's obviously
more reason to have a (separate) option for it. :-)
Real HW doesn't necessarily have decent amount of TT-RAM.
Yes, but we are talking about emulators here.
What I meant is that emulator can be used to speed up the process of
getting to a setup that works on the real device. I.e. user wanting
to come up with a Linux config that will work on his real machine
could use emulator to test different kernel config options, initrd
content etc, and defer copying it to real HW and testing it there
until it (about) works in the emulator.
M68k kernel & Debian developers could use emulator to test things on
emulator in different configs when such HW isn't readily available,
and to (much) more easily debug kernel issues.
These of course requires emulator to be accurate enough that
things working on real HW will work with it too.
Checks for real HW are the task of the bootstra.tos :)
Because it's what needs to be run on real HW, it working identically
on emulator is of interest.
BTW, do you know of a current source for that program?
No, but I would like to.
(It's binary version seems to have last changed nearly decade ago.)
Use-case is making a stripped down Linux kernel + user-space that
can actually run on real HW.
Thats not an easy task. You definitely don't want to compile the kernel in
linux-m68k, not even in emulators, that would take ages.
I haven't done kernel compiling in over a decade, but I know
it to be trivially cross-compilable (out of necessity).
Also i think most of the drivers are already compiled as modules,
no idea what can be left out of the kernel to make it smaller.
Compile everything needed at boot statically, and skip module
loading. There are also several "embedded" options, both in
and out of tree (those are occasionally discussed at lwn.net).
>> I don't see them in https://github.com/aranym/aranym.git?
>
> Oops. Now pushed.
Looks good except maybe for load::File still using long for
kernel size, but functions it calls using 32-bit value for that.
- Eero