Hi,
I have been playing with Debian/m68k for a few days on my Atari Falcon with CT60. Maybe you are aware of the fact that CT60 TOS (basically a patched
TOS 4.04) also contains its own version of ataboot (based on ataboot 3.3
from 2004).
This built-in ataboot was able to boot 2.2.25 from Debian Sarge 3.1 just
fine, with -T 0x8000000 even without -s (2.4.x, as you perhaps remember, is unable to boot without -s due to internal changes fixed much later).
However that ataboot doesn't contain the important update from late 2004
which allowed to use the staging area also outside ST RAM, drastically
limiting how big the kernel+initrd can be. For 2.2.25 it was fine, for
Debian 10 or 12 it was way too little.
So I switched to bootstra.tos/prg, unchanged since 2011 but in reality the
same code base as m68kboot <https://github.com/geertu/m68kboot> from linux-m68k. To my surprise, not only I couldn't get any new kernel booting (Debian 10, 12, some snapshot from 2023) but the 2.2.25 using the same
bootargs wouldn't boot.
After some digging I have found the culprit: for all those years, the data cache hasn't been flushed! A simple fix: https://github.com/mikrosk/m68kboot/commit/c6408a2e37fe9d43ad964f09fefcbed9aad361bc
made ataboot.ttp working again.
I guess one of the reasons why this bug went unnoticed is that Debian/m68k
now lives mostly in Aranym which doesn't implement copy-back caching of the 68040.
Now to figure out how to make the installer read the ISO ... Debian 3.1's
one just scanned Atari TOS C:, D:, ... drives, Debian 10's (and later) for
some reason refuses to do the same.


--- PyGate Linux v1.5.18
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Hi Miro,

On Thu, 2026-07-16 at 23:32 +1000, Miro Krop ?ek wrote:

I have been playing with Debian/m68k for a few days on my Atari Falcon wi

th CT60. Maybe you are aware of the fact that CT60 TOS (basically a patched
TOS 4.04) also contains its own version of ataboot (based on ataboot 3.3 f
rom 2004).

This built-in ataboot was able to boot 2.2.25 from Debian Sarge 3.1 just

fine, with -T 0x8000000 even without -s (2.4.x, as you perhaps remember, is
unable to boot without -s due to internal changes fixed much later).

However that ataboot doesn't contain the important update from late 2004

which allowed to use the staging area also outside ST RAM, drastically limi ting how big the kernel+initrd can be. For 2.2.25 it was fine, for Debian 1
0 or 12 it was way too little.

So I switched to bootstra.tos/prg, unchanged since 2011 but in reality th

e same code base asÿm68kboot from linux-m68k. To my surprise, not only
I couldn't get any new kernel booting (Debian 10, 12, some snapshot from 2 023) but the 2.2.25 using the same bootargs wouldn't boot.

After some digging I have found the culprit: for all those years, the dat

a cache hasn't been flushed! A simple fix:ÿhttps://github.com/mikrosk/ m68kboot/commit/c6408a2e37fe9d43ad964f09fefcbed9aad361bc made ataboot.ttp w orking again.

I guess one of the reasons why this bug went unnoticed is that Debian/m68

k now lives mostly in Aranym which doesn't implement copy-back caching of t
he 68040.

Now to figure out how to make the installer read the ISO ... Debian 3.1's

one just scanned Atari TOS C:, D:, ... drives, Debian 10's (and later) for
some reason refuses to do the same.ÿ

You can sent a patch to Geert and he will take care of it.

He is still a very active m68k maintainer.

Adrian

--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

--- PyGate Linux v1.5.18
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Hi Miro,
Nice catch! AFAIR the CT60 came with a patched version of
ataboot/bootstrap that would have contained the cache flush patch.
That's what I've been using for many years. The CT60 web pages appear to
have gone away - can't check what version could be downloaded there anymore. Does the installer find the IDE disk drive at all? I wonder if the ISO scanning issues are down to the kernel using a different host adapter
driver (pata_falcon, not falconide) these days?
Cheers,
? ? Michael
On 17/07/2026 1:32 AM, Miro Krop?\u010dek wrote:

Hi,

I have been playing with Debian/m68k for a few days on my Atari Falcon
with CT60. Maybe you are aware of the fact that CT60 TOS (basically a patched TOS 4.04) also contains its own version of ataboot (based on
ataboot 3.3 from 2004).

