On 8/30/07, Paul Brook <[EMAIL PROTECTED]> wrote:
> > If this is the case, it means we don't need anything complicated. Devices
> > map themselves straight into the system address space at the appropriate
> > slot address (no plug-n-play to worry about), and device "DMA" goes via the
> > IOMMU.
>
>
> From DMA2.txt, NCR89C100.txt, NCR89C105.txt and turbosparc.pdf I
> gather the following:
> - CPU and IOMMU always perform slave accesses
> - Slave accesses use the 28-bit address bus to select the device
I thought device selection was separate from the 28-bit SBus slave address
space. ie. each
On 9/8/07, Paul Brook <[EMAIL PROTECTED]> wrote:
> > From DMA2.txt, NCR89C100.txt, NCR89C105.txt and turbosparc.pdf I
> > gather the following:
> > - CPU and IOMMU always perform slave accesses
> > - Slave accesses use the 28-bit address bus to select the device
>
> I thought device selection was s
> > IIUC devices never register addresses on the master bus. The only thing
> > that responds on that bus is the IOMMU.
>
> Generally yes, but these "intelligent masters" and their targets would
> register on on both buses. The only case I can only think of is a
> video grabber, it's frame memory c
Attached patch implements enough of the MMC-6 specification so that certain
guest operating systems (Darwin/x86) recognize the emulated CD-ROM drive as
DVD one. Specific DVD behavior is enabled for images larger than 700Mb.
qemu-ide-dvd.patch
Description: Binary data
There is a bug in the block-vmdk.c that prevents writing to images larger
than 2Gb on Windows host operating systems. Attached patch fixes it.
qemu-block-vmdk.patch
Description: Binary data
Fix the CPUID function 2 to correctly report cache info for the particular
processor. I chose the values closest to the ones reported in the AMD
registers. This is important for operating systems that detect cache line
width and later call CLFLUSH for each line. In the previous implementation
the v
Fix the reported xlevel for Intel CPU. We support the extended CPUID calls,
so report that we support them.
qemu-cpuid-xlevel.patch
Description: Binary data
Not sure if this is usefull, but the Darwin network driver uses the "flow
control" registers, so it's not good idea to bail out and stop the emulation
if they're accessed. The registers aren't vital for the EEPRO 100 operation,
so no harm in ignoring them.
qemu-eepro100-flow-control.patch
Descrip
Attached patch allows KQEMU to build on pure MinGW installation without the
need for ELF tools or compilation on Linux. I'm not sure if it breaks the
Linux compilation, so it should be carefully tested. Hope it's usefull at
least for someone.
Best regards,
Filip Navara
kqemu-mingw.diff
Descripti
On 9/8/07, Filip Navara <[EMAIL PROTECTED]> wrote:
> Attached patch allows KQEMU to build on pure MinGW installation without the
> need for ELF tools or compilation on Linux. I'm not sure if it breaks the
> Linux compilation, so it should be carefully tested. Hope it's usefull at
> least for someon
Attached patch allows KQEMU to build on pure MinGW installation without the
need for ELF tools or compilation on Linux. I'm not sure if it breaks the
Linux compilation, so it should be carefully tested. Hope it's usefull at
least for someone.
Best regards,
Filip Navara
kqemu-mingw.diff
Descripti
Hi,
On Sat, 2007-09-08 at 21:21 +0200, Filip Navara wrote:
> Attached patch implements enough of the MMC-6 specification so that
> certain guest operating systems (Darwin/x86) recognize the emulated
> CD-ROM drive as DVD one. Specific DVD behavior is enabled for images
> larger than 700Mb.
Are t
13 matches
Mail list logo
