coreboot April 2007

coreboot@coreboot.org

76 participants
281 discussions

[LinuxBIOS] Add initial support for intel i855gme northbridge

by Jon Dufresne

Add initial support for i855gme. This is a work in progress and I don't expect it to work on all boards, or even any besides mine. This is based heavily on i855pm. Signed off by Jon Dufresne <jon.dufresne(a)gmail.com>

12 years, 9 months

[LinuxBIOS] my zepto.se laptop info

by Peter Brännvall

14 years

[LinuxBIOS] i440bx RAM initialization code (SPD)

by Alfred Wanga

Ok, so I've been working on porting the SPD code, and this patch is what I've got so far. Here are some of the outstanding issues/changes: * SPD register code (tested using PCI/SMBus Dumps) I ported the v1 assembly and made some modifications when the numbers didn't really add up on my machine (particularly the DRB registers) and added some minor functionality (CAS2/3 detection) that may or may not work, although based on the results from the dataset I used, it should work (at least for my current setup). * PMCR - When should it be updated? Looking at the assembly, it seems as though it's ok to just set the final value before the RAM refresh code instead of waiting until afterwards, but I don't know for sure, so I left the original code alone. Judging from some of the recent 440bx discussions, it may not make much of a difference anyway. * sdram_enable delays I changed all the RAM timing delays (tRP, tRC, tMRD) to 1usec, since the timings are on the order of hundreds of nanoseconds (according to SPD values) and the smallest resolution timer available seems to be udelay() anyway. It should work for any SDRAM, and shaves a few milliseconds off previous code. Incidentally, I noticed that the v1 assembly sets the clock idle value to 32 in the PGPOL register until SDRAM refresh is enabled, but it seems like it should eventually be set back to zero (which is what the patch does). Does it matter? Anyway, enough verbosity... take a look and see what you think. Unfortunately, besides testing the SPD code on memory dumps, I haven't tested the image. Alfred

14 years, 4 months

Re: [LinuxBIOS] BIOS Saver RD1

by Ken Fuchs

> On Wed, Aug 03, 2005 at 11:59:20AM +0900, Jun OKAJIMA wrote: > > Probably, most guys here use BIOS Saver. > > And it works well? > > In mine, RD1 for PLCC gets not being writable suddenly. > > I mean, it seems writable but # flash_rom -v fails. > > I solved this problem by a quick hack. > > > > How about yours? You can write RD1 or W49F002U well? > > Any problem happen? Johnathan McDowell wrote: > Even after that it's sometimes a bit flakey and I have to erase, then > write it. I've put the board's original BIOS in the RD1 and am writing > to the SST 39SF020A instead, which works without problems. I've read posts about the RD1 that suggest its integrated flash device is low quality and it may take 10 or more flash attempts to get a good flash update to the RD1 flash device. As a result, many RD1 BIOS Savior users will flash the commercial BIOS image (or other known good BIOS image) into the RD1 integrated flash device as many times as needed to get an image that boots. Then use the original BIOS device to flash test BIOS image (usually LinuxBIOS images among this group), since the original BIOS device usually flashes OK on the first attempt. I've used the RD1 in the above fashion with great success on the Tyan S2885 mainboard. The same RD1 would not work on the nVidia CK8-04 CRB mainboard. I think the CK8-04 CRB requires a flash device that the RD1 does not support. However, the RD1 worked well as an "do nothing" adapter which allowed swapping the BIOS flash device between my flash burner and the mainboard without any wear to the mainboard's BIOS socket. BTW, my flash burner is an older Enhanced Willem Universal Programmer. I got mine for only $60 US over a year ago. I've seen it for less than $40 on eBay a few weeks ago. The newest model is going for about $50 US. It does a LinuxBIOS flash in about 5 minutes; not bad for a $60 burner. However, it does require changing DIP switches to match an image for each device it can program. Great for the amateur or professional with a small budget. > > BTW, a cable of your RD1 is not broken? > > I needed soldering to fix it. > Mine was fine out of the box. Mine cable and switch worked fine out of the box as well. Sincerely, Ken Fuchs <kfuchs(a)winternet.com> ami-mac-sun

