On Fri, 9 May 2008, Per Öberg wrote:
> Does anyone know If it is easy to program the MMU (or what it's called)
> to not interfear?
I am developing an RTOS on a TS7250 (and other boards), and with the
available documentation and some bare metal experience it's not hard to
net-boot your own software on the board using Redboot. I really like it as
a development platform.
ARM9 cores have a funny cache and MMU architecture. To be able to use
the caches, you need to enable the MMU -- which in turn means you have to
set up at least some rudimentary page table.
One thing to note is that Redboot enables the caches, and uses the MMU
to remap the board's SDRAM to a (virtually) contiguous block. So when you
boot your software from scratch, it actually starts out running in virtual
memory! Thus you have to write your bootstrap code position-independent,
turn the MMU off, and install your own page tables and then flush and
jump to your next instruction -- but this is all pretty standard bootstrap
procedure, it's not very hard.
If all you want to do is create a single address space with all your
tasks sharing memory, you have no problem -- you can generate the kernel
page table and just compile it into the binary. I made a perl script to
statically create page tables for simple cases like these. The easiest
thing for this kind of project is to map all the hardware you want to use
to their physical address spaces, so that virtual address are identical to
physical address. Then you never need to think about where you mapped
what, and all your addresses will match the board hardware docs. :-)
Context-switching in a flat, shared address space is as simple as
switching thread contexts -- it's about as hard as returning correctly
from a function call in assembly. :-)
Of course, you still have to set up and manage interrupts and timers to
implement your realtime scheduler -- but that seemed to be the point of
your project anyway so.. :-)
The different modes of the ARM aren't very different from other
processors; they're just there to facilitate the implementation of
unprivileged "user space", and make interrupt and syscall handling easier
and faster. If you don't care about user space, you can just run all your
code in the (privileged) supervisor mode intended for the kernel. Then
only interrupts will run in any other mode (because taking interrupts
automatically transfers you to IRQ mode -- which is a good thing).
If you are trying to create an OS with processes running in separate
virtual address spaces (which I doubt, seeing as this appears to be some
kind of university course project :-) ), we're opening an entirely
different can of worms and have to consider virtual address aliasing,
cache and TLB coherency, shared page reference counting and all that.
Hope this helps,
/ali:)
------------------------------------
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/ts-7000/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/ts-7000/join
(Yahoo! ID required)
<*> To change settings via email:
<*> To unsubscribe from this group, send an email to:
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
|