[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Remote kernel debugging an Amiga; was: "BUG: soft lockup" on A1200


On Wed, 11 Dec 2019, Christian T. Steigies wrote:

> > > > (BTW, if any kernel developer wants to take a look, I can make the
> > > > A1200 or the A4000 remotely accessible, via a Raspberry Pi. Serial
> > > > console, and hardware-reset for the Amiga via RPi GPIO. On boot it
> > > > would just fetch a new kernel from the RPi (from AmigaOS), before
> > > > trying to boot it. So if anyone feels like debugging this, it's
> > > > there. We've done this before for debugging the MorphOS kernel on
> > > > the same hardware, worked quite well.)
> > >
> (... snip ...)
> And how do you transfer the kernel from the RPi?
> This sounds like a cool setup, a fully remote controlled Amiga...

Yeah, it was/can be quite fun. :) Quite a story to tell at events for
sure, that the main MorphOS kernel dev was sitting in South Africa, while
the Amiga was sitting on my desk near Mainz in Germany hooked on an RPi,
and this is how we debugged a PPC kernel for the box... :)

On the question itself: over the network of course. So in the A4000 case,
the thing has an X-Surf, and a minimal AmigaOS setup to boot into some
sort of networked state after a reset. (An a A1200 could utilize a PCMCIA
network card instead.)

In detail (this is long overdue for a blogpost or something):

After a reset, AmigaOS (3.x) boots by default, then autostarts a TCP/IP
stack + brings the network card online automatically. When interface up is
reached, most Amiga TCP/IP stacks support some kind of post-up script, so
it will execute an AmigaDOS script to fetch the kernel and the a boot
script from the RPi. In our case this was done using httpresume (available
on Aminet), which is a http downloader, kinda a native-wget-for-AmigaOS,
which we found it works better in some cases than the actual wget port.
Obviously, the RPi runs a small (LAN only) webserver to expose the files
to the Amiga via http, but the uploads to the RPi from "outside" are done
via scp/sftp.

Then it just makes the boot script executable, and starts it, which in
turn starts the kernel. The rest can already be observed over the serial
console. Optionally, the AmigaOS boot process and various stages described
above can be also made to send messages over serial, as there are tools
for that too, but we never bothered... (I think I researched at some
point, and in case of fatal errors in the process, there was a way to
expose an AmigaDOS command line over serial too. As a last-resort
solution, or you'd at least get some news that something has failed, and
don't wait for it to boot into the other kernel.)

Obviously, having both the kernel image and the boot script downloaded on
every iteration has the advantage, that all kernel command line parameters
can be modified for every new boot configuration. Other tools and required
files (initrd maybe? or custom amiboot versions) are easy to include too.
Actually AmigaDOS even has an ext2fs handler, so theoretically even
modules can be overwritten on some Linux root FS...

In fact, our download process for MorphOS became two stage at some point,
the first system would just download a "download script", and execute
that, so even the list of files to be fetched from the RPi on next boot
can be edited easily without physically touching the machine, or custom
commands can be executed too (copying files to the right place before
attempting to boot, etc).

In our experience, the entire reboot process including downloads takes
less than a minute on a well executed '060 based setup, so it's really
workable. We actually tried to fiddle with TFTP and other things first,
but we found this "naive" HTTP-download approach worked the best and was
the easiest to get to.

I'm happy to share more details over the AmigaOS setup, the download
scripts we used, the reset-script using RPi GPIO, etc, but given the task
we had at hand, they are as super minimal, and as sketchy and makeshift as
you might expect... :) Just ask.

Sorry for the long mail...


Reply to: