David VomLehn wrote:
> Pelton, Dave wrote:
> > <snip>
> > Normally kseg2 is in the address range 0xC0000000-0xFFFFFFFF.
> > on the BMIPS3300 (the embedded MIPS32 core used on my SOC), there is
> > range of addresses within kseg2 that are reserved
> > (0xFF200000-0xFFFEFFFF).
> > This means that the TLB entry that kmap_coherent creates will not
> > if it falls within the reserved range. The virtual address space
> > by kmap_coherent is controlled by FIXADDR_TOP in
> > include/asm-mips/fixmap.h.
> > To fix my issue, I changed FIXADDR_TOP to avoid the reserved address
> > space.
> Is your range of addresses reserved on the BMIPS3300 because it is
being used as
> dseg, i.e. because it is being used for debugging? If I read the
> the processor I am using, the 24Kc, it has a similar issue. I don't
need to be
> able to use kmap_coherent because the 24K hardware takes care of data
> issues, i.e. cpu_has_dc_aliases is false, but I'm sort of thinking we
> generally want to change FIXADDR_TOP to avoid address in the dseg
range for all
> MIPS32 processors. As we work our way through some of the cache
> related to using high memory, I'd like to be able to develop code that
> processors for which cpu_has_dc_aliases is true. If my kmap_coherent
is working I
> can check things out for those processors and then simply use
> processors where cpu_has_dc_aliases is false.
Apologies in advance for what my plain-text impaired mail client is
likely to do to this message. The reserved range on the BMIPS3300 is
used by memory mapped registers. I am not a memory management expert,
so I am not sure what implications there would be to moving FIXADDR_TOP
as a general fix. The impression I have from general MIPS documentation
is that kseg2 should not be used for memory mapped i/o and hence
platforms that do this should be treated as an exception case, rather
than moving the general case to deal with this.
- David Pelton