This built-in ataboot was able to boot 2.2.25 from Debian Sarge 3.1
just fine, with -T 0x8000000 even without -s (2.4.x, as you perhaps remember, is unable to boot without -s due to internal changes fixed
much later).

However that ataboot doesn't contain the important update from late
2004 which allowed to use the staging area also outside ST RAM,
drastically limiting how big the kernel+initrd can be. For 2.2.25 it
was fine, for Debian 10 or 12 it was way too little.

So I switched to bootstra.tos/prg, unchanged since 2011 but in reality
the same code base as m68kboot <https://github.com/geertu/m68kboot>
from linux-m68k. To my surprise, not only I couldn't get any new
kernel booting (Debian 10, 12, some snapshot from 2023) but the 2.2.25
using the same bootargs wouldn't boot.

After some digging I have found the culprit: for all those years, the
data cache hasn't been flushed! A simple fix: https://github.com/mikrosk/m68kboot/commit/c6408a2e37fe9d43ad964f09fefcbed9aad361bc
made ataboot.ttp working again.

I guess one of the reasons why this bug went unnoticed is that
Debian/m68k now lives mostly in Aranym which doesn't implement
copy-back caching of the 68040.

Now to figure out how to make the installer read the ISO ... Debian
3.1's one just scanned Atari TOS C:, D:, ... drives, Debian 10's (and
later) for some reason refuses to do the same.

--- PyGate Linux v1.5.18
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Fri, 17 Jul 2026 at 03:51, Michael Schmitz <schmitzmic@gmail.com> wrote:

AFAIR the CT60 came with a patched version of ataboot/bootstrap that would have contained the cache flush patch.

That's true but as mentioned, it wouldn't let you boot anything which
requires more than ~6.5 MB of ST RAM for the staging area.

The CT60 web pages appear to have gone away - can't check what version
could be downloaded there anymore.

They didn't: http://didier.mequignon.free.fr. Its CT60 section offers
2.2.25 (vanilla debian) and 2.4.25 (patched/ with the one off bugfix).

Does the installer find the IDE disk drive at all? I wonder if the ISO scanning issues are down to the kernel using a different host adapter
driver (pata_falcon, not falconide) these days?

I wanted to post a separate email about it but since you have asked... ;)
No, it doesn't (at least the image with 6.6.15 I tried). I had to extract
and inject libata.ko.xz + pata_falcon.ko.xz from cdrom to hd-media
initrd.gz, that made /dev/sda accessible. However not mountable because it seems that the kernel doesn't contain modules for msdosfs? So that's
another task to tick off.
--
http://mikro.atari.org


--- PyGate Linux v1.5.18
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Miro,
On 17/07/2026 1:15 PM, Miro Krop?\u010dek wrote:

On Fri, 17 Jul 2026 at 03:51, Michael Schmitz <schmitzmic@gmail.com>
wrote:

AFAIR the CT60 came with a patched version of ataboot/bootstrap
that would have contained the cache flush patch.

That's true but as mentioned, it wouldn't let you boot anything which requires more than ~6.5 MB of ST RAM for the staging area.

I see - I must admit I never tried booting large kernels and initrds
since my CT60 stopped booting in a reasonable video mode. I'll have to
give that another try sometime.

The CT60 web pages appear to have gone away - can't check what
version could be downloaded there anymore.

They didn't: http://didier.mequignon.free.fr. Its CT60 section offers
2.2.25 (vanilla debian) and 2.4.25 (patched/ with the one off bugfix).

Good to know - not sure what else I had bookmarked that failed to load
then.

Does the installer find the IDE disk drive at all? I wonder if the
ISO scanning issues are down to the kernel using a different host
adapter driver (pata_falcon, not falconide) these days?

I wanted to post a separate email about it but since you have asked...
;) No, it doesn't (at least the image with 6.6.15 I tried). I had to
extract and inject?libata.ko.xz + pata_falcon.ko.xz from cdrom to
hd-media initrd.gz, that made /dev/sda accessible. However not
mountable because it seems that the kernel doesn't contain modules for msdosfs? So that's another task to tick off.

The vfat.ko module would also be needed then. I would have thought
that's already in the initrd though.
Try loading that module explicitly and see what log messages you get. I
don't remember having to use any special module options.
Cheers,
? ? Michael

--
http://mikro.atari.org

--- PyGate Linux v1.5.18
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Miro,
On 18/07/2026 2:11 AM, Miro Krop?\u010dek wrote:

Hi Michael,

