* [Bug 1906905] [NEW] qemu-system-sparc stucked while booting using ss20_v2.25_rom
@ 2020-12-05 4:01 yapkv
2020-12-05 6:37 ` [Bug 1906905] " yapkv
` (2 more replies)
0 siblings, 3 replies; 11+ messages in thread
From: yapkv @ 2020-12-05 4:01 UTC (permalink / raw)
To: qemu-devel
Public bug reported:
I cannot boot up OBP using the current (5.1) version of qemu with
ss20_v2.25_rom. It just stuck at "Power-ON reset" and hanged. However
using the previous version from 2015 I can successfully both up the OBP.
qemu-system-sparc -M SS-20 -m 256 -bios ss20_v2.25.rom -nographic
Power-ON Reset
(*hang)
regards
Yap KV
** Affects: qemu
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1906905
Title:
qemu-system-sparc stucked while booting using ss20_v2.25_rom
Status in QEMU:
New
Bug description:
I cannot boot up OBP using the current (5.1) version of qemu with
ss20_v2.25_rom. It just stuck at "Power-ON reset" and hanged. However
using the previous version from 2015 I can successfully both up the
OBP.
qemu-system-sparc -M SS-20 -m 256 -bios ss20_v2.25.rom -nographic
Power-ON Reset
(*hang)
regards
Yap KV
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1906905/+subscriptions
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug 1906905] Re: qemu-system-sparc stucked while booting using ss20_v2.25_rom
2020-12-05 4:01 [Bug 1906905] [NEW] qemu-system-sparc stucked while booting using ss20_v2.25_rom yapkv
@ 2020-12-05 6:37 ` yapkv
2020-12-05 15:09 ` [PATCH] hw/timer/slavio_timer: Allow 64-bit accesses Philippe Mathieu-Daudé
2021-04-30 8:34 ` [Bug 1906905] Re: qemu-system-sparc stucked while booting using ss20_v2.25_rom Thomas Huth
2 siblings, 0 replies; 11+ messages in thread
From: yapkv @ 2020-12-05 6:37 UTC (permalink / raw)
To: qemu-devel
I have just compiled a few version from source code:
4.1.1 worked: able to boot up with -bios ss20_v2.25.rom
5.0.0 worked: able to boot up with -bios ss20_v2.25.rom
5.1.0 not working. Stuck after "Power-On Reset"
SS5.bin worked for 5.1.0
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1906905
Title:
qemu-system-sparc stucked while booting using ss20_v2.25_rom
Status in QEMU:
New
Bug description:
I cannot boot up OBP using the current (5.1) version of qemu with
ss20_v2.25_rom. It just stuck at "Power-ON reset" and hanged. However
using the previous version from 2015 I can successfully both up the
OBP.
qemu-system-sparc -M SS-20 -m 256 -bios ss20_v2.25.rom -nographic
Power-ON Reset
(*hang)
regards
Yap KV
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1906905/+subscriptions
^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH] hw/timer/slavio_timer: Allow 64-bit accesses
@ 2020-12-05 15:09 ` Philippe Mathieu-Daudé
2020-12-05 15:09 ` [Bug 1906905] Re: qemu-system-sparc stucked while booting using ss20_v2.25_rom Philippe Mathieu-Daudé
` (2 more replies)
0 siblings, 3 replies; 11+ messages in thread
From: Philippe Mathieu-Daudé @ 2020-12-05 15:09 UTC (permalink / raw)
To: qemu-devel
Cc: Benoit Canet, Michael S . Tsirkin, Mark Cave-Ayland,
Philippe Mathieu-Daudé,
Yap KV, 1906905, Artyom Tarasenko
Per the "NCR89C105 Chip Specification" referenced in the header:
Chip-level Address Map
------------------------------------------------------------------
| 1D0 0000 -> | Counter/Timers | W,D |
| 1DF FFFF | | |
...
The address map indicated the allowed accesses at each address.
[...] W indicates a word access, and D indicates a double-word
access.
The SLAVIO timer controller is implemented expecting 32-bit accesses.
Commit a3d12d073e1 restricted the memory accesses to 32-bit, while
the device allows 64-bit accesses.
This was not an issue until commit 5d971f9e67 which reverted
("memory: accept mismatching sizes in memory_region_access_valid").
Fix by renaming .valid MemoryRegionOps as .impl, and add the valid
access range (W -> 4, D -> 8).
Since commit 21786c7e598 ("memory: Log invalid memory accesses")
this class of bug can be quickly debugged displaying 'guest_errors'
accesses, as:
$ qemu-system-sparc -M SS-20 -m 256 -bios ss20_v2.25_rom -serial stdio -d guest_errors
Power-ON Reset
Invalid access at addr 0x0, size 8, region 'timer-1', reason: invalid size (min:4 max:4)
$ qemu-system-sparc -M SS-20 -m 256 -bios ss20_v2.25_rom -monitor stdio -S
(qemu) info mtree
address-space: memory
0000000000000000-ffffffffffffffff (prio 0, i/o): system
...
0000000ff1300000-0000000ff130000f (prio 0, i/o): timer-1
^^^^^^^^^ ^^^^^^^
\ memory region base address and name /
(qemu) info qtree
bus: main-system-bus
dev: slavio_timer, id "" <-- device type name
gpio-out "sysbus-irq" 17
num_cpus = 1 (0x1)
mmio 0000000ff1310000/0000000000000014
mmio 0000000ff1300000/0000000000000010 <--- base address
mmio 0000000ff1301000/0000000000000010
mmio 0000000ff1302000/0000000000000010
...
Reported-by: Yap KV <yapkv@yahoo.com>
Buglink: https://bugs.launchpad.net/bugs/1906905
Fixes: a3d12d073e1 ("slavio_timer: convert to memory API")
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
---
Cc: Benoit Canet <benoit.canet@gmail.com>
Cc: <1906905@bugs.launchpad.net>
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
---
hw/timer/slavio_timer.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/hw/timer/slavio_timer.c b/hw/timer/slavio_timer.c
index 5b2d20cb6a5..03e33fc5926 100644
--- a/hw/timer/slavio_timer.c
+++ b/hw/timer/slavio_timer.c
@@ -331,6 +331,10 @@ static const MemoryRegionOps slavio_timer_mem_ops = {
.write = slavio_timer_mem_writel,
.endianness = DEVICE_NATIVE_ENDIAN,
.valid = {
+ .min_access_size = 4,
+ .max_access_size = 8,
+ },
+ .impl = {
.min_access_size = 4,
.max_access_size = 4,
},
--
2.26.2
^ permalink raw reply related [flat|nested] 11+ messages in thread
* [Bug 1906905] Re: qemu-system-sparc stucked while booting using ss20_v2.25_rom
2020-12-05 15:09 ` [PATCH] hw/timer/slavio_timer: Allow 64-bit accesses Philippe Mathieu-Daudé
@ 2020-12-05 15:09 ` Philippe Mathieu-Daudé
2020-12-08 15:13 ` [Bug 1906905] Re: [PATCH] hw/timer/slavio_timer: Allow 64-bit accesses Mark Cave-Ayland
2021-01-05 11:06 ` Philippe Mathieu-Daudé
2 siblings, 0 replies; 11+ messages in thread
From: Philippe Mathieu-Daudé @ 2020-12-05 15:09 UTC (permalink / raw)
To: qemu-devel
Per the "NCR89C105 Chip Specification" referenced in the header:
Chip-level Address Map
------------------------------------------------------------------
| 1D0 0000 -> | Counter/Timers | W,D |
| 1DF FFFF | | |
...
The address map indicated the allowed accesses at each address.
[...] W indicates a word access, and D indicates a double-word
access.
The SLAVIO timer controller is implemented expecting 32-bit accesses.
Commit a3d12d073e1 restricted the memory accesses to 32-bit, while
the device allows 64-bit accesses.
This was not an issue until commit 5d971f9e67 which reverted
("memory: accept mismatching sizes in memory_region_access_valid").
Fix by renaming .valid MemoryRegionOps as .impl, and add the valid
access range (W -> 4, D -> 8).
Since commit 21786c7e598 ("memory: Log invalid memory accesses")
this class of bug can be quickly debugged displaying 'guest_errors'
accesses, as:
$ qemu-system-sparc -M SS-20 -m 256 -bios ss20_v2.25_rom -serial stdio
-d guest_errors
Power-ON Reset
Invalid access at addr 0x0, size 8, region 'timer-1', reason: invalid size (min:4 max:4)
$ qemu-system-sparc -M SS-20 -m 256 -bios ss20_v2.25_rom -monitor stdio -S
(qemu) info mtree
address-space: memory
0000000000000000-ffffffffffffffff (prio 0, i/o): system
...
0000000ff1300000-0000000ff130000f (prio 0, i/o): timer-1
^^^^^^^^^ ^^^^^^^
\ memory region base address and name /
(qemu) info qtree
bus: main-system-bus
dev: slavio_timer, id "" <-- device type name
gpio-out "sysbus-irq" 17
num_cpus = 1 (0x1)
mmio 0000000ff1310000/0000000000000014
mmio 0000000ff1300000/0000000000000010 <--- base address
mmio 0000000ff1301000/0000000000000010
mmio 0000000ff1302000/0000000000000010
...
Reported-by: Yap KV <yapkv@yahoo.com>
Buglink: https://bugs.launchpad.net/bugs/1906905
Fixes: a3d12d073e1 ("slavio_timer: convert to memory API")
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
---
Cc: Benoit Canet <benoit.canet@gmail.com>
Cc: <1906905@bugs.launchpad.net>
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
---
hw/timer/slavio_timer.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/hw/timer/slavio_timer.c b/hw/timer/slavio_timer.c
index 5b2d20cb6a5..03e33fc5926 100644
--- a/hw/timer/slavio_timer.c
+++ b/hw/timer/slavio_timer.c
@@ -331,6 +331,10 @@ static const MemoryRegionOps slavio_timer_mem_ops = {
.write = slavio_timer_mem_writel,
.endianness = DEVICE_NATIVE_ENDIAN,
.valid = {
+ .min_access_size = 4,
+ .max_access_size = 8,
+ },
+ .impl = {
.min_access_size = 4,
.max_access_size = 4,
},
--
2.26.2
** Changed in: qemu
Status: New => Confirmed
** Tags added: sparc
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1906905
Title:
qemu-system-sparc stucked while booting using ss20_v2.25_rom
Status in QEMU:
Confirmed
Bug description:
I cannot boot up OBP using the current (5.1) version of qemu with
ss20_v2.25_rom. It just stuck at "Power-ON reset" and hanged. However
using the previous version from 2015 I can successfully both up the
OBP.
qemu-system-sparc -M SS-20 -m 256 -bios ss20_v2.25.rom -nographic
Power-ON Reset
(*hang)
regards
Yap KV
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1906905/+subscriptions
^ permalink raw reply related [flat|nested] 11+ messages in thread
* [Bug 1906905] Re: [PATCH] hw/timer/slavio_timer: Allow 64-bit accesses
2020-12-05 15:09 ` [PATCH] hw/timer/slavio_timer: Allow 64-bit accesses Philippe Mathieu-Daudé
2020-12-05 15:09 ` [Bug 1906905] Re: qemu-system-sparc stucked while booting using ss20_v2.25_rom Philippe Mathieu-Daudé
@ 2020-12-08 15:13 ` Mark Cave-Ayland
2020-12-08 15:13 ` Mark Cave-Ayland
2021-01-05 11:06 ` Philippe Mathieu-Daudé
2 siblings, 1 reply; 11+ messages in thread
From: Mark Cave-Ayland @ 2020-12-08 15:13 UTC (permalink / raw)
To: qemu-devel
On 05/12/2020 15:09, Philippe Mathieu-Daudé wrote:
> Per the "NCR89C105 Chip Specification" referenced in the header:
>
> Chip-level Address Map
>
> ------------------------------------------------------------------
> | 1D0 0000 -> | Counter/Timers | W,D |
> | 1DF FFFF | | |
> ...
>
> The address map indicated the allowed accesses at each address.
> [...] W indicates a word access, and D indicates a double-word
> access.
>
> The SLAVIO timer controller is implemented expecting 32-bit accesses.
> Commit a3d12d073e1 restricted the memory accesses to 32-bit, while
> the device allows 64-bit accesses.
>
> This was not an issue until commit 5d971f9e67 which reverted
> ("memory: accept mismatching sizes in memory_region_access_valid").
>
> Fix by renaming .valid MemoryRegionOps as .impl, and add the valid
> access range (W -> 4, D -> 8).
>
> Since commit 21786c7e598 ("memory: Log invalid memory accesses")
> this class of bug can be quickly debugged displaying 'guest_errors'
> accesses, as:
>
> $ qemu-system-sparc -M SS-20 -m 256 -bios ss20_v2.25_rom -serial stdio -d guest_errors
>
> Power-ON Reset
> Invalid access at addr 0x0, size 8, region 'timer-1', reason: invalid size (min:4 max:4)
>
> $ qemu-system-sparc -M SS-20 -m 256 -bios ss20_v2.25_rom -monitor stdio -S
> (qemu) info mtree
> address-space: memory
> 0000000000000000-ffffffffffffffff (prio 0, i/o): system
> ...
> 0000000ff1300000-0000000ff130000f (prio 0, i/o): timer-1
> ^^^^^^^^^ ^^^^^^^
> \ memory region base address and name /
>
> (qemu) info qtree
> bus: main-system-bus
> dev: slavio_timer, id "" <-- device type name
> gpio-out "sysbus-irq" 17
> num_cpus = 1 (0x1)
> mmio 0000000ff1310000/0000000000000014
> mmio 0000000ff1300000/0000000000000010 <--- base address
> mmio 0000000ff1301000/0000000000000010
> mmio 0000000ff1302000/0000000000000010
> ...
>
> Reported-by: Yap KV <yapkv@yahoo.com>
> Buglink: https://bugs.launchpad.net/bugs/1906905
> Fixes: a3d12d073e1 ("slavio_timer: convert to memory API")
> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
> ---
> Cc: Benoit Canet <benoit.canet@gmail.com>
> Cc: <1906905@bugs.launchpad.net>
> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
> ---
> hw/timer/slavio_timer.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/hw/timer/slavio_timer.c b/hw/timer/slavio_timer.c
> index 5b2d20cb6a5..03e33fc5926 100644
> --- a/hw/timer/slavio_timer.c
> +++ b/hw/timer/slavio_timer.c
> @@ -331,6 +331,10 @@ static const MemoryRegionOps slavio_timer_mem_ops = {
> .write = slavio_timer_mem_writel,
> .endianness = DEVICE_NATIVE_ENDIAN,
> .valid = {
> + .min_access_size = 4,
> + .max_access_size = 8,
> + },
> + .impl = {
> .min_access_size = 4,
> .max_access_size = 4,
> },
I don't really use the proprietary Sun ROMs here, but the fix looks good
to me:
Reviewed-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
It's probably also worth a CC to qemu-stable to try and also get this into 5.1.1 to
accompany the related TCX issues.
ATB,
Mark.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1906905
Title:
qemu-system-sparc stucked while booting using ss20_v2.25_rom
Status in QEMU:
Confirmed
Bug description:
I cannot boot up OBP using the current (5.1) version of qemu with
ss20_v2.25_rom. It just stuck at "Power-ON reset" and hanged. However
using the previous version from 2015 I can successfully both up the
OBP.
qemu-system-sparc -M SS-20 -m 256 -bios ss20_v2.25.rom -nographic
Power-ON Reset
(*hang)
regards
Yap KV
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1906905/+subscriptions
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] hw/timer/slavio_timer: Allow 64-bit accesses
2020-12-08 15:13 ` [Bug 1906905] Re: [PATCH] hw/timer/slavio_timer: Allow 64-bit accesses Mark Cave-Ayland
@ 2020-12-08 15:13 ` Mark Cave-Ayland
0 siblings, 0 replies; 11+ messages in thread
From: Mark Cave-Ayland @ 2020-12-08 15:13 UTC (permalink / raw)
To: Philippe Mathieu-Daudé, qemu-devel
Cc: Artyom Tarasenko, Benoit Canet, Yap KV, 1906905, Michael S . Tsirkin
On 05/12/2020 15:09, Philippe Mathieu-Daudé wrote:
> Per the "NCR89C105 Chip Specification" referenced in the header:
>
> Chip-level Address Map
>
> ------------------------------------------------------------------
> | 1D0 0000 -> | Counter/Timers | W,D |
> | 1DF FFFF | | |
> ...
>
> The address map indicated the allowed accesses at each address.
> [...] W indicates a word access, and D indicates a double-word
> access.
>
> The SLAVIO timer controller is implemented expecting 32-bit accesses.
> Commit a3d12d073e1 restricted the memory accesses to 32-bit, while
> the device allows 64-bit accesses.
>
> This was not an issue until commit 5d971f9e67 which reverted
> ("memory: accept mismatching sizes in memory_region_access_valid").
>
> Fix by renaming .valid MemoryRegionOps as .impl, and add the valid
> access range (W -> 4, D -> 8).
>
> Since commit 21786c7e598 ("memory: Log invalid memory accesses")
> this class of bug can be quickly debugged displaying 'guest_errors'
> accesses, as:
>
> $ qemu-system-sparc -M SS-20 -m 256 -bios ss20_v2.25_rom -serial stdio -d guest_errors
>
> Power-ON Reset
> Invalid access at addr 0x0, size 8, region 'timer-1', reason: invalid size (min:4 max:4)
>
> $ qemu-system-sparc -M SS-20 -m 256 -bios ss20_v2.25_rom -monitor stdio -S
> (qemu) info mtree
> address-space: memory
> 0000000000000000-ffffffffffffffff (prio 0, i/o): system
> ...
> 0000000ff1300000-0000000ff130000f (prio 0, i/o): timer-1
> ^^^^^^^^^ ^^^^^^^
> \ memory region base address and name /
>
> (qemu) info qtree
> bus: main-system-bus
> dev: slavio_timer, id "" <-- device type name
> gpio-out "sysbus-irq" 17
> num_cpus = 1 (0x1)
> mmio 0000000ff1310000/0000000000000014
> mmio 0000000ff1300000/0000000000000010 <--- base address
> mmio 0000000ff1301000/0000000000000010
> mmio 0000000ff1302000/0000000000000010
> ...
>
> Reported-by: Yap KV <yapkv@yahoo.com>
> Buglink: https://bugs.launchpad.net/bugs/1906905
> Fixes: a3d12d073e1 ("slavio_timer: convert to memory API")
> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
> ---
> Cc: Benoit Canet <benoit.canet@gmail.com>
> Cc: <1906905@bugs.launchpad.net>
> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
> ---
> hw/timer/slavio_timer.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/hw/timer/slavio_timer.c b/hw/timer/slavio_timer.c
> index 5b2d20cb6a5..03e33fc5926 100644
> --- a/hw/timer/slavio_timer.c
> +++ b/hw/timer/slavio_timer.c
> @@ -331,6 +331,10 @@ static const MemoryRegionOps slavio_timer_mem_ops = {
> .write = slavio_timer_mem_writel,
> .endianness = DEVICE_NATIVE_ENDIAN,
> .valid = {
> + .min_access_size = 4,
> + .max_access_size = 8,
> + },
> + .impl = {
> .min_access_size = 4,
> .max_access_size = 4,
> },
I don't really use the proprietary Sun ROMs here, but the fix looks good to me:
Reviewed-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
It's probably also worth a CC to qemu-stable to try and also get this into 5.1.1 to
accompany the related TCX issues.
ATB,
Mark.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] hw/timer/slavio_timer: Allow 64-bit accesses
2020-12-05 15:09 ` [PATCH] hw/timer/slavio_timer: Allow 64-bit accesses Philippe Mathieu-Daudé
2020-12-05 15:09 ` [Bug 1906905] Re: qemu-system-sparc stucked while booting using ss20_v2.25_rom Philippe Mathieu-Daudé
2020-12-08 15:13 ` [Bug 1906905] Re: [PATCH] hw/timer/slavio_timer: Allow 64-bit accesses Mark Cave-Ayland
@ 2021-01-05 11:06 ` Philippe Mathieu-Daudé
2021-01-05 11:06 ` [Bug 1906905] " Philippe Mathieu-Daudé
2021-01-05 13:02 ` Mark Cave-Ayland
2 siblings, 2 replies; 11+ messages in thread
From: Philippe Mathieu-Daudé @ 2021-01-05 11:06 UTC (permalink / raw)
To: qemu-devel
Cc: Benoit Canet, Michael S . Tsirkin, Mark Cave-Ayland, Yap KV,
1906905, Artyom Tarasenko
ping?
On 12/5/20 4:09 PM, Philippe Mathieu-Daudé wrote:
> Per the "NCR89C105 Chip Specification" referenced in the header:
>
> Chip-level Address Map
>
> ------------------------------------------------------------------
> | 1D0 0000 -> | Counter/Timers | W,D |
> | 1DF FFFF | | |
> ...
>
> The address map indicated the allowed accesses at each address.
> [...] W indicates a word access, and D indicates a double-word
> access.
>
> The SLAVIO timer controller is implemented expecting 32-bit accesses.
> Commit a3d12d073e1 restricted the memory accesses to 32-bit, while
> the device allows 64-bit accesses.
>
> This was not an issue until commit 5d971f9e67 which reverted
> ("memory: accept mismatching sizes in memory_region_access_valid").
>
> Fix by renaming .valid MemoryRegionOps as .impl, and add the valid
> access range (W -> 4, D -> 8).
>
> Since commit 21786c7e598 ("memory: Log invalid memory accesses")
> this class of bug can be quickly debugged displaying 'guest_errors'
> accesses, as:
>
> $ qemu-system-sparc -M SS-20 -m 256 -bios ss20_v2.25_rom -serial stdio -d guest_errors
>
> Power-ON Reset
> Invalid access at addr 0x0, size 8, region 'timer-1', reason: invalid size (min:4 max:4)
>
> $ qemu-system-sparc -M SS-20 -m 256 -bios ss20_v2.25_rom -monitor stdio -S
> (qemu) info mtree
> address-space: memory
> 0000000000000000-ffffffffffffffff (prio 0, i/o): system
> ...
> 0000000ff1300000-0000000ff130000f (prio 0, i/o): timer-1
> ^^^^^^^^^ ^^^^^^^
> \ memory region base address and name /
>
> (qemu) info qtree
> bus: main-system-bus
> dev: slavio_timer, id "" <-- device type name
> gpio-out "sysbus-irq" 17
> num_cpus = 1 (0x1)
> mmio 0000000ff1310000/0000000000000014
> mmio 0000000ff1300000/0000000000000010 <--- base address
> mmio 0000000ff1301000/0000000000000010
> mmio 0000000ff1302000/0000000000000010
> ...
>
> Reported-by: Yap KV <yapkv@yahoo.com>
> Buglink: https://bugs.launchpad.net/bugs/1906905
> Fixes: a3d12d073e1 ("slavio_timer: convert to memory API")
> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
> ---
> Cc: Benoit Canet <benoit.canet@gmail.com>
> Cc: <1906905@bugs.launchpad.net>
> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
> ---
> hw/timer/slavio_timer.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/hw/timer/slavio_timer.c b/hw/timer/slavio_timer.c
> index 5b2d20cb6a5..03e33fc5926 100644
> --- a/hw/timer/slavio_timer.c
> +++ b/hw/timer/slavio_timer.c
> @@ -331,6 +331,10 @@ static const MemoryRegionOps slavio_timer_mem_ops = {
> .write = slavio_timer_mem_writel,
> .endianness = DEVICE_NATIVE_ENDIAN,
> .valid = {
> + .min_access_size = 4,
> + .max_access_size = 8,
> + },
> + .impl = {
> .min_access_size = 4,
> .max_access_size = 4,
> },
>
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug 1906905] Re: [PATCH] hw/timer/slavio_timer: Allow 64-bit accesses
2021-01-05 11:06 ` Philippe Mathieu-Daudé
@ 2021-01-05 11:06 ` Philippe Mathieu-Daudé
2021-01-05 13:02 ` Mark Cave-Ayland
1 sibling, 0 replies; 11+ messages in thread
From: Philippe Mathieu-Daudé @ 2021-01-05 11:06 UTC (permalink / raw)
To: qemu-devel
ping?
On 12/5/20 4:09 PM, Philippe Mathieu-Daudé wrote:
> Per the "NCR89C105 Chip Specification" referenced in the header:
>
> Chip-level Address Map
>
> ------------------------------------------------------------------
> | 1D0 0000 -> | Counter/Timers | W,D |
> | 1DF FFFF | | |
> ...
>
> The address map indicated the allowed accesses at each address.
> [...] W indicates a word access, and D indicates a double-word
> access.
>
> The SLAVIO timer controller is implemented expecting 32-bit accesses.
> Commit a3d12d073e1 restricted the memory accesses to 32-bit, while
> the device allows 64-bit accesses.
>
> This was not an issue until commit 5d971f9e67 which reverted
> ("memory: accept mismatching sizes in memory_region_access_valid").
>
> Fix by renaming .valid MemoryRegionOps as .impl, and add the valid
> access range (W -> 4, D -> 8).
>
> Since commit 21786c7e598 ("memory: Log invalid memory accesses")
> this class of bug can be quickly debugged displaying 'guest_errors'
> accesses, as:
>
> $ qemu-system-sparc -M SS-20 -m 256 -bios ss20_v2.25_rom -serial stdio -d guest_errors
>
> Power-ON Reset
> Invalid access at addr 0x0, size 8, region 'timer-1', reason: invalid size (min:4 max:4)
>
> $ qemu-system-sparc -M SS-20 -m 256 -bios ss20_v2.25_rom -monitor stdio -S
> (qemu) info mtree
> address-space: memory
> 0000000000000000-ffffffffffffffff (prio 0, i/o): system
> ...
> 0000000ff1300000-0000000ff130000f (prio 0, i/o): timer-1
> ^^^^^^^^^ ^^^^^^^
> \ memory region base address and name /
>
> (qemu) info qtree
> bus: main-system-bus
> dev: slavio_timer, id "" <-- device type name
> gpio-out "sysbus-irq" 17
> num_cpus = 1 (0x1)
> mmio 0000000ff1310000/0000000000000014
> mmio 0000000ff1300000/0000000000000010 <--- base address
> mmio 0000000ff1301000/0000000000000010
> mmio 0000000ff1302000/0000000000000010
> ...
>
> Reported-by: Yap KV <yapkv@yahoo.com>
> Buglink: https://bugs.launchpad.net/bugs/1906905
> Fixes: a3d12d073e1 ("slavio_timer: convert to memory API")
> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
> ---
> Cc: Benoit Canet <benoit.canet@gmail.com>
> Cc: <1906905@bugs.launchpad.net>
> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
> ---
> hw/timer/slavio_timer.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/hw/timer/slavio_timer.c b/hw/timer/slavio_timer.c
> index 5b2d20cb6a5..03e33fc5926 100644
> --- a/hw/timer/slavio_timer.c
> +++ b/hw/timer/slavio_timer.c
> @@ -331,6 +331,10 @@ static const MemoryRegionOps slavio_timer_mem_ops = {
> .write = slavio_timer_mem_writel,
> .endianness = DEVICE_NATIVE_ENDIAN,
> .valid = {
> + .min_access_size = 4,
> + .max_access_size = 8,
> + },
> + .impl = {
> .min_access_size = 4,
> .max_access_size = 4,
> },
>
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1906905
Title:
qemu-system-sparc stucked while booting using ss20_v2.25_rom
Status in QEMU:
Confirmed
Bug description:
I cannot boot up OBP using the current (5.1) version of qemu with
ss20_v2.25_rom. It just stuck at "Power-ON reset" and hanged. However
using the previous version from 2015 I can successfully both up the
OBP.
qemu-system-sparc -M SS-20 -m 256 -bios ss20_v2.25.rom -nographic
Power-ON Reset
(*hang)
regards
Yap KV
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1906905/+subscriptions
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Bug 1906905] Re: [PATCH] hw/timer/slavio_timer: Allow 64-bit accesses
2021-01-05 11:06 ` Philippe Mathieu-Daudé
2021-01-05 11:06 ` [Bug 1906905] " Philippe Mathieu-Daudé
@ 2021-01-05 13:02 ` Mark Cave-Ayland
2021-01-05 13:02 ` Mark Cave-Ayland
1 sibling, 1 reply; 11+ messages in thread
From: Mark Cave-Ayland @ 2021-01-05 13:02 UTC (permalink / raw)
To: Bug 1906905, qemu-devel
On 05/01/2021 11:06, Philippe Mathieu-Daudé wrote:
> ping?
>
> On 12/5/20 4:09 PM, Philippe Mathieu-Daudé wrote:
>> Per the "NCR89C105 Chip Specification" referenced in the header:
>>
>> Chip-level Address Map
>>
>> ------------------------------------------------------------------
>> | 1D0 0000 -> | Counter/Timers | W,D |
>> | 1DF FFFF | | |
>> ...
>>
>> The address map indicated the allowed accesses at each address.
>> [...] W indicates a word access, and D indicates a double-word
>> access.
>>
>> The SLAVIO timer controller is implemented expecting 32-bit accesses.
>> Commit a3d12d073e1 restricted the memory accesses to 32-bit, while
>> the device allows 64-bit accesses.
>>
>> This was not an issue until commit 5d971f9e67 which reverted
>> ("memory: accept mismatching sizes in memory_region_access_valid").
>>
>> Fix by renaming .valid MemoryRegionOps as .impl, and add the valid
>> access range (W -> 4, D -> 8).
>>
>> Since commit 21786c7e598 ("memory: Log invalid memory accesses")
>> this class of bug can be quickly debugged displaying 'guest_errors'
>> accesses, as:
>>
>> $ qemu-system-sparc -M SS-20 -m 256 -bios ss20_v2.25_rom -serial stdio -d guest_errors
>>
>> Power-ON Reset
>> Invalid access at addr 0x0, size 8, region 'timer-1', reason: invalid size (min:4 max:4)
>>
>> $ qemu-system-sparc -M SS-20 -m 256 -bios ss20_v2.25_rom -monitor stdio -S
>> (qemu) info mtree
>> address-space: memory
>> 0000000000000000-ffffffffffffffff (prio 0, i/o): system
>> ...
>> 0000000ff1300000-0000000ff130000f (prio 0, i/o): timer-1
>> ^^^^^^^^^ ^^^^^^^
>> \ memory region base address and name /
>>
>> (qemu) info qtree
>> bus: main-system-bus
>> dev: slavio_timer, id "" <-- device type name
>> gpio-out "sysbus-irq" 17
>> num_cpus = 1 (0x1)
>> mmio 0000000ff1310000/0000000000000014
>> mmio 0000000ff1300000/0000000000000010 <--- base address
>> mmio 0000000ff1301000/0000000000000010
>> mmio 0000000ff1302000/0000000000000010
>> ...
>>
>> Reported-by: Yap KV <yapkv@yahoo.com>
>> Buglink: https://bugs.launchpad.net/bugs/1906905
>> Fixes: a3d12d073e1 ("slavio_timer: convert to memory API")
>> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
>> ---
>> Cc: Benoit Canet <benoit.canet@gmail.com>
>> Cc: <1906905@bugs.launchpad.net>
>> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
>> ---
>> hw/timer/slavio_timer.c | 4 ++++
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/hw/timer/slavio_timer.c b/hw/timer/slavio_timer.c
>> index 5b2d20cb6a5..03e33fc5926 100644
>> --- a/hw/timer/slavio_timer.c
>> +++ b/hw/timer/slavio_timer.c
>> @@ -331,6 +331,10 @@ static const MemoryRegionOps slavio_timer_mem_ops = {
>> .write = slavio_timer_mem_writel,
>> .endianness = DEVICE_NATIVE_ENDIAN,
>> .valid = {
>> + .min_access_size = 4,
>> + .max_access_size = 8,
>> + },
>> + .impl = {
>> .min_access_size = 4,
>> .max_access_size = 4,
>> },
Looks like I did queue this to my local qemu-sparc branch, but was waiting to see if
there was feedback on the other outstanding SPARC patches before sending a PR. The
patches are all fairly minor, however I would prefer an Ack for the outstanding LEON
patchset first. I'll go chase that one up now.
ATB,
Mark.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Bug 1906905] Re: [PATCH] hw/timer/slavio_timer: Allow 64-bit accesses
2021-01-05 13:02 ` Mark Cave-Ayland
@ 2021-01-05 13:02 ` Mark Cave-Ayland
0 siblings, 0 replies; 11+ messages in thread
From: Mark Cave-Ayland @ 2021-01-05 13:02 UTC (permalink / raw)
To: qemu-devel
On 05/01/2021 11:06, Philippe Mathieu-Daudé wrote:
> ping?
>
> On 12/5/20 4:09 PM, Philippe Mathieu-Daudé wrote:
>> Per the "NCR89C105 Chip Specification" referenced in the header:
>>
>> Chip-level Address Map
>>
>> ------------------------------------------------------------------
>> | 1D0 0000 -> | Counter/Timers | W,D |
>> | 1DF FFFF | | |
>> ...
>>
>> The address map indicated the allowed accesses at each address.
>> [...] W indicates a word access, and D indicates a double-word
>> access.
>>
>> The SLAVIO timer controller is implemented expecting 32-bit accesses.
>> Commit a3d12d073e1 restricted the memory accesses to 32-bit, while
>> the device allows 64-bit accesses.
>>
>> This was not an issue until commit 5d971f9e67 which reverted
>> ("memory: accept mismatching sizes in memory_region_access_valid").
>>
>> Fix by renaming .valid MemoryRegionOps as .impl, and add the valid
>> access range (W -> 4, D -> 8).
>>
>> Since commit 21786c7e598 ("memory: Log invalid memory accesses")
>> this class of bug can be quickly debugged displaying 'guest_errors'
>> accesses, as:
>>
>> $ qemu-system-sparc -M SS-20 -m 256 -bios ss20_v2.25_rom -serial stdio -d guest_errors
>>
>> Power-ON Reset
>> Invalid access at addr 0x0, size 8, region 'timer-1', reason: invalid size (min:4 max:4)
>>
>> $ qemu-system-sparc -M SS-20 -m 256 -bios ss20_v2.25_rom -monitor stdio -S
>> (qemu) info mtree
>> address-space: memory
>> 0000000000000000-ffffffffffffffff (prio 0, i/o): system
>> ...
>> 0000000ff1300000-0000000ff130000f (prio 0, i/o): timer-1
>> ^^^^^^^^^ ^^^^^^^
>> \ memory region base address and name /
>>
>> (qemu) info qtree
>> bus: main-system-bus
>> dev: slavio_timer, id "" <-- device type name
>> gpio-out "sysbus-irq" 17
>> num_cpus = 1 (0x1)
>> mmio 0000000ff1310000/0000000000000014
>> mmio 0000000ff1300000/0000000000000010 <--- base address
>> mmio 0000000ff1301000/0000000000000010
>> mmio 0000000ff1302000/0000000000000010
>> ...
>>
>> Reported-by: Yap KV <yapkv@yahoo.com>
>> Buglink: https://bugs.launchpad.net/bugs/1906905
>> Fixes: a3d12d073e1 ("slavio_timer: convert to memory API")
>> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
>> ---
>> Cc: Benoit Canet <benoit.canet@gmail.com>
>> Cc: <1906905@bugs.launchpad.net>
>> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
>> ---
>> hw/timer/slavio_timer.c | 4 ++++
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/hw/timer/slavio_timer.c b/hw/timer/slavio_timer.c
>> index 5b2d20cb6a5..03e33fc5926 100644
>> --- a/hw/timer/slavio_timer.c
>> +++ b/hw/timer/slavio_timer.c
>> @@ -331,6 +331,10 @@ static const MemoryRegionOps slavio_timer_mem_ops = {
>> .write = slavio_timer_mem_writel,
>> .endianness = DEVICE_NATIVE_ENDIAN,
>> .valid = {
>> + .min_access_size = 4,
>> + .max_access_size = 8,
>> + },
>> + .impl = {
>> .min_access_size = 4,
>> .max_access_size = 4,
>> },
Looks like I did queue this to my local qemu-sparc branch, but was waiting to see if
there was feedback on the other outstanding SPARC patches before sending a PR. The
patches are all fairly minor, however I would prefer an Ack for the outstanding LEON
patchset first. I'll go chase that one up now.
ATB,
Mark.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1906905
Title:
qemu-system-sparc stucked while booting using ss20_v2.25_rom
Status in QEMU:
Confirmed
Bug description:
I cannot boot up OBP using the current (5.1) version of qemu with
ss20_v2.25_rom. It just stuck at "Power-ON reset" and hanged. However
using the previous version from 2015 I can successfully both up the
OBP.
qemu-system-sparc -M SS-20 -m 256 -bios ss20_v2.25.rom -nographic
Power-ON Reset
(*hang)
regards
Yap KV
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1906905/+subscriptions
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug 1906905] Re: qemu-system-sparc stucked while booting using ss20_v2.25_rom
2020-12-05 4:01 [Bug 1906905] [NEW] qemu-system-sparc stucked while booting using ss20_v2.25_rom yapkv
2020-12-05 6:37 ` [Bug 1906905] " yapkv
2020-12-05 15:09 ` [PATCH] hw/timer/slavio_timer: Allow 64-bit accesses Philippe Mathieu-Daudé
@ 2021-04-30 8:34 ` Thomas Huth
2 siblings, 0 replies; 11+ messages in thread
From: Thomas Huth @ 2021-04-30 8:34 UTC (permalink / raw)
To: qemu-devel
Fix has been included here:
https://gitlab.com/qemu-project/qemu/-/commit/62a9b228b5fefe0f9e364d
** Changed in: qemu
Status: Confirmed => Fix Released
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1906905
Title:
qemu-system-sparc stucked while booting using ss20_v2.25_rom
Status in QEMU:
Fix Released
Bug description:
I cannot boot up OBP using the current (5.1) version of qemu with
ss20_v2.25_rom. It just stuck at "Power-ON reset" and hanged. However
using the previous version from 2015 I can successfully both up the
OBP.
qemu-system-sparc -M SS-20 -m 256 -bios ss20_v2.25.rom -nographic
Power-ON Reset
(*hang)
regards
Yap KV
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1906905/+subscriptions
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2021-04-30 8:46 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-12-05 4:01 [Bug 1906905] [NEW] qemu-system-sparc stucked while booting using ss20_v2.25_rom yapkv
2020-12-05 6:37 ` [Bug 1906905] " yapkv
2020-12-05 15:09 ` [PATCH] hw/timer/slavio_timer: Allow 64-bit accesses Philippe Mathieu-Daudé
2020-12-05 15:09 ` [Bug 1906905] Re: qemu-system-sparc stucked while booting using ss20_v2.25_rom Philippe Mathieu-Daudé
2020-12-08 15:13 ` [Bug 1906905] Re: [PATCH] hw/timer/slavio_timer: Allow 64-bit accesses Mark Cave-Ayland
2020-12-08 15:13 ` Mark Cave-Ayland
2021-01-05 11:06 ` Philippe Mathieu-Daudé
2021-01-05 11:06 ` [Bug 1906905] " Philippe Mathieu-Daudé
2021-01-05 13:02 ` Mark Cave-Ayland
2021-01-05 13:02 ` Mark Cave-Ayland
2021-04-30 8:34 ` [Bug 1906905] Re: qemu-system-sparc stucked while booting using ss20_v2.25_rom Thomas Huth
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).