Close

Sometimes You Have To Rebuild Everything

A project log for Mackerel 68k Computer

A computer engineering journey through the Motorola 68k CPU family

colin-maykishColin Maykish 09/22/2022 at 02:031 Comment
Second handmade revision of Mackerel on a backplane

The rat's nest of wires I've been calling the Mackerel 68k has been completely rebuilt. It's now a slightly smaller rat's nest, but it's on a much nicer backplane with more thought given to the bus pinout, power delivery, and noise reduction.

I have a few 8-bit computer designs in various states of development, so I built a backplane I could use for all of them.

New backplane for 8-bit computers

The big updates are more power and ground pins dispersed throughout the bus, a 4-layer PCB with solid power/ground planes internally, and a MCP2221A USB-serial converter built in.
Since the pinout of the backplane is completely different from the first iteration of Mackerel, I rebuilt the component boards as well. The RAM/ROM board design is unlikely to change, so I committed it to a PCB. I'm actually using one and three-quarters of these boards for a total of 3.5MB of RAM. The remaining 512KB of available address space is used by the ROM and the serial port.

2 MB SRAM, 512KB ROM with programmable address decoder

The CPU is still the same 52-pin 68008, but the address decoder and glue logic has moved to an FPGA. This is ridiculous overkill, but I wanted to rule out some stability issues that I thought may have been caused by the EPM7064 CPLD I was using previously. Since the Upduino is a 3.3v part, I connected it to the system bus via 74HC245 bus transceivers acting as level shifters.

Finally, I replaced the 68901 and the classic 68681 with a single XR68C681. The MFP was working alright as a system timer, but the serial port was just too slow. The 68681 can technically run at 115200, but requires a weird hack involving the timer circuit to generate the right clock. The XR68C681 has native support for 115200 baud without resorting to hacks, leaving the timer free to use as a periodic interrupt. It does this beautifully.

On the programmable logic side, I simplified the address decoding and removed all of the DTACK generation logic (I just grounded the pin for now). All of my components are capable of running at the 8 MHz supported by the CPU without any wait states, so this just makes things simpler.

The rebuild was a huge success. I spend some time updating my Linux kernel code to use the new DUART for serial output and the system timer, compiled, and loaded the kernel into RAM over the serial port. On the first boot, I got farther than I ever did on the old system.

Still getting an error, but it's a new and exciting error:

Jumping to 0x8000
5Linux version 4.4.0-uc0 (colin@ada) (gcc version 11.3.0 (GCC) ) #3 Wed Sep 21 20:42:55 EDT 2022
6Herring-8 68k support by Colin Maykish 
6

uClinux/MC68000
6Flat model support (C) 1998,1999 Kenneth Albanowski, D. Jeff Dionne
7On node 0 totalpages: 888
7free_area_init_node: node 0, pgdat 000e8064, node_mem_map 000ff100
7  DMA zone: 7 pages used for memmap
7  DMA zone: 0 pages reserved
7  DMA zone: 888 pages, LIFO batch:0
7pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
7pcpu-alloc: [0] 0 
6Built 1 zonelists in Zone order, mobility grouping off.  Total pages: 881
5Kernel command line: 
6PID hash table entries: 1024 (order: 0, 4096 bytes)
6Dentry cache hash table entries: 1024 (order: 0, 4096 bytes)
6Inode-cache hash table entries: 1024 (order: 0, 4096 bytes)
6Memory: 2480K/3552K available (787K kernel code, 30K rwdata, 80K rodata, 36K init, 41K bss, 1072K reserved, 0K cma-reserved)
5Virtual kernel memory layout:
    vector  : 0x00000000 - 0x00000400   (   1 KiB)
    kmap    : 0x00000000 - 0xffffffff   (4095 MiB)
    vmalloc : 0x00000000 - 0xffffffff   (4095 MiB)
    lowmem  : 0x00008000 - 0x00380000   (   3 MiB)
      .init : 0x000e9000 - 0x000f2000   (  36 KiB)
      .text : 0x00008000 - 0x000cced0   ( 788 KiB)
      .data : 0x000cced0 - 0x000e8a00   ( 111 KiB)
      .bss  : 0x000f2000 - 0x000fc568   (  42 KiB)
6NR_IRQS:32
6clocksource: timer: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1911260446275000 ns
6Calibrating delay loop... 0.69 BogoMIPS (lpj=3459)
6pid_max: default: 32768 minimum: 301
6Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
6Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
6clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
6clocksource: Switched to clocksource timer
3dummy-irq: no IRQ given.  Use irq=N
3Warning: unable to open an initial console.
6Freeing unused kernel memory: 36K (000e9000 - 000f2000)
0Kernel panic - not syncing: No working init found.  Try passing init= option to kernel. See Linux Documentation/init.txt for guidance.
0---[ end Kernel panic - not syncing: No working init found.  Try passing init= option to kernel. See Linux Documentation/init.txt for guidance.
5random: nonblocking pool is initialized

We've made it all the way through the kernel startup code and got a panic when no `init` program was found. This is great news, and totally expected since I have no filesystem and thus no `init` binary in the Linux image. Helpfully, the error message suggests you read the documentation which provides a handy list of things to check:

A) Unable to mount root FS
B) init binary doesn't exist on rootfs
C) broken console device
D) binary exists but dependencies not available
E) binary cannot be loaded

Pretty much all of these apply. As well as having no filesystem, I still have not implemented a real serial console driver. So I've got a checklist to get through before Mackerel can make the jump from kernel space to user space, but I'm super happy to have gotten this far. The Linux boot process has been stable and consistent which gives me a lot more faith in the hardware. All of my problems should now be software problems.

Discussions

Gravis wrote 09/23/2022 at 07:49 point

It looks like you have built working computer. Congratulations! Looking forward to your Doom port. :P

  Are you sure? yes | no