coreboot September 2006

coreboot@coreboot.org

52 participants
173 discussions

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

13 years, 3 months

[LinuxBIOS] LinuxBIOS Debian package.

by Uwe Hermann

Hi, being a Debian developer I wondered wether it would make sense to create one or more Debian packages for LinuxBIOS. It seems there are no packages available at the moment - is this correct? I'm not sure it makes sense to have the src/* and targets/* stuff packaged (maybe it does), but some things would be nice, I guess. For example (quick draft): linuxbios - metapackage which draws in all/most other packages linuxbios-doc - documentation linuxbios-utils - standalone utilities, e.g. romcc, flashrom, ... Maybe also something like linuxbios-src which contains the rest, and which can be used to compile images(?) Anyways, let me know if that makes sense or whether there are problems (e.g. if you'd HAVE TO recompile romcc/flashrom/whatever every time on your own, it doesn't make sense to package it)... Cheers, Uwe. -- Uwe Hermann http://www.hermann-uwe.de http://www.it-services-uh.de | http://www.crazy-hacks.org http://www.holsham-traders.de | http://www.unmaintained-free-software.org

13 years, 10 months

Re: [LinuxBIOS] selection of compression algorithm

by Carl-Daniel Hailfinger

yhlu wrote: > then how about the lines for 7z uncompress code? > > YH Working on it. 7z decompressor is really small (8 kb compiled on i386) and written in ISO C (1884 lines of code), but compressor is big and written in C++. Does it still make sense to try to use 7z? How much RAM is the decompressor allowed to use? Regards, Carl-Daniel -- http://www.hailfinger.org/

13 years, 11 months

[LinuxBIOS] qemu images

by Nathanael D. Noblet

Hello, I have a semi related question. I see that the OLPC project uses buildroot to create a root filesystem. I've done the same for a few projects. I'm wondering though, how they convert the filesystem to a disk image. I went over the docs on the wiki and used google, and I don't know how they get a disk image from the filesystems it creates. -- Nathanael D. Noblet <nathanael(a)gnat.ca> Gnat Solutions, Inc

13 years, 11 months

[LinuxBIOS] nVidia MCP55

by Ed Swierk

Hello, I'm about to start getting LinuxBIOS to work on an nVidia MCP55-based mainboard, and wonder whether other folks have already began work on this chipset. I haven't managed to get hold of any nVidia specs yet. Any clues how to enable the serial port on the MCP55? Will it require some SMBus diddling? --Ed

13 years, 12 months

[LinuxBIOS] LinuxBIOS on ASUS P2B-L

by Don Waugaman

