Running qemu tests on RISC-V

Running qemu tests on RISC-V

[Simon Glass]

Hi,

I am trying to run the SPL tests for riscv32 but it dies with an
illegal instruction. I have tried building qemu 4.2 but it seems to
happen on various versions. Has anyone seen this?


+u-boot-test-reset qemu-riscv32_spl na

U-Boot SPL 2022.01 (Feb 07 2022 - 08:33:30 -0700)
Trying to boot from RAM
Unhandled exception: Illegal instruction
EPC: 8UUU1000564nhandled nhandled exception:nhandled exceptexception:
ion:  RA: 810000IIllegal10 instruction
Illllegal inegal instruction
EPC: structEPC: ion
EPC:  TVAL: 81081000564 RA: 008100564 RA: 8100000100010 TVAL: 00000000 TV
0000000
AL: 00
ode:00000

Code:3400
050 808334004082 0073 00 8081050 2 bff5 0001 55b7007 4942 ( 3 859b 134f5)
2 0073 bff5
0
001 1050 bff5 055b7 001 55b74942  4942 ((859b 859b 34f34f5)
5)




81000564 RA: 81000010 TVAL: 00000000

Code: 3400 8082 0073 1050 bff5 0001 55b7 4942 (859b 34f5)


resresetting ...
pporesetting ...ng ...
rese
trtered ys not supported yet
### ERROet
R ### Please RES### ERRet notET the board ###
OR ### Please  sRESEupT the board ###
ported yet
### ERROR ### Please RESET the board ###

Regards,
Simon

Re: Running qemu tests on RISC-V

[Heinrich Schuchardt]

On 2/7/22 16:38, Simon Glass wrote:
> Hi,
>
> I am trying to run the SPL tests for riscv32 but it dies with an
> illegal instruction. I have tried building qemu 4.2 but it seems to
> happen on various versions. Has anyone seen this?

Did you try to run qemu-riscv32_spl_defconfig in the Docker container we
are using for Gitlab?

We are using QEMU v6.1.0 according to tools/docker/Dockerfile.

With all that duplicate output below it is hard to understand what is
going. Why is each byte written twice to the serial?

Best regards

Heinrich

>
>
> +u-boot-test-reset qemu-riscv32_spl na
>
> U-Boot SPL 2022.01 (Feb 07 2022 - 08:33:30 -0700)
> Trying to boot from RAM
> Unhandled exception: Illegal instruction
> EPC: 8UUU1000564nhandled nhandled exception:nhandled exceptexception:
> ion:  RA: 810000IIllegal10 instruction
> Illllegal inegal instruction
> EPC: structEPC: ion
> EPC:  TVAL: 81081000564 RA: 008100564 RA: 8100000100010 TVAL: 00000000 TV
> 0000000
> AL: 00
> ode:00000
>
> Code:3400
> 050 808334004082 0073 00 8081050 2 bff5 0001 55b7007 4942 ( 3 859b 134f5)
> 2 0073 bff5
> 0
> 001 1050 bff5 055b7 001 55b74942  4942 ((859b 859b 34f34f5)
> 5)
>
>
>
>
> 81000564 RA: 81000010 TVAL: 00000000
>
> Code: 3400 8082 0073 1050 bff5 0001 55b7 4942 (859b 34f5)
>
>
> resresetting ...
> pporesetting ...ng ...
> rese
> trtered ys not supported yet
> ### ERROet
> R ### Please RES### ERRet notET the board ###
> OR ### Please  sRESEupT the board ###
> ported yet
> ### ERROR ### Please RESET the board ###
>
> Regards,
> Simon

Re: Running qemu tests on RISC-V

[Michael Lawnick]

Hi Simon,

having absolutely no knowledge about the details here just 2 cents:
It looks like concurrent run of multiple cores. Are you sure that all
cores beside #0 are properly caught and blocked on start?

KR
Michael

Am 07.02.2022 um 16:38 schrieb Simon Glass:
> Hi,
>
> I am trying to run the SPL tests for riscv32 but it dies with an
> illegal instruction. I have tried building qemu 4.2 but it seems to
> happen on various versions. Has anyone seen this?
>
>
> +u-boot-test-reset qemu-riscv32_spl na
>
> U-Boot SPL 2022.01 (Feb 07 2022 - 08:33:30 -0700)
> Trying to boot from RAM
> Unhandled exception: Illegal instruction
> EPC: 8UUU1000564nhandled nhandled exception:nhandled exceptexception:
> ion:  RA: 810000IIllegal10 instruction
> Illllegal inegal instruction
> EPC: structEPC: ion
> EPC:  TVAL: 81081000564 RA: 008100564 RA: 8100000100010 TVAL: 00000000 TV
> 0000000
> AL: 00
> ode:00000
>
> Code:3400
> 050 808334004082 0073 00 8081050 2 bff5 0001 55b7007 4942 ( 3 859b 134f5)
> 2 0073 bff5
> 0
> 001 1050 bff5 055b7 001 55b74942  4942 ((859b 859b 34f34f5)
> 5)
>
>
>
>
> 81000564 RA: 81000010 TVAL: 00000000
>
> Code: 3400 8082 0073 1050 bff5 0001 55b7 4942 (859b 34f5)
>
>
> resresetting ...
> pporesetting ...ng ...
> rese
> trtered ys not supported yet
> ### ERROet
> R ### Please RES### ERRet notET the board ###
> OR ### Please  sRESEupT the board ###
> ported yet
> ### ERROR ### Please RESET the board ###
>
> Regards,
> Simon

