loader: Map all of RAM in the loader#511
Conversation
|
Ok, this breaks SMP, because I'm an absolute buffoon, and changed the loader mappings to be NORMAL, when of course that is wrong when we don't care about caching. I can now fix this booting by keeping everything as |
As opposed to them being accessed via global variables directly. The reason to do this is to enable us to vary the page table placement from the C side without needing to touch or modify the assembly any further, which will enable the future commits for making the number of page page table structures dynamic, which is necessary for making the loader 1:1 all of RAM. Also, remove some redundant stack pops/pushs to util64.S. Signed-off-by: Julia Vassiliki <julia.vassiliki@unsw.edu.au>
This performs cleanups to the loader code, to remove a bunch of boilerplate, and also makes the page table entries placed in the loader binary at the end. This is in preparation for moving towards mapping all of RAM in the loader. Signed-off-by: Julia Vassiliki <julia.vassiliki@unsw.edu.au>
Signed-off-by: Julia Vassiliki <julia.vassiliki@unsw.edu.au>
a600a29 to
376b71b
Compare
|
I'm debating whether it makes sense to instead allocate a fixed amount of slots in the loader, and do this code in the loader. Then in (some future world) where we have one build of the loader for every platform on AArch64 (once seL4 has that) then this will just work like that, too. The sel4_tools elfloader also works like that. I think I see many positives for doing it at runtime, and the only one I can maybe see for build-time is just that we can know it works at build time. |
|
Yes, of course do it runtime. If you go through the trouble making your own loader, at least have one that supports all boards of the same platform. :-) |
2 participants
This will fix #463 (closing #465) and #466.