Hello Cedric,
Sure, Let me check.
On 1/26/24 10:48, Cédric Le Goater wrote:
On 1/26/24 16:56, Peter Maydell wrote:
On Fri, 26 Jan 2024 at 13:33, Cédric Le Goater <c...@kaod.org> wrote:
The following changes since commit
e029fe22caad9b75c7ab69bd4e84853c11fb71e0:
Merge tag 'pull-qapi-2024-01-26' of
https://repo.or.cz/qemu/armbru into staging (2024-01-26 10:21:27 +0000)
are available in the Git repository at:
https://github.com/legoater/qemu/ tags/pull-aspeed-20240126
for you to fetch changes up to
b40769f4b49d15485ffaaa7acade3e3593ee6daa:
hw/fsi: Update MAINTAINER list (2024-01-26 14:22:08 +0100)
----------------------------------------------------------------
aspeed queue:
* Update of buildroot images to 2023.11 (6.6.3 kernel)
* Check of the valid CPU type supported by aspeed machines
* Simplified models for the IBM's FSI bus and the Aspeed
controller bridge
----------------------------------------------------------------
Looks like you have an endianness bug, either in the device
or in the test. From the s390 runner:
https://gitlab.com/qemu-project/qemu/-/jobs/6029422595
232/847 qemu:qtest+qtest-arm / qtest-arm/aspeed-fsi-test ERROR 0.38s
killed by signal 6 SIGABRT
PYTHON=/home/gitlab-runner/builds/-LCfcJ2T/0/qemu-project/qemu/build/pyvenv/bin/python3
QTEST_QEMU_STORAGE_DAEMON_BINARY=./storage-daemon/qemu-storage-daemon
QTEST_QEMU_BINARY=./qemu-system-arm
G_TEST_DBUS_DAEMON=/home/gitlab-runner/builds/-LCfcJ2T/0/qemu-project/qemu/tests/dbus-vmstate-daemon.sh
MALLOC_PERTURB_=82 QTEST_QEMU_IMG=./qemu-img
/home/gitlab-runner/builds/-LCfcJ2T/0/qemu-project/qemu/build/tests/qtest/aspeed-fsi-test
--tap -k
――――――――――――――――――――――――――――――――――――― ✀
―――――――――――――――――――――――――――――――――――――
stderr:
**
ERROR:../tests/qtest/aspeed-fsi-test.c:152:test_fsi0_getcfam_addr0:
assertion failed (curval == 0x152d02c0): (3221368085 == 355271360)
(test program exited with status code -6)
where 3221368085 is 0xC0022D15, and 355271360 is 0x152D02C0...
drat. Indeed. I didn't check BE ... Sorry about that.
Ninad,
Some changes are required in fsi_aspeed_apb2opb_write().
Could you please rework the address space accesses to use
address_space_*_le() routines instead of address_space_rw() ?
This will be less concise.
To check, you can use a PPC64 debian (big-endian) on a PPC64
KVM guest or PowerVM LPAR, or a s390x LPAR.
Thanks,
C.