Re: Running qemu tests on RISC-V

[Sean Anderson]

On 2/7/22 10:53 AM, Heinrich Schuchardt wrote:
> On 2/7/22 16:38, Simon Glass wrote:
>> Hi,
>>
>> I am trying to run the SPL tests for riscv32 but it dies with an
>> illegal instruction. I have tried building qemu 4.2 but it seems to
>> happen on various versions. Has anyone seen this?
> 
> Did you try to run qemu-riscv32_spl_defconfig in the Docker container we
> are using for Gitlab?
> 
> We are using QEMU v6.1.0 according to tools/docker/Dockerfile.
> 
> With all that duplicate output below it is hard to understand what is
> going. Why is each byte written twice to the serial?

If I had to guess there are 2 harts, and they both trigger an illegal
instruction. In situations like these, I have added a spinlock around puts.

--Sean

Re: Running qemu tests on RISC-V

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 1322 bytes --]

On Mon, Feb 07, 2022 at 11:34:17AM -0500, Sean Anderson wrote:
> 
> 
> On 2/7/22 10:53 AM, Heinrich Schuchardt wrote:
> > On 2/7/22 16:38, Simon Glass wrote:
> >> Hi,
> >>
> >> I am trying to run the SPL tests for riscv32 but it dies with an
> >> illegal instruction. I have tried building qemu 4.2 but it seems to
> >> happen on various versions. Has anyone seen this?
> > 
> > Did you try to run qemu-riscv32_spl_defconfig in the Docker container we
> > are using for Gitlab?
> > 
> > We are using QEMU v6.1.0 according to tools/docker/Dockerfile.
> > 
> > With all that duplicate output below it is hard to understand what is
> > going. Why is each byte written twice to the serial?
> 
> If I had to guess there are 2 harts, and they both trigger an illegal
> instruction. In situations like these, I have added a spinlock around puts.

It might also be worth asking why such an old QEMU?  I know my
host-provided QEMU is 4.2.1 but I just don't use it since it's too old
for everything we do, especially on something as fast moving as RISC-V.

And as an aside, if anyone has tips on changes that would need to be
made to our Dockerfile so that some of those tools that let you run app
from a container "normally" would work with our container, that'd be
handy and appreciated.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: Running qemu tests on RISC-V

[Simon Glass]

Hi Tom,

On Mon, 7 Feb 2022 at 09:49, Tom Rini <trini@konsulko.com> wrote:
>
> On Mon, Feb 07, 2022 at 11:34:17AM -0500, Sean Anderson wrote:
> >
> >
> > On 2/7/22 10:53 AM, Heinrich Schuchardt wrote:
> > > On 2/7/22 16:38, Simon Glass wrote:
> > >> Hi,
> > >>
> > >> I am trying to run the SPL tests for riscv32 but it dies with an
> > >> illegal instruction. I have tried building qemu 4.2 but it seems to
> > >> happen on various versions. Has anyone seen this?
> > >
> > > Did you try to run qemu-riscv32_spl_defconfig in the Docker container we
> > > are using for Gitlab?

No, I want to run it outside docker. I can see that it works in the
docker container, but not sure why it fails for me.

> > >
> > > We are using QEMU v6.1.0 according to tools/docker/Dockerfile.
> > >
> > > With all that duplicate output below it is hard to understand what is
> > > going. Why is each byte written twice to the serial?
> >
> > If I had to guess there are 2 harts, and they both trigger an illegal
> > instruction. In situations like these, I have added a spinlock around puts.

There are 4 CPUs I think.

>
> It might also be worth asking why such an old QEMU?  I know my
> host-provided QEMU is 4.2.1 but I just don't use it since it's too old
> for everything we do, especially on something as fast moving as RISC-V.

I tried 6.x and went back to 4.2.1 because I thought that might be the problem.

>
> And as an aside, if anyone has tips on changes that would need to be
> made to our Dockerfile so that some of those tools that let you run app
> from a container "normally" would work with our container, that'd be
> handy and appreciated.

I'm not sure what that means, probably because I am not an expert in that area.

Regards,
Simon

Re: Running qemu tests on RISC-V

[Heinrich Schuchardt]

