Hello,
On Thu, 26 May 2022, Daniel Henrique Barboza wrote:
Hi,
This patch broke the boot of the sam460ex ppc machine:
qemu-system-ppc -M sam460ex -kernel
./buildroot/qemu_ppc_sam460ex-latest/vmlinux \
-device virtio-net-pci,netdev=net0 -netdev user,id=net0 -serial mon:stdio \
-nographic -snapshot
qemu-system-ppc: ../hw/pci/pcie_host.c:97: pcie_host_mmcfg_init: Assertion
`size <= PCIE_MMCFG_SIZE_MAX' failed.
Thanks for noticing this. I usually only test it during the freeze. Wasn't
there a test patch submitted by Philippe before? Isn't that yet merged or
included in CI? That should catch these before breaking it.
The reason is that it changed commit 58d5b22bbd5 ("ppc4xx: Add device
models found in PPC440 core SoCs")) in a way that it wasn't expected by
the board. The code seems to believe that, for a reason that isn't
stated in the 58d5b22bbd5 commit message, PCIE_MMCFG_SIZE_MAX must be
set to 1 << 29.
I'm CCing BALATON Zoltan since he's the author of 58d5b22bbd5 and can
provide context of his initial change and why the board seems to rely on
it. qemu-ppc is being CCed for awareness of the sam460ex problem.
I'm afraid I don't remember but maybe I did not have a definitive answer
even back then as the docs for this PCIe controller were not available so
I've mostly worked from docs for similar SoCs and U-Boot and Linux sources
so there were a lot of guessing. Maybe it's related to that the board maps
peripheral addresses above 4GB as the first 4GB is reserved for memory? Or
maybe there's some mixup between address spaces and the PCIe controller
should have a separate address space that's mapped in the system? I did
not have any knowledge about this back then and my understanding may still
be lacking on how this should work.
Zoltan, I wasn't able to amend to quickly amend the code in a way that I
could preserve the current PCIE_MMCFG_SIZE_MAX setting and make sam460ex
work again. Can you please take a look?
The PCIe controllers of the 460EX are implemented at the end of
hw/ppc/ppc440_uc.c (a lot of these 4xx SoCs are sharing components and the
code organisation is a bit messy). As the comment near it says it's not
really fully tested and working. only good enough for firmware and OSes
get past testing it. I think trying to attach any device to it probably
would fail or I would be surprised if the OS could actually talk to it as
there may be some missing parts. So I'm happy with any solution that keeps
the current state of being able to boot the OSes running on it (some of
which like AmigaOS and MorphOS are closed source though so I don't know
what their drivers need; closest open source OS to them is AROS but not
sure that's working on real hardware). Some advice from somebody more
knowledgeable about PCIe emulation in QEMU would be welcome here.
Regards,
BALATON Zoltan
Thanks,
Daniel
On 5/16/22 17:55, Michael S. Tsirkin wrote:
From: Francisco Iglesias <frasse.igles...@gmail.com>
According to 7.2.2 in [1] bit 27 is the last bit that can be part of the
bus number, this makes the ECAM max size equal to '1 << 28'. This patch
restores back this value into the PCIE_MMCFG_SIZE_MAX define (which was
changed in commit 58d5b22bbd5 ("ppc4xx: Add device models found in PPC440
core SoCs")).
[1] PCI Express® Base Specification Revision 5.0 Version 1.0
Signed-off-by: Francisco Iglesias <frasse.igles...@gmail.com>
Message-Id: <20220411221836.17699-3-frasse.igles...@gmail.com>
Reviewed-by: Michael S. Tsirkin <m...@redhat.com>
Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
---
include/hw/pci/pcie_host.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/hw/pci/pcie_host.h b/include/hw/pci/pcie_host.h
index b3c8ce973c..82d92177da 100644
--- a/include/hw/pci/pcie_host.h
+++ b/include/hw/pci/pcie_host.h
@@ -65,7 +65,7 @@ void pcie_host_mmcfg_update(PCIExpressHost *e,
* bit 12 - 14: function number
* bit 0 - 11: offset in configuration space of a given device
*/
-#define PCIE_MMCFG_SIZE_MAX (1ULL << 29)
+#define PCIE_MMCFG_SIZE_MAX (1ULL << 28)
#define PCIE_MMCFG_SIZE_MIN (1ULL << 20)
#define PCIE_MMCFG_BUS_BIT 20
#define PCIE_MMCFG_BUS_MASK 0xff
