[LinuxBIOS] "Cache As RAM" support routine for non-K8 CPUs

[Darmawan Salihun]

Hi guys,
    Is there any implementation of Cache as RAM in the current LinuxBIOS
code (it's version 2 at the moment, right?) for processor other than  K8
(Opteron/Athlon64 family)? I've just grepped through the code and can spot
supports for K8 platforms.
    Anyway, I've got this conversation with Dell BIOS developer few years
back maybe of some use:
-------------
*written in my article :*

There are couples of tricky areas in the BIOS code due to the execution of
some of its parts in ROM. I'll present some of my findings below.

*call instruction is not available during bios code execution from within
BIOS ROM chip*. This is due to call instruction uses/manipulate stack while
we don't have writeable area in BIOS ROM chip to be used for stack. What I
mean by manipulating stack here is the "implicit" push instruction which is
executed by the call instruction to "write/save" the return address in the
stack. As we know clearly, address pointed to by ss:sp at this point is in
ROM, meaning: we can't write into it. If you think, why don't use the RAM
altogether ? the DRAM chip is not even available at this point. It hasn't
been tested by the BIOS code, thus we haven't know if RAM even exists!


*Mark_Larson (a reader of the article) :*

Sort of. On current Intel processors there is a feature called *Cache As Ram
*. It allows you to use your cache as if it were RAM before memory is
initialized. Cache As Ram is only supported on the latest processors. On
older processors in some BIOSes a trick was used to *"fake" a stack in the
cache*. This allowed the BIOS programmer to do CALLs and RETs without memory
having been set up. You fake a stack in the cache and then disable the
cache. All accesses to the stack come from the cache. The fake stack never
gets removed from the cache because the cache is disabled. AMI first did
this about 8 years ago.


*further explanation from Mark Larson*
I'll expand a bit on both parts.

1) *Cache As Ram* - Intel basically allows you to set the cache to respond
to memory acceses from a certain memory range. For instance you could set
the memory range 1000h:0 for 8k to be your stack in Cache as Ram. When the
processor accesses anything in the 8k range of 1000h:0 it will get the
information from the cache. So setting up a stack somewhere is trivial. That
allows you to do CALLs and RETs

2) *"Faking a stack"* -
A) Make sure the L1 is enabled and on and the L2 cache is off.

B) Have 1K ( or however big you want your stack to be), set aside as data in
the BIOS ROM chip. Doesn't matter what the 1k of data is, as long as you
don't use it for anything else.

C) Read that data in, forcing it to go into the L1 cache ( rep lods).

D) Disable the L1 cache.

E) Now set up the stack through the appropriate commands to point to the
data that you just read in.

F) All accesses to the stack now go through the cache, but the data never
gets removed from the cache since it's disabled.

G) Having the cache disabled doesn't really mean it's "disabled". What it
means is that nothing new can be added to the cache. It still responds to
all "hits" with the appropriate data.

As a variation, you can do this with the code in the BIOS ROM as well, and
use both the L1 and L2. I only used the L1 to make it easier to illustrate.
There is actually an MSR on P3 and earlier processors ( I think it got added
in the pentium pro), that lets you directly write to the cache. A lot of 3rd
party testing tools use this to test the cache. It works like a memory test.
You write a pattern and read it back via this MSR. But you can also use it
to load up the data or code you want to use directly into the cache. You can
also use that mechanism to create the stack in the cache. However it won't
work on P4's. So the above method is more robust, since it works in all
cases. AMI if I remember right used the MSR method. Look in Book 3 of any of
the processor manuals in the appendix under MSRs ( appendix B). In my P4
book it's under the section "MSRs in the P6 Family Processors". It spans
multiple MSRs starting at 88h. Keep in mind that this is no longer on the
P4.

------------------------

PS: The article mentioned above is my Award BIOS Reverse Engineering
Article:
http://www.geocities.com/mamanzip/Articles/Award_Bios_RE/Award_Bios_RE_guide.html

--Darmawan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20070428/cf5cd083/attachment.html>