On 2/7/22 19:19, Simon Glass wrote:
> Hi Tom,
>
> On Mon, 7 Feb 2022 at 09:49, Tom Rini <trini@konsulko.com> wrote:
>>
>> On Mon, Feb 07, 2022 at 11:34:17AM -0500, Sean Anderson wrote:
>>>
>>>
>>> On 2/7/22 10:53 AM, Heinrich Schuchardt wrote:
>>>> On 2/7/22 16:38, Simon Glass wrote:
>>>>> Hi,
>>>>>
>>>>> I am trying to run the SPL tests for riscv32 but it dies with an
>>>>> illegal instruction. I have tried building qemu 4.2 but it seems to
>>>>> happen on various versions. Has anyone seen this?
>>>>
>>>> Did you try to run qemu-riscv32_spl_defconfig in the Docker container we
>>>> are using for Gitlab?
>
> No, I want to run it outside docker. I can see that it works in the
> docker container, but not sure why it fails for me.
>
>>>>
>>>> We are using QEMU v6.1.0 according to tools/docker/Dockerfile.
>>>>
>>>> With all that duplicate output below it is hard to understand what is
>>>> going. Why is each byte written twice to the serial?
>>>
>>> If I had to guess there are 2 harts, and they both trigger an illegal
>>> instruction. In situations like these, I have added a spinlock around puts.
>
> There are 4 CPUs I think.
>
>>
>> It might also be worth asking why such an old QEMU?  I know my
>> host-provided QEMU is 4.2.1 but I just don't use it since it's too old
>> for everything we do, especially on something as fast moving as RISC-V.
>
> I tried 6.x and went back to 4.2.1 because I thought that might be the problem.
>
>>
>> And as an aside, if anyone has tips on changes that would need to be
>> made to our Dockerfile so that some of those tools that let you run app
>> from a container "normally" would work with our container, that'd be
>> handy and appreciated.
>
> I'm not sure what that means, probably because I am not an expert in that area.
>
> Regards,
> Simon

Hello Simon,

The qemu-riscv32_spl_defconfig image built inside Docker with

wget -O -
https://github.com/riscv/opensbi/releases/download/v0.9/opensbi-0.9-rv-bin.tar.xz
export
OPENSBI=/tmp/opensbi-0.9-rv-bin/share/opensbi/ilp32/generic/firmware/fw_dynamic.bin
tools/buildman/buildman -o build -w -E -W -e --board qemu-riscv32_spl

runs flawlessly on Ubuntu Jammy with:

qemu-system-riscv32 -nographic -machine virt -bios spl/u-boot-spl \
     -device loader,file=u-boot.itb,addr=0x80200000 -smp cpus=4

This is a QEMU 6.0

Please, provide a reproducible instruction for your problem.

Best regards

Heinrich

Re: Running qemu tests on RISC-V

[Simon Glass]

Hi Heinrich,

On Tue, 8 Feb 2022 at 01:21, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>
> On 2/7/22 19:19, Simon Glass wrote:
> > Hi Tom,
> >
> > On Mon, 7 Feb 2022 at 09:49, Tom Rini <trini@konsulko.com> wrote:
> >>
> >> On Mon, Feb 07, 2022 at 11:34:17AM -0500, Sean Anderson wrote:
> >>>
> >>>
> >>> On 2/7/22 10:53 AM, Heinrich Schuchardt wrote:
> >>>> On 2/7/22 16:38, Simon Glass wrote:
> >>>>> Hi,
> >>>>>
> >>>>> I am trying to run the SPL tests for riscv32 but it dies with an
> >>>>> illegal instruction. I have tried building qemu 4.2 but it seems to
> >>>>> happen on various versions. Has anyone seen this?
> >>>>
> >>>> Did you try to run qemu-riscv32_spl_defconfig in the Docker container we
> >>>> are using for Gitlab?
> >
> > No, I want to run it outside docker. I can see that it works in the
> > docker container, but not sure why it fails for me.
> >
> >>>>
> >>>> We are using QEMU v6.1.0 according to tools/docker/Dockerfile.
> >>>>
> >>>> With all that duplicate output below it is hard to understand what is
> >>>> going. Why is each byte written twice to the serial?
> >>>
> >>> If I had to guess there are 2 harts, and they both trigger an illegal
> >>> instruction. In situations like these, I have added a spinlock around puts.
> >
> > There are 4 CPUs I think.
> >
> >>
> >> It might also be worth asking why such an old QEMU?  I know my
> >> host-provided QEMU is 4.2.1 but I just don't use it since it's too old
> >> for everything we do, especially on something as fast moving as RISC-V.
> >
> > I tried 6.x and went back to 4.2.1 because I thought that might be the problem.
> >
> >>
> >> And as an aside, if anyone has tips on changes that would need to be
> >> made to our Dockerfile so that some of those tools that let you run app
> >> from a container "normally" would work with our container, that'd be
> >> handy and appreciated.
> >
> > I'm not sure what that means, probably because I am not an expert in that area.
> >
> > Regards,
> > Simon
>
> Hello Simon,
>
> The qemu-riscv32_spl_defconfig image built inside Docker with
>
> wget -O -
> https://github.com/riscv/opensbi/releases/download/v0.9/opensbi-0.9-rv-bin.tar.xz
> export
> OPENSBI=/tmp/opensbi-0.9-rv-bin/share/opensbi/ilp32/generic/firmware/fw_dynamic.bin
> tools/buildman/buildman -o build -w -E -W -e --board qemu-riscv32_spl
>
> runs flawlessly on Ubuntu Jammy with:
>
> qemu-system-riscv32 -nographic -machine virt -bios spl/u-boot-spl \
>      -device loader,file=u-boot.itb,addr=0x80200000 -smp cpus=4
>
> This is a QEMU 6.0
>
> Please, provide a reproducible instruction for your problem.

