> I'm looking at arch/mips/include/asm//mach-malta/kernel-entry-init.h
and there is a definition for
> SegCtl2:
/* SegCtl2 */
li t0, ((MIPS_SEGCFG_MUSUK << MIPS_SEGCFG_AM_SHIFT) | \
(6 << MIPS_SEGCFG_PA_SHIFT) | \
(1 << MIPS_SEGCFG_EU_SHIFT)) | \
(((MIPS_SEGCFG_MUSUK << MIPS_SEGCFG_AM_SHIFT) | \
(4 << MIPS_SEGCFG_PA_SHIFT) | \
(1 << MIPS_SEGCFG_EU_SHIFT)) << 16)
it defines, that kernel logical addresses from the range 0x00000000 -
0x7fffffff are unmapped (no tlbs) and dictates, that in order to get a
physical address for any logical addresses from 0x00000000 -
0x3fffffff range in kernel space, bits [31:29] of the logical address
must be changed to 100,
and (again in kernel space) for any logical addresses from 0x40000000
- 0x7fffffff range, bits [31:29] of the logical address must be
changed to 110, right?
What physical addresses will logical addresses 0x00000000 and
0x20000000 be translated in kernel space?.. logical 0x00000000 -->
physical 0x80000000, and logical 0x20000000 --> .... 0x80000000 too?
Since we must to change bits [31:29], we have to change bit 29 ('1')
in logical address 0x200000000 to '0' (since PA for this range is 100).
So, what physical addresses will all logical addresses which have '1'
at 29 bit be translated, if we define PA as 100 and 110 in SegCtl2? It
looks like there's no flat translation of logical addresses to
physical addresses in kernel space, and this is obviously just not
correct, there is something simple I've been overlooking.
Thank you,
Yuri
The only way this scheme can work, is that 'these bits are used' phrase
from Table 3.5 CFG (Segment Configuration) Field Description means not
'these bits substitute bits [31:29] in virtual address', but 'these bits
are 'OR'-ed with bits [31:29] in virtual address.
