On Mon, Jan 22, 2018 at 12:41 PM, BALATON Zoltan wrote:
> Hello,
>
> On Thu, 18 Jan 2018, bzt bzt wrote:
>
>> Since you still haven't merged Alistair's patch, I decided to include it
>> in
>> my own.
>>
>
> Which patch exactly are you referr
Hi,
On Mon, Jan 22, 2018 at 1:12 PM, Peter Maydell
wrote:
> On 18 January 2018 at 21:39, bzt bzt wrote:
> > Dear All,
> >
> > Since you still haven't merged Alistair's patch, I decided to include it
> in
> > my own.
> > I've shrinked t
On Tue, Jan 23, 2018 at 12:22 PM, Peter Maydell
wrote:
> On 23 January 2018 at 11:13, bzt bzt wrote:
> > There's a huge misunderstanding here. I have a working qemu for about
> half a
> > year now, and I don't need it merged. It's not my goal to submit a patch
Dear Andrew,
A month passed, and the maintainers didn't gave a damn about raspi3 support
in qemu. Any ideas?
On Wed, Oct 25, 2017 at 10:52 AM, bzt bzt wrote:
> Hi Andrew!
>
> On Tue, Oct 24, 2017 at 6:44 PM, Andrew Baumann <
> andrew.baum...@microsoft.com> wrote:
s a new top level
> > thread -- if you send it as a reply/followup to the
> > first patch it's liable to not be noticed.
>
> Please also CC me on the new patch as I am not very reliable at monitoring
> qemu-devel.
>
Noted :-) Thank you for your help! I'm sure qemu users appreciate it very
much!
bzt
>
> Thanks!
> Andrew
>
On Tue, Nov 28, 2017 at 12:56 PM, Peter Maydell
wrote:
> On 28 November 2017 at 11:26, bzt bzt wrote:
> > (Although I have a question. I'm not sure what's the preferred
> > way to get MachineClass* object in bcm2836. Use a MachineState* cast on
> it's
> >
On Tue, Nov 28, 2017 at 6:54 PM, Andrew Baumann <
andrew.baum...@microsoft.com> wrote:
> > 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
> d
&error_abort);
}
diff --git a/hw/arm/raspi.c b/hw/arm/raspi.c
index cd5fa8c3dc..24a9243440 100644
--- a/hw/arm/raspi.c
+++ b/hw/arm/raspi.c
@@ -5,6 +5,8 @@
* Rasperry Pi 2 emulation Copyright (c) 2015, Microsoft
* Written by Andrew Baumann
*
+ * Raspberry
Dear All,
I've added support for "-M raspi3" to qemu. This is my first patch, I hope
it's okay. The github repo is here: https://github.com/bztsrc/qemu-raspi3
in case my patch does not work for some reason.
>From 1f10f957b57f336728097803bf8339a5577dd3c2 Mon Sep 17 00:00:
Okay, thanks! Sorry I haven't splitted.
Best wishes,
Zoli (bzt)
On Mon, Oct 23, 2017 at 11:34 AM, KONRAD Frederic <
frederic.kon...@adacore.com> wrote:
> Hi,
>
> Thanks for your patch.
>
> I'd split the patch as there are different piece of work here.
>
Hi Andrew!
On Mon, Oct 23, 2017 at 6:34 PM, Andrew Baumann <
andrew.baum...@microsoft.com> wrote:
> > From: Qemu-devel On Behalf Of bzt bzt
> > Sent: Sunday, 22 October 2017 06:21
> >
> > I've added support for "-M raspi3" to qemu. This is my first p
istic version without the BCM2837 class
(just a flag added to BCM2836State). Feel free to choose which one to
apply. :-)
Cheers,
Zoli (bzt)
>From a4d5c240d3b872a7ff1068de83d2080cd00e4517 Mon Sep 17 00:00:00 2001
From: bzt
Date: Tue, 24 Oct 2017 18:07:28 +0200
Subject: [PATCH] machine rasp
ch
https://lists.gnu.org/archive/html/qemu-devel/2017-10/msg04153.html When it
makes through, the bcm2836.c could simply use mc->default_cpu_type and
would be no need for anything else in BCM2836State, neither a version nor a
CPU model.
Okay, for now let's see what the maintainers prefer!
Cheers,
bzt
> Andrew
>
27;s OK. I'll modify that.
Thanks,
bzt
On 3/7/19, Peter Maydell wrote:
> On Thu, 7 Mar 2019 at 15:57, bzt wrote:
>>
>> Nope. I meant the second patch, sent on 4th Mar, which had all the
>> things fixed you listed in your review.
>>
>> But here's th
;hw/sysbus.h"
+#include "qemu/timer.h"
/* 4 mailboxes per core, for 16 total */
#define BCM2836_NCORES 4
@@ -39,6 +43,11 @@ typedef struct BCM2836ControlState {
bool gpu_irq, gpu_fiq;
uint8_t timerirqs[BCM2836_NCORES];
+/* local timer */
+QEMUTimer timer;
+
Hi,
That's great, thank you! Looking forward to see the patch in the master branch!
Cheers,
bzt
On 3/12/19, Peter Maydell wrote:
> On Sun, 10 Mar 2019 at 11:02, bzt wrote:
>>
>> Hi,
>>
>> Okay, as you wish. My code works either way and on real hardware as
&g
tdio
Connects the VM's UART1 (AUX) serial console to the host terminal
I think this is simple and good, please don't remove this option. If
your commit does not influence these cli args, I'm not against it.
bzt
tcode nor does it receive an entire boot partition with the -kernel
argument. Another reason to use AArch64 for raspi3 machine is if a
real board finds both kernel7.img and kernel8.img on the boot
partition, then it will load the AArch64 kernel.
Cheers,
bzt
On 9/3/19, Philippe Mathieu-Daudé wrote
thing is mostly for me, I'd like to reboot and shut down
the vm gracefully from the guest without the semihosting hack :-)
Thank you again, I'll get to work!
Best wishes,
bzt
On 2/27/19, Andrew Baumann wrote:
>> From: bzt
>> Sent: Wednesday, 27 February 2019 03:54
>&
+ * 64-bit ARM Local Timer Copyright (c) 2019. Zoltán Baldaszti
>> + * Added basic IRQ_TIMER interrupt support
>> + *
>> * This code is licensed under the GNU GPLv2 and later.
>> */
>>
>> @@ -12,6 +15,7 @@
>> #define BCM2836_CONTROL_H
>>
>> #include "hw/sysbus.h"
>> +#include "qemu/timer.h"
>>
>> /* 4 mailboxes per core, for 16 total */
>> #define BCM2836_NCORES 4
>> @@ -39,6 +43,12 @@ typedef struct BCM2836ControlState {
>> bool gpu_irq, gpu_fiq;
>> uint8_t timerirqs[BCM2836_NCORES];
>>
>> +/* local timer */
>> +uint8_t route_localtimer;
>> +uint32_t period;
>> +bool triggered;
>> +QEMUTimer *timer;
>
> Slightly nicer to just embed the QEMUTimer struct (and
> then initialize it with timer_init_ns() rather than using
> timer_new_ns(), which does 'allocate and init'.)
What do you mean by embed? Statically include the QEMUTimer struct?
That would require more memory even if a guest never turns the local
timer IRQ on. Is that acceptable? Otherwise OK!
>
>> +
>> /* interrupt source registers, post-routing (also input-derived;
>> visible) */
>> uint32_t irqsrc[BCM2836_NCORES];
>> uint32_t fiqsrc[BCM2836_NCORES];
>
> New fields in this struct require new entries in the
> vmstate_bcm2836_control struct so the data is migrated.
> In this case we don't care about maintaining migration
> compatibility between QEMU versions, so the easiest thing
> is to bump the .version_id field to 2, and use
> VMSTATE_*_V(..., 2) macros to mark the new fields as
> being only present in version 2.
>
> If you take my suggestion about using a single uint32_t
> local_timer_control and an embedded QEMUTimer struct,
> that works out at
>VMSTATE_TIMER_V(timer, BCM2836ControlState, 2),
>VMSTATE_UINT32_V(local_timer_control, BCM2836ControlState, 2),
>VMSTATE_UINT8_V(route_localtimer, BCM2836ControlState, 2),
OK!
>
> thanks
> -- PMM
>
Thanks for the review again, I'll modify the patch accordingly.
bzt
everything you asked for.
bzt
Sign-off-by: Zoltán Baldaszti
Subject: [PATCH] Added periodic IRQ support for bcm2836_control local timer
diff --git a/hw/intc/bcm2836_control.c b/hw/intc/bcm2836_control.c
index cfa5bc7365..2157099b31 100644
--- a/hw/intc/bcm2836_control.c
+++ b/hw/intc/bcm2836_co
aid, this patch adds only the periodic IRQ, and not a full timer
emulation.
Do you want any modifications on the patch? If so, what exactly? Let
me know and I'll update it.
Cheers,
bzt
On 3/5/19, Peter Maydell wrote:
> On Mon, 4 Mar 2019 at 19:27, bzt wrote:
>>
>> On 3/4/19,
ot;
/* 4 mailboxes per core, for 16 total */
#define BCM2836_NCORES 4
@@ -39,6 +43,11 @@ typedef struct BCM2836ControlState {
bool gpu_irq, gpu_fiq;
uint8_t timerirqs[BCM2836_NCORES];
+/* local timer */
+QEMUTimer timer;
+uint32_t local_timer_control;
+uint8_t route_localtimer;
Dear qemu developers,
Honestly SubmitAPatch is a bit complicated for me, so I'm hoping I've
done everything right. To be sure, you can find my patch here:
https://github.com/bztsrc/qemu-local-timer and diff against the latest
github repo here:
https://github.com/bztsrc/qemu-local-timer/blob/patche
YPE_BCM2835_POWER and
TYPE_BCM2835_ST drivers, which I know many hoppy OS developers lack
and would improve the raspi emulation experience remarkably. It would
be still a long way to boot a raspbian image, but still, a small step
towards that goal at least.
Thanks,
bzt
On 2/26/19, Peter Maydel
25 matches
Mail list logo
