Making IPL coding easier? (fwd)
Eric W. Biederman
ebiederman at lnxi.com
Sun Oct 13 12:16:00 CEST 2002
Ronald G Minnich <rminnich at lanl.gov> writes:
> Neil has a very interesting point, and it does bring up the "cache as ram"
> issue again.
> Neil, my only question is, did you test this MTRR approach on lots of
> CPUs. My impression is that it is not guaranteed to work.
Let me respond. My apologies for the delay but I misplaced this
There are several sides to this problem.
1) I have tried setting up the MTRRs and fake an area of ram.
In fact if you look at the p4dc6 I actually implemented it and
did a port that way.
Unfortunately there is not an architecturally garanteed way
to make this work, and cpu designers are continuously tweaking
how their caches work so it breaks with new cpus at the drop
of a hat. Especially new hyperthreaded monsters.
There is no real savings in having code that breaks when new
cpus are introduced.
2) Using memory that is elsewhere in the system. I do use
cmos memory but not currently for temporaries. I like
the idea. But with only 128bytes to play with you can not
do much with it.
3) Using external ram for a stack, is dangerous in a couple
of ways. Cache coherency with pci devices isn't garanteed,
so setting up mttrs over the stack is not guaranteed to work.
The common case is in processors is to work against cacheable memory.
I have seen P4's incorrectly execute code when caching was disabled.
Stacks may soon follow suite. So long term this does not look
Then there is the added danger that the device or something on the path
to the device will be corrupted/broken. And then you get very strange
hard to debug failure cases.
The only real solution to this problem is to build a compiler that generates
code that does not use ram. And then the compiler can have all of the smarts
about how to call subroutines etc. The coding would still be tryi
More information about the coreboot