On Sat, May 4, 2019 at 8:38 PM Karsten Merker merker@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