Oh, and thanks again Kent, as always you've been very helpful! On Tue, Jul 12, 2022 at 4:02 PM Sam Leffler <[email protected]> wrote:
> 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]
