On 5/9/10, Artyom Tarasenko <atar4q...@googlemail.com> wrote: > 2010/5/9 Blue Swirl <blauwir...@gmail.com>: > > > On 5/8/10, Artyom Tarasenko <atar4q...@googlemail.com> wrote: > >> On the real hardware (SS-5, LX) the MMU is not padded, but aliased. > >> Software shouldn't use aliased addresses, neither should it crash > >> when it uses (on the real hardware it wouldn't). Using empty_slot > >> instead of aliasing can help with debugging such accesses. > > > > TurboSPARC Microprocessor User's Manual shows that there are > > additional pages after the main IOMMU for AFX registers. So this is > > not board specific, but depends on CPU/IOMMU versions. > > > I checked it on the real hw: on LX and SS-5 these are aliased MMU addresses. > SS-20 doesn't have any aliasing.
But are your machines equipped with TurboSPARC or some other CPU? > At what address the additional AFX registers are located? Here's complete TurboSPARC IOMMU address map: PA[30:0] Register Access 1000_0000 IOMMU Control R/W 1000_0004 IOMMU Base Address R/W 1000_0014 Flush All IOTLB Entries W 1000_0018 Address Flush W 1000_1000 Asynchronous Fault Status R/W 1000_1004 Asynchronous Fault Address R/W 1000_1010 SBus Slot Configuration 0 R/W 1000_1014 SBus Slot Configuration 1 R/W 1000_1018 SBus Slot Configuration 2 R/W 1000_101C SBus Slot Configuration 3 R/W 1000_1020 SBus Slot Configuration 4 R/W 1000_1050 Memory Fault Status R/W 1000_1054 Memory Fault Address R/W 1000_2000 Module Identification R/W 1000_3018 Mask Identification R 1000_4000 AFX Queue Level W 1000_6000 AFX Queue Level R 1000_7000 AFX Queue Status R > > One approach would be that IOMMU_NREGS would be increased to cover > > these registers (with the bump in savevm version field) and > > iommu_init1() should check the version field to see how much MMIO to > > provide. > > > The problem I see here is that we already have too much registers: we > emulate SS-20 IOMMU (I guess), while SS-5 and LX seem to have only > 0x20 registers which are aliased all the way. > > > > But in order to avoid the savevm version change, iommu_init1() could > > just install dummy MMIO (in the TurboSPARC case), if OBP does not care > > if the read back data matches what has been written earlier. Because > > from OBP point of view this is identical to what your patch results > > in, I'd suppose this approach would also work. > > > OBP doesn't seem to care about these addresses at all. It's only the "MUNIX" > SunOS 4.1.4 kernel who does. The "MUNIX" kernel is the only kernel available > during the installation, so it is currently not possible to install 4.1.4. > Surprisingly "GENERIC" kernel which is on the disk after the > installation doesn't > try to access these address ranges either, so a disk image taken from a live > system works. > > Actually access to the non-connected/aliased addresses may also be a > consequence of phys_page_find bug I mentioned before. When I run > install with -m 64 and -m 256 it tries to access different > non-connected addresses. May also be a SunOS bug of course. 256m used > to be a lot back then. Perhaps with 256MB, memory probing advances blindly from memory to IOMMU registers. Proll (used before OpenBIOS) did that once, with bad results :-). If this is true, 64M, 128M and 192M should show identical results and only with close or equal to 256M the accesses happen.