> 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
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.dehttp://www.it-services-uh.de | http://www.crazy-hacks.orghttp://www.holsham-traders.de | http://www.unmaintained-free-software.org
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/
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
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
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
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.
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
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
