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

[Conor Dooley]

On Tue, Apr 23, 2024 at 09:52:06AM -0300, Daniel Henrique Barboza wrote:
> 
> 
> 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.

My "fear" was that new QEMU + new U-Boot meant that the
riscv,isa-extensions codepath was in use and there was something lurking in
the riscv,isa parsing which had a problem. Fortunately, I think that's
not the case, as the fix seems to be b90edde701 "riscv: don't read riscv,isa
in the riscv cpu's get_desc()" rather than f39b1b77d8 "riscv: support
extension probing using riscv, isa-extensions".

I am, however, not going to look into why exactly it was failing before,
I'm satisfied once the riscv,isa parsing isn't broken in master.

> 
> 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
> 
-------------- 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/b5a4996c/attachment.sig>