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 >
signature.asc
Description: PGP signature