RE: Any example command lines for the RaspberryPi Models

> From: Alex Bennée > > Someone was asking on IRC earlier and I realised we don't give any examples > in the documentation of how to attach block devices. I found a reference in > an out-of-tree repo that mentioned -sd which seems right but I assume you > must be able to use -device sd-card as

[PATCH] MAINTAINERS: Remove myself (for raspi).

Signed-off-by: Andrew Baumann --- MAINTAINERS | 1 - 1 file changed, 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index e4b3a4bcdf..3baa83dfc9 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -818,7 +818,6 @@ F: docs/system/arm/palm.rst Raspberry Pi M: Peter Maydell -R: Andrew Baumann

Re: [Qemu-devel] RFC raspberry pi sd-card reset

From: Damien Hedde Sent: Wednesday, July 31, 2019 7:21:02 AM To: QEMU Developers Cc: Peter Maydell ; Andrew Baumann ; f4...@amsat.org ; qemu-arm Subject: RFC raspberry pi sd-card reset Hi, Concerning the reset on the raspi2/3 machine, I ran into an issue with the sd-card

Re: [Qemu-devel] [PATCH] Added periodic IRQ support for bcm2836_control local timer

> From: bzt > Sent: Wednesday, 27 February 2019 03:54 > > I'd like to add more drivers for the bcm283[567] too, and this question goes > to > Andrew Baumann mostly. I've seen implemented those missing drivers in his > repo, which aren't in the qemu mainline yet. I d

Re: [Qemu-devel] [v3 PATCH] hw/arm/bcm2835_peripherals: add bcm283x sp804-alike timer

Hi Mark, > From: Mark > Sent: Sunday, 10 February 2019 08:58 > Subject: [v3 PATCH] hw/arm/bcm2835_peripherals: add bcm283x sp804-alike > timer Thanks for the patch. The integration with bcm2835_peripherals looks good, but hopefully one of the QEMU maintainers can give you a review of the timer

Re: [Qemu-devel] [PATCH for 3.1 v2 1/7] MAINTAINERS: Add an entry for the Raspberry Pi machines

> From: Peter Maydell > Sent: Monday, 5 November 2018 09:58 > > On 5 November 2018 at 17:06, Andrew Baumann > wrote: > > From: Peter Maydell > >> Andrew, as the original submitter of the Raspberry Pi code would you > >> like to be listed as a maint

Re: [Qemu-devel] [PATCH for 3.1 v2 1/7] MAINTAINERS: Add an entry for the Raspberry Pi machines

> From: Peter Maydell > Sent: Monday, 5 November 2018 07:26 > > On 2 November 2018 at 00:12, Philippe Mathieu-Daudé > wrote: > > So far the Raspi machines use the BCM2836 SoC which includes a BCM2835 > > for the peripherals. > > > > Signed-off-by: Philippe Mathieu-Daudé > > --- > >

Re: [Qemu-devel] crashes with win2008 host

isn’t a great idea either – it fixed a deadlock. Andrew From: KONRAD Frederic Sent: Friday, September 14, 2018 4:17:36 AM To: Andrew Baumann; Andrey Shedel Cc: Paolo Bonzini; QEMU Developers Subject: Re: [Qemu-devel] crashes with win2008 host Ok finally got

Re: [Qemu-devel] crashes with win2008 host

debugger (windbg, etc.) in this scenario. Cheers, Andrew From: KONRAD Frederic Sent: Thursday, September 13, 2018 10:02:56 AM To: Andrey Shedel Cc: Andrew Baumann; Paolo Bonzini; QEMU Developers Subject: crashes with win2008 host Hi Andrey, I've strange

Re: [Qemu-devel] [PATCH 8/9] hw/arm/bcm2836: Hardcode correct CPU type

> -object_property_set_str(OBJECT(>soc), machine->cpu_type, "cpu-type", > - _abort); > object_property_set_int(OBJECT(>soc), smp_cpus, "enabled-cpus", > _abort); > int board_rev = version == 3 ? 0xa02082 : 0xa21041; What about the default_cpu_type field of MachineClass set in raspi[23]_machine_init? That seems irrelevant now... Also, if anyone cares (I don't), we also just lost the ability to override the CPU type of a raspi model. Otherwise, Reviewed-by: Andrew Baumann <andrew.baum...@microsoft.com> Cheers, Andrew

Re: [Qemu-devel] [PATCH 5/9] hw/arm/bcm2836: Rename bcm2836 type/struct to bcm283x

CM2836_NCPUS; > +mc->max_cpus = BCM283X_NCPUS; > +mc->min_cpus = BCM283X_NCPUS; > +mc->default_cpus = BCM283X_NCPUS; > mc->default_ram_size = 1024 * 1024 * 1024; > mc->ignore_memory_transaction_failures = true; > }; > @@ -212,9 +212,9 @@ static void raspi3_machine_init(MachineClass *mc) > mc->no_floppy = 1; > mc->no_cdrom = 1; > mc->default_cpu_type = ARM_CPU_TYPE_NAME("cortex-a53"); > -mc->max_cpus = BCM2836_NCPUS; > -mc->min_cpus = BCM2836_NCPUS; > -mc->default_cpus = BCM2836_NCPUS; > +mc->max_cpus = BCM283X_NCPUS; > +mc->min_cpus = BCM283X_NCPUS; > +mc->default_cpus = BCM283X_NCPUS; > mc->default_ram_size = 1024 * 1024 * 1024; > } > DEFINE_MACHINE("raspi3", raspi3_machine_init) Reviewed-by: Andrew Baumann <andrew.baum...@microsoft.com>

