[U-Boot] RISC-V: Crashes with OpenSBI+U-Boot on the qemu "virt" machine

[Anup Patel]

On Sat, May 4, 2019 at 8:38 PM Karsten Merker <merker at debian.org> wrote:
>
> On Sat, May 04, 2019 at 09:24:15AM +0530, Anup Patel wrote:
>
> [U-Boot+OpenSBI crash with more than 2GB RAM in qemu-system-riscv64]
> > I tried again with image header changes applied to u-boot and
> > Linux kernel but still not able to reproduce the issues.
> >
> > Either you might have more local changes or debian toolchain
> > is causing issue for u-boot.
>
> Hello,
>
> I hadn't made any local changes besides the ones described in my
> original email, i.e. the application of the booti patches.  To
> check for a toolchain-related problem I have rebuilt everything
> with both the gcc8-based and the gcc7-based buildroot toolchains,
> but the problem remained in all cases, regardless of whether I
> used the branch with the booti patch or the plain v2019.07-rc1
> tag, so the problem is definitely not specific to the Debian
> toolchain.  As a new qemu release has happend just a few days
> ago, I have now tried to upgrade qemu from the previous release
> version 3.1.0 to the freshly released version 4.0.0, and indeed
> with qemu 4.0.0 both the 2GB problem and the hang of init in SMP
> configurations with OpenSBI+U-Boot are gone.  Which qemu version
> had you been using in your tests?

I am using QEMU 4.0.0-rc2.

Like mentioned in previous email, BBL has limitation that it allows
full memory access to S-mode software. This means S-mode software
can actually corrupt BBL too. This is not possible in OpenSBI because
we use PMP configuration to protect firmware and critical memory
regions.

With QEMU 3.x, OpenSBI+U-Boot is failing for you because there
were bugs in QEMU PMP checks.

>
> What makes this interesting is that I'm running qemu 3.1.0 with
> BBL and Linux in a 4-core SMP configuration and with 8GB of RAM
> since months and never had any problems with it, so
> OpenSBI+U-Boot seems to do something differently from BBL.

That's because BBL is buggy. It allows complete RAM access to
S-mode software so QEMU PMP checks did not matter.

Regards,
Anup