Re: [LinuxBIOS] BIOS Saver RD1

[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&gt; ami-mac-sun

[LinuxBIOS] BIOS Saver RD1

[Ronald G. Minnich]

can somebody write Ken's excellent note up as a FAQ entry and get it on 
the web page? 

ron

[LinuxBIOS] BIOS Saver RD1

[Bari Ari]

Ronald G. Minnich wrote:
 can somebody write Ken's excellent note up as a FAQ entry and get
it on 
 the web page?
Done.

-Bari

[LinuxBIOS] BIOS Saver RD1

[yhlu]

You need split mess into two seperate thing
1. does flash_rom support your MB, some mb has gpio to disable the
flash write or last 64KiB
2. are you give dead bios savior.

ps. other thing about flash_rom
1. with 2.6 kernel 64 bit for amd8111 based MB, you can not install 4G
or more in CPU0.
2. with 2.6 kernel 64 bit for Nvidia ck804 based MB, you must install
4G or more in CPU0

solution is use 32 bit 2.6 or 2.4 32bit or 2.4 64 bit.
for case 1 you can command line: maxmem to limit mem to 4G less.

It seems last 4KiB near 4G can not be accessed. when read in Linux it
alreays show 0.

Andi may have some idea about it. maybe something related iommu...

YH


On 8/3/05, Ken Fuchs <kfuchs(a)winternet.com&gt; wrote:
 > 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&gt; ami-mac-sun
 
 _______________________________________________
 LinuxBIOS mailing list
 LinuxBIOS(a)openbios.org
 http://www.openbios.org/mailman/listinfo/linuxbios

[LinuxBIOS] BIOS Saver RD1

[Andi Kleen]

On Wed, Aug 03, 2005 at 09:50:49AM -0700, yhlu wrote:
 You need split mess into two seperate thing
 1. does flash_rom support your MB, some mb has gpio to disable the
 flash write or last 64KiB
 2. are you give dead bios savior.
 
 ps. other thing about flash_rom
 1. with 2.6 kernel 64 bit for amd8111 based MB, you can not install 4G
 or more in CPU0.
 2. with 2.6 kernel 64 bit for Nvidia ck804 based MB, you must install
 4G or more in CPU0
 
 solution is use 32 bit 2.6 or 2.4 32bit or 2.4 64 bit.
 for case 1 you can command line: maxmem to limit mem to 4G less.
 
 It seems last 4KiB near 4G can not be accessed. when read in Linux it
 alreays show 0.
 
 Andi may have some idea about it. maybe something related iommu...
IOMMU is not involved here. Me and Torsten looked at it some time ago
and we suspected a chipset issue because there was nothing obviously
special with the way that memory was mapped via /dev/mem.

-Andi

[LinuxBIOS] BIOS Saver RD1

[yhlu]

I believe, sometime the SB eat some byte...write to LPC.

YH

On 8/3/05, Andi Kleen <ak(a)suse.de&gt; wrote:
 On Wed, Aug 03, 2005 at 09:50:49AM -0700, yhlu wrote:
 > You need split mess into two seperate thing
 > 1. does flash_rom support your MB, some mb has gpio to disable the
 > flash write or last 64KiB
 > 2. are you give dead bios savior.
 >
 > ps. other thing about flash_rom
 > 1. with 2.6 kernel 64 bit for amd8111 based MB, you can not install 4G
 > or more in CPU0.
 > 2. with 2.6 kernel 64 bit for Nvidia ck804 based MB, you must install
 > 4G or more in CPU0
 >
 > solution is use 32 bit 2.6 or 2.4 32bit or 2.4 64 bit.
 > for case 1 you can command line: maxmem to limit mem to 4G less.
 >
 > It seems last 4KiB near 4G can not be accessed. when read in Linux it
 > alreays show 0.
 >
 > Andi may have some idea about it. maybe something related iommu...
 
 IOMMU is not involved here. Me and Torsten looked at it some time ago
 and we suspected a chipset issue because there was nothing obviously
 special with the way that memory was mapped via /dev/mem.
 
 -Andi

[LinuxBIOS] BIOS Saver RD1

[Torsten Duwe]

>>>> "yhlu" == yhlu  <yinghailu(a)gmail.com&gt;
writes:
    yhlu> I believe, sometime the SB eat some byte...write to LPC.  YH

> > ps. other thing about flash_rom > 1. with 2.6 kernel 64
bit for
> amd8111 based MB, you can not install 4G > or more in CPU0.  > 2. with
> 2.6 kernel 64 bit for Nvidia ck804 based MB, you must install > 4G or
> more in CPU0
But how is the (physical?) mapping of the LPC bus dependent on the amount of
memory installed? If it's neither MMU, nor IOMMU, nor MTRR, it must be the
chipset, as you suggest above!

	Torsten

[LinuxBIOS] BIOS Saver RD1

[yhlu]

why 32bit kernel  could work at any cases?

YH

On 8/4/05, Torsten Duwe <duwe(a)suse.de&gt; wrote:
 >>>>> "yhlu" == yhlu 
<yinghailu(a)gmail.com&gt; writes:
 
     yhlu> I believe, sometime the SB eat some byte...write to LPC.  YH
 
     >> > ps. other thing about flash_rom > 1. with 2.6 kernel 64 bit for
     >> amd8111 based MB, you can not install 4G > or more in CPU0.  > 2.
with
     >> 2.6 kernel 64 bit for Nvidia ck804 based MB, you must install > 4G or
     >> more in CPU0
 
 But how is the (physical?) mapping of the LPC bus dependent on the amount of
 memory installed? If it's neither MMU, nor IOMMU, nor MTRR, it must be the
 chipset, as you suggest above!
 
         Torsten

[LinuxBIOS] BIOS Saver RD1

[Andi Kleen]

On Thu, Aug 04, 2005 at 06:12:42PM -0700, yhlu wrote:
 why 32bit kernel  could work at any cases?
Does it really?

-Andi

[LinuxBIOS] BIOS Saver RD1

[yhlu]

Yes.

Sometime i suspect if ia32 emulation could cause problem. I will try
to disable that to test that.

YH

On 8/5/05, Andi Kleen <ak(a)suse.de&gt; wrote:
 On Thu, Aug 04, 2005 at 06:12:42PM -0700, yhlu wrote:
 > why 32bit kernel  could work at any cases?
 
 Does it really?
 
 -Andi

[LinuxBIOS] BIOS Saver RD1

[Andi Kleen]

On Fri, Aug 05, 2005 at 09:09:44AM -0700, yhlu wrote:
 Yes.
Ok that would wreck the chipset theory. 

 
 Sometime i suspect if ia32 emulation could cause problem. I will try
 to disable that to test that.
I doubt it has anything to do with it.

-Andi

[LinuxBIOS] BIOS Saver RD1

[yhlu]

I can not figure out why behavior in AMD SB and NV SB is different.
one need less 4G installed in CPU0, and the other need more than 4G
installed in CPU0.

YH

On 8/5/05, Andi Kleen <ak(a)suse.de&gt; wrote:
 On Fri, Aug 05, 2005 at 09:09:44AM -0700, yhlu wrote:
 > Yes.
 
 Ok that would wreck the chipset theory.
 
 >
 > Sometime i suspect if ia32 emulation could cause problem. I will try
 > to disable that to test that.
 
 I doubt it has anything to do with it.
 
 -Andi

[LinuxBIOS] BIOS Saver RD1

[Jeff Carr]

On 08/03/2005 08:27 AM, Ken Fuchs wrote:

 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.
The webpage that is linked rom the linuxbios FAQ says that it comes with
a USB cable. Are you able to control this device from Linux? It would be
a big hassle for me since I don't have any windows machines.

Thanks,
Jeff

[LinuxBIOS] BIOS Saver RD1

[Ken Fuchs]

 On 08/03/2005 08:27 AM, Ken Fuchs wrote:
 > 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.
Jeff Carr wrote:

 The webpage that is linked rom the linuxbios FAQ says that it 
 comes with a USB cable.
The USB cable is used to provide power only.  (I disconnect the USB
cable when inserting/removing a PLCC flash device, although the manual
doesn't mention this.  I just do it because it can't hurt and it might
be safer.)

The programmmer is controlled via a parallel port in EPP (Normal)
mode (This can checked/set in the COTS BIOS of most IBM PC
compatibles.)

 Are you able to control this device from Linux?
The Enhanced Willem Universal Programmer comes with a CD containing a
MS Windows program that shows how the DIP switches should be set for
any supported device.  Of course, this program also erases, writes &
verifies BIOS image files among other things.

 It would be a big hassle for me since I don't have any windows
 machines.
I use MS Windows 2000 for the (Willem) EPROM3 software.

Here's a web page that suggests that there is a remote chance that
EPROM3 might run on Linux via Wine:

http://www.sdconsult.no/linux/wine-doc/hardware-trace.html

Has anyone tried to run EPROM3 on Linux via Wine?

The Willem CD Readme.txt mentions "win98/me", so it might be easier to
just borrow a MS Windows machine or get one free (many people are
giving away Pentium II and even lower MHz Pentium III machines).

Sincerely,

Ken Fuchs <kfuchs(a)winternet.com&gt;

[LinuxBIOS] BIOS Saver RD1

[yhlu]

I hope I could get one with USB2 cable and it could work with Linux.

USB2 would be faster than others.

YH

On 8/12/05, Ken Fuchs <kfuchs(a)winternet.com&gt; wrote:
 > On 08/03/2005 08:27 AM, Ken Fuchs wrote:
 
 > > 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.
 
 Jeff Carr wrote:
 
 > The webpage that is linked rom the linuxbios FAQ says that it
 > comes with a USB cable.
 
 The USB cable is used to provide power only.  (I disconnect the USB
 cable when inserting/removing a PLCC flash device, although the manual
 doesn't mention this.  I just do it because it can't hurt and it might
 be safer.)
 
 The programmmer is controlled via a parallel port in EPP (Normal)
 mode (This can checked/set in the COTS BIOS of most IBM PC
 compatibles.)
 
 > Are you able to control this device from Linux?
 
 The Enhanced Willem Universal Programmer comes with a CD containing a
 MS Windows program that shows how the DIP switches should be set for
 any supported device.  Of course, this program also erases, writes &
 verifies BIOS image files among other things.
 
 > It would be a big hassle for me since I don't have any windows
 > machines.
 
 I use MS Windows 2000 for the (Willem) EPROM3 software.
 
 Here's a web page that suggests that there is a remote chance that
 EPROM3 might run on Linux via Wine:
 
 http://www.sdconsult.no/linux/wine-doc/hardware-trace.html
 
 Has anyone tried to run EPROM3 on Linux via Wine?
 
 The Willem CD Readme.txt mentions "win98/me", so it might be easier to
 just borrow a MS Windows machine or get one free (many people are
 giving away Pentium II and even lower MHz Pentium III machines).
 
 Sincerely,
 
 Ken Fuchs <kfuchs(a)winternet.com&gt;
 
 _______________________________________________
 LinuxBIOS mailing list
 LinuxBIOS(a)openbios.org
 http://www.openbios.org/mailman/listinfo/linuxbios

[LinuxBIOS] BIOS Saver RD1

[Richard Smith]

On 8/12/05, yhlu <yinghailu(a)gmail.com&gt; wrote:
 I hope I could get one with USB2 cable and it could work with Linux.
 
 USB2 would be faster than others.
I don't think it matters.  Your bottleneck is not the bandwith to the
programmer but the time it takes for the flash part to write a byte or
block.  Flash writes are slow.

-- 
Richard A. Smith

[LinuxBIOS] BIOS Saver RD1

[yhlu]

you are right.

1. download image to burner buffer, NON USB need to 5s..., USB may only need 1s.
2. issue command to burn from buffer to flash. .... burner need 30s,
flash_rom need 10s.

YH

On 8/12/05, Richard Smith <smithbone(a)gmail.com&gt; wrote:
 On 8/12/05, yhlu <yinghailu(a)gmail.com&gt; wrote:
 > I hope I could get one with USB2 cable and it could work with Linux.
 >
 > USB2 would be faster than others.
 
 I don't think it matters.  Your bottleneck is not the bandwith to the
 programmer but the time it takes for the flash part to write a byte or
 block.  Flash writes are slow.
 
 --
 Richard A. Smith

[LinuxBIOS] BIOS Saver RD1

[Ken Fuchs]

Sorry, you are both wrong.  The USB cable is used _only_ for power.
All data goes through the parallel port.  It is a slow (5 minutes to
burn and 2 minutes to verify), cheap burner, but I have found it to be
extremely reliable.

I was talking about the Enhanced Willem Universal Programmer.
Perhaps, the two of you were talking about another, possibly
hypothetical flash programmer.

Disclaimer: I'm not using the newest Willem programmer, but I think
even the newest Willem programmer still uses USB only for power (They
include the option of an AC adapter that can be used instead of the
USB cable - an option my USB only powered, older unit lacks).  

YH wrote:  

 you are right.
 1. download image to burner buffer, NON USB need to 5s..., USB may
only
 need 1s.
 2. issue command to burn from buffer to flash. .... burner need 30s,
 flash_rom need 10s.
 On 8/12/05, yhlu <yinghailu(a)gmail.com&gt; wrote:
 > I hope I could get one with USB2 cable and it could work with
Linux.
 >
 > USB2 would be faster than others.
On 8/12/05, Richard Smith <smithbone(a)gmail.com&gt; wrote:

 I don't think it matters.  Your bottleneck is not the bandwith to
the
 programmer but the time it takes for the flash part to write a byte or
 block.  Flash writes are slow.
Sincerely,

Ken Fuchs <kfuchs(a)winternet.com&gt;

[LinuxBIOS] BIOS Saver RD1

[yhlu]

http://www.xeltek.com/home.php
http://www.xeltek.com/product.php?productid=16221  
It's about $549.00

but no Linux support.

Also there is some EEPROM emulator, then only about download time 1s.

YH

On 8/12/05, Ken Fuchs <kfuchs(a)winternet.com&gt; wrote:
 Sorry, you are both wrong.  The USB cable is used _only_ for power.
 All data goes through the parallel port.  It is a slow (5 minutes to
 burn and 2 minutes to verify), cheap burner, but I have found it to be
 extremely reliable.
 
 I was talking about the Enhanced Willem Universal Programmer.
 Perhaps, the two of you were talking about another, possibly
 hypothetical flash programmer.
 
 Disclaimer: I'm not using the newest Willem programmer, but I think
 even the newest Willem programmer still uses USB only for power (They
 include the option of an AC adapter that can be used instead of the
 USB cable - an option my USB only powered, older unit lacks).
 
 YH wrote:
 
 > you are right.
 
 > 1. download image to burner buffer, NON USB need to 5s..., USB may only
 > need 1s.
 > 2. issue command to burn from buffer to flash. .... burner need 30s,
 > flash_rom need 10s.
 
 > On 8/12/05, yhlu <yinghailu(a)gmail.com&gt; wrote:
 
 > > I hope I could get one with USB2 cable and it could work with Linux.
 > >
 > > USB2 would be faster than others.
 
 On 8/12/05, Richard Smith <smithbone(a)gmail.com&gt; wrote:
 
 > I don't think it matters.  Your bottleneck is not the bandwith to the
 > programmer but the time it takes for the flash part to write a byte or
 > block.  Flash writes are slow.
 
 Sincerely,
 
 Ken Fuchs <kfuchs(a)winternet.com&gt;
 
 _______________________________________________
 LinuxBIOS mailing list
 LinuxBIOS(a)openbios.org
 http://www.openbios.org/mailman/listinfo/linuxbios

[LinuxBIOS] BIOS Saver RD1

[Stefan Reinauer]

* yhlu <yinghailu(a)gmail.com&gt; [050812 21:28]:
 http://www.xeltek.com/home.php
 http://www.xeltek.com/product.php?productid=16221  
 It's about $549.00
 
 but no Linux support.
 
 Also there is some EEPROM emulator, then only about download time 1s.

Eyeteck had a bios simulator and debug card for little money on their
web page..

http://www.eyeteck.com/usbbios/eindex.htm

but they don't seem to exist anymore, or have temporary trouble.

it reads some chinese government error message now.. no idea what it
means

Stefan

[LinuxBIOS] BIOS Saver RD1

[yhlu]

The xeltek ISP Header + 280U can be used for in-system programming.

http://www.xeltek.com/pages.php?pageid=8

That could be useful, if your mb don't have flash socket and flash os
soldered in.

YH

On 8/12/05, Stefan Reinauer <stepan(a)openbios.org&gt; wrote:
 * yhlu <yinghailu(a)gmail.com&gt; [050812 21:28]:
 > http://www.xeltek.com/home.php
 > http://www.xeltek.com/product.php?productid=16221
 > It's about $549.00
 >
 > but no Linux support.
 >
 > Also there is some EEPROM emulator, then only about download time 1s.
 
 
 Eyeteck had a bios simulator and debug card for little money on their
 web page..
 
 http://www.eyeteck.com/usbbios/eindex.htm
 
 but they don't seem to exist anymore, or have temporary trouble.
 
 it reads some chinese government error message now.. no idea what it
 means
 
 Stefan

[LinuxBIOS] In System Flash Programming [Was: BIOS Saver RD1]

[Ken Fuchs]

YH wrote:

 The xeltek ISP Header + 280U can be used for in-system programming.
 
 http://www.xeltek.com/pages.php?pageid=8
 
 That could be useful, if your mb don't have flash socket and flash os
 soldered in.
This would require one or more (a lot of them for the Xeltek ISP
Header) headers on the mainboard.  I couldn't find any information
about the Xeltek ISP Header.  It seems like it might even work on an
Enhanced Willem Universal Programmer.  It would be simpler to have a
single larger header, if the Xeltec ISP Header (adapter) needs to be
detached while the mainboard is operating.  I'd really prefer
something that can remain attached while the mainboard is in
operation.

------

It would even be possible to use the JTAG connector to flash the
system BIOS.  All Opteron mainboards must include "JTAG" circuits, but
usually don't include the two JTAG headers.  Adding the headers is
quite easy.  An open source Opteron JTAG flash programmer is probably
won't happen any time soon, although it shouldn't be too difficult to
do.  Anyone aware of an open source JTAG flash programmer of any kind?

Sincerely,

Ken Fuchs <kfuchs(a)winternet.com&gt;

 On 8/12/05, Stefan Reinauer <stepan(a)openbios.org&gt; wrote:
 > * yhlu <yinghailu(a)gmail.com&gt; [050812 21:28]:
 > > http://www.xeltek.com/home.php
 > > http://www.xeltek.com/product.php?productid=16221
 > > It's about $549.00
 > >
 > > but no Linux support.
 > >
 > > Also there is some EEPROM emulator, then only about 
 download time 1s.
 > 
 > 
 > Eyeteck had a bios simulator and debug card for little 
 money on their
 > web page..
 > 
 > http://www.eyeteck.com/usbbios/eindex.htm
 > 
 > but they don't seem to exist anymore, or have temporary trouble.
 > 
 > it reads some chinese government error message now.. no idea what it
 > means
 > 
 > Stefan
 > 
 > 
 > 
 >
 
 _______________________________________________
 LinuxBIOS mailing list
 LinuxBIOS(a)openbios.org
 http://www.openbios.org/mailman/listinfo/linuxbios

[LinuxBIOS] In System Flash Programming [Was: BIOS Saver RD1]

[Jeff Carr]

On 08/15/2005 01:59 PM, Ken Fuchs wrote:
 YH wrote:
 
 
>The xeltek ISP Header + 280U can be used for in-system programming.
>
>http://www.xeltek.com/pages.php?pageid=8
>
>That could be useful, if your mb don't have flash socket and flash os
>soldered in.
That's great; I just added it to the FAQ. The hardware development tools
links currently in the FAQ might be better off right on the main page.
Anyone seriously interested in helping linuxbios is going to need some
of those tools.

 This would require one or more (a lot of them for the Xeltek ISP
 Header) headers on the mainboard.  I couldn't find any information
 about the Xeltek ISP Header.  It seems like it might even work on an
 Enhanced Willem Universal Programmer.  It would be simpler to have a
 single larger header, if the Xeltec ISP Header (adapter) needs to be
 detached while the mainboard is operating.  I'd really prefer
 something that can remain attached while the mainboard is in
 operation.
Ya, there are such things floating around. I've seen in circuit
programmers before; this xeltek one looks like it may be hard to use.

 It would even be possible to use the JTAG connector to flash the
 system BIOS.  All Opteron mainboards must include "JTAG" circuits, but
You don't say!

 usually don't include the two JTAG headers.  Adding the headers
is
 quite easy.
Hmmm. two headers? Interesting.

 An open source Opteron JTAG flash programmer is probably
 won't happen any time soon,
Holy (**& that's fantastic. It sure might happen soon! OK, I might be
getting ahead of myself. Are you sure the Opteron doesn't require a ITP
or similar debugging port? Or in other words: Can you single step/halt
the processor/dump registers using the JTAG port. Lets hope so;
otherwise you might not be able to do much via the JTAG port.

JTAG is a fantastic standard -- I'd expect it to be adopted for any new
chip entering the market.

 although it shouldn't be too difficult to
 do.  Anyone aware of an open source JTAG flash programmer of any kind?
Yes, there are at least two projects. I added a JTAG programming page to
the FAQ: http://linuxbios.org/index.php/JTAG/BSDL_Guide

So here are some questions then:

Do you know of any motherboards that leave the JTAG connections populated?

Do you have instructions for populating them on some motherboard I could
pick up?

Do you have links to the Opteron JTAG docs (these docs will tell you
what you can and can't do from the JTAG port)?

We will need the BSDL files for the Opteron. Now if only that was the
case for the Pentium M...

Have a nice day,
Jeff

Here is output of talking to a Xilinx FPGA & CPLD using a $25 jtag cable
from linux with all free software: (that's why everyone is switching to
JTAG -- cheaper manufacturing software/hardware costs)

jtag> cable parallel 0x378 DLC5
Initializing Xilinx DLC5 JTAG Parallel Cable III on parallel port at 0x378
jtag> detect
IR length: 14
Chain length: 2
Device Id: 00000101000001000110000010010011
  Manufacturer: Xilinx
  Unknown part!
Device Id: 00010001010000101000000010010011
  Manufacturer: Xilinx
  Part:         xc3s1000_ft256
  Stepping:     0
  Filename:     /usr/share/jtag/xilinx/xc3s1000_ft256/xc3s1000_ft256
chain.c(110) Part 0 without active instruction
chain.c(133) Part 0 without active instruction
chain.c(110) Part 0 without active instruction
jtag> instruction SAMPLE/PRELOAD
jtag> shift ir
chain.c(110) Part 0 without active instruction
jtag>

[LinuxBIOS] In System Flash Programming [Was: BIOS Saver RD1]

[Peter Stuge]

On Mon, Aug 15, 2005 at 05:04:23PM -0700, Jeff Carr wrote:
 >>The xeltek ISP Header + 280U can be used for in-system
 >>programming.
 >>
 >>http://www.xeltek.com/pages.php?pageid=8
I like how the 280U and 580U look.

I just sent Xeltek an email asking if they would be interested in
releasing specs for the USB communication, and offered to write Linux
software supporting their products.


//Peter

[LinuxBIOS] In System Flash Programming [Was: BIOS Saver RD1]

[Jeff Carr]

On 08/15/2005 05:42 PM, Peter Stuge wrote:
 On Mon, Aug 15, 2005 at 05:04:23PM -0700, Jeff Carr wrote:
 
>>>The xeltek ISP Header + 280U can be used for in-system
>>>programming.
>>>
>>>http://www.xeltek.com/pages.php?pageid=8
 
 I like how the 280U and 580U look.
 
 I just sent Xeltek an email asking if they would be interested in
 releasing specs for the USB communication, and offered to write Linux
 software supporting their products.
Excellent; goodluck!

We need to dig up some old hat's in this arena. See if we can find a
lead on better in-socket options. The adapters for in socket programming
are rare and expensive I think (not lots of demand for that kind of
thing). For some chips, that's just going to be the only way things can
go of course.

Anyone care to estimate the percentage of socketed vs. non-socketed
BIOS's in the world's x86 machines shipped since 1990? since 2000?

Jeff

[LinuxBIOS] In System Flash Programming [Was: BIOS Saver RD1]

[Frieder Ferlemann]

Peter Stuge wrote:
 On Mon, Aug 15, 2005 at 05:04:23PM -0700, Jeff Carr wrote:
>>>The xeltek ISP Header + 280U can be used for in-system
>>>programming.
>>>
>>>http://www.xeltek.com/pages.php?pageid=8
 
 I like how the 280U and 580U look.
 
 I just sent Xeltek an email asking if they would be interested in
 releasing specs for the USB communication, and offered to write Linux
 software supporting their products.
Hi,

it seems that conitec had an alpha version of linux software
for their GALEP programmer.

http://www.conitec.net/english/software.htm

Greetings,

Frieder

[LinuxBIOS] In System Flash Programming [Was: BIOS Saver RD1]

[Peter Stuge]

On Tue, Aug 16, 2005 at 08:46:12AM +0200, Frieder Ferlemann wrote:
 it seems that conitec had an alpha version of linux software
 for their GALEP programmer.
It looks nice, now if it only came with a USB connector instead of
the parallell..


//Peter

[LinuxBIOS] In System Flash Programming [Was: BIOS Saver RD1]

[Ken Fuchs]

 Ken Fuchs wrote:
 > It would even be possible to use the JTAG connector to flash
the
 > system BIOS.  All Opteron mainboards must include "JTAG" 
 > circuits, but
Jeff Carr wrote:

 You don't say!
Yes, AMD requires all Opteron (probably uniprocessor AMD64 too)
mainboards have the "JTAG" debugging circuits so AMD's Hardware Debug
Tool (HDT - requies a host with MS Windows 2000/XP & NDA) will run on
them.  Any Opteron mainboard without "JTAG" circuits would have to be
developed without AMD's support, so such mainboards probably don't
exist.

 > usually don't include the two JTAG headers.  Adding the
headers is
 > quite easy.
 Hmmm. two headers? Interesting.
Yes, one per Opteron processor.  Obviously only one would be needed to
flash the BIOS.

 > An open source Opteron JTAG flash programmer probably
 > won't happen any time soon,
Sorry, I was just being pessimistic here.  I'm not even sure the
Opteron JTAG chains support flashing the BIOS device, but I would be
surprised if it didn't.

 Holy (**& that's fantastic. It sure might happen soon! OK, I
might be
 getting ahead of myself. Are you sure the Opteron doesn't 
 require a ITP
 or similar debugging port? Or in other words: Can you single step/halt
 the processor/dump registers using the JTAG port. Lets hope so;
 otherwise you might not be able to do much via the JTAG port.
AMD requires a special JTAG port be used for the Opteron (AMD64).  The
AMD64 JTAG header is 2x13 with 0.05" spacing between pins.

The HDT software running on a MS Windows 2000/XP host can be used to
single step/halt the processor, dump registers and a whole lot more.

The American Arium ECM-50 can be attached using an Opteron Personality
Module via the JTAG (HDT) port.  Provides nice source level debugging.

 JTAG is a fantastic standard -- I'd expect it to be adopted 
 for any new chip entering the market.
It has been used for several years, AFAIK.

 > although it shouldn't be too difficult to do.  Anyone aware
of
 > an open source JTAG flash programmer of any kind?
 Yes, there are at least two projects. I added a JTAG programming
 page to the FAQ: http://linuxbios.org/index.php/JTAG/BSDL_Guide
Thank you!

Macraigor Systems produces and sells the Raven or OCDemon device that
is required to attach to the AMD Opteron JTAG.  They also have GNU
software that allows one to use their OCD adapters (Raven & OCDemon):

http://www.macraigor.com/full_gnu.htm

 So here are some questions then:
 Do you know of any motherboards that leave the JTAG 
 connections populated?
I don't think any motherboards include JTAG headers, except possibly
Reference Design mainboards produced by chipset makers to demonstate
their chipsets to mainboard manufacturers.  However, even my nVidia
CK8-04 CRB mainboard did not come with JTAG headers.  However, the
toggle switch that enables JTAG access to one or both CPUs was
included.  Those 2x13 .05" headers must be expensive.

 Do you have instructions for populating them on some 
 motherboard I could pick up?
There are only two 2x13 .05" pads for the headers, so it should be
easy to see where they.  If the headers are keyed (have a missing
pin), one may need to look at the mainboard schematic to get the right
orientation.  You would need that in any case to get the ribbon cables
attached to the header with the proper orientation.

 Do you have links to the Opteron JTAG docs (these docs will tell you
 what you can and can't do from the JTAG port)?
Clearly, the Opteron JTAG docs are available on the AMD NDA web site,
but I suspect that the more basic JTAG information is available
without need for an NDA from 

 We will need the BSDL files for the Opteron. Now if only that was
the
 case for the Pentium M...
The closest I could find was BSDL files for K6:

http://www.amd.com/epd/designing/tsdocs/3.bsdfiles/

Maybe, if the right person nicely asks the right person at AMD, they
would provide the BSDL files for the Opteron.  Couldn't hurt to try.

Sincerely,

Ken Fuchs <kfuchs(a)winternet.com&gt;

[LinuxBIOS] BIOS Saver RD1

[Richard Smith]

On 8/12/05, yhlu <yinghailu(a)gmail.com&gt; wrote:
 you are right.

 1. download image to burner buffer, NON USB need to 5s..., USB may only need 1s.
 2. issue command to burn from buffer to flash. .... burner need 30s,
 flash_rom need 10s.
Ok.. So its the _device_ then thats non-optimal.  A usb2 device may or
may not be of any use.

We have a Batronix USB programmer.  It has a windows only interface
that really sucks.

I've been toying with writing a python cli for it.  Looking at the
windows program its obvious that the device downloads its frimware.
Each chip that is supported has its own firmware.  I've done a little
bit of looking and its some sort of EZ-usb setup.

I've haven't had the motivation but since you are asking about one I
will go back this weekend and look at harder.

If I can get some sort of cli for the batronix device it would be
really sweet.  Its a good little programmer but it just suffers from a
horrible software interface.  In fact, I've yet to use a  programmer
yet that I thought had interface worth a damn.

-- 
Richard A. Smith

[LinuxBIOS] BIOS Saver RD1

[Richard Smith]

On 8/12/05, Ken Fuchs <kfuchs(a)winternet.com&gt; wrote:

 Sorry, you are both wrong.  The USB cable is used _only_ for power.
 All data goes through the parallel port.  It is a slow (5 minutes to
 burn and 2 minutes to verify), cheap burner, but I have found it to be
 extremely reliable.
I was refering to any usb programmer. USB 1 can do 12Mbps. or roughly
a 1MB/s but you can't program a flash at that rate.  So you ether
download the contents into the programmer or the programmer polls for
when the device is ready to accept the next byte.  In a polling setup
a USB 2.0 device my be just as slow a parallel port device because its
not the transport thats the problem.  Its the implementation.

USB 2 devices however by virtue of being newer may indeed be faster
but its not ncecssarly  because they are USB 2.

-- 
Richard A. Smith

[LinuxBIOS] No known linux compatable BIOS programmer ?

[Jeff Carr]

On 08/12/2005 12:19 PM, Ken Fuchs wrote:
 Sorry, you are both wrong.  The USB cable is used _only_ for power.
 All data goes through the parallel port.  It is a slow (5 minutes to
 burn and 2 minutes to verify), cheap burner, but I have found it to be
 extremely reliable.
 
 I was talking about the Enhanced Willem Universal Programmer.
 Perhaps, the two of you were talking about another, possibly
 hypothetical flash programmer.
Just to verify once again, there is no known linux bios programmer?

What about programming the chips in socket from within Linux; yes risky,
but this does work right? The reason I ask is because that means that we
do know *HOW* to program them, we just don't have an external device to
do it.

I guess this is just another project to start with a bunch of people
that know how to program fpga's.


Thanks for everyone's feedback to me as a new person here.

Jeff
BTW: you might be able to speed up the programming of the chip if you do
it in burst mode. Lots of NOR flash chips support this. Are PC bios
chips usually NOR or NAND or something else all together? The code I saw
for the M-Systems chip in my machine looked like it was doing the
classic NOR state machine triggers (write 0xAAA, 0x555, etc). So I'm
guessing they are more like NOR than NAND. NAND would suck anyway
because it's not very reliable. Using NAND would be insanely stupid! (IMHO)

[LinuxBIOS] RD1 BIOS Savior [was Re: No known linux compatable BIOS programmer ?]

[Ken Fuchs]

On 08/12/2005 12:19 PM, Ken Fuchs wrote:
> Sorry, you are both wrong.  The USB cable is used _only_ for
power.
> All data goes through the parallel port.  It is a slow (5 minutes to
> burn and 2 minutes to verify), cheap burner, but I have found it to be
> extremely reliable.
> 
> I was talking about the Enhanced Willem Universal Programmer.
> Perhaps, the two of you were talking about another, possibly
> hypothetical flash programmer.
Jeff Carr wrote:

Just to verify once again, there is no known linux bios programmer?
I don't know of any, but I haven't looked beyond the Enhanced Willem
Universal Programmer and its MS Windows program.

What about programming the chips in socket from within Linux; yes
risky,
but this does work right? The reason I ask is because that means that we
do know *HOW* to program them, we just don't have an external device to
do it.
The RD1 BIOS Savior is what you need to make this a safe operation.
It adds a second flash (BIOS) device that works as a backup, once it is
successfully programmed.  It is installed in the BIOS socket and the
original BIOS chip is installed into it.  There is a pair of wire going
from the RD1 BIOS Savior to a sliding switch that mounts into the
provided slot cover.  In the ORG position, the original BIOS is active
and in the RD1 position, the RD1's BIOS device is active.  I used one
successfully on a Tyan S2885 system.

First copy the original BIOS to a file.  Next, boot in the ORG
position.  Move the switch to the RD1 position and flash the original
BIOS image to the RD1 flash device.  Test booting the RD1 flash device.
Repeat the last two steps until the RD1 flash device boots OK.  Now,
flash all development BIOS images to the original BIOS device which is
usually a higher quality device.  The RD1 BIOS image can be used in case
of a bad development BIOS image that doesn't boot.

Sincerely,

Ken Fuchs <kfuchs(a)winternet.com&gt;

[LinuxBIOS] RD1 BIOS Savior [was Re: No known linux compatable BIOS programmer ?]

[Jeff Carr]

On 08/12/2005 10:47 PM, Ken Fuchs wrote:

>Just to verify once again, there is no known linux bios
programmer?
 
 I don't know of any, but I haven't looked beyond the Enhanced Willem
 Universal Programmer and its MS Windows program.
OK. I'll put that on my todo list of things to look for.

 The RD1 BIOS Savior is what you need to make this a safe operation.
 It adds a second flash (BIOS) device that works as a backup, once it is
 successfully programmed.  It is installed in the BIOS socket and the
 original BIOS chip is installed into it.  There is a pair of wire going
 from the RD1 BIOS Savior to a sliding switch that mounts into the
 provided slot cover.  In the ORG position, the original BIOS is active
 and in the RD1 position, the RD1's BIOS device is active.  I used one
 successfully on a Tyan S2885 system.
Yes, that's an essential tool.

 First copy the original BIOS to a file.
I'm still having problems with this. I haven't been able to convince
linux's mtd drivers to do this. I've tried many things so far to try to
save the BIOS to a file from within linux. Maybe this is also not what
people normally do.

I see the instructions in the wiki for pulling out the VIDEO BIOS.
Please tell me this is a standard in the PC world and we can just use
the video bios to init the video chip and wrap linuxbios around it. That
would be fantastic! Programming the video chips is going to be extremely
unlikely/impossible in most cases.
(linux-2.6.12.2/Documentation/power/video.txt is interesting reading)

I dumped my vgabios without a hitch:
root@jcarr:/home# dd if=/dev/mem of=vgabios.bin count=1 bs=64K skip=12
1+0 records in
1+0 records out
65536 bytes transferred in 0.012833 seconds (5106847 bytes/sec)
root@jcarr:/home# strings vgabios.bin |grep "ATI Tech"
(C) 1988-2003, ATI Technologies Inc. BK-ATI VER008.017M.097.000

I'm very surprised to have that work. Thats great though! I wonder how
that works. Can't the iomem window be expanded to show the whole bios
image then? Then it would be really really trivial to save your bios
image as a file! All you'd have to use is dd!

Anyway, I don't understand enough to know how this is being done. I
assume the BIOS is hooked up to the host bridge chip somehow. Or perhaps
it goes through ACPI somehow? I don't know how to figure out how the
kernel finds & maps the video bios. It seems to happen early on in the
boot process arch/i368/setup.c just hard codes an entry for it:

static struct resource video_rom_resource = {
        .name   = "Video ROM",
        .start  = 0xc0000,
        .end    = 0xc7fff,
        .flags  = IORESOURCE_BUSY | IORESOURCE_READONLY | IORESOURCE_MEM
};

Man, not a lot to go on there. I guess if it was possible to just memory
map the whole BIOS someone would have done that by now.

Is there a standard place that the videobios is stored in the bios flash?

Sorry about the rambling, it's been a long day of experiements. I got
annoyed about the changing location and size of the video bios so I made
the attached perl script to pull it out.
Jeff
BTW: strings vgabios.bin on my machine showed "pbd47ev.sab" which seemed
suspiciously like a DOS filename. google revealed SAB as a standard ASIC
file format. Makes me wonder what kind of software ATI uses to do their
ASIC designs.

[LinuxBIOS] RD1 BIOS Savior [was Re: No known linux compatable BIOS programmer ?]

[Paul Millar]

On Sunday 14 Aug 2005 10:26, Jeff Carr wrote:
 On 08/12/2005 10:47 PM, Ken Fuchs wrote:
 > I don't know of any, but I haven't looked beyond the Enhanced Willem
 > Universal Programmer and its MS Windows program.

 OK. I'll put that on my todo list of things to look for.
I have some user-land software for getting the Willem board working under 
Linux.

Back a little while back (while an impoverished student), I decided it was the 
best available burner that had publicly available schematics and PCB layout, 
so built it, planning on writing the software myself. (first PCB project, it 
was a miracle it worked :)

I wrote some software that handles some 27cxx chips (read, write, ...), but 
the code's written so it should be fairly easy to add support for other 
chips.

From the posts, I figured others might want the software too, so spend some of 
last weekend finishing off porting the software to using Linux's ppdev 
(rather than hitting the parallel port directly).  I got most of the way 
there (just some timing issues left) before my 5v regulator died.

So, I have some non-functional (but hopefully not too far off) software.  I 
hope to have the regulator fixed today, so should be able to hunt down the 
remaining bugs soon.

Would people be interested, either in the software or in helping improve it?

Cheers,

Paul.

[LinuxBIOS] RD1 BIOS Savior [was Re: No known linux compatable BIOS programmer ?]

[Jeff Carr]

On 08/15/05 02:56, Paul Millar wrote:

 I have some user-land software for getting the Willem board working
 under Linux.
Sweet.

 Back a little while back (while an impoverished student), I decided 
 it was the best available burner that had publicly available
 schematics and PCB layout, so built it, planning on writing the
 software myself. (first PCB project, it was a miracle it worked :)
Cool.

 Would people be interested, either in the software or in helping 
 improve it?
I would. You said you built your own device, but I'm not a poor student
(anymore). Could you guess which of the three on the mcmull page:
http://www.mcumall.com/comersus/store/comersus_dynamicIndex.asp
would be the closest to the schematic you used?

I'd certainly be willing to make a go of it. If I can dig it up, there
were some guys that wrote a parallel jtag interface to program amd
flash. Maybe it would be useful. That was several years ago and the site
seems lost in the annals of history now. Maybe you wrote that too :)

Jeff

[LinuxBIOS] RD1 BIOS Savior [was Re: No known linux compatable BIOS programmer ?]

[Paul Millar]

On Monday 15 Aug 2005 14:23, Jeff Carr wrote:
 On 08/15/05 02:56, Paul Millar wrote:
 > Would people be interested, either in the software or in helping
 > improve it?

 I would. You said you built your own device, but I'm not a poor student
 (anymore). Could you guess which of the three on the mcmull page:
 http://www.mcumall.com/comersus/store/comersus_dynamicIndex.asp
 would be the closest to the schematic you used?
(three?  only two on that page that I could see ....)

The closest is the "Dual Power Willem Universal EPROM Programmer".

This looks to be the same design: it has the same number of chips, in the same 
locations.  The image quality isn't good enough to say more.  Visually, the 
only difference between this one and mine is someone has mounted the linear 
regulator vertically to make space for the USB connected (just for its +5v 
line).  Obviously, without schematics for the card, I can't say for sure.

The Enhanced Willem board looks quite funky and claims to be backwards 
compatible with the previous design, but I can't find schematics for it, nor 
any reference to it on the Willem pages:
  http://www.willem.org/

I was thinking of getting one of these (not so much of a poor student 
anymore), but without the schematics, it wouldn't be so much use.

 I'd certainly be willing to make a go of it. If I can dig it up,
there
 were some guys that wrote a parallel jtag interface to program amd
 flash. Maybe it would be useful. That was several years ago and the site
 seems lost in the annals of history now. Maybe you wrote that too :)
Cool.  I'll stick the software somewhere useful.

Sadly, having fixed the regulator, I'm still stuck with the problem getting 
data off of the EPROM.  I've tested  the 4014 read circuitry (and software) 
by hot-wiring various EPROM-ZIF output bits to gnd or +5v and checking the 
output: this works correctly.  Addresses are clocked in OK.  Both /CE and /OE 
are low, yet the output is neither correct (well ... believable) nor 
consistent.

Ideas on how to debug this greatfully received.

Cheers,

Paul.

[LinuxBIOS] RD1 BIOS Savior [was Re: No known linux compatable BIOS programmer ?]

[Richard Smith]

 > I'd certainly be willing to make a go of it. If I can dig it
up, there
 > were some guys that wrote a parallel jtag interface to program amd
 > flash. Maybe it would be useful. That was several years ago and the site
 > seems lost in the annals of history now. Maybe you wrote that too :)
 
 Cool.  I'll stick the software somewhere useful.
If you are really up for a challenge that involves a bit of RE.  Then
let me sugggest the batronix
http://www.batronix.com/electronic/index.shtml programmer.

This weekend I spent some time working with it and linux.  The device
has a USB Cypress an2131s.  The device firmware is downloaded into the
device and linux has all the tools to do this.   I was able to build
and dowload and the usb-test code and it sort of worked.  I need to
code up a bit toggle and see if I can get that to happen and verify I
_really_ am running my firmware.  I've grabbed the datasheets off of
cypress's website and I have the example test code so this shouldn't
be too hard.

The unit is basically a bunch of latches and bus drivers that are all
on some sort of make shift address/data bus.  I beeped out a lot of
the connections to the latches and although it will be a lot of work
it looks workable to RE all the connections to the programming socket
and how to drive it.

Some USB sniffing software should also help me figure out a few
things.  Perhaps I can figure out how to  get it to work with the
firmware(s) that come with the doze software.

 Sadly, having fixed the regulator, I'm still stuck with the
problem getting
 data off of the EPROM.  I've tested  the 4014 read circuitry (and software)
 by hot-wiring various EPROM-ZIF output bits to gnd or +5v and checking the
 output: this works correctly.  Addresses are clocked in OK.  Both /CE and /OE
 are low, yet the output is neither correct (well ... believable) nor
 consistent.
In the past when we have blown up various things like this some of the
latches or bus drivers were also damaged.  They may appear to work but
fail when you load them real world.

When you toasted the regulator could you have overvoltaged Vcc?  If so
then every active part on there is suspect.

-- 
Richard A. Smith

[LinuxBIOS] RD1 BIOS Savior [was Re: No known linux compatable BIOS programmer ?]

[Jeremy Jackson]

Sorry to jump in a bit late here, but for parallel flash, what about
using a NIC with a boot ROM socket?  I've used that for both PLCC32 and
DIP32 parts.

Regards,

Jeremy

[LinuxBIOS] RD1 BIOS Savior [was Re: No known linux compatable BIOS programmer ?]

[Peter Stuge]

On Sat, Jun 02, 2007 at 03:29:08PM -0400, Jeremy Jackson wrote:
 Sorry to jump in a bit late here, but for parallel flash, what
 about using a NIC with a boot ROM socket?  I've used that for both
 PLCC32 and DIP32 parts.
You mean for salvaging flash parts? They're usually small. 128kb.

The flash chip on those cards isn't reachable until after PCI init
has set an address for it so it's not that handy for booting.

Sorry - what are you suggesting? :)


//Peter

[LinuxBIOS] RD1 BIOS Savior [was Re: No known linux compatable BIOS programmer ?]

[Luc Verhaegen]

On Mon, Jun 04, 2007 at 05:39:37PM +0200, Peter Stuge wrote:
 On Sat, Jun 02, 2007 at 03:29:08PM -0400, Jeremy Jackson wrote:
 > Sorry to jump in a bit late here, but for parallel flash, what
 > about using a NIC with a boot ROM socket?  I've used that for both
 > PLCC32 and DIP32 parts.
 
 You mean for salvaging flash parts? They're usually small. 128kb.
 
 The flash chip on those cards isn't reachable until after PCI init
 has set an address for it so it's not that handy for booting.
 
 Sorry - what are you suggesting? :)
 
 
 //Peter