14 years, 4 months

[LinuxBIOS] ASUS A8N-SLI Premium (K8, CK804, IT8712)

by David M Barr

Hi, Attached are dmidecode and lspci -t/n/v output for my system, which has the same MB as Adrian's. Since he has the tools, can anyone provide tips on how to get started? Regards, David M. Barr On 19/03/2007 12:06:43 am, Adrian-Ken Rueegsegger wrote: Hi David, Thanks for the info! I did find out that all chipsets are supported. I bought myself a Bios saviour and I have all the other hardware one needs. I just had little time playing around with it the last two weeks but I want to start looking into it again, that's why I wanted to ask if you had made some progress. I am not quite sure where to start but I found a motherboard [1] that is quite "similar" to ours: Sun Ultra40. It has the same North- and Southbridge; SuperIO is different though. Would you know where to go from here? Cheers, Adrian

14 years, 4 months

[LinuxBIOS] #40: Decide on common header #ifndef names or standards for usage

by LinuxBIOS

#40: Decide on common header #ifndef names or standards for usage -----------------------------+---------------------------------------------- Reporter: uwe | Owner: uwe Type: enhancement | Status: new Priority: minor | Milestone: Cosmetic fixes Component: code | Version: v2 Keywords: | Due_close: MM/DD/YYYY Include_gantt: 0 | Dependencies: Due_assign: MM/DD/YYYY | Patchstatus: there is no patch -----------------------------+---------------------------------------------- We have lots of variations for "include guards" in the code: {{{ _FOO _FOO_H __FOO_H __FOO_H__ _FOO_H_ __FOO_DEFINED ... }}} Is there a special convention or agreement on when to use which? If yes, it should be documented. If no, we should standardize on one format and use it consistently. -- Ticket URL: <http://tracker.linuxbios.org/trac/LinuxBIOS/ticket/40> LinuxBIOS <http://www.linuxbios.org/>

14 years, 5 months

[LinuxBIOS] Fwd: ECS top hat flash - dual-bios-circuit useable els ewhere ?

by David H. Barr

