On Tue, Jan 19, 2010 at 9:44 PM, Artyom Tarasenko <atar4q...@googlemail.com> wrote: > 2010/1/19 Blue Swirl <blauwir...@gmail.com>: >> On Tue, Jan 19, 2010 at 5:30 PM, Artyom Tarasenko >> <atar4q...@googlemail.com> wrote: >>> 2010/1/15 Artyom Tarasenko <atar4q...@googlemail.com>: >>>> 2010/1/15 Blue Swirl <blauwir...@gmail.com>: >>>>> On Fri, Jan 15, 2010 at 9:11 PM, Artyom Tarasenko >>>>> <atar4q...@googlemail.com> wrote: >>>>>> 2010/1/15 Blue Swirl <blauwir...@gmail.com>: >>>>>>> On Fri, Jan 15, 2010 at 6:46 PM, Artyom Tarasenko >>>>>>> <atar4q...@googlemail.com> wrote: >>>>>>>> According to pages 9-31 - 9-34 of "SuperSPARC & MultiCache Controller >>>>>>>> User's Manual": >>>>>>>> >>>>>>>> 1. "A lower priority fault may not overwrite the >>>>>>>> MFSR status of a higher priority fault." >>>>>>>> 2. The MFAR is overwritten according to the policy defined for the MFSR >>>>>>>> 3. The overwrite bit is asserted if the fault status register (MFSR) >>>>>>>> has been written more than once by faults of the same class >>>>>>>> 4. SuperSPARC will never place instruction fault addresses in the MFAR. >>>>>>>> >>>>>>>> Implementation of points 1-3 allows booting Solaris 2.6 and 2.5.1. >>>>>>> >>>>>>> Nice work! This also passes my tests. >>>>>> >>>>>> I'm afraid we still are not there yet though: Solaris 7 fails >>>>>> potentially due to >>>>>> another bug in the MMU emulation, and the initial [missing-] RAM >>>>>> detection in OBP fails >>>>>> very probably due to a bug in in the MMU emulation. >>>>> >>>>> Some guesses: >>>>> - Access to unassigned RAM area may be handled by the memory >>>>> controller differently (no faults, different faults etc.) than >>>>> unassigned access to SBus or other area. >>> >>> You are right! It seems to be true for the area larger than max RAM though. >>> On a real SS-5 with 32M in the first bank, no fault is produced at >>> least for the areas >>> 0-0x2fffffff, 0x70000000-0xafffffff (ha, this would solve problems >>> with SS-20 OBP >>> too) and 0xf0000000-0xf6ffffff. >> >> The fault may still be recorded somewhere else (MXCC, RAM/ECC >> controller or IOMMU). > > sfar and sfsr were empty, so it's definitely not MXCC. Don't know > where to look for the other two. > > But how the fault would be generated? Don't know about Sun simms, but > PC ones don't have any handshake. IMHO the ECC can be the only > possibility. > >> OBP may have disabled the fault, or it has not >> enabled fault generation. > > NF bit is not set. Also, you can see the other faults. > >> On SS-5, the physical address space should be only 31 bits, so you >> should see RAM aliased at 0x80000000. > > No. The RAM can be aliased only within one bank or completely outside > the RAM area. Otherwise different banks would have interfered. > >>> Would you like to implement it? >> >> For RAM, there could be a new device which implements generic address >> space wrapping (base, length, AND mask, OR mask), it should be useful >> for embedded boards. Shouldn't be too difficult, want to try? :-) > > Minutes for you, days for me. :)
Here's my patch. It implements mapping of bottom 2G to upper 2G. Could you play with the patch and try to implement RAM aliasing so that OBP is content?
0001-Add-generic-address-space-aliasing-mechanism-and-use.patch
Description: application/mbox
