[PATCH v1 0/1] riscv: Update MIPS vendor id

Djordje Todorovic posted 1 patch 1 week, 4 days ago
Failed in applying to current master (apply log)
target/riscv/cpu_vendorid.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
[PATCH v1 0/1] riscv: Update MIPS vendor id
Posted by Djordje Todorovic 1 week, 4 days ago
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
Re: [PATCH v1 0/1] riscv: Update MIPS vendor id
Posted by Alistair Francis 1 week, 4 days ago
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
Re: [PATCH v1 0/1] riscv: Update MIPS vendor id
Posted by Djordje Todorovic 1 week, 2 days ago
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
Re: [PATCH v1 0/1] riscv: Update MIPS vendor id
Posted by Thomas Huth 1 week, 2 days ago
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