Does this kind of MMU makes sense

[technix]

This MMU is intended for MC68SEC000. It offers only coarse memory remapping.

Since the chip has 16MB memory space and requires memory-mapped I/O, that would be the basis of the design. The memory space is split into 16x 1MB pages, called page 0 through page F. Any page P has address range 0xP00000 to 0xPFFFFF. Memory pages 1 through D, as well as page F are regular pages. Page 0 is almost a regular page but addresses 0x000000-0x000007 can reads as fixed contents. Page E is dedicated I/O address space.

This separation of data and I/O space effectively gave the machine 17MB of physical memory space. Before going deeper in the mapping, here is the physical memory mapping I am using:
* 0x000000-0x5FFFFF: 6MB SRAM
* 0x600000-0x7FFFFF: 2MB NOR Flash
* 0x800000-0xFFFFFF: Unused
I/O space are subdivided into 32kB blocks, with each block corresponding to one chip:
* 0xE00000-0xE07FFF: INTC
* 0xE08000-0xE0FFFF: DMA
* 0xE10000-0xE17FFF: MMU
* 0xE18000-0xEFFFFF: Other peripherals, up to 29 chip selects.

The MMU has 16 TLB entries, corresponding to the 16 memory pages. Each TLB entry is one byte long, with a structure:

Code: [Select]

struct tlb_entry {
    uint8_t physical:4;
    bool exist:1;
    uint8_t:3;
} __attribute__((packed));The exist field marks whether the page is loaded or not. Accessing a nonexistent page will result in the MMU not emitting any chip selects. The physical field contains the physical page address for the virtual page. The TLB entry for page E, while exists, is ignored. The TLB is located at address 0xE10000-0xE1000F.

Upon bus reset, only three TLB entries are defined: logical pages D, E and F. Logical page D is mapped to RAM at physical page 0, page E is the I/O space, and logical page F is mapped to Flash at physical page 6.

The bus matrix maps a small internal ROM to address 0 with contents 0x00E00000 and 0x00F00000, allowing the CPU to boot with stack pointer located at the end of mapped RAM and program counter at the beginning of mapped Flash. This small ROM can be de-mapped by writing byte 0x00 to 0xE10010.

[westfw]

"Makes sense" for what purpose?

Accessing a nonexistent page will result in the MMU not emitting any chip selects.

Does that end up causing a bus error?

[bson]

Do you need an MMU for this?  It looks like pretty straightforward address decoding, given the original 68000 can't restart instructions on page faults.

[iMo]

The OP wants to run linux on it, it seems. Not sure it is worth the effort. I loved the 68k CPU in mid 80ties (Atari 520STM w/ 1MB ram owner).

A 68k emulator running on a Cortex M4 or pic32MZ will be faster than the 20MHz 68k, imho.

PS:
@technix: take your pic32MZDA and try..

[technix]

"Makes sense" for what purpose?

As a rudimentary page switching mechanism for 68000, so I can properly boot to Flash and use RAM as interrupt vectors.

Accessing a nonexistent page will result in the MMU not emitting any chip selects.

Does that end up causing a bus error?

It *should* result in a bus error, but since 68000 has a broken bus error recovery I am currently allowing it to fail silently.

[technix]

The OP wants to run linux on it, it seems. Not sure it is worth the effort. I loved the 68k CPU in mid 80ties (Atari 520STM w/ 1MB ram owner).

A 68k emulator running on a Cortex M4 or pic32MZ will be faster than the 20MHz 68k, imho.

PS:
@technix: take your pic32MZDA and try..

