[Qemu-devel] Re: sparc32 do_unassigned_access overhaul

[Blue Swirl <blauwirbel@gmail.com>]

On Sat, Jan 23, 2010 at 4:46 PM, Artyom Tarasenko
<atar4qemu@googlemail.com> wrote:
> 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?

Right, it's not unreasonable to fix some limits for OBP use case, like
'you must use 256M only'.

>>> 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?

Not that I know of.