Well, this is just for flashrom i think, you only tend to run flashrom 
when running an operating system :)

This is a good idea, and somebody on irc recently brought it up (too?).  

ctflasher has some (oddly licensed) code to this end, and there is no 
need to copy this code, as the actual functionality is limited to 
knowing which BAR to use and what offset address. ctflasher and author 
should of course be mentioned for good measure.

Now, the code in there is for:
* via rhine
* 3com vortex
* those intel 100base cards
* those common realtek chips.

I currently have all but the intel cards, and these sadly all have DIP
roms, but this should be enough to get such an implementation started.

Also, uniflash has some code for some graphics cards. I sadly only have 
one graphics card with a PLCC flash, and i'm not sure if flashing 
through that is supported by the hardware, let alone me finding out how 
to pull it off. But i will hopefully, in time, be able to add support 
for many graphics cards.

If somebody wants to have a crack at implementing any of this before me, 
please, by all means, do, i have so many things piling up now that it 
ain't fun any more :)

Also, implementation wise, we might want flashrom to take in a pcitag 
for this sort of flashing to be enabled. This is a reasonably idiot 
proof solution as to not accidentally flash the wrong rom to the wrong 
place.

Luc Verhaegen.

[LinuxBIOS] RD1 BIOS Savior [was Re: No known linux compatable BIOS programmer ?]