PIC32MZ DA is almost guaranteed to be able to run Linux, since it is an integrated SoC with proper MMU and everything as well as a mainlined BSP. (I would also just drop stock Debian on top of it - no fun really after everything booted, I have my Raspberry Pi's for similar projects.)

As of the 68000, since it has a bugged bus error recovery anyway the Linux dream was long dashed.

[technix]

Do you need an MMU for this?  It looks like pretty straightforward address decoding, given the original 68000 can't restart instructions on page faults.

I still want to have some flexibility when mapping memory. Also I want to be able to boot from Flash and have the interrupt vector located in RAM.

[nfmax]

This problem was solved long, long ago. The trick is to use two 68000's. One runs the UNIX O/S (this was before the days of Linux) while the other idles. When the O/S CPU hits a page fault, it is held in indefinite wait for the memory to be ready, while the second 68000 loads the missing page from disc. Once it is loaded, the wait on the O/S processor is released and it continues with the faulting instruction as though the fault had never happened.

PCS Cadmus Unix System V, sometime in the mid to late 80's

[janoc]

As a rudimentary page switching mechanism for 68000, so I can properly boot to Flash and use RAM as interrupt vectors.

If this is all you need then a much simpler solution is a cycle counter that will remap the memory after the first bus cycles fetching the stack and pc counter values.

[janoc]

This problem was solved long, long ago. The trick is to use two 68000's. One runs the UNIX O/S (this was before the days of Linux) while the other idles. When the O/S CPU hits a page fault, it is held in indefinite wait for the memory to be ready, while the second 68000 loads the missing page from disc. Once it is loaded, the wait on the O/S processor is released and it continues with the faulting instruction as though the fault had never happened.

PCS Cadmus Unix System V, sometime in the mid to late 80's

That trick is long obsolete. If  you really really need MMU on a 68k, use the newer variant which has it fully functional. Like MC68010.

The hack with two processors is very complicated to implement.

[technix]

This problem was solved long, long ago. The trick is to use two 68000's. One runs the UNIX O/S (this was before the days of Linux) while the other idles. When the O/S CPU hits a page fault, it is held in indefinite wait for the memory to be ready, while the second 68000 loads the missing page from disc. Once it is loaded, the wait on the O/S processor is released and it continues with the faulting instruction as though the fault had never happened.

PCS Cadmus Unix System V, sometime in the mid to late 80's

That is way too complicated - If I need to use two 68000 and MMU, I’d go with two 68010s in SMP. Actually dual 68010 in SMP has a simpler logic than locksteping the two 68000s. And Linux since version 2.0 already supports SMP so I get better performances as well.

[technix]

As a rudimentary page switching mechanism for 68000, so I can properly boot to Flash and use RAM as interrupt vectors.

If this is all you need then a much simpler solution is a cycle counter that will remap the memory after the first bus cycles fetching the stack and pc counter values.

How to implement that?

[legacy]

Linux

Linux on 68000 is a bad idea. Even running Linux on a modified Apple LC475 (replace the CPU with a MC68040 with MMU and FPU) is ... slow, too slow and not comfortable at all.

Why don't you look for a more appropriate OS?

[legacy]

As a rudimentary page switching mechanism for 68000, so I can properly boot to Flash and use RAM as interrupt vectors.

Look at the Motorola 68000 Educational board, the rudimentary page switching mechanism to properly boot from a flash and then remap to RAM can be done easily without any MMU.

[technix]

Linux

Linux on 68000 is a bad idea. Even running Linux on a modified Apple LC475 (replace the CPU with a MC68040 with MMU and FPU) is ... slow, too slow and not comfortable at all.

Why don't you look for a more appropriate OS?

Any recommendations? Linux is just an example, but for MMU-equipped machines I do like to use some flavor of GNU-capable UNIX, even though it might have to be an old version of BSD built with GCC 2.95 or something.

Bare minimum would be a ported xv6 with newlib and busybox. xv6 itself is a C99 reimplementation of the PDP/11 Version 6 Unix with full documentation intended for one semester of undergraduate course at MIT, so it should be have a lower barrier of entry to separate the current x86 drivers out, add m68k drivers, and implement some modern POSIX syscalls so newlib would work.

[SiliconWizard]

http://www.linux-m68k.org/dists.html

Of course Linux 68k will be slow compared to how it runs on a Core i7 , but it does work.
I'm guessing you will have to rewrite some part of the kernel to support your MMU?

[legacy]

Of course Linux 68k will be slow compared to how it runs on a Core i7 , but it does work.

emm, on my LC475

m68k ~ # dmseg

Code: [Select]

version 2.6.27-rotary-wombat-m68k-apple-lc475-68040
- compiled by root@queen-vittoria
- compiled with gcc version 3.4.5
- compiled on 19 Tue Jan2009
Detected Macintosh model: LC475
 Bootinfo data:
 Video: addr 0xf9001000 row 0x400 depth 8 dimensions 640 x 480
 Videological 0xf0101000 phys. 0x51901000, SCC at 0x50f0c020
 Boottime: 0xe71c3e2a GMTBias: 0x0
 Machine ID: 90 CPUid: 0x2 memory size: 0x24
VIA1 at 50f00000 is a 6522 or clone
VIA2 at 50f02000 is a 6522 or clone
On node 0 totalpages: 9216
free_area_init_node: node 0, pgdat 00207b9c, node_mem_map 00257000
  DMA zone: 9135 pages, LIFO batch:1
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 9135
Kernel command line: root=/dev/sda7 init=/sbin/initmini
mac_init_IRQ(): Setting things up …
- Killing onboard sonic ethernet card ... <6>Done
mac_init_IRQ(): Done!
CPU HACK: 68060 support pack armed
PID hash table entries: 256 (order: 8, 1024 bytes)
mac_enable_irq irq=14, irq_src=1 <6> via_irq_enable <6>
Console: colour dummy device 80x25
console [tty0] enabled
Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
Memory: 34072k/34092k available (1544k kernel code, 1144k data, 84k init)
SLUB: Genslabs=12, HWalign=16, Order=0-3, MinObjects=0, CPUs=1, Nodes=8
Calibrating delay loop... 31.70 BogoMIPS
Mount-cache hash table entries: 512
net_namespace: 292 bytes
NET: Registered protocol family 16
NuBus: Scanning NuBus slots.
Now probing slot E at feffffff
Now probing slot E at fefffffe
Slot E:
  Board resource:
    type: [cat 0x1 type 0x0 hw 0x0 sw 0x0]
    name: EtherNet card
    board id: 0x8
    vendor info:
    ID: TFL LAN INC.
    revision: REV 1.1
    part: E410 NuBus/E420 LC PDS,EtherNet Adapter
  Function 0x08:
    type: [cat 0x4 type 0x1 hw 0x11e sw 0x100]
    name: Network_Ethernet_Apple_TFL
    memory offset: 0x000d0000
    MAC address: 00:a0:4b:08:db:26
SCSI subsystem initialized
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 2048 (order: 2, 16384 bytes)
TCP bind hash table entries: 2048 (order: 1, 8192 bytes)
TCP: Hash tables configured (established 2048 bind 2048)
TCP reno registered
NET: Registered protocol family 1
msgmni has been set to 66
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)
macfb: framebuffer at 0xf9001000, mapped to 0x02800000, size 480k
macfb: mode is 640x480x8, linelength=1024
macfb: scrolling: redraw
Console: switching to colour frame buffer device 80x30
fb0: DAFB frame buffer device
r3964: Philips r3964 Driver $Revision: 1.10 $
Ethernet Channel Bonding Driver: v3.3.0 (June 10, 2008)
bonding: Warning: either miimon or arp_interval and arp_ip_target module parameters must be specified, otherwise bonding will not detect link failures! see bonding.txt for details.
mac8390.c: v0.4 2001-05-15 David Huggins-Daines <dhd@debian.org> and others
eth0: Memory length resource for slot E not found, probing
eth0: EtherNet card in slot E (type apple)
MAC 00:a0:4b:08:db:26 IRQ 61, 32 KB shared memory at 0xfeed0000,  32-bit access.
tun: Universal TUN/TAP device driver, 1.6
tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
input: Macintosh mouse button emulation as /class/input/input0
mac_enable_irq irq=10, irq_src=1 <6> via_irq_enable <6>
Macintosh CUDA driver v0.5 for Unified ADB.
adb: starting probe task …
mac_esp: using PDMA for controller 0
mac_enable_irq irq=19, irq_src=2 <6> (via:present) <6>
esp: esp0, regs[50f10000:0] irq[19]
esp: esp0 is a ESP236, 16 MHz (ccf=4), SCSI ID 7
adb devices: [2]: 2 8
ADB keyboard at 2, handler 1
Detected ADB keyboard, type ANSI.
input: ADB keyboard as /class/input/input1
adb: finished probe task...
scsi0 : esp
osst :I: Tape driver with OnStream support version 0.99.4
osst :I: $Id: osst.c,v 1.73 2005/01/01 21:13:34 wriede Exp $
Driver 'osst' needs updating - please use bus_type methods
scsi 0:0:0:0: Direct-Access     SEAGATE  ST32550N         8607 PQ: 0 ANSI: 2
 target0:0:0: Beginning Domain Validation
