The branch flag is very often used. To increase the speed
the flag is separated. This patch removes several
ands and ors and branches from the generated code.
The additional flag btaken is no longer necessary.
Signed-off-by: Sebastian Macke
---
target-openrisc/cpu.c |1 +
targe
This fixes missing debug feature opcodes of dc233c core variant.
Cc: qemu-sta...@nongnu.org
Signed-off-by: Max Filippov
---
target-xtensa/core-dc233c.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/target-xtensa/core-dc233c.c b/target-xtensa/core-dc233c.c
index 11acbf3..738d543 100644
---
Am 17.10.2013 21:17, schrieb Peter Maydell:
>
>> - make sure the flash emulation supports reflashing (properties)
>> - change qemu memory subsystem to support execution from a flash that
>>can be reprogrammed (properties are rewritten during startup)
>>(maybe this is already possible, bu
The mtspr and mfspr routines didn't check for the correct memory boundaries.
This fixes a segmentation fault while booting Linux.
Signed-off-by: Sebastian Macke
---
target-openrisc/sys_helper.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/target-openris
The clock value is only evaluated when really necessary reducing
the overhead of the timer handling.
This also solves a problem in the way the Linux kernel
handles the timer and the expected accuracy.
The old version could lead to inaccurate timings.
Signed-off-by: Sebastian Macke
---
hw/openr
On 19 October 2013 18:04, Roy Franz wrote:
> The width of the devices that make up the flash interface
> is required to mask certain commands, in particular the
> write length for buffered writes. This length will be presented
> to each device on the interface by the program writing the flash,
>
On 2013-10-19 10:05, Kevin Wolf wrote:
Am 18.10.2013 um 19:59 hat Max Reitz geschrieben:
Then there's still the problem that I'm not the one who introduced
error_propagate. Someone obviously intended some purpose for it, so
even if it doesn't make a difference now (and my RFC is unneeded),
I'd s
On Sat, Oct 19, 2013 at 02:13:44AM +0200, Andreas Färber wrote:
> Am 17.10.2013 23:52, schrieb Michael S. Tsirkin:
> > diff --git a/tests/acpi-test.c b/tests/acpi-test.c
> > new file mode 100644
> > index 000..42de248
> > --- /dev/null
> > +++ b/tests/acpi-test.c
> [...]
> > +static void test_a
Here is my updated patch to fix buffered flash writes on the VExpress
platform. Buffered writes should now work properly on platforms whose
flash interface width is different from the device width. The default
is for the device-width to be set to the interface width, so platforms
that can benefit
The width of the devices that make up the flash interface
is required to mask certain commands, in particular the
write length for buffered writes. This length will be presented
to each device on the interface by the program writing the flash,
and the flash emulation code needs to be able to deter
Create vexpress specific pflash registration
function which properly configures the device-width
of 16 bits (2 bytes) for the NOR flash on the
vexpress platform. This change is required for
buffered flash writes to work properly.
Signed-off-by: Roy Franz
---
hw/arm/vexpress.c | 43 +++
The QMP wire format uses "", not '', around strings.
* docs/qapi-code-gen.txt: Fix typo.
Signed-off-by: Eric Blake
---
docs/qapi-code-gen.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/docs/qapi-code-gen.txt b/docs/qapi-code-gen.txt
index 91f44d0..0728f36 100644
--- a/d
Erik de Castro Lopo wrote:
> mle...@mega-nerd.com wrote:
>
> >
> > Changes from original:
> >
> > * Call host's libc functions directly rather than _syscall*() (as suggested
> > by Peter Maydell).
> > * Remove un-needed #defines.
> >
> > Launchpad bug is here: https://bugs.launchpad.net/bugs
Bah, the patch in #13 segfaults in some circumstances, the previous one
doesn't.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1042388
Title:
qemu: Unsupported syscall: 257 (timer_create)
Status i
mle...@mega-nerd.com wrote:
>
> Changes from original:
>
> * Call host's libc functions directly rather than _syscall*() (as suggested
> by Peter Maydell).
> * Remove un-needed #defines.
>
> Launchpad bug is here: https://bugs.launchpad.net/bugs/1042388
Bah! This version segfaults in some c
On Sat, Oct 19, 2013 at 10:05:10AM +0100, Peter Maydell wrote:
> On 19 October 2013 00:36, Ken Moffat wrote:
> > Seems I can just
> > $export ARFLAGS="rv"
> > before I configure, and it will build and install. Unless there is
> > some reason NOT to do that, please consider this closed.
>
> Well
On 18 October 2013 19:50, Roy Franz wrote:
> Create vexpress specific pflash registration
> function which properly configures the device-width
> of 16 bits (2 bytes) for the NOR flash on the
> vexpress platform. This change is required for
> buffered flash writes to work properly.
> +/* Open co
On 18 October 2013 19:42, Roy Franz wrote:
> From: Grant Likely
>
> The kernel parameter is not used when booting using firmware
> such as UEFI. The firmware image is supplied with the -pflash
> parameter, and the -kernel parameter should not be required since
> the kernel will be loaded by the
as it's depend on current direction
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD
---
hw/sd/pl181.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/hw/sd/pl181.c b/hw/sd/pl181.c
index 03875bf..91adbbd 100644
--- a/hw/sd/pl181.c
+++ b/hw/sd/pl181.c
@@ -344,7 +344,11 @@
Qemu-devel mailing list submissions
On 19 October 2013 00:36, Ken Moffat wrote:
> Seems I can just
> $export ARFLAGS="rv"
> before I configure, and it will build and install. Unless there is
> some reason NOT to do that, please consider this closed.
Well, the reason would be that nobody in practice will do
that. Make should be se
On 19 October 2013 00:38, Roy Franz wrote:
>Glad to see this go in. Is your target-arm.next branch available
> in a public repo?
No, not generally.
-- PMM
Il 18/10/2013 19:59, Max Reitz ha scritto:
> Someone obviously intended some purpose for it, so even if it doesn't
> make a difference now (and my RFC is unneeded), I'd still use it to
> propagate errors (instead of passing the error pointer). My point being
> that there *is* a function for propaga
Am 18.10.2013 um 19:59 hat Max Reitz geschrieben:
> Then there's still the problem that I'm not the one who introduced
> error_propagate. Someone obviously intended some purpose for it, so
> even if it doesn't make a difference now (and my RFC is unneeded),
> I'd still use it to propagate errors (i
24 matches
Mail list logo
