coreboot

coreboot@coreboot.org

6 participants
39699 discussions

Re: the plan for stable
by ebiederman＠lnxi.com 14 Oct '02

14 Oct '02

Ronald G Minnich <rminnich(a)lanl.gov> writes: > A short sketch. > > What I want to do, but have not had time to do. For each mainboard, we > designate an owner. The owner is responsible for letting us know that > their mainboard works. Mainboards are in one of 3 states: (stable, > unstable, unsupported) > > Mainboards start out in the unstable or unsupported state. > > We pick a date (1/1/03?) and say we want all owners of all mainboards to > tell us that their mainboard is stable. We freeze the tree one month > ahead of that time and the only changes that go in are for stabilization. 1 January 2003 is a bad date for me as I have plans to be far away from computers over christmas. > If nobody steps up for a board, it goes to unsupported state. Boards with > owners start out in the unstable state. The challenge is for a lot of boards we do not get active feedback after a port has been completed. So for any ongoing work we need to very very careful not to make changes to the core that break ports. I am probably the worst offender, except for the various bits of debug code that come and go but still. > Mainboards move to the stable state when the owner confirms stability. > When patches are made for a problem, ALL stable mainboards revert to > unstable. We iterate until we get it solid, then freeze it. For the first round this looks o.k, it really depends on what kind of feedback we have. > This information is maintained by a file in each mainboard directory > called STATUS, which consists of name/value paris. One file in the root directory called STATUS should do it.. > Will this work? Sounds like a good rough draft. The very important thing about the stable series is that nothing happens to the core code that could possibly break a motherboard port. That way within a stable series we can get more but not fewer boards working. Then whenever a new port gets working we can do another release. Of course if the come in fast enough we can delay... > thanks (I'm off email for a bit -- at a workshop) Speaking of which we probably should put together some kind of conference/workshop for LinuxBIOS. So the developers can get together and talk face to face. Eric

3 2

strange error on sis900 ethernet
by zhu shi song 14 Oct '02

14 Oct '02

I met one strange error on sis900 ethernet driver. I'm using cvs freebios on 6 Oct, 2002 , kernel 2.4.17, mainboard is winfast6300. After booting using linuxbios stored in DOC, I boot my host linux system using normal bios. the host linux is the same system as in DOC. I test pings, the result is ( after linuxbios booting): ping -s 2592 192.12.11.1 ( remote ip addr ) 0% lost ping -s 2593 192.12.11.1 ( remote ip addr ) no response, 100% lost I can't make the mainboard work correctly until I have booted windows98. Then I use my host linux system to boot, the thing is ok. (after windows98 booting ) ping -s 2592 192.12.11.1 0% lost ping -s 2593 192.12.11.1 0% lost What's the problem, maybe something wrong with pci ,or sis900 init code. thanks zhu __________________________________________________ Do you Yahoo!? Faith Hill - Exclusive Performances, Videos & More http://faith.yahoo.com

1 0

MTRR problem
by majinsuk＠etri.re.kr 13 Oct '02

13 Oct '02

Hello I am Korean reseacher and was deeply impressed by your project and community. I have been working some home server with linuxbios. That is based on SIS645, SIS961 and Pentium 4. My project was stopped by P4 MTRR fixing problem at last week. I found cache on/off routine in mailing list and inserted that code. The result was system stop on that routine. How can I solve this problem? Please let me know about this. Best regards.

1 0

Re: p4dpe
by ebiederman＠lnxi.com 13 Oct '02

13 Oct '02

Larry Creech <larry.creech(a)baldguysoftware.com> writes: > Eric, > > I just got subscribed to the listserv. I'm a few months behind since I've only > had access to the archives upto Aug. I'm trying to build linux bios for the > p4dpe. I've got it mostly working except some raminit stuff. I wasn't looking > forward to writing it for the E7500 and knowing it was going to be about 2k > lines in assembly and that you had already done it. I'm assuming the > SMBUS_MEM_CHANNEL_OFF value is "4", but have not tackled the spot_check function > > yet. Is spot_check something that will be in the E7500/raminit.inc? It is a cleaned up variant of ram/ramtest.inc and I think I have probably checked it in. Many not yet. SMBUS_MEM_CHANNEL_OFF is indeed 4. That is how I group the paired dimms. I haven't gotten to merging the mainboard directories yet. There is some old stuff in there but not quite everything. Eric

1 0

Drive VGA card (Am I right ?)
by chiangyj 13 Oct '02

13 Oct '02

After reading some related posts, I am not sure how LinuxBios drive VGA card ? LinuxBios replace normal BIOS with its own BIOS, so it can't drive VGA card like normal initialization(find the VGA card, map VGA BIOS to system memory, then call initialize routine) There are two ways to drive it: 1. Use BIOS emulator: Run VGA BIOS in BIOS emulator and you can drive it like normal initialization. BIOS emulator's job is to take appropriate actions(hardware-dependent actions, eg. access VGA register) 2. Use matroxfb: Because it can intiailize VGA without VGA BIOS. Am I right ? And Is there another way to drive VGA card? Thank for your help.

2 1

Making IPL coding easier? (fwd)
by Ronald G Minnich 13 Oct '02

13 Oct '02

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. thanks ron ---------- Forwarded message ---------- Date: Wed, 9 Oct 2002 17:50:22 -0600 From: Neil Crossley <etanza(a)lycos.co.uk> To: rminnich(a)lanl.gov Subject: Making IPL coding easier? Hi Ron, Dunno if this will be any use to you but you never know ..... I was thinking how much easier is would be to write dram setup code for IPL's if it was possible to get even a small amount of memory for temp variables and a stack. This would get rid of the annoing CALL_SP/BP and RET_SP macros. Obviously this 'memory' couldn't be DRAM coz we haven't initialised it yet. and using the CMOS RTC locations would get us a few bytes of memory, but no stack (i'm suprised you dont use the RTC memory though as at least you could store a few temp vars if you needed to) Having some work memory should make the IPL code a bit more readable and thus easier to work with, you could also put more functionality there leaving less work for the C code to do later. I found 2 methods of getting some work memory, one relies of the motherboard having a SiS7018 soundchip (as found on the SiS540/630/730 series) and the other requires a CPU with MTRR support. Using method 2 may allow you to code the DRAM initialisation code in 'C' as it will provide you with 64K of work memory, but it may take some tweaking to get C code running. Appologies for the following code fragments using intel syntax but they should be easy enoogh to follow. Have fun and mail me if you have any questions ... bye for now .... Neil :) METHOD 1 - Use the 7018 Soundchip to get 1KB of memory ------------------------------------------------------ The first way is at least relativley sane but relies on the mainboard having the 7018 soundchip enabled (some motherboard manufacturers choose to disable this and fit another chip on the mainboard) The 1KB of ram exists from offset 0x800 in the soundchip's Memory mapped IO space mov ebx,0x80000c00 ; Select 7018 Soundchip mov eax,ebx ; Set MMIO Base address mov al,0x14 mov dx,0xcf8 out dx,eax add dl,4 mov eax,0xf8100000 ; Map MMIO at this address out dx,eax mov eax,ebx ; Enable device mov al,0x04 sub dl,4 out dx,eax add dl,4 mov eax,0x6 ; Just set Bus master and MMIO, not I/O out dx,eax mov esp,0xf8100bfc ; Set stack to top of ram mov ebp,0xf8100800 ; Set ebp to bottom mov eax,0xf00dface ; Check the memory is really mov [ebp],eax ; working ... mov ebx,[ebp] cmp eax,ebx je .got_mem jmp ERROR_1 ; issue some sort of BEEP code or something .got_mem As far as I know, VIA and ALI both use variations of this soundchip on their integrated boards so this may work on those chipsets too :) METHOD 2 - Abuse the CPU Cache to get 64K of memory --------------------------------------------------- CPU's like the Hitachi SH series allow the cache to be memory mapped and used as RAM, so I wondered if there was any way to do this on the Intel chips. I actually discovered this method by accident (dont ask - long story!!). To use it requires a CPU with MTRR support. Note - When you switch to protected mode make sure the NW and CD bits in CR0 are 0 (enabled) doing "mov eax,1" and "mov cr0,eax" will do this nicely :) ; Enable Variable MTRR's only (not fixed) and set the default memory type to ; uncached xor edx,edx mov eax,0x800 mov ecx,0x2ff wrmsr ; Allocate ONE MTRR to map 64KB at location 0xc000000 mov ecx,0x200 ; Base mov edx,0 mov eax,0xc0000006 wrmsr mov eax,0xffff0800 ; Mask (64K) mov edx,0x0000000f mov ecx,0x201 wrmsr cld ; Wipe our 'memory' forcing all the 64K xor eax,eax ; to be cached mov ecx,65536/4 mov edi,ebp rep stosd mov esp,0xc000fffc ; Set stack to top of ram mov ebp,0xc0000000 ; Set ebp to bottom mov eax,0xf00dface ; Check the memory is really mov [ebp],eax ; working ... mov ebx,[ebp] cmp eax,ebx je .got_mem jmp ERROR_1 ; issue some sort of BEEP code or something .got_mem ______________________________________________________ Check out all the latest outrageous email attachments on the Outrageous Email Chart! - http://viral.lycos.co.uk