Driver 'sd' needs updating - please use bus_type methods
Driver 'sr' needs updating - please use bus_type methods
SCSI Media Changer driver v0.25
Driver 'ch' needs updating - please use bus_type methods
 target0:0:0: FAST-5 SCSI 3.3 MB/s ST (304 ns, offset 15)
 target0:0:0: Domain Validation skipping write tests
 target0:0:0: Ending Domain Validation
mice: PS/2 mouse device common for all mice
NET: Registered protocol family 26
IPv4 over IPv4 tunneling driver
sd 0:0:0:0: [sda] 4194995 512-byte hardware sectors (2148 MB)
TCP bic registered
TCP cubic registered
TCP westwood registered
TCP htcp registered
NET: Registered protocol family 17
NET: Registered protocol family 15
802.1Q VLAN Support v1.8
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: ab 00 10 08
scsi: waiting for bus probes to complete ...
sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, supports DPO and FUA
sd 0:0:0:0: [sda] 4194995 512-byte hardware sectors (2148 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: ab 00 10 08
sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, supports DPO and FUA
 sda: [mac] sda1 sda2 sda3 sda4 sda5 sda6 sda7
sd 0:0:0:0: [sda] Attached SCSI disk
sd 0:0:0:0: Attached scsi generic sg0 type 0
kjournald starting.  Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
EXT3-fs warning: checktime reached, running e2fsck is recommended
EXT3 FS on sda7, internal journal


m68k ~ # gcc -v

Code: [Select]

Target: m68k-unknown-linux-gnu
Configured with: /var/tmp/portage/sys-devel/gcc-4.2.3/work/gcc-4.2.3/configure --prefix=/usr --bindir=/usr/m68k-unknown-linux-gnu/gcc-bin/4.2.3 --includedir=/usr/lib/gcc/m68k-unknown-linux-gnu/4.2.3/include --datadir=/usr/share/gcc-data/m68k-unknown-linux-gnu/4.2.3 --mandir=/usr/share/gcc-data/m68k-unknown-linux-gnu/4.2.3/man --infodir=/usr/share/gcc-data/m68k-unknown-linux-gnu/4.2.3/info --with-gxx-include-dir=/usr/lib/gcc/m68k-unknown-linux-gnu/4.2.3/include/g++-v4 --host=m68k-unknown-linux-gnu --build=m68k-unknown-linux-gnu --disable-altivec --disable-nls --with-system-zlib --disable-checking --disable-werror --enable-secureplt --disable-libunwind-exceptions --disable-multilib --disable-libmudflap --disable-libssp --disable-libgcj --enable-languages=c,c++,objc,obj-c++,treelang,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
Thread model: posix
gcc version 4.2.3 experimental


m68k ~ # cat /proc/cpuinfo

Code: [Select]

CPU:      68060
MMU:      68060
FPU:      68060
Clocking:   33 MHz


Code: [Select]

m68k ~ # nano hAllo.c
include <stdio.h>

int main()
{
   printf("hAllo world, I have done muuuuuuuu again\n");
   return 0;
}


Code: [Select]

m68k ~ # time gcc hAllo.c -o hAllo
real   0m6.890s
user   0m5.620s
sys   0m1.260s
m68k ~ # ./hAllo
hAllo world, I have done muuuuuuuu again


it takes 7 seconds to compile hAlloWorld, and 5 months 24h/h to compile a stage3 

[janoc]

How to implement that?

Easy - make a counter that will reset to zero on system reset, e.g. out of two flip-flops. Clock it with the AS signal. This signal indicates address valid on the bus, so you see when the CPU is trying to read the first two values. When it sees the read, trigger a flip-flop or something that will remap your RAM in place of ROM before the next read cycle happens. And block the counter as well so that it doesn't advance anymore.

I had a schematic of it too but can't find it anymore - it was in the documentation of some Motorola demo board, I believe. However, that shouldn't be to difficult to implement.

Of course, you have to make sure that wherever the code has jumped on reset (the address PC was initialized to) is a valid address   somewhere in the now-remapped ROM containing an initialization routine that will set up the interrupt vectors and other things correctly afterwards. But that shouldn't be too difficult.

EDIT: Found it:
https://www.ist-schlau.de/hardware.html

The circuit comes from Motorola App. Note 897 "MC68008 Minimum Configuration System".

However, there are many other ways to do it - e.g. using a flip-flop that resets on reset, make the CPU jump into a subroutine which will push the address to stack and use the first write cycle signal to trigger the flip-flop and remap the memory.

[legacy]

Any recommendations? Linux is just an example, but for MMU-equipped machines

It depends on what you need and on what you are willing to do.

for example, VxWorks is a very good OS, and it comes with MMU support. I have recently worked with the control board of an industrial sewing machine. This board is based on a dual 68060 CPUs, and the board is connected to a VME bus, and there is VxWorks v5 inside the ROMs.

Unfortunately, it is a proprietary OS made by WindRiver. It can be recompiled with GCC, as well as DiabCC.


XINU is a good didactical OS, well written in C, and very well documented. Hence for personal researching or for fun, I think it's more adequate.

It's up to you, but ... if we compare MacOS9+MacTen(1) vs Linux on the LC475 ... well, the first is usable and comfortable, the second looks just like a dead elephant 

(1) MacTen is cooperative, it's scheduled by MacOS9, and it adds a sort of UNIX ecosystem, you have a shell and gcc.

[legacy]

it was in the documentation of some Motorola demo board, I believe

yes, The Motorola Educational 68000 board 

[janoc]

it was in the documentation of some Motorola demo board, I believe

yes, The Motorola Educational 68000 board 

I think I have seen it in the app note I have added above. The Kiwi computer uses the trick too:

[SiliconWizard]

it takes 7 seconds to compile hAlloWorld, and 5 months 24h/h to compile a stage3 

Well, it does work though.

Interesting how your CPU is detected as a 68060?

[legacy]

Interesting how your CPU is detected as a 68060?

oh, that LC475 is a modified version of the original Apple Low-Cost Pizza Box Computer (LC = Low-Cost) where the four EPROMs on the mobo got desoldered and replaced by DIP sockets for EPROM-emulation(1). There was also a commercial "magic socket" that adapts a 68060 to the 68040's socket. I was lucky to find one on eBay, it didn't cost an arm and a leg, and I bought it to install on the LC475. Therefore /proc/cpu is telling the Truth, there is a true 68060 on the CPU socket 

The four EPROMs are emulated due to the incompatibility between 68040 and 68060, specifically all the instructions removed from the 060's instruction set which need the 060-support package released by Motorola. I found it kindly offered by NetBSD/m68k.

Anyway, this hack was made just for fun several years ago, and it has been collecting dust since then 


(1) physically four EPROM emulators in parallel, each one talks to a USB port of a USB-hub connected to a Linux Arm SoC like the Raspberry PI that has more computer power than the whole LC475. But these are just details 

[westfw]

Linux needs actual paging support, doesn't it?  The MMU originally described doesn't do that; it's just a section re-mapper.It might be useful for running "applications" (each of which thinks it starts at location 1M or similar), or solving the ROM/RAM vector issues, and it might even run BSD2.9 (which "swaps" rather than pages.) (IIRC, that's how PIC32mx manages to run BSD - their "basic memory protection unit" allows a privileged and unprivileged chunk of memory, each of which appears (to itself) to start at 0.)  (The PDP11s that originally ran unix pre-dated "paging.")
In this sort of application, you might not care about the 68k bus error problem - accessing an invalid address is probably a fatal error, except is special circumstances that might be manageable.
But it's not what most people would call a "real MMU", probably won't be useful for any conventional OS that wants a conventional MMU, and implementing it as an MMU is probably more complicated than getting just the features you can support with it needs to be...

