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>
Well, as there seems to be a lot of cleaning up going on lately, might
as well add this to the docket. The attached patch removes the Bitworks
IMS, as 1) there's no video support for it, 2) no one objected when this
was discussed previously, and 3) no one seems to have one, and they
aren't readily available. Any comments are welcome.
Signed-off-by: Corey Osgood <corey_osgood(a)verizon.net>
Here's the chip_enable code for the ALI M1533 and the board_enable for
the Asus P5A, an ALI M1541+M1533 socket 7 motherboard.
It's quite nasty:
It does an SMBUS read/write to a yet unidentified device, i think it is
the superio, but i'm not sure.
The Asus P5A also seriously messes up pci-ids, there is nothing
dependable there, so people who want to use flashrom on this board
should use -m asus:p5a
but it works :)
This is a board i own myself and this has been tested successfully.
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.
Right now, I start laying down the infrastructure for the Windows
version of flashrom utility, i.e. the kernel mode driver and the very
basic user mode application. Because this version of flashrom will be
quite different in terms of code due to inherent differences between
Linux/other Unix and Windows, I think it's better to put it as a
"branch" of the flashrom directory. I'm still thinking about the way
to incorporate the flash chip and motherboard support in as seamless
way as possible so that every newer chip/motherboard support will be
merged easily. In the mean time I need the information on how to commit
the code once I have a tested version of the Winflashrom.
Anyway, I wonder how the qa (Quality Assurance / auto build, etc.)
system will handle a windows version source code :-? especially the
I added my new board to mainboards and successfully compile with
northbridge i855pm and i82801dbm southbridge.
After flashing and reboot I get beep beep beep 2 times per second.
And there is nothing to see on serial output.
I know, that the i855pm is not fully supported and I'm waiting for the
patches from Joe, but I thought the serial console may work without it.
Maybe someone is willing to check my config so far.
The most stuff is stolen from digitallogic/adl855pc directory.
It would be nice to get the serial console to work in the first step, so
I can see what is wrong with the other stuff.
I've uploaded a tar.gz to:
It is only 9K big ;)
Thank you for your help.
I do not get viruses because I do not use MS software.
If you use Outlook then please do not put my email address in your
address-book so that WHEN you get a virus it won't use my address in the
> 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.
Ken Fuchs <kfuchs(a)winternet.com> ami-mac-sun
We adapted LinuxBIOS for Broadcom Explosion based on Blast LinuxBIOS. It runs well in LinuxBIOS phase, but in Linux phase, there are some problems. It seems the hard disk can't be found. Anyone has the same problem? The attached is the log.
Best Regards <<explosion.log>>
丰立波 Feng Libo @ AMD Ext: 20906
Mobile Phone: 13683249071
Office Phone: 0086-010-62801406