»But does it run Linux?«
Computers are universal machines. With the input we give them they can do whatever we want them to. What is information to us, is nothing but signals to the machine: endless strings of ones and zeros whose meaning arises solely from our interpretation. A computer’s only function is to process these signals an to apply mathematical and logical functions on them.
The most fundamental of all operations is the addition of two numbers, from which all others can be derived. This makes the simple addition of two numbers, executed millions of times a second in modern devices, one of the most important algorithms. But the processes inside these devices remain abstract and hardly graspable. This clocked mechanical adder transfers one of these hidden processes into human dimensions.
Version 2 at the 35th Chaos Communication Congress
Inhalte von Vimeo werden aufgrund deiner Cookie-Einstellungen nicht angezeigt. Akzeptiere die funktionellen Cookies im Cookie-Banner, um den Cookie-Richtlinien von Vimeo zuzustimmen und den Inhalt anzusehen.
The first version in action
How it works
The installation is the mechanical implementation of a serial adder logical circuit. Binary numbers are represented by marbles (glass meaning «one» and wood meaning «zero»). Hence both logical states are physically present and visible. A feature of the machine is its clock cycle that mimics the procedure of computers. The clock signal with the length of 13s is provided by three servos. At the beginning they open the inputs of all active components. All parts reset autonomously. The whole logical circuit is executed mechanically; merely the clock signal is provided by a microcontroller.
For more information, have a look at the detailed documentation (in german).
Realisation
All components consist of soldered brass wire. Steel bolts form the framework that is mounted on medium density fibreboard. Currently, the installation is in its second version.
Logical composition:
1: Two numbers are put into the input registers. With every clock cycle, the last bit is released.
2: The first half adder gives out the interim sum of the two input bits
3: Carry bits are saved in a one-bit-memory.
4: The second half adder gives out the sum of the interim sum and the carry bit.5: the result is given to the output register
Construction history: from sketch to prototype
But does it run Linux?
Getting a recent Linux kernel to run on the T030 turned out to be much less painful than I first anticipated. Mostly because someone had allready done a lot of the hard work.
When I started putting the T030 together, I was not aware of any recent homebrew projects using the 68030 processor, but a couple of months ago I found this:
The KISS-68030 is designed by John Coffman and features a very nice, clean and simple design with a DRAM controller implemented in three GALs capable of running two 72 pin SIMMs.
And Will Sowerbutts has ported Debian Linux to the KISS-68030:
Check out his videos, they are very informative.
Will’s kernel patch has been the most valuable resource I have found online for porting a recent Linux kernel to a homebrew m68k-based board. With that at hand, it didn’t take many hours of work before I had the first kernel messages spewing out on the console of the T030.
I did run in to a few obstacles though. Normally the Linux kernel expects RAM at address 0x0 and starts from 0x1000, but the T030 has ROM at 0x0 and the chunk of 16 MB RAM at 0x1000000.
It took me a while to figure out, but the assembly code in arch/m68k/kernel/head.S is fully relocatable and runs fine from 0x1000000. No need to mess with the kernel linker script, which I tried at first which didn’t work. All I needed was to add transparent address translation for the MMU for the second last 16 MB chunk of the address space for the memory mapped IO (ROM, SRAM, IO and DRAM areas are mirrored throughout the address space).
I have added functionality in my ROM BIOS to supply the bootinfo structure at the end of the kernel image, which contains parameters like RAM location and size and the kernel command line.
With that in place, and with timer A in the 68901 MFP set up as timer tick for the scheduler, I was able to load the kernel to the point where it tries mount a root file system and start init. Without any real storage available yet, I have created a small initrd image with a statically linked busybox binary and a small shell script which outputs some stuff to /dev/kmsg (no real TTY device available yet, only the simple boot console).
Then I ran into another problem. No matter what I tried to use as init, the kernel just got an «unexpected bus error» and died. Further debugging revealed that the culprit was floating point instructions. But shouldn’t the FPU emulation take care of that? A good number of hours later, I found the real problem: An error in the glue logic caused the ROM to respond during coprocessor bus cycles in CPU address space, resulting in a bus error exception instead of the F-line emulation exception needed for the FPU emulation to work. Doh!
Glue logic CPLD updated and we’re good to go:
Notice the kernel messages with the 68901 serial driver. That is work in progress and it doesn’t work yet. Before this project, I have never done anything with the Linux kernel source apart from just compiling it for different platforms. In other words, I still have a lot to learn about kernel programming and device drivers, so it will probably take a good number of attempts before I have a real TTY driver for the 68901 UART.
When that is complete someday, it should be possible to get at real shell. Then the next thing will be a SPI master driver for the TP3465.
Until then, the T030 can only spew out the output from a couple of commands to /dev/kmsg, but I guess it’s enough to say: Yes, the T030 runs Linux. 🙂
But does it run Linux?
Getting a recent Linux kernel to run on the T030 turned out to be much less painful than I first anticipated. Mostly because someone had allready done a lot of the hard work.
When I started putting the T030 together, I was not aware of any recent homebrew projects using the 68030 processor, but a couple of months ago I found this:
The KISS-68030 is designed by John Coffman and features a very nice, clean and simple design with a DRAM controller implemented in three GALs capable of running two 72 pin SIMMs.
And Will Sowerbutts has ported Debian Linux to the KISS-68030:
Check out his videos, they are very informative.
Will’s kernel patch has been the most valuable resource I have found online for porting a recent Linux kernel to a homebrew m68k-based board. With that at hand, it didn’t take many hours of work before I had the first kernel messages spewing out on the console of the T030.
I did run in to a few obstacles though. Normally the Linux kernel expects RAM at address 0x0 and starts from 0x1000, but the T030 has ROM at 0x0 and the chunk of 16 MB RAM at 0x1000000.
It took me a while to figure out, but the assembly code in arch/m68k/kernel/head.S is fully relocatable and runs fine from 0x1000000. No need to mess with the kernel linker script, which I tried at first which didn’t work. All I needed was to add transparent address translation for the MMU for the second last 16 MB chunk of the address space for the memory mapped IO (ROM, SRAM, IO and DRAM areas are mirrored throughout the address space).
I have added functionality in my ROM BIOS to supply the bootinfo structure at the end of the kernel image, which contains parameters like RAM location and size and the kernel command line.
With that in place, and with timer A in the 68901 MFP set up as timer tick for the scheduler, I was able to load the kernel to the point where it tries mount a root file system and start init. Without any real storage available yet, I have created a small initrd image with a statically linked busybox binary and a small shell script which outputs some stuff to /dev/kmsg (no real TTY device available yet, only the simple boot console).
Then I ran into another problem. No matter what I tried to use as init, the kernel just got an «unexpected bus error» and died. Further debugging revealed that the culprit was floating point instructions. But shouldn’t the FPU emulation take care of that? A good number of hours later, I found the real problem: An error in the glue logic caused the ROM to respond during coprocessor bus cycles in CPU address space, resulting in a bus error exception instead of the F-line emulation exception needed for the FPU emulation to work. Doh!
Glue logic CPLD updated and we’re good to go:
Notice the kernel messages with the 68901 serial driver. That is work in progress and it doesn’t work yet. Before this project, I have never done anything with the Linux kernel source apart from just compiling it for different platforms. In other words, I still have a lot to learn about kernel programming and device drivers, so it will probably take a good number of attempts before I have a real TTY driver for the 68901 UART.
When that is complete someday, it should be possible to get at real shell. Then the next thing will be a SPI master driver for the TP3465.
Until then, the T030 can only spew out the output from a couple of commands to /dev/kmsg, but I guess it’s enough to say: Yes, the T030 runs Linux. 🙂