[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: |
Wed, 20 Jan 2010 18:29:22 +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.
For SS-5 there is MFAR and MFSR in IOMMU (0x10001050, 0x10001054), see
chapters 6.3.7 and 6.3.8 in "TurboSPARC Microprocessor User's Guide",
Fujitsu, October 1996, version 1.0.
SS-20 has M-S AFAR/AFSR (5.2.1 in Sun4m System Architecture Manual)
and ECC EFSR and EFAR (5.5.2/5.5.3). With Viking there is also
B.III.5.4.6. MXCC Error Register.
> 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.
I meant memory parity etc. On TurboSparc, parity is enabled in MMU
config register. The fault is registerd in MFSR/MFAR.
>> 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. :)
>
>> 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?
>
> Looks like a white noise to me. The first byte is frequently
> different. Also the mapped RAM is filled with 0's. The pattern can not
> be found anywhere in the mapped RAM (0x1000-0x9fffff):
>
> ok create pattern hex 00 c, d1 c, e1 c, 44 c, ff c, d1 c, e2 c, 18 c,
> ok pattern 8 1000 9effff sindex .
> ffffffff
> ok
>
> Hold on... I tested only the reading. Should have tested writing too:
>
> ok aa55aa55 8000000 l!
> ok sfar@ . sfsr@ .
> 0 0
>
> no fault, no interrupt, but
>
> ok 8000000 10 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.
> ok
>
> no change either. And if I read it differently I get other contents:
> ok 8000000 l@ .
> f811bdd
>
> So it's either a noise or a random cache contents.
>
>>> 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?
>
> In theory it could be a RAM alias, as it is outside RAM area, but RAM
> wouldn't be immutable.
> And... should have tested this one for writing too:
>
> ok aa55aa55 2fff0000 l!
> Level 15 Interrupt
> ok sfar@ . sfsr@ .
> 0 0
> ok
>
> No fault, but a NMI! Might be an ECC error as written on page 58 of
> Sun4m architecture manual. But this particular SS-5 doesn't seem to
> know anything about ECC. It's not in the device tree and reading the
> fault address register via asi doesn't work either:
>
> ok 10 2f spacel! .
> Data Access Error
> ok
No, SS-5 is very different from SS-10/20/600MP so there is no ECC.
>
> Viking CPU also produces NMI after the mmu trap (page 89), but this is
> a SS-5, so no Vikings. Could be an asynchronous fault, but afar
> doesn't match:
>
> ok afsr@ . afar@ .
> 3820000 71100006
>
> So, no idea who pulls the NMI.
>
>>
>>> 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.
>
> Yes, probably a ROM alias, but not to 0xffffffff, only to 0xf6ffffff,
> see the fault below.
>
>>> 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, 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 <=
- [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