On Tue, Feb 3, 2015 at 7:08 AM, Måns Rullgård <mans@xxxxxxxxx> wrote: > Kevin Cernekee <cernekee@xxxxxxxxxxxx> writes: >> On Tue, Feb 3, 2015 at 3:39 AM, Maciej W. Rozycki <macro@xxxxxxxxxxxxxx> wrote: >>> For the record -- the exact address `__fast_iob' reads from does not >>> really matter, all it has to guarantee is no side effects on read access. >>> Using the base of KSEG1 was therefore a natural choice for legacy MIPS >>> processors that set the architecture back at the time this code was added, >>> as the presence of exception vectors there guaranteed this area of the >>> address space behaved like RAM so the same location did for any system. >>> >>> With the introduction of revision 2 of the MIPS architecture the CP0 >>> EBase register was added and consequently there is no longer a guarantee >>> that exception vectors reside at the base of KSEG1. Using the value read >>> from CP0.EBase to determine a usable address might therefore be a better >>> idea, although the current revision of the MIPS architecture specification >>> that includes segmentation control makes it a bit complicated. Using a >>> dummy page mapped uncached instead might work the best. >> >> Would something like this work, assuming __fast_iob() doesn't get >> called before mem_init()? >> >> CKSEG1ADDR((void *)empty_zero_page) >> >> It is currently a GPL export, so maybe that would need to change to >> allow non-GPL drivers to use iob(). But that's still easier than >> allocating another dummy page. > > The 86xx has a 64k remappable block at CPU physical address zero, so one > option would be to simply point this at some actual memory and leave the > macro alone. There doesn't seem to be anything useful in that bus > address range anyway. Reading returns zeros, and writes have no > apparent effect. Maybe it's even safe to do a dummy read from there in > iob(). IIRC, one of the special operating modes on BCM7435 allows partitioning the hardware in a way that prohibits accesses to PA 0. Not sure how widely it is used, however. I've also seen other embedded MIPS systems that don't have RAM at PA 0, but they didn't run Linux. So there are two paths forward: 1) Make SMP86xx behave like other currently-supported CPUs, i.e. use the remap registers to configure the chip so that uncached reads from PA 0 do something sensible. This sounds like the easiest fix. 2) Agree to support memory configurations where PA 0 doesn't map to RAM, changing __fast_iob (and maybe other code) accordingly.
