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
PS: The article mentioned above is my Award BIOS Reverse Engineering
please keep the discussion on the list. Thanks!
On Sun, Apr 29, 2007 at 05:27:29PM +0100, Ben Hewson wrote:
> >Hm, I don't know about this, this file is used with
> >densitron/dpx114 also and it should also have this fixup in
> Does the densitron/dpx114 board still boot with the current
> version of LB ?
I don't know, but let's try not to make it any worse in any case.
> >Ben, is there really no way to have that register setting in the
> >8231 code in v2?
> I can think of only 2 reasons why the write to register 0x42 does
> not work properly in ide_init(). Either it must be done before the
> IDE peripheral is enabled (it is disabled by default)
This makes sense.
> or it is a timing issue.
Also possible, but mode before enable seems more likely.
> If we move the fix from auto.c it would probably need to go before
> the IDE enable in vt8231_init().
> At this point dev does not point to the correct PCI section,
> however the 2 lines of code in auto.c could be moved there.
Sure, finding the IDE device is neccessary.
> Alternatively the IDE enable in vt8231_init() could be moved to
> ide_init(), but again dev does not then point to the correct PCI
> registers to enable the IDE.
> Not sure which solution would be the most elegant. Do you have any
> preference ?
Not sure there is an elegant solution to this in v2 but I prefer the
first solution, set compatibility mode before enabling IDE in _init.
I recently purchased a Tyan S2882 motherboard so that I could play with
Alas, even purchasing a supported board with a tutorial isn't straight
forward. I have cut and pasted the Config example for FILO with grub, and
editing only the
MENULST_FILE = "hda1:/grub/menu.lst"
to MENULST_FILE = "hda1:/boot/grub/menu.lst"
to reflect the location of my grub's menu.lst file.
But, it won't compile.
Sorry if this is quite very basic question. I haven't got the time to
read the latest version of linuxbios's flashrom. Is the basic mechanism to
access the BIOS chip address space is through mmap function? haven't grep
the code though :-(.
-= Human knowledge belongs to the world =-
Thanks to Stepan's perseverence (thanks!), the m57sli-s4 code is now
sufficiently merged into the v2 tree; the following is based on v2 checkout
I've reported before that there still seems to be something missing in the
i2c initialization for the gigabyte m57sli-s4 board. The symptom I was seeing
before was a very slow X start (30-50s delay) which can be fixed by adding
to the "device" section of the X config file.
I tried playing with lm-sensors today, and sure enough, I can only read out a
couple of sensors (the ones controlled by the k8temp module). There is
another set of sensors on the SuperIO, which is detected by the
lmsensors-detect script as
Found `ITE IT8716F Super IO Sensors'
(but not activated)
The sensors-detect script is a perl script part of the lm-sensors package;
you can also download the latest version here
Under LinuxBIOS, the it87 module can not be loaded:
FATAL: Error inserting it87
(/lib/modules/184.108.40.206/kernel/drivers/hwmon/it87.ko): No such device
Under the proprietary bios, the sensors-detect script detects the IT8716F
just fine. The it87 module can be loaded, which allows reading out of various
system temperatures and fan speeds, as well as manual fan speed control.
Any clues as to what is going on here, and how to fix this?
Ward Vandewege <ward(a)fsf.org>
Free Software Foundation - Senior System Administrator
I'm thinking of buying a small pc for home server duty (haven't found
where I could buy the AMD NAS RDK, which would suit the job
excellently, I think) and found this. Specs are as follows:
AMD Althon 64/FX/X2 up to 5200+ GHz
North Bridge: nVidia Crush 51PV
South Bridge: nVidia MCP 51
Dual DDRII 800/667/533/400
Support max. 2GB
2 x PCI
Integrated GeForce 6 GPU
1 x ATA 133
2 x SATA II
I know that ck804 is supported, but never saw anyone mentioning any
work on a geforce 6 mobo. Can this be supported by LinuxBios?
> Signed-off-by: Adam Kaufman <adam.kaufman(a)pinnacle.com>
> Signed-off-by: Stefan Reinauer <stepan(a)coresystems.de>
> Acked-by: Stefan Reinauer <stepan(a)coresystems.de>
> Acked-by: Adam Kaufman <adam.kaufman(a)pinnacle.com>
It seems there is still some confusion about Signed-off-by
and Acked-by. The meaning of Acked-by is a real subset of
Signed-off-by. So acking a patch you already signed off
for is totally meaningless and should be avoided. The
Linux kernel guys never ack and sign off the same patch.
When I make a 512KB image which contains a payload with about 300KB size, it
will okay to jump to payload to execute
the payload. But when I make a 1MB image contains the same payload as 512KB
image has, it cannot jump to
payload to execute. It reports that checksum is not okay. Is there some
restriction elfboot() has??
Does anyone meet this problem before?