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@winternet.com ami-mac-sun
can somebody write Ken's excellent note up as a FAQ entry and get it on the web page?
ron
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@winternet.com 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@winternet.com ami-mac-sun
LinuxBIOS mailing list LinuxBIOS@openbios.org http://www.openbios.org/mailman/listinfo/linuxbios
On Wed, Aug 03, 2005 at 09:50:49AM -0700, yhlu wrote:
You need split mess into two seperate thing
- 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
- 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
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
I believe, sometime the SB eat some byte...write to LPC.
YH
On 8/3/05, Andi Kleen ak@suse.de wrote:
On Wed, Aug 03, 2005 at 09:50:49AM -0700, yhlu wrote:
You need split mess into two seperate thing
- 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
- 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
"yhlu" == yhlu yinghailu@gmail.com 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
why 32bit kernel could work at any cases?
YH
On 8/4/05, Torsten Duwe duwe@suse.de wrote:
"yhlu" == yhlu yinghailu@gmail.com 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 CPU0But 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
On Thu, Aug 04, 2005 at 06:12:42PM -0700, yhlu wrote:
why 32bit kernel could work at any cases?
Does it really?
-Andi
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@suse.de 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
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@suse.de 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
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
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@winternet.com
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@winternet.com 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@winternet.com
LinuxBIOS mailing list LinuxBIOS@openbios.org http://www.openbios.org/mailman/listinfo/linuxbios
On 8/12/05, yhlu yinghailu@gmail.com 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.
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@gmail.com wrote:
On 8/12/05, yhlu yinghailu@gmail.com 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
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.
- 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@gmail.com 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@gmail.com 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@winternet.com
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@winternet.com 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.
- 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@gmail.com 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@gmail.com 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@winternet.com
LinuxBIOS mailing list LinuxBIOS@openbios.org http://www.openbios.org/mailman/listinfo/linuxbios
On 8/12/05, yhlu yinghailu@gmail.com wrote:
you are right.
- download image to burner buffer, NON USB need to 5s..., USB may only need 1s.
- 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.
On 8/12/05, Ken Fuchs kfuchs@winternet.com 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.
* yhlu yinghailu@gmail.com [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
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)
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@winternet.com
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
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.
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@openbios.org wrote:
- yhlu yinghailu@gmail.com [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
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@cdy.org To: LinuxBIOS@openbios.org 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@openbios.org http://www.openbios.org/mailman/listinfo/linuxbios
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@openbios.org http://www.openbios.org/mailman/listinfo/linuxbios
-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@linuxmachines.com To: "Adam Talbot" talbotx@comcast.net Cc: LinuxBIOS@openbios.org 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@openbios.org http://www.openbios.org/mailman/listinfo/linuxbios
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.
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
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
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@winternet.com
On 8/12/05, Stefan Reinauer stepan@openbios.org wrote:
- yhlu yinghailu@gmail.com [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@openbios.org http://www.openbios.org/mailman/listinfo/linuxbios
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@winternet.com
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>
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.
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
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.
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
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.
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
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
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@winternet.com
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.
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.
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
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
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.
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
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.
-
Adam Talbot -
Andi Kleen -
Bari Ari -
Frieder Ferlemann -
Jeff Carr -
Jeremy Jackson -
Ken Fuchs -
Luc Verhaegen -
Paul Millar -
Paul Millar -
Peter Stuge -
Richard Smith -
Ronald G. Minnich -
Stefan Reinauer -
Torsten Duwe -
yhlu