Running qemu tests on RISC-V
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
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
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
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.
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
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.t... 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
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.t... 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
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.t... 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
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.t... 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
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.t... 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...
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.t... 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
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.
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
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
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
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...
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.
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.
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
participants (6)
-
Alper Nebi Yasak -
Heinrich Schuchardt -
Michael Lawnick -
Sean Anderson -
Simon Glass -
Tom Rini