Author Topic: Does this kind of MMU makes sense  (Read 1983 times)

0 Members and 1 Guest are viewing this topic.

Offline technix

  • Super Contributor
  • ***
  • Posts: 3216
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Re: Does this kind of MMU makes sense
« Reply #25 on: October 13, 2018, 08:09:06 am »
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...
The 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.
 

Offline technix

  • Super Contributor
  • ***
  • Posts: 3216
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Re: Does this kind of MMU makes sense
« Reply #26 on: October 13, 2018, 08:44:08 am »
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.  :-//
Linux 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.
 

Offline legacy

  • Super Contributor
  • ***
  • Posts: 4208
  • Country: ch
Re: Does this kind of MMU makes sense
« Reply #27 on: October 13, 2018, 11:14:37 am »
But Linux won't even boot on a plain 68000.

ucLinux with flatBinary-patches may be an option.
 

Offline legacy

  • Super Contributor
  • ***
  • Posts: 4208
  • Country: ch
Re: Does this kind of MMU makes sense
« Reply #28 on: October 13, 2018, 11:42:08 am »
Xv6, this one?
 

Offline technix

  • Super Contributor
  • ***
  • Posts: 3216
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Re: Does this kind of MMU makes sense
« Reply #29 on: October 13, 2018, 12:43:15 pm »
Xv6, this one?
Yes. 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.
 

Offline legacy

  • Super Contributor
  • ***
  • Posts: 4208
  • Country: ch
Re: Does this kind of MMU makes sense
« Reply #30 on: October 13, 2018, 01:37:40 pm »
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.
 

Offline technix

  • Super Contributor
  • ***
  • Posts: 3216
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Re: Does this kind of MMU makes sense
« Reply #31 on: October 13, 2018, 03:34:18 pm »
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.
Having 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.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf