Re: [PULL 00/17] aspeed queue

[Cédric Le Goater]

On 1/26/24 16:56, Peter Maydell wrote:
> On Fri, 26 Jan 2024 at 13:33, Cédric Le Goater <clg@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.