Does this kind of MMU makes sense - Page 1
Forum section: electronics / general

author: technix
author_rank: Super Contributor
timestamp: October 11, 2018, 11:56:41 am
content: 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: UnusedI/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: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.

author: westfw
author_rank: Super Contributor
timestamp: October 12, 2018, 03:02:54 am
content: "Makes sense" for what purpose?QuoteDoes that end up causing a bus error?

author: bson
author_rank: Unknown
timestamp: October 12, 2018, 03:35:51 am
content: 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.

author: iMo
author_rank: Super Contributor
timestamp: October 12, 2018, 07:17:24 am
content: 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..

author: technix
author_rank: Super Contributor
timestamp: October 12, 2018, 08:57:41 am
content: Quote from: westfw on October 12, 2018, 03:02:54 amAs a rudimentary page switching mechanism for 68000, so I can properly boot to Flash and use RAM as interrupt vectors.Quote from: westfw on October 12, 2018, 03:02:54 amIt *should* result in a bus error, but since 68000 has a broken bus error recovery I am currently allowing it to fail silently.

author: technix
author_rank: Super Contributor
timestamp: October 12, 2018, 09:01:10 am
content: Quote from: imo on October 12, 2018, 07:17:24 amPIC32MZ 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.

author: technix
author_rank: Super Contributor
timestamp: October 12, 2018, 09:05:04 am
content: Quote from: bson on October 12, 2018, 03:35:51 amI 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.

author: nfmax
author_rank: Super Contributor
timestamp: October 12, 2018, 09:06:00 am
content: 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

author: janoc
author_rank: Super Contributor
timestamp: October 12, 2018, 09:07:00 am
content: Quote from: technix on October 12, 2018, 08:57:41 amIf 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.

author: janoc
author_rank: Super Contributor
timestamp: October 12, 2018, 09:12:00 am
content: Quote from: nfmax on October 12, 2018, 09:06:00 amThat 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.

author: technix
author_rank: Super Contributor
timestamp: October 12, 2018, 02:11:25 pm
content: Quote from: nfmax on October 12, 2018, 09:06:00 amThat 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.

author: technix
author_rank: Super Contributor
timestamp: October 12, 2018, 02:13:05 pm
content: Quote from: janoc on October 12, 2018, 09:07:00 amHow to implement that?

author: legacy
author_rank: Super Contributor
timestamp: October 12, 2018, 02:34:38 pm
content: Quote from: technix on October 12, 2018, 02:11:25 pmLinux 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?

author: legacy
author_rank: Super Contributor
timestamp: October 12, 2018, 02:46:14 pm
content: Quote from: technix on October 12, 2018, 08:57:41 amLook 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.

author: technix
author_rank: Super Contributor
timestamp: October 12, 2018, 05:13:50 pm
content: Quote from: legacy on October 12, 2018, 02:34:38 pmAny 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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: October 12, 2018, 05:57:41 pm
content: http://www.linux-m68k.org/dists.htmlOf 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?

