On Sunday 11 November 2007, Carlo Marcelo Arenas Belon wrote:
> The following patch includes "exec-all.h" in block-raw.c when QEMU_IMG is
> not defined to avoid the following implicit declaration :
I applied a slightly different version, thanks.
Paul
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook 07/11/11 12:02:33
Modified files:
hw : mips_r4k.c
Log message:
mips_r4k warning fixes.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/mips_r4k.c?cvsroot=qemu&r1=1.52&r2=1.53
On Sunday 11 November 2007, Carlo Marcelo Arenas Belon wrote:
> as shown by the following warning when compiling HEAD :
>
> qemu/target-sh4/translate.c: In function `cpu_sh4_reset':
> qemu/target-sh4/translate.c:139: warning: overflow in implicit constant
> conversion
>...
> the following patch
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook 07/11/11 14:36:36
Modified files:
target-arm : translate.c
Log message:
Fix msr_mask.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/target-arm/translate.c?cvsroot=qemu&r1=1.58&r2=1.59
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook 07/11/11 14:52:02
Modified files:
. : gdbstub.c
Log message:
Fix format mismatch.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/gdbstub.c?cvsroot=qemu&r1=1.69&r2=1.70
> +#undef NULL
> +#define NULL ((void *)0)
Absolutely not.
Paul
> This means that time_t had to be tracked down on varying architectures
> to find the size and there was an assumption made that time_t is 32 bits
> - which isn't true for all targets. The next problem is that if the
> target is 32 bits but the host is 64 bits then there's a sign extension
> prob
> time_t is only one example. There are similar problems with the
> handling of struct target_iovec. There are still other places with
> similar problems.
>
> Yes, special casing can work. There's the possible problem of value
> truncation when moving between 32 and 64 bits.
My point is that I
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook 07/11/15 19:04:09
Modified files:
. : vl.c
Log message:
Init dumb display if no others available.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/vl.c?cvsroot=qemu&r1=1.36
On Thursday 15 November 2007, Torbjörn Andersson wrote:
> This seems great! But does this mean that QEMU has support for a subset of
> the ARM11 cores?
Yes. Qemu now supports the arm1136 and arm11mpcore, plus some armv7 based
cores.
> Also, I'm curious about ARMs position to this.
CodeSourcery
> So gcc puts the zero constant to .rodata.cst8 and generates code to
> load the zero value from this location. This method is not supported
> by dyngen for Sparc, but ARM uses similar method for all (?)
> constants.
Not quite. ARM puts constant pools inline with the code, not in rodata. This
is
> Then, I choosed to replace 'inline' by 'always_inline', which is more
> invasive but have less risks of side effects. The diff is attached in
> always_inline.diff.
> The last thing that helps solve the problem is to change the inlining
> limits of gcc, at least to compile the op.o file.
Presumab
On Friday 16 November 2007, Lauro Ramos Venancio wrote:
> Hi all,
>
> I'm creating a project in Sourceforge to maintain a bleeding edge
> version of QEMU for ARM-EABI programs. The main idea is to keep up to
> date the ARM EABI patches.
Why don't you just fix whatever's wrong with normal qemu?
Pa
> > > > Check permissions for the last byte first in unaligned slow_st
> > > > accesses (patch from TeLeMan).
> > >
> > > 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
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook 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
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook 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=qemu&r1=1.4&r2=1.5
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook 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
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook 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
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 pointer
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook 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
> there might be
> some issues in the ohci/uhci because they currently assume only
> isochronous transfers are async.
That's definitely incorrect. The USB mass storage emulation uses async bulk
transfers.
Paul
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook 07/11/18 14:36:09
Modified files:
. : Makefile
hw : devices.h irq.c stellaris.c
Added files:
hw : stellaris_input.c
Log message:
Luminary
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook 07/11/18 14:33:24
Modified files:
fpu: softfloat-specialize.h softfloat.c softfloat.h
target-arm/nwfpe: double_cpdo.c single_cpdo.c
target-m68k: helper.c op.c
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook 07/11/18 14:40:35
Modified files:
hw : gumstix.c
Log message:
Fix connex board init routine.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/gumstix.c?cvsroot=qemu&r1=1.
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook 07/11/18 21:12:37
Modified files:
. : Makefile
Log message:
Fix out of tree builds.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/Makefile?cvsroot=qemu&r1=1.133&r2=1.134
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook 07/11/18 21:54:57
Modified files:
hw : ssd0323.c
Log message:
SSD0323 vertical incrememnt mode.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/ssd0323.c?cvsroot=qemu&r1
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook 07/11/19 02:38:22
Modified files:
hw : stellaris.c
Log message:
Fix typo in error message.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/stellaris.c?cvsroot=qemu&r1=1.
On Monday 19 November 2007, Samuel Thibault wrote:
> Samuel Thibault, le Mon 19 Nov 2007 15:20:16 +, a écrit :
> > Qemu currently uses 6 65k tables of pointers for handling ioports, which
> > makes 3MB on 64bit machines. There's a comment that says "XXX: use a two
> > level table to limit memor
> > Log message:
> > Add strict checking mode for softfp code.
>
> This commit has broken sparc-softmmu,
Strange. My intention was for this commit to have absolutely no functional
changes.
FWIW I verified that the debian-sparc installer image booted successfully. I
guess this probably d
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook 07/11/21 15:32:12
Modified files:
fpu: softfloat.c
Log message:
Fix typo in softfloat code.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/fpu/softfloat.c?cvsroot=qemu&r1
> Ok the problem comes from bad copy&paste. Please find a patch below that
> fixes the problem on MIPS.
>
> av = float64_val(a);
> -bv = float64_val(a);
> +bv = float64_val(b);
Applied, thanks for tracking this down. Sorry about the breakage.
Paul
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook 07/11/23 02:11:10
Modified files:
. : cpu-exec.c
Log message:
Fix TB chaining for exceptions.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/cpu-exec.c?cvsroot=qemu&r1=1
> Then I took a closer look to the code, to ensure I was not wrong.
> The PowerPC 32 on 64 bits hosts is implemented the same way that the
> specification says a PowerPC in 32 bits mode should be. Then higher bits
> are not garbage. They are what the PowerPC specification say they should
> be (apar
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook 07/11/24 03:09:07
Modified files:
hw : arm-misc.h arm_gic.c armv7m_nvic.c stellaris.c
Log message:
ARMv7-M SysTick fix.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/arm
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook 07/11/24 03:13:04
Modified files:
. : Makefile.target
hw : arm-misc.h armv7m_nvic.c stellaris.c
Added files:
hw : stellaris_enet.c
Log message
> > I think what you mean is that they work the way that ppc64 is defined, to
> > remain compatible with ppc32. IMHO this is entirely irrelevant as we're
> > emulating a ppc32. You could replace the high bits with garbage and
> > nothing would ever be able to tell the difference.
>
> PowerPC is a
> > The old code before the patch is obviously broken. It's mixing 64-bit
> > (ppc_gpr_t) and 32-bit (target_ulong) values.
>
> It seems you do not understand that what was done was correct. It's not
> mixing two different types. GPR are of ppc_gpr_t type and should be
> displayed this way.
> It's
> Furthermore this patch was made in a brainless way, it will be reverted
> asap.
> If you think there is a bug in someone else code, submit it a patch, if
> it's cleaver and addresses a real bug (which is not the case here) it
> will be accepted and merged.
The old code before the patch is obviou
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook 07/11/23 17:33:13
Modified files:
hw : ppc_oldworld.c
target-ppc : cpu.h helper.c op_helper.c
Log message:
Fix ppc32 register dumps on 64-bit hosts.
CVSWeb URLs:
http
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook 07/11/23 16:54:00
Modified files:
. : exec.c
Log message:
Fix va_list reuse in cpu_abort.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/exec.c?cvsroot=qemu&r1=1.115&r2=1.116
> There is a chance that when using "unix" or "dynticks" clock, the
> signal arrives when no cpu is executing.
I've seen similar stalls, but not managed to track down the source. Your
analysis seems correct.
> + /* cause an interrupt in the first cpu that tries to start running */
> + if
> > By your own admission, we can get away with not calculating the
> > high 32 bit of the register. If follows that the high bits are completely
> > meaningless.
>
> Not completelly. There are even some way to do 64 bits computations when
> running in 32 bits mode... Some may see this as an archi
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook 07/11/24 23:22:12
Modified files:
target-arm : helper.c
Log message:
Thumb semihosting fixes.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/target-arm/helper.c?cvsroot=qemu&r1=1.2
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook 07/11/24 23:35:08
Modified files:
. : Makefile Makefile.target
hw : omap_mmc.c pl061.c pl181.c primecell.h
pxa2xx_mmci.c sd.c sd.h ssd0323.c
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook 07/11/24 23:55:53
Modified files:
hw : pxa2xx_mmci.c
Log message:
Fix SD init arguments.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/pxa2xx_mmci.c?cvsroot=qemu&r1=1.
On Friday 30 November 2007, Carlo Marcelo Arenas Belon wrote:
> On Fri, Nov 30, 2007 at 04:28:09PM +0000, Paul Brook wrote:
> > On Friday 30 November 2007, Carlo Marcelo Arenas Belon wrote:
> > > The following patch enforces that the sh4 target is 32 bit to prevent
> > >
> > target_phys_addr_t = physical address of the host
> > ram_addr_t = physical address of the guest
>
> No, target_phys_addr_t is the physical address of the emulated target
> system. For host addresses ram_addr_t, unsigned long or even int is
> used. Host addresses are of course virtual, Qemu
On Friday 30 November 2007, Carlo Marcelo Arenas Belon wrote:
> The following patch enforces that the sh4 target is 32 bit to prevent qemu
> to expand incorrectly to a 64 bit wide cpu if compiled in a 64 bit host.
This is wrong. As the comment in cpu-defs.h says, target_phys_addr_t may need
to be
> I think T2 may need to store host addresses as well. To be frank, I
> don't understand that part but there is a compiler warning on a 64
> bit host.
If you're thinking of the warnings in op_goto_tb0, these are actually due to
tb->tb_next having the wrong type.
> > In general all access to tar
> > What solution do you prefer for the opaque types? I have used the simple:
> > >> -void *args[MAX_ARGS];
> > >> +intptr_t args[MAX_ARGS];
> >
> > A more portable and clean solution would be this:
> > -void *args[MAX_ARGS];
> > +union
> > +{
> > +void* ptr;
> > +
On Thursday 29 November 2007, André Przywara wrote:
> -qemu_get_be32s(f, &depth);
> +qemu_get_be32s(f, (uint32_t *)&depth);
This is almost certainly the wrong way to fix this.
Paul
On Friday 30 November 2007, Blue Swirl wrote:
> On 11/30/07, Jeremy C. Reed <[EMAIL PROTECTED]> wrote:
> > On Fri, 30 Nov 2007, Jeremy C. Reed wrote:
> > > The pkgsrc build system has several patches against qemu 0.9.0.
> > >
> > > They are at:
> > >
> > > http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc
> What is current situation with Host ARM and guest X86?
Should work with a bit of hacking.
Of course it's not likely to be particularly fast, even on relatively high-end
xscale hardware.
Paul
On Monday 03 December 2007, Markus Hitter wrote:
> Am 03.12.2007 um 11:30 schrieb Laurent Vivier:
> > But if you think I should remove the buffered case, I can.
>
> In doubt, less code is always better. For the unlikely case you broke
> something badly, there's always the option to take back the pa
On Monday 03 December 2007, Samuel Thibault wrote:
> Anthony Liguori, le Mon 03 Dec 2007 09:54:47 -0600, a écrit :
> > Have you done any performance testing? Buffered IO should absolutely
> > beat direct IO simply because buffered IO allows writes to complete
> > before they actually hit disk.
>
>
> Yes, librt is providing posix-aio, and librt coming with GNU libc uses
> threads.
> But if I remember correctly librt coming with RHEL uses a mix of threads
> and linux kernel AIO (you can have a look to the .srpm of libc).
>
> BTW, if everyone thinks it could be a good idea I can port block-raw.
> Well, let's separate a few things. QEMU uses posix-aio which uses
> threads and normal read/write operations. It also limits the number of
> threads that aio uses to 1 which effectively makes everything
> synchronous anyway.
This is a bug. Allegedly this is to workaround an old broken glibc, s
> Log message:
> Always create an SD bdrv, so that PXA and OMAP boards can boot with
> no card inserted again. Eventually SD, CDROM and floppy should all
> be registered conditionally depending on machine.
This seems the wrong way to solve this problem. The SD emulation should b
On Tuesday 04 December 2007, andrzej zaborowski wrote:
> On 04/12/2007, Paul Brook <[EMAIL PROTECTED]> wrote:
> > > Log message:
> > > Always create an SD bdrv, so that PXA and OMAP boards can boot
> > > with no card inserted again. Eventually SD,
> If you want to make a 16
> CPU, 64 Gb machine, define a QEMU specific machine. There are no real
> 32 bit sparc systems like that.
I believe the Cray CS6400 was a 64-way sparc32 machine with 16Gb ram.
Admittedly it's a sun4d variant, not sun4m. I've no idea how much difference
(if any) that ma
> > Actually according to qemu's standard, one should use
> > cpu_physical_memory_write/ cpu_physical_memory_read functions.
> > This is true also for reading the ring values.
>
> Yes, and unfortunately, cpu_physical_memory_{read,write} are copy
> interfaces. We really don't want that for high spe
On Wednesday 05 December 2007, Balazs Attila-Mihaly (Cd-MaN) wrote:
> This patch allows to capture the traffic flowing through a particular vlan
> in a tcpdump compatible pcap file.
>
> The patch is identical to the one created some time back, however it was
> updated to apply to HEAD.
>
> Usage: -
On Friday 07 December 2007, Laurent Vivier wrote:
> - acb->aiocb.aio_nbytes = nb_sectors * 512;
> + if (nb_sectors < 0)
> + acb->aiocb.aio_nbytes = -nb_sectors;
> + else
> + acb->aiocb.aio_nbytes = nb_sectors * 512;
Ugly hacks like this need at least a decent comment.
Paul
On Friday 07 December 2007, Alexandre Pereira Nunes wrote:
> Hi,
>
> I'm attempting to use qemu-user-arm in a very weird way:
>
> Everything works fine, except that the entry points attempts to copy memory
> from what it believes to be the "rom" image and the ram segment.
Don't do that then. Just
> virtio makes things a bit trickier though. There's a shared ring queue
> between the host and guest. The ring queue is lock-less and depends on
> the ability to atomically increment ring queue indices to be SMP safe.
> Using a copy-API wouldn't be a problem for QEMU since the host and guest
> a
On Saturday 08 December 2007, Jamie Lokier wrote:
> Paul Brook wrote:
> > > virtio makes things a bit trickier though. There's a shared ring queue
> > > between the host and guest. The ring queue is lock-less and depends on
> > > the ability to atomically inc
> +x86_cpu_def->vendor1 = cpu_to_le32(*(uint32_t *)val);
> +x86_cpu_def->vendor2 = cpu_to_le32(*(uint32_t *)(val +
> 4)); +x86_cpu_def->vendor3 = cpu_to_le32(*(uint32_t *)(val
Still not good enough. val might not be aligned.
Paul
On Monday 10 December 2007, Anthony Liguori wrote:
> Balazs Attila-Mihaly (Cd-MaN) wrote:
> > Here goes v0.2 for my patch :-)
> > Changes
> > - now the option is a separate command line switch:
> > -net capture,vlan=2,file=test.pcap
>
> Is it really necessary/useful to specify this on the command
> > I think the throttling should be done at CharDriver level so that all
> > targets and also other devices, like parallel ports (SUNW,bpp anyone?)
>
> But the timing is entirely a concept of the hardware devices. It seems
> like it would be easier to just add a growable buffer, and then setup a
> > Why can't we make the monitor interface a "formal" interface?
>
> Because then fixing a type or extending the interface becomes a pain.
>
> It's also much more difficult to specify a text-base interface
> completey, compared to a C api (where sometimes all you need is the
> header and a few com
On Tuesday 11 December 2007, andrzej zaborowski wrote:
> On 10/12/2007, Balazs Attila-Mihaly (Cd-MaN) <[EMAIL PROTECTED]> wrote:
> > Here goes v0.2 for my patch :-)
> > Changes
> > - now the option is a separate command line switch:
> > -net capture,vlan=2,file=test.pcap
> > - it is also availabl
On Wednesday 12 December 2007, Thayne Harbaugh wrote:
> I believe Paul Brook did the original patch for arm eabi TLS. The patch
> has bounced around for a bit but hasn't been applied. We've been using
> this patch for a while and have tweaked it to be a bit more corre
On Monday 08 May 2006 01:18, Jim C. Brown wrote:
> On Mon, May 08, 2006 at 12:46:24AM +0200, Pavel Jan?k wrote:
> > configure contains:
> >
> > if [ ! -x "`which $cc`" ] ; then
> > echo "Compiler $cc could not be found"
> > exit
> > fi
> >
> > You should check if the command compiles, not i
> > - Instead of copying the raw block driver, use the block driver
> > recursively.
>
> I'll work on this tonight. I've been thinking about doing this, since it
> would allow one to use any qemu-supported disk image format as a partition
> image.
>
> I can't think of any disk format that's heavily
On Monday 08 May 2006 15:19, Jim C. Brown wrote:
> On Mon, May 08, 2006 at 02:11:36PM +0100, Paul Brook wrote:
> > > I'll work on this tonight. I've been thinking about doing this, since
> > > it would allow one to use any qemu-supported disk image format as a
>
> The syntax is getting kinda ugly though. Anthony suggested that we use
> mini-config files with all the options and just pass those to -hda (e.g.
> -hda multipart:hda.config)
>
> > A vmware split image file is just a composite of several raw images with
> > a funny config file.
>
> It'd still be
On Tuesday 09 May 2006 02:36, Anthony Liguori wrote:
> Jim C. Brown wrote:
> > Aactually, the bug is in vfat not in qemu-img.
>
> Not really. POSIX doesn't mandate that ftruncate() increase a file
> size. This is a Linux-ism and is only valid for filesystems that
> support holes (which vfat doesn
> emu-0.8.1/linux-user/i386 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64
> -D_LARGEFILE_SOURCE -I/home/kadil/qemu-0.8.1/fpu -DHAS_AUDIO
> -I/home/kadil/qemu-0.8.1/slirp -c -o
> gdbstub.o /home/kadil/qemu-0.8.1/gdbstub.c
> gcc -g -Wl,-T,/home/kadil/qemu-0.8.1/x86_64.ld -o qemu-i386 elfload.o
> main.o syscal
The attached patch rearranges the PCI code and separates the PCI host
controller emulation from the generic PCI code.
There should be no functional changes except the new PCI controller for Arm
targets.
I've tested a reasonable selection of x86 guest systems (win98, win2k, Linux,
FreeBSD) and
On Wednesday 10 May 2006 19:16, Ben Taylor wrote:
> Enclosed is a patch that fixes the color mapping when running qemu on a
> Solaris/Sparc system. To enable the color mapping bgr, call qemu with the
> flag "-bgr".
We've been over this several times before. qemu should be able to autodetect
what
On Wednesday 10 May 2006 23:05, Fabrice Bellard wrote:
> In order to stop the release of incomplete BGR patches, I am
> implementing a more complete patch. I am just adding depth = 32 with BGR
> instead of RGB. If other pixel formats are wanted, you should signal it
> now.
I don't have any paticul
> Anyway, many people think of OpenGL as just 3D, but it is extremely
> competent for 2D (given a good driver).
That's where your argument falls down.
I wouldn't be surprised if even a crappy OpenGL implementation could beat
plain GDI. However I'd guess most OpenGL drivers are optimised for commo
CVSROOT:/sources/qemu
Module name:qemu
Branch:
Changes by: Paul Brook <[EMAIL PROTECTED]> 06/05/13 13:55:08
Modified files:
. : Makefile
Log message:
Allow parallel make.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qem
On Saturday 13 May 2006 16:15, Chris Wilson wrote:
> Hi Anthony,
>
> On Fri, 12 May 2006, Anthony Liguori wrote:
> > A problem arises when the client sends a SetPixelFormat message. There
> > is no "ack" message from the server so the client has to assume that as
> > soon as it sends out the messa
CVSROOT:/sources/qemu
Module name:qemu
Branch:
Changes by: Paul Brook <[EMAIL PROTECTED]> 06/05/13 16:11:23
Modified files:
. : Makefile.target vl.h
hw : acpi.c ide.c pc.c pci.c ppc_chrp.c s
CVSROOT:/sources/qemu
Module name:qemu
Branch:
Changes by: Paul Brook <[EMAIL PROTECTED]> 06/05/13 16:30:17
Modified files:
. : Makefile.target
Log message:
Add dependency on config.h and config-host.h.
CVSWeb URLs
CVSROOT:/sources/qemu
Module name:qemu
Branch:
Changes by: Paul Brook <[EMAIL PROTECTED]> 06/05/13 16:54:03
Modified files:
. : Makefile
Log message:
Move all: target first.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qem
CVSROOT:/sources/qemu
Module name:qemu
Branch:
Changes by: Paul Brook <[EMAIL PROTECTED]> 06/05/13 16:55:46
Modified files:
. : qemu-doc.texi
Log message:
Update ARM board documentation.
CVSWeb URLs:
http://cvs.savannah.gnu.org/v
CVSROOT:/sources/qemu
Module name:qemu
Branch:
Changes by: Paul Brook <[EMAIL PROTECTED]> 06/05/14 11:30:38
Modified files:
. : configure
linux-user : main.c qemu.h syscall.c
Log message:
Teach usermode emulation how
CVSROOT:/sources/qemu
Module name:qemu
Branch:
Changes by: Paul Brook <[EMAIL PROTECTED]> 06/05/14 12:07:54
Modified files:
. : .cvsignore Makefile
Log message:
Add doc, html, dvi and .PHONY Makefile targets.
Add resulting fi
On Sunday 14 May 2006 12:00, Stefan Weil wrote:
> The patch enhances the Makefile with new targets
> (and ignores these targets and intermediate files for CVS):
>
> make info - create documentation in info format
> make dvi - create documentation in dvi format
>
> It also fixes some minor issues i
CVSROOT:/sources/qemu
Module name:qemu
Branch:
Changes by: Paul Brook <[EMAIL PROTECTED]> 06/05/14 13:44:07
Modified files:
hw : pc.c
Log message:
Avoid compiler warning.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/q
CVSROOT:/sources/qemu
Module name:qemu
Branch:
Changes by: Paul Brook <[EMAIL PROTECTED]> 06/05/21 12:46:31
Modified files:
hw : esp.c
Log message:
ESP DMA fix.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/hw/esp.c.di
CVSROOT:/sources/qemu
Module name:qemu
Branch:
Changes by: Paul Brook <[EMAIL PROTECTED]> 06/05/21 13:45:10
Modified files:
hw : pci.c
Log message:
Use lookup table for PCI class descriptions.
CVSWeb URLs:
http://cvs.savannah.g
CVSROOT:/sources/qemu
Module name:qemu
Branch:
Changes by: Paul Brook <[EMAIL PROTECTED]> 06/05/21 16:30:16
Modified files:
. : Makefile.target vl.c vl.h
hw : pc.c ppc_chrp.c ppc_prep.c usb-hub.c usb-
CVSROOT:/sources/qemu
Module name:qemu
Branch:
Changes by: Paul Brook <[EMAIL PROTECTED]> 06/05/21 22:20:04
Modified files:
hw : esp.c
Log message:
Don't clear DMA status register when loading address.
CVSWeb
CVSROOT:/sources/qemu
Module name:qemu
Branch:
Changes by: Paul Brook <[EMAIL PROTECTED]> 06/05/22 14:10:48
Modified files:
. : osdep.c
Log message:
Only use /dev/shm hack when kqemu is enabled.
CVSWeb URLs:
http://cvs.savannah.g
CVSROOT:/sources/qemu
Module name:qemu
Branch:
Changes by: Paul Brook <[EMAIL PROTECTED]> 06/05/22 17:17:06
Modified files:
hw : usb-ohci.c usb-uhci.c
Log message:
Fix USB root hub hotplugging.
CVSWeb URLs:
http://cvs.savannah.g
On Thursday 25 May 2006 14:16, Ben Taylor wrote:
> The question came up a little while back about getting Solaris (Sparc) to
> boot in qemu under qemu-system-sparc.
>
> I did a little work yesterday to find out that the boot process in
> hw/sun4m.c is really kind of hard wired for a linux boot. I
CVSROOT:/sources/qemu
Module name:qemu
Branch:
Changes by: Paul Brook <[EMAIL PROTECTED]> 06/05/25 23:37:07
Modified files:
hw : usb-ohci.c
Log message:
OHCI large packet fix.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/q
901 - 1000 of 1782 matches
Mail list logo