[Peter Stuge]

On Mon, Jun 04, 2007 at 08:42:56PM +0200, Luc Verhaegen wrote:
 On Mon, Jun 04, 2007 at 05:39:37PM +0200, Peter Stuge wrote:
 > On Sat, Jun 02, 2007 at 03:29:08PM -0400, Jeremy Jackson wrote:
 > > Sorry to jump in a bit late here, but for parallel flash, what
 > > about using a NIC with a boot ROM socket?  I've used that for
 > > both PLCC32 and DIP32 parts.
 > 
 > Sorry - what are you suggesting? :)
 
 Well, this is just for flashrom i think, you only tend to run
 flashrom when running an operating system :)
 
 This is a good idea, and somebody on irc recently brought it up (too?).
Ah yes, for flashing chips! Great idea!


 ctflasher has some (oddly licensed) code to this end, and there is
 no need to copy this code, as the actual functionality is limited
 to knowing which BAR to use and what offset address. ctflasher and
 author should of course be mentioned for good measure.
 
 Now, the code in there is for:
 * via rhine
 * 3com vortex
 * those intel 100base cards
 * those common realtek chips.
A good start I think.


 Also, implementation wise, we might want flashrom to take in a
 pcitag for this sort of flashing to be enabled. This is a
 reasonably idiot proof solution as to not accidentally flash the
 wrong rom to the wrong place.
