RISC-V u-boot unable to boot QEMU using '-cpu max'

[Daniel Henrique Barboza]

On 4/23/24 09:41, Conor Dooley wrote:
> On Tue, Apr 23, 2024 at 01:34:42PM +0800, Leo Liang wrote:
>> On Mon, Apr 22, 2024 at 04:43:59PM -0300, Daniel Henrique Barboza wrote:
>>> [EXTERNAL MAIL]
>>>
>>> Hi,
>>>
>>> In QEMU we have a 'max' type CPU that implements (almost) all extensions that QEMU
>>> is able to emulate. Recently, in QEMU commit 249e0905d05, we bumped the extensions
>>> for this CPU.
>>>
>>> And after this commit this CPU is now unable to boot a guest using upstream
>>> u-boot. Here's the error being thrown:
>>>
>>> qemu-system-riscv64 \
>>>          -machine virt -nographic -m 8G -smp 8 \
>>>          -cpu max -kernel uboot.elf (...)
>>> (...)
>>>
>>> initcall sequence 000000008027c3e8 failed at call 000000008021259e (err=-28)
>>> ### ERROR ### Please RESET the board ###
>>>
>>>
>>> I can get the guest to boot if I disable the following extensions from the 'max' CPU:
>>>
>>>   -cpu max,zfbfmin=false,zvfbfmin=false,zvfbfwma=false
>>>
>>> Due to QEMU extension dependencies I'm not able to disable these individually. What I can
>>> say is that u-boot isn't playing ball to at least one of them.
>>>
>>> Is this an u-boot bug? Up to this point I was assuming that u-boot would silently ignore
>>> hart extensions that it doesn't support.
>>
>> Hi Daniel,
>>
>> Which u-boot version are you using?
>>
>> I think this issue is fixed by the following patch set sent by Conor.
>>
>> 	f39b1b77d8 riscv: support extension probing using riscv, isa-extensions
>> 	b90edde701 riscv: don't read riscv, isa in the riscv cpu's get_desc()
>>
>> I've tested and can reproduce the issue you mentioned if these two patches are reverted.
>>
>> Could you try with the lastest u-boot master branch again?
>>
>>
>> For reference, my testing commands are as follows:
>> 1. cd ${u-boot} && make qemu-riscv64_defconfig && make -j`nproc`
>> 2. ./${qemu}/build/qemu-system-riscv64 -nographic -machine virt -cpu max -bios u-boot.bin -m 8G -smp 8
>>
>> - u-boot branch (commit): master (38ea74d6d5c0 "Prepare v2024.07-rc1")
>> - qemu branch (commit): master (62dbe54c24db "Update version for v9.0.0-rc4 release")
> 
> I'll go take a look at this, it's possible that my patches only hide the
> problem due to the new property being prioritised.


Don't bother. I just checked with most recent u-boot master and I can't reproduce the
problem, as Leo said.

I apologize for the noise. I failed to fetch the latest upstream and do a last
test before posting it here.

We were discussing here and there about disabling these extensions in the 'max'
CPU in QEMU if u-boot wasn't able to handle them. I'm happy to see that u-boot
is now able to do so and we can keep the 'max' CPU as is.


Thanks for the help,

Daniel