* [PATCH v3 0/7] Reduce load on ppc target maintainers @ 2021-09-27 4:48 David Gibson 2021-09-27 4:48 ` [PATCH v3 1/7] qemu: Split machine_ppc.py acceptance tests David Gibson ` (7 more replies) 0 siblings, 8 replies; 93+ messages in thread From: David Gibson @ 2021-09-27 4:48 UTC (permalink / raw) To: qemu-devel, qemu-ppc Cc: peter.maydell, dbarboza, aik, mark.cave-ayland, groug, wainersm, hpoussin, clg, crosa, Edgar E. Iglesias, philmd, 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 ^ permalink raw reply [flat|nested] 93+ messages in thread
* [PATCH v3 1/7] qemu: Split machine_ppc.py acceptance tests 2021-09-27 4:48 [PATCH v3 0/7] Reduce load on ppc target maintainers David Gibson @ 2021-09-27 4:48 ` David Gibson 2021-09-27 4:50 ` Philippe Mathieu-Daudé 2021-09-27 16:44 ` Philippe Mathieu-Daudé 2021-09-27 4:48 ` [PATCH v3 2/7] MAINTAINERS: Remove machine specific files from ppc TCG CPUs entry David Gibson ` (6 subsequent siblings) 7 siblings, 2 replies; 93+ messages in thread From: David Gibson @ 2021-09-27 4:48 UTC (permalink / raw) To: qemu-devel, qemu-ppc Cc: peter.maydell, dbarboza, aik, Philippe Mathieu-Daudé, mark.cave-ayland, groug, wainersm, hpoussin, clg, crosa, Edgar E. Iglesias, philmd, 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 ^ permalink raw reply related [flat|nested] 93+ messages in thread
* Re: [PATCH v3 1/7] qemu: Split machine_ppc.py acceptance tests 2021-09-27 4:48 ` [PATCH v3 1/7] qemu: Split machine_ppc.py acceptance tests David Gibson @ 2021-09-27 4:50 ` Philippe Mathieu-Daudé 2021-09-27 16:44 ` Philippe Mathieu-Daudé 1 sibling, 0 replies; 93+ messages in thread From: Philippe Mathieu-Daudé @ 2021-09-27 4:50 UTC (permalink / raw) To: David Gibson, qemu-devel, qemu-ppc Cc: peter.maydell, dbarboza, aik, mark.cave-ayland, groug, wainersm, hpoussin, clg, crosa, Edgar E. Iglesias 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> ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v3 1/7] qemu: Split machine_ppc.py acceptance tests 2021-09-27 4:48 ` [PATCH v3 1/7] qemu: Split machine_ppc.py acceptance tests David Gibson 2021-09-27 4:50 ` Philippe Mathieu-Daudé @ 2021-09-27 16:44 ` Philippe Mathieu-Daudé 2021-09-27 16:53 ` Cédric Le Goater 1 sibling, 1 reply; 93+ messages in thread From: Philippe Mathieu-Daudé @ 2021-09-27 16:44 UTC (permalink / raw) To: David Gibson, qemu-devel, qemu-ppc Cc: peter.maydell, dbarboza, aik, mark.cave-ayland, groug, wainersm, hpoussin, clg, crosa, Edgar E. Iglesias, 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. ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v3 1/7] qemu: Split machine_ppc.py acceptance tests 2021-09-27 16:44 ` Philippe Mathieu-Daudé @ 2021-09-27 16:53 ` Cédric Le Goater 2021-09-27 17:18 ` Philippe Mathieu-Daudé 0 siblings, 1 reply; 93+ messages in thread From: Cédric Le Goater @ 2021-09-27 16:53 UTC (permalink / raw) To: Philippe Mathieu-Daudé, David Gibson, qemu-devel, qemu-ppc Cc: peter.maydell, dbarboza, aik, mark.cave-ayland, groug, wainersm, hpoussin, crosa, Edgar E. Iglesias, Philippe Mathieu-Daudé 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. ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v3 1/7] qemu: Split machine_ppc.py acceptance tests 2021-09-27 16:53 ` Cédric Le Goater @ 2021-09-27 17:18 ` Philippe Mathieu-Daudé 0 siblings, 0 replies; 93+ messages in thread From: Philippe Mathieu-Daudé @ 2021-09-27 17:18 UTC (permalink / raw) To: Cédric Le Goater, David Gibson, qemu-devel, qemu-ppc Cc: peter.maydell, dbarboza, aik, mark.cave-ayland, groug, wainersm, hpoussin, crosa, Edgar E. Iglesias, 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. ^ permalink raw reply [flat|nested] 93+ messages in thread
* [PATCH v3 2/7] MAINTAINERS: Remove machine specific files from ppc TCG CPUs entry 2021-09-27 4:48 [PATCH v3 0/7] Reduce load on ppc target maintainers David Gibson 2021-09-27 4:48 ` [PATCH v3 1/7] qemu: Split machine_ppc.py acceptance tests David Gibson @ 2021-09-27 4:48 ` David Gibson 2021-09-27 4:48 ` [PATCH v3 3/7] MAINTAINERS: Remove David & Greg as reviewers for a number of boards David Gibson ` (5 subsequent siblings) 7 siblings, 0 replies; 93+ messages in thread From: David Gibson @ 2021-09-27 4:48 UTC (permalink / raw) To: qemu-devel, qemu-ppc Cc: peter.maydell, dbarboza, aik, mark.cave-ayland, groug, wainersm, hpoussin, clg, crosa, Edgar E. Iglesias, philmd, 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 ^ permalink raw reply related [flat|nested] 93+ messages in thread
* [PATCH v3 3/7] MAINTAINERS: Remove David & Greg as reviewers for a number of boards 2021-09-27 4:48 [PATCH v3 0/7] Reduce load on ppc target maintainers David Gibson 2021-09-27 4:48 ` [PATCH v3 1/7] qemu: Split machine_ppc.py acceptance tests David Gibson 2021-09-27 4:48 ` [PATCH v3 2/7] MAINTAINERS: Remove machine specific files from ppc TCG CPUs entry David Gibson @ 2021-09-27 4:48 ` David Gibson 2021-09-27 4:48 ` [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms David Gibson ` (4 subsequent siblings) 7 siblings, 0 replies; 93+ messages in thread From: David Gibson @ 2021-09-27 4:48 UTC (permalink / raw) To: qemu-devel, qemu-ppc Cc: peter.maydell, dbarboza, aik, mark.cave-ayland, groug, wainersm, hpoussin, clg, crosa, Edgar E. Iglesias, philmd, 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 ^ permalink raw reply related [flat|nested] 93+ messages in thread
* [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms 2021-09-27 4:48 [PATCH v3 0/7] Reduce load on ppc target maintainers David Gibson ` (2 preceding siblings ...) 2021-09-27 4:48 ` [PATCH v3 3/7] MAINTAINERS: Remove David & Greg as reviewers for a number of boards David Gibson @ 2021-09-27 4:48 ` David Gibson 2021-10-01 8:35 ` Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms) Thomas Huth 2021-09-27 4:48 ` [PATCH v3 5/7] MAINTAINERS: Remove David & Greg as reviewers/co-maintainers of powernv David Gibson ` (3 subsequent siblings) 7 siblings, 1 reply; 93+ messages in thread From: David Gibson @ 2021-09-27 4:48 UTC (permalink / raw) To: qemu-devel, qemu-ppc Cc: peter.maydell, dbarboza, aik, mark.cave-ayland, groug, wainersm, hpoussin, clg, crosa, Edgar E. Iglesias, philmd, 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 ^ permalink raw reply related [flat|nested] 93+ messages in thread
* Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms) 2021-09-27 4:48 ` [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms David Gibson @ 2021-10-01 8:35 ` Thomas Huth 2021-10-01 9:14 ` Christophe Leroy 0 siblings, 1 reply; 93+ messages in thread From: Thomas Huth @ 2021-10-01 8:35 UTC (permalink / raw) To: David Gibson, qemu-devel, qemu-ppc Cc: Christophe Leroy, peter.maydell, dbarboza, aik, mark.cave-ayland, groug, wainersm, Alexander Graf, hpoussin, clg, crosa, Edgar E. Iglesias, philmd 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 ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms) 2021-10-01 8:35 ` Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms) Thomas Huth @ 2021-10-01 9:14 ` Christophe Leroy 2021-10-01 9:43 ` Thomas Huth 0 siblings, 1 reply; 93+ messages in thread From: Christophe Leroy @ 2021-10-01 9:14 UTC (permalink / raw) To: Thomas Huth, David Gibson, qemu-devel, qemu-ppc Cc: Christophe Leroy, peter.maydell, dbarboza, aik, mark.cave-ayland, groug, wainersm, Alexander Graf, hpoussin, clg, crosa, Edgar E. Iglesias, philmd 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? > ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms) 2021-10-01 9:14 ` Christophe Leroy @ 2021-10-01 9:43 ` Thomas Huth 2021-10-01 11:12 ` Peter Maydell 0 siblings, 1 reply; 93+ messages in thread From: Thomas Huth @ 2021-10-01 9:43 UTC (permalink / raw) To: Christophe Leroy, David Gibson, qemu-devel, qemu-ppc Cc: Christophe Leroy, peter.maydell, dbarboza, aik, mark.cave-ayland, groug, wainersm, Alexander Graf, hpoussin, clg, crosa, Edgar E. Iglesias, philmd 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 ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms) 2021-10-01 9:43 ` Thomas Huth @ 2021-10-01 11:12 ` Peter Maydell 2021-10-01 12:04 ` Thomas Huth 0 siblings, 1 reply; 93+ messages in thread From: Peter Maydell @ 2021-10-01 11:12 UTC (permalink / raw) To: Thomas Huth Cc: Christophe Leroy, dbarboza, Alexey Kardashevskiy, Mark Cave-Ayland, QEMU Developers, Christophe Leroy, Greg Kurz, Cédric Le Goater, Alexander Graf, qemu-ppc, Wainer dos Santos Moschetta, Cleber Rosa, Hervé Poussineau, Philippe Mathieu-Daudé, Edgar E. Iglesias, David Gibson 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 ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms) 2021-10-01 11:12 ` Peter Maydell @ 2021-10-01 12:04 ` Thomas Huth 2021-10-01 13:04 ` Christophe Leroy 0 siblings, 1 reply; 93+ messages in thread From: Thomas Huth @ 2021-10-01 12:04 UTC (permalink / raw) To: Peter Maydell Cc: Christophe Leroy, dbarboza, Alexey Kardashevskiy, Mark Cave-Ayland, QEMU Developers, Christophe Leroy, Greg Kurz, Cédric Le Goater, Alexander Graf, qemu-ppc, Wainer dos Santos Moschetta, Cleber Rosa, Hervé Poussineau, Philippe Mathieu-Daudé, Edgar E. Iglesias, David Gibson 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 ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms) 2021-10-01 12:04 ` Thomas Huth @ 2021-10-01 13:04 ` Christophe Leroy 2021-10-01 13:14 ` Cédric Le Goater ` (2 more replies) 0 siblings, 3 replies; 93+ messages in thread From: Christophe Leroy @ 2021-10-01 13:04 UTC (permalink / raw) To: Thomas Huth, Peter Maydell Cc: Christophe Leroy, dbarboza, Alexey Kardashevskiy, Mark Cave-Ayland, QEMU Developers, Wainer dos Santos Moschetta, Greg Kurz, Alexander Graf, qemu-ppc, Cédric Le Goater, Cleber Rosa, Hervé Poussineau, Philippe Mathieu-Daudé, Edgar E. Iglesias, David Gibson 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 ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms) 2021-10-01 13:04 ` Christophe Leroy @ 2021-10-01 13:14 ` Cédric Le Goater 2021-10-01 13:24 ` Peter Maydell 2021-10-01 14:18 ` Thomas Huth 2 siblings, 0 replies; 93+ messages in thread From: Cédric Le Goater @ 2021-10-01 13:14 UTC (permalink / raw) To: Christophe Leroy, Thomas Huth, Peter Maydell Cc: Christophe Leroy, dbarboza, Alexey Kardashevskiy, Mark Cave-Ayland, QEMU Developers, Wainer dos Santos Moschetta, Greg Kurz, Alexander Graf, qemu-ppc, Cleber Rosa, Hervé Poussineau, Philippe Mathieu-Daudé, Edgar E. Iglesias, David Gibson 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. ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms) 2021-10-01 13:04 ` Christophe Leroy 2021-10-01 13:14 ` Cédric Le Goater @ 2021-10-01 13:24 ` Peter Maydell 2021-10-01 14:18 ` Thomas Huth 2 siblings, 0 replies; 93+ messages in thread From: Peter Maydell @ 2021-10-01 13:24 UTC (permalink / raw) To: Christophe Leroy Cc: Christophe Leroy, Thomas Huth, dbarboza, Alexey Kardashevskiy, Mark Cave-Ayland, QEMU Developers, Wainer dos Santos Moschetta, Greg Kurz, Alexander Graf, qemu-ppc, Cédric Le Goater, Cleber Rosa, Hervé Poussineau, Philippe Mathieu-Daudé, Edgar E. Iglesias, David Gibson 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 ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms) 2021-10-01 13:04 ` Christophe Leroy 2021-10-01 13:14 ` Cédric Le Goater 2021-10-01 13:24 ` Peter Maydell @ 2021-10-01 14:18 ` Thomas Huth 2021-10-05 0:48 ` David Gibson 2 siblings, 1 reply; 93+ messages in thread From: Thomas Huth @ 2021-10-01 14:18 UTC (permalink / raw) To: Christophe Leroy, Peter Maydell Cc: Christophe Leroy, dbarboza, Alexey Kardashevskiy, Mark Cave-Ayland, QEMU Developers, Wainer dos Santos Moschetta, Greg Kurz, Alexander Graf, qemu-ppc, Cédric Le Goater, Cleber Rosa, Hervé Poussineau, Philippe Mathieu-Daudé, Edgar E. Iglesias, David Gibson 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 ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms) 2021-10-01 14:18 ` Thomas Huth @ 2021-10-05 0:48 ` David Gibson 2021-10-05 4:44 ` Christophe Leroy 0 siblings, 1 reply; 93+ messages in thread From: David Gibson @ 2021-10-05 0:48 UTC (permalink / raw) To: Thomas Huth Cc: Christophe Leroy, Peter Maydell, dbarboza, Alexey Kardashevskiy, Mark Cave-Ayland, QEMU Developers, Christophe Leroy, Greg Kurz, Alexander Graf, qemu-ppc, Wainer dos Santos Moschetta, Cleber Rosa, Hervé Poussineau, Philippe Mathieu-Daudé, Edgar E. Iglesias, Cédric Le Goater [-- 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 --] ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms) 2021-10-05 0:48 ` David Gibson @ 2021-10-05 4:44 ` Christophe Leroy 2021-10-05 6:18 ` Alexey Kardashevskiy 2021-10-05 8:49 ` Daniel P. Berrangé 0 siblings, 2 replies; 93+ messages in thread From: Christophe Leroy @ 2021-10-05 4:44 UTC (permalink / raw) To: David Gibson, Thomas Huth Cc: Christophe Leroy, Peter Maydell, dbarboza, Alexey Kardashevskiy, Mark Cave-Ayland, QEMU Developers, Wainer dos Santos Moschetta, Greg Kurz, Alexander Graf, qemu-ppc, Cédric Le Goater, Cleber Rosa, Hervé Poussineau, Philippe Mathieu-Daudé, Edgar E. Iglesias 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 ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms) 2021-10-05 4:44 ` Christophe Leroy @ 2021-10-05 6:18 ` Alexey Kardashevskiy 2021-10-05 6:42 ` Thomas Huth 2021-10-05 8:14 ` Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms) Cédric Le Goater 2021-10-05 8:49 ` Daniel P. Berrangé 1 sibling, 2 replies; 93+ messages in thread From: Alexey Kardashevskiy @ 2021-10-05 6:18 UTC (permalink / raw) To: Christophe Leroy, David Gibson, Thomas Huth Cc: Christophe Leroy, Peter Maydell, dbarboza, Mark Cave-Ayland, Greg Kurz, Wainer dos Santos Moschetta, QEMU Developers, Alexander Graf, qemu-ppc, Cédric Le Goater, Cleber Rosa, Hervé Poussineau, Philippe Mathieu-Daudé, Edgar E. Iglesias 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 ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms) 2021-10-05 6:18 ` Alexey Kardashevskiy @ 2021-10-05 6:42 ` Thomas Huth 2021-10-05 8:05 ` Alexey Kardashevskiy 2021-10-05 8:14 ` Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms) Cédric Le Goater 1 sibling, 1 reply; 93+ messages in thread From: Thomas Huth @ 2021-10-05 6:42 UTC (permalink / raw) To: Alexey Kardashevskiy, Christophe Leroy, David Gibson Cc: Christophe Leroy, Peter Maydell, dbarboza, Mark Cave-Ayland, Greg Kurz, Wainer dos Santos Moschetta, QEMU Developers, Alexander Graf, qemu-ppc, Cédric Le Goater, Cleber Rosa, Hervé Poussineau, Philippe Mathieu-Daudé, Edgar E. Iglesias 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 ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms) 2021-10-05 6:42 ` Thomas Huth @ 2021-10-05 8:05 ` Alexey Kardashevskiy 2021-10-05 8:07 ` Thomas Huth 0 siblings, 1 reply; 93+ messages in thread From: Alexey Kardashevskiy @ 2021-10-05 8:05 UTC (permalink / raw) To: Thomas Huth, Christophe Leroy, David Gibson Cc: Christophe Leroy, Peter Maydell, dbarboza, Mark Cave-Ayland, Greg Kurz, Wainer dos Santos Moschetta, QEMU Developers, Alexander Graf, qemu-ppc, Cédric Le Goater, Cleber Rosa, Hervé Poussineau, Philippe Mathieu-Daudé, Edgar E. Iglesias 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 ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms) 2021-10-05 8:05 ` Alexey Kardashevskiy @ 2021-10-05 8:07 ` Thomas Huth 2021-10-05 8:51 ` Deprecate the ppc405 boards in QEMU? Thomas Huth 0 siblings, 1 reply; 93+ messages in thread From: Thomas Huth @ 2021-10-05 8:07 UTC (permalink / raw) To: Alexey Kardashevskiy, Christophe Leroy, David Gibson Cc: Christophe Leroy, Peter Maydell, dbarboza, Mark Cave-Ayland, Greg Kurz, Wainer dos Santos Moschetta, QEMU Developers, Alexander Graf, qemu-ppc, Cédric Le Goater, Cleber Rosa, Hervé Poussineau, Philippe Mathieu-Daudé, Edgar E. Iglesias 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 ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: Deprecate the ppc405 boards in QEMU? 2021-10-05 8:07 ` Thomas Huth @ 2021-10-05 8:51 ` Thomas Huth 2021-10-05 12:17 ` BALATON Zoltan 0 siblings, 1 reply; 93+ messages in thread From: Thomas Huth @ 2021-10-05 8:51 UTC (permalink / raw) To: Alexey Kardashevskiy, Christophe Leroy, David Gibson Cc: Christophe Leroy, Peter Maydell, dbarboza, Mark Cave-Ayland, Greg Kurz, Wainer dos Santos Moschetta, QEMU Developers, Alexander Graf, qemu-ppc, Cédric Le Goater, Cleber Rosa, Hervé Poussineau, Philippe Mathieu-Daudé, Edgar E. Iglesias 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 ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: Deprecate the ppc405 boards in QEMU? 2021-10-05 8:51 ` Deprecate the ppc405 boards in QEMU? Thomas Huth @ 2021-10-05 12:17 ` BALATON Zoltan 2021-10-05 12:35 ` Thomas Huth 0 siblings, 1 reply; 93+ messages in thread From: BALATON Zoltan @ 2021-10-05 12:17 UTC (permalink / raw) To: Thomas Huth Cc: Christophe Leroy, Peter Maydell, dbarboza, Alexey Kardashevskiy, Greg Kurz, Christophe Leroy, QEMU Developers, Cédric Le Goater, Alexander Graf, qemu-ppc, Wainer dos Santos Moschetta, Cleber Rosa, Hervé Poussineau, Philippe Mathieu-Daudé, David Gibson 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 ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: Deprecate the ppc405 boards in QEMU? 2021-10-05 12:17 ` BALATON Zoltan @ 2021-10-05 12:35 ` Thomas Huth 2021-10-05 21:53 ` BALATON Zoltan 0 siblings, 1 reply; 93+ messages in thread From: Thomas Huth @ 2021-10-05 12:35 UTC (permalink / raw) To: BALATON Zoltan Cc: Christophe Leroy, Peter Maydell, dbarboza, Alexey Kardashevskiy, Greg Kurz, Christophe Leroy, QEMU Developers, Cédric Le Goater, Alexander Graf, qemu-ppc, Wainer dos Santos Moschetta, Cleber Rosa, Hervé Poussineau, Philippe Mathieu-Daudé, David Gibson 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 ^ permalink raw reply related [flat|nested] 93+ messages in thread
* Re: Deprecate the ppc405 boards in QEMU? 2021-10-05 12:35 ` Thomas Huth @ 2021-10-05 21:53 ` BALATON Zoltan 2021-10-06 6:39 ` Thomas Huth 2021-10-06 7:25 ` Thomas Huth 0 siblings, 2 replies; 93+ messages in thread From: BALATON Zoltan @ 2021-10-05 21:53 UTC (permalink / raw) To: Thomas Huth Cc: Christophe Leroy, Peter Maydell, dbarboza, Alexey Kardashevskiy, Greg Kurz, Christophe Leroy, QEMU Developers, Cédric Le Goater, Alexander Graf, qemu-ppc, Wainer dos Santos Moschetta, Cleber Rosa, Hervé Poussineau, Philippe Mathieu-Daudé, David Gibson [-- 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 ^ permalink raw reply related [flat|nested] 93+ messages in thread
* Re: Deprecate the ppc405 boards in QEMU? 2021-10-05 21:53 ` BALATON Zoltan @ 2021-10-06 6:39 ` Thomas Huth 2021-10-06 7:25 ` Thomas Huth 1 sibling, 0 replies; 93+ messages in thread From: Thomas Huth @ 2021-10-06 6:39 UTC (permalink / raw) To: BALATON Zoltan Cc: Christophe Leroy, Peter Maydell, dbarboza, Alexey Kardashevskiy, Greg Kurz, Christophe Leroy, QEMU Developers, Cédric Le Goater, Alexander Graf, qemu-ppc, Wainer dos Santos Moschetta, Cleber Rosa, Hervé Poussineau, Philippe Mathieu-Daudé, David Gibson 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 ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: Deprecate the ppc405 boards in QEMU? 2021-10-05 21:53 ` BALATON Zoltan 2021-10-06 6:39 ` Thomas Huth @ 2021-10-06 7:25 ` Thomas Huth 2021-10-11 8:10 ` Thomas Huth 1 sibling, 1 reply; 93+ messages in thread From: Thomas Huth @ 2021-10-06 7:25 UTC (permalink / raw) To: BALATON Zoltan, QEMU Developers, Christophe Leroy Cc: Christophe Leroy, Peter Maydell, dbarboza, Alexey Kardashevskiy, Greg Kurz, Wainer dos Santos Moschetta, Alexander Graf, qemu-ppc, Cédric Le Goater, Cleber Rosa, Hervé Poussineau, Philippe Mathieu-Daudé, David Gibson [-- 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)); } ^ permalink raw reply related [flat|nested] 93+ messages in thread
* Re: Deprecate the ppc405 boards in QEMU? 2021-10-06 7:25 ` Thomas Huth @ 2021-10-11 8:10 ` Thomas Huth 2021-10-11 9:20 ` David Gibson 0 siblings, 1 reply; 93+ messages in thread From: Thomas Huth @ 2021-10-11 8:10 UTC (permalink / raw) To: BALATON Zoltan, QEMU Developers, Christophe Leroy Cc: Christophe Leroy, Peter Maydell, dbarboza, Alexey Kardashevskiy, Greg Kurz, Wainer dos Santos Moschetta, Alexander Graf, qemu-ppc, Cédric Le Goater, Cleber Rosa, Hervé Poussineau, Philippe Mathieu-Daudé, David Gibson 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 ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: Deprecate the ppc405 boards in QEMU? 2021-10-11 8:10 ` Thomas Huth @ 2021-10-11 9:20 ` David Gibson 2021-10-11 13:24 ` Thomas Huth 0 siblings, 1 reply; 93+ messages in thread From: David Gibson @ 2021-10-11 9:20 UTC (permalink / raw) To: Thomas Huth Cc: Christophe Leroy, Peter Maydell, dbarboza, Alexey Kardashevskiy, QEMU Developers, Christophe Leroy, Greg Kurz, Alexander Graf, qemu-ppc, Wainer dos Santos Moschetta, Cleber Rosa, Hervé Poussineau, Philippe Mathieu-Daudé, Cédric Le Goater [-- 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 --] ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: Deprecate the ppc405 boards in QEMU? 2021-10-11 9:20 ` David Gibson @ 2021-10-11 13:24 ` Thomas Huth 2021-10-19 9:31 ` Christophe Leroy 0 siblings, 1 reply; 93+ messages in thread From: Thomas Huth @ 2021-10-11 13:24 UTC (permalink / raw) To: David Gibson Cc: Christophe Leroy, Peter Maydell, dbarboza, Alexey Kardashevskiy, QEMU Developers, Christophe Leroy, Greg Kurz, Alexander Graf, qemu-ppc, Wainer dos Santos Moschetta, Cleber Rosa, Hervé Poussineau, Philippe Mathieu-Daudé, Cédric Le Goater 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 ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: Deprecate the ppc405 boards in QEMU? 2021-10-11 13:24 ` Thomas Huth @ 2021-10-19 9:31 ` Christophe Leroy 2021-10-19 9:39 ` Thomas Huth 2021-10-19 9:41 ` Deprecate the ppc405 boards in QEMU? Greg Kurz 0 siblings, 2 replies; 93+ messages in thread From: Christophe Leroy @ 2021-10-19 9:31 UTC (permalink / raw) To: Thomas Huth, David Gibson Cc: Christophe Leroy, Peter Maydell, dbarboza, Alexey Kardashevskiy, QEMU Developers, Wainer dos Santos Moschetta, Greg Kurz, Alexander Graf, qemu-ppc, Cédric Le Goater, Cleber Rosa, Hervé Poussineau, Philippe Mathieu-Daudé 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 ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: Deprecate the ppc405 boards in QEMU? 2021-10-19 9:31 ` Christophe Leroy @ 2021-10-19 9:39 ` Thomas Huth 2021-10-19 9:48 ` Christophe Leroy 2021-10-19 9:41 ` Deprecate the ppc405 boards in QEMU? Greg Kurz 1 sibling, 1 reply; 93+ messages in thread From: Thomas Huth @ 2021-10-19 9:39 UTC (permalink / raw) To: Christophe Leroy, David Gibson Cc: Christophe Leroy, Peter Maydell, dbarboza, Alexey Kardashevskiy, QEMU Developers, Wainer dos Santos Moschetta, Greg Kurz, Alexander Graf, qemu-ppc, Cédric Le Goater, Cleber Rosa, Hervé Poussineau, Philippe Mathieu-Daudé 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 ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: Deprecate the ppc405 boards in QEMU? 2021-10-19 9:39 ` Thomas Huth @ 2021-10-19 9:48 ` Christophe Leroy 2021-10-19 10:07 ` BALATON Zoltan 0 siblings, 1 reply; 93+ messages in thread From: Christophe Leroy @ 2021-10-19 9:48 UTC (permalink / raw) To: Thomas Huth Cc: Peter Maydell, dbarboza, Alexey Kardashevskiy, Greg Kurz, Wainer dos Santos Moschetta, QEMU Developers, Alexander Graf, qemu-ppc, Cédric Le Goater, Cleber Rosa, Hervé Poussineau, Philippe Mathieu-Daudé, David Gibson 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 ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: Deprecate the ppc405 boards in QEMU? 2021-10-19 9:48 ` Christophe Leroy @ 2021-10-19 10:07 ` BALATON Zoltan 2021-10-19 11:11 ` Thomas Huth 2021-10-20 10:12 ` CLI: Using -bios AND -kernel Philippe Mathieu-Daudé 0 siblings, 2 replies; 93+ messages in thread From: BALATON Zoltan @ 2021-10-19 10:07 UTC (permalink / raw) To: Christophe Leroy Cc: Peter Maydell, Thomas Huth, dbarboza, QEMU Developers, Wainer dos Santos Moschetta, Greg Kurz, Alexander Graf, qemu-ppc, Cédric Le Goater, Cleber Rosa, Hervé Poussineau, Philippe Mathieu-Daudé, David Gibson [-- 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 ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: Deprecate the ppc405 boards in QEMU? 2021-10-19 10:07 ` BALATON Zoltan @ 2021-10-19 11:11 ` Thomas Huth 2021-10-19 11:51 ` Christophe Leroy 2021-10-20 10:21 ` Philippe Mathieu-Daudé 2021-10-20 10:12 ` CLI: Using -bios AND -kernel Philippe Mathieu-Daudé 1 sibling, 2 replies; 93+ messages in thread From: Thomas Huth @ 2021-10-19 11:11 UTC (permalink / raw) To: BALATON Zoltan, Christophe Leroy Cc: Peter Maydell, dbarboza, QEMU Developers, Wainer dos Santos Moschetta, Greg Kurz, Alexander Graf, qemu-ppc, Cédric Le Goater, Cleber Rosa, Hervé Poussineau, Philippe Mathieu-Daudé, David Gibson 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 ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: Deprecate the ppc405 boards in QEMU? 2021-10-19 11:11 ` Thomas Huth @ 2021-10-19 11:51 ` Christophe Leroy 2021-10-19 12:38 ` BALATON Zoltan 2021-10-20 10:21 ` Philippe Mathieu-Daudé 1 sibling, 1 reply; 93+ messages in thread From: Christophe Leroy @ 2021-10-19 11:51 UTC (permalink / raw) To: Thomas Huth, BALATON Zoltan Cc: Peter Maydell, dbarboza, QEMU Developers, Wainer dos Santos Moschetta, Greg Kurz, Alexander Graf, qemu-ppc, Cédric Le Goater, Cleber Rosa, Hervé Poussineau, Philippe Mathieu-Daudé, David Gibson 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 ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: Deprecate the ppc405 boards in QEMU? 2021-10-19 11:51 ` Christophe Leroy @ 2021-10-19 12:38 ` BALATON Zoltan 2021-10-19 13:44 ` Christophe Leroy 0 siblings, 1 reply; 93+ messages in thread From: BALATON Zoltan @ 2021-10-19 12:38 UTC (permalink / raw) To: Christophe Leroy Cc: Peter Maydell, Thomas Huth, dbarboza, QEMU Developers, Wainer dos Santos Moschetta, Greg Kurz, Alexander Graf, qemu-ppc, Cédric Le Goater, Cleber Rosa, Hervé Poussineau, Philippe Mathieu-Daudé, David Gibson [-- 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 ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: Deprecate the ppc405 boards in QEMU? 2021-10-19 12:38 ` BALATON Zoltan @ 2021-10-19 13:44 ` Christophe Leroy 2021-10-19 14:24 ` Christophe Leroy 0 siblings, 1 reply; 93+ messages in thread From: Christophe Leroy @ 2021-10-19 13:44 UTC (permalink / raw) To: BALATON Zoltan Cc: Peter Maydell, Thomas Huth, dbarboza, QEMU Developers, Wainer dos Santos Moschetta, Greg Kurz, Alexander Graf, qemu-ppc, Cédric Le Goater, Cleber Rosa, Hervé Poussineau, Philippe Mathieu-Daudé, David Gibson 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 ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: Deprecate the ppc405 boards in QEMU? 2021-10-19 13:44 ` Christophe Leroy @ 2021-10-19 14:24 ` Christophe Leroy 2021-10-19 14:56 ` BALATON Zoltan 0 siblings, 1 reply; 93+ messages in thread From: Christophe Leroy @ 2021-10-19 14:24 UTC (permalink / raw) To: BALATON Zoltan Cc: Peter Maydell, Thomas Huth, dbarboza, QEMU Developers, Wainer dos Santos Moschetta, Greg Kurz, Alexander Graf, qemu-ppc, Cédric Le Goater, Cleber Rosa, Hervé Poussineau, Philippe Mathieu-Daudé, David Gibson 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 ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: Deprecate the ppc405 boards in QEMU? 2021-10-19 14:24 ` Christophe Leroy @ 2021-10-19 14:56 ` BALATON Zoltan 2021-10-19 16:12 ` Christophe Leroy 0 siblings, 1 reply; 93+ messages in thread From: BALATON Zoltan @ 2021-10-19 14:56 UTC (permalink / raw) To: Christophe Leroy Cc: Peter Maydell, Thomas Huth, dbarboza, QEMU Developers, Wainer dos Santos Moschetta, Greg Kurz, Alexander Graf, qemu-ppc, Cédric Le Goater, Cleber Rosa, Hervé Poussineau, Philippe Mathieu-Daudé, David Gibson [-- 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 ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: Deprecate the ppc405 boards in QEMU? 2021-10-19 14:56 ` BALATON Zoltan @ 2021-10-19 16:12 ` Christophe Leroy 2021-10-19 20:55 ` Cédric Le Goater 2021-10-19 21:30 ` Cédric Le Goater 0 siblings, 2 replies; 93+ messages in thread From: Christophe Leroy @ 2021-10-19 16:12 UTC (permalink / raw) To: BALATON Zoltan Cc: Peter Maydell, Thomas Huth, dbarboza, QEMU Developers, Wainer dos Santos Moschetta, Greg Kurz, Alexander Graf, qemu-ppc, Cédric Le Goater, Cleber Rosa, Hervé Poussineau, Philippe Mathieu-Daudé, David Gibson 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 ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: Deprecate the ppc405 boards in QEMU? 2021-10-19 16:12 ` Christophe Leroy @ 2021-10-19 20:55 ` Cédric Le Goater 2021-10-19 21:30 ` Cédric Le Goater 1 sibling, 0 replies; 93+ messages in thread From: Cédric Le Goater @ 2021-10-19 20:55 UTC (permalink / raw) To: Christophe Leroy, BALATON Zoltan Cc: Peter Maydell, Thomas Huth, dbarboza, QEMU Developers, Wainer dos Santos Moschetta, Greg Kurz, Alexander Graf, qemu-ppc, Cleber Rosa, Hervé Poussineau, Philippe Mathieu-Daudé, David Gibson 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. ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: Deprecate the ppc405 boards in QEMU? 2021-10-19 16:12 ` Christophe Leroy 2021-10-19 20:55 ` Cédric Le Goater @ 2021-10-19 21:30 ` Cédric Le Goater 2021-10-20 9:02 ` Christophe Leroy 1 sibling, 1 reply; 93+ messages in thread From: Cédric Le Goater @ 2021-10-19 21:30 UTC (permalink / raw) To: Christophe Leroy, BALATON Zoltan Cc: Peter Maydell, Thomas Huth, dbarboza, QEMU Developers, Wainer dos Santos Moschetta, Greg Kurz, Alexander Graf, qemu-ppc, Cleber Rosa, Hervé Poussineau, Philippe Mathieu-Daudé, David Gibson 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 ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: Deprecate the ppc405 boards in QEMU? 2021-10-19 21:30 ` Cédric Le Goater @ 2021-10-20 9:02 ` Christophe Leroy 2021-10-20 10:10 ` Cédric Le Goater 0 siblings, 1 reply; 93+ messages in thread From: Christophe Leroy @ 2021-10-20 9:02 UTC (permalink / raw) To: Cédric Le Goater, BALATON Zoltan Cc: Peter Maydell, Thomas Huth, dbarboza, QEMU Developers, Wainer dos Santos Moschetta, Greg Kurz, Alexander Graf, qemu-ppc, Cleber Rosa, Hervé Poussineau, Philippe Mathieu-Daudé, David Gibson 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 ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: Deprecate the ppc405 boards in QEMU? 2021-10-20 9:02 ` Christophe Leroy @ 2021-10-20 10:10 ` Cédric Le Goater 2021-10-20 13:27 ` LEROY Christophe 0 siblings, 1 reply; 93+ messages in thread From: Cédric Le Goater @ 2021-10-20 10:10 UTC (permalink / raw) To: Christophe Leroy, BALATON Zoltan Cc: Peter Maydell, Thomas Huth, dbarboza, QEMU Developers, Wainer dos Santos Moschetta, Greg Kurz, Alexander Graf, qemu-ppc, Cleber Rosa, Hervé Poussineau, Philippe Mathieu-Daudé, David Gibson 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. ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: Deprecate the ppc405 boards in QEMU? 2021-10-20 10:10 ` Cédric Le Goater @ 2021-10-20 13:27 ` LEROY Christophe 2021-10-20 14:31 ` BALATON Zoltan 2021-10-20 14:39 ` Cédric Le Goater 0 siblings, 2 replies; 93+ messages in thread From: LEROY Christophe @ 2021-10-20 13:27 UTC (permalink / raw) To: Cédric Le Goater, BALATON Zoltan Cc: Peter Maydell, Thomas Huth, dbarboza, QEMU Developers, Wainer dos Santos Moschetta, Greg Kurz, Alexander Graf, qemu-ppc, Cleber Rosa, Hervé Poussineau, Philippe Mathieu-Daudé, David Gibson 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 ^ permalink raw reply related [flat|nested] 93+ messages in thread
* Re: Deprecate the ppc405 boards in QEMU? 2021-10-20 13:27 ` LEROY Christophe @ 2021-10-20 14:31 ` BALATON Zoltan 2021-10-20 14:34 ` Thomas Huth 2021-10-20 14:39 ` Cédric Le Goater 1 sibling, 1 reply; 93+ messages in thread From: BALATON Zoltan @ 2021-10-20 14:31 UTC (permalink / raw) To: LEROY Christophe Cc: Peter Maydell, Thomas Huth, dbarboza, Greg Kurz, Wainer dos Santos Moschetta, QEMU Developers, Alexander Graf, qemu-ppc, Cédric Le Goater, Cleber Rosa, Hervé Poussineau, Philippe Mathieu-Daudé, David Gibson [-- 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 ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: Deprecate the ppc405 boards in QEMU? 2021-10-20 14:31 ` BALATON Zoltan @ 2021-10-20 14:34 ` Thomas Huth 2021-10-20 14:41 ` Cédric Le Goater 0 siblings, 1 reply; 93+ messages in thread From: Thomas Huth @ 2021-10-20 14:34 UTC (permalink / raw) To: BALATON Zoltan, LEROY Christophe Cc: Peter Maydell, dbarboza, QEMU Developers, Wainer dos Santos Moschetta, Greg Kurz, Alexander Graf, qemu-ppc, Cédric Le Goater, Cleber Rosa, Hervé Poussineau, Philippe Mathieu-Daudé, David Gibson 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 ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: Deprecate the ppc405 boards in QEMU? 2021-10-20 14:34 ` Thomas Huth @ 2021-10-20 14:41 ` Cédric Le Goater 2021-10-20 15:03 ` LEROY Christophe 0 siblings, 1 reply; 93+ messages in thread From: Cédric Le Goater @ 2021-10-20 14:41 UTC (permalink / raw) To: Thomas Huth, BALATON Zoltan, LEROY Christophe Cc: Peter Maydell, dbarboza, QEMU Developers, Wainer dos Santos Moschetta, Greg Kurz, Alexander Graf, qemu-ppc, Cleber Rosa, Hervé Poussineau, Philippe Mathieu-Daudé, David Gibson 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 ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: Deprecate the ppc405 boards in QEMU? 2021-10-20 14:41 ` Cédric Le Goater @ 2021-10-20 15:03 ` LEROY Christophe 0 siblings, 0 replies; 93+ messages in thread From: LEROY Christophe @ 2021-10-20 15:03 UTC (permalink / raw) To: Cédric Le Goater, Thomas Huth, BALATON Zoltan Cc: Peter Maydell, dbarboza, QEMU Developers, Wainer dos Santos Moschetta, Greg Kurz, Alexander Graf, qemu-ppc, Cleber Rosa, Hervé Poussineau, Philippe Mathieu-Daudé, David Gibson 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 ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: Deprecate the ppc405 boards in QEMU? 2021-10-20 13:27 ` LEROY Christophe 2021-10-20 14:31 ` BALATON Zoltan @ 2021-10-20 14:39 ` Cédric Le Goater 2021-10-20 15:28 ` LEROY Christophe 1 sibling, 1 reply; 93+ messages in thread From: Cédric Le Goater @ 2021-10-20 14:39 UTC (permalink / raw) To: LEROY Christophe, BALATON Zoltan Cc: Peter Maydell, Thomas Huth, dbarboza, QEMU Developers, Wainer dos Santos Moschetta, Greg Kurz, Alexander Graf, qemu-ppc, Cleber Rosa, Hervé Poussineau, Philippe Mathieu-Daudé, David Gibson 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 > ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: Deprecate the ppc405 boards in QEMU? 2021-10-20 14:39 ` Cédric Le Goater @ 2021-10-20 15:28 ` LEROY Christophe 0 siblings, 0 replies; 93+ messages in thread From: LEROY Christophe @ 2021-10-20 15:28 UTC (permalink / raw) To: Cédric Le Goater, BALATON Zoltan Cc: Peter Maydell, Thomas Huth, dbarboza, QEMU Developers, Wainer dos Santos Moschetta, Greg Kurz, Alexander Graf, qemu-ppc, Cleber Rosa, Hervé Poussineau, Philippe Mathieu-Daudé, David Gibson 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 ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: Deprecate the ppc405 boards in QEMU? 2021-10-19 11:11 ` Thomas Huth 2021-10-19 11:51 ` Christophe Leroy @ 2021-10-20 10:21 ` Philippe Mathieu-Daudé 2021-10-20 11:40 ` BALATON Zoltan 1 sibling, 1 reply; 93+ messages in thread From: Philippe Mathieu-Daudé @ 2021-10-20 10:21 UTC (permalink / raw) To: Thomas Huth, BALATON Zoltan, Christophe Leroy Cc: Peter Maydell, dbarboza, QEMU Developers, Wainer dos Santos Moschetta, Greg Kurz, Alexander Graf, qemu-ppc, Cédric Le Goater, Cleber Rosa, Hervé Poussineau, David Gibson 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... ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: Deprecate the ppc405 boards in QEMU? 2021-10-20 10:21 ` Philippe Mathieu-Daudé @ 2021-10-20 11:40 ` BALATON Zoltan 0 siblings, 0 replies; 93+ messages in thread From: BALATON Zoltan @ 2021-10-20 11:40 UTC (permalink / raw) To: Philippe Mathieu-Daudé Cc: Peter Maydell, Thomas Huth, dbarboza, Greg Kurz, Wainer dos Santos Moschetta, QEMU Developers, Alexander Graf, qemu-ppc, Christophe Leroy, Cleber Rosa, Hervé Poussineau, David Gibson, Cédric Le Goater [-- 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 ^ permalink raw reply [flat|nested] 93+ messages in thread
* CLI: Using -bios AND -kernel 2021-10-19 10:07 ` BALATON Zoltan 2021-10-19 11:11 ` Thomas Huth @ 2021-10-20 10:12 ` Philippe Mathieu-Daudé 2021-10-20 10:54 ` Thomas Huth 1 sibling, 1 reply; 93+ messages in thread From: Philippe Mathieu-Daudé @ 2021-10-20 10:12 UTC (permalink / raw) To: Markus Armbruster, Paolo Bonzini, John Snow Cc: Peter Maydell, Thomas Huth, dbarboza, QEMU Developers, Greg Kurz, Christophe Leroy, Alexander Graf, qemu-ppc, Wainer dos Santos Moschetta, Cleber Rosa, Hervé Poussineau, David Gibson, Cédric Le Goater 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. ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: CLI: Using -bios AND -kernel 2021-10-20 10:12 ` CLI: Using -bios AND -kernel Philippe Mathieu-Daudé @ 2021-10-20 10:54 ` Thomas Huth 2021-10-20 11:35 ` BALATON Zoltan 0 siblings, 1 reply; 93+ messages in thread From: Thomas Huth @ 2021-10-20 10:54 UTC (permalink / raw) To: Philippe Mathieu-Daudé, Markus Armbruster, Paolo Bonzini, John Snow Cc: Peter Maydell, dbarboza, QEMU Developers, Greg Kurz, Wainer dos Santos Moschetta, Alexander Graf, qemu-ppc, Christophe Leroy, Cleber Rosa, Hervé Poussineau, David Gibson, Cédric Le Goater 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 ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: CLI: Using -bios AND -kernel 2021-10-20 10:54 ` Thomas Huth @ 2021-10-20 11:35 ` BALATON Zoltan 0 siblings, 0 replies; 93+ messages in thread From: BALATON Zoltan @ 2021-10-20 11:35 UTC (permalink / raw) To: Thomas Huth Cc: Peter Maydell, dbarboza, QEMU Developers, Philippe Mathieu-Daudé, Hervé Poussineau, Markus Armbruster, Christophe Leroy, Greg Kurz, Alexander Graf, qemu-ppc, Wainer dos Santos Moschetta, Cleber Rosa, Paolo Bonzini, David Gibson, John Snow, Cédric Le Goater [-- 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 ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: Deprecate the ppc405 boards in QEMU? 2021-10-19 9:31 ` Christophe Leroy 2021-10-19 9:39 ` Thomas Huth @ 2021-10-19 9:41 ` Greg Kurz 1 sibling, 0 replies; 93+ messages in thread From: Greg Kurz @ 2021-10-19 9:41 UTC (permalink / raw) To: Christophe Leroy Cc: Christophe Leroy, Peter Maydell, Thomas Huth, dbarboza, Alexey Kardashevskiy, QEMU Developers, Wainer dos Santos Moschetta, Alexander Graf, qemu-ppc, Cédric Le Goater, Cleber Rosa, Hervé Poussineau, Philippe Mathieu-Daudé, David Gibson 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 ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms) 2021-10-05 6:18 ` Alexey Kardashevskiy 2021-10-05 6:42 ` Thomas Huth @ 2021-10-05 8:14 ` Cédric Le Goater 2021-10-05 12:20 ` BALATON Zoltan 1 sibling, 1 reply; 93+ messages in thread From: Cédric Le Goater @ 2021-10-05 8:14 UTC (permalink / raw) To: Alexey Kardashevskiy, Christophe Leroy, David Gibson, Thomas Huth Cc: Christophe Leroy, Peter Maydell, dbarboza, Mark Cave-Ayland, Greg Kurz, Wainer dos Santos Moschetta, QEMU Developers, Alexander Graf, qemu-ppc, Cleber Rosa, Hervé Poussineau, Philippe Mathieu-Daudé, Edgar E. Iglesias 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 ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms) 2021-10-05 8:14 ` Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms) Cédric Le Goater @ 2021-10-05 12:20 ` BALATON Zoltan 2021-10-05 12:29 ` Thomas Huth 0 siblings, 1 reply; 93+ messages in thread From: BALATON Zoltan @ 2021-10-05 12:20 UTC (permalink / raw) To: Cédric Le Goater Cc: Christophe Leroy, Peter Maydell, Thomas Huth, dbarboza, Alexey Kardashevskiy, Greg Kurz, Christophe Leroy, QEMU Developers, Alexander Graf, qemu-ppc, Wainer dos Santos Moschetta, Cleber Rosa, Hervé Poussineau, Philippe Mathieu-Daudé, David Gibson [-- 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 ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms) 2021-10-05 12:20 ` BALATON Zoltan @ 2021-10-05 12:29 ` Thomas Huth 2021-10-20 10:26 ` Philippe Mathieu-Daudé 0 siblings, 1 reply; 93+ messages in thread From: Thomas Huth @ 2021-10-05 12:29 UTC (permalink / raw) To: BALATON Zoltan, Cédric Le Goater Cc: Christophe Leroy, Peter Maydell, dbarboza, Alexey Kardashevskiy, Greg Kurz, Christophe Leroy, QEMU Developers, Alexander Graf, qemu-ppc, Wainer dos Santos Moschetta, Cleber Rosa, Hervé Poussineau, Philippe Mathieu-Daudé, David Gibson 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 ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms) 2021-10-05 12:29 ` Thomas Huth @ 2021-10-20 10:26 ` Philippe Mathieu-Daudé 2021-10-20 11:42 ` BALATON Zoltan 0 siblings, 1 reply; 93+ messages in thread From: Philippe Mathieu-Daudé @ 2021-10-20 10:26 UTC (permalink / raw) To: Thomas Huth, BALATON Zoltan, Cédric Le Goater, Richard Henderson Cc: Christophe Leroy, Peter Maydell, dbarboza, Alexey Kardashevskiy, Greg Kurz, Christophe Leroy, QEMU Developers, Alexander Graf, qemu-ppc, Wainer dos Santos Moschetta, Cleber Rosa, Hervé Poussineau, David Gibson +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? ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms) 2021-10-20 10:26 ` Philippe Mathieu-Daudé @ 2021-10-20 11:42 ` BALATON Zoltan 2021-10-20 12:43 ` Cédric Le Goater 0 siblings, 1 reply; 93+ messages in thread From: BALATON Zoltan @ 2021-10-20 11:42 UTC (permalink / raw) To: Philippe Mathieu-Daudé Cc: Christophe Leroy, Peter Maydell, Thomas Huth, dbarboza, Wainer dos Santos Moschetta, Alexey Kardashevskiy, Richard Henderson, Greg Kurz, Christophe Leroy, QEMU Developers, Alexander Graf, qemu-ppc, Cédric Le Goater, Cleber Rosa, Hervé Poussineau, David Gibson [-- 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 ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms) 2021-10-20 11:42 ` BALATON Zoltan @ 2021-10-20 12:43 ` Cédric Le Goater 2021-10-20 13:16 ` LEROY Christophe ` (2 more replies) 0 siblings, 3 replies; 93+ messages in thread From: Cédric Le Goater @ 2021-10-20 12:43 UTC (permalink / raw) To: BALATON Zoltan, Philippe Mathieu-Daudé Cc: Christophe Leroy, Peter Maydell, Thomas Huth, dbarboza, Alexey Kardashevskiy, Richard Henderson, Greg Kurz, Christophe Leroy, QEMU Developers, Alexander Graf, qemu-ppc, Wainer dos Santos Moschetta, Cleber Rosa, Hervé Poussineau, David Gibson 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 ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms) 2021-10-20 12:43 ` Cédric Le Goater @ 2021-10-20 13:16 ` LEROY Christophe 2021-10-20 15:04 ` Simon Marchi ` (2 more replies) 2021-10-20 13:35 ` Deprecate the ppc405 boards in QEMU? Thomas Huth 2021-10-20 14:16 ` Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms) BALATON Zoltan 2 siblings, 3 replies; 93+ messages in thread From: LEROY Christophe @ 2021-10-20 13:16 UTC (permalink / raw) To: Cédric Le Goater, BALATON Zoltan, Philippe Mathieu-Daudé Cc: Peter Maydell, Thomas Huth, dbarboza, Alexey Kardashevskiy, gdb, Richard Henderson, Greg Kurz, Wainer dos Santos Moschetta, QEMU Developers, Alexander Graf, qemu-ppc, Cleber Rosa, Hervé Poussineau, David Gibson 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. ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms) 2021-10-20 13:16 ` LEROY Christophe @ 2021-10-20 15:04 ` Simon Marchi 2021-10-21 6:48 ` Christophe Leroy 2021-10-28 12:24 ` Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms) Luis Machado 2 siblings, 0 replies; 93+ messages in thread From: Simon Marchi @ 2021-10-20 15:04 UTC (permalink / raw) To: LEROY Christophe, Cédric Le Goater, BALATON Zoltan, Philippe Mathieu-Daudé Cc: Peter Maydell, Thomas Huth, dbarboza, Alexey Kardashevskiy, gdb, Richard Henderson, Greg Kurz, Wainer dos Santos Moschetta, QEMU Developers, Alexander Graf, qemu-ppc, Hervé Poussineau, David Gibson 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 ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms) 2021-10-20 13:16 ` LEROY Christophe 2021-10-20 15:04 ` Simon Marchi @ 2021-10-21 6:48 ` Christophe Leroy 2021-10-21 7:25 ` Deprecate the ppc405 boards in QEMU? Thomas Huth 2021-10-28 12:24 ` Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms) Luis Machado 2 siblings, 1 reply; 93+ messages in thread From: Christophe Leroy @ 2021-10-21 6:48 UTC (permalink / raw) To: Cédric Le Goater, BALATON Zoltan, Philippe Mathieu-Daudé Cc: Peter Maydell, Thomas Huth, dbarboza, Alexey Kardashevskiy, Richard Henderson, Greg Kurz, Wainer dos Santos Moschetta, QEMU Developers, Alexander Graf, qemu-ppc, Cleber Rosa, Hervé Poussineau, David Gibson 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 ^ permalink raw reply related [flat|nested] 93+ messages in thread
* Re: Deprecate the ppc405 boards in QEMU? 2021-10-21 6:48 ` Christophe Leroy @ 2021-10-21 7:25 ` Thomas Huth 2021-10-21 8:01 ` Christophe Leroy 0 siblings, 1 reply; 93+ messages in thread From: Thomas Huth @ 2021-10-21 7:25 UTC (permalink / raw) To: Christophe Leroy, Cédric Le Goater, BALATON Zoltan, Philippe Mathieu-Daudé, Richard Henderson Cc: Peter Maydell, dbarboza, Alexey Kardashevskiy, Greg Kurz, Wainer dos Santos Moschetta, QEMU Developers, Alexander Graf, qemu-ppc, Cleber Rosa, Hervé Poussineau, David Gibson 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 ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: Deprecate the ppc405 boards in QEMU? 2021-10-21 7:25 ` Deprecate the ppc405 boards in QEMU? Thomas Huth @ 2021-10-21 8:01 ` Christophe Leroy 0 siblings, 0 replies; 93+ messages in thread From: Christophe Leroy @ 2021-10-21 8:01 UTC (permalink / raw) To: Thomas Huth, Cédric Le Goater, BALATON Zoltan, Philippe Mathieu-Daudé, Richard Henderson Cc: Peter Maydell, dbarboza, Alexey Kardashevskiy, Greg Kurz, Wainer dos Santos Moschetta, QEMU Developers, Alexander Graf, qemu-ppc, Cleber Rosa, Hervé Poussineau, David Gibson 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 ^ permalink raw reply related [flat|nested] 93+ messages in thread
* Re: Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms) 2021-10-20 13:16 ` LEROY Christophe 2021-10-20 15:04 ` Simon Marchi 2021-10-21 6:48 ` Christophe Leroy @ 2021-10-28 12:24 ` Luis Machado 2021-10-28 17:27 ` Christophe Leroy 2 siblings, 1 reply; 93+ messages in thread From: Luis Machado @ 2021-10-28 12:24 UTC (permalink / raw) To: LEROY Christophe, Cédric Le Goater, BALATON Zoltan, Philippe Mathieu-Daudé Cc: Peter Maydell, Thomas Huth, dbarboza, Alexey Kardashevskiy, gdb, Richard Henderson, Greg Kurz, Wainer dos Santos Moschetta, QEMU Developers, Alexander Graf, qemu-ppc, Hervé Poussineau, David Gibson 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? ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms) 2021-10-28 12:24 ` Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms) Luis Machado @ 2021-10-28 17:27 ` Christophe Leroy 0 siblings, 0 replies; 93+ messages in thread From: Christophe Leroy @ 2021-10-28 17:27 UTC (permalink / raw) To: Luis Machado, Cédric Le Goater, BALATON Zoltan, Philippe Mathieu-Daudé Cc: Peter Maydell, Thomas Huth, dbarboza, Alexey Kardashevskiy, gdb, Richard Henderson, Greg Kurz, Wainer dos Santos Moschetta, QEMU Developers, Alexander Graf, qemu-ppc, Hervé Poussineau, David Gibson 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 ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: Deprecate the ppc405 boards in QEMU? 2021-10-20 12:43 ` Cédric Le Goater 2021-10-20 13:16 ` LEROY Christophe @ 2021-10-20 13:35 ` Thomas Huth 2021-10-20 14:55 ` BALATON Zoltan 2021-10-20 14:16 ` Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms) BALATON Zoltan 2 siblings, 1 reply; 93+ messages in thread From: Thomas Huth @ 2021-10-20 13:35 UTC (permalink / raw) To: Cédric Le Goater, BALATON Zoltan, Philippe Mathieu-Daudé Cc: Christophe Leroy, Peter Maydell, dbarboza, Alexey Kardashevskiy, Richard Henderson, Greg Kurz, Christophe Leroy, QEMU Developers, Alexander Graf, qemu-ppc, Wainer dos Santos Moschetta, Cleber Rosa, Hervé Poussineau, David Gibson 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 ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: Deprecate the ppc405 boards in QEMU? 2021-10-20 13:35 ` Deprecate the ppc405 boards in QEMU? Thomas Huth @ 2021-10-20 14:55 ` BALATON Zoltan 2021-10-20 15:04 ` Thomas Huth 0 siblings, 1 reply; 93+ messages in thread From: BALATON Zoltan @ 2021-10-20 14:55 UTC (permalink / raw) To: Thomas Huth Cc: Christophe Leroy, Peter Maydell, QEMU Developers, dbarboza, Wainer dos Santos Moschetta, Alexey Kardashevskiy, Richard Henderson, Philippe Mathieu-Daudé, Christophe Leroy, Greg Kurz, Alexander Graf, qemu-ppc, Cédric Le Goater, Cleber Rosa, Hervé Poussineau, David Gibson [-- 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 ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: Deprecate the ppc405 boards in QEMU? 2021-10-20 14:55 ` BALATON Zoltan @ 2021-10-20 15:04 ` Thomas Huth 0 siblings, 0 replies; 93+ messages in thread From: Thomas Huth @ 2021-10-20 15:04 UTC (permalink / raw) To: BALATON Zoltan Cc: Christophe Leroy, Peter Maydell, QEMU Developers, dbarboza, Wainer dos Santos Moschetta, Alexey Kardashevskiy, Richard Henderson, Philippe Mathieu-Daudé, Christophe Leroy, Greg Kurz, Alexander Graf, qemu-ppc, Cédric Le Goater, Cleber Rosa, Hervé Poussineau, David Gibson 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 ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms) 2021-10-20 12:43 ` Cédric Le Goater 2021-10-20 13:16 ` LEROY Christophe 2021-10-20 13:35 ` Deprecate the ppc405 boards in QEMU? Thomas Huth @ 2021-10-20 14:16 ` BALATON Zoltan 2 siblings, 0 replies; 93+ messages in thread From: BALATON Zoltan @ 2021-10-20 14:16 UTC (permalink / raw) To: Cédric Le Goater Cc: Christophe Leroy, Thomas Huth, QEMU Developers, Philippe Mathieu-Daudé, Greg Kurz, qemu-ppc, Cleber Rosa, Hervé Poussineau, David Gibson [-- 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 ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms) 2021-10-05 4:44 ` Christophe Leroy 2021-10-05 6:18 ` Alexey Kardashevskiy @ 2021-10-05 8:49 ` Daniel P. Berrangé 2021-10-05 16:15 ` Philippe Mathieu-Daudé 1 sibling, 1 reply; 93+ messages in thread From: Daniel P. Berrangé @ 2021-10-05 8:49 UTC (permalink / raw) To: Christophe Leroy Cc: Christophe Leroy, Peter Maydell, Thomas Huth, dbarboza, Alexey Kardashevskiy, Mark Cave-Ayland, QEMU Developers, Wainer dos Santos Moschetta, Greg Kurz, Alexander Graf, qemu-ppc, Cédric Le Goater, Cleber Rosa, Hervé Poussineau, Philippe Mathieu-Daudé, Edgar E. Iglesias, David Gibson 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 :| ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms) 2021-10-05 8:49 ` Daniel P. Berrangé @ 2021-10-05 16:15 ` Philippe Mathieu-Daudé 2021-10-05 16:20 ` Daniel P. Berrangé 0 siblings, 1 reply; 93+ messages in thread From: Philippe Mathieu-Daudé @ 2021-10-05 16:15 UTC (permalink / raw) To: Daniel P. Berrangé, Christophe Leroy Cc: Christophe Leroy, Peter Maydell, Thomas Huth, dbarboza, Alexey Kardashevskiy, Mark Cave-Ayland, QEMU Developers, Wainer dos Santos Moschetta, Greg Kurz, Alexander Graf, qemu-ppc, Cédric Le Goater, Cleber Rosa, Hervé Poussineau, Edgar E. Iglesias, David Gibson 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 :) ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms) 2021-10-05 16:15 ` Philippe Mathieu-Daudé @ 2021-10-05 16:20 ` Daniel P. Berrangé 2021-10-27 4:06 ` Philippe Mathieu-Daudé 0 siblings, 1 reply; 93+ messages in thread From: Daniel P. Berrangé @ 2021-10-05 16:20 UTC (permalink / raw) To: Philippe Mathieu-Daudé Cc: Christophe Leroy, Peter Maydell, Thomas Huth, dbarboza, Alexey Kardashevskiy, Mark Cave-Ayland, QEMU Developers, Christophe Leroy, Greg Kurz, Cédric Le Goater, Alexander Graf, qemu-ppc, Wainer dos Santos Moschetta, Cleber Rosa, Hervé Poussineau, Edgar E. Iglesias, David Gibson 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 :| ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms) 2021-10-05 16:20 ` Daniel P. Berrangé @ 2021-10-27 4:06 ` Philippe Mathieu-Daudé 2021-10-27 8:40 ` Cédric Le Goater 0 siblings, 1 reply; 93+ messages in thread From: Philippe Mathieu-Daudé @ 2021-10-27 4:06 UTC (permalink / raw) To: Daniel P. Berrangé Cc: Christophe Leroy, Peter Maydell, Thomas Huth, dbarboza, Alexey Kardashevskiy, Mark Cave-Ayland, QEMU Developers, Christophe Leroy, Greg Kurz, Alexander Graf, qemu-ppc, Cédric Le Goater, Cleber Rosa, Hervé Poussineau, David Gibson, Edgar E. Iglesias, Wainer dos Santos Moschetta 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. ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms) 2021-10-27 4:06 ` Philippe Mathieu-Daudé @ 2021-10-27 8:40 ` Cédric Le Goater 2021-10-27 10:42 ` Christophe Leroy 0 siblings, 1 reply; 93+ messages in thread From: Cédric Le Goater @ 2021-10-27 8:40 UTC (permalink / raw) To: Philippe Mathieu-Daudé, Daniel P. Berrangé Cc: Christophe Leroy, Peter Maydell, Thomas Huth, dbarboza, Alexey Kardashevskiy, Mark Cave-Ayland, QEMU Developers, Christophe Leroy, Greg Kurz, Alexander Graf, qemu-ppc, Wainer dos Santos Moschetta, Cleber Rosa, Hervé Poussineau, Edgar E. Iglesias, David Gibson >>> 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. ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms) 2021-10-27 8:40 ` Cédric Le Goater @ 2021-10-27 10:42 ` Christophe Leroy 2021-10-27 10:48 ` Philippe Mathieu-Daudé 2021-10-27 17:03 ` Cédric Le Goater 0 siblings, 2 replies; 93+ messages in thread From: Christophe Leroy @ 2021-10-27 10:42 UTC (permalink / raw) To: Cédric Le Goater, Philippe Mathieu-Daudé, Daniel P. Berrangé Cc: Christophe Leroy, Peter Maydell, Thomas Huth, dbarboza, Alexey Kardashevskiy, Mark Cave-Ayland, QEMU Developers, Wainer dos Santos Moschetta, Greg Kurz, Alexander Graf, qemu-ppc, Cleber Rosa, Hervé Poussineau, Edgar E. Iglesias, David Gibson 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 ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms) 2021-10-27 10:42 ` Christophe Leroy @ 2021-10-27 10:48 ` Philippe Mathieu-Daudé 2021-10-27 17:03 ` Cédric Le Goater 1 sibling, 0 replies; 93+ messages in thread From: Philippe Mathieu-Daudé @ 2021-10-27 10:48 UTC (permalink / raw) To: Christophe Leroy, Cédric Le Goater, Daniel P. Berrangé Cc: Christophe Leroy, Peter Maydell, Thomas Huth, dbarboza, Alexey Kardashevskiy, Mark Cave-Ayland, QEMU Developers, Wainer dos Santos Moschetta, Greg Kurz, Alexander Graf, qemu-ppc, Cleber Rosa, Hervé Poussineau, Edgar E. Iglesias, David Gibson 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. ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms) 2021-10-27 10:42 ` Christophe Leroy 2021-10-27 10:48 ` Philippe Mathieu-Daudé @ 2021-10-27 17:03 ` Cédric Le Goater 1 sibling, 0 replies; 93+ messages in thread From: Cédric Le Goater @ 2021-10-27 17:03 UTC (permalink / raw) To: Christophe Leroy, Philippe Mathieu-Daudé, Daniel P. Berrangé Cc: Christophe Leroy, Peter Maydell, Thomas Huth, dbarboza, Alexey Kardashevskiy, Mark Cave-Ayland, QEMU Developers, Wainer dos Santos Moschetta, Greg Kurz, Alexander Graf, qemu-ppc, Cleber Rosa, Hervé Poussineau, Edgar E. Iglesias, David Gibson 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.. ^ permalink raw reply [flat|nested] 93+ messages in thread
* [PATCH v3 5/7] MAINTAINERS: Remove David & Greg as reviewers/co-maintainers of powernv 2021-09-27 4:48 [PATCH v3 0/7] Reduce load on ppc target maintainers David Gibson ` (3 preceding siblings ...) 2021-09-27 4:48 ` [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms David Gibson @ 2021-09-27 4:48 ` David Gibson 2021-09-27 4:48 ` [PATCH v3 6/7] MAINTAINERS: Add information for OpenPIC David Gibson ` (2 subsequent siblings) 7 siblings, 0 replies; 93+ messages in thread From: David Gibson @ 2021-09-27 4:48 UTC (permalink / raw) To: qemu-devel, qemu-ppc Cc: peter.maydell, dbarboza, aik, mark.cave-ayland, groug, wainersm, hpoussin, clg, crosa, Edgar E. Iglesias, philmd, 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 ^ permalink raw reply related [flat|nested] 93+ messages in thread
* [PATCH v3 6/7] MAINTAINERS: Add information for OpenPIC 2021-09-27 4:48 [PATCH v3 0/7] Reduce load on ppc target maintainers David Gibson ` (4 preceding siblings ...) 2021-09-27 4:48 ` [PATCH v3 5/7] MAINTAINERS: Remove David & Greg as reviewers/co-maintainers of powernv David Gibson @ 2021-09-27 4:48 ` David Gibson 2021-09-29 7:08 ` Mark Cave-Ayland 2021-09-27 4:48 ` [PATCH v3 7/7] MAINTAINERS: Demote sPAPR from "Supported" to "Maintained" David Gibson 2021-09-30 1:15 ` [PATCH v3 0/7] Reduce load on ppc target maintainers David Gibson 7 siblings, 1 reply; 93+ messages in thread From: David Gibson @ 2021-09-27 4:48 UTC (permalink / raw) To: qemu-devel, qemu-ppc Cc: peter.maydell, dbarboza, aik, mark.cave-ayland, groug, wainersm, hpoussin, clg, crosa, Edgar E. Iglesias, philmd, 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 ^ permalink raw reply related [flat|nested] 93+ messages in thread
* Re: [PATCH v3 6/7] MAINTAINERS: Add information for OpenPIC 2021-09-27 4:48 ` [PATCH v3 6/7] MAINTAINERS: Add information for OpenPIC David Gibson @ 2021-09-29 7:08 ` Mark Cave-Ayland 0 siblings, 0 replies; 93+ messages in thread From: Mark Cave-Ayland @ 2021-09-29 7:08 UTC (permalink / raw) To: David Gibson, qemu-devel, qemu-ppc Cc: peter.maydell, dbarboza, aik, groug, wainersm, hpoussin, clg, crosa, Edgar E. Iglesias, philmd 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. ^ permalink raw reply [flat|nested] 93+ messages in thread
* [PATCH v3 7/7] MAINTAINERS: Demote sPAPR from "Supported" to "Maintained" 2021-09-27 4:48 [PATCH v3 0/7] Reduce load on ppc target maintainers David Gibson ` (5 preceding siblings ...) 2021-09-27 4:48 ` [PATCH v3 6/7] MAINTAINERS: Add information for OpenPIC David Gibson @ 2021-09-27 4:48 ` David Gibson 2021-09-30 1:15 ` [PATCH v3 0/7] Reduce load on ppc target maintainers David Gibson 7 siblings, 0 replies; 93+ messages in thread From: David Gibson @ 2021-09-27 4:48 UTC (permalink / raw) To: qemu-devel, qemu-ppc Cc: peter.maydell, dbarboza, aik, mark.cave-ayland, groug, wainersm, hpoussin, clg, crosa, Edgar E. Iglesias, philmd, 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 ^ permalink raw reply related [flat|nested] 93+ messages in thread
* Re: [PATCH v3 0/7] Reduce load on ppc target maintainers 2021-09-27 4:48 [PATCH v3 0/7] Reduce load on ppc target maintainers David Gibson ` (6 preceding siblings ...) 2021-09-27 4:48 ` [PATCH v3 7/7] MAINTAINERS: Demote sPAPR from "Supported" to "Maintained" David Gibson @ 2021-09-30 1:15 ` David Gibson 2021-10-06 9:52 ` Alexey Kardashevskiy 7 siblings, 1 reply; 93+ messages in thread From: David Gibson @ 2021-09-30 1:15 UTC (permalink / raw) To: qemu-devel, qemu-ppc Cc: peter.maydell, dbarboza, aik, mark.cave-ayland, groug, wainersm, hpoussin, clg, crosa, Edgar E. Iglesias, philmd [-- 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 --] ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v3 0/7] Reduce load on ppc target maintainers 2021-09-30 1:15 ` [PATCH v3 0/7] Reduce load on ppc target maintainers David Gibson @ 2021-10-06 9:52 ` Alexey Kardashevskiy 2021-10-06 11:03 ` Greg Kurz 0 siblings, 1 reply; 93+ messages in thread From: Alexey Kardashevskiy @ 2021-10-06 9:52 UTC (permalink / raw) To: David Gibson, qemu-devel, qemu-ppc Cc: peter.maydell, Thomas Huth, dbarboza, mark.cave-ayland, groug, wainersm, hpoussin, clg, crosa, Edgar E. Iglesias, philmd 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 ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v3 0/7] Reduce load on ppc target maintainers 2021-10-06 9:52 ` Alexey Kardashevskiy @ 2021-10-06 11:03 ` Greg Kurz 0 siblings, 0 replies; 93+ messages in thread From: Greg Kurz @ 2021-10-06 11:03 UTC (permalink / raw) To: Alexey Kardashevskiy Cc: qemu-ppc, Thomas Huth, dbarboza, peter.maydell, mark.cave-ayland, qemu-devel, wainersm, hpoussin, clg, crosa, Edgar E. Iglesias, philmd, David Gibson 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 :-) > > > ^ permalink raw reply [flat|nested] 93+ messages in thread
end of thread, other threads:[~2021-10-28 17:31 UTC | newest] Thread overview: 93+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-09-27 4:48 [PATCH v3 0/7] Reduce load on ppc target maintainers David Gibson 2021-09-27 4:48 ` [PATCH v3 1/7] qemu: Split machine_ppc.py acceptance tests David Gibson 2021-09-27 4:50 ` Philippe Mathieu-Daudé 2021-09-27 16:44 ` Philippe Mathieu-Daudé 2021-09-27 16:53 ` Cédric Le Goater 2021-09-27 17:18 ` Philippe Mathieu-Daudé 2021-09-27 4:48 ` [PATCH v3 2/7] MAINTAINERS: Remove machine specific files from ppc TCG CPUs entry David Gibson 2021-09-27 4:48 ` [PATCH v3 3/7] MAINTAINERS: Remove David & Greg as reviewers for a number of boards David Gibson 2021-09-27 4:48 ` [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms David Gibson 2021-10-01 8:35 ` Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms) Thomas Huth 2021-10-01 9:14 ` Christophe Leroy 2021-10-01 9:43 ` Thomas Huth 2021-10-01 11:12 ` Peter Maydell 2021-10-01 12:04 ` Thomas Huth 2021-10-01 13:04 ` Christophe Leroy 2021-10-01 13:14 ` Cédric Le Goater 2021-10-01 13:24 ` Peter Maydell 2021-10-01 14:18 ` Thomas Huth 2021-10-05 0:48 ` David Gibson 2021-10-05 4:44 ` Christophe Leroy 2021-10-05 6:18 ` Alexey Kardashevskiy 2021-10-05 6:42 ` Thomas Huth 2021-10-05 8:05 ` Alexey Kardashevskiy 2021-10-05 8:07 ` Thomas Huth 2021-10-05 8:51 ` Deprecate the ppc405 boards in QEMU? Thomas Huth 2021-10-05 12:17 ` BALATON Zoltan 2021-10-05 12:35 ` Thomas Huth 2021-10-05 21:53 ` BALATON Zoltan 2021-10-06 6:39 ` Thomas Huth 2021-10-06 7:25 ` Thomas Huth 2021-10-11 8:10 ` Thomas Huth 2021-10-11 9:20 ` David Gibson 2021-10-11 13:24 ` Thomas Huth 2021-10-19 9:31 ` Christophe Leroy 2021-10-19 9:39 ` Thomas Huth 2021-10-19 9:48 ` Christophe Leroy 2021-10-19 10:07 ` BALATON Zoltan 2021-10-19 11:11 ` Thomas Huth 2021-10-19 11:51 ` Christophe Leroy 2021-10-19 12:38 ` BALATON Zoltan 2021-10-19 13:44 ` Christophe Leroy 2021-10-19 14:24 ` Christophe Leroy 2021-10-19 14:56 ` BALATON Zoltan 2021-10-19 16:12 ` Christophe Leroy 2021-10-19 20:55 ` Cédric Le Goater 2021-10-19 21:30 ` Cédric Le Goater 2021-10-20 9:02 ` Christophe Leroy 2021-10-20 10:10 ` Cédric Le Goater 2021-10-20 13:27 ` LEROY Christophe 2021-10-20 14:31 ` BALATON Zoltan 2021-10-20 14:34 ` Thomas Huth 2021-10-20 14:41 ` Cédric Le Goater 2021-10-20 15:03 ` LEROY Christophe 2021-10-20 14:39 ` Cédric Le Goater 2021-10-20 15:28 ` LEROY Christophe 2021-10-20 10:21 ` Philippe Mathieu-Daudé 2021-10-20 11:40 ` BALATON Zoltan 2021-10-20 10:12 ` CLI: Using -bios AND -kernel Philippe Mathieu-Daudé 2021-10-20 10:54 ` Thomas Huth 2021-10-20 11:35 ` BALATON Zoltan 2021-10-19 9:41 ` Deprecate the ppc405 boards in QEMU? Greg Kurz 2021-10-05 8:14 ` Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms) Cédric Le Goater 2021-10-05 12:20 ` BALATON Zoltan 2021-10-05 12:29 ` Thomas Huth 2021-10-20 10:26 ` Philippe Mathieu-Daudé 2021-10-20 11:42 ` BALATON Zoltan 2021-10-20 12:43 ` Cédric Le Goater 2021-10-20 13:16 ` LEROY Christophe 2021-10-20 15:04 ` Simon Marchi 2021-10-21 6:48 ` Christophe Leroy 2021-10-21 7:25 ` Deprecate the ppc405 boards in QEMU? Thomas Huth 2021-10-21 8:01 ` Christophe Leroy 2021-10-28 12:24 ` Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms) Luis Machado 2021-10-28 17:27 ` Christophe Leroy 2021-10-20 13:35 ` Deprecate the ppc405 boards in QEMU? Thomas Huth 2021-10-20 14:55 ` BALATON Zoltan 2021-10-20 15:04 ` Thomas Huth 2021-10-20 14:16 ` Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms) BALATON Zoltan 2021-10-05 8:49 ` Daniel P. Berrangé 2021-10-05 16:15 ` Philippe Mathieu-Daudé 2021-10-05 16:20 ` Daniel P. Berrangé 2021-10-27 4:06 ` Philippe Mathieu-Daudé 2021-10-27 8:40 ` Cédric Le Goater 2021-10-27 10:42 ` Christophe Leroy 2021-10-27 10:48 ` Philippe Mathieu-Daudé 2021-10-27 17:03 ` Cédric Le Goater 2021-09-27 4:48 ` [PATCH v3 5/7] MAINTAINERS: Remove David & Greg as reviewers/co-maintainers of powernv David Gibson 2021-09-27 4:48 ` [PATCH v3 6/7] MAINTAINERS: Add information for OpenPIC David Gibson 2021-09-29 7:08 ` Mark Cave-Ayland 2021-09-27 4:48 ` [PATCH v3 7/7] MAINTAINERS: Demote sPAPR from "Supported" to "Maintained" David Gibson 2021-09-30 1:15 ` [PATCH v3 0/7] Reduce load on ppc target maintainers David Gibson 2021-10-06 9:52 ` Alexey Kardashevskiy 2021-10-06 11:03 ` Greg Kurz
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).