Mh. I would prefer to probe and do something sane by default.

Of course -w is always required to actually write.

For disambiguating if there are several PCI devices that could be
used to flash I think as you say -p is a good idea.

I guess the ISA bridge is one of them too.

flashrom should list the PCI devices it sees that can be used to
flash.


//Peter

[LinuxBIOS] RD1 BIOS Savior [was Re: No known linux compatable BIOS programmer ?]

[Luc Verhaegen]

On Tue, Jun 05, 2007 at 07:56:10PM +0200, Peter Stuge wrote:
 
 > Also, implementation wise, we might want flashrom to take in a
 > pcitag for this sort of flashing to be enabled. This is a
 > reasonably idiot proof solution as to not accidentally flash the
 > wrong rom to the wrong place.
 
 Mh. I would prefer to probe and do something sane by default.
 
 Of course -w is always required to actually write.
 
 For disambiguating if there are several PCI devices that could be
 used to flash I think as you say -p is a good idea.
 
 I guess the ISA bridge is one of them too.
 
 flashrom should list the PCI devices it sees that can be used to
 flash.

Well, my view is that the default behaviour should be to use the 
motherboard.

Yes, good idea, flashrom should list the possible devices:
-p without arguments could scan all pci devices and list the ones it can 
use and list the rom id.

