qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
* [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).