TL;DR: Mackerel now runs Linux! Updated pictures of the hardware and a quick video demo below.


After struggling with my port of ucLinux 2016 for long enough, I decided I needed a clean slate. Steve Chamberlin's 68 Katy is one of the more famous examples of a homebrew 68008 machine on the internet and he managed to run ucLinux, albeit a version from 2004 with the v2.0 of the Linux kernel. I found a clean copy of the same ucLinux release he used, and with his modifications as reference, I was able to get Mackerel booting as well. This still managed to take me about a week and a lot of trial and error, but having Steve's known good configuration definitely made for an easier process than working completely blind like I was in the 2016 version.
My hardware differs enough from the 68 Katy that quite a bit of porting still had to happen, but before all that I had to find a toolchain that would actually build a 20+ year old Linux kernel. I learned the hard way that although you can build your own toolchain from source, that may not be th best idea in this case. There's a 32-bit version of the m68k-elf-tools from 2003 that ended up working for me on my modern Debian 12 machine. I did need to enable the i386 repo and install the i386 version of libc and libgcc, but otherwise the ancient gcc 2.x cross-compiler ran perfectly. Backwards compatibility is amazing.
There are three basic things Linux needs to boot and run: a periodic interrupt for task switching, a serial console, and a file system. I have two XR68C681 DUART chips attached to the system bus. One of them is providing this periodic interrupt function, the other is the kernel's main serial console. I hacked my way through a Linux serial driver and ended up with a kernel image and a romfs filesystem image. In theory these can be combined into one piece and loaded together into RAM or ROM, but I was not able to get this working. My solution is to load the kernel into RAM at address 0x200000 and the filesystem at 0x300000 and just hardcode the filesystem code to look for it there. This is ugly and is on the short list for cleanup tasks, but it works. You can see the bootloader loading the filesystem and kernel to these addresses in the video.
The other "hack" in place is the memory map itself. Mackerel actually has 3.5MB of SRAM from addresses 0x00 to 0x380000 with peripherals and the bootloader ROM mapped above that. For simplicity, the Linux kernel thinks that it actually has 2MB of RAM starting at 0x00 and that the rest of the RAM is ROM. These are all implementation details and should be cleaned up, but I'm not worried about it too much at the moment.
I'm still working on getting a more modern kernel running on this hardware, but this is a great milestone and an even better reference for future porting work. My immediate plans are to do a little bit of cleanup and documentation and then think about designing a single-board PCB of this hardware configuration. Longer term I'm still toying with the idea of jumping up to a 68030 for that sweet MMU, but for now I'm going to go play some Colossal Cave Adventure!

Links for reference:
Mackerel 68k project on Github: https://github.com/crmaykish/mackerel-68k
ucLinux port on Github: https://github.com/crmaykish/mackerel-uclinux-20040218
Toolchain I used to build: https://github.com/crmaykish/mackerel-m68k-elf-tools-2003
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.
Color me impressed! Congratulations on achieving such a monumental feat!
Are you sure? yes | no