When using -w, a pci tag argument should be required to avoid mistakes. 
-r with -p can happen if only one possible device is found.

Luc Verhaegen.

[LinuxBIOS] RD1 BIOS Savior [was Re: No known linux compatible BIOS programmer ?]

[Ken Fuchs]

Paul Millar wrote:

 I have some user-land software for getting the Willem board 
 working under Linux.
...
 Would people be interested, either in the software or in 
 helping improve it?
I would definitely use the software, help debug and improve it.

I currently have an MS Windows 2000 machine whose only purpose is the
run the EPROM3 software on the Enhanced Willem Universal Programmer
board.  I'd be very happy to dedicate that machine to Linux service
instead.

Sincerely,

Ken Fuchs <kfuchs(a)winternet.com&gt;

[LinuxBIOS] No known linux compatable BIOS programmer ?

[Peter Stuge]

On Fri, Aug 12, 2005 at 06:24:45PM -0700, Jeff Carr wrote:
 What about programming the chips in socket from within Linux; yes
 risky, but this does work right?
Yes, indeed. Many use this as primary means of testing.


 The reason I ask is because that means that we do know *HOW* to
 program them, we just don't have an external device to do it.
Right. But the programming sequence for flash memory is always in the
data sheet, and manufacturers have those on their web sites.


 I guess this is just another project to start with a bunch of
 people that know how to program fpga's.