2 2

Re: p4dpe (fwd)
by ebiederman＠lnxi.com 13 Oct '02

13 Oct '02

Ronald G Minnich <rminnich(a)lanl.gov> writes: > fyi ... I'm still merging... And yes I probably introduced a typo or two. So far I have just managed to wade through most of the easy parts. I am having to watch my code fairly closely so I don't introduce changes that break the tree for other people. Who was this from? I'm willing to work with people directly... Eric > > ---------- Forwarded message ---------- > Date: Sat, 12 Oct 2002 15:29:55 -0500 > Subject: Re: p4dpe > > Ron, > > Thanks. > > The E7500/raminit.inc has a few problems. > > SMBUS_MEM_CHANNEL_OFF on line# 981 and 985 is not defined. > A typo on line # 1097, "a" should be deleted? > Proceedure call to "spot_check" on line# 1664 does not exsist (in > this codebase).

1 0

LinuxBIOS + FreeBSD = true?
by Christer Weinigel 12 Oct '02

12 Oct '02

Hi, a quick question, is LinuxBIOS able to boot any of the BSD-flavours? I'm especially interested in FreeBSD. /Christer -- "Just how much can I get away with and still go to heaven?" Freelance consultant specializing in device driver programming for Linux Christer Weinigel <christer(a)weinigel.se> http://www.weinigel.se

