Chagas, Jason writes:
> Why is it that each task needs its own copy of the translation table is
> unclear to me. I would appreciate if someone could shed some light into it.
Every separate task in Linux requires its own set of page tables. This
allows different user-space mappings between the virtual and physical
addresses to be set up. When the kernel needs to switch between two
tasks, all it essentially needs to do is to remap the user space, and
the way this is done is to switch the page tables.
> However, it starts copying the entries at the RAM address offset
> (0xc00000000 for Brutus or 0x20000000 for my board). Note, unlike
> the Brutus code that mapped all IO to virtual address higher than
> RAM (mm-sa1100.c), I [inadvertently] mapped some IO virtual address
> below the RAM address.
Why are you setting this so low? You're not leaving very much for the
actual user-mode tasks/threads. Do you have a lot of IO space on this
board? If not, then you might as well adopt the already proven generic
structure which is used on all the other 32-bit platforms.
There should be *NO* IO mappings below the TASK_SIZE boundary, except for
the first page. TASK_SIZE defines the end of the 'user-mode' memory area.
Everything above that is defined to be 'system' mappings, which are
always copied.
> What seems strange to me is that the Brutus kernel does not seem copy the
> exception vector table entry, virtual address 0x0000000 initialized by
> function setup_pagetables (mm_init.h), from the old translation table into
> the new one. Some how the Brutus kernel still works. Could anyone explain to
> me this magic?
See new_page_tables() in mm/memory.c.
> I tried copying all (16k) the translation table (instead of just part of it)
> into the new table and the kernel didn't hang after the TLB flush but it
> "bombed" later with:
It will do - the kernel demand-loads the binaries, which means that it
relies on the page tables being marked as invalid to cause prefetch and
data aborts. These aborts then cause pages to be read in. If old pages
are present, then literally anything can happen to the user program, and
will probably result in the kernel killing the program in some way.
If you follow the generic mapping (zero-page, user, kernel, io in that
order) then you can't go far wrong with the page tables - it should
just work.
A tip - make sure 'Split text into discardable sections' is disabled.
It does cause strange problems at run time with most (but not all) of
the GNU ARM tool chain. The latest versions may be ok, but at this
stage, I'd say you want that option off.
_____
|_____| ------------------------------------------------- ---+---+-
| | Russell King [EMAIL PROTECTED] --- ---
| | | | http://www.arm.linux.org.uk/~rmk/armlinux.html / / |
| +-+-+ --- -+-
/ | THE developer of ARM Linux |+| /|\
/ | | | --- |
+-+-+ ------------------------------------------------- /\\\ |
unsubscribe: body of `unsubscribe linux-arm' to [EMAIL PROTECTED]