I wonder if the problem is the OPENSBI thing. I am not providing that,
nor am I seeing a warning about it.

+Alper Nebi Yasak did a series that makes Fit a subclass of Section
but even that does not help with the missing warning. Has anyone else
noticed it?

Regards,
Simon

Re: Running qemu tests on RISC-V

[Heinrich Schuchardt]

On 2/8/22 15:52, Simon Glass wrote:
> Hi Heinrich,
>
> On Tue, 8 Feb 2022 at 01:21, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>>
>> On 2/7/22 19:19, Simon Glass wrote:
>>> Hi Tom,
>>>
>>> On Mon, 7 Feb 2022 at 09:49, Tom Rini <trini@konsulko.com> wrote:
>>>>
>>>> On Mon, Feb 07, 2022 at 11:34:17AM -0500, Sean Anderson wrote:
>>>>>
>>>>>
>>>>> On 2/7/22 10:53 AM, Heinrich Schuchardt wrote:
>>>>>> On 2/7/22 16:38, Simon Glass wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> I am trying to run the SPL tests for riscv32 but it dies with an
>>>>>>> illegal instruction. I have tried building qemu 4.2 but it seems to
>>>>>>> happen on various versions. Has anyone seen this?
>>>>>>
>>>>>> Did you try to run qemu-riscv32_spl_defconfig in the Docker container we
>>>>>> are using for Gitlab?
>>>
>>> No, I want to run it outside docker. I can see that it works in the
>>> docker container, but not sure why it fails for me.
>>>
>>>>>>
>>>>>> We are using QEMU v6.1.0 according to tools/docker/Dockerfile.
>>>>>>
>>>>>> With all that duplicate output below it is hard to understand what is
>>>>>> going. Why is each byte written twice to the serial?
>>>>>
>>>>> If I had to guess there are 2 harts, and they both trigger an illegal
>>>>> instruction. In situations like these, I have added a spinlock around puts.
>>>
>>> There are 4 CPUs I think.
>>>
>>>>
>>>> It might also be worth asking why such an old QEMU?  I know my
>>>> host-provided QEMU is 4.2.1 but I just don't use it since it's too old
>>>> for everything we do, especially on something as fast moving as RISC-V.
>>>
>>> I tried 6.x and went back to 4.2.1 because I thought that might be the problem.
>>>
>>>>
>>>> And as an aside, if anyone has tips on changes that would need to be
>>>> made to our Dockerfile so that some of those tools that let you run app
>>>> from a container "normally" would work with our container, that'd be
>>>> handy and appreciated.
>>>
>>> I'm not sure what that means, probably because I am not an expert in that area.
>>>
>>> Regards,
>>> Simon
>>
>> Hello Simon,
>>
>> The qemu-riscv32_spl_defconfig image built inside Docker with
>>
>> wget -O -
>> https://github.com/riscv/opensbi/releases/download/v0.9/opensbi-0.9-rv-bin.tar.xz
>> export
>> OPENSBI=/tmp/opensbi-0.9-rv-bin/share/opensbi/ilp32/generic/firmware/fw_dynamic.bin
>> tools/buildman/buildman -o build -w -E -W -e --board qemu-riscv32_spl
>>
>> runs flawlessly on Ubuntu Jammy with:
>>
>> qemu-system-riscv32 -nographic -machine virt -bios spl/u-boot-spl \
>>       -device loader,file=u-boot.itb,addr=0x80200000 -smp cpus=4
>>
>> This is a QEMU 6.0
>>
>> Please, provide a reproducible instruction for your problem.
>
> I wonder if the problem is the OPENSBI thing. I am not providing that,
> nor am I seeing a warning about it.

OpenSBI is needed to emulate unaligned access, access to CSR registers
and so forth. I assume you cannot run qemu-riscv32_spl_defconfig.

A build warning if CONFIG_SPL_OPENSBI=y and OPENSBI is not defined might
make sense.

Best regards

Heinrich

>
> +Alper Nebi Yasak did a series that makes Fit a subclass of Section
> but even that does not help with the missing warning. Has anyone else
> noticed it?
>
> Regards,
> Simon

Re: Running qemu tests on RISC-V

[Simon Glass]

Hi Heinrich,

