The nios2-softmmu target requires libfdt to function properly (see
hw/nios2/boot.c).
Signed-off-by: Stephanos Ioannidis
---
configure | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure b/configure
index 233c671aaa..029adcf795 100755
--- a/configure
+++ b/configure
AM
To: Stephanos Ioannidis
Cc: Peter Maydell ; Alistair Francis
; open list:All patches CC here
; open list:ARM TCG CPUs
Subject: Re: [PATCH] hw/arm/stm32f405: Add preliminary flash interface
emulation support
On Sun, Mar 1, 2020 at 12:47 AM Stephanos Ioannidis wrote:
>
> The flash interf
DYIE
No, PLLSAIRDYF and PLLSAIRDYIE are for STM32F42xxx and STM32F43xxx. STM32F405
does not have these fields.
Stephanos
-----Original Message-
From: Alistair Francis
Sent: Friday, March 6, 2020 4:40 AM
To: Stephanos Ioannidis
Cc: Peter Maydell ; Alistair Francis
; open list:All patches
BIT_RANGE(a, b), ...)?
-Original Message-
From: Peter Maydell
Sent: Friday, March 6, 2020 4:30 AM
To: Alistair Francis
Cc: Stephanos Ioannidis ; Alistair Francis
; open list:All patches CC here
; open list:ARM TCG CPUs
Subject: Re: [PATCH] hw/arm/stm32f405: Add preliminary RCC emulati
e as possible and leave any optimisation up to the
compiler.
I will address these changes in the upcoming v2.
-Original Message-
From: Alistair Francis
Sent: Friday, March 6, 2020 4:17 AM
To: Stephanos Ioannidis
Cc: Peter Maydell ; Alistair Francis
; open list:All patches CC here
;
STM32Cube driver, which configures and validates the
FLASH_ACR register during system initialisation.
Signed-off-by: Stephanos Ioannidis
---
hw/arm/Kconfig | 1 +
hw/arm/stm32f405_soc.c | 15 +-
hw/misc/Kconfig | 3 +
hw/misc/Makefile.objs
guest. This problem is addressed by configuring the SysTick clock
scaling factor from the AHB clock frequency computed using the RCC
clock configurations.
Signed-off-by: Stephanos Ioannidis
---
hw/arm/Kconfig | 1 +
hw/arm/netduinoplus2.c | 1 +
hw/arm/stm32f405_soc.c
Hi Peter and Philip,
Thanks for your insight on this matter.
I am okay as long as this issue is going to be eventually fixed in one way or
another; the three-phase reset scheme you mentioned does sound like a more
manageable approach for this purpose; though, I still believe having the option
-aliased flash memory address
(0x800), which is the default configuration used by many toolchains.
Stephanos Ioannidis (2):
hw/core: Support device reset handler priority
hw/arm/armv7m: Downgrade CPU reset handler priority
hw/arm/armv7m.c| 3 ++-
hw/core/reset.c| 32
0.
Signed-off-by: Stephanos Ioannidis
---
hw/arm/armv7m.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/hw/arm/armv7m.c b/hw/arm/armv7m.c
index 7531b97ccd..8b7c4b12a6 100644
--- a/hw/arm/armv7m.c
+++ b/hw/arm/armv7m.c
@@ -352,7 +352,8 @@ void armv7m_load_kernel(ARMCPU
struct and
introduces the `qemu_register_reset_with_priority` function that
implements descending-order insertion into the reset handler list based
on the priority value, in order to allow the reset handler invocation
order to be specified by the caller.
Signed-off-by: Stephanos Ioannidis
---
hw
0.
Signed-off-by: Stephanos Ioannidis
---
hw/arm/armv7m.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/hw/arm/armv7m.c b/hw/arm/armv7m.c
index 7531b97ccd..8b7c4b12a6 100644
--- a/hw/arm/armv7m.c
+++ b/hw/arm/armv7m.c
@@ -352,7 +352,8 @@ void armv7m_load_kernel(ARMCPU
struct and
introduces the `qemu_register_reset_with_priority` function that
implements descending-order insertion into the reset handler list based
on the priority value, in order to allow the reset handler invocation
order to be specified by the caller.
Signed-off-by: Stephanos Ioannidis
---
hw
13 matches
Mail list logo
