Home » RBC Forums » General Discussion » Linux on KISS-68030 single board computer
Linux on KISS-68030 single board computer [message #349] |
Sun, 21 February 2016 14:30  |
 |
will
Messages: 213 Registered: October 2015
|
Senior Member |
|
|
Hello everyone!
I am pleased to announce my first release of Linux for the KISS-68030!
I've made a slightly rambling video to show the board and demonstrate it working: https://www.youtube.com/watch?v=MYpMOBaohbw
Not sure how the group feels about the video format - I think it's a good way to properly demonstrate a system which others may not have access to. Feedback is welcomed -- and I'd love to see videos from other SBC and S-100 builders!
Current status:
- ROM supports loading COFF, ELF executables from FAT filesystem
- Linux has been ported to the machine and I have written drivers for all of the hardware
- System appears to be very stable
- System is self-hosting; the ROM and the Linux kernel can both be built on the machine itself.
Required hardware:
- Power supply (I used my bench power supply set to 5V 2A)
- ECB backplane
- KISS-68030 CPU board
- MF/PIC I/O board (you must first apply the 2015-09-22 update to connect IDE IRQ to NS32202 IRQ9)
- 8GB CompactFlash card and IDE adapter (possibly a regular hard disk will work also)
I have uploaded a ZIP file (331MB) which contains:
- Boot ROM image
- Patch against Linux 4.4.1 source code
- README file with further instructions
- CompactFlash card disk image: This includes a boot filesystem and a current Debian Linux root filesystem with a bunch of standard tools. This has gcc and the other tools required to rebuild the kernel and ROM from the source code (also included).
I think at this stage the Linux support for this board is complete, pending hardware additions! My next objective is to connect the machine to a TCP/IP network. I think the simplest way to achieve this will be to add another UART for a PPP serial link. Initially I will use a second MF/PIC board with some modifications, essentially omitting the NS32202 and DS1302 and re-routing the interrupts. I am waiting for the PCB and components to arrive so I can start work on that. John is also working on a quad-UART board design which will be a better solution when it becomes available.
Copy of the README file follows. Share and enjoy!
Debian Linux for KISS-68030
To make this work:
- configure your MF-PIC at a base address of 0x40 (which is the standard
setting).
- fit as much RAM as possible. I suspect 16MB is the minimum required to boot
to multiuser.
- fast CPU recommended.
- get an 8GB or larger Compact Flash card, and write the disk image to it:
bunzip -dc 2016-02-20-kiss68030-hddimage.dd.bz2 | dd bs=1M of=/dev/sdX
where /dev/sdX is the name of your CF card (note: the whole card, not a
partition on it, ie /dev/sde instead of /dev/sde1). The Compact Flash
card contains:
- First partition (128MB): A FAT format filesystem, used by the boot ROM.
- Second partition (about 7GB): An ext4 format filesystem, used by Linux.
- Third partition (1GB): Swap space for Linux. Try to avoid using this!
- Connect the CF card to the IDE port on the MF-PIC.
- write "kissbios.rom" to your ROM chip -- I have padded the file to 512KB to
make this easier, however only the first 46KB is actually used so you could
use a smaller flash ROM chip if you need to (this is untested)
- set your terminal to 115200 baud, 8 bit data, no parity, 1 stop bit, and
enable RTS/CTS hardware flow control.
- power on the system. On the first boot you will want to run Setup by
pressing "s" immediately on power-on. Enable IDE Board Type 1 ("Parallel
Port") at Base port address 44 hex. Then on rebooting the system it should
run the ROM. This should detect the CF card, find "boot.cmd" on it, and boot
it automatically after 1--2 seconds.
- Linux should boot and after about 10 minutes you should be able to log in with
username "root", password "root".
- Useful tricks:
rz, sz -- Z-Modem file transfer through console
screen -- Run multiple sessions on one terminal (read the man page)
flash030 -- Reprogram the flash ROM in-system
nice -- Run a program with reduced CPU priority
- When you're finished, type "halt".
Source code and build environment:
- Source code for the Linux kernel, boot ROM and flash030 is all in the /root/
directory on the Linux filesystem. The filesystem image includes all the
tools to build these on the KISS-68030 system itself, or you can
cross-compile on a faster machine.
Notes on the ROM:
- It is only really useful with a CF card present.
- If a file named "boot.cmd" is present it will be used as a list of commands
to automatically boot the system.
- If "boot.cmd" is not present the system will drop to the ROM command line
rather than automatically booting.
- Pressing "x" or "s" quickly after reset will drop to the command line or
enter setup, respectively. Note that any other key will skip the delay and
automatically boot immediately.
- At the ROM command line:
- If you have multiple disks, 0:, 1:, 2:, 3: etc will switch between them
- "cd" will change directory
- "ls" or "dir" will list the directory.
- typing a file name will try to load it as a program:
- COFF or ELF executables are supported. A single argument of "u" or "s"
will cause the program to run in user or supervisor mode, respectively:
"myprog.elf u"
- Linux kernels are supported. Arguments are passed to the kernel verbatim,
with the exception of "initrd=<filename>" which can be given to load an
initrd image into memory for the kernel:
"vmlinux.elf initrd=initrd.img console=ttyS0,115200n8r init=/bin/bash"
- Any other arbitrary file can be loaded by giving the load-address as
address (in hex):
"myprog.bin 1000"
- "execute <addr> [u|s]" will jump to a given address in user or supervisor
mode.
- "writemem <addr> <byte...>" will write to a given address in memory. You
can use "wm" as a shorthand.
- "dump <addr> <count>" will dump the contents of the specified region of
memory in hex and ASCII. You can use "dm" as a shorthand.
[Updated on: Thu, 25 February 2016 11:27] Report message to a moderator
|
|
|
|
|
Re: Linux on N8VEM KISS-68030 single board computer [message #353 is a reply to message #351] |
Mon, 22 February 2016 07:57   |
 |
Andrew B
Messages: 467 Registered: October 2015 Location: Near Redmond, WA
|
Senior Member Administrator |
|
|
Will, how difficult was it to write the custom patches to make this all work? I've looked at 68xxx-series Linux stuff a few times and it has been really hard to find good information - the m68k website is from 2001 and talks about kernel 2.x, the Debian wiki sites are way out of date, etc. I wasn't even aware that anyone was working on new m68k kernels.....
[Updated on: Mon, 22 February 2016 07:57] Report message to a moderator
|
|
|
|
|
Re: Linux on N8VEM KISS-68030 single board computer [message #357 is a reply to message #356] |
Mon, 22 February 2016 10:24   |
 |
will
Messages: 213 Registered: October 2015
|
Senior Member |
|
|
Hi Greg
To clarify -- to boot a full Debian system to a "login:" prompt (runlevel 2) takes about 10 minutes.
For most of my testing I have been booting the kernel and just running bash. To do this I boot with the argument "init=/bin/bash". This is very quick, about 20 seconds from hitting enter in the ROM to seeing the bash prompt appear.
The disk image I have supplied is a full Debian system - kernel which has full support for the KISS-68030 hardware, userspace which has a bunch of packages installed including python, perl, gcc, make, etc, and source code for the kernel, ROM, and my flash030 utility.
|
|
|
Re: Linux on N8VEM KISS-68030 single board computer [message #360 is a reply to message #357] |
Mon, 22 February 2016 11:12   |
 |
w9gb
Messages: 55 Registered: October 2015 Location: Chicago, IL
|
Member |
|
|
Will -
Perfect.
About 20 seconds to load kernel and then have bash prompt ...
that jarred my memory (Apple Mac II, NeXT Cube) from 25+ years ago (has it really been that long!!).
It is almost 30 years since the 68030 was introduced by Motorola
You also answered my follow-up question: You are loading the full Debian system (hence the 10-minutes).
My personal preference is pack light (years of airline travel will do that), so that can be improved by lightening the load.
Greg
[Updated on: Mon, 22 February 2016 11:13] Report message to a moderator
|
|
|
|
|
Re: Linux on N8VEM KISS-68030 single board computer [message #368 is a reply to message #367] |
Wed, 24 February 2016 12:22   |
 |
will
Messages: 213 Registered: October 2015
|
Senior Member |
|
|
Yes, the system is certainly CPU limited. I spent a bit of time optimising the disk I/O -- with my 32MHz CPU it runs at about 750KB/sec which is not bad. I made it go slightly faster (single digit %) by unrolling the inner loop but removed this for other reasons.
The transfer functions look like this, suggestions for improvements welcomed!
kiss68030_ide_data_input:
moveal %sp@(4),%a0 /* void *buf */
moveal %sp@(12),%a1 /* 8255 base address */
movel %sp@(8),%d1 /* int dwords */
/* save registers */
movem.l %d2-%d3/%a2,-(%sp)
lea %a1@(3),%a2 /* 8255 control register */
moveq #13, %d2
moveq #12, %d3
/* skip to the end - to test for dwords=0 */
jbra ide_input_loop
ide_input_nextword:
/* read a DWORD */
moveb %d2, %a2@ /* begin /RD pulse */
movew %a1@, %d0 /* reads LSB then MSB in that order */
moveb %d3, %a2@ /* end /RD pulse */
swap %d0 /* move to the top half of the word */
moveb %d2, %a2@ /* begin /RD pulse */
movew %a1@, %d0 /* reads LSB then MSB in that order */
moveb %d3, %a2@ /* end /RD pulse */
/* store to memory */
movel %d0, %a0@+
/* loop until done */
ide_input_loop:
dbra %d1, ide_input_nextword
/* restore registers, return */
movem.l (%sp)+,%d2-%d3/%a2
rts
kiss68030_ide_data_output:
moveal %sp@(4),%a0 /* void *buf */
moveal %sp@(12),%a1 /* 8255 base address */
movel %sp@(8),%d1 /* int dwords */
/* save registers */
movem.l %d2-%d3/%a2,-(%sp)
lea %a1@(3),%a2 /* 8255 control register */
moveq #11, %d2
moveq #10, %d3
/* note that to give the drive time to latch the data we do
housekeeping including swaps and branches while the /WR
line is asserted -- so the first thing we do each loop is
end the previous cycle's /WR pulse, which is a NOP on the
entry to the first loop */
/* skip to the end - to test for dwords=0 */
jbra ide_output_loop
ide_output_nextword:
/* load from memory */
movel %a0@+, %d0
/* write a DWORD */
moveb %d3, %a2@ /* end /WR pulse -- nop on the first loop*/
swap %d0 /* top half first */
movew %d0, %a1@ /* set up data lines */
moveb %d2, %a2@ /* begin /WR pulse */
swap %d0 /* get the bottom half */
moveb %d3, %a2@ /* end /WR pulse */
movew %d0, %a1@ /* set up data lines */
moveb %d2, %a2@ /* begin /WR pulse */
/* loop until done */
ide_output_loop:
dbra %d1, ide_output_nextword
moveb %d3, %a2@ /* end the final /WR pulse */
/* restore registers, return */
movem.l (%sp)+,%d2-%d3/%a2
rts
[Updated on: Wed, 24 February 2016 16:25] Report message to a moderator
|
|
|
Re: Linux on N8VEM KISS-68030 single board computer [message #385 is a reply to message #368] |
Sat, 27 February 2016 22:43   |
 |
Andrew B
Messages: 467 Registered: October 2015 Location: Near Redmond, WA
|
Senior Member Administrator |
|
|
Will, is the Debian userspace you used new enough to have systemd?
I bet there are a lot of opportunities to get that full userspace boot time down. Here is a presentation a guy at Ti gave about reducing userspace boot times from 120 seconds to 1 second on a Ti development board - http://elinux.org/images/b/b3/Elce11_koen.pdf - a factor of 120 improvement - even if we could erk out a factor of 10 improvement, it would make things a lot better as far as the full userspace.
I'd really like to get a page in the "firmware/OS" section of the RBC wiki created for this - as well as the KISS-68030 page updated.
[Updated on: Sat, 27 February 2016 22:44] Report message to a moderator
|
|
|
|
|
|
|
Re: Linux on KISS-68030 single board computer [message #410 is a reply to message #394] |
Fri, 04 March 2016 14:43   |
 |
will
Messages: 213 Registered: October 2015
|
Senior Member |
|
|
Hi all
Quick update: I have the "secondary" MF/PIC board assembled. It provides UART and IDE interfaces only, interrupts are routed (through spare inverters) to the bus IRQ lines (I am using IRQ0 for serial, IRQ1 for IDE) and handled by the NS32202 on the primary MF/PIC. About a dozen chips on the secondary board can be omitted.
Both IDE and UART interfaces are confirmed working.
I have swapped the AHCT login on the bus transceivers for LS series. No noise issues observed (so far!) in combinations of bus slots which were previously problematic.
I had some issues with the interrupt controller; the timer would stop ticking when Linux booted. Resolved by increasing from 2 to 3 wait-states on I/O. I have not had this previously, unclear if the change to slower LS logic on the transceivers is related. I have enough chips to swap all back to AHCT so I may try that when I have the software issues sorted.
I have PPP up and running on the second UART; I can ping stuff on the internet etc. However some issues remain to investigate:
root@darkstar:~# wget sowerbutts.com
--2016-03-04 22:11:33-- http://sowerbutts.com/
Resolving sowerbutts.com (sowerbutts.com)... 195.149.84.65
Connecting to sowerbutts.com (sowerbutts.com)|195.149.84.65|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 2188 (2.1K) [text/html]
Saving to: 'index.html'
index.html 0%[ ] 0 --.-KB/s in 0s
2016-03-04 22:11:33 (0.00 B/s) - Read error at byte 0/2188 (Invalid argument). Retrying.
Possibly wget is using some kernel feature I've compiled out, or maybe it doesn't like the fact that our timers have only 10ms resolution. Need to investigate. Telnet to port 80 on the web server and typing the request in by hand works fine so the TCP stack is certainly working.
I have issues with interrupt priorities; with the 1Mbit/sec serial port on IRQ0 (highest priority) it is possible to send data at 1Mbit/sec and overwhelm the machine. Similarly with second IDE on IRQ1 and timer on IRQ8 when you use the second IDE interface heavily about 60% of timer interrupts are lost.
I have looked in the NS32202 datasheet and I see it has several different priority modes including a "rotating priority" mode. Also there is the option of edge/level triggering. There is also interrupt nesting to consider. I need to sit down and figure out which modes would be best and how they would interact with Linux's IRQ handling.
It may be that the best solution is actually to have the timer as the highest priority interrupt, followed by the serial ports, with IDE last. This may mean some more hardware mods to re-arrange to fit the required order.
Can anyone confirm my ideas about the '202;
- An EOI cycle (ie read with A13 set) simply clears the highest priority bit that is set in the ISRV register
- The CPU can also clear the bit in ISRV itself by reading, masking, and writing back the register; doing this removes the need for a separate EOI
- Writing (eg) 8 to FPRT will make IRQ8 the highest priority, so the priority order becomes: 8, 9, 10, 11, 12, 13, 14, 15, 0, 1, 2, 3, 4, 5, 6, 7 ie it just rotates the priority around -- the datasheet is unclear on this point.
Also can anyone confirm my understanding that we could run all the devices on this system in EITHER edge or level triggered modes without issue.
If anyone has thoughts on edge vs level, priorities, and the various modes of the 202, input would be most welcome at this stage.
Hmmmmmm. Lots to think about! But enough for tonight. Tomorrow I am in London all day so it will probably be Sunday before I get to look at this again.
|
|
|
Re: Linux on KISS-68030 single board computer [message #414 is a reply to message #410] |
Mon, 07 March 2016 05:57   |
 |
will
Messages: 213 Registered: October 2015
|
Senior Member |
|
|
Hi all
I have implemented both NS32202 hardware-controlled priority interrupts (any interrupt in service masks all lower priority interrupts), and a mode in which the kernel treats the NS32202 as a "dumb" level sensitive interrupt controller. One can choose between them at build time. I am using the hardware prioritised mode on my system.
I have re-arranged interrupts on my system very slightly - moving only IDE1. The NS32202 allows one to specify the highest priority interrupt, so I have made it IRQ10 which I have assigned to the timer tick. I have chosen to place the timer tick as highest priority, then any UARTs, then any disk interfaces.
With this change I no longer see lost timer ticks when the IDE1 port is in use.
The new IRQ allocation in my system is as follows:
IRQ DEVICE
0 UART1
1 4UART A (future)
2 4UART B (future)
3 4UART C (future)
4 4UART D (future)
5
6
7 IDE1 <-- moved (was previously IRQ 1)
8
9 IDE0
10 TIMERH <-- highest priority (then 11, 12, ... 15, 0, 1, ... 9 is lowest)
11
12 UART0
13
14
15 TIMERL (unused. IRQ11 may be a better choice; software configurable)
I have implemented a mechanism for the kernel to read the NS32202 timer to get higher resolution time information. It now measures real time using the full resolution of the 1.8432MHz system timer.
I am back to 2 I/O wait states. I discovered that the 2A limit I had configured on my power supply was being exceeded now that I am using 74LS for the bus transceivers and have the secondary MF/PIC and additional CF card in the system. My power supply was therefore going into current limiting mode and the voltage to the system was dropping. Whoops! I think this is what was causing the NS32202 timer to drop out. I have raised the current limit to 3A which is sufficient and the system now appears stable at 2 wait states again.
I am still running the PPP link at 1Mbit/sec. I am pretty confident the system cannot sustain this data rate but have not had time to look into it fully yet.
Both UARTs are running with the receive FIFO threshold at 32 bytes. The threshold is runtime configurable through a file in /sys. 32 bytes is probably the best choice for this system.
I have telnetd working on the system so one can telnet in over the PPP link. Works pretty well!
I have tried to get sshd working as well. It built the host keys (which takes nearly an hour!) and the daemon runs. One can get part way through the authentication process, but then the daemon dies with a SIGSEGV. Not quite sure why yet, but as the kernel also emits a stack backtrace at the same time I expect it may be some kernel feature I have configured out.
I am currently working on getting the KISS68030 support to "play nice" with the other m68k architectures so one can use a kernel that boots on all m68k machines on KISS68030. This will be an important step if we are ever to get support merged into mainline, which may be unlikely with fewer than ten machines in the world, but it will likely make it easier for us to maintain support out-of-tree also. Currently this effort has run aground with a null pointer dereference in the serial console driver. Ugh. I will keep hacking at it.
Will
|
|
|
|
|
|
|
|
|
|
Re: Linux on KISS-68030 single board computer [message #444 is a reply to message #439] |
Mon, 28 March 2016 09:17   |
 |
will
Messages: 213 Registered: October 2015
|
Senior Member |
|
|
Hi all
I have identified what appears to be a hardware flow control bug in the Linux 8250 UART driver, when handling the TL16C750.
I discovered the fault when I moved from a terminal emulator on a PC to my DEC VT510. The PC is very fast and uses a USB RS232 adapter with very deep (multiple kilobyte) FIFOs, consequently the KISS system's output is rarely (if ever) flow controlled. The VT510 is slow enough that, at 115200 baud, hardware flow control is required to avoid overruns.
The VT510 uses the DTR line to indicate when it has space in its input FIFO buffer. The VT510 DTR line is wired up to the CTS input on the MF/PIC UART.
Linux enables hardware-assisted flow control on the TL16C750, ie the chip is responsible for generating the outgoing RTS signal and monitoring the incoming CTS signal; the hardware will not begin transmitting a new character while the CTS line is asserted. When the CTS line is de-asserted it will continue transmission automatically.
In principle this should work perfectly, indeed most of the time it does. However when outputting a lot of text to the VT510 I find the output just stops after a while, apparently at random. Nothing further happens until I send some input to the terminal eg by typing a character -- then the output will continue, although it may halt again a short while later.
If I knobble the 8250 driver to disable this hardware-assisted feature, ie handle RTS and CTS just like a standard 16550, the issue goes away. Similarly if I use the VT510 with another serial device which can generate data faster than it can consume it (I tested with my PC) the issue does not occur. So it looks to be a fault with the flow control of output from the TL16C750.
I grabbed my scope and hooked up probes to:
- TX line (cyan trace; output from MF/PIC MAX232)
- CTS line (yellow trace; input to MF/PIC MAX232, note this signal is active low)
- UART IRQ line (magenta trace; input IRQ12 on NS32202 pin 5)
As usual deploying the scope quickly shed a lot of light on the problem.

This shows sending a bunch of data, then the eventual hang.

This is the same trace, zoomed in to show the last gasp. You can see the data transmission halts when the CTS line is asserted, but when it is later de-asserted the transmission does not resume.

This zooms in further on the last few bytes, and I think this reveals the issue: We take an interrupt from the UART to refill the TX buffer just as the CTS line is asserted. You can see here the scope decoding the last six bytes transmitted, "- 0038", which were indeed the last bytes to appear on the terminal. You can see the interrupt line asserted and released.
My guess at this stage is that Linux is reading out the CTS line in the interrupt handler, deciding to stop transmission because CTS is asserted, and expecting an interrupt when CTS is released. The hardware, meanwhile, believes that *it* is handling the CTS line, so it will not generate an interrupt when it is released.
Will do some digging in the driver source code and report back. I suspect the fix will be either: Disable auto-CTS when disabling the transmitter (but this may cause a race condition), or do not check CTS when auto-CTS is enabled.
Will report back.
Will
[Updated on: Tue, 29 March 2016 10:29] Report message to a moderator
|
|
|
Re: Linux on KISS-68030 single board computer [message #445 is a reply to message #444] |
Mon, 28 March 2016 09:51   |
 |
will
Messages: 213 Registered: October 2015
|
Senior Member |
|
|
Well that was quicker to fix than I expected!
The fix is in and works perfectly. It is almost a one-liner. I will submit to the serial driver maintainer.
--- linux-4.5/drivers/tty/serial/8250/8250_port.c 2016-03-14 04:28:54.000000000 +0000
+++ linux-4.5-kiss/drivers/tty/serial/8250/8250_port.c 2016-03-28 17:55:45.580249260 +0100
@@ -2309,8 +2309,12 @@
*/
if (up->capabilities & UART_CAP_AFE && port->fifosize >= 32) {
up->mcr &= ~UART_MCR_AFE;
- if (termios->c_cflag & CRTSCTS)
+ port->status &= ~UPSTAT_AUTOCTS;
+
+ if (termios->c_cflag & CRTSCTS) {
up->mcr |= UART_MCR_AFE;
+ port->status |= UPSTAT_AUTOCTS;
+ }
}
/*
[Updated on: Mon, 28 March 2016 10:25] Report message to a moderator
|
|
|
|
Re: Linux on KISS-68030 single board computer [message #7859 is a reply to message #349] |
Thu, 09 July 2020 09:37  |
jvmartins
Messages: 1 Registered: June 2020
|
Junior Member |
|
|
Hi Will,
A few weeks back i was zapping on Youtube when i saw your retrobrew computer project which have caught my attention.
First of all, your project is Fantastic.
Took me a few days with your project going around my head. I had to try to do one myself.
Acquired the PCB's from Richard Cini, which already shipped them and hopeful i'll receive then in the next few days.
I know i have a nice journey in from of me, but i hope i can count on your support if i find some dead ends in the journey.
By listening your video i see that you used one MC68030RC33C at 33Mhz instead of the recommended 16 and 25Mhz in the documentation.
For that we need to alter the CPU oscillator to 32Mhz.
Did you altered any other component specification?
I started looking for the parts list for the 3 PCB boards (KISS-68030, MF/PIC board and the ECB back-plane).
Do you have record of your parts list that you could share with parts-numbers from any known vendor?
Regarding the old Motorola CPU i'm looking in Ebay for one but i'll wait for your reply before buying.
Kind regards,
Joao Vaz Martins
|
|
|
Current Time: Sun Mar 16 03:22:42 PDT 2025
Total time taken to generate the page: 0.00696 seconds
|