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