[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] Re: sparc32 do_unassigned_access overhaul
From: |
Blue Swirl |
Subject: |
[Qemu-devel] Re: sparc32 do_unassigned_access overhaul |
Date: |
Fri, 22 Jan 2010 18:00:33 +0000 |
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?
0001-Add-generic-address-space-aliasing-mechanism-and-use.patch
Description: application/mbox
- [Qemu-devel] sparc32 do_unassigned_access overhaul, Artyom Tarasenko, 2010/01/15
- [Qemu-devel] Re: sparc32 do_unassigned_access overhaul, Blue Swirl, 2010/01/15
- [Qemu-devel] Re: sparc32 do_unassigned_access overhaul, Artyom Tarasenko, 2010/01/15
- [Qemu-devel] Re: sparc32 do_unassigned_access overhaul, Blue Swirl, 2010/01/15
- [Qemu-devel] Re: sparc32 do_unassigned_access overhaul, Artyom Tarasenko, 2010/01/15
- [Qemu-devel] Re: sparc32 do_unassigned_access overhaul, Artyom Tarasenko, 2010/01/19
- [Qemu-devel] Re: sparc32 do_unassigned_access overhaul, Blue Swirl, 2010/01/19
- [Qemu-devel] Re: sparc32 do_unassigned_access overhaul, Artyom Tarasenko, 2010/01/19
- [Qemu-devel] Re: sparc32 do_unassigned_access overhaul, Blue Swirl, 2010/01/20
- [Qemu-devel] Re: sparc32 do_unassigned_access overhaul,
Blue Swirl <=
- [Qemu-devel] Re: sparc32 do_unassigned_access overhaul, Artyom Tarasenko, 2010/01/22
- [Qemu-devel] Re: sparc32 do_unassigned_access overhaul, Blue Swirl, 2010/01/23
- [Qemu-devel] Re: sparc32 do_unassigned_access overhaul, Artyom Tarasenko, 2010/01/23
- [Qemu-devel] Re: sparc32 do_unassigned_access overhaul, Blue Swirl, 2010/01/23