On Tue, 8 Feb 2022 at 08:34, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>
> On 2/8/22 15:52, Simon Glass wrote:
> > Hi Heinrich,
> >
> > On Tue, 8 Feb 2022 at 01:21, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
> >>
> >> On 2/7/22 19:19, Simon Glass wrote:
> >>> Hi Tom,
> >>>
> >>> On Mon, 7 Feb 2022 at 09:49, Tom Rini <trini@konsulko.com> wrote:
> >>>>
> >>>> On Mon, Feb 07, 2022 at 11:34:17AM -0500, Sean Anderson wrote:
> >>>>>
> >>>>>
> >>>>> On 2/7/22 10:53 AM, Heinrich Schuchardt wrote:
> >>>>>> On 2/7/22 16:38, Simon Glass wrote:
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> I am trying to run the SPL tests for riscv32 but it dies with an
> >>>>>>> illegal instruction. I have tried building qemu 4.2 but it seems to
> >>>>>>> happen on various versions. Has anyone seen this?
> >>>>>>
> >>>>>> Did you try to run qemu-riscv32_spl_defconfig in the Docker container we
> >>>>>> are using for Gitlab?
> >>>
> >>> No, I want to run it outside docker. I can see that it works in the
> >>> docker container, but not sure why it fails for me.
> >>>
> >>>>>>
> >>>>>> We are using QEMU v6.1.0 according to tools/docker/Dockerfile.
> >>>>>>
> >>>>>> With all that duplicate output below it is hard to understand what is
> >>>>>> going. Why is each byte written twice to the serial?
> >>>>>
> >>>>> If I had to guess there are 2 harts, and they both trigger an illegal
> >>>>> instruction. In situations like these, I have added a spinlock around puts.
> >>>
> >>> There are 4 CPUs I think.
> >>>
> >>>>
> >>>> It might also be worth asking why such an old QEMU?  I know my
> >>>> host-provided QEMU is 4.2.1 but I just don't use it since it's too old
> >>>> for everything we do, especially on something as fast moving as RISC-V.
> >>>
> >>> I tried 6.x and went back to 4.2.1 because I thought that might be the problem.
> >>>
> >>>>
> >>>> And as an aside, if anyone has tips on changes that would need to be
> >>>> made to our Dockerfile so that some of those tools that let you run app
> >>>> from a container "normally" would work with our container, that'd be
> >>>> handy and appreciated.
> >>>
> >>> I'm not sure what that means, probably because I am not an expert in that area.
> >>>
> >>> Regards,
> >>> Simon
> >>
> >> Hello Simon,
> >>
> >> The qemu-riscv32_spl_defconfig image built inside Docker with
> >>
> >> wget -O -
> >> https://github.com/riscv/opensbi/releases/download/v0.9/opensbi-0.9-rv-bin.tar.xz
> >> export
> >> OPENSBI=/tmp/opensbi-0.9-rv-bin/share/opensbi/ilp32/generic/firmware/fw_dynamic.bin
> >> tools/buildman/buildman -o build -w -E -W -e --board qemu-riscv32_spl
> >>
> >> runs flawlessly on Ubuntu Jammy with:
> >>
> >> qemu-system-riscv32 -nographic -machine virt -bios spl/u-boot-spl \
> >>       -device loader,file=u-boot.itb,addr=0x80200000 -smp cpus=4
> >>
> >> This is a QEMU 6.0
> >>
> >> Please, provide a reproducible instruction for your problem.
> >
> > I wonder if the problem is the OPENSBI thing. I am not providing that,
> > nor am I seeing a warning about it.
>
> OpenSBI is needed to emulate unaligned access, access to CSR registers
> and so forth. I assume you cannot run qemu-riscv32_spl_defconfig.
>
> A build warning if CONFIG_SPL_OPENSBI=y and OPENSBI is not defined might
> make sense.

OK, it seems we need a binman test that we warn on external blobs that
are embedded in a FIT.


> >
> > +Alper Nebi Yasak did a series that makes Fit a subclass of Section
> > but even that does not help with the missing warning. Has anyone else
> > noticed it?

Regards,
Simon

Re: Running qemu tests on RISC-V

[Alper Nebi Yasak]

On 08/02/2022 20:13, Simon Glass wrote:
> Hi Heinrich,
> 
> On Tue, 8 Feb 2022 at 08:34, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>>
>> On 2/8/22 15:52, Simon Glass wrote:
>>> Hi Heinrich,
>>>
>>> On Tue, 8 Feb 2022 at 01:21, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>>>> Hello Simon,
>>>>
>>>> The qemu-riscv32_spl_defconfig image built inside Docker with
>>>>
>>>> wget -O -
>>>> https://github.com/riscv/opensbi/releases/download/v0.9/opensbi-0.9-rv-bin.tar.xz
>>>> export
>>>> OPENSBI=/tmp/opensbi-0.9-rv-bin/share/opensbi/ilp32/generic/firmware/fw_dynamic.bin
>>>> tools/buildman/buildman -o build -w -E -W -e --board qemu-riscv32_spl
>>>>
>>>> runs flawlessly on Ubuntu Jammy with:
>>>>
>>>> qemu-system-riscv32 -nographic -machine virt -bios spl/u-boot-spl \
>>>>       -device loader,file=u-boot.itb,addr=0x80200000 -smp cpus=4
>>>>
>>>> This is a QEMU 6.0
>>>>
>>>> Please, provide a reproducible instruction for your problem.
>>>
>>> I wonder if the problem is the OPENSBI thing. I am not providing that,
>>> nor am I seeing a warning about it.
>>
>> OpenSBI is needed to emulate unaligned access, access to CSR registers
>> and so forth. I assume you cannot run qemu-riscv32_spl_defconfig.
>>
>> A build warning if CONFIG_SPL_OPENSBI=y and OPENSBI is not defined might
>> make sense.
> 
> OK, it seems we need a binman test that we warn on external blobs that
> are embedded in a FIT.

