Board:gigabyte/m57sli: Difference between revisions

From coreboot
Jump to navigation Jump to search
No edit summary
Line 5: Line 5:
The fact that the BIOS is soldered onto the board complicates matters considerably, because it means that one flash of a faulty image will 'brick' your board.
The fact that the BIOS is soldered onto the board complicates matters considerably, because it means that one flash of a faulty image will 'brick' your board.


It is possible to desolder the BIOS chip, and replace it with a PLCC socket. You will need some tools (heat gun/pencil, good soldering iron, etc) and soldering experience to do that. There has also been [http://www.openbios.org/pipermail/linuxbios/2007-March/018993.html some speculation] about the unpopulated paths for a second PLCC socket/chip, and whether it would be possible to put a PLCC socket on there and switch between the on-board BIOS and the extra socket.
It is possible to desolder the BIOS chip, and replace it with a PLCC socket. You will need some tools (heat gun/pencil, good soldering iron, etc) and soldering experience to do that. The other option is to add a PLCC socket to the empty position next to the soldered-on BIOS chip. With an extra resistor and a switch, this allows switching between 2 BIOS chips. This has been documented carefully by ST; see his [http://private.vlsi.informatik.tu-darmstadt.de/st/instructions.html instructions].


If you're going to work on this board, I suggest you put a socket on it, or ask a friend to do so. It's just too risky otherwise.
If you're going to work on this board, you need a backup plan in the event you flash a faulty BIOS image (it's called 'bricking' the board). I suggest you put a socket on it, or ask a friend to do so. It's just too risky otherwise.


Once you put a socket on the board, you will also discover that the [http://www.ioss.com.tw/web/English/RD1BIOSSavior/SelectionChart/PLCCTYPE/RD1PMC4.html RD1-PMC4 BiosSavior] does not work with this motherboard: the RD1's built-in chip seems to be incompatible with the mainboard. This means you will need to hot-swap BIOS chips until you have a working LinuxBIOS chip. Plugging your BIOS chip into the RD1 and switching it to 'ORG' does work though. I have used the BiosSavior to ease hot swapping; it's a lot easier to pull out the BiosSavior and replace the chip plugged into it than to replace the ROM chip on the board.
Once you put a socket on the board, you will also discover that the [http://www.ioss.com.tw/web/English/RD1BIOSSavior/SelectionChart/PLCCTYPE/RD1PMC4.html RD1-PMC4 BiosSavior] does not work with this motherboard: the RD1's built-in chip seems to be incompatible with the mainboard. This means you will need to hot-swap BIOS chips until you have a working LinuxBIOS chip. Plugging your BIOS chip into the RD1 and switching it to 'ORG' does work though. I have used the BiosSavior to ease hot swapping; it's a lot easier to pull out the BiosSavior and replace the chip plugged into it than to replace the ROM chip on the board.


Finding a BiosSavior can be a little tricky - most resellers seem to be out of stock, and the rumor is that IOSS has stopped producing them. This is the list of resellers:
This is the list of BiosSavior resellers:


   http://www.ioss.com.tw/web/English/WheretoBuy.html
   http://www.ioss.com.tw/web/English/WheretoBuy.html


I was able to purchase a couple (2007/03) from [http://www.eksitdata.com Eksitdata] in Sweden.
In the US, FrozenCPU seems to have stock (verified 2007/04). Eksitdata in Sweden also seems to have stock (verified 2007/03).


This wiki page is maintained by Ward Vandewege (ward at gnu dot org).
This wiki page is maintained by Ward Vandewege (ward at gnu dot org).
Line 66: Line 66:
   # Loader for standard Linux kernel image, a.k.a. /vmlinuz
   # Loader for standard Linux kernel image, a.k.a. /vmlinuz
   LINUX_LOADER = 1
   LINUX_LOADER = 1
Because physical disks take a while to spin up, I've had to add an extra delay to FILO:
Index: main/filo.c
===================================================================
--- main/filo.c (revision 34)
+++ main/filo.c (working copy)
@@ -60,6 +60,7 @@
    /* Initialize */
    init();
+    delay (5);
    grub_main();
    return 0;
}
This will make FILO wait 5 seconds before probing the disks, making sure that the SATA disk is ready.


In order to get serial output from Grub, you will also need to add something like this to your menu.list:
In order to get serial output from Grub, you will also need to add something like this to your menu.list:
Line 93: Line 122:
===Current status of the LBv2 tree===
===Current status of the LBv2 tree===


As of 2007-03-19, the v2 tree does not yet have all the necessary patches to build a working LinuxBIOS for the M57SLI-S4. For now, we have to work from the patches that Yinghai Lu sent to the LinuxBIOS list on January 19. Download all three archives and extract them into a directory on your system:
Use revision 2619 or higher.
 
  [http://www.openbios.org/pipermail/linuxbios/2007-January/017993.html Patch 1]
  [http://www.openbios.org/pipermail/linuxbios/2007-January/017994.html Patch 2]
  [http://www.openbios.org/pipermail/linuxbios/2007-January/017995.html Patch 3]
 
The code comes with a script called 'nsf', which, out of the box, is quite dangerous. NEVER run this script as root without any arguments - it will wipe out most of your system. I suggest you replace it with this version instead:
 
<pre>
#!/bin/bash
MBVENDOR=$1
MBMODEL=$2
LBROOT=/home/yhlu/xx/xx/xx/
if [ "$MBVENDOR" = "" ] || [ "$MBMODEL" = "" ]; then
        cat ./readme_mcp55.txt
        echo
        echo "ERROR: Not enough command line arguments"
        exit 1
fi
echo $MBVENDOR/$MBMODEL
date
 
cd "$LBROOT/freebios2/targets"
rm -rf "$MBVENDOR/$MBMODEL/$MBMODEL"
./buildtarget "$MBVENDOR/$MBMODEL" &> "$LBROOT/x_b.txt"
cd "$MBVENDOR/$MBMODEL/$MBMODEL"
#make clean
eval make &> "$LBROOT/x_m.txt"
        if [ $? -eq 0 ]; then
                echo "ok."
        else
                echo "FAILED! Log excerpt:"
                tail -n 20 "$LBROOT/x_m.txt"
                exit
        fi
cat ./normal/linuxbios.rom ./fallback/linuxbios.rom ./failover/linuxbios.rom > "$LBROOT/rom/"$MBMODEL"_linuxbios.rom"
ls -l "$LBROOT/"$MBMODEL"_linuxbios.rom"
date
</pre>
 
You will need to update the LBROOT variable to be correct for your system.


===Building LinuxBIOS===
===Building LinuxBIOS===


Unless you have a USB debug device, you should disable USB debug support from the codebase to allow for a much faster boot (otherwise the code will probe for the USB device that is not there, which will take a long time). Edit this file:
Make sure that the path to your payload is correct, by editing  
 
  freebios2/src/mainboard/gigabyte/m57sli/Options.lb
 
and make sure that CONFIG_USBDEBUG_DIRECT is set to 0, not 1:
 
  default CONFIG_USBDEBUG_DIRECT=0
 
Next, make sure that the path to your payload is correct, by editing  


   freebios2/targets/gigabyte/m57sli/Config.lb
   freebios2/targets/gigabyte/m57sli/Config.lb
Line 151: Line 132:
and updating all the lines that start with 'payload'. There are 2 occurrences, one for the normal image, and one for the fallback image.
and updating all the lines that start with 'payload'. There are 2 occurrences, one for the normal image, and one for the fallback image.


Now execute nsf to build the right image. Make sure you are NOT doing this as the root user:
Then build a target directory:


   nsf gigabyte m57sli
   cd targets
  ./buildtarget gigabyte/m57sli


When that's done, you will find a file called 'm57sli_linuxbios.rom' in the 'rom' subdirectory.
Finally build the image


That's the file that should be burned into your BIOS chip.
  cd gigabyte/m57sli/m57sli
  make
 
This will generate a linuxbios.rom image, which is 512KB large. That's the file that should be burned into your BIOS chip.


===Burning LinuxBIOS===
===Burning LinuxBIOS===


Make SURE that you have a fallback position: a rom chip with backup copy of your factory ROM image (you can make one with flashrom), and either a socket on the board to plug the backup chip into, or the tools and skills to remove a 'bricked' BIOS chip from the board and replace it with a socket for the backup chip.  
Make SURE that you have a fallback position: a rom chip with backup copy of your factory ROM image (you can make one with flashrom), and either a socket on the board to plug the backup chip into, or the tools and skills to remove a 'bricked' BIOS chip from the board and replace it with a socket for the backup chip.  
You could also follow ST's [http://private.vlsi.informatik.tu-darmstadt.de/st/instructions.html instructions] to add a PLCC socket in the empty position next to the soldered-on BIOS chip. With an extra resistor and a switch, that seems to allow easy swapping between bios chips on this board.


If you do not prepare properly, you are likely to brick your motherboard. You have been warned!
If you do not prepare properly, you are likely to brick your motherboard. You have been warned!
Line 169: Line 152:
You can use flashrom from the LinuxBIOS v2 tree to burn the image:
You can use flashrom from the LinuxBIOS v2 tree to burn the image:


   util/flashrom/flashrom -v -w rom/m57sli_linuxbios.rom
   util/flashrom/flashrom -v -w linuxbios.rom


===Running LinuxBIOS===
===Running LinuxBIOS===

Revision as of 15:55, 27 April 2007

Before you begin

The Gigabyte M57SLI-S4 seems to exist in at least 2 versions: one with a PLCC socket for the BIOS chip (socketed BIOS), and one with the PLCC BIOS chip soldered onto the board (soldered BIOS). The former might be a pre-production board since nobody has so far (2007/03) confirmed the purchase of a M57SLI-S4 board with socketed BIOS.

The fact that the BIOS is soldered onto the board complicates matters considerably, because it means that one flash of a faulty image will 'brick' your board.

It is possible to desolder the BIOS chip, and replace it with a PLCC socket. You will need some tools (heat gun/pencil, good soldering iron, etc) and soldering experience to do that. The other option is to add a PLCC socket to the empty position next to the soldered-on BIOS chip. With an extra resistor and a switch, this allows switching between 2 BIOS chips. This has been documented carefully by ST; see his instructions.

If you're going to work on this board, you need a backup plan in the event you flash a faulty BIOS image (it's called 'bricking' the board). I suggest you put a socket on it, or ask a friend to do so. It's just too risky otherwise.

Once you put a socket on the board, you will also discover that the RD1-PMC4 BiosSavior does not work with this motherboard: the RD1's built-in chip seems to be incompatible with the mainboard. This means you will need to hot-swap BIOS chips until you have a working LinuxBIOS chip. Plugging your BIOS chip into the RD1 and switching it to 'ORG' does work though. I have used the BiosSavior to ease hot swapping; it's a lot easier to pull out the BiosSavior and replace the chip plugged into it than to replace the ROM chip on the board.

This is the list of BiosSavior resellers:

 http://www.ioss.com.tw/web/English/WheretoBuy.html

In the US, FrozenCPU seems to have stock (verified 2007/04). Eksitdata in Sweden also seems to have stock (verified 2007/03).

This wiki page is maintained by Ward Vandewege (ward at gnu dot org).

Payload

LinuxBIOS requires a Payload to boot an operating system.

If you want to boot from the network, you will need to use Etherboot.

If you want to boot from an IDE drive, SATA drive, USB stick or CDROM, you can use FILO.

Building the payload

In order to boot from a SATA disk, we use FILO.

Once you've downloaded FILO, you will need to put a file 'Config' in its root tree. An example can be found in the distribution, called 'defconfig'.

You can configure FILO to load Grub. Here's my Config, which does that:

 # Use grub instead of autoboot?
 USE_GRUB = 1
 # Grub menu.lst path
 MENULST_FILE = "hde1:/grub/menu.lst"
 # Driver for hard disk, CompactFlash, and CD-ROM on IDE bus
 IDE_DISK = 1
 # Add a short delay when polling status registers
 # (required on some broken SATA controllers)
 IDE_DISK_POLL_DELAY = 1
 # Driver for USB Storage
 USB_DISK = 1
 # VGA text console
 VGA_CONSOLE = 1
 PC_KEYBOARD = 1
 # Enable the serial console
 SERIAL_CONSOLE = 1
 # Serial console; real external serial port
 SERIAL_IOBASE = 0x3f8
 SERIAL_SPEED = 115200
 # Filesystems
 FSYS_EXT2FS = 1
 FSYS_ISO9660 = 1
 # Support for boot disk image in bootable CD-ROM (El Torito)
 ELTORITO = 1
 # PCI support
 SUPPORT_PCI = 1
 # Enable this to scan PCI busses above bus 0
 # AMD64 based boards do need this.
 PCI_BRUTE_SCAN = 1
 # Loader for standard Linux kernel image, a.k.a. /vmlinuz
 LINUX_LOADER = 1

Because physical disks take a while to spin up, I've had to add an extra delay to FILO:

Index: main/filo.c

=======================================================

--- main/filo.c (revision 34)

+++ main/filo.c (working copy)

@@ -60,6 +60,7 @@


    /* Initialize */
    init();

+ delay (5);

    grub_main();
    return 0;
}


This will make FILO wait 5 seconds before probing the disks, making sure that the SATA disk is ready.

In order to get serial output from Grub, you will also need to add something like this to your menu.list:

 # serial port 0
 serial --unit=0 --speed=115200
 terminal --timeout=15 serial console

Now execute 'make', which will generate a filo.elf file that will be your payload. You will need to refer to this file to build LinuxBIOS as explained below, because it gets included in the LinuxBIOS ROM image.

Your menu.list entry

When using FILO in grub emulation mode, it's important to get a few details right in your grub boot stanza. This is what mine looks like:

title   Ubuntu LB, kernel 2.6.21-rc3
root    (hd4,0)
kernel    /boot/vmlinuz-2.6.21-rc3 root=/dev/sda1 ro acpi_use_timer_override console=tty0 console=ttyS0,115200
savedefault
boot

Note the root device - FILO sees the first sata device as hd4.

Also, the m57sli-s4 will not boot unless you add acpi_use_timer_override as a kernel option - and use a modern kernel (tested on 2.6.20.1 and up). Hopefully this will be fixed in newer kernels. If you have a somewhat older kernel (tested with 2.6.16 and up), add these options: apic=debug acpi_dbg_level=0xffffffff pci=noacpi,routeirq snd-hda-intel.enable_msi=1.

Current status of the LBv2 tree

Use revision 2619 or higher.

Building LinuxBIOS

Make sure that the path to your payload is correct, by editing

 freebios2/targets/gigabyte/m57sli/Config.lb

and updating all the lines that start with 'payload'. There are 2 occurrences, one for the normal image, and one for the fallback image.

Then build a target directory:

 cd targets
 ./buildtarget gigabyte/m57sli

Finally build the image

 cd gigabyte/m57sli/m57sli
 make

This will generate a linuxbios.rom image, which is 512KB large. That's the file that should be burned into your BIOS chip.

Burning LinuxBIOS

Make SURE that you have a fallback position: a rom chip with backup copy of your factory ROM image (you can make one with flashrom), and either a socket on the board to plug the backup chip into, or the tools and skills to remove a 'bricked' BIOS chip from the board and replace it with a socket for the backup chip.

If you do not prepare properly, you are likely to brick your motherboard. You have been warned!

You can use flashrom from the LinuxBIOS v2 tree to burn the image:

 util/flashrom/flashrom -v -w linuxbios.rom

Running LinuxBIOS

Now shut down your computer (a reset will not work, you need to power down), and restart it. Hook up a serial console so that you can see what's happening.

The mac address for the onboard network card will have changed, so you may have to modify /etc/iftab (Debian/Ubuntu, see your distro documentation for the equivalent file) to get your network working.

Help?

Did something go wrong? Use your backup rom chip (you DID make one, right?) to boot into the proprietary BIOS, and see if you can resolve the problem. Feel free to contact the friendly and helpful mailing list if you need help.

TODO

ACPI support is not implemented yet. This is a fairly major problem, and needs to be addressed soon.

There is also still an issue with I2C, which causes X startup to be very slow. You can bypass this problem by adding

 Option   "NoDDC2"

to your "Device" section.

If you can help out with this, please join the mailing list and let us know!