On 29/04/12 11:02, Rob Landley wrote:
On 04/28/2012 08:09 AM, Greg Ungerer wrote:
On 04/28/2012 04:15 PM, Rob Landley wrote:
On 04/27/2012 01:08 AM, Greg Ungerer wrote:
On 26/04/12 15:14, Rob Landley wrote:
I have also been able to boot an ARM noMMU kernel for the AT91x40 SoC
under SkyEye. This time, the userspace works fine. I haven't had the
time to clean up this, and it requires patches to both the kernel and
SkyEye to work properly. If you're interested, I'll give you these
patches and configs when I'm done with the cleanup.
I'm unlikely to play with skyeye (tried it once, but it was years ago).
Is there a strong reason nommu kernel's won't run on hardware or an
emulator that _does_ implement an mmu? (Can't it just not use it?)
No. It comes down to architectural support. There are a few that do
it. I have ColdFire hardware with MMU, it can be compiled and run
either with or without MMU enabled (by flicking the kernel's
CONFIG_MMU switch).
Architectural support in the kernel, or in the emulator?
In the kernel. For arches that don't currently do any non-mmu it is
usually the code in arch/foobar/mm and often some in arch/foobar/kernel
that has no concept of operating with the MMU turned off.
Surely there's a way to genericize this. Even on processors that don't
_come_ without an mmu, in ultra-low-memory environments doing without
page tables can still be a win sometimes...
The generic parts are already generic :-) That is to say the common
mm code is already non-MMU capable. This is the arch specific bits
that need to be done for each different arch - and the details are
not the same for each.
Mostly it is simple stuff. You end up just "#ifdef CONFIG_MMU" in a
few places so it doesn't do anything MMU related. As Geert described
though, cache can be a little tricky to deal with. And how to do it
is very arch dependent.
Not having
nommu support for i386 is one thing, but why can I boot a nommu arm
under qemu?
It has been done on ARM targets in the past. I don't know if any can
be compiled and work both ways currently in mainline.
Considering that u-boot starts running before the mmu is set up, and
doesn't always bother to enable cacheing (and thus _never_ sets up the
MMU), I'd think it would have to work...
(What's involved in nommu archiectural support? Running a dedicated
single-process i386 system in 4 megs ram might get a bit easier if you
don't need to spend memory on page tables, seems nice to have the
_option_...)
It would be very nice to have :-)
The difficulty depends on the architecture. On some architectures some
important details just work differently with or without the MMU enabled
(things like caches, interrupts, etc).
Can you set the mmu into flat memory mode with everything running in
ring 0 and a 1:1 mapping of all physical memory?
I am sure you could, for x86. I wouldn't be surprised if on some
architectures you had to have page tables in place still (they could
be static I expect).
(There was a Gargoyles episode where the way the way to fix the
character under a spell of obedience was to use it to command him to act
like he wasn't under a spell. Possibly same general theory here...)
Regards
Greg
------------------------------------------------------------------------
Greg Ungerer -- Principal Engineer EMAIL: g...@snapgear.com
SnapGear Group, McAfee PHONE: +61 7 3435 2888
8 Gardner Close FAX: +61 7 3217 5323
Milton, QLD, 4064, Australia WEB: http://www.SnapGear.com
_______________________________________________
Celinux-dev mailing list
Celinux-dev@lists.celinuxforum.org
https://lists.celinuxforum.org/mailman/listinfo/celinux-dev