Jmayes, author of... "Tivo piggy-back PROM" "How to build the Tivo PROM piggy socket", and "Tivo PROM piggy-back socket installation" ...has given explicit permission for these documents to be posted to this list; for them to be published under the "Creative Commons Attribution-Share Alike 3.0 License" found at http://creativecommons.org/licenses/by-sa/3.0/ ; and for their contents to be inserted into the LinuxBIOS wiki. I have temprorarily hosted these documents at... http://gozelle.com/jmayes/tivo_piggyback_prom.pdf http://gozelle.com/jmayes/how_to_build_the_tivo_prom_piggy_socket.pdf http://gozelle.com/jmayes/tivo_prom_piggy_back_socket_installation.pdf ...until such time as their useful data is wikified. Again, none of this is my original work; all I did was ask for permission. -dhbarr. ---------- Forwarded message ---------- From: Jmayes - Direct Date: Apr 29, 2007 8:48 PM Subject: RE: [LinuxBIOS] ECS top hat flash - dual-bios-circuit useable els ewhere ? To: "David H. Barr" <dhbarr(a)gozelle.com> Ok, that sounds fine to me :) Go ahead and post. Hope it helps out. Thankx again, Jeff -----Original Message----- From: David H. Barr [mailto:dhbarr@gozelle.com] Sent: Sunday, April 29, 2007 9:21 PM To: Jmayes - Direct Subject: Re: [LinuxBIOS] ECS top hat flash - dual-bios-circuit useable els ewhere ? Jeff, My gut says to go with the "Creative Commons Attribution-Share Alike 3.0 License", found at http://creativecommons.org/licenses/by-sa/3.0/ When you break it down this says: - I want people to be able to use this - I don't care if they make some money off of it - I want to be recognized as the original author - I want people to be able to modify and redistribute this, but only if they keep this same set of provisions. A quick note posted directly back to me indicating that it is okay for me to release your work under this or another specific license of your choice would be great; that way there's a written understanding. Basically I intend to simply CC: your 'pdfs to the LinuxBIOS list with the CreativeCommons license attached and your name mentioned as the original author and copyright holder, and then put the content in the LinuxBIOS wiki. Thanks again for your affirmitive response; I just want to make doubly certain before I use someone else's good work. Thanks again, -dhbarr. On 4/29/07, Jmayes - Direct wrote: > > > HI, > > No problem, you can just pick whatever licence you think will do- my > first guess is the 'Sharealike'. I am not interested in any fame or > fortune, just glad the info is going to good use. > > I finally found a good low-profile socket at digikey- I will try to > find the info, Almost all of the USA made sockets are too tall (made > with to much plastic), but most of the china ones are fine. > > I have used this trick (piggyback rom) in many widgets, saves huge > time vs taking the old one off the board, most cases you have to cut > the enable pin to the original prom but sometimes you can do it > without any cuts at all. > > Just get me some info on your target devices and I can help. > > Thankx and goodluck! > Jeff > > > -----Original Message----- > From: David H. Barr [mailto:dhbarr@gozelle.com] > Sent: Sunday, April 29, 2007 5:19 PM > To: Jmayes - Direct > Subject: Fwd: [LinuxBIOS] ECS top hat flash - dual-bios-circuit > useable elsewhere ? > > > Greetings. > > I'm with the LinuxBIOS project, and I was wondering if we could get > permission to license your three documents... > > * "How to build the Tivo PROM piggy socket" > * "Tivo PROM piggy-back socket installation" > * "Tivo piggy-back PROM" > > ...under some sort of open license such as... > * Free Documentation License > * Creative Commons License > * Attribution License > * Sharealike License > > Basically I want to be able to share this data with our other > developers, but I want to make sure you get credit for sparking me on > this idea. We're basically doing the same work you did with TiVo's, > except we do server, desktop, and embedded motherboard BIOS chips. > > Let me know what I'd need to do to make this happen. I think the > easiest method for -our- purposes would be permission to copy the data > and pictures out of your PDFs and into the LinuxBIOS wiki. I can > guarantee your name and URL would be included, and like I mentioned > any open license that allows people to update, correct, etc. the > original would be awesome. > > Anyhoo, I've wasted enough of your time. Thanks for taking the time > to read this. > > -dhbarr. > > PS: Attached is the conversation on-list that sparked all this. > > > On 4/29/07, Peter Stuge <stuge-linuxbios(a)cdy.org> wrote: > > On Sun, Apr 29, 2007 at 01:38:44PM -0500, David H. Barr wrote: > > > > I'd love to find out more about exactly how this is done. > > > > > > Probably a lot like the TiVo PROM back-to-back socket. Basically > > > two plcc32 sockets soldered back to back with a few pin tweaks. > > > > Yes, with "a lot like" and "a few tweaks" being the gaps I'd like to > > fill. :p > > > > > > > Yet another variation on dead-roaching or piggy-backing a chip. > > > > > > "tivo prom piggy" should get you there as a search query. > > > > Not really with a lot of detail unless I registered at the DDB > > forum. Oh how I hate forums. > > > > Anyway, at least one of the posts indicated that a trace needs to be > > cut, and one wire needs to be soldered. This solves the problem I'm > > interested in, but I'm only interested in ways to accomplish the > > same thing completely without soldering. > > > > > > > I've occasionally wondered how hard it would be to have something > > > like this manufactured, thereby bypassing the whole TopHat / > > > BIOSSavior vendor specific issue. > > > > The BIOS savior is very generic. Some issues may come from the > > choice of flash chip inside it, but there would probably be issues > > on other boards with another chip if that's the actual cause of the > > reported problems. > > > > TopHat I don't know about. I'm interested in Quux' findings! :) > > > > > > On Sun, Apr 29, 2007 at 09:44:43PM +0200, Quux wrote: > > > the tivo socket has no circuitry at all. > > > > Really? Is there a schematic somewhere?