[bson]

But Linux won't even boot on a plain 68000.  Imagine what happens when it tries to run something?  Linux is totally based on having a working VM system - it will use everything from copy-on-write address space cloning to memory mapping .so and executable files and loading pages on demand.  All address space is backed by open files (which can be an unstructured device, like /dev/zero).  Linux had all the old, early support for anything else thrown overboard a loooong time ago.  It's not part of the kernel anymore, for good reason.  It has what 20 years ago was a modern, unified, pressure based VM system.  Today it's just baseline commodity design.

It's not my project of course, but personally I'd never build a 68k anything to run Linux on it.  A Sitara big ass BGA package, some DDR ram, an SD card slot, ethernet PHY, USB ULPI PHY, and done.  2-4 days for the hardware, then 2-4 months to get the software working - and that's what a project like this is - a medium sized software project, really.  The hardware, whether a monster Sitara SoC or 68k discrete, is just cookie cutter stuff.  And you don't want to be stuck with a slow-ass 68k for a non-trivial software project.  Again, personally, just my view, the only reason for a 68k design would be to run legacy software.

Maybe dig up an old version (1, 1.5, maybe 2) of Minix or something? That should run and would be very easy to get up and running, especially v1.  I haven't looked closer at it, but v3 looks like a very different animal, a microkernel services based system similiar to Plan 9 or GNU Hurd.

Unless you're going to run something totally without memory management, the use of system will dictate MMU needs - so I'd start at that end, then implement what my chosen system requires to function properly.  (Minix IIRC is somewhat tied to x86 segment registers, but only for specific kernel address space operations.)

Anyway, just my 2c.