coreboot April 2007

coreboot@coreboot.org

76 participants
281 discussions

[LinuxBIOS] "Cache As RAM" support routine for non-K8 CPUs
by Darmawan Salihun 30 Apr '07

30 Apr '07

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_guid… --Darmawan

5 15

[LinuxBIOS] FLASH Schematic
by Bari Ari 29 Apr '07

29 Apr '07

Here's a typical parallel flash device schematic in pdf. -Bari

1 0

Re: [LinuxBIOS] EPIA fix for non working IDE
by Peter Stuge 29 Apr '07

29 Apr '07

Hey Ben, 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 > >auto.c. > > 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. //Peter

2 1

[LinuxBIOS] Tyan S2882 Payload
by Jim Bradley 29 Apr '07

29 Apr '07

I recently purchased a Tyan S2882 motherboard so that I could play with linuxbios. 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. Any help? Thank you.

2 1

[LinuxBIOS] On flashrom architecture
by Darmawan Salihun 28 Apr '07

28 Apr '07

Hi all, 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 :-(. --Darmawan -- -------------------------------------------------------------------- -= Human knowledge belongs to the world =-

4 9

[LinuxBIOS] GA-M57SLI-DS4 rev. 2.0 with one 8-pin BIOS chip
by Quux 28 Apr '07

28 Apr '07

seems like GA came out with the third revision of their M57SLI mobo. still no real dual bios ! no socketed chip either. rev. 2.0 has one populated flash chip and they dont use plcc32 on that board. a secondary 8 pin chip would be easier to solder, I'd guess. http://www.gigabyte.de/Products/Motherboard/Products_Overview.aspx?ProductI…

4 7

[LinuxBIOS] m57sli-s4 and i2c
by Ward Vandewege 28 Apr '07

28 Apr '07

Hi all, 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 2611. 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 Option "NoDDC2" 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 http://www.lm-sensors.org/browser/lm-sensors/trunk/prog/detect/sensors-dete… Under LinuxBIOS, the it87 module can not be loaded: FATAL: Error inserting it87 (/lib/modules/2.6.20.1/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? Thanks, Ward. -- Ward Vandewege <ward(a)fsf.org> Free Software Foundation - Senior System Administrator

6 14

[LinuxBIOS] Can this barebone be supported? Asus P1-AH2
by Marcelo Coelho 28 Apr '07

28 Apr '07

Hi! 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: CPU AMD Althon 64/FX/X2 up to 5200+ GHz Socket M2 1000/800 MHz Chipset North Bridge: nVidia Crush 51PV South Bridge: nVidia MCP 51 Memory Dual DDRII 800/667/533/400 Support max. 2GB Expansion Slots 2 x PCI Graphics Integrated GeForce 6 GPU IDE 1 x ATA 133 S-ATA 2 x SATA II LAN 10/100/1000 Mbps I know that ck804 is supported, but never saw anyone mentioning any work on a geforce 6 mobo. Can this be supported by LinuxBios? Best regards!

2 2

Re: [LinuxBIOS] r2550 - trunk/LinuxBIOSv2/util/flashrom
by Carl-Daniel Hailfinger 28 Apr '07

28 Apr '07

Hi! svn(a)openbios.org wrote: > 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. Regards, Carl-Daniel -- http://www.hailfinger.org/

7 28

[LinuxBIOS] Question of making 1MB flash rom?
by Hao Li 28 Apr '07

28 Apr '07

Hi all, 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? Thanks

2 1

← Newer
1
2
3
4
5
6
7
...
29
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot April 2007