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

Conor Dooley conor.dooley at microchip.com
Tue Apr 23 14:41:56 CEST 2024


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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20240423/c2f250c5/attachment.sig>


More information about the U-Boot mailing list