On Fri, 17 Jul 2026 at 14:08, Michael Schmitz <schmitzmic@gmail.com>
wrote:

The vfat.ko module would also be needed then. I would have thought
that's already in the initrd though.

I had to pull:?fat.ko, msdos.ko, nls_cp437.ko and nls_ascii.ko from
the Debian 12 ISO's own linux-image-6.1.0-9-m68k.deb plus
pata_falcon.ko and libata.ko from its cdrom initrd.gz

Sounds about right ...

Try loading that module explicitly and see what log messages you
get. I don't remember having to use any special module options.

Well, me neither, on 2.2.25. ;-)

However I have bumped into another issue: in 2.4.4.6 a breaking change
was introduced for my 1GiB GEMDOS partition: bytes per logical sector
can be at most 4096 bytes (memory page size) so my 16K logical sectors
are rejected by the kernel. So currently, one can mount only a 256 MB
GEMDOS partition at most.

Yes, that's a limitation we can't bypass. Users need to be aware of
that. I'm sure this had been discussed on the lists at that time.

Perhaps I'll try to mount an ext2 partition from FreeMiNT. :)

I'm sure that would be a lot easier (unless FreeMINT has introduced
endianness issues).
Cheers,
? ? Michael

--
http://mikro.atari.org

--- PyGate Linux v1.5.18
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Miro,
please compile some notes on what you had to add to the initrd, and what changes were necessary after installation. Even if none of that ever
makes it into the installer bugfixes, it would help anyone trying to
install Debian on the CT60.
Last I heard of someone attempting to use systemd on the CT60, it was
too slow and continued to time out. That was 10 years or more ago, so
some issues appear to have been fixed in the meantime.
You'll likely hit the same timeouts due to slow crypto code again when
using ssh - public key authentication (and the simplest crypto
algorithms supported) was the only way for me. There used to be 060
optimized crypto libraries that could speed up logins a great deal, but
AFAIR they used hand optimized assembly for crypto primitives. Not sure letting the compiler optimize for 060 can achieve near as much speedup.
The keymap issue is a long standing problem - that should be reported to
the installer team as a bugfix (same as the missing modules).
Cheers,
? ? Michael
On 19/07/2026 12:27 AM, Miro Krop?\u010dek wrote:

On Sat, 18 Jul 2026 at 00:39, Michael Schmitz <schmitzmic@gmail.com>
wrote:

I'm sure that would be a lot easier (unless FreeMINT has
introduced endianness issues).

It was. But of course I had to prepare another initrd because the
default one didn't contain ext4.ko and?jbd2.ko. :)

So, after that?I was finally able to finish the installation but oh
dear, was it a long one. Against Debian 3.1, Debian 12's netinst.iso
is twice as big but the installation time was 30 minutes?vs. ... I
don't know, several hours (I let it run during the night). And that
was with TT RAM enabled!

Another hiccup was booting the installed system: since the default
kernel doesn't contain?pata_falcon.ko, libata.ko, ext4.ko and jbd2.ko,
I had to boot into the installer again, take initrd.img from my
installed partition, copy to FreeMiNT's ext2 partition, then copy it
to TOS GEMDOS partition, then add -r to bootargs (unlike 2.2.25) and
after /that/?I was able to see the login prompt after a long series of
debug messages. Funny to see systemd on my Falcon. :)

Could I log into the system after all? Of course not. :) This took
another couple of hours: by default, Debian 12 uses yescrypt for
password hashes. yescrypt is so heavy that even 60s is not enough for verifying my password so after entering login+password I was welcomed
with ... a restarted login prompt because the kernel killed the login process for taking 100% CPU time for one minute. :)

So a happy end but oh dear, Debian 3.1 was a breeze in comparison to
this. I have one last item on my TODO and that is trying a build from Geert's branch so I can see my NetUSBee alive.

P.S. I could also observe a few minor oddities like "shutdown"
actually not shutting down the CT60 or that after a while (that
happened in both the installer and the installed system), IKBD packets
are interpreted somewhat... weirdly. For instance UP arrow doesn't
work anymore, I have to use INSERT. shell history's UP arrow also
doesn't work and if I use CTRL+P, I have to go RIGHT if I want to move
the cursor LEFT.

--
http://mikro.atari.org

