[Qemu-devel] Re: sparc32 do_unassigned_access overhaul

[Artyom Tarasenko]

2010/1/22 Blue Swirl <address@hidden>:
> On Tue, Jan 19, 2010 at 9:44 PM, Artyom Tarasenko
> <address@hidden> wrote:
>> 2010/1/19 Blue Swirl <address@hidden>:
>>> On Tue, Jan 19, 2010 at 5:30 PM, Artyom Tarasenko
>>> <address@hidden> wrote:
>>>> 2010/1/15 Artyom Tarasenko <address@hidden>:
>>>>> 2010/1/15 Blue Swirl <address@hidden>:
>>>>>> On Fri, Jan 15, 2010 at 9:11 PM, Artyom Tarasenko
>>>>>> <address@hidden> wrote:
>>>>>>> 2010/1/15 Blue Swirl <address@hidden>:
>>>>>>>> On Fri, Jan 15, 2010 at 6:46 PM, Artyom Tarasenko
>>>>>>>> <address@hidden> 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.

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).


-- 
Regards,
Artyom Tarasenko

solaris/sparc under qemu blog: http://tyom.blogspot.com/