Current kernel for Atari Falcon install?

classic Classic list List threaded Threaded
27 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Current kernel for Atari Falcon install?

David Henderson-3
Good afternoon all,

I’ve been searching around for the latest installation package to use for a stock 14M Falcon. I had installed etch (I think) a while back, but was pleased to see the 68k port had seen a little more love of late, so thought I’d try again.

Unfortunately the kernel shipped with all the CD image versions I’ve found hangs before boot, filling the screen with random noise.

I read a 2016 post (https://lists.debian.org/debian-68k/2016/10/msg00040.html) that suggested the EtherNEC search might block booting on an 030. Is this still the case? I have an 030 and EtherNEC, so that would be a bit of a show stopper.

FWIW, running with debug=ser gets me “\nABCEFGIJK\n”

Regards,


David.




Reply | Threaded
Open this post in threaded view
|

Re: Current kernel for Atari Falcon install?

Geert Uytterhoeven
Hi David,

On Sun, Mar 3, 2019 at 7:32 PM David Henderson <[hidden email]> wrote:
> I read a 2016 post (https://lists.debian.org/debian-68k/2016/10/msg00040.html) that suggested the EtherNEC search might block booting on an 030. Is this still the case? I have an 030 and EtherNEC, so that would be a bit of a show stopper.

That was fixed in v4.18, in commit 3f90f9ef2dda316d ("m68k/mm: Adjust
VM area to be unmapped by gap size for __iounmap()").

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [hidden email]

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Reply | Threaded
Open this post in threaded view
|

Re: Current kernel for Atari Falcon install?

David Henderson-3
Thanks, Geert. That’s positive.

Is the v10 disc image kernel expected to work, then? I’m afraid to say it doesn’t.

I’m happy to have a go at building my own. Is there an example configuration? My last attempt (going via make menuconfig from scratch) led to the same hang with screen filled with noise.

Regards,

--
David


> On 4 Mar 2019, at 08:13, Geert Uytterhoeven <[hidden email]> wrote:
>
> Hi David,
>
>> On Sun, Mar 3, 2019 at 7:32 PM David Henderson <[hidden email]> wrote:
>> I read a 2016 post (https://lists.debian.org/debian-68k/2016/10/msg00040.html) that suggested the EtherNEC search might block booting on an 030. Is this still the case? I have an 030 and EtherNEC, so that would be a bit of a show stopper.
>
> That was fixed in v4.18, in commit 3f90f9ef2dda316d ("m68k/mm: Adjust
> VM area to be unmapped by gap size for __iounmap()").
>
> Gr{oetje,eeting}s,
>
>                        Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [hidden email]
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                -- Linus Torvalds

Reply | Threaded
Open this post in threaded view
|

Re: Current kernel for Atari Falcon install?

Geert Uytterhoeven
Hi David,

On Mon, Mar 4, 2019 at 9:34 AM David Henderson <[hidden email]> wrote:
> Is the v10 disc image kernel expected to work, then? I’m afraid to say it doesn’t.

I have no idea which kernel version is used for the "v10 disc image".

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [hidden email]

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Reply | Threaded
Open this post in threaded view
|

Re: Current kernel for Atari Falcon install?

John Paul Adrian Glaubitz
In reply to this post by David Henderson-3
Hello David!

On 3/3/19 7:01 PM, David Henderson wrote:
> I’ve been searching around for the latest installation package to use for a stock 14M Falcon. I had installed etch (I think) a while back, but was pleased to see the 68k port had seen a little more love of late, so thought I’d try again.
>
> Unfortunately the kernel shipped with all the CD image versions I’ve found hangs before boot, filling the screen with random noise.

I'm afraid your machine has not enough memory to run Linux. I don't think
you won't get far with just 14 MiB of memory and I wouldn't be surprised
if that's the reason the kernel won't boot for you.

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - [hidden email]
`. `'   Freie Universitaet Berlin - [hidden email]
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Reply | Threaded
Open this post in threaded view
|

Re: Current kernel for Atari Falcon install?

David Henderson-3
In reply to this post by Geert Uytterhoeven
On Mon, 4 Mar 2019, Geert Uytterhoeven wrote:

> I have no idea which kernel version is used for the "v10 disc image".

I'm sorry. I had thought the Debian 68k list was the right place to ask
about the Debian 68k port distributed at
https://cdimage.debian.org/cdimage/ports/2019-01-27/.

--
David.
[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Current kernel for Atari Falcon install?

David Henderson-3
In reply to this post by John Paul Adrian Glaubitz
On Mon, 4 Mar 2019, John Paul Adrian Glaubitz wrote:

> Hello David!
> I'm afraid your machine has not enough memory to run Linux. I don't think
> you won't get far with just 14 MiB of memory and I wouldn't be surprised
> if that's the reason the kernel won't boot for you.

Hi Adrian,

Ah, thanks for this. That's a shame. So Debian has evolved beyond the
ability to run on any stock Atari hardware bar the TT? The Falcon is
physically unable to address more than 14Mb without getting out the
soldering iron and replacing the CPU and bus.

Doing some more digging I see Michael Schmitz mentioned the same in
passing last year
(https://lists.debian.org/debian-68k/2018/09/msg00003.html), but the
positive there is it sounds like the kernel itself (from 2018) ought to be
able to boot, but I may need a sysvinit release. Would that be Pre-Jessie?

Also it sounds like Geert was able to build a working 3.16 kernel in 2015
(https://lists.debian.org/debian-68k/2016/06/msg00059.html), so that may
be an option.

Thanks again,

--
David.
[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Current kernel for Atari Falcon install?

John Paul Adrian Glaubitz
In reply to this post by David Henderson-3
Hi David!

On 3/4/19 12:31 PM, David Henderson wrote:
>> I have no idea which kernel version is used for the "v10 disc image".
>
> I'm sorry. I had thought the Debian 68k list was the right place to ask about the Debian 68k port distributed at https://cdimage.debian.org/cdimage/ports/2019-01-27/.

It's the right list, that's correct. But Geert is an upstream developer
for the Linux kernel on m68k, so he might not always be in the loop
then it comes to Debian-specific questions.

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - [hidden email]
`. `'   Freie Universitaet Berlin - [hidden email]
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Reply | Threaded
Open this post in threaded view
|

Re: Current kernel for Atari Falcon install?

Eero Tamminen
In reply to this post by David Henderson-3
Hi,

On 3/4/19 1:46 PM, David Henderson wrote:
> On Mon, 4 Mar 2019, John Paul Adrian Glaubitz wrote:
>> I'm afraid your machine has not enough memory to run Linux. I don't think
>> you won't get far with just 14 MiB of memory and I wouldn't be surprised
>> if that's the reason the kernel won't boot for you.

Have Debian kernels really grown that much?

Many years ago I tried Debian stable in Aranym with just 14MB of memory.

Kernel itself wasn't the problem, but Debian user-space was.  After
logging in, there was only 1-2MB free RAM.  Replacing Bash with
something leaner, removing *everything* from boot that's not absolutely
needed (logging etc), and building more minimal kernel config could
help.


> Ah, thanks for this. That's a shame. So Debian has evolved beyond the
> ability to run on any stock Atari hardware bar the TT?  The Falcon is
> physically unable to address more than 14Mb without getting out the
> soldering iron and replacing the CPU and bus.

Another serious problem was crypto.  Before changing PAM to use MD5
instead of SHA, login was unusable slow (modern crypto needs special
crypto instructions to run at reasonable speed).

=> I would suggest preparing suitable stripped down / configured Debian
    installation in emulator before trying it on real (16Mhz/14MB) HW.

Latest Hatari 2.2.x version in Debian "should" have good enough
TT & Falcon / 030 / MMU emulation to run Linux, and it supports
TT-RAM also with Falcon:
hatari --tos tos404.img --machine falcon -s 14 --ttram 32 --addr24 off
--ide-master <IDE image>  <linux boot floppy image>

(Instead of Atari TOS, one could also use the latest free / open source
EmuTOS 512k release image.)


I would suggest doing at least the final preparation in Hatari instead
of Aranym, because Aranym doesn't emulate all Falcon HW, and it's
emulating (AFAIK somewhat simpler) 040 CPU instead of 030.

Aranym is much faster (because it doesn't try to be cycle accurate etc),
and it emulates networking which makes some things easier though, so
one could start with that though.


> Doing some more digging I see Michael Schmitz mentioned the same in
> passing last year
> (https://lists.debian.org/debian-68k/2018/09/msg00003.html), but the
> positive there is it sounds like the kernel itself (from 2018) ought to
> be able to boot, but I may need a sysvinit release. Would that be
> Pre-Jessie?
>
> Also it sounds like Geert was able to build a working 3.16 kernel in
> 2015 (https://lists.debian.org/debian-68k/2016/06/msg00059.html), so
> that may be an option.

If somebody can provide links to suitable images for latest debian m68k
images & kernels and short instructions how to boot them, I could
debug things a bit with Hatari.

Or if somebody else wants to try that himself, I can help with any
Hatari related issues (I'm one of its developers).


        - Eero

Reply | Threaded
Open this post in threaded view
|

Re: Current kernel for Atari Falcon install?

David Henderson-3
On Tue, 5 Mar 2019, Eero Tamminen wrote:

> Have Debian kernels really grown that much?

Hi Eero,

I've been looking into exactly this today. I compiled a kernel from commit
616d4cf8ea1c370198f548a7e84f1fe90b09921b (a bit arbitrary, it was the last
atari_defconfig commit) and tried various combinations.

I established the majority of dead ends I came up with were memory
related, but indirectly. The hang in BOOTSTRAP.PRG, filling the screen
with noise, related to kernels with an initrd, but mostly CPIO variants,
suggesting there's an overhead to those.

Dropping the initial ramdisk did mean the kernel started coming up, but
sure enough it ran out of memory quite early on in the process.

I'm currently in the process of building the lightest current kernel I
can.

> Many years ago I tried Debian stable in Aranym with just 14MB of memory.
> Kernel itself wasn't the problem, but Debian user-space was.  After
> logging in, there was only 1-2MB free RAM.  Replacing Bash with
> something leaner, removing *everything* from boot that's not absolutely
> needed (logging etc), and building more minimal kernel config could
> help.

Yes, I had a functioning install with a 2.x kernel, but yes, it was slow.
I can't recall if it was etch, potato or even earlier than that.

> => I would suggest preparing suitable stripped down / configured Debian
>   installation in emulator before trying it on real (16Mhz/14MB) HW.
>
> Latest Hatari 2.2.x version in Debian "should" have good enough
> TT & Falcon / 030 / MMU emulation to run Linux, and it supports
> TT-RAM also with Falcon:
> hatari --tos tos404.img --machine falcon -s 14 --ttram 32 --addr24 off
> --ide-master <IDE image>  <linux boot floppy image>

Yes, cheers. I've moved over to Hatari to carry out these tests.
Interestingly one of the old kernels gets further on Hatari than on my
actual Falcon when set up the same and booting from the same media, but
that's an investigation for another day!

> If somebody can provide links to suitable images for latest debian m68k
> images & kernels and short instructions how to boot them, I could
> debug things a bit with Hatari.

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.

Cheers,

--
David.
[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Current kernel for Atari Falcon install?

Eero Tamminen
Hi,

On 3/5/19 11:08 PM, David Henderson wrote:

> On Tue, 5 Mar 2019, Eero Tamminen wrote:
>> Have Debian kernels really grown that much?
>
> I've been looking into exactly this today. I compiled a kernel from
> commit 616d4cf8ea1c370198f548a7e84f1fe90b09921b (a bit arbitrary, it was
> the last atari_defconfig commit) and tried various combinations.
>
> I established the majority of dead ends I came up with were memory
> related, but indirectly. The hang in BOOTSTRAP.PRG, filling the screen
> with noise, related to kernels with an initrd, but mostly CPIO variants,
> suggesting there's an overhead to those.
>
> Dropping the initial ramdisk did mean the kernel started coming up, but
> sure enough it ran out of memory quite early on in the process.
>
> I'm currently in the process of building the lightest current kernel I can.
>
>> Many years ago I tried Debian stable in Aranym with just 14MB of memory.
>> Kernel itself wasn't the problem, but Debian user-space was.  After
>> logging in, there was only 1-2MB free RAM.  Replacing Bash with
>> something leaner, removing *everything* from boot that's not absolutely
>> needed (logging etc), and building more minimal kernel config could
>> help.
>
> Yes, I had a functioning install with a 2.x kernel, but yes, it was
> slow. I can't recall if it was etch, potato or even earlier than that.
>
>> => I would suggest preparing suitable stripped down / configured Debian
>>   installation in emulator before trying it on real (16Mhz/14MB) HW.
>>
>> Latest Hatari 2.2.x version in Debian "should" have good enough
>> TT & Falcon / 030 / MMU emulation to run Linux, and it supports
>> TT-RAM also with Falcon:
>> hatari --tos tos404.img --machine falcon -s 14 --ttram 32 --addr24 off
>> --ide-master <IDE image>  <linux boot floppy image>
>
> Yes, cheers. I've moved over to Hatari to carry out these tests.
> Interestingly one of the old kernels gets further on Hatari than on my
> actual Falcon when set up the same and booting from the same media, but
> that's an investigation for another day!

Few other comments:

* Hatari 2.2 has regression in UNPK instruction emulation, but I
   think it's mainly used when dealing with BCD numbers, so hopefully
   not relevant for Linux booting.  I've filed bug about upgrading
   Debian Hatari version to v2.2.1 where this is fixed, but until
   that you might want to build your own Hatari version:
        https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923833

* I'm assuming that Linux doesn't use DSP for anything.  Hatari
   fast-forward [1] works much faster if you disable Falcon DSP
   (--dsp none/dummy)

[1] "--fast-forward yes" option and AltGr-X keyboard shortcut.


>> If somebody can provide links to suitable images for latest debian m68k
>> images & kernels and short instructions how to boot them, I could
>> debug things a bit with Hatari.
>
> A Debian 10 ISO is available here:
> https://cdimage.debian.org/cdimage/ports/10.0/m68k/iso-cd/

While that should be fine for bootup testing, I don't think install
itself would work with 14MB, as packaging tools can require very
large amounts of RAM. :-)

(And net install would require networking i.e. Aranym.)


> Booting involves copying an appropriate initrd and kernel onto your HD
> and running BOOTSTRAP.PRG, either taking its arguments from BOOTARGS file.

Thanks!


> I've not investigated how to load the initrd into alt RAM, though, as
> I've not resorted to that in Hatari yet.

Doesn't bootloader do that automatically or have some option
for it?

In Hatari you can profile where the code is running.
Use AltGr-Pause to invoke console debugger, and type:
        profile on
        c # for continue

After a while, invoke debugger again and profiler tells
(among other things) in which memory areas code had been running.


        - Eero

PS. To get bootloader itself to alt-RAM, its program header needs
to have flag set that tells TOS it should be loaded there.

"gst2ascii" utility installed with Hatari shows Atari program
header flags.  I think the relevant flag is TTRAMLOAD.

(Atari GCC installs include "flags" program to change the flags,
but if it's not set for program already, it probably won't work
from there.)

Reply | Threaded
Open this post in threaded view
|

Re: Current kernel for Atari Falcon install?

Stefan Niestegge-2
In reply to this post by David Henderson-3
Hello all,

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

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.

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.


greets,
Stefan "Beetle" Niestegge

Reply | Threaded
Open this post in threaded view
|

Re: Current kernel for Atari Falcon install?

David Henderson-3
In reply to this post by Eero Tamminen
Hi Eero and Stefan,

On 7 Mar 2019, at 23:09, Eero Tamminen <[hidden email]> wrote:

Hi,

On 3/6/19 12:04 AM, David Henderson wrote:
I've not investigated how to load the initrd into alt RAM, though, as I've not resorted to that in Hatari yet.

Doesn't bootloader do that automatically or have some option for it?
Looking at the help text, it would appear you have to explicitly tell it to load to ST-RAM, so alt-ram is probably the default.

According to some other docs I read, things are loaded to TT-RAM, but *uncompressed* to ST-RAM.

So it's better to use uncompressed vmlinuz and initrd files.  That way they don't need to be uncompressed and load (much) faster.

Either way, I couldn’t get the Debian 10 ISO version to boot in Hatari. Obviously it was too big for the real Falcon.

Give Hatari "--trace os_base" option to get the TOS boot program output to terminal.

<snip detailed explanation of Hatari debugging>

Thanks, Eero, but kernel debugging via Hatari is a bit beyond me a the moment.



On 9 Mar 2019, at 00:34, Stefan Niestegge <[hidden email]> wrote:

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.

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.


Thanks Stefan,

That’s interesting and does suggest perhaps it’s a processor issue. Obviously I can’t address that sort of memory, but even adding AltRAM to Hatari when otherwise set to maximum Falcon compatibility hangs in the same way.

I’ve put together a video showing my experiments with Debian 10 too:-


I think changing my partition scheme and having a go with Debian 9 are next on my list.

(BTW, not shown on my videos was my other line of enquiry: putting Debian Potato on as well — that installed, but would frequently BUSERR out, often when just doing simple things [like ls -l]. Same on Hatari. Perplexing.)


Regards,

David.


Reply | Threaded
Open this post in threaded view
|

Re: Current kernel for Atari Falcon install?

Eero Tamminen
In reply to this post by Stefan Niestegge-2
Hi,

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

Reply | Threaded
Open this post in threaded view
|

Re: Current kernel for Atari Falcon install?

Michael Schmitz-4
In reply to this post by Stefan Niestegge-2
Stefan

Am 09.03.2019 um 13:34 schrieb Stefan Niestegge:

> Hello all,
>
> 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.
>>
>> Cheers,
>>
>
> 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.

Thanks for confirming this still works.

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

Kernel and simple (pre-systemd) userland still fit into 14 MB:

schmitz@hobbes:~$ uname -a
Linux hobbes 5.0.0-rc3-atari-fpuemu+ #943 Fri Jan 25 19:14:11 NZDT 2019
m68k GNU/Linux
schmitz@hobbes:~$ free
              total       used       free     shared    buffers     cached
Mem:         10408       8244       2164          0        600       2048
-/+ buffers/cache:       5596       4812
Swap:      2097144       2304    2094840

The initrd used by the installer to supply modules and busybox won't
fit, sorry. From what I recall, preparing an installation using
emulation and booting that on a stock Falcon has the system run out of
memory before swap space can be activated (Christian tried that for me a
while ago). So that's not an option either.

Cheers,

        Michael


>
>
> greets,
> Stefan "Beetle" Niestegge
>

Reply | Threaded
Open this post in threaded view
|

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

Eero Tamminen
In reply to this post by Eero Tamminen
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)?
>
>

m68k-linux-boot.txt (8K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Finn Thain
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 | Threaded
Open this post in threaded view
|

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

Geert Uytterhoeven
In reply to this post by Eero Tamminen
Hi Eero,

On Wed, Apr 3, 2019 at 1:06 AM Eero Tamminen <[hidden email]> wrote:
> And ataboot & bootstra.prg programs sources?  There's something
> I'd like to check about LILO memory area config setups.

The Debian sources at
http://ftp.nl.debian.org/debian-archive/debian/pool/main/m/m68kboot/
seem to match the latest CVS version.

The CVS server no longer exists. I forgot if we already have a public
copy of m68kboot.git. If we don't, I can push mine to github.

OK, found https://people.debian.org/~cts/m68kboot.git/, but it seems
it was forked in 2000, while my copy has CVS commits until 2004.

Gr{oetje,eeting}s,

                        Geert


--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [hidden email]

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Reply | Threaded
Open this post in threaded view
|

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

John Paul Adrian Glaubitz
On 4/3/19 9:16 AM, Geert Uytterhoeven wrote:
> The CVS server no longer exists. I forgot if we already have a public
> copy of m68kboot.git. If we don't, I can push mine to github.

Yes, please :). I would be interested to see that code.

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - [hidden email]
`. `'   Freie Universitaet Berlin - [hidden email]
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Reply | Threaded
Open this post in threaded view
|

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

Geert Uytterhoeven
On Wed, Apr 3, 2019 at 9:30 AM John Paul Adrian Glaubitz
<[hidden email]> wrote:
> On 4/3/19 9:16 AM, Geert Uytterhoeven wrote:
> > The CVS server no longer exists. I forgot if we already have a public
> > copy of m68kboot.git. If we don't, I can push mine to github.
>
> Yes, please :). I would be interested to see that code.

https://github.com/geertu/m68kboot

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [hidden email]

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

12