I tried building qemu-riscv32_spl with buildman on current master from
Debian unstable (outside the container). I am getting the "missing
external blobs" binman warning when I don't pass OPENSBI as a make flag.

The qemu-system-riscv32 command above works fine with that OPENSBI
binary, but not without it. I get garbled output and errors including:
Illegal instruction, Unhandled exception, Please RESET the board...

Re: Running qemu tests on RISC-V

[Simon Glass]

Hi Alper,

On Tue, 8 Feb 2022 at 11:20, Alper Nebi Yasak <alpernebiyasak@gmail.com> wrote:
>
> On 08/02/2022 20:13, Simon Glass wrote:
> > Hi Heinrich,
> >
> > On Tue, 8 Feb 2022 at 08:34, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
> >>
> >> On 2/8/22 15:52, Simon Glass wrote:
> >>> Hi Heinrich,
> >>>
> >>> On Tue, 8 Feb 2022 at 01:21, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
> >>>> Hello Simon,
> >>>>
> >>>> The qemu-riscv32_spl_defconfig image built inside Docker with
> >>>>
> >>>> wget -O -
> >>>> https://github.com/riscv/opensbi/releases/download/v0.9/opensbi-0.9-rv-bin.tar.xz
> >>>> export
> >>>> OPENSBI=/tmp/opensbi-0.9-rv-bin/share/opensbi/ilp32/generic/firmware/fw_dynamic.bin
> >>>> tools/buildman/buildman -o build -w -E -W -e --board qemu-riscv32_spl
> >>>>
> >>>> runs flawlessly on Ubuntu Jammy with:
> >>>>
> >>>> qemu-system-riscv32 -nographic -machine virt -bios spl/u-boot-spl \
> >>>>       -device loader,file=u-boot.itb,addr=0x80200000 -smp cpus=4
> >>>>
> >>>> This is a QEMU 6.0
> >>>>
> >>>> Please, provide a reproducible instruction for your problem.
> >>>
> >>> I wonder if the problem is the OPENSBI thing. I am not providing that,
> >>> nor am I seeing a warning about it.
> >>
> >> OpenSBI is needed to emulate unaligned access, access to CSR registers
> >> and so forth. I assume you cannot run qemu-riscv32_spl_defconfig.
> >>
> >> A build warning if CONFIG_SPL_OPENSBI=y and OPENSBI is not defined might
> >> make sense.
> >
> > OK, it seems we need a binman test that we warn on external blobs that
> > are embedded in a FIT.
>
> I tried building qemu-riscv32_spl with buildman on current master from
> Debian unstable (outside the container). I am getting the "missing
> external blobs" binman warning when I don't pass OPENSBI as a make flag.
>
> The qemu-system-riscv32 command above works fine with that OPENSBI
> binary, but not without it. I get garbled output and errors including:
> Illegal instruction, Unhandled exception, Please RESET the board...

Thanks for testing it. I don't see this on

8b139f4e1c0 (HEAD, us/master) Merge tag 'u-boot-imx-20220207' of
https://gitlab.denx.de/u-boot/custodians/u-boot-imx

:

tools/binman/binman   --toolpath ./tools  build -u -d u-boot.dtb -O .
-m --allow-missing --fake-ext-blobs -I . -I
/scratch/sglass/cosarm/src/third_party/u-boot/files -I
/scratch/sglass/cosarm/src/third_party/u-boot/files/board/emulation/qemu-riscv
-I arch/riscv/dts -a of-list="qemu-virt32"  -a atf-bl31-path= -a
opensbi-path= -a default-dt="qemu-virt32" -a scp-path= -a
spl-bss-pad=1 -a tpl-bss-pad=1 -a spl-dtb=y -a tpl-dtb=


Regards,
Simon

Re: Running qemu tests on RISC-V

[Alper Nebi Yasak]

On 08/02/2022 23:43, Simon Glass wrote:
> Thanks for testing it. I don't see this on
> 
> 8b139f4e1c0 (HEAD, us/master) Merge tag 'u-boot-imx-20220207' of
> https://gitlab.denx.de/u-boot/custodians/u-boot-imx
> 
> :
> 
> tools/binman/binman   --toolpath ./tools  build -u -d u-boot.dtb -O .
> -m --allow-missing --fake-ext-blobs -I . -I
> /scratch/sglass/cosarm/src/third_party/u-boot/files -I
> /scratch/sglass/cosarm/src/third_party/u-boot/files/board/emulation/qemu-riscv
> -I arch/riscv/dts -a of-list="qemu-virt32"  -a atf-bl31-path= -a
> opensbi-path= -a default-dt="qemu-virt32" -a scp-path= -a
> spl-bss-pad=1 -a tpl-bss-pad=1 -a spl-dtb=y -a tpl-dtb=

This command does print the warning for me at that commit (and I see it
with `make` before that).

If I run `touch fw_dynamic.bin` it no longer does, maybe check if such a
file exists in your include paths.

Re: Running qemu tests on RISC-V

[Simon Glass]

Hi Alper,

