Re: bootstra.tos broken on 68040/68060 real hardware

Michael Schmitz <[email protected]> Fri, 17 Jul 2026 05:50:56 +1200
Newsgroups gmane.linux.debian.ports.68k
Message-ID <[email protected]>
This is a multi-part message in MIME format.
--------------86eRZZDDZSbNsmPvMwAzetoa
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

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áček 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.
--------------86eRZZDDZSbNsmPvMwAzetoa
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Hi Miro,</p>
    <p>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.</p>
    <p>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?</p>
    <p>Cheers,</p>
    <p>    Michael</p>
    <div class="moz-cite-prefix">On 17/07/2026 1:32 AM, Miro Kropáček
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAN5rfbRT3J=P=yivRmA2rM1f9TFtRpAwMKpoTNwiw5NDM-TQEA@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">
        <div>Hi,</div>
        <div><br>
        </div>
        <div>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).</div>
        <div><br>
        </div>
        <div>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).</div>
        <div><br>
        </div>
        <div>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.</div>
        <div><br>
        </div>
        <div>So I switched to bootstra.tos/prg, unchanged since 2011 but
          in reality the same code base as <a
            href="https://github.com/geertu/m68kboot"
            moz-do-not-send="true">m68kboot</a> 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.</div>
        <div><br>
        </div>
        <div>After some digging I have found the culprit: for all those
          years, the data cache hasn't been flushed! A simple fix: <a
href="https://github.com/mikrosk/m68kboot/commit/c6408a2e37fe9d43ad964f09fefcbed9aad361bc"
            moz-do-not-send="true" class="moz-txt-link-freetext">https://github.com/mikrosk/m68kboot/commit/c6408a2e37fe9d43ad964f09fefcbed9aad361bc</a>
          made ataboot.ttp working again.</div>
        <div><br>
        </div>
        <div>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.</div>
        <div><br>
        </div>
        <div>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. </div>
      </div>
    </blockquote>
  </body>
</html>

--------------86eRZZDDZSbNsmPvMwAzetoa--