ron minnich wrote:
[on arm]
Why is it helpful or neccessary there?
It only matters if you like to have a dcache. Do you want a dcache?
What are the numbers?
On PPC, you have no choice
Not much effort going into that in coreboot these days, so might not be a big concern.
We will have to have it on x86_64.
Why is it neccessary there?
It only matters if you want to enter 64-bit mode.
(Why) Does coreboot need to do so?
- MTRRs sure make for a lot of fuss.
- I wish we could do something simpler.
- Let's turn on paging, that would be simpler!
And, in fact, it is. It's far, far simpler.
I am not dismissing the thought that it is simpler.
I am trying to say that *despite paging being simpler* there are (several) more things to think of, which are not being mentioned and so how would anyone know if they've been considered?
Just look at our last iteration of MTRR setup.
I'm unfortunately being kept too busy trying to keep coreboot from making changes which seem good enough when proposed but which may not actually be worth the change.
For the base identity map on x86-32, it's one page for 4G. For a map which locks out page 0, it's two pages.
I think it would be great if you could write up what you actually want to accomplish.
I am very worried that this is an XY problem:
Someone wants X and thinks that Y is the best way to accomplish it. They move on to communicate with others about Y, instead of about X, which is the more constructive communication to be had.
Is your goal to write-protect coreboot code in RAM while coreboot runs?
And, again, we've had virtual addresses forever. That's what segmentation hardware does. We just had a 1:1 mapping.
A 1:1 mapping is (obviously, I hope) equivalent to not having paging at all for the purpose of this discussion.
//Peter