[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: |
Tue, 19 Jan 2010 19:32:04 +0000 |
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). OBP may have disabled the fault, or it has not
enabled fault generation.
On SS-5, the physical address space should be only 31 bits, so you
should see RAM aliased at 0x80000000.
> 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? :-)
Dummy MMIO could be registered for the other areas in sun4m.c. I'm not
sure this is the correct approach, if the fault is still handled
somewhere else.
> That's how I tested it:
>
> ok 8000000 map?
> Virtual : 0800.0000
> Context : @ 0.01ff.f000 001f.eec1 # 0
> Region : @ 0.01fe.ec20 0000.0000 Invalid
> ok 8000000 obmem 8000000 map-page
> ok 8000000 map?
> Virtual : 0800.0000
> Context : @ 0.01ff.f000 001f.eec1 # 0
> Region : @ 0.01fe.ec20 001f.b231
> Segment : @ 0.01fb.2300 001f.b221
> Page : @ 0.01fb.2200 0080.001e Access : rwx---
> Physical : 0.0800.0000
> ok 8000000 20 dump
> \/ 1 2 3 4 5 6 7 8 9 a b c d e f v123456789abcdef
> 8000000 00 d1 e1 44 ff d1 e2 18 08 d1 e1 4e ff d1 e2 18 .QaV.Qb..QaV.Qb.
> 8000010 00 d1 e1 44 ff d1 e2 18 08 d1 e1 4e ff d1 e2 18 .QaV.Qb..QaV.Qb.
RAM?
> ok
> ok 10000000 map?
> Virtual : 1000.0000
> Context : @ 0.01ff.f000 001f.eec1 # 0
> Region : @ 0.01fe.ec40 0000.0000 Invalid
> ok 10000000 obmem 10000000 map-page
> ok 10000000 20 dump
> \/ 1 2 3 4 5 6 7 8 9 a b c d e f v123456789abcdef
> 10000000 04 00 00 05 00 1f e0 00 04 00 00 05 00 1f e0 00 ......`.......`.
> 10000010 04 00 00 05 04 00 00 05 04 00 00 05 04 00 00 05 ................
IOMMU registers here...
> ok 30000000 map?
> Virtual : 3000.0000
> Context : @ 0.01ff.f000 001f.eec1 # 0
> Region : @ 0.01fe.ecc0 0000.0000 Invalid
> ok 30000000 obmem 30000000 map-page
> ok 30000000 20 dump
> \/ 1 2 3 4 5 6 7 8 9 a b c d e f v123456789abcdef
> 30000000 Data Access Error
> ok 2fff0000 obmem 2fff0000 map-page
> ok 2fff0000 20 dump
> \/ 1 2 3 4 5 6 7 8 9 a b c d e f v123456789abcdef
> 2fff0000 02 ff e1 44 ff d1 e2 18 2f d1 e1 4e ff d1 e2 18 .QaV.Qb..QaV.Qb.
> 2fff0010 00 d1 e1 44 ff d1 e2 18 2f d1 e1 4e ff d1 e2 18 .QaV.Qb..QaV.Qb.
RAM again?
> ok
> ok f0000000 map?
> Virtual : f000.0000
> Context : @ 0.01ff.f000 001f.eec1 # 0
> Region : @ 0.01fe.efc0 0000.0000 Invalid
> ok f0000000 obmem f0000000 map-page
> ok f0000000 20 dump
> \/ 1 2 3 4 5 6 7 8 9 a b c d e f v123456789abcdef
> f0000000 10 80 2f 66 a1 48 00 00 01 00 00 00 01 00 00 00 ../f!H..........
> f0000010 29 1c 00 04 a8 15 20 d0 81 c5 00 00 a1 48 00 00 )...(. P.E..!H..
This could be boot ROM aliased all over 0xf0000000 to 0xffffffff.
> ok f7ff0000 map?
> Virtual : f7ff.0000
> Context : @ 0.01ff.f000 001f.eec1 # 0
> Region : @ 0.01fe.efdc 0000.0000 Invalid
> ok f7ff0000 obmem f7ff0000 map-page
> ok f7ff0000 20 dump
> \/ 1 2 3 4 5 6 7 8 9 a b c d e f v123456789abcdef
> f7ff0000 Data Access Error
> ok f6ff0000 map?
> Virtual : f6ff.0000
> Context : @ 0.01ff.f000 001f.eec1 # 0
> Region : @ 0.01fe.efd8 0000.0000 Invalid
> ok f6ff0000 obmem f6ff0000 map-page
> ok f6ff0000 20 dump
> \/ 1 2 3 4 5 6 7 8 9 a b c d e f v123456789abcdef
> f6ff0000 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
> f6ff0010 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
>
> --
> Regards,
> Artyom Tarasenko
>
> solaris/sparc under qemu blog: http://tyom.blogspot.com/
>
- [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 <=
- [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, 2010/01/22
- [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