2010/1/23 Blue Swirl <blauwir...@gmail.com>: > On Fri, Jan 22, 2010 at 8:51 PM, Artyom Tarasenko > <atar4q...@googlemail.com> wrote: >> 2010/1/22 Blue Swirl <blauwir...@gmail.com>: >>> 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? >> >> It's a nice patch, but I'm confused. I thought that in my last mail I >> proved that we don't observe any RAM aliasing on SS-5. We see some ROM >> aliasing, but I'm not sure whether it's worth implementing. > > I'd still expect some aliasing if a bank has smaller chips than > others. For example, if you have 40M of memory and bank size is 16M, > there are two full banks and one bank with 8M. This 8M should be > aliased within the 16MB area twice. > > Otherwise the DRAM controller must somehow know or be told the chip size. > > So, the aliasing code could be useful to emulate more arbitrary memory > sizes (with OBP), not just multiples of bank sizes.
Yes, but do we need it? Nowadays 32M is small enough (and Classic/X/LX have even smaller memory banks: 16M. Of course if we going to support the Ross Technologies SS-20, it will make sense again, as it has larger memory banks (128M iirc). But for now wouldn't it be better to focus on fully supporting full banks? >> Also we see no synchronous faults on SS-5 when accessing missing >> memory. Haven't tested it on SS-20 yet. I'll try to get an access to a >> real SS-20 next week (can't have a simultaneous access to the both of >> them). > > Is memory parity enabled? ok mcr@ . 43d1b01 ok The 12th bit is set. Are there further parity switches on SS-5? -- Regards, Artyom Tarasenko solaris/sparc under qemu blog: http://tyom.blogspot.com/