author: legacy
author_rank: Super Contributor
timestamp: October 12, 2018, 06:18:58 pm
content: Quote from: SiliconWizard on October 12, 2018, 05:57:41 pmemm, on my LC475m68k ~ # dmsegCode: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 Jan2009Detected Macintosh model: LC475Bootinfo data:Video: addr 0xf9001000 row 0x400 depth 8 dimensions 640 x 480Videological 0xf0101000 phys. 0x51901000, SCC at 0x50f0c020Boottime: 0xe71c3e2a GMTBias: 0x0Machine ID: 90 CPUid: 0x2 memory size: 0x24VIA1 at 50f00000 is a 6522 or cloneVIA2 at 50f02000 is a 6522 or cloneOn node 0 totalpages: 9216free_area_init_node: node 0, pgdat 00207b9c, node_mem_map 00257000DMA zone: 9135 pages, LIFO batch:1Built 1 zonelists in Zone order, mobility grouping on. Total pages: 9135Kernel command line: root=/dev/sda7 init=/sbin/initminimac_init_IRQ(): Setting things up …- Killing onboard sonic ethernet card ... <6>Donemac_init_IRQ(): Done!CPU HACK: 68060 support pack armedPID 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 80x25console  enabledDentry 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=8Calibrating delay loop... 31.70 BogoMIPSMount-cache hash table entries: 512net_namespace: 292 bytesNET: Registered protocol family 16NuBus: Scanning NuBus slots.Now probing slot E at feffffffNow probing slot E at fefffffeSlot E:Board resource:type: [cat 0x1 type 0x0 hw 0x0 sw 0x0]name: EtherNet cardboard id: 0x8vendor info:ID: TFL LAN INC.revision: REV 1.1part: E410 NuBus/E420 LC PDS,EtherNet AdapterFunction 0x08:type: [cat 0x4 type 0x1 hw 0x11e sw 0x100]name: Network_Ethernet_Apple_TFLmemory offset: 0x000d0000MAC address: 00:a0:4b:08:db:26SCSI subsystem initializedNET: Registered protocol family 2IP 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 registeredNET: Registered protocol family 1msgmni has been set to 66io scheduler noop registeredio scheduler anticipatory registeredio scheduler deadline registeredio scheduler cfq registered (default)macfb: framebuffer at 0xf9001000, mapped to 0x02800000, size 480kmacfb: mode is 640x480x8, linelength=1024macfb: scrolling: redrawConsole: switching to colour frame buffer device 80x30fb0: DAFB frame buffer devicer3964: 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 otherseth0: Memory length resource for slot E not found, probingeth0: 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.6tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>input: Macintosh mouse button emulation as /class/input/input0mac_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 0mac_enable_irq irq=19, irq_src=2 <6> (via:present) <6>esp: esp0, regs[50f10000:0] irqesp: esp0 is a ESP236, 16 MHz (ccf=4), SCSI ID 7adb devices: : 2 8ADB keyboard at 2, handler 1Detected ADB keyboard, type ANSI.input: ADB keyboard as /class/input/input1adb: finished probe task...scsi0 : esposst :I: Tape driver with OnStream support version 0.99.4osst :I: $Id: osst.c,v 1.73 2005/01/01 21:13:34 wriede Exp $Driver 'osst' needs updating - please use bus_type methodsscsi 0:0:0:0: Direct-Access SEAGATE ST32550N 8607 PQ: 0 ANSI: 2target0:0:0: Beginning Domain ValidationDriver 'sd' needs updating - please use bus_type methodsDriver 'sr' needs updating - please use bus_type methodsSCSI Media Changer driver v0.25Driver 'ch' needs updating - please use bus_type methodstarget0:0:0: FAST-5 SCSI 3.3 MB/s ST (304 ns, offset 15)target0:0:0: Domain Validation skipping write teststarget0:0:0: Ending Domain Validationmice: PS/2 mouse device common for all miceNET: Registered protocol family 26IPv4 over IPv4 tunneling driversd 0:0:0:0:  4194995 512-byte hardware sectors (2148 MB)TCP bic registeredTCP cubic registeredTCP westwood registeredTCP htcp registeredNET: Registered protocol family 17NET: Registered protocol family 15802.1Q VLAN Support v1.8sd 0:0:0:0:  Write Protect is offsd 0:0:0:0:  Mode Sense: ab 00 10 08scsi: waiting for bus probes to complete ...sd 0:0:0:0:  Write cache: disabled, read cache: enabled, supports DPO and FUAsd 0:0:0:0:  4194995 512-byte hardware sectors (2148 MB)sd 0:0:0:0:  Write Protect is offsd 0:0:0:0:  Mode Sense: ab 00 10 08sd 0:0:0:0:  Write cache: disabled, read cache: enabled, supports DPO and FUAsda:  sda1 sda2 sda3 sda4 sda5 sda6 sda7sd 0:0:0:0:  Attached SCSI disksd 0:0:0:0: Attached scsi generic sg0 type 0kjournald starting. Commit interval 5 secondsEXT3-fs: mounted filesystem with ordered data mode.VFS: Mounted root (ext3 filesystem) readonly.EXT3-fs warning: checktime reached, running e2fsck is recommendedEXT3 FS on sda7, internal journalm68k ~ # gcc -vCode:Target: m68k-unknown-linux-gnuConfigured 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=gnuThread model: posixgcc version 4.2.3 experimentalm68k ~ # cat /proc/cpuinfoCode:CPU: 68060MMU: 68060FPU: 68060Clocking: 33 MHzCode:m68k ~ # nano hAllo.cinclude <stdio.h>int main(){printf("hAllo world, I have done muuuuuuuu again\n");return 0;}Code:m68k ~ # time gcc hAllo.c -o hAlloreal 0m6.890suser 0m5.620ssys 0m1.260sm68k ~ # ./hAllohAllo world, I have done muuuuuuuu againit takes 7 seconds to compile hAlloWorld, and 5 months 24h/h to compile a stage3

