On Wed, Jul 13, 2022 at 7:36 AM Sam Leffler via Devel <devel@sel4.systems> wrote: > > On Mon, Jul 11, 2022 at 1:24 PM Axel Heider <axelhei...@gmx.de> wrote: > > > Sam > > > > > Aha, thank you (that's very hidden)! I do see the 2MB reserve in the > > > generated DTS (gen_headers/plat/machine/devices_gen.h). And we don't > > > have/use SBI. Any reason why this PR has yet to be merged? > > > > > > Basically lack of time and nobody was really pushing for that. It's > > still on my list of pending PRs, but dropped a bit in priority as > > the current solution also works. Seem all RISC-V board have the same > > physical memory layout, so the hard-coded values are not too painful. > > What's left is maybe a bit more testing with the parameters and > > another round of comparing with what is done on ARM, to see if the > > behavior is similar or if there are pitfalls we forgot. > > If you can confirm this PR id working for you, that feedback is really > > appreciated. > > > > Mixed answer. The PR seems to DTRT but I had to do some mangling for it to > apply on my old tree. > > As to whether this resolved my issue, the answer is no. Our target platform > uses opentitan to boot and that was already assuming no memory was reserved > for SBI. So the end result was that I got back a fraction of the 2MB, not > all of it as I hoped. >
With the change applied, is the new load address of the kernel.elf at the start of the provided memory region rather than a 2MiB offset? What is the size of the kernel image footprint that you're observing? > -Sam > _______________________________________________ > Devel mailing list -- devel@sel4.systems > To unsubscribe send an email to devel-leave@sel4.systems _______________________________________________ Devel mailing list -- devel@sel4.systems To unsubscribe send an email to devel-leave@sel4.systems
