Hi
I bought an Gigabyte GA-M57SLI-S4 (rev 1.0) due to support in linuxbios. Since i am having a hard time getting the original bios running i would be happy to know if it is save to use the linuxbios for this board? I have pretty sound knowledge of computers and hardware, but haven't tried linuxbios yet.
Since i don't have an modern flash programmer (and this version of the gigabyte doesn't have a dual bios) i am afraid to "brick" this mainboard.
Since i can't use the gigabyte tools anymore once i have flashed linuxbios to this board. Is there a way back.
Thanks ST
* ST st@iss.tu-darmstadt.de [070312 11:58]:
Since i don't have an modern flash programmer (and this version of the gigabyte doesn't have a dual bios) i am afraid to "brick" this mainboard.
Does it have a socketed bios chip?
Since i can't use the gigabyte tools anymore once i have flashed linuxbios to this board. Is there a way back.
Yes. You can always use "flashrom" from the LinuxBIOS tree to flash back the proprietary BIOS (given you can still boot Linux ;)
Am Montag, 12. März 2007 12:23 schrieb Stefan Reinauer:
- ST st@iss.tu-darmstadt.de [070312 11:58]:
Since i don't have an modern flash programmer (and this version of the gigabyte doesn't have a dual bios) i am afraid to "brick" this mainboard.
Does it have a socketed bios chip?
No, it doesn't but it seems to me as if the place for a dual bios chip is printed but not used. It seems to be a serial chip since it has not so many pins. At first i really thought this MB had a dual bios :-(.
Yes. You can always use "flashrom" from the LinuxBIOS tree to flash back the proprietary BIOS (given you can still boot Linux ;)
Ok, that sounds good.
ST
On Mon, Mar 12, 2007 at 01:12:37PM +0100, ST wrote:
Am Montag, 12. März 2007 12:23 schrieb Stefan Reinauer:
- ST st@iss.tu-darmstadt.de [070312 11:58]:
Since i don't have an modern flash programmer (and this version of the gigabyte doesn't have a dual bios) i am afraid to "brick" this mainboard.
Does it have a socketed bios chip?
No, it doesn't but it seems to me as if the place for a dual bios chip is printed but not used. It seems to be a serial chip since it has not so many pins. At first i really thought this MB had a dual bios :-(.
Yes. You can always use "flashrom" from the LinuxBIOS tree to flash back the proprietary BIOS (given you can still boot Linux ;)
Ok, that sounds good.
Be careful. One you bricked the original BIOS you will _not_ be able to boot Linux (or a DOS disk or whatever), so you will _not_ be able to reflash the BIOS...
Uwe.
* Uwe Hermann uwe@hermann-uwe.de [070312 14:46]:
On Mon, Mar 12, 2007 at 01:12:37PM +0100, ST wrote:
Am Montag, 12. März 2007 12:23 schrieb Stefan Reinauer:
- ST st@iss.tu-darmstadt.de [070312 11:58]:
Since i don't have an modern flash programmer (and this version of the gigabyte doesn't have a dual bios) i am afraid to "brick" this mainboard.
Does it have a socketed bios chip?
No, it doesn't but it seems to me as if the place for a dual bios chip is printed but not used. It seems to be a serial chip since it has not so many pins. At first i really thought this MB had a dual bios :-(.
Yes. You can always use "flashrom" from the LinuxBIOS tree to flash back the proprietary BIOS (given you can still boot Linux ;)
Ok, that sounds good.
Be careful. One you bricked the original BIOS you will _not_ be able to boot Linux (or a DOS disk or whatever), so you will _not_ be able to reflash the BIOS...
According to this picture, some of the boards obviously have a bios socket. How can we find out where to get those instead of the soldered-only boards? http://pclab.pl/zdjecia/artykuly/pila/am2/gigabyte-ga-m57sli-s4/plyta-gora.j...
Stefan Reinauer schrieb:
According to this picture, some of the boards obviously have a bios socket. How can we find out where to get those instead of the soldered-only boards? http://pclab.pl/zdjecia/artykuly/pila/am2/gigabyte-ga-m57sli-s4/plyta-gora.j...
is it possible to just manually place a bios chip on the contacts of the dual bios , fix it with sello-tape and reflash it ? -- Q
On Mon, 12 Mar 2007 14:57:56 +0100 Stefan Reinauer stepan@coresystems.de wrote:
- Uwe Hermann uwe@hermann-uwe.de [070312 14:46]:
On Mon, Mar 12, 2007 at 01:12:37PM +0100, ST wrote:
Am Montag, 12. März 2007 12:23 schrieb Stefan Reinauer:
- ST st@iss.tu-darmstadt.de [070312 11:58]:
Since i don't have an modern flash programmer (and this version of the gigabyte doesn't have a dual bios) i am afraid to "brick" this mainboard.
Does it have a socketed bios chip?
No, it doesn't but it seems to me as if the place for a dual bios chip is printed but not used. It seems to be a serial chip since it has not so many pins. At first i really thought this MB had a dual bios :-(.
Yes. You can always use "flashrom" from the LinuxBIOS tree to flash back the proprietary BIOS (given you can still boot Linux ;)
Ok, that sounds good.
Be careful. One you bricked the original BIOS you will _not_ be able to boot Linux (or a DOS disk or whatever), so you will _not_ be able to reflash the BIOS...
According to this picture, some of the boards obviously have a bios socket. How can we find out where to get those instead of the soldered-only boards? http://pclab.pl/zdjecia/artykuly/pila/am2/gigabyte-ga-m57sli-s4/plyta-gora.j...
What are the means for recovering from faulty writes into SPI flash-chip? Chip is not socketed ;) Moreover, it is soldered.
On Mon, Mar 12, 2007 at 11:22:12PM +0800, Anton wrote:
According to this picture, some of the boards obviously have a bios socket. How can we find out where to get those instead of the soldered-only boards? http://pclab.pl/zdjecia/artykuly/pila/am2/gigabyte-ga-m57sli-s4/plyta-gora.j...
What are the means for recovering from faulty writes into SPI flash-chip? Chip is not socketed ;) Moreover, it is soldered.
De-solder the chip, and put a socket on it. Richard Smith helped me out with that, we now have one m57sli-s4 board with a socket instead of the soldered-on chip. Requires quite a bit of skill and some good equipment though (heat-pencil or heat-gun and a good soldering iron).
Thanks, Ward.
On 12.03.2007 16:29, Ward Vandewege wrote:
On Mon, Mar 12, 2007 at 11:22:12PM +0800, Anton wrote:
What are the means for recovering from faulty writes into SPI flash-chip? Chip is not socketed ;) Moreover, it is soldered.
De-solder the chip, and put a socket on it. Richard Smith helped me out with that, we now have one m57sli-s4 board with a socket instead of the soldered-on chip. Requires quite a bit of skill and some good equipment though (heat-pencil or heat-gun and a good soldering iron).
Anton wrote about SPI (SOIC) flash, not LPC/FWH (PLCC32) flash. Are there really matching sockets out there?
Regards, Carl-Daniel
On Mon, Mar 12, 2007 at 04:50:18PM +0100, Carl-Daniel Hailfinger wrote:
On 12.03.2007 16:29, Ward Vandewege wrote:
On Mon, Mar 12, 2007 at 11:22:12PM +0800, Anton wrote:
What are the means for recovering from faulty writes into SPI flash-chip? Chip is not socketed ;) Moreover, it is soldered.
De-solder the chip, and put a socket on it. Richard Smith helped me out with that, we now have one m57sli-s4 board with a socket instead of the soldered-on chip. Requires quite a bit of skill and some good equipment though (heat-pencil or heat-gun and a good soldering iron).
Anton wrote about SPI (SOIC) flash, not LPC/FWH (PLCC32) flash. Are there really matching sockets out there?
Yeah, sorry, my bad :( I was referring to LPC (PLCC32). I don't know anything about SPI.
Thanks, Ward.
On Mon, 12 Mar 2007 11:53:43 -0400 Ward Vandewege ward@gnu.org wrote:
On Mon, Mar 12, 2007 at 04:50:18PM +0100, Carl-Daniel Hailfinger wrote:
On 12.03.2007 16:29, Ward Vandewege wrote:
On Mon, Mar 12, 2007 at 11:22:12PM +0800, Anton wrote:
What are the means for recovering from faulty writes into SPI flash-chip? Chip is not socketed ;) Moreover, it is soldered.
De-solder the chip, and put a socket on it. Richard Smith helped me out with that, we now have one m57sli-s4 board with a socket instead of the soldered-on chip. Requires quite a bit of skill and some good equipment though (heat-pencil or heat-gun and a good soldering iron).
Anton wrote about SPI (SOIC) flash, not LPC/FWH (PLCC32) flash. Are there really matching sockets out there?
Yeah, sorry, my bad :( I was referring to LPC (PLCC32). I don't know anything about SPI.
O'k. Does anyone common w/ SPI flashing / BIOS Saviour tools out there?
On 12.03.2007 16:57, Anton wrote:
On Mon, 12 Mar 2007 11:53:43 -0400 Ward Vandewege ward@gnu.org wrote:
On Mon, Mar 12, 2007 at 04:50:18PM +0100, Carl-Daniel Hailfinger wrote:
On 12.03.2007 16:29, Ward Vandewege wrote:
On Mon, Mar 12, 2007 at 11:22:12PM +0800, Anton wrote:
What are the means for recovering from faulty writes into SPI flash-chip? Chip is not socketed ;) Moreover, it is soldered.
De-solder the chip, and put a socket on it. Richard Smith helped me out with that, we now have one m57sli-s4 board with a socket instead of the soldered-on chip. Requires quite a bit of skill and some good equipment though (heat-pencil or heat-gun and a good soldering iron).
Anton wrote about SPI (SOIC) flash, not LPC/FWH (PLCC32) flash. Are there really matching sockets out there?
Yeah, sorry, my bad :( I was referring to LPC (PLCC32). I don't know anything about SPI.
O'k. Does anyone common w/ SPI flashing / BIOS Saviour tools out there?
Easiest would be to desolder the CE# "chip enable" pin, connect it to high level, attach a SPI chip with known-good image on top of it and connect CE# of the new chip to the board.
Regards, Carl-Daniel
Carl-Daniel Hailfinger wrote:
Yeah, sorry, my bad :( I was referring to LPC (PLCC32). I don't know anything about SPI.
O'k. Does anyone common w/ SPI flashing / BIOS Saviour tools out there?
Easiest would be to desolder the CE# "chip enable" pin, connect it to high level, attach a SPI chip with known-good image on top of it and connect CE# of the new chip to the board.
Where is the LPC <-> SPI being done? Can the northbridge do both? If there is a additional chip (say like an EC) that does the LPC to SPI conversion then there might be a way to put that device into recovery mode where you can download new bits into the SPI flash.
Otherwise you just have to remove the SPI part device and add a SOIC to DIP socket and use a DIP part. SOIC sockets are a pain in the ass the use.
Or like Carl suggests. Lift the enable pin and wire up your own select system. Essentially the same as PLCC only less pins.
On Mon, 12 Mar 2007 13:30:23 -0400 Richard Smith smithbone@gmail.com wrote:
Where is the LPC <-> SPI being done? Can the northbridge do both? If there is a additional chip (say like an EC) that does the LPC to SPI conversion then there might be a way to put that device into recovery mode where you can download new bits into the SPI flash.
I can't say for sure - no schematic available. Yet.
Otherwise you just have to remove the SPI part device and add a SOIC to DIP socket and use a DIP part. SOIC sockets are a pain in the ass the use.
Or like Carl suggests. Lift the enable pin and wire up your own select system. Essentially the same as PLCC only less pins.
I've been thinking about the same solution as Carl-Daniel suggested. Just to verify once again, that it would work as planned.
Thanks.
On Mon, 12 Mar 2007 13:30:23 -0400 Richard Smith smithbone@gmail.com wrote:
Carl-Daniel Hailfinger wrote:
Yeah, sorry, my bad :( I was referring to LPC (PLCC32). I don't know anything about SPI.
O'k. Does anyone common w/ SPI flashing / BIOS Saviour tools out there?
Easiest would be to desolder the CE# "chip enable" pin, connect it to high level, attach a SPI chip with known-good image on top of it and connect CE# of the new chip to the board.
Where is the LPC <-> SPI being done? Can the northbridge do both? If there is a additional chip (say like an EC) that does the LPC to SPI conversion then there might be a way to put that device into recovery mode where you can download new bits into the SPI flash.
That sounds tricky. Can't find EC over here (this's casual desktop board).
Otherwise you just have to remove the SPI part device and add a SOIC to DIP socket and use a DIP part. SOIC sockets are a pain in the ass the use.
Or like Carl suggests. Lift the enable pin and wire up your own select system. Essentially the same as PLCC only less pins.
How to physically route signals is clear. Programming chip - my goal. Board is ICH7-based, flashrom doesn't detect chip (SST25LF080A). I'm stuck here...
On Tue, Mar 13, 2007 at 11:37:10PM +0800, Anton wrote:
How to physically route signals is clear. Programming chip - my goal. Board is ICH7-based, flashrom doesn't detect chip (SST25LF080A). I'm stuck here...
Try attached patch (haven't tested it, just a random guess)...
Uwe.
* Uwe Hermann uwe@hermann-uwe.de [070313 17:41]:
On Tue, Mar 13, 2007 at 11:37:10PM +0800, Anton wrote:
How to physically route signals is clear. Programming chip - my goal. Board is ICH7-based, flashrom doesn't detect chip (SST25LF080A). I'm stuck here...
Try attached patch (haven't tested it, just a random guess)...
That's an SPI flash, so I would guess using "olpcflash" as a basis might be a good idea.
Stefan
On Tue, 13 Mar 2007 19:06:54 +0100 Stefan Reinauer stepan@coresystems.de wrote:
- Uwe Hermann uwe@hermann-uwe.de [070313 17:41]:
On Tue, Mar 13, 2007 at 11:37:10PM +0800, Anton wrote:
How to physically route signals is clear. Programming chip - my goal. Board is ICH7-based, flashrom doesn't detect chip (SST25LF080A). I'm stuck here...
Try attached patch (haven't tested it, just a random guess)...
That's an SPI flash, so I would guess using "olpcflash" as a basis might be a good idea.
If I'm not mistaken olpcflash is Richard's domain - I remember his bricking / unbricking routines.
On Tue, Mar 13, 2007 at 07:06:54PM +0100, Stefan Reinauer wrote:
That's an SPI flash, so I would guess using "olpcflash" as a basis might be a good idea.
Not neccessarily (without looking further at olpcflash) because the ICH7 just decodes to SPI instead of LPC.
Software shouldn't know the difference between the two. Uwe's patch may well be enough to get it working! :)
//Peter
On Wed, 14 Mar 2007 06:31:16 +0100 Peter Stuge stuge-linuxbios@cdy.org wrote:
On Tue, Mar 13, 2007 at 07:06:54PM +0100, Stefan Reinauer wrote:
That's an SPI flash, so I would guess using "olpcflash" as a basis might be a good idea.
Not neccessarily (without looking further at olpcflash) because the ICH7 just decodes to SPI instead of LPC.
Software shouldn't know the difference between the two. Uwe's patch may well be enough to get it working! :)
Not enough.
Calibrating delay loop... Setting up microsecond timing loop 755M loops per second ok No LinuxBIOS table found. Warning: Unknown system. Flash detection will most likely fail. Trying Am29F040B, 512 KB probe_29f040b: id1 0xff, id2 0xff Trying Am29F016D, 2048 KB probe_29f040b: id1 0xff, id2 0xff Trying AE49F2008, 256 KB probe_jedec: id1 0xff, id2 0xff Trying At29C040A, 512 KB probe_jedec: id1 0xff, id2 0xff Trying Mx29f002, 256 KB probe_29f002: id1 0xff, id2 0xff Trying SST25LF080A, 1024 KB probe_jedec: id1 0x0, id2 0x0 Trying SST29EE020A, 256 KB probe_jedec: id1 0xff, id2 0xff Trying SST28SF040A, 512 KB probe_28sf040: id1 0xff, id2 0xff Trying SST39SF010A, 128 KB probe_jedec: id1 0xff, id2 0xff Trying SST39SF020A, 256 KB probe_jedec: id1 0xff, id2 0xff Trying SST39SF040, 512 KB probe_jedec: id1 0xff, id2 0xff Trying SST39VF020, 256 KB probe_jedec: id1 0xff, id2 0xff Trying SST49LF040B, 512 KB probe_jedec: id1 0xff, id2 0xff Trying SST49LF040, 512 KB probe_jedec: id1 0xff, id2 0xff Trying SST49LF020A, 256 KB probe_jedec: id1 0xff, id2 0xff Trying SST49LF080A, 1024 KB probe_jedec: id1 0x0, id2 0x0 Trying SST49LF002A/B, 256 KB probe_jedec: id1 0xff, id2 0xff Trying SST49LF003A/B, 384 KB probe_jedec: id1 0xff, id2 0xff Trying SST49LF004A/B, 512 KB probe_jedec: id1 0xff, id2 0xff Trying SST49LF008A, 1024 KB probe_jedec: id1 0x0, id2 0x0 Trying Pm49FL002, 256 KB probe_jedec: id1 0xff, id2 0xff Trying Pm49FL004, 512 KB probe_jedec: id1 0xff, id2 0xff Trying W29C011, 128 KB probe_jedec: id1 0xff, id2 0xff Trying W29C020C, 256 KB probe_jedec: id1 0xff, id2 0xff Trying W49F002U, 256 KB probe_jedec: id1 0xff, id2 0xff Trying W49V002A, 256 KB probe_jedec: id1 0xff, id2 0xff Trying W49V002FA, 256 KB probe_jedec: id1 0xff, id2 0xff Trying W39V040A, 512 KB probe_jedec: id1 0xff, id2 0xff Trying W39V040B, 512 KB probe_jedec: id1 0xff, id2 0xff Trying M29F040B, 512 KB probe_29f040b: id1 0xff, id2 0xff Trying M29F400BT, 512 KB probe_m29f400bt: id1 0xff, id2 0xff Trying 82802ab, 512 KB probe_82802ab: id1 0xff, id2 0xff Trying 82802ac, 1024 KB probe_82802ab: id1 0x0, id2 0x0 Trying F49B002UA, 256 KB probe_jedec: id1 0xff, id2 0xff Trying LHF00L04, 1024 KB probe_lhf00l04: id1 0x0, id2 0x0 Trying S29C51001T, 128 KB probe_jedec: id1 0xff, id2 0xff Trying S29C51002T, 256 KB probe_jedec: id1 0xff, id2 0xff Trying S29C51004T, 512 KB probe_jedec: id1 0xff, id2 0xff Trying S29C31004T, 512 KB probe_jedec: id1 0xff, id2 0xff No EEPROM/flash device found.
On Tue, Mar 13, 2007 at 11:37:10PM +0800, Anton wrote:
How to physically route signals is clear. Programming chip - my goal. Board is ICH7-based, flashrom doesn't detect chip (SST25LF080A). I'm stuck here...
ICH7 has SPI master for the flash.
There are functional straps for selecting whether to boot from SPI, PCI or LPC, it can also be controlled by bits 11:10 in register 3410. (I guess to boot from another source after a reset.)
That could be used to boot from SPI with factory BIOS first, to a simple program that resets the registers to boot from LPC or PCI, puts LinuxBIOS in place, and does a reset.
The PCI option is interesting.
http://download.intel.com/design/chipsets/datashts/30701302.pdf --8<-- page 289 Boot BIOS Straps (BBS): This field determines the destination of accesses to the BIOS memory range. The default values for these bits represent the strap values of GNT5#/GPIO17 (bit 11) and GNT4#/GPIO48 (bit 10) (active-high logic levels) at the rising edge of PWROK.
When PCI is selected, the top 16 MB of memory below 4 GB is accepted by the primary side of the PCI-to-PCI bridge and forwarded to the PCI bus. This allows systems with corrupted or unprogrammed flash to boot from a PCI device. The PCI-to-PCI bridge Memory Space Enable bit does not need to be set (nor any other bits) for these cycles to go to PCI. Note that BIOS decode range bits and the other BIOS protection bits have no effect when PCI is selected.
When SPI or LPC is selected, the range that is decoded is further qualified by other configuration bits described in the respective sections.
The value in this field can be overwritten by software as long as the BIOS Interface Lock-Down (bit 0) is not set. -->8--
There are several things to explore especially if you're handy with the soldering iron. If not you could investigate the LPC boot option and simply pressing a PLCC flash chip against the pads where it could be soldered. (Or am I confusing your board with another now?)
//Peter
Peter Stuge schrieb:
That could be used to boot from SPI with factory BIOS first, to a simple program that resets the registers to boot from LPC or PCI, puts LinuxBIOS in place, and does a reset.
The PCI option is interesting.
http://download.intel.com/design/chipsets/datashts/30701302.pdf
I put a note in the wiki (flashrom).
PCI. Note that BIOS decode range bits and the other BIOS protection bits have no effect when PCI is selected.
There are several things to explore especially if you're handy with the soldering iron. If not you could investigate the LPC boot option and simply pressing a PLCC flash chip against the pads where it could be soldered. (Or am I confusing your board with another now?)
there was talk about the Gigabyte 570SLI board with pads for DUAL BIOS. Would be interesting to know whether the secondary soldering pads are functional or not.
If booting from PCI expansion ROM can be made possible, it may be quite handy for some LinuxBIOS developers who like to fall back to manufacturer std BIOS without much hassle (unplug the PCI card). --Q
On Wed, Mar 14, 2007 at 07:44:27AM +0100, Quux wrote:
If booting from PCI expansion ROM can be made possible,
Not any expansion ROM. It just sends BIOS accesses to PCI instead of LPC or SPI. A special (but simple) PCI card would be required.
I don't know if this feature is common on most northbridges.
We have larger problems with Intel hardware unfortunately.
//Peter
Peter Stuge schrieb:
On Wed, Mar 14, 2007 at 07:44:27AM +0100, Quux wrote:
If booting from PCI expansion ROM can be made possible,
Not any expansion ROM. It just sends BIOS accesses to PCI instead of
LPC or SPI. A special (but simple) PCI card would be required.
I don't know if this feature is common on most northbridges.
this is where Altera CPLD DevKit MAXII comes into play ... http://www.buyaltera.com/scripts/partsearch.dll/partdetail?site=ALTERA;lang=...
other debugging functions can be implemented ... --Q
On Wed, Mar 14, 2007 at 08:45:51AM +0100, Quux wrote:
A special (but simple) PCI card would be required.
this is where Altera CPLD DevKit MAXII comes into play ... http://www.buyaltera.com/scripts/partsearch.dll/partdetail?site=ALTERA;lang=...
The same money gets me a http://www.xilinx.com/xlnx/xebiz/designResources/ip_product_details.jsp?key=...
which looks nice too, but doesn't have the PCI.
//Peter
Peter Stuge schrieb:
On Wed, Mar 14, 2007 at 08:45:51AM +0100, Quux wrote:
A special (but simple) PCI card would be required.
this is where Altera CPLD DevKit MAXII comes into play ... http://www.buyaltera.com/scripts/partsearch.dll/partdetail?site=ALTERA;lang=...
The same money gets me a http://www.xilinx.com/xlnx/xebiz/designResources/ip_product_details.jsp?key=...
which looks nice too, but doesn't have the PCI.
clearly some bang for the buck. The MAXII people unfortunately sell the avove at 150 USD worldwide, but for 250 EURO in europe (rohs version) since recently. quite a ripoff really. there is another PCI FPGA card from another manufacturer but no cheaper either. Using the SERR signal on PCI bus may allow to call a NMI like debugging routine. --Q
Peter Stuge wrote:
On Wed, Mar 14, 2007 at 08:45:51AM +0100, Quux wrote:
A special (but simple) PCI card would be required.
this is where Altera CPLD DevKit MAXII comes into play ... http://www.buyaltera.com/scripts/partsearch.dll/partdetail?site=ALTERA;lang=...
The same money gets me a http://www.xilinx.com/xlnx/xebiz/designResources/ip_product_details.jsp?key=...
Why don't we just make some adapters and use these to replace the BIOS Savers? These could be used to not only program LPC and SPI in circuit but also act as a Flash BIOS emulator using the DDR. Is $150 too expensive for anyone seriously interested in LinuxBIOS development?
-Bari
* Bari Ari bari@onelabs.com [070320 18:33]:
Why don't we just make some adapters and use these to replace the BIOS Savers? These could be used to not only program LPC and SPI in circuit but also act as a Flash BIOS emulator using the DDR. Is $150 too expensive for anyone seriously interested in LinuxBIOS development?
Not at all. The problem is if I start making the schematics, i will spend a lot more than 150$ before it works ;-), not counting the time.
Stefan
Stefan Reinauer wrote:
- Bari Ari bari@onelabs.com [070320 18:33]:
Why don't we just make some adapters and use these to replace the BIOS Savers? These could be used to not only program LPC and SPI in circuit but also act as a Flash BIOS emulator using the DDR. Is $150 too expensive for anyone seriously interested in LinuxBIOS development?
Not at all. The problem is if I start making the schematics, i will spend a lot more than 150$ before it works ;-), not counting the time.
Well, if I design the hardware adapters and have them available for cheap +$150 forth Xilinx board, will anyone else step up on the software side?
-Bari
does the $150 xilinx board come with full software to do that ? the altera has "free" soft going with it - and is a pci card. greetinx --Q
Bari Ari schrieb:
Stefan Reinauer wrote:
- Bari Ari bari@onelabs.com [070320 18:33]:
Why don't we just make some adapters and use these to replace the BIOS Savers? These could be used to not only program LPC and SPI in circuit but also act as a Flash BIOS emulator using the DDR. Is $150 too expensive for anyone seriously interested in LinuxBIOS development?
Not at all. The problem is if I start making the schematics, i will spend a lot more than 150$ before it works ;-), not counting the time.
Well, if I design the hardware adapters and have them available for cheap +$150 forth Xilinx board, will anyone else step up on the software side?
-Bari
Quux wrote:
does the $150 xilinx board come with full software to do that ? the altera has "free" soft going with it - and is a pci card. greetinx --Q
Both boards come with eval software. Either board would still need to have software written to be functional as a Flash programmer.
The Altera board only comes with 1MB (128Kx8) of SRAM. So memory would have to be added. This could be done via the prototype headers with a custom board.
The Xilinx board comes with 128 Mbit Parallel Flash, 16 Mbit SPI Flash and 64 MByte DDR SDRAM on board. It can be used to program Flash in or out of circuit and also be used to emulate Flash in circuit through the use of a few custom adapter cables. The Xilinx board seems to be more versatile.
-Bari
Bari Ari schrieb:
Quux wrote:
does the $150 xilinx board come with full software to do that ? the altera has "free" soft going with it - and is a pci card. greetinx --Q
Both boards come with eval software. Either board would still need to have software written to be functional as a Flash programmer.
The Altera board only comes with 1MB (128Kx8) of SRAM. So memory would have to be added. This could be done via the prototype headers with a custom board.
The Xilinx board comes with 128 Mbit Parallel Flash, 16 Mbit SPI Flash and 64 MByte DDR SDRAM on board. It can be used to program Flash in or out of circuit and also be used to emulate Flash in circuit through the use of a few custom adapter cables. The Xilinx board seems to be more versatile.
the xilinx looks nicer than the altera except the latter pas pci and also some example designs as pci expansion cards come with it. on the little patch area there may be just enough space for some small-outline memory like RAM, connector to plcc socket or such. --Q
Quux wrote:
the xilinx looks nicer than the altera except the latter pas pci and also some example designs as pci expansion cards come with it. on the little patch area there may be just enough space for some small-outline memory like RAM, connector to plcc socket or such. --Q
What advantage to you see with PCI over USB and Ethernet?
PCI is disappearing from desktop/server mainboards and was never on laptops except in the form of miniPCI.
USB and Ethernet is available on almost all desktop/server mainboards and laptops.
-Bari
Bari Ari schrieb:
Quux wrote:
the xilinx looks nicer than the altera except the latter pas pci and also some example designs as pci expansion cards come with it. on the little patch area there may be just enough space for some small-outline memory like RAM, connector to plcc socket or such. --Q
What advantage to you see with PCI over USB and Ethernet? PCI is disappearing from desktop/server mainboards and was never on laptops except in the form of miniPCI. USB and Ethernet is available on almost all desktop/server mainboards and laptops.
You can do memory mapped I/O which is fast and simple. Physics cards are mostly PCI cards for speed reasons. A hardware chess computer would best be done as pci card too, I guess. You could work towards hardware debugger capabilities using a compact NMI-Service Routine. for our purpose, both systems are eligible tho. --Q
* Bari Ari bari@onelabs.com [070321 14:24]:
Quux wrote:
the xilinx looks nicer than the altera except the latter pas pci and also some example designs as pci expansion cards come with it. on the little patch area there may be just enough space for some small-outline memory like RAM, connector to plcc socket or such. --Q
What advantage to you see with PCI over USB and Ethernet?
PCI is disappearing from desktop/server mainboards and was never on laptops except in the form of miniPCI.
USB and Ethernet is available on almost all desktop/server mainboards and laptops.
Yes, it should definitely be USB or Ethernet driven. PCI would mean I have to get another box to use it.
* Bari Ari bari@onelabs.com [070320 19:01]:
Stefan Reinauer wrote:
- Bari Ari bari@onelabs.com [070320 18:33]:
Why don't we just make some adapters and use these to replace the BIOS Savers? These could be used to not only program LPC and SPI in circuit but also act as a Flash BIOS emulator using the DDR. Is $150 too expensive for anyone seriously interested in LinuxBIOS development?
Not at all. The problem is if I start making the schematics, i will spend a lot more than 150$ before it works ;-), not counting the time.
Well, if I design the hardware adapters and have them available for cheap +$150 forth Xilinx board, will anyone else step up on the software side?
I'd definitely give it a try if someone comes up with a HW solution.
Does this require writing flash drivers in VHDL?
Stefan
Stefan Reinauer schrieb:
Not at all. The problem is if I start making the schematics, i will spend a lot more than 150$ before it works ;-), not counting the time.
Well, if I design the hardware adapters and have them available for cheap +$150 forth Xilinx board, will anyone else step up on the software side?
I'd definitely give it a try if someone comes up with a HW solution.
Does this require writing flash drivers in VHDL?
I guess the Xilinx has more features than the Altera CPLD. Whats the salient point there ? which example designs does it come with ? --Q
Stefan Reinauer wrote:
I'd definitely give it a try if someone comes up with a HW solution.
Does this require writing flash drivers in VHDL?
I can get some boards and make some adapters.
They include a XC3S500E-4FG320C FPGA with 500K logic gates.
It seems like we can use the PicoBlaze cpu core: http://www.xilinx.com/bvdocs/ipcenter/data_sheet/picoblaze_productbrief.pdf
The PicoBlaze instruction set can be found here: http://www.xilinx.com/bvdocs/userguides/ug129.pdf
There is a free C compiler found here: http://www.poderico.co.uk/
A simulator and assembler for the picoblaze, with a graphical user interface, and an assembler for the picoblaze, with a command line interface: http://www.xs4all.nl/~marksix/
KPicoSim is an IDE for the picoblaze microcontroller.KPicoSim is a development environment for the Xilinx PicoBlaze-3 soft-core processor for the KDE Desktop (Linux).The environment has an editor with syntax highlighting (based on the popular katepart), compiler, simulator and an export functions to VHDL, HEX and MEM files.
If it looks better to use a 32 bit cpu core and run uClinux we can use the MicroBlaze core. I'll have to see how well it fits into the 500K gates of the FPGA. http://www.xilinx.com/xlnx/xebiz/designResources/ip_product_details.jsp?key=...
uClinux for the MicroBlaze http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux/
FLASH drivers aren't too complicated. Having the board emulate flash is mostly done in hardware. Ethernet would require a tcp\ip stack. We have a choice between doing everything in C on an 8-bit micro or uClinux on a 32-bit cpu.
I have time do develop the hardware for this, but not much for software. I'll post all the schematics, regster info. and VHDL to the LinuxBIOS site. Let me know what everyone else thinks and prefers to use for the software end.
-Bari
is there a "standard" logic-analyzer design for this board like there is for some similar boards ? --Q
Bari Ari schrieb:
I can get some boards and make some adapters.
They include a XC3S500E-4FG320C FPGA with 500K logic gates.
It seems like we can use the PicoBlaze cpu core: http://www.xilinx.com/bvdocs/ipcenter/data_sheet/picoblaze_productbrief.pdf
The PicoBlaze instruction set can be found here: http://www.xilinx.com/bvdocs/userguides/ug129.pdf
There is a free C compiler found here: http://www.poderico.co.uk/
A simulator and assembler for the picoblaze, with a graphical user interface, and an assembler for the picoblaze, with a command line interface: http://www.xs4all.nl/~marksix/
KPicoSim is an IDE for the picoblaze microcontroller.KPicoSim is a development environment for the Xilinx PicoBlaze-3 soft-core processor for the KDE Desktop (Linux).The environment has an editor with syntax highlighting (based on the popular katepart), compiler, simulator and an export functions to VHDL, HEX and MEM files.
If it looks better to use a 32 bit cpu core and run uClinux we can use the MicroBlaze core. I'll have to see how well it fits into the 500K gates of the FPGA. http://www.xilinx.com/xlnx/xebiz/designResources/ip_product_details.jsp?key=...
uClinux for the MicroBlaze http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux/
FLASH drivers aren't too complicated. Having the board emulate flash is mostly done in hardware. Ethernet would require a tcp\ip stack. We have a choice between doing everything in C on an 8-bit micro or uClinux on a 32-bit cpu.
I have time do develop the hardware for this, but not much for software. I'll post all the schematics, regster info. and VHDL to the LinuxBIOS site. Let me know what everyone else thinks and prefers to use for the software end.
Quux wrote:
is there a "standard" logic-analyzer design for this board like there is for some similar boards ? --Q
Do you mean something like this: http://www.sump.org/projects/analyzer/
-Bari
this looks interesting, yes. gives it decent versatility. --Q
is there a "standard" logic-analyzer design for this board like there is for some similar boards ? --Q
Do you mean something like this: http://www.sump.org/projects/analyzer/
Carl-Daniel Hailfinger schrieb:
What are the means for recovering from faulty writes into SPI flash-chip? Chip is not socketed ;) Moreover, it is soldered.
what is the content of those SPI chips ? is that known ? (maybe dumb question) --Q
Quoting Ward Vandewege ward@gnu.org:
On Mon, Mar 12, 2007 at 11:22:12PM +0800, Anton wrote:
According to this picture, some of the boards obviously have a bios socket. How can we find out where to get those instead of the soldered-only boards?
http://pclab.pl/zdjecia/artykuly/pila/am2/gigabyte-ga-m57sli-s4/plyta-gora.j...
What are the means for recovering from faulty writes into SPI flash-chip? Chip is not socketed ;) Moreover, it is soldered.
De-solder the chip, and put a socket on it. Richard Smith helped me out with that, we now have one m57sli-s4 board with a socket instead of the soldered-on chip. Requires quite a bit of skill and some good equipment though (heat-pencil or heat-gun and a good soldering iron).
Thanks, Ward.
-- Ward Vandewege ward@fsf.org Free Software Foundation - Senior System Administrator
Hello, I have socketed PLCC32's a bunch of times. It is not very hard. You just have to be very careful not to lift any pads or you may just end up with a big paperweight.
Thanks - Joe
Anton schrieb:
According to this picture, some of the boards obviously have a bios socket. How can we find out where to get those instead of the soldered-only boards? http://pclab.pl/zdjecia/artykuly/pila/am2/gigabyte-ga-m57sli-s4/plyta-gora.j...
What are the means for recovering from faulty writes into SPI flash-chip? Chip is not socketed ;) Moreover, it is soldered.
1. desolder the chip & put in a socket 2. use some sort of "top hat flash" look-alike (not yet available) 3. possibly make use of the other unpopulated DUAL BIOS contacts (unknown whether it works)
On Mon, 12 Mar 2007 16:33:26 +0100 Quux pawn2be.wild@yahoo.de wrote:
Anton schrieb:
According to this picture, some of the boards obviously have a bios socket. How can we find out where to get those instead of the soldered-only boards? http://pclab.pl/zdjecia/artykuly/pila/am2/gigabyte-ga-m57sli-s4/plyta-gora.j...
What are the means for recovering from faulty writes into SPI flash-chip? Chip is not socketed ;) Moreover, it is soldered.
- desolder the chip & put in a socket
- use some sort of "top hat flash" look-alike (not yet available)
- possibly make use of the other unpopulated DUAL BIOS contacts
(unknown whether it works)
No, I'm not owner of that board ;-) Just curious, what to do if I'll spoil genuine code in SPI-flash (say, in modern boards). Again, this is *not* PLCC32.
-
Anton -
Bari Ari -
Carl-Daniel Hailfinger -
joe＠smittys.pointclark.net -
Peter Stuge -
Quux -
Richard Smith -
ST -
Stefan Reinauer -
Uwe Hermann -
Ward Vandewege