Perhaps not even an FPGA is needed, I've made an EPROM toy out of a
USB PIC microcontroller and two 12-bit counters. Really simple. Not
too quick though, took a good few minutes to read the 256kb EPROM,
but that's probably because the USB microcontroller only does low
speed USB (8kbps) while it's newer sibling does full speed at 12Mbps.

The problem with making a universal programmer is that the device
pinout and voltage changes too often, and a production programmer
should program and verify at several different voltages. The pin
drivers need to be programmable and fast and preferably indifferent
of voltage, which isn't a very common combination. But sure, it would
be possible to make a small series of a rather limited programmer
(256kbyte to 4mbyte devices, only standardized pinout) for, say $200
retail, but then you might as well pay twice as much and get the
"real" deal..


 BTW: you might be able to speed up the programming of the chip if
 you do it in burst mode. Lots of NOR flash chips support this. Are
 PC bios chips usually NOR or NAND or something else all together?
 The code I saw for the M-Systems chip in my machine looked like it
 was doing the classic NOR state machine triggers (write 0xAAA,
 0x555, etc).
0xAA and 0x55 are part of a command sequence standardized by JEDEC
and used for just about all flash memory and even some EEPROMS. :)


 So I'm guessing they are more like NOR than NAND. NAND would
suck
 anyway because it's not very reliable. Using NAND would be insanely
 stupid! (IMHO)
