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...
--Darmawan
thank you for your posting, Darmawan.
do you think that PCI expansion ROM may be useful during the developing phase in order to avoid soldering as on an GA M57sli mobo ? Eventually it does not make much sense anymore, when the LinuxBIOS code is verified to work. But before that it allows quick fallback, one might think. --Q
Darmawan Salihun schrieb:
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.
On Sat, Apr 28, 2007 at 03:11:19PM +0200, Quux wrote:
do you think that PCI expansion ROM may be useful during the developing phase in order to avoid soldering as on an GA M57sli mobo ?
Not an expansion ROM, that suggests the ROM is part of a PCI expansion card (sound card, networking card, graphics card, RAID card etc) but some southbridges support decoding the BIOS address range to the PCI bus. There has to be a jumper for this on the board in order to work.
In that case, a simple PCI card could be designed with just a flash chip and probably little more, and this could be booted from.
The board would likely need to be double sided though, so not trivial to produce at home. (But prototype quality boards can be gotten fairly cheap.)
//Peter
On 4/28/07, Peter Stuge stuge-linuxbios@cdy.org wrote:
On Sat, Apr 28, 2007 at 03:11:19PM +0200, Quux wrote:
do you think that PCI expansion ROM may be useful during the developing phase in order to avoid soldering as on an GA M57sli mobo ?
Not an expansion ROM, that suggests the ROM is part of a PCI expansion card (sound card, networking card, graphics card, RAID card etc) but some southbridges support decoding the BIOS address range to the PCI bus. There has to be a jumper for this on the board in order to work.
I used to be a not very big fan of this idea, but my interest is growing given the unwillingness of some companies (*****) to help. This would allow us to grab control of the platform, although it is pretty late in the process, but we could add this card to nodes and force them to use linuxbiosmain and give us control over payload and some other parameters. It is not an ideal solution, but it is a transition path to full control. It would certainly be very helpful on a dell cluster we have at sandia, because the bios situation on that cluster is difficult to work with, to say the least.
So, are there proto cards out there with nothing but a flash part on them?
thanks
ron
not as I know of, but there is $150 Altera devKit PCI card, which clearly could do the trick, and some more !
http://www.altera.com/products/devkits/altera/kit-maxii-1270.html even a bare proto card can easily cost $40-60 these days. though DIY cost maybe $20 would one have to add little switches onboard connected to the chipset ? --Q
ron minnich schrieb:
On 4/28/07, Peter Stuge stuge-linuxbios@cdy.org wrote:
On Sat, Apr 28, 2007 at 03:11:19PM +0200, Quux wrote:
do you think that PCI expansion ROM may be useful during the developing phase in order to avoid soldering as on an GA M57sli mobo ?
Not an expansion ROM, that suggests the ROM is part of a PCI expansion card (sound card, networking card, graphics card, RAID card etc) but some southbridges support decoding the BIOS address range to the PCI bus. There has to be a jumper for this on the board in order to work.
I used to be a not very big fan of this idea, but my interest is growing given the unwillingness of some companies (*****) to help. This would allow us to grab control of the platform, although it is pretty late in the process, but we could add this card to nodes and force them to use linuxbiosmain and give us control over payload and some other parameters. It is not an ideal solution, but it is a transition path to full control. It would certainly be very helpful on a dell cluster we have at sandia, because the bios situation on that cluster is difficult to work with, to say the least.
So, are there proto cards out there with nothing but a flash part on them?
thanks
ron
Hi Ron, I'm not sure about the existence of such a card. I used to hack an unused PCI Expansion Card (Adaptec SCSI Controller) to place my self-made code < http://www.geocities.com/mamanzip/Articles/Low_Cost_Embedded_x86_Teaching_To.... Maybe such approach can be used. Nonetheless, it means we needed a code to "clean-up" the original vendor BIOS code. Maybe this condition is not a good place to start :-(.
On 4/29/07, ron minnich rminnich@gmail.com wrote:
On 4/28/07, Peter Stuge stuge-linuxbios@cdy.org wrote:
On Sat, Apr 28, 2007 at 03:11:19PM +0200, Quux wrote:
do you think that PCI expansion ROM may be useful during the developing phase in order to avoid soldering as on an GA M57sli mobo ?
Not an expansion ROM, that suggests the ROM is part of a PCI expansion card (sound card, networking card, graphics card, RAID card etc) but some southbridges support decoding the BIOS address range to the PCI bus. There has to be a jumper for this on the board in order to work.
I used to be a not very big fan of this idea, but my interest is growing given the unwillingness of some companies (*****) to help. This would allow us to grab control of the platform, although it is pretty late in the process, but we could add this card to nodes and force them to use linuxbiosmain and give us control over payload and some other parameters. It is not an ideal solution, but it is a transition path to full control. It would certainly be very helpful on a dell cluster we have at sandia, because the bios situation on that cluster is difficult to work with, to say the least.
So, are there proto cards out there with nothing but a flash part on them?
thanks
ron
-- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Maybe the following card is of some use:
http://www.uxd.nl/en/pages/producten/hardware/phdpci2.html
As for the cost, maybe it's better to use the Altera MAX II proposed by Quux
On 4/29/07, Darmawan Salihun darmawan.salihun@gmail.com wrote:
Hi Ron, I'm not sure about the existence of such a card. I used to hack an unused PCI Expansion Card (Adaptec SCSI Controller) to place my self-made code http://www.geocities.com/mamanzip/Articles/Low_Cost_Embedded_x86_Teaching_Tool.html. Maybe such approach can be used. Nonetheless, it means we needed a code to "clean-up" the original vendor BIOS code. Maybe this condition is not a good place to start :-(.
On 4/29/07, ron minnich rminnich@gmail.com wrote:
On 4/28/07, Peter Stuge stuge-linuxbios@cdy.org wrote:
On Sat, Apr 28, 2007 at 03:11:19PM +0200, Quux wrote:
do you think that PCI expansion ROM may be useful during the developing phase in order to avoid soldering as on an GA M57sli mobo ?
Not an expansion ROM, that suggests the ROM is part of a PCI expansion card (sound card, networking card, graphics card, RAID card etc) but some southbridges support decoding the BIOS address range to the PCI bus. There has to be a jumper for this on the board in order to work.
I used to be a not very big fan of this idea, but my interest is growing given the unwillingness of some companies (*****) to help. This would allow us to grab control of the platform, although it is pretty late in the process, but we could add this card to nodes and force them to use linuxbiosmain and give us control over payload and some other parameters. It is not an ideal solution, but it is a transition path to full control. It would certainly be very helpful on a dell cluster we have at sandia, because the bios situation on that cluster is difficult to work with, to say the least.
So, are there proto cards out there with nothing but a flash part on them?
thanks
ron
-- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
--
-= Human knowledge belongs to the world =-
ron minnich wrote:
So, are there proto cards out there with nothing but a flash part on them?
There are cheap ~$15 SCSI cards around and also PCI media card readers for ~$30.
If the ROM's on NIC's show up during boot, then cards are available for under $5. But I don't recall any of them mapping the ROM to any PCI space.
-Bari
that is the point - the issue was discussed here a couple of days ago.
a regular PCI expansion BIOS is called too late during POST by legacy BIOS. The Altera MAXII has a patch field to put a flash mem into.
this PCI space mapping business is the key point. chipset's provide for booting from PCI space but I wonder whether they need to be told to do so by a hardware switch / signal or whether a small patching of legacy bios would do the trick. --Q
Bari Ari schrieb:
ron minnich wrote:
So, are there proto cards out there with nothing but a flash part on them?
There are cheap ~$15 SCSI cards around and also PCI media card readers for ~$30.
If the ROM's on NIC's show up during boot, then cards are available for under $5. But I don't recall any of them mapping the ROM to any PCI space.
-Bari
empty PCI cards with patch fields are around - but some cost even more than MAXII devkit which has much more bang/buck.
http://www.quancom.com/quancom/quancom01.nsf/home_prod_eng.htm
So, are there proto cards out there with nothing but a flash part on them?
http://www.intel.com/design/intarch/applnots/273121.HTM
an intel PCI board with fpga & lotsa flash chips only. intel say it allows dead-on startup of embedded systems ... what u think ?
Quux schrieb:
empty PCI cards with patch fields are around - but some cost even more than MAXII devkit which has much more bang/buck.
http://www.quancom.com/quancom/quancom01.nsf/home_prod_eng.htm
So, are there proto cards out there with nothing but a flash part on them?
5.4.1 BIOS Boot Specification 1.01 The BIOS Boot Specification as defined by Compaq, Phoenix Technologies and Intel provides the means for any device in a system to be identified as an *Initial Program Load* (IPL) device. If the system BIOS supports this specification, the expansion ROM within the card can indicate that it is an available IPL device. The BIOS maintains a list of available IPL devices and assigns a priority to the devices. The user can change to the IPL order/priority of the available devices. If the expansion ROM is used as an IPL device, the IPL code must be contained within the expansion ROM space of the card. The system BIOS calls the Bootstrap Entry Vector (BEV) to boot the operating system. The expansion ROM either copies the OS to DRAM for execution or jumps directly to the entry point of the image contained in Flash. Example ROM code is available which provides an example of how to implement a Plug and Play IPL device. Please see the BIOS Boot Specification for a complete description of all required tables and actions to support this capability.
Sorry about this long message.
To clarify, there are two distinct ways in which LB could be loaded from PCI. I think both are interestng.
* Expansion ROM
Here, LinuxBIOS does not replace the system BIOS, but the system BIOS would see an expansion ROM on a PCI card and try to call it just like it does other expansion ROMS. (SCSI, VGA, SATA, NIC, etc.)
This does not requre any hardware support in the system, only that there is a boot software in the system which will discover and call the LB expansion ROM.
To test this, old NICs are a pefect target.
One thing to keep in mind with expansion ROMs is that they are generally small. 128kb is probably the best anyone can hope for.
* 4G addresses decoded to PCI
Here, LinuxBIOS is the system BIOS, just like we normally use it.
Ths requires explicit support where the system BIOS flash chip is connected, usually the southbridge, and usually there must also be a jumper on the mainboard that selects this method of reaching the boot software instead of the normal one. (Usually LPC or SPI.)
So far I've only seen the ICHx southbridges support this, but I have not looked very hard.
As I understand, this simply does PCI reads on the 4G addresses and hopes that someone will answer.
This needs to be implemented with a special PCI card designed for the purpose, possibly with differences depending on each southbridge. Making hardware is expensive unless in bulk so for testing it the $60 prototype boards may actually not be a bad deal. :(
On Sat, Apr 28, 2007 at 03:09:07PM -0700, ron minnich wrote:
This would allow us to grab control of the platform, although it is pretty late in the process, but we could add this card to nodes and force them to use linuxbiosmain and give us control over payload and some other parameters.
This would require some puzzling in the v2 Makefile right? And perhaps a new utility to turn LB into a valid expansion ROM?
So, are there proto cards out there with nothing but a flash part on them?
What Bari sad, try to use a cheap NIC for this. I think I've even seen Linux flashing software for realtek cards. Don't forget to check the flash size on the cards.
On Sun, Apr 29, 2007 at 10:11:21AM +0200, Quux wrote:
would one have to add little switches onboard connected to the chipset
No, the chipset would need to already have a switch to select the decode mode.
On Sun, Apr 29, 2007 at 08:41:51PM +0700, Darmawan Salihun wrote:
http://www.geocities.com/mamanzip/Articles/Low_Cost_Embedded_x86_Teaching_To... Maybe such approach can be used.
Right, this is by far the most cost effective way.
Nonetheless, it means we needed a code to "clean-up" the original vendor BIOS code. Maybe this condition is not a good place to start :-(
Well, it may not be all that bad, and as Ron said it's better than no LB at all.
On Sun, Apr 29, 2007 at 09:18:26PM +0700, Darmawan Salihun wrote:
This looks like a diagnostics card. I guess it uses the expansion ROM method to load it's software.
On Sun, Apr 29, 2007 at 09:24:20AM -0500, Bari Ari wrote:
If the ROM's on NIC's show up during boot, then cards are available for under $5. But I don't recall any of them mapping the ROM to any PCI space.
That's right. They would only be useful (but very!) for the expansion ROM mode.
On Sun, Apr 29, 2007 at 04:38:41PM +0200, Quux wrote:
that is the point - the issue was discussed here a couple of days ago.
A: No. Q: Should I include quotations after my reply?
*Please* stop top-posting. See
http://www.catb.org/~esr/jargon/html/T/top-post.html http://www.faqs.org/qa/rfcc-449.html http://en.wikipedia.org/wiki/Top-posting
I would be in the TOFU/jeopardy camp.
a regular PCI expansion BIOS is called too late during POST by legacy BIOS.
Late, but not too late. I think there is utility in this method also.
The Altera MAXII has a patch field to put a flash mem into.
And it has logic that can be used to decode the PCI reads to the flash chip. This is required since no flash ROM I've seen comes with a PCI interface. (Probably too expensive and unusual.)
chipset's provide for booting from PCI space but I wonder whether they need to be told to do so by a hardware switch / signal
Yes.
or whether a small patching of legacy bios would do the trick.
There is no legacy BIOS with the 4G PCI decode method.
While the method can certainly be an alternative I would assume it is used by the big boys exclusively during board development and because of that even if southbridges support the mode, the neccessary signal will never be available for user control on the production run mainboard. I hope I'm wrong. We need to research it. It seems that at least the Gigabyte board did have this signal also on the production boards, at an unpopulated jumper.
On Sun, Apr 29, 2007 at 04:55:21PM +0200, Quux wrote:
http://www.intel.com/design/intarch/applnots/273121.HTM
an intel PCI board with fpga & lotsa flash chips only. intel say it allows dead-on startup of embedded systems ... what u think ?
--8<-- 3.6 Expansion ROM Operation The expansion ROM is accessed at power-up through the system BIOS. -->8--
and
--8<-- 5.0 Software Overview It is advisable for the card to begin executing after system start. An expansion ROM serves this function. -->8--
means this card works exclusively in the expansion ROM mode.
But that would change with a different FPGA bitstream of course. Note that Intel do not sell this board anyway.
On Sun, Apr 29, 2007 at 05:00:53PM +0200, Quux wrote:
5.4.1 BIOS Boot Specification 1.01
[..]
If the system BIOS supports this specification, the expansion ROM within the card can indicate that it is an available IPL device.
This is "on top of" an expansion ROM.
This allows a legacy BIOS to boot an OS from a controller with an expansion ROM by adding some structured information to the expansion ROM. The BIOS will read the info and then present all bootable devices to the user.
This is an alternative to, or expansion of, the other legacy BIOS boot methods. (int 13h, int 18h, int 19h)
//Peter
check out this rip off: $60 for an empty PCI card ... ;-) http://www.jdr.com/interact/item.asp?itemno=JDR-PR1000
Quux schrieb:
empty PCI cards with patch fields are around - but some cost even more than MAXII devkit which has much more bang/buck.
http://www.quancom.com/quancom/quancom01.nsf/home_prod_eng.htm
So, are there proto cards out there with nothing but a flash part on them?
Quux wrote:
that is the point - the issue was discussed here a couple of days ago.
a regular PCI expansion BIOS is called too late during POST by legacy BIOS. The Altera MAXII has a patch field to put a flash mem into.
this PCI space mapping business is the key point. chipset's provide for booting from PCI space but I wonder whether they need to be told to do so by a hardware switch / signal or whether a small patching of legacy bios would do the trick. --Q
What is the actual problem here? Accessing factory BIOS write enables when the mainboard vendor has enabled "security through obscurity" mechanisms?
If so reverse engineer their flash BIOS write enable method or get out the soldering iron and bypass the write enable garbage and enable it with a switch/jumper or unused chipset gpio and a pull-up/down resistor.
Trying to have control from PCI space via IPL BIOS ROM isn't supported by every chipset and does not give you full control of the hardware. How much control do you want/need and do you really need that chipset supported? Isn't it simpler and lower cost to just solder a few connections vs using a PCI FPGA card that costs more or equal to the motherboard?
The software reverse engineering method takes more time initially but then it's easy later to modify thousands of machines in a cluster or application. If there is enough money for Intel to be interested in supporting you they will. If there is not enough interest, is your project really just a hobby and isn't reverse engineering part of the fun?
The hardware method is easy for a board or two but lots of time later for a thousands of boards.
-Bari
On Sun, Apr 29, 2007 at 01:28:37PM -0500, Bari Ari wrote:
What is the actual problem here?
To effortlessly boot a mainboard from a flash chip separate from the one with the legacy BIOS.
//Peter