[PATCH v3 0/7] Reduce load on ppc target maintainers

[PATCH v3 0/7] Reduce load on ppc target maintainers

[David Gibson]

Greg Kurz and myself have been co-maintainers for the ppc and ppc64
targets for some time now.  However, both our day job responsibilities
and interests are leading us towards other areas, so we have less time
to devote to this any more.

Therefore, here's a bunch of updates to MAINTAINERS, intended to
reduce the load on us.  Mostly this is marking fairly obscure
platforms as orphaned (if someone wants to take over maintainership,
let me know ASAP).  Bigger changes may be coming, but we haven't
decided exactly what that's going to look like yet.

Changes since v2:
 * Clarified overly broad TCG CPUs entry
Changes since v1:
 * Reworked how OpenPIC is listed

David Gibson (7):
  qemu: Split machine_ppc.py acceptance tests
  MAINTAINERS: Remove machine specific files from ppc TCG CPUs entry
  MAINTAINERS: Remove David & Greg as reviewers for a number of boards
  MAINTAINERS: Orphan obscure ppc platforms
  MAINTAINERS: Remove David & Greg as reviewers/co-maintainers of
    powernv
  MAINTAINERS: Add information for OpenPIC
  MAINTAINERS: Demote sPAPR from "Supported" to "Maintained"

 MAINTAINERS                          | 51 ++++++++------------
 tests/acceptance/machine_ppc.py      | 69 ----------------------------
 tests/acceptance/ppc_mpc8544ds.py    | 32 +++++++++++++
 tests/acceptance/ppc_pseries.py      | 35 ++++++++++++++
 tests/acceptance/ppc_virtex_ml507.py | 34 ++++++++++++++
 5 files changed, 121 insertions(+), 100 deletions(-)
 delete mode 100644 tests/acceptance/machine_ppc.py
 create mode 100644 tests/acceptance/ppc_mpc8544ds.py
 create mode 100644 tests/acceptance/ppc_pseries.py
 create mode 100644 tests/acceptance/ppc_virtex_ml507.py

-- 
2.31.1

[PATCH v3 1/7] qemu: Split machine_ppc.py acceptance tests

[David Gibson]

machine_ppc.py contains tests for 3 different ppc based machine types.  It
is listed in MAINTAINERS along with the PPC TCG cpu code.  That's not
really accurate though, since it's really more about testing those machines
than the CPUs.

Therefore, split it up into separate files for the separate machine types,
and list those along with their machine types in MAINTAINERS.

Suggested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
 MAINTAINERS                          |  4 +-
 tests/acceptance/machine_ppc.py      | 69 ----------------------------
 tests/acceptance/ppc_mpc8544ds.py    | 32 +++++++++++++
 tests/acceptance/ppc_pseries.py      | 35 ++++++++++++++
 tests/acceptance/ppc_virtex_ml507.py | 34 ++++++++++++++
 5 files changed, 104 insertions(+), 70 deletions(-)
 delete mode 100644 tests/acceptance/machine_ppc.py
 create mode 100644 tests/acceptance/ppc_mpc8544ds.py
 create mode 100644 tests/acceptance/ppc_pseries.py
 create mode 100644 tests/acceptance/ppc_virtex_ml507.py

diff --git a/MAINTAINERS b/MAINTAINERS
index d7915ec128..53b318053c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -274,7 +274,6 @@ F: target/ppc/
 F: hw/ppc/
 F: include/hw/ppc/
 F: disas/ppc.c
-F: tests/acceptance/machine_ppc.py
 
 RISC-V TCG CPUs
 M: Palmer Dabbelt <palmer@dabbelt.com>
@@ -1270,6 +1269,7 @@ L: qemu-ppc@nongnu.org
 S: Odd Fixes
 F: hw/ppc/mpc8544ds.c
 F: hw/ppc/mpc8544_guts.c
+F: tests/acceptance/ppc_mpc8544ds.py
 
 New World (mac99)
 M: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
@@ -1340,6 +1340,7 @@ F: tests/qtest/spapr*
 F: tests/qtest/libqos/*spapr*
 F: tests/qtest/rtas*
 F: tests/qtest/libqos/rtas*
+F: tests/acceptance/ppc_pseries.py
 
 PowerNV (Non-Virtualized)
 M: Cédric Le Goater <clg@kaod.org>
@@ -1361,6 +1362,7 @@ M: Edgar E. Iglesias <edgar.iglesias@gmail.com>
 L: qemu-ppc@nongnu.org
 S: Odd Fixes
 F: hw/ppc/virtex_ml507.c
+F: tests/acceptance/ppc_virtex_ml507.py
 
 sam460ex
 M: BALATON Zoltan <balaton@eik.bme.hu>
diff --git a/tests/acceptance/machine_ppc.py b/tests/acceptance/machine_ppc.py
deleted file mode 100644
index a836e2496f..0000000000
--- a/tests/acceptance/machine_ppc.py
+++ /dev/null
@@ -1,69 +0,0 @@
-# Test that Linux kernel boots on ppc machines and check the console
-#
-# Copyright (c) 2018, 2020 Red Hat, Inc.
-#
-# This work is licensed under the terms of the GNU GPL, version 2 or
-# later.  See the COPYING file in the top-level directory.
-
-from avocado.utils import archive
-from avocado_qemu import Test
-from avocado_qemu import wait_for_console_pattern
-
-class PpcMachine(Test):
-
-    timeout = 90
-    KERNEL_COMMON_COMMAND_LINE = 'printk.time=0 '
-    panic_message = 'Kernel panic - not syncing'
-
-    def test_ppc64_pseries(self):
-        """
-        :avocado: tags=arch:ppc64
-        :avocado: tags=machine:pseries
-        """
-        kernel_url = ('https://archives.fedoraproject.org/pub/archive'
-                      '/fedora-secondary/releases/29/Everything/ppc64le/os'
-                      '/ppc/ppc64/vmlinuz')
-        kernel_hash = '3fe04abfc852b66653b8c3c897a59a689270bc77'
-        kernel_path = self.fetch_asset(kernel_url, asset_hash=kernel_hash)
-
-        self.vm.set_console()
-        kernel_command_line = self.KERNEL_COMMON_COMMAND_LINE + 'console=hvc0'
-        self.vm.add_args('-kernel', kernel_path,
-                         '-append', kernel_command_line)
-        self.vm.launch()
-        console_pattern = 'Kernel command line: %s' % kernel_command_line
-        wait_for_console_pattern(self, console_pattern, self.panic_message)
-
-    def test_ppc_mpc8544ds(self):
-        """
-        :avocado: tags=arch:ppc
-        :avocado: tags=machine:mpc8544ds
-        """
-        tar_url = ('https://www.qemu-advent-calendar.org'
-                   '/2020/download/day17.tar.gz')
-        tar_hash = '7a5239542a7c4257aa4d3b7f6ddf08fb6775c494'
-        file_path = self.fetch_asset(tar_url, asset_hash=tar_hash)
-        archive.extract(file_path, self.workdir)
-        self.vm.set_console()
-        self.vm.add_args('-kernel', self.workdir + '/creek/creek.bin')
-        self.vm.launch()
-        wait_for_console_pattern(self, 'QEMU advent calendar 2020',
-                                 self.panic_message)
-
-    def test_ppc_virtex_ml507(self):
-        """
-        :avocado: tags=arch:ppc
-        :avocado: tags=machine:virtex-ml507
-        """
-        tar_url = ('https://www.qemu-advent-calendar.org'
-                   '/2020/download/hippo.tar.gz')
-        tar_hash = '306b95bfe7d147f125aa176a877e266db8ef914a'
-        file_path = self.fetch_asset(tar_url, asset_hash=tar_hash)
-        archive.extract(file_path, self.workdir)
-        self.vm.set_console()
-        self.vm.add_args('-kernel', self.workdir + '/hippo/hippo.linux',
-                         '-dtb', self.workdir + '/hippo/virtex440-ml507.dtb',
-                         '-m', '512')
-        self.vm.launch()
-        wait_for_console_pattern(self, 'QEMU advent calendar 2020',
-                                 self.panic_message)
diff --git a/tests/acceptance/ppc_mpc8544ds.py b/tests/acceptance/ppc_mpc8544ds.py
new file mode 100644
index 0000000000..ce840600c1
--- /dev/null
+++ b/tests/acceptance/ppc_mpc8544ds.py
@@ -0,0 +1,32 @@
+# Test that Linux kernel boots on ppc machines and check the console
+#
+# Copyright (c) 2018, 2020 Red Hat, Inc.
+#
+# This work is licensed under the terms of the GNU GPL, version 2 or
+# later.  See the COPYING file in the top-level directory.
+
+from avocado.utils import archive
+from avocado_qemu import Test
+from avocado_qemu import wait_for_console_pattern
+
+class Mpc8544dsMachine(Test):
+
+    timeout = 90
+    KERNEL_COMMON_COMMAND_LINE = 'printk.time=0 '
+    panic_message = 'Kernel panic - not syncing'
+
+    def test_ppc_mpc8544ds(self):
+        """
+        :avocado: tags=arch:ppc
+        :avocado: tags=machine:mpc8544ds
+        """
+        tar_url = ('https://www.qemu-advent-calendar.org'
+                   '/2020/download/day17.tar.gz')
+        tar_hash = '7a5239542a7c4257aa4d3b7f6ddf08fb6775c494'
+        file_path = self.fetch_asset(tar_url, asset_hash=tar_hash)
+        archive.extract(file_path, self.workdir)
+        self.vm.set_console()
+        self.vm.add_args('-kernel', self.workdir + '/creek/creek.bin')
+        self.vm.launch()
+        wait_for_console_pattern(self, 'QEMU advent calendar 2020',
+                                 self.panic_message)
diff --git a/tests/acceptance/ppc_pseries.py b/tests/acceptance/ppc_pseries.py
new file mode 100644
index 0000000000..f14a884ee1
--- /dev/null
+++ b/tests/acceptance/ppc_pseries.py
@@ -0,0 +1,35 @@
+# Test that Linux kernel boots on ppc machines and check the console
+#
+# Copyright (c) 2018, 2020 Red Hat, Inc.
+#
+# This work is licensed under the terms of the GNU GPL, version 2 or
+# later.  See the COPYING file in the top-level directory.
+
+from avocado.utils import archive
+from avocado_qemu import Test
+from avocado_qemu import wait_for_console_pattern
+
+class pseriesMachine(Test):
+
+    timeout = 90
+    KERNEL_COMMON_COMMAND_LINE = 'printk.time=0 '
+    panic_message = 'Kernel panic - not syncing'
+
+    def test_ppc64_pseries(self):
+        """
+        :avocado: tags=arch:ppc64
+        :avocado: tags=machine:pseries
+        """
+        kernel_url = ('https://archives.fedoraproject.org/pub/archive'
+                      '/fedora-secondary/releases/29/Everything/ppc64le/os'
+                      '/ppc/ppc64/vmlinuz')
+        kernel_hash = '3fe04abfc852b66653b8c3c897a59a689270bc77'
+        kernel_path = self.fetch_asset(kernel_url, asset_hash=kernel_hash)
+
+        self.vm.set_console()
+        kernel_command_line = self.KERNEL_COMMON_COMMAND_LINE + 'console=hvc0'
+        self.vm.add_args('-kernel', kernel_path,
+                         '-append', kernel_command_line)
+        self.vm.launch()
+        console_pattern = 'Kernel command line: %s' % kernel_command_line
+        wait_for_console_pattern(self, console_pattern, self.panic_message)
diff --git a/tests/acceptance/ppc_virtex_ml507.py b/tests/acceptance/ppc_virtex_ml507.py
new file mode 100644
index 0000000000..27f7bf2d49
--- /dev/null
+++ b/tests/acceptance/ppc_virtex_ml507.py
@@ -0,0 +1,34 @@
+# Test that Linux kernel boots on ppc machines and check the console
+#
+# Copyright (c) 2018, 2020 Red Hat, Inc.
+#
+# This work is licensed under the terms of the GNU GPL, version 2 or
+# later.  See the COPYING file in the top-level directory.
+
+from avocado.utils import archive
+from avocado_qemu import Test
+from avocado_qemu import wait_for_console_pattern
+
+class VirtexMl507Machine(Test):
+
+    timeout = 90
+    KERNEL_COMMON_COMMAND_LINE = 'printk.time=0 '
+    panic_message = 'Kernel panic - not syncing'
+
+    def test_ppc_virtex_ml507(self):
+        """
+        :avocado: tags=arch:ppc
+        :avocado: tags=machine:virtex-ml507
+        """
+        tar_url = ('https://www.qemu-advent-calendar.org'
+                   '/2020/download/hippo.tar.gz')
+        tar_hash = '306b95bfe7d147f125aa176a877e266db8ef914a'
+        file_path = self.fetch_asset(tar_url, asset_hash=tar_hash)
+        archive.extract(file_path, self.workdir)
+        self.vm.set_console()
+        self.vm.add_args('-kernel', self.workdir + '/hippo/hippo.linux',
+                         '-dtb', self.workdir + '/hippo/virtex440-ml507.dtb',
+                         '-m', '512')
+        self.vm.launch()
+        wait_for_console_pattern(self, 'QEMU advent calendar 2020',
+                                 self.panic_message)
-- 
2.31.1

Re: [PATCH v3 1/7] qemu: Split machine_ppc.py acceptance tests

[Philippe Mathieu-Daudé]

On 9/27/21 06:48, David Gibson wrote:
> machine_ppc.py contains tests for 3 different ppc based machine types.  It
> is listed in MAINTAINERS along with the PPC TCG cpu code.  That's not
> really accurate though, since it's really more about testing those machines
> than the CPUs.
> 
> Therefore, split it up into separate files for the separate machine types,
> and list those along with their machine types in MAINTAINERS.
> 
> Suggested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> ---
>  MAINTAINERS                          |  4 +-
>  tests/acceptance/machine_ppc.py      | 69 ----------------------------
>  tests/acceptance/ppc_mpc8544ds.py    | 32 +++++++++++++
>  tests/acceptance/ppc_pseries.py      | 35 ++++++++++++++
>  tests/acceptance/ppc_virtex_ml507.py | 34 ++++++++++++++
>  5 files changed, 104 insertions(+), 70 deletions(-)
>  delete mode 100644 tests/acceptance/machine_ppc.py
>  create mode 100644 tests/acceptance/ppc_mpc8544ds.py
>  create mode 100644 tests/acceptance/ppc_pseries.py
>  create mode 100644 tests/acceptance/ppc_virtex_ml507.py

Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>

Re: [PATCH v3 1/7] qemu: Split machine_ppc.py acceptance tests

[Philippe Mathieu-Daudé]

Hi David,

On 9/27/21 06:48, David Gibson wrote:
> machine_ppc.py contains tests for 3 different ppc based machine types.  It
> is listed in MAINTAINERS along with the PPC TCG cpu code.  That's not
> really accurate though, since it's really more about testing those machines
> than the CPUs.
> 
> Therefore, split it up into separate files for the separate machine types,
> and list those along with their machine types in MAINTAINERS.
> 
> Suggested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> ---
>  MAINTAINERS                          |  4 +-
>  tests/acceptance/machine_ppc.py      | 69 ----------------------------
>  tests/acceptance/ppc_mpc8544ds.py    | 32 +++++++++++++
>  tests/acceptance/ppc_pseries.py      | 35 ++++++++++++++
>  tests/acceptance/ppc_virtex_ml507.py | 34 ++++++++++++++
>  5 files changed, 104 insertions(+), 70 deletions(-)
>  delete mode 100644 tests/acceptance/machine_ppc.py
>  create mode 100644 tests/acceptance/ppc_mpc8544ds.py
>  create mode 100644 tests/acceptance/ppc_pseries.py
>  create mode 100644 tests/acceptance/ppc_virtex_ml507.py

Since I'm preparing an integration-testing pull request,
I'll queue this single patch directly, to avoid future
merge conflicts.

Re: [PATCH v3 1/7] qemu: Split machine_ppc.py acceptance tests

[Cédric Le Goater]

On 9/27/21 18:44, Philippe Mathieu-Daudé wrote:
> Hi David,
> 
> On 9/27/21 06:48, David Gibson wrote:
>> machine_ppc.py contains tests for 3 different ppc based machine types.  It
>> is listed in MAINTAINERS along with the PPC TCG cpu code.  That's not
>> really accurate though, since it's really more about testing those machines
>> than the CPUs.
>>
>> Therefore, split it up into separate files for the separate machine types,
>> and list those along with their machine types in MAINTAINERS.
>>
>> Suggested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
>> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
>> ---
>>   MAINTAINERS                          |  4 +-
>>   tests/acceptance/machine_ppc.py      | 69 ----------------------------
>>   tests/acceptance/ppc_mpc8544ds.py    | 32 +++++++++++++
>>   tests/acceptance/ppc_pseries.py      | 35 ++++++++++++++
>>   tests/acceptance/ppc_virtex_ml507.py | 34 ++++++++++++++
>>   5 files changed, 104 insertions(+), 70 deletions(-)
>>   delete mode 100644 tests/acceptance/machine_ppc.py
>>   create mode 100644 tests/acceptance/ppc_mpc8544ds.py
>>   create mode 100644 tests/acceptance/ppc_pseries.py
>>   create mode 100644 tests/acceptance/ppc_virtex_ml507.py
> 
> Since I'm preparing an integration-testing pull request,
> I'll queue this single patch directly, to avoid future
> merge conflicts.
> 

Should I resend this patch ?

http://patchwork.ozlabs.org/project/qemu-devel/patch/20210817093036.1288791-1-clg@kaod.org/

Thanks,

C.

Re: [PATCH v3 1/7] qemu: Split machine_ppc.py acceptance tests

[Philippe Mathieu-Daudé]

On 9/27/21 18:53, Cédric Le Goater wrote:
> On 9/27/21 18:44, Philippe Mathieu-Daudé wrote:
>> Hi David,
>>
>> On 9/27/21 06:48, David Gibson wrote:
>>> machine_ppc.py contains tests for 3 different ppc based machine
>>> types.  It
>>> is listed in MAINTAINERS along with the PPC TCG cpu code.  That's not
>>> really accurate though, since it's really more about testing those
>>> machines
>>> than the CPUs.
>>>
>>> Therefore, split it up into separate files for the separate machine
>>> types,
>>> and list those along with their machine types in MAINTAINERS.
>>>
>>> Suggested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
>>> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
>>> ---
>>>   MAINTAINERS                          |  4 +-
>>>   tests/acceptance/machine_ppc.py      | 69 ----------------------------
>>>   tests/acceptance/ppc_mpc8544ds.py    | 32 +++++++++++++
>>>   tests/acceptance/ppc_pseries.py      | 35 ++++++++++++++
>>>   tests/acceptance/ppc_virtex_ml507.py | 34 ++++++++++++++
>>>   5 files changed, 104 insertions(+), 70 deletions(-)
>>>   delete mode 100644 tests/acceptance/machine_ppc.py
>>>   create mode 100644 tests/acceptance/ppc_mpc8544ds.py
>>>   create mode 100644 tests/acceptance/ppc_pseries.py
>>>   create mode 100644 tests/acceptance/ppc_virtex_ml507.py
>>
>> Since I'm preparing an integration-testing pull request,
>> I'll queue this single patch directly, to avoid future
>> merge conflicts.
>>
> 
> Should I resend this patch ?
> 
> http://patchwork.ozlabs.org/project/qemu-devel/patch/20210817093036.1288791-1-clg@kaod.org/

Doh, I scanned the list for patches unattended during the last 8 months
but apparently missed it. No need to resend.

[PATCH v3 2/7] MAINTAINERS: Remove machine specific files from ppc TCG CPUs entry

[David Gibson]

Currently the PowerPC TCG CPUs entry in MAINTAINERS lists all of hw/ppc/
and include/hw/ppc.  Nearly all the files in those places are related to
specific ppc machine types, rather than to the actual CPUs however.  Those
machine types list their own files separately, often overlapping with this.
For greater clarity, remove these misleading entries from the TCG CPUs
stanza, leaving just hw/ppc/ppc.c and hw/ppc/ppc_booke.c which are the only
ones common to a wide range of PPC TCG cpus each.

Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
 MAINTAINERS | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 53b318053c..e51bab91bd 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -271,8 +271,9 @@ M: Greg Kurz <groug@kaod.org>
 L: qemu-ppc@nongnu.org
 S: Maintained
 F: target/ppc/
-F: hw/ppc/
-F: include/hw/ppc/
+F: hw/ppc/ppc.c
+F: hw/ppc/ppc_booke.c
+F: include/hw/ppc/ppc.h
 F: disas/ppc.c
 
 RISC-V TCG CPUs
-- 
2.31.1

[PATCH v3 3/7] MAINTAINERS: Remove David & Greg as reviewers for a number of boards

[David Gibson]

Greg and I are moving towards other areas and no longer have capacity to
act as regular reviewers for several of the secondary ppc machine types.
So, remove ourselves as reviewers for Macintosh, PReP, sam460ex and
pegasos2 in MAINTAINERS.

Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Greg Kurz <groug@kaod.org>
Acked-by: BALATON Zoltan <balaton@eik.bme.hu>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
---
 MAINTAINERS | 9 ---------
 1 file changed, 9 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index e51bab91bd..f2060b46f9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1274,8 +1274,6 @@ F: tests/acceptance/ppc_mpc8544ds.py
 
 New World (mac99)
 M: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
-R: David Gibson <david@gibson.dropbear.id.au>
-R: Greg Kurz <groug@kaod.org>
 L: qemu-ppc@nongnu.org
 S: Odd Fixes
 F: hw/ppc/mac_newworld.c
@@ -1294,8 +1292,6 @@ F: pc-bios/qemu_vga.ndrv
 
 Old World (g3beige)
 M: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
-R: David Gibson <david@gibson.dropbear.id.au>
-R: Greg Kurz <groug@kaod.org>
 L: qemu-ppc@nongnu.org
 S: Odd Fixes
 F: hw/ppc/mac_oldworld.c
@@ -1309,8 +1305,6 @@ F: pc-bios/qemu_vga.ndrv
 
 PReP
 M: Hervé Poussineau <hpoussin@reactos.org>
-R: David Gibson <david@gibson.dropbear.id.au>
-R: Greg Kurz <groug@kaod.org>
 L: qemu-ppc@nongnu.org
 S: Maintained
 F: hw/ppc/prep.c
@@ -1367,8 +1361,6 @@ F: tests/acceptance/ppc_virtex_ml507.py
 
 sam460ex
 M: BALATON Zoltan <balaton@eik.bme.hu>
-R: David Gibson <david@gibson.dropbear.id.au>
-R: Greg Kurz <groug@kaod.org>
 L: qemu-ppc@nongnu.org
 S: Maintained
 F: hw/ppc/sam460ex.c
@@ -1382,7 +1374,6 @@ F: roms/u-boot-sam460ex
 
 pegasos2
 M: BALATON Zoltan <balaton@eik.bme.hu>
-R: David Gibson <david@gibson.dropbear.id.au>
 L: qemu-ppc@nongnu.org
 S: Maintained
 F: hw/ppc/pegasos2.c
-- 
2.31.1

[PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms

[David Gibson]

There are a nunber of old embedded ppc machine types which have been little
changed and in "Odd Fixes" state for a long time.  With both myself and
Greg Kurz moving toward other areas, we no longer have the capacity to
keep reviewing and maintaining even the rare patches that come in for those
platforms.

Therefore, remove our names as reviewers and mark these platforms as
orphaned.

Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Greg Kurz <groug@kaod.org>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
---
 MAINTAINERS | 19 +++++--------------
 1 file changed, 5 insertions(+), 14 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index f2060b46f9..1ecb5716c8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1236,24 +1236,18 @@ F: hw/openrisc/openrisc_sim.c
 PowerPC Machines
 ----------------
 405
-M: David Gibson <david@gibson.dropbear.id.au>
-M: Greg Kurz <groug@kaod.org>
 L: qemu-ppc@nongnu.org
-S: Odd Fixes
+S: Orphan
 F: hw/ppc/ppc405_boards.c
 
 Bamboo
-M: David Gibson <david@gibson.dropbear.id.au>
-M: Greg Kurz <groug@kaod.org>
 L: qemu-ppc@nongnu.org
-S: Odd Fixes
+S: Orphan
 F: hw/ppc/ppc440_bamboo.c
 
 e500
-M: David Gibson <david@gibson.dropbear.id.au>
-M: Greg Kurz <groug@kaod.org>
 L: qemu-ppc@nongnu.org
-S: Odd Fixes
+S: Orphan
 F: hw/ppc/e500*
 F: hw/gpio/mpc8xxx.c
 F: hw/i2c/mpc_i2c.c
@@ -1264,10 +1258,8 @@ F: include/hw/pci-host/ppce500.h
 F: pc-bios/u-boot.e500
 
 mpc8544ds
-M: David Gibson <david@gibson.dropbear.id.au>
-M: Greg Kurz <groug@kaod.org>
 L: qemu-ppc@nongnu.org
-S: Odd Fixes
+S: Orphan
 F: hw/ppc/mpc8544ds.c
 F: hw/ppc/mpc8544_guts.c
 F: tests/acceptance/ppc_mpc8544ds.py
@@ -1777,9 +1769,8 @@ F: include/hw/acpi/ghes.h
 F: docs/specs/acpi_hest_ghes.rst
 
 ppc4xx
-M: David Gibson <david@gibson.dropbear.id.au>
 L: qemu-ppc@nongnu.org
-S: Odd Fixes
+S: Orphan
 F: hw/ppc/ppc4*.c
 F: hw/i2c/ppc4xx_i2c.c
 F: include/hw/ppc/ppc4xx.h
-- 
2.31.1

Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms)

[Thomas Huth]

On 27/09/2021 06.48, David Gibson wrote:
> There are a nunber of old embedded ppc machine types which have been little
> changed and in "Odd Fixes" state for a long time.  With both myself and
> Greg Kurz moving toward other areas, we no longer have the capacity to
> keep reviewing and maintaining even the rare patches that come in for those
> platforms.
> 
> Therefore, remove our names as reviewers and mark these platforms as
> orphaned.
> 
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> Reviewed-by: Greg Kurz <groug@kaod.org>
> Reviewed-by: Cédric Le Goater <clg@kaod.org>
> ---
>   MAINTAINERS | 19 +++++--------------
>   1 file changed, 5 insertions(+), 14 deletions(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index f2060b46f9..1ecb5716c8 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1236,24 +1236,18 @@ F: hw/openrisc/openrisc_sim.c
>   PowerPC Machines
>   ----------------
>   405
> -M: David Gibson <david@gibson.dropbear.id.au>
> -M: Greg Kurz <groug@kaod.org>
>   L: qemu-ppc@nongnu.org
> -S: Odd Fixes
> +S: Orphan
>   F: hw/ppc/ppc405_boards.c

Related question: Does *anybody* know how to still use the ref405ep or taihu 
board in QEMU? We just got another ticket asking for the related firmware image:

  https://gitlab.com/qemu-project/qemu/-/issues/651

And if you google for 'ppc405_rom.bin', I only find pages where people are 
asking basically the same question, e.g.:

  https://lists.nongnu.org/archive/html/qemu-devel/2007-08/msg00252.html (in 
2007 already! And no answer)

  https://github.com/Xilinx/qemu/issues/36 (in 2019, no answer)

  https://lists.libreplanet.org/archive/html/qemu-ppc/2019-12/msg00263.html 
(in 2019, no answer about bios location)

  https://lkml.org/lkml/2020/4/25/61 (in 2020, no answer)


Seems like the Linux kernel removed support for the 405ep board here:

 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=548f5244f1064c9facb19c5e9

... to me this all sounds like these 405 boards are pretty dead code in QEMU 
right now, so if nobody has a clue how to use them, I'd suggest to mark them 
as deprecated and remove them in a couple of releases?

  Thomas

Re: Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms)

[Christophe Leroy]

Le 01/10/2021 à 10:35, Thomas Huth a écrit :
> On 27/09/2021 06.48, David Gibson wrote:
>> There are a nunber of old embedded ppc machine types which have been 
>> little
>> changed and in "Odd Fixes" state for a long time.  With both myself and
>> Greg Kurz moving toward other areas, we no longer have the capacity to
>> keep reviewing and maintaining even the rare patches that come in for 
>> those
>> platforms.
>>
>> Therefore, remove our names as reviewers and mark these platforms as
>> orphaned.
>>
>> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
>> Reviewed-by: Greg Kurz <groug@kaod.org>
>> Reviewed-by: Cédric Le Goater <clg@kaod.org>
>> ---
>>   MAINTAINERS | 19 +++++--------------
>>   1 file changed, 5 insertions(+), 14 deletions(-)
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index f2060b46f9..1ecb5716c8 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -1236,24 +1236,18 @@ F: hw/openrisc/openrisc_sim.c
>>   PowerPC Machines
>>   ----------------
>>   405
>> -M: David Gibson <david@gibson.dropbear.id.au>
>> -M: Greg Kurz <groug@kaod.org>
>>   L: qemu-ppc@nongnu.org
>> -S: Odd Fixes
>> +S: Orphan
>>   F: hw/ppc/ppc405_boards.c
> 
> Related question: Does *anybody* know how to still use the ref405ep or 
> taihu board in QEMU? We just got another ticket asking for the related 
> firmware image:
> 
>   https://gitlab.com/qemu-project/qemu/-/issues/651
> 
> And if you google for 'ppc405_rom.bin', I only find pages where people 
> are asking basically the same question, e.g.:
> 
>   https://lists.nongnu.org/archive/html/qemu-devel/2007-08/msg00252.html 
> (in 2007 already! And no answer)
> 
>   https://github.com/Xilinx/qemu/issues/36 (in 2019, no answer)
> 
>   https://lists.libreplanet.org/archive/html/qemu-ppc/2019-12/msg00263.html (in 2019, no answer about bios location)
> 
>   https://lkml.org/lkml/2020/4/25/61 (in 2020, no answer)
> 
> 
> Seems like the Linux kernel removed support for the 405ep board here:
> 
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=548f5244f1064c9facb19c5e9 
> 

The EP405 board was removed because it was apparently based on the buggy 
405GP processor (It was selecting option CONFIG_405GP).

AFAIU the EP405 board is different from the ref405ep. The ref405ep has a 
405EP processor which is still supported, see 
https://elixir.bootlin.com/linux/v5.15-rc3/source/arch/powerpc/kernel/cputable.c#L1300

Christophe


> 
> ... to me this all sounds like these 405 boards are pretty dead code in 
> QEMU right now, so if nobody has a clue how to use them, I'd suggest to 
> mark them as deprecated and remove them in a couple of releases?
> 

Re: Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms)

[Thomas Huth]

On 01/10/2021 11.14, Christophe Leroy wrote:
> 
> 
> Le 01/10/2021 à 10:35, Thomas Huth a écrit :
>> On 27/09/2021 06.48, David Gibson wrote:
>>> There are a nunber of old embedded ppc machine types which have been little
>>> changed and in "Odd Fixes" state for a long time.  With both myself and
>>> Greg Kurz moving toward other areas, we no longer have the capacity to
>>> keep reviewing and maintaining even the rare patches that come in for those
>>> platforms.
>>>
>>> Therefore, remove our names as reviewers and mark these platforms as
>>> orphaned.
>>>
>>> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
>>> Reviewed-by: Greg Kurz <groug@kaod.org>
>>> Reviewed-by: Cédric Le Goater <clg@kaod.org>
>>> ---
>>>   MAINTAINERS | 19 +++++--------------
>>>   1 file changed, 5 insertions(+), 14 deletions(-)
>>>
>>> diff --git a/MAINTAINERS b/MAINTAINERS
>>> index f2060b46f9..1ecb5716c8 100644
>>> --- a/MAINTAINERS
>>> +++ b/MAINTAINERS
>>> @@ -1236,24 +1236,18 @@ F: hw/openrisc/openrisc_sim.c
>>>   PowerPC Machines
>>>   ----------------
>>>   405
>>> -M: David Gibson <david@gibson.dropbear.id.au>
>>> -M: Greg Kurz <groug@kaod.org>
>>>   L: qemu-ppc@nongnu.org
>>> -S: Odd Fixes
>>> +S: Orphan
>>>   F: hw/ppc/ppc405_boards.c
>>
>> Related question: Does *anybody* know how to still use the ref405ep or 
>> taihu board in QEMU? We just got another ticket asking for the related 
>> firmware image:
>>
>>   https://gitlab.com/qemu-project/qemu/-/issues/651
>>
>> And if you google for 'ppc405_rom.bin', I only find pages where people are 
>> asking basically the same question, e.g.:
>>
>>   https://lists.nongnu.org/archive/html/qemu-devel/2007-08/msg00252.html 
>> (in 2007 already! And no answer)
>>
>>   https://github.com/Xilinx/qemu/issues/36 (in 2019, no answer)
>>
>>   https://lists.libreplanet.org/archive/html/qemu-ppc/2019-12/msg00263.html (in 
>> 2019, no answer about bios location)
>>
>>   https://lkml.org/lkml/2020/4/25/61 (in 2020, no answer)
>>
>>
>> Seems like the Linux kernel removed support for the 405ep board here:
>>
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=548f5244f1064c9facb19c5e9 
>>
> 
> The EP405 board was removed because it was apparently based on the buggy 
> 405GP processor (It was selecting option CONFIG_405GP).
> 
> AFAIU the EP405 board is different from the ref405ep. The ref405ep has a 
> 405EP processor which is still supported, see 
> https://elixir.bootlin.com/linux/v5.15-rc3/source/arch/powerpc/kernel/cputable.c#L1300 

Oh, that's pretty confusing, thank a lot for the clarification!

Nevertheless, as long as nobody has a hint where to find that 
ppc405_rom.bin, I think both boards are pretty useless in QEMU (as far as I 
can see, they do not work without the bios at all, so it's also not possible 
to use a Linux image with the "-kernel" CLI option directly).

  Thomas

Re: Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms)

[Peter Maydell]

On Fri, 1 Oct 2021 at 10:43, Thomas Huth <thuth@redhat.com> wrote:
> Nevertheless, as long as nobody has a hint where to find that
> ppc405_rom.bin, I think both boards are pretty useless in QEMU (as far as I
> can see, they do not work without the bios at all, so it's also not possible
> to use a Linux image with the "-kernel" CLI option directly).

It is at least in theory possible to run bare-metal code on
either board, by passing either a pflash or a bios argument.
But I agree that there seem to be no signs of anybody actually
successfully using these boards for anything, so we should
deprecate-and-delete them.

-- PMM

Re: Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms)

[Thomas Huth]

On 01/10/2021 13.12, Peter Maydell wrote:
> On Fri, 1 Oct 2021 at 10:43, Thomas Huth <thuth@redhat.com> wrote:
>> Nevertheless, as long as nobody has a hint where to find that
>> ppc405_rom.bin, I think both boards are pretty useless in QEMU (as far as I
>> can see, they do not work without the bios at all, so it's also not possible
>> to use a Linux image with the "-kernel" CLI option directly).
> 
> It is at least in theory possible to run bare-metal code on
> either board, by passing either a pflash or a bios argument.

True. I did some more research, and seems like there was once support for 
those boards in u-boot, but it got removed there a couple of years ago already:

https://gitlab.com/qemu-project/u-boot/-/commit/98f705c9cefdf

https://gitlab.com/qemu-project/u-boot/-/commit/b147ff2f37d5b

https://gitlab.com/qemu-project/u-boot/-/commit/7514037bcdc37

> But I agree that there seem to be no signs of anybody actually
> successfully using these boards for anything, so we should
> deprecate-and-delete them.

Yes, let's mark them as deprecated now ... if someone still uses them and 
speaks up, we can still revert the deprecation again.

  Thomas

Re: Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms)

[Christophe Leroy]

Le 01/10/2021 à 14:04, Thomas Huth a écrit :
> On 01/10/2021 13.12, Peter Maydell wrote:
>> On Fri, 1 Oct 2021 at 10:43, Thomas Huth <thuth@redhat.com> wrote:
>>> Nevertheless, as long as nobody has a hint where to find that
>>> ppc405_rom.bin, I think both boards are pretty useless in QEMU (as 
>>> far as I
>>> can see, they do not work without the bios at all, so it's also not 
>>> possible
>>> to use a Linux image with the "-kernel" CLI option directly).
>>
>> It is at least in theory possible to run bare-metal code on
>> either board, by passing either a pflash or a bios argument.
> 
> True. I did some more research, and seems like there was once support 
> for those boards in u-boot, but it got removed there a couple of years 
> ago already:
> 
> https://gitlab.com/qemu-project/u-boot/-/commit/98f705c9cefdf
> 
> https://gitlab.com/qemu-project/u-boot/-/commit/b147ff2f37d5b
> 
> https://gitlab.com/qemu-project/u-boot/-/commit/7514037bcdc37
> 
>> But I agree that there seem to be no signs of anybody actually
>> successfully using these boards for anything, so we should
>> deprecate-and-delete them.
> 
> Yes, let's mark them as deprecated now ... if someone still uses them 
> and speaks up, we can still revert the deprecation again.
> 


I really would like to be able to use them to validate Linux Kernel 
changes, hence looking for that missing BIOS.

If we remove ppc405 from QEMU, we won't be able to do any regression 
tests of Linux Kernel on those processors.

Christophe

Re: Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms)

[Cédric Le Goater]

On 10/1/21 15:04, Christophe Leroy wrote:
> 
> 
> Le 01/10/2021 à 14:04, Thomas Huth a écrit :
>> On 01/10/2021 13.12, Peter Maydell wrote:
>>> On Fri, 1 Oct 2021 at 10:43, Thomas Huth <thuth@redhat.com> wrote:
>>>> Nevertheless, as long as nobody has a hint where to find that
>>>> ppc405_rom.bin, I think both boards are pretty useless in QEMU (as far as I
>>>> can see, they do not work without the bios at all, so it's also not possible
>>>> to use a Linux image with the "-kernel" CLI option directly).
>>>
>>> It is at least in theory possible to run bare-metal code on
>>> either board, by passing either a pflash or a bios argument.
>>
>> True. I did some more research, and seems like there was once support for those boards in u-boot, but it got removed there a couple of years ago already:
>>
>> https://gitlab.com/qemu-project/u-boot/-/commit/98f705c9cefdf
>>
>> https://gitlab.com/qemu-project/u-boot/-/commit/b147ff2f37d5b
>>
>> https://gitlab.com/qemu-project/u-boot/-/commit/7514037bcdc37
>>
>>> But I agree that there seem to be no signs of anybody actually
>>> successfully using these boards for anything, so we should
>>> deprecate-and-delete them.
>>
>> Yes, let's mark them as deprecated now ... if someone still uses them and speaks up, we can still revert the deprecation again.
>>
> 
> 
> I really would like to be able to use them to validate Linux Kernel changes, hence looking for that missing BIOS.
> 
> If we remove ppc405 from QEMU, we won't be able to do any regression tests of Linux Kernel on those processors.

It's nice to have I agree.

Someone needs to find the right u-boot level and certainly also,
a host old enough to support the compiler options. May be, a RH6
ppc64 VM or an old ppc32 debian image running under QEMU or
some MAC.

Tell me if you need some help to get a system/image.

C.

Re: Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms)

[Peter Maydell]

On Fri, 1 Oct 2021 at 14:04, Christophe Leroy
<christophe.leroy@csgroup.eu> wrote:
> I really would like to be able to use them to validate Linux Kernel
> changes, hence looking for that missing BIOS.
>
> If we remove ppc405 from QEMU, we won't be able to do any regression
> tests of Linux Kernel on those processors.

Do you (does anyone) have real hardware to test against? If the only
thing you have is QEMU's emulation, I wouldn't particularly trust it
to be bug-free enough to keep the kernel still working on real h/w...

-- PMM

Re: Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms)

[Thomas Huth]

On 01/10/2021 15.04, Christophe Leroy wrote:
> 
> 
> Le 01/10/2021 à 14:04, Thomas Huth a écrit :
>> On 01/10/2021 13.12, Peter Maydell wrote:
>>> On Fri, 1 Oct 2021 at 10:43, Thomas Huth <thuth@redhat.com> wrote:
>>>> Nevertheless, as long as nobody has a hint where to find that
>>>> ppc405_rom.bin, I think both boards are pretty useless in QEMU (as far as I
>>>> can see, they do not work without the bios at all, so it's also not 
>>>> possible
>>>> to use a Linux image with the "-kernel" CLI option directly).
>>>
>>> It is at least in theory possible to run bare-metal code on
>>> either board, by passing either a pflash or a bios argument.
>>
>> True. I did some more research, and seems like there was once support for 
>> those boards in u-boot, but it got removed there a couple of years ago 
>> already:
>>
>> https://gitlab.com/qemu-project/u-boot/-/commit/98f705c9cefdf
>>
>> https://gitlab.com/qemu-project/u-boot/-/commit/b147ff2f37d5b
>>
>> https://gitlab.com/qemu-project/u-boot/-/commit/7514037bcdc37
>>
>>> But I agree that there seem to be no signs of anybody actually
>>> successfully using these boards for anything, so we should
>>> deprecate-and-delete them.
>>
>> Yes, let's mark them as deprecated now ... if someone still uses them and 
>> speaks up, we can still revert the deprecation again.
> 
> I really would like to be able to use them to validate Linux Kernel changes, 
> hence looking for that missing BIOS.
> 
> If we remove ppc405 from QEMU, we won't be able to do any regression tests 
> of Linux Kernel on those processors.

If you/someone managed to compile an old version of u-boot for one of these 
two boards, so that we would finally have something for regression testing, 
we can of course also keep the boards in QEMU...

  Thomas

Re: Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms)

[David Gibson]

[-- Attachment #1: Type: text/plain, Size: 2428 bytes --]

On Fri, Oct 01, 2021 at 04:18:49PM +0200, Thomas Huth wrote:
> On 01/10/2021 15.04, Christophe Leroy wrote:
> > 
> > 
> > Le 01/10/2021 à 14:04, Thomas Huth a écrit :
> > > On 01/10/2021 13.12, Peter Maydell wrote:
> > > > On Fri, 1 Oct 2021 at 10:43, Thomas Huth <thuth@redhat.com> wrote:
> > > > > Nevertheless, as long as nobody has a hint where to find that
> > > > > ppc405_rom.bin, I think both boards are pretty useless in QEMU (as far as I
> > > > > can see, they do not work without the bios at all, so it's
> > > > > also not possible
> > > > > to use a Linux image with the "-kernel" CLI option directly).
> > > > 
> > > > It is at least in theory possible to run bare-metal code on
> > > > either board, by passing either a pflash or a bios argument.
> > > 
> > > True. I did some more research, and seems like there was once
> > > support for those boards in u-boot, but it got removed there a
> > > couple of years ago already:
> > > 
> > > https://gitlab.com/qemu-project/u-boot/-/commit/98f705c9cefdf
> > > 
> > > https://gitlab.com/qemu-project/u-boot/-/commit/b147ff2f37d5b
> > > 
> > > https://gitlab.com/qemu-project/u-boot/-/commit/7514037bcdc37
> > > 
> > > > But I agree that there seem to be no signs of anybody actually
> > > > successfully using these boards for anything, so we should
> > > > deprecate-and-delete them.
> > > 
> > > Yes, let's mark them as deprecated now ... if someone still uses
> > > them and speaks up, we can still revert the deprecation again.
> > 
> > I really would like to be able to use them to validate Linux Kernel
> > changes, hence looking for that missing BIOS.
> > 
> > If we remove ppc405 from QEMU, we won't be able to do any regression
> > tests of Linux Kernel on those processors.
> 
> If you/someone managed to compile an old version of u-boot for one of these
> two boards, so that we would finally have something for regression testing,
> we can of course also keep the boards in QEMU...

I can see that it would be usefor for some cases, but unless someone
volunteers to track down the necessary firmware and look after it, I
think we do need to deprecate it - I certainly don't have the capacity
to look into this.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms)

[Christophe Leroy]

Le 05/10/2021 à 02:48, David Gibson a écrit :
> On Fri, Oct 01, 2021 at 04:18:49PM +0200, Thomas Huth wrote:
>> On 01/10/2021 15.04, Christophe Leroy wrote:
>>>
>>>
>>> Le 01/10/2021 à 14:04, Thomas Huth a écrit :
>>>> On 01/10/2021 13.12, Peter Maydell wrote:
>>>>> On Fri, 1 Oct 2021 at 10:43, Thomas Huth <thuth@redhat.com> wrote:
>>>>>> Nevertheless, as long as nobody has a hint where to find that
>>>>>> ppc405_rom.bin, I think both boards are pretty useless in QEMU (as far as I
>>>>>> can see, they do not work without the bios at all, so it's
>>>>>> also not possible
>>>>>> to use a Linux image with the "-kernel" CLI option directly).
>>>>>
>>>>> It is at least in theory possible to run bare-metal code on
>>>>> either board, by passing either a pflash or a bios argument.
>>>>
>>>> True. I did some more research, and seems like there was once
>>>> support for those boards in u-boot, but it got removed there a
>>>> couple of years ago already:
>>>>
>>>> https://gitlab.com/qemu-project/u-boot/-/commit/98f705c9cefdf
>>>>
>>>> https://gitlab.com/qemu-project/u-boot/-/commit/b147ff2f37d5b
>>>>
>>>> https://gitlab.com/qemu-project/u-boot/-/commit/7514037bcdc37
>>>>
>>>>> But I agree that there seem to be no signs of anybody actually
>>>>> successfully using these boards for anything, so we should
>>>>> deprecate-and-delete them.
>>>>
>>>> Yes, let's mark them as deprecated now ... if someone still uses
>>>> them and speaks up, we can still revert the deprecation again.
>>>
>>> I really would like to be able to use them to validate Linux Kernel
>>> changes, hence looking for that missing BIOS.
>>>
>>> If we remove ppc405 from QEMU, we won't be able to do any regression
>>> tests of Linux Kernel on those processors.
>>
>> If you/someone managed to compile an old version of u-boot for one of these
>> two boards, so that we would finally have something for regression testing,
>> we can of course also keep the boards in QEMU...
> 
> I can see that it would be usefor for some cases, but unless someone
> volunteers to track down the necessary firmware and look after it, I
> think we do need to deprecate it - I certainly don't have the capacity
> to look into this.
> 

I will look at it, please allow me a few weeks though.

Thanks
Christophe

Re: Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms)

[Alexey Kardashevskiy]

On 05/10/2021 15:44, Christophe Leroy wrote:
> 
> 
> Le 05/10/2021 à 02:48, David Gibson a écrit :
>> On Fri, Oct 01, 2021 at 04:18:49PM +0200, Thomas Huth wrote:
>>> On 01/10/2021 15.04, Christophe Leroy wrote:
>>>>
>>>>
>>>> Le 01/10/2021 à 14:04, Thomas Huth a écrit :
>>>>> On 01/10/2021 13.12, Peter Maydell wrote:
>>>>>> On Fri, 1 Oct 2021 at 10:43, Thomas Huth <thuth@redhat.com> wrote:
>>>>>>> Nevertheless, as long as nobody has a hint where to find that
>>>>>>> ppc405_rom.bin, I think both boards are pretty useless in QEMU 
>>>>>>> (as far as I
>>>>>>> can see, they do not work without the bios at all, so it's
>>>>>>> also not possible
>>>>>>> to use a Linux image with the "-kernel" CLI option directly).
>>>>>>
>>>>>> It is at least in theory possible to run bare-metal code on
>>>>>> either board, by passing either a pflash or a bios argument.
>>>>>
>>>>> True. I did some more research, and seems like there was once
>>>>> support for those boards in u-boot, but it got removed there a
>>>>> couple of years ago already:
>>>>>
>>>>> https://gitlab.com/qemu-project/u-boot/-/commit/98f705c9cefdf
>>>>>
>>>>> https://gitlab.com/qemu-project/u-boot/-/commit/b147ff2f37d5b
>>>>>
>>>>> https://gitlab.com/qemu-project/u-boot/-/commit/7514037bcdc37
>>>>>
>>>>>> But I agree that there seem to be no signs of anybody actually
>>>>>> successfully using these boards for anything, so we should
>>>>>> deprecate-and-delete them.
>>>>>
>>>>> Yes, let's mark them as deprecated now ... if someone still uses
>>>>> them and speaks up, we can still revert the deprecation again.
>>>>
>>>> I really would like to be able to use them to validate Linux Kernel
>>>> changes, hence looking for that missing BIOS.
>>>>
>>>> If we remove ppc405 from QEMU, we won't be able to do any regression
>>>> tests of Linux Kernel on those processors.
>>>
>>> If you/someone managed to compile an old version of u-boot for one of 
>>> these
>>> two boards, so that we would finally have something for regression 
>>> testing,
>>> we can of course also keep the boards in QEMU...
>>
>> I can see that it would be usefor for some cases, but unless someone
>> volunteers to track down the necessary firmware and look after it, I
>> think we do need to deprecate it - I certainly don't have the capacity
>> to look into this.
>>
> 
> I will look at it, please allow me a few weeks though.

Well, building it was not hard but now I'd like to know what board QEMU 
actually emulates, there are way too many codenames and PVRs.

Here is what I was building:
https://github.com/aik/u-boot/tree/ppc4xx-qemu

CONFIG_SYS_ARCH="powerpc"
CONFIG_SYS_CPU="ppc4xx"
CONFIG_SYS_VENDOR="esd"
CONFIG_SYS_BOARD="pmc405de"
CONFIG_SYS_CONFIG_NAME="PMC405DE"

Is this any use?

-- 
Alexey

Re: Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms)

[Thomas Huth]

On 05/10/2021 08.18, Alexey Kardashevskiy wrote:
> 
> 
> On 05/10/2021 15:44, Christophe Leroy wrote:
>>
>>
>> Le 05/10/2021 à 02:48, David Gibson a écrit :
>>> On Fri, Oct 01, 2021 at 04:18:49PM +0200, Thomas Huth wrote:
>>>> On 01/10/2021 15.04, Christophe Leroy wrote:
>>>>>
>>>>>
>>>>> Le 01/10/2021 à 14:04, Thomas Huth a écrit :
>>>>>> On 01/10/2021 13.12, Peter Maydell wrote:
>>>>>>> On Fri, 1 Oct 2021 at 10:43, Thomas Huth <thuth@redhat.com> wrote:
>>>>>>>> Nevertheless, as long as nobody has a hint where to find that
>>>>>>>> ppc405_rom.bin, I think both boards are pretty useless in QEMU (as 
>>>>>>>> far as I
>>>>>>>> can see, they do not work without the bios at all, so it's
>>>>>>>> also not possible
>>>>>>>> to use a Linux image with the "-kernel" CLI option directly).
>>>>>>>
>>>>>>> It is at least in theory possible to run bare-metal code on
>>>>>>> either board, by passing either a pflash or a bios argument.
>>>>>>
>>>>>> True. I did some more research, and seems like there was once
>>>>>> support for those boards in u-boot, but it got removed there a
>>>>>> couple of years ago already:
>>>>>>
>>>>>> https://gitlab.com/qemu-project/u-boot/-/commit/98f705c9cefdf
>>>>>>
>>>>>> https://gitlab.com/qemu-project/u-boot/-/commit/b147ff2f37d5b
>>>>>>
>>>>>> https://gitlab.com/qemu-project/u-boot/-/commit/7514037bcdc37
>>>>>>
>>>>>>> But I agree that there seem to be no signs of anybody actually
>>>>>>> successfully using these boards for anything, so we should
>>>>>>> deprecate-and-delete them.
>>>>>>
>>>>>> Yes, let's mark them as deprecated now ... if someone still uses
>>>>>> them and speaks up, we can still revert the deprecation again.
>>>>>
>>>>> I really would like to be able to use them to validate Linux Kernel
>>>>> changes, hence looking for that missing BIOS.
>>>>>
>>>>> If we remove ppc405 from QEMU, we won't be able to do any regression
>>>>> tests of Linux Kernel on those processors.
>>>>
>>>> If you/someone managed to compile an old version of u-boot for one of these
>>>> two boards, so that we would finally have something for regression testing,
>>>> we can of course also keep the boards in QEMU...
>>>
>>> I can see that it would be usefor for some cases, but unless someone
>>> volunteers to track down the necessary firmware and look after it, I
>>> think we do need to deprecate it - I certainly don't have the capacity
>>> to look into this.
>>>
>>
>> I will look at it, please allow me a few weeks though.
> 
> Well, building it was not hard but now I'd like to know what board QEMU 
> actually emulates, there are way too many codenames and PVRs.
> 
> Here is what I was building:
> https://github.com/aik/u-boot/tree/ppc4xx-qemu
> 
> CONFIG_SYS_ARCH="powerpc"
> CONFIG_SYS_CPU="ppc4xx"
> CONFIG_SYS_VENDOR="esd"
> CONFIG_SYS_BOARD="pmc405de"
> CONFIG_SYS_CONFIG_NAME="PMC405DE"
> 
> Is this any use?

If I've got u-boot commit 98f705c9cefdfdba62c069821bbba10273a0a8
right, there used to be SYS_BOARD="405ep" config before that removal, so 
that sounds like a promising match for the ref405ep of QEMU?

The support for "taihu" even got removed earlier, in u-boot commit 
123b6cd7a4f75536734a7bff97db6eebce614bd1 , and the commit message says that 
it did not compile anymore at the end, so you might need to check out an 
even older version for that one.

  Thomas

Re: Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms)

[Alexey Kardashevskiy]

On 05/10/2021 17:42, Thomas Huth wrote:
> On 05/10/2021 08.18, Alexey Kardashevskiy wrote:
>>
>>
>> On 05/10/2021 15:44, Christophe Leroy wrote:
>>>
>>>
>>> Le 05/10/2021 à 02:48, David Gibson a écrit :
>>>> On Fri, Oct 01, 2021 at 04:18:49PM +0200, Thomas Huth wrote:
>>>>> On 01/10/2021 15.04, Christophe Leroy wrote:
>>>>>>
>>>>>>
>>>>>> Le 01/10/2021 à 14:04, Thomas Huth a écrit :
>>>>>>> On 01/10/2021 13.12, Peter Maydell wrote:
>>>>>>>> On Fri, 1 Oct 2021 at 10:43, Thomas Huth <thuth@redhat.com> wrote:
>>>>>>>>> Nevertheless, as long as nobody has a hint where to find that
>>>>>>>>> ppc405_rom.bin, I think both boards are pretty useless in QEMU 
>>>>>>>>> (as far as I
>>>>>>>>> can see, they do not work without the bios at all, so it's
>>>>>>>>> also not possible
>>>>>>>>> to use a Linux image with the "-kernel" CLI option directly).
>>>>>>>>
>>>>>>>> It is at least in theory possible to run bare-metal code on
>>>>>>>> either board, by passing either a pflash or a bios argument.
>>>>>>>
>>>>>>> True. I did some more research, and seems like there was once
>>>>>>> support for those boards in u-boot, but it got removed there a
>>>>>>> couple of years ago already:
>>>>>>>
>>>>>>> https://gitlab.com/qemu-project/u-boot/-/commit/98f705c9cefdf
>>>>>>>
>>>>>>> https://gitlab.com/qemu-project/u-boot/-/commit/b147ff2f37d5b
>>>>>>>
>>>>>>> https://gitlab.com/qemu-project/u-boot/-/commit/7514037bcdc37
>>>>>>>
>>>>>>>> But I agree that there seem to be no signs of anybody actually
>>>>>>>> successfully using these boards for anything, so we should
>>>>>>>> deprecate-and-delete them.
>>>>>>>
>>>>>>> Yes, let's mark them as deprecated now ... if someone still uses
>>>>>>> them and speaks up, we can still revert the deprecation again.
>>>>>>
>>>>>> I really would like to be able to use them to validate Linux Kernel
>>>>>> changes, hence looking for that missing BIOS.
>>>>>>
>>>>>> If we remove ppc405 from QEMU, we won't be able to do any regression
>>>>>> tests of Linux Kernel on those processors.
>>>>>
>>>>> If you/someone managed to compile an old version of u-boot for one 
>>>>> of these
>>>>> two boards, so that we would finally have something for regression 
>>>>> testing,
>>>>> we can of course also keep the boards in QEMU...
>>>>
>>>> I can see that it would be usefor for some cases, but unless someone
>>>> volunteers to track down the necessary firmware and look after it, I
>>>> think we do need to deprecate it - I certainly don't have the capacity
>>>> to look into this.
>>>>
>>>
>>> I will look at it, please allow me a few weeks though.
>>
>> Well, building it was not hard but now I'd like to know what board 
>> QEMU actually emulates, there are way too many codenames and PVRs.
>>
>> Here is what I was building:
>> https://github.com/aik/u-boot/tree/ppc4xx-qemu
>>
>> CONFIG_SYS_ARCH="powerpc"
>> CONFIG_SYS_CPU="ppc4xx"
>> CONFIG_SYS_VENDOR="esd"
>> CONFIG_SYS_BOARD="pmc405de"
>> CONFIG_SYS_CONFIG_NAME="PMC405DE"
>>
>> Is this any use?
> 
> If I've got u-boot commit 98f705c9cefdfdba62c069821bbba10273a0a8
> right, there used to be SYS_BOARD="405ep" config before that removal, so 
> that sounds like a promising match for the ref405ep of QEMU?

Tricky. The board can be 405ep if 
TARGET_IO/TARGET_DLVISION/TARGET_DLVISION_10G selected. Neither compiles 
at 98f705c9cefdfdba62c^ due to missing CONFIG_SYS_PCI_PTM1PCI :-/

> 
> The support for "taihu" even got removed earlier, in u-boot commit 
> 123b6cd7a4f75536734a7bff97db6eebce614bd1 , and the commit message says 
> that it did not compile anymore at the end, so you might need to check 
> out an even older version for that one.


What is so special about taihu?



-- 
Alexey

Re: Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms)

[Thomas Huth]

On 05/10/2021 10.05, Alexey Kardashevskiy wrote:
> 
> 
> On 05/10/2021 17:42, Thomas Huth wrote:
>> On 05/10/2021 08.18, Alexey Kardashevskiy wrote:
>>>
>>>
>>> On 05/10/2021 15:44, Christophe Leroy wrote:
>>>>
>>>>
>>>> Le 05/10/2021 à 02:48, David Gibson a écrit :
>>>>> On Fri, Oct 01, 2021 at 04:18:49PM +0200, Thomas Huth wrote:
>>>>>> On 01/10/2021 15.04, Christophe Leroy wrote:
>>>>>>>
>>>>>>>
>>>>>>> Le 01/10/2021 à 14:04, Thomas Huth a écrit :
>>>>>>>> On 01/10/2021 13.12, Peter Maydell wrote:
>>>>>>>>> On Fri, 1 Oct 2021 at 10:43, Thomas Huth <thuth@redhat.com> wrote:
>>>>>>>>>> Nevertheless, as long as nobody has a hint where to find that
>>>>>>>>>> ppc405_rom.bin, I think both boards are pretty useless in QEMU (as 
>>>>>>>>>> far as I
>>>>>>>>>> can see, they do not work without the bios at all, so it's
>>>>>>>>>> also not possible
>>>>>>>>>> to use a Linux image with the "-kernel" CLI option directly).
>>>>>>>>>
>>>>>>>>> It is at least in theory possible to run bare-metal code on
>>>>>>>>> either board, by passing either a pflash or a bios argument.
>>>>>>>>
>>>>>>>> True. I did some more research, and seems like there was once
>>>>>>>> support for those boards in u-boot, but it got removed there a
>>>>>>>> couple of years ago already:
>>>>>>>>
>>>>>>>> https://gitlab.com/qemu-project/u-boot/-/commit/98f705c9cefdf
>>>>>>>>
>>>>>>>> https://gitlab.com/qemu-project/u-boot/-/commit/b147ff2f37d5b
>>>>>>>>
>>>>>>>> https://gitlab.com/qemu-project/u-boot/-/commit/7514037bcdc37
>>>>>>>>
>>>>>>>>> But I agree that there seem to be no signs of anybody actually
>>>>>>>>> successfully using these boards for anything, so we should
>>>>>>>>> deprecate-and-delete them.
>>>>>>>>
>>>>>>>> Yes, let's mark them as deprecated now ... if someone still uses
>>>>>>>> them and speaks up, we can still revert the deprecation again.
>>>>>>>
>>>>>>> I really would like to be able to use them to validate Linux Kernel
>>>>>>> changes, hence looking for that missing BIOS.
>>>>>>>
>>>>>>> If we remove ppc405 from QEMU, we won't be able to do any regression
>>>>>>> tests of Linux Kernel on those processors.
>>>>>>
>>>>>> If you/someone managed to compile an old version of u-boot for one of 
>>>>>> these
>>>>>> two boards, so that we would finally have something for regression 
>>>>>> testing,
>>>>>> we can of course also keep the boards in QEMU...
>>>>>
>>>>> I can see that it would be usefor for some cases, but unless someone
>>>>> volunteers to track down the necessary firmware and look after it, I
>>>>> think we do need to deprecate it - I certainly don't have the capacity
>>>>> to look into this.
>>>>>
>>>>
>>>> I will look at it, please allow me a few weeks though.
>>>
>>> Well, building it was not hard but now I'd like to know what board QEMU 
>>> actually emulates, there are way too many codenames and PVRs.
>>>
>>> Here is what I was building:
>>> https://github.com/aik/u-boot/tree/ppc4xx-qemu
>>>
>>> CONFIG_SYS_ARCH="powerpc"
>>> CONFIG_SYS_CPU="ppc4xx"
>>> CONFIG_SYS_VENDOR="esd"
>>> CONFIG_SYS_BOARD="pmc405de"
>>> CONFIG_SYS_CONFIG_NAME="PMC405DE"
>>>
>>> Is this any use?
>>
>> If I've got u-boot commit 98f705c9cefdfdba62c069821bbba10273a0a8
>> right, there used to be SYS_BOARD="405ep" config before that removal, so 
>> that sounds like a promising match for the ref405ep of QEMU?
> 
> Tricky. The board can be 405ep if 
> TARGET_IO/TARGET_DLVISION/TARGET_DLVISION_10G selected. Neither compiles at 
> 98f705c9cefdfdba62c^ due to missing CONFIG_SYS_PCI_PTM1PCI :-/
> 
>>
>> The support for "taihu" even got removed earlier, in u-boot commit 
>> 123b6cd7a4f75536734a7bff97db6eebce614bd1 , and the commit message says 
>> that it did not compile anymore at the end, so you might need to check out 
>> an even older version for that one.
> 
> 
> What is so special about taihu?

taihu is the other 405 board defined in hw/ppc/ppc405_boards.c (which I 
suggested to deprecate now)

  Thomas

Re: Deprecate the ppc405 boards in QEMU?

[Thomas Huth]

On 05/10/2021 10.07, Thomas Huth wrote:
> On 05/10/2021 10.05, Alexey Kardashevskiy wrote:
[...]
>> What is so special about taihu?
> 
> taihu is the other 405 board defined in hw/ppc/ppc405_boards.c (which I 
> suggested to deprecate now)

I've now also played with the u-boot sources a little bit, and with some bit 
of tweaking, it's indeed possible to compile the old taihu board there. 
However, it does not really work with QEMU anymore, it immediately triggers 
an assert():

$ qemu-system-ppc -M taihu -bios u-boot.bin -serial null -serial mon:stdio
**
ERROR:accel/tcg/tcg-accel-ops.c:79:tcg_handle_interrupt: assertion failed: 
(qemu_mutex_iothread_locked())
Aborted (core dumped)

Going back to QEMU v2.3.0, I can see at least a little bit of output, but it 
then also triggers an assert() during DRAM initialization:

$ qemu-system-ppc -M taihu -bios u-boot.bin -serial null -serial mon:stdio

Reset PowerPC core

U-Boot 2014.10-rc2-00123-g461be2f96e-dirty (Oct 05 2021 - 10:02:56)

CPU:   AMCC PowerPC 405EP Rev. B at 770 MHz (PLB=256 OPB=128 EBC=128)
        I2C boot EEPROM disabled
        Internal PCI arbiter enabled
        16 KiB I-Cache 16 KiB D-Cache
Board: Taihu - AMCC PPC405EP Evaluation Board
I2C:   ready
DRAM:  qemu-system-ppc: memory.c:1693: memory_region_del_subregion: 
Assertion `subregion->container == mr' failed.
Aborted (core dumped)

Not sure if this ever worked in QEMU, maybe in the early 0.15 time, but that 
version of QEMU also does not compile easily anymore on modern systems. So 
I'm afraid, getting this into a workable shape again will take a lot of 
time. At least I'll stop my efforts here now.

  Thomas

Re: Deprecate the ppc405 boards in QEMU?

[BALATON Zoltan]

On Tue, 5 Oct 2021, Thomas Huth wrote:
> On 05/10/2021 10.07, Thomas Huth wrote:
>> On 05/10/2021 10.05, Alexey Kardashevskiy wrote:
> [...]
>>> What is so special about taihu?
>> 
>> taihu is the other 405 board defined in hw/ppc/ppc405_boards.c (which I 
>> suggested to deprecate now)
>
> I've now also played with the u-boot sources a little bit, and with some bit 
> of tweaking, it's indeed possible to compile the old taihu board there. 
> However, it does not really work with QEMU anymore, it immediately triggers 
> an assert():
>
> $ qemu-system-ppc -M taihu -bios u-boot.bin -serial null -serial mon:stdio
> **
> ERROR:accel/tcg/tcg-accel-ops.c:79:tcg_handle_interrupt: assertion failed: 
> (qemu_mutex_iothread_locked())
> Aborted (core dumped)

Maybe it's similar to this: 2025fc6766ab25501e0041c564c44bb0f7389774 The 
helper_load_dcr() and helper_store_dcr() in target/ppc/timebase_helper.c 
seem to lock/unlock the iothread but I'm not sure if that's necessary. 
Also not sure why this does not happen with 460ex but that maybe uses 
different code.

> Going back to QEMU v2.3.0, I can see at least a little bit of output, but it 
> then also triggers an assert() during DRAM initialization:
>
> $ qemu-system-ppc -M taihu -bios u-boot.bin -serial null -serial mon:stdio
>
> Reset PowerPC core
>
> U-Boot 2014.10-rc2-00123-g461be2f96e-dirty (Oct 05 2021 - 10:02:56)
>
> CPU:   AMCC PowerPC 405EP Rev. B at 770 MHz (PLB=256 OPB=128 EBC=128)
>       I2C boot EEPROM disabled
>       Internal PCI arbiter enabled
>       16 KiB I-Cache 16 KiB D-Cache
> Board: Taihu - AMCC PPC405EP Evaluation Board
> I2C:   ready
> DRAM:  qemu-system-ppc: memory.c:1693: memory_region_del_subregion: Assertion 
> `subregion->container == mr' failed.
> Aborted (core dumped)
>
> Not sure if this ever worked in QEMU, maybe in the early 0.15 time, but that 
> version of QEMU also does not compile easily anymore on modern systems. So 
> I'm afraid, getting this into a workable shape again will take a lot of time. 
> At least I'll stop my efforts here now.

Do you have this u-boot binary somewhere just for others who want to try it?

Regards,
BALATON Zoltan

Re: Deprecate the ppc405 boards in QEMU?

[Thomas Huth]

On 05/10/2021 14.17, BALATON Zoltan wrote:
> On Tue, 5 Oct 2021, Thomas Huth wrote:
>> On 05/10/2021 10.07, Thomas Huth wrote:
>>> On 05/10/2021 10.05, Alexey Kardashevskiy wrote:
>> [...]
>>>> What is so special about taihu?
>>>
>>> taihu is the other 405 board defined in hw/ppc/ppc405_boards.c (which I 
>>> suggested to deprecate now)
>>
>> I've now also played with the u-boot sources a little bit, and with some 
>> bit of tweaking, it's indeed possible to compile the old taihu board 
>> there. However, it does not really work with QEMU anymore, it immediately 
>> triggers an assert():
>>
>> $ qemu-system-ppc -M taihu -bios u-boot.bin -serial null -serial mon:stdio
>> **
>> ERROR:accel/tcg/tcg-accel-ops.c:79:tcg_handle_interrupt: assertion failed: 
>> (qemu_mutex_iothread_locked())
>> Aborted (core dumped)
> 
> Maybe it's similar to this: 2025fc6766ab25501e0041c564c44bb0f7389774 The 
> helper_load_dcr() and helper_store_dcr() in target/ppc/timebase_helper.c 
> seem to lock/unlock the iothread but I'm not sure if that's necessary. Also 
> not sure why this does not happen with 460ex but that maybe uses different 
> code.

It's rather the other way round, the locking is missing here instead. I can 
get the serial output with the current QEMU when I add the following patch 
(not sure whether that's the right spot, though):

diff --git a/hw/ppc/ppc.c b/hw/ppc/ppc.c
index f5d012f860..bb57f1c9ed 100644
--- a/hw/ppc/ppc.c
+++ b/hw/ppc/ppc.c
@@ -336,6 +336,8 @@ void store_40x_dbcr0(CPUPPCState *env, uint32_t val)
  {
      PowerPCCPU *cpu = env_archcpu(env);

+    qemu_mutex_lock_iothread();
+
      switch ((val >> 28) & 0x3) {
      case 0x0:
          /* No action */
@@ -353,6 +355,8 @@ void store_40x_dbcr0(CPUPPCState *env, uint32_t val)
          ppc40x_system_reset(cpu);
          break;
      }
+
+    qemu_mutex_unlock_iothread();
  }

  /* PowerPC 40x internal IRQ controller */


>> Going back to QEMU v2.3.0, I can see at least a little bit of output, but 
>> it then also triggers an assert() during DRAM initialization:
>>
>> $ qemu-system-ppc -M taihu -bios u-boot.bin -serial null -serial mon:stdio
>>
>> Reset PowerPC core
>>
>> U-Boot 2014.10-rc2-00123-g461be2f96e-dirty (Oct 05 2021 - 10:02:56)
>>
>> CPU:   AMCC PowerPC 405EP Rev. B at 770 MHz (PLB=256 OPB=128 EBC=128)
>>       I2C boot EEPROM disabled
>>       Internal PCI arbiter enabled
>>       16 KiB I-Cache 16 KiB D-Cache
>> Board: Taihu - AMCC PPC405EP Evaluation Board
>> I2C:   ready
>> DRAM:  qemu-system-ppc: memory.c:1693: memory_region_del_subregion: 
>> Assertion `subregion->container == mr' failed.
>> Aborted (core dumped)
>>
>> Not sure if this ever worked in QEMU, maybe in the early 0.15 time, but 
>> that version of QEMU also does not compile easily anymore on modern 
>> systems. So I'm afraid, getting this into a workable shape again will take 
>> a lot of time. At least I'll stop my efforts here now.
> 
> Do you have this u-boot binary somewhere just for others who want to try it?

FWIW:
http://people.redhat.com/~thuth/data/u-boot-taihu.bin

  Thomas

Re: Deprecate the ppc405 boards in QEMU?

[BALATON Zoltan]

[-- Attachment #1: Type: text/plain, Size: 6540 bytes --]

On Tue, 5 Oct 2021, Thomas Huth wrote:
> On 05/10/2021 14.17, BALATON Zoltan wrote:
>> On Tue, 5 Oct 2021, Thomas Huth wrote:
>>> On 05/10/2021 10.07, Thomas Huth wrote:
>>>> On 05/10/2021 10.05, Alexey Kardashevskiy wrote:
>>> [...]
>>>>> What is so special about taihu?
>>>> 
>>>> taihu is the other 405 board defined in hw/ppc/ppc405_boards.c (which I 
>>>> suggested to deprecate now)
>>> 
>>> I've now also played with the u-boot sources a little bit, and with some 
>>> bit of tweaking, it's indeed possible to compile the old taihu board 
>>> there. However, it does not really work with QEMU anymore, it immediately 
>>> triggers an assert():
>>> 
>>> $ qemu-system-ppc -M taihu -bios u-boot.bin -serial null -serial mon:stdio
>>> **
>>> ERROR:accel/tcg/tcg-accel-ops.c:79:tcg_handle_interrupt: assertion failed: 
>>> (qemu_mutex_iothread_locked())
>>> Aborted (core dumped)
>> 
>> Maybe it's similar to this: 2025fc6766ab25501e0041c564c44bb0f7389774 The 
>> helper_load_dcr() and helper_store_dcr() in target/ppc/timebase_helper.c 
>> seem to lock/unlock the iothread but I'm not sure if that's necessary. Also 
>> not sure why this does not happen with 460ex but that maybe uses different 
>> code.
>
> It's rather the other way round, the locking is missing here instead. I can 
> get the serial output with the current QEMU when I add the following patch 
> (not sure whether that's the right spot, though):
>
> diff --git a/hw/ppc/ppc.c b/hw/ppc/ppc.c
> index f5d012f860..bb57f1c9ed 100644
> --- a/hw/ppc/ppc.c
> +++ b/hw/ppc/ppc.c
> @@ -336,6 +336,8 @@ void store_40x_dbcr0(CPUPPCState *env, uint32_t val)
> {
>     PowerPCCPU *cpu = env_archcpu(env);
>
> +    qemu_mutex_lock_iothread();
> +
>     switch ((val >> 28) & 0x3) {
>     case 0x0:
>         /* No action */
> @@ -353,6 +355,8 @@ void store_40x_dbcr0(CPUPPCState *env, uint32_t val)
>         ppc40x_system_reset(cpu);
>         break;
>     }
> +
> +    qemu_mutex_unlock_iothread();
> }
>
> /* PowerPC 40x internal IRQ controller */
>
>
>>> Going back to QEMU v2.3.0, I can see at least a little bit of output, but 
>>> it then also triggers an assert() during DRAM initialization:
>>> 
>>> $ qemu-system-ppc -M taihu -bios u-boot.bin -serial null -serial mon:stdio
>>> 
>>> Reset PowerPC core
>>> 
>>> U-Boot 2014.10-rc2-00123-g461be2f96e-dirty (Oct 05 2021 - 10:02:56)
>>> 
>>> CPU:   AMCC PowerPC 405EP Rev. B at 770 MHz (PLB=256 OPB=128 EBC=128)
>>>       I2C boot EEPROM disabled
>>>       Internal PCI arbiter enabled
>>>       16 KiB I-Cache 16 KiB D-Cache
>>> Board: Taihu - AMCC PPC405EP Evaluation Board
>>> I2C:   ready
>>> DRAM:  qemu-system-ppc: memory.c:1693: memory_region_del_subregion: 
>>> Assertion `subregion->container == mr' failed.
>>> Aborted (core dumped)

The assert can be avoided with this patch:

diff --git a/hw/ppc/ppc4xx_devs.c b/hw/ppc/ppc4xx_devs.c
index 980c48944f..3a4a094772 100644
--- a/hw/ppc/ppc4xx_devs.c
+++ b/hw/ppc/ppc4xx_devs.c
@@ -169,7 +170,8 @@ static target_ulong sdram_size (uint32_t bcr)
  static void sdram_set_bcr(ppc4xx_sdram_t *sdram, int i,
                            uint32_t bcr, int enabled)
  {
-    if (sdram->bcr[i] & 0x00000001) {
+    if (sdram->bcr[i] & 0x00000001 &&
+        memory_region_is_mapped(&sdram->containers[i])) {
          /* Unmap RAM */
  #ifdef DEBUG_SDRAM
          printf("%s: unmap RAM area " TARGET_FMT_plx " " TARGET_FMT_lx "\n",
@@ -220,8 +222,7 @@ static void sdram_unmap_bcr (ppc4xx_sdram_t *sdram)
          printf("%s: Unmap RAM area " TARGET_FMT_plx " " TARGET_FMT_lx "\n",
                 __func__, sdram_base(sdram->bcr[i]), sdram_size(sdram->bcr[i]));
  #endif
-        memory_region_del_subregion(get_system_memory(),
-                                    &sdram->ram_memories[i]);
+        sdram_set_bcr(sdram, i, 0x00000000, 0);
      }
  }


which then detects 128MiB RAM but leaves the controller disabled and thus 
RAM unmapped then it does not continue (not sure if because of disabled 
SDRAM controller or some other reason). I get this with #define DEBUG_SDRAM:

Board: Taihu - AMCC PPC405EP Evaluation Board
I2C:   ready
DRAM:  dcr_write_sdram: enable SDRAM controller
sdram_set_bcr: Map RAM area 0000000000000000 04000000
sdram_set_bcr: Map RAM area 0000000004000000 04000000
dcr_write_sdram: disable SDRAM controller
sdram_unmap_bcr: Unmap RAM area 0000000000000000 04000000
sdram_set_bcr: unmap RAM area 0000000000000000 04000000
sdram_unmap_bcr: Unmap RAM area 0000000004000000 04000000
sdram_set_bcr: unmap RAM area 0000000004000000 04000000
dcr_write_sdram: enable SDRAM controller
sdram_set_bcr: Map RAM area 0000000000000000 04000000
sdram_set_bcr: Map RAM area 0000000004000000 04000000
sdram_set_bcr: unmap RAM area 0000000004000000 04000000
dcr_write_sdram: disable SDRAM controller
sdram_unmap_bcr: Unmap RAM area 0000000000000000 04000000
sdram_set_bcr: unmap RAM area 0000000000000000 04000000
sdram_unmap_bcr: Unmap RAM area 0000000000000000 00400000
128 MiB

If this is simliar to the sam460ex u-boot then AFAIR that looks for SPD 
data from memory modules and sets up RAM according to those at this point 
(probably the same here as there's an i2c init before DRAM) then also runs 
some speed calibration routine that may need more registers emulated for 
the SDRAM controller. We have very similar code for the PPC440 based 460ex 
in ppc440_uc that I think I've copied from this and modified to work with 
the sam460ex u-boot. This could be cleaned up to share common code more 
but these may have slightly different registers and the bcr value is 
different too which is dependent on the supported memory sizes that are 
different between the two SoCs.

Maybe these 405 boards in QEMU ran with modified firmware where the memory 
detection was patched out but it seems to detect the RAM so I wonder where 
it gets that from. Maybe by reading the SDRAM controller DCRs 
ppc4xx_sdram_init() sets up. Then I'm not sure what it needs the SPD for, 
I forgot how this worked on sam460ex. Maybe for the speed calibration, so 
could be it detects ram by reading DCRs then tries to get SPD data and 
that's where it stops as i2c is not emulated on taihu. This could be 
confirmed by checking what it pokes with -d guest_errors that shows 
accesses to missing devices but don't know where 405 has the i2c 
controller and if it's the same as newer SoCs. If so that could be reused 
and an i2c bus could be added with the SPD data like in sam460ex to make 
u-boot happy or you could skip this in u-boot.

Regards,
BALATON Zoltan

Re: Deprecate the ppc405 boards in QEMU?

[Thomas Huth]

On 05/10/2021 23.53, BALATON Zoltan wrote:
[...]
> Maybe these 405 boards in QEMU ran with modified firmware where the memory 
> detection was patched out
I guess you're right - the code also expects a file called ppc405_rom.bin, 
and not u-boot.bin, so this board was likely used with a completely 
different firmware (which is not available anymore), not with u-boot...

  Thomas

Re: Deprecate the ppc405 boards in QEMU?

[Thomas Huth]

[-- Attachment #1: Type: text/plain, Size: 1732 bytes --]

On 05/10/2021 23.53, BALATON Zoltan wrote:
[...]
> Maybe these 405 boards in QEMU ran with modified firmware where the memory 
> detection was patched out but it seems to detect the RAM so I wonder where 
> it gets that from. Maybe by reading the SDRAM controller DCRs 
> ppc4xx_sdram_init() sets up. Then I'm not sure what it needs the SPD for, I 
> forgot how this worked on sam460ex. Maybe for the speed calibration, so 
> could be it detects ram by reading DCRs then tries to get SPD data and 
> that's where it stops as i2c is not emulated on taihu. This could be 
> confirmed by checking what it pokes with -d guest_errors that shows accesses 
> to missing devices but don't know where 405 has the i2c controller and if 
> it's the same as newer SoCs. If so that could be reused and an i2c bus could 
> be added with the SPD data like in sam460ex to make u-boot happy or you 
> could skip this in u-boot.

FWIW, I've just tried the latter (skipping the sdram init in u-boot), and 
indeed, I can get to the u-boot prompt now. Binary can be found here:

  http://people.redhat.com/~thuth/data/u-boot-taihu-skip-sdram.bin

Christophe, maybe that's already enough for you to boot a Linux kernel with 
the "taihu" board? (or do you need the ref405ep board instead?)

I've also attached the patch with my modifications to u-boot.

To build the u-boot firmware:

  git clone git://git.denx.de/u-boot.git
  cd u-boot
  git checkout 123b6cd7a4f75536734a7bff97db6eebce614bd1~1
  patch -p1 -i .../u-boot-taihu.patch
  make taihu_defconfig CROSS_COMPILE=powerpc-...
  make CROSS_COMPILE=powerpc-...

... if the linker complains at the end, remove some features from the 
".config" file, like CONFIG_CMD_NFS, and run make again.

  Thomas

[-- Attachment #2: u-boot-taihu.patch --]
[-- Type: text/x-patch, Size: 11223 bytes --]

diff --git a/arch/powerpc/cpu/ppc4xx/sdram.c b/arch/powerpc/cpu/ppc4xx/sdram.c
index d4ef36d39f..729f69f5c2 100644
--- a/arch/powerpc/cpu/ppc4xx/sdram.c
+++ b/arch/powerpc/cpu/ppc4xx/sdram.c
@@ -172,14 +172,13 @@ phys_size_t initdram(int board_type)
 		/*
 		 * Disable memory controller.
 		 */
-		mtsdram(SDRAM0_CFG, 0x00000000);
-
+//		mtsdram(SDRAM0_CFG, 0x00000000);
 		/*
 		 * Set MB0CF for bank 0.
 		 */
-		mtsdram(SDRAM0_B0CR, mb0cf[i].reg);
-		mtsdram(SDRAM0_TR, sdtr1);
-		mtsdram(SDRAM0_RTR, compute_rtr(speed, mb0cf[i].rows, 64));
+//		mtsdram(SDRAM0_B0CR, mb0cf[i].reg);
+//		mtsdram(SDRAM0_TR, sdtr1);
+//		mtsdram(SDRAM0_RTR, compute_rtr(speed, mb0cf[i].rows, 64));
 
 		udelay(200);
 
@@ -199,7 +198,7 @@ phys_size_t initdram(int board_type)
 			 * OK, size detected.  Enable second bank if
 			 * defined (assumes same type as bank 0)
 			 */
-#ifdef CONFIG_SDRAM_BANK1
+#if 0 //def CONFIG_SDRAM_BANK1
 			mtsdram(SDRAM0_CFG, 0x00000000);
 			mtsdram(SDRAM0_B1CR, mb0cf[i].size | mb0cf[i].reg);
 			mtsdram(SDRAM0_CFG, 0x80800000);
@@ -230,7 +229,7 @@ phys_size_t initdram(int board_type)
 		}
 	}
 
-	return 0;
+	return 128*1024*1024; /* Hack */
 }
 
 #else /* CONFIG_440 */
diff --git a/arch/powerpc/cpu/ppc4xx/u-boot.lds b/arch/powerpc/cpu/ppc4xx/u-boot.lds
index 198050853a..55dd4e1300 100644
--- a/arch/powerpc/cpu/ppc4xx/u-boot.lds
+++ b/arch/powerpc/cpu/ppc4xx/u-boot.lds
@@ -46,7 +46,6 @@ SECTIONS
     _GOT2_TABLE_ = .;
     KEEP(*(.got2))
     KEEP(*(.got))
-    PROVIDE(_GLOBAL_OFFSET_TABLE_ = . + 4);
     _FIXUP_TABLE_ = .;
     KEEP(*(.fixup))
   }
diff --git a/arch/powerpc/include/asm/bitops.h b/arch/powerpc/include/asm/bitops.h
index a6bcf3c3fe..4aba02a031 100644
--- a/arch/powerpc/include/asm/bitops.h
+++ b/arch/powerpc/include/asm/bitops.h
@@ -7,12 +7,14 @@
 
 #include <asm/byteorder.h>
 
+/*
 extern void set_bit(int nr, volatile void *addr);
 extern void clear_bit(int nr, volatile void *addr);
 extern void change_bit(int nr, volatile void *addr);
 extern int test_and_set_bit(int nr, volatile void *addr);
 extern int test_and_clear_bit(int nr, volatile void *addr);
 extern int test_and_change_bit(int nr, volatile void *addr);
+*/
 
 /*
  * Arguably these bit operations don't imply any memory barrier or
@@ -34,7 +36,7 @@ extern int test_and_change_bit(int nr, volatile void *addr);
  * These used to be if'd out here because using : "cc" as a constraint
  * resulted in errors from egcs.  Things may be OK with gcc-2.95.
  */
-extern __inline__ void set_bit(int nr, volatile void * addr)
+static __inline__ void set_bit(int nr, volatile void * addr)
 {
 	unsigned long old;
 	unsigned long mask = 1 << (nr & 0x1f);
@@ -51,7 +53,7 @@ extern __inline__ void set_bit(int nr, volatile void * addr)
 	: "cc" );
 }
 
-extern __inline__ void clear_bit(int nr, volatile void *addr)
+static __inline__ void clear_bit(int nr, volatile void *addr)
 {
 	unsigned long old;
 	unsigned long mask = 1 << (nr & 0x1f);
@@ -68,7 +70,7 @@ extern __inline__ void clear_bit(int nr, volatile void *addr)
 	: "cc");
 }
 
-extern __inline__ void change_bit(int nr, volatile void *addr)
+static __inline__ void change_bit(int nr, volatile void *addr)
 {
 	unsigned long old;
 	unsigned long mask = 1 << (nr & 0x1f);
@@ -85,7 +87,7 @@ extern __inline__ void change_bit(int nr, volatile void *addr)
 	: "cc");
 }
 
-extern __inline__ int test_and_set_bit(int nr, volatile void *addr)
+static __inline__  int test_and_set_bit(int nr, volatile void *addr)
 {
 	unsigned int old, t;
 	unsigned int mask = 1 << (nr & 0x1f);
@@ -104,7 +106,7 @@ extern __inline__ int test_and_set_bit(int nr, volatile void *addr)
 	return (old & mask) != 0;
 }
 
-extern __inline__ int test_and_clear_bit(int nr, volatile void *addr)
+static __inline__  int test_and_clear_bit(int nr, volatile void *addr)
 {
 	unsigned int old, t;
 	unsigned int mask = 1 << (nr & 0x1f);
@@ -123,7 +125,7 @@ extern __inline__ int test_and_clear_bit(int nr, volatile void *addr)
 	return (old & mask) != 0;
 }
 
-extern __inline__ int test_and_change_bit(int nr, volatile void *addr)
+static __inline__  int test_and_change_bit(int nr, volatile void *addr)
 {
 	unsigned int old, t;
 	unsigned int mask = 1 << (nr & 0x1f);
@@ -143,7 +145,7 @@ extern __inline__ int test_and_change_bit(int nr, volatile void *addr)
 }
 #endif /* __INLINE_BITOPS */
 
-extern __inline__ int test_bit(int nr, __const__ volatile void *addr)
+static __inline__  int test_bit(int nr, __const__ volatile void *addr)
 {
 	__const__ unsigned int *p = (__const__ unsigned int *) addr;
 
@@ -152,7 +154,7 @@ extern __inline__ int test_bit(int nr, __const__ volatile void *addr)
 
 /* Return the bit position of the most significant 1 bit in a word */
 /* - the result is undefined when x == 0 */
-extern __inline__ int __ilog2(unsigned int x)
+static __inline__  int __ilog2(unsigned int x)
 {
 	int lz;
 
@@ -160,7 +162,7 @@ extern __inline__ int __ilog2(unsigned int x)
 	return 31 - lz;
 }
 
-extern __inline__ int ffz(unsigned int x)
+static __inline__  int ffz(unsigned int x)
 {
 	if ((x = ~x) == 0)
 		return 32;
@@ -226,7 +228,7 @@ static inline int ffs64(u64 x)
  * the libc and compiler builtin ffs routines, therefore
  * differs in spirit from the above ffz (man ffs).
  */
-extern __inline__ int ffs(int x)
+static __inline__  int ffs(int x)
 {
 	return __ilog2(x & -x) + 1;
 }
@@ -250,7 +252,7 @@ extern __inline__ int ffs(int x)
 #define find_first_zero_bit(addr, size) \
 	find_next_zero_bit((addr), (size), 0)
 
-extern __inline__ unsigned long find_next_zero_bit(void * addr,
+static __inline__  unsigned long find_next_zero_bit(void * addr,
 	unsigned long size, unsigned long offset)
 {
 	unsigned int * p = ((unsigned int *) addr) + (offset >> 5);
@@ -298,7 +300,7 @@ found_middle:
 #define ext2_clear_bit(nr, addr)	test_and_clear_bit((nr) ^ 0x18, addr)
 
 #else
-extern __inline__ int ext2_set_bit(int nr, void * addr)
+static __inline__  int ext2_set_bit(int nr, void * addr)
 {
 	int		mask;
 	unsigned char	*ADDR = (unsigned char *) addr;
@@ -311,7 +313,7 @@ extern __inline__ int ext2_set_bit(int nr, void * addr)
 	return oldbit;
 }
 
-extern __inline__ int ext2_clear_bit(int nr, void * addr)
+static __inline__  int ext2_clear_bit(int nr, void * addr)
 {
 	int		mask;
 	unsigned char	*ADDR = (unsigned char *) addr;
@@ -325,7 +327,7 @@ extern __inline__ int ext2_clear_bit(int nr, void * addr)
 }
 #endif	/* __KERNEL__ */
 
-extern __inline__ int ext2_test_bit(int nr, __const__ void * addr)
+static __inline__  int ext2_test_bit(int nr, __const__ void * addr)
 {
 	__const__ unsigned char	*ADDR = (__const__ unsigned char *) addr;
 
diff --git a/arch/powerpc/include/asm/byteorder.h b/arch/powerpc/include/asm/byteorder.h
index 3f5bcf63a1..5f57a08d39 100644
--- a/arch/powerpc/include/asm/byteorder.h
+++ b/arch/powerpc/include/asm/byteorder.h
@@ -5,7 +5,7 @@
 
 #ifdef __GNUC__
 
-extern __inline__ unsigned ld_le16(const volatile unsigned short *addr)
+static __inline__  unsigned ld_le16(const volatile unsigned short *addr)
 {
 	unsigned val;
 
@@ -13,12 +13,12 @@ extern __inline__ unsigned ld_le16(const volatile unsigned short *addr)
 	return val;
 }
 
-extern __inline__ void st_le16(volatile unsigned short *addr, const unsigned val)
+static __inline__  void st_le16(volatile unsigned short *addr, const unsigned val)
 {
 	__asm__ __volatile__ ("sthbrx %1,0,%2" : "=m" (*addr) : "r" (val), "r" (addr));
 }
 
-extern __inline__ unsigned ld_le32(const volatile unsigned *addr)
+static __inline__  unsigned ld_le32(const volatile unsigned *addr)
 {
 	unsigned val;
 
@@ -26,7 +26,7 @@ extern __inline__ unsigned ld_le32(const volatile unsigned *addr)
 	return val;
 }
 
-extern __inline__ void st_le32(volatile unsigned *addr, const unsigned val)
+static __inline__  void st_le32(volatile unsigned *addr, const unsigned val)
 {
 	__asm__ __volatile__ ("stwbrx %1,0,%2" : "=m" (*addr) : "r" (val), "r" (addr));
 }
diff --git a/arch/powerpc/include/asm/io.h b/arch/powerpc/include/asm/io.h
index a5257e9b62..a54fc468d5 100644
--- a/arch/powerpc/include/asm/io.h
+++ b/arch/powerpc/include/asm/io.h
@@ -163,7 +163,7 @@ static inline void __raw_writel(unsigned int v, volatile void __iomem *addr)
  * is actually performed (i.e. the data has come back) before we start
  * executing any following instructions.
  */
-extern inline u8 in_8(const volatile unsigned char __iomem *addr)
+static inline u8 in_8(const volatile unsigned char __iomem *addr)
 {
 	u8 ret;
 
@@ -174,7 +174,7 @@ extern inline u8 in_8(const volatile unsigned char __iomem *addr)
 	return ret;
 }
 
-extern inline void out_8(volatile unsigned char __iomem *addr, u8 val)
+static inline void out_8(volatile unsigned char __iomem *addr, u8 val)
 {
 	__asm__ __volatile__("sync;\n"
 			     "stb%U0%X0 %1,%0;\n"
@@ -182,7 +182,7 @@ extern inline void out_8(volatile unsigned char __iomem *addr, u8 val)
 			     : "r" (val));
 }
 
-extern inline u16 in_le16(const volatile unsigned short __iomem *addr)
+static inline u16 in_le16(const volatile unsigned short __iomem *addr)
 {
 	u16 ret;
 
@@ -193,7 +193,7 @@ extern inline u16 in_le16(const volatile unsigned short __iomem *addr)
 	return ret;
 }
 
-extern inline u16 in_be16(const volatile unsigned short __iomem *addr)
+static inline u16 in_be16(const volatile unsigned short __iomem *addr)
 {
 	u16 ret;
 
@@ -203,18 +203,18 @@ extern inline u16 in_be16(const volatile unsigned short __iomem *addr)
 	return ret;
 }
 
-extern inline void out_le16(volatile unsigned short __iomem *addr, u16 val)
+static inline void out_le16(volatile unsigned short __iomem *addr, u16 val)
 {
 	__asm__ __volatile__("sync; sthbrx %1,0,%2" : "=m" (*addr) :
 			      "r" (val), "r" (addr));
 }
 
-extern inline void out_be16(volatile unsigned short __iomem *addr, u16 val)
+static inline void out_be16(volatile unsigned short __iomem *addr, u16 val)
 {
 	__asm__ __volatile__("sync; sth%U0%X0 %1,%0" : "=m" (*addr) : "r" (val));
 }
 
-extern inline u32 in_le32(const volatile unsigned __iomem *addr)
+static inline u32 in_le32(const volatile unsigned __iomem *addr)
 {
 	u32 ret;
 
@@ -225,7 +225,7 @@ extern inline u32 in_le32(const volatile unsigned __iomem *addr)
 	return ret;
 }
 
-extern inline u32 in_be32(const volatile unsigned __iomem *addr)
+static inline u32 in_be32(const volatile unsigned __iomem *addr)
 {
 	u32 ret;
 
@@ -235,13 +235,13 @@ extern inline u32 in_be32(const volatile unsigned __iomem *addr)
 	return ret;
 }
 
-extern inline void out_le32(volatile unsigned __iomem *addr, u32 val)
+static inline void out_le32(volatile unsigned __iomem *addr, u32 val)
 {
 	__asm__ __volatile__("sync; stwbrx %1,0,%2" : "=m" (*addr) :
 			     "r" (val), "r" (addr));
 }
 
-extern inline void out_be32(volatile unsigned __iomem *addr, u32 val)
+static inline void out_be32(volatile unsigned __iomem *addr, u32 val)
 {
 	__asm__ __volatile__("sync; stw%U0%X0 %1,%0" : "=m" (*addr) : "r" (val));
 }

Re: Deprecate the ppc405 boards in QEMU?

[Thomas Huth]

On 06/10/2021 09.25, Thomas Huth wrote:
> On 05/10/2021 23.53, BALATON Zoltan wrote:
> [...]
>> Maybe these 405 boards in QEMU ran with modified firmware where the memory 
>> detection was patched out but it seems to detect the RAM so I wonder where 
>> it gets that from. Maybe by reading the SDRAM controller DCRs 
>> ppc4xx_sdram_init() sets up. Then I'm not sure what it needs the SPD for, 
>> I forgot how this worked on sam460ex. Maybe for the speed calibration, so 
>> could be it detects ram by reading DCRs then tries to get SPD data and 
>> that's where it stops as i2c is not emulated on taihu. This could be 
>> confirmed by checking what it pokes with -d guest_errors that shows 
>> accesses to missing devices but don't know where 405 has the i2c 
>> controller and if it's the same as newer SoCs. If so that could be reused 
>> and an i2c bus could be added with the SPD data like in sam460ex to make 
>> u-boot happy or you could skip this in u-boot.
> 
> FWIW, I've just tried the latter (skipping the sdram init in u-boot), and 
> indeed, I can get to the u-boot prompt now.
[...]> I've also attached the patch with my modifications to u-boot.

FYI, the changes can now be found on this branch here:

  https://gitlab.com/huth/u-boot/-/commits/taihu

I also added a gitlab-CI file, so you can now download the u-boot.bin as an 
artifact from the corresponding pipeline, e.g.:

  https://gitlab.com/huth/u-boot/-/jobs/1667201028

  Thomas

Re: Deprecate the ppc405 boards in QEMU?

[David Gibson]

[-- Attachment #1: Type: text/plain, Size: 2047 bytes --]

On Mon, Oct 11, 2021 at 10:10:36AM +0200, Thomas Huth wrote:
> On 06/10/2021 09.25, Thomas Huth wrote:
> > On 05/10/2021 23.53, BALATON Zoltan wrote:
> > [...]
> > > Maybe these 405 boards in QEMU ran with modified firmware where the
> > > memory detection was patched out but it seems to detect the RAM so I
> > > wonder where it gets that from. Maybe by reading the SDRAM
> > > controller DCRs ppc4xx_sdram_init() sets up. Then I'm not sure what
> > > it needs the SPD for, I forgot how this worked on sam460ex. Maybe
> > > for the speed calibration, so could be it detects ram by reading
> > > DCRs then tries to get SPD data and that's where it stops as i2c is
> > > not emulated on taihu. This could be confirmed by checking what it
> > > pokes with -d guest_errors that shows accesses to missing devices
> > > but don't know where 405 has the i2c controller and if it's the same
> > > as newer SoCs. If so that could be reused and an i2c bus could be
> > > added with the SPD data like in sam460ex to make u-boot happy or you
> > > could skip this in u-boot.
> > 
> > FWIW, I've just tried the latter (skipping the sdram init in u-boot),
> > and indeed, I can get to the u-boot prompt now.
> [...]> I've also attached the patch with my modifications to u-boot.
> 
> FYI, the changes can now be found on this branch here:
> 
>  https://gitlab.com/huth/u-boot/-/commits/taihu
> 
> I also added a gitlab-CI file, so you can now download the u-boot.bin as an
> artifact from the corresponding pipeline, e.g.:
> 
>  https://gitlab.com/huth/u-boot/-/jobs/1667201028

Thanks.

Are you going to send a v2 of your proposed deprecation patches?  If
you do can you please CC me explicitly.  I only scan qemu-ppc once a
week or so, and it goes into a different folder.  If I'm CCed I'll
notice and respond to it faster.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Deprecate the ppc405 boards in QEMU?

[Thomas Huth]

On 11/10/2021 11.20, David Gibson wrote:
> On Mon, Oct 11, 2021 at 10:10:36AM +0200, Thomas Huth wrote:
>> On 06/10/2021 09.25, Thomas Huth wrote:
>>> On 05/10/2021 23.53, BALATON Zoltan wrote:
>>> [...]
>>>> Maybe these 405 boards in QEMU ran with modified firmware where the
>>>> memory detection was patched out but it seems to detect the RAM so I
>>>> wonder where it gets that from. Maybe by reading the SDRAM
>>>> controller DCRs ppc4xx_sdram_init() sets up. Then I'm not sure what
>>>> it needs the SPD for, I forgot how this worked on sam460ex. Maybe
>>>> for the speed calibration, so could be it detects ram by reading
>>>> DCRs then tries to get SPD data and that's where it stops as i2c is
>>>> not emulated on taihu. This could be confirmed by checking what it
>>>> pokes with -d guest_errors that shows accesses to missing devices
>>>> but don't know where 405 has the i2c controller and if it's the same
>>>> as newer SoCs. If so that could be reused and an i2c bus could be
>>>> added with the SPD data like in sam460ex to make u-boot happy or you
>>>> could skip this in u-boot.
>>>
>>> FWIW, I've just tried the latter (skipping the sdram init in u-boot),
>>> and indeed, I can get to the u-boot prompt now.
>> [...]> I've also attached the patch with my modifications to u-boot.
>>
>> FYI, the changes can now be found on this branch here:
>>
>>   https://gitlab.com/huth/u-boot/-/commits/taihu
>>
>> I also added a gitlab-CI file, so you can now download the u-boot.bin as an
>> artifact from the corresponding pipeline, e.g.:
>>
>>   https://gitlab.com/huth/u-boot/-/jobs/1667201028
> 
> Thanks.
> 
> Are you going to send a v2 of your proposed deprecation patches?

No, since there was interest in keeping the 405 boards for testing the 405 
code in the Linux kernel, and since there is now a way to do at least some 
very basic testing of these boards (with the u-boot firmware), I don't plan 
to respin the deprecation patch. I just sent a patch for adding the boards 
to our CI instead:

  https://lists.gnu.org/archive/html/qemu-devel/2021-10/msg02072.html

  Thomas

Re: Deprecate the ppc405 boards in QEMU?

[Christophe Leroy]

Le 11/10/2021 à 15:24, Thomas Huth a écrit :
> On 11/10/2021 11.20, David Gibson wrote:
>> On Mon, Oct 11, 2021 at 10:10:36AM +0200, Thomas Huth wrote:
>>> On 06/10/2021 09.25, Thomas Huth wrote:
>>>> On 05/10/2021 23.53, BALATON Zoltan wrote:
>>>> [...]
>>>>> Maybe these 405 boards in QEMU ran with modified firmware where the
>>>>> memory detection was patched out but it seems to detect the RAM so I
>>>>> wonder where it gets that from. Maybe by reading the SDRAM
>>>>> controller DCRs ppc4xx_sdram_init() sets up. Then I'm not sure what
>>>>> it needs the SPD for, I forgot how this worked on sam460ex. Maybe
>>>>> for the speed calibration, so could be it detects ram by reading
>>>>> DCRs then tries to get SPD data and that's where it stops as i2c is
>>>>> not emulated on taihu. This could be confirmed by checking what it
>>>>> pokes with -d guest_errors that shows accesses to missing devices
>>>>> but don't know where 405 has the i2c controller and if it's the same
>>>>> as newer SoCs. If so that could be reused and an i2c bus could be
>>>>> added with the SPD data like in sam460ex to make u-boot happy or you
>>>>> could skip this in u-boot.
>>>>
>>>> FWIW, I've just tried the latter (skipping the sdram init in u-boot),
>>>> and indeed, I can get to the u-boot prompt now.
>>> [...]> I've also attached the patch with my modifications to u-boot.
>>>
>>> FYI, the changes can now be found on this branch here:
>>>
>>>   https://gitlab.com/huth/u-boot/-/commits/taihu
>>>
>>> I also added a gitlab-CI file, so you can now download the u-boot.bin 
>>> as an
>>> artifact from the corresponding pipeline, e.g.:
>>>
>>>   https://gitlab.com/huth/u-boot/-/jobs/1667201028
>>
>> Thanks.
>>
>> Are you going to send a v2 of your proposed deprecation patches?
> 
> No, since there was interest in keeping the 405 boards for testing the 
> 405 code in the Linux kernel, and since there is now a way to do at 
> least some very basic testing of these boards (with the u-boot 
> firmware), I don't plan to respin the deprecation patch. I just sent a 
> patch for adding the boards to our CI instead:
> 
>   https://lists.gnu.org/archive/html/qemu-devel/2021-10/msg02072.html
> 

I have downloaded your u-boot.bin and tried it with both QEMU 5.2.0 and 
mainline, and I get:

ERROR:../accel/tcg/tcg-accel-ops.c:79:tcg_handle_interrupt: assertion 
failed: (qemu_mutex_iothread_locked())
Bail out! ERROR:../accel/tcg/tcg-accel-ops.c:79:tcg_handle_interrupt: 
assertion failed: (qemu_mutex_iothread_locked())
Abandon (core dumped)

I see in the mail history that you got that problem as well at some 
point. How did you fix it ?

Thanks
Christophe

Re: Deprecate the ppc405 boards in QEMU?

[Thomas Huth]

On 19/10/2021 11.31, Christophe Leroy wrote:
> 
> 
> Le 11/10/2021 à 15:24, Thomas Huth a écrit :
>> On 11/10/2021 11.20, David Gibson wrote:
>>> On Mon, Oct 11, 2021 at 10:10:36AM +0200, Thomas Huth wrote:
>>>> On 06/10/2021 09.25, Thomas Huth wrote:
>>>>> On 05/10/2021 23.53, BALATON Zoltan wrote:
>>>>> [...]
>>>>>> Maybe these 405 boards in QEMU ran with modified firmware where the
>>>>>> memory detection was patched out but it seems to detect the RAM so I
>>>>>> wonder where it gets that from. Maybe by reading the SDRAM
>>>>>> controller DCRs ppc4xx_sdram_init() sets up. Then I'm not sure what
>>>>>> it needs the SPD for, I forgot how this worked on sam460ex. Maybe
>>>>>> for the speed calibration, so could be it detects ram by reading
>>>>>> DCRs then tries to get SPD data and that's where it stops as i2c is
>>>>>> not emulated on taihu. This could be confirmed by checking what it
>>>>>> pokes with -d guest_errors that shows accesses to missing devices
>>>>>> but don't know where 405 has the i2c controller and if it's the same
>>>>>> as newer SoCs. If so that could be reused and an i2c bus could be
>>>>>> added with the SPD data like in sam460ex to make u-boot happy or you
>>>>>> could skip this in u-boot.
>>>>>
>>>>> FWIW, I've just tried the latter (skipping the sdram init in u-boot),
>>>>> and indeed, I can get to the u-boot prompt now.
>>>> [...]> I've also attached the patch with my modifications to u-boot.
>>>>
>>>> FYI, the changes can now be found on this branch here:
>>>>
>>>>   https://gitlab.com/huth/u-boot/-/commits/taihu
>>>>
>>>> I also added a gitlab-CI file, so you can now download the u-boot.bin as an
>>>> artifact from the corresponding pipeline, e.g.:
>>>>
>>>>   https://gitlab.com/huth/u-boot/-/jobs/1667201028
>>>
>>> Thanks.
>>>
>>> Are you going to send a v2 of your proposed deprecation patches?
>>
>> No, since there was interest in keeping the 405 boards for testing the 405 
>> code in the Linux kernel, and since there is now a way to do at least some 
>> very basic testing of these boards (with the u-boot firmware), I don't 
>> plan to respin the deprecation patch. I just sent a patch for adding the 
>> boards to our CI instead:
>>
>>   https://lists.gnu.org/archive/html/qemu-devel/2021-10/msg02072.html
>>
> 
> I have downloaded your u-boot.bin and tried it with both QEMU 5.2.0 and 
> mainline, and I get:
> 
> ERROR:../accel/tcg/tcg-accel-ops.c:79:tcg_handle_interrupt: assertion 
> failed: (qemu_mutex_iothread_locked())
> Bail out! ERROR:../accel/tcg/tcg-accel-ops.c:79:tcg_handle_interrupt: 
> assertion failed: (qemu_mutex_iothread_locked())
> Abandon (core dumped)
> 
> I see in the mail history that you got that problem as well at some point. 
> How did you fix it ?

You need this patch here to fix this issue:

  https://lists.gnu.org/archive/html/qemu-devel/2021-10/msg01019.html
  ("hw/ppc: Fix iothread locking in the 405 code")

  Thomas

Re: Deprecate the ppc405 boards in QEMU?

[Christophe Leroy]

Le 19/10/2021 à 11:39, Thomas Huth a écrit :
> On 19/10/2021 11.31, Christophe Leroy wrote:
>>
>>
>> Le 11/10/2021 à 15:24, Thomas Huth a écrit :
>>> On 11/10/2021 11.20, David Gibson wrote:
>>>> On Mon, Oct 11, 2021 at 10:10:36AM +0200, Thomas Huth wrote:
>>>>> On 06/10/2021 09.25, Thomas Huth wrote:
>>>>>> On 05/10/2021 23.53, BALATON Zoltan wrote:
>>>>>> [...]
>>>>>>> Maybe these 405 boards in QEMU ran with modified firmware where the
>>>>>>> memory detection was patched out but it seems to detect the RAM so I
>>>>>>> wonder where it gets that from. Maybe by reading the SDRAM
>>>>>>> controller DCRs ppc4xx_sdram_init() sets up. Then I'm not sure what
>>>>>>> it needs the SPD for, I forgot how this worked on sam460ex. Maybe
>>>>>>> for the speed calibration, so could be it detects ram by reading
>>>>>>> DCRs then tries to get SPD data and that's where it stops as i2c is
>>>>>>> not emulated on taihu. This could be confirmed by checking what it
>>>>>>> pokes with -d guest_errors that shows accesses to missing devices
>>>>>>> but don't know where 405 has the i2c controller and if it's the same
>>>>>>> as newer SoCs. If so that could be reused and an i2c bus could be
>>>>>>> added with the SPD data like in sam460ex to make u-boot happy or you
>>>>>>> could skip this in u-boot.
>>>>>>
>>>>>> FWIW, I've just tried the latter (skipping the sdram init in u-boot),
>>>>>> and indeed, I can get to the u-boot prompt now.
>>>>> [...]> I've also attached the patch with my modifications to u-boot.
>>>>>
>>>>> FYI, the changes can now be found on this branch here:
>>>>>
>>>>>   https://gitlab.com/huth/u-boot/-/commits/taihu
>>>>>
>>>>> I also added a gitlab-CI file, so you can now download the 
>>>>> u-boot.bin as an
>>>>> artifact from the corresponding pipeline, e.g.:
>>>>>
>>>>>   https://gitlab.com/huth/u-boot/-/jobs/1667201028
>>>>
>>>> Thanks.
>>>>
>>>> Are you going to send a v2 of your proposed deprecation patches?
>>>
>>> No, since there was interest in keeping the 405 boards for testing 
>>> the 405 code in the Linux kernel, and since there is now a way to do 
>>> at least some very basic testing of these boards (with the u-boot 
>>> firmware), I don't plan to respin the deprecation patch. I just sent 
>>> a patch for adding the boards to our CI instead:
>>>
>>>   https://lists.gnu.org/archive/html/qemu-devel/2021-10/msg02072.html
>>>
>>
>> I have downloaded your u-boot.bin and tried it with both QEMU 5.2.0 
>> and mainline, and I get:
>>
>> ERROR:../accel/tcg/tcg-accel-ops.c:79:tcg_handle_interrupt: assertion 
>> failed: (qemu_mutex_iothread_locked())
>> Bail out! ERROR:../accel/tcg/tcg-accel-ops.c:79:tcg_handle_interrupt: 
>> assertion failed: (qemu_mutex_iothread_locked())
>> Abandon (core dumped)
>>
>> I see in the mail history that you got that problem as well at some 
>> point. How did you fix it ?
> 
> You need this patch here to fix this issue:
> 
>   https://lists.gnu.org/archive/html/qemu-devel/2021-10/msg01019.html
>   ("hw/ppc: Fix iothread locking in the 405 code")
> 

Thank you.

Is there anything special to do then in order to boot a Linux kernel ?

I build the uImage for ppc40x_defconfig

I use the following command, but it does nothing, it stays in uboot 
prompt as when I don't get a kernel argument

	~/qemu/build/qemu-system-ppc -M taihu -bios 
~/Téléchargements/u-boot.bin -serial null -serial mon:stdio -kernel 
arch/powerpc/boot/uImage

Thanks
Christophe

Re: Deprecate the ppc405 boards in QEMU?

[BALATON Zoltan]

[-- Attachment #1: Type: text/plain, Size: 4005 bytes --]

On Tue, 19 Oct 2021, Christophe Leroy wrote:
> Le 19/10/2021 à 11:39, Thomas Huth a écrit :
>> On 19/10/2021 11.31, Christophe Leroy wrote:
>>> Le 11/10/2021 à 15:24, Thomas Huth a écrit :
>>>> On 11/10/2021 11.20, David Gibson wrote:
>>>>> On Mon, Oct 11, 2021 at 10:10:36AM +0200, Thomas Huth wrote:
>>>>>> On 06/10/2021 09.25, Thomas Huth wrote:
>>>>>>> On 05/10/2021 23.53, BALATON Zoltan wrote:
>>>>>>> [...]
>>>>>>>> Maybe these 405 boards in QEMU ran with modified firmware where the
>>>>>>>> memory detection was patched out but it seems to detect the RAM so I
>>>>>>>> wonder where it gets that from. Maybe by reading the SDRAM
>>>>>>>> controller DCRs ppc4xx_sdram_init() sets up. Then I'm not sure what
>>>>>>>> it needs the SPD for, I forgot how this worked on sam460ex. Maybe
>>>>>>>> for the speed calibration, so could be it detects ram by reading
>>>>>>>> DCRs then tries to get SPD data and that's where it stops as i2c is
>>>>>>>> not emulated on taihu. This could be confirmed by checking what it
>>>>>>>> pokes with -d guest_errors that shows accesses to missing devices
>>>>>>>> but don't know where 405 has the i2c controller and if it's the same
>>>>>>>> as newer SoCs. If so that could be reused and an i2c bus could be
>>>>>>>> added with the SPD data like in sam460ex to make u-boot happy or you
>>>>>>>> could skip this in u-boot.
>>>>>>> 
>>>>>>> FWIW, I've just tried the latter (skipping the sdram init in u-boot),
>>>>>>> and indeed, I can get to the u-boot prompt now.
>>>>>> [...]> I've also attached the patch with my modifications to u-boot.
>>>>>> 
>>>>>> FYI, the changes can now be found on this branch here:
>>>>>> 
>>>>>>   https://gitlab.com/huth/u-boot/-/commits/taihu
>>>>>> 
>>>>>> I also added a gitlab-CI file, so you can now download the u-boot.bin 
>>>>>> as an
>>>>>> artifact from the corresponding pipeline, e.g.:
>>>>>> 
>>>>>>   https://gitlab.com/huth/u-boot/-/jobs/1667201028
>>>>> 
>>>>> Thanks.
>>>>> 
>>>>> Are you going to send a v2 of your proposed deprecation patches?
>>>> 
>>>> No, since there was interest in keeping the 405 boards for testing the 
>>>> 405 code in the Linux kernel, and since there is now a way to do at least 
>>>> some very basic testing of these boards (with the u-boot firmware), I 
>>>> don't plan to respin the deprecation patch. I just sent a patch for 
>>>> adding the boards to our CI instead:
>>>> 
>>>>   https://lists.gnu.org/archive/html/qemu-devel/2021-10/msg02072.html
>>>> 
>>> 
>>> I have downloaded your u-boot.bin and tried it with both QEMU 5.2.0 and 
>>> mainline, and I get:
>>> 
>>> ERROR:../accel/tcg/tcg-accel-ops.c:79:tcg_handle_interrupt: assertion 
>>> failed: (qemu_mutex_iothread_locked())
>>> Bail out! ERROR:../accel/tcg/tcg-accel-ops.c:79:tcg_handle_interrupt: 
>>> assertion failed: (qemu_mutex_iothread_locked())
>>> Abandon (core dumped)
>>> 
>>> I see in the mail history that you got that problem as well at some point. 
>>> How did you fix it ?
>> 
>> You need this patch here to fix this issue:
>>
>>   https://lists.gnu.org/archive/html/qemu-devel/2021-10/msg01019.html
>>   ("hw/ppc: Fix iothread locking in the 405 code")
>> 
>
> Thank you.
>
> Is there anything special to do then in order to boot a Linux kernel ?
>
> I build the uImage for ppc40x_defconfig
>
> I use the following command, but it does nothing, it stays in uboot prompt as 
> when I don't get a kernel argument
>
> 	~/qemu/build/qemu-system-ppc -M taihu -bios 
> ~/Téléchargements/u-boot.bin -serial null -serial mon:stdio -kernel 
> arch/powerpc/boot/uImage

I'm not sure using -bios and -kernel together makes sense, it probably 
starts u-boot in this case and you have to load and start the kernel from 
u-boot as you'd notmally do on a real machine. Alternatively you could use 
-kernel instead of -bios which then loads a kernel and starts it directly 
but not sure if it needs a firmware to work.

Ot I could be completely wrong as I don't know this machine and haven't 
tried it.

Regards,
BALATON Zoltan

Re: Deprecate the ppc405 boards in QEMU?

[Thomas Huth]

On 19/10/2021 12.07, BALATON Zoltan wrote:
> On Tue, 19 Oct 2021, Christophe Leroy wrote:
>> Le 19/10/2021 à 11:39, Thomas Huth a écrit :
>>> On 19/10/2021 11.31, Christophe Leroy wrote:
>>>> Le 11/10/2021 à 15:24, Thomas Huth a écrit :
>>>>> On 11/10/2021 11.20, David Gibson wrote:
>>>>>> On Mon, Oct 11, 2021 at 10:10:36AM +0200, Thomas Huth wrote:
>>>>>>> On 06/10/2021 09.25, Thomas Huth wrote:
>>>>>>>> On 05/10/2021 23.53, BALATON Zoltan wrote:
>>>>>>>> [...]
>>>>>>>>> Maybe these 405 boards in QEMU ran with modified firmware where the
>>>>>>>>> memory detection was patched out but it seems to detect the RAM so I
>>>>>>>>> wonder where it gets that from. Maybe by reading the SDRAM
>>>>>>>>> controller DCRs ppc4xx_sdram_init() sets up. Then I'm not sure what
>>>>>>>>> it needs the SPD for, I forgot how this worked on sam460ex. Maybe
>>>>>>>>> for the speed calibration, so could be it detects ram by reading
>>>>>>>>> DCRs then tries to get SPD data and that's where it stops as i2c is
>>>>>>>>> not emulated on taihu. This could be confirmed by checking what it
>>>>>>>>> pokes with -d guest_errors that shows accesses to missing devices
>>>>>>>>> but don't know where 405 has the i2c controller and if it's the same
>>>>>>>>> as newer SoCs. If so that could be reused and an i2c bus could be
>>>>>>>>> added with the SPD data like in sam460ex to make u-boot happy or you
>>>>>>>>> could skip this in u-boot.
>>>>>>>>
>>>>>>>> FWIW, I've just tried the latter (skipping the sdram init in u-boot),
>>>>>>>> and indeed, I can get to the u-boot prompt now.
>>>>>>> [...]> I've also attached the patch with my modifications to u-boot.
>>>>>>>
>>>>>>> FYI, the changes can now be found on this branch here:
>>>>>>>
>>>>>>>   https://gitlab.com/huth/u-boot/-/commits/taihu
>>>>>>>
>>>>>>> I also added a gitlab-CI file, so you can now download the u-boot.bin 
>>>>>>> as an
>>>>>>> artifact from the corresponding pipeline, e.g.:
>>>>>>>
>>>>>>>   https://gitlab.com/huth/u-boot/-/jobs/1667201028
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>> Are you going to send a v2 of your proposed deprecation patches?
>>>>>
>>>>> No, since there was interest in keeping the 405 boards for testing the 
>>>>> 405 code in the Linux kernel, and since there is now a way to do at 
>>>>> least some very basic testing of these boards (with the u-boot 
>>>>> firmware), I don't plan to respin the deprecation patch. I just sent a 
>>>>> patch for adding the boards to our CI instead:
>>>>>
>>>>>   https://lists.gnu.org/archive/html/qemu-devel/2021-10/msg02072.html
>>>>>
>>>>
>>>> I have downloaded your u-boot.bin and tried it with both QEMU 5.2.0 and 
>>>> mainline, and I get:
>>>>
>>>> ERROR:../accel/tcg/tcg-accel-ops.c:79:tcg_handle_interrupt: assertion 
>>>> failed: (qemu_mutex_iothread_locked())
>>>> Bail out! ERROR:../accel/tcg/tcg-accel-ops.c:79:tcg_handle_interrupt: 
>>>> assertion failed: (qemu_mutex_iothread_locked())
>>>> Abandon (core dumped)
>>>>
>>>> I see in the mail history that you got that problem as well at some 
>>>> point. How did you fix it ?
>>>
>>> You need this patch here to fix this issue:
>>>
>>>   https://lists.gnu.org/archive/html/qemu-devel/2021-10/msg01019.html
>>>   ("hw/ppc: Fix iothread locking in the 405 code")
>>>
>>
>> Thank you.
>>
>> Is there anything special to do then in order to boot a Linux kernel ?
>>
>> I build the uImage for ppc40x_defconfig
>>
>> I use the following command, but it does nothing, it stays in uboot prompt 
>> as when I don't get a kernel argument
>>
>>     ~/qemu/build/qemu-system-ppc -M taihu -bios 
>> ~/Téléchargements/u-boot.bin -serial null -serial mon:stdio -kernel 
>> arch/powerpc/boot/uImage
> 
> I'm not sure using -bios and -kernel together makes sense, it probably 
> starts u-boot in this case and you have to load and start the kernel from 
> u-boot as you'd notmally do on a real machine. Alternatively you could use 
> -kernel instead of -bios which then loads a kernel and starts it directly 
> but not sure if it needs a firmware to work.
> 
> Ot I could be completely wrong as I don't know this machine and haven't 
> tried it.

Actually, these 405 machines are quite weird. They refuse to boot without 
bios image, so you currently need the firmware image for sure.

OTOH, when you look at the ref405ep_init() function, it seems that at least 
the ref405ep machine was once supposed to start a kernel directly:

         env->nip = KERNEL_LOAD_ADDR;

... however, this does not seem to work anymore, the initial NIP is always 
reset to the firmware entry when the board resets. Not sure if/how this ever 
used worked ...

  Thomas

Re: Deprecate the ppc405 boards in QEMU?

[Christophe Leroy]

Le 19/10/2021 à 13:11, Thomas Huth a écrit :
> On 19/10/2021 12.07, BALATON Zoltan wrote:
>> On Tue, 19 Oct 2021, Christophe Leroy wrote:
>>> Le 19/10/2021 à 11:39, Thomas Huth a écrit :
>>>> On 19/10/2021 11.31, Christophe Leroy wrote:
>>>>> Le 11/10/2021 à 15:24, Thomas Huth a écrit :
>>>>>> On 11/10/2021 11.20, David Gibson wrote:
>>>>>>> On Mon, Oct 11, 2021 at 10:10:36AM +0200, Thomas Huth wrote:
>>>>>>>> On 06/10/2021 09.25, Thomas Huth wrote:
>>>>>>>>> On 05/10/2021 23.53, BALATON Zoltan wrote:
>>>>>>>>> [...]
>>>>>>>>>> Maybe these 405 boards in QEMU ran with modified firmware 
>>>>>>>>>> where the
>>>>>>>>>> memory detection was patched out but it seems to detect the 
>>>>>>>>>> RAM so I
>>>>>>>>>> wonder where it gets that from. Maybe by reading the SDRAM
>>>>>>>>>> controller DCRs ppc4xx_sdram_init() sets up. Then I'm not sure 
>>>>>>>>>> what
>>>>>>>>>> it needs the SPD for, I forgot how this worked on sam460ex. Maybe
>>>>>>>>>> for the speed calibration, so could be it detects ram by reading
>>>>>>>>>> DCRs then tries to get SPD data and that's where it stops as 
>>>>>>>>>> i2c is
>>>>>>>>>> not emulated on taihu. This could be confirmed by checking 
>>>>>>>>>> what it
>>>>>>>>>> pokes with -d guest_errors that shows accesses to missing devices
>>>>>>>>>> but don't know where 405 has the i2c controller and if it's 
>>>>>>>>>> the same
>>>>>>>>>> as newer SoCs. If so that could be reused and an i2c bus could be
>>>>>>>>>> added with the SPD data like in sam460ex to make u-boot happy 
>>>>>>>>>> or you
>>>>>>>>>> could skip this in u-boot.
>>>>>>>>>
>>>>>>>>> FWIW, I've just tried the latter (skipping the sdram init in 
>>>>>>>>> u-boot),
>>>>>>>>> and indeed, I can get to the u-boot prompt now.
>>>>>>>> [...]> I've also attached the patch with my modifications to 
>>>>>>>> u-boot.
>>>>>>>>
>>>>>>>> FYI, the changes can now be found on this branch here:
>>>>>>>>
>>>>>>>>   https://gitlab.com/huth/u-boot/-/commits/taihu
>>>>>>>>
>>>>>>>> I also added a gitlab-CI file, so you can now download the 
>>>>>>>> u-boot.bin as an
>>>>>>>> artifact from the corresponding pipeline, e.g.:
>>>>>>>>
>>>>>>>>   https://gitlab.com/huth/u-boot/-/jobs/1667201028
>>>>>>>
>>>>>>> Thanks.
>>>>>>>
>>>>>>> Are you going to send a v2 of your proposed deprecation patches?
>>>>>>
>>>>>> No, since there was interest in keeping the 405 boards for testing 
>>>>>> the 405 code in the Linux kernel, and since there is now a way to 
>>>>>> do at least some very basic testing of these boards (with the 
>>>>>> u-boot firmware), I don't plan to respin the deprecation patch. I 
>>>>>> just sent a patch for adding the boards to our CI instead:
>>>>>>
>>>>>>   https://lists.gnu.org/archive/html/qemu-devel/2021-10/msg02072.html
>>>>>>
>>>>>
>>>>> I have downloaded your u-boot.bin and tried it with both QEMU 5.2.0 
>>>>> and mainline, and I get:
>>>>>
>>>>> ERROR:../accel/tcg/tcg-accel-ops.c:79:tcg_handle_interrupt: 
>>>>> assertion failed: (qemu_mutex_iothread_locked())
>>>>> Bail out! 
>>>>> ERROR:../accel/tcg/tcg-accel-ops.c:79:tcg_handle_interrupt: 
>>>>> assertion failed: (qemu_mutex_iothread_locked())
>>>>> Abandon (core dumped)
>>>>>
>>>>> I see in the mail history that you got that problem as well at some 
>>>>> point. How did you fix it ?
>>>>
>>>> You need this patch here to fix this issue:
>>>>
>>>>   https://lists.gnu.org/archive/html/qemu-devel/2021-10/msg01019.html
>>>>   ("hw/ppc: Fix iothread locking in the 405 code")
>>>>
>>>
>>> Thank you.
>>>
>>> Is there anything special to do then in order to boot a Linux kernel ?
>>>
>>> I build the uImage for ppc40x_defconfig
>>>
>>> I use the following command, but it does nothing, it stays in uboot 
>>> prompt as when I don't get a kernel argument
>>>
>>>     ~/qemu/build/qemu-system-ppc -M taihu -bios 
>>> ~/Téléchargements/u-boot.bin -serial null -serial mon:stdio -kernel 
>>> arch/powerpc/boot/uImage
>>
>> I'm not sure using -bios and -kernel together makes sense, it probably 
>> starts u-boot in this case and you have to load and start the kernel 
>> from u-boot as you'd notmally do on a real machine. Alternatively you 
>> could use -kernel instead of -bios which then loads a kernel and 
>> starts it directly but not sure if it needs a firmware to work.
>>
>> Ot I could be completely wrong as I don't know this machine and 
>> haven't tried it.
> 
> Actually, these 405 machines are quite weird. They refuse to boot 
> without bios image, so you currently need the firmware image for sure.
> 
> OTOH, when you look at the ref405ep_init() function, it seems that at 
> least the ref405ep machine was once supposed to start a kernel directly:
> 
>          env->nip = KERNEL_LOAD_ADDR;
> 
> ... however, this does not seem to work anymore, the initial NIP is 
> always reset to the firmware entry when the board resets. Not sure 
> if/how this ever used worked ...
> 

On the e500 we use both -bios and -kernel:

	qemu-system-ppc64 -nographic -M ppce500 -cpu e5500 -m 1G -bios 
u-boot-e500 -kernel ./arch/powerpc/boot/uImage  -initrd 
./qemu/rootfs.cpio.gz -append noreboot -s


Uboot for e500 has the following environment:

	=> printenv
	bootcmd=test -n "$qemu_kernel_addr" && bootm $qemu_kernel_addr - 
$fdt_addr_r
	fdt_addr_r=e8000000
	qemu_kernel_addr=2000000
	stderr=serial
	stdin=serial
	stdout=serial

	Environment size: 164/8188 bytes


I think I need to findout where QEMU loads the kernel when using TAIHU 
machine.

Christophe

Re: Deprecate the ppc405 boards in QEMU?

[BALATON Zoltan]

[-- Attachment #1: Type: text/plain, Size: 6274 bytes --]

On Tue, 19 Oct 2021, Christophe Leroy wrote:
> Le 19/10/2021 à 13:11, Thomas Huth a écrit :
>> On 19/10/2021 12.07, BALATON Zoltan wrote:
>>> On Tue, 19 Oct 2021, Christophe Leroy wrote:
>>>> Le 19/10/2021 à 11:39, Thomas Huth a écrit :
>>>>> On 19/10/2021 11.31, Christophe Leroy wrote:
>>>>>> Le 11/10/2021 à 15:24, Thomas Huth a écrit :
>>>>>>> On 11/10/2021 11.20, David Gibson wrote:
>>>>>>>> On Mon, Oct 11, 2021 at 10:10:36AM +0200, Thomas Huth wrote:
>>>>>>>>> On 06/10/2021 09.25, Thomas Huth wrote:
>>>>>>>>>> On 05/10/2021 23.53, BALATON Zoltan wrote:
>>>>>>>>>> [...]
>>>>>>>>>>> Maybe these 405 boards in QEMU ran with modified firmware where 
>>>>>>>>>>> the
>>>>>>>>>>> memory detection was patched out but it seems to detect the RAM so 
>>>>>>>>>>> I
>>>>>>>>>>> wonder where it gets that from. Maybe by reading the SDRAM
>>>>>>>>>>> controller DCRs ppc4xx_sdram_init() sets up. Then I'm not sure 
>>>>>>>>>>> what
>>>>>>>>>>> it needs the SPD for, I forgot how this worked on sam460ex. Maybe
>>>>>>>>>>> for the speed calibration, so could be it detects ram by reading
>>>>>>>>>>> DCRs then tries to get SPD data and that's where it stops as i2c 
>>>>>>>>>>> is
>>>>>>>>>>> not emulated on taihu. This could be confirmed by checking what it
>>>>>>>>>>> pokes with -d guest_errors that shows accesses to missing devices
>>>>>>>>>>> but don't know where 405 has the i2c controller and if it's the 
>>>>>>>>>>> same
>>>>>>>>>>> as newer SoCs. If so that could be reused and an i2c bus could be
>>>>>>>>>>> added with the SPD data like in sam460ex to make u-boot happy or 
>>>>>>>>>>> you
>>>>>>>>>>> could skip this in u-boot.
>>>>>>>>>> 
>>>>>>>>>> FWIW, I've just tried the latter (skipping the sdram init in 
>>>>>>>>>> u-boot),
>>>>>>>>>> and indeed, I can get to the u-boot prompt now.
>>>>>>>>> [...]> I've also attached the patch with my modifications to u-boot.
>>>>>>>>> 
>>>>>>>>> FYI, the changes can now be found on this branch here:
>>>>>>>>> 
>>>>>>>>>   https://gitlab.com/huth/u-boot/-/commits/taihu
>>>>>>>>> 
>>>>>>>>> I also added a gitlab-CI file, so you can now download the 
>>>>>>>>> u-boot.bin as an
>>>>>>>>> artifact from the corresponding pipeline, e.g.:
>>>>>>>>> 
>>>>>>>>>   https://gitlab.com/huth/u-boot/-/jobs/1667201028
>>>>>>>> 
>>>>>>>> Thanks.
>>>>>>>> 
>>>>>>>> Are you going to send a v2 of your proposed deprecation patches?
>>>>>>> 
>>>>>>> No, since there was interest in keeping the 405 boards for testing the 
>>>>>>> 405 code in the Linux kernel, and since there is now a way to do at 
>>>>>>> least some very basic testing of these boards (with the u-boot 
>>>>>>> firmware), I don't plan to respin the deprecation patch. I just sent a 
>>>>>>> patch for adding the boards to our CI instead:
>>>>>>> 
>>>>>>>   https://lists.gnu.org/archive/html/qemu-devel/2021-10/msg02072.html
>>>>>>> 
>>>>>> 
>>>>>> I have downloaded your u-boot.bin and tried it with both QEMU 5.2.0 and 
>>>>>> mainline, and I get:
>>>>>> 
>>>>>> ERROR:../accel/tcg/tcg-accel-ops.c:79:tcg_handle_interrupt: assertion 
>>>>>> failed: (qemu_mutex_iothread_locked())
>>>>>> Bail out! ERROR:../accel/tcg/tcg-accel-ops.c:79:tcg_handle_interrupt: 
>>>>>> assertion failed: (qemu_mutex_iothread_locked())
>>>>>> Abandon (core dumped)
>>>>>> 
>>>>>> I see in the mail history that you got that problem as well at some 
>>>>>> point. How did you fix it ?
>>>>> 
>>>>> You need this patch here to fix this issue:
>>>>> 
>>>>>   https://lists.gnu.org/archive/html/qemu-devel/2021-10/msg01019.html
>>>>>   ("hw/ppc: Fix iothread locking in the 405 code")
>>>>> 
>>>> 
>>>> Thank you.
>>>> 
>>>> Is there anything special to do then in order to boot a Linux kernel ?
>>>> 
>>>> I build the uImage for ppc40x_defconfig
>>>> 
>>>> I use the following command, but it does nothing, it stays in uboot 
>>>> prompt as when I don't get a kernel argument
>>>> 
>>>>     ~/qemu/build/qemu-system-ppc -M taihu -bios 
>>>> ~/Téléchargements/u-boot.bin -serial null -serial mon:stdio -kernel 
>>>> arch/powerpc/boot/uImage
>>> 
>>> I'm not sure using -bios and -kernel together makes sense, it probably 
>>> starts u-boot in this case and you have to load and start the kernel from 
>>> u-boot as you'd notmally do on a real machine. Alternatively you could use 
>>> -kernel instead of -bios which then loads a kernel and starts it directly 
>>> but not sure if it needs a firmware to work.
>>> 
>>> Ot I could be completely wrong as I don't know this machine and haven't 
>>> tried it.
>> 
>> Actually, these 405 machines are quite weird. They refuse to boot without 
>> bios image, so you currently need the firmware image for sure.
>> 
>> OTOH, when you look at the ref405ep_init() function, it seems that at least 
>> the ref405ep machine was once supposed to start a kernel directly:
>>
>>          env->nip = KERNEL_LOAD_ADDR;
>> 
>> ... however, this does not seem to work anymore, the initial NIP is always 
>> reset to the firmware entry when the board resets. Not sure if/how this 
>> ever used worked ...
>> 
>
> On the e500 we use both -bios and -kernel:
>
> 	qemu-system-ppc64 -nographic -M ppce500 -cpu e5500 -m 1G -bios 
> u-boot-e500 -kernel ./arch/powerpc/boot/uImage  -initrd ./qemu/rootfs.cpio.gz 
> -append noreboot -s
>
>
> Uboot for e500 has the following environment:
>
> 	=> printenv
> 	bootcmd=test -n "$qemu_kernel_addr" && bootm $qemu_kernel_addr - 
> $fdt_addr_r
> 	fdt_addr_r=e8000000
> 	qemu_kernel_addr=2000000
> 	stderr=serial
> 	stdin=serial
> 	stdout=serial
>
> 	Environment size: 164/8188 bytes

The -bios and -kernel options are handled by the machine code so these 
work differently on every machine depending on what they decide to do for 
these.

> I think I need to findout where QEMU loads the kernel when using TAIHU 
> machine.

Look in qemu/hw/ppc/ppc405_boards.c it has
#define KERNEL_LOAD_ADDR 0x00000000
but it does not seem to do anything with a kernel other than loading it. I 
don't see anything that would start the kernel. I think this board is 
probably unfinished, if you want to use it you may need to implement some 
stuff in it. Also try using -d unimp,guest_errors options to see errors 
when something goes wrong otherwise you may not get much feedback.

Regard,
BALATON Zoltan

Re: Deprecate the ppc405 boards in QEMU?

[Christophe Leroy]

Le 19/10/2021 à 14:38, BALATON Zoltan a écrit :
> On Tue, 19 Oct 2021, Christophe Leroy wrote:
>> Le 19/10/2021 à 13:11, Thomas Huth a écrit :
>>> On 19/10/2021 12.07, BALATON Zoltan wrote:
>>>> On Tue, 19 Oct 2021, Christophe Leroy wrote:
>>>>> Le 19/10/2021 à 11:39, Thomas Huth a écrit :
>>>>>> On 19/10/2021 11.31, Christophe Leroy wrote:
>>>>>>> Le 11/10/2021 à 15:24, Thomas Huth a écrit :
>>>>>>>> On 11/10/2021 11.20, David Gibson wrote:
>>>>>>>>> On Mon, Oct 11, 2021 at 10:10:36AM +0200, Thomas Huth wrote:
>>>>>>>>>> On 06/10/2021 09.25, Thomas Huth wrote:
>>>>>>>>>>> On 05/10/2021 23.53, BALATON Zoltan wrote:
>>>>>>>>>>> [...]
>>>>>>>>>>>> Maybe these 405 boards in QEMU ran with modified firmware 
>>>>>>>>>>>> where the
>>>>>>>>>>>> memory detection was patched out but it seems to detect the 
>>>>>>>>>>>> RAM so I
>>>>>>>>>>>> wonder where it gets that from. Maybe by reading the SDRAM
>>>>>>>>>>>> controller DCRs ppc4xx_sdram_init() sets up. Then I'm not 
>>>>>>>>>>>> sure what
>>>>>>>>>>>> it needs the SPD for, I forgot how this worked on sam460ex. 
>>>>>>>>>>>> Maybe
>>>>>>>>>>>> for the speed calibration, so could be it detects ram by 
>>>>>>>>>>>> reading
>>>>>>>>>>>> DCRs then tries to get SPD data and that's where it stops as 
>>>>>>>>>>>> i2c is
>>>>>>>>>>>> not emulated on taihu. This could be confirmed by checking 
>>>>>>>>>>>> what it
>>>>>>>>>>>> pokes with -d guest_errors that shows accesses to missing 
>>>>>>>>>>>> devices
>>>>>>>>>>>> but don't know where 405 has the i2c controller and if it's 
>>>>>>>>>>>> the same
>>>>>>>>>>>> as newer SoCs. If so that could be reused and an i2c bus 
>>>>>>>>>>>> could be
>>>>>>>>>>>> added with the SPD data like in sam460ex to make u-boot 
>>>>>>>>>>>> happy or you
>>>>>>>>>>>> could skip this in u-boot.
>>>>>>>>>>>
>>>>>>>>>>> FWIW, I've just tried the latter (skipping the sdram init in 
>>>>>>>>>>> u-boot),
>>>>>>>>>>> and indeed, I can get to the u-boot prompt now.
>>>>>>>>>> [...]> I've also attached the patch with my modifications to 
>>>>>>>>>> u-boot.
>>>>>>>>>>
>>>>>>>>>> FYI, the changes can now be found on this branch here:
>>>>>>>>>>
>>>>>>>>>>   https://gitlab.com/huth/u-boot/-/commits/taihu
>>>>>>>>>>
>>>>>>>>>> I also added a gitlab-CI file, so you can now download the 
>>>>>>>>>> u-boot.bin as an
>>>>>>>>>> artifact from the corresponding pipeline, e.g.:
>>>>>>>>>>
>>>>>>>>>>   https://gitlab.com/huth/u-boot/-/jobs/1667201028
>>>>>>>>>
>>>>>>>>> Thanks.
>>>>>>>>>
>>>>>>>>> Are you going to send a v2 of your proposed deprecation patches?
>>>>>>>>
>>>>>>>> No, since there was interest in keeping the 405 boards for 
>>>>>>>> testing the 405 code in the Linux kernel, and since there is now 
>>>>>>>> a way to do at least some very basic testing of these boards 
>>>>>>>> (with the u-boot firmware), I don't plan to respin the 
>>>>>>>> deprecation patch. I just sent a patch for adding the boards to 
>>>>>>>> our CI instead:
>>>>>>>>
>>>>>>>>   https://lists.gnu.org/archive/html/qemu-devel/2021-10/msg02072.html 
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> I have downloaded your u-boot.bin and tried it with both QEMU 
>>>>>>> 5.2.0 and mainline, and I get:
>>>>>>>
>>>>>>> ERROR:../accel/tcg/tcg-accel-ops.c:79:tcg_handle_interrupt: 
>>>>>>> assertion failed: (qemu_mutex_iothread_locked())
>>>>>>> Bail out! 
>>>>>>> ERROR:../accel/tcg/tcg-accel-ops.c:79:tcg_handle_interrupt: 
>>>>>>> assertion failed: (qemu_mutex_iothread_locked())
>>>>>>> Abandon (core dumped)
>>>>>>>
>>>>>>> I see in the mail history that you got that problem as well at 
>>>>>>> some point. How did you fix it ?
>>>>>>
>>>>>> You need this patch here to fix this issue:
>>>>>>
>>>>>>   https://lists.gnu.org/archive/html/qemu-devel/2021-10/msg01019.html
>>>>>>   ("hw/ppc: Fix iothread locking in the 405 code")
>>>>>>
>>>>>
>>>>> Thank you.
>>>>>
>>>>> Is there anything special to do then in order to boot a Linux kernel ?
>>>>>
>>>>> I build the uImage for ppc40x_defconfig
>>>>>
>>>>> I use the following command, but it does nothing, it stays in uboot 
>>>>> prompt as when I don't get a kernel argument
>>>>>
>>>>>     ~/qemu/build/qemu-system-ppc -M taihu -bios 
>>>>> ~/Téléchargements/u-boot.bin -serial null -serial mon:stdio -kernel 
>>>>> arch/powerpc/boot/uImage
>>>>
>>>> I'm not sure using -bios and -kernel together makes sense, it 
>>>> probably starts u-boot in this case and you have to load and start 
>>>> the kernel from u-boot as you'd notmally do on a real machine. 
>>>> Alternatively you could use -kernel instead of -bios which then 
>>>> loads a kernel and starts it directly but not sure if it needs a 
>>>> firmware to work.
>>>>
>>>> Ot I could be completely wrong as I don't know this machine and 
>>>> haven't tried it.
>>>
>>> Actually, these 405 machines are quite weird. They refuse to boot 
>>> without bios image, so you currently need the firmware image for sure.
>>>
>>> OTOH, when you look at the ref405ep_init() function, it seems that at 
>>> least the ref405ep machine was once supposed to start a kernel directly:
>>>
>>>          env->nip = KERNEL_LOAD_ADDR;
>>>
>>> ... however, this does not seem to work anymore, the initial NIP is 
>>> always reset to the firmware entry when the board resets. Not sure 
>>> if/how this ever used worked ...
>>>
>>
>> On the e500 we use both -bios and -kernel:
>>
>>     qemu-system-ppc64 -nographic -M ppce500 -cpu e5500 -m 1G -bios 
>> u-boot-e500 -kernel ./arch/powerpc/boot/uImage  -initrd 
>> ./qemu/rootfs.cpio.gz -append noreboot -s
>>
>>
>> Uboot for e500 has the following environment:
>>
>>     => printenv
>>     bootcmd=test -n "$qemu_kernel_addr" && bootm $qemu_kernel_addr - 
>> $fdt_addr_r
>>     fdt_addr_r=e8000000
>>     qemu_kernel_addr=2000000
>>     stderr=serial
>>     stdin=serial
>>     stdout=serial
>>
>>     Environment size: 164/8188 bytes
> 
> The -bios and -kernel options are handled by the machine code so these 
> work differently on every machine depending on what they decide to do 
> for these.
> 
>> I think I need to findout where QEMU loads the kernel when using TAIHU 
>> machine.
> 
> Look in qemu/hw/ppc/ppc405_boards.c it has
> #define KERNEL_LOAD_ADDR 0x00000000
> but it does not seem to do anything with a kernel other than loading it. 
> I don't see anything that would start the kernel. I think this board is 
> probably unfinished, if you want to use it you may need to implement 
> some stuff in it. Also try using -d unimp,guest_errors options to see 
> errors when something goes wrong otherwise you may not get much feedback.
> 

There is something:

=> bootm 0
Wrong Image Format for bootm command
ERROR: can't get kernel image!

=> md 0
00000000: 00000000 b497aae1 616e9207 003227a4    '..V....an...2'.
00000010: 00000000 00000000 ee36255f 05070201    .........6%_....
00000020: 4c696e75 782d352e 31352e30 2d726335    Linux-5.15.0-rc5
00000030: 2d303232 32342d67 61336330 30376164    -02224-ga3c007ad
00000040: 1f8b0800 00000000 0203ec5c 0f7013e7    ...........\.p..

=> mw.l 0 0x27051956

=> bootm 0
## Booting kernel from Legacy Image at 00000000 ...
    Image Name:   Linux-5.15.0-rc5-02224-ga3c007ad
    Image Type:   PowerPC Linux Kernel Image (gzip compressed)
    Data Size:    3286948 Bytes = 3.1 MiB
    Load Address: 00000000
    Entry Point:  00000000
    Verifying Checksum ... Bad Data CRC
ERROR: can't get kernel image!


So we have something but it seems it gets overwritten by stuff.

Anyway loading a uImage at 0 is just bad because it is a gzipped image 
that should get gunzipped at address 0.

Or should we just copy the raw kernel at 0 and jump to the entry point ? 
But then we also need a device tree somewhere.

Christophe

Re: Deprecate the ppc405 boards in QEMU?

[Christophe Leroy]

Le 19/10/2021 à 15:44, Christophe Leroy a écrit :
> 
> 
> Le 19/10/2021 à 14:38, BALATON Zoltan a écrit :
>> On Tue, 19 Oct 2021, Christophe Leroy wrote:
>>> Le 19/10/2021 à 13:11, Thomas Huth a écrit :
>>>> On 19/10/2021 12.07, BALATON Zoltan wrote:
>>>>> On Tue, 19 Oct 2021, Christophe Leroy wrote:
>>>>>> Le 19/10/2021 à 11:39, Thomas Huth a écrit :
>>>>>>> On 19/10/2021 11.31, Christophe Leroy wrote:
>>>>>>>> Le 11/10/2021 à 15:24, Thomas Huth a écrit :
>>>>>>>>> On 11/10/2021 11.20, David Gibson wrote:
>>>>>>>>>> On Mon, Oct 11, 2021 at 10:10:36AM +0200, Thomas Huth wrote:
>>>>>>>>>>> On 06/10/2021 09.25, Thomas Huth wrote:
>>>>>>>>>>>> On 05/10/2021 23.53, BALATON Zoltan wrote:
>>>>>>>>>>>> [...]
>>>>>>>>>>>>> Maybe these 405 boards in QEMU ran with modified firmware 
>>>>>>>>>>>>> where the
>>>>>>>>>>>>> memory detection was patched out but it seems to detect the 
>>>>>>>>>>>>> RAM so I
>>>>>>>>>>>>> wonder where it gets that from. Maybe by reading the SDRAM
>>>>>>>>>>>>> controller DCRs ppc4xx_sdram_init() sets up. Then I'm not 
>>>>>>>>>>>>> sure what
>>>>>>>>>>>>> it needs the SPD for, I forgot how this worked on sam460ex. 
>>>>>>>>>>>>> Maybe
>>>>>>>>>>>>> for the speed calibration, so could be it detects ram by 
>>>>>>>>>>>>> reading
>>>>>>>>>>>>> DCRs then tries to get SPD data and that's where it stops 
>>>>>>>>>>>>> as i2c is
>>>>>>>>>>>>> not emulated on taihu. This could be confirmed by checking 
>>>>>>>>>>>>> what it
>>>>>>>>>>>>> pokes with -d guest_errors that shows accesses to missing 
>>>>>>>>>>>>> devices
>>>>>>>>>>>>> but don't know where 405 has the i2c controller and if it's 
>>>>>>>>>>>>> the same
>>>>>>>>>>>>> as newer SoCs. If so that could be reused and an i2c bus 
>>>>>>>>>>>>> could be
>>>>>>>>>>>>> added with the SPD data like in sam460ex to make u-boot 
>>>>>>>>>>>>> happy or you
>>>>>>>>>>>>> could skip this in u-boot.
>>>>>>>>>>>>
>>>>>>>>>>>> FWIW, I've just tried the latter (skipping the sdram init in 
>>>>>>>>>>>> u-boot),
>>>>>>>>>>>> and indeed, I can get to the u-boot prompt now.
>>>>>>>>>>> [...]> I've also attached the patch with my modifications to 
>>>>>>>>>>> u-boot.
>>>>>>>>>>>
>>>>>>>>>>> FYI, the changes can now be found on this branch here:
>>>>>>>>>>>
>>>>>>>>>>>   https://gitlab.com/huth/u-boot/-/commits/taihu
>>>>>>>>>>>
>>>>>>>>>>> I also added a gitlab-CI file, so you can now download the 
>>>>>>>>>>> u-boot.bin as an
>>>>>>>>>>> artifact from the corresponding pipeline, e.g.:
>>>>>>>>>>>
>>>>>>>>>>>   https://gitlab.com/huth/u-boot/-/jobs/1667201028
>>>>>>>>>>
>>>>>>>>>> Thanks.
>>>>>>>>>>
>>>>>>>>>> Are you going to send a v2 of your proposed deprecation patches?
>>>>>>>>>
>>>>>>>>> No, since there was interest in keeping the 405 boards for 
>>>>>>>>> testing the 405 code in the Linux kernel, and since there is 
>>>>>>>>> now a way to do at least some very basic testing of these 
>>>>>>>>> boards (with the u-boot firmware), I don't plan to respin the 
>>>>>>>>> deprecation patch. I just sent a patch for adding the boards to 
>>>>>>>>> our CI instead:
>>>>>>>>>
>>>>>>>>>   https://lists.gnu.org/archive/html/qemu-devel/2021-10/msg02072.html 
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> I have downloaded your u-boot.bin and tried it with both QEMU 
>>>>>>>> 5.2.0 and mainline, and I get:
>>>>>>>>
>>>>>>>> ERROR:../accel/tcg/tcg-accel-ops.c:79:tcg_handle_interrupt: 
>>>>>>>> assertion failed: (qemu_mutex_iothread_locked())
>>>>>>>> Bail out! 
>>>>>>>> ERROR:../accel/tcg/tcg-accel-ops.c:79:tcg_handle_interrupt: 
>>>>>>>> assertion failed: (qemu_mutex_iothread_locked())
>>>>>>>> Abandon (core dumped)
>>>>>>>>
>>>>>>>> I see in the mail history that you got that problem as well at 
>>>>>>>> some point. How did you fix it ?
>>>>>>>
>>>>>>> You need this patch here to fix this issue:
>>>>>>>
>>>>>>>   https://lists.gnu.org/archive/html/qemu-devel/2021-10/msg01019.html 
>>>>>>>
>>>>>>>   ("hw/ppc: Fix iothread locking in the 405 code")
>>>>>>>
>>>>>>
>>>>>> Thank you.
>>>>>>
>>>>>> Is there anything special to do then in order to boot a Linux 
>>>>>> kernel ?
>>>>>>
>>>>>> I build the uImage for ppc40x_defconfig
>>>>>>
>>>>>> I use the following command, but it does nothing, it stays in 
>>>>>> uboot prompt as when I don't get a kernel argument
>>>>>>
>>>>>>     ~/qemu/build/qemu-system-ppc -M taihu -bios 
>>>>>> ~/Téléchargements/u-boot.bin -serial null -serial mon:stdio 
>>>>>> -kernel arch/powerpc/boot/uImage
>>>>>
>>>>> I'm not sure using -bios and -kernel together makes sense, it 
>>>>> probably starts u-boot in this case and you have to load and start 
>>>>> the kernel from u-boot as you'd notmally do on a real machine. 
>>>>> Alternatively you could use -kernel instead of -bios which then 
>>>>> loads a kernel and starts it directly but not sure if it needs a 
>>>>> firmware to work.
>>>>>
>>>>> Ot I could be completely wrong as I don't know this machine and 
>>>>> haven't tried it.
>>>>
>>>> Actually, these 405 machines are quite weird. They refuse to boot 
>>>> without bios image, so you currently need the firmware image for sure.
>>>>
>>>> OTOH, when you look at the ref405ep_init() function, it seems that 
>>>> at least the ref405ep machine was once supposed to start a kernel 
>>>> directly:
>>>>
>>>>          env->nip = KERNEL_LOAD_ADDR;
>>>>
>>>> ... however, this does not seem to work anymore, the initial NIP is 
>>>> always reset to the firmware entry when the board resets. Not sure 
>>>> if/how this ever used worked ...
>>>>
>>>
>>> On the e500 we use both -bios and -kernel:
>>>
>>>     qemu-system-ppc64 -nographic -M ppce500 -cpu e5500 -m 1G -bios 
>>> u-boot-e500 -kernel ./arch/powerpc/boot/uImage  -initrd 
>>> ./qemu/rootfs.cpio.gz -append noreboot -s
>>>
>>>
>>> Uboot for e500 has the following environment:
>>>
>>>     => printenv
>>>     bootcmd=test -n "$qemu_kernel_addr" && bootm $qemu_kernel_addr - 
>>> $fdt_addr_r
>>>     fdt_addr_r=e8000000
>>>     qemu_kernel_addr=2000000
>>>     stderr=serial
>>>     stdin=serial
>>>     stdout=serial
>>>
>>>     Environment size: 164/8188 bytes
>>
>> The -bios and -kernel options are handled by the machine code so these 
>> work differently on every machine depending on what they decide to do 
>> for these.
>>
>>> I think I need to findout where QEMU loads the kernel when using 
>>> TAIHU machine.
>>
>> Look in qemu/hw/ppc/ppc405_boards.c it has
>> #define KERNEL_LOAD_ADDR 0x00000000
>> but it does not seem to do anything with a kernel other than loading 
>> it. I don't see anything that would start the kernel. I think this 
>> board is probably unfinished, if you want to use it you may need to 
>> implement some stuff in it. Also try using -d unimp,guest_errors 
>> options to see errors when something goes wrong otherwise you may not 
>> get much feedback.
>>
> 
> There is something:
> 
> => bootm 0
> Wrong Image Format for bootm command
> ERROR: can't get kernel image!
> 
> => md 0
> 00000000: 00000000 b497aae1 616e9207 003227a4    '..V....an...2'.
> 00000010: 00000000 00000000 ee36255f 05070201    .........6%_....
> 00000020: 4c696e75 782d352e 31352e30 2d726335    Linux-5.15.0-rc5
> 00000030: 2d303232 32342d67 61336330 30376164    -02224-ga3c007ad
> 00000040: 1f8b0800 00000000 0203ec5c 0f7013e7    ...........\.p..
> 
> => mw.l 0 0x27051956
> 
> => bootm 0
> ## Booting kernel from Legacy Image at 00000000 ...
>     Image Name:   Linux-5.15.0-rc5-02224-ga3c007ad
>     Image Type:   PowerPC Linux Kernel Image (gzip compressed)
>     Data Size:    3286948 Bytes = 3.1 MiB
>     Load Address: 00000000
>     Entry Point:  00000000
>     Verifying Checksum ... Bad Data CRC
> ERROR: can't get kernel image!
> 
> 
> So we have something but it seems it gets overwritten by stuff.
> 
> Anyway loading a uImage at 0 is just bad because it is a gzipped image 
> that should get gunzipped at address 0.
> 
> Or should we just copy the raw kernel at 0 and jump to the entry point ? 
> But then we also need a device tree somewhere.
> 

If I change KERNEL_LOAD_ADDR to 0x1000000, I can bootm at that address, 
and it seems it properly decompress the kernel:

=> bootm 0x1000000
## Booting kernel from Legacy Image at 01000000 ...
    Image Name:   Linux-5.15.0-rc5-02224-ga3c007ad
    Image Type:   PowerPC Linux Kernel Image (gzip compressed)
    Data Size:    3296789 Bytes = 3.1 MiB
    Load Address: 00000000
    Entry Point:  00000000
    Verifying Checksum ... OK
    Uncompressing Kernel Image ... OK


And it initialises the MMU properly.

Then it gets stuck because there is no devicetree.

(gdb) bt
#0  0xc00094cc in udelay ()
#1  0xc0025d34 in panic ()
#2  0xc06415a0 in early_init_devtree ()
#3  0xc0641da8 in machine_init ()
#4  0xc0002200 in start_here ()

Christophe

Re: Deprecate the ppc405 boards in QEMU?

[BALATON Zoltan]

[-- Attachment #1: Type: text/plain, Size: 2797 bytes --]

On Tue, 19 Oct 2021, Christophe Leroy wrote:
> Le 19/10/2021 à 15:44, Christophe Leroy a écrit :
>> There is something:
>> 
>> => bootm 0
>> Wrong Image Format for bootm command
>> ERROR: can't get kernel image!
>> 
>> => md 0
>> 00000000: 00000000 b497aae1 616e9207 003227a4    '..V....an...2'.
>> 00000010: 00000000 00000000 ee36255f 05070201    .........6%_....
>> 00000020: 4c696e75 782d352e 31352e30 2d726335    Linux-5.15.0-rc5
>> 00000030: 2d303232 32342d67 61336330 30376164    -02224-ga3c007ad
>> 00000040: 1f8b0800 00000000 0203ec5c 0f7013e7    ...........\.p..
>> 
>> => mw.l 0 0x27051956
>> 
>> => bootm 0
>> ## Booting kernel from Legacy Image at 00000000 ...
>>     Image Name:   Linux-5.15.0-rc5-02224-ga3c007ad
>>     Image Type:   PowerPC Linux Kernel Image (gzip compressed)
>>     Data Size:    3286948 Bytes = 3.1 MiB
>>     Load Address: 00000000
>>     Entry Point:  00000000
>>     Verifying Checksum ... Bad Data CRC
>> ERROR: can't get kernel image!
>> 
>> 
>> So we have something but it seems it gets overwritten by stuff.
>> 
>> Anyway loading a uImage at 0 is just bad because it is a gzipped image that 
>> should get gunzipped at address 0.
>> 
>> Or should we just copy the raw kernel at 0 and jump to the entry point ? 
>> But then we also need a device tree somewhere.
>> 
>
> If I change KERNEL_LOAD_ADDR to 0x1000000, I can bootm at that address, and 
> it seems it properly decompress the kernel:
>
> => bootm 0x1000000
> ## Booting kernel from Legacy Image at 01000000 ...
>   Image Name:   Linux-5.15.0-rc5-02224-ga3c007ad
>   Image Type:   PowerPC Linux Kernel Image (gzip compressed)
>   Data Size:    3296789 Bytes = 3.1 MiB
>   Load Address: 00000000
>   Entry Point:  00000000
>   Verifying Checksum ... OK
>   Uncompressing Kernel Image ... OK
>
>
> And it initialises the MMU properly.
>
> Then it gets stuck because there is no devicetree.
>
> (gdb) bt
> #0  0xc00094cc in udelay ()
> #1  0xc0025d34 in panic ()
> #2  0xc06415a0 in early_init_devtree ()
> #3  0xc0641da8 in machine_init ()
> #4  0xc0002200 in start_here ()

Maybe you need to embed a dtb in your kernel if that's possible somehow? 
Or QEMU has a -dtb option that sets machine->dtb but you need board code 
to do something with it. See how it's done in other boards like 
virtex_ml507 and sam460ex. But maybe you'd be better off not using -kernel 
option as it seems to not really working for these 405 boards but load and 
start the kernel from u-boot. Not sure what device does u-boot support but 
QEMU can emulate usb-storage, network, different disks so something might 
work with u-boot if this board has any peripherals. If it doesn't emulate 
any peripherals what do you expect to do with the kernel once it boots?

Regards,
BALATON Zoltan

Re: Deprecate the ppc405 boards in QEMU?

[Christophe Leroy]

Le 19/10/2021 à 16:56, BALATON Zoltan a écrit :
> On Tue, 19 Oct 2021, Christophe Leroy wrote:
>> Le 19/10/2021 à 15:44, Christophe Leroy a écrit :
>>> There is something:
>>>
>>> => bootm 0
>>> Wrong Image Format for bootm command
>>> ERROR: can't get kernel image!
>>>
>>> => md 0
>>> 00000000: 00000000 b497aae1 616e9207 003227a4    '..V....an...2'.
>>> 00000010: 00000000 00000000 ee36255f 05070201    .........6%_....
>>> 00000020: 4c696e75 782d352e 31352e30 2d726335    Linux-5.15.0-rc5
>>> 00000030: 2d303232 32342d67 61336330 30376164    -02224-ga3c007ad
>>> 00000040: 1f8b0800 00000000 0203ec5c 0f7013e7    ...........\.p..
>>>
>>> => mw.l 0 0x27051956
>>>
>>> => bootm 0
>>> ## Booting kernel from Legacy Image at 00000000 ...
>>>     Image Name:   Linux-5.15.0-rc5-02224-ga3c007ad
>>>     Image Type:   PowerPC Linux Kernel Image (gzip compressed)
>>>     Data Size:    3286948 Bytes = 3.1 MiB
>>>     Load Address: 00000000
>>>     Entry Point:  00000000
>>>     Verifying Checksum ... Bad Data CRC
>>> ERROR: can't get kernel image!
>>>
>>>
>>> So we have something but it seems it gets overwritten by stuff.
>>>
>>> Anyway loading a uImage at 0 is just bad because it is a gzipped 
>>> image that should get gunzipped at address 0.
>>>
>>> Or should we just copy the raw kernel at 0 and jump to the entry 
>>> point ? But then we also need a device tree somewhere.
>>>
>>
>> If I change KERNEL_LOAD_ADDR to 0x1000000, I can bootm at that 
>> address, and it seems it properly decompress the kernel:
>>
>> => bootm 0x1000000
>> ## Booting kernel from Legacy Image at 01000000 ...
>>   Image Name:   Linux-5.15.0-rc5-02224-ga3c007ad
>>   Image Type:   PowerPC Linux Kernel Image (gzip compressed)
>>   Data Size:    3296789 Bytes = 3.1 MiB
>>   Load Address: 00000000
>>   Entry Point:  00000000
>>   Verifying Checksum ... OK
>>   Uncompressing Kernel Image ... OK
>>
>>
>> And it initialises the MMU properly.
>>
>> Then it gets stuck because there is no devicetree.
>>
>> (gdb) bt
>> #0  0xc00094cc in udelay ()
>> #1  0xc0025d34 in panic ()
>> #2  0xc06415a0 in early_init_devtree ()
>> #3  0xc0641da8 in machine_init ()
>> #4  0xc0002200 in start_here ()
> 
> Maybe you need to embed a dtb in your kernel if that's possible somehow? 
> Or QEMU has a -dtb option that sets machine->dtb but you need board code 
> to do something with it. See how it's done in other boards like 
> virtex_ml507 and sam460ex. But maybe you'd be better off not using 
> -kernel option as it seems to not really working for these 405 boards 
> but load and start the kernel from u-boot. Not sure what device does 
> u-boot support but QEMU can emulate usb-storage, network, different 
> disks so something might work with u-boot if this board has any 
> peripherals. If it doesn't emulate any peripherals what do you expect to 
> do with the kernel once it boots?
> 

I should be able to build a multi-FIT image that embeds the kernel and 
the device tree.

I don't know about the peripherals, what I need it a kernel that is able 
to boot and run some user exe. I'm working on low level functionnalities 
like VMAP_STACK, STRICT_KERNEL_RWX, Userspace protection, etc ... I want 
to be able to check that after some modifications the kernel can still 
boot on every CPU sub-family, and I need to run LKDTM tests.

For this a kernel + initrd is enough.

Thanks
Christophe

Re: Deprecate the ppc405 boards in QEMU?

[Cédric Le Goater]

On 10/19/21 18:12, Christophe Leroy wrote:
> 
> 
> Le 19/10/2021 à 16:56, BALATON Zoltan a écrit :
>> On Tue, 19 Oct 2021, Christophe Leroy wrote:
>>> Le 19/10/2021 à 15:44, Christophe Leroy a écrit :
>>>> There is something:
>>>>
>>>> => bootm 0
>>>> Wrong Image Format for bootm command
>>>> ERROR: can't get kernel image!
>>>>
>>>> => md 0
>>>> 00000000: 00000000 b497aae1 616e9207 003227a4    '..V....an...2'.
>>>> 00000010: 00000000 00000000 ee36255f 05070201    .........6%_....
>>>> 00000020: 4c696e75 782d352e 31352e30 2d726335    Linux-5.15.0-rc5
>>>> 00000030: 2d303232 32342d67 61336330 30376164    -02224-ga3c007ad
>>>> 00000040: 1f8b0800 00000000 0203ec5c 0f7013e7    ...........\.p..
>>>>
>>>> => mw.l 0 0x27051956
>>>>
>>>> => bootm 0
>>>> ## Booting kernel from Legacy Image at 00000000 ...
>>>>     Image Name:   Linux-5.15.0-rc5-02224-ga3c007ad
>>>>     Image Type:   PowerPC Linux Kernel Image (gzip compressed)
>>>>     Data Size:    3286948 Bytes = 3.1 MiB
>>>>     Load Address: 00000000
>>>>     Entry Point:  00000000
>>>>     Verifying Checksum ... Bad Data CRC
>>>> ERROR: can't get kernel image!
>>>>
>>>>
>>>> So we have something but it seems it gets overwritten by stuff.
>>>>
>>>> Anyway loading a uImage at 0 is just bad because it is a gzipped image that should get gunzipped at address 0.
>>>>
>>>> Or should we just copy the raw kernel at 0 and jump to the entry point ? But then we also need a device tree somewhere.
>>>>
>>>
>>> If I change KERNEL_LOAD_ADDR to 0x1000000, I can bootm at that address, and it seems it properly decompress the kernel:
>>>
>>> => bootm 0x1000000
>>> ## Booting kernel from Legacy Image at 01000000 ...
>>>   Image Name:   Linux-5.15.0-rc5-02224-ga3c007ad
>>>   Image Type:   PowerPC Linux Kernel Image (gzip compressed)
>>>   Data Size:    3296789 Bytes = 3.1 MiB
>>>   Load Address: 00000000
>>>   Entry Point:  00000000
>>>   Verifying Checksum ... OK
>>>   Uncompressing Kernel Image ... OK
>>>
>>>
>>> And it initialises the MMU properly.
>>>
>>> Then it gets stuck because there is no devicetree.
>>>
>>> (gdb) bt
>>> #0  0xc00094cc in udelay ()
>>> #1  0xc0025d34 in panic ()
>>> #2  0xc06415a0 in early_init_devtree ()
>>> #3  0xc0641da8 in machine_init ()
>>> #4  0xc0002200 in start_here ()
>>
>> Maybe you need to embed a dtb in your kernel if that's possible somehow? Or QEMU has a -dtb option that sets machine->dtb but you need board code to do something with it. See how it's done in other boards like virtex_ml507 and sam460ex. But maybe you'd be better off not using -kernel option as it seems to not really working for these 405 boards but load and start the kernel from u-boot. Not sure what device does u-boot support but QEMU can emulate usb-storage, network, different disks so something might work with u-boot if this board has any peripherals. If it doesn't emulate any peripherals what do you expect to do with the kernel once it boots?
>>
> 
> I should be able to build a multi-FIT image that embeds the kernel and the device tree.
> 
> I don't know about the peripherals, what I need it a kernel that is able to boot and run some user exe. I'm working on low level functionnalities like VMAP_STACK, STRICT_KERNEL_RWX, Userspace protection, etc ... I want to be able to check that after some modifications the kernel can still boot on every CPU sub-family, and I need to run LKDTM tests.
> 
> For this a kernel + initrd is enough.
> 
> Thanks
> Christophe

If we don't need a loader, we are better off simplifying the 405 boards with
a simple init sequence such as :

     if (machine->kernel_filename) {
         hwaddr kernel_base = 0;
         int kernel_size = 0;
         hwaddr initrd_base = 0;
         int initrd_size = 0;

         kernel_size = load_elf(machine->kernel_filename, NULL, NULL, NULL,
                                &boot_entry, &kernel_base, NULL, NULL,
                                0 /* LE */, PPC_ELF_MACHINE, 0, 0);
         if (kernel_size < 0) {
             error_report("Could not load kernel '%s' : %s",
                          machine->kernel_filename, load_elf_strerror(kernel_size));
             exit(1);
         }

         if (machine->initrd_filename) {
             initrd_base = QEMU_ALIGN_UP(kernel_base + kernel_size, 0x10000);
             initrd_size = load_image_targphys(machine->initrd_filename,
                                               initrd_base, 16 * MiB /* Some value */);
             if (initrd_size < 0) {
                 error_report("Could not load initial ram disk '%s'",
                              machine->initrd_filename);
                 exit(1);
             }
         }

         if (machine->dtb) {
             dt_base = mw_dtb_load(machine, kernel_base, kernel_size, initrd_base,
                                   initrd_size);
         }
     }

We need to set the nip to 'boot_entry' and gpr[3] to 'dt_base'.

unless some pre-initialization of hw is required before running Linux ?

Thanks,

C.

Re: Deprecate the ppc405 boards in QEMU?

[Cédric Le Goater]

On 10/19/21 18:12, Christophe Leroy wrote:
> 
> 
> Le 19/10/2021 à 16:56, BALATON Zoltan a écrit :
>> On Tue, 19 Oct 2021, Christophe Leroy wrote:
>>> Le 19/10/2021 à 15:44, Christophe Leroy a écrit :
>>>> There is something:
>>>>
>>>> => bootm 0
>>>> Wrong Image Format for bootm command
>>>> ERROR: can't get kernel image!
>>>>
>>>> => md 0
>>>> 00000000: 00000000 b497aae1 616e9207 003227a4    '..V....an...2'.
>>>> 00000010: 00000000 00000000 ee36255f 05070201    .........6%_....
>>>> 00000020: 4c696e75 782d352e 31352e30 2d726335    Linux-5.15.0-rc5
>>>> 00000030: 2d303232 32342d67 61336330 30376164    -02224-ga3c007ad
>>>> 00000040: 1f8b0800 00000000 0203ec5c 0f7013e7    ...........\.p..
>>>>
>>>> => mw.l 0 0x27051956
>>>>
>>>> => bootm 0
>>>> ## Booting kernel from Legacy Image at 00000000 ...
>>>>     Image Name:   Linux-5.15.0-rc5-02224-ga3c007ad
>>>>     Image Type:   PowerPC Linux Kernel Image (gzip compressed)
>>>>     Data Size:    3286948 Bytes = 3.1 MiB
>>>>     Load Address: 00000000
>>>>     Entry Point:  00000000
>>>>     Verifying Checksum ... Bad Data CRC
>>>> ERROR: can't get kernel image!
>>>>
>>>>
>>>> So we have something but it seems it gets overwritten by stuff.
>>>>
>>>> Anyway loading a uImage at 0 is just bad because it is a gzipped image that should get gunzipped at address 0.
>>>>
>>>> Or should we just copy the raw kernel at 0 and jump to the entry point ? But then we also need a device tree somewhere.
>>>>
>>>
>>> If I change KERNEL_LOAD_ADDR to 0x1000000, I can bootm at that address, and it seems it properly decompress the kernel:
>>>
>>> => bootm 0x1000000
>>> ## Booting kernel from Legacy Image at 01000000 ...
>>>   Image Name:   Linux-5.15.0-rc5-02224-ga3c007ad
>>>   Image Type:   PowerPC Linux Kernel Image (gzip compressed)
>>>   Data Size:    3296789 Bytes = 3.1 MiB
>>>   Load Address: 00000000
>>>   Entry Point:  00000000
>>>   Verifying Checksum ... OK
>>>   Uncompressing Kernel Image ... OK
>>>
>>>
>>> And it initialises the MMU properly.
>>>
>>> Then it gets stuck because there is no devicetree.
>>>
>>> (gdb) bt
>>> #0  0xc00094cc in udelay ()
>>> #1  0xc0025d34 in panic ()
>>> #2  0xc06415a0 in early_init_devtree ()
>>> #3  0xc0641da8 in machine_init ()
>>> #4  0xc0002200 in start_here ()
>>
>> Maybe you need to embed a dtb in your kernel if that's possible somehow? Or QEMU has a -dtb option that sets machine->dtb but you need board code to do something with it. See how it's done in other boards like virtex_ml507 and sam460ex. But maybe you'd be better off not using -kernel option as it seems to not really working for these 405 boards but load and start the kernel from u-boot. Not sure what device does u-boot support but QEMU can emulate usb-storage, network, different disks so something might work with u-boot if this board has any peripherals. If it doesn't emulate any peripherals what do you expect to do with the kernel once it boots?
>>
> 
> I should be able to build a multi-FIT image that embeds the kernel and the device tree.
> 
> I don't know about the peripherals, what I need it a kernel that is able to boot and run some user exe. I'm working on low level functionnalities like VMAP_STACK, STRICT_KERNEL_RWX, Userspace protection, etc ... I want to be able to check that after some modifications the kernel can still boot on every CPU sub-family, and I need to run LKDTM tests.
> 
> For this a kernel + initrd is enough.

hotfoot.dts is the only DT with a CPU model "PowerPC,405EP".

With cuImage.hotfoot,

U-Boot 2015.10-00236-g677f970bc6-dirty (Oct 06 2021 - 08:59:53 +0200)

CPU:   AMCC PowerPC 405EP Rev. B at 770 MHz (PLB=256 OPB=128 EBC=128)
        I2C boot EEPROM disabled
        Internal PCI arbiter enabled
        16 KiB I-Cache 16 KiB D-Cache
Board: Taihu - AMCC PPC405EP Evaluation Board
I2C:   ready
DRAM:  128 MiB
Flash: ## Unknown FLASH on Bank 0 - Size = 0x00000000 = 0 MB
## Unknown FLASH on Bank 1 - Size = 0x00000000 = 0 MB
0 Bytes
*** Warning - bad CRC, using default environment

PCI:   Bus Dev VenId DevId Class Int
PCI:
Net:   No ethernet found.

Type run flash_nfs to mount root filesystem over NFS

Hit any key to stop autoboot:  0
=> bootm 01000000
## Booting kernel from Legacy Image at 01000000 ...
    Image Name:   Linux-5.15.0-rc6-dirty
    Image Type:   PowerPC Linux Kernel Image (gzip compressed)
    Data Size:    3326878 Bytes = 3.2 MiB
    Load Address: 00700000
    Entry Point:  00701aa8
    Verifying Checksum ... OK
    Uncompressing Kernel Image ... OK
Memory <- <0x0 0x8000000> (128MB)
CPU clock-frequency <- 0x0 (0MHz)
CPU timebase-frequency <- 0x0 (0MHz)
/plb: clock-frequency <- 0 (0MHz)
/plb/opb: clock-frequency <- 0 (0MHz)
/plb/ebc: clock-frequency <- 0 (0MHz)
/plb/opb/serial@ef600300: clock-frequency <- 0 (0MHz)
/plb/opb/serial@ef600400: clock-frequency <- 0 (0MHz)
ethernet0: local-mac-address <- 00:00:00:00:00:00
ethernet1: local-mac-address <- 00:00:2d:e5:44:80
Fixing devtree for 4M Flash

zImage starting: loaded at 0x00700000 (sp: 0x07eaabb0)
Decompression error: 'Not a gzip file'
No valid compressed data found, assume uncompressed data
Allocating 0x6c128c bytes for kernel...
0x69e1ec bytes of uncompressed data copied

Linux/PowerPC load:
Finalizing device tree... flat tree at 0xdc5960
Linux version 5.15.0-rc6-dirty (legoater@yukon) (powerpc64-linux-gnu-gcc (GCC) 11.2.1 20210728 (Red Hat Cross 11.2.1-1), GNU ld version 2.35.2-1.fc34) #1 Tue Oct 19 15:15:21 CEST 2021
Using PowerPC 40x Platform machine description
printk: bootconsole [udbg0] enabled
-----------------------------------------------------
phys_mem_size     = 0x8000000
dcache_bsize      = 0x20
icache_bsize      = 0x20
cpu_features      = 0x0000000000000100
   possible        = 0x0000000000000100
   always          = 0x0000000000000100
cpu_user_features = 0x86000000 0x00000000
mmu_features      = 0x00000004
-----------------------------------------------------
Zone ranges:
   Normal   [mem 0x0000000000000000-0x0000000007ffffff]
Movable zone start for each node
Early memory node ranges
   node   0: [mem 0x0000000000000000-0x0000000007ffffff]
Initmem setup node 0 [mem 0x0000000000000000-0x0000000007ffffff]
MMU: Allocated 1088 bytes of context maps for 255 contexts
Built 1 zonelists, mobility grouping on.  Total pages: 32512
Kernel command line:
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes, linear)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes, linear)
mem auto-init: stack:off, heap alloc:off, heap free:off
Kernel virtual memory layout:
   * 0xffbdf000..0xfffff000  : fixmap
   * 0xc9000000..0xffbdf000  : vmalloc & ioremap
Memory: 122948K/131072K available (5040K kernel code, 220K rwdata, 1320K rodata, 200K init, 136K bss, 8124K reserved, 0K cma-reserved)
SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
NR_IRQS: 512, nr_irqs: 512, preallocated irqs: 16
UIC0 (32 IRQ sources) at DCR 0xc0
random: get_random_u32 called from start_kernel+0x498/0x5f8 with crng_init=0

Re: Deprecate the ppc405 boards in QEMU?

[Christophe Leroy]

Le 19/10/2021 à 23:30, Cédric Le Goater a écrit :
> On 10/19/21 18:12, Christophe Leroy wrote:
>>
>>
>> Le 19/10/2021 à 16:56, BALATON Zoltan a écrit :
>>> On Tue, 19 Oct 2021, Christophe Leroy wrote:
>>>> Le 19/10/2021 à 15:44, Christophe Leroy a écrit :
>>>>> There is something:
>>>>>
>>>>> => bootm 0
>>>>> Wrong Image Format for bootm command
>>>>> ERROR: can't get kernel image!
>>>>>
>>>>> => md 0
>>>>> 00000000: 00000000 b497aae1 616e9207 003227a4    '..V....an...2'.
>>>>> 00000010: 00000000 00000000 ee36255f 05070201    .........6%_....
>>>>> 00000020: 4c696e75 782d352e 31352e30 2d726335    Linux-5.15.0-rc5
>>>>> 00000030: 2d303232 32342d67 61336330 30376164    -02224-ga3c007ad
>>>>> 00000040: 1f8b0800 00000000 0203ec5c 0f7013e7    ...........\.p..
>>>>>
>>>>> => mw.l 0 0x27051956
>>>>>
>>>>> => bootm 0
>>>>> ## Booting kernel from Legacy Image at 00000000 ...
>>>>>     Image Name:   Linux-5.15.0-rc5-02224-ga3c007ad
>>>>>     Image Type:   PowerPC Linux Kernel Image (gzip compressed)
>>>>>     Data Size:    3286948 Bytes = 3.1 MiB
>>>>>     Load Address: 00000000
>>>>>     Entry Point:  00000000
>>>>>     Verifying Checksum ... Bad Data CRC
>>>>> ERROR: can't get kernel image!
>>>>>
>>>>>
>>>>> So we have something but it seems it gets overwritten by stuff.
>>>>>
>>>>> Anyway loading a uImage at 0 is just bad because it is a gzipped 
>>>>> image that should get gunzipped at address 0.
>>>>>
>>>>> Or should we just copy the raw kernel at 0 and jump to the entry 
>>>>> point ? But then we also need a device tree somewhere.
>>>>>
>>>>
>>>> If I change KERNEL_LOAD_ADDR to 0x1000000, I can bootm at that 
>>>> address, and it seems it properly decompress the kernel:
>>>>
>>>> => bootm 0x1000000
>>>> ## Booting kernel from Legacy Image at 01000000 ...
>>>>   Image Name:   Linux-5.15.0-rc5-02224-ga3c007ad
>>>>   Image Type:   PowerPC Linux Kernel Image (gzip compressed)
>>>>   Data Size:    3296789 Bytes = 3.1 MiB
>>>>   Load Address: 00000000
>>>>   Entry Point:  00000000
>>>>   Verifying Checksum ... OK
>>>>   Uncompressing Kernel Image ... OK
>>>>
>>>>
>>>> And it initialises the MMU properly.
>>>>
>>>> Then it gets stuck because there is no devicetree.
>>>>
>>>> (gdb) bt
>>>> #0  0xc00094cc in udelay ()
>>>> #1  0xc0025d34 in panic ()
>>>> #2  0xc06415a0 in early_init_devtree ()
>>>> #3  0xc0641da8 in machine_init ()
>>>> #4  0xc0002200 in start_here ()
>>>
>>> Maybe you need to embed a dtb in your kernel if that's possible 
>>> somehow? Or QEMU has a -dtb option that sets machine->dtb but you 
>>> need board code to do something with it. See how it's done in other 
>>> boards like virtex_ml507 and sam460ex. But maybe you'd be better off 
>>> not using -kernel option as it seems to not really working for these 
>>> 405 boards but load and start the kernel from u-boot. Not sure what 
>>> device does u-boot support but QEMU can emulate usb-storage, network, 
>>> different disks so something might work with u-boot if this board has 
>>> any peripherals. If it doesn't emulate any peripherals what do you 
>>> expect to do with the kernel once it boots?
>>>
>>
>> I should be able to build a multi-FIT image that embeds the kernel and 
>> the device tree.
>>
>> I don't know about the peripherals, what I need it a kernel that is 
>> able to boot and run some user exe. I'm working on low level 
>> functionnalities like VMAP_STACK, STRICT_KERNEL_RWX, Userspace 
>> protection, etc ... I want to be able to check that after some 
>> modifications the kernel can still boot on every CPU sub-family, and I 
>> need to run LKDTM tests.
>>
>> For this a kernel + initrd is enough.
> 
> hotfoot.dts is the only DT with a CPU model "PowerPC,405EP".
> 
> With cuImage.hotfoot,
> 
> U-Boot 2015.10-00236-g677f970bc6-dirty (Oct 06 2021 - 08:59:53 +0200)
> 
> CPU:   AMCC PowerPC 405EP Rev. B at 770 MHz (PLB=256 OPB=128 EBC=128)
>         I2C boot EEPROM disabled
>         Internal PCI arbiter enabled
>         16 KiB I-Cache 16 KiB D-Cache
> Board: Taihu - AMCC PPC405EP Evaluation Board
> I2C:   ready
> DRAM:  128 MiB
> Flash: ## Unknown FLASH on Bank 0 - Size = 0x00000000 = 0 MB
> ## Unknown FLASH on Bank 1 - Size = 0x00000000 = 0 MB
> 0 Bytes
> *** Warning - bad CRC, using default environment
> 
> PCI:   Bus Dev VenId DevId Class Int
> PCI:
> Net:   No ethernet found.
> 
> Type run flash_nfs to mount root filesystem over NFS
> 
> Hit any key to stop autoboot:  0
> => bootm 01000000
> ## Booting kernel from Legacy Image at 01000000 ...
>     Image Name:   Linux-5.15.0-rc6-dirty
>     Image Type:   PowerPC Linux Kernel Image (gzip compressed)
>     Data Size:    3326878 Bytes = 3.2 MiB
>     Load Address: 00700000
>     Entry Point:  00701aa8
>     Verifying Checksum ... OK
>     Uncompressing Kernel Image ... OK
> Memory <- <0x0 0x8000000> (128MB)
> CPU clock-frequency <- 0x0 (0MHz)
> CPU timebase-frequency <- 0x0 (0MHz)
> /plb: clock-frequency <- 0 (0MHz)
> /plb/opb: clock-frequency <- 0 (0MHz)
> /plb/ebc: clock-frequency <- 0 (0MHz)
> /plb/opb/serial@ef600300: clock-frequency <- 0 (0MHz)
> /plb/opb/serial@ef600400: clock-frequency <- 0 (0MHz)
> ethernet0: local-mac-address <- 00:00:00:00:00:00
> ethernet1: local-mac-address <- 00:00:2d:e5:44:80
> Fixing devtree for 4M Flash
> 
> zImage starting: loaded at 0x00700000 (sp: 0x07eaabb0)
> Decompression error: 'Not a gzip file'
> No valid compressed data found, assume uncompressed data
> Allocating 0x6c128c bytes for kernel...
> 0x69e1ec bytes of uncompressed data copied
> 
> Linux/PowerPC load:
> Finalizing device tree... flat tree at 0xdc5960
> Linux version 5.15.0-rc6-dirty (legoater@yukon) (powerpc64-linux-gnu-gcc 
> (GCC) 11.2.1 20210728 (Red Hat Cross 11.2.1-1), GNU ld version 
> 2.35.2-1.fc34) #1 Tue Oct 19 15:15:21 CEST 2021
> Using PowerPC 40x Platform machine description
> printk: bootconsole [udbg0] enabled
> -----------------------------------------------------
> phys_mem_size     = 0x8000000
> dcache_bsize      = 0x20
> icache_bsize      = 0x20
> cpu_features      = 0x0000000000000100
>    possible        = 0x0000000000000100
>    always          = 0x0000000000000100
> cpu_user_features = 0x86000000 0x00000000
> mmu_features      = 0x00000004
> -----------------------------------------------------
> Zone ranges:
>    Normal   [mem 0x0000000000000000-0x0000000007ffffff]
> Movable zone start for each node
> Early memory node ranges
>    node   0: [mem 0x0000000000000000-0x0000000007ffffff]
> Initmem setup node 0 [mem 0x0000000000000000-0x0000000007ffffff]
> MMU: Allocated 1088 bytes of context maps for 255 contexts
> Built 1 zonelists, mobility grouping on.  Total pages: 32512
> Kernel command line:
> Dentry cache hash table entries: 16384 (order: 4, 65536 bytes, linear)
> Inode-cache hash table entries: 8192 (order: 3, 32768 bytes, linear)
> mem auto-init: stack:off, heap alloc:off, heap free:off
> Kernel virtual memory layout:
>    * 0xffbdf000..0xfffff000  : fixmap
>    * 0xc9000000..0xffbdf000  : vmalloc & ioremap
> Memory: 122948K/131072K available (5040K kernel code, 220K rwdata, 1320K 
> rodata, 200K init, 136K bss, 8124K reserved, 0K cma-reserved)
> SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
> NR_IRQS: 512, nr_irqs: 512, preallocated irqs: 16
> UIC0 (32 IRQ sources) at DCR 0xc0
> random: get_random_u32 called from start_kernel+0x498/0x5f8 with 
> crng_init=0
> 

Great.

(gdb) bt
#0  __div64_32 () at arch/powerpc/lib/div64.S:29
#1  0xc00099bc in div128_by_32 (dividend_high=<optimized out>, 
dividend_low=<optimized out>, divisor=<optimized out>, 
dr=dr@entry=0xc0693f78) at arch/powerpc/kernel/time.c:1038
#2  0xc0641060 in time_init () at arch/powerpc/kernel/time.c:978
#3  0xc063dc48 in start_kernel () at init/main.c:1055
#4  0xc0002204 in start_here () at arch/powerpc/kernel/head_40x.S:617


Looping forever in __div64_32() due to:

 > CPU clock-frequency <- 0x0 (0MHz)
 > CPU timebase-frequency <- 0x0 (0MHz)
 > /plb: clock-frequency <- 0 (0MHz)
 > /plb/opb: clock-frequency <- 0 (0MHz)
 > /plb/ebc: clock-frequency <- 0 (0MHz)
 > /plb/opb/serial@ef600300: clock-frequency <- 0 (0MHz)
 > /plb/opb/serial@ef600400: clock-frequency <- 0 (0MHz)


Christophe

Re: Deprecate the ppc405 boards in QEMU?

[Cédric Le Goater]

On 10/20/21 11:02, Christophe Leroy wrote:
> 
> 
> Le 19/10/2021 à 23:30, Cédric Le Goater a écrit :
>> On 10/19/21 18:12, Christophe Leroy wrote:
>>>
>>>
>>> Le 19/10/2021 à 16:56, BALATON Zoltan a écrit :
>>>> On Tue, 19 Oct 2021, Christophe Leroy wrote:
>>>>> Le 19/10/2021 à 15:44, Christophe Leroy a écrit :
>>>>>> There is something:
>>>>>>
>>>>>> => bootm 0
>>>>>> Wrong Image Format for bootm command
>>>>>> ERROR: can't get kernel image!
>>>>>>
>>>>>> => md 0
>>>>>> 00000000: 00000000 b497aae1 616e9207 003227a4    '..V....an...2'.
>>>>>> 00000010: 00000000 00000000 ee36255f 05070201    .........6%_....
>>>>>> 00000020: 4c696e75 782d352e 31352e30 2d726335    Linux-5.15.0-rc5
>>>>>> 00000030: 2d303232 32342d67 61336330 30376164    -02224-ga3c007ad
>>>>>> 00000040: 1f8b0800 00000000 0203ec5c 0f7013e7    ...........\.p..
>>>>>>
>>>>>> => mw.l 0 0x27051956
>>>>>>
>>>>>> => bootm 0
>>>>>> ## Booting kernel from Legacy Image at 00000000 ...
>>>>>>     Image Name:   Linux-5.15.0-rc5-02224-ga3c007ad
>>>>>>     Image Type:   PowerPC Linux Kernel Image (gzip compressed)
>>>>>>     Data Size:    3286948 Bytes = 3.1 MiB
>>>>>>     Load Address: 00000000
>>>>>>     Entry Point:  00000000
>>>>>>     Verifying Checksum ... Bad Data CRC
>>>>>> ERROR: can't get kernel image!
>>>>>>
>>>>>>
>>>>>> So we have something but it seems it gets overwritten by stuff.
>>>>>>
>>>>>> Anyway loading a uImage at 0 is just bad because it is a gzipped image that should get gunzipped at address 0.
>>>>>>
>>>>>> Or should we just copy the raw kernel at 0 and jump to the entry point ? But then we also need a device tree somewhere.
>>>>>>
>>>>>
>>>>> If I change KERNEL_LOAD_ADDR to 0x1000000, I can bootm at that address, and it seems it properly decompress the kernel:
>>>>>
>>>>> => bootm 0x1000000
>>>>> ## Booting kernel from Legacy Image at 01000000 ...
>>>>>   Image Name:   Linux-5.15.0-rc5-02224-ga3c007ad
>>>>>   Image Type:   PowerPC Linux Kernel Image (gzip compressed)
>>>>>   Data Size:    3296789 Bytes = 3.1 MiB
>>>>>   Load Address: 00000000
>>>>>   Entry Point:  00000000
>>>>>   Verifying Checksum ... OK
>>>>>   Uncompressing Kernel Image ... OK
>>>>>
>>>>>
>>>>> And it initialises the MMU properly.
>>>>>
>>>>> Then it gets stuck because there is no devicetree.
>>>>>
>>>>> (gdb) bt
>>>>> #0  0xc00094cc in udelay ()
>>>>> #1  0xc0025d34 in panic ()
>>>>> #2  0xc06415a0 in early_init_devtree ()
>>>>> #3  0xc0641da8 in machine_init ()
>>>>> #4  0xc0002200 in start_here ()
>>>>
>>>> Maybe you need to embed a dtb in your kernel if that's possible somehow? Or QEMU has a -dtb option that sets machine->dtb but you need board code to do something with it. See how it's done in other boards like virtex_ml507 and sam460ex. But maybe you'd be better off not using -kernel option as it seems to not really working for these 405 boards but load and start the kernel from u-boot. Not sure what device does u-boot support but QEMU can emulate usb-storage, network, different disks so something might work with u-boot if this board has any peripherals. If it doesn't emulate any peripherals what do you expect to do with the kernel once it boots?
>>>>
>>>
>>> I should be able to build a multi-FIT image that embeds the kernel and the device tree.
>>>
>>> I don't know about the peripherals, what I need it a kernel that is able to boot and run some user exe. I'm working on low level functionnalities like VMAP_STACK, STRICT_KERNEL_RWX, Userspace protection, etc ... I want to be able to check that after some modifications the kernel can still boot on every CPU sub-family, and I need to run LKDTM tests.
>>>
>>> For this a kernel + initrd is enough.
>>
>> hotfoot.dts is the only DT with a CPU model "PowerPC,405EP".
>>
>> With cuImage.hotfoot,
>>
>> U-Boot 2015.10-00236-g677f970bc6-dirty (Oct 06 2021 - 08:59:53 +0200)
>>
>> CPU:   AMCC PowerPC 405EP Rev. B at 770 MHz (PLB=256 OPB=128 EBC=128)
>>         I2C boot EEPROM disabled
>>         Internal PCI arbiter enabled
>>         16 KiB I-Cache 16 KiB D-Cache
>> Board: Taihu - AMCC PPC405EP Evaluation Board
>> I2C:   ready
>> DRAM:  128 MiB
>> Flash: ## Unknown FLASH on Bank 0 - Size = 0x00000000 = 0 MB
>> ## Unknown FLASH on Bank 1 - Size = 0x00000000 = 0 MB
>> 0 Bytes
>> *** Warning - bad CRC, using default environment
>>
>> PCI:   Bus Dev VenId DevId Class Int
>> PCI:
>> Net:   No ethernet found.
>>
>> Type run flash_nfs to mount root filesystem over NFS
>>
>> Hit any key to stop autoboot:  0
>> => bootm 01000000
>> ## Booting kernel from Legacy Image at 01000000 ...
>>     Image Name:   Linux-5.15.0-rc6-dirty
>>     Image Type:   PowerPC Linux Kernel Image (gzip compressed)
>>     Data Size:    3326878 Bytes = 3.2 MiB
>>     Load Address: 00700000
>>     Entry Point:  00701aa8
>>     Verifying Checksum ... OK
>>     Uncompressing Kernel Image ... OK
>> Memory <- <0x0 0x8000000> (128MB)
>> CPU clock-frequency <- 0x0 (0MHz)
>> CPU timebase-frequency <- 0x0 (0MHz)
>> /plb: clock-frequency <- 0 (0MHz)
>> /plb/opb: clock-frequency <- 0 (0MHz)
>> /plb/ebc: clock-frequency <- 0 (0MHz)
>> /plb/opb/serial@ef600300: clock-frequency <- 0 (0MHz)
>> /plb/opb/serial@ef600400: clock-frequency <- 0 (0MHz)
>> ethernet0: local-mac-address <- 00:00:00:00:00:00
>> ethernet1: local-mac-address <- 00:00:2d:e5:44:80
>> Fixing devtree for 4M Flash
>>
>> zImage starting: loaded at 0x00700000 (sp: 0x07eaabb0)
>> Decompression error: 'Not a gzip file'
>> No valid compressed data found, assume uncompressed data
>> Allocating 0x6c128c bytes for kernel...
>> 0x69e1ec bytes of uncompressed data copied
>>
>> Linux/PowerPC load:
>> Finalizing device tree... flat tree at 0xdc5960
>> Linux version 5.15.0-rc6-dirty (legoater@yukon) (powerpc64-linux-gnu-gcc (GCC) 11.2.1 20210728 (Red Hat Cross 11.2.1-1), GNU ld version 2.35.2-1.fc34) #1 Tue Oct 19 15:15:21 CEST 2021
>> Using PowerPC 40x Platform machine description
>> printk: bootconsole [udbg0] enabled
>> -----------------------------------------------------
>> phys_mem_size     = 0x8000000
>> dcache_bsize      = 0x20
>> icache_bsize      = 0x20
>> cpu_features      = 0x0000000000000100
>>    possible        = 0x0000000000000100
>>    always          = 0x0000000000000100
>> cpu_user_features = 0x86000000 0x00000000
>> mmu_features      = 0x00000004
>> -----------------------------------------------------
>> Zone ranges:
>>    Normal   [mem 0x0000000000000000-0x0000000007ffffff]
>> Movable zone start for each node
>> Early memory node ranges
>>    node   0: [mem 0x0000000000000000-0x0000000007ffffff]
>> Initmem setup node 0 [mem 0x0000000000000000-0x0000000007ffffff]
>> MMU: Allocated 1088 bytes of context maps for 255 contexts
>> Built 1 zonelists, mobility grouping on.  Total pages: 32512
>> Kernel command line:
>> Dentry cache hash table entries: 16384 (order: 4, 65536 bytes, linear)
>> Inode-cache hash table entries: 8192 (order: 3, 32768 bytes, linear)
>> mem auto-init: stack:off, heap alloc:off, heap free:off
>> Kernel virtual memory layout:
>>    * 0xffbdf000..0xfffff000  : fixmap
>>    * 0xc9000000..0xffbdf000  : vmalloc & ioremap
>> Memory: 122948K/131072K available (5040K kernel code, 220K rwdata, 1320K rodata, 200K init, 136K bss, 8124K reserved, 0K cma-reserved)
>> SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
>> NR_IRQS: 512, nr_irqs: 512, preallocated irqs: 16
>> UIC0 (32 IRQ sources) at DCR 0xc0
>> random: get_random_u32 called from start_kernel+0x498/0x5f8 with crng_init=0
>>
> 
> Great.
> 
> (gdb) bt
> #0  __div64_32 () at arch/powerpc/lib/div64.S:29
> #1  0xc00099bc in div128_by_32 (dividend_high=<optimized out>, dividend_low=<optimized out>, divisor=<optimized out>, dr=dr@entry=0xc0693f78) at arch/powerpc/kernel/time.c:1038
> #2  0xc0641060 in time_init () at arch/powerpc/kernel/time.c:978
> #3  0xc063dc48 in start_kernel () at init/main.c:1055
> #4  0xc0002204 in start_here () at arch/powerpc/kernel/head_40x.S:617
> 
> 
> Looping forever in __div64_32() due to:
> 
>  > CPU clock-frequency <- 0x0 (0MHz)
>  > CPU timebase-frequency <- 0x0 (0MHz)
>  > /plb: clock-frequency <- 0 (0MHz)
>  > /plb/opb: clock-frequency <- 0 (0MHz)
>  > /plb/ebc: clock-frequency <- 0 (0MHz)
>  > /plb/opb/serial@ef600300: clock-frequency <- 0 (0MHz)
>  > /plb/opb/serial@ef600400: clock-frequency <- 0 (0MHz)


I dont understand how

   static bd_t bd;

can be updated in the kernel.

C.

Re: Deprecate the ppc405 boards in QEMU?

[LEROY Christophe]

Le 20/10/2021 à 12:10, Cédric Le Goater a écrit :
> On 10/20/21 11:02, Christophe Leroy wrote:
>>
>>
>> Le 19/10/2021 à 23:30, Cédric Le Goater a écrit :
>>> On 10/19/21 18:12, Christophe Leroy wrote:
>>>>
>>>>
>>>> Le 19/10/2021 à 16:56, BALATON Zoltan a écrit :
>>>>> On Tue, 19 Oct 2021, Christophe Leroy wrote:
>>>>>> Le 19/10/2021 à 15:44, Christophe Leroy a écrit :
>>>>>>> There is something:
>>>>>>>
>>>>>>> => bootm 0
>>>>>>> Wrong Image Format for bootm command
>>>>>>> ERROR: can't get kernel image!
>>>>>>>
>>>>>>> => md 0
>>>>>>> 00000000: 00000000 b497aae1 616e9207 003227a4    '..V....an...2'.
>>>>>>> 00000010: 00000000 00000000 ee36255f 05070201    .........6%_....
>>>>>>> 00000020: 4c696e75 782d352e 31352e30 2d726335    Linux-5.15.0-rc5
>>>>>>> 00000030: 2d303232 32342d67 61336330 30376164    -02224-ga3c007ad
>>>>>>> 00000040: 1f8b0800 00000000 0203ec5c 0f7013e7    ...........\.p..
>>>>>>>
>>>>>>> => mw.l 0 0x27051956
>>>>>>>
>>>>>>> => bootm 0
>>>>>>> ## Booting kernel from Legacy Image at 00000000 ...
>>>>>>>     Image Name:   Linux-5.15.0-rc5-02224-ga3c007ad
>>>>>>>     Image Type:   PowerPC Linux Kernel Image (gzip compressed)
>>>>>>>     Data Size:    3286948 Bytes = 3.1 MiB
>>>>>>>     Load Address: 00000000
>>>>>>>     Entry Point:  00000000
>>>>>>>     Verifying Checksum ... Bad Data CRC
>>>>>>> ERROR: can't get kernel image!
>>>>>>>
>>>>>>>
>>>>>>> So we have something but it seems it gets overwritten by stuff.
>>>>>>>
>>>>>>> Anyway loading a uImage at 0 is just bad because it is a gzipped 
>>>>>>> image that should get gunzipped at address 0.
>>>>>>>
>>>>>>> Or should we just copy the raw kernel at 0 and jump to the entry 
>>>>>>> point ? But then we also need a device tree somewhere.
>>>>>>>
>>>>>>
>>>>>> If I change KERNEL_LOAD_ADDR to 0x1000000, I can bootm at that 
>>>>>> address, and it seems it properly decompress the kernel:
>>>>>>
>>>>>> => bootm 0x1000000
>>>>>> ## Booting kernel from Legacy Image at 01000000 ...
>>>>>>   Image Name:   Linux-5.15.0-rc5-02224-ga3c007ad
>>>>>>   Image Type:   PowerPC Linux Kernel Image (gzip compressed)
>>>>>>   Data Size:    3296789 Bytes = 3.1 MiB
>>>>>>   Load Address: 00000000
>>>>>>   Entry Point:  00000000
>>>>>>   Verifying Checksum ... OK
>>>>>>   Uncompressing Kernel Image ... OK
>>>>>>
>>>>>>
>>>>>> And it initialises the MMU properly.
>>>>>>
>>>>>> Then it gets stuck because there is no devicetree.
>>>>>>
>>>>>> (gdb) bt
>>>>>> #0  0xc00094cc in udelay ()
>>>>>> #1  0xc0025d34 in panic ()
>>>>>> #2  0xc06415a0 in early_init_devtree ()
>>>>>> #3  0xc0641da8 in machine_init ()
>>>>>> #4  0xc0002200 in start_here ()
>>>>>
>>>>> Maybe you need to embed a dtb in your kernel if that's possible 
>>>>> somehow? Or QEMU has a -dtb option that sets machine->dtb but you 
>>>>> need board code to do something with it. See how it's done in other 
>>>>> boards like virtex_ml507 and sam460ex. But maybe you'd be better 
>>>>> off not using -kernel option as it seems to not really working for 
>>>>> these 405 boards but load and start the kernel from u-boot. Not 
>>>>> sure what device does u-boot support but QEMU can emulate 
>>>>> usb-storage, network, different disks so something might work with 
>>>>> u-boot if this board has any peripherals. If it doesn't emulate any 
>>>>> peripherals what do you expect to do with the kernel once it boots?
>>>>>
>>>>
>>>> I should be able to build a multi-FIT image that embeds the kernel 
>>>> and the device tree.
>>>>
>>>> I don't know about the peripherals, what I need it a kernel that is 
>>>> able to boot and run some user exe. I'm working on low level 
>>>> functionnalities like VMAP_STACK, STRICT_KERNEL_RWX, Userspace 
>>>> protection, etc ... I want to be able to check that after some 
>>>> modifications the kernel can still boot on every CPU sub-family, and 
>>>> I need to run LKDTM tests.
>>>>
>>>> For this a kernel + initrd is enough.
>>>
>>> hotfoot.dts is the only DT with a CPU model "PowerPC,405EP".
>>>
>>> With cuImage.hotfoot,
>>>
>>> U-Boot 2015.10-00236-g677f970bc6-dirty (Oct 06 2021 - 08:59:53 +0200)
>>>
>>> CPU:   AMCC PowerPC 405EP Rev. B at 770 MHz (PLB=256 OPB=128 EBC=128)
>>>         I2C boot EEPROM disabled
>>>         Internal PCI arbiter enabled
>>>         16 KiB I-Cache 16 KiB D-Cache
>>> Board: Taihu - AMCC PPC405EP Evaluation Board
>>> I2C:   ready
>>> DRAM:  128 MiB
>>> Flash: ## Unknown FLASH on Bank 0 - Size = 0x00000000 = 0 MB
>>> ## Unknown FLASH on Bank 1 - Size = 0x00000000 = 0 MB
>>> 0 Bytes
>>> *** Warning - bad CRC, using default environment
>>>
>>> PCI:   Bus Dev VenId DevId Class Int
>>> PCI:
>>> Net:   No ethernet found.
>>>
>>> Type run flash_nfs to mount root filesystem over NFS
>>>
>>> Hit any key to stop autoboot:  0
>>> => bootm 01000000
>>> ## Booting kernel from Legacy Image at 01000000 ...
>>>     Image Name:   Linux-5.15.0-rc6-dirty
>>>     Image Type:   PowerPC Linux Kernel Image (gzip compressed)
>>>     Data Size:    3326878 Bytes = 3.2 MiB
>>>     Load Address: 00700000
>>>     Entry Point:  00701aa8
>>>     Verifying Checksum ... OK
>>>     Uncompressing Kernel Image ... OK
>>> Memory <- <0x0 0x8000000> (128MB)
>>> CPU clock-frequency <- 0x0 (0MHz)
>>> CPU timebase-frequency <- 0x0 (0MHz)
>>> /plb: clock-frequency <- 0 (0MHz)
>>> /plb/opb: clock-frequency <- 0 (0MHz)
>>> /plb/ebc: clock-frequency <- 0 (0MHz)
>>> /plb/opb/serial@ef600300: clock-frequency <- 0 (0MHz)
>>> /plb/opb/serial@ef600400: clock-frequency <- 0 (0MHz)
>>> ethernet0: local-mac-address <- 00:00:00:00:00:00
>>> ethernet1: local-mac-address <- 00:00:2d:e5:44:80
>>> Fixing devtree for 4M Flash
>>>
>>> zImage starting: loaded at 0x00700000 (sp: 0x07eaabb0)
>>> Decompression error: 'Not a gzip file'
>>> No valid compressed data found, assume uncompressed data
>>> Allocating 0x6c128c bytes for kernel...
>>> 0x69e1ec bytes of uncompressed data copied
>>>
>>> Linux/PowerPC load:
>>> Finalizing device tree... flat tree at 0xdc5960
>>> Linux version 5.15.0-rc6-dirty (legoater@yukon) 
>>> (powerpc64-linux-gnu-gcc (GCC) 11.2.1 20210728 (Red Hat Cross 
>>> 11.2.1-1), GNU ld version 2.35.2-1.fc34) #1 Tue Oct 19 15:15:21 CEST 
>>> 2021
>>> Using PowerPC 40x Platform machine description
>>> printk: bootconsole [udbg0] enabled
>>> -----------------------------------------------------
>>> phys_mem_size     = 0x8000000
>>> dcache_bsize      = 0x20
>>> icache_bsize      = 0x20
>>> cpu_features      = 0x0000000000000100
>>>    possible        = 0x0000000000000100
>>>    always          = 0x0000000000000100
>>> cpu_user_features = 0x86000000 0x00000000
>>> mmu_features      = 0x00000004
>>> -----------------------------------------------------
>>> Zone ranges:
>>>    Normal   [mem 0x0000000000000000-0x0000000007ffffff]
>>> Movable zone start for each node
>>> Early memory node ranges
>>>    node   0: [mem 0x0000000000000000-0x0000000007ffffff]
>>> Initmem setup node 0 [mem 0x0000000000000000-0x0000000007ffffff]
>>> MMU: Allocated 1088 bytes of context maps for 255 contexts
>>> Built 1 zonelists, mobility grouping on.  Total pages: 32512
>>> Kernel command line:
>>> Dentry cache hash table entries: 16384 (order: 4, 65536 bytes, linear)
>>> Inode-cache hash table entries: 8192 (order: 3, 32768 bytes, linear)
>>> mem auto-init: stack:off, heap alloc:off, heap free:off
>>> Kernel virtual memory layout:
>>>    * 0xffbdf000..0xfffff000  : fixmap
>>>    * 0xc9000000..0xffbdf000  : vmalloc & ioremap
>>> Memory: 122948K/131072K available (5040K kernel code, 220K rwdata, 
>>> 1320K rodata, 200K init, 136K bss, 8124K reserved, 0K cma-reserved)
>>> SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
>>> NR_IRQS: 512, nr_irqs: 512, preallocated irqs: 16
>>> UIC0 (32 IRQ sources) at DCR 0xc0
>>> random: get_random_u32 called from start_kernel+0x498/0x5f8 with 
>>> crng_init=0
>>>
>>
>> Great.
>>
>> (gdb) bt
>> #0  __div64_32 () at arch/powerpc/lib/div64.S:29
>> #1  0xc00099bc in div128_by_32 (dividend_high=<optimized out>, 
>> dividend_low=<optimized out>, divisor=<optimized out>, 
>> dr=dr@entry=0xc0693f78) at arch/powerpc/kernel/time.c:1038
>> #2  0xc0641060 in time_init () at arch/powerpc/kernel/time.c:978
>> #3  0xc063dc48 in start_kernel () at init/main.c:1055
>> #4  0xc0002204 in start_here () at arch/powerpc/kernel/head_40x.S:617
>>
>>
>> Looping forever in __div64_32() due to:
>>
>>  > CPU clock-frequency <- 0x0 (0MHz)
>>  > CPU timebase-frequency <- 0x0 (0MHz)
>>  > /plb: clock-frequency <- 0 (0MHz)
>>  > /plb/opb: clock-frequency <- 0 (0MHz)
>>  > /plb/ebc: clock-frequency <- 0 (0MHz)
>>  > /plb/opb/serial@ef600300: clock-frequency <- 0 (0MHz)
>>  > /plb/opb/serial@ef600400: clock-frequency <- 0 (0MHz)
> 
> 
> I dont understand how
> 
>    static bd_t bd;
> 
> can be updated in the kernel.
> 

It's not updated in the kernel.

It is supposed to be provided by UBoot to Linux Kernel. But modern 
kernels don't take that anymore, they take a device tree. For this 
reason cuboot takes the content of bd to build/update the device tree.

Looks like QEMU also provides the bd, see ref405ep_init()

I managed to get a kernel booting with the following change (and with 
CONFIG_ETHERNET removed)

diff --git a/arch/powerpc/boot/cuboot-hotfoot.c 
b/arch/powerpc/boot/cuboot-hotfoot.c
index 888a6b9bfead..63a9545ff55d 100644
--- a/arch/powerpc/boot/cuboot-hotfoot.c
+++ b/arch/powerpc/boot/cuboot-hotfoot.c
@@ -132,6 +132,12 @@ void platform_init(unsigned long r3, unsigned long 
r4, unsigned long r5,
                    unsigned long r6, unsigned long r7)
  {
         CUBOOT_INIT();
+        bd.bi_intfreq = 133333333;
+        bd.bi_busfreq = 33333333;
+        bd.bi_procfreq = 133333333;
+        bd.bi_plb_busfreq = 33333333;
+        bd.bi_pci_busfreq = 33333333;
+        bd.bi_opbfreq = 33333333;
         platform_ops.fixups = hotfoot_fixups;
          platform_ops.exit = ibm40x_dbcr_reset;
         fdt_init(_dtb_start);


Christophe

Re: Deprecate the ppc405 boards in QEMU?

[BALATON Zoltan]

[-- Attachment #1: Type: text/plain, Size: 2013 bytes --]

On Wed, 20 Oct 2021, LEROY Christophe wrote:
> Le 20/10/2021 à 12:10, Cédric Le Goater a écrit :
>> I dont understand how
>>
>>    static bd_t bd;
>>
>> can be updated in the kernel.
>>
>
> It's not updated in the kernel.
>
> It is supposed to be provided by UBoot to Linux Kernel. But modern
> kernels don't take that anymore, they take a device tree. For this
> reason cuboot takes the content of bd to build/update the device tree.
>
> Looks like QEMU also provides the bd, see ref405ep_init()
>
> I managed to get a kernel booting with the following change (and with
> CONFIG_ETHERNET removed)
>
> diff --git a/arch/powerpc/boot/cuboot-hotfoot.c
> b/arch/powerpc/boot/cuboot-hotfoot.c
> index 888a6b9bfead..63a9545ff55d 100644
> --- a/arch/powerpc/boot/cuboot-hotfoot.c
> +++ b/arch/powerpc/boot/cuboot-hotfoot.c
> @@ -132,6 +132,12 @@ void platform_init(unsigned long r3, unsigned long
> r4, unsigned long r5,
>                    unsigned long r6, unsigned long r7)
>  {
>         CUBOOT_INIT();
> +        bd.bi_intfreq = 133333333;
> +        bd.bi_busfreq = 33333333;
> +        bd.bi_procfreq = 133333333;
> +        bd.bi_plb_busfreq = 33333333;
> +        bd.bi_pci_busfreq = 33333333;
> +        bd.bi_opbfreq = 33333333;
>         platform_ops.fixups = hotfoot_fixups;
>          platform_ops.exit = ibm40x_dbcr_reset;
>         fdt_init(_dtb_start);

So maybe taihu should also provide this boot info when linux_boot is true 
(i.e. using -kernel) like the ref405ep does? Usually when using -kernel 
without -bios then QEMU has to also emulate enough of what the firmware 
would otherwise do like setting up devices and setting boot environment. 
Or if we have both -bios and -kernel then maybe -kernel should tell the 
firmware to boot a kernel but that may need a way to do that like setting 
variables in nvram but we don't have models of that in taihu. This taihu 
machine seems to be an early skeleton that wasn't finished, the ref405ep 
seems to be more advanced.

Regards,
BALATON Zoltan

Re: Deprecate the ppc405 boards in QEMU?

[Thomas Huth]

On 20/10/2021 16.31, BALATON Zoltan wrote:
> On Wed, 20 Oct 2021, LEROY Christophe wrote:
>> Le 20/10/2021 à 12:10, Cédric Le Goater a écrit :
>>> I dont understand how
>>>
>>>    static bd_t bd;
>>>
>>> can be updated in the kernel.
>>>
>>
>> It's not updated in the kernel.
>>
>> It is supposed to be provided by UBoot to Linux Kernel. But modern
>> kernels don't take that anymore, they take a device tree. For this
>> reason cuboot takes the content of bd to build/update the device tree.
>>
>> Looks like QEMU also provides the bd, see ref405ep_init()
>>
>> I managed to get a kernel booting with the following change (and with
>> CONFIG_ETHERNET removed)
>>
>> diff --git a/arch/powerpc/boot/cuboot-hotfoot.c
>> b/arch/powerpc/boot/cuboot-hotfoot.c
>> index 888a6b9bfead..63a9545ff55d 100644
>> --- a/arch/powerpc/boot/cuboot-hotfoot.c
>> +++ b/arch/powerpc/boot/cuboot-hotfoot.c
>> @@ -132,6 +132,12 @@ void platform_init(unsigned long r3, unsigned long
>> r4, unsigned long r5,
>>                    unsigned long r6, unsigned long r7)
>>  {
>>         CUBOOT_INIT();
>> +        bd.bi_intfreq = 133333333;
>> +        bd.bi_busfreq = 33333333;
>> +        bd.bi_procfreq = 133333333;
>> +        bd.bi_plb_busfreq = 33333333;
>> +        bd.bi_pci_busfreq = 33333333;
>> +        bd.bi_opbfreq = 33333333;
>>         platform_ops.fixups = hotfoot_fixups;
>>          platform_ops.exit = ibm40x_dbcr_reset;
>>         fdt_init(_dtb_start);
> 
> So maybe taihu should also provide this boot info when linux_boot is true 
> (i.e. using -kernel) like the ref405ep does? Usually when using -kernel 
> without -bios then QEMU has to also emulate enough of what the firmware 
> would otherwise do like setting up devices and setting boot environment. Or 
> if we have both -bios and -kernel then maybe -kernel should tell the 
> firmware to boot a kernel but that may need a way to do that like setting 
> variables in nvram but we don't have models of that in taihu. This taihu 
> machine seems to be an early skeleton that wasn't finished, the ref405ep 
> seems to be more advanced.

I agree, looking code, the ref405ep board seems to be in a better shape than 
the taihu board. My u-boot image seems to run fine with both machines, so 
I'd suggest that we deprecate (and later remove) the taihu board, and keep 
the ref405ep board in QEMU if it is still helpful for Christophe (or anybody 
else).

  Thomas

Re: Deprecate the ppc405 boards in QEMU?

[Cédric Le Goater]

On 10/20/21 16:34, Thomas Huth wrote:
> On 20/10/2021 16.31, BALATON Zoltan wrote:
>> On Wed, 20 Oct 2021, LEROY Christophe wrote:
>>> Le 20/10/2021 à 12:10, Cédric Le Goater a écrit :
>>>> I dont understand how
>>>>
>>>>    static bd_t bd;
>>>>
>>>> can be updated in the kernel.
>>>>
>>>
>>> It's not updated in the kernel.
>>>
>>> It is supposed to be provided by UBoot to Linux Kernel. But modern
>>> kernels don't take that anymore, they take a device tree. For this
>>> reason cuboot takes the content of bd to build/update the device tree.
>>>
>>> Looks like QEMU also provides the bd, see ref405ep_init()
>>>
>>> I managed to get a kernel booting with the following change (and with
>>> CONFIG_ETHERNET removed)
>>>
>>> diff --git a/arch/powerpc/boot/cuboot-hotfoot.c
>>> b/arch/powerpc/boot/cuboot-hotfoot.c
>>> index 888a6b9bfead..63a9545ff55d 100644
>>> --- a/arch/powerpc/boot/cuboot-hotfoot.c
>>> +++ b/arch/powerpc/boot/cuboot-hotfoot.c
>>> @@ -132,6 +132,12 @@ void platform_init(unsigned long r3, unsigned long
>>> r4, unsigned long r5,
>>>                    unsigned long r6, unsigned long r7)
>>>  {
>>>         CUBOOT_INIT();
>>> +        bd.bi_intfreq = 133333333;
>>> +        bd.bi_busfreq = 33333333;
>>> +        bd.bi_procfreq = 133333333;
>>> +        bd.bi_plb_busfreq = 33333333;
>>> +        bd.bi_pci_busfreq = 33333333;
>>> +        bd.bi_opbfreq = 33333333;
>>>         platform_ops.fixups = hotfoot_fixups;
>>>          platform_ops.exit = ibm40x_dbcr_reset;
>>>         fdt_init(_dtb_start);
>>
>> So maybe taihu should also provide this boot info when linux_boot is true (i.e. using -kernel) like the ref405ep does? Usually when using -kernel without -bios then QEMU has to also emulate enough of what the firmware would otherwise do like setting up devices and setting boot environment. Or if we have both -bios and -kernel then maybe -kernel should tell the firmware to boot a kernel but that may need a way to do that like setting variables in nvram but we don't have models of that in taihu. This taihu machine seems to be an early skeleton that wasn't finished, the ref405ep seems to be more advanced.
> 
> I agree, looking code, the ref405ep board seems to be in a better shape than the taihu board. My u-boot image seems to run fine with both machines, so I'd suggest that we deprecate (and later remove) the taihu board, and keep the ref405ep board in QEMU if it is still helpful for Christophe (or anybody else).

Yes. It could nearly run userspace, if one was available.

Thanks,

C.

U-Boot 2015.10-00236-g677f970bc6-dirty (Oct 06 2021 - 08:59:53 +0200)

CPU:   AMCC PowerPC 405EP Rev. B at 770 MHz (PLB=256 OPB=128 EBC=128)
        I2C boot EEPROM disabled
        Internal PCI arbiter enabled
        16 KiB I-Cache 16 KiB D-Cache
Board: Taihu - AMCC PPC405EP Evaluation Board
I2C:   ready
DRAM:  128 MiB
Flash: ## Unknown FLASH on Bank 0 - Size = 0x00000000 = 0 MB
## Unknown FLASH on Bank 1 - Size = 0x00000000 = 0 MB
0 Bytes
*** Warning - bad CRC, using default environment

PCI:   Bus Dev VenId DevId Class Int
PCI:
Net:   No ethernet found.

Type run flash_nfs to mount root filesystem over NFS

Hit any key to stop autoboot:  0
=> bootm 0x1000000
## Booting kernel from Legacy Image at 01000000 ...
    Image Name:   Linux-5.15.0-rc6-dirty
    Image Type:   PowerPC Linux Kernel Image (gzip compressed)
    Data Size:    3870579 Bytes = 3.7 MiB
    Load Address: 00800000
    Entry Point:  00801ad0
    Verifying Checksum ... OK
    Uncompressing Kernel Image ... OK
Memory <- <0x0 0x8000000> (128MB)
CPU clock-frequency <- 0x7f28155 (133MHz)
CPU timebase-frequency <- 0x7f28155 (133MHz)
/plb: clock-frequency <- 1fca055 (33MHz)
/plb/opb: clock-frequency <- 1fca055 (33MHz)
/plb/ebc: clock-frequency <- 1fca055 (33MHz)
/plb/opb/serial@ef600300: clock-frequency <- 1d1079 (2MHz)
/plb/opb/serial@ef600400: clock-frequency <- 1d1079 (2MHz)
ethernet0: local-mac-address <- 00:00:00:00:00:00
ethernet1: local-mac-address <- 00:00:2d:e5:44:80
Fixing devtree for 4M Flash

zImage starting: loaded at 0x00800000 (sp: 0x07eaabb0)
Decompression error: 'Not a gzip file'
No valid compressed data found, assume uncompressed data
Allocating 0x73f274 bytes for kernel...
0x71c0f0 bytes of uncompressed data copied

Linux/PowerPC load:
Finalizing device tree... flat tree at 0xf43960
Linux version 5.15.0-rc6-dirty (legoater@yukon) (powerpc64-linux-gnu-gcc (GCC) 11.2.1 20210728 (Red Hat Cross 11.2.1-1), GNU ld version 2.35.2-1.fc34) #4 Wed Oct 20 16:37:46 CEST 2021
Using PowerPC 40x Platform machine description
printk: bootconsole [udbg0] enabled
-----------------------------------------------------
phys_mem_size     = 0x8000000
dcache_bsize      = 0x20
icache_bsize      = 0x20
cpu_features      = 0x0000000000000100
   possible        = 0x0000000000000100
   always          = 0x0000000000000100
cpu_user_features = 0x86000000 0x00000000
mmu_features      = 0x00000004
-----------------------------------------------------
Zone ranges:
   Normal   [mem 0x0000000000000000-0x0000000007ffffff]
Movable zone start for each node
Early memory node ranges
   node   0: [mem 0x0000000000000000-0x0000000007ffffff]
Initmem setup node 0 [mem 0x0000000000000000-0x0000000007ffffff]
MMU: Allocated 1088 bytes of context maps for 255 contexts
Built 1 zonelists, mobility grouping on.  Total pages: 32512
Kernel command line:
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes, linear)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes, linear)
mem auto-init: stack:off, heap alloc:off, heap free:off
Kernel virtual memory layout:
   * 0xffbdf000..0xfffff000  : fixmap
   * 0xc9000000..0xffbdf000  : vmalloc & ioremap
Memory: 122444K/131072K available (4908K kernel code, 224K rwdata, 1300K rodata, 852K init, 136K bss, 8628K reserved, 0K cma-reserved)
SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
NR_IRQS: 512, nr_irqs: 512, preallocated irqs: 16
UIC0 (32 IRQ sources) at DCR 0xc0
random: get_random_u32 called from start_kernel+0x498/0x5f8 with crng_init=0
clocksource: timebase: mask: 0xffffffffffffffff max_cycles: 0x1ec031343f, max_idle_ns: 440795203544 ns
clocksource: timebase mult[7800000] shift[24] registered
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 1024 (order: 0, 4096 bytes, linear)
Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes, linear)
clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
futex hash table entries: 256 (order: -1, 3072 bytes, linear)
NET: Registered PF_NETLINK/PF_ROUTE protocol family
DMA: preallocated 128 KiB GFP_KERNEL pool for atomic allocations
              
thermal_sys: Registered thermal governor 'step_wise'
PCI host bridge /plb/pci@ec000000 (primary) ranges:
  MEM 0x0000000080000000..0x000000009fffffff -> 0x0000000080000000
   IO 0x00000000e8000000..0x00000000e800ffff -> 0x0000000000000000
4xx PCI DMA offset set to 0x00000000
4xx PCI DMA window base to 0x0000000000000000
DMA window size 0x0000000080000000
PCI: Probing PCI hardware
PCI host bridge to bus 0008:00
pci_bus 0008:00: root bus resource [io  0x0000-0xffff]
pci_bus 0008:00: root bus resource [mem 0x80000000-0x9fffffff]
pci_bus 0008:00: root bus resource [bus 00-ff]
pci_bus 0008:00: busn_res: [bus 00-ff] end is updated to ff
pci_bus 0008:00: busn_res: [bus 00-ff] end is updated to 00
pci_bus 0008:00: resource 4 [io  0x0000-0xffff]
pci_bus 0008:00: resource 5 [mem 0x80000000-0x9fffffff]
vgaarb: loaded
pps_core: LinuxPPS API ver. 1 registered
pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
PTP clock support registered
clocksource: Switched to clocksource timebase
NET: Registered PF_INET protocol family
IP idents hash table entries: 2048 (order: 2, 16384 bytes, linear)
tcp_listen_portaddr_hash hash table entries: 512 (order: 0, 4096 bytes, linear)
TCP established hash table entries: 1024 (order: 0, 4096 bytes, linear)
TCP bind hash table entries: 1024 (order: 0, 4096 bytes, linear)
TCP: Hash tables configured (established 1024 bind 1024)
UDP hash table entries: 256 (order: 0, 4096 bytes, linear)
UDP-Lite hash table entries: 256 (order: 0, 4096 bytes, linear)
NET: Registered PF_UNIX/PF_LOCAL protocol family
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
PCI: CLS 0 bytes, default 32
workingset: timestamp_bits=30 max_order=15 bucket_order=0
io scheduler mq-deadline registered
io scheduler kyber registered
Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
printk: console [ttyS0] disabled
serial8250.0: ttyS0 at MMIO 0xef600400 (irq = 16, base_baud = 119047) is a 16550A
printk: console [ttyS0] enabled
printk: console [ttyS0] enabled
printk: bootconsole [udbg0] disabled
printk: bootconsole [udbg0] disabled
serial8250.0: ttyS1 at MMIO 0xef600300 (irq = 17, base_baud = 119047) is a 16550A
printk: console [ttyS0] disabled
printk: console [ttyS0] enabled
ef600300.serial: ttyS1 at MMIO 0xef600300 (irq = 17, base_baud = 119047) is a 16550
brd: module loaded
libphy: Fixed MDIO Bus: probed
NET: Registered PF_INET6 protocol family
Segment Routing with IPv6
In-situ OAM (IOAM) with IPv6
sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
NET: Registered PF_PACKET protocol family
drmem: No dynamic reconfiguration memory found
Freeing unused kernel image (initmem) memory: 852K
Kernel memory protection not selected by kernel config.
Run /init as init process
init[1]: illegal instruction (4) at 10038380 nip 10038380 lr 10034be0 code 1 in busybox[10000000+61000]
init[1]: code: 6129c000 7f914840 419d0350 562be13e 380bffff 2b800020 409d0314 3d204330
init[1]: code: 6c008000 91210018 3d201006 9001001c <c1a9b834> c8010018 fc006828 fc000018
Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000004
CPU: 0 PID: 1 Comm: init Not tainted 5.15.0-rc6-dirty #4
Call Trace:
[c0815da0] [c0024408] panic+0x11c/0x2e0 (unreliable)
[c0815e00] [c0026038] do_exit+0x8b0/0x908
[c0815e50] [c0027044] do_group_exit+0x34/0x9c
[c0815e70] [c0033bd0] get_signal+0x174/0x734
[c0815ec0] [c0007794] do_notify_resume+0x70/0x2b0
[c0815f20] [c000ca7c] interrupt_exit_user_prepare_main+0x6c/0xe0
[c0815f40] [c000f1e0] interrupt_return+0x14/0x148
--- interrupt: 700 at 0x10038380
NIP:  10038380 LR: 10034be0 CTR: 1000db60
REGS: c0815f50 TRAP: 0700   Not tainted  (5.15.0-rc6-dirty)
MSR:  0008c030 <EE,PR,IR,DR>  CR: 40000024  XER: 00000000

GPR00: 8000005a bf9c7d90 100791f8 000005a4 bf9c8144 0000001f 00000001 1000026c
GPR08: 0000c030 10060000 00001000 0000005b 72656773 00000000 00000000 00000000
GPR16: 00000000 000005b0 00000000 100726ec 00000000 00000000 00000000 00000000
GPR24: 00000000 00000002 00000002 bf9c8144 10070000 000005a4 bf9c8144 000005a4
NIP [10038380] 0x10038380
LR [10034be0] 0x10034be0
--- interrupt: 700
Rebooting in 180 seconds..
QEMU 6.1.50 monitor - type 'help' for more information

Re: Deprecate the ppc405 boards in QEMU?

[LEROY Christophe]

Le 20/10/2021 à 16:41, Cédric Le Goater a écrit :
> init[1]: illegal instruction (4) at 10038380 nip 10038380 lr 10034be0 
> code 1 in busybox[10000000+61000]
> init[1]: code: 6129c000 7f914840 419d0350 562be13e 380bffff 2b800020 
> 409d0314 3d204330
> init[1]: code: 6c008000 91210018 3d201006 9001001c <c1a9b834> c8010018 
> fc006828 fc000018

That's a floating point instruction.

You need CONFIG_MATH_EMULATION.


> Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000004
> CPU: 0 PID: 1 Comm: init Not tainted 5.15.0-rc6-dirty #4
> Call Trace:
> [c0815da0] [c0024408] panic+0x11c/0x2e0 (unreliable)
> [c0815e00] [c0026038] do_exit+0x8b0/0x908
> [c0815e50] [c0027044] do_group_exit+0x34/0x9c
> [c0815e70] [c0033bd0] get_signal+0x174/0x734
> [c0815ec0] [c0007794] do_notify_resume+0x70/0x2b0
> [c0815f20] [c000ca7c] interrupt_exit_user_prepare_main+0x6c/0xe0
> [c0815f40] [c000f1e0] interrupt_return+0x14/0x148
> --- interrupt: 700 at 0x10038380
> NIP:  10038380 LR: 10034be0 CTR: 1000db60
> REGS: c0815f50 TRAP: 0700   Not tainted  (5.15.0-rc6-dirty)
> MSR:  0008c030 <EE,PR,IR,DR>  CR: 40000024  XER: 00000000
> 
> GPR00: 8000005a bf9c7d90 100791f8 000005a4 bf9c8144 0000001f 00000001 
> 1000026c
> GPR08: 0000c030 10060000 00001000 0000005b 72656773 00000000 00000000 
> 00000000
> GPR16: 00000000 000005b0 00000000 100726ec 00000000 00000000 00000000 
> 00000000
> GPR24: 00000000 00000002 00000002 bf9c8144 10070000 000005a4 bf9c8144 
> 000005a4
> NIP [10038380] 0x10038380
> LR [10034be0] 0x10034be0
> --- interrupt: 700
> Rebooting in 180 seconds..
> QEMU 6.1.50 monitor - type 'help' for more information

Re: Deprecate the ppc405 boards in QEMU?

[Cédric Le Goater]

On 10/20/21 15:27, LEROY Christophe wrote:
> 
> 
> Le 20/10/2021 à 12:10, Cédric Le Goater a écrit :
>> On 10/20/21 11:02, Christophe Leroy wrote:
>>>
>>>
>>> Le 19/10/2021 à 23:30, Cédric Le Goater a écrit :
>>>> On 10/19/21 18:12, Christophe Leroy wrote:
>>>>>
>>>>>
>>>>> Le 19/10/2021 à 16:56, BALATON Zoltan a écrit :
>>>>>> On Tue, 19 Oct 2021, Christophe Leroy wrote:
>>>>>>> Le 19/10/2021 à 15:44, Christophe Leroy a écrit :
>>>>>>>> There is something:
>>>>>>>>
>>>>>>>> => bootm 0
>>>>>>>> Wrong Image Format for bootm command
>>>>>>>> ERROR: can't get kernel image!
>>>>>>>>
>>>>>>>> => md 0
>>>>>>>> 00000000: 00000000 b497aae1 616e9207 003227a4    '..V....an...2'.
>>>>>>>> 00000010: 00000000 00000000 ee36255f 05070201    .........6%_....
>>>>>>>> 00000020: 4c696e75 782d352e 31352e30 2d726335    Linux-5.15.0-rc5
>>>>>>>> 00000030: 2d303232 32342d67 61336330 30376164    -02224-ga3c007ad
>>>>>>>> 00000040: 1f8b0800 00000000 0203ec5c 0f7013e7    ...........\.p..
>>>>>>>>
>>>>>>>> => mw.l 0 0x27051956
>>>>>>>>
>>>>>>>> => bootm 0
>>>>>>>> ## Booting kernel from Legacy Image at 00000000 ...
>>>>>>>>      Image Name:   Linux-5.15.0-rc5-02224-ga3c007ad
>>>>>>>>      Image Type:   PowerPC Linux Kernel Image (gzip compressed)
>>>>>>>>      Data Size:    3286948 Bytes = 3.1 MiB
>>>>>>>>      Load Address: 00000000
>>>>>>>>      Entry Point:  00000000
>>>>>>>>      Verifying Checksum ... Bad Data CRC
>>>>>>>> ERROR: can't get kernel image!
>>>>>>>>
>>>>>>>>
>>>>>>>> So we have something but it seems it gets overwritten by stuff.
>>>>>>>>
>>>>>>>> Anyway loading a uImage at 0 is just bad because it is a gzipped
>>>>>>>> image that should get gunzipped at address 0.
>>>>>>>>
>>>>>>>> Or should we just copy the raw kernel at 0 and jump to the entry
>>>>>>>> point ? But then we also need a device tree somewhere.
>>>>>>>>
>>>>>>>
>>>>>>> If I change KERNEL_LOAD_ADDR to 0x1000000, I can bootm at that
>>>>>>> address, and it seems it properly decompress the kernel:
>>>>>>>
>>>>>>> => bootm 0x1000000
>>>>>>> ## Booting kernel from Legacy Image at 01000000 ...
>>>>>>>    Image Name:   Linux-5.15.0-rc5-02224-ga3c007ad
>>>>>>>    Image Type:   PowerPC Linux Kernel Image (gzip compressed)
>>>>>>>    Data Size:    3296789 Bytes = 3.1 MiB
>>>>>>>    Load Address: 00000000
>>>>>>>    Entry Point:  00000000
>>>>>>>    Verifying Checksum ... OK
>>>>>>>    Uncompressing Kernel Image ... OK
>>>>>>>
>>>>>>>
>>>>>>> And it initialises the MMU properly.
>>>>>>>
>>>>>>> Then it gets stuck because there is no devicetree.
>>>>>>>
>>>>>>> (gdb) bt
>>>>>>> #0  0xc00094cc in udelay ()
>>>>>>> #1  0xc0025d34 in panic ()
>>>>>>> #2  0xc06415a0 in early_init_devtree ()
>>>>>>> #3  0xc0641da8 in machine_init ()
>>>>>>> #4  0xc0002200 in start_here ()
>>>>>>
>>>>>> Maybe you need to embed a dtb in your kernel if that's possible
>>>>>> somehow? Or QEMU has a -dtb option that sets machine->dtb but you
>>>>>> need board code to do something with it. See how it's done in other
>>>>>> boards like virtex_ml507 and sam460ex. But maybe you'd be better
>>>>>> off not using -kernel option as it seems to not really working for
>>>>>> these 405 boards but load and start the kernel from u-boot. Not
>>>>>> sure what device does u-boot support but QEMU can emulate
>>>>>> usb-storage, network, different disks so something might work with
>>>>>> u-boot if this board has any peripherals. If it doesn't emulate any
>>>>>> peripherals what do you expect to do with the kernel once it boots?
>>>>>>
>>>>>
>>>>> I should be able to build a multi-FIT image that embeds the kernel
>>>>> and the device tree.
>>>>>
>>>>> I don't know about the peripherals, what I need it a kernel that is
>>>>> able to boot and run some user exe. I'm working on low level
>>>>> functionnalities like VMAP_STACK, STRICT_KERNEL_RWX, Userspace
>>>>> protection, etc ... I want to be able to check that after some
>>>>> modifications the kernel can still boot on every CPU sub-family, and
>>>>> I need to run LKDTM tests.
>>>>>
>>>>> For this a kernel + initrd is enough.
>>>>
>>>> hotfoot.dts is the only DT with a CPU model "PowerPC,405EP".
>>>>
>>>> With cuImage.hotfoot,
>>>>
>>>> U-Boot 2015.10-00236-g677f970bc6-dirty (Oct 06 2021 - 08:59:53 +0200)
>>>>
>>>> CPU:   AMCC PowerPC 405EP Rev. B at 770 MHz (PLB=256 OPB=128 EBC=128)
>>>>          I2C boot EEPROM disabled
>>>>          Internal PCI arbiter enabled
>>>>          16 KiB I-Cache 16 KiB D-Cache
>>>> Board: Taihu - AMCC PPC405EP Evaluation Board
>>>> I2C:   ready
>>>> DRAM:  128 MiB
>>>> Flash: ## Unknown FLASH on Bank 0 - Size = 0x00000000 = 0 MB
>>>> ## Unknown FLASH on Bank 1 - Size = 0x00000000 = 0 MB
>>>> 0 Bytes
>>>> *** Warning - bad CRC, using default environment
>>>>
>>>> PCI:   Bus Dev VenId DevId Class Int
>>>> PCI:
>>>> Net:   No ethernet found.
>>>>
>>>> Type run flash_nfs to mount root filesystem over NFS
>>>>
>>>> Hit any key to stop autoboot:  0
>>>> => bootm 01000000
>>>> ## Booting kernel from Legacy Image at 01000000 ...
>>>>      Image Name:   Linux-5.15.0-rc6-dirty
>>>>      Image Type:   PowerPC Linux Kernel Image (gzip compressed)
>>>>      Data Size:    3326878 Bytes = 3.2 MiB
>>>>      Load Address: 00700000
>>>>      Entry Point:  00701aa8
>>>>      Verifying Checksum ... OK
>>>>      Uncompressing Kernel Image ... OK
>>>> Memory <- <0x0 0x8000000> (128MB)
>>>> CPU clock-frequency <- 0x0 (0MHz)
>>>> CPU timebase-frequency <- 0x0 (0MHz)
>>>> /plb: clock-frequency <- 0 (0MHz)
>>>> /plb/opb: clock-frequency <- 0 (0MHz)
>>>> /plb/ebc: clock-frequency <- 0 (0MHz)
>>>> /plb/opb/serial@ef600300: clock-frequency <- 0 (0MHz)
>>>> /plb/opb/serial@ef600400: clock-frequency <- 0 (0MHz)
>>>> ethernet0: local-mac-address <- 00:00:00:00:00:00
>>>> ethernet1: local-mac-address <- 00:00:2d:e5:44:80
>>>> Fixing devtree for 4M Flash
>>>>
>>>> zImage starting: loaded at 0x00700000 (sp: 0x07eaabb0)
>>>> Decompression error: 'Not a gzip file'
>>>> No valid compressed data found, assume uncompressed data
>>>> Allocating 0x6c128c bytes for kernel...
>>>> 0x69e1ec bytes of uncompressed data copied
>>>>
>>>> Linux/PowerPC load:
>>>> Finalizing device tree... flat tree at 0xdc5960
>>>> Linux version 5.15.0-rc6-dirty (legoater@yukon)
>>>> (powerpc64-linux-gnu-gcc (GCC) 11.2.1 20210728 (Red Hat Cross
>>>> 11.2.1-1), GNU ld version 2.35.2-1.fc34) #1 Tue Oct 19 15:15:21 CEST
>>>> 2021
>>>> Using PowerPC 40x Platform machine description
>>>> printk: bootconsole [udbg0] enabled
>>>> -----------------------------------------------------
>>>> phys_mem_size     = 0x8000000
>>>> dcache_bsize      = 0x20
>>>> icache_bsize      = 0x20
>>>> cpu_features      = 0x0000000000000100
>>>>     possible        = 0x0000000000000100
>>>>     always          = 0x0000000000000100
>>>> cpu_user_features = 0x86000000 0x00000000
>>>> mmu_features      = 0x00000004
>>>> -----------------------------------------------------
>>>> Zone ranges:
>>>>     Normal   [mem 0x0000000000000000-0x0000000007ffffff]
>>>> Movable zone start for each node
>>>> Early memory node ranges
>>>>     node   0: [mem 0x0000000000000000-0x0000000007ffffff]
>>>> Initmem setup node 0 [mem 0x0000000000000000-0x0000000007ffffff]
>>>> MMU: Allocated 1088 bytes of context maps for 255 contexts
>>>> Built 1 zonelists, mobility grouping on.  Total pages: 32512
>>>> Kernel command line:
>>>> Dentry cache hash table entries: 16384 (order: 4, 65536 bytes, linear)
>>>> Inode-cache hash table entries: 8192 (order: 3, 32768 bytes, linear)
>>>> mem auto-init: stack:off, heap alloc:off, heap free:off
>>>> Kernel virtual memory layout:
>>>>     * 0xffbdf000..0xfffff000  : fixmap
>>>>     * 0xc9000000..0xffbdf000  : vmalloc & ioremap
>>>> Memory: 122948K/131072K available (5040K kernel code, 220K rwdata,
>>>> 1320K rodata, 200K init, 136K bss, 8124K reserved, 0K cma-reserved)
>>>> SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
>>>> NR_IRQS: 512, nr_irqs: 512, preallocated irqs: 16
>>>> UIC0 (32 IRQ sources) at DCR 0xc0
>>>> random: get_random_u32 called from start_kernel+0x498/0x5f8 with
>>>> crng_init=0
>>>>
>>>
>>> Great.
>>>
>>> (gdb) bt
>>> #0  __div64_32 () at arch/powerpc/lib/div64.S:29
>>> #1  0xc00099bc in div128_by_32 (dividend_high=<optimized out>,
>>> dividend_low=<optimized out>, divisor=<optimized out>,
>>> dr=dr@entry=0xc0693f78) at arch/powerpc/kernel/time.c:1038
>>> #2  0xc0641060 in time_init () at arch/powerpc/kernel/time.c:978
>>> #3  0xc063dc48 in start_kernel () at init/main.c:1055
>>> #4  0xc0002204 in start_here () at arch/powerpc/kernel/head_40x.S:617
>>>
>>>
>>> Looping forever in __div64_32() due to:
>>>
>>>   > CPU clock-frequency <- 0x0 (0MHz)
>>>   > CPU timebase-frequency <- 0x0 (0MHz)
>>>   > /plb: clock-frequency <- 0 (0MHz)
>>>   > /plb/opb: clock-frequency <- 0 (0MHz)
>>>   > /plb/ebc: clock-frequency <- 0 (0MHz)
>>>   > /plb/opb/serial@ef600300: clock-frequency <- 0 (0MHz)
>>>   > /plb/opb/serial@ef600400: clock-frequency <- 0 (0MHz)
>>
>>
>> I dont understand how
>>
>>     static bd_t bd;
>>
>> can be updated in the kernel.
>>
> 
> It's not updated in the kernel.
> 
> It is supposed to be provided by UBoot to Linux Kernel. But modern
> kernels don't take that anymore, they take a device tree. For this
> reason cuboot takes the content of bd to build/update the device tree.
> 
> Looks like QEMU also provides the bd, see ref405ep_init()


yes. It is updated here :

     /* We put the bd structure at the top of memory */
     if (bd->bi_memsize >= 0x01000000UL)
         bdloc = 0x01000000UL - sizeof(struct ppc4xx_bd_info_t);
     else
         bdloc = bd->bi_memsize - sizeof(struct ppc4xx_bd_info_t);

then
        env->gpr[3] = bdloc;

The structure definitions are probably out of sync :/

> 
> I managed to get a kernel booting with the following change (and with
> CONFIG_ETHERNET removed)

Looks good.

Do you have a compatible builroot image ?

Thanks

C.


> 
> diff --git a/arch/powerpc/boot/cuboot-hotfoot.c
> b/arch/powerpc/boot/cuboot-hotfoot.c
> index 888a6b9bfead..63a9545ff55d 100644
> --- a/arch/powerpc/boot/cuboot-hotfoot.c
> +++ b/arch/powerpc/boot/cuboot-hotfoot.c
> @@ -132,6 +132,12 @@ void platform_init(unsigned long r3, unsigned long
> r4, unsigned long r5,
>                      unsigned long r6, unsigned long r7)
>    {
>           CUBOOT_INIT();
> +        bd.bi_intfreq = 133333333;
> +        bd.bi_busfreq = 33333333;
> +        bd.bi_procfreq = 133333333;
> +        bd.bi_plb_busfreq = 33333333;
> +        bd.bi_pci_busfreq = 33333333;
> +        bd.bi_opbfreq = 33333333;
>           platform_ops.fixups = hotfoot_fixups;
>            platform_ops.exit = ibm40x_dbcr_reset;
>           fdt_init(_dtb_start);
> 
> 
> Christophe
> 

Re: Deprecate the ppc405 boards in QEMU?

[LEROY Christophe]

Le 20/10/2021 à 16:39, Cédric Le Goater a écrit :
> On 10/20/21 15:27, LEROY Christophe wrote:
>> I managed to get a kernel booting with the following change (and with
>> CONFIG_ETHERNET removed)
> 
> Looks good.
> 
> Do you have a compatible builroot image ?
> 

I'm trying with the cpio one from 
https://github.com/groeck/linux-build-test/tree/master/rootfs/ppc

Christophe

Re: Deprecate the ppc405 boards in QEMU?

[Philippe Mathieu-Daudé]

On 10/19/21 13:11, Thomas Huth wrote:
> On 19/10/2021 12.07, BALATON Zoltan wrote:
>> On Tue, 19 Oct 2021, Christophe Leroy wrote:
>>> Le 19/10/2021 à 11:39, Thomas Huth a écrit :
>>>> On 19/10/2021 11.31, Christophe Leroy wrote:
>>>>> Le 11/10/2021 à 15:24, Thomas Huth a écrit :
>>>>>> On 11/10/2021 11.20, David Gibson wrote:
>>>>>>> On Mon, Oct 11, 2021 at 10:10:36AM +0200, Thomas Huth wrote:
>>>>>>>> On 06/10/2021 09.25, Thomas Huth wrote:
>>>>>>>>> On 05/10/2021 23.53, BALATON Zoltan wrote:
>>>>>>>>> [...]
>>>>>>>>>> Maybe these 405 boards in QEMU ran with modified firmware
>>>>>>>>>> where the
>>>>>>>>>> memory detection was patched out but it seems to detect the
>>>>>>>>>> RAM so I
>>>>>>>>>> wonder where it gets that from. Maybe by reading the SDRAM
>>>>>>>>>> controller DCRs ppc4xx_sdram_init() sets up. Then I'm not sure
>>>>>>>>>> what
>>>>>>>>>> it needs the SPD for, I forgot how this worked on sam460ex. Maybe
>>>>>>>>>> for the speed calibration, so could be it detects ram by reading
>>>>>>>>>> DCRs then tries to get SPD data and that's where it stops as
>>>>>>>>>> i2c is
>>>>>>>>>> not emulated on taihu. This could be confirmed by checking
>>>>>>>>>> what it
>>>>>>>>>> pokes with -d guest_errors that shows accesses to missing devices
>>>>>>>>>> but don't know where 405 has the i2c controller and if it's
>>>>>>>>>> the same
>>>>>>>>>> as newer SoCs. If so that could be reused and an i2c bus could be
>>>>>>>>>> added with the SPD data like in sam460ex to make u-boot happy
>>>>>>>>>> or you
>>>>>>>>>> could skip this in u-boot.
>>>>>>>>>
>>>>>>>>> FWIW, I've just tried the latter (skipping the sdram init in
>>>>>>>>> u-boot),
>>>>>>>>> and indeed, I can get to the u-boot prompt now.
>>>>>>>> [...]> I've also attached the patch with my modifications to
>>>>>>>> u-boot.
>>>>>>>>
>>>>>>>> FYI, the changes can now be found on this branch here:
>>>>>>>>
>>>>>>>>   https://gitlab.com/huth/u-boot/-/commits/taihu
>>>>>>>>
>>>>>>>> I also added a gitlab-CI file, so you can now download the
>>>>>>>> u-boot.bin as an
>>>>>>>> artifact from the corresponding pipeline, e.g.:
>>>>>>>>
>>>>>>>>   https://gitlab.com/huth/u-boot/-/jobs/1667201028
>>>>>>>
>>>>>>> Thanks.
>>>>>>>
>>>>>>> Are you going to send a v2 of your proposed deprecation patches?
>>>>>>
>>>>>> No, since there was interest in keeping the 405 boards for testing
>>>>>> the 405 code in the Linux kernel, and since there is now a way to
>>>>>> do at least some very basic testing of these boards (with the
>>>>>> u-boot firmware), I don't plan to respin the deprecation patch. I
>>>>>> just sent a patch for adding the boards to our CI instead:
>>>>>>
>>>>>>   https://lists.gnu.org/archive/html/qemu-devel/2021-10/msg02072.html
>>>>>>
>>>>>
>>>>> I have downloaded your u-boot.bin and tried it with both QEMU 5.2.0
>>>>> and mainline, and I get:
>>>>>
>>>>> ERROR:../accel/tcg/tcg-accel-ops.c:79:tcg_handle_interrupt:
>>>>> assertion failed: (qemu_mutex_iothread_locked())
>>>>> Bail out!
>>>>> ERROR:../accel/tcg/tcg-accel-ops.c:79:tcg_handle_interrupt:
>>>>> assertion failed: (qemu_mutex_iothread_locked())
>>>>> Abandon (core dumped)
>>>>>
>>>>> I see in the mail history that you got that problem as well at some
>>>>> point. How did you fix it ?
>>>>
>>>> You need this patch here to fix this issue:
>>>>
>>>>   https://lists.gnu.org/archive/html/qemu-devel/2021-10/msg01019.html
>>>>   ("hw/ppc: Fix iothread locking in the 405 code")
>>>>
>>>
>>> Thank you.
>>>
>>> Is there anything special to do then in order to boot a Linux kernel ?
>>>
>>> I build the uImage for ppc40x_defconfig
>>>
>>> I use the following command, but it does nothing, it stays in uboot
>>> prompt as when I don't get a kernel argument
>>>
>>>     ~/qemu/build/qemu-system-ppc -M taihu -bios
>>> ~/Téléchargements/u-boot.bin -serial null -serial mon:stdio -kernel
>>> arch/powerpc/boot/uImage
>>
>> I'm not sure using -bios and -kernel together makes sense, it probably
>> starts u-boot in this case and you have to load and start the kernel
>> from u-boot as you'd notmally do on a real machine. Alternatively you
>> could use -kernel instead of -bios which then loads a kernel and
>> starts it directly but not sure if it needs a firmware to work.
>>
>> Ot I could be completely wrong as I don't know this machine and
>> haven't tried it.
> 
> Actually, these 405 machines are quite weird. They refuse to boot
> without bios image, so you currently need the firmware image for sure.

When using -kernel/-append, if a BIOS is required by the kernel,
then it should be crafted by the machine IMO. Usually OS only
access a configuration area in PROM. The PROM must be mapped,
and the minimum configuration structure filled.

Anyhow I find -bios confusing, I never know if this option parse
or expects a full/partial raw flash image, an ELF image, something
else...

Re: Deprecate the ppc405 boards in QEMU?

[BALATON Zoltan]

[-- Attachment #1: Type: text/plain, Size: 5373 bytes --]

On Wed, 20 Oct 2021, Philippe Mathieu-Daudé wrote:
> On 10/19/21 13:11, Thomas Huth wrote:
>> On 19/10/2021 12.07, BALATON Zoltan wrote:
>>> On Tue, 19 Oct 2021, Christophe Leroy wrote:
>>>> Le 19/10/2021 à 11:39, Thomas Huth a écrit :
>>>>> On 19/10/2021 11.31, Christophe Leroy wrote:
>>>>>> Le 11/10/2021 à 15:24, Thomas Huth a écrit :
>>>>>>> On 11/10/2021 11.20, David Gibson wrote:
>>>>>>>> On Mon, Oct 11, 2021 at 10:10:36AM +0200, Thomas Huth wrote:
>>>>>>>>> On 06/10/2021 09.25, Thomas Huth wrote:
>>>>>>>>>> On 05/10/2021 23.53, BALATON Zoltan wrote:
>>>>>>>>>> [...]
>>>>>>>>>>> Maybe these 405 boards in QEMU ran with modified firmware
>>>>>>>>>>> where the
>>>>>>>>>>> memory detection was patched out but it seems to detect the
>>>>>>>>>>> RAM so I
>>>>>>>>>>> wonder where it gets that from. Maybe by reading the SDRAM
>>>>>>>>>>> controller DCRs ppc4xx_sdram_init() sets up. Then I'm not sure
>>>>>>>>>>> what
>>>>>>>>>>> it needs the SPD for, I forgot how this worked on sam460ex. Maybe
>>>>>>>>>>> for the speed calibration, so could be it detects ram by reading
>>>>>>>>>>> DCRs then tries to get SPD data and that's where it stops as
>>>>>>>>>>> i2c is
>>>>>>>>>>> not emulated on taihu. This could be confirmed by checking
>>>>>>>>>>> what it
>>>>>>>>>>> pokes with -d guest_errors that shows accesses to missing devices
>>>>>>>>>>> but don't know where 405 has the i2c controller and if it's
>>>>>>>>>>> the same
>>>>>>>>>>> as newer SoCs. If so that could be reused and an i2c bus could be
>>>>>>>>>>> added with the SPD data like in sam460ex to make u-boot happy
>>>>>>>>>>> or you
>>>>>>>>>>> could skip this in u-boot.
>>>>>>>>>>
>>>>>>>>>> FWIW, I've just tried the latter (skipping the sdram init in
>>>>>>>>>> u-boot),
>>>>>>>>>> and indeed, I can get to the u-boot prompt now.
>>>>>>>>> [...]> I've also attached the patch with my modifications to
>>>>>>>>> u-boot.
>>>>>>>>>
>>>>>>>>> FYI, the changes can now be found on this branch here:
>>>>>>>>>
>>>>>>>>>   https://gitlab.com/huth/u-boot/-/commits/taihu
>>>>>>>>>
>>>>>>>>> I also added a gitlab-CI file, so you can now download the
>>>>>>>>> u-boot.bin as an
>>>>>>>>> artifact from the corresponding pipeline, e.g.:
>>>>>>>>>
>>>>>>>>>   https://gitlab.com/huth/u-boot/-/jobs/1667201028
>>>>>>>>
>>>>>>>> Thanks.
>>>>>>>>
>>>>>>>> Are you going to send a v2 of your proposed deprecation patches?
>>>>>>>
>>>>>>> No, since there was interest in keeping the 405 boards for testing
>>>>>>> the 405 code in the Linux kernel, and since there is now a way to
>>>>>>> do at least some very basic testing of these boards (with the
>>>>>>> u-boot firmware), I don't plan to respin the deprecation patch. I
>>>>>>> just sent a patch for adding the boards to our CI instead:
>>>>>>>
>>>>>>>   https://lists.gnu.org/archive/html/qemu-devel/2021-10/msg02072.html
>>>>>>>
>>>>>>
>>>>>> I have downloaded your u-boot.bin and tried it with both QEMU 5.2.0
>>>>>> and mainline, and I get:
>>>>>>
>>>>>> ERROR:../accel/tcg/tcg-accel-ops.c:79:tcg_handle_interrupt:
>>>>>> assertion failed: (qemu_mutex_iothread_locked())
>>>>>> Bail out!
>>>>>> ERROR:../accel/tcg/tcg-accel-ops.c:79:tcg_handle_interrupt:
>>>>>> assertion failed: (qemu_mutex_iothread_locked())
>>>>>> Abandon (core dumped)
>>>>>>
>>>>>> I see in the mail history that you got that problem as well at some
>>>>>> point. How did you fix it ?
>>>>>
>>>>> You need this patch here to fix this issue:
>>>>>
>>>>>   https://lists.gnu.org/archive/html/qemu-devel/2021-10/msg01019.html
>>>>>   ("hw/ppc: Fix iothread locking in the 405 code")
>>>>>
>>>>
>>>> Thank you.
>>>>
>>>> Is there anything special to do then in order to boot a Linux kernel ?
>>>>
>>>> I build the uImage for ppc40x_defconfig
>>>>
>>>> I use the following command, but it does nothing, it stays in uboot
>>>> prompt as when I don't get a kernel argument
>>>>
>>>>     ~/qemu/build/qemu-system-ppc -M taihu -bios
>>>> ~/Téléchargements/u-boot.bin -serial null -serial mon:stdio -kernel
>>>> arch/powerpc/boot/uImage
>>>
>>> I'm not sure using -bios and -kernel together makes sense, it probably
>>> starts u-boot in this case and you have to load and start the kernel
>>> from u-boot as you'd notmally do on a real machine. Alternatively you
>>> could use -kernel instead of -bios which then loads a kernel and
>>> starts it directly but not sure if it needs a firmware to work.
>>>
>>> Ot I could be completely wrong as I don't know this machine and
>>> haven't tried it.
>>
>> Actually, these 405 machines are quite weird. They refuse to boot
>> without bios image, so you currently need the firmware image for sure.
>
> When using -kernel/-append, if a BIOS is required by the kernel,
> then it should be crafted by the machine IMO. Usually OS only
> access a configuration area in PROM. The PROM must be mapped,
> and the minimum configuration structure filled.
>
> Anyhow I find -bios confusing, I never know if this option parse
> or expects a full/partial raw flash image, an ELF image, something
> else...

Generally a firmware image in whatever format the board expects. Usually 
raw binary or ELF. Not that different from -kernel that also takes 
different formats depending on the machine. Think of -bios like -kernel 
for firmware, i.e. specifying what firmware to use like -kernel specifies 
what kernel to use.

Regards,
BALATON Zoltan

CLI: Using -bios AND -kernel

[Philippe Mathieu-Daudé]

Hi John / Paolo / Markus,

On 10/19/21 12:07, BALATON Zoltan wrote:
> On Tue, 19 Oct 2021, Christophe Leroy wrote:
>> Le 19/10/2021 à 11:39, Thomas Huth a écrit :
>>> On 19/10/2021 11.31, Christophe Leroy wrote:
[...]
>> I use the following command, but it does nothing, it stays in uboot
>> prompt as when I don't get a kernel argument
>>
>>     ~/qemu/build/qemu-system-ppc -M taihu -bios
>> ~/Téléchargements/u-boot.bin -serial null -serial mon:stdio -kernel
>> arch/powerpc/boot/uImage
> 
> I'm not sure using -bios and -kernel together makes sense, it probably
> starts u-boot in this case and you have to load and start the kernel
> from u-boot as you'd notmally do on a real machine. Alternatively you
> could use -kernel instead of -bios which then loads a kernel and starts
> it directly but not sure if it needs a firmware to work.
> 
> Ot I could be completely wrong as I don't know this machine and haven't
> tried it.

Usually -bios overwrites -kernel/-append cmdline options.
Having them accepted together is probably a configuration mistake,
and we should reject that (generically).

You guys have been working on the CLI recently, is there an easy
way to not allow such combination?

Thanks,

Phil.

Re: CLI: Using -bios AND -kernel

[Thomas Huth]

On 20/10/2021 12.12, Philippe Mathieu-Daudé wrote:
> Hi John / Paolo / Markus,
> 
> On 10/19/21 12:07, BALATON Zoltan wrote:
>> On Tue, 19 Oct 2021, Christophe Leroy wrote:
>>> Le 19/10/2021 à 11:39, Thomas Huth a écrit :
>>>> On 19/10/2021 11.31, Christophe Leroy wrote:
> [...]
>>> I use the following command, but it does nothing, it stays in uboot
>>> prompt as when I don't get a kernel argument
>>>
>>>      ~/qemu/build/qemu-system-ppc -M taihu -bios
>>> ~/Téléchargements/u-boot.bin -serial null -serial mon:stdio -kernel
>>> arch/powerpc/boot/uImage
>>
>> I'm not sure using -bios and -kernel together makes sense, it probably
>> starts u-boot in this case and you have to load and start the kernel
>> from u-boot as you'd notmally do on a real machine. Alternatively you
>> could use -kernel instead of -bios which then loads a kernel and starts
>> it directly but not sure if it needs a firmware to work.
>>
>> Ot I could be completely wrong as I don't know this machine and haven't
>> tried it.
> 
> Usually -bios overwrites -kernel/-append cmdline options.
> Having them accepted together is probably a configuration mistake,
> and we should reject that (generically).

No, having -bios and -kernel together is perfectly fine if the BIOS knows 
about it. Have a look at the ppc64 pseries machine, it works perfectly fine 
with -bios and -kernel at the same time.

  Thomas

Re: CLI: Using -bios AND -kernel

[BALATON Zoltan]

[-- Attachment #1: Type: text/plain, Size: 2078 bytes --]

On Wed, 20 Oct 2021, Thomas Huth wrote:
> On 20/10/2021 12.12, Philippe Mathieu-Daudé wrote:
>> Hi John / Paolo / Markus,
>> 
>> On 10/19/21 12:07, BALATON Zoltan wrote:
>>> On Tue, 19 Oct 2021, Christophe Leroy wrote:
>>>> Le 19/10/2021 à 11:39, Thomas Huth a écrit :
>>>>> On 19/10/2021 11.31, Christophe Leroy wrote:
>> [...]
>>>> I use the following command, but it does nothing, it stays in uboot
>>>> prompt as when I don't get a kernel argument
>>>>
>>>>      ~/qemu/build/qemu-system-ppc -M taihu -bios
>>>> ~/Téléchargements/u-boot.bin -serial null -serial mon:stdio -kernel
>>>> arch/powerpc/boot/uImage
>>> 
>>> I'm not sure using -bios and -kernel together makes sense, it probably
>>> starts u-boot in this case and you have to load and start the kernel
>>> from u-boot as you'd notmally do on a real machine. Alternatively you
>>> could use -kernel instead of -bios which then loads a kernel and starts
>>> it directly but not sure if it needs a firmware to work.
>>> 
>>> Ot I could be completely wrong as I don't know this machine and haven't
>>> tried it.
>> 
>> Usually -bios overwrites -kernel/-append cmdline options.
>> Having them accepted together is probably a configuration mistake,
>> and we should reject that (generically).
>
> No, having -bios and -kernel together is perfectly fine if the BIOS knows 
> about it. Have a look at the ppc64 pseries machine, it works perfectly fine 
> with -bios and -kernel at the same time.

Also this way the board can decide what's right, In pegasos2 I added a 
warning for cases that may not work as expected to let users know but on 
other machines a firmware may be needed and -kernel could set firmware 
environment to boot that loaded kernel (this may be what ref405 is trying 
to do or e500 also messes with some boot_info struct that it writes to 
guest I think). So maybe there's no generic way to handle it. These 
options are just defined by the board which is not great for UI 
consistency but may be needed for enough flexibility to implement 
everything boards want.

Regards,
BALATON Zoltan

Re: Deprecate the ppc405 boards in QEMU?

[Greg Kurz]

On Tue, 19 Oct 2021 11:31:03 +0200
Christophe Leroy <christophe.leroy@csgroup.eu> wrote:

> 
> 
> Le 11/10/2021 à 15:24, Thomas Huth a écrit :
> > On 11/10/2021 11.20, David Gibson wrote:
> >> On Mon, Oct 11, 2021 at 10:10:36AM +0200, Thomas Huth wrote:
> >>> On 06/10/2021 09.25, Thomas Huth wrote:
> >>>> On 05/10/2021 23.53, BALATON Zoltan wrote:
> >>>> [...]
> >>>>> Maybe these 405 boards in QEMU ran with modified firmware where the
> >>>>> memory detection was patched out but it seems to detect the RAM so I
> >>>>> wonder where it gets that from. Maybe by reading the SDRAM
> >>>>> controller DCRs ppc4xx_sdram_init() sets up. Then I'm not sure what
> >>>>> it needs the SPD for, I forgot how this worked on sam460ex. Maybe
> >>>>> for the speed calibration, so could be it detects ram by reading
> >>>>> DCRs then tries to get SPD data and that's where it stops as i2c is
> >>>>> not emulated on taihu. This could be confirmed by checking what it
> >>>>> pokes with -d guest_errors that shows accesses to missing devices
> >>>>> but don't know where 405 has the i2c controller and if it's the same
> >>>>> as newer SoCs. If so that could be reused and an i2c bus could be
> >>>>> added with the SPD data like in sam460ex to make u-boot happy or you
> >>>>> could skip this in u-boot.
> >>>>
> >>>> FWIW, I've just tried the latter (skipping the sdram init in u-boot),
> >>>> and indeed, I can get to the u-boot prompt now.
> >>> [...]> I've also attached the patch with my modifications to u-boot.
> >>>
> >>> FYI, the changes can now be found on this branch here:
> >>>
> >>>   https://gitlab.com/huth/u-boot/-/commits/taihu
> >>>
> >>> I also added a gitlab-CI file, so you can now download the u-boot.bin 
> >>> as an
> >>> artifact from the corresponding pipeline, e.g.:
> >>>
> >>>   https://gitlab.com/huth/u-boot/-/jobs/1667201028
> >>
> >> Thanks.
> >>
> >> Are you going to send a v2 of your proposed deprecation patches?
> > 
> > No, since there was interest in keeping the 405 boards for testing the 
> > 405 code in the Linux kernel, and since there is now a way to do at 
> > least some very basic testing of these boards (with the u-boot 
> > firmware), I don't plan to respin the deprecation patch. I just sent a 
> > patch for adding the boards to our CI instead:
> > 
> >   https://lists.gnu.org/archive/html/qemu-devel/2021-10/msg02072.html
> > 
> 
> I have downloaded your u-boot.bin and tried it with both QEMU 5.2.0 and 
> mainline, and I get:
> 
> ERROR:../accel/tcg/tcg-accel-ops.c:79:tcg_handle_interrupt: assertion 
> failed: (qemu_mutex_iothread_locked())
> Bail out! ERROR:../accel/tcg/tcg-accel-ops.c:79:tcg_handle_interrupt: 
> assertion failed: (qemu_mutex_iothread_locked())
> Abandon (core dumped)
> 
> I see in the mail history that you got that problem as well at some 
> point. How did you fix it ?
> 

https://lists.gnu.org/archive/html/qemu-devel/2021-10/msg01019.html

Not yet upstream but already in David's ppc-for-6.2 tree :

https://gitlab.com/dgibson/qemu/-/commit/c29fca5c8173e9e647ebff07cb78b7c8135bd11a

> Thanks
> Christophe

Re: Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms)

[Cédric Le Goater]

On 10/5/21 08:18, Alexey Kardashevskiy wrote:
> 
> 
> On 05/10/2021 15:44, Christophe Leroy wrote:
>>
>>
>> Le 05/10/2021 à 02:48, David Gibson a écrit :
>>> On Fri, Oct 01, 2021 at 04:18:49PM +0200, Thomas Huth wrote:
>>>> On 01/10/2021 15.04, Christophe Leroy wrote:
>>>>>
>>>>>
>>>>> Le 01/10/2021 à 14:04, Thomas Huth a écrit :
>>>>>> On 01/10/2021 13.12, Peter Maydell wrote:
>>>>>>> On Fri, 1 Oct 2021 at 10:43, Thomas Huth <thuth@redhat.com> wrote:
>>>>>>>> Nevertheless, as long as nobody has a hint where to find that
>>>>>>>> ppc405_rom.bin, I think both boards are pretty useless in QEMU (as far as I
>>>>>>>> can see, they do not work without the bios at all, so it's
>>>>>>>> also not possible
>>>>>>>> to use a Linux image with the "-kernel" CLI option directly).
>>>>>>>
>>>>>>> It is at least in theory possible to run bare-metal code on
>>>>>>> either board, by passing either a pflash or a bios argument.
>>>>>>
>>>>>> True. I did some more research, and seems like there was once
>>>>>> support for those boards in u-boot, but it got removed there a
>>>>>> couple of years ago already:
>>>>>>
>>>>>> https://gitlab.com/qemu-project/u-boot/-/commit/98f705c9cefdf
>>>>>>
>>>>>> https://gitlab.com/qemu-project/u-boot/-/commit/b147ff2f37d5b
>>>>>>
>>>>>> https://gitlab.com/qemu-project/u-boot/-/commit/7514037bcdc37
>>>>>>
>>>>>>> But I agree that there seem to be no signs of anybody actually
>>>>>>> successfully using these boards for anything, so we should
>>>>>>> deprecate-and-delete them.
>>>>>>
>>>>>> Yes, let's mark them as deprecated now ... if someone still uses
>>>>>> them and speaks up, we can still revert the deprecation again.
>>>>>
>>>>> I really would like to be able to use them to validate Linux Kernel
>>>>> changes, hence looking for that missing BIOS.
>>>>>
>>>>> If we remove ppc405 from QEMU, we won't be able to do any regression
>>>>> tests of Linux Kernel on those processors.
>>>>
>>>> If you/someone managed to compile an old version of u-boot for one of these
>>>> two boards, so that we would finally have something for regression testing,
>>>> we can of course also keep the boards in QEMU...
>>>
>>> I can see that it would be usefor for some cases, but unless someone
>>> volunteers to track down the necessary firmware and look after it, I
>>> think we do need to deprecate it - I certainly don't have the capacity
>>> to look into this.
>>>
>>
>> I will look at it, please allow me a few weeks though.
> 
> Well, building it was not hard but now I'd like to know what board QEMU actually emulates, there are way too many codenames and PVRs.

yes. We should try to reduce the list below. Deprecating embedded machines
is one way.

C.


$ ./install/bin/qemu-system-ppc -cpu ?
PowerPC 601_v0           PVR 00010001
PowerPC 601_v1           PVR 00010001
PowerPC 601_v2           PVR 00010002
PowerPC 601              (alias for 601_v2)
PowerPC 601v             (alias for 601_v2)
PowerPC 603              PVR 00030100
PowerPC mpc8240          (alias for 603)
PowerPC vanilla          (alias for 603)
PowerPC 604              PVR 00040103
PowerPC ppc32            (alias for 604)
PowerPC ppc              (alias for 604)
PowerPC default          (alias for 604)
PowerPC 602              PVR 00050100
PowerPC 603e_v1.1        PVR 00060101
PowerPC 603e_v1.2        PVR 00060102
PowerPC 603e_v1.3        PVR 00060103
PowerPC 603e_v1.4        PVR 00060104
PowerPC 603e_v2.2        PVR 00060202
PowerPC 603e_v3          PVR 00060300
PowerPC 603e_v4          PVR 00060400
PowerPC 603e_v4.1        PVR 00060401
PowerPC 603e             (alias for 603e_v4.1)
PowerPC stretch          (alias for 603e_v4.1)
PowerPC 603p             PVR 00070000
PowerPC 603e7v           PVR 00070100
PowerPC vaillant         (alias for 603e7v)
PowerPC 603e7v1          PVR 00070101
PowerPC 603e7            PVR 00070200
PowerPC 603e7v2          PVR 00070201
PowerPC 603e7t           PVR 00071201
PowerPC 603r             (alias for 603e7t)
PowerPC goldeneye        (alias for 603e7t)
PowerPC 740_v1.0         PVR 00080100
PowerPC 740e             PVR 00080100
PowerPC 750_v1.0         PVR 00080100
PowerPC 750_v2.0         PVR 00080200
PowerPC 740_v2.0         PVR 00080200
PowerPC 750e             PVR 00080200
PowerPC 750_v2.1         PVR 00080201
PowerPC 740_v2.1         PVR 00080201
PowerPC 750_v2.2         PVR 00080202
PowerPC 740_v2.2         PVR 00080202
PowerPC 750_v3.0         PVR 00080300
PowerPC 740_v3.0         PVR 00080300
PowerPC 750_v3.1         PVR 00080301
PowerPC 750              (alias for 750_v3.1)
PowerPC typhoon          (alias for 750_v3.1)
PowerPC g3               (alias for 750_v3.1)
PowerPC 740_v3.1         PVR 00080301
PowerPC 740              (alias for 740_v3.1)
PowerPC arthur           (alias for 740_v3.1)
PowerPC 750cx_v1.0       PVR 00082100
PowerPC 750cx_v2.0       PVR 00082200
PowerPC 750cx_v2.1       PVR 00082201
PowerPC 750cx_v2.2       PVR 00082202
PowerPC 750cx            (alias for 750cx_v2.2)
PowerPC 750cxe_v2.1      PVR 00082211
PowerPC 750cxe_v2.2      PVR 00082212
PowerPC 750cxe_v2.3      PVR 00082213
PowerPC 750cxe_v2.4      PVR 00082214
PowerPC 750cxe_v3.0      PVR 00082310
PowerPC 750cxe_v3.1      PVR 00082311
PowerPC 745_v1.0         PVR 00083100
PowerPC 755_v1.0         PVR 00083100
PowerPC 755_v1.1         PVR 00083101
PowerPC 745_v1.1         PVR 00083101
PowerPC 755_v2.0         PVR 00083200
PowerPC 745_v2.0         PVR 00083200
PowerPC 755_v2.1         PVR 00083201
PowerPC 745_v2.1         PVR 00083201
PowerPC 755_v2.2         PVR 00083202
PowerPC 745_v2.2         PVR 00083202
PowerPC 755_v2.3         PVR 00083203
PowerPC 745_v2.3         PVR 00083203
PowerPC 755_v2.4         PVR 00083204
PowerPC 745_v2.4         PVR 00083204
PowerPC 755_v2.5         PVR 00083205
PowerPC 745_v2.5         PVR 00083205
PowerPC 755_v2.6         PVR 00083206
PowerPC 745_v2.6         PVR 00083206
PowerPC 755_v2.7         PVR 00083207
PowerPC 745_v2.7         PVR 00083207
PowerPC 745_v2.8         PVR 00083208
PowerPC 745              (alias for 745_v2.8)
PowerPC 755_v2.8         PVR 00083208
PowerPC 755              (alias for 755_v2.8)
PowerPC goldfinger       (alias for 755_v2.8)
PowerPC 750cxe_v2.4b     PVR 00083214
PowerPC 750cxe_v3.1b     PVR 00083311
PowerPC 750cxe           (alias for 750cxe_v3.1b)
PowerPC 750cxr           PVR 00083410
PowerPC 750cl_v1.0       PVR 00087200
PowerPC 750cl_v2.0       PVR 00087210
PowerPC 750cl            (alias for 750cl_v2.0)
PowerPC 750l_v2.0        PVR 00088200
PowerPC 750l_v2.1        PVR 00088201
PowerPC 750l_v2.2        PVR 00088202
PowerPC 750l_v3.0        PVR 00088300
PowerPC 750l_v3.2        PVR 00088302
PowerPC 750l             (alias for 750l_v3.2)
PowerPC lonestar         (alias for 750l_v3.2)
PowerPC 604e_v1.0        PVR 00090100
PowerPC 604e_v2.2        PVR 00090202
PowerPC 604e_v2.4        PVR 00090204
PowerPC 604e             (alias for 604e_v2.4)
PowerPC sirocco          (alias for 604e_v2.4)
PowerPC 604r             PVR 000a0101
PowerPC mach5            (alias for 604r)
PowerPC 7400_v1.0        PVR 000c0100
PowerPC 7400_v1.1        PVR 000c0101
PowerPC 7400_v2.0        PVR 000c0200
PowerPC 7400_v2.1        PVR 000c0201
PowerPC 7400_v2.2        PVR 000c0202
PowerPC 7400_v2.6        PVR 000c0206
PowerPC 7400_v2.7        PVR 000c0207
PowerPC 7400_v2.8        PVR 000c0208
PowerPC 7400_v2.9        PVR 000c0209
PowerPC 7400             (alias for 7400_v2.9)
PowerPC max              (alias for 7400_v2.9)
PowerPC g4               (alias for 7400_v2.9)
PowerPC 403ga            PVR 00200011
PowerPC 403gb            PVR 00200100
PowerPC 403gc            PVR 00200200
PowerPC 403              (alias for 403gc)
PowerPC 403gcx           PVR 00201400
PowerPC 401a1            PVR 00210000
PowerPC 401b2            PVR 00220000
PowerPC iop480           PVR 00220000
PowerPC 401c2            PVR 00230000
PowerPC 401d2            PVR 00240000
PowerPC 401e2            PVR 00250000
PowerPC 401f2            PVR 00260000
PowerPC 401g2            PVR 00270000
PowerPC 401              PVR 00270000
PowerPC g2               PVR 00810011
PowerPC mpc603           PVR 00810100
PowerPC g2hip3           PVR 00810101
PowerPC mpc8250_hip3     (alias for g2hip3)
PowerPC mpc8255_hip3     (alias for g2hip3)
PowerPC mpc8260_hip3     (alias for g2hip3)
PowerPC mpc8264_hip3     (alias for g2hip3)
PowerPC mpc8265_hip3     (alias for g2hip3)
PowerPC mpc8266_hip3     (alias for g2hip3)
PowerPC mpc8343          PVR 00830010
PowerPC mpc8349a         PVR 00830010
PowerPC mpc8347at        PVR 00830010
PowerPC mpc8347a         (alias for mpc8347at)
PowerPC e300c1           PVR 00830010
PowerPC mpc8343ea        PVR 00830010
PowerPC mpc8349e         PVR 00830010
PowerPC mpc8347ep        PVR 00830010
PowerPC mpc8347p         PVR 00830010
PowerPC mpc8347eap       PVR 00830010
PowerPC mpc8349          PVR 00830010
PowerPC mpc8347et        PVR 00830010
PowerPC mpc8347e         (alias for mpc8347et)
PowerPC mpc8347t         PVR 00830010
PowerPC mpc8347          (alias for mpc8347t)
PowerPC mpc8343a         PVR 00830010
PowerPC mpc8347eat       PVR 00830010
PowerPC mpc8347ea        (alias for mpc8347eat)
PowerPC mpc8347ap        PVR 00830010
PowerPC mpc8349ea        PVR 00830010
PowerPC mpc8343e         PVR 00830010
PowerPC e300c2           PVR 00840010
PowerPC e300c3           PVR 00850010
PowerPC e300             (alias for e300c3)
PowerPC mpc8379e         PVR 00860010
PowerPC e300c4           PVR 00860010
PowerPC mpc8377e         PVR 00860010
PowerPC mpc8377          PVR 00860010
PowerPC mpc8378          PVR 00860010
PowerPC mpc8379          PVR 00860010
PowerPC mpc8378e         PVR 00860010
PowerPC 740p             PVR 10080000
PowerPC 750p             PVR 10080000
PowerPC conan/doyle      (alias for 750p)
PowerPC cobra            PVR 10100000
PowerPC 460exb           PVR 130218a4
PowerPC 460ex            (alias for 460exb)
PowerPC 440epx           PVR 200008d0
PowerPC 405d2            PVR 20010000
PowerPC x2vp4            PVR 20010820
PowerPC x2vp7            (alias for x2vp4)
PowerPC x2vp20           PVR 20010860
PowerPC x2vp50           (alias for x2vp20)
PowerPC 405gpa           PVR 40110000
PowerPC 405gpb           PVR 40110040
PowerPC 405cra           PVR 40110041
PowerPC 405gpc           PVR 40110082
PowerPC 405gpd           PVR 401100c4
PowerPC 405gp            (alias for 405gpd)
PowerPC 405crb           PVR 401100c5
PowerPC 405crc           PVR 40110145
PowerPC 405cr            (alias for 405crc)
PowerPC 405gpe           (alias for 405crc)
PowerPC stb03            PVR 40310000
PowerPC npe4gs3          PVR 40b10000
PowerPC npe405h          PVR 414100c0
PowerPC npe405h2         PVR 41410140
PowerPC 405ez            PVR 41511460
PowerPC npe405l          PVR 416100c0
PowerPC stb04            PVR 41810000
PowerPC 405d4            PVR 41810000
PowerPC 405              (alias for 405d4)
PowerPC 405lp            PVR 41f10000
PowerPC 440epa           PVR 42221850
PowerPC 440epb           PVR 422218d3
PowerPC 440ep            (alias for 440epb)
PowerPC 405gpr           PVR 50910951
PowerPC 405ep            PVR 51210950
PowerPC stb25            PVR 51510950
PowerPC 750fx_v1.0       PVR 70000100
PowerPC 750fx_v2.0       PVR 70000200
PowerPC 750fx_v2.1       PVR 70000201
PowerPC 750fx_v2.2       PVR 70000202
PowerPC 750fx_v2.3       PVR 70000203
PowerPC 750fx            (alias for 750fx_v2.3)
PowerPC 750fl            PVR 70000203
PowerPC 750gx_v1.0       PVR 70020100
PowerPC 750gx_v1.1       PVR 70020101
PowerPC 750gl            PVR 70020102
PowerPC 750gx_v1.2       PVR 70020102
PowerPC 750gx            (alias for 750gx_v1.2)
PowerPC 440-xilinx-w-dfpu PVR 7ff21910
PowerPC 440-xilinx       PVR 7ff21910
PowerPC 7450_v1.0        PVR 80000100
PowerPC 7450_v1.1        PVR 80000101
PowerPC 7450_v1.2        PVR 80000102
PowerPC 7450_v2.0        PVR 80000200
PowerPC 7441_v2.1        PVR 80000201
PowerPC 7450_v2.1        PVR 80000201
PowerPC 7450             (alias for 7450_v2.1)
PowerPC vger             (alias for 7450_v2.1)
PowerPC 7451_v2.3        PVR 80000203
PowerPC 7451             (alias for 7451_v2.3)
PowerPC 7441_v2.3        PVR 80000203
PowerPC 7441             (alias for 7441_v2.3)
PowerPC 7451_v2.10       PVR 80000210
PowerPC 7441_v2.10       PVR 80000210
PowerPC 7455_v1.0        PVR 80010100
PowerPC 7445_v1.0        PVR 80010100
PowerPC 7445_v2.1        PVR 80010201
PowerPC 7455_v2.1        PVR 80010201
PowerPC 7455_v3.2        PVR 80010302
PowerPC 7455             (alias for 7455_v3.2)
PowerPC apollo6          (alias for 7455_v3.2)
PowerPC 7445_v3.2        PVR 80010302
PowerPC 7445             (alias for 7445_v3.2)
PowerPC 7455_v3.3        PVR 80010303
PowerPC 7445_v3.3        PVR 80010303
PowerPC 7455_v3.4        PVR 80010304
PowerPC 7445_v3.4        PVR 80010304
PowerPC 7447_v1.0        PVR 80020100
PowerPC 7457_v1.0        PVR 80020100
PowerPC 7447_v1.1        PVR 80020101
PowerPC 7447             (alias for 7447_v1.1)
PowerPC 7457_v1.1        PVR 80020101
PowerPC 7457_v1.2        PVR 80020102
PowerPC 7457             (alias for 7457_v1.2)
PowerPC apollo7          (alias for 7457_v1.2)
PowerPC 7457a_v1.0       PVR 80030100
PowerPC apollo7pm        (alias for 7457a_v1.0)
PowerPC 7447a_v1.0       PVR 80030100
PowerPC 7457a_v1.1       PVR 80030101
PowerPC 7447a_v1.1       PVR 80030101
PowerPC 7457a_v1.2       PVR 80030102
PowerPC 7457a            (alias for 7457a_v1.2)
PowerPC 7447a_v1.2       PVR 80030102
PowerPC 7447a            (alias for 7447a_v1.2)
PowerPC mpc8641d         PVR 80040010
PowerPC mpc8610          PVR 80040010
PowerPC e600             PVR 80040010
PowerPC mpc8641          PVR 80040010
PowerPC 7448_v1.0        PVR 80040100
PowerPC 7448_v1.1        PVR 80040101
PowerPC 7448_v2.0        PVR 80040200
PowerPC 7448_v2.1        PVR 80040201
PowerPC 7448             (alias for 7448_v2.1)
PowerPC 7410_v1.0        PVR 800c1100
PowerPC 7410_v1.1        PVR 800c1101
PowerPC 7410_v1.2        PVR 800c1102
PowerPC 7410_v1.3        PVR 800c1103
PowerPC 7410_v1.4        PVR 800c1104
PowerPC 7410             (alias for 7410_v1.4)
PowerPC nitro            (alias for 7410_v1.4)
PowerPC mpc8540_v10      PVR 80200010
PowerPC e500_v10         PVR 80200010
PowerPC mpc8541_v10      PVR 80200020
PowerPC mpc8541_v11      PVR 80200020
PowerPC mpc8541          (alias for mpc8541_v11)
PowerPC mpc8541e_v10     PVR 80200020
PowerPC mpc8540_v20      PVR 80200020
PowerPC mpc8541e_v11     PVR 80200020
PowerPC mpc8541e         (alias for mpc8541e_v11)
PowerPC mpc8540_v21      PVR 80200020
PowerPC mpc8540          (alias for mpc8540_v21)
PowerPC e500_v20         PVR 80200020
PowerPC e500v1           (alias for e500_v20)
PowerPC mpc8543e_v10     PVR 80210010
PowerPC mpc8543_v10      PVR 80210010
PowerPC mpc8548e_v10     PVR 80210010
PowerPC mpc8555_v10      PVR 80210010
PowerPC mpc8555e_v10     PVR 80210010
PowerPC e500v2_v10       PVR 80210010
PowerPC mpc8560_v10      PVR 80210010
PowerPC mpc8548_v10      PVR 80210010
PowerPC mpc8543e_v11     PVR 80210011
PowerPC mpc8548e_v11     PVR 80210011
PowerPC mpc8543_v11      PVR 80210011
PowerPC mpc8555_v11      PVR 80210011
PowerPC mpc8555          (alias for mpc8555_v11)
PowerPC mpc8555e_v11     PVR 80210011
PowerPC mpc8555e         (alias for mpc8555e_v11)
PowerPC mpc8548_v11      PVR 80210011
PowerPC mpc8560_v20      PVR 80210020
PowerPC mpc8548_v20      PVR 80210020
PowerPC mpc8547e_v20     PVR 80210020
PowerPC mpc8545_v20      PVR 80210020
PowerPC mpc8543e_v20     PVR 80210020
PowerPC mpc8548e_v20     PVR 80210020
PowerPC mpc8543_v20      PVR 80210020
PowerPC mpc8545e_v20     PVR 80210020
PowerPC e500v2_v20       PVR 80210020
PowerPC mpc8545e_v21     PVR 80210021
PowerPC mpc8545e         (alias for mpc8545e_v21)
PowerPC mpc8544_v10      PVR 80210021
PowerPC mpc8560_v21      PVR 80210021
PowerPC mpc8560          (alias for mpc8560_v21)
PowerPC mpc8533e_v10     PVR 80210021
PowerPC mpc8544e_v10     PVR 80210021
PowerPC mpc8547e_v21     PVR 80210021
PowerPC mpc8547e         (alias for mpc8547e_v21)
PowerPC mpc8548_v21      PVR 80210021
PowerPC mpc8548          (alias for mpc8548_v21)
PowerPC mpc8545_v21      PVR 80210021
PowerPC mpc8545          (alias for mpc8545_v21)
PowerPC mpc8543e_v21     PVR 80210021
PowerPC mpc8543e         (alias for mpc8543e_v21)
PowerPC mpc8543_v21      PVR 80210021
PowerPC mpc8543          (alias for mpc8543_v21)
PowerPC mpc8548e_v21     PVR 80210021
PowerPC mpc8548e         (alias for mpc8548e_v21)
PowerPC e500v2_v21       PVR 80210021
PowerPC mpc8533_v10      PVR 80210021
PowerPC mpc8544_v11      PVR 80210022
PowerPC mpc8544          (alias for mpc8544_v11)
PowerPC mpc8568e         PVR 80210022
PowerPC mpc8533e_v11     PVR 80210022
PowerPC mpc8533e         (alias for mpc8533e_v11)
PowerPC mpc8544e_v11     PVR 80210022
PowerPC mpc8544e         (alias for mpc8544e_v11)
PowerPC mpc8567          PVR 80210022
PowerPC mpc8568          PVR 80210022
PowerPC mpc8567e         PVR 80210022
PowerPC e500v2_v22       PVR 80210022
PowerPC e500             (alias for e500v2_v22)
PowerPC e500v2           (alias for e500v2_v22)
PowerPC mpc8533_v11      PVR 80210022
PowerPC mpc8533          (alias for mpc8533_v11)
PowerPC mpc8572e         PVR 80210030
PowerPC e500v2_v30       PVR 80210030
PowerPC mpc8572          PVR 80210030
PowerPC e500mc           PVR 80230020
PowerPC g2h4             PVR 80811010
PowerPC g2hip4           PVR 80811014
PowerPC mpc8241          (alias for g2hip4)
PowerPC mpc8245          (alias for g2hip4)
PowerPC mpc8250          (alias for g2hip4)
PowerPC mpc8250_hip4     (alias for g2hip4)
PowerPC mpc8255          (alias for g2hip4)
PowerPC mpc8255_hip4     (alias for g2hip4)
PowerPC mpc8260          (alias for g2hip4)
PowerPC mpc8260_hip4     (alias for g2hip4)
PowerPC mpc8264          (alias for g2hip4)
PowerPC mpc8264_hip4     (alias for g2hip4)
PowerPC mpc8265          (alias for g2hip4)
PowerPC mpc8265_hip4     (alias for g2hip4)
PowerPC mpc8266          (alias for g2hip4)
PowerPC mpc8266_hip4     (alias for g2hip4)
PowerPC g2le             PVR 80820010
PowerPC g2gp             PVR 80821010
PowerPC g2legp           PVR 80822010
PowerPC mpc5200b_v20     PVR 80822011
PowerPC mpc5200_v10      PVR 80822011
PowerPC mpc5200b_v21     PVR 80822011
PowerPC mpc5200b         (alias for mpc5200b_v21)
PowerPC mpc5200_v11      PVR 80822011
PowerPC mpc5200_v12      PVR 80822011
PowerPC mpc52xx          (alias for mpc5200_v12)
PowerPC mpc5200          (alias for mpc5200_v12)
PowerPC g2legp1          PVR 80822011
PowerPC g2legp3          PVR 80822013
PowerPC mpc82xx          (alias for g2legp3)
PowerPC powerquicc-ii    (alias for g2legp3)
PowerPC mpc8247          (alias for g2legp3)
PowerPC mpc8248          (alias for g2legp3)
PowerPC mpc8270          (alias for g2legp3)
PowerPC mpc8271          (alias for g2legp3)
PowerPC mpc8272          (alias for g2legp3)
PowerPC mpc8275          (alias for g2legp3)
PowerPC mpc8280          (alias for g2legp3)
PowerPC e200z5           PVR 81000000
PowerPC e200z6           PVR 81120000
PowerPC e200             (alias for e200z6)
PowerPC g2ls             PVR 90810010
PowerPC g2lels           PVR a0822010

Re: Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms)

[BALATON Zoltan]

[-- Attachment #1: Type: text/plain, Size: 3045 bytes --]

On Tue, 5 Oct 2021, Cédric Le Goater wrote:
> On 10/5/21 08:18, Alexey Kardashevskiy wrote:
>> On 05/10/2021 15:44, Christophe Leroy wrote:
>>> Le 05/10/2021 à 02:48, David Gibson a écrit :
>>>> On Fri, Oct 01, 2021 at 04:18:49PM +0200, Thomas Huth wrote:
>>>>> On 01/10/2021 15.04, Christophe Leroy wrote:
>>>>>> Le 01/10/2021 à 14:04, Thomas Huth a écrit :
>>>>>>> On 01/10/2021 13.12, Peter Maydell wrote:
>>>>>>>> On Fri, 1 Oct 2021 at 10:43, Thomas Huth <thuth@redhat.com> wrote:
>>>>>>>>> Nevertheless, as long as nobody has a hint where to find that
>>>>>>>>> ppc405_rom.bin, I think both boards are pretty useless in QEMU (as 
>>>>>>>>> far as I
>>>>>>>>> can see, they do not work without the bios at all, so it's
>>>>>>>>> also not possible
>>>>>>>>> to use a Linux image with the "-kernel" CLI option directly).
>>>>>>>> 
>>>>>>>> It is at least in theory possible to run bare-metal code on
>>>>>>>> either board, by passing either a pflash or a bios argument.
>>>>>>> 
>>>>>>> True. I did some more research, and seems like there was once
>>>>>>> support for those boards in u-boot, but it got removed there a
>>>>>>> couple of years ago already:
>>>>>>> 
>>>>>>> https://gitlab.com/qemu-project/u-boot/-/commit/98f705c9cefdf
>>>>>>> 
>>>>>>> https://gitlab.com/qemu-project/u-boot/-/commit/b147ff2f37d5b
>>>>>>> 
>>>>>>> https://gitlab.com/qemu-project/u-boot/-/commit/7514037bcdc37
>>>>>>> 
>>>>>>>> But I agree that there seem to be no signs of anybody actually
>>>>>>>> successfully using these boards for anything, so we should
>>>>>>>> deprecate-and-delete them.
>>>>>>> 
>>>>>>> Yes, let's mark them as deprecated now ... if someone still uses
>>>>>>> them and speaks up, we can still revert the deprecation again.
>>>>>> 
>>>>>> I really would like to be able to use them to validate Linux Kernel
>>>>>> changes, hence looking for that missing BIOS.
>>>>>> 
>>>>>> If we remove ppc405 from QEMU, we won't be able to do any regression
>>>>>> tests of Linux Kernel on those processors.
>>>>> 
>>>>> If you/someone managed to compile an old version of u-boot for one of 
>>>>> these
>>>>> two boards, so that we would finally have something for regression 
>>>>> testing,
>>>>> we can of course also keep the boards in QEMU...
>>>> 
>>>> I can see that it would be usefor for some cases, but unless someone
>>>> volunteers to track down the necessary firmware and look after it, I
>>>> think we do need to deprecate it - I certainly don't have the capacity
>>>> to look into this.
>>>> 
>>> 
>>> I will look at it, please allow me a few weeks though.
>> 
>> Well, building it was not hard but now I'd like to know what board QEMU 
>> actually emulates, there are way too many codenames and PVRs.
>
> yes. We should try to reduce the list below. Deprecating embedded machines
> is one way.

Why should we reduce that list? It's good to have different cpu options 
when one wants to test code for different PPC versions (maybe also in user 
mode) or just to have a quick list of these at one place.

Regards,
BALATON Zoltan

Re: Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms)

[Thomas Huth]

On 05/10/2021 14.20, BALATON Zoltan wrote:
> On Tue, 5 Oct 2021, Cédric Le Goater wrote:
>> On 10/5/21 08:18, Alexey Kardashevskiy wrote:
>>> On 05/10/2021 15:44, Christophe Leroy wrote:
>>>> Le 05/10/2021 à 02:48, David Gibson a écrit :
>>>>> On Fri, Oct 01, 2021 at 04:18:49PM +0200, Thomas Huth wrote:
>>>>>> On 01/10/2021 15.04, Christophe Leroy wrote:
>>>>>>> Le 01/10/2021 à 14:04, Thomas Huth a écrit :
>>>>>>>> On 01/10/2021 13.12, Peter Maydell wrote:
>>>>>>>>> On Fri, 1 Oct 2021 at 10:43, Thomas Huth <thuth@redhat.com> wrote:
>>>>>>>>>> Nevertheless, as long as nobody has a hint where to find that
>>>>>>>>>> ppc405_rom.bin, I think both boards are pretty useless in QEMU (as 
>>>>>>>>>> far as I
>>>>>>>>>> can see, they do not work without the bios at all, so it's
>>>>>>>>>> also not possible
>>>>>>>>>> to use a Linux image with the "-kernel" CLI option directly).
>>>>>>>>>
>>>>>>>>> It is at least in theory possible to run bare-metal code on
>>>>>>>>> either board, by passing either a pflash or a bios argument.
>>>>>>>>
>>>>>>>> True. I did some more research, and seems like there was once
>>>>>>>> support for those boards in u-boot, but it got removed there a
>>>>>>>> couple of years ago already:
>>>>>>>>
>>>>>>>> https://gitlab.com/qemu-project/u-boot/-/commit/98f705c9cefdf
>>>>>>>>
>>>>>>>> https://gitlab.com/qemu-project/u-boot/-/commit/b147ff2f37d5b
>>>>>>>>
>>>>>>>> https://gitlab.com/qemu-project/u-boot/-/commit/7514037bcdc37
>>>>>>>>
>>>>>>>>> But I agree that there seem to be no signs of anybody actually
>>>>>>>>> successfully using these boards for anything, so we should
>>>>>>>>> deprecate-and-delete them.
>>>>>>>>
>>>>>>>> Yes, let's mark them as deprecated now ... if someone still uses
>>>>>>>> them and speaks up, we can still revert the deprecation again.
>>>>>>>
>>>>>>> I really would like to be able to use them to validate Linux Kernel
>>>>>>> changes, hence looking for that missing BIOS.
>>>>>>>
>>>>>>> If we remove ppc405 from QEMU, we won't be able to do any regression
>>>>>>> tests of Linux Kernel on those processors.
>>>>>>
>>>>>> If you/someone managed to compile an old version of u-boot for one of 
>>>>>> these
>>>>>> two boards, so that we would finally have something for regression 
>>>>>> testing,
>>>>>> we can of course also keep the boards in QEMU...
>>>>>
>>>>> I can see that it would be usefor for some cases, but unless someone
>>>>> volunteers to track down the necessary firmware and look after it, I
>>>>> think we do need to deprecate it - I certainly don't have the capacity
>>>>> to look into this.
>>>>>
>>>>
>>>> I will look at it, please allow me a few weeks though.
>>>
>>> Well, building it was not hard but now I'd like to know what board QEMU 
>>> actually emulates, there are way too many codenames and PVRs.
>>
>> yes. We should try to reduce the list below. Deprecating embedded machines
>> is one way.
> 
> Why should we reduce that list? It's good to have different cpu options when 
> one wants to test code for different PPC versions (maybe also in user mode) 
> or just to have a quick list of these at one place.

I think there are many CPUs in that list which cannot be used with any 
board, some of them might be also in a very incomplete state. So presenting 
such a big list to the users is confusing and might create wrong 
expectations. It would be good to remove at least the CPUs which are really 
completely useless.

  Thomas

Re: Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms)

[Philippe Mathieu-Daudé]

+Richard

On 10/5/21 14:29, Thomas Huth wrote:
> On 05/10/2021 14.20, BALATON Zoltan wrote:
>> On Tue, 5 Oct 2021, Cédric Le Goater wrote:
>>> On 10/5/21 08:18, Alexey Kardashevskiy wrote:
>>>> On 05/10/2021 15:44, Christophe Leroy wrote:
>>>>> Le 05/10/2021 à 02:48, David Gibson a écrit :
>>>>>> On Fri, Oct 01, 2021 at 04:18:49PM +0200, Thomas Huth wrote:
>>>>>>> On 01/10/2021 15.04, Christophe Leroy wrote:
>>>>>>>> Le 01/10/2021 à 14:04, Thomas Huth a écrit :
>>>>>>>>> On 01/10/2021 13.12, Peter Maydell wrote:
>>>>>>>>>> On Fri, 1 Oct 2021 at 10:43, Thomas Huth <thuth@redhat.com>
>>>>>>>>>> wrote:
>>>>>>>>>>> Nevertheless, as long as nobody has a hint where to find that
>>>>>>>>>>> ppc405_rom.bin, I think both boards are pretty useless in
>>>>>>>>>>> QEMU (as far as I
>>>>>>>>>>> can see, they do not work without the bios at all, so it's
>>>>>>>>>>> also not possible
>>>>>>>>>>> to use a Linux image with the "-kernel" CLI option directly).
>>>>>>>>>>
>>>>>>>>>> It is at least in theory possible to run bare-metal code on
>>>>>>>>>> either board, by passing either a pflash or a bios argument.
>>>>>>>>>
>>>>>>>>> True. I did some more research, and seems like there was once
>>>>>>>>> support for those boards in u-boot, but it got removed there a
>>>>>>>>> couple of years ago already:
>>>>>>>>>
>>>>>>>>> https://gitlab.com/qemu-project/u-boot/-/commit/98f705c9cefdf
>>>>>>>>>
>>>>>>>>> https://gitlab.com/qemu-project/u-boot/-/commit/b147ff2f37d5b
>>>>>>>>>
>>>>>>>>> https://gitlab.com/qemu-project/u-boot/-/commit/7514037bcdc37
>>>>>>>>>
>>>>>>>>>> But I agree that there seem to be no signs of anybody actually
>>>>>>>>>> successfully using these boards for anything, so we should
>>>>>>>>>> deprecate-and-delete them.
>>>>>>>>>
>>>>>>>>> Yes, let's mark them as deprecated now ... if someone still uses
>>>>>>>>> them and speaks up, we can still revert the deprecation again.
>>>>>>>>
>>>>>>>> I really would like to be able to use them to validate Linux Kernel
>>>>>>>> changes, hence looking for that missing BIOS.
>>>>>>>>
>>>>>>>> If we remove ppc405 from QEMU, we won't be able to do any
>>>>>>>> regression
>>>>>>>> tests of Linux Kernel on those processors.
>>>>>>>
>>>>>>> If you/someone managed to compile an old version of u-boot for
>>>>>>> one of these
>>>>>>> two boards, so that we would finally have something for
>>>>>>> regression testing,
>>>>>>> we can of course also keep the boards in QEMU...
>>>>>>
>>>>>> I can see that it would be usefor for some cases, but unless someone
>>>>>> volunteers to track down the necessary firmware and look after it, I
>>>>>> think we do need to deprecate it - I certainly don't have the
>>>>>> capacity
>>>>>> to look into this.
>>>>>>
>>>>>
>>>>> I will look at it, please allow me a few weeks though.
>>>>
>>>> Well, building it was not hard but now I'd like to know what board
>>>> QEMU actually emulates, there are way too many codenames and PVRs.
>>>
>>> yes. We should try to reduce the list below. Deprecating embedded
>>> machines
>>> is one way.
>>
>> Why should we reduce that list? It's good to have different cpu
>> options when one wants to test code for different PPC versions (maybe
>> also in user mode) or just to have a quick list of these at one place.
> 
> I think there are many CPUs in that list which cannot be used with any
> board, some of them might be also in a very incomplete state. So
> presenting such a big list to the users is confusing and might create
> wrong expectations. It would be good to remove at least the CPUs which
> are really completely useless.

Maybe only remove some from system emulation but keep all of them
in user emulation?

Re: Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms)

[BALATON Zoltan]

[-- Attachment #1: Type: text/plain, Size: 4063 bytes --]

On Wed, 20 Oct 2021, Philippe Mathieu-Daudé wrote:
> On 10/5/21 14:29, Thomas Huth wrote:
>> On 05/10/2021 14.20, BALATON Zoltan wrote:
>>> On Tue, 5 Oct 2021, Cédric Le Goater wrote:
>>>> On 10/5/21 08:18, Alexey Kardashevskiy wrote:
>>>>> On 05/10/2021 15:44, Christophe Leroy wrote:
>>>>>> Le 05/10/2021 à 02:48, David Gibson a écrit :
>>>>>>> On Fri, Oct 01, 2021 at 04:18:49PM +0200, Thomas Huth wrote:
>>>>>>>> On 01/10/2021 15.04, Christophe Leroy wrote:
>>>>>>>>> Le 01/10/2021 à 14:04, Thomas Huth a écrit :
>>>>>>>>>> On 01/10/2021 13.12, Peter Maydell wrote:
>>>>>>>>>>> On Fri, 1 Oct 2021 at 10:43, Thomas Huth <thuth@redhat.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>> Nevertheless, as long as nobody has a hint where to find that
>>>>>>>>>>>> ppc405_rom.bin, I think both boards are pretty useless in
>>>>>>>>>>>> QEMU (as far as I
>>>>>>>>>>>> can see, they do not work without the bios at all, so it's
>>>>>>>>>>>> also not possible
>>>>>>>>>>>> to use a Linux image with the "-kernel" CLI option directly).
>>>>>>>>>>>
>>>>>>>>>>> It is at least in theory possible to run bare-metal code on
>>>>>>>>>>> either board, by passing either a pflash or a bios argument.
>>>>>>>>>>
>>>>>>>>>> True. I did some more research, and seems like there was once
>>>>>>>>>> support for those boards in u-boot, but it got removed there a
>>>>>>>>>> couple of years ago already:
>>>>>>>>>>
>>>>>>>>>> https://gitlab.com/qemu-project/u-boot/-/commit/98f705c9cefdf
>>>>>>>>>>
>>>>>>>>>> https://gitlab.com/qemu-project/u-boot/-/commit/b147ff2f37d5b
>>>>>>>>>>
>>>>>>>>>> https://gitlab.com/qemu-project/u-boot/-/commit/7514037bcdc37
>>>>>>>>>>
>>>>>>>>>>> But I agree that there seem to be no signs of anybody actually
>>>>>>>>>>> successfully using these boards for anything, so we should
>>>>>>>>>>> deprecate-and-delete them.
>>>>>>>>>>
>>>>>>>>>> Yes, let's mark them as deprecated now ... if someone still uses
>>>>>>>>>> them and speaks up, we can still revert the deprecation again.
>>>>>>>>>
>>>>>>>>> I really would like to be able to use them to validate Linux Kernel
>>>>>>>>> changes, hence looking for that missing BIOS.
>>>>>>>>>
>>>>>>>>> If we remove ppc405 from QEMU, we won't be able to do any
>>>>>>>>> regression
>>>>>>>>> tests of Linux Kernel on those processors.
>>>>>>>>
>>>>>>>> If you/someone managed to compile an old version of u-boot for
>>>>>>>> one of these
>>>>>>>> two boards, so that we would finally have something for
>>>>>>>> regression testing,
>>>>>>>> we can of course also keep the boards in QEMU...
>>>>>>>
>>>>>>> I can see that it would be usefor for some cases, but unless someone
>>>>>>> volunteers to track down the necessary firmware and look after it, I
>>>>>>> think we do need to deprecate it - I certainly don't have the
>>>>>>> capacity
>>>>>>> to look into this.
>>>>>>>
>>>>>>
>>>>>> I will look at it, please allow me a few weeks though.
>>>>>
>>>>> Well, building it was not hard but now I'd like to know what board
>>>>> QEMU actually emulates, there are way too many codenames and PVRs.
>>>>
>>>> yes. We should try to reduce the list below. Deprecating embedded
>>>> machines
>>>> is one way.
>>>
>>> Why should we reduce that list? It's good to have different cpu
>>> options when one wants to test code for different PPC versions (maybe
>>> also in user mode) or just to have a quick list of these at one place.
>>
>> I think there are many CPUs in that list which cannot be used with any
>> board, some of them might be also in a very incomplete state. So
>> presenting such a big list to the users is confusing and might create
>> wrong expectations. It would be good to remove at least the CPUs which
>> are really completely useless.
>
> Maybe only remove some from system emulation but keep all of them
> in user emulation?

Or keep them all but mark those that are not tested/may be incomplete? So 
the used can see what is expected to work and what may need to be fixed. 
That way somebody may try and fix it whereas if it's not there they are 
unlikely to try to add it.

Regards,
BALATON Zoltan

Re: Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms)

[Cédric Le Goater]

On 10/20/21 13:42, BALATON Zoltan wrote:
> On Wed, 20 Oct 2021, Philippe Mathieu-Daudé wrote:
>> On 10/5/21 14:29, Thomas Huth wrote:
>>> On 05/10/2021 14.20, BALATON Zoltan wrote:
>>>> On Tue, 5 Oct 2021, Cédric Le Goater wrote:
>>>>> On 10/5/21 08:18, Alexey Kardashevskiy wrote:
>>>>>> On 05/10/2021 15:44, Christophe Leroy wrote:
>>>>>>> Le 05/10/2021 à 02:48, David Gibson a écrit :
>>>>>>>> On Fri, Oct 01, 2021 at 04:18:49PM +0200, Thomas Huth wrote:
>>>>>>>>> On 01/10/2021 15.04, Christophe Leroy wrote:
>>>>>>>>>> Le 01/10/2021 à 14:04, Thomas Huth a écrit :
>>>>>>>>>>> On 01/10/2021 13.12, Peter Maydell wrote:
>>>>>>>>>>>> On Fri, 1 Oct 2021 at 10:43, Thomas Huth <thuth@redhat.com>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>> Nevertheless, as long as nobody has a hint where to find that
>>>>>>>>>>>>> ppc405_rom.bin, I think both boards are pretty useless in
>>>>>>>>>>>>> QEMU (as far as I
>>>>>>>>>>>>> can see, they do not work without the bios at all, so it's
>>>>>>>>>>>>> also not possible
>>>>>>>>>>>>> to use a Linux image with the "-kernel" CLI option directly).
>>>>>>>>>>>>
>>>>>>>>>>>> It is at least in theory possible to run bare-metal code on
>>>>>>>>>>>> either board, by passing either a pflash or a bios argument.
>>>>>>>>>>>
>>>>>>>>>>> True. I did some more research, and seems like there was once
>>>>>>>>>>> support for those boards in u-boot, but it got removed there a
>>>>>>>>>>> couple of years ago already:
>>>>>>>>>>>
>>>>>>>>>>> https://gitlab.com/qemu-project/u-boot/-/commit/98f705c9cefdf
>>>>>>>>>>>
>>>>>>>>>>> https://gitlab.com/qemu-project/u-boot/-/commit/b147ff2f37d5b
>>>>>>>>>>>
>>>>>>>>>>> https://gitlab.com/qemu-project/u-boot/-/commit/7514037bcdc37
>>>>>>>>>>>
>>>>>>>>>>>> But I agree that there seem to be no signs of anybody actually
>>>>>>>>>>>> successfully using these boards for anything, so we should
>>>>>>>>>>>> deprecate-and-delete them.
>>>>>>>>>>>
>>>>>>>>>>> Yes, let's mark them as deprecated now ... if someone still uses
>>>>>>>>>>> them and speaks up, we can still revert the deprecation again.
>>>>>>>>>>
>>>>>>>>>> I really would like to be able to use them to validate Linux Kernel
>>>>>>>>>> changes, hence looking for that missing BIOS.
>>>>>>>>>>
>>>>>>>>>> If we remove ppc405 from QEMU, we won't be able to do any
>>>>>>>>>> regression
>>>>>>>>>> tests of Linux Kernel on those processors.
>>>>>>>>>
>>>>>>>>> If you/someone managed to compile an old version of u-boot for
>>>>>>>>> one of these
>>>>>>>>> two boards, so that we would finally have something for
>>>>>>>>> regression testing,
>>>>>>>>> we can of course also keep the boards in QEMU...
>>>>>>>>
>>>>>>>> I can see that it would be usefor for some cases, but unless someone
>>>>>>>> volunteers to track down the necessary firmware and look after it, I
>>>>>>>> think we do need to deprecate it - I certainly don't have the
>>>>>>>> capacity
>>>>>>>> to look into this.
>>>>>>>>
>>>>>>>
>>>>>>> I will look at it, please allow me a few weeks though.
>>>>>>
>>>>>> Well, building it was not hard but now I'd like to know what board
>>>>>> QEMU actually emulates, there are way too many codenames and PVRs.
>>>>>
>>>>> yes. We should try to reduce the list below. Deprecating embedded
>>>>> machines
>>>>> is one way.
>>>>
>>>> Why should we reduce that list? It's good to have different cpu
>>>> options when one wants to test code for different PPC versions (maybe
>>>> also in user mode) or just to have a quick list of these at one place.
>>>
>>> I think there are many CPUs in that list which cannot be used with any
>>> board, some of them might be also in a very incomplete state. So
>>> presenting such a big list to the users is confusing and might create
>>> wrong expectations. It would be good to remove at least the CPUs which
>>> are really completely useless.
>>
>> Maybe only remove some from system emulation but keep all of them
>> in user emulation?
> 
> Or keep them all but mark those that are not tested/may be incomplete? So the used can see what is expected to work and what may need to be fixed. That way somebody may try and fix it whereas if it's not there they are unlikely to try to add it.


The bamboo machine with 440 CPUs is booting with the latest kernel
and we have an acceptance test for it now, thanks to Thomas. There
is not much effort in keeping them in a working state until someone
volunteers. Hopefully, Christophe is making sure that we are not
breaking anything with Linux support.

The 405 machine are still close to deprecation I think. We are still
struggling to boot one with mainline Linux, using uboot provided by
Thomas which skips SDRAM init. It is not clear to me if u-boot is
strictly necessary. It depends if Linux relies on it to do some
pre-initialization of HW. I guess once we find a good DTS for it, or
not, we can take a decision.

Thanks,

C.




> 
> Regards,
> BALATON Zoltan

Re: Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms)

[LEROY Christophe]

Le 20/10/2021 à 14:43, Cédric Le Goater a écrit :
> On 10/20/21 13:42, BALATON Zoltan wrote:
>> On Wed, 20 Oct 2021, Philippe Mathieu-Daudé wrote:
>>> On 10/5/21 14:29, Thomas Huth wrote:
>>>> On 05/10/2021 14.20, BALATON Zoltan wrote:
>>>>> On Tue, 5 Oct 2021, Cédric Le Goater wrote:
>>>>>> On 10/5/21 08:18, Alexey Kardashevskiy wrote:
>>>>>>> On 05/10/2021 15:44, Christophe Leroy wrote:
>>>>>>>> Le 05/10/2021 à 02:48, David Gibson a écrit :
>>>>>>>>> On Fri, Oct 01, 2021 at 04:18:49PM +0200, Thomas Huth wrote:
>>>>>>>>>> On 01/10/2021 15.04, Christophe Leroy wrote:
>>>>>>>>>>> Le 01/10/2021 à 14:04, Thomas Huth a écrit :
>>>>>>>>>>>> On 01/10/2021 13.12, Peter Maydell wrote:
>>>>>>>>>>>>> On Fri, 1 Oct 2021 at 10:43, Thomas Huth <thuth@redhat.com>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>> Nevertheless, as long as nobody has a hint where to find that
>>>>>>>>>>>>>> ppc405_rom.bin, I think both boards are pretty useless in
>>>>>>>>>>>>>> QEMU (as far as I
>>>>>>>>>>>>>> can see, they do not work without the bios at all, so it's
>>>>>>>>>>>>>> also not possible
>>>>>>>>>>>>>> to use a Linux image with the "-kernel" CLI option directly).
>>>>>>>>>>>>>
>>>>>>>>>>>>> It is at least in theory possible to run bare-metal code on
>>>>>>>>>>>>> either board, by passing either a pflash or a bios argument.
>>>>>>>>>>>>
>>>>>>>>>>>> True. I did some more research, and seems like there was once
>>>>>>>>>>>> support for those boards in u-boot, but it got removed there a
>>>>>>>>>>>> couple of years ago already:
>>>>>>>>>>>>
>>>>>>>>>>>> https://gitlab.com/qemu-project/u-boot/-/commit/98f705c9cefdf
>>>>>>>>>>>>
>>>>>>>>>>>> https://gitlab.com/qemu-project/u-boot/-/commit/b147ff2f37d5b
>>>>>>>>>>>>
>>>>>>>>>>>> https://gitlab.com/qemu-project/u-boot/-/commit/7514037bcdc37
>>>>>>>>>>>>
>>>>>>>>>>>>> But I agree that there seem to be no signs of anybody actually
>>>>>>>>>>>>> successfully using these boards for anything, so we should
>>>>>>>>>>>>> deprecate-and-delete them.
>>>>>>>>>>>>
>>>>>>>>>>>> Yes, let's mark them as deprecated now ... if someone still 
>>>>>>>>>>>> uses
>>>>>>>>>>>> them and speaks up, we can still revert the deprecation again.
>>>>>>>>>>>
>>>>>>>>>>> I really would like to be able to use them to validate Linux 
>>>>>>>>>>> Kernel
>>>>>>>>>>> changes, hence looking for that missing BIOS.
>>>>>>>>>>>
>>>>>>>>>>> If we remove ppc405 from QEMU, we won't be able to do any
>>>>>>>>>>> regression
>>>>>>>>>>> tests of Linux Kernel on those processors.
>>>>>>>>>>
>>>>>>>>>> If you/someone managed to compile an old version of u-boot for
>>>>>>>>>> one of these
>>>>>>>>>> two boards, so that we would finally have something for
>>>>>>>>>> regression testing,
>>>>>>>>>> we can of course also keep the boards in QEMU...
>>>>>>>>>
>>>>>>>>> I can see that it would be usefor for some cases, but unless 
>>>>>>>>> someone
>>>>>>>>> volunteers to track down the necessary firmware and look after 
>>>>>>>>> it, I
>>>>>>>>> think we do need to deprecate it - I certainly don't have the
>>>>>>>>> capacity
>>>>>>>>> to look into this.
>>>>>>>>>
>>>>>>>>
>>>>>>>> I will look at it, please allow me a few weeks though.
>>>>>>>
>>>>>>> Well, building it was not hard but now I'd like to know what board
>>>>>>> QEMU actually emulates, there are way too many codenames and PVRs.
>>>>>>
>>>>>> yes. We should try to reduce the list below. Deprecating embedded
>>>>>> machines
>>>>>> is one way.
>>>>>
>>>>> Why should we reduce that list? It's good to have different cpu
>>>>> options when one wants to test code for different PPC versions (maybe
>>>>> also in user mode) or just to have a quick list of these at one place.
>>>>
>>>> I think there are many CPUs in that list which cannot be used with any
>>>> board, some of them might be also in a very incomplete state. So
>>>> presenting such a big list to the users is confusing and might create
>>>> wrong expectations. It would be good to remove at least the CPUs which
>>>> are really completely useless.
>>>
>>> Maybe only remove some from system emulation but keep all of them
>>> in user emulation?
>>
>> Or keep them all but mark those that are not tested/may be incomplete? 
>> So the used can see what is expected to work and what may need to be 
>> fixed. That way somebody may try and fix it whereas if it's not there 
>> they are unlikely to try to add it.
> 
> 
> The bamboo machine with 440 CPUs is booting with the latest kernel
> and we have an acceptance test for it now, thanks to Thomas. There
> is not much effort in keeping them in a working state until someone
> volunteers. Hopefully, Christophe is making sure that we are not
> breaking anything with Linux support.
> 
> The 405 machine are still close to deprecation I think. We are still
> struggling to boot one with mainline Linux, using uboot provided by
> Thomas which skips SDRAM init. It is not clear to me if u-boot is
> strictly necessary. It depends if Linux relies on it to do some
> pre-initialization of HW. I guess once we find a good DTS for it, or
> not, we can take a decision.
> 

I now have a hacked configuration booting linux with the hotfoot DTS and 
the kernel is booting up to starting /init

Then it is faulting forever taking a DSI for write protection. The 
problem is now likely in Linux and I'm investigating it, but I'm having 
problem with GDB (7.8.1), I'm hitting the bug 
https://sourceware.org/bugzilla/show_bug.cgi?id=17700

And GDB 11.1 coredumps while reading vmlinux's symbols

Hopefully I'll find a GDB version between 7.8 and 11 that works.

Re: Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms)

[Simon Marchi]

On 2021-10-20 9:16 a.m., LEROY Christophe wrote:
> And GDB 11.1 coredumps while reading vmlinux's symbols
> 
> Hopefully I'll find a GDB version between 7.8 and 11 that works.

That's not cool.  Could you file a bug for it?  If you could share your
vmlinux executable (or steps to re-create it, with details about compiler
version and all), that would be very helpful.

Thanks,

Simon

Re: Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms)

[Christophe Leroy]

Le 20/10/2021 à 15:16, Christophe Leroy a écrit :
> 
> 
> Le 20/10/2021 à 14:43, Cédric Le Goater a écrit :
>> On 10/20/21 13:42, BALATON Zoltan wrote:
>>> On Wed, 20 Oct 2021, Philippe Mathieu-Daudé wrote:
>>>> On 10/5/21 14:29, Thomas Huth wrote:
>>>>> On 05/10/2021 14.20, BALATON Zoltan wrote:
>>>>>> On Tue, 5 Oct 2021, Cédric Le Goater wrote:
>>>>>>> On 10/5/21 08:18, Alexey Kardashevskiy wrote:
>>>>>>>> On 05/10/2021 15:44, Christophe Leroy wrote:
>>>>>>>>> Le 05/10/2021 à 02:48, David Gibson a écrit :
>>>>>>>>>> On Fri, Oct 01, 2021 at 04:18:49PM +0200, Thomas Huth wrote:
>>>>>>>>>>> On 01/10/2021 15.04, Christophe Leroy wrote:
>>>>>>>>>>>> Le 01/10/2021 à 14:04, Thomas Huth a écrit :
>>>>>>>>>>>>> On 01/10/2021 13.12, Peter Maydell wrote:
>>>>>>>>>>>>>> On Fri, 1 Oct 2021 at 10:43, Thomas Huth <thuth@redhat.com>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>> Nevertheless, as long as nobody has a hint where to find 
>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>> ppc405_rom.bin, I think both boards are pretty useless in
>>>>>>>>>>>>>>> QEMU (as far as I
>>>>>>>>>>>>>>> can see, they do not work without the bios at all, so it's
>>>>>>>>>>>>>>> also not possible
>>>>>>>>>>>>>>> to use a Linux image with the "-kernel" CLI option 
>>>>>>>>>>>>>>> directly).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> It is at least in theory possible to run bare-metal code on
>>>>>>>>>>>>>> either board, by passing either a pflash or a bios argument.
>>>>>>>>>>>>>
>>>>>>>>>>>>> True. I did some more research, and seems like there was once
>>>>>>>>>>>>> support for those boards in u-boot, but it got removed there a
>>>>>>>>>>>>> couple of years ago already:
>>>>>>>>>>>>>
>>>>>>>>>>>>> https://gitlab.com/qemu-project/u-boot/-/commit/98f705c9cefdf
>>>>>>>>>>>>>
>>>>>>>>>>>>> https://gitlab.com/qemu-project/u-boot/-/commit/b147ff2f37d5b
>>>>>>>>>>>>>
>>>>>>>>>>>>> https://gitlab.com/qemu-project/u-boot/-/commit/7514037bcdc37
>>>>>>>>>>>>>
>>>>>>>>>>>>>> But I agree that there seem to be no signs of anybody 
>>>>>>>>>>>>>> actually
>>>>>>>>>>>>>> successfully using these boards for anything, so we should
>>>>>>>>>>>>>> deprecate-and-delete them.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Yes, let's mark them as deprecated now ... if someone still 
>>>>>>>>>>>>> uses
>>>>>>>>>>>>> them and speaks up, we can still revert the deprecation again.
>>>>>>>>>>>>
>>>>>>>>>>>> I really would like to be able to use them to validate Linux 
>>>>>>>>>>>> Kernel
>>>>>>>>>>>> changes, hence looking for that missing BIOS.
>>>>>>>>>>>>
>>>>>>>>>>>> If we remove ppc405 from QEMU, we won't be able to do any
>>>>>>>>>>>> regression
>>>>>>>>>>>> tests of Linux Kernel on those processors.
>>>>>>>>>>>
>>>>>>>>>>> If you/someone managed to compile an old version of u-boot for
>>>>>>>>>>> one of these
>>>>>>>>>>> two boards, so that we would finally have something for
>>>>>>>>>>> regression testing,
>>>>>>>>>>> we can of course also keep the boards in QEMU...
>>>>>>>>>>
>>>>>>>>>> I can see that it would be usefor for some cases, but unless 
>>>>>>>>>> someone
>>>>>>>>>> volunteers to track down the necessary firmware and look after 
>>>>>>>>>> it, I
>>>>>>>>>> think we do need to deprecate it - I certainly don't have the
>>>>>>>>>> capacity
>>>>>>>>>> to look into this.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I will look at it, please allow me a few weeks though.
>>>>>>>>
>>>>>>>> Well, building it was not hard but now I'd like to know what board
>>>>>>>> QEMU actually emulates, there are way too many codenames and PVRs.
>>>>>>>
>>>>>>> yes. We should try to reduce the list below. Deprecating embedded
>>>>>>> machines
>>>>>>> is one way.
>>>>>>
>>>>>> Why should we reduce that list? It's good to have different cpu
>>>>>> options when one wants to test code for different PPC versions (maybe
>>>>>> also in user mode) or just to have a quick list of these at one 
>>>>>> place.
>>>>>
>>>>> I think there are many CPUs in that list which cannot be used with any
>>>>> board, some of them might be also in a very incomplete state. So
>>>>> presenting such a big list to the users is confusing and might create
>>>>> wrong expectations. It would be good to remove at least the CPUs which
>>>>> are really completely useless.
>>>>
>>>> Maybe only remove some from system emulation but keep all of them
>>>> in user emulation?
>>>
>>> Or keep them all but mark those that are not tested/may be 
>>> incomplete? So the used can see what is expected to work and what may 
>>> need to be fixed. That way somebody may try and fix it whereas if 
>>> it's not there they are unlikely to try to add it.
>>
>>
>> The bamboo machine with 440 CPUs is booting with the latest kernel
>> and we have an acceptance test for it now, thanks to Thomas. There
>> is not much effort in keeping them in a working state until someone
>> volunteers. Hopefully, Christophe is making sure that we are not
>> breaking anything with Linux support.
>>
>> The 405 machine are still close to deprecation I think. We are still
>> struggling to boot one with mainline Linux, using uboot provided by
>> Thomas which skips SDRAM init. It is not clear to me if u-boot is
>> strictly necessary. It depends if Linux relies on it to do some
>> pre-initialization of HW. I guess once we find a good DTS for it, or
>> not, we can take a decision.
>>
> 
> I now have a hacked configuration booting linux with the hotfoot DTS and 
> the kernel is booting up to starting /init
> 
> Then it is faulting forever taking a DSI for write protection. The 
> problem is now likely in Linux and I'm investigating it, but I'm having 
> problem with GDB (7.8.1), I'm hitting the bug 
> https://sourceware.org/bugzilla/show_bug.cgi?id=17700
> 
> And GDB 11.1 coredumps while reading vmlinux's symbols
> 
> Hopefully I'll find a GDB version between 7.8 and 11 that works.

I bisected the issue to 
https://github.com/linuxppc/linux/commit/52ae92cc290f0506eef9ad5466bb453ce4a9e80e

The problem is in QEMU, it should ignore upper bits of PID register.

The following change fixes the issue, don't know it is it the right way 
to fix though

diff --git a/target/ppc/mmu_common.c b/target/ppc/mmu_common.c
index 754509e556..44f4fa5280 100644
--- a/target/ppc/mmu_common.c
+++ b/target/ppc/mmu_common.c
@@ -570,7 +570,7 @@ static int mmu40x_get_physical_address(CPUPPCState 
*env, mmu_ctx_t *ctx,
      for (i = 0; i < env->nb_tlb; i++) {
          tlb = &env->tlb.tlbe[i];
          if (ppcemb_tlb_check(env, tlb, &raddr, address,
-                             env->spr[SPR_40x_PID], 0, i) < 0) {
+                             env->spr[SPR_40x_PID] & 0xff, 0, i) < 0) {
              continue;
          }
          zsel = (tlb->attr >> 4) & 0xF;
diff --git a/target/ppc/mmu_helper.c b/target/ppc/mmu_helper.c
index 2cb98c5169..9331830f34 100644
--- a/target/ppc/mmu_helper.c
+++ b/target/ppc/mmu_helper.c
@@ -789,7 +789,7 @@ void helper_4xx_tlbwe_hi(CPUPPCState *env, 
target_ulong entry,
      } else {
          tlb->prot &= ~PAGE_VALID;
      }
-    tlb->PID = env->spr[SPR_40x_PID]; /* PID */
+    tlb->PID = env->spr[SPR_40x_PID] & 0xff; /* PID */
      LOG_SWTLB("%s: set up TLB %d RPN " TARGET_FMT_plx " EPN " 
TARGET_FMT_lx
                " size " TARGET_FMT_lx " prot %c%c%c%c PID %d\n", __func__,
                (int)entry, tlb->RPN, tlb->EPN, tlb->size,
@@ -837,7 +837,7 @@ void helper_4xx_tlbwe_lo(CPUPPCState *env, 
target_ulong entry,

  target_ulong helper_4xx_tlbsx(CPUPPCState *env, target_ulong address)
  {
-    return ppcemb_tlb_search(env, address, env->spr[SPR_40x_PID]);
+    return ppcemb_tlb_search(env, address, env->spr[SPR_40x_PID] & 0xff);
  }

  /* PowerPC 440 TLB management */
---

Christophe

Re: Deprecate the ppc405 boards in QEMU?

[Thomas Huth]

On 21/10/2021 08.48, Christophe Leroy wrote:
> 
> 
> Le 20/10/2021 à 15:16, Christophe Leroy a écrit :
>>
>>
>> Le 20/10/2021 à 14:43, Cédric Le Goater a écrit :
>>> On 10/20/21 13:42, BALATON Zoltan wrote:
>>>> On Wed, 20 Oct 2021, Philippe Mathieu-Daudé wrote:
>>>>> On 10/5/21 14:29, Thomas Huth wrote:
>>>>>> On 05/10/2021 14.20, BALATON Zoltan wrote:
>>>>>>> On Tue, 5 Oct 2021, Cédric Le Goater wrote:
>>>>>>>> On 10/5/21 08:18, Alexey Kardashevskiy wrote:
>>>>>>>>> On 05/10/2021 15:44, Christophe Leroy wrote:
>>>>>>>>>> Le 05/10/2021 à 02:48, David Gibson a écrit :
>>>>>>>>>>> On Fri, Oct 01, 2021 at 04:18:49PM +0200, Thomas Huth wrote:
>>>>>>>>>>>> On 01/10/2021 15.04, Christophe Leroy wrote:
>>>>>>>>>>>>> Le 01/10/2021 à 14:04, Thomas Huth a écrit :
>>>>>>>>>>>>>> On 01/10/2021 13.12, Peter Maydell wrote:
>>>>>>>>>>>>>>> On Fri, 1 Oct 2021 at 10:43, Thomas Huth <thuth@redhat.com>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>> Nevertheless, as long as nobody has a hint where to find that
>>>>>>>>>>>>>>>> ppc405_rom.bin, I think both boards are pretty useless in
>>>>>>>>>>>>>>>> QEMU (as far as I
>>>>>>>>>>>>>>>> can see, they do not work without the bios at all, so it's
>>>>>>>>>>>>>>>> also not possible
>>>>>>>>>>>>>>>> to use a Linux image with the "-kernel" CLI option directly).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It is at least in theory possible to run bare-metal code on
>>>>>>>>>>>>>>> either board, by passing either a pflash or a bios argument.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> True. I did some more research, and seems like there was once
>>>>>>>>>>>>>> support for those boards in u-boot, but it got removed there a
>>>>>>>>>>>>>> couple of years ago already:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> https://gitlab.com/qemu-project/u-boot/-/commit/98f705c9cefdf
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> https://gitlab.com/qemu-project/u-boot/-/commit/b147ff2f37d5b
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> https://gitlab.com/qemu-project/u-boot/-/commit/7514037bcdc37
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> But I agree that there seem to be no signs of anybody actually
>>>>>>>>>>>>>>> successfully using these boards for anything, so we should
>>>>>>>>>>>>>>> deprecate-and-delete them.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Yes, let's mark them as deprecated now ... if someone still uses
>>>>>>>>>>>>>> them and speaks up, we can still revert the deprecation again.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I really would like to be able to use them to validate Linux 
>>>>>>>>>>>>> Kernel
>>>>>>>>>>>>> changes, hence looking for that missing BIOS.
>>>>>>>>>>>>>
>>>>>>>>>>>>> If we remove ppc405 from QEMU, we won't be able to do any
>>>>>>>>>>>>> regression
>>>>>>>>>>>>> tests of Linux Kernel on those processors.
>>>>>>>>>>>>
>>>>>>>>>>>> If you/someone managed to compile an old version of u-boot for
>>>>>>>>>>>> one of these
>>>>>>>>>>>> two boards, so that we would finally have something for
>>>>>>>>>>>> regression testing,
>>>>>>>>>>>> we can of course also keep the boards in QEMU...
>>>>>>>>>>>
>>>>>>>>>>> I can see that it would be usefor for some cases, but unless someone
>>>>>>>>>>> volunteers to track down the necessary firmware and look after it, I
>>>>>>>>>>> think we do need to deprecate it - I certainly don't have the
>>>>>>>>>>> capacity
>>>>>>>>>>> to look into this.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I will look at it, please allow me a few weeks though.
>>>>>>>>>
>>>>>>>>> Well, building it was not hard but now I'd like to know what board
>>>>>>>>> QEMU actually emulates, there are way too many codenames and PVRs.
>>>>>>>>
>>>>>>>> yes. We should try to reduce the list below. Deprecating embedded
>>>>>>>> machines
>>>>>>>> is one way.
>>>>>>>
>>>>>>> Why should we reduce that list? It's good to have different cpu
>>>>>>> options when one wants to test code for different PPC versions (maybe
>>>>>>> also in user mode) or just to have a quick list of these at one place.
>>>>>>
>>>>>> I think there are many CPUs in that list which cannot be used with any
>>>>>> board, some of them might be also in a very incomplete state. So
>>>>>> presenting such a big list to the users is confusing and might create
>>>>>> wrong expectations. It would be good to remove at least the CPUs which
>>>>>> are really completely useless.
>>>>>
>>>>> Maybe only remove some from system emulation but keep all of them
>>>>> in user emulation?
>>>>
>>>> Or keep them all but mark those that are not tested/may be incomplete? 
>>>> So the used can see what is expected to work and what may need to be 
>>>> fixed. That way somebody may try and fix it whereas if it's not there 
>>>> they are unlikely to try to add it.
>>>
>>>
>>> The bamboo machine with 440 CPUs is booting with the latest kernel
>>> and we have an acceptance test for it now, thanks to Thomas. There
>>> is not much effort in keeping them in a working state until someone
>>> volunteers. Hopefully, Christophe is making sure that we are not
>>> breaking anything with Linux support.
>>>
>>> The 405 machine are still close to deprecation I think. We are still
>>> struggling to boot one with mainline Linux, using uboot provided by
>>> Thomas which skips SDRAM init. It is not clear to me if u-boot is
>>> strictly necessary. It depends if Linux relies on it to do some
>>> pre-initialization of HW. I guess once we find a good DTS for it, or
>>> not, we can take a decision.
>>>
>>
>> I now have a hacked configuration booting linux with the hotfoot DTS and 
>> the kernel is booting up to starting /init
>>
>> Then it is faulting forever taking a DSI for write protection. The problem 
>> is now likely in Linux and I'm investigating it, but I'm having problem 
>> with GDB (7.8.1), I'm hitting the bug 
>> https://sourceware.org/bugzilla/show_bug.cgi?id=17700
>>
>> And GDB 11.1 coredumps while reading vmlinux's symbols
>>
>> Hopefully I'll find a GDB version between 7.8 and 11 that works.
> 
> I bisected the issue to 
> https://github.com/linuxppc/linux/commit/52ae92cc290f0506eef9ad5466bb453ce4a9e80e 

You could argue that this commit introduced a bug, or at least a bad 
behavior in the kernel: According to the 405 user's manual that I have:

  10.2 Reserved Fields
  For all registers having fields marked as reserved, the reserved
  fields should be written as zero and read as undefined. That is,
  when writing to a reseved field, write a 0 to the field. When
  reading from a reserved field, ignore the field.

Thus the kernel should not write non-zero bits into the upper bits of this 
register.

> The problem is in QEMU, it should ignore upper bits of PID register.

Agreed, that's certainly necessary, too.

> The following change fixes the issue, don't know it is it the right way to 
> fix though
> 
> diff --git a/target/ppc/mmu_common.c b/target/ppc/mmu_common.c
> index 754509e556..44f4fa5280 100644
> --- a/target/ppc/mmu_common.c
> +++ b/target/ppc/mmu_common.c
> @@ -570,7 +570,7 @@ static int mmu40x_get_physical_address(CPUPPCState *env, 
> mmu_ctx_t *ctx,
>       for (i = 0; i < env->nb_tlb; i++) {
>           tlb = &env->tlb.tlbe[i];
>           if (ppcemb_tlb_check(env, tlb, &raddr, address,
> -                             env->spr[SPR_40x_PID], 0, i) < 0) {
> +                             env->spr[SPR_40x_PID] & 0xff, 0, i) < 0) {
>               continue;
>           }
>           zsel = (tlb->attr >> 4) & 0xF;
> diff --git a/target/ppc/mmu_helper.c b/target/ppc/mmu_helper.c
> index 2cb98c5169..9331830f34 100644
> --- a/target/ppc/mmu_helper.c
> +++ b/target/ppc/mmu_helper.c
> @@ -789,7 +789,7 @@ void helper_4xx_tlbwe_hi(CPUPPCState *env, target_ulong 
> entry,
>       } else {
>           tlb->prot &= ~PAGE_VALID;
>       }
> -    tlb->PID = env->spr[SPR_40x_PID]; /* PID */
> +    tlb->PID = env->spr[SPR_40x_PID] & 0xff; /* PID */
>       LOG_SWTLB("%s: set up TLB %d RPN " TARGET_FMT_plx " EPN " TARGET_FMT_lx
>                 " size " TARGET_FMT_lx " prot %c%c%c%c PID %d\n", __func__,
>                 (int)entry, tlb->RPN, tlb->EPN, tlb->size,
> @@ -837,7 +837,7 @@ void helper_4xx_tlbwe_lo(CPUPPCState *env, target_ulong 
> entry,
> 
>   target_ulong helper_4xx_tlbsx(CPUPPCState *env, target_ulong address)
>   {
> -    return ppcemb_tlb_search(env, address, env->spr[SPR_40x_PID]);
> +    return ppcemb_tlb_search(env, address, env->spr[SPR_40x_PID] & 0xff);
>   }

The modications looks sane to me, could you please send this as a proper 
patch (with Signed-off-by line) to the mailing list?

Alternatively, it might be possible to do the masking only once in 
helper_booke_setpid() in mmu_helper.c:

void helper_booke_setpid(CPUPPCState *env, uint32_t pidn, target_ulong pid)
{
     if (pid == SPR_40x_PID) {
         pid &= 0xff;
     }
     env->spr[pidn] = pid;
     /* changing PIDs mean we're in a different address space now */
     tlb_flush(env_cpu(env));
}

... not sure whether that is the better approach here, though ... it maybe 
depends whether the reserved bits read back as zeros on a real 405 or not...

  Thomas

Re: Deprecate the ppc405 boards in QEMU?

[Christophe Leroy]

Le 21/10/2021 à 09:25, Thomas Huth a écrit :
> On 21/10/2021 08.48, Christophe Leroy wrote:
>>
>>
>> Le 20/10/2021 à 15:16, Christophe Leroy a écrit :
>>>
>>>
>>> Le 20/10/2021 à 14:43, Cédric Le Goater a écrit :
>>>> On 10/20/21 13:42, BALATON Zoltan wrote:
>>>>> On Wed, 20 Oct 2021, Philippe Mathieu-Daudé wrote:
>>>>>> On 10/5/21 14:29, Thomas Huth wrote:
>>>>>>> On 05/10/2021 14.20, BALATON Zoltan wrote:
>>>>>>>> On Tue, 5 Oct 2021, Cédric Le Goater wrote:
>>>>>>>>> On 10/5/21 08:18, Alexey Kardashevskiy wrote:
>>>>>>>>>> On 05/10/2021 15:44, Christophe Leroy wrote:
>>>>>>>>>>> Le 05/10/2021 à 02:48, David Gibson a écrit :
>>>>>>>>>>>> On Fri, Oct 01, 2021 at 04:18:49PM +0200, Thomas Huth wrote:
>>>>>>>>>>>>> On 01/10/2021 15.04, Christophe Leroy wrote:
>>>>>>>>>>>>>> Le 01/10/2021 à 14:04, Thomas Huth a écrit :
>>>>>>>>>>>>>>> On 01/10/2021 13.12, Peter Maydell wrote:
>>>>>>>>>>>>>>>> On Fri, 1 Oct 2021 at 10:43, Thomas Huth <thuth@redhat.com>
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>> Nevertheless, as long as nobody has a hint where to 
>>>>>>>>>>>>>>>>> find that
>>>>>>>>>>>>>>>>> ppc405_rom.bin, I think both boards are pretty useless in
>>>>>>>>>>>>>>>>> QEMU (as far as I
>>>>>>>>>>>>>>>>> can see, they do not work without the bios at all, so it's
>>>>>>>>>>>>>>>>> also not possible
>>>>>>>>>>>>>>>>> to use a Linux image with the "-kernel" CLI option 
>>>>>>>>>>>>>>>>> directly).
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> It is at least in theory possible to run bare-metal code on
>>>>>>>>>>>>>>>> either board, by passing either a pflash or a bios 
>>>>>>>>>>>>>>>> argument.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> True. I did some more research, and seems like there was 
>>>>>>>>>>>>>>> once
>>>>>>>>>>>>>>> support for those boards in u-boot, but it got removed 
>>>>>>>>>>>>>>> there a
>>>>>>>>>>>>>>> couple of years ago already:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> https://gitlab.com/qemu-project/u-boot/-/commit/98f705c9cefdf 
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> https://gitlab.com/qemu-project/u-boot/-/commit/b147ff2f37d5b 
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> https://gitlab.com/qemu-project/u-boot/-/commit/7514037bcdc37 
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> But I agree that there seem to be no signs of anybody 
>>>>>>>>>>>>>>>> actually
>>>>>>>>>>>>>>>> successfully using these boards for anything, so we should
>>>>>>>>>>>>>>>> deprecate-and-delete them.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Yes, let's mark them as deprecated now ... if someone 
>>>>>>>>>>>>>>> still uses
>>>>>>>>>>>>>>> them and speaks up, we can still revert the deprecation 
>>>>>>>>>>>>>>> again.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I really would like to be able to use them to validate 
>>>>>>>>>>>>>> Linux Kernel
>>>>>>>>>>>>>> changes, hence looking for that missing BIOS.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> If we remove ppc405 from QEMU, we won't be able to do any
>>>>>>>>>>>>>> regression
>>>>>>>>>>>>>> tests of Linux Kernel on those processors.
>>>>>>>>>>>>>
>>>>>>>>>>>>> If you/someone managed to compile an old version of u-boot for
>>>>>>>>>>>>> one of these
>>>>>>>>>>>>> two boards, so that we would finally have something for
>>>>>>>>>>>>> regression testing,
>>>>>>>>>>>>> we can of course also keep the boards in QEMU...
>>>>>>>>>>>>
>>>>>>>>>>>> I can see that it would be usefor for some cases, but unless 
>>>>>>>>>>>> someone
>>>>>>>>>>>> volunteers to track down the necessary firmware and look 
>>>>>>>>>>>> after it, I
>>>>>>>>>>>> think we do need to deprecate it - I certainly don't have the
>>>>>>>>>>>> capacity
>>>>>>>>>>>> to look into this.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I will look at it, please allow me a few weeks though.
>>>>>>>>>>
>>>>>>>>>> Well, building it was not hard but now I'd like to know what 
>>>>>>>>>> board
>>>>>>>>>> QEMU actually emulates, there are way too many codenames and 
>>>>>>>>>> PVRs.
>>>>>>>>>
>>>>>>>>> yes. We should try to reduce the list below. Deprecating embedded
>>>>>>>>> machines
>>>>>>>>> is one way.
>>>>>>>>
>>>>>>>> Why should we reduce that list? It's good to have different cpu
>>>>>>>> options when one wants to test code for different PPC versions 
>>>>>>>> (maybe
>>>>>>>> also in user mode) or just to have a quick list of these at one 
>>>>>>>> place.
>>>>>>>
>>>>>>> I think there are many CPUs in that list which cannot be used 
>>>>>>> with any
>>>>>>> board, some of them might be also in a very incomplete state. So
>>>>>>> presenting such a big list to the users is confusing and might 
>>>>>>> create
>>>>>>> wrong expectations. It would be good to remove at least the CPUs 
>>>>>>> which
>>>>>>> are really completely useless.
>>>>>>
>>>>>> Maybe only remove some from system emulation but keep all of them
>>>>>> in user emulation?
>>>>>
>>>>> Or keep them all but mark those that are not tested/may be 
>>>>> incomplete? So the used can see what is expected to work and what 
>>>>> may need to be fixed. That way somebody may try and fix it whereas 
>>>>> if it's not there they are unlikely to try to add it.
>>>>
>>>>
>>>> The bamboo machine with 440 CPUs is booting with the latest kernel
>>>> and we have an acceptance test for it now, thanks to Thomas. There
>>>> is not much effort in keeping them in a working state until someone
>>>> volunteers. Hopefully, Christophe is making sure that we are not
>>>> breaking anything with Linux support.
>>>>
>>>> The 405 machine are still close to deprecation I think. We are still
>>>> struggling to boot one with mainline Linux, using uboot provided by
>>>> Thomas which skips SDRAM init. It is not clear to me if u-boot is
>>>> strictly necessary. It depends if Linux relies on it to do some
>>>> pre-initialization of HW. I guess once we find a good DTS for it, or
>>>> not, we can take a decision.
>>>>
>>>
>>> I now have a hacked configuration booting linux with the hotfoot DTS 
>>> and the kernel is booting up to starting /init
>>>
>>> Then it is faulting forever taking a DSI for write protection. The 
>>> problem is now likely in Linux and I'm investigating it, but I'm 
>>> having problem with GDB (7.8.1), I'm hitting the bug 
>>> https://sourceware.org/bugzilla/show_bug.cgi?id=17700
>>>
>>> And GDB 11.1 coredumps while reading vmlinux's symbols
>>>
>>> Hopefully I'll find a GDB version between 7.8 and 11 that works.
>>
>> I bisected the issue to 
>> https://github.com/linuxppc/linux/commit/52ae92cc290f0506eef9ad5466bb453ce4a9e80e 
> 
> 
> You could argue that this commit introduced a bug, or at least a bad 
> behavior in the kernel: According to the 405 user's manual that I have:
> 
>   10.2 Reserved Fields
>   For all registers having fields marked as reserved, the reserved
>   fields should be written as zero and read as undefined. That is,
>   when writing to a reseved field, write a 0 to the field. When
>   reading from a reserved field, ignore the field.
> 
> Thus the kernel should not write non-zero bits into the upper bits of 
> this register.

Yes, SHOULD, not SHALL ...


The following changes fixes the issue in the kernel though:

diff --git a/arch/powerpc/kernel/head_40x.S b/arch/powerpc/kernel/head_40x.S
index 618d7f3f9c95..bcde7e284bfa 100644
--- a/arch/powerpc/kernel/head_40x.S
+++ b/arch/powerpc/kernel/head_40x.S
@@ -317,8 +317,9 @@ _ENTRY(saved_ksp_limit)
  	/* The bailout.  Restore registers to pre-exception conditions
  	 * and call the heavyweights to help us out.
  	 */
-	mtspr	SPRN_PID, r12
  	mtcrf	0x80, r12
+	rlwinm	r12, r12, 0, 0xff
+	mtspr	SPRN_PID, r12
  	mfspr	r9, SPRN_SPRG_SCRATCH4
  	mfspr	r12, SPRN_SPRG_SCRATCH3
  	mfspr	r11, SPRN_SPRG_SCRATCH6
@@ -397,8 +398,9 @@ _ENTRY(saved_ksp_limit)
  	/* The bailout.  Restore registers to pre-exception conditions
  	 * and call the heavyweights to help us out.
  	 */
-	mtspr	SPRN_PID, r12
  	mtcrf	0x80, r12
+	rlwinm	r12, r12, 0, 0xff
+	mtspr	SPRN_PID, r12
  	mfspr	r9, SPRN_SPRG_SCRATCH4
  	mfspr	r12, SPRN_SPRG_SCRATCH3
  	mfspr	r11, SPRN_SPRG_SCRATCH6
@@ -542,8 +544,9 @@ finish_tlb_load:

  	/* Done...restore registers and get out of here.
  	*/
-	mtspr	SPRN_PID, r12
  	mtcrf	0x80, r12
+	rlwinm	r12, r12, 0, 0xff
+	mtspr	SPRN_PID, r12
  	mfspr	r9, SPRN_SPRG_SCRATCH4
  	mfspr	r12, SPRN_SPRG_SCRATCH3
  	mfspr	r11, SPRN_SPRG_SCRATCH6


> 
>> The problem is in QEMU, it should ignore upper bits of PID register.
> 
> Agreed, that's certainly necessary, too.

Yes it seems clear in 405 user's manual chapter 7 Memory Management, 
especially in all drawings, that only bits 24:31 are taken into account 
from PID register.


Christophe

Re: Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms)

[Luis Machado]

On 10/20/21 10:16 AM, LEROY Christophe wrote:
> 
> 
> Le 20/10/2021 à 14:43, Cédric Le Goater a écrit :
>> On 10/20/21 13:42, BALATON Zoltan wrote:
>>> On Wed, 20 Oct 2021, Philippe Mathieu-Daudé wrote:
>>>> On 10/5/21 14:29, Thomas Huth wrote:
>>>>> On 05/10/2021 14.20, BALATON Zoltan wrote:
>>>>>> On Tue, 5 Oct 2021, Cédric Le Goater wrote:
>>>>>>> On 10/5/21 08:18, Alexey Kardashevskiy wrote:
>>>>>>>> On 05/10/2021 15:44, Christophe Leroy wrote:
>>>>>>>>> Le 05/10/2021 à 02:48, David Gibson a écrit :
>>>>>>>>>> On Fri, Oct 01, 2021 at 04:18:49PM +0200, Thomas Huth wrote:
>>>>>>>>>>> On 01/10/2021 15.04, Christophe Leroy wrote:
>>>>>>>>>>>> Le 01/10/2021 à 14:04, Thomas Huth a écrit :
>>>>>>>>>>>>> On 01/10/2021 13.12, Peter Maydell wrote:
>>>>>>>>>>>>>> On Fri, 1 Oct 2021 at 10:43, Thomas Huth <thuth@redhat.com>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>> Nevertheless, as long as nobody has a hint where to find that
>>>>>>>>>>>>>>> ppc405_rom.bin, I think both boards are pretty useless in
>>>>>>>>>>>>>>> QEMU (as far as I
>>>>>>>>>>>>>>> can see, they do not work without the bios at all, so it's
>>>>>>>>>>>>>>> also not possible
>>>>>>>>>>>>>>> to use a Linux image with the "-kernel" CLI option directly).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> It is at least in theory possible to run bare-metal code on
>>>>>>>>>>>>>> either board, by passing either a pflash or a bios argument.
>>>>>>>>>>>>>
>>>>>>>>>>>>> True. I did some more research, and seems like there was once
>>>>>>>>>>>>> support for those boards in u-boot, but it got removed there a
>>>>>>>>>>>>> couple of years ago already:
>>>>>>>>>>>>>
>>>>>>>>>>>>> https://gitlab.com/qemu-project/u-boot/-/commit/98f705c9cefdf
>>>>>>>>>>>>>
>>>>>>>>>>>>> https://gitlab.com/qemu-project/u-boot/-/commit/b147ff2f37d5b
>>>>>>>>>>>>>
>>>>>>>>>>>>> https://gitlab.com/qemu-project/u-boot/-/commit/7514037bcdc37
>>>>>>>>>>>>>
>>>>>>>>>>>>>> But I agree that there seem to be no signs of anybody actually
>>>>>>>>>>>>>> successfully using these boards for anything, so we should
>>>>>>>>>>>>>> deprecate-and-delete them.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Yes, let's mark them as deprecated now ... if someone still
>>>>>>>>>>>>> uses
>>>>>>>>>>>>> them and speaks up, we can still revert the deprecation again.
>>>>>>>>>>>>
>>>>>>>>>>>> I really would like to be able to use them to validate Linux
>>>>>>>>>>>> Kernel
>>>>>>>>>>>> changes, hence looking for that missing BIOS.
>>>>>>>>>>>>
>>>>>>>>>>>> If we remove ppc405 from QEMU, we won't be able to do any
>>>>>>>>>>>> regression
>>>>>>>>>>>> tests of Linux Kernel on those processors.
>>>>>>>>>>>
>>>>>>>>>>> If you/someone managed to compile an old version of u-boot for
>>>>>>>>>>> one of these
>>>>>>>>>>> two boards, so that we would finally have something for
>>>>>>>>>>> regression testing,
>>>>>>>>>>> we can of course also keep the boards in QEMU...
>>>>>>>>>>
>>>>>>>>>> I can see that it would be usefor for some cases, but unless
>>>>>>>>>> someone
>>>>>>>>>> volunteers to track down the necessary firmware and look after
>>>>>>>>>> it, I
>>>>>>>>>> think we do need to deprecate it - I certainly don't have the
>>>>>>>>>> capacity
>>>>>>>>>> to look into this.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I will look at it, please allow me a few weeks though.
>>>>>>>>
>>>>>>>> Well, building it was not hard but now I'd like to know what board
>>>>>>>> QEMU actually emulates, there are way too many codenames and PVRs.
>>>>>>>
>>>>>>> yes. We should try to reduce the list below. Deprecating embedded
>>>>>>> machines
>>>>>>> is one way.
>>>>>>
>>>>>> Why should we reduce that list? It's good to have different cpu
>>>>>> options when one wants to test code for different PPC versions (maybe
>>>>>> also in user mode) or just to have a quick list of these at one place.
>>>>>
>>>>> I think there are many CPUs in that list which cannot be used with any
>>>>> board, some of them might be also in a very incomplete state. So
>>>>> presenting such a big list to the users is confusing and might create
>>>>> wrong expectations. It would be good to remove at least the CPUs which
>>>>> are really completely useless.
>>>>
>>>> Maybe only remove some from system emulation but keep all of them
>>>> in user emulation?
>>>
>>> Or keep them all but mark those that are not tested/may be incomplete?
>>> So the used can see what is expected to work and what may need to be
>>> fixed. That way somebody may try and fix it whereas if it's not there
>>> they are unlikely to try to add it.
>>
>>
>> The bamboo machine with 440 CPUs is booting with the latest kernel
>> and we have an acceptance test for it now, thanks to Thomas. There
>> is not much effort in keeping them in a working state until someone
>> volunteers. Hopefully, Christophe is making sure that we are not
>> breaking anything with Linux support.
>>
>> The 405 machine are still close to deprecation I think. We are still
>> struggling to boot one with mainline Linux, using uboot provided by
>> Thomas which skips SDRAM init. It is not clear to me if u-boot is
>> strictly necessary. It depends if Linux relies on it to do some
>> pre-initialization of HW. I guess once we find a good DTS for it, or
>> not, we can take a decision.
>>
> 
> I now have a hacked configuration booting linux with the hotfoot DTS and
> the kernel is booting up to starting /init
> 
> Then it is faulting forever taking a DSI for write protection. The
> problem is now likely in Linux and I'm investigating it, but I'm having
> problem with GDB (7.8.1), I'm hitting the bug
> https://sourceware.org/bugzilla/show_bug.cgi?id=17700
> 
> And GDB 11.1 coredumps while reading vmlinux's symbols
> 
> Hopefully I'll find a GDB version between 7.8 and 11 that works.
> 

Just to confirm, you're not really having problems with the ARM port of 
GDB, right? It is a 32-bit PowerPC one. The bug you pointed out is only 
a reference to a similar one for PowerPC?

Re: Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms)

[Christophe Leroy]

Le 28/10/2021 à 14:24, Luis Machado a écrit :
> 
> 
> On 10/20/21 10:16 AM, LEROY Christophe wrote:
>>
>>
>> Le 20/10/2021 à 14:43, Cédric Le Goater a écrit :
>>> On 10/20/21 13:42, BALATON Zoltan wrote:
>>>> On Wed, 20 Oct 2021, Philippe Mathieu-Daudé wrote:
>>>>> On 10/5/21 14:29, Thomas Huth wrote:
>>>>>> On 05/10/2021 14.20, BALATON Zoltan wrote:
>>>>>>> On Tue, 5 Oct 2021, Cédric Le Goater wrote:
>>>>>>>> On 10/5/21 08:18, Alexey Kardashevskiy wrote:
>>>>>>>>> On 05/10/2021 15:44, Christophe Leroy wrote:
>>>>>>>>>> Le 05/10/2021 à 02:48, David Gibson a écrit :
>>>>>>>>>>> On Fri, Oct 01, 2021 at 04:18:49PM +0200, Thomas Huth wrote:
>>>>>>>>>>>> On 01/10/2021 15.04, Christophe Leroy wrote:
>>>>>>>>>>>>> Le 01/10/2021 à 14:04, Thomas Huth a écrit :
>>>>>>>>>>>>>> On 01/10/2021 13.12, Peter Maydell wrote:
>>>>>>>>>>>>>>> On Fri, 1 Oct 2021 at 10:43, Thomas Huth <thuth@redhat.com>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>> Nevertheless, as long as nobody has a hint where to find 
>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>> ppc405_rom.bin, I think both boards are pretty useless in
>>>>>>>>>>>>>>>> QEMU (as far as I
>>>>>>>>>>>>>>>> can see, they do not work without the bios at all, so it's
>>>>>>>>>>>>>>>> also not possible
>>>>>>>>>>>>>>>> to use a Linux image with the "-kernel" CLI option 
>>>>>>>>>>>>>>>> directly).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It is at least in theory possible to run bare-metal code on
>>>>>>>>>>>>>>> either board, by passing either a pflash or a bios argument.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> True. I did some more research, and seems like there was once
>>>>>>>>>>>>>> support for those boards in u-boot, but it got removed 
>>>>>>>>>>>>>> there a
>>>>>>>>>>>>>> couple of years ago already:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> https://gitlab.com/qemu-project/u-boot/-/commit/98f705c9cefdf
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> https://gitlab.com/qemu-project/u-boot/-/commit/b147ff2f37d5b
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> https://gitlab.com/qemu-project/u-boot/-/commit/7514037bcdc37
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> But I agree that there seem to be no signs of anybody 
>>>>>>>>>>>>>>> actually
>>>>>>>>>>>>>>> successfully using these boards for anything, so we should
>>>>>>>>>>>>>>> deprecate-and-delete them.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Yes, let's mark them as deprecated now ... if someone still
>>>>>>>>>>>>>> uses
>>>>>>>>>>>>>> them and speaks up, we can still revert the deprecation 
>>>>>>>>>>>>>> again.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I really would like to be able to use them to validate Linux
>>>>>>>>>>>>> Kernel
>>>>>>>>>>>>> changes, hence looking for that missing BIOS.
>>>>>>>>>>>>>
>>>>>>>>>>>>> If we remove ppc405 from QEMU, we won't be able to do any
>>>>>>>>>>>>> regression
>>>>>>>>>>>>> tests of Linux Kernel on those processors.
>>>>>>>>>>>>
>>>>>>>>>>>> If you/someone managed to compile an old version of u-boot for
>>>>>>>>>>>> one of these
>>>>>>>>>>>> two boards, so that we would finally have something for
>>>>>>>>>>>> regression testing,
>>>>>>>>>>>> we can of course also keep the boards in QEMU...
>>>>>>>>>>>
>>>>>>>>>>> I can see that it would be usefor for some cases, but unless
>>>>>>>>>>> someone
>>>>>>>>>>> volunteers to track down the necessary firmware and look after
>>>>>>>>>>> it, I
>>>>>>>>>>> think we do need to deprecate it - I certainly don't have the
>>>>>>>>>>> capacity
>>>>>>>>>>> to look into this.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I will look at it, please allow me a few weeks though.
>>>>>>>>>
>>>>>>>>> Well, building it was not hard but now I'd like to know what board
>>>>>>>>> QEMU actually emulates, there are way too many codenames and PVRs.
>>>>>>>>
>>>>>>>> yes. We should try to reduce the list below. Deprecating embedded
>>>>>>>> machines
>>>>>>>> is one way.
>>>>>>>
>>>>>>> Why should we reduce that list? It's good to have different cpu
>>>>>>> options when one wants to test code for different PPC versions 
>>>>>>> (maybe
>>>>>>> also in user mode) or just to have a quick list of these at one 
>>>>>>> place.
>>>>>>
>>>>>> I think there are many CPUs in that list which cannot be used with 
>>>>>> any
>>>>>> board, some of them might be also in a very incomplete state. So
>>>>>> presenting such a big list to the users is confusing and might create
>>>>>> wrong expectations. It would be good to remove at least the CPUs 
>>>>>> which
>>>>>> are really completely useless.
>>>>>
>>>>> Maybe only remove some from system emulation but keep all of them
>>>>> in user emulation?
>>>>
>>>> Or keep them all but mark those that are not tested/may be incomplete?
>>>> So the used can see what is expected to work and what may need to be
>>>> fixed. That way somebody may try and fix it whereas if it's not there
>>>> they are unlikely to try to add it.
>>>
>>>
>>> The bamboo machine with 440 CPUs is booting with the latest kernel
>>> and we have an acceptance test for it now, thanks to Thomas. There
>>> is not much effort in keeping them in a working state until someone
>>> volunteers. Hopefully, Christophe is making sure that we are not
>>> breaking anything with Linux support.
>>>
>>> The 405 machine are still close to deprecation I think. We are still
>>> struggling to boot one with mainline Linux, using uboot provided by
>>> Thomas which skips SDRAM init. It is not clear to me if u-boot is
>>> strictly necessary. It depends if Linux relies on it to do some
>>> pre-initialization of HW. I guess once we find a good DTS for it, or
>>> not, we can take a decision.
>>>
>>
>> I now have a hacked configuration booting linux with the hotfoot DTS and
>> the kernel is booting up to starting /init
>>
>> Then it is faulting forever taking a DSI for write protection. The
>> problem is now likely in Linux and I'm investigating it, but I'm having
>> problem with GDB (7.8.1), I'm hitting the bug
>> https://sourceware.org/bugzilla/show_bug.cgi?id=17700
>>
>> And GDB 11.1 coredumps while reading vmlinux's symbols
>>
>> Hopefully I'll find a GDB version between 7.8 and 11 that works.
>>
> 
> Just to confirm, you're not really having problems with the ARM port of 
> GDB, right? It is a 32-bit PowerPC one. The bug you pointed out is only 
> a reference to a similar one for PowerPC?

That's correct, saw the same problem on PowerPC.

I added a comment in bugzilla.

Christophe

Re: Deprecate the ppc405 boards in QEMU?

[Thomas Huth]

On 20/10/2021 14.43, Cédric Le Goater wrote:

> The 405 machine are still close to deprecation I think. We are still
> struggling to boot one with mainline Linux, using uboot provided by
> Thomas which skips SDRAM init. It is not clear to me if u-boot is
> strictly necessary. It depends if Linux relies on it to do some
> pre-initialization of HW. I guess once we find a good DTS for it, or
> not, we can take a decision.

FWIW, seems like this tarball contains a dts for a "taihushui" 405ep board:

https://dev.archive.openwrt.org/raw-attachment/ticket/4153/kolsch.tranzeo.openwrt.bsp.tar.bz2

... I wonder whether that's the same board as the "taihu" board in QEMU?

  Thomas

Re: Deprecate the ppc405 boards in QEMU?

[BALATON Zoltan]

[-- Attachment #1: Type: text/plain, Size: 1398 bytes --]

On Wed, 20 Oct 2021, Thomas Huth wrote:
> On 20/10/2021 14.43, Cédric Le Goater wrote:
>
>> The 405 machine are still close to deprecation I think. We are still
>> struggling to boot one with mainline Linux, using uboot provided by
>> Thomas which skips SDRAM init. It is not clear to me if u-boot is
>> strictly necessary. It depends if Linux relies on it to do some
>> pre-initialization of HW. I guess once we find a good DTS for it, or
>> not, we can take a decision.
>
> FWIW, seems like this tarball contains a dts for a "taihushui" 405ep board:
>
> https://dev.archive.openwrt.org/raw-attachment/ticket/4153/kolsch.tranzeo.openwrt.bsp.tar.bz2
>
> ... I wonder whether that's the same board as the "taihu" board in QEMU?

The corresponding ticket has some info on the machine:

https://dev.archive.openwrt.org/ticket/4153.html

but it's not clear what taihu in QEMU is in the first place. The comment 
in ppc405_boards.c says it's an evaluation board so most likely the above 
one may have been designed based on this reference board. Some info on the 
eval board can be found here:

http://www.welcm.com/amccTaihu/amccTaihu.htm
https://datasheet.octopart.com/EV-460GT-KIT-03-AMCC-datasheet-11746697.pdf
https://happytrees.org/files/chips/datasheets/product_selector_guide--AMCC--PowerPC.pdf

I wonder what ref405ep was then, an earlier or later or different version?

Regards,
BALATON Zoltan

Re: Deprecate the ppc405 boards in QEMU?

[Thomas Huth]

On 20/10/2021 16.55, BALATON Zoltan wrote:
> On Wed, 20 Oct 2021, Thomas Huth wrote:
>> On 20/10/2021 14.43, Cédric Le Goater wrote:
>>
>>> The 405 machine are still close to deprecation I think. We are still
>>> struggling to boot one with mainline Linux, using uboot provided by
>>> Thomas which skips SDRAM init. It is not clear to me if u-boot is
>>> strictly necessary. It depends if Linux relies on it to do some
>>> pre-initialization of HW. I guess once we find a good DTS for it, or
>>> not, we can take a decision.
>>
>> FWIW, seems like this tarball contains a dts for a "taihushui" 405ep board:
>>
>> https://dev.archive.openwrt.org/raw-attachment/ticket/4153/kolsch.tranzeo.openwrt.bsp.tar.bz2 
>>
>>
>> ... I wonder whether that's the same board as the "taihu" board in QEMU?
> 
> The corresponding ticket has some info on the machine:
> 
> https://dev.archive.openwrt.org/ticket/4153.html

Ok, so as far as I got that now, Taihu was a board by AMCC, while Taihushui 
was from Tranzeo ? ... so they were likely different boards, I think.

> I wonder what ref405ep was then, an earlier or later or different version?

According to hw/ppc/ppc405_boards.c, the ref405ep machine was a reference 
board by IBM, not from AMCC ?

  Thomas

Re: Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms)

[BALATON Zoltan]

[-- Attachment #1: Type: text/plain, Size: 2317 bytes --]

On Wed, 20 Oct 2021, Cédric Le Goater wrote:
> On 10/20/21 13:42, BALATON Zoltan wrote:
>> On Wed, 20 Oct 2021, Philippe Mathieu-Daudé wrote:
>>> On 10/5/21 14:29, Thomas Huth wrote:
>>>> I think there are many CPUs in that list which cannot be used with any
>>>> board, some of them might be also in a very incomplete state. So
>>>> presenting such a big list to the users is confusing and might create
>>>> wrong expectations. It would be good to remove at least the CPUs which
>>>> are really completely useless.
>>> 
>>> Maybe only remove some from system emulation but keep all of them
>>> in user emulation?
>> 
>> Or keep them all but mark those that are not tested/may be incomplete? So 
>> the used can see what is expected to work and what may need to be fixed. 
>> That way somebody may try and fix it whereas if it's not there they are 
>> unlikely to try to add it.
>
>
> The bamboo machine with 440 CPUs is booting with the latest kernel
> and we have an acceptance test for it now, thanks to Thomas. There

We also have the sam460ex for 440 based CPU that runs with Linux as 
another test but having more than one is better and not sure if the 
sam460ex has an acceptance test in QEMU. (I think Guenter Roeck tests 
sam460ex with Linux at least he did in the past.)

By the way what happened to the test written by Philippe for pegasos2. Is 
that upstream yet? That test used MorphOS so we don't only test Linux (but 
it needs the iso which is freely downloadable but probably not 
redistributable due to its license). And that's not a BookE CPU so maybe 
off-topic in this thtead I was just reminded of it.

> is not much effort in keeping them in a working state until someone
> volunteers. Hopefully, Christophe is making sure that we are not
> breaking anything with Linux support.
>
> The 405 machine are still close to deprecation I think. We are still
> struggling to boot one with mainline Linux, using uboot provided by
> Thomas which skips SDRAM init. It is not clear to me if u-boot is

I think the SDRAM init could be fixed by adding SPD data, I've done that 
for sam460ex, I may try to look at cleaning up the memory controller 
models together with the 440 one as these are similar but not too high on 
my list I want to do now so maybe later if 405 will be kept.

Regards,
BALATON Zoltan

Re: Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms)

[Daniel P. Berrangé]

On Tue, Oct 05, 2021 at 06:44:23AM +0200, Christophe Leroy wrote:
> 
> 
> Le 05/10/2021 à 02:48, David Gibson a écrit :
> > On Fri, Oct 01, 2021 at 04:18:49PM +0200, Thomas Huth wrote:
> > > On 01/10/2021 15.04, Christophe Leroy wrote:
> > > > 
> > > > 
> > > > Le 01/10/2021 à 14:04, Thomas Huth a écrit :
> > > > > On 01/10/2021 13.12, Peter Maydell wrote:
> > > > > > On Fri, 1 Oct 2021 at 10:43, Thomas Huth <thuth@redhat.com> wrote:
> > > > > > > Nevertheless, as long as nobody has a hint where to find that
> > > > > > > ppc405_rom.bin, I think both boards are pretty useless in QEMU (as far as I
> > > > > > > can see, they do not work without the bios at all, so it's
> > > > > > > also not possible
> > > > > > > to use a Linux image with the "-kernel" CLI option directly).
> > > > > > 
> > > > > > It is at least in theory possible to run bare-metal code on
> > > > > > either board, by passing either a pflash or a bios argument.
> > > > > 
> > > > > True. I did some more research, and seems like there was once
> > > > > support for those boards in u-boot, but it got removed there a
> > > > > couple of years ago already:
> > > > > 
> > > > > https://gitlab.com/qemu-project/u-boot/-/commit/98f705c9cefdf
> > > > > 
> > > > > https://gitlab.com/qemu-project/u-boot/-/commit/b147ff2f37d5b
> > > > > 
> > > > > https://gitlab.com/qemu-project/u-boot/-/commit/7514037bcdc37
> > > > > 
> > > > > > But I agree that there seem to be no signs of anybody actually
> > > > > > successfully using these boards for anything, so we should
> > > > > > deprecate-and-delete them.
> > > > > 
> > > > > Yes, let's mark them as deprecated now ... if someone still uses
> > > > > them and speaks up, we can still revert the deprecation again.
> > > > 
> > > > I really would like to be able to use them to validate Linux Kernel
> > > > changes, hence looking for that missing BIOS.
> > > > 
> > > > If we remove ppc405 from QEMU, we won't be able to do any regression
> > > > tests of Linux Kernel on those processors.
> > > 
> > > If you/someone managed to compile an old version of u-boot for one of these
> > > two boards, so that we would finally have something for regression testing,
> > > we can of course also keep the boards in QEMU...
> > 
> > I can see that it would be usefor for some cases, but unless someone
> > volunteers to track down the necessary firmware and look after it, I
> > think we do need to deprecate it - I certainly don't have the capacity
> > to look into this.
> > 
> 
> I will look at it, please allow me a few weeks though.

Once something is deprecated, it remains in QEMU for a minimum of two
release cycles, before being deleted. At any time in that deprecation
period it can be returned to supported status, if someone provides a
good enough justification to keep it.

IOW, we can deprecate this now, and you still have plenty of time to
investigate more.


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms)

[Philippe Mathieu-Daudé]

On 10/5/21 10:49, Daniel P. Berrangé wrote:
> On Tue, Oct 05, 2021 at 06:44:23AM +0200, Christophe Leroy wrote:

>> I will look at it, please allow me a few weeks though.
> 
> Once something is deprecated, it remains in QEMU for a minimum of two
> release cycles, before being deleted. At any time in that deprecation
> period it can be returned to supported status, if someone provides a
> good enough justification to keep it.

My understanding is once being in deprecated state for 2 releases, it
can be removed, but it doesn't have to be removed (assuming it is
functional and nobody complains). Am I incorrect?

I am raising this because the nanoMIPS support is in deprecated state
since more than 2 releases, but it is still in-tree and I try to keep
it functional. However, since no toolchain reached mainstream GCC/LLVM
it is not easy to maintain. By keeping it in that state we give some
time to other communities to have their toolchain upstreamed / merged.

> IOW, we can deprecate this now, and you still have plenty of time to
> investigate more.

Yes, almost 8 months :)

Re: Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms)

[Daniel P. Berrangé]

On Tue, Oct 05, 2021 at 06:15:35PM +0200, Philippe Mathieu-Daudé wrote:
> On 10/5/21 10:49, Daniel P. Berrangé wrote:
> > On Tue, Oct 05, 2021 at 06:44:23AM +0200, Christophe Leroy wrote:
> 
> >> I will look at it, please allow me a few weeks though.
> > 
> > Once something is deprecated, it remains in QEMU for a minimum of two
> > release cycles, before being deleted. At any time in that deprecation
> > period it can be returned to supported status, if someone provides a
> > good enough justification to keep it.
> 
> My understanding is once being in deprecated state for 2 releases, it
> can be removed, but it doesn't have to be removed (assuming it is
> functional and nobody complains). Am I incorrect?

It should be removed after 2 releases. Things live longer because
people forget or are busy with other things, but ultimately anything
in the deprecated list is liable to be deleted at any point after
the 2 release minimum is up.

If we change our minds about deleting something, then it should
be un-deprecated.

> I am raising this because the nanoMIPS support is in deprecated state
> since more than 2 releases, but it is still in-tree and I try to keep
> it functional. However, since no toolchain reached mainstream GCC/LLVM
> it is not easy to maintain. By keeping it in that state we give some
> time to other communities to have their toolchain upstreamed / merged.

If you're trying to keep it functional and aren't going to remove
it, then it shouldn't be marked deprecated.



Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms)

[Philippe Mathieu-Daudé]

On 10/5/21 18:20, Daniel P. Berrangé wrote:
> On Tue, Oct 05, 2021 at 06:15:35PM +0200, Philippe Mathieu-Daudé wrote:
>> On 10/5/21 10:49, Daniel P. Berrangé wrote:
>>> On Tue, Oct 05, 2021 at 06:44:23AM +0200, Christophe Leroy wrote:
>>
>>>> I will look at it, please allow me a few weeks though.
>>>
>>> Once something is deprecated, it remains in QEMU for a minimum of two
>>> release cycles, before being deleted. At any time in that deprecation
>>> period it can be returned to supported status, if someone provides a
>>> good enough justification to keep it.
>>
>> My understanding is once being in deprecated state for 2 releases, it
>> can be removed, but it doesn't have to be removed (assuming it is
>> functional and nobody complains). Am I incorrect?
> 
> It should be removed after 2 releases. Things live longer because
> people forget or are busy with other things, but ultimately anything
> in the deprecated list is liable to be deleted at any point after
> the 2 release minimum is up.
> 
> If we change our minds about deleting something, then it should
> be un-deprecated.

Sigh. This is more work on me then.

>> I am raising this because the nanoMIPS support is in deprecated state
>> since more than 2 releases, but it is still in-tree and I try to keep
>> it functional. However, since no toolchain reached mainstream GCC/LLVM
>> it is not easy to maintain. By keeping it in that state we give some
>> time to other communities to have their toolchain upstreamed / merged.
> 
> If you're trying to keep it functional and aren't going to remove
> it, then it shouldn't be marked deprecated.

OK, I'll move it back to Odd-fixes.

Re: Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms)

[Cédric Le Goater]

>>> I am raising this because the nanoMIPS support is in deprecated state
>>> since more than 2 releases, but it is still in-tree and I try to keep
>>> it functional. However, since no toolchain reached mainstream GCC/LLVM
>>> it is not easy to maintain. By keeping it in that state we give some
>>> time to other communities to have their toolchain upstreamed / merged.
>>
>> If you're trying to keep it functional and aren't going to remove
>> it, then it shouldn't be marked deprecated.
> 
> OK, I'll move it back to Odd-fixes.

The ppc405 boards are still in pretty bad shape. We need a patched u-boot,
a patched QEMU and a patched Linux and still, we do not reach user space
without some sort of crash.

C.

Re: Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms)

[Christophe Leroy]

Hi Cédric,

Le 27/10/2021 à 10:40, Cédric Le Goater a écrit :
>>>> I am raising this because the nanoMIPS support is in deprecated state
>>>> since more than 2 releases, but it is still in-tree and I try to keep
>>>> it functional. However, since no toolchain reached mainstream GCC/LLVM
>>>> it is not easy to maintain. By keeping it in that state we give some
>>>> time to other communities to have their toolchain upstreamed / merged.
>>>
>>> If you're trying to keep it functional and aren't going to remove
>>> it, then it shouldn't be marked deprecated.
>>
>> OK, I'll move it back to Odd-fixes.
> 
> The ppc405 boards are still in pretty bad shape. We need a patched u-boot,
> a patched QEMU and a patched Linux and still, we do not reach user space
> without some sort of crash.
> 

I guess Philippe was talking about the nanoMIPS here.

By the way, ppc405 is not on an optimal shape yet for sure, but we are 
getting better and better, and I'm aiming at getting it back to work, 
just because I need it.

By the way, were you able to re-test with CONFIG_MATH_EMULATION enabled 
after your last oops report which shows that you're trying to execute 
floating points instruction ?

Thanks
Christophe

Re: Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms)

[Philippe Mathieu-Daudé]

On 10/27/21 12:42, Christophe Leroy wrote:
> Le 27/10/2021 à 10:40, Cédric Le Goater a écrit :
>>>>> I am raising this because the nanoMIPS support is in deprecated state
>>>>> since more than 2 releases, but it is still in-tree and I try to keep
>>>>> it functional. However, since no toolchain reached mainstream GCC/LLVM
>>>>> it is not easy to maintain. By keeping it in that state we give some
>>>>> time to other communities to have their toolchain upstreamed / merged.
>>>>
>>>> If you're trying to keep it functional and aren't going to remove
>>>> it, then it shouldn't be marked deprecated.
>>>
>>> OK, I'll move it back to Odd-fixes.
>>
>> The ppc405 boards are still in pretty bad shape. We need a patched
>> u-boot,
>> a patched QEMU and a patched Linux and still, we do not reach user space
>> without some sort of crash.
>>
> 
> I guess Philippe was talking about the nanoMIPS here.

Yes, I was following the deprecation thread, sorry for the confusion.

Re: Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms)

[Cédric Le Goater]

Hello Christophe,

On 10/27/21 12:42, Christophe Leroy wrote:
> Hi Cédric,
> 
> Le 27/10/2021 à 10:40, Cédric Le Goater a écrit :
>>>>> I am raising this because the nanoMIPS support is in deprecated state
>>>>> since more than 2 releases, but it is still in-tree and I try to keep
>>>>> it functional. However, since no toolchain reached mainstream GCC/LLVM
>>>>> it is not easy to maintain. By keeping it in that state we give some
>>>>> time to other communities to have their toolchain upstreamed / merged.
>>>>
>>>> If you're trying to keep it functional and aren't going to remove
>>>> it, then it shouldn't be marked deprecated.
>>>
>>> OK, I'll move it back to Odd-fixes.
>>
>> The ppc405 boards are still in pretty bad shape. We need a patched u-boot,
>> a patched QEMU and a patched Linux and still, we do not reach user space
>> without some sort of crash.
>>
> 
> I guess Philippe was talking about the nanoMIPS here.
> 
> By the way, ppc405 is not on an optimal shape yet for sure, but we are getting better and better, and I'm aiming at getting it back to work, just because I need it.
> 
> By the way, were you able to re-test with CONFIG_MATH_EMULATION enabled after your last oops report which shows that you're trying to execute floating points instruction ?
> 

That's the best I got :( Please send me your .config.

Thanks,

C.

=> bootm 0x1000000
## Booting kernel from Legacy Image at 01000000 ...
    Image Name:   Linux-5.15.0-rc7-dirty
    Image Type:   PowerPC Linux Kernel Image (gzip compressed)
    Data Size:    3273457 Bytes = 3.1 MiB
    Load Address: 00700000
    Entry Point:  00701ad0
    Verifying Checksum ... OK
    Uncompressing Kernel Image ... OK
Memory <- <0x0 0x8000000> (128MB)
CPU clock-frequency <- 0x7f28155 (133MHz)
CPU timebase-frequency <- 0x7f28155 (133MHz)
/plb: clock-frequency <- 1fca055 (33MHz)
/plb/opb: clock-frequency <- 1fca055 (33MHz)
/plb/ebc: clock-frequency <- 1fca055 (33MHz)
/plb/opb/serial@ef600300: clock-frequency <- 1d1079 (2MHz)
/plb/opb/serial@ef600400: clock-frequency <- 1d1079 (2MHz)
ethernet0: local-mac-address <- 00:00:00:00:00:00
ethernet1: local-mac-address <- 00:00:2d:e5:44:80
Fixing devtree for 4M Flash

zImage starting: loaded at 0x00700000 (sp: 0x07eaabb0)
Decompression error: 'Not a gzip file'
No valid compressed data found, assume uncompressed data
Allocating 0x6bd274 bytes for kernel...
0x69a114 bytes of uncompressed data copied

Linux/PowerPC load:
Finalizing device tree... flat tree at 0xdc1960
Linux version 5.15.0-rc7-dirty (legoater@yukon) (powerpc64-linux-gnu-gcc (GCC) 11.2.1 20210728 (Red Hat Cross 11.2.1-1), GNU ld version 2.35.2-1.fc34) #14 Wed Oct 27 18:41:41 CEST 2021
Using PowerPC 40x Platform machine description
printk: bootconsole [udbg0] enabled
-----------------------------------------------------
phys_mem_size     = 0x8000000
dcache_bsize      = 0x20
icache_bsize      = 0x20
cpu_features      = 0x0000000000000100
   possible        = 0x0000000000000100
   always          = 0x0000000000000100
cpu_user_features = 0x86000000 0x00000000
mmu_features      = 0x00000004
-----------------------------------------------------
Zone ranges:
   Normal   [mem 0x0000000000000000-0x0000000007ffffff]
Movable zone start for each node
Early memory node ranges
   node   0: [mem 0x0000000000000000-0x0000000007ffffff]
Initmem setup node 0 [mem 0x0000000000000000-0x0000000007ffffff]
MMU: Allocated 1088 bytes of context maps for 255 contexts
Built 1 zonelists, mobility grouping on.  Total pages: 32512
Kernel command line:
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes, linear)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes, linear)
mem auto-init: stack:off, heap alloc:off, heap free:off
Kernel virtual memory layout:
   * 0xffbdf000..0xfffff000  : fixmap
   * 0xc9000000..0xffbdf000  : vmalloc & ioremap
Memory: 122964K/131072K available (4920K kernel code, 224K rwdata, 1304K rodata, 316K init, 136K bss, 8108K reserved, 0K cma-reserved)
SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
NR_IRQS: 512, nr_irqs: 512, preallocated irqs: 16
UIC0 (32 IRQ sources) at DCR 0xc0
random: get_random_u32 called from start_kernel+0x498/0x5f8 with crng_init=0
clocksource: timebase: mask: 0xffffffffffffffff max_cycles: 0x1ec031343f, max_idle_ns: 440795203544 ns
clocksource: timebase mult[7800000] shift[24] registered
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 1024 (order: 0, 4096 bytes, linear)
Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes, linear)
clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
futex hash table entries: 256 (order: -1, 3072 bytes, linear)
NET: Registered PF_NETLINK/PF_ROUTE protocol family
DMA: preallocated 128 KiB GFP_KERNEL pool for atomic allocations
              
thermal_sys: Registered thermal governor 'step_wise'
PCI host bridge /plb/pci@ec000000 (primary) ranges:
  MEM 0x0000000080000000..0x000000009fffffff -> 0x0000000080000000
   IO 0x00000000e8000000..0x00000000e800ffff -> 0x0000000000000000
4xx PCI DMA offset set to 0x00000000
4xx PCI DMA window base to 0x0000000000000000
DMA window size 0x0000000080000000
PCI: Probing PCI hardware
PCI host bridge to bus 0008:00
pci_bus 0008:00: root bus resource [io  0x0000-0xffff]
pci_bus 0008:00: root bus resource [mem 0x80000000-0x9fffffff]
pci_bus 0008:00: root bus resource [bus 00-ff]
pci_bus 0008:00: busn_res: [bus 00-ff] end is updated to ff
pci_bus 0008:00: busn_res: [bus 00-ff] end is updated to 00
pci_bus 0008:00: resource 4 [io  0x0000-0xffff]
pci_bus 0008:00: resource 5 [mem 0x80000000-0x9fffffff]
vgaarb: loaded
pps_core: LinuxPPS API ver. 1 registered
pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
PTP clock support registered
clocksource: Switched to clocksource timebase
NET: Registered PF_INET protocol family
IP idents hash table entries: 2048 (order: 2, 16384 bytes, linear)
tcp_listen_portaddr_hash hash table entries: 512 (order: 0, 4096 bytes, linear)
TCP established hash table entries: 1024 (order: 0, 4096 bytes, linear)
TCP bind hash table entries: 1024 (order: 0, 4096 bytes, linear)
TCP: Hash tables configured (established 1024 bind 1024)
UDP hash table entries: 256 (order: 0, 4096 bytes, linear)
UDP-Lite hash table entries: 256 (order: 0, 4096 bytes, linear)
NET: Registered PF_UNIX/PF_LOCAL protocol family
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
PCI: CLS 0 bytes, default 32
Mem-Info:
active_anon:0 inactive_anon:0 isolated_anon:0
  active_file:0 inactive_file:0 isolated_file:0
  unevictable:0 dirty:0 writeback:0
  slab_reclaimable:11 slab_unreclaimable:171
  mapped:0 shmem:0 pagetables:0 bounce:0
  kernel_misc_reclaimable:0
  free:30452 free_pcp:19 free_cma:0
Node 0 active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB mapped:0kB dirty:0kB writeback:0kB shmem:0kB writeback_tmp:0kB kernel_stack:152kB pagetables:0kB all_unreclaimable? no
Normal free:121808kB min:1400kB low:1748kB high:2096kB reserved_highatomic:0KB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB present:131072kB managed:122964kB mlocked:0kB bounce:0kB free_pcp:76kB local_pcp:76kB free_cma:0kB
lowmem_reserve[]: 0 0
Normal: 4*4kB (UM) 2*8kB (ME) 3*16kB (UM) 2*32kB (UM) 3*64kB (ME) 3*128kB (UME) 5*256kB (UME) 4*512kB (UME) 3*1024kB (ME) 4*2048kB (UME) 26*4096kB (M) = 121808kB
0 total pagecache pages
0 pages in swap cache
Swap cache stats: add 0, delete 0, find 0/0
Free swap  = 0kB
Total swap = 0kB
32768 pages RAM
0 pages HighMem/MovableOnly
2027 pages reserved
Kernel panic - not syncing:
CPU: 0 PID: 5 Comm: kworker/u2:0 Not tainted 5.15.0-rc7-dirty #12
Workqueue: events_unbound async_run_entry_fn
Call Trace:
[c0845d70] [c0026a40] panic+0x11c/0x2e0 (unreliable)
[c0845dd0] [c000513c] sys_mmap2+0x0/0x20
[c0845e20] [c0617844] do_populate_rootfs+0x48/0x17c
[c0845e60] [c004a8ec] async_run_entry_fn+0x34/0xc4
[c0845e80] [c003f6c0] process_one_work+0x268/0x3e0
[c0845eb0] [c003fd40] worker_thread+0x17c/0x4c4
[c0845f00] [c0047898] kthread+0x12c/0x14c
[c0845f40] [c0010114] ret_from_kernel_thread+0x14/0x1c
Rebooting in 180 seconds..

[PATCH v3 5/7] MAINTAINERS: Remove David & Greg as reviewers/co-maintainers of powernv

[David Gibson]

With our interests moving to other areas, Greg and myself no longer have
capacity to be regular reviewers of code for the powernv machine type, let
alone co-maintainers.  Additionally, not being IBM employees, we don't have
easy access to the hardware information we'd need for good review.

Therefore, remove our names as reviewers and/or co-maintainers of the
powernv machine type, and the related XIVE interrupt controller.

Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Greg Kurz <groug@kaod.org>
Acked-by: Cédric Le Goater <clg@kaod.org>
---
 MAINTAINERS | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 1ecb5716c8..7439ef1bd9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1331,8 +1331,6 @@ F: tests/acceptance/ppc_pseries.py
 
 PowerNV (Non-Virtualized)
 M: Cédric Le Goater <clg@kaod.org>
-M: David Gibson <david@gibson.dropbear.id.au>
-M: Greg Kurz <groug@kaod.org>
 L: qemu-ppc@nongnu.org
 S: Maintained
 F: hw/ppc/pnv*
@@ -2225,8 +2223,6 @@ T: git https://github.com/philmd/qemu.git fw_cfg-next
 
 XIVE
 M: Cédric Le Goater <clg@kaod.org>
-R: David Gibson <david@gibson.dropbear.id.au>
-R: Greg Kurz <groug@kaod.org>
 L: qemu-ppc@nongnu.org
 S: Supported
 F: hw/*/*xive*
-- 
2.31.1

[PATCH v3 6/7] MAINTAINERS: Add information for OpenPIC

[David Gibson]

The OpenPIC interrupt controller was once the de facto standard on ppc
machines.  In qemu it's now only used on some Macintosh and the
Freescale e500 machine.  It has no listed maintainer, and as far as I
know, no-one who's really familiar with it any more.

Since I'm moving away from the area, I no longer have capacity to do even
minimal maintenance of it under the auspices of the ppc targets in general.

Therefore, this patch lists the main part of openpic, and marks it as
"Odd Fixes" to be looked after by Mark Cave-Ayland who handles the
Macintosh targets.  The openpic_kvm variant is only used on e500, so
add it to the files for that machine type (itself already Orphaned).

Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: Greg Kurz <groug@kaod.org>
---
 MAINTAINERS | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 7439ef1bd9..c0fcba7f8b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1256,6 +1256,8 @@ F: hw/pci-host/ppce500.c
 F: include/hw/ppc/ppc_e500.h
 F: include/hw/pci-host/ppce500.h
 F: pc-bios/u-boot.e500
+F: hw/intc/openpic_kvm.h
+F: include/hw/ppc/openpic_kvm.h
 
 mpc8544ds
 L: qemu-ppc@nongnu.org
@@ -2258,6 +2260,12 @@ F: net/can/*
 F: hw/net/can/*
 F: include/net/can_*.h
 
+OpenPIC interrupt controller
+M: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
+S: Odd Fixes
+F: hw/intc/openpic.c
+F: include/hw/ppc/openpic.h
+
 Subsystems
 ----------
 Overall Audio backends
-- 
2.31.1

Re: [PATCH v3 6/7] MAINTAINERS: Add information for OpenPIC

[Mark Cave-Ayland]

On 27/09/2021 05:48, David Gibson wrote:

> The OpenPIC interrupt controller was once the de facto standard on ppc
> machines.  In qemu it's now only used on some Macintosh and the
> Freescale e500 machine.  It has no listed maintainer, and as far as I
> know, no-one who's really familiar with it any more.
> 
> Since I'm moving away from the area, I no longer have capacity to do even
> minimal maintenance of it under the auspices of the ppc targets in general.
> 
> Therefore, this patch lists the main part of openpic, and marks it as
> "Odd Fixes" to be looked after by Mark Cave-Ayland who handles the
> Macintosh targets.  The openpic_kvm variant is only used on e500, so
> add it to the files for that machine type (itself already Orphaned).
> 
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> Reviewed-by: Cédric Le Goater <clg@kaod.org>
> Reviewed-by: Greg Kurz <groug@kaod.org>
> ---
>   MAINTAINERS | 8 ++++++++
>   1 file changed, 8 insertions(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 7439ef1bd9..c0fcba7f8b 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1256,6 +1256,8 @@ F: hw/pci-host/ppce500.c
>   F: include/hw/ppc/ppc_e500.h
>   F: include/hw/pci-host/ppce500.h
>   F: pc-bios/u-boot.e500
> +F: hw/intc/openpic_kvm.h
> +F: include/hw/ppc/openpic_kvm.h
>   
>   mpc8544ds
>   L: qemu-ppc@nongnu.org
> @@ -2258,6 +2260,12 @@ F: net/can/*
>   F: hw/net/can/*
>   F: include/net/can_*.h
>   
> +OpenPIC interrupt controller
> +M: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
> +S: Odd Fixes
> +F: hw/intc/openpic.c
> +F: include/hw/ppc/openpic.h
> +
>   Subsystems
>   ----------
>   Overall Audio backends

Reviewed-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>


ATB,

Mark.

[PATCH v3 7/7] MAINTAINERS: Demote sPAPR from "Supported" to "Maintained"

[David Gibson]

qemu/KVM on Power is no longer my primary job responsibility, nor Greg
Kurz'.  I still have some time for upstream maintenance, but it's no longer
accurate to say that I'm paid to do so.  Therefore, reduce sPAPR (the
"pseries" machine type) from Supported to Maintained.

Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Greg Kurz <groug@kaod.org>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
---
 MAINTAINERS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index c0fcba7f8b..8b7cb859e9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1317,7 +1317,7 @@ sPAPR
 M: David Gibson <david@gibson.dropbear.id.au>
 M: Greg Kurz <groug@kaod.org>
 L: qemu-ppc@nongnu.org
-S: Supported
+S: Maintained
 F: hw/*/spapr*
 F: include/hw/*/spapr*
 F: hw/*/xics*
-- 
2.31.1

Re: [PATCH v3 0/7] Reduce load on ppc target maintainers

[David Gibson]

[-- Attachment #1: Type: text/plain, Size: 2165 bytes --]

On Mon, Sep 27, 2021 at 02:48:01PM +1000, David Gibson wrote:
> Greg Kurz and myself have been co-maintainers for the ppc and ppc64
> targets for some time now.  However, both our day job responsibilities
> and interests are leading us towards other areas, so we have less time
> to devote to this any more.
> 
> Therefore, here's a bunch of updates to MAINTAINERS, intended to
> reduce the load on us.  Mostly this is marking fairly obscure
> platforms as orphaned (if someone wants to take over maintainership,
> let me know ASAP).  Bigger changes may be coming, but we haven't
> decided exactly what that's going to look like yet.

Thanks for the feedback and acks on this.  I'm now merging v3 into
ppc-for-6.2 to go into a pull request shortly.

> 
> Changes since v2:
>  * Clarified overly broad TCG CPUs entry
> Changes since v1:
>  * Reworked how OpenPIC is listed
> 
> David Gibson (7):
>   qemu: Split machine_ppc.py acceptance tests
>   MAINTAINERS: Remove machine specific files from ppc TCG CPUs entry
>   MAINTAINERS: Remove David & Greg as reviewers for a number of boards
>   MAINTAINERS: Orphan obscure ppc platforms
>   MAINTAINERS: Remove David & Greg as reviewers/co-maintainers of
>     powernv
>   MAINTAINERS: Add information for OpenPIC
>   MAINTAINERS: Demote sPAPR from "Supported" to "Maintained"
> 
>  MAINTAINERS                          | 51 ++++++++------------
>  tests/acceptance/machine_ppc.py      | 69 ----------------------------
>  tests/acceptance/ppc_mpc8544ds.py    | 32 +++++++++++++
>  tests/acceptance/ppc_pseries.py      | 35 ++++++++++++++
>  tests/acceptance/ppc_virtex_ml507.py | 34 ++++++++++++++
>  5 files changed, 121 insertions(+), 100 deletions(-)
>  delete mode 100644 tests/acceptance/machine_ppc.py
>  create mode 100644 tests/acceptance/ppc_mpc8544ds.py
>  create mode 100644 tests/acceptance/ppc_pseries.py
>  create mode 100644 tests/acceptance/ppc_virtex_ml507.py
> 

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v3 0/7] Reduce load on ppc target maintainers

[Alexey Kardashevskiy]

On 30/09/2021 11:15, David Gibson wrote:
> On Mon, Sep 27, 2021 at 02:48:01PM +1000, David Gibson wrote:
>> Greg Kurz and myself have been co-maintainers for the ppc and ppc64
>> targets for some time now.  However, both our day job responsibilities
>> and interests are leading us towards other areas, so we have less time
>> to devote to this any more.
>>
>> Therefore, here's a bunch of updates to MAINTAINERS, intended to
>> reduce the load on us.  Mostly this is marking fairly obscure
>> platforms as orphaned (if someone wants to take over maintainership,
>> let me know ASAP).  Bigger changes may be coming, but we haven't
>> decided exactly what that's going to look like yet.
> 
> Thanks for the feedback and acks on this.  I'm now merging v3 into
> ppc-for-6.2 to go into a pull request shortly.
> 
>>
>> Changes since v2:
>>  * Clarified overly broad TCG CPUs entry
>> Changes since v1:
>>  * Reworked how OpenPIC is listed
>>
>> David Gibson (7):
>>   qemu: Split machine_ppc.py acceptance tests
>>   MAINTAINERS: Remove machine specific files from ppc TCG CPUs entry
>>   MAINTAINERS: Remove David & Greg as reviewers for a number of boards
>>   MAINTAINERS: Orphan obscure ppc platforms
>>   MAINTAINERS: Remove David & Greg as reviewers/co-maintainers of
>>     powernv
>>   MAINTAINERS: Add information for OpenPIC
>>   MAINTAINERS: Demote sPAPR from "Supported" to "Maintained"
>>
>>  MAINTAINERS                          | 51 ++++++++------------
>>  tests/acceptance/machine_ppc.py      | 69 ----------------------------
>>  tests/acceptance/ppc_mpc8544ds.py    | 32 +++++++++++++
>>  tests/acceptance/ppc_pseries.py      | 35 ++++++++++++++
>>  tests/acceptance/ppc_virtex_ml507.py | 34 ++++++++++++++
>>  5 files changed, 121 insertions(+), 100 deletions(-)
>>  delete mode 100644 tests/acceptance/machine_ppc.py
>>  create mode 100644 tests/acceptance/ppc_mpc8544ds.py
>>  create mode 100644 tests/acceptance/ppc_pseries.py
>>  create mode 100644 tests/acceptance/ppc_virtex_ml507.py
I have a bunch of small patches for SLOF - what do I do with those now?
Still send pull requests to you and Greg as usual? Thanks,




-- 
Alexey

Re: [PATCH v3 0/7] Reduce load on ppc target maintainers

[Greg Kurz]

On Wed, 6 Oct 2021 20:52:00 +1100
Alexey Kardashevskiy <aik@ozlabs.ru> wrote:

> 
> 
> On 30/09/2021 11:15, David Gibson wrote:
> > On Mon, Sep 27, 2021 at 02:48:01PM +1000, David Gibson wrote:
> >> Greg Kurz and myself have been co-maintainers for the ppc and ppc64
> >> targets for some time now.  However, both our day job responsibilities
> >> and interests are leading us towards other areas, so we have less time
> >> to devote to this any more.
> >>
> >> Therefore, here's a bunch of updates to MAINTAINERS, intended to
> >> reduce the load on us.  Mostly this is marking fairly obscure
> >> platforms as orphaned (if someone wants to take over maintainership,
> >> let me know ASAP).  Bigger changes may be coming, but we haven't
> >> decided exactly what that's going to look like yet.
> > 
> > Thanks for the feedback and acks on this.  I'm now merging v3 into
> > ppc-for-6.2 to go into a pull request shortly.
> > 
> >>
> >> Changes since v2:
> >>  * Clarified overly broad TCG CPUs entry
> >> Changes since v1:
> >>  * Reworked how OpenPIC is listed
> >>
> >> David Gibson (7):
> >>   qemu: Split machine_ppc.py acceptance tests
> >>   MAINTAINERS: Remove machine specific files from ppc TCG CPUs entry
> >>   MAINTAINERS: Remove David & Greg as reviewers for a number of boards
> >>   MAINTAINERS: Orphan obscure ppc platforms
> >>   MAINTAINERS: Remove David & Greg as reviewers/co-maintainers of
> >>     powernv
> >>   MAINTAINERS: Add information for OpenPIC
> >>   MAINTAINERS: Demote sPAPR from "Supported" to "Maintained"
> >>
> >>  MAINTAINERS                          | 51 ++++++++------------
> >>  tests/acceptance/machine_ppc.py      | 69 ----------------------------
> >>  tests/acceptance/ppc_mpc8544ds.py    | 32 +++++++++++++
> >>  tests/acceptance/ppc_pseries.py      | 35 ++++++++++++++
> >>  tests/acceptance/ppc_virtex_ml507.py | 34 ++++++++++++++
> >>  5 files changed, 121 insertions(+), 100 deletions(-)
> >>  delete mode 100644 tests/acceptance/machine_ppc.py
> >>  create mode 100644 tests/acceptance/ppc_mpc8544ds.py
> >>  create mode 100644 tests/acceptance/ppc_pseries.py
> >>  create mode 100644 tests/acceptance/ppc_virtex_ml507.py
> I have a bunch of small patches for SLOF - what do I do with those now?
> Still send pull requests to you and Greg as usual? Thanks,
> 

We've downgraded sPAPR from "Supported" to "Maintained", which means
that we're no longer paid to do it (i.e. likely less responsive than
before) but we're still in charge of SLOF in QEMU.

$ ./scripts/get_maintainer.pl -f pc-bios/slof.bin
David Gibson <david@gibson.dropbear.id.au> (maintainer:sPAPR)
Greg Kurz <groug@kaod.org> (maintainer:sPAPR)
qemu-ppc@nongnu.org (open list:sPAPR)
qemu-devel@nongnu.org (open list:All patches CC here)

As usual then :-)

> 
> 
>