[PATCH 00/26] ppc: qemu: Convert qemu-ppce500 to driver model

At present when building qemu-ppce500 the following warnings are seen:
===================== WARNING ====================== This board does not use CONFIG_DM. CONFIG_DM will be compulsory starting with the v2020.01 release. Failure to update may result in board removal. UPD include/generated/timestamp_autogenerated.h See doc/driver-model/migration.rst for more info. ==================================================== ===================== WARNING ====================== This board does not use CONFIG_DM_PCI Please update the board to use CONFIG_DM_PCI before the v2019.07 release. Failure to update by the deadline may result in board removal. See doc/driver-model/migration.rst for more info. ==================================================== ===================== WARNING ====================== This board does not use CONFIG_DM_ETH (Driver Model for Ethernet drivers). Please update the board to use CONFIG_DM_ETH before the v2020.07 release. Failure to update by the deadline may result in board removal. See doc/driver-model/migration.rst for more info. ====================================================
The conversion of qemu-ppce500 board to driver model is long overdue.
When testing the exisitng qemu-ppce500 support, PCI was found broken. This is caused by 2 separate issues:
- One issue was caused by U-Boot: Commit e002474158d1 ("pci: pci-uclass: Dynamically allocate the PCI regions") Patch #1 reverts this commit as it broken all boards that have not converted to driver model PCI. - One issue was caused by QEMU: commit e6b4e5f4795b ("PPC: e500: Move CCSR and MMIO space to upper end of address space") commit cb3778a0455a ("PPC: e500 pci host: Add support for ATMUs") Patch #3-4 fixed this issue to keep in sync with latest QEMU upstream
Patch #5-8 are minor fixes and clean-ups.
Starting from patch#9, these are driver model conversion patches.
Patch #11-16 are mainly related to CONFIG_ADDR_MAP, a library to support targets that have non-identity virtual-physical address mappings. A new command 'addrmap' is introduced to aid debugging, and a fix to arch/powerpc/asm/include/io.h is made to correct the usage of CONFIG_ADDR_MAP as it can only be used in the post- relocation phase. Also the initialization of this library is moved a bit earlier in the post-relocation phase otherwise device drivers won't work.
Patch #18-20 are 85xx PCI driver fixes. It adds support to controller register physical address beyond 32-bit, as well as support to 64-bit bus and cpu address as current upstream QEMU uses 64-bit cpu address.
Patch #23 is minor fix to the 'virtio' command dependency.
Patch #24 enables the VirtIO NET support as by default a VirtIO standard PCI networking device is connected as an ethernet interface at PCI address 0.1.0.
Patch #25 moves the qemu-ppce500 boards codes to board/emulation as that is the place for other QEMU targets like x86, arm, riscv.
Patch #26 adds a reST document to describe how to build and run U-Boot for the QEMU ppce500 machine.
I hope we can make this series to U-Boot v2021.04 release.
This series is available at u-boot-x86/qemu-ppc for testing.
This cover letter is cc'ed to QEMU mailing list for a heads-up. A future patch will be sent to QEMU mailing list to bring its in-tree U-Boot source codes up-to-date.
Bin Meng (26): Revert "pci: pci-uclass: Dynamically allocate the PCI regions" ppc: qemu: Update MAINTAINERS for correct email address common: fdt_support: Support special case of PCI address in fdt_read_prop() ppc: qemu: Support non-identity PCI bus address ppc: qemu: Fix CONFIG_SYS_PCI_MAP_END ppc: mpc85xx: Wrap LAW related codes with CONFIG_FSL_LAW ppc: qemu: Drop init_laws() and print_laws() ppc: qemu: Drop board_early_init_f() ppc: qemu: Enable OF_CONTROL ppc: qemu: Enable driver model include: Remove extern from addr_map.h lib: addr_map: Move address_map[] type to the header file cmd: Add a command to display the address map lib: kconfig: Mention CONFIG_ADDR_MAP limitation in the help ppc: io.h: Use addrmap_ translation APIs only in post-relocation phase common: Move initr_addr_map() to a bit earlier ppc: qemu: Switch over to use DM serial pci: mpc85xx: Wrap LAW programming with CONFIG_FSL_LAW pci: mpc85xx: Support controller register physical address beyond 32-bit pci: mpc85xx: Support 64-bit bus and cpu address ppc: qemu: Switch over to use DM ETH and PCI ppc: qemu: Drop CONFIG_OF_BOARD_SETUP cmd: Fix virtio command dependency ppc: qemu: Enable VirtIO NET support ppc: qemu: Move board directory from board/freescale to board/emulation doc: Add a reST document for qemu-ppce500
arch/powerpc/cpu/mpc85xx/Kconfig | 2 +- arch/powerpc/cpu/mpc85xx/cpu.c | 2 + arch/powerpc/cpu/mpc85xx/cpu_init_early.c | 2 + arch/powerpc/include/asm/io.h | 15 +- .../{freescale => emulation}/qemu-ppce500/Kconfig | 2 +- board/emulation/qemu-ppce500/MAINTAINERS | 7 + .../{freescale => emulation}/qemu-ppce500/Makefile | 0 .../qemu-ppce500/qemu-ppce500.c | 159 ++++++--------------- board/freescale/qemu-ppce500/MAINTAINERS | 6 - cmd/Kconfig | 8 ++ cmd/Makefile | 1 + cmd/addrmap.c | 35 +++++ common/board_r.c | 6 +- common/fdt_support.c | 15 +- configs/qemu-ppce500_defconfig | 14 +- doc/board/emulation/index.rst | 1 + doc/board/emulation/qemu-ppce500.rst | 73 ++++++++++ drivers/pci/pci-uclass.c | 14 +- drivers/pci/pci_mpc85xx.c | 25 ++-- include/addr_map.h | 16 ++- include/configs/qemu-ppce500.h | 25 +--- include/pci.h | 4 +- lib/Kconfig | 2 + lib/addr_map.c | 6 +- 24 files changed, 250 insertions(+), 190 deletions(-) rename board/{freescale => emulation}/qemu-ppce500/Kconfig (86%) create mode 100644 board/emulation/qemu-ppce500/MAINTAINERS rename board/{freescale => emulation}/qemu-ppce500/Makefile (100%) rename board/{freescale => emulation}/qemu-ppce500/qemu-ppce500.c (68%) delete mode 100644 board/freescale/qemu-ppce500/MAINTAINERS create mode 100644 cmd/addrmap.c create mode 100644 doc/board/emulation/qemu-ppce500.rst