author: janoc
author_rank: Super Contributor
timestamp: October 12, 2018, 06:25:37 pm
content: Quote from: technix on October 12, 2018, 02:13:05 pmEasy - 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.htmlThe 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.

author: legacy
author_rank: Super Contributor
timestamp: October 12, 2018, 06:54:02 pm
content: Quote from: technix on October 12, 2018, 05:13:50 pmIt depends on what you need and on what you are willing to do.for example,VxWorksis 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.XINUis 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.

author: legacy
author_rank: Super Contributor
timestamp: October 12, 2018, 06:56:19 pm
content: Quote from: janoc on October 12, 2018, 06:25:37 pmyes, The Motorola Educational 68000 board

author: janoc
author_rank: Super Contributor
timestamp: October 12, 2018, 06:58:50 pm
content: Quote from: legacy on October 12, 2018, 06:56:19 pmI think I have seen it in the app note I have added above. The Kiwi computer uses the trick too:

author: SiliconWizard
author_rank: Super Contributor
timestamp: October 12, 2018, 07:47:15 pm
content: Quote from: legacy on October 12, 2018, 06:18:58 pmWell, it does work though.Interesting how your CPU is detected as a 68060?

author: legacy
author_rank: Super Contributor
timestamp: October 12, 2018, 10:15:29 pm
content: Quote from: SiliconWizard on October 12, 2018, 07:47:15 pmoh, 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 socketThe 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

author: westfw
author_rank: Super Contributor
timestamp: October 13, 2018, 03:43:52 am
content: 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...

author: bson
author_rank: Unknown
timestamp: October 13, 2018, 04:06:45 am
content: 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.

author: technix
author_rank: Super Contributor
timestamp: October 13, 2018, 08:09:06 am
content: Quote from: westfw on October 13, 2018, 03:43:52 amThe Linux dream was long dashed already. The current target OS is xv6 port with some POSIX extensions to support newlib. xv6 is a C99 rewrite of the original PDP/11 Version 6 UNIX by created by MIT.

author: technix
author_rank: Super Contributor
timestamp: October 13, 2018, 08:44:08 am
content: Quote from: bson on October 13, 2018, 04:06:45 amLinux dream is long dashed. The current target is xv6 kernel, a C99 rewrite of the original PDP/11 Version 6 UNIX, plus a newlib/busybox userland. My planned hardware actually has modern amenities like graphics LCD touchscreen, USB OTG and Ethernet.For Linux I have my $1 Allwinner A13 + 512MB DDR3 + 32GB eMMC. Or AM1808B. Or i.MX233. Or AT91SAM9260. I even have a few reballed i.MX6D automotive chips if I really want to go there.

author: legacy
author_rank: Super Contributor
timestamp: October 13, 2018, 11:14:37 am
content: Quote from: bson on October 13, 2018, 04:06:45 amucLinux with flatBinary-patches may be an option.

author: legacy
author_rank: Super Contributor
timestamp: October 13, 2018, 11:42:08 am
content: Xv6,thisone?

author: technix
author_rank: Super Contributor
timestamp: October 13, 2018, 12:43:15 pm
content: Quote from: legacy on October 13, 2018, 11:42:08 amYes. It should be able to be modified into a small kernel, add in a rudimentary POSIX API subset to support newlib, now I can get at least a static linked busybox up.

author: legacy
author_rank: Super Contributor
timestamp: October 13, 2018, 01:37:40 pm
content: why do you want busybox? do you need a full shell? or, can't you write your own minimal one?if you need a minimal shell + sort of scripting, you'd better integrate ucPython or eLua into ucMon.they are all opensource, well written in C, and they can be implemented as a couple of static tasks, therefore they don't require any MMU.

author: technix
author_rank: Super Contributor
timestamp: October 13, 2018, 03:34:18 pm
content: Quote from: legacy on October 13, 2018, 01:37:40 pmHaving a small but full POSIX compliant shell is the kind of non-trivial gauntlet I want my UNIX style systems to go through. As of busybox since it has almost all common UNIX commands in one executable I can just put it in the ROM (along with the kernel itself and newlib) and run it over and over using different argv and stack - saves RAM.