* RISC-V u-boot unable to boot QEMU using '-cpu max'
@ 2024-04-22 19:43 Daniel Henrique Barboza
2024-04-23 5:34 ` Leo Liang
0 siblings, 1 reply; 5+ messages in thread
From: Daniel Henrique Barboza @ 2024-04-22 19:43 UTC (permalink / raw
To: u-boot; +Cc: Andrew Jones
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.
Thanks,
Daniel
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: RISC-V u-boot unable to boot QEMU using '-cpu max'
2024-04-22 19:43 RISC-V u-boot unable to boot QEMU using '-cpu max' Daniel Henrique Barboza
@ 2024-04-23 5:34 ` Leo Liang
2024-04-23 12:41 ` Conor Dooley
0 siblings, 1 reply; 5+ messages in thread
From: Leo Liang @ 2024-04-23 5:34 UTC (permalink / raw
To: Daniel Henrique Barboza; +Cc: u-boot, Andrew Jones
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")
Best regards,
Leo
>
>
> Thanks,
>
>
> Daniel
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: RISC-V u-boot unable to boot QEMU using '-cpu max'
2024-04-23 5:34 ` Leo Liang
@ 2024-04-23 12:41 ` Conor Dooley
2024-04-23 12:52 ` Daniel Henrique Barboza
0 siblings, 1 reply; 5+ messages in thread
From: Conor Dooley @ 2024-04-23 12:41 UTC (permalink / raw
To: Leo Liang; +Cc: Daniel Henrique Barboza, u-boot, Andrew Jones
[-- Attachment #1: Type: text/plain, Size: 2249 bytes --]
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.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: RISC-V u-boot unable to boot QEMU using '-cpu max'
2024-04-23 12:41 ` Conor Dooley
@ 2024-04-23 12:52 ` Daniel Henrique Barboza
2024-04-23 14:23 ` Conor Dooley
0 siblings, 1 reply; 5+ messages in thread
From: Daniel Henrique Barboza @ 2024-04-23 12:52 UTC (permalink / raw
To: Conor Dooley, Leo Liang; +Cc: u-boot, Andrew Jones
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: RISC-V u-boot unable to boot QEMU using '-cpu max'
2024-04-23 12:52 ` Daniel Henrique Barboza
@ 2024-04-23 14:23 ` Conor Dooley
0 siblings, 0 replies; 5+ messages in thread
From: Conor Dooley @ 2024-04-23 14:23 UTC (permalink / raw
To: Daniel Henrique Barboza; +Cc: Conor Dooley, Leo Liang, u-boot, Andrew Jones
[-- Attachment #1: Type: text/plain, Size: 3665 bytes --]
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
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2024-04-23 14:24 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-04-22 19:43 RISC-V u-boot unable to boot QEMU using '-cpu max' Daniel Henrique Barboza
2024-04-23 5:34 ` Leo Liang
2024-04-23 12:41 ` Conor Dooley
2024-04-23 12:52 ` Daniel Henrique Barboza
2024-04-23 14:23 ` Conor Dooley
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.