[Qemu-devel] Re: sparc32 do_unassigned_access overhaul

[Artyom Tarasenko <atar4qemu@googlemail.com>]

2010/1/23 Blue Swirl <blauwirbel@gmail.com>:
> On Fri, Jan 22, 2010 at 8:51 PM, Artyom Tarasenko
> <atar4qemu@googlemail.com> wrote:
>> 2010/1/22 Blue Swirl <blauwirbel@gmail.com>:
>>> On Tue, Jan 19, 2010 at 9:44 PM, Artyom Tarasenko
>>> <atar4qemu@googlemail.com> wrote:
>>>> 2010/1/19 Blue Swirl <blauwirbel@gmail.com>:
>>>>> On Tue, Jan 19, 2010 at 5:30 PM, Artyom Tarasenko
>>>>> <atar4qemu@googlemail.com> wrote:
>>>>>> 2010/1/15 Artyom Tarasenko <atar4qemu@googlemail.com>:
>>>>>>> 2010/1/15 Blue Swirl <blauwirbel@gmail.com>:
>>>>>>>> On Fri, Jan 15, 2010 at 9:11 PM, Artyom Tarasenko
>>>>>>>> <atar4qemu@googlemail.com> wrote:
>>>>>>>>> 2010/1/15 Blue Swirl <blauwirbel@gmail.com>:
>>>>>>>>>> On Fri, Jan 15, 2010 at 6:46 PM, Artyom Tarasenko
>>>>>>>>>> <atar4qemu@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/