Hi Heinrich, On Tue, 8 Feb 2022 at 08:34, Heinrich Schuchardt <xypron.g...@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.g...@gmx.de> wrote: > >> > >> On 2/7/22 19:19, Simon Glass wrote: > >>> Hi Tom, > >>> > >>> On Mon, 7 Feb 2022 at 09:49, Tom Rini <tr...@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
