On Tue, Jul 12, 2022 at 3:40 PM Kent Mcleod <[email protected]> wrote:
> On Wed, Jul 13, 2022 at 7:36 AM Sam Leffler via Devel > <[email protected]> wrote: > > > > On Mon, Jul 11, 2022 at 1:24 PM Axel Heider <[email protected]> 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? > 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 -- [email protected] > > To unsubscribe send an email to [email protected] > _______________________________________________ Devel mailing list -- [email protected] To unsubscribe send an email to [email protected]