14 years, 5 months

[LinuxBIOS] LinuxBios on a braille display ?

by Sébastien Hinderer

Dear all, I am wondering if it would be possible to run LinuxBios on a braille device. Regarded from a Linux point of view, such a device is very similar to a PC or a laptop, as you will certainly notice according to the datas provided below. If the device is supported, the idea would be to install a screen-reader (like brltty) in the BIOS, which would help when there is a problem while booting the operating system's kernel. So below are the outputs of lspci -n, lspci -v and lspci -t run on the terminal. Could someone please tell me whether there is a possibility or not to install LinuxBios on such a machine ? Thanks a lot in advance for your help, Sébastien. # lspci -n 00:00.0 0600: 1078:0001 00:02.0 0200: 1282:9102 (rev 40) 00:12.0 0601: 1078:0100 (rev 30) 00:12.1 0680: 1078:0101 00:12.2 0101: 1078:0102 00:12.3 0401: 1078:0103 00:12.4 0300: 1078:0104 00:13.0 0c03: 0e11:a0f8 (rev 06) # lspci -v 00:00.0 Host bridge: Cyrix Corporation PCI Master Flags: bus master, medium devsel, latency 0 00:02.0 Ethernet controller: Davicom Semiconductor, Inc. 21x4x DEC-Tulip compatible 10/100 Ethernet (rev 40) Subsystem: Davicom Semiconductor, Inc. Unknown device 8212 Flags: bus master, medium devsel, latency 165, IRQ 11 I/O ports at 1000 [size=256] Memory at fedfe000 (32-bit, non-prefetchable) [size=256] [virtual] Expansion ROM at 10000000 [disabled] [size=256K] Capabilities: [50] Power Management version 2 00:12.0 ISA bridge: Cyrix Corporation 5530 Legacy [Kahlua] (rev 30) Flags: bus master, medium devsel, latency 64 00:12.1 Bridge: Cyrix Corporation 5530 SMI [Kahlua] Flags: medium devsel Memory at 40012000 (32-bit, non-prefetchable) [size=256] 00:12.2 IDE interface: Cyrix Corporation 5530 IDE [Kahlua] (prog-if 80 [Master]) Flags: bus master, medium devsel, latency 0 I/O ports at 1400 [size=16] 00:12.3 Multimedia audio controller: Cyrix Corporation 5530 Audio [Kahlua] Flags: bus master, medium devsel, latency 0 Memory at 40011000 (32-bit, non-prefetchable) [size=128] 00:12.4 VGA compatible controller: Cyrix Corporation 5530 Video [Kahlua] (prog-if 00 [VGA]) Subsystem: Cyrix Corporation Unknown device 0001 Flags: medium devsel Memory at 40800000 (32-bit, non-prefetchable) [size=8M] 00:13.0 USB Controller: Compaq Computer Corporation ZFMicro Chipset USB (rev 06) (prog-if 10 [OHCI]) Subsystem: Compaq Computer Corporation ZFMicro Chipset USB Flags: bus master, medium devsel, latency 64, IRQ 9 Memory at 000e0000 (32-bit, non-prefetchable) [size=4K] # lspci -t -[0000:00]-+-00.0 +-02.0 +-12.0 +-12.1 +-12.2 +-12.3 +-12.4 \-13.0

14 years, 5 months

[LinuxBIOS] 16p h8qm8 s4985 1207f

by Zeb Whitman