Hi all, I'm working on putting LinuxBIOS on an old ASUS P2B-L that I'd like to convert into an "instant-on" server for home use. It has an Intel 440BX Host Bridge with Intel PIIX4e hard disk controller, and a Winbond W83977TF SuperIO chip. I downloaded the manuals for these various chips, so I think I might have a shot at getting them working correctly as long as I can get some debug output on the serial port. Since this will be a server, I don't need any video support, though I'd like to keep the card in the machine uninitialized for when I have to boot the factory BIOS. I've configured grub and the kernel to use the serial port as the console, which works OK. My plan is to use FILO as the LinuxBIOS payload. I've installed a BIOS Savior in the machine and flashed it with another copy of the factory BIOS, which works OK, so (barring checks in the utility's code) I should be able to use the ASUS AFLASH program rather than flashrom. First, I tried to build a FILO payload with serial console only and USE_GRUB=1, which didn't work - it looked like it was still trying to use the VGA console for some functions. It worked OK when I commented out the USE_GRUB line, but I'd still like to try the former configuration - any FILO experts have any tips on how to squash the VGA functions once and for all? Then I grabbed the SVN trees for both v1 and v2. I copied the bitworks/ims mainboard and target directories, as they seemed to be using the 440bx code, and I'm slogging through changing the various bitworks & ims entries in the code to asus & p2bl entries. So far, so good, though I feel somewhat like I'm in a maze of twisty little passages, all alike. My main question is: The W83977TF has support under v1, but not v2 - any tips on porting from one to the other? Also, once I have the superIO initialization code installed, is there some way to get some kind of debug output before RAM initialization? I'm not sure where to put my own debugging output into the code - just a "hello, I'm here" is all I need for starters. I'd be happy for pointers to some docs which might answer some of these questions - I perused some of what I could find in the SVN tree and wiki, but ended up just trying to jump right in instead. Another big question would be - should I continue ahead with v2, or go back to v1? I noticed that v1 had the 440bx support as well, but it looked like v2's configuration setup was a lot easier to deal with, so I started there. Would it be worth it to learn how v1 does things for this project? The other outstanding issue coming down the pike is that the machine has all ECC RAM. Is ECC supported by v1 or v2, and if not by either, which would make it easiest to add support? I'm assuming v2, but I'll try v1 if that would be easier. Many thanks, Don

13 years, 12 months

[LinuxBIOS] Fitting larger flash chips to accomodate a kernel

by Phil Endecott

Dear LinuxBIOS experts, I note the comment on the web site saying that most motherboards have only a 512 kbyte flash chip, which isn't enough for a compressed kernel, and so LinuxBIOS is normally used with a bootloader like FILO to load a kernel from an IDE device or whatever. But larger flash chips are available. For example, my VIA board has a 512k SST chip for which pin-compatible 1M and 2M parts are available (but apparently no larger than that). So my first question is, will higher-capacity flash chips "just work", or does the motherboard design limit them to the flash size that they are supplied with? If it is possible to fit a larger chip the next question is whether these are easy to obtain in small (e.g. one-off) quantities. Assuming that this is possible, let's say that I build a kernel containing only minimal drivers for the framebuffer and ethernet - no IDE etc, and maybe use the "Linux-Tiny" patch. I wonder how much space would then be left for an initrd. Ideally I would like to fit a single executable of maybe a few hundred kbytes uncompressed which is run instead of init (this is a for fixed-purpose box). This is a very appealing way to use cheap PC hardware in fixed-purpose applications, if it can be done. Maybe other readers are already doing this sort of thing? Many thanks for any advice, or pointers to existing docs. Cheers, Phil.

13 years, 12 months

[LinuxBIOS] iasl path config option.

by Uwe Hermann

13 years, 12 months

Re: [LinuxBIOS] DK8HTX - CONFIG_PCI_ROM_RUN -> VGA

by Philipp Degler

On Thursday 28 September 2006 21:51, ollie wrote: > On Thu, 2006-09-28 at 21:09 +0200, Philipp Degler wrote: > > Am Donnerstag, 28. September 2006 19:49 schrieb ollie: > > > On Thu, 2006-09-28 at 18:03 +0200, Philipp Degler wrote: > > > > Am Mittwoch, 27. September 2006 22:20 schrieb ollie: > > > > > On Wed, 2006-09-27 at 21:13 +0200, Philipp Degler wrote: > > > > > > Right now we have all on-board devices working. Even xorg shows > > > > > > up. Only exception is native vga-bios. It gets loaded but just a > > > > > > few lines of LB-boot are printed. Anyway at least our HTX adaptor > > > > > > card is working :) > > > > > > > > > > Any serial console log when it is initializing VGA? > > > > > > > > I attached you the capture file of my console log if i boot with > > > > option CONFIG_CONSOLE_VGA = 1 > > > > option CONFIG_PCI_ROM_RUN = 1 > > > > option CONFIG_CONSOLE_BTEXT = 0 > > > > > > > > instead of > > > > option CONFIG_CONSOLE_VGA = 0 > > > > option CONFIG_PCI_ROM_RUN = 0 > > > > option CONFIG_CONSOLE_BTEXT = 1 > > > > > > > > to mention. I can already see something on the screen. > > > > > > The log looks alright. What is the problem exactly? > > > > The last line of the log is also the last line on the screen. After this > > last line "for IRQ, reg 0x00000017 value 0x00010000 0x00000000" the > > system hangs completely. > > Does this happen when VGA is disabled? no, and if we use "dir /drivers/ati/ragexl" we even have xorg running. Switching on CONFIG_PCI_ROM_RUN and CONFIG_CONSOLE_VGA leads to this behavior. We prepared rom image as described in the online vga howto. > > Where does these lines come from? Your modification to LB? > > Ollie

14 years

[LinuxBIOS] stuff to bring

by Ronald G Minnich

RON > usb to serial (2) > 1M flash parts 49lf008a > 512K flash parts. 49lf004 > epia that works > digital logic msm800sev that is in progress > lippert frontrunner that is in progress. > serial and ethernet cables. > several enet switches. > outlet strips > CF cards > IDE->CF adapters > USB storage dongles > RUMBA board for burning flash parts. > PCMCIA->CF > USB->CF > several IBM power warts 3 OLPC Richard 1 OLPC ?? monitor(s) keyboard(s) USB rom emulator ron

14 years

Jump to page:

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot September 2006