[Qemu-devel] sparc32 do_unassigned_access overhaul

[Qemu-devel] sparc32 do_unassigned_access overhaul

[Artyom Tarasenko]

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.

Signed-off-by: Artyom Tarasenko <atar4qemu@gmail.com>
---
diff --git a/target-sparc/op_helper.c b/target-sparc/op_helper.c
index 381e6c4..3a56ce9 100644
--- a/target-sparc/op_helper.c
+++ b/target-sparc/op_helper.c
@@ -3714,6 +3714,7 @@ void do_unassigned_access(target_phys_addr_t addr, int is_write, int is_exec,
                           int is_asi, int size)
 {
     CPUState *saved_env;
+    int fault_type;
 
     /* XXX: hack to restore env in all cases, even if not called from
        generated code */
@@ -3731,18 +3732,27 @@ void do_unassigned_access(target_phys_addr_t addr, int is_write, int is_exec,
                is_exec ? "exec" : is_write ? "write" : "read", size,
                size == 1 ? "" : "s", addr, env->pc);
 #endif
-    if (env->mmuregs[3]) /* Fault status register */
-        env->mmuregs[3] = 1; /* overflow (not read before another fault) */
-    if (is_asi)
-        env->mmuregs[3] |= 1 << 16;
-    if (env->psrs)
-        env->mmuregs[3] |= 1 << 5;
-    if (is_exec)
-        env->mmuregs[3] |= 1 << 6;
-    if (is_write)
-        env->mmuregs[3] |= 1 << 7;
-    env->mmuregs[3] |= (5 << 2) | 2;
-    env->mmuregs[4] = addr; /* Fault address register */
+    /* Don't overwrite translation and access faults */
+    fault_type=(env->mmuregs[3]&0x1c)>>2;
+    if ((fault_type > 4) || (fault_type==0)) {
+        env->mmuregs[3]=0; /* Fault status register */
+        if (is_asi)
+            env->mmuregs[3] |= 1 << 16;
+        if (env->psrs)
+            env->mmuregs[3] |= 1 << 5;
+        if (is_exec)
+            env->mmuregs[3] |= 1 << 6;
+        if (is_write)
+            env->mmuregs[3] |= 1 << 7;
+        env->mmuregs[3] |= (5 << 2) | 2;
+        /* SuperSPARC will never place instruction fault addresses in the FAR */
+        if (!is_exec)
+            env->mmuregs[4] = addr; /* Fault address register */
+    }
+    /* overflow (same type fault was not read before another fault) */
+    if (fault_type==((env->mmuregs[3]&0x1c))>>2)
+        env->mmuregs[3] |= 1;
+
     if ((env->mmuregs[0] & MMU_E) && !(env->mmuregs[0] & MMU_NF)) {
         if (is_exec)
             raise_exception(TT_CODE_ACCESS);
@@ -3750,6 +3760,10 @@ void do_unassigned_access(target_phys_addr_t addr, int is_write, int is_exec,
             raise_exception(TT_DATA_ACCESS);
     }
     env = saved_env;
+    /* flush neverland mappings created during no-fault mode,
+       so the sequential MMU faults report proper fault types */
+    if (env->mmuregs[0] & MMU_NF)
+        tlb_flush(env, 1);
 }
 #else
 void do_unassigned_access(target_phys_addr_t addr, int is_write, int is_exec,

[Qemu-devel] Re: sparc32 do_unassigned_access overhaul

[Blue Swirl]

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. However, there are some
CODING_STYLE issues.

>
> Signed-off-by: Artyom Tarasenko <atar4qemu@gmail.com>
> ---
> diff --git a/target-sparc/op_helper.c b/target-sparc/op_helper.c
> index 381e6c4..3a56ce9 100644
> --- a/target-sparc/op_helper.c
> +++ b/target-sparc/op_helper.c
> @@ -3714,6 +3714,7 @@ void do_unassigned_access(target_phys_addr_t addr, int is_write, int is_exec,
>                           int is_asi, int size)
>  {
>     CPUState *saved_env;
> +    int fault_type;
>
>     /* XXX: hack to restore env in all cases, even if not called from
>        generated code */
> @@ -3731,18 +3732,27 @@ void do_unassigned_access(target_phys_addr_t addr, int is_write, int is_exec,
>                is_exec ? "exec" : is_write ? "write" : "read", size,
>                size == 1 ? "" : "s", addr, env->pc);
>  #endif
> -    if (env->mmuregs[3]) /* Fault status register */
> -        env->mmuregs[3] = 1; /* overflow (not read before another fault) */
> -    if (is_asi)
> -        env->mmuregs[3] |= 1 << 16;
> -    if (env->psrs)
> -        env->mmuregs[3] |= 1 << 5;
> -    if (is_exec)
> -        env->mmuregs[3] |= 1 << 6;
> -    if (is_write)
> -        env->mmuregs[3] |= 1 << 7;
> -    env->mmuregs[3] |= (5 << 2) | 2;
> -    env->mmuregs[4] = addr; /* Fault address register */
> +    /* Don't overwrite translation and access faults */
> +    fault_type=(env->mmuregs[3]&0x1c)>>2;

Must have spaces around '=', '&' and '>>'.

> +    if ((fault_type > 4) || (fault_type==0)) {

Must have spaces around '=='.

> +        env->mmuregs[3]=0; /* Fault status register */

and '='

> +        if (is_asi)
> +            env->mmuregs[3] |= 1 << 16;
> +        if (env->psrs)
> +            env->mmuregs[3] |= 1 << 5;
> +        if (is_exec)
> +            env->mmuregs[3] |= 1 << 6;
> +        if (is_write)
> +            env->mmuregs[3] |= 1 << 7;

Here you could add the {} which the original lacked, but as this is
only code movement it's not needed.

> +        env->mmuregs[3] |= (5 << 2) | 2;
> +        /* SuperSPARC will never place instruction fault addresses in the FAR */
> +        if (!is_exec)
> +            env->mmuregs[4] = addr; /* Fault address register */

But this is new code so {} must be added.

> +    }
> +    /* overflow (same type fault was not read before another fault) */
> +    if (fault_type==((env->mmuregs[3]&0x1c))>>2)

Must have spaces around '=', '&' and '>>'.

> +        env->mmuregs[3] |= 1;
> +
>     if ((env->mmuregs[0] & MMU_E) && !(env->mmuregs[0] & MMU_NF)) {
>         if (is_exec)
>             raise_exception(TT_CODE_ACCESS);
> @@ -3750,6 +3760,10 @@ void do_unassigned_access(target_phys_addr_t addr, int is_write, int is_exec,
>             raise_exception(TT_DATA_ACCESS);
>     }
>     env = saved_env;
> +    /* flush neverland mappings created during no-fault mode,
> +       so the sequential MMU faults report proper fault types */
> +    if (env->mmuregs[0] & MMU_NF)
> +        tlb_flush(env, 1);

New code, {}.

>  }
>  #else
>  void do_unassigned_access(target_phys_addr_t addr, int is_write, int is_exec,
>

[Qemu-devel] Re: sparc32 do_unassigned_access overhaul

[Artyom Tarasenko]

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.

> However, there are some CODING_STYLE issues.

Is it something you do by hand (or, actually, by eyes), or is there a
way I can automatically test my patches before sending?

-- 
Regards,
Artyom Tarasenko

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

[Qemu-devel] Re: sparc32 do_unassigned_access overhaul

[Blue Swirl]

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.
 - Real RAM banks have aliasing effects (which could be emulated by
mapping the aliased RAM areas many times).
 - OBP on machines with ECC controller may detect missing RAM using ECC checks.

>> However, there are some CODING_STYLE issues.
>
> Is it something you do by hand (or, actually, by eyes), or is there a
> way I can automatically test my patches before sending?

There is CODING_STYLE document in the QEMU tree, please read it.

It's too bad we don't have a checkpatch script like Linux kernel has.
IIRC Anthony once said that he may write one.

[Qemu-devel] Re: sparc32 do_unassigned_access overhaul

[Artyom Tarasenko]

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.

It is possible, but may not be the only reason: -M SS-20 -cpu "TI
SuperSparc 50" detects missing RAM properly, and -cpu "TI SuperSparc
51" doesn't. Looks like the problem has to do with the cache.

Also Solaris 2.5&2.6 hang with -M SS-20 very early, at the place where
they say "vac: enabled in write through mode" on SS-5.

Unfortunately I don't know any cacheless SS-5 cpu, which would have
helped to prove the hypothesis.

>  - Real RAM banks have aliasing effects (which could be emulated by
> mapping the aliased RAM areas many times).

They do, but afaics it should be relevant only for sizes < max RAM bank size.

>  - OBP on machines with ECC controller may detect missing RAM using ECC checks.

There is a special message in OBP for ECC failures. (I know it is a
weak argument, but still).

-- 
Regards,
Artyom Tarasenko

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

[Qemu-devel] Re: sparc32 do_unassigned_access overhaul

[Artyom Tarasenko]

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.

Would you like to implement it?

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

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.
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..
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] Re: sparc32 do_unassigned_access overhaul

[Blue Swirl]

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). 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] Re: sparc32 do_unassigned_access overhaul

[Artyom Tarasenko]

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

> 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

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] Re: sparc32 do_unassigned_access overhaul

[Blue Swirl]

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.

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] Re: sparc32 do_unassigned_access overhaul

[Blue Swirl]

[-- Attachment #1: Type: text/plain, Size: 3293 bytes --]

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?

[-- Attachment #2: 0001-Add-generic-address-space-aliasing-mechanism-and-use.patch --]
[-- Type: application/mbox, Size: 7600 bytes --]

[Qemu-devel] Re: sparc32 do_unassigned_access overhaul

[Artyom Tarasenko]

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.

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/

[Qemu-devel] Re: sparc32 do_unassigned_access overhaul

[Blue Swirl]

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.

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

[Qemu-devel] Re: sparc32 do_unassigned_access overhaul

[Artyom Tarasenko]

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?

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


-- 
Regards,
Artyom Tarasenko

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

[Qemu-devel] Re: sparc32 do_unassigned_access overhaul

[Blue Swirl]

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.