Gigabyte have told me that the BIOS chip is made by SST, and the model name is SST25LF040A BIOS ROM which is PLCC32 type.
The data sheet and details are at
http://www.sst.com/products.xhtml/serial_flash/25/SST25LF040A
I am now very confused because I have PLCC32 sockets and these are nothing like the BIOS chip which has 8 connections.
(I have two PLCC32 sockets and four unused flash chips to give away, if they are no use to this version of the motherboard).
I will probably try to source some of these chips, just in case the rest of the problems can be solved.
Chris Lingard
Hmmm.. When you took contact with Gigabyte, did you clearly told them that you have a SPI revision of their board? For my part, I desoldered the SPI flash chip on my board and took a look at it with a powerfull glass and found that, in fact, they use a MX25L4005A chip from MXC. But that doesn't matter a lot I think.. I found that many SPI flash use the same protocol (CFI?) for programming, so adding support in flashrom should be easy, now that we already know that the controller of the SPI signals is the SuperIO chip.. Hope this helps.. Florentin
Quoting Chris Lingard chris@stockwith.co.uk:
Gigabyte have told me that the BIOS chip is made by SST, and the model name is SST25LF040A BIOS ROM which is PLCC32 type.
The data sheet and details are at
http://www.sst.com/products.xhtml/serial_flash/25/SST25LF040A
I am now very confused because I have PLCC32 sockets and these are nothing like the BIOS chip which has 8 connections.
(I have two PLCC32 sockets and four unused flash chips to give away, if they are no use to this version of the motherboard).
I will probably try to source some of these chips, just in case the rest of the problems can be solved.
Chris Lingard
-- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
On Fri, Sep 07, 2007 at 06:46:17PM +0100, Chris Lingard wrote:
Gigabyte have told me that the BIOS chip is made by SST, and the model name is SST25LF040A BIOS ROM which is PLCC32 type.
Nonsense, I'm afraid.
SST25LF040A is only available in 8-contact packages. (SOIC and WSON)
Whoever you had contact with at Gigabyte didn't know about the different revisions of the board and their differences.
I am now very confused because I have PLCC32 sockets and these are nothing like the BIOS chip which has 8 connections.
(I have two PLCC32 sockets and four unused flash chips to give away, if they are no use to this version of the motherboard).
Correct, since you don't have PLCC chips you have the revision with SOIC chips.
I will probably try to source some of these chips, just in case the rest of the problems can be solved.
The hardware part is solved, but there's no support for flashing in flashrom yet, you would have to reboot into another OS (DOS or Windows) and use the Gigabyte-supplied flashing utility.
For the hardware mod you would need:
1x SST25LF040A or MX25L4005A 2x 100k resistors (0.125W ones are good size-wise) 1x SPDT (single pole dual throw) switch (break-before-make or make-before-break doesn't matter much - neither will reliably allow the switch to be flipped while the flash chip is being accessed.)
See http://stuge.se/m57sli_soic_detail_labels.jpg for contact names.
1. Lift the U5-CS# pin from the board. 2. Solder 1x 100k resistor between U5-VCC and the lifted U5-CS# pin. 3. Solder the center contact on the switch to the U5-CS# pad on the mainboard. 4. Solder one outer contact on the switch to the U5-CS# pin, where one end of the resistor in step 2 is also soldered. 5. Solder the new flash chip to the U9 pads. Note pin 1! There should be a marking on the flash chip near one corner pin, that's pin 1, U9-CS#. 6. Lift U9-CS# from the board. (Or just don't solder it in step 5.) 7. Solder 1x 100k resistor between U9-VCC and the lifted U9-CS# pin. 8. Solder the second outer contact on the switch to the U9-CS# pin, where one end of the resistor in step 7 is also soldered.
Done! Now the switch controls which of U5 and U9 is actually selected when the super io wants to access the flash chip.
You could get a biased (spring-loaded) switch in order to help avoiding accidentally leaving the system running with the factory BIOS chip selected when you're doing LB work - so that the next flashing operation does not overwrite the wrong chip. You would need to hold the switch while booting the factory BIOS, but that may be worthwhile if you can't easily redo the soldering work if both flash chips contain junk.
//Peter
Peter Stuge wrote:
On Fri, Sep 07, 2007 at 06:46:17PM +0100, Chris Lingard wrote:
Gigabyte have told me that the BIOS chip is made by SST, and the model name is SST25LF040A BIOS ROM which is PLCC32 type.
Nonsense, I'm afraid.
SST25LF040A is only available in 8-contact packages. (SOIC and WSON)
Whoever you had contact with at Gigabyte didn't know about the different revisions of the board and their differences.
I am now very confused because I have PLCC32 sockets and these are nothing like the BIOS chip which has 8 connections.
(I have two PLCC32 sockets and four unused flash chips to give away, if they are no use to this version of the motherboard).
Correct, since you don't have PLCC chips you have the revision with SOIC chips.
I will probably try to source some of these chips, just in case the rest of the problems can be solved.
The hardware part is solved, but there's no support for flashing in flashrom yet, you would have to reboot into another OS (DOS or Windows) and use the Gigabyte-supplied flashing utility.
For the hardware mod you would need:
1x SST25LF040A or MX25L4005A 2x 100k resistors (0.125W ones are good size-wise) 1x SPDT (single pole dual throw) switch (break-before-make or make-before-break doesn't matter much - neither will reliably allow the switch to be flipped while the flash chip is being accessed.)
See http://stuge.se/m57sli_soic_detail_labels.jpg for contact names.
- Lift the U5-CS# pin from the board.
- Solder 1x 100k resistor between U5-VCC and the lifted U5-CS# pin.
- Solder the center contact on the switch to the U5-CS# pad on the
mainboard. 4. Solder one outer contact on the switch to the U5-CS# pin, where one end of the resistor in step 2 is also soldered. 5. Solder the new flash chip to the U9 pads. Note pin 1! There should be a marking on the flash chip near one corner pin, that's pin 1, U9-CS#. 6. Lift U9-CS# from the board. (Or just don't solder it in step 5.) 7. Solder 1x 100k resistor between U9-VCC and the lifted U9-CS# pin. 8. Solder the second outer contact on the switch to the U9-CS# pin, where one end of the resistor in step 7 is also soldered.
Done! Now the switch controls which of U5 and U9 is actually selected when the super io wants to access the flash chip.
You could get a biased (spring-loaded) switch in order to help avoiding accidentally leaving the system running with the factory BIOS chip selected when you're doing LB work - so that the next flashing operation does not overwrite the wrong chip. You would need to hold the switch while booting the factory BIOS, but that may be worthwhile if you can't easily redo the soldering work if both flash chips contain junk.
//Peter
Thank you, that is brilliant.
OK, two PLCC32 sockets and four unused flash chips free to good home :-) Apply by email, (or 2 sets of one socket and two chips).
Will start sourcing SST25LF040A on Monday, then rebook the workshop.
My second newbie dumb question. If I make copies of the Factory BIOS on a floppy, I can overwrite one of them with LinuxBios. I then use the BIOS, and when it asks for confirmation, I switch over to the new chip, and hope. (The Gigabyte BIOS can overwrite itself, press <end> key during post to enter Q-flash)
Chris Lingard
On Sat, Sep 08, 2007 at 08:21:07PM +0100, Chris Lingard wrote:
Peter Stuge wrote:
For the hardware mod you would need:
..
Thank you, that is brilliant.
Note that I have not tested it since I don't have the board, but in theory it should work based on the measurements done by others.
Will start sourcing SST25LF040A on Monday, then rebook the workshop.
No guarantees from me that it will work - but if you still want to give it a go we sure would appreciate hearing from you when it's done.
I think there are some more electronics savvy people reading the list who could try the mod on their own boards with less effort than booking a workshop - to confirm that it actually works in practice. But if you can't wait I completely understand! =)
My second newbie dumb question. If I make copies of the Factory BIOS on a floppy, I can overwrite one of them with LinuxBios. I then use the BIOS, and when it asks for confirmation, I switch over to the new chip, and hope. (The Gigabyte BIOS can overwrite itself, press <end> key during post to enter Q-flash)
Yes - make copies of the factory BIOS. Several of them, ideally.
I'd even recommend flashing the factory BIOS into the new chip and then going back to the shop and replacing one flash chip with a blank one so you know you have one working flash chip safely stored away from the board.
I would also recommend using a flashing program separate from the one in the factory BIOS however, since Q-flash may be making assumptions about the flash chip contents (since it knows it is stored in flash) which are no longer true when you flip the switch, and could cause the flashing to fail.
But it could also just work. :)
//Peter
Peter Stuge wrote:
..
See http://stuge.se/m57sli_soic_detail_labels.jpg for contact names.
- Lift the U5-CS# pin from the board.
maybe thaere is a resistor of 0 Ohm (maybe R509 ?) between the Superio and U5? it might be easier and a LOT saver to unsorder a resistor the it is to unsolder a singer soic pin .....
- Solder 1x 100k resistor between U5-VCC and the lifted U5-CS# pin.
- Solder the center contact on the switch to the U5-CS# pad on the
mainboard. 4. Solder one outer contact on the switch to the U5-CS# pin, where one end of the resistor in step 2 is also soldered. 5. Solder the new flash chip to the U9 pads. Note pin 1! There should be a marking on the flash chip near one corner pin, that's pin 1, U9-CS#. 6. Lift U9-CS# from the board. (Or just don't solder it in step 5.) 7. Solder 1x 100k resistor between U9-VCC and the lifted U9-CS# pin. 8. Solder the second outer contact on the switch to the U9-CS# pin, where one end of the resistor in step 7 is also soldered.
Done! Now the switch controls which of U5 and U9 is actually selected when the super io wants to access the flash chip.
You could get a biased (spring-loaded) switch in order to help avoiding accidentally leaving the system running with the factory BIOS chip selected when you're doing LB work - so that the next flashing operation does not overwrite the wrong chip. You would need to hold the switch while booting the factory BIOS, but that may be worthwhile if you can't easily redo the soldering work if both flash chips contain junk.
Good suggestion
another one:
dont solder a chip to the U9 pads but solder a 8 pin connector to that pads... then solder a mating connector to the chip(s)
greetings
todthgie
On Sun, Sep 02, 2007 at 08:13:24PM +0200, echelon@free.fr wrote:
- what Q4-1, Q5-1, R99-1 and R102-2 connects to on U5, if anything.
Q4-1 -> U9-CS# Q5-1 -> U5-CS#
On Sun, Sep 09, 2007 at 11:14:40PM +0200, todthgie wrote:
- Lift the U5-CS# pin from the board.
maybe thaere is a resistor of 0 Ohm (maybe R509 ?) between the Superio and U5?
Possible, but someone will have to spend some time checking connections on the board to find it. Really tedious work.
It's not R509 though since Q5-1 is U5-CS#, not Q4-3/Q5-3. :\
it might be easier and a LOT saver to unsorder a resistor the it is to unsolder a singer soic pin .....
I think lifting a corner pin should be doable for pretty much anyone with a little soldering experience but if you can find a 0 ohm that's great! :)
dont solder a chip to the U9 pads but solder a 8 pin connector to that pads... then solder a mating connector to the chip(s)
Can you suggest some good connector part numbers? Needing a PCB for the chip+connector is no fun either..
//Peter
On Monday 10 September 2007 03:54, Peter Stuge wrote:
On Sun, Sep 02, 2007 at 08:13:24PM +0200, echelon@free.fr wrote:
- what Q4-1, Q5-1, R99-1 and R102-2 connects to on U5, if
anything.
Q4-1 -> U9-CS# Q5-1 -> U5-CS#
On Sun, Sep 09, 2007 at 11:14:40PM +0200, todthgie wrote:
- Lift the U5-CS# pin from the board.
maybe thaere is a resistor of 0 Ohm (maybe R509 ?) between the Superio and U5?
Possible, but someone will have to spend some time checking connections on the board to find it. Really tedious work.
It's not R509 though since Q5-1 is U5-CS#, not Q4-3/Q5-3. :\
it might be easier and a LOT saver to unsorder a resistor the it is to unsolder a singer soic pin .....
I think lifting a corner pin should be doable for pretty much anyone with a little soldering experience but if you can find a 0 ohm that's great! :)
A nice method of desoldering soic pins is to use a 26 swg enamelled copper wire. Pass the wire under the ic and between the pin. Tug the wire so that it slides under the pin while heating the pin. You end up with the pin clear of the board. Can also be used to remove the entire chip without damaging the ic or the board.
On Mon, Sep 10, 2007 at 12:03:37PM +0530, jtd wrote:
I think lifting a corner pin should be doable for pretty much anyone with a little soldering experience but if you can find a 0 ohm that's great! :)
A nice method of desoldering soic pins is to use a 26 swg enamelled copper wire. Pass the wire under the ic and between the pin. Tug the wire so that it slides under the pin while heating the pin.
Nice trick!
Another similarly good tool is a plain sewing needle which can be used as a lever to bend the pin slightly while melting the solder with the soldering iron.
//Peter
I use Chemtronics Chem-Wik Desoldering Braid. It seems to work really well. It sucks up all the solder so the pads are left pretty much bare:-)
Thanks - Joe
Quoting Peter Stuge peter@stuge.se:
On Mon, Sep 10, 2007 at 12:03:37PM +0530, jtd wrote:
I think lifting a corner pin should be doable for pretty much anyone with a little soldering experience but if you can find a 0 ohm that's great! :)
A nice method of desoldering soic pins is to use a 26 swg enamelled copper wire. Pass the wire under the ic and between the pin. Tug the wire so that it slides under the pin while heating the pin.
Nice trick!
Another similarly good tool is a plain sewing needle which can be used as a lever to bend the pin slightly while melting the solder with the soldering iron.
//Peter
-- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
On Tue, Sep 11, 2007 at 05:47:53AM -0400, joe@smittys.pointclark.net wrote:
I use Chemtronics Chem-Wik Desoldering Braid. It seems to work really well. It sucks up all the solder so the pads are left pretty much bare:-)
Yeah - braid is good! Sometimes there can still be a very small amount of solder left though, so that a lot more force is needed to lift the pin - in that case just heating the pad quickly works well.
Removing as much solder as possible is good also because the pin doesn't have to be lifted as high from the board to break the joint - which means less risk of breaking the pin in the process.
//Peter
Hi all,
Finaly a little victory with the SPI version of the GA-M57SLI-S4 board.. It works!!! LinuxBIOS + FILO as payload work (almost) "out of the box" on the spi revision of the card, i.e. I didn't make any changes to the source tree used to generate the rom image. But some issues remain: -1) no support in flashrom for spi chips. I used a home made spi programmer (with a Altera FPGA) to flash the rom image. I "socketised" also the flash chip and the mainboard. -2) I managed to boot a Linux with LB (a pretty old Debian distro with a 2.4 kernel). No VGA display at all! I had to use a serial console to display the LB logs and then to log in into Linux. BTW my graphics adapter was a old PCI graphics card. -3) I tried to install a network card too (PCI also). When booting with the factory bios image (Award) it works well, lspci shows both the graphics adapter and the ethernet one. But when booting with LB, these 2 items don't appear anymore into the lspci scan.. It looks to me that the PCI bridge is not correctly initialized into the SB : am I wrong or not on this issue?
That's the first assessement I can make for my work with this motherboard for the moment. Now I will try to add support for SPI flash and ITE8716 superio in flashrom (I have never done that before, it will be hard for me!..). Btw, is someone else working with this board at this moment or am I alone?.. I would like to avoid to do unusefull work..
Finaly another finding I made: - the board comes with a 512 KiB flash chip. I tried to use a 1 MiB flash chip and it works! But I had to duplicate the linuxbios.rom image (cat lb.rom lb.rom
lb2.rom) to generate a bigger image suitable for this bigger flash.
That's all folks.. Florentin
On Wed, Sep 12, 2007 at 03:11:19AM +0200, echelon@free.fr wrote:
Finaly a little victory with the SPI version of the GA-M57SLI-S4 board.. It works!!!
Great to hear. Glad you can confirm they didn't do too much to change it.
But some issues remain: -1) no support in flashrom for spi chips. I used a home made spi programmer (with a Altera FPGA) to flash the rom image. I "socketised" also the flash chip and the mainboard.
Can you confirm or reject the theory for adding a switch?
How did you do the socket?
No VGA display at all!
Did you include the VGA BIOS in your LB image and enable VGA in Config.lb?
-3) I tried to install a network card too (PCI also). When booting with the factory bios image (Award) it works well, lspci shows both the graphics adapter and the ethernet one. But when booting with LB, these 2 items don't appear anymore into the lspci scan..
Does LB find them? Can you show us lspci from factory BIOS and full serial output from the LB boot?
It looks to me that the PCI bridge is not correctly initialized into the SB : am I wrong or not on this issue?
That could be it. Maybe they changed enough to make the board's Config.lb invalid.
Now I will try to add support for SPI flash and ITE8716 superio in flashrom (I have never done that before, it will be hard for me!..). Btw, is someone else working with this board at this moment or am I alone?.. I would like to avoid to do unusefull work..
Carl-Daniel was going to have a look at it when he got back online unless someone else did it first.
flashrom has no support at all for the SPI way of flashing so I would just do a massive hack for the first round of SPI support.
Finaly another finding I made:
- the board comes with a 512 KiB flash chip. I tried to use a 1
MiB flash chip and it works! But I had to duplicate the linuxbios.rom, image (cat lb.rom lb.rom > lb2.rom) to generate a bigger image suitable for this bigger flash.
Yep - I would expect that to work. Cool.
//Peter
Hi all, First of all I have to apologise for answering so late on this topic but I was very busy last time..
Quoting Peter Stuge peter@stuge.se:
It works!!!
Great to hear. Glad you can confirm they didn't do too much to change it.
ugh.. not so fast!..
But some issues remain: -1) no support in flashrom for spi chips. I used a home made spi programmer (with a Altera FPGA) to flash the rom image. I "socketised" also the flash chip and the mainboard.
Can you confirm or reject the theory for adding a switch?
I don't think we can install a second chip.. at least without heavy hardware hacks (like desoldering the #CS of the first chip etc..)
How did you do the socket?
Maybe I will send some photos later..
-3) I tried to install a network card too (PCI also). When booting with the factory bios image (Award) it works well, lspci shows both the graphics adapter and the ethernet one. But when booting with LB, these 2 items don't appear anymore into the lspci scan..
Does LB find them? Can you show us lspci from factory BIOS and full serial output from the LB boot?
Yes. I attach some files to this email: -1) lb_linux_dump.txt => this is the boot of LinuxBIOS and of Linux (a Ubuntu Feisty distro) captured on a serial link. -2) award_linux_dmesg.txt => the result of dmesg after booting with the factory (Award) bios. -3) lb_linux_dmesg.txt => the result of dmesg after booting with LinuxBIOS. -4) lspci_award.txt => the result of "lspci -vvv" after booting with the factory bios. -5) lspci_lb.txt => the result of "lspci -vvv" after booting with LinuxBIOS -6) lspci_award_nnn.txt => "lspci -nnn" with factory bios.
It looks to me that the PCI bridge is not correctly initialized into the SB : am I wrong or not on this issue?
That could be it. Maybe they changed enough to make the board's Config.lb invalid.
One remark : in lspci_award.txt on can see that the device 00:06.0 (PCI bridge) is in "substractive decode" (i.e. "transparent") mode which is not the case in lspci_lb.txt. What does this mean? Also the IO and memory windows are not at all the same and in lb_linux_dmesg.txt one can see that these ranges are .. "disabed" (what does this mean?!)
A last request : can someone who has a PLCC version of m57sli send me some logs (at least the LB boot logs..) please..
I'll be back..., Florentin
Some random things I noticed, not all of them critical or related to your issue at hand:
PCI: 00:18.0 init PCI: 00:01.0 init set power on after power fail RTC Init Invalid CMOS LB checksum
I wonder why, but probably not critical.
PNP: 002e.1 init PNP: 002e.4 init FAN_CTL: reg = 0x02a9, read value = 0x50 FAN_CTL: reg = 0x02a9, writing value = 0xd7 PNP: 002e.5 init Keyboard selftest failed
Strange, but seems to work nonetheless (as per discussion on IRC; it's a USB keyboard attached via an USB-to-PS/2 adapter, btw).
PCI: 00:06.1 init base = fc040000 codec_mask = 01 codec viddid: 10ec0888 No verb!
Critical? What does this mean anyway?
[ 0.000000] Linux version 2.6.20-15-generic (root@yellow) (gcc version 4.1.2 (Ubuntu 4.1.2-0ubuntu4)) #2 SMP Sun Apr 15 06:17:24 UTC 2007 (Ubuntu 2.6.20-15.27-generic) [ 0.000000] Command line: acpi=off pci=noacpi,nobios console=tty0 console=ttyS0,115200 root=UUID=3bd44ac7-3a5b-4d3a-b452-fbbc051c9f8d ro
^^^^^^
[ 0.000000] BIOS-provided physical RAM map: [ 0.000000] BIOS-e820: 0000000000001000 - 00000000000a0000 (usable) [ 0.000000] BIOS-e820: 00000000000c0000 - 00000000000f0000 (usable) [ 0.000000] BIOS-e820: 0000000000100000 - 0000000080000000 (usable) [ 0.000000] PCI: Unknown option `nobios'
nobios unknown
[ 0.000000] Nvidia board detected. Ignoring ACPI timer override. [ 0.000000] If you got timer trouble try acpi_use_timer_override
The wiki suggests 'acpi_use_timer_override', too.
http://linuxbios.org/GIGABYTE_GA-M57SLI-S4_Build_Tutorial
[ 20.774883] PNP: No PS/2 controller found. Probing ports directly. [ 20.781319] serio: i8042 KBD port at 0x60,0x64 irq 1 [ 20.786293] serio: i8042 AUX port at 0x60,0x64 irq 12
OK, so Linux does indeed find the keyboard, it seems.
[ 20.802838] drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
LB related?
- Starting powernowd... [80G /etc/rc2.d/S20powernowd: 156: cannot create /sys/devices/system/cpu/cpu0//cpufreq/scaling_governor: Directory nonexistent
- CPU frequency scaling not supported
I think this is because of missing ACPI?
Uwe.
On 12.09.2007 02:52, Peter Stuge wrote:
On Wed, Sep 12, 2007 at 03:11:19AM +0200, echelon@free.fr wrote:
Now I will try to add support for SPI flash and ITE8716 superio in flashrom (I have never done that before, it will be hard for me!..). Btw, is someone else working with this board at this moment or am I alone?.. I would like to avoid to do unusefull work..
Carl-Daniel was going to have a look at it when he got back online unless someone else did it first.
I'm back, but swamped with work. A few suggestions below:
flashrom has no support at all for the SPI way of flashing so I would just do a massive hack for the first round of SPI support.
That's why I'd like to go with the Linux kernel MTD SPI framework for now. I have some scripts which are able to "port" code between flashrom and Linux kernel MTD code, but they are in a too early stage to be of use for anyone besides me.
@Stefan: The Linux SPI implementation has progressed quite a lot in the last few months, so you may want to rethink your objections to using it.
Oh, and I have really good news. It seems SPI flashing on the GA-M57SLI is only a few lines of code away. I have a rough code skeleton which should be checked by someone with the new GA-M57SLI who can reflash manually if necessary.
Regards, Carl-Daniel
Does this set of directions fit on the wiki somewhere? pictures?
ron
On Sat, Sep 08, 2007 at 04:43:25PM -0700, ron minnich wrote:
Does this set of directions fit on the wiki somewhere?
Too early until it has actually been tested? Maybe not.
pictures?
I can take some pictures of the process using an experiment board and another SO-8 chip, that might be useful to illustrate how the resistors can be mounted even if it's not the Gigabyte board.
Maybe whoever does the first testing on actual hardware can also take some pictures?
//Peter
On Sun, Sep 09, 2007 at 03:15:57AM +0200, Peter Stuge wrote:
On Sat, Sep 08, 2007 at 04:43:25PM -0700, ron minnich wrote:
pictures?
I can take some pictures of the process using an experiment board and another SO-8 chip
These photos are of two completely different boards I dug up, but it does show how the mod should look, just using two other SO-8 chips. I put some labels in there too for clarification.
Feel free to use {overview,U5,U9}.jpg in any way. It would be awesome if someone put the instructions in my previous email and the images together on the m57sli wiki page so the theory can be tested by anyone passing by with the right equipment and supplies.
//Peter
-
Carl-Daniel Hailfinger -
Chris Lingard -
echelon＠free.fr -
joe＠smittys.pointclark.net -
jtd -
Peter Stuge -
ron minnich -
todthgie -
Uwe Hermann