David VomLehn wrote: > Pelton, Dave wrote: > > <snip> > > Normally kseg2 is in the address range 0xC0000000-0xFFFFFFFF. However, > > on the BMIPS3300 (the embedded MIPS32 core used on my SOC), there is a > > range of addresses within kseg2 that are reserved > > (0xFF200000-0xFFFEFFFF). > > This means that the TLB entry that kmap_coherent creates will not work > > if it falls within the reserved range. The virtual address space used > > 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. > <snip> > > 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 documentation on > 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 coherence > issues, i.e. cpu_has_dc_aliases is false, but I'm sort of thinking we might just > 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 flushing issues > related to using high memory, I'd like to be able to develop code that works on > 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 kmap_atomic for > 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