My guess is that NAND is more common, at least in PCs.


//Peter

[LinuxBIOS] No known linux compatable BIOS programmer ?

[Adam Talbot]

I am using a top2005 USB based programmer. http://www.mcumall.com I have 
done over 100 flash's and had no problems with Linux bios and this 
programmer.
-Adam

----- Original Message ----- 
From: "Peter Stuge" <stuge-linuxbios(a)cdy.org&gt;
To: <LinuxBIOS(a)openbios.org&gt;
Sent: Saturday, August 13, 2005 5:30 AM
Subject: Re: [LinuxBIOS] No known linux compatable BIOS programmer ?


 On Fri, Aug 12, 2005 at 06:24:45PM -0700, Jeff Carr wrote:
> What about programming the chips in socket from within Linux; yes
> risky, but this does work right?

 Yes, indeed. Many use this as primary means of testing.


> The reason I ask is because that means that we do know *HOW* to
> program them, we just don't have an external device to do it.

 Right. But the programming sequence for flash memory is always in the
 data sheet, and manufacturers have those on their web sites.


> I guess this is just another project to start with a bunch of
> people that know how to program fpga's.

 Perhaps not even an FPGA is needed, I've made an EPROM toy out of a
 USB PIC microcontroller and two 12-bit counters. Really simple. Not
 too quick though, took a good few minutes to read the 256kb EPROM,
 but that's probably because the USB microcontroller only does low
 speed USB (8kbps) while it's newer sibling does full speed at 12Mbps.

 The problem with making a universal programmer is that the device
 pinout and voltage changes too often, and a production programmer
 should program and verify at several different voltages. The pin
 drivers need to be programmable and fast and preferably indifferent
 of voltage, which isn't a very common combination. But sure, it would
 be possible to make a small series of a rather limited programmer
 (256kbyte to 4mbyte devices, only standardized pinout) for, say $200
 retail, but then you might as well pay twice as much and get the
 "real" deal..


