[Qemu-devel] qemu/target-sparc op_helper.c
CVSROOT:/cvsroot/qemu Module name:qemu Changes by: Blue Swirl blueswir1 07/11/17 08:19:00 Modified files: target-sparc : op_helper.c Log message: Add MXCC module reset register (Robert Reif) CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-sparc/op_helper.c?cvsroot=qemur1=1.52r2=1.53
[Qemu-devel] qemu/target-sparc op_helper.c
CVSROOT:/cvsroot/qemu Module name:qemu Changes by: Blue Swirl blueswir1 07/11/17 08:21:43 Modified files: target-sparc : op_helper.c Log message: Remove unnecessary register masking (Robert Reif) CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-sparc/op_helper.c?cvsroot=qemur1=1.54r2=1.55
Re: [Qemu-devel] Re: RFC: fix for random Qemu crashes
On Fri, 2007-11-16 at 18:58 -0800, Ben Pfaff wrote: J. Mayer [EMAIL PROTECTED] writes: On Fri, 2007-11-16 at 21:32 +0100, andrzej zaborowski wrote: I think a line like #define inline __attribute__ (( always_inline )) inline in dyngen-exec.h should be As I already pointed it in the first message of the thread, this kind of define would expand recursivelly, [...] No. A macro is not expanded within its own expansion. See ISO C99: I just take a look of what happens in *real life* while compiling the linux kernel which uses such a definition As I reported, I had compilation problems due to this behavior and did inspect the preprocessor output and saw this result. I did not check if it happens only with some versions of gcc or if this behavior has been changed with newer releases, I have to admit. 6.10.3.4 Rescanning and further replacement [...] 2If the name of the macro being replaced is found during this scan of the replacement list (not including the rest of the source file's preprocessing tokens), it is not replaced. If it still bothers you, you could write it as #define inline __attribute__ (( always_inline )) __inline__ since GCC accepts __inline__ as a synonym for inline. You're right, this would be a good solution to avoid many changes in the code. -- J. Mayer [EMAIL PROTECTED] Never organized
[Qemu-devel] qemu/target-sparc op_helper.c
CVSROOT:/cvsroot/qemu Module name:qemu Changes by: Blue Swirl blueswir1 07/11/17 08:19:57 Modified files: target-sparc : op_helper.c Log message: Fix MXCC error register (Robert Reif) CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-sparc/op_helper.c?cvsroot=qemur1=1.53r2=1.54
[Qemu-devel] qemu vl.h hw/iommu.c hw/sun4m.c
CVSROOT:/cvsroot/qemu Module name:qemu Changes by: Blue Swirl blueswir1 07/11/17 09:04:10 Modified files: . : vl.h hw : iommu.c sun4m.c Log message: Machine specific IOMMU version (Robert Reif) CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/vl.h?cvsroot=qemur1=1.295r2=1.296 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/iommu.c?cvsroot=qemur1=1.17r2=1.18 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/sun4m.c?cvsroot=qemur1=1.61r2=1.62
Re: [Qemu-devel] [PATCH] sparc32 add new MXCC register
On 11/16/07, Robert Reif [EMAIL PROTECTED] wrote: Add new MXCC register. Thanks, applied. BTW, I couldn't use the diff directly because patch does not understand the diff format you used. In this case it was easy to delete the characters and paste the result but please use unified diffs in the future.
Re: [Qemu-devel] [PATCH] sparc32 fix MXCC error bit clearing
On 11/16/07, Robert Reif [EMAIL PROTECTED] wrote: Fix MXCC error register bit clearing. Thanks, applied.
Re: [Qemu-devel] [PATCH] sparc32 remove unnecessary 0xffffffff
On 11/16/07, Robert Reif [EMAIL PROTECTED] wrote: Remove unnecessary masking of lower word with 0x. Applied, thank you.
Re: [Qemu-devel] [PATCH] add iommu version to sparc32
On 11/16/07, Robert Reif [EMAIL PROTECTED] wrote: Add iommu version to sparc32. Also reset iommu after initialization. Should the version be tied to CPU model instead of machine type? At least for Turbosparc this seems to be the case. On SMP systems the IOMMU is on the system board in a separate ASIC. On single CPU systems the IOMMU is integrated into the CPU. Without checking the FEH, the SS 5 was the only single CPU system that shipped with more than one family of CPUs (MicroSparc II and TurboSparc and they do have different IOMMU versions). That could be special cased. OK, then the machine is more correct place. Thanks, patch applied. Unfortunately QEMU will allow you to specify unrealistic systems. We should probably add allowable CPU types to specific machine types to catch this. Well, there are plenty of things that can be unrealistic, for example memory size. For the IOMMU case, Linux does not make any checks for the version, same with NetBSD. I don't think it matters too much.
[Qemu-devel] qemu softmmu_template.h
CVSROOT:/sources/qemu Module name:qemu Changes by: Andrzej Zaborowski balrog 07/11/17 09:53:42 Modified files: . : softmmu_template.h Log message: Check permissions for the last byte first in unaligned slow_st accesses (patch from TeLeMan). CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/softmmu_template.h?cvsroot=qemur1=1.19r2=1.20
Re: [Qemu-devel] qemu softmmu_template.h
On Sat, 2007-11-17 at 09:53 +, Andrzej Zaborowski wrote: CVSROOT: /sources/qemu Module name: qemu Changes by: Andrzej Zaborowski balrog 07/11/17 09:53:42 Modified files: . : softmmu_template.h Log message: Check permissions for the last byte first in unaligned slow_st accesses (patch from TeLeMan). CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/softmmu_template.h?cvsroot=qemur1=1.19r2=1.20 Has it been checked that it's legal for all architectures and cannot have any nasty side effect to do accesses in the reverse order ? Real hardware do not ever seem to do this... -- J. Mayer [EMAIL PROTECTED] Never organized
[Qemu-devel] qemu configure
CVSROOT:/sources/qemu Module name:qemu Changes by: Andrzej Zaborowski balrog 07/11/17 10:24:32 Modified files: . : configure Log message: Show usage and abort if an unknown option is passed to configure (Carlo Marcelo Arenas Belon). CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/configure?cvsroot=qemur1=1.173r2=1.174
Re: [Qemu-devel] qemu softmmu_template.h
On 17/11/2007, J. Mayer [EMAIL PROTECTED] wrote: On Sat, 2007-11-17 at 11:14 +0100, andrzej zaborowski wrote: On 17/11/2007, J. Mayer [EMAIL PROTECTED] wrote: On Sat, 2007-11-17 at 09:53 +, Andrzej Zaborowski wrote: CVSROOT: /sources/qemu Module name: qemu Changes by: Andrzej Zaborowski balrog 07/11/17 09:53:42 Modified files: . : softmmu_template.h Log message: Check permissions for the last byte first in unaligned slow_st accesses (patch from TeLeMan). CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/softmmu_template.h?cvsroot=qemur1=1.19r2=1.20 Has it been checked that it's legal for all architectures and cannot have any nasty side effect to do accesses in the reverse order ? Real hardware do not ever seem to do this... For real hardware the store is a single operation. For PowerPC, at least, only aligned stores are defined as atomic. It's absolutely legal for an implementation to split all non-atomic accesses into smaller aligned accesses. And I guess it is the same for all architecture that can do unaligned accesses. Logically it shouldn't have any side effects, but if it does then it would rather mean that other code for that architecture is (also) broken, I believe. I've only tested ARM, mips, x86 and x86_64 before committing, so please test. I figured that the patch won't get any comments on the mailing list if it isn't merged. I don't think it's so easy to test because it may be very hard to trigger the cases that would have side effects, which are target dependent. I then am very curious to know how you did check that there is no problem with this patch Well, for ARM, x86 and x86_64 I only checked that unaligned accesses still work, i.e. that I haven't made an obvious typo. I haven't tested cross-page accesses with the access to the second page being invalid, I also don't know how the specifications for other architectures define the effect of such accesses, so maybe I shouldn't have committed this, but I assumed a common sense in the design of cpu archs, meaning that in the example given by TeLeMan the addition is not performed two times on some bytes. Regards
Re: [Qemu-devel] qemu softmmu_template.h
On 11/17/07, andrzej zaborowski [EMAIL PROTECTED] wrote: On 17/11/2007, J. Mayer [EMAIL PROTECTED] wrote: On Sat, 2007-11-17 at 11:14 +0100, andrzej zaborowski wrote: On 17/11/2007, J. Mayer [EMAIL PROTECTED] wrote: On Sat, 2007-11-17 at 09:53 +, Andrzej Zaborowski wrote: CVSROOT: /sources/qemu Module name: qemu Changes by: Andrzej Zaborowski balrog 07/11/17 09:53:42 Modified files: . : softmmu_template.h Log message: Check permissions for the last byte first in unaligned slow_st accesses (patch from TeLeMan). CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/softmmu_template.h?cvsroot=qemur1=1.19r2=1.20 Has it been checked that it's legal for all architectures and cannot have any nasty side effect to do accesses in the reverse order ? Real hardware do not ever seem to do this... For real hardware the store is a single operation. For PowerPC, at least, only aligned stores are defined as atomic. It's absolutely legal for an implementation to split all non-atomic accesses into smaller aligned accesses. And I guess it is the same for all architecture that can do unaligned accesses. Logically it shouldn't have any side effects, but if it does then it would rather mean that other code for that architecture is (also) broken, I believe. I've only tested ARM, mips, x86 and x86_64 before committing, so please test. I figured that the patch won't get any comments on the mailing list if it isn't merged. I don't think it's so easy to test because it may be very hard to trigger the cases that would have side effects, which are target dependent. I then am very curious to know how you did check that there is no problem with this patch Well, for ARM, x86 and x86_64 I only checked that unaligned accesses still work, i.e. that I haven't made an obvious typo. I haven't tested cross-page accesses with the access to the second page being invalid, I also don't know how the specifications for other architectures define the effect of such accesses, so maybe I shouldn't have committed this, but I assumed a common sense in the design of cpu archs, meaning that in the example given by TeLeMan the addition is not performed two times on some bytes. Sparc is unaffected, unaligned accesses are forbidden.
Re: [Qemu-devel] qemu softmmu_template.h
andrzej zaborowski wrote: On 17/11/2007, J. Mayer [EMAIL PROTECTED] wrote: On Sat, 2007-11-17 at 11:14 +0100, andrzej zaborowski wrote: On 17/11/2007, J. Mayer [EMAIL PROTECTED] wrote: On Sat, 2007-11-17 at 09:53 +, Andrzej Zaborowski wrote: CVSROOT: /sources/qemu Module name: qemu Changes by: Andrzej Zaborowski balrog 07/11/17 09:53:42 Modified files: . : softmmu_template.h Log message: Check permissions for the last byte first in unaligned slow_st accesses (patch from TeLeMan). CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/softmmu_template.h?cvsroot=qemur1=1.19r2=1.20 Has it been checked that it's legal for all architectures and cannot have any nasty side effect to do accesses in the reverse order ? Real hardware do not ever seem to do this... For real hardware the store is a single operation. For PowerPC, at least, only aligned stores are defined as atomic. It's absolutely legal for an implementation to split all non-atomic accesses into smaller aligned accesses. And I guess it is the same for all architecture that can do unaligned accesses. Logically it shouldn't have any side effects, but if it does then it would rather mean that other code for that architecture is (also) broken, I believe. I've only tested ARM, mips, x86 and x86_64 before committing, so please test. I figured that the patch won't get any comments on the mailing list if it isn't merged. I don't think it's so easy to test because it may be very hard to trigger the cases that would have side effects, which are target dependent. I then am very curious to know how you did check that there is no problem with this patch Well, for ARM, x86 and x86_64 I only checked that unaligned accesses still work, i.e. that I haven't made an obvious typo. I haven't tested cross-page accesses with the access to the second page being invalid, I also don't know how the specifications for other architectures define the effect of such accesses, so maybe I shouldn't have committed this, but I assumed a common sense in the design of cpu archs, meaning that in the example given by TeLeMan the addition is not performed two times on some bytes. Regards I agree with this patch is the sense that the previous behaviour was clearly incorrect. Now this patch relies on the fact that tlb_fill() does not remove the previous page from the TLB cache which is an important hidden constraint. Fabrice.
[Qemu-devel] qemu Makefile.target vl.c vl.h hw/gumstix.c hw/...
CVSROOT:/sources/qemu Module name:qemu Changes by: Andrzej Zaborowski balrog 07/11/17 11:50:55 Modified files: . : Makefile.target vl.c vl.h Added files: hw : gumstix.c pflash_cfi01.c Log message: Gumstix 'connex' board support by Thorsten Zitterell. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/Makefile.target?cvsroot=qemur1=1.223r2=1.224 http://cvs.savannah.gnu.org/viewcvs/qemu/vl.c?cvsroot=qemur1=1.362r2=1.363 http://cvs.savannah.gnu.org/viewcvs/qemu/vl.h?cvsroot=qemur1=1.296r2=1.297 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/gumstix.c?cvsroot=qemurev=1.1 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/pflash_cfi01.c?cvsroot=qemurev=1.1
[Qemu-devel] qemu/target-ppc translate.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Jocelyn Mayer j_mayer 07/11/17 12:01:45 Modified files: target-ppc : translate.c Log message: Fix collision in PowerPC instructions definitions. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/translate.c?cvsroot=qemur1=1.109r2=1.110
Re: [Qemu-devel] qemu softmmu_template.h
On Sat, 2007-11-17 at 12:57 +0100, andrzej zaborowski wrote: On 17/11/2007, J. Mayer [EMAIL PROTECTED] wrote: On Sat, 2007-11-17 at 11:44 +0100, andrzej zaborowski wrote: On 17/11/2007, J. Mayer [EMAIL PROTECTED] wrote: On Sat, 2007-11-17 at 11:14 +0100, andrzej zaborowski wrote: On 17/11/2007, J. Mayer [EMAIL PROTECTED] wrote: On Sat, 2007-11-17 at 09:53 +, Andrzej Zaborowski wrote: CVSROOT: /sources/qemu Module name: qemu Changes by: Andrzej Zaborowski balrog 07/11/17 09:53:42 Modified files: . : softmmu_template.h Log message: Check permissions for the last byte first in unaligned slow_st accesses (patch from TeLeMan). CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/softmmu_template.h?cvsroot=qemur1=1.19r2=1.20 Has it been checked that it's legal for all architectures and cannot have any nasty side effect to do accesses in the reverse order ? Real hardware do not ever seem to do this... For real hardware the store is a single operation. For PowerPC, at least, only aligned stores are defined as atomic. It's absolutely legal for an implementation to split all non-atomic accesses into smaller aligned accesses. And I guess it is the same for all architecture that can do unaligned accesses. Logically it shouldn't have any side effects, but if it does then it would rather mean that other code for that architecture is (also) broken, I believe. I've only tested ARM, mips, x86 and x86_64 before committing, so please test. I figured that the patch won't get any comments on the mailing list if it isn't merged. I don't think it's so easy to test because it may be very hard to trigger the cases that would have side effects, which are target dependent. I then am very curious to know how you did check that there is no problem with this patch Well, for ARM, x86 and x86_64 I only checked that unaligned accesses still work, i.e. that I haven't made an obvious typo. I haven't tested cross-page accesses with the access to the second page being invalid, I also don't know how the specifications for other architectures define the effect of such accesses, so maybe I shouldn't have committed this, but I assumed a common sense in the design of cpu archs, meaning that in the example given by TeLeMan the addition is not performed two times on some bytes. One case that obviously can have nasty side effects is if doing unaligned IO accesses. Doing accesses from first byte to the last is very different than doing the access from the last to the first. Hmm, right, I had not thought about IO accesses. I will watch for reports of any breakage that may have any connection with this and revert if there's any such report. What also can be very different is what is to happen when the instruction is to be restarted because of a page fault. I checked the PowerPC specification, and it appears that it allows splitted memory accesses to be done in any order. It also specifies that load and stores are restartable even if they have been partially executed (ie some registers or memory locations have already been changed), then this patch is likely not to break this target (but I did not check all specific implementations to see if some have specific requirements). This is to be checked for all other targets before such a patch can be applied, imho. Yes, although in practice that means the workaround (not a proper bugfix) would never be in qemu CVS and would be maintained in other trees endlessly. Hopefully not ! Just means one have to check the targets specifications. If specifications say it's valid to do access in random order, then it's up to the emulation code to take care of that case and make it work properly and the patch would not be to blame if it triggers some bugs. In the meantime, I checked the Alpha spec which seems, if I understood well, to allow such a behavior. -- J. Mayer [EMAIL PROTECTED] Never organized
Re: [Qemu-devel] qemu softmmu_template.h
On 17/11/2007, J. Mayer [EMAIL PROTECTED] wrote: On Sat, 2007-11-17 at 11:44 +0100, andrzej zaborowski wrote: On 17/11/2007, J. Mayer [EMAIL PROTECTED] wrote: On Sat, 2007-11-17 at 11:14 +0100, andrzej zaborowski wrote: On 17/11/2007, J. Mayer [EMAIL PROTECTED] wrote: On Sat, 2007-11-17 at 09:53 +, Andrzej Zaborowski wrote: CVSROOT: /sources/qemu Module name: qemu Changes by: Andrzej Zaborowski balrog 07/11/17 09:53:42 Modified files: . : softmmu_template.h Log message: Check permissions for the last byte first in unaligned slow_st accesses (patch from TeLeMan). CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/softmmu_template.h?cvsroot=qemur1=1.19r2=1.20 Has it been checked that it's legal for all architectures and cannot have any nasty side effect to do accesses in the reverse order ? Real hardware do not ever seem to do this... For real hardware the store is a single operation. For PowerPC, at least, only aligned stores are defined as atomic. It's absolutely legal for an implementation to split all non-atomic accesses into smaller aligned accesses. And I guess it is the same for all architecture that can do unaligned accesses. Logically it shouldn't have any side effects, but if it does then it would rather mean that other code for that architecture is (also) broken, I believe. I've only tested ARM, mips, x86 and x86_64 before committing, so please test. I figured that the patch won't get any comments on the mailing list if it isn't merged. I don't think it's so easy to test because it may be very hard to trigger the cases that would have side effects, which are target dependent. I then am very curious to know how you did check that there is no problem with this patch Well, for ARM, x86 and x86_64 I only checked that unaligned accesses still work, i.e. that I haven't made an obvious typo. I haven't tested cross-page accesses with the access to the second page being invalid, I also don't know how the specifications for other architectures define the effect of such accesses, so maybe I shouldn't have committed this, but I assumed a common sense in the design of cpu archs, meaning that in the example given by TeLeMan the addition is not performed two times on some bytes. One case that obviously can have nasty side effects is if doing unaligned IO accesses. Doing accesses from first byte to the last is very different than doing the access from the last to the first. Hmm, right, I had not thought about IO accesses. I will watch for reports of any breakage that may have any connection with this and revert if there's any such report. What also can be very different is what is to happen when the instruction is to be restarted because of a page fault. I checked the PowerPC specification, and it appears that it allows splitted memory accesses to be done in any order. It also specifies that load and stores are restartable even if they have been partially executed (ie some registers or memory locations have already been changed), then this patch is likely not to break this target (but I did not check all specific implementations to see if some have specific requirements). This is to be checked for all other targets before such a patch can be applied, imho. Yes, although in practice that means the workaround (not a proper bugfix) would never be in qemu CVS and would be maintained in other trees endlessly.
[Qemu-devel] qemu softmmu_template.h vl.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Andrzej Zaborowski balrog 07/11/17 12:12:29 Modified files: . : softmmu_template.h vl.c Log message: Don't compare '\0' against pointers. Add a note from Fabrice in slow_st template. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/softmmu_template.h?cvsroot=qemur1=1.20r2=1.21 http://cvs.savannah.gnu.org/viewcvs/qemu/vl.c?cvsroot=qemur1=1.363r2=1.364
Re: [Qemu-devel] qemu softmmu_template.h
Here is one sample to reproduce the previous bug on guest windows. Usage: rundll32 qemu-test.dll test The correct running result is to display a message box. If no patch, the exception will occur. I tested this sample on windows xp sp2. http://www.nabble.com/file/p13808936/qemu-test.rar qemu-test.rar -- View this message in context: http://www.nabble.com/qemu-softmmu_template.h-tf4825948.html#a13808936 Sent from the QEMU - Dev mailing list archive at Nabble.com.
[Qemu-devel] qemu/hw omap_mmc.c pxa.h pxa2xx_mmci.c sd.c sd....
CVSROOT:/sources/qemu Module name:qemu Changes by: Andrzej Zaborowski balrog 07/11/17 14:34:44 Modified files: hw : omap_mmc.c pxa.h pxa2xx_mmci.c sd.c sd.h spitz.c Log message: Convert SD cards code to use qemu_irq too. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/omap_mmc.c?cvsroot=qemur1=1.3r2=1.4 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/pxa.h?cvsroot=qemur1=1.9r2=1.10 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/pxa2xx_mmci.c?cvsroot=qemur1=1.3r2=1.4 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/sd.c?cvsroot=qemur1=1.3r2=1.4 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/sd.h?cvsroot=qemur1=1.3r2=1.4 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/spitz.c?cvsroot=qemur1=1.15r2=1.16
[Qemu-devel] qemu vl.h hw/gumstix.c hw/pxa.h hw/pxa2xx.c hw/...
CVSROOT:/sources/qemu Module name:qemu Changes by: Andrzej Zaborowski balrog 07/11/17 14:07:13 Modified files: . : vl.h hw : gumstix.c pxa.h pxa2xx.c pxa2xx_gpio.c pxa2xx_lcd.c spitz.c Log message: Convert PXA2xx GPIOs and SCOOP GPIOs to a qemu_irq based api (similar to omap, max7310 and s3c gpios). Convert spitz and gumstix boards to use new api. Remove now obsolete gpio_handler_t definition. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/vl.h?cvsroot=qemur1=1.297r2=1.298 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/gumstix.c?cvsroot=qemur1=1.1r2=1.2 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/pxa.h?cvsroot=qemur1=1.8r2=1.9 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/pxa2xx.c?cvsroot=qemur1=1.21r2=1.22 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/pxa2xx_gpio.c?cvsroot=qemur1=1.5r2=1.6 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/pxa2xx_lcd.c?cvsroot=qemur1=1.7r2=1.8 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/spitz.c?cvsroot=qemur1=1.14r2=1.15
[Qemu-devel] qemu/target-mips fop_template.c op.c op_helper.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Paul Brook pbrook 07/11/17 14:53:06 Modified files: target-mips: fop_template.c op.c op_helper.c Log message: Fix int/float inconsistencies. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/fop_template.c?cvsroot=qemur1=1.7r2=1.8 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/op.c?cvsroot=qemur1=1.86r2=1.87 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/op_helper.c?cvsroot=qemur1=1.71r2=1.72
Re: [Qemu-devel] [PATCH] hw/pxa2xx_dma.c
Hi,
On 15/11/2007, Thorsten Zitterell [EMAIL PROTECTED] wrote:
The following patch fixes the problem that DMA transfers are not performed
when
the DCSR_STOPINTR bit is set.
--
Thorsten
Index: hw/pxa2xx_dma.c
===
RCS file: /sources/qemu/qemu/hw/pxa2xx_dma.c,v
retrieving revision 1.5
diff -u -r1.5 pxa2xx_dma.c
--- hw/pxa2xx_dma.c 11 Nov 2007 19:47:58 - 1.5
+++ hw/pxa2xx_dma.c 15 Nov 2007 09:28:22 -
@@ -186,7 +186,8 @@
s-running = 1;
for (c = 0; c s-channels; c ++) {
ch = s-chan[c];
-
+
+ch-state = ~DCSR_STOPINTR;
while ((ch-state DCSR_RUN) !(ch-state DCSR_STOPINTR)) {
/* Test for pending requests */
if ((ch-cmd (DCMD_FLOWSRC | DCMD_FLOWTRG))
!ch-request)
Can you check if the following change would make the gumstix NIC work
too? In my understanding of the specs it's more correct, but I'm not
sure.
diff --git a/hw/pxa2xx_dma.c b/hw/pxa2xx_dma.c
index 4c60ffd..7067a78 100644
--- a/hw/pxa2xx_dma.c
+++ b/hw/pxa2xx_dma.c
@@ -342,7 +343,7 @@ static void pxa2xx_dma_write(void *opaque,
DCSR_STARTINTR | DCSR_BUSERRINTR));
s-chan[channel].state |= value 0xfc80;
-if (s-chan[channel].state DCSR_STOPIRQEN)
+if (s-chan[channel].state (DCSR_STOPIRQEN | DCSR_RUN))
s-chan[channel].state = ~DCSR_STOPINTR;
if (value DCSR_NODESCFETCH) {
@@ -352,7 +353,6 @@ static void pxa2xx_dma_write(void *opaque,
} else {
/* Descriptor-fetch mode */
if (value DCSR_RUN) {
-s-chan[channel].state = ~DCSR_STOPINTR;
pxa2xx_dma_descriptor_fetch(s, channel);
pxa2xx_dma_run(s);
}
Regards
diff --git a/hw/pxa2xx_dma.c b/hw/pxa2xx_dma.c
index 4c60ffd..7067a78 100644
--- a/hw/pxa2xx_dma.c
+++ b/hw/pxa2xx_dma.c
@@ -342,7 +343,7 @@ static void pxa2xx_dma_write(void *opaque,
DCSR_STARTINTR | DCSR_BUSERRINTR));
s-chan[channel].state |= value 0xfc80;
-if (s-chan[channel].state DCSR_STOPIRQEN)
+if (s-chan[channel].state (DCSR_STOPIRQEN | DCSR_RUN))
s-chan[channel].state = ~DCSR_STOPINTR;
if (value DCSR_NODESCFETCH) {
@@ -352,7 +353,6 @@ static void pxa2xx_dma_write(void *opaque,
} else {
/* Descriptor-fetch mode */
if (value DCSR_RUN) {
-s-chan[channel].state = ~DCSR_STOPINTR;
pxa2xx_dma_descriptor_fetch(s, channel);
pxa2xx_dma_run(s);
}
Re: [Qemu-devel] [PATCH] hw/pxa2xx_dma.c
On 17/11/2007, andrzej zaborowski [EMAIL PROTECTED] wrote:
Hi,
On 15/11/2007, Thorsten Zitterell [EMAIL PROTECTED] wrote:
The following patch fixes the problem that DMA transfers are not performed
when
the DCSR_STOPINTR bit is set.
--
Thorsten
Index: hw/pxa2xx_dma.c
===
RCS file: /sources/qemu/qemu/hw/pxa2xx_dma.c,v
retrieving revision 1.5
diff -u -r1.5 pxa2xx_dma.c
--- hw/pxa2xx_dma.c 11 Nov 2007 19:47:58 - 1.5
+++ hw/pxa2xx_dma.c 15 Nov 2007 09:28:22 -
@@ -186,7 +186,8 @@
s-running = 1;
for (c = 0; c s-channels; c ++) {
ch = s-chan[c];
-
+
+ch-state = ~DCSR_STOPINTR;
while ((ch-state DCSR_RUN) !(ch-state DCSR_STOPINTR))
{
/* Test for pending requests */
if ((ch-cmd (DCMD_FLOWSRC | DCMD_FLOWTRG))
!ch-request)
Can you check if the following change would make the gumstix NIC work
too? In my understanding of the specs it's more correct, but I'm not
sure.
Sorry, rather this is what I meant:
--- a/hw/pxa2xx_dma.c
+++ b/hw/pxa2xx_dma.c
@@ -347,8 +348,10 @@ static void pxa2xx_dma_write(void *opaque,
if (value DCSR_NODESCFETCH) {
/* No-descriptor-fetch mode */
-if (value DCSR_RUN)
+if (value DCSR_RUN) {
+s-chan[channel].state = ~DCSR_STOPINTR;
pxa2xx_dma_run(s);
+}
} else {
/* Descriptor-fetch mode */
if (value DCSR_RUN) {
diff --git a/hw/pxa2xx_dma.c b/hw/pxa2xx_dma.c
index 4c60ffd..048cb93 100644
--- a/hw/pxa2xx_dma.c
+++ b/hw/pxa2xx_dma.c
@@ -347,8 +348,10 @@ static void pxa2xx_dma_write(void *opaque,
if (value DCSR_NODESCFETCH) {
/* No-descriptor-fetch mode */
-if (value DCSR_RUN)
+if (value DCSR_RUN) {
+s-chan[channel].state = ~DCSR_STOPINTR;
pxa2xx_dma_run(s);
+}
} else {
/* Descriptor-fetch mode */
if (value DCSR_RUN) {
[Qemu-devel] qemu/hw sd.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Paul Brook pbrook 07/11/17 15:32:38 Modified files: hw : sd.c Log message: sd.c build fix. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/sd.c?cvsroot=qemur1=1.4r2=1.5
Re: [Qemu-devel] [PATCH] hw/pxa2xx_dma.c
Can you check if the following change would make the gumstix NIC work too? In my understanding of the specs it's more correct, but I'm not sure. It works!
[Qemu-devel] qemu Makefile Makefile.target arm-semi.c block-...
CVSROOT:/sources/qemu Module name:qemu Changes by: Paul Brook pbrook 07/11/17 17:14:51 Modified files: . : Makefile Makefile.target arm-semi.c block-raw.c block.c block.h cocoa.m console.c cpu-defs.h gdbstub.c loader.c m68k-semi.c monitor.c osdep.c qemu-common.h readline.c sdl.c tap-win32.c usb-linux.c vl.c vnc.c x_keymap.c audio : audio.c audio.h mixeng.c noaudio.c ossaudio.c sdlaudio.c wavaudio.c wavcapture.c hw : acpi.c adb.c adlib.c ads7846.c an5206.c apb_pci.c apic.c arm_boot.c arm_pic.c arm_sysctl.c arm_timer.c armv7m.c armv7m_nvic.c cdrom.c cirrus_vga.c cs4231.c cuda.c dma.c ds1225y.c dummy_m68k.c ecc.c eepro100.c eeprom93xx.c eeprom93xx.h es1370.c esp.c etraxfs.c etraxfs_ser.c etraxfs_timer.c fdc.c grackle_pci.c gt64xxx.c gumstix.c heathrow_pic.c i2c.c i2c.h i8254.c i8259.c ide.c integratorcp.c iommu.c irq.c irq.h isa_mmio.c jazz_led.c lsi53c895a.c m48t59.c mac_dbdma.c mac_nvram.c macio.c max111x.c max7310.c mc146818rtc.c mcf5206.c mcf5208.c mcf_fec.c mcf_intc.c mcf_uart.c mips_int.c mips_malta.c mips_mipssim.c mips_pica61.c mips_r4k.c mips_timer.c mipsnet.c mpcore.c nand.c ne2000.c omap.c omap.h omap1_clk.c omap_i2c.c omap_lcdc.c omap_mmc.c openpic.c palm.c parallel.c pc.c pci.c pckbd.c pcnet.c pcspk.c pflash_cfi01.c pflash_cfi02.c piix_pci.c pl011.c pl022.c pl031.c pl050.c pl061.c pl080.c pl110.c pl181.c pl190.c ppc.c ppc405_boards.c ppc405_uc.c ppc4xx_devs.c ppc_chrp.c ppc_mac.h ppc_oldworld.c ppc_prep.c prep_pci.c ps2.c ptimer.c pxa.h pxa2xx.c pxa2xx_dma.c pxa2xx_gpio.c pxa2xx_lcd.c pxa2xx_mmci.c pxa2xx_pcmcia.c pxa2xx_pic.c pxa2xx_timer.c r2d.c realview.c realview_gic.c rtl8139.c sb16.c scsi-disk.c sd.c sd.h serial.c sh7750.c sh7750_regnames.c sh_intc.c sh_serial.c sh_timer.c shix.c slavio_intctl.c slavio_misc.c slavio_serial.c slavio_timer.c smbus.c smbus.h smbus_eeprom.c smc91c111.c sparc32_dma.c spitz.c ssd0303.c ssd0323.c stellaris.c sun4m.c sun4u.c tc58128.c tcx.c tsc210x.c unin_pci.c usb-hid.c usb-hub.c usb-msd.c usb-ohci.c usb-uhci.c usb-wacom.c usb.c usb.h versatile_pci.c versatilepb.c vga.c vmmouse.c vmport.c vmware_vga.c wm8750.c target-sparc : helper.c op_helper.c Added files: . : console.h net.h qemu-char.h qemu-timer.h sysemu.h hw : arm-misc.h audiodev.h boards.h devices.h fdc.h flash.h hw.h isa.h mcf.h mips.h nvram.h pc.h pci.h pcmcia.h ppc.h primecell.h ps2.h scsi-disk.h sh.h sparc32_dma.h sun4m.h Removed files: . : vl.h hw : arm_pic.h m48t59.h Log message: Break up vl.h. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/Makefile?cvsroot=qemur1=1.131r2=1.132 http://cvs.savannah.gnu.org/viewcvs/qemu/Makefile.target?cvsroot=qemur1=1.224r2=1.225 http://cvs.savannah.gnu.org/viewcvs/qemu/arm-semi.c?cvsroot=qemur1=1.8r2=1.9 http://cvs.savannah.gnu.org/viewcvs/qemu/block-raw.c?cvsroot=qemur1=1.27r2=1.28 http://cvs.savannah.gnu.org/viewcvs/qemu/block.c?cvsroot=qemur1=1.47r2=1.48 http://cvs.savannah.gnu.org/viewcvs/qemu/block.h?cvsroot=qemur1=1.1r2=1.2 http://cvs.savannah.gnu.org/viewcvs/qemu/cocoa.m?cvsroot=qemur1=1.13r2=1.14 http://cvs.savannah.gnu.org/viewcvs/qemu/console.c?cvsroot=qemur1=1.16r2=1.17 http://cvs.savannah.gnu.org/viewcvs/qemu/cpu-defs.h?cvsroot=qemur1=1.26r2=1.27 http://cvs.savannah.gnu.org/viewcvs/qemu/gdbstub.c?cvsroot=qemur1=1.70r2=1.71 http://cvs.savannah.gnu.org/viewcvs/qemu/loader.c?cvsroot=qemur1=1.9r2=1.10 http://cvs.savannah.gnu.org/viewcvs/qemu/m68k-semi.c?cvsroot=qemur1=1.5r2=1.6 http://cvs.savannah.gnu.org/viewcvs/qemu/monitor.c?cvsroot=qemur1=1.85r2=1.86 http://cvs.savannah.gnu.org/viewcvs/qemu/osdep.c?cvsroot=qemur1=1.18r2=1.19
[Qemu-devel] qemu/audio alsaaudio.c coreaudio.c dsoundaudio....
CVSROOT:/sources/qemu Module name:qemu Changes by: Paul Brook pbrook 07/11/17 17:35:54 Modified files: audio : alsaaudio.c coreaudio.c dsoundaudio.c fmodaudio.c Log message: Remove stray uses of vl.h. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/audio/alsaaudio.c?cvsroot=qemur1=1.10r2=1.11 http://cvs.savannah.gnu.org/viewcvs/qemu/audio/coreaudio.c?cvsroot=qemur1=1.8r2=1.9 http://cvs.savannah.gnu.org/viewcvs/qemu/audio/dsoundaudio.c?cvsroot=qemur1=1.3r2=1.4 http://cvs.savannah.gnu.org/viewcvs/qemu/audio/fmodaudio.c?cvsroot=qemur1=1.7r2=1.8
[Qemu-devel] Breaking up vl.h
I just applied a patch that breaks up and removes vl.h My strategy (as discussed previously) is to split the contents along functional lines, and hardware split along bus/machine boundaries.. In order to avoid lots of little header files it makes fairly extensive use of opaque structure pointers. This allows e.g. network and display controllers to be prototyped in the same header without requiring all users to include net.h and console.h. It's not perfect, but I'm reasonably happy with how it ended up. There's some scope for splitting things up further, but I tended to err on the size of a few big includes. Paul
[Qemu-devel] qemu/hw pxa2xx_dma.c pxa2xx_gpio.c pxa2xx_mmci....
CVSROOT:/sources/qemu Module name:qemu Changes by: Andrzej Zaborowski balrog 07/11/17 18:43:47 Modified files: hw : pxa2xx_dma.c pxa2xx_gpio.c pxa2xx_mmci.c sd.c Log message: Better STOPINTR bit semantics in the PXA2xx DMA. Don't error out on reading GPCR register, just warn (Thorsten Zitterell). Don't zero a memory that's already zeroed. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/pxa2xx_dma.c?cvsroot=qemur1=1.6r2=1.7 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/pxa2xx_gpio.c?cvsroot=qemur1=1.7r2=1.8 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/pxa2xx_mmci.c?cvsroot=qemur1=1.5r2=1.6 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/sd.c?cvsroot=qemur1=1.6r2=1.7
[Qemu-devel] [PATCH] hw/pflash_cfi01.c
Patch to catch wrong/unknown command sequences.
Index: hw/pflash_cfi01.c
===
RCS file: /sources/qemu/qemu/hw/pflash_cfi01.c,v
retrieving revision 1.2
diff -u -r1.2 pflash_cfi01.c
--- hw/pflash_cfi01.c 17 Nov 2007 17:14:45 - 1.2
+++ hw/pflash_cfi01.c 17 Nov 2007 18:51:04 -
@@ -353,6 +353,8 @@
pfl-counter--;
break;
+default:
+goto error_flash;
}
return;
case 3: /* Confirm mode */
@@ -361,11 +363,14 @@
if (cmd == 0xd0) {
pfl-wcycle = 0;
pfl-status |= 0x80;
-break;
} else {
DPRINTF(%s: unknown command for \write block\\n, __func__);
PFLASH_BUG(Write block confirm);
+goto reset_flash;
}
+break;
+default:
+goto error_flash;
}
return;
default:
[Qemu-devel] [PATCH] Gumstix verdex support
Patch to add gumstix verdex board support.
Index: vl.c
===
RCS file: /sources/qemu/qemu/vl.c,v
retrieving revision 1.365
diff -u -r1.365 vl.c
--- vl.c 17 Nov 2007 17:14:38 - 1.365
+++ vl.c 17 Nov 2007 18:54:56 -
@@ -7451,6 +7451,7 @@
qemu_register_machine(lm3s811evb_machine);
qemu_register_machine(lm3s6965evb_machine);
qemu_register_machine(connex_machine);
+qemu_register_machine(verdex_machine);
#elif defined(TARGET_SH4)
qemu_register_machine(shix_machine);
qemu_register_machine(r2d_machine);
Index: hw/boards.h
===
RCS file: /sources/qemu/qemu/hw/boards.h,v
retrieving revision 1.1
diff -u -r1.1 boards.h
--- hw/boards.h 17 Nov 2007 17:14:40 - 1.1
+++ hw/boards.h 17 Nov 2007 18:54:56 -
@@ -77,6 +77,7 @@
/* gumstix.c */
extern QEMUMachine connex_machine;
+extern QEMUMachine verdex_machine;
/* stellaris.c */
extern QEMUMachine lm3s811evb_machine;
Index: hw/gumstix.c
===
RCS file: /sources/qemu/qemu/hw/gumstix.c,v
retrieving revision 1.3
diff -u -r1.3 gumstix.c
--- hw/gumstix.c 17 Nov 2007 17:14:42 - 1.3
+++ hw/gumstix.c 17 Nov 2007 18:54:56 -
@@ -7,6 +7,29 @@
*
* This code is licensed under the GNU GPL v2.
*/
+
+/*
+ * Example usage:
+ *
+ * connex:
+ * ===
+ * create image:
+ * # dd of=flash bs=1k count=16k if=/dev/zero
+ * # dd of=flash bs=1k conv=notrunc if=u-boot.bin
+ * # dd of=flash bs=1k conv=notrunc seek=256 if=rootfs.arm_nofpu.jffs2
+ * start it:
+ * # qemu-system-arm -M connex -pflash flash -monitor null -nographic
+ *
+ * verdex:
+ * ===
+ * create image:
+ * # dd of=flash bs=1k count=32k if=/dev/zero
+ * # dd of=flash bs=1k conv=notrunc if=u-boot.bin
+ * # dd of=flash bs=1k conv=notrunc seek=256 if=rootfs.arm_nofpu.jffs2
+ * # dd of=flash bs=1k conv=notrunc seek=31744 if=uImage
+ * start it:
+ * # qemu-system-arm -M verdex -pflash flash -monitor null -nographic -m 289
+ */
#include hw.h
#include pxa.h
@@ -16,26 +39,24 @@
#include devices.h
#include boards.h
-/* Board init. */
-enum gumstix_model_e { connex };
-
-static void gumstix_common_init(int ram_size, int vga_ram_size,
-DisplayState *ds, const char *kernel_filename,
-const char *kernel_cmdline, const char *initrd_filename,
-const char *cpu_model, enum gumstix_model_e model)
+static void connex_init(int ram_size, int vga_ram_size,
+const char *boot_device, DisplayState *ds,
+const char **fd_filename, int snapshot,
+const char *kernel_filename, const char *kernel_cmdline,
+const char *initrd_filename, const char *cpu_model)
{
struct pxa2xx_state_s *cpu;
-uint32_t gumstix_rom = 0x0200;
-uint32_t gumstix_ram = 0x0800;
+uint32_t connex_rom = 0x0100;
+uint32_t connex_ram = 0x0400;
-if (ram_size (gumstix_ram + gumstix_rom + PXA2XX_INTERNAL_SIZE)) {
+if (ram_size (connex_ram + connex_rom + PXA2XX_INTERNAL_SIZE)) {
fprintf(stderr, This platform requires %i bytes of memory\n,
-gumstix_ram + gumstix_rom + PXA2XX_INTERNAL_SIZE);
+connex_ram + connex_rom + PXA2XX_INTERNAL_SIZE);
exit(1);
}
-cpu = pxa255_init(gumstix_ram, ds);
+cpu = pxa255_init(connex_ram, ds);
if (pflash_table[0] == NULL) {
fprintf(stderr, A flash image must be given with the
@@ -43,7 +64,7 @@
exit(1);
}
-if (!pflash_register(0x, gumstix_ram + PXA2XX_INTERNAL_SIZE,
+if (!pflash_register(0x, connex_ram + PXA2XX_INTERNAL_SIZE,
pflash_table[0], 128 * 1024, 128, 2, 0, 0, 0, 0)) {
fprintf(stderr, qemu: Error register flash memory.\n);
exit(1);
@@ -56,18 +77,53 @@
pxa2xx_gpio_in_get(cpu-gpio)[36]);
}
-static void connex_init(int ram_size, int vga_ram_size,
+static void verdex_init(int ram_size, int vga_ram_size,
const char *boot_device, DisplayState *ds,
const char **fd_filename, int snapshot,
const char *kernel_filename, const char *kernel_cmdline,
const char *initrd_filename, const char *cpu_model)
{
-gumstix_common_init(ram_size, vga_ram_size, ds, kernel_filename,
-kernel_cmdline, initrd_filename, cpu_model, connex);
+struct pxa2xx_state_s *cpu;
+
+uint32_t verdex_rom = 0x0200;
+uint32_t verdex_ram = 0x1000;
+
+if (ram_size (verdex_ram + verdex_rom + PXA2XX_INTERNAL_SIZE)) {
+fprintf(stderr, This platform requires %i bytes of memory\n,
+verdex_ram + verdex_rom + PXA2XX_INTERNAL_SIZE);
+exit(1);
+}
+
+cpu = pxa270_init(verdex_ram, ds, pxa270-c0);
+
+if (pflash_table[0] == NULL) {
+fprintf(stderr, A flash image must
Re: [Qemu-devel] i386 debug exception should set BS of DR6 when single-stepping
Vegard Nossum [EMAIL PROTECTED] wrote: Hi, I experience the following problem: Setting the trap flag (TF) of the EFLAGS register correctly calls the debug exception DE. However, the DR6 register does not have the single step (BS) flag set. I remember this getting submitted. which version of Qemu are you running? 0.9.0 or 0.9.0-cvs? This patch fixes things for me, and I think it deserves some more attention given that it had no replies at that time and it's not in the latest release. http://lists.gnu.org/archive/html/qemu-devel/2007-03/msg00126.html This patch was added to CVS on June 26, 07 Ben
Re: [Qemu-devel] i386 debug exception should set BS of DR6 when single-stepping
On Nov 17, 2007 8:46 PM, Ben Taylor [EMAIL PROTECTED] wrote: Vegard Nossum [EMAIL PROTECTED] wrote: Hi, I experience the following problem: Setting the trap flag (TF) of the EFLAGS register correctly calls the debug exception DE. However, the DR6 register does not have the single step (BS) flag set. I remember this getting submitted. which version of Qemu are you running? 0.9.0 or 0.9.0-cvs? This patch fixes things for me, and I think it deserves some more attention given that it had no replies at that time and it's not in the latest release. http://lists.gnu.org/archive/html/qemu-devel/2007-03/msg00126.html This patch was added to CVS on June 26, 07 Ben Right, thanks. I couldn't find any view-cvs interface and the cvs snapshot didn't download. I was using the 0.9.0 release, yes. Vegard
[Qemu-devel] qemu/hw slavio_intctl.c
CVSROOT:/cvsroot/qemu Module name:qemu Changes by: Blue Swirl blueswir1 07/11/17 21:01:04 Modified files: hw : slavio_intctl.c Log message: Name the magic constants, fix a hex number without 0x CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/slavio_intctl.c?cvsroot=qemur1=1.23r2=1.24
[Qemu-devel] qemu/target-ppc cpu.h helper.c helper_regs.h op...
CVSROOT:/sources/qemu Module name:qemu Changes by: Jocelyn Mayer j_mayer 07/11/17 21:14:09 Modified files: target-ppc : cpu.h helper.c helper_regs.h op_helper.c Log message: PowerPC hypervisor mode is not fundamentally available only for PowerPC 64. Remove TARGET_PPC64 dependency and add code provision to be able to define a fake 32 bits CPU with hypervisor feature support. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/cpu.h?cvsroot=qemur1=1.97r2=1.98 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/helper.c?cvsroot=qemur1=1.92r2=1.93 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/helper_regs.h?cvsroot=qemur1=1.4r2=1.5 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/op_helper.c?cvsroot=qemur1=1.69r2=1.70
[Qemu-devel] qemu/target-ppc translate.c translate_init.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Jocelyn Mayer j_mayer 07/11/17 22:26:51 Modified files: target-ppc : translate.c translate_init.c Log message: A little more granularity in PowerPC instructions definition is needed in order to implement Freescale cores. Fix efsadd / efssub opcodes. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/translate.c?cvsroot=qemur1=1.110r2=1.111 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/translate_init.c?cvsroot=qemur1=1.62r2=1.63
[Qemu-devel] qemu/target-ppc cpu.h helper.c translate_init.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Jocelyn Mayer j_mayer 07/11/17 22:42:36 Modified files: target-ppc : cpu.h helper.c translate_init.c Log message: Define Freescale cores specific MMU model, exceptions and input bus. (but do not provide any actual implementation). CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/cpu.h?cvsroot=qemur1=1.98r2=1.99 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/helper.c?cvsroot=qemur1=1.93r2=1.94 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/translate_init.c?cvsroot=qemur1=1.63r2=1.64
[Qemu-devel] qemu/target-ppc cpu.h translate_init.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Jocelyn Mayer j_mayer 07/11/17 23:02:21 Modified files: target-ppc : cpu.h translate_init.c Log message: Add definitions for Freescale PowerPC implementations, ie MPC5xx, MPC8xx, e200, e300, e500 and e600 cores. Make those CPUs and PowerPC 440 available for user-mode emulation, thus providing a way of testing their implementation specific instructions. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/cpu.h?cvsroot=qemur1=1.99r2=1.100 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/translate_init.c?cvsroot=qemur1=1.64r2=1.65
[Qemu-devel] qemu/target-ppc cpu.h translate_init.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Jocelyn Mayer j_mayer 07/11/17 23:14:54 Modified files: target-ppc : cpu.h translate_init.c Log message: Improve PowerPC instructions set dump. Remove meaningless define from cpu.h Misc cleanups. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/cpu.h?cvsroot=qemur1=1.100r2=1.101 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/translate_init.c?cvsroot=qemur1=1.65r2=1.66
[Qemu-devel] qemu block-vvfat.c block.c console.c dyngen.c e...
CVSROOT:/sources/qemu Module name:qemu Changes by: Paul Brook pbrook 07/11/18 01:44:38 Modified files: . : block-vvfat.c block.c console.c dyngen.c elf_ops.h i386-dis.c loader.c monitor.c osdep.c qemu-char.h translate-op.c usb-linux.c vl.c vnc.c x_keymap.c audio : audio.c hw : arm_sysctl.c arm_timer.c gt64xxx.c i8259.c ide.c mc146818rtc.c mcf_fec.c mips_malta.c ne2000.c nvram.h omap.c omap.h omap_lcdc.c parallel.c pc.c pci.c pckbd.c piix_pci.c pl061.c pl190.c pxa2xx_lcd.c pxa2xx_pcmcia.c realview_gic.c rtl8139.c sd.c sh_serial.c sh_timer.c smbus.c stellaris.c usb-ohci.c wm8750.c target-i386: helper.c Log message: Add statics and missing #includes for prototypes. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/block-vvfat.c?cvsroot=qemur1=1.12r2=1.13 http://cvs.savannah.gnu.org/viewcvs/qemu/block.c?cvsroot=qemur1=1.48r2=1.49 http://cvs.savannah.gnu.org/viewcvs/qemu/console.c?cvsroot=qemur1=1.17r2=1.18 http://cvs.savannah.gnu.org/viewcvs/qemu/dyngen.c?cvsroot=qemur1=1.57r2=1.58 http://cvs.savannah.gnu.org/viewcvs/qemu/elf_ops.h?cvsroot=qemur1=1.11r2=1.12 http://cvs.savannah.gnu.org/viewcvs/qemu/i386-dis.c?cvsroot=qemur1=1.5r2=1.6 http://cvs.savannah.gnu.org/viewcvs/qemu/loader.c?cvsroot=qemur1=1.10r2=1.11 http://cvs.savannah.gnu.org/viewcvs/qemu/monitor.c?cvsroot=qemur1=1.86r2=1.87 http://cvs.savannah.gnu.org/viewcvs/qemu/osdep.c?cvsroot=qemur1=1.19r2=1.20 http://cvs.savannah.gnu.org/viewcvs/qemu/qemu-char.h?cvsroot=qemur1=1.1r2=1.2 http://cvs.savannah.gnu.org/viewcvs/qemu/translate-op.c?cvsroot=qemur1=1.2r2=1.3 http://cvs.savannah.gnu.org/viewcvs/qemu/usb-linux.c?cvsroot=qemur1=1.16r2=1.17 http://cvs.savannah.gnu.org/viewcvs/qemu/vl.c?cvsroot=qemur1=1.365r2=1.366 http://cvs.savannah.gnu.org/viewcvs/qemu/vnc.c?cvsroot=qemur1=1.28r2=1.29 http://cvs.savannah.gnu.org/viewcvs/qemu/x_keymap.c?cvsroot=qemur1=1.2r2=1.3 http://cvs.savannah.gnu.org/viewcvs/qemu/audio/audio.c?cvsroot=qemur1=1.18r2=1.19 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/arm_sysctl.c?cvsroot=qemur1=1.6r2=1.7 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/arm_timer.c?cvsroot=qemur1=1.8r2=1.9 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/gt64xxx.c?cvsroot=qemur1=1.23r2=1.24 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/i8259.c?cvsroot=qemur1=1.27r2=1.28 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/ide.c?cvsroot=qemur1=1.71r2=1.72 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/mc146818rtc.c?cvsroot=qemur1=1.14r2=1.15 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/mcf_fec.c?cvsroot=qemur1=1.4r2=1.5 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/mips_malta.c?cvsroot=qemur1=1.49r2=1.50 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/ne2000.c?cvsroot=qemur1=1.30r2=1.31 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/nvram.h?cvsroot=qemur1=1.1r2=1.2 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/omap.c?cvsroot=qemur1=1.22r2=1.23 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/omap.h?cvsroot=qemur1=1.16r2=1.17 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/omap_lcdc.c?cvsroot=qemur1=1.2r2=1.3 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/parallel.c?cvsroot=qemur1=1.11r2=1.12 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/pc.c?cvsroot=qemur1=1.93r2=1.94 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/pci.c?cvsroot=qemur1=1.42r2=1.43 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/pckbd.c?cvsroot=qemur1=1.25r2=1.26 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/piix_pci.c?cvsroot=qemur1=1.13r2=1.14 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/pl061.c?cvsroot=qemur1=1.2r2=1.3 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/pl190.c?cvsroot=qemur1=1.7r2=1.8 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/pxa2xx_lcd.c?cvsroot=qemur1=1.9r2=1.10 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/pxa2xx_pcmcia.c?cvsroot=qemur1=1.4r2=1.5 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/realview_gic.c?cvsroot=qemur1=1.2r2=1.3 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/rtl8139.c?cvsroot=qemur1=1.15r2=1.16 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/sd.c?cvsroot=qemur1=1.7r2=1.8 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/sh_serial.c?cvsroot=qemur1=1.2r2=1.3 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/sh_timer.c?cvsroot=qemur1=1.2r2=1.3 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/smbus.c?cvsroot=qemur1=1.4r2=1.5 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/stellaris.c?cvsroot=qemur1=1.2r2=1.3 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/usb-ohci.c?cvsroot=qemur1=1.11r2=1.12 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/wm8750.c?cvsroot=qemur1=1.3r2=1.4 http://cvs.savannah.gnu.org/viewcvs/qemu/target-i386/helper.c?cvsroot=qemur1=1.94r2=1.95
Re: [Qemu-devel] [PATCH] Gumstix verdex support
Hi, On 17/11/2007, Thorsten Zitterell [EMAIL PROTECTED] wrote: Patch to add gumstix verdex board support. The code has: +/* Interrupt line of NIC is connected to GPIO line 49 */ +smc91c111_init(nd_table[0], 0x04000300, +pxa2xx_gpio_in_get(cpu-gpio)[99]); Should it be 49 or 99? Regarding the usage example, I think not many people will look into the code for this kind of information, it would be of more use in the mailing list archives and optionally the docs. Do these boards have an LCD? If not, you can pass NULL as the ds parameter to pxa2xx_init() I think (not tested). I see that -nographic is used in both examples. Regards, Andrew
[Qemu-devel] qemu vl.c hw/pflash_cfi01.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Andrzej Zaborowski balrog 07/11/18 02:09:36 Modified files: . : vl.c hw : pflash_cfi01.c Log message: Fix a - typo. Catch wrong/unknown NOR flash command sequences, by Thorsten Zitterell. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/vl.c?cvsroot=qemur1=1.366r2=1.367 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/pflash_cfi01.c?cvsroot=qemur1=1.2r2=1.3
[Qemu-devel] qemu/target-mips translate_init.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/11/18 03:19:59 Modified files: target-mips: translate_init.c Log message: Use a valid PRid. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/translate_init.c?cvsroot=qemur1=1.29r2=1.30
[Qemu-devel] qemu/target-mips op.c op_helper.c translate.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/11/18 03:36:07 Modified files: target-mips: op.c op_helper.c translate.c Log message: Fix MIPS64 R2 instructions. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/op.c?cvsroot=qemur1=1.87r2=1.88 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/op_helper.c?cvsroot=qemur1=1.72r2=1.73 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/translate.c?cvsroot=qemur1=1.113r2=1.114
