target/riscv/cpu_vendorid.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
We have already sent patch set for introducing MIPS's p8700 CPU in qemu at: https://patchew.org/QEMU/20251018154522.745788-1-djordje.todorovic@htecgroup.com/ So, this is a bugfix that should go on top of it. Djordje Todorovic (1): riscv: Update MIPS vendor id target/riscv/cpu_vendorid.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 2.34.1
On Wed, Nov 5, 2025 at 1:07 AM Djordje Todorovic <Djordje.Todorovic@htecgroup.com> wrote: > > We have already sent patch set for introducing MIPS's > p8700 CPU in qemu at: > > https://patchew.org/QEMU/20251018154522.745788-1-djordje.todorovic@htecgroup.com/ That series was dropped as it failed to pass the CI tests: https://patchew.org/QEMU/20251023041435.1775208-1-alistair.francis@wdc.com/ You can just include this change in a new patchset Alistair > > So, this is a bugfix that should go on top of it. > > Djordje Todorovic (1): > riscv: Update MIPS vendor id > > target/riscv/cpu_vendorid.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > -- > 2.34.1
On 5. 11. 25. 00:08, Alistair Francis wrote: > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. > > > On Wed, Nov 5, 2025 at 1:07 AM Djordje Todorovic > <Djordje.Todorovic@htecgroup.com> wrote: >> We have already sent patch set for introducing MIPS's >> p8700 CPU in qemu at: >> >> https://patchew.org/QEMU/20251018154522.745788-1-djordje.todorovic@htecgroup.com/ > That series was dropped as it failed to pass the CI tests: > https://patchew.org/QEMU/20251023041435.1775208-1-alistair.francis@wdc.com/ > > You can just include this change in a new patchset > > Alistair > Hi Alistair, I am looking into the https://gitlab.com/qemu-project/qemu/-/jobs/11827080939#L5859 and it seems that it did not get the binaries from: https://github.com/MIPS/linux-test-downloads/raw/main/p8700/fw_payload.bin The test for Boston board should try to download that, but there is TIMEOUT set for it. Any advice on how to check this on the s390x machine? Is there a way to run the CI from a fork? Thanks a lot, Djordje >> So, this is a bugfix that should go on top of it. >> >> Djordje Todorovic (1): >> riscv: Update MIPS vendor id >> >> target/riscv/cpu_vendorid.h | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> -- >> 2.34.1
On 06/11/2025 11.16, Djordje Todorovic wrote: > > On 5. 11. 25. 00:08, Alistair Francis wrote: >> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. >> >> >> On Wed, Nov 5, 2025 at 1:07 AM Djordje Todorovic >> <Djordje.Todorovic@htecgroup.com> wrote: >>> We have already sent patch set for introducing MIPS's >>> p8700 CPU in qemu at: >>> >>> https://patchew.org/QEMU/20251018154522.745788-1-djordje.todorovic@htecgroup.com/ >> That series was dropped as it failed to pass the CI tests: >> https://patchew.org/QEMU/20251023041435.1775208-1-alistair.francis@wdc.com/ >> >> You can just include this change in a new patchset >> >> Alistair >> > Hi Alistair, > > > I am looking into the > https://gitlab.com/qemu-project/qemu/-/jobs/11827080939#L5859 > > and it seems that it did not get the binaries from: > > https://github.com/MIPS/linux-test-downloads/raw/main/p8700/fw_payload.bin > > The test for Boston board should try to download that, but there is > TIMEOUT set for it. According to the job log, the test has been added to the "quick" category. If the test downloads assets, it has to be in the "thorough" category instead, otherwise you might run into timeouts when the download takes to long. (See also the "Asset handling" section in docs/devel/testing/functional.rst) HTH, Thomas
© 2016 - 2025 Red Hat, Inc.