1. You may have noticed things look a little different around here - we've switched to a new platform (XenForo) and have some new forum styles and features. This how-to guide will help you find your way around. If you find anything that looks strange, post it in this thread.

G74SX in-circuit reprogram of BIOS SPI

Discussion in 'ASUS Gaming Notebook Forum' started by Sir Robin, Apr 11, 2012.

  1. Sir Robin

    Sir Robin Notebook Geek

    Likes Received:
    Trophy Points:
    Greetings Everyone!

    I originally posted this in the "G74SX 202 BIOS Now Available" thread,
    but did not see any responses. It's an older thread, so maybe a separate
    thread makes more sense. Hope you don't mind the re-posting :)

    Well, you can count me among the (dare I say) thousands of poor fools,
    that attempted to update their BIOS, using the EasyFlash Utility,
    and used that nifty feature of pulling the file directly from a NTFS
    drive partition. I wish I had checked the forums, before I attempted
    to do the update. I guess it was too much to expect Asus to support
    any kind of recovery mechanism, or make sure their update utilities actually
    worked correctly. You gotta love a company that leaves landmines in their
    code, and no way to repair the damage, short of doing a RMA. What the
    heck were they thinking? At least bundle the update files, with a Readme,
    warning not to use the error prone features of the tool.

    Okay, enough venting (at least for now) :)

    So it turns out that in-circuit reprogramming of the SPI Flash is
    fairly easy, if you have the right tools. I dumped the contents of
    the bricked BIOS, and discovered that the Easyflash tool uses an
    incorrect buffer pointer (at least when doing NTFS based updates).
    Rather than the new BIOS code, the tool wrote the contents of my
    hard drive directory tree into the flash. Nice, huh? Needless to say,
    the G74SX would do nothing, after the update (no sign of power, no
    lights, dead to the world). Side note, I was updating from 201 to 203,
    on a G74SX, purchased in the last few months.

    I tried downloading the 201, 202 and 203 BIOS files into the flash. The
    good news is that the lights started coming on. The bad news is that is
    as far as the unit gets. Holding the power button does not cause the
    power to cycle back off, so the EC is probably in a bad state. Based on
    the size of the files, and the fact that the first 512Meg is all 0xFF's,
    I suspect the update files are either incomplete (they rely on some code
    that stays resident in the flash, during update), or the file format is
    not a raw binary image.

    Does anyone, out there, know what format are the BIOS update files? Do
    they need to be parsed?

    Alternately, I was wondering if anyone has a raw image copy of their
    SPI flash available, that they could send me (PM)? It should be about
    4M in size. I believe the Linux tool "flashrom" should be able to extract
    the SPI flash image. It is available as part of the following RecoveryCD:

    Live CD - flashrom

    Would anyone be willing to boot the CD, and take a snapshot, from their G74SX?
    In return, I will gladly put together a tutorial on how to reprogram the BIOS flash.
    It would be great if enough people made snapshots, so we
    could get all 4 variants archived (V201, V202, V203, V203 + Throttle Mods).

    Thanks to everyone who participates in this forum, and for all of your
    time, expertise and efforts!

    Brave, Brave Sir Robin :)
  2. svl7

    svl7 T|I

    Likes Received:
    Trophy Points:
    It's a binary file.

    Bad idea, chances are you overwrite your serial nr / service tag when flashing a dump of a complete bios chip of another system.
  3. evgasr2

    evgasr2 Notebook Deity

    Likes Received:
    Trophy Points:
    Hey I have Asus G73Jh's full bios backuped by spi programmer.
    I know it wont help, but one of my friends has an asus g74 , il ask him to make a backup of his bios, can you tell me how to do that with live cd .
    thank you
  4. Sir Robin

    Sir Robin Notebook Geek

    Likes Received:
    Trophy Points:
    Thanks for confirming the format, svl7 :)
    Do you know if there the file needs to be
    offset in the flash (start programming at an
    address other than 0x00000000)?

    If those fields were stored in the SPI flash, they are long gone. Easyflash
    erased and replaced them with garbage. They must erase the entire device,
    and then attempt to rewrite the data, they want to save. Not good, if you've
    got the wrong buffer pointer, in your code :) If they truly are storing the serial
    number/service tag, in there somewhere. I can always edit the image to include the
    correct number(s). I just want to get my G74SX running again. I know others are in
    the same boat. If we can figure out how to fix the issue, in the field, it will be very
    helpful, for those who are out of warranty service. Asus should really issue a generic
    image file (complete image), for those people who need to go to a repair shop, or
    need to order a replacement chip. After all, this is 100% Asus's fault. They should
    never have let this problem occur in the first place. The least they can do, is provide
    the files necessary to fix the problem.

    Thanks evgasr2, if your friend is up for it, it would be a great help! :)

    Here are the instructions. I just verified them on a H67 based Shuttle SFF:

    1. Make sure your bios is setup to boot from CD/DVD as the first boot device
    2. Plug in a USB Flash drive (for storing the image)
    3. Insert the recover CD, and boot the system
    4. Select "boot directly to graphical interface"
    5. Once Gentoo has finished loading, you should see a console window
    6. In the console window, enter the following (assumes only one USB drive installed)
    "mkdir /mnt/flash"
    "mount /dev/sdf1 /mnt/flash"
    "cd /mnt/flash"
    "flashrom -r bios_image.bin -p internal" (flashrom should write the file to your usb drive)
    "flashrom -v bios_image.bin -p internal" (flashrom will verify the SPI contents to the file)
    "cd /"
    "umount /mnt/flash"
    7. Once you are finished, you can use the shutdown button, on the lower right
    side of the GUI, or type "shutdown now" on the console.
    8. The file will be on the top level of your USB drive.
    9. Then just remove the CD, boot to your normal OS, zip the file, and send it off :)

    One note, according to the users manual, for flashrom, it may complain if it
    detects that you are running on a laptop. Unfortunately, I do not have any way
    to confirm if it will run successfully on the G74SX. Since we are only reading the
    SPI, it should be fine. Reads between different masters, on the SPI bus, should be
    properly semaphored (EC vs processor code etc). If this is the case, we should be
    able to use the "−p internal:laptop=this_is_not_a_laptop" override.

    Thanks to anyone who is willing to give it a shot!

    Sir Robin
  5. svl7

    svl7 T|I

    Likes Received:
    Trophy Points:
    I'm not concerned about your serial... The issue is that you have a valid serial of someone else afterwards.
  6. evgasr2

    evgasr2 Notebook Deity

    Likes Received:
    Trophy Points:
    cant it be changed?
  7. Sir Robin

    Sir Robin Notebook Geek

    Likes Received:
    Trophy Points:
    I understand and share your concern. That was why I suggested PM rather
    than posting the image. Just on the outside chance, that they are doing
    something like that. My intention was to compare images, from at least
    two units, and see if any unique fields are present (outside of the BIOS
    variable storage areas). If present, I was going to try to decode the fields,
    and either null out the value, or reenter my original SN. Honestly, I am
    not convinced that Asus actually puts a unique serial number/service
    tag in each BIOS Flash. That has not been their practice, with other
    EFI based boards, with which I have experience,and they tend to avoid
    complication/cost. Adding a unique serial number, to each device manufactured,
    is a costly step, for a high volume OEM. It means either a serializing programmer,
    or a programming step, during integration testing. I did not notice any mention
    of a unique serial number, in the BIOS setup, or anywhere in their windows tools.
    It is possible that I overlooked it, however. I never went digging to find one.
    Other vendors (Toshiba, for instance), appear to provide a complete image file,
    suggesting that they do not rely on any pre-stored values in the flash (same basic design).
    It is possible that Asus chose to pre-program part of the flash, simply to avoid
    possible contention issues with the EC/ME, which are known problems, if not
    handled properly. It may have nothing to do with a unique serial number. I see from your
    other posts, that you have a great deal of experience, in this area. Can you confirm
    that Asus is indeed placing unique serial numbers/service tags, in the G74SX bios SPI?
    If so, can you provide an offset location and/or the storage format?

    Depends on the storage format. If it is encrypted, probably not, however, there may
    not be any checks to see if the field contains valid data, so nulling it out may be okay.
    If it is not encrypted, it should be something we can change. Changes should not mess
    up the BIOS checksum, since that section of code is a unique entity.

    Sir Robin
  8. Sir Robin

    Sir Robin Notebook Geek

    Likes Received:
    Trophy Points:
    Good news! :)

    I have figured out how to bring a G74SX back to life, after a failed
    BIOS update attempt. I will put together a guide, but in the mean time,
    for those who are in need, here are the basic steps:

    1. Gain access to the SPI ROM
    2. Using a SPI ISP programming adapter, or device programmer, read and store
    the bricked BIOS image (4MB, Winbond W25Q32)
    3. Download, from Asus, the BIOS update file, for the version that you were
    originally running, before the failed update attempt (V201 is on the driver
    CD, V202, V203 are on the download site).
    4. Using a hex editor, merge the two images as follows:
    Reconstructed_Image 0x0 - 0x17FFFF = Bricked_Image 0x0 - 0x17FFFF
    Reconstructed_Image 0x180000 - 0x3FFFFF = Update_Image 0x0 - 0x27FFFF
    5. Program the Reconstructed_Image into your SPI Flash
    6. Power-up or power cycle the laptop (your G74SX should be alive again)
    7. Enter BIOS setup, by pressing F2
    8. Select "Restore Defaults"
    9. Save and exit

    If you plan on reattempting the original BIOS update, be sure to follow this guide (using the
    Easy Flash method). Also be sure that Easy Flash correctly reports the image as being for the
    G74SX. If it fails to do so, abort the update (wrong buffer pointer problem):


    Some useful notes:

    1. I was wrong. Easy Flash does not erase the entire flash, during an update.
    It only replaces 0x180000 - 0x3FFFFF. The data in 0x0 - 0x17FFFF is essential to
    allow the system to boot properly. I was originally fooled by an incorrect assumption,
    I made early on, about where the update file was being placed.

    2. I have confirmed that Flashrom is not able to read the SPI flash on a G74SX,
    even with the override. The SPI accesses are terminated, with an error. I believe there
    is a way around this, but in it's current form, it is not a viable path to making a copy of
    your G74SX SPI flash. For non-laptop motherboards, it works quite well. For anyone who
    plans to play around with their BIOS, I suggest making an archival snapshot.

    3. 0x0 - 17FFFF is a locked region, on a working system (reserved for the ME, descriptors and some
    other stuff).

    4. During boot, the SPI flash occupies 0xFFC00000 - 0xFFFFFFFF of the processor address space.
    It is also aliased to other areas.

    Good luck, and let me know if this works for you,

    Sir Robin
  9. hackness

    hackness Notebook Deity

    Likes Received:
    Trophy Points:
    Does it mean you will be doing some soldering work as well?
  10. Sir Robin

    Sir Robin Notebook Geek

    Likes Received:
    Trophy Points:

    Soldering is certainly an option, for those who have already disassembled
    their unit, but may not be the best way to go, depending on your situation.
    For those who are willing to make a small "adjustment" to their
    internal shell wall, no soldering/dis-assembly is necessary, or recommended.
    The SPI flash is located on the bottom of the motherboard, just offset from
    one of the lower-cover retention tab holes. With care, an approx 3/4"x1/2"
    hole can be added to the plastic, without seriously impacting the structural
    strength of the panel (warning, the plastic cover is impregnated with metal,
    to act as an RF shield. You need to be very careful to avoid loosing shards
    into the circuitry). For this job, I used some patience, an Xacto knife,
    and a cardboard "debris catcher". Others might consider a soldering iron.
    It's hard on the tip, and the fumes are toxic, but with a little practice,
    you can cut a nice hole, without dropping any debris. To ISP read/program
    the flash, I used a Pomona SOIC-8 chip clip, tied to a Total Phase Aardvark.
    Total Phase includes a flash programming utility, for the Aardvark.
    The Aardvark is an overkill, for this application, and expensive. For
    those looking to setup their own ISP fixture, I would recommend
    a Bus Pirate, or one of the other inexpensive solutions based on USB-Serial
    controllers (FTDI, SI Labs, etc). There are also many inexpensive
    chip programmers available (Ebay). For those, just create a DIP-8 to
    Pomona clip adapter cable. Adapters using pogo-pins, also work well,
    but you need to hold them steady, while you're working with the device.
    I noticed that Flashrom supports the Bus Pirate. For those, with a Linux
    computer handy, it may be a good option (or use the Rescue CD).

    For those attempting this, be sure to only attach to the signal pins.
    Let the laptop provide the power. With the battery removed, the G74SX
    will apply 3.3V to the flash, whenever the AC brick is plugged in. As long
    as the system is not told to boot (button press) or is fully bricked, the
    chipset will not attempt to drive the SPI signals. I hooked a meter to the
    clip power/ground pins, so I could tell if the clip was attached properly.
    Avoid manipulating the clip, with the power on :)

    Good luck,

    Sir Robin
  11. hackness

    hackness Notebook Deity

    Likes Received:
    Trophy Points:
    Interesting, I should try it one day if mine is bricked too, it'll be a hardcore lesson for me as I haven't done any SPI programming before. Did you happen to take a picture of where you cut the hole?
  12. Sir Robin

    Sir Robin Notebook Geek

    Likes Received:
    Trophy Points:
    Yes, here is a good shot of the hole, and the surrounding area.
    You should be able find the spot, without too much effort. The
    DDR DIMMs are to the right. The drives are below the hole. The
    wireless adapter is too the left. I found the hole to be a little snug.
    It works fine, but it's not easy to see the pins, on the SPI flash,
    when attaching the clip. In hindsight, I would have made the hole
    slightly taller/wider, so I could better see around the clip, or added a
    side view hole (wall near the drive). With a little work, it would be easy
    to put together a long pogo-pin adapter. In that case, the hole size
    could be reduced.

    Sir Robin

    Attached Files:

  13. hackness

    hackness Notebook Deity

    Likes Received:
    Trophy Points:
    Ahh you mean without disassembly, I was thinking that you had to cut a hole on the motherboard :D. So if I do the SPI flashing after disassembled, I don't need to cut anything and just attach the device to the chip right?
  14. Sir Robin

    Sir Robin Notebook Geek

    Likes Received:
    Trophy Points:
    LOL! :)

    Right, but there may be an issue with powering the board? I have not
    tried powering a stand-alone G74SX motherboard. My guess is that it will
    work fine, but there is the possibility that the power/control logic has some
    dependency on the other parts of the system. It should be easy to test.
    Assuming the DC brick jack is mounted to the motherboard, you should be
    able to engage the DC plug, and see if 3.3V is delivered across pins 4 (GND)
    and 8 (3.3V), of the SPI device. If so, you should be good, on that front. If not,
    you either need to fix/bypass the dependency, or de-solder the part, and read/write it
    in a programmer. I do not recommend applying your own 3.3V power. Many
    motherboard chips are multi-voltage, and can be damaged if one supply is
    present, and not the others (you can, if there is an inline diode, or transistor,
    between the primary rail, and the device, but that is beyond the scope of
    what we're talking about here :) ) The other issue, that comes to mind, is
    SPI bus signal contention. You do not want to drive the signals (with the
    ISP adapter), if the chipset is also driving them. Most likely, the motherboard
    will power-up in a reset state, waiting for the user to press the power button.
    If this is the case, you should be able to read/modify the SPI flash without
    problems. If, for some reason, the motherboard attempts to access the SPI
    flash, once power is applied, you may have a problem accessing the flash,
    with the ISP adapter. In some cases, this can lead to damaged chips on
    the motherboard or ISP adapter. Holding the board in reset, if you can find
    the signal/button, should prevent this from being an issue. With an
    oscilloscope, you can easily determine if the motherboard is attempting to
    access the SPI flash, after power-up. If you try this, always read and verify,
    before attempting to change the SPI contents. Due to buggy programmer/ISP
    software, I recommend the following:

    1. Read the device contents into the programmer buffer
    2. Verify your read buffer against the device
    3. Save the file, in the desired format
    4. Clear the programmer read buffer
    5. Read the file back into the programmer buffer
    6. Verify your programmer buffer against the device
    7. If everything checks out, make a backup of the file, on another machine/drive

    Sir Robin
  15. Sir Robin

    Sir Robin Notebook Geek

    Likes Received:
    Trophy Points:
    I have been digging into how to make a complete backup
    of the SPI flash, on the motherboard. Since each unit may
    have a unique programming of offset 0x0 - 0x17FFFF, it is
    important that owners be able to make a backup image, in case
    something goes wrong with the device/data, once the unit
    is out of warranty. As I mentioned earlier, this section does not
    appear to be changed by Easyflash, during the update procedure, and
    is not included in the update files, provided by Asus. So, if you
    loose the data contained in 0x0 - 0x17FFFF, you have no way to
    recover it, short of an RMA. This data is critical, because it
    contains the descriptor tables, ME code, Ethernet firmware, and
    likely some manufacture specific data structures (serial number,
    model/assembly numbers, etc).

    I have reviewed many of the available tools. So far, I have not
    found anything that does a complete SPI flash snapshot. I have,
    however, found two tools, that will make an accurate backup of the
    0x180000 - 0x3FFFFF section. In essence, they create an equivalent
    of the Asus update file, with the added benefit of including you current
    BIOS setups (since the NVRAM sections are included in that range). Here
    are the tool names:

    AMI AFUDOS or AFUWIN Aptio version (I recommend this tool over the other)
    AMI | American Megatrends Inc. : AMIBIOS Support

    Universal BIOS Backup ToolKit 2.0
    (The best way to get this tool is to google it.)

    So why is this important? If you are into custom BIOS mods, this is
    an easy way to backup/distribute your tested BIOS. Also, if you have
    a complicated BIOS setup, this trick will store the setup along with the
    BIOS code. Here is my personal favorite reason. Because it fixes the
    disabled keyboard backlight issue :)

    Yep, the G74SX appears to be subject to the same problem as the
    G73 series. Somewhere, in the BIOS, there is a variable, that, if changed,
    causes the backlight support code to be skipped (lack of backlight display
    during Asus splash screen). This same code must be responsible for the
    ACPI entry, which tells the windows driver how to handle the Fn key press
    events. I suspect this is why windows can not recover the lights, once the
    variable is corrupted. I do not yet know the exact cause of the variable
    corruption, but I suspect it has something to do with uninstalling Asus
    apps, which talk to the ATK driver module. Here is a link to the G73 series
    thread, for reference:


    Gary's fix updates one of the BIOS variable locations, with a value that
    re-enables the keyboard backlight. At this time, I do not believe the
    G74SX uses the same location, so I would not suggest running Gary's
    fix on a G74SX. It may work, but so far, I don't see a similar variable in
    the G74SX snapshots.

    I will post the full keyboard backlight fix, in this thread:


    Here is the readers digest version. If you have working keyboard backlights,
    make a snapshot of the BIOS code now, using one of the above tools. If they
    ever become disabled, you can use Easyflash, to re-enable them with your
    backup copy of the BIOS code.


    Sir Robin
  16. mybouadani

    mybouadani Newbie

    Likes Received:
    Trophy Points:
    Dear Sir Robin,
    I have a bricked g74sx bbk8 after a failed bios update to version 203 from version 202.
    I am desperate to get the 4mb file to then look for an SPI ROM tool to put things back into the BIOS chip according to your instructions.
    Would you please help me
  17. Sir Robin

    Sir Robin Notebook Geek

    Likes Received:
    Trophy Points:
    Hi mybouadani,

    Sure, lets see if we can get your system going again :)

    First things first. If your unit is still under warranty, the easiest path
    to recovery is an RMA. There is a certain amount of hacking skill needed,
    to perform the reconstruction method. If you're comfortable with the concept,
    or up for a learning experience, then the reconstruction method may be a
    good option for you. If you are not comfortable with performing the
    operations, the reconstruction method may still be an option, if you have
    an open-minded repair shop, or friend, who can help you with the trickier

    This subject has been discussed, in more detail, in the following thread:


    I recommend you give it a look. It may answer some of your questions.

    The first and most important step, in the reconstruction method, is to
    make a full copy of your SPI flash device. To do this, you will either
    need to disassemble your laptop, or duplicate the access hole modification
    I showed above. If you choose to do the access hole change, be sure to
    capture all of the plastic debris. It contains metal shielding, which can
    lodge between pins, on your motherboard, and cause shorts. I used a
    combination of an Xacto knife, and a debris catching tray, to make the
    change. I also carefully vacuumed the area, after I was done. As mentioned
    earlier, a soldering iron can be used to cut the hole, without dropping debris.
    I would avoid Dremel or grinding tools, because it's too hard to catch all
    of the removed material.

    Once you have access to the SPI flash, you will need to rig up a
    device reader/programmer, to read the contents. I can provide an
    Aardvark cable definition, if you have access to one. Alternately, I have
    outline a Bus Pirate cable in the above mentioned link. You are not limited
    to those two options. There are many programmers/adapters available.
    My personal favorite is the Dediprog SF-100. It is fast and reliable, but
    very expensive, compared to other options:

    DediProg.com :: products

    Once we have a copy of your SPI flash, we can put together a reconstruction,
    that will hopefully bring your unit back to life.

    One other thing. I have a slightly different model than you. It is possible that
    Asus used different sized SPI devices, in the G74SX line. The size of the device
    will effect where we do the splicing.

    How do you plan to access the SPI device?

    Sir Robin
  18. Wozzzaaa

    Wozzzaaa Newbie

    Likes Received:
    Trophy Points:
    Thanks Sir Robin. Ive just fixed one of these for a customer. I had it already stripped, so it was easy to hex edit & splice the BIOS together. I used an external programmer, as I do this fairly often.

    I used a Smartpro 5000U with a SOIC8_W adapter.

    Ive got a copy of the 4mb Reconstructed BIOS if anybody wants one.
  19. Sir Robin

    Sir Robin Notebook Geek

    Likes Received:
    Trophy Points:
    That's fantastic news Wozzzaaa! :) Glad it worked for you, and
    thanks for posting your results + the tools you used! It really helps
    to know that the trick has worked for others. Do you recall the
    laptop family/model number, and SPI part number? I would like to start
    list of families/models that have been repaired, and their associated
    SPI flash sizes/splice offsets.

    Thanks again, for taking the time to post your results!

    Sir Robin
  20. Wozzzaaa

    Wozzzaaa Newbie

    Likes Received:
    Trophy Points:
    The SPI was a Winbond W25Q32BV SOIC 208mil. I dont have the laptop details on me now, but it was a G74S.

    The dump from the SPI was 4MB. The downloaded file from Asus was 2MB, I pasted it at offset 0x180000 - 0x3FFFFF using a hex editor to create a reconstructed image. I was thinking of flashing the Asus bios dirrectly to the SPI at that offset, but decided against it.

    First time it flashed correctly, however failed to verify. I erased the SPI completely and the next time it verified fine.

    Once the Asus fired up, I used easyflash to load the latest BIOS - 203.

    Got some crappy iphone photos and screencaps of the flashing.

Share This Page