[seL4] Re: seL4 kernel memory footprint

Oh, and thanks again Kent, as always you've been very helpful! On Tue, Jul 12, 2022 at 4:02 PM Sam Leffler wrote:

On Tue, Jul 12, 2022 at 3:40 PM Kent Mcleod wrote:

...

On Wed, Jul 13, 2022 at 7:36 AM Sam Leffler via Devel wrote:

...

On Mon, Jul 11, 2022 at 1:24 PM Axel Heider 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

...

apply on my old tree.

As to whether this resolved my issue, the answer is no. Our target

to 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?

It's unchanged because opentitan uses the kernel.elf headers to specify where to load the kernel (prior to applying the PR the SBI reservation was just ignored)--which took me a while to understand :().

...

What is the size of the kernel image footprint that you're observing?

Looks like ~130KB, likely because we have CONFIG_PRINTING + some drivers. I haven't looked too closely at that # because the immediate goal is to reclaim all the rootserver resources which will allow us to meet our target platform constraints--and that looks doable. We likely have lots of places we can trim fat (e.g. kernel config, user space optimizations, removing devel facilities).

...

...

-Sam _______________________________________________ Devel mailing list -- devel@sel4.systems To unsubscribe send an email to devel-leave@sel4.systems