--- PyGate Linux v1.5.18
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Miro,
the network portion of the NetUSBee is identical to the EtherNEC, which
is just a NE2000 ISA adapter (without interrupt line). All ugliness
involved in making that one work had been hidden away in the m68k IO primitives header.
The transfer rate is somewhat limited by the chosen timer D interrupt frequency - you can try to load the timer D data register with a smaller
value to increase the polling frequency (in arch/m68k/atari/ataints.c).
The value chosen is rather conservative and won't load down a 030 Falcon
with interrupt polling too much.
Cheers,
? ? Michael
On 19/07/2026 12:08 PM, Miro Krop?\u010dek wrote:

That's exactly why I'm posting these emails, I won't remember a thing
in one weeks time. :-)

However if you have a wiki which I can access and update, I can post
my findings there, too. I remember seeing an aranym guide from ~2012.

Surprisingly (to me), I had the netusbee (network) driver available
all along, at least in the installed root. No need to use Geert's tree
(but thanks to docker it is quite trivial to setup the whole cross
compiler tool chain).

The actual apt update (first I had to update the keyring as the one in Debian 12 iso is no longer valid) and install was another slow motion
show. :-)

But the good news is that NetUSBee's transfer rate is basically
identical to what I'm seeing in FreeMiNT, about 300 KB/s. So even with
all that modern baggage, the kernel itself can still run efficiently.

Would be interesting to explore how many kernel options can be
disabled to help out ancient hardware to boot/work faster. I'm sure
that there is also a lot of user space stuff to skip/disable.

http://mikro.atari.org

On Sun, 19 July 2026, 4:12\u202fam Michael Schmitz, <schmitzmic@gmail.com> wrote:

Miro,

please compile some notes on what you had to add to the initrd,
and what changes were necessary after installation. Even if none
of that ever makes it into the installer bugfixes, it would help
anyone trying to install Debian on the CT60.

Last I heard of someone attempting to use systemd on the CT60, it
was too slow and continued to time out. That was 10 years or more
ago, so some issues appear to have been fixed in the meantime.

You'll likely hit the same timeouts due to slow crypto code again
when using ssh - public key authentication (and the simplest
crypto algorithms supported) was the only way for me. There used
to be 060 optimized crypto libraries that could speed up logins a
great deal, but AFAIR they used hand optimized assembly for crypto
primitives. Not sure letting the compiler optimize for 060 can
achieve near as much speedup.

The keymap issue is a long standing problem - that should be
reported to the installer team as a bugfix (same as the missing
modules).

Cheers,

? ? Michael

On 19/07/2026 12:27 AM, Miro Krop?\u010dek wrote:

On Sat, 18 Jul 2026 at 00:39, Michael Schmitz
<schmitzmic@gmail.com> wrote:

I'm sure that would be a lot easier (unless FreeMINT has
introduced endianness issues).

It was. But of course I had to prepare another initrd because the
default one didn't contain ext4.ko and?jbd2.ko. :)

So, after that?I was finally able to finish the installation but
oh dear, was it a long one. Against Debian 3.1, Debian 12's
netinst.iso is twice as big but the installation time was 30
minutes?vs. ... I don't know, several hours (I let it run during
the night). And that was with TT RAM enabled!

Another hiccup was booting the installed system: since the
default kernel doesn't contain?pata_falcon.ko, libata.ko, ext4.ko
and jbd2.ko, I had to boot into the installer again, take
initrd.img from my installed partition, copy to FreeMiNT's ext2
partition, then copy it to TOS GEMDOS partition, then add -r to
bootargs (unlike 2.2.25) and after /that/?I was able to see the
login prompt after a long series of debug messages. Funny to see
systemd on my Falcon. :)

Could I log into the system after all? Of course not. :) This
took another couple of hours: by default, Debian 12 uses yescrypt
for password hashes. yescrypt is so heavy that even 60s is not
enough for verifying my password so after entering login+password
I was welcomed with ... a restarted login prompt because the
kernel killed the login process for taking 100% CPU time for one
minute. :)

So a happy end but oh dear, Debian 3.1 was a breeze in comparison
to this. I have one last item on my TODO and that is trying a
build from Geert's branch so I can see my NetUSBee alive.

P.S. I could also observe a few minor oddities like "shutdown"
actually not shutting down the CT60 or that after a while (that
happened in both the installer and the installed system), IKBD
packets are interpreted somewhat... weirdly. For instance UP
arrow doesn't work anymore, I have to use INSERT. shell history's
UP arrow also doesn't work and if I use CTRL+P, I have to go
RIGHT if I want to move the cursor LEFT.

--
http://mikro.atari.org

--- PyGate Linux v1.5.18
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)