Re: [Qemu-devel] [PATCH 6/9] hw/arm/bcm2836: Create proper bcm2837 device

> From: Peter Maydell > Sent: Tuesday, 13 March 2018 08:35 > > The bcm2837 is pretty similar to the bcm2836, but it does have > some differences. Notably, the MPIDR affinity aff1 values it > sets for the CPUs are 0x0, rather than the 0xf that the bcm2836 > uses, and if

Re: [Qemu-devel] [PATCH 4/9] hw/arm/bcm2386: Fix parent type of bcm2386

static void bcm2836_class_init(ObjectClass *oc, void > *data) > > static const TypeInfo bcm2836_type_info = { > .name = TYPE_BCM2836, > -.parent = TYPE_SYS_BUS_DEVICE, > +.parent = TYPE_DEVICE, > .instance_size = sizeof(BCM2836State), > .instance_init =

Re: [Qemu-devel] [PATCH 1/9] hw/arm/raspi: Don't do board-setup or secure-boot for raspi3

etup; > +binfo.secure_board_setup = true; > + binfo.secure_boot = true; > +} > > /* Pi2 and Pi3 requires SMP setup */ > if (version >= 2) { Reviewed-by: Andrew Baumann <andrew.baum...@microsoft.com>

Re: [Qemu-devel] [PATCH 7/9] hw/arm/bcm2836: Use correct affinity values for BCM2837

first line of this comment should probably move or just be deleted. It's not relevant here. > * TODO: this should be converted to a property of ARM_CPU > */ > -s->cpus[n].mp_affinity = 0xF00 | n; > +s->cpus[n].mp_affinity = (info->clusterid &

Re: [Qemu-devel] [PATCH v3 33/42] hw/arm/bcm2835_peripherals: implement SDHCI Spec v3

> From: Philippe Mathieu-Daudé [mailto:philippe.mathieu.da...@gmail.com] > Sent: Friday, 29 December 2017 09:49 > > Signed-off-by: Philippe Mathieu-Daudé > --- > > Note, the bcm2835 seems to have 1KB minimum blocksize, however the > current > model is implemented with 512B. >

Re: [Qemu-devel] [PATCH] BCM2837 and machine raspi3

> From: bzt bzt [mailto:bztem...@gmail.com] > Sent: Tuesday, 28 November 2017 03:27 > Yes, I agree. I've provided a parameterised version on Oct 24, which does not > have a separate bcm2837 implementation. Is that patch ok? That patch was moving in the right direction, but I think there were two

Re: [Qemu-devel] [PATCH] BCM2837 and machine raspi3

> From: Peter Maydell [mailto:peter.mayd...@linaro.org] > Sent: Saturday, 25 November 2017 10:05 > On 25 November 2017 at 16:43, bzt bzt wrote: > > Dear Andrew, > > > > A month passed, and the maintainers didn't gave a damn about raspi3 > support > > in qemu. Any ideas? > >

[Qemu-devel] [Bug 1717708] Re: QEMU aarch64 can't run Windows ARM64 iso's

@Laszlo, I got the binaries from someone else, but they from a parallel build system... nothing particularly special: some preprocessor rules to build against the newer WDK, and also it was just those three drivers (netkvm, vioinput, viostor). I imagine you can get the same result by tweaking the

[Qemu-devel] [Bug 1717708] Re: QEMU aarch64 can't run Windows ARM64 iso's

I just noticed this bug via qemu-devel. For the record, recent QEMU (2.11-rc1 and later) can run recent arm64 Windows images using -M virt and the virtio storage/input/networking drivers in the guest. I was using older UEFI build that still includes the VGA framebuffer support. (I only just

Re: [Qemu-devel] [PATCH v2 00/43] Windbg supporting

> From: Ladi Prosek [mailto:lpro...@redhat.com] > Sent: Tuesday, 7 November 2017 00:11 > > On Mon, Nov 6, 2017 at 7:41 PM, Andrew Baumann > <andrew.baum...@microsoft.com> wrote: > > Hi, > > > > I just noticed this thread, and the problem sounded very

Re: [Qemu-devel] [PATCH v2 00/43] Windbg supporting

Hi, I just noticed this thread, and the problem sounded very familiar... > From: Ladi Prosek > Sent: Monday, 6 November 2017 07:16 [...] > FS base passes all the checks in windbg_on_load() as the guest kernel > loads and it returns true. QEMU then sends some data over the pipe. > Windbg doesn't

[Qemu-devel] [PATCH v4] arm: implement cache/shareability attribute bits for PAR registers

on them. This patch collects the attribute bits in the page-table walk, and updates PAR with the correct attributes for all LPAE translations. Short descriptor formats still return 0 for these bits, as in the prior implementation. Signed-off-by: Andrew Baumann <andrew.baum...@microsoft.com>

Re: [Qemu-devel] [PATCH v3] arm: implement cache/shareability attribute bits for PAR registers

> From: Andrew Baumann > Sent: Tuesday, 31 October 2017 21:02 [...] > +static uint8_t convert_stage2_attrs(CPUARMState *env, uint8_t s2attrs) > +{ > +uint8_t hiattr = extract32(s2attrs, 2, 2); > +uint8_t loattr = extract32(s2attrs, 0, 2); > +uint8_t h

[Qemu-devel] [PATCH v3] arm: implement cache/shareability attribute bits for PAR registers

on them. This patch collects the attribute bits in the page-table walk, and updates PAR with the correct attributes for all LPAE translations. Short descriptor formats still return 0 for these bits, as in the prior implementation. Signed-off-by: Andrew Baumann <andrew.baum...@microsoft.com>

Re: [Qemu-devel] [PATCH v2] arm: implement cache/shareability attribute bits for PAR registers

> From: Peter Maydell [mailto:peter.mayd...@linaro.org] > Sent: Tuesday, 31 October 2017 17:53 > > On 31 October 2017 at 01:23, Andrew Baumann > <andrew.baum...@microsoft.com> wrote: > >> From: Peter Maydell [mailto:peter.mayd...@linaro.org] > >> Hi. This i

Re: [Qemu-devel] [PATCH v2] arm: implement cache/shareability attribute bits for PAR registers

> From: Peter Maydell [mailto:peter.mayd...@linaro.org] > Sent: Tuesday, 31 October 2017 03:25 > > On 20 October 2017 at 22:49, Andrew Baumann > <andrew.baum...@microsoft.com> wrote: > > On a successful address translation instruction, PAR is supposed to > > cont

Re: [Qemu-devel] [PATCH] BCM2837 and machine raspi3

> From: bzt bzt [mailto:bztem...@gmail.com] > Sent: Tuesday, 24 October 2017 02:54 > On Mon, Oct 23, 2017 at 6:34 PM, Andrew Baumann wrote: > Are there any changes from bcm2836 other than the CPU model? > > > Duplicating the whole file just to have a different

Re: [Qemu-devel] [PATCH] BCM2837 and machine raspi3

*] (c) 2013 Jan Petrous > + * > + * Rasperry Pi 2 emulation and refactoring Copyright (c) 2015, Microsoft > + * Written by Andrew Baumann > + * > + * Raspberry Pi 3 emulation 2017 by bzt > + * > + * This code is licensed under the GNU GPLv2 and later. > + */ > + >

[Qemu-devel] [PATCH v2] arm: implement cache/shareability attribute bits for PAR registers

on them. This patch collects the attribute bits in the page-table walk, and updates PAR with the correct attributes for all LPAE translations. Short descriptor formats still return 0 for these bits, as in the prior implementation, but now log an unimplemented message. Signed-off-by: Andrew Baumann

Re: [Qemu-devel] [RFC PATCH] arm: implement cache/shareability attribute bits for PAR registers

> From: Peter Maydell [mailto:peter.mayd...@linaro.org] > Sent: Thursday, 19 October 2017 09:51 > > On 18 October 2017 at 01:16, Andrew Baumann > <andrew.baum...@microsoft.com> wrote: > Hi; thanks for this patch. Looks like you forgot to add your > signed-off-by line.

[Qemu-devel] [RFC PATCH] arm: implement cache/shareability attribute bits for PAR registers

On a successful address translation instruction, PAR is supposed to contain cacheability and shareability attributes determined by the translation. Previous versions of QEMU returned 0 for these bits (in line with the general strategy of ignoring caches and memory attributes), but some guests may

Re: [Qemu-devel] [PATCH] notdirty_mem_write: implement 8-byte accesses

> From: Andrew Baumann > Sent: Friday, 13 October 2017 11:19 > > Aligned 8-byte memory writes by a 64-bit target on a 64-bit host should > always turn into atomic 8-byte writes on the host, however if we missed > in the softmmu, and the TLB line was marked as not dirty, then

[Qemu-devel] [PATCH] notdirty_mem_write: implement 8-byte accesses

in access_with_adjusted_size(). Signed-off-by: Andrew Baumann <andrew.baum...@microsoft.com> --- This manifested as a race in lock-free synchronisation with an aarch64 Windows guest on an x86-64 host (with multithreaded TCG). exec.c | 13 + 1 file changed, 13 insertions(+) diff --git a/exec.c b/exec.c

Re: [Qemu-devel] Torn read/write possible on aarch64/x86-64 MTTCG?

> From: Richard Henderson [mailto:rth7...@gmail.com] On Behalf Of Richard > Henderson > Sent: Monday, 24 July 2017 15:03 > > On 07/24/2017 02:23 PM, Emilio G. Cota wrote: > > (Adding some Cc's) > > > > On Mon, Jul 24, 2017 at 19:05:33 +, Andrew Baumann vi

[Qemu-devel] Torn read/write possible on aarch64/x86-64 MTTCG?

Hi all, I'm trying to track down what appears to be a translation bug in either the aarch64 target or x86_64 TCG (in multithreaded mode). The symptoms are entirely consistent with a torn read/write -- that is, a 64-bit load or store that was translated to two 32-bit loads and stores -- but

Re: [Qemu-devel] [PATCH 2/2] file-posix: Do runtime check for ofd lock API

t.vhdx,if=none,id=hd0: Failed to unlock > byte 100 > qemu-system-aarch64: -drive file=test.vhdx,if=none,id=hd0: Failed to lock > byte 100 > > Let's do a runtime check to cope with that. > > Reported-by: Andrew Baumann <andrew.baum...@microsoft.com> > Signed

Re: [Qemu-devel] Disable image locking for snapshot drive?

> From: Fam Zheng [mailto:f...@redhat.com] > Sent: Wednesday, 19 July 2017 23:53 > > On Tue, 07/18 16:19, Andrew Baumann wrote: > > > From: Eric Blake [mailto:ebl...@redhat.com] > > > Sent: Tuesday, 18 July 2017 8:07 > > > On 07/17/2017 07:33 PM, John Sno

Re: [Qemu-devel] Disable image locking for snapshot drive?

> From: Eric Blake [mailto:ebl...@redhat.com] > Sent: Tuesday, 18 July 2017 8:07 > On 07/17/2017 07:33 PM, John Snow wrote: > > On 07/17/2017 07:30 PM, Andrew Baumann via Qemu-devel wrote: > >> I'm running a recent Linux build of qemu on Windows Subsystem for Linux >

Re: [Qemu-devel] Disable image locking for snapshot drive?

> From: John Snow [mailto:js...@redhat.com] > Sent: Monday, 17 July 2017 17:34 > On 07/17/2017 07:30 PM, Andrew Baumann via Qemu-devel wrote: > > Hi all, > > > > I'm running a recent Linux build of qemu on Windows Subsystem for Linux > (WSL) which doesn't ap

[Qemu-devel] Disable image locking for snapshot drive?

Hi all, I'm running a recent Linux build of qemu on Windows Subsystem for Linux (WSL) which doesn't appear to implement file locking: $ qemu-system-aarch64 ... -drive file=test.vhdx,if=none,id=hd0 -device virtio-blk-pci,drive=hd0 qemu-system-aarch64: -drive file=test.vhdx,if=none,id=hd0:

Re: [Qemu-devel] [PATCH] raspi: Add Raspberry Pi 1 support

> From: Andrew Baumann > Sent: Monday, 10 April 2017 10:05 > > From: Omar Rizwan [mailto:omar.riz...@gmail.com] > > Sent: Friday, 7 April 2017 23:13 > > I can't easily find documentation for that 0x4000 memory mapping, > > which I figured I'd keep in; should i

Re: [Qemu-devel] [PATCH] raspi: Add Raspberry Pi 1 support

> From: Omar Rizwan [mailto:omar.riz...@gmail.com] > Sent: Friday, 7 April 2017 23:13 > On Fri, Apr 7, 2017 at 10:57 PM Andrew Baumann > <andrew.baum...@microsoft.com> wrote: > > > From: Omar Rizwan [mailto:omar.riz...@gmail.com] > > > Sent: Friday, 7 April 20

Re: [Qemu-devel] [PATCH] raspi: Add Raspberry Pi 1 support

Hi Omar, > From: Omar Rizwan [mailto:omar.riz...@gmail.com] > Sent: Friday, 7 April 2017 22:43 Did you do any testing of this? One of the reasons I never got around to upstreaming this was that I couldn't get Raspbian working reliably (there was some problem with stalled DMA reads from the MMC

Re: [Qemu-devel] [PATCH] win32: replace custom mutex and condition variable with native primitives

> From: Cornelia Huck [mailto:cornelia.h...@de.ibm.com] > Sent: Monday, 3 April 2017 7:20 > > On Fri, 24 Mar 2017 15:01:41 -0700 > Andrew Baumann <andrew.baum...@microsoft.com> wrote: > > > From: Andrey Shedel <ashe...@microsoft.com> > > > > The mu

Re: [Qemu-devel] [PATCH for 2.9?] tap-win32: don't abort in tap_enable(); enables -netdev tap

> From: Jason Wang [mailto:jasow...@redhat.com] > Sent: Tuesday, 28 March 2017 19:39 > > On 2017年03月29日 02:55, Andrew Baumann wrote: > >> From: Stefan Weil [mailto:s...@weilnetz.de] > >> Sent: Tuesday, 28 March 2017 11:28 > >> Am 25.03.2017 um 00:46

Re: [Qemu-devel] [PATCH v3 for-2.9?] virtio: fix vring_align() on 64-bit windows

> From: Eric Blake [mailto:ebl...@redhat.com] > Sent: Tuesday, 28 March 2017 11:52 > > On 03/28/2017 01:38 PM, Stefan Weil wrote: > > Am 25.03.2017 um 00:19 schrieb Andrew Baumann: > >> long is 32-bits on 64-bit windows, which caused the top half of the > >>

Re: [Qemu-devel] [PATCH for 2.9?] tap-win32: don't abort in tap_enable(); enables -netdev tap

> From: Stefan Weil [mailto:s...@weilnetz.de] > Sent: Tuesday, 28 March 2017 11:28 > Am 25.03.2017 um 00:46 schrieb Andrew Baumann: > > The docs generally steer users away from using the legacy -net > > parameter, however on win32 attempting to enable a tap device using

Re: [Qemu-devel] qemu-devel mailing list vs DMARC and microsoft.com's p=reject policy

> From: Peter Maydell [mailto:peter.mayd...@linaro.org] > Sent: Tuesday, 28 March 2017 10:36 > > Hi; it's been pointed out to me that we have a problem with qemu-devel > unsubscribing people because of DMARC. Specifically: > * microsoft.com publishes a DMARC policy that has p=reject > * some

[Qemu-devel] [PATCH] tap-win32: don't abort in tap_enable(); enables -netdev tap

The docs generally steer users away from using the legacy -net parameter, however on win32 attempting to enable a tap device using -netdev tap fails at an abort() in tap_enable(). Removing the abort()s seems to be enough to get everything working, so do that. Signed-off-by: Andrew Baumann

Re: [Qemu-devel] [PATCH for-2.9 v2] virtio: fix vring_align() on 64-bit win32 platforms

> From: Eric Blake [mailto:ebl...@redhat.com] > Sent: Friday, 24 March 2017 15:20 > So is 'win32' really a 64-bit platform, or should the subject be '64-bit > windows'? Sigh. Yes, ok, it's a little silly if you put it like that. I guess I was thinking of the _WIN32 ifdef and the files named

[Qemu-devel] [PATCH v3] virtio: fix vring_align() on 64-bit windows

long is 32-bits on 64-bit windows, which caused the top half of the address to be truncated; this patch changes it to use the QEMU_ALIGN_UP macro which does not suffer the same problem Signed-off-by: Andrew Baumann <andrew.baum...@microsoft.com> Reviewed-by: Eric Blake <ebl...@r

Re: [Qemu-devel] [PATCH] win32: replace custom mutex and condition variable with native primitives

> This patch replaces all the custom synchronisation code for mutexes > > and condition variables with native Windows primitives (SRWlocks and > > condition variables) with the same semantics as their POSIX > > equivalents. To enable that, it requires a Windows Vista or newer host

[Qemu-devel] [PATCH] win32: replace custom mutex and condition variable with native primitives

POSIX equivalents. To enable that, it requires a Windows Vista or newer host OS. [AB: edited commit message] Signed-off-by: Andrew Baumann <andrew.baum...@microsoft.com> --- The major implication of this patch is that it drops support for pre-Vista versions of Windows. However, those OSes are pa

[Qemu-devel] [PATCH v2] virtio: fix vring_align() on 64-bit win32 platforms

long is 32-bits on win32, which caused the top half of the address to be truncated; this patch changes it to use the QEMU_ALIGN_UP macro which does not suffer the same problem Signed-off-by: Andrew Baumann <andrew.baum...@microsoft.com> --- include/hw/virtio/virtio.h | 2 +- 1 file chan

Re: [Qemu-devel] [PATCH] virtio: fix vring_align() on 64-bit win32 platforms

> From: Eric Blake [mailto:ebl...@redhat.com] > Sent: Tuesday, 21 March 2017 15:52 > > On 03/21/2017 05:31 PM, Andrew Baumann wrote: > > "long" is 32-bits on win32, but we need to promote it to a 64-bit hwaddr > > before negating, or else the top half of the a

[Qemu-devel] [PATCH] virtio: fix vring_align() on 64-bit win32 platforms

"long" is 32-bits on win32, but we need to promote it to a 64-bit hwaddr before negating, or else the top half of the address is truncated Signed-off-by: Andrew Baumann <andrew.baum...@microsoft.com> --- include/hw/virtio/virtio.h | 2 +- 1 file changed, 1 insertion(+), 1 deletio

Re: [Qemu-devel] [PATCH 0/2] misc aarch64 fixes for Windows

> From: no-re...@patchew.org [mailto:no-re...@patchew.org] > Sent: Tuesday, 28 February 2017 14:13 > > Hi, > > This series failed build test on s390x host. Please find the details below. [..] > /var/tmp/patchew-tester-tmp-64adnjjr/src/target/arm/helper.c:931:23: > error: ‘pmreg_access_ccntr’

[Qemu-devel] [PATCH 0/2] misc aarch64 fixes for Windows

to try a more recent kernel if someone could point me to a bootable image. Cheers, Andrew Andrew Baumann (2): target/arm: implement armv8 PMUSERENR (user-mode enable bits) target/arm: lie more convincingly about memory attributes in PAR_EL1 target/arm/helper.c | 87

[Qemu-devel] [PATCH 1/2] target/arm: implement armv8 PMUSERENR (user-mode enable bits)

In armv8, this register implements more than a single bit, with fine-grained enables for read access to event counters, cycles counters, and write access to the software increment. This change implements those checks using custom access functions for the relevant registers. Signed-off-by: Andrew

[Qemu-devel] [PATCH 2/2] target/arm: lie more convincingly about memory attributes in PAR_EL1

), this change sets them to 0xff, which corresponds to write-back cached normal memory. Signed-off-by: Andrew Baumann <andrew.baum...@microsoft.com> --- In my (biased!) opinion, this is a better lie to tell for an emulated environment. It also happens to un-break the Windows boot process, and

Re: [Qemu-devel] [PATCH v2 3/3] bcm2835: add sdhost and gpio controllers

wo SD cards between the two controllers, which doesn't sound like a faithful recreation of the hardware. Otherwise, Reviewed-by: Andrew Baumann <andrew.baum...@microsoft.com> Cheers, Andrew

Re: [Qemu-devel] [PATCH 2/2] bcm2835: add bcm2835_sdhost to bcm2835 platform

Hi Clement, I think Peter already gave you a great high-level suggestion, but FWIW I spotted one minor niggle here: > diff --git a/hw/sd/Makefile.objs b/hw/sd/Makefile.objs > index 31c83308f2..c2b7664264 100644 > --- a/hw/sd/Makefile.objs > +++ b/hw/sd/Makefile.objs > @@ -6,3 +6,4 @@

Re: [Qemu-devel] Call for GSoC 2017 mentors & project ideas

is a > >> piece of string" project, but on the other hand breaks > >> down easily into small parts that can all go upstream > >> individually. Would suit student who likes debugging :-) > > > Who was working on this most recently? There was someone submitti

Re: [Qemu-devel] [PATCH 26/37] sd: free timer

ently also leaky (I don't remember where unfortunately). One thing: are you sure it is safe to call timer_del() again if the timer may already have been deleted? It looks that way from the implementation, but the header comment isn't explicit. Otherwise, Reviewed-by: Andrew Baumann <andrew.baum...@microsoft.com> Cheers, Andrew

[Qemu-devel] Shouldn't cortex-a15 enable ARM_FEATURE_EL2?

Hi Peter, I'm trying to use the MRS/MSR banked register instructions you recently implemented, but found that they raised an undefined instruction exception on the cortex-a15 CPU model. This seems to be caused by the check in msr_banked_access_decode(), which looks for ARM_FEATURE_V8 or

Re: [Qemu-devel] [Qemu-arm] [PATCH] bcm2835_property: use cached values when querying framebuffer

> From: Gerd Hoffmann [mailto:kra...@redhat.com] > Sent: Friday, 22 April 2016 09:46 > > Alternatively we can just go for a later boot loader stage, i.e. put a u-boot > build > for rpi2 to pc-bios/ (we already have one for ppc there) and run that by > default. > > Our sdcard emulation seems to

Re: [Qemu-devel] [Qemu-arm] [PATCH] bcm2835_property: use cached values when querying framebuffer

Hi all, > From: Peter Crosthwaite [mailto:crosthwaitepe...@gmail.com] > Sent: Friday, 22 April 2016 09:18 > > On Thu, Apr 21, 2016 at 9:06 AM, Stephen Warren > wrote: > > On 04/21/2016 08:07 AM, Sylvain Garrigues wrote: > >> > >> Le 21 avr. 2016 à 15:42, Peter Maydell

Re: [Qemu-devel] [PATCH] bcm2835_property: use cached values when querying framebuffer

> From: Sylvain Garrigues [mailto:sylv...@sylvaingarrigues.com] > Sent: Friday, 22 April 2016 13:27 > > Le 22 avr. 2016 à 13:22, Andrew Baumann > <andrew.baum...@microsoft.com> a écrit : > >> +stl_le_phys(>dma_as, value + 16, tmp_xres

Re: [Qemu-devel] [PATCH] bcm2835_property: use cached values when querying framebuffer

ewbpp != NULL ? *newbpp : s->fbdev->bpp; > +stl_le_phys(>dma_as, value + 16, tmp_xres * tmp_yres * > + (tmp_bpp >> 3)); Personal style nit: I prefer * 8 rather than >> 3, because it's more immediately obvious what you're computing, a trivial optimisation fo

Re: [Qemu-devel] [PATCH] hw/arm/bcm2836: Wire up CPU timer interrupts correctly

did get the > virt timer right, at least.) > > Reported-by: Antonio Huete Jiménez <tuxi...@quantumachine.net> > Signed-off-by: Peter Maydell <peter.mayd...@linaro.org> Reviewed-by: Andrew Baumann <andrew.baum...@microsoft.com> Thanks Peter! Andrew

Re: [Qemu-devel] Timer interrupts for -M raspi2

Hi Antonio, > From: Antonio Huete Jiménez [mailto:tuxi...@quantumachine.net] > Sent: Wednesday, 16 March 2016 3:40 PM > > Hi, > > I am experiencing what I think it's an issue with -M raspi2 and > interrupts in a baremetal application. > > According to this document >

Re: [Qemu-devel] Timer interrupts for -M raspi2

this ARM per-core > timers? Here's a starting point to some docs (just from a quick search): http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0438c/BGBBIJCB.html Cheers, Andrew > Andrew Baumann <andrew.baum...@microsoft.com> escribió: > > > Hi Antonio, &

Re: [Qemu-devel] Ubuntu 14.04 LTS Arm for Raspberry - QEMU Support

Hi Vincenzo, > From: Vincenzo Calabrò [mailto:muawi...@moosth.net] > Sent: Wednesday, 16 March 2016 12:39 PM [...] > 1. I'm using the "official" arm ubuntu 14.04 > (https://wiki.ubuntu.com/ARM/RaspberryPi) - you can download the image from > that link and follow the instruction to flash a SD

Re: [Qemu-devel] [PATCH v3 0/5] Raspberry Pi framebuffer, DMA and Windows support

> From: Peter Maydell [mailto:peter.mayd...@linaro.org] > Sent: Wednesday, 16 March 2016 9:54 AM > > On 8 March 2016 at 20:05, Andrew Baumann > <andrew.baum...@microsoft.com> wrote: > > This patch series adds support for the AUX (second UART), framebuffer > > and

Re: [Qemu-devel] [PATCH] Include setjmp.h in qemu/osdep.h (bug fix for w64)

> From: Stefan Weil [mailto:s...@weilnetz.de] > Sent: Friday, 11 March 2016 10:32 PM > > setjmp must be declared before sysemu/os-win32.h > because it is redefined there for 64 bit Windows. > > Signed-off-by: Stefan Weil <s...@weilnetz.de> > --- Tested-b

Re: [Qemu-devel] [PATCH v2 00/18] Multiple fixes & improvements to QIOChannel & Win32

Hi folks, > From: Paolo Bonzini [mailto:pbonz...@redhat.com] > Sent: Thursday, 10 March 2016 9:37 AM > > On 10/03/2016 18:26, Daniel P. Berrange wrote: > > This series started out as an attempt to fix the Win32 problems > > identified by Andrew Baumann > > > &

[Qemu-devel] [PATCH v3 4/5] bcm2835_property: implement framebuffer control/configuration properties

ze), and the ram-size property is no longer relevant here. Signed-off-by: Grégory ESTRADE <gregory.estr...@gmail.com> [AB: cleanup/refactoring for upstream submission] Signed-off-by: Andrew Baumann <andrew.baum...@microsoft.com> Reviewed-by: Peter Maydell <peter.mayd...@linaro.org>

[Qemu-devel] [PATCH v3 5/5] bcm2835_dma: add emulation of Raspberry Pi DMA controller

.com> [AB: implement 2D mode, cleanup/refactoring for upstream submission] Signed-off-by: Andrew Baumann <andrew.baum...@microsoft.com> Reviewed-by: Peter Maydell <peter.mayd...@linaro.org> --- Notes: v2: * avoid ldl_phys/stl_phys * compute address of channel structure

[Qemu-devel] [PATCH v3 3/5] bcm2835_fb: add framebuffer device for Raspberry Pi

gory.estr...@gmail.com> [AB: added Windows (BGR) support and cleanup/refactoring for upstream submission] Signed-off-by: Andrew Baumann <andrew.baum...@microsoft.com> Reviewed-by: Peter Maydell <peter.mayd...@linaro.org> --- Notes: v2: * avoid ldl_phys * move code to increase

[Qemu-devel] [PATCH v3 2/5] bcm2835_aux: add emulation of BCM2835 AUX (aka UART1) block

At present only the core UART functions (data path for tx/rx) are implemented, which is enough for UEFI to boot. The following features/registers are unimplemented: * Line/modem control * Scratch register * Extra control * Baudrate * SPI interfaces Signed-off-by: Andrew Baumann

[Qemu-devel] [PATCH v3 0/5] Raspberry Pi framebuffer, DMA and Windows support

ed Gregory as primary author of framebuffer and DMA emulation Cheers, Andrew Andrew Baumann (2): bcm2835_peripherals: enable sdhci pending-insert quirk for raspberry pi bcm2835_aux: add emulation of BCM2835 AUX (aka UART1) block Grégory ESTRADE (3): bcm2835_fb: add framebuffer device for Ra

[Qemu-devel] [PATCH v3 1/5] bcm2835_peripherals: enable sdhci pending-insert quirk for raspberry pi

Signed-off-by: Andrew Baumann <andrew.baum...@microsoft.com> Reviewed-by: Peter Maydell <peter.mayd...@linaro.org> --- hw/arm/bcm2835_peripherals.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/hw/arm/bcm2835_peripherals.c b/hw/arm/bcm2835_peripherals.c index 6d66fa0..6c

Re: [Qemu-devel] [PATCH v2 5/5] bcm2835_dma: add emulation of Raspberry Pi DMA controller

> From: Peter Maydell [mailto:peter.mayd...@linaro.org] > Sent: Monday, 7 March 2016 8:37 PM > > On 4 March 2016 at 01:24, Andrew Baumann > <andrew.baum...@microsoft.com> wrote: > > At present, all DMA transfers complete inline (so a looping descriptor > > queue

Re: [Qemu-devel] [PATCH] win32: fix socket_error() to work with Mingw64

iel P. Berrange <berra...@redhat.com> > --- > > NB, I've not actually done anything other that compile > test this so far. I'll be doing a runtime test once I > get my windows VM working with QEMU builds agian... If it helps, this works for me. Tested-by: Andrew Baumann <andrew.baum...@microsoft.com> (It doesn't fix the watch/accept problem, obviously, but at least we can listen now.) Thanks, Andrew

Re: [Qemu-devel] broken socket events on win32 qemu

> From: Daniel P. Berrange [mailto:berra...@redhat.com] > Sent: Monday, 7 March 2016 2:19 AM > > On Mon, Mar 07, 2016 at 07:23:12AM +0000, Andrew Baumann wrote: > > BTW, The same change introduces another problem on win32: server > sockets > > like the GDB exampl

[Qemu-devel] broken socket events on win32 qemu

Hi Daniel, This commit ("char: convert from GIOChannel to QIOChannel"): https://github.com/qemu/qemu/commit/9894dc0cdcc397ee5b26370bc53da6d360a363c2 ... appears to have broken socket events for character devices on Win32. For example, I can no longer connect to a GDB stub (started with: "-gdb

[Qemu-devel] [PATCH v2 5/5] bcm2835_dma: add emulation of Raspberry Pi DMA controller

At present, all DMA transfers complete inline (so a looping descriptor queue will lock up the device). We also do not model pause/abort, arbitrarion/priority, or debug features. Signed-off-by: Andrew Baumann <andrew.baum...@microsoft.com> --- Notes: v2: * avoid ldl_phys/st

[Qemu-devel] [PATCH v2 4/5] bcm2835_property: implement framebuffer control/configuration properties

Signed-off-by: Andrew Baumann <andrew.baum...@microsoft.com> --- Notes: v2: * avoid ldl/stl_phys * move code to increase default pi2 memory size from preceding patch here (it was incorrect without the property channel implementation changes) hw/arm/bcm2835_periphera

[Qemu-devel] [PATCH v2 2/5] bcm2835_aux: add emulation of BCM2835 AUX (aka UART1) block

At present only the core UART functions (data path for tx/rx) are implemented, which is enough for UEFI to boot. The following features/registers are unimplemented: * Line/modem control * Scratch register * Extra control * Baudrate * SPI interfaces Signed-off-by: Andrew Baumann

[Qemu-devel] [PATCH v2 0/5] Raspberry Pi framebuffer, DMA and Windows support

plete code is available at https://github.com/0xabu/qemu v2: * added DMA controller * revised per PMM's review feedback * rebased on top of the patch for fixing ldl_phys/stl_phys in raspi devices, presently in target-arm.next Cheers, Andrew Andrew Baumann (5): bcm2835_peripherals: en

[Qemu-devel] [PATCH v2 3/5] bcm2835_fb: add framebuffer device for Raspberry Pi

The framebuffer occupies the upper portion of memory (64MiB by default), but it can only be controlled/configured via a system mailbox or property channel (to be added by a subsequent patch). Signed-off-by: Andrew Baumann <andrew.baum...@microsoft.com> --- Notes: v2: * avoid ld

[Qemu-devel] [PATCH v2 1/5] bcm2835_peripherals: enable sdhci pending-insert quirk for raspberry pi

Reviewed-by: Peter Maydell <peter.mayd...@linaro.org> Signed-off-by: Andrew Baumann <andrew.baum...@microsoft.com> --- hw/arm/bcm2835_peripherals.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/hw/arm/bcm2835_peripherals.c b/hw/arm/bcm2835_peripherals.c index 6d66fa0..6c

Re: [Qemu-devel] [PATCH RFC] bcm2835_dma: add emulation of Raspberry Pi DMA controller

> From: Peter Maydell [mailto:peter.mayd...@linaro.org] > Sent: Thursday, 3 March 2016 8:22 AM > > On 3 March 2016 at 16:16, Gerd Hoffmann wrote: > > usb emulation has this problem too. > > > > uhci queue heads can go in circles. The emulation code keeps a linked > > list of

[Qemu-devel] [PATCH] bcm2835_mbox/property: replace ldl_phys/stl_phys with endian-specific accesses

PMM pointed out that ldl_phys and stl_phys are dependent on the CPU's endianness, whereas device model code should be independent of it. This changes the relevant Raspberry Pi devices to explicitly call the little-endian variants. Signed-off-by: Andrew Baumann <andrew.baum...@microsoft.

Re: [Qemu-devel] [PATCH 3/4] bcm2835_fb: add framebuffer device for Raspberry Pi

> From: Peter Maydell [mailto:peter.mayd...@linaro.org] > Sent: Tuesday, 1 March 2016 11:23 AM > > On 27 February 2016 at 00:16, Andrew Baumann > <andrew.baum...@microsoft.com> wrote: > > The framebuffer occupies the upper portion of memory (64MiB by > > defaul

Re: [Qemu-devel] [PATCH v1 00/17] ARM big-endian and setend support

> From: Peter Crosthwaite [mailto:crosthwaitepe...@gmail.com] > Sent: Tuesday, 1 March 2016 10:44 AM > > On Mon, Feb 29, 2016 at 9:27 PM, Stefan Weil wrote: > > Am 18.01.2016 um 08:12 schrieb Peter Crosthwaite: > >> Hi All, > >> > >> This patch series adds system-mode

Re: [Qemu-devel] [PATCH] Use special code for sigsetjmp only in cpu-exec.c

> From: Stefan Weil [mailto:s...@weilnetz.de] > Sent: Tuesday, 1 March 2016 5:16 AM > > Am 01.03.2016 um 13:22 schrieb Peter Maydell: > > On 1 March 2016 at 11:54, Stefan Weil wrote: > >> Am 01.03.2016 um 10:59 schrieb Peter Maydell: > >>> I don't understand this patch. Why

Re: [Qemu-devel] [PATCH] Use special code for sigsetjmp only in cpu-exec.c

; > QEMU for Windows currently gets the wrong definition for > sigsetjmp. It uses stack unwinding for longjmp which results > in a crash when it is called from generated code. > > Thanks to Andrew Baumann for his reminder that this patch was > still missing. Andrew, could you

[Qemu-devel] [PATCH RFC] bcm2835_dma: add emulation of Raspberry Pi DMA controller

Signed-off-by: Andrew Baumann <andrew.baum...@microsoft.com> --- This patch applies on top of the previous series for Windows and framebuffer support: https://lists.gnu.org/archive/html/qemu-devel/2016-02/msg06387.html After preparing that, I was disappointed to discover that Raspbian

  1   2   3   >