I've experienced an interesting problem trying to port ARM-Linux v2.2.3
(Brutus) to a new platform and StrongARM based processor.
The problem occurs when loading an executable image(/sbin/init - the first
executable called by the kernel). In the process of loading the executable,
the kernel calls 'new_page_tables' (memory.c). This function in turn calls
'pgd_alloc' (pgtable.h) to allocate a new translation table that is
eventually activated with CP15 (register 2) by a macro defined as
'SET_PAGE_DIR' (pgtable.h) followed by all the appropriate cache flushes.
The pointer to this new is saved is saved in task structure. 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.
Anyway, 'pgd_alloc' in this case calls 'get_pgd_slow' (fault-armv.c).
'get_pgd_slow' allocates 16k of memory, zeros it out, and copies the
original translation table into this new buffer. 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. Evidently, the end result was that my
IO addresses didn't get copied and the kernel hanged right after flushing of
the instruction and data TLBs ('_saxxxx_flsu_tlb_all' - proc-saxxxx.S). 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?
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:
Bad pmd in pte_alloc: 03f00442
Function entered at [<200102c0>] from [<2002058c>]
r4 = 00000000
Function entered at [<20020448>] from [<20035590>]
r8 = 03ffffda
r7 = 21fdde10
.
.
.
Any ideas?
Thanks,
Jason
unsubscribe: body of `unsubscribe linux-arm' to [EMAIL PROTECTED]
