> 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
You should be right.
When I was testing that on Broadcom BLAST ref board: STAT and IDE
But on another MB (serverworks HT1000 based), IDE is working.
Maybe some magic bit in pci conf space need to set by option rom...
You could compare the pci conf dump between system bios and LinuxBIOS...
BTW, Can drop your funny signature in LinuxBIOS?
Please check the issue 41, I make K8 MB can be compiled, and It include
bus0/dev0 and fidvid change enhancement
Default is 1, and if it is 6, then amd8131 will be from 6, also
if it is 0, will assume ht chain only have one HT device...
Default is 0x20 --- mean do not use that, if it is 0, the
amd8111 will be dev0
Default is 1, so if HT_CHAIN_UNITID_BASE!=1, will only offset
unitid of SB CHAIN.
Deault is 0, if it is 1, will put sb chain on bus 0, even for
S2885 sb ht is on link2, it will put on bus0.
K8_SET_FIDVID in cache_as_ram_auto.c or auto.c
Fidvid change to sync the fid on 4 way or more system with different cpu
Put following sequence in your cache_as_ram_auto.c after ht is set.
please check init_cpus.c and fidvid.c and amd8111_early_ctrl.c for
Just FYI on the Geodes in case anyone missed them...
The AMD Geode dev site has a few handy utilities and tools for debugging
BIOS and driver settings.
Cyreg - Cyreg is a menu driven utility that displays memory, I/O and
PCI configuration space data. The menus are defined in a text file that
allows the user to easily modify each menu.
Loadreg - Loadreg is a command line utility that allows the user to read
or modify any I/O, memory, or PCI configuration space location. It is
ideally suited to modifying system registers via a batch file.
MCVAL - Mcval tests the state of the memory controller against known
values, as well as lists all supported processor speeds and their
associated memory controller register values.
Hello LB people,
First, a great thank for the quick boost I had from your project
in creating a special firmware for our project.
I've ported LB to a SC2200 based platform, NCG266 (you can see some
old photos at www.nano-system.com) The jump to the load just takes
a couple of secs instead of like a minute with the Insyde BIOS...
The LB base is svn ver 2171, I've got a 71K big patch for it.
How do I contribute it to LB tree?
Also during the learning and porting of LB, a couple of questions
Q1: The source code files often include source files again instead
of like building object modules that are later linked together.
Why something like this? It seems odd to me as an perhaps oldschool
Q2: Why does the LB project need a special compiler?
I've done numberous of firmware stuff and ordinary gnu tools have a
good job so far.
Must admit though that these hasn't been x86 which of course has it
special boot mode, but there exist "standard" tools for that as well.
(RPM package dev86 for example)
I was perhaps a bit optimistic when I thought the LB port should
take one week, it was more like one month :-)
But more documentation could help here a lot, or are there docs
outside of linuxbios.org I've missed? Any work in progress here
or can I contribute to it somehow?
mvh Per Hallsmark
I'm going to check in new cache_as_ram code. It is more solid and could
copy data from cache to ram. So we can pass some info from CAR stage to
I want to change the default value for CONFIG_LB_MEM_TOPK from 1024 to
So I don't need to change every Opteron MB Config.lb...
Let me know if is ok to you.
System BIOS or LinuxBIOS?
Did you base the code in the tree?
[mailto:email@example.com] On Behalf Of Jia Jianwei
Sent: Thursday, March 30, 2006 12:36 PM
Subject: [LinuxBIOS] broadcom HT1000 SATA PHY initializing
I'm porting BIOS on a AMD opteron system with broadcom HT2000 and HT1000
chipset. I meet a problem when initilizing SATA device of HT1000. The
PHY status(0x40)always return a disable status(04), whatever I did with
PHY reset ( set 0x48 bit 0 and clear it ). Can anyone give me some
Thanks in advance!
*** Disclaimer: This message may contain privileged and/or confidential
information. If you have received this e-mail in error or are not the
intended recipient, you may not use, copy, disseminate or distribute it;
do not open any attachments, delete it immediately from your system and
notify the sender promptly by e-mail that you have done so. Thank you.
linuxbios mailing list
Some change in src/cpu/amd/car...
From: Stefan Reinauer [mailto:firstname.lastname@example.org]
Sent: Friday, March 31, 2006 2:40 AM
To: Lu, Yinghai
Cc: Ronald G Minnich; Jason Schildt; linuxbios(a)linuxbios.org
Subject: Re: CONFIG_LB_MEM_TOPK
* Lu, Yinghai <yinghai.lu(a)amd.com> [060331 04:13]:
> I'm going to check in new cache_as_ram code. It is more solid and
> copy data from cache to ram. So we can pass some info from CAR stage
> RAM stage.
> I want to change the default value for CONFIG_LB_MEM_TOPK from 1024 to
> So I don't need to change every Opteron MB Config.lb...
> Let me know if is ok to you.
Let me know where we can review that code before you go ahead and check
it in. It's not in the issue tracker yet, is it?