On Tue, 8 Feb 2022 at 14:36, Alper Nebi Yasak <alpernebiyasak@gmail.com> wrote:
>
> On 08/02/2022 23:43, Simon Glass wrote:
> > Thanks for testing it. I don't see this on
> >
> > 8b139f4e1c0 (HEAD, us/master) Merge tag 'u-boot-imx-20220207' of
> > https://gitlab.denx.de/u-boot/custodians/u-boot-imx
> >
> > :
> >
> > tools/binman/binman   --toolpath ./tools  build -u -d u-boot.dtb -O .
> > -m --allow-missing --fake-ext-blobs -I . -I
> > /scratch/sglass/cosarm/src/third_party/u-boot/files -I
> > /scratch/sglass/cosarm/src/third_party/u-boot/files/board/emulation/qemu-riscv
> > -I arch/riscv/dts -a of-list="qemu-virt32"  -a atf-bl31-path= -a
> > opensbi-path= -a default-dt="qemu-virt32" -a scp-path= -a
> > spl-bss-pad=1 -a tpl-bss-pad=1 -a spl-dtb=y -a tpl-dtb=
>
> This command does print the warning for me at that commit (and I see it
> with `make` before that).
>
> If I run `touch fw_dynamic.bin` it no longer does, maybe check if such a
> file exists in your include paths.

OK that is it, thanks.

I think binman should remove the fake files before exiting. What do you think?

Regards,
Simon

Re: Running qemu tests on RISC-V

[Heinrich Schuchardt]

Am 8. Februar 2022 22:55:38 MEZ schrieb Simon Glass <sjg@chromium.org>:
>Hi Alper,
>
>On Tue, 8 Feb 2022 at 14:36, Alper Nebi Yasak <alpernebiyasak@gmail.com> wrote:
>>
>> On 08/02/2022 23:43, Simon Glass wrote:
>> > Thanks for testing it. I don't see this on
>> >
>> > 8b139f4e1c0 (HEAD, us/master) Merge tag 'u-boot-imx-20220207' of
>> > https://gitlab.denx.de/u-boot/custodians/u-boot-imx
>> >
>> > :
>> >
>> > tools/binman/binman   --toolpath ./tools  build -u -d u-boot.dtb -O .
>> > -m --allow-missing --fake-ext-blobs -I . -I
>> > /scratch/sglass/cosarm/src/third_party/u-boot/files -I
>> > /scratch/sglass/cosarm/src/third_party/u-boot/files/board/emulation/qemu-riscv
>> > -I arch/riscv/dts -a of-list="qemu-virt32"  -a atf-bl31-path= -a
>> > opensbi-path= -a default-dt="qemu-virt32" -a scp-path= -a
>> > spl-bss-pad=1 -a tpl-bss-pad=1 -a spl-dtb=y -a tpl-dtb=
>>
>> This command does print the warning for me at that commit (and I see it
>> with `make` before that).
>>
>> If I run `touch fw_dynamic.bin` it no longer does, maybe check if such a
>> file exists in your include paths.
>
>OK that is it, thanks.
>
>I think binman should remove the fake files before exiting. What do you think?

What do you mean by fake file? Does your build fail if you put the correct file there?

Best regards 

Heinrich 

>
>Regards,
>Simon

Re: Running qemu tests on RISC-V

[Simon Glass]

Hi Heinrich,

On Tue, 8 Feb 2022 at 17:58, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>
>
>
> Am 8. Februar 2022 22:55:38 MEZ schrieb Simon Glass <sjg@chromium.org>:
> >Hi Alper,
> >
> >On Tue, 8 Feb 2022 at 14:36, Alper Nebi Yasak <alpernebiyasak@gmail.com> wrote:
> >>
> >> On 08/02/2022 23:43, Simon Glass wrote:
> >> > Thanks for testing it. I don't see this on
> >> >
> >> > 8b139f4e1c0 (HEAD, us/master) Merge tag 'u-boot-imx-20220207' of
> >> > https://gitlab.denx.de/u-boot/custodians/u-boot-imx
> >> >
> >> > :
> >> >
> >> > tools/binman/binman   --toolpath ./tools  build -u -d u-boot.dtb -O .
> >> > -m --allow-missing --fake-ext-blobs -I . -I
> >> > /scratch/sglass/cosarm/src/third_party/u-boot/files -I
> >> > /scratch/sglass/cosarm/src/third_party/u-boot/files/board/emulation/qemu-riscv
> >> > -I arch/riscv/dts -a of-list="qemu-virt32"  -a atf-bl31-path= -a
> >> > opensbi-path= -a default-dt="qemu-virt32" -a scp-path= -a
> >> > spl-bss-pad=1 -a tpl-bss-pad=1 -a spl-dtb=y -a tpl-dtb=
> >>
> >> This command does print the warning for me at that commit (and I see it
> >> with `make` before that).
> >>
> >> If I run `touch fw_dynamic.bin` it no longer does, maybe check if such a
> >> file exists in your include paths.
> >
> >OK that is it, thanks.
> >
> >I think binman should remove the fake files before exiting. What do you think?
>
> What do you mean by fake file? Does your build fail if you put the correct file there?

U-Boot writes fake files if needed to make the build works, e.g. for
mkimage which needs a real file to actually run.

Not yet but I'm sure it's just a case of finding the right binary
blob. For a brand-new platform too. So sad.