5 9

Trouble calling hardwaremain
by Hieu T. Tran 12 Oct '02

12 Oct '02

Greeting, With Ron and Eric help, we were able to build a romimage for our VIA vt133 platform with reset_vector correctly located at 0x7fff0. The resulting romimage seems to have successfully initialized memory and copied code from rom to ram, but seems to be stucked at the call to hardwaremain from crt0. (Post code is 0xfd, which is right before the call). Anyone has a good idea as to why this call would possibly fail? I'm assuming that SDRAM is successfully initialized because the copy operation to ram was successful (e.g. it didn't hang the system), but I'm not too sure. I'm going to insert some code in crt0 tomorrow to verify that the image in rom and ram are the same, but if anyone has any other idea, I would very much like to know. Regards, -- HT

3 4

support for supermicro P4DL6 - serverworks GC-LE chipset
by Dale J Robson 12 Oct '02

12 Oct '02

I'm trying to get LinuxBIOS working on a SMP xeon board: http://www.supermicro.com/PRODUCT/MotherBoards/GC_LE/P4DL6.htm I'm attaching the lspci -vv output. Is there any possibility of this board being supported? Would it require writing numerous new device drivers? If this board is a poor fit for use with the LinuxBIOS project. Can anyone recommend a more compatible dual p4 xeon board with 1000baseT? -- Dale Robson Software Engineer Lockheed Martin - NESS Syracuse

3 3

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