[Qemu-devel] Re: sparc32 do_unassigned_access overhaul
2010/1/23 Blue Swirl blauwir...@gmail.com: On Fri, Jan 22, 2010 at 8:51 PM, Artyom Tarasenko atar4q...@googlemail.com wrote: 2010/1/22 Blue Swirl blauwir...@gmail.com: On Tue, Jan 19, 2010 at 9:44 PM, Artyom Tarasenko atar4q...@googlemail.com wrote: 2010/1/19 Blue Swirl blauwir...@gmail.com: On Tue, Jan 19, 2010 at 5:30 PM, Artyom Tarasenko atar4q...@googlemail.com wrote: 2010/1/15 Artyom Tarasenko atar4q...@googlemail.com: 2010/1/15 Blue Swirl blauwir...@gmail.com: On Fri, Jan 15, 2010 at 9:11 PM, Artyom Tarasenko atar4q...@googlemail.com wrote: 2010/1/15 Blue Swirl blauwir...@gmail.com: On Fri, Jan 15, 2010 at 6:46 PM, Artyom Tarasenko atar4q...@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-0x2fff, 0x7000-0xafff (ha, this would solve problems with SS-20 OBP too) and 0xf000-0xf6ff. 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 0x8000. 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
On Sat, Jan 23, 2010 at 4:46 PM, Artyom Tarasenko atar4q...@googlemail.com wrote: 2010/1/23 Blue Swirl blauwir...@gmail.com: On Fri, Jan 22, 2010 at 8:51 PM, Artyom Tarasenko atar4q...@googlemail.com wrote: 2010/1/22 Blue Swirl blauwir...@gmail.com: On Tue, Jan 19, 2010 at 9:44 PM, Artyom Tarasenko atar4q...@googlemail.com wrote: 2010/1/19 Blue Swirl blauwir...@gmail.com: On Tue, Jan 19, 2010 at 5:30 PM, Artyom Tarasenko atar4q...@googlemail.com wrote: 2010/1/15 Artyom Tarasenko atar4q...@googlemail.com: 2010/1/15 Blue Swirl blauwir...@gmail.com: On Fri, Jan 15, 2010 at 9:11 PM, Artyom Tarasenko atar4q...@googlemail.com wrote: 2010/1/15 Blue Swirl blauwir...@gmail.com: On Fri, Jan 15, 2010 at 6:46 PM, Artyom Tarasenko atar4q...@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-0x2fff, 0x7000-0xafff (ha, this would solve problems with SS-20 OBP too) and 0xf000-0xf6ff. 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 0x8000. 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.
[Qemu-devel] Re: sparc32 do_unassigned_access overhaul
On Tue, Jan 19, 2010 at 9:44 PM, Artyom Tarasenko atar4q...@googlemail.com wrote: 2010/1/19 Blue Swirl blauwir...@gmail.com: On Tue, Jan 19, 2010 at 5:30 PM, Artyom Tarasenko atar4q...@googlemail.com wrote: 2010/1/15 Artyom Tarasenko atar4q...@googlemail.com: 2010/1/15 Blue Swirl blauwir...@gmail.com: On Fri, Jan 15, 2010 at 9:11 PM, Artyom Tarasenko atar4q...@googlemail.com wrote: 2010/1/15 Blue Swirl blauwir...@gmail.com: On Fri, Jan 15, 2010 at 6:46 PM, Artyom Tarasenko atar4q...@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-0x2fff, 0x7000-0xafff (ha, this would solve problems with SS-20 OBP too) and 0xf000-0xf6ff. 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 0x8000. 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] Re: sparc32 do_unassigned_access overhaul
2010/1/22 Blue Swirl blauwir...@gmail.com: On Tue, Jan 19, 2010 at 9:44 PM, Artyom Tarasenko atar4q...@googlemail.com wrote: 2010/1/19 Blue Swirl blauwir...@gmail.com: On Tue, Jan 19, 2010 at 5:30 PM, Artyom Tarasenko atar4q...@googlemail.com wrote: 2010/1/15 Artyom Tarasenko atar4q...@googlemail.com: 2010/1/15 Blue Swirl blauwir...@gmail.com: On Fri, Jan 15, 2010 at 9:11 PM, Artyom Tarasenko atar4q...@googlemail.com wrote: 2010/1/15 Blue Swirl blauwir...@gmail.com: On Fri, Jan 15, 2010 at 6:46 PM, Artyom Tarasenko atar4q...@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-0x2fff, 0x7000-0xafff (ha, this would solve problems with SS-20 OBP too) and 0xf000-0xf6ff. 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 0x8000. 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
On Fri, Jan 22, 2010 at 8:51 PM, Artyom Tarasenko atar4q...@googlemail.com wrote: 2010/1/22 Blue Swirl blauwir...@gmail.com: On Tue, Jan 19, 2010 at 9:44 PM, Artyom Tarasenko atar4q...@googlemail.com wrote: 2010/1/19 Blue Swirl blauwir...@gmail.com: On Tue, Jan 19, 2010 at 5:30 PM, Artyom Tarasenko atar4q...@googlemail.com wrote: 2010/1/15 Artyom Tarasenko atar4q...@googlemail.com: 2010/1/15 Blue Swirl blauwir...@gmail.com: On Fri, Jan 15, 2010 at 9:11 PM, Artyom Tarasenko atar4q...@googlemail.com wrote: 2010/1/15 Blue Swirl blauwir...@gmail.com: On Fri, Jan 15, 2010 at 6:46 PM, Artyom Tarasenko atar4q...@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-0x2fff, 0x7000-0xafff (ha, this would solve problems with SS-20 OBP too) and 0xf000-0xf6ff. 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 0x8000. 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
On Tue, Jan 19, 2010 at 9:44 PM, Artyom Tarasenko atar4q...@googlemail.com wrote: 2010/1/19 Blue Swirl blauwir...@gmail.com: On Tue, Jan 19, 2010 at 5:30 PM, Artyom Tarasenko atar4q...@googlemail.com wrote: 2010/1/15 Artyom Tarasenko atar4q...@googlemail.com: 2010/1/15 Blue Swirl blauwir...@gmail.com: On Fri, Jan 15, 2010 at 9:11 PM, Artyom Tarasenko atar4q...@googlemail.com wrote: 2010/1/15 Blue Swirl blauwir...@gmail.com: On Fri, Jan 15, 2010 at 6:46 PM, Artyom Tarasenko atar4q...@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-0x2fff, 0x7000-0xafff (ha, this would solve problems with SS-20 OBP too) and 0xf000-0xf6ff. 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 0x8000. 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 800 map? Virtual : 0800. Context : @ 0.01ff.f000 001f.eec1 # 0 Region : @ 0.01fe.ec20 . Invalid ok 800 obmem 800 map-page ok 800 map? Virtual : 0800. 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. ok 800 20 dump \/ 1 2 3 4 5 6 7 8 9 a b c d e f v123456789abcdef 800 00 d1 e1 44 ff d1 e2 18 08 d1 e1 4e ff d1 e2 18 .QaV.Qb..QaV.Qb. 810 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-0x9f): ok create pattern hex 00 c, d1 c, e1 c, 44 c, ff c, d1 c, e2 c, 18 c, ok pattern 8 1000 9e sindex . ok Hold on... I tested only the reading. Should have tested writing too: ok aa55aa55 800 l! ok sfar@ . sfsr@ . 0 0 no fault, no interrupt, but ok 800 10 dump \/ 1 2 3 4 5 6 7 8 9 a b c d e f v123456789abcdef 800 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 800 l@ . f811bdd So it's either a noise or a random cache contents. ok ok 1000 map? Virtual : 1000. Context : @ 0.01ff.f000 001f.eec1 # 0 Region : @ 0.01fe.ec40 .
[Qemu-devel] Re: sparc32 do_unassigned_access overhaul
On Tue, Jan 19, 2010 at 5:30 PM, Artyom Tarasenko atar4q...@googlemail.com wrote: 2010/1/15 Artyom Tarasenko atar4q...@googlemail.com: 2010/1/15 Blue Swirl blauwir...@gmail.com: On Fri, Jan 15, 2010 at 9:11 PM, Artyom Tarasenko atar4q...@googlemail.com wrote: 2010/1/15 Blue Swirl blauwir...@gmail.com: On Fri, Jan 15, 2010 at 6:46 PM, Artyom Tarasenko atar4q...@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-0x2fff, 0x7000-0xafff (ha, this would solve problems with SS-20 OBP too) and 0xf000-0xf6ff. 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 0x8000. 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 800 map? Virtual : 0800. Context : @ 0.01ff.f000 001f.eec1 # 0 Region : @ 0.01fe.ec20 . Invalid ok 800 obmem 800 map-page ok 800 map? Virtual : 0800. 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. ok 800 20 dump \/ 1 2 3 4 5 6 7 8 9 a b c d e f v123456789abcdef 800 00 d1 e1 44 ff d1 e2 18 08 d1 e1 4e ff d1 e2 18 .QaV.Qb..QaV.Qb. 810 00 d1 e1 44 ff d1 e2 18 08 d1 e1 4e ff d1 e2 18 .QaV.Qb..QaV.Qb. RAM? ok ok 1000 map? Virtual : 1000. Context : @ 0.01ff.f000 001f.eec1 # 0 Region : @ 0.01fe.ec40 . Invalid ok 1000 obmem 1000 map-page ok 1000 20 dump \/ 1 2 3 4 5 6 7 8 9 a b c d e f v123456789abcdef 1000 04 00 00 05 00 1f e0 00 04 00 00 05 00 1f e0 00 ..`...`. 1010 04 00 00 05 04 00 00 05 04 00 00 05 04 00 00 05 IOMMU registers here... ok 3000 map? Virtual : 3000. Context : @ 0.01ff.f000 001f.eec1 # 0 Region : @ 0.01fe.ecc0 . Invalid ok 3000 obmem 3000 map-page ok 3000 20 dump \/ 1 2 3 4 5 6 7 8 9 a b c d e f v123456789abcdef 3000 Data Access Error ok 2fff obmem 2fff map-page ok 2fff 20 dump \/ 1 2 3 4 5 6 7 8 9 a b c d e f v123456789abcdef 2fff 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 f000 map? Virtual : f000. Context : @ 0.01ff.f000 001f.eec1 # 0 Region : @ 0.01fe.efc0 . Invalid ok f000 obmem f000 map-page ok f000 20 dump \/ 1 2 3 4 5 6 7 8 9 a b c d e f v123456789abcdef f000 10 80 2f 66 a1 48 00 00 01 00 00 00 01 00 00 00 ../f!H.. f010 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 0xf000 to 0x. ok f7ff map? Virtual : f7ff. Context : @ 0.01ff.f000 001f.eec1 # 0 Region : @ 0.01fe.efdc . Invalid ok f7ff obmem f7ff map-page ok f7ff 20 dump \/ 1 2 3 4 5 6 7 8 9 a b c d e f v123456789abcdef f7ff Data Access Error ok f6ff map? Virtual : f6ff. Context : @ 0.01ff.f000 001f.eec1 # 0 Region : @ 0.01fe.efd8 . Invalid ok f6ff obmem f6ff map-page ok f6ff 20 dump
[Qemu-devel] Re: sparc32 do_unassigned_access overhaul
2010/1/19 Blue Swirl blauwir...@gmail.com: On Tue, Jan 19, 2010 at 5:30 PM, Artyom Tarasenko atar4q...@googlemail.com wrote: 2010/1/15 Artyom Tarasenko atar4q...@googlemail.com: 2010/1/15 Blue Swirl blauwir...@gmail.com: On Fri, Jan 15, 2010 at 9:11 PM, Artyom Tarasenko atar4q...@googlemail.com wrote: 2010/1/15 Blue Swirl blauwir...@gmail.com: On Fri, Jan 15, 2010 at 6:46 PM, Artyom Tarasenko atar4q...@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-0x2fff, 0x7000-0xafff (ha, this would solve problems with SS-20 OBP too) and 0xf000-0xf6ff. 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 0x8000. 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 800 map? Virtual : 0800. Context : @ 0.01ff.f000 001f.eec1 # 0 Region : @ 0.01fe.ec20 . Invalid ok 800 obmem 800 map-page ok 800 map? Virtual : 0800. 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. ok 800 20 dump \/ 1 2 3 4 5 6 7 8 9 a b c d e f v123456789abcdef 800 00 d1 e1 44 ff d1 e2 18 08 d1 e1 4e ff d1 e2 18 .QaV.Qb..QaV.Qb. 810 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-0x9f): ok create pattern hex 00 c, d1 c, e1 c, 44 c, ff c, d1 c, e2 c, 18 c, ok pattern 8 1000 9e sindex . ok Hold on... I tested only the reading. Should have tested writing too: ok aa55aa55 800 l! ok sfar@ . sfsr@ . 0 0 no fault, no interrupt, but ok 800 10 dump \/ 1 2 3 4 5 6 7 8 9 a b c d e f v123456789abcdef 800 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 800 l@ . f811bdd So it's either a noise or a random cache contents. ok ok 1000 map? Virtual : 1000. Context : @ 0.01ff.f000 001f.eec1 # 0 Region : @ 0.01fe.ec40 . Invalid ok 1000 obmem 1000 map-page ok 1000 20 dump \/ 1 2 3 4 5 6 7 8 9 a b c d e f v123456789abcdef 1000 04 00 00 05 00 1f e0 00 04 00 00 05 00 1f e0 00 ..`...`. 1010 04 00 00 05 04 00 00 05 04 00 00 05 04 00 00 05 IOMMU registers here... ok 3000 map? Virtual : 3000. Context : @ 0.01ff.f000 001f.eec1 # 0 Region : @ 0.01fe.ecc0 . Invalid ok 3000 obmem 3000 map-page ok 3000 20 dump \/ 1 2 3 4 5 6 7 8 9 a b c d e f
[Qemu-devel] Re: sparc32 do_unassigned_access overhaul v2
Btw, what is the following hack for in do_unassigned_access?
saved_env = env;
env = cpu_single_env;
//...
env = saved_env;
I wonder whether I modify the correct env here:
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);
+}
--
Regards,
Artyom Tarasenko
solaris/sparc under qemu blog: http://tyom.blogspot.com/
[Qemu-devel] Re: sparc32 do_unassigned_access overhaul v2
On Mon, Jan 18, 2010 at 4:17 PM, Artyom Tarasenko
atar4q...@googlemail.com wrote:
Btw, what is the following hack for in do_unassigned_access?
saved_env = env;
env = cpu_single_env;
//...
env = saved_env;
env is a host CPU register, see for example target-sparc/exec.h. Code
which is called directly from translated code (and cpu-exec.c) is
compiled this way.
I'm not sure if do_unassigned_access will ever be called from outside
of translated code, grep hits were from exec.c, cpu-exec.c and
op_helper.c.
I wonder whether I modify the correct env here:
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);
+ }
Right, if env was NULL when entering the function, it will crash.
[Qemu-devel] Re: sparc32 do_unassigned_access overhaul
On Fri, Jan 15, 2010 at 6:46 PM, Artyom Tarasenko
atar4q...@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 atar4q...@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
On Fri, Jan 15, 2010 at 9:11 PM, Artyom Tarasenko atar4q...@googlemail.com wrote: 2010/1/15 Blue Swirl blauwir...@gmail.com: On Fri, Jan 15, 2010 at 6:46 PM, Artyom Tarasenko atar4q...@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 v2
Thanks, applied.
On Fri, Jan 15, 2010 at 9:28 PM, Artyom Tarasenko
atar4q...@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.
v2: CODING_STYLE fixes
Signed-off-by: Artyom Tarasenko atar4q...@gmail.com
---
diff --git a/target-sparc/op_helper.c b/target-sparc/op_helper.c
index 381e6c4..3ff35d3 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,29 @@ 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 +3762,12 @@ 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
2010/1/15 Blue Swirl blauwir...@gmail.com: On Fri, Jan 15, 2010 at 9:11 PM, Artyom Tarasenko atar4q...@googlemail.com wrote: 2010/1/15 Blue Swirl blauwir...@gmail.com: On Fri, Jan 15, 2010 at 6:46 PM, Artyom Tarasenko atar4q...@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.52.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/