> BTW: you might be able to speed up the programming of the chip if
> you do it in burst mode. Lots of NOR flash chips support this. Are
> PC bios chips usually NOR or NAND or something else all together?
> The code I saw for the M-Systems chip in my machine looked like it
> was doing the classic NOR state machine triggers (write 0xAAA,
> 0x555, etc).

 0xAA and 0x55 are part of a command sequence standardized by JEDEC
 and used for just about all flash memory and even some EEPROMS. :)


> So I'm guessing they are more like NOR than NAND. NAND would suck
> anyway because it's not very reliable. Using NAND would be insanely
> stupid! (IMHO)

 My guess is that NAND is more common, at least in PCs.


 //Peter

 _______________________________________________
 LinuxBIOS mailing list
 LinuxBIOS(a)openbios.org
 http://www.openbios.org/mailman/listinfo/linuxbios

[LinuxBIOS] No known linux compatable BIOS programmer ?

[Jeff Carr]

On 08/14/05 21:51, Adam Talbot wrote:
 I am using a top2005 USB based programmer. http://www.mcumall.com I
have
 done over 100 flash's and had no problems with Linux bios and this
 programmer.
Just to clarify, are you saying that you have the top2005 sucessfully
hooked up to a linux machine? No windows machine? That would be great --
I'd order that one then.
Jeff

PS: If the mailing list admin could change the ______'s to just two __
then normal mail readers would not include the footer in a reply.

__
 
 
 _______________________________________________
 LinuxBIOS mailing list
 LinuxBIOS(a)openbios.org
 http://www.openbios.org/mailman/listinfo/linuxbios

[LinuxBIOS] No known linux compatable BIOS programmer ?

[Adam Talbot]

-Jeff
Have not tried the top2005 on a Linux system, the closest I have come is a 
windows box in VMware.
----- Original Message ----- 
From: "Jeff Carr" <jcarr(a)linuxmachines.com&gt;
To: "Adam Talbot" <talbotx(a)comcast.net&gt;
Cc: <LinuxBIOS(a)openbios.org&gt;
Sent: Sunday, August 14, 2005 11:55 PM
Subject: Re: [LinuxBIOS] No known linux compatable BIOS programmer ?


 On 08/14/05 21:51, Adam Talbot wrote:
> I am using a top2005 USB based programmer. http://www.mcumall.com I have
> done over 100 flash's and had no problems with Linux bios and this
> programmer.

 Just to clarify, are you saying that you have the top2005 sucessfully
 hooked up to a linux machine? No windows machine? That would be great --
 I'd order that one then.
 Jeff

 PS: If the mailing list admin could change the ______'s to just two __
 then normal mail readers would not include the footer in a reply.

 __
>
>
> _______________________________________________
> LinuxBIOS mailing list
> LinuxBIOS(a)openbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
>

[LinuxBIOS] No known linux compatable BIOS programmer ?

[Jeff Carr]

On 08/14/05 23:56, Adam Talbot wrote:

 Have not tried the top2005 on a Linux system, the closest I have come
is
 a windows box in VMware.

OK; thanks for the info. I'll try to get Paul's code to work first I think.

I haven't had a windows box for many years & I'd rather avoid ever
having one again!
Jeff