afaik supermicro h8qm8-2 ( http://www.supermicro.com/Aplus/motherboard/Opteron8000/MCP55/H8QM8-2.cfm ) and tyan s4985 ( http://www.tyan.com/product_board_detail.aspx?pid=271 ) are only quad socket 1207/ f boards on market discounting sunfire x4600-m2 query is two fold 1 what is future of quad core barcelona support on 1207 / f 2 what are odds of these boards supported i do not yet own either board but linuxbios support would sway me zw ps http://www.llnl.gov/computing/hpc/resources/OCF_resources.html#zeus http://www.appro.com/product/server_1Uxserver_opteron.asp

14 years, 5 months

[LinuxBIOS] EPIA fix for non working IDE

by Ben Hewson

Hi all There has been a bug in the EPIA build which at some point stopped FILO being able to boot from an IDE drive. After much digging I have found the problem and have changed the following two files. LinuxBIOSv2/src/mainboard/via/epia/auto.c LinuxBIOSv2/src/southbridge/via/vt8231/vt8231_ide.c I have also changed the default COM speed from 19200 to 115200. This is a personal thing but every time I update LB I forget to change it back. Leave it out if you wish. LinuxBIOSv2/src/mainboard/via/epia/Options.lb I have attached a patch file. Can someone please see about checking & adding the fixes to the repository. There is still an issue with the board sometimes hanging on boot. So I would not class this as fully working just yet. Regards Ben Hewson Index: /home/ben/sw/LinuxBIOSv2/src/mainboard/via/epia/auto.c =================================================================== --- /home/ben/sw/LinuxBIOSv2/src/mainboard/via/epia/auto.c (revision 2621) +++ /home/ben/sw/LinuxBIOSv2/src/mainboard/via/epia/auto.c (working copy) @@ -66,8 +66,16 @@ /* we do this here as in V2, we can not yet do raw operations * to pci! */ - dev += 0x100; /* ICKY */ - + + /* changed this to work correctly on later revisions of LB. + * The original dev += 0x100; stopped working. It also appears + * that if this is not set here, but in ide_init() only, the IDE + * does not work at all. I assume it needs to be set before something else, + * possibly before enabling the IDE peripheral, or it is a timing issue. + * Ben Hewson 29 Apr 2007. + */ + + dev = pci_locate_device(PCI_ID(0x1106,0x0571), 0); pci_write_config8(dev, 0x42, 0); } Index: /home/ben/sw/LinuxBIOSv2/src/southbridge/via/vt8231/vt8231_ide.c =================================================================== --- /home/ben/sw/LinuxBIOSv2/src/southbridge/via/vt8231/vt8231_ide.c (revision 2621) +++ /home/ben/sw/LinuxBIOSv2/src/southbridge/via/vt8231/vt8231_ide.c (working copy) @@ -15,6 +15,12 @@ // Run the IDE controller in 'compatiblity mode - i.e. don't use PCI // interrupts. Using PCI ints confuses linux for some reason. + /* Setting reg 0x42 here does not work. It is set in mainboard/auto.c + * It probably can only be changed while the IDE is disabled + * or it is possibly a timing issue. Ben Hewson29 Apr 2007. + */ + + /* printk_info("%s: enabling compatibility IDE addresses\n", __FUNCTION__); enables = pci_read_config8(dev, 0x42); printk_debug("enables in reg 0x42 0x%x\n", enables); @@ -22,6 +28,8 @@ pci_write_config8(dev, 0x42, enables); enables = pci_read_config8(dev, 0x42); printk_debug("enables in reg 0x42 read back as 0x%x\n", enables); + */ + } enables = pci_read_config8(dev, 0x40); Index: /home/ben/sw/LinuxBIOSv2/src/mainboard/via/epia/Options.lb =================================================================== --- /home/ben/sw/LinuxBIOSv2/src/mainboard/via/epia/Options.lb (revision 2621) +++ /home/ben/sw/LinuxBIOSv2/src/mainboard/via/epia/Options.lb (working copy) @@ -51,7 +51,7 @@ default CONFIG_CONSOLE_SERIAL8250=1 ## Select the serial console baud rate -default TTYS0_BAUD=19200 +default TTYS0_BAUD=115200 # Select the serial console base port default TTYS0_BASE=0x3f8

14 years, 5 months

Jump to page:

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot April 2007