CROSS_COMPILE=~/.buildman-toolchains/gcc-9.2.0-nolibc/riscv32-linux/bin/riscv32-linux-
make PLATFORM=generic -j30

$ do-qemu-riscv_spl.sh help
+ test=help
+ OPENSBI=opensbi/build/platform/generic/firmware/fw_dynamic.bin
crosfw qemu-riscv32_spl
+ PATH=/home/sglass/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/home/sglass/bin:/sbin:/scratch/sglass/cosarm/depot_tools:/home/sglass/cosarm/chromite/bin:/home/sglass/.local/bin:/home/sglass/bin:/vid/software/devel/ubtest/u-boot-test-hooks/bin:/vid/software/devel/ubtest/u-boot-test-hooks/
test/py/test.py -B qemu-riscv32_spl --id na --build-dir
/tmp/b/qemu-riscv32_spl -k help
+u-boot-test-flash qemu-riscv32_spl na
===================================================== test session
starts =====================================================
platform linux -- Python 3.8.10, pytest-4.6.9, py-1.8.1, pluggy-0.13.0
hypothesis profile 'default' ->
database=DirectoryBasedExampleDatabase('/scratch/sglass/cosarm/src/third_party/u-boot/files/.hypothesis/examples')
rootdir: /scratch/sglass/cosarm/src/third_party/u-boot/files/test/py,
inifile: pytest.ini
plugins: forked-1.1.3, hypothesis-4.36.2, xdist-1.31.0
collected 344 items / 342 deselected / 2 selected

test/py/tests/test_fpga.py s
                                                 [ 50%]
test/py/tests/test_help.py E
                                                 [100%]

=========================================================== ERRORS
============================================================
_________________________________________________ ERROR at setup of
test_help _________________________________________________
test/py/conftest.py:367: in u_boot_console
    console.ensure_spawned()
test/py/u_boot_console_base.py:372: in ensure_spawned
    m = self.p.expect([pattern_u_boot_main_signon] + self.bad_patterns)
test/py/u_boot_spawn.py:193: in expect
    raise Timeout()
E   u_boot_spawn.Timeout
---------------------------------------------------- Captured stdout
setup ----------------------------------------------------
+u-boot-test-reset qemu-riscv32_spl na

U-Boot SPL 2022.04-rc1-00001-gbddd3967b6f (Feb 08 2022 - 19:36:55 -0700)
Trying to boot from RAM
===================================== 1 skipped, 342 deselected, 1
error in 31.47 seconds =====================================


Regards,
Simon

Re: Running qemu tests on RISC-V

[Alper Nebi Yasak]

On 07/02/2022 19:49, Tom Rini wrote:
> And as an aside, if anyone has tips on changes that would need to be
> made to our Dockerfile so that some of those tools that let you run app
> from a container "normally" would work with our container, that'd be
> handy and appreciated.

I also don't know which tools you mean, but I tried to get a shell in
the container to experiment and this worked:

  docker run --privileged --volume="$(pwd):/build" --interactive --tty \
      trini/u-boot-gitlab-ci-runner:focal-20220113-03Feb2022 \
      /bin/bash -i

One thing I noticed is that when I omit the version of the container, it
tries to download a version named "latest" and fails, and it looks like
you should publish/update that whenever you upload a new build.

Re: Running qemu tests on RISC-V

[Alper Nebi Yasak]

On 09/02/2022 00:55, Simon Glass wrote:
> Hi Alper,
> 
> On Tue, 8 Feb 2022 at 14:36, Alper Nebi Yasak <alpernebiyasak@gmail.com> wrote:
>> If I run `touch fw_dynamic.bin` it no longer does, maybe check if such a
>> file exists in your include paths.
> 
> OK that is it, thanks.
> 
> I think binman should remove the fake files before exiting. What do you think?

That sounds fine for binman-generated files, but I haven't looked into
the fake-file things enough to see if/how things would break.

I'd say ideally binman should check if it's input files are broken and
warn about it, but that might be too complicated to do...

Re: Running qemu tests on RISC-V

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 1177 bytes --]

On Wed, Feb 09, 2022 at 11:20:51PM +0300, Alper Nebi Yasak wrote:
> On 07/02/2022 19:49, Tom Rini wrote:
> > And as an aside, if anyone has tips on changes that would need to be
> > made to our Dockerfile so that some of those tools that let you run app
> > from a container "normally" would work with our container, that'd be
> > handy and appreciated.
> 
> I also don't know which tools you mean, but I tried to get a shell in
> the container to experiment and this worked:

What I was thinking of was based on reading:
https://public-inbox.org/meta/20210909213935.hh6dyuxaq63o72cc@meerkat.local/
as part of trying out b4 for my workflow (didn't fit for most things,
quite handy for a few tho).

>   docker run --privileged --volume="$(pwd):/build" --interactive --tty \
>       trini/u-boot-gitlab-ci-runner:focal-20220113-03Feb2022 \
>       /bin/bash -i
> 
> One thing I noticed is that when I omit the version of the container, it
> tries to download a version named "latest" and fails, and it looks like
> you should publish/update that whenever you upload a new build.

I've never populated a "latest" tag, but probably should, yes.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]