This reverts commit e002474158d1054a7a2ff9a66149384c639ff242.
Commit e002474158d1 ("pci: pci-uclass: Dynamically allocate the PCI regions") changes 'struct pci_controller'.regions from pre-allocated array of regions to dynamically allocated, which unfortunately broken lots of boards that still use the non-DM PCI driver.
We may update every non-DM PCI board codes to do the dynamical allocation of PCI regions but that's a lot of work (e.g.: almost all Freescale PowerPC boards are broken now and need to be fixed). Let's do the easy way.
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
drivers/pci/pci-uclass.c | 14 ++++++-------- include/pci.h | 4 +++- 2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c index ba65f47..8a94ea2 100644 --- a/drivers/pci/pci-uclass.c +++ b/drivers/pci/pci-uclass.c @@ -907,7 +907,6 @@ static void decode_regions(struct pci_controller *hose, ofnode parent_node, int cells_per_record; struct bd_info *bd; const u32 *prop; - int max_regions; int len; int i;
@@ -927,13 +926,7 @@ static void decode_regions(struct pci_controller *hose, ofnode parent_node, hose->region_count = 0; debug("%s: len=%d, cells_per_record=%d\n", __func__, len, cells_per_record); - - /* Dynamically allocate the regions array */ - max_regions = len / cells_per_record + CONFIG_NR_DRAM_BANKS; - hose->regions = (struct pci_region *) - calloc(1, max_regions * sizeof(struct pci_region)); - - for (i = 0; i < max_regions; i++, len -= cells_per_record) { + for (i = 0; i < MAX_PCI_REGIONS; i++, len -= cells_per_record) { u64 pci_addr, addr, size; int space_code; u32 flags; @@ -987,6 +980,11 @@ static void decode_regions(struct pci_controller *hose, ofnode parent_node, return;
for (i = 0; i < CONFIG_NR_DRAM_BANKS; ++i) { + if (hose->region_count == MAX_PCI_REGIONS) { + pr_err("maximum number of regions parsed, aborting\n"); + break; + } + if (bd->bi_dram[i].size) { pci_set_region(hose->regions + hose->region_count++, bd->bi_dram[i].start, diff --git a/include/pci.h b/include/pci.h index 5f36537..64dff55 100644 --- a/include/pci.h +++ b/include/pci.h @@ -610,6 +610,8 @@ extern void pci_cfgfunc_do_nothing(struct pci_controller* hose, pci_dev_t dev, extern void pci_cfgfunc_config_device(struct pci_controller* hose, pci_dev_t dev, struct pci_config_table *);
+#define MAX_PCI_REGIONS 7 + #define INDIRECT_TYPE_NO_PCIE_LINK 1
/** @@ -650,7 +652,7 @@ struct pci_controller { * for PCI controllers and a separate UCLASS (or perhaps * UCLASS_PCI_GENERIC) is used for bridges. */ - struct pci_region *regions; + struct pci_region regions[MAX_PCI_REGIONS]; int region_count;
struct pci_config_table *config_table;

Hi Bin,
On Sun, 7 Feb 2021 at 08:11, Bin Meng bmeng.cn@gmail.com wrote:
This reverts commit e002474158d1054a7a2ff9a66149384c639ff242.
Commit e002474158d1 ("pci: pci-uclass: Dynamically allocate the PCI regions") changes 'struct pci_controller'.regions from pre-allocated array of regions to dynamically allocated, which unfortunately broken lots of boards that still use the non-DM PCI driver.
We may update every non-DM PCI board codes to do the dynamical allocation of PCI regions but that's a lot of work (e.g.: almost all Freescale PowerPC boards are broken now and need to be fixed). Let's do the easy way.
No one has noticed since July, apparently. I think it would be better to disable PCI on these boards, until either someone migrates them or they are removed. The PCI deadline was about 18 months ago.
Tom, do you know the situation here?
Signed-off-by: Bin Meng bmeng.cn@gmail.com
drivers/pci/pci-uclass.c | 14 ++++++-------- include/pci.h | 4 +++- 2 files changed, 9 insertions(+), 9 deletions(-)
Regards, Simon

On Sun, Feb 07, 2021 at 08:33:50AM -0700, Simon Glass wrote:
Hi Bin,
On Sun, 7 Feb 2021 at 08:11, Bin Meng bmeng.cn@gmail.com wrote:
This reverts commit e002474158d1054a7a2ff9a66149384c639ff242.
Commit e002474158d1 ("pci: pci-uclass: Dynamically allocate the PCI regions") changes 'struct pci_controller'.regions from pre-allocated array of regions to dynamically allocated, which unfortunately broken lots of boards that still use the non-DM PCI driver.
We may update every non-DM PCI board codes to do the dynamical allocation of PCI regions but that's a lot of work (e.g.: almost all Freescale PowerPC boards are broken now and need to be fixed). Let's do the easy way.
No one has noticed since July, apparently. I think it would be better to disable PCI on these boards, until either someone migrates them or they are removed. The PCI deadline was about 18 months ago.
Tom, do you know the situation here?
I want to hear what Priyanka has to say, as there's been an effort a few times on NXP's part to remove boards they don't want to maintain anymore.
Outside of that, I do keep meaning to, but not quite finding the time to, pick a random well-past migration deadline, make it fatal, and then go start removing boards. I think I'll go pick a not-PCI (as some number of PowerPC ones will fail, and that's not as interesting until Priyanka can chime in) one right now and see what fails there.

Hi Simon,
On Sun, Feb 7, 2021 at 11:34 PM Simon Glass sjg@chromium.org wrote:
Hi Bin,
On Sun, 7 Feb 2021 at 08:11, Bin Meng bmeng.cn@gmail.com wrote:
This reverts commit e002474158d1054a7a2ff9a66149384c639ff242.
Commit e002474158d1 ("pci: pci-uclass: Dynamically allocate the PCI regions") changes 'struct pci_controller'.regions from pre-allocated array of regions to dynamically allocated, which unfortunately broken lots of boards that still use the non-DM PCI driver.
We may update every non-DM PCI board codes to do the dynamical allocation of PCI regions but that's a lot of work (e.g.: almost all Freescale PowerPC boards are broken now and need to be fixed). Let's do the easy way.
No one has noticed since July, apparently. I think it would be better to disable PCI on these boards, until either someone migrates them or they are removed. The PCI deadline was about 18 months ago.
Yep, but I'd like to keep this revert instead of just fixing the qemu-ppce500 here, to give people a chance to test their original non-DM version of PCI driver before the DM conversion.
Once all boards have converted to DM PCI, we can revert this revert patch again.
Tom, do you know the situation here?
Signed-off-by: Bin Meng bmeng.cn@gmail.com
drivers/pci/pci-uclass.c | 14 ++++++-------- include/pci.h | 4 +++- 2 files changed, 9 insertions(+), 9 deletions(-)
Regards, Bin

On Wed, Feb 10, 2021 at 08:46:51AM +0800, Bin Meng wrote:
Hi Simon,
On Sun, Feb 7, 2021 at 11:34 PM Simon Glass sjg@chromium.org wrote:
Hi Bin,
On Sun, 7 Feb 2021 at 08:11, Bin Meng bmeng.cn@gmail.com wrote:
This reverts commit e002474158d1054a7a2ff9a66149384c639ff242.
Commit e002474158d1 ("pci: pci-uclass: Dynamically allocate the PCI regions") changes 'struct pci_controller'.regions from pre-allocated array of regions to dynamically allocated, which unfortunately broken lots of boards that still use the non-DM PCI driver.
We may update every non-DM PCI board codes to do the dynamical allocation of PCI regions but that's a lot of work (e.g.: almost all Freescale PowerPC boards are broken now and need to be fixed). Let's do the easy way.
No one has noticed since July, apparently. I think it would be better to disable PCI on these boards, until either someone migrates them or they are removed. The PCI deadline was about 18 months ago.
Yep, but I'd like to keep this revert instead of just fixing the qemu-ppce500 here, to give people a chance to test their original non-DM version of PCI driver before the DM conversion.
Once all boards have converted to DM PCI, we can revert this revert patch again.
I'm not quite sure as a number of PowerPC boards did convert. I will see what's left, on top of the series I'm currently testing that deals with LIBATA+AHCI (and in turn kills off some PowerPC stuff).

Hi Bin,
On Tue, 9 Feb 2021 at 17:47, Bin Meng bmeng.cn@gmail.com wrote:
Hi Simon,
On Sun, Feb 7, 2021 at 11:34 PM Simon Glass sjg@chromium.org wrote:
Hi Bin,
On Sun, 7 Feb 2021 at 08:11, Bin Meng bmeng.cn@gmail.com wrote:
This reverts commit e002474158d1054a7a2ff9a66149384c639ff242.
Commit e002474158d1 ("pci: pci-uclass: Dynamically allocate the PCI regions") changes 'struct pci_controller'.regions from pre-allocated array of regions to dynamically allocated, which unfortunately broken lots of boards that still use the non-DM PCI driver.
We may update every non-DM PCI board codes to do the dynamical allocation of PCI regions but that's a lot of work (e.g.: almost all Freescale PowerPC boards are broken now and need to be fixed). Let's do the easy way.
No one has noticed since July, apparently. I think it would be better to disable PCI on these boards, until either someone migrates them or they are removed. The PCI deadline was about 18 months ago.
Yep, but I'd like to keep this revert instead of just fixing the qemu-ppce500 here, to give people a chance to test their original non-DM version of PCI driver before the DM conversion.
Once all boards have converted to DM PCI, we can revert this revert patch again.
I'm fine with that if Tom is. But deleting unmaintained code is always another option!
Tom, do you know the situation here?
Regards, Simon

Hi Simon, Bin & Tom,
On 10.02.21 06:10, Simon Glass wrote:
Hi Bin,
On Tue, 9 Feb 2021 at 17:47, Bin Meng bmeng.cn@gmail.com wrote:
Hi Simon,
On Sun, Feb 7, 2021 at 11:34 PM Simon Glass sjg@chromium.org wrote:
Hi Bin,
On Sun, 7 Feb 2021 at 08:11, Bin Meng bmeng.cn@gmail.com wrote:
This reverts commit e002474158d1054a7a2ff9a66149384c639ff242.
Commit e002474158d1 ("pci: pci-uclass: Dynamically allocate the PCI regions") changes 'struct pci_controller'.regions from pre-allocated array of regions to dynamically allocated, which unfortunately broken lots of boards that still use the non-DM PCI driver.
We may update every non-DM PCI board codes to do the dynamical allocation of PCI regions but that's a lot of work (e.g.: almost all Freescale PowerPC boards are broken now and need to be fixed). Let's do the easy way.
No one has noticed since July, apparently. I think it would be better to disable PCI on these boards, until either someone migrates them or they are removed. The PCI deadline was about 18 months ago.
Yep, but I'd like to keep this revert instead of just fixing the qemu-ppce500 here, to give people a chance to test their original non-DM version of PCI driver before the DM conversion.
Once all boards have converted to DM PCI, we can revert this revert patch again.
I'm fine with that if Tom is. But deleting unmaintained code is always another option!
Sorry for chiming in this late in this discussion. If we decide to revert this patch, this will break OcteonTX/TX2 support. As we need a higher value for the PCI regions here. Originally we just increased MAX_PCI_REGIONS to 10. This dynamic allocation superseeded this change. This increase might introduce size issues on other platforms though.
So please keep this in mind that with the revert the value of MAX_PCI_REGIONS needs to get increased to 10 - at least for Octeon TX.
Thanks, Stefan

On Wed, Feb 10, 2021 at 08:46:51AM +0800, Bin Meng wrote:
Hi Simon,
On Sun, Feb 7, 2021 at 11:34 PM Simon Glass sjg@chromium.org wrote:
Hi Bin,
On Sun, 7 Feb 2021 at 08:11, Bin Meng bmeng.cn@gmail.com wrote:
This reverts commit e002474158d1054a7a2ff9a66149384c639ff242.
Commit e002474158d1 ("pci: pci-uclass: Dynamically allocate the PCI regions") changes 'struct pci_controller'.regions from pre-allocated array of regions to dynamically allocated, which unfortunately broken lots of boards that still use the non-DM PCI driver.
We may update every non-DM PCI board codes to do the dynamical allocation of PCI regions but that's a lot of work (e.g.: almost all Freescale PowerPC boards are broken now and need to be fixed). Let's do the easy way.
No one has noticed since July, apparently. I think it would be better to disable PCI on these boards, until either someone migrates them or they are removed. The PCI deadline was about 18 months ago.
Yep, but I'd like to keep this revert instead of just fixing the qemu-ppce500 here, to give people a chance to test their original non-DM version of PCI driver before the DM conversion.
Once all boards have converted to DM PCI, we can revert this revert patch again.
Tom, do you know the situation here?
So, I made a lack of DM_PCI migration be fatal and got a build done here: https://gitlab.denx.de/u-boot/u-boot/-/pipelines/6348
Of note, MIPS malta fails, so I had to drop that from pytest to complete the world build. There's then a handful of ARM boards, another large chunk of PowerPC, and then a few others such as r7780mp. SH is the big what to do here to me, other than PowerPC, as other than r2dplus everything is missing the main "convert to DM" migration deadline as well.

On 2/10/21 3:13 PM, Tom Rini wrote:
On Wed, Feb 10, 2021 at 08:46:51AM +0800, Bin Meng wrote:
Hi Simon,
On Sun, Feb 7, 2021 at 11:34 PM Simon Glass sjg@chromium.org wrote:
Hi Bin,
On Sun, 7 Feb 2021 at 08:11, Bin Meng bmeng.cn@gmail.com wrote:
This reverts commit e002474158d1054a7a2ff9a66149384c639ff242.
Commit e002474158d1 ("pci: pci-uclass: Dynamically allocate the PCI regions") changes 'struct pci_controller'.regions from pre-allocated array of regions to dynamically allocated, which unfortunately broken lots of boards that still use the non-DM PCI driver.
We may update every non-DM PCI board codes to do the dynamical allocation of PCI regions but that's a lot of work (e.g.: almost all Freescale PowerPC boards are broken now and need to be fixed). Let's do the easy way.
No one has noticed since July, apparently. I think it would be better to disable PCI on these boards, until either someone migrates them or they are removed. The PCI deadline was about 18 months ago.
Yep, but I'd like to keep this revert instead of just fixing the qemu-ppce500 here, to give people a chance to test their original non-DM version of PCI driver before the DM conversion.
Once all boards have converted to DM PCI, we can revert this revert patch again.
Tom, do you know the situation here?
So, I made a lack of DM_PCI migration be fatal and got a build done here: https://gitlab.denx.de/u-boot/u-boot/-/pipelines/6348
Of note, MIPS malta fails, so I had to drop that from pytest to complete the world build. There's then a handful of ARM boards, another large chunk of PowerPC, and then a few others such as r7780mp. SH is the big what to do here to me, other than PowerPC, as other than r2dplus everything is missing the main "convert to DM" migration deadline as well.
Anything SH except r2dplus is likely dead.

On Wed, Feb 10, 2021 at 03:27:22PM +0100, Marek Vasut wrote:
On 2/10/21 3:13 PM, Tom Rini wrote:
On Wed, Feb 10, 2021 at 08:46:51AM +0800, Bin Meng wrote:
Hi Simon,
On Sun, Feb 7, 2021 at 11:34 PM Simon Glass sjg@chromium.org wrote:
Hi Bin,
On Sun, 7 Feb 2021 at 08:11, Bin Meng bmeng.cn@gmail.com wrote:
This reverts commit e002474158d1054a7a2ff9a66149384c639ff242.
Commit e002474158d1 ("pci: pci-uclass: Dynamically allocate the PCI regions") changes 'struct pci_controller'.regions from pre-allocated array of regions to dynamically allocated, which unfortunately broken lots of boards that still use the non-DM PCI driver.
We may update every non-DM PCI board codes to do the dynamical allocation of PCI regions but that's a lot of work (e.g.: almost all Freescale PowerPC boards are broken now and need to be fixed). Let's do the easy way.
No one has noticed since July, apparently. I think it would be better to disable PCI on these boards, until either someone migrates them or they are removed. The PCI deadline was about 18 months ago.
Yep, but I'd like to keep this revert instead of just fixing the qemu-ppce500 here, to give people a chance to test their original non-DM version of PCI driver before the DM conversion.
Once all boards have converted to DM PCI, we can revert this revert patch again.
Tom, do you know the situation here?
So, I made a lack of DM_PCI migration be fatal and got a build done here: https://gitlab.denx.de/u-boot/u-boot/-/pipelines/6348
Of note, MIPS malta fails, so I had to drop that from pytest to complete the world build. There's then a handful of ARM boards, another large chunk of PowerPC, and then a few others such as r7780mp. SH is the big what to do here to me, other than PowerPC, as other than r2dplus everything is missing the main "convert to DM" migration deadline as well.
Anything SH except r2dplus is likely dead.
Shall I send a series to remove most of the boards then?

On 2/10/21 3:48 PM, Tom Rini wrote:
On Wed, Feb 10, 2021 at 03:27:22PM +0100, Marek Vasut wrote:
On 2/10/21 3:13 PM, Tom Rini wrote:
On Wed, Feb 10, 2021 at 08:46:51AM +0800, Bin Meng wrote:
Hi Simon,
On Sun, Feb 7, 2021 at 11:34 PM Simon Glass sjg@chromium.org wrote:
Hi Bin,
On Sun, 7 Feb 2021 at 08:11, Bin Meng bmeng.cn@gmail.com wrote:
This reverts commit e002474158d1054a7a2ff9a66149384c639ff242.
Commit e002474158d1 ("pci: pci-uclass: Dynamically allocate the PCI regions") changes 'struct pci_controller'.regions from pre-allocated array of regions to dynamically allocated, which unfortunately broken lots of boards that still use the non-DM PCI driver.
We may update every non-DM PCI board codes to do the dynamical allocation of PCI regions but that's a lot of work (e.g.: almost all Freescale PowerPC boards are broken now and need to be fixed). Let's do the easy way.
No one has noticed since July, apparently. I think it would be better to disable PCI on these boards, until either someone migrates them or they are removed. The PCI deadline was about 18 months ago.
Yep, but I'd like to keep this revert instead of just fixing the qemu-ppce500 here, to give people a chance to test their original non-DM version of PCI driver before the DM conversion.
Once all boards have converted to DM PCI, we can revert this revert patch again.
Tom, do you know the situation here?
So, I made a lack of DM_PCI migration be fatal and got a build done here: https://gitlab.denx.de/u-boot/u-boot/-/pipelines/6348
Of note, MIPS malta fails, so I had to drop that from pytest to complete the world build. There's then a handful of ARM boards, another large chunk of PowerPC, and then a few others such as r7780mp. SH is the big what to do here to me, other than PowerPC, as other than r2dplus everything is missing the main "convert to DM" migration deadline as well.
Anything SH except r2dplus is likely dead.
Shall I send a series to remove most of the boards then?
You can.

Hi Tom,
On Wed, Feb 10, 2021 at 10:13 PM Tom Rini trini@konsulko.com wrote:
On Wed, Feb 10, 2021 at 08:46:51AM +0800, Bin Meng wrote:
Hi Simon,
On Sun, Feb 7, 2021 at 11:34 PM Simon Glass sjg@chromium.org wrote:
Hi Bin,
On Sun, 7 Feb 2021 at 08:11, Bin Meng bmeng.cn@gmail.com wrote:
This reverts commit e002474158d1054a7a2ff9a66149384c639ff242.
Commit e002474158d1 ("pci: pci-uclass: Dynamically allocate the PCI regions") changes 'struct pci_controller'.regions from pre-allocated array of regions to dynamically allocated, which unfortunately broken lots of boards that still use the non-DM PCI driver.
We may update every non-DM PCI board codes to do the dynamical allocation of PCI regions but that's a lot of work (e.g.: almost all Freescale PowerPC boards are broken now and need to be fixed). Let's do the easy way.
No one has noticed since July, apparently. I think it would be better to disable PCI on these boards, until either someone migrates them or they are removed. The PCI deadline was about 18 months ago.
Yep, but I'd like to keep this revert instead of just fixing the qemu-ppce500 here, to give people a chance to test their original non-DM version of PCI driver before the DM conversion.
Once all boards have converted to DM PCI, we can revert this revert patch again.
Tom, do you know the situation here?
So, I made a lack of DM_PCI migration be fatal and got a build done here: https://gitlab.denx.de/u-boot/u-boot/-/pipelines/6348
Of note, MIPS malta fails, so I had to drop that from pytest to complete the world build. There's then a handful of ARM boards, another large chunk of PowerPC, and then a few others such as r7780mp. SH is the big what to do here to me, other than PowerPC, as other than r2dplus everything is missing the main "convert to DM" migration deadline as well.
What should we do for this patch?
If the plan is to drop all boards that are not converted to DM PCI in 2021.04, I can drop this revert patch in v2.
Regards, Bin

On Sun, Feb 14, 2021 at 12:53:29PM +0800, Bin Meng wrote:
Hi Tom,
On Wed, Feb 10, 2021 at 10:13 PM Tom Rini trini@konsulko.com wrote:
On Wed, Feb 10, 2021 at 08:46:51AM +0800, Bin Meng wrote:
Hi Simon,
On Sun, Feb 7, 2021 at 11:34 PM Simon Glass sjg@chromium.org wrote:
Hi Bin,
On Sun, 7 Feb 2021 at 08:11, Bin Meng bmeng.cn@gmail.com wrote:
This reverts commit e002474158d1054a7a2ff9a66149384c639ff242.
Commit e002474158d1 ("pci: pci-uclass: Dynamically allocate the PCI regions") changes 'struct pci_controller'.regions from pre-allocated array of regions to dynamically allocated, which unfortunately broken lots of boards that still use the non-DM PCI driver.
We may update every non-DM PCI board codes to do the dynamical allocation of PCI regions but that's a lot of work (e.g.: almost all Freescale PowerPC boards are broken now and need to be fixed). Let's do the easy way.
No one has noticed since July, apparently. I think it would be better to disable PCI on these boards, until either someone migrates them or they are removed. The PCI deadline was about 18 months ago.
Yep, but I'd like to keep this revert instead of just fixing the qemu-ppce500 here, to give people a chance to test their original non-DM version of PCI driver before the DM conversion.
Once all boards have converted to DM PCI, we can revert this revert patch again.
Tom, do you know the situation here?
So, I made a lack of DM_PCI migration be fatal and got a build done here: https://gitlab.denx.de/u-boot/u-boot/-/pipelines/6348
Of note, MIPS malta fails, so I had to drop that from pytest to complete the world build. There's then a handful of ARM boards, another large chunk of PowerPC, and then a few others such as r7780mp. SH is the big what to do here to me, other than PowerPC, as other than r2dplus everything is missing the main "convert to DM" migration deadline as well.
What should we do for this patch?
If the plan is to drop all boards that are not converted to DM PCI in 2021.04, I can drop this revert patch in v2.
I've posted the patch to drop the SH boards. Daniel, what about Malta? I guess maybe the next steps are I need to pull in the already acked board removal patches I've posted and then do another posting of "remove these boards now" and see what shakes out.

On 2/14/21 3:35 PM, Tom Rini wrote:
On Sun, Feb 14, 2021 at 12:53:29PM +0800, Bin Meng wrote:
Hi Tom,
On Wed, Feb 10, 2021 at 10:13 PM Tom Rini trini@konsulko.com wrote:
On Wed, Feb 10, 2021 at 08:46:51AM +0800, Bin Meng wrote:
Hi Simon,
On Sun, Feb 7, 2021 at 11:34 PM Simon Glass sjg@chromium.org wrote:
Hi Bin,
On Sun, 7 Feb 2021 at 08:11, Bin Meng bmeng.cn@gmail.com wrote:
This reverts commit e002474158d1054a7a2ff9a66149384c639ff242.
Commit e002474158d1 ("pci: pci-uclass: Dynamically allocate the PCI regions") changes 'struct pci_controller'.regions from pre-allocated array of regions to dynamically allocated, which unfortunately broken lots of boards that still use the non-DM PCI driver.
We may update every non-DM PCI board codes to do the dynamical allocation of PCI regions but that's a lot of work (e.g.: almost all Freescale PowerPC boards are broken now and need to be fixed). Let's do the easy way.
No one has noticed since July, apparently. I think it would be better to disable PCI on these boards, until either someone migrates them or they are removed. The PCI deadline was about 18 months ago.
Yep, but I'd like to keep this revert instead of just fixing the qemu-ppce500 here, to give people a chance to test their original non-DM version of PCI driver before the DM conversion.
Once all boards have converted to DM PCI, we can revert this revert patch again.
Tom, do you know the situation here?
So, I made a lack of DM_PCI migration be fatal and got a build done here: https://gitlab.denx.de/u-boot/u-boot/-/pipelines/6348
Of note, MIPS malta fails, so I had to drop that from pytest to complete the world build. There's then a handful of ARM boards, another large chunk of PowerPC, and then a few others such as r7780mp. SH is the big what to do here to me, other than PowerPC, as other than r2dplus everything is missing the main "convert to DM" migration deadline as well.
What should we do for this patch?
If the plan is to drop all boards that are not converted to DM PCI in 2021.04, I can drop this revert patch in v2.
I've posted the patch to drop the SH boards. Daniel, what about Malta?
Malta should be fixed, since it's mips used in CI.
I guess maybe the next steps are I need to pull in the already acked board removal patches I've posted and then do another posting of "remove these boards now" and see what shakes out.
Yeah

On Sun, Feb 14, 2021 at 03:44:26PM +0100, Marek Vasut wrote:
On 2/14/21 3:35 PM, Tom Rini wrote:
On Sun, Feb 14, 2021 at 12:53:29PM +0800, Bin Meng wrote:
Hi Tom,
On Wed, Feb 10, 2021 at 10:13 PM Tom Rini trini@konsulko.com wrote:
On Wed, Feb 10, 2021 at 08:46:51AM +0800, Bin Meng wrote:
Hi Simon,
On Sun, Feb 7, 2021 at 11:34 PM Simon Glass sjg@chromium.org wrote:
Hi Bin,
On Sun, 7 Feb 2021 at 08:11, Bin Meng bmeng.cn@gmail.com wrote: > > This reverts commit e002474158d1054a7a2ff9a66149384c639ff242. > > Commit e002474158d1 ("pci: pci-uclass: Dynamically allocate the PCI regions") > changes 'struct pci_controller'.regions from pre-allocated array of > regions to dynamically allocated, which unfortunately broken lots of > boards that still use the non-DM PCI driver. > > We may update every non-DM PCI board codes to do the dynamical > allocation of PCI regions but that's a lot of work (e.g.: almost > all Freescale PowerPC boards are broken now and need to be fixed). > Let's do the easy way.
No one has noticed since July, apparently. I think it would be better to disable PCI on these boards, until either someone migrates them or they are removed. The PCI deadline was about 18 months ago.
Yep, but I'd like to keep this revert instead of just fixing the qemu-ppce500 here, to give people a chance to test their original non-DM version of PCI driver before the DM conversion.
Once all boards have converted to DM PCI, we can revert this revert patch again.
Tom, do you know the situation here?
So, I made a lack of DM_PCI migration be fatal and got a build done here: https://gitlab.denx.de/u-boot/u-boot/-/pipelines/6348
Of note, MIPS malta fails, so I had to drop that from pytest to complete the world build. There's then a handful of ARM boards, another large chunk of PowerPC, and then a few others such as r7780mp. SH is the big what to do here to me, other than PowerPC, as other than r2dplus everything is missing the main "convert to DM" migration deadline as well.
What should we do for this patch?
If the plan is to drop all boards that are not converted to DM PCI in 2021.04, I can drop this revert patch in v2.
I've posted the patch to drop the SH boards. Daniel, what about Malta?
Malta should be fixed, since it's mips used in CI.
There's also qemu_mips* in CI, so it depends on what Daniel thinks is the right overall answer here.

Am Sonntag, den 14.02.2021, 09:52 -0500 schrieb Tom Rini:
...
> Tom, do you know the situation here?
So, I made a lack of DM_PCI migration be fatal and got a build done here: https://gitlab.denx.de/u-boot/u-boot/-/pipelines/6348
Of note, MIPS malta fails, so I had to drop that from pytest to complete the world build. There's then a handful of ARM boards, another large chunk of PowerPC, and then a few others such as r7780mp. SH is the big what to do here to me, other than PowerPC, as other than r2dplus everything is missing the main "convert to DM" migration deadline as well.
What should we do for this patch?
If the plan is to drop all boards that are not converted to DM PCI in 2021.04, I can drop this revert patch in v2.
I've posted the patch to drop the SH boards. Daniel, what about Malta?
Malta should be fixed, since it's mips used in CI.
There's also qemu_mips* in CI, so it depends on what Daniel thinks is the right overall answer here.
Malta is the MIPS reference board physically as well as in Qemu. qemu_mips is actually deprecated and is going to be removed from Qemu sooner or later. That's why I added Malta to CI with the goal to remove qemu_mips.
The problem with MIPS and DM_PCI is that there are some generic issues with memory mapping and CONFIG_SYS_SDRAM_BASE being used as virtual address. Actually I have a pending patch queue from Paul Burton for Malta for converting to DM_PCI, but that requires resolving the generic issues with some refactoring for all MIPS boards. It's still on my TODO list ;)
Until I can spare enough time to resolve all issues, I could try to disable the PCI driver in Malta defconfig and mark the driver as broken in Kconfig. This way we can avoid removing the whole board.

On Sun, Feb 14, 2021 at 08:12:16PM +0100, Daniel Schwierzeck wrote:
Am Sonntag, den 14.02.2021, 09:52 -0500 schrieb Tom Rini:
...
> > > Tom, do you know the situation here?
So, I made a lack of DM_PCI migration be fatal and got a build done here: https://gitlab.denx.de/u-boot/u-boot/-/pipelines/6348
Of note, MIPS malta fails, so I had to drop that from pytest to complete the world build. There's then a handful of ARM boards, another large chunk of PowerPC, and then a few others such as r7780mp. SH is the big what to do here to me, other than PowerPC, as other than r2dplus everything is missing the main "convert to DM" migration deadline as well.
What should we do for this patch?
If the plan is to drop all boards that are not converted to DM PCI in 2021.04, I can drop this revert patch in v2.
I've posted the patch to drop the SH boards. Daniel, what about Malta?
Malta should be fixed, since it's mips used in CI.
There's also qemu_mips* in CI, so it depends on what Daniel thinks is the right overall answer here.
Malta is the MIPS reference board physically as well as in Qemu. qemu_mips is actually deprecated and is going to be removed from Qemu sooner or later. That's why I added Malta to CI with the goal to remove qemu_mips.
The problem with MIPS and DM_PCI is that there are some generic issues with memory mapping and CONFIG_SYS_SDRAM_BASE being used as virtual address. Actually I have a pending patch queue from Paul Burton for Malta for converting to DM_PCI, but that requires resolving the generic issues with some refactoring for all MIPS boards. It's still on my TODO list ;)
Until I can spare enough time to resolve all issues, I could try to disable the PCI driver in Malta defconfig and mark the driver as broken in Kconfig. This way we can avoid removing the whole board.
Thanks for explaining. Yes, lets go that route for now.

Hi Tom,
On Mon, Feb 15, 2021 at 4:30 AM Tom Rini trini@konsulko.com wrote:
On Sun, Feb 14, 2021 at 08:12:16PM +0100, Daniel Schwierzeck wrote:
Am Sonntag, den 14.02.2021, 09:52 -0500 schrieb Tom Rini:
...
> > > > > Tom, do you know the situation here? > > So, I made a lack of DM_PCI migration be fatal and got a > build done > here: > https://gitlab.denx.de/u-boot/u-boot/-/pipelines/6348 > > Of note, MIPS malta fails, so I had to drop that from pytest > to complete > the world build. There's then a handful of ARM boards, > another large > chunk of PowerPC, and then a few others such as r7780mp. SH > is the big > what to do here to me, other than PowerPC, as other than > r2dplus > everything is missing the main "convert to DM" migration > deadline as > well.
What should we do for this patch?
If the plan is to drop all boards that are not converted to DM PCI in 2021.04, I can drop this revert patch in v2.
I've posted the patch to drop the SH boards. Daniel, what about Malta?
Malta should be fixed, since it's mips used in CI.
There's also qemu_mips* in CI, so it depends on what Daniel thinks is the right overall answer here.
Malta is the MIPS reference board physically as well as in Qemu. qemu_mips is actually deprecated and is going to be removed from Qemu sooner or later. That's why I added Malta to CI with the goal to remove qemu_mips.
The problem with MIPS and DM_PCI is that there are some generic issues with memory mapping and CONFIG_SYS_SDRAM_BASE being used as virtual address. Actually I have a pending patch queue from Paul Burton for Malta for converting to DM_PCI, but that requires resolving the generic issues with some refactoring for all MIPS boards. It's still on my TODO list ;)
Until I can spare enough time to resolve all issues, I could try to disable the PCI driver in Malta defconfig and mark the driver as broken in Kconfig. This way we can avoid removing the whole board.
Thanks for explaining. Yes, lets go that route for now.
To make this series not to depend on board removal series, I will drop this revert patch in v2, and fix the non-DM PCI driver of mpc85xx instead.
Regards, Bin

Alex's previous email address is no longer reachable.
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
board/freescale/qemu-ppce500/MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/board/freescale/qemu-ppce500/MAINTAINERS b/board/freescale/qemu-ppce500/MAINTAINERS index 77d0a4a..e70c095 100644 --- a/board/freescale/qemu-ppce500/MAINTAINERS +++ b/board/freescale/qemu-ppce500/MAINTAINERS @@ -1,5 +1,5 @@ QEMU-PPCE500 BOARD -M: Alexander Graf agraf@suse.de +M: Alexander Graf agraf@csgraf.de S: Maintained F: board/freescale/qemu-ppce500/ F: include/configs/qemu-ppce500.h

On Sun, 7 Feb 2021 at 08:11, Bin Meng bmeng.cn@gmail.com wrote:
Alex's previous email address is no longer reachable.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
board/freescale/qemu-ppce500/MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Reviewed-by: Simon Glass sjg@chromium.org

At present fdt_read_prop() can only handle 1 or 2 cells. It is called by fdt_read_range() which may be used to read PCI address from <ranges> for a PCI bus node where the number of PCI address cell is 3.
This adds the special handling of such case.
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
common/fdt_support.c | 15 ++++++++++++--- 1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/common/fdt_support.c b/common/fdt_support.c index 638eca9..b3aa865 100644 --- a/common/fdt_support.c +++ b/common/fdt_support.c @@ -1602,22 +1602,31 @@ u64 fdt_get_base_address(const void *fdt, int node) }
/* - * Read a property of size <prop_len>. Currently only supports 1 or 2 cells. + * Read a property of size <prop_len>. Currently only supports 1 or 2 cells, + * or 3 cells specially for a PCI address. */ static int fdt_read_prop(const fdt32_t *prop, int prop_len, int cell_off, uint64_t *val, int cells) { - const fdt32_t *prop32 = &prop[cell_off]; - const unaligned_fdt64_t *prop64 = (const fdt64_t *)&prop[cell_off]; + const fdt32_t *prop32; + const unaligned_fdt64_t *prop64;
if ((cell_off + cells) > prop_len) return -FDT_ERR_NOSPACE;
+ prop32 = &prop[cell_off]; + + /* Special handling for PCI address in PCI bus <ranges> */ + if (cells == 3) + cell_off += 1; + prop64 = (const fdt64_t *)&prop[cell_off]; + switch (cells) { case 1: *val = fdt32_to_cpu(*prop32); break; case 2: + case 3: *val = fdt64_to_cpu(*prop64); break; default:

Hi Bin,
On Sun, 7 Feb 2021 at 08:11, Bin Meng bmeng.cn@gmail.com wrote:
At present fdt_read_prop() can only handle 1 or 2 cells. It is called by fdt_read_range() which may be used to read PCI address from <ranges> for a PCI bus node where the number of PCI address cell is 3.
This adds the special handling of such case.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
common/fdt_support.c | 15 ++++++++++++--- 1 file changed, 12 insertions(+), 3 deletions(-)
I think this is missing why it is needed. Also needs an update to function to the comment in the header file.
Regards, Simon

Hi Simon,
On Mon, Feb 8, 2021 at 12:21 PM Simon Glass sjg@chromium.org wrote:
Hi Bin,
On Sun, 7 Feb 2021 at 08:11, Bin Meng bmeng.cn@gmail.com wrote:
At present fdt_read_prop() can only handle 1 or 2 cells. It is called by fdt_read_range() which may be used to read PCI address from <ranges> for a PCI bus node where the number of PCI address cell is 3.
This adds the special handling of such case.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
common/fdt_support.c | 15 ++++++++++++--- 1 file changed, 12 insertions(+), 3 deletions(-)
I think this is missing why it is needed. Also needs an update to function to the comment in the header file.
I will try to add more details in v2.
The reason why this is needed is because in fdt_read_range() may be used to read PCI address from <ranges>. The <ranges> property is an array of { <child address> <parent address> <size in child address space> }.
When trying to read <child address> from a PCI bus node using fdt_read_prop(), as the codes below:
/* Read <child address> */ if (child_addr) { r = fdt_read_prop(ranges, ranges_len, cell, child_addr, acells); if (r) return r; }
it will fail, because the PCI child address is made up of 3 cells but fdt_read_prop() cannot handle it. We advance the cell offset by 1 so that the <child address> can be correctly read.
Regards, Bin

Hi Bin,
On Sun, 7 Feb 2021 at 22:17, Bin Meng bmeng.cn@gmail.com wrote:
Hi Simon,
On Mon, Feb 8, 2021 at 12:21 PM Simon Glass sjg@chromium.org wrote:
Hi Bin,
On Sun, 7 Feb 2021 at 08:11, Bin Meng bmeng.cn@gmail.com wrote:
At present fdt_read_prop() can only handle 1 or 2 cells. It is called by fdt_read_range() which may be used to read PCI address from <ranges> for a PCI bus node where the number of PCI address cell is 3.
This adds the special handling of such case.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
common/fdt_support.c | 15 ++++++++++++--- 1 file changed, 12 insertions(+), 3 deletions(-)
I think this is missing why it is needed. Also needs an update to function to the comment in the header file.
I will try to add more details in v2.
The reason why this is needed is because in fdt_read_range() may be used to read PCI address from <ranges>. The <ranges> property is an array of { <child address> <parent address> <size in child address space> }.
When trying to read <child address> from a PCI bus node using fdt_read_prop(), as the codes below:
/* Read <child address> */ if (child_addr) { r = fdt_read_prop(ranges, ranges_len, cell, child_addr, acells); if (r) return r; }
it will fail, because the PCI child address is made up of 3 cells but fdt_read_prop() cannot handle it. We advance the cell offset by 1 so that the <child address> can be correctly read.
OK, that could go in the commit message and a function comment somewhere about the case.
There is similar code in decode_regions(), so we have two places that read ranges.
Regards, Simon

When QEMU originally supported the ppce500 machine back in Jan 2014, it was created with a 1:1 mapping of PCI bus address. Things seemed to change rapidly that in Nov 2014 with the following QEMU commits:
commit e6b4e5f4795b ("PPC: e500: Move CCSR and MMIO space to upper end of address space")
and
commit cb3778a0455a ("PPC: e500 pci host: Add support for ATMUs")
the PCI memory and IO physical address were moved to beyond 4 GiB, but PCI bus address remained below 4 GiB, hence a non-identity mapping was created. Unfortunately corresponding U-Boot updates were missed along with the QEMU changes and the U-Boot QEMU ppce500 PCI support has been broken since then.
This commit makes the PCI (non-DM version) work again.
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
board/freescale/qemu-ppce500/qemu-ppce500.c | 29 ++++++++++++++--------------- 1 file changed, 14 insertions(+), 15 deletions(-)
diff --git a/board/freescale/qemu-ppce500/qemu-ppce500.c b/board/freescale/qemu-ppce500/qemu-ppce500.c index 3395377..f82501c 100644 --- a/board/freescale/qemu-ppce500/qemu-ppce500.c +++ b/board/freescale/qemu-ppce500/qemu-ppce500.c @@ -84,20 +84,24 @@ int checkboard(void) }
static int pci_map_region(void *fdt, int pci_node, int range_id, - phys_size_t *ppaddr, pci_addr_t *pvaddr, - pci_size_t *psize, ulong *pmap_addr) + phys_addr_t *pbaddr, phys_size_t *ppaddr, + pci_addr_t *pvaddr, pci_size_t *psize, + ulong *pmap_addr) { - uint64_t addr; + uint64_t baddr; + uint64_t paddr; uint64_t size; ulong map_addr; int r;
- r = fdt_read_range(fdt, pci_node, range_id, NULL, &addr, &size); + r = fdt_read_range(fdt, pci_node, range_id, &baddr, &paddr, &size); if (r) return r;
+ if (pbaddr) + *pbaddr = baddr; if (ppaddr) - *ppaddr = addr; + *ppaddr = paddr; if (psize) *psize = size;
@@ -114,7 +118,7 @@ static int pci_map_region(void *fdt, int pci_node, int range_id, return -1;
/* Map virtual memory for range */ - assert(!tlb_map_range(map_addr, addr, size, TLB_MAP_IO)); + assert(!tlb_map_range(map_addr, paddr, size, TLB_MAP_IO)); *pmap_addr = map_addr + size;
if (pvaddr) @@ -165,24 +169,19 @@ void pci_init_board(void) pci_info.regs = fdt_translate_address(fdt, pci_node, reg);
/* Map MMIO range */ - r = pci_map_region(fdt, pci_node, 0, &pci_info.mem_phys, NULL, + r = pci_map_region(fdt, pci_node, 0, &pci_info.mem_bus, + &pci_info.mem_phys, NULL, &pci_info.mem_size, &map_addr); if (r) break;
/* Map PIO range */ - r = pci_map_region(fdt, pci_node, 1, &pci_info.io_phys, NULL, + r = pci_map_region(fdt, pci_node, 1, &pci_info.io_bus, + &pci_info.io_phys, NULL, &pci_info.io_size, &map_addr); if (r) break;
- /* - * The PCI framework finds virtual addresses for the buses - * through our address map, so tell it the physical addresses. - */ - pci_info.mem_bus = pci_info.mem_phys; - pci_info.io_bus = pci_info.io_phys; - /* Instantiate */ pci_info.pci_num = pci_num + 1;

CONFIG_SYS_PCI_MAP_END currently points to 0xe8000000, which means the upper end of the virtual address mapped to PCI bus address ends at 0xe8000000. But this is wrong as the CCSBAR was already mapped at 0xe0000000 with a 1 MiB size.
Fixes: fa08d3951777 ("PPC 85xx: Add qemu-ppce500 machine") Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
include/configs/qemu-ppce500.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/configs/qemu-ppce500.h b/include/configs/qemu-ppce500.h index ee6ef18..f13e4ea 100644 --- a/include/configs/qemu-ppce500.h +++ b/include/configs/qemu-ppce500.h @@ -35,7 +35,7 @@ extern unsigned long long get_phys_ccsrbar_addr_early(void);
/* Virtual address range for PCI region maps */ #define CONFIG_SYS_PCI_MAP_START 0x80000000 -#define CONFIG_SYS_PCI_MAP_END 0xe8000000 +#define CONFIG_SYS_PCI_MAP_END 0xe0000000
/* Virtual address to a temporary map if we need it (max 128MB) */ #define CONFIG_SYS_TMPVIRT 0xe8000000

LAW related codes should be wrapped with CONFIG_FSL_LAW.
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
arch/powerpc/cpu/mpc85xx/cpu.c | 2 ++ arch/powerpc/cpu/mpc85xx/cpu_init_early.c | 2 ++ 2 files changed, 4 insertions(+)
diff --git a/arch/powerpc/cpu/mpc85xx/cpu.c b/arch/powerpc/cpu/mpc85xx/cpu.c index 3ff1ef4..9d3a68e 100644 --- a/arch/powerpc/cpu/mpc85xx/cpu.c +++ b/arch/powerpc/cpu/mpc85xx/cpu.c @@ -394,7 +394,9 @@ int cpu_mmc_init(struct bd_info *bis) void print_reginfo(void) { print_tlbcam(); +#ifdef CONFIG_FSL_LAW print_laws(); +#endif #if defined(CONFIG_FSL_LBC) print_lbc_regs(); #endif diff --git a/arch/powerpc/cpu/mpc85xx/cpu_init_early.c b/arch/powerpc/cpu/mpc85xx/cpu_init_early.c index c519e8b..b0c2e2a 100644 --- a/arch/powerpc/cpu/mpc85xx/cpu_init_early.c +++ b/arch/powerpc/cpu/mpc85xx/cpu_init_early.c @@ -122,7 +122,9 @@ void cpu_init_early_f(void *fdt) setbits_be32(&gur->pmuxcr, MPC85xx_PMUXCR_LCLK_IFC_CS3); #endif
+#ifdef CONFIG_FSL_LAW init_laws(); +#endif
/* * Work Around for IFC Erratum A003399, issue will hit only when execution

These are no longer needed. Drop them.
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
board/freescale/qemu-ppce500/qemu-ppce500.c | 10 ---------- 1 file changed, 10 deletions(-)
diff --git a/board/freescale/qemu-ppce500/qemu-ppce500.c b/board/freescale/qemu-ppce500/qemu-ppce500.c index f82501c..fb0b01f 100644 --- a/board/freescale/qemu-ppce500/qemu-ppce500.c +++ b/board/freescale/qemu-ppce500/qemu-ppce500.c @@ -253,11 +253,6 @@ int ft_board_setup(void *blob, struct bd_info *bd) } #endif
-void print_laws(void) -{ - /* We don't emulate LAWs yet */ -} - phys_size_t fixed_sdram(void) { return get_linear_ram_size(); @@ -301,11 +296,6 @@ void init_tlbs(void) 1024 * 1024, TLB_MAP_RAM)); }
-void init_laws(void) -{ - /* We don't emulate LAWs yet */ -} - static uint32_t get_cpu_freq(void) { void *fdt = get_fdt_virt();

This function does nothing. Drop it.
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
board/freescale/qemu-ppce500/qemu-ppce500.c | 5 ----- configs/qemu-ppce500_defconfig | 1 - 2 files changed, 6 deletions(-)
diff --git a/board/freescale/qemu-ppce500/qemu-ppce500.c b/board/freescale/qemu-ppce500/qemu-ppce500.c index fb0b01f..33d71ba 100644 --- a/board/freescale/qemu-ppce500/qemu-ppce500.c +++ b/board/freescale/qemu-ppce500/qemu-ppce500.c @@ -73,11 +73,6 @@ uint64_t get_phys_ccsrbar_addr_early(void) return r; }
-int board_early_init_f(void) -{ - return 0; -} - int checkboard(void) { return 0; diff --git a/configs/qemu-ppce500_defconfig b/configs/qemu-ppce500_defconfig index d17c556..25fcd41 100644 --- a/configs/qemu-ppce500_defconfig +++ b/configs/qemu-ppce500_defconfig @@ -10,7 +10,6 @@ CONFIG_OF_BOARD_SETUP=y CONFIG_OF_STDOUT_VIA_ALIAS=y CONFIG_BOOTDELAY=1 # CONFIG_DISPLAY_BOARDINFO is not set -CONFIG_BOARD_EARLY_INIT_F=y CONFIG_LAST_STAGE_INIT=y # CONFIG_MISC_INIT_R is not set CONFIG_HUSH_PARSER=y

The QEMU ppce500 machine generates a device tree blob and passes it to U-Boot during boot. Let's enable OF_CONTROL with OF_BOARD and provide board_fdt_blob_setup() in the board codes.
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
board/freescale/qemu-ppce500/qemu-ppce500.c | 10 ++++++++++ configs/qemu-ppce500_defconfig | 3 ++- 2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/board/freescale/qemu-ppce500/qemu-ppce500.c b/board/freescale/qemu-ppce500/qemu-ppce500.c index 33d71ba..83cff2d 100644 --- a/board/freescale/qemu-ppce500/qemu-ppce500.c +++ b/board/freescale/qemu-ppce500/qemu-ppce500.c @@ -363,3 +363,13 @@ u32 cpu_mask(void) { return (1 << cpu_numcores()) - 1; } + +/** + * Return the virtual address of FDT that was passed by QEMU + * + * @return virtual address of FDT received from QEMU in r3 register + */ +void *board_fdt_blob_setup(void) +{ + return get_fdt_virt(); +} diff --git a/configs/qemu-ppce500_defconfig b/configs/qemu-ppce500_defconfig index 25fcd41..4522e18 100644 --- a/configs/qemu-ppce500_defconfig +++ b/configs/qemu-ppce500_defconfig @@ -22,6 +22,8 @@ CONFIG_CMD_PING=y # CONFIG_CMD_HASH is not set CONFIG_CMD_EXT2=y CONFIG_DOS_PARTITION=y +CONFIG_OF_CONTROL=y +CONFIG_OF_BOARD=y CONFIG_ENV_OVERWRITE=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y # CONFIG_MMC is not set @@ -29,4 +31,3 @@ CONFIG_E1000=y CONFIG_SYS_NS16550=y CONFIG_ADDR_MAP=y CONFIG_PANIC_HANG=y -CONFIG_OF_LIBFDT=y

On Sun, 7 Feb 2021 at 08:12, Bin Meng bmeng.cn@gmail.com wrote:
The QEMU ppce500 machine generates a device tree blob and passes it to U-Boot during boot. Let's enable OF_CONTROL with OF_BOARD and provide board_fdt_blob_setup() in the board codes.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
board/freescale/qemu-ppce500/qemu-ppce500.c | 10 ++++++++++ configs/qemu-ppce500_defconfig | 3 ++- 2 files changed, 12 insertions(+), 1 deletion(-)
Reviewed-by: Simon Glass sjg@chromium.org

At present QEMU ppce500 target has not been migrated to driver model yet. As a start, let's enable driver model and the 'dm' command.
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
configs/qemu-ppce500_defconfig | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/configs/qemu-ppce500_defconfig b/configs/qemu-ppce500_defconfig index 4522e18..f2a8b83 100644 --- a/configs/qemu-ppce500_defconfig +++ b/configs/qemu-ppce500_defconfig @@ -16,6 +16,7 @@ CONFIG_HUSH_PARSER=y CONFIG_CMD_REGINFO=y CONFIG_CMD_BOOTZ=y CONFIG_CMD_GREPENV=y +CONFIG_CMD_DM=y CONFIG_CMD_PCI=y CONFIG_CMD_DHCP=y CONFIG_CMD_PING=y @@ -26,6 +27,7 @@ CONFIG_OF_CONTROL=y CONFIG_OF_BOARD=y CONFIG_ENV_OVERWRITE=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y +CONFIG_DM=y # CONFIG_MMC is not set CONFIG_E1000=y CONFIG_SYS_NS16550=y

On Sun, 7 Feb 2021 at 08:12, Bin Meng bmeng.cn@gmail.com wrote:
At present QEMU ppce500 target has not been migrated to driver model yet. As a start, let's enable driver model and the 'dm' command.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
configs/qemu-ppce500_defconfig | 2 ++ 1 file changed, 2 insertions(+)
Reviewed-by: Simon Glass sjg@chromium.org

Remove the extern of the header because they are useless.
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
include/addr_map.h | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/addr_map.h b/include/addr_map.h index d322dd2..85e737d 100644 --- a/include/addr_map.h +++ b/include/addr_map.h @@ -8,9 +8,9 @@
#include <asm/types.h>
-extern phys_addr_t addrmap_virt_to_phys(void *vaddr); -extern void *addrmap_phys_to_virt(phys_addr_t paddr); -extern void addrmap_set_entry(unsigned long vaddr, phys_addr_t paddr, - phys_size_t size, int idx); +phys_addr_t addrmap_virt_to_phys(void *vaddr); +void *addrmap_phys_to_virt(phys_addr_t paddr); +void addrmap_set_entry(unsigned long vaddr, phys_addr_t paddr, + phys_size_t size, int idx);
#endif

On Sun, 7 Feb 2021 at 08:12, Bin Meng bmeng.cn@gmail.com wrote:
Remove the extern of the header because they are useless.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
include/addr_map.h | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
Reviewed-by: Simon Glass sjg@chromium.org

At present address_map[] is static and its type is unknown to external modules. In preparation to create a command to list its contents, this patch moves its type definition and declaration to the header file.
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
include/addr_map.h | 8 ++++++++ lib/addr_map.c | 6 +----- 2 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/include/addr_map.h b/include/addr_map.h index 85e737d..55d3a6a 100644 --- a/include/addr_map.h +++ b/include/addr_map.h @@ -8,6 +8,14 @@
#include <asm/types.h>
+struct addrmap { + phys_addr_t paddr; + phys_size_t size; + unsigned long vaddr; +}; + +extern struct addrmap address_map[CONFIG_SYS_NUM_ADDR_MAP]; + phys_addr_t addrmap_virt_to_phys(void *vaddr); void *addrmap_phys_to_virt(phys_addr_t paddr); void addrmap_set_entry(unsigned long vaddr, phys_addr_t paddr, diff --git a/lib/addr_map.c b/lib/addr_map.c index 09771f3..fb2ef40 100644 --- a/lib/addr_map.c +++ b/lib/addr_map.c @@ -6,11 +6,7 @@ #include <common.h> #include <addr_map.h>
-static struct { - phys_addr_t paddr; - phys_size_t size; - unsigned long vaddr; -} address_map[CONFIG_SYS_NUM_ADDR_MAP]; +struct addrmap address_map[CONFIG_SYS_NUM_ADDR_MAP];
phys_addr_t addrmap_virt_to_phys(void * vaddr) {

On Sun, 7 Feb 2021 at 08:12, Bin Meng bmeng.cn@gmail.com wrote:
At present address_map[] is static and its type is unknown to external modules. In preparation to create a command to list its contents, this patch moves its type definition and declaration to the header file.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
include/addr_map.h | 8 ++++++++ lib/addr_map.c | 6 +----- 2 files changed, 9 insertions(+), 5 deletions(-)
Reviewed-by: Simon Glass sjg@chromium.org

This adds a new command 'addrmap' to display the address map for non-identity virtual-physical memory mappings.
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
cmd/Kconfig | 7 +++++++ cmd/Makefile | 1 + cmd/addrmap.c | 35 +++++++++++++++++++++++++++++++++++ 3 files changed, 43 insertions(+) create mode 100644 cmd/addrmap.c
diff --git a/cmd/Kconfig b/cmd/Kconfig index 928a2a0..2021939 100644 --- a/cmd/Kconfig +++ b/cmd/Kconfig @@ -97,6 +97,13 @@ config CMD_ACPI between the firmware and OS, and is particularly useful when you want to make hardware changes without the OS needing to be adjusted.
+config CMD_ADDRMAP + bool "addrmap" + depends on ADDR_MAP + default y + help + List non-identity virtual-physical memory mappings for 32-bit CPUs. + config CMD_BDI bool "bdinfo" default y diff --git a/cmd/Makefile b/cmd/Makefile index 176bf92..567e2b7 100644 --- a/cmd/Makefile +++ b/cmd/Makefile @@ -13,6 +13,7 @@ obj-y += version.o
# command obj-$(CONFIG_CMD_ACPI) += acpi.o +obj-$(CONFIG_CMD_ADDRMAP) += addrmap.o obj-$(CONFIG_CMD_AES) += aes.o obj-$(CONFIG_CMD_AB_SELECT) += ab_select.o obj-$(CONFIG_CMD_ADC) += adc.o diff --git a/cmd/addrmap.c b/cmd/addrmap.c new file mode 100644 index 0000000..bd23549 --- /dev/null +++ b/cmd/addrmap.c @@ -0,0 +1,35 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Copyright (C) 2021, Bin Meng bmeng.cn@gmail.com + */ + +#include <common.h> +#include <command.h> +#include <addr_map.h> + +static int do_addrmap(struct cmd_tbl *cmdtp, int flag, int argc, + char *const argv[]) +{ + int i; + + printf(" vaddr paddr size\n"); + printf("================ ================ ================\n"); + + for (i = 0; i < CONFIG_SYS_NUM_ADDR_MAP; i++) { + if (address_map[i].size == 0) + continue; + + printf("%16.8lx %16.8llx %16.8llx\n", + address_map[i].vaddr, + (unsigned long long)address_map[i].paddr, + (unsigned long long)address_map[i].size); + } + + return 0; +} + +U_BOOT_CMD( + addrmap, 1, 1, do_addrmap, + "List non-identity virtual-physical memory mappings for 32-bit CPUs", + "" +);

On Sun, 7 Feb 2021 at 08:12, Bin Meng bmeng.cn@gmail.com wrote:
This adds a new command 'addrmap' to display the address map for non-identity virtual-physical memory mappings.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
cmd/Kconfig | 7 +++++++ cmd/Makefile | 1 + cmd/addrmap.c | 35 +++++++++++++++++++++++++++++++++++ 3 files changed, 43 insertions(+) create mode 100644 cmd/addrmap.c
This should have a test (e.g. see mem_search.c) and doc/usage file.
Regards, Simon

Hi Simon,
On Mon, Feb 8, 2021 at 12:20 PM Simon Glass sjg@chromium.org wrote:
On Sun, 7 Feb 2021 at 08:12, Bin Meng bmeng.cn@gmail.com wrote:
This adds a new command 'addrmap' to display the address map for non-identity virtual-physical memory mappings.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
cmd/Kconfig | 7 +++++++ cmd/Makefile | 1 + cmd/addrmap.c | 35 +++++++++++++++++++++++++++++++++++ 3 files changed, 43 insertions(+) create mode 100644 cmd/addrmap.c
This should have a test (e.g. see mem_search.c) and doc/usage file.
I am not sure how that is useful to add a test for this command, because this command only prints some value from an array.
Regards, Bin

Hi Bin,
On Sun, 7 Feb 2021 at 22:12, Bin Meng bmeng.cn@gmail.com wrote:
Hi Simon,
On Mon, Feb 8, 2021 at 12:20 PM Simon Glass sjg@chromium.org wrote:
On Sun, 7 Feb 2021 at 08:12, Bin Meng bmeng.cn@gmail.com wrote:
This adds a new command 'addrmap' to display the address map for non-identity virtual-physical memory mappings.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
cmd/Kconfig | 7 +++++++ cmd/Makefile | 1 + cmd/addrmap.c | 35 +++++++++++++++++++++++++++++++++++ 3 files changed, 43 insertions(+) create mode 100644 cmd/addrmap.c
This should have a test (e.g. see mem_search.c) and doc/usage file.
I am not sure how that is useful to add a test for this command, because this command only prints some value from an array.
Right but then it will only be a short test:
console_record_reset(); ut_assertok(run_command("...", 0)); ut_assert_nextline() .. ut_assert_console_end();
Then if someone expands it later they will feel obligated to add to the test.
I feel that a lot of things look too trivial to test when started, but it is often that first trivial test that determines whether we have tests ever. That is why we have the patman check about adding tests for new commands.
Regards, Simon

Mention that CONFIG_ADDR_MAP only works in the post-relocation phase.
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
lib/Kconfig | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/lib/Kconfig b/lib/Kconfig index 7f4c30e..7288340 100644 --- a/lib/Kconfig +++ b/lib/Kconfig @@ -6,6 +6,8 @@ config ADDR_MAP Enables helper code for implementing non-identity virtual-physical memory mappings for 32bit CPUs.
+ This library only works in the post-relocation phase. + config SYS_NUM_ADDR_MAP int "Size of the address-map table" depends on ADDR_MAP

On Sun, 7 Feb 2021 at 08:12, Bin Meng bmeng.cn@gmail.com wrote:
Mention that CONFIG_ADDR_MAP only works in the post-relocation phase.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
lib/Kconfig | 2 ++ 1 file changed, 2 insertions(+)
Reviewed-by: Simon Glass sjg@chromium.org

In phys_to_virt() and virt_to_phys(), if CONFIG_ADDR_MAP is defined, they use addrmap_ translation APIs to do the address translation. However these APIs only work in post-relocation phase.
Update the code logic to fall back to use the default one when in pre-relocation phase.
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
arch/powerpc/include/asm/io.h | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/include/asm/io.h b/arch/powerpc/include/asm/io.h index 6d76e3e..998a82a 100644 --- a/arch/powerpc/include/asm/io.h +++ b/arch/powerpc/include/asm/io.h @@ -10,7 +10,10 @@ #include <asm/byteorder.h>
#ifdef CONFIG_ADDR_MAP +#include <asm/global_data.h> #include <addr_map.h> + +DECLARE_GLOBAL_DATA_PTR; #endif
#define SIO_CONFIG_RA 0x398 @@ -303,20 +306,20 @@ static inline void out_be32(volatile unsigned __iomem *addr, u32 val) static inline void *phys_to_virt(phys_addr_t paddr) { #ifdef CONFIG_ADDR_MAP - return addrmap_phys_to_virt(paddr); -#else - return (void *)((unsigned long)paddr); + if (gd->flags & GD_FLG_RELOC) + return addrmap_phys_to_virt(paddr); #endif + return (void *)((unsigned long)paddr); } #define phys_to_virt phys_to_virt
static inline phys_addr_t virt_to_phys(void * vaddr) { #ifdef CONFIG_ADDR_MAP - return addrmap_virt_to_phys(vaddr); -#else - return (phys_addr_t)((unsigned long)vaddr); + if (gd->flags & GD_FLG_RELOC) + return addrmap_virt_to_phys(vaddr); #endif + return (phys_addr_t)((unsigned long)vaddr); } #define virt_to_phys virt_to_phys

At present initr_addr_map() is put at a late stage in the init_sequence_r[] calls. This won't work because lot of device driver initialization (e.g.: serial port) happens before it but is lack of the address translation support.
This moves the call to a bit earlier, right after the DM initialization.
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
common/board_r.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/common/board_r.c b/common/board_r.c index 9fa4d4b..cce0336 100644 --- a/common/board_r.c +++ b/common/board_r.c @@ -625,6 +625,9 @@ static init_fnc_t init_sequence_r[] = { #ifdef CONFIG_DM initr_dm, #endif +#ifdef CONFIG_ADDR_MAP + initr_addr_map, +#endif #if defined(CONFIG_ARM) || defined(CONFIG_NDS32) || defined(CONFIG_RISCV) || \ defined(CONFIG_SANDBOX) board_init, /* Setup chipselects */ @@ -660,9 +663,6 @@ static init_fnc_t init_sequence_r[] = { initr_manual_reloc_cmdtable, #endif arch_initr_trap, -#ifdef CONFIG_ADDR_MAP - initr_addr_map, -#endif #if defined(CONFIG_BOARD_EARLY_INIT_R) board_early_init_r, #endif

On Sun, 7 Feb 2021 at 08:12, Bin Meng bmeng.cn@gmail.com wrote:
At present initr_addr_map() is put at a late stage in the init_sequence_r[] calls. This won't work because lot of device driver initialization (e.g.: serial port) happens before it but is lack of the address translation support.
This moves the call to a bit earlier, right after the DM initialization.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
common/board_r.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
Reviewed-by: Simon Glass sjg@chromium.org

The QEMU ppce500 target integrates 2 NS16550 serial ports. Switch over to use the DM version of the driver by:
- drop unnecessary ad-hoc config macros - add get_serial_clock() in the board codes
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
board/freescale/qemu-ppce500/qemu-ppce500.c | 6 ++++++ configs/qemu-ppce500_defconfig | 1 + include/configs/qemu-ppce500.h | 10 ---------- 3 files changed, 7 insertions(+), 10 deletions(-)
diff --git a/board/freescale/qemu-ppce500/qemu-ppce500.c b/board/freescale/qemu-ppce500/qemu-ppce500.c index 83cff2d..48588e8 100644 --- a/board/freescale/qemu-ppce500/qemu-ppce500.c +++ b/board/freescale/qemu-ppce500/qemu-ppce500.c @@ -373,3 +373,9 @@ void *board_fdt_blob_setup(void) { return get_fdt_virt(); } + +/* See CONFIG_SYS_NS16550_CLK in arch/powerpc/include/asm/config.h */ +int get_serial_clock(void) +{ + return get_bus_freq(0); +} diff --git a/configs/qemu-ppce500_defconfig b/configs/qemu-ppce500_defconfig index f2a8b83..c528a68 100644 --- a/configs/qemu-ppce500_defconfig +++ b/configs/qemu-ppce500_defconfig @@ -30,6 +30,7 @@ CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_DM=y # CONFIG_MMC is not set CONFIG_E1000=y +CONFIG_DM_SERIAL=y CONFIG_SYS_NS16550=y CONFIG_ADDR_MAP=y CONFIG_PANIC_HANG=y diff --git a/include/configs/qemu-ppce500.h b/include/configs/qemu-ppce500.h index f13e4ea..feac6ef 100644 --- a/include/configs/qemu-ppce500.h +++ b/include/configs/qemu-ppce500.h @@ -73,16 +73,6 @@ extern unsigned long long get_phys_ccsrbar_addr_early(void); #define CONFIG_SYS_MONITOR_LEN (512 * 1024) #define CONFIG_SYS_MALLOC_LEN (4 * 1024 * 1024)
-#define CONFIG_SYS_NS16550_SERIAL -#define CONFIG_SYS_NS16550_REG_SIZE 1 -#define CONFIG_SYS_NS16550_CLK (get_bus_freq(0)) - -#define CONFIG_SYS_BAUDRATE_TABLE \ - {300, 600, 1200, 2400, 4800, 9600, 19200, 38400, 57600, 115200} - -#define CONFIG_SYS_NS16550_COM1 (CONFIG_SYS_CCSRBAR+0x4500) -#define CONFIG_SYS_NS16550_COM2 (CONFIG_SYS_CCSRBAR+0x4600) - /* * General PCI * Memory space is mapped 1-1, but I/O space must start from 0.

On Sun, 7 Feb 2021 at 08:12, Bin Meng bmeng.cn@gmail.com wrote:
The QEMU ppce500 target integrates 2 NS16550 serial ports. Switch over to use the DM version of the driver by:
- drop unnecessary ad-hoc config macros
- add get_serial_clock() in the board codes
Signed-off-by: Bin Meng bmeng.cn@gmail.com
board/freescale/qemu-ppce500/qemu-ppce500.c | 6 ++++++ configs/qemu-ppce500_defconfig | 1 + include/configs/qemu-ppce500.h | 10 ---------- 3 files changed, 7 insertions(+), 10 deletions(-)
Reviewed-by: Simon Glass sjg@chromium.org

For the QEMU ppce500 machine, LAW registers are not implemented hence CONFIG_FSL_LAW is not turned on and all LAW APIs are not available. We should wrap all LAW registers programming in the mpc85xx PCI driver with CONFIG_FSL_LAW.
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
drivers/pci/pci_mpc85xx.c | 4 ++++ 1 file changed, 4 insertions(+)
diff --git a/drivers/pci/pci_mpc85xx.c b/drivers/pci/pci_mpc85xx.c index ab6ff45..7387a1e 100644 --- a/drivers/pci/pci_mpc85xx.c +++ b/drivers/pci/pci_mpc85xx.c @@ -46,6 +46,7 @@ static int mpc85xx_pci_dm_write_config(struct udevice *dev, pci_dev_t bdf, return 0; }
+#ifdef CONFIG_FSL_LAW static int mpc85xx_pci_dm_setup_laws(struct pci_region *io, struct pci_region *mem, struct pci_region *pre) @@ -68,6 +69,7 @@ mpc85xx_pci_dm_setup_laws(struct pci_region *io, struct pci_region *mem,
return 0; } +#endif
static int mpc85xx_pci_dm_probe(struct udevice *dev) { @@ -85,7 +87,9 @@ static int mpc85xx_pci_dm_probe(struct udevice *dev) return -EINVAL; }
+#ifdef CONFIG_FSL_LAW mpc85xx_pci_dm_setup_laws(io, mem, pre); +#endif
pcix = priv->cfg_addr; /* BAR 1: memory */

devfdt_get_addr_index() returns fdt_addr_t which might be a 64-bit physical address. Use map_physmem() to return the virtual address that can be used by a 32-bit machine.
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
drivers/pci/pci_mpc85xx.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/pci/pci_mpc85xx.c b/drivers/pci/pci_mpc85xx.c index 7387a1e..f0d469a 100644 --- a/drivers/pci/pci_mpc85xx.c +++ b/drivers/pci/pci_mpc85xx.c @@ -134,9 +134,8 @@ static int mpc85xx_pci_of_to_plat(struct udevice *dev) addr = devfdt_get_addr_index(dev, 0); if (addr == FDT_ADDR_T_NONE) return -EINVAL; - priv->cfg_addr = (void __iomem *)addr; - addr += 4; - priv->cfg_data = (void __iomem *)addr; + priv->cfg_addr = (void __iomem *)map_physmem(addr, 0, MAP_NOCACHE); + priv->cfg_data = (void __iomem *)((ulong)priv->cfg_addr + 4);
return 0; }

At present the driver only supports 32-bit bus and cpu address. The controller's outbound registers/fields for extended address are not programmed. Let's program them to support 64-bit bus and cpu address.
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
drivers/pci/pci_mpc85xx.c | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/pci/pci_mpc85xx.c b/drivers/pci/pci_mpc85xx.c index f0d469a..574cb78 100644 --- a/drivers/pci/pci_mpc85xx.c +++ b/drivers/pci/pci_mpc85xx.c @@ -93,18 +93,18 @@ static int mpc85xx_pci_dm_probe(struct udevice *dev)
pcix = priv->cfg_addr; /* BAR 1: memory */ - out_be32(&pcix->potar1, (mem->bus_start >> 12) & 0x000fffff); - out_be32(&pcix->potear1, 0); - out_be32(&pcix->powbar1, (mem->phys_start >> 12) & 0x000fffff); - out_be32(&pcix->powbear1, 0); + out_be32(&pcix->potar1, mem->bus_start >> 12); + out_be32(&pcix->potear1, (u64)mem->bus_start >> 44); + out_be32(&pcix->powbar1, mem->phys_start >> 12); + out_be32(&pcix->powbear1, (u64)mem->phys_start >> 44); out_be32(&pcix->powar1, (POWAR_EN | POWAR_MEM_READ | POWAR_MEM_WRITE | (__ilog2(mem->size) - 1)));
/* BAR 1: IO */ - out_be32(&pcix->potar2, (io->bus_start >> 12) & 0x000fffff); - out_be32(&pcix->potear2, 0); - out_be32(&pcix->powbar2, (io->phys_start >> 12) & 0x000fffff); - out_be32(&pcix->powbear2, 0); + out_be32(&pcix->potar2, io->bus_start >> 12); + out_be32(&pcix->potear2, (u64)io->bus_start >> 44); + out_be32(&pcix->powbar2, io->phys_start >> 12); + out_be32(&pcix->powbear2, (u64)io->phys_start >> 44); out_be32(&pcix->powar2, (POWAR_EN | POWAR_IO_READ | POWAR_IO_WRITE | (__ilog2(io->size) - 1)));

At present the board supports non-DM version PCI and E1000 drivers. Switch over to use DM ETH and PCI by:
- Rewrite the PCI address map functions using DM APIs - Enable CONFIG_MISC_INIT_R to do the PCI initialization and address map - Drop unnecessary ad-hoc config macros - Remove board_eth_init() in the board codes
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
board/freescale/qemu-ppce500/qemu-ppce500.c | 111 ++++++---------------------- configs/qemu-ppce500_defconfig | 4 +- include/configs/qemu-ppce500.h | 13 ---- 3 files changed, 24 insertions(+), 104 deletions(-)
diff --git a/board/freescale/qemu-ppce500/qemu-ppce500.c b/board/freescale/qemu-ppce500/qemu-ppce500.c index 48588e8..88cada1 100644 --- a/board/freescale/qemu-ppce500/qemu-ppce500.c +++ b/board/freescale/qemu-ppce500/qemu-ppce500.c @@ -6,6 +6,7 @@ #include <common.h> #include <command.h> #include <cpu_func.h> +#include <dm.h> #include <env.h> #include <init.h> #include <log.h> @@ -78,27 +79,9 @@ int checkboard(void) return 0; }
-static int pci_map_region(void *fdt, int pci_node, int range_id, - phys_addr_t *pbaddr, phys_size_t *ppaddr, - pci_addr_t *pvaddr, pci_size_t *psize, - ulong *pmap_addr) +static int pci_map_region(phys_addr_t paddr, phys_size_t size, ulong *pmap_addr) { - uint64_t baddr; - uint64_t paddr; - uint64_t size; ulong map_addr; - int r; - - r = fdt_read_range(fdt, pci_node, range_id, &baddr, &paddr, &size); - if (r) - return r; - - if (pbaddr) - *pbaddr = baddr; - if (ppaddr) - *ppaddr = paddr; - if (psize) - *psize = size;
if (!pmap_addr) return 0; @@ -116,82 +99,37 @@ static int pci_map_region(void *fdt, int pci_node, int range_id, assert(!tlb_map_range(map_addr, paddr, size, TLB_MAP_IO)); *pmap_addr = map_addr + size;
- if (pvaddr) - *pvaddr = map_addr; - return 0; }
-void pci_init_board(void) +int misc_init_r(void) { - struct pci_controller *pci_hoses; - void *fdt = get_fdt_virt(); - int pci_node = -1; - int pci_num = 0; - int pci_count = 0; + struct udevice *dev; + struct pci_region *io; + struct pci_region *mem; + struct pci_region *pre; ulong map_addr; + int ret;
- puts("\n"); + /* Ensure PCI is probed */ + uclass_first_device(UCLASS_PCI, &dev); + + pci_get_regions(dev, &io, &mem, &pre);
/* Start MMIO and PIO range maps above RAM */ map_addr = CONFIG_SYS_PCI_MAP_START;
- /* Count and allocate PCI buses */ - pci_node = fdt_node_offset_by_prop_value(fdt, pci_node, - "device_type", "pci", 4); - while (pci_node != -FDT_ERR_NOTFOUND) { - pci_node = fdt_node_offset_by_prop_value(fdt, pci_node, - "device_type", "pci", 4); - pci_count++; - } - - if (pci_count) { - pci_hoses = malloc(sizeof(struct pci_controller) * pci_count); - } else { - printf("PCI: disabled\n\n"); - return; - } + /* Map MMIO range */ + ret = pci_map_region(mem->phys_start, mem->size, &map_addr); + if (ret) + return ret;
- /* Spawn PCI buses based on device tree */ - pci_node = fdt_node_offset_by_prop_value(fdt, pci_node, - "device_type", "pci", 4); - while (pci_node != -FDT_ERR_NOTFOUND) { - struct fsl_pci_info pci_info = { }; - const fdt32_t *reg; - int r; - - reg = fdt_getprop(fdt, pci_node, "reg", NULL); - pci_info.regs = fdt_translate_address(fdt, pci_node, reg); - - /* Map MMIO range */ - r = pci_map_region(fdt, pci_node, 0, &pci_info.mem_bus, - &pci_info.mem_phys, NULL, - &pci_info.mem_size, &map_addr); - if (r) - break; - - /* Map PIO range */ - r = pci_map_region(fdt, pci_node, 1, &pci_info.io_bus, - &pci_info.io_phys, NULL, - &pci_info.io_size, &map_addr); - if (r) - break; - - /* Instantiate */ - pci_info.pci_num = pci_num + 1; - - fsl_setup_hose(&pci_hoses[pci_num], pci_info.regs); - printf("PCI: base address %lx\n", pci_info.regs); - - fsl_pci_init_port(&pci_info, &pci_hoses[pci_num], pci_num); - - /* Jump to next PCI node */ - pci_node = fdt_node_offset_by_prop_value(fdt, pci_node, - "device_type", "pci", 4); - pci_num++; - } + /* Map PIO range */ + ret = pci_map_region(io->phys_start, io->size, &map_addr); + if (ret) + return ret;
- puts("\n"); + return 0; }
int last_stage_init(void) @@ -234,16 +172,9 @@ static uint64_t get_linear_ram_size(void) panic("Couldn't determine RAM size"); }
-int board_eth_init(struct bd_info *bis) -{ - return pci_eth_init(bis); -} - #if defined(CONFIG_OF_BOARD_SETUP) int ft_board_setup(void *blob, struct bd_info *bd) { - FT_FSL_PCI_SETUP; - return 0; } #endif diff --git a/configs/qemu-ppce500_defconfig b/configs/qemu-ppce500_defconfig index c528a68..4a4b369 100644 --- a/configs/qemu-ppce500_defconfig +++ b/configs/qemu-ppce500_defconfig @@ -11,7 +11,6 @@ CONFIG_OF_STDOUT_VIA_ALIAS=y CONFIG_BOOTDELAY=1 # CONFIG_DISPLAY_BOARDINFO is not set CONFIG_LAST_STAGE_INIT=y -# CONFIG_MISC_INIT_R is not set CONFIG_HUSH_PARSER=y CONFIG_CMD_REGINFO=y CONFIG_CMD_BOOTZ=y @@ -29,7 +28,10 @@ CONFIG_ENV_OVERWRITE=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_DM=y # CONFIG_MMC is not set +CONFIG_DM_ETH=y CONFIG_E1000=y +CONFIG_DM_PCI=y +CONFIG_PCI_MPC85XX=y CONFIG_DM_SERIAL=y CONFIG_SYS_NS16550=y CONFIG_ADDR_MAP=y diff --git a/include/configs/qemu-ppce500.h b/include/configs/qemu-ppce500.h index feac6ef..b1ee810 100644 --- a/include/configs/qemu-ppce500.h +++ b/include/configs/qemu-ppce500.h @@ -13,8 +13,6 @@
#define CONFIG_SYS_RAMBOOT
-#define CONFIG_PCI1 1 /* PCI controller 1 */ -#define CONFIG_FSL_PCI_INIT /* Use common FSL init code */ #define CONFIG_SYS_PCI_64BIT /* enable 64-bit PCI resources */
#define CONFIG_ENABLE_36BIT_PHYS @@ -73,17 +71,6 @@ extern unsigned long long get_phys_ccsrbar_addr_early(void); #define CONFIG_SYS_MONITOR_LEN (512 * 1024) #define CONFIG_SYS_MALLOC_LEN (4 * 1024 * 1024)
-/* - * General PCI - * Memory space is mapped 1-1, but I/O space must start from 0. - */ - -#ifdef CONFIG_PCI -#define CONFIG_PCI_INDIRECT_BRIDGE - -#define CONFIG_PCI_SCAN_SHOW /* show pci devices on startup */ -#endif /* CONFIG_PCI */ - #define CONFIG_LBA48
/*

ft_board_setup() is now empty. Drop it.
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
board/freescale/qemu-ppce500/qemu-ppce500.c | 7 ------- configs/qemu-ppce500_defconfig | 1 - 2 files changed, 8 deletions(-)
diff --git a/board/freescale/qemu-ppce500/qemu-ppce500.c b/board/freescale/qemu-ppce500/qemu-ppce500.c index 88cada1..b85316b 100644 --- a/board/freescale/qemu-ppce500/qemu-ppce500.c +++ b/board/freescale/qemu-ppce500/qemu-ppce500.c @@ -172,13 +172,6 @@ static uint64_t get_linear_ram_size(void) panic("Couldn't determine RAM size"); }
-#if defined(CONFIG_OF_BOARD_SETUP) -int ft_board_setup(void *blob, struct bd_info *bd) -{ - return 0; -} -#endif - phys_size_t fixed_sdram(void) { return get_linear_ram_size(); diff --git a/configs/qemu-ppce500_defconfig b/configs/qemu-ppce500_defconfig index 4a4b369..918739b 100644 --- a/configs/qemu-ppce500_defconfig +++ b/configs/qemu-ppce500_defconfig @@ -6,7 +6,6 @@ CONFIG_MPC85xx=y CONFIG_TARGET_QEMU_PPCE500=y CONFIG_FIT=y CONFIG_FIT_VERBOSE=y -CONFIG_OF_BOARD_SETUP=y CONFIG_OF_STDOUT_VIA_ALIAS=y CONFIG_BOOTDELAY=1 # CONFIG_DISPLAY_BOARDINFO is not set

The 'virtio' command calls blk_common_cmd() which is only available when CONFIG_HAVE_BLOCK_DEVICE is on. Fix the Kconfig dependency.
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
cmd/Kconfig | 1 + 1 file changed, 1 insertion(+)
diff --git a/cmd/Kconfig b/cmd/Kconfig index 2021939..eda5190 100644 --- a/cmd/Kconfig +++ b/cmd/Kconfig @@ -1344,6 +1344,7 @@ config CMD_PVBLOCK config CMD_VIRTIO bool "virtio" depends on VIRTIO + depends on HAVE_BLOCK_DEVICE default y if VIRTIO help VirtIO block device support

On Sun, 7 Feb 2021 at 08:13, Bin Meng bmeng.cn@gmail.com wrote:
The 'virtio' command calls blk_common_cmd() which is only available when CONFIG_HAVE_BLOCK_DEVICE is on. Fix the Kconfig dependency.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
cmd/Kconfig | 1 + 1 file changed, 1 insertion(+)
Reviewed-by: Simon Glass sjg@chromium.org

By default the QEMU ppce500 machine connects a VirtIO NET to the PCI controller, although it can be replaced to an e1000 NIC via additional command line options.
Now that we have switched over to DM PCI, VirtIO support becomes possible. This commit enables the support.
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
board/freescale/qemu-ppce500/qemu-ppce500.c | 8 ++++++++ configs/qemu-ppce500_defconfig | 2 ++ 2 files changed, 10 insertions(+)
diff --git a/board/freescale/qemu-ppce500/qemu-ppce500.c b/board/freescale/qemu-ppce500/qemu-ppce500.c index b85316b..a105130 100644 --- a/board/freescale/qemu-ppce500/qemu-ppce500.c +++ b/board/freescale/qemu-ppce500/qemu-ppce500.c @@ -23,6 +23,8 @@ #include <fdtdec.h> #include <errno.h> #include <malloc.h> +#include <virtio_types.h> +#include <virtio.h>
DECLARE_GLOBAL_DATA_PTR;
@@ -129,6 +131,12 @@ int misc_init_r(void) if (ret) return ret;
+ /* + * Make sure virtio bus is enumerated so that peripherals + * on the virtio bus can be discovered by their drivers. + */ + virtio_init(); + return 0; }
diff --git a/configs/qemu-ppce500_defconfig b/configs/qemu-ppce500_defconfig index 918739b..202e97e 100644 --- a/configs/qemu-ppce500_defconfig +++ b/configs/qemu-ppce500_defconfig @@ -33,5 +33,7 @@ CONFIG_DM_PCI=y CONFIG_PCI_MPC85XX=y CONFIG_DM_SERIAL=y CONFIG_SYS_NS16550=y +CONFIG_VIRTIO_PCI=y +CONFIG_VIRTIO_NET=y CONFIG_ADDR_MAP=y CONFIG_PANIC_HANG=y

board/emulation is the place for other QEMU targets like x86, arm, riscv. Let's move the qemu-ppce500 board codes there.
List me as a co-maintainer for this board.
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
arch/powerpc/cpu/mpc85xx/Kconfig | 2 +- board/{freescale => emulation}/qemu-ppce500/Kconfig | 2 +- board/{freescale => emulation}/qemu-ppce500/MAINTAINERS | 3 ++- board/{freescale => emulation}/qemu-ppce500/Makefile | 0 board/{freescale => emulation}/qemu-ppce500/qemu-ppce500.c | 1 + 5 files changed, 5 insertions(+), 3 deletions(-) rename board/{freescale => emulation}/qemu-ppce500/Kconfig (86%) rename board/{freescale => emulation}/qemu-ppce500/MAINTAINERS (67%) rename board/{freescale => emulation}/qemu-ppce500/Makefile (100%) rename board/{freescale => emulation}/qemu-ppce500/qemu-ppce500.c (99%)
diff --git a/arch/powerpc/cpu/mpc85xx/Kconfig b/arch/powerpc/cpu/mpc85xx/Kconfig index 54c7fd9..d40ea85 100644 --- a/arch/powerpc/cpu/mpc85xx/Kconfig +++ b/arch/powerpc/cpu/mpc85xx/Kconfig @@ -1437,6 +1437,7 @@ config SYS_FSL_LBC_CLK_DIV Defines divider of platform clock(clock input to eLBC controller).
+source "board/emulation/qemu-ppce500/Kconfig" source "board/freescale/corenet_ds/Kconfig" source "board/freescale/mpc8541cds/Kconfig" source "board/freescale/mpc8544ds/Kconfig" @@ -1448,7 +1449,6 @@ source "board/freescale/mpc8572ds/Kconfig" source "board/freescale/p1010rdb/Kconfig" source "board/freescale/p1_p2_rdb_pc/Kconfig" source "board/freescale/p2041rdb/Kconfig" -source "board/freescale/qemu-ppce500/Kconfig" source "board/freescale/t102xrdb/Kconfig" source "board/freescale/t104xrdb/Kconfig" source "board/freescale/t208xqds/Kconfig" diff --git a/board/freescale/qemu-ppce500/Kconfig b/board/emulation/qemu-ppce500/Kconfig similarity index 86% rename from board/freescale/qemu-ppce500/Kconfig rename to board/emulation/qemu-ppce500/Kconfig index 236cd17..4312d98 100644 --- a/board/freescale/qemu-ppce500/Kconfig +++ b/board/emulation/qemu-ppce500/Kconfig @@ -4,7 +4,7 @@ config SYS_BOARD default "qemu-ppce500"
config SYS_VENDOR - default "freescale" + default "emulation"
config SYS_CONFIG_NAME default "qemu-ppce500" diff --git a/board/freescale/qemu-ppce500/MAINTAINERS b/board/emulation/qemu-ppce500/MAINTAINERS similarity index 67% rename from board/freescale/qemu-ppce500/MAINTAINERS rename to board/emulation/qemu-ppce500/MAINTAINERS index e70c095..7317983 100644 --- a/board/freescale/qemu-ppce500/MAINTAINERS +++ b/board/emulation/qemu-ppce500/MAINTAINERS @@ -1,6 +1,7 @@ QEMU-PPCE500 BOARD M: Alexander Graf agraf@csgraf.de +M: Bin Meng bmeng.cn@gmail.com S: Maintained -F: board/freescale/qemu-ppce500/ +F: board/emulation/qemu-ppce500/ F: include/configs/qemu-ppce500.h F: configs/qemu-ppce500_defconfig diff --git a/board/freescale/qemu-ppce500/Makefile b/board/emulation/qemu-ppce500/Makefile similarity index 100% rename from board/freescale/qemu-ppce500/Makefile rename to board/emulation/qemu-ppce500/Makefile diff --git a/board/freescale/qemu-ppce500/qemu-ppce500.c b/board/emulation/qemu-ppce500/qemu-ppce500.c similarity index 99% rename from board/freescale/qemu-ppce500/qemu-ppce500.c rename to board/emulation/qemu-ppce500/qemu-ppce500.c index a105130..4955563 100644 --- a/board/freescale/qemu-ppce500/qemu-ppce500.c +++ b/board/emulation/qemu-ppce500/qemu-ppce500.c @@ -1,6 +1,7 @@ // SPDX-License-Identifier: GPL-2.0+ /* * Copyright 2007,2009-2014 Freescale Semiconductor, Inc. + * Copyright (C) 2021, Bin Meng bmeng.cn@gmail.com */
#include <common.h>

Add a reST document to describe how to build and run U-Boot for the QEMU ppce500 machine.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
---
doc/board/emulation/index.rst | 1 + doc/board/emulation/qemu-ppce500.rst | 73 ++++++++++++++++++++++++++++++++++++ 2 files changed, 74 insertions(+) create mode 100644 doc/board/emulation/qemu-ppce500.rst
diff --git a/doc/board/emulation/index.rst b/doc/board/emulation/index.rst index a09ead1..be66b6b 100644 --- a/doc/board/emulation/index.rst +++ b/doc/board/emulation/index.rst @@ -8,6 +8,7 @@ Emulation
qemu-arm qemu-mips + qemu-ppce500 qemu-riscv qemu-x86 qemu_capsule_update diff --git a/doc/board/emulation/qemu-ppce500.rst b/doc/board/emulation/qemu-ppce500.rst new file mode 100644 index 0000000..7472867 --- /dev/null +++ b/doc/board/emulation/qemu-ppce500.rst @@ -0,0 +1,73 @@ +.. SPDX-License-Identifier: GPL-2.0+ +.. Copyright (C) 2021, Bin Meng bmeng.cn@gmail.com + +QEMU PPC E500 +============= + +QEMU for PPC supports a special 'ppce500' machine designed for emulation and +virtualization purposes. This document describes how to run U-Boot under it. + +The QEMU ppce500 machine models a generic PowerPC E500 virtual machine with +support for the VirtIO standard networking device connected to the built-in +PCI host controller. Some common devices in the CCSBAR space are modeled, +including MPIC, 16550A UART devices, GPIO, I2C and PCI host controller with +MSI delivery to MPIC. It uses device-tree to pass configuration information +to guest software. + +Building U-Boot +--------------- +Set the CROSS_COMPILE environment variable as usual, and run:: + + $ make qemu-ppce500_defconfig + $ make + +Running U-Boot +-------------- +The minimal QEMU command line to get U-Boot up and running is:: + + $ qemu-system-ppc -nographic -machine ppce500 -bios u-boot + +You can also run U-Boot using 'qemu-system-ppc64':: + + $ qemu-system-ppc64 -nographic -machine ppce500 -bios u-boot + +The commands above create a target with 128 MiB memory by default. A freely +configurable amount of RAM can be created via the '-m' parameter. For example, +'-m 2G' creates 2 GiB memory for the target, and the memory node in the +embedded DTB created by QEMU reflects the new setting. + +Both qemu-system-ppc and qemu-system-ppc64 provide emulation for the following +32-bit PowerPC CPUs: + +* e500v2 +* e500mc + +Additionally qemu-system-ppc64 provides support for the following 64-bit CPUs: + +* e5500 +* e6500 + +The CPU type can be specified via the '-cpu' command line. If not specified, +it creates a machine with e500v2 core. The following example shows an e6500 +based machine creation:: + + $ qemu-system-ppc64 -nographic -machine ppce500 -cpu e6500 -bios u-boot + +When U-Boot boots, you will notice the following:: + + CPU: Unknown, Version: 0.0, (0x00000000) + Core: e6500, Version: 2.0, (0x80400020) + +This is because we only specified a core name to QEMU and it does not have a +meaningful SVR value which represents an actual SoC that integrates such core. +You can specify a real world SoC device that QEMU has built-in support but all +these SoCs are e500v2 based MPC85xx series, hence you cannot test anything +built for P4080 (e500mc), P5020 (e5500) and T2080 (e6500). + +By default a VirtIO standard PCI networking device is connected as an ethernet +interface at PCI address 0.1.0, but we can switch that to an e1000 NIC by:: + + $ qemu-system-ppc -nographic -machine ppce500 -bios u-boot \ + -nic tap,ifname=tap0,script=no,downscript=no,model=e1000 + +These have been tested in QEMU 5.2.0.

On Sun, 7 Feb 2021 at 08:13, Bin Meng bmeng.cn@gmail.com wrote:
Add a reST document to describe how to build and run U-Boot for the QEMU ppce500 machine.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
doc/board/emulation/index.rst | 1 + doc/board/emulation/qemu-ppce500.rst | 73 ++++++++++++++++++++++++++++++++++++ 2 files changed, 74 insertions(+) create mode 100644 doc/board/emulation/qemu-ppce500.rst
Reviewed-by: Simon Glass sjg@chromium.org

On Sun, Feb 7, 2021 at 11:11 PM Bin Meng bmeng.cn@gmail.com wrote:
At present when building qemu-ppce500 the following warnings are seen:
===================== WARNING ====================== This board does not use CONFIG_DM. CONFIG_DM will be compulsory starting with the v2020.01 release. Failure to update may result in board removal. UPD include/generated/timestamp_autogenerated.h See doc/driver-model/migration.rst for more info. ==================================================== ===================== WARNING ====================== This board does not use CONFIG_DM_PCI Please update the board to use CONFIG_DM_PCI before the v2019.07 release. Failure to update by the deadline may result in board removal. See doc/driver-model/migration.rst for more info. ==================================================== ===================== WARNING ====================== This board does not use CONFIG_DM_ETH (Driver Model for Ethernet drivers). Please update the board to use CONFIG_DM_ETH before the v2020.07 release. Failure to update by the deadline may result in board removal. See doc/driver-model/migration.rst for more info. ====================================================
The conversion of qemu-ppce500 board to driver model is long overdue.
When testing the exisitng qemu-ppce500 support, PCI was found broken. This is caused by 2 separate issues:
- One issue was caused by U-Boot: Commit e002474158d1 ("pci: pci-uclass: Dynamically allocate the PCI regions") Patch #1 reverts this commit as it broken all boards that have not converted to driver model PCI.
- One issue was caused by QEMU: commit e6b4e5f4795b ("PPC: e500: Move CCSR and MMIO space to upper end of address space") commit cb3778a0455a ("PPC: e500 pci host: Add support for ATMUs") Patch #3-4 fixed this issue to keep in sync with latest QEMU upstream
Patch #5-8 are minor fixes and clean-ups.
Starting from patch#9, these are driver model conversion patches.
Patch #11-16 are mainly related to CONFIG_ADDR_MAP, a library to support targets that have non-identity virtual-physical address mappings. A new command 'addrmap' is introduced to aid debugging, and a fix to arch/powerpc/asm/include/io.h is made to correct the usage of CONFIG_ADDR_MAP as it can only be used in the post- relocation phase. Also the initialization of this library is moved a bit earlier in the post-relocation phase otherwise device drivers won't work.
Patch #18-20 are 85xx PCI driver fixes. It adds support to controller register physical address beyond 32-bit, as well as support to 64-bit bus and cpu address as current upstream QEMU uses 64-bit cpu address.
Patch #23 is minor fix to the 'virtio' command dependency.
Patch #24 enables the VirtIO NET support as by default a VirtIO standard PCI networking device is connected as an ethernet interface at PCI address 0.1.0.
Patch #25 moves the qemu-ppce500 boards codes to board/emulation as that is the place for other QEMU targets like x86, arm, riscv.
Patch #26 adds a reST document to describe how to build and run U-Boot for the QEMU ppce500 machine.
I hope we can make this series to U-Boot v2021.04 release.
This series is available at u-boot-x86/qemu-ppc for testing.
This cover letter is cc'ed to QEMU mailing list for a heads-up. A future patch will be sent to QEMU mailing list to bring its in-tree U-Boot source codes up-to-date.
Bin Meng (26): Revert "pci: pci-uclass: Dynamically allocate the PCI regions" ppc: qemu: Update MAINTAINERS for correct email address common: fdt_support: Support special case of PCI address in fdt_read_prop() ppc: qemu: Support non-identity PCI bus address ppc: qemu: Fix CONFIG_SYS_PCI_MAP_END ppc: mpc85xx: Wrap LAW related codes with CONFIG_FSL_LAW ppc: qemu: Drop init_laws() and print_laws() ppc: qemu: Drop board_early_init_f() ppc: qemu: Enable OF_CONTROL ppc: qemu: Enable driver model include: Remove extern from addr_map.h lib: addr_map: Move address_map[] type to the header file cmd: Add a command to display the address map lib: kconfig: Mention CONFIG_ADDR_MAP limitation in the help ppc: io.h: Use addrmap_ translation APIs only in post-relocation phase common: Move initr_addr_map() to a bit earlier ppc: qemu: Switch over to use DM serial pci: mpc85xx: Wrap LAW programming with CONFIG_FSL_LAW pci: mpc85xx: Support controller register physical address beyond 32-bit pci: mpc85xx: Support 64-bit bus and cpu address ppc: qemu: Switch over to use DM ETH and PCI ppc: qemu: Drop CONFIG_OF_BOARD_SETUP cmd: Fix virtio command dependency ppc: qemu: Enable VirtIO NET support ppc: qemu: Move board directory from board/freescale to board/emulation doc: Add a reST document for qemu-ppce500
arch/powerpc/cpu/mpc85xx/Kconfig | 2 +- arch/powerpc/cpu/mpc85xx/cpu.c | 2 + arch/powerpc/cpu/mpc85xx/cpu_init_early.c | 2 + arch/powerpc/include/asm/io.h | 15 +- .../{freescale => emulation}/qemu-ppce500/Kconfig | 2 +- board/emulation/qemu-ppce500/MAINTAINERS | 7 + .../{freescale => emulation}/qemu-ppce500/Makefile | 0 .../qemu-ppce500/qemu-ppce500.c | 159 ++++++--------------- board/freescale/qemu-ppce500/MAINTAINERS | 6 - cmd/Kconfig | 8 ++ cmd/Makefile | 1 + cmd/addrmap.c | 35 +++++ common/board_r.c | 6 +- common/fdt_support.c | 15 +- configs/qemu-ppce500_defconfig | 14 +- doc/board/emulation/index.rst | 1 + doc/board/emulation/qemu-ppce500.rst | 73 ++++++++++ drivers/pci/pci-uclass.c | 14 +- drivers/pci/pci_mpc85xx.c | 25 ++-- include/addr_map.h | 16 ++- include/configs/qemu-ppce500.h | 25 +--- include/pci.h | 4 +- lib/Kconfig | 2 + lib/addr_map.c | 6 +- 24 files changed, 250 insertions(+), 190 deletions(-) rename board/{freescale => emulation}/qemu-ppce500/Kconfig (86%) create mode 100644 board/emulation/qemu-ppce500/MAINTAINERS rename board/{freescale => emulation}/qemu-ppce500/Makefile (100%) rename board/{freescale => emulation}/qemu-ppce500/qemu-ppce500.c (68%) delete mode 100644 board/freescale/qemu-ppce500/MAINTAINERS create mode 100644 cmd/addrmap.c create mode 100644 doc/board/emulation/qemu-ppce500.rst
Alex, Priyanka, do you have some time to review this series?
Regards, Bin
participants (6)
-
Bin Meng
-
Daniel Schwierzeck
-
Marek Vasut
-
Simon Glass
-
Stefan Roese
-
Tom Rini