Tuesday, 22 November 2016

Updating DVD drive firmware

I recently  tried to watch a few DVD's with the drive in my computer. That didn't work so well; towards the end of the "file" was the drive not able to read the frames any more. Maybe this has something to do with the second layer on the disk or something with the security on a DVD.
But anyhow I thought it was maybe a good thing to try to update the firmware  of the DVD drive to see if that helps.

I have, as Linux advertises, a HL-DT-ST DVDRAM GSA-H12N in my linux computer. This is relative old LG made drive with a Pata interface that can read and write DVDs next to CDs.

 Looking for a firmware upgrade showed only a windows utilities for firmware upgrades. The new firmware was packed in "GSAH12N_UL02.exe".  I couldn't get it working under Freedos, because it explicitly needed windows. And with wine I only got an error message / no response at all. But I had not much confidence in wine for this hardware job, which made that I started to do some Google search.
This question on launchpad gave me a hint how I could get it working. I did needed to install the mfc42.dll with help of winetricks.

Then I only needed to do the following to update the firmware:

sudo chown -R root ~/.wine
sudo wine GSAH12N_UL02.exe
sudo chown -R $USER:$USER ~/.wine

I did had to add a disk to the drive to make sure that the windows program could find it.

After the reboot is my DVD drive indeed advertising the higher firmware number UL01 is now UL02. However I am still not able to read the complete DVD. That will be the next thing to sort-out.

Saturday, 12 November 2016

Kid's stuff

Just a small update: for our daughter's birthday party, we needed two large puzzles with a toolchest-y theme. The idea being that the kids will search for, and hopefully find, the various pieces and put them together to win a price.

So I took a bit of scrap triplex left from some home improvement job, cut it in half, an traced a bunch of my tools. First in pencil to make sure I got the contours right, and then in black marker. After that, I took the electric jigsaw and cut the pieces. Note 1: when making multiple puzzles, mark pieces on the back to know which puzzle it belongs to. Note 2: be careful when cutting, as an electric jigsaw cuts straight through metal workbench parts...

After that I sanded the edges and my wife added a bit of colour. And finally the kids liked the puzzles, so all in all another successful little project!

The puzzle before cutting it into pieces. I traced a few of my tools in pencil, and then used a permanent marker to make it, well, permanent.

And the other one, as we needed two... Notice the differences.

After cutting and painting number 1...

...and two.

Sunday, 2 October 2016

Finding a use for an obsolete tablet: part 1 - resurrection

Somewhere in the year 2012 I thought buying a cheapish Chinese android based tablet was a good idea. My wife just got her first iPad, and I was curious what sort of tablet €85 would get me. From a tablet point of view this turned out as somewhat of a disappointment, or rather, it would have been a disappointment if I would have expected to get a useable tablet.

Looking at it from the hackable Linux device perspective it was actually quite okay. It came with a 7" 800x480 colour LCD, ethernet, WiFi, serial port, microphone, speakers, camera, two USB ports, 2Gb flash, a micro SD port, and a resistive (i.e. single touch) touchscreen digitiser. On top of that it had a rechargeable battery that would sustain the thing for about two hours. And all this rather underpowered by a 300MHz ARM processor and 128Mb of ram.
The tablet came with this dongle. On this side I hacked a serial port. On the other side, there are two USB2 ports. And on the left side, there is an UTP plug for ethernet.
Unfortunately, I started with trying different versions of Android based firmware. A firmware upgrade consisted of downloading a zip, extracting to SD card, and booting the tablet with the SD in it. Apart from a new android kernel and rootfs, all these firmware updates always included an update for w-boot and u-boot as well. These were the pre-bootloader and main bootloader respectively. At a certain moment I left the SD card in when I hadn't meant to, booted, noticed my mistake, yanked the card out, and corrupted either w-boot or u-boot. As a result, the tablet would not boot anymore, and I had made myself a fancy paperweight.

At the time, I looked into fixing this. The bootloaders are stored in a spi flash chip, while the rest of the software lives in another set of flash chips. So I hooked my buspirate to the spi flash and tried to access it in circuit. This was ultimately unsuccessful: while I could read the flash chip id, the rest of the tablet's circuitry a somehow prevented me from writing or even reliably reading the chip's contents. I decided that I would have to desolder the chip to continue, and that I had more important things to. 
Attempt at in-situ programming of the spi flash chip.

So I put the tablet in its box and more or less forgot about it for a couple of years.

Recently I came across it again while looking for something else. I then saw connection points for a JTAG interface. These I had noticed before, but at the time I did not have anything to interface with JTAG. But now it seemed that, with a firmware update, my buspirate and openocd could be made to do this.

So I soldered a connector to the JTAG interface, hooked it to my buspirate and tried openocd. I quickly found that openocd needs some kind of description of the item on the other side of the JTAG to work. This makes sense as designing such a hardware debug interface, with a very limited number of users, for  "plug and play" would be a serious waste of effort. Unfortunately the tablet was based on a wondermedia WM8505-board that was unknown to openocd.

JTAG header added to tablet. GND is hooked to the spi flash ground pin. And I stuck a description of the pins to the inside of the tablet case, for future reference.
This meant I had to make my own definition file, while discovering how openocd actually works. I could find a single post on a forum of someone who had done the same or similar, but that post did not have much detail. But fortunately, it all proved relatively straightforward. When I connected the board, only a single JTAG tap (something like a client or receiver) was found, so this had to be the processor. And by now I knew that the WM8505 had an ARM926ej-s core, for which openocd already had a definition file. So after some experimenting, I could halt the processor on the tablet, dump/change its registers and other state, and make it do anything I want.

For those in need of this, here is the definition file I cobbled together:
# Barebones openocd definition file for WM8505
# not sure if this actually works
jtag_rclk 3000

# WM8505 SoC
jtag newtap WM cpu -irlen 4 -expected-id 0x07926f0f

target create CPU arm926ejs -chain-position WM.cpu

# no hard reset, use soft reset
CPU configure -event reset-assert  { jtag arp_init }

# Work area in ram: last 8k from 128M
CPU configure -work-area-phys 0x07ffe000 -work-area-size 0x4000

arm7_9 dcc_downloads enable
arm7_9 fast_memory_access enable

reset_config trst_only
Next step was to load a copy of u-boot via JTAG into the tablet's ram, and run it. From there, I could take control of u-boot via the serial interface, and use that to flash both u-boot and w-boot from the SD card into the spi rom. But first I hit a small snag: the first 6 or so u-boot versions I tried all seemed to work, but then shut down the tablet. Fortunately, the 7th version did give me a prompt, and I could fix the corrupted spi flash. 

(I later discovered that the other u-boot copies were actually fine: what happened was that these checked the state of the power-button. If the button was pressed for about 1 second, the boot process would continue. If not, the tablet would power down. As u-boot is (almost) the first thing to run when the tablet is powered on, this would prevent accidental turning on of the tablet. But in my JTAG case, the power button was always off, so u-boot would power down the tablet.)

After fixing the spi flash, it was also possible again to update the original android firmware in nand flash. However, I had difficulties finding a correct one. For starters I  was and am not 100% sure which exact model of tablet I have. Many variants with minor differences in hardware existed, and firmwares of other models would sort-of work on mine, but with some features (i.e. touchscreen or audio) missing. And most firmware versions originally were on download sites that either no longer exist, or do not have the files anymore. Some of the versions that I could find did boot and show something but I could not get the touchscreen to work.

Success! Notice the low-glare screen on this high quality product.
So I decided to forget about android, and install a plain Debian Linux on the tablet. But that will be the subject of another post.

Monday, 19 September 2016

Bathroom ventilator upgrade/repair

This was intended to be a simple job involving nothing but simple mechanics and a bit of electrical wiring.


The ventilator. Just in case you were wondering...
The ventilator. Just in case you were wondering...
Some years ago we had a new ventilator installed in our bathroom. This was a smart fan with a moisture sensor. So if someone was running the shower, the air would get moist, the fan would switch on and extract the air towards outside. As an extra, the unit also had a set of little flaps (a more to the point word probably exists in English) that automatically open and close when the fan starts or stops, and an indicator light, because everyone needs an indicator light.

From the start this thing had the problem of being quite loud. The other family members very much preferred it to stay off while relaxing in the bath. Over time their wish was gradually granted as the fan got more and more slow and finally stopped turning altogether.

Naturally I took the thing apart and checked the motor. Even when hooking it up to mains directly (and yes, it was a 240V part) it did not run anymore. So I got thinking what to do next.

A simple plan

Since the warranty had already run out by a few weeks (duh), I was free to do what I wanted. I figured I could install a new fan as far away from the bathroom as possible in the exhaust chimney thingy on top of the bathroom's roof. So I bought a simple 240V on/off ventilator of similar wattage as the old fan that fitted in the chimney pipe. I would run the wire through the pipe, hook it up to the ventilator controller, and Bob would be my uncle. Easy.

But Murphy was not to be outdone by Bob. While I was thinking this through, buying the ventilator and planning this job, the old ventilator unit failed completely. The flaps no longer opened and the little indicator light stayed dark when running the shower. 

Circuit debugging

The circuit. Note the triac (next to the lamp), and the yellow filtering cap.
The circuit. Note the triac (next to the lamp),
and the yellow filtering cap.
Since I lost the receipt of the new-bought fan, I could not return it to the shop. What was left was to take a good look at the controller circuit. It was pretty simple. It had a triac to switch the mains, a moisture sensor, two adjustable potmeters, a few transistors, diodes and resistors. The transistors were there to get a lower voltage from the mains (I think) and switch the triac when the moisture sensor's resistance would fall below one of the potentiometers. (The other potmeter controlled the time the fan would run before switching off.)

While I am not the most experienced circuit debugger, I know it involves sticking a multimeter in a live circuit. But since this circuit is directly hooked to mains, I would be competing for a Darwin award that way. So I had to try to figure this out without power.

I knew for a fact that the old fan had failed. I also knew that a non-turning motor can draw 2 to 3 times the current compared to when it runs normally. This could potentially overload the controller, causing something to fail.

The only semiconductor in the "240V on" part of the circuit was the Z0103 triac. Some probing with my multimeter also seemed to suggest it was not 100% happy anymore. So I ordered a replacement and let things rest until the new part arrived.

Replacing the triac made the light come back on and the shutters work again! Success! So I did a little dance, kissed my wife, and connected the new fan motor. Disappointment! It showed the same not-really-turning-over behaviour as the old one did towards its end. Clearly something was still wrong with the controller board.

More circuit debugging

Further poking around identified another component in the 240V part of the system: a 0.22μF filter capacitor. For lack of a better idea I took it off and put it in my little component tester: 33nF, about a factor 7 too low. So I ordered a replacement and put the whole lot aside while waiting for the mail.
After I soldered the new cap in the circuit, the new motor ran smoothly. Hurray! So I finally was ready to start installing the new fan.
It works! Note the piece of paper lifted by the air flow, the new orange capacitor peeking through, and the flange still being attached to the new fan.
It works! Note the piece of paper lifted by the air flow, the new orange
capacitor peeking through, and the flange still being attached to the new fan.

First step was to remove the old fan from the ventilator housing and change the wiring a bit. While messing with the circuit I had removed the original connectors since they seemed flaky, so everything is now either soldered or attached with screw terminals.

The fan attached to the (upside-down) chimney top. Note the two bolts that just allow the fan to turn.
The fan attached to the (upside-down) chimney top.
Note the two bolts that just allow the fan to turn.
Next step was installing the new fan. In principle the new fan just fitted in the top part of the chimney, except that it had a flange. While very useful for the scenario where I would do what the installation instructions say, I was not planning to do that. Fortunately a plastic flange is no match for me and my hacksaw.

I then drilled two holes through the chimney top and the pipe around the fan, while taking care not to get in the way of the fan blades. Through the holes went two flat head bolts, and on the bolts went two nuts that I secured with a tiny drip of super glue. The top actually has an inner and an outer pipe. The inner one goes inside the chimney, while the outer sits on the outside. The fan is bolted to the inner pipe. The heads of the bolts were flat enough not to stop the top to go inside the chimney pipe. So I ran the wire through the chimney, put the top back on the roof, and went downstairs into the bathroom to hook things up.

Inside, things were straightforward in concept. But trying to get a bunch of wires to fit under the cover, the cover to be against the ceiling, 4 screws to through 4 holes, and somehow have a hand left over to fasten the screws above my head was somewhat tricky to say the least. And of course I had to repeat the exercise because I found I had to tweak the two potmeters a bit after the first test run.

But all is well that ends well. The ventilator works again, and is noticeably more quiet than before. However, in the future I might still add a switch so my wife can enjoy her bath in absolute silence if she is so inclined.

Some more photos

The orignal (non-working) fan. The brown part in the front-right is a bi-metal actuator to open the flaps.
The orignal (non-working) fan. The brown part in the front-right is a bi-metal actuator to open the flaps.

Good cap.
Good cap.

Bad cap.
Bad cap.

Removed the original fan. Note the feed-through for the  new fan's wire fixed in place with some hot glue.
Removed the original fan. Note the feed-through for the
new fan's wire fixed in place with some hot glue.

The new fan in the upside-down chimney top. The wire will run through the chimney pipe and connect to the controller in the orignal casing.
The new fan in the upside-down chimney top. The wire will run
through the chimney pipe and connect to the controller in the orignal casing.

The chimney top back where it belongs. Nothing to see here, folks!
The chimney top back where it belongs. Nothing to see here, folks!

Tuesday, 23 August 2016

Internet away from home

Nowadays on holidays we bring with us about 6 WiFi capable devices just for our little family. Make it a more extended group and we pass the 10 device mark easily. All these pieces of kit expect, or at least work better with, a connection to the internet. Fortunately, WiFi internet is available at most holiday parks, hotels and campsites in 2016. However, typically you get a password that allows a single device (or a few more) for a certain amount of Euros. Sharing this directly across this many devices is quite a hassle.

A few years ago, I bought a couple of TP-Link WR703N travelling routers on eBay. These come with a 2.4 GHz WiFi radio, an 10/100mbit Ethernet port and an USB2 port. Originally, I intended to repurpose them as network enabled things, but I could use them as travel router as well! For this, I put the latest and greatest Openwrt firmware on one, naturally with a few modifications. I also added an external pigtail antenna in place of the original internal one, as described here

The essentials of the external antenna hack. I later redid the soldering much neater than is shown here😉.

The Openwrt modifications are basically a default /etc/passwd file, an /etc/config/wireless file and a change of the failsafe control flow so that failsafe automatically triggers a firmware reset. In this way, when I press the little reset button, it restores the router to a state where I can connect to a known WiFi network and login with a known password. Normally the reset button in Openwrt triggers a default failsafe mode that only allows a login over Ethernet, but that is not really helping when I only have my phone with me.

As said, this router comes with a single radio, but it can do a combined access point and client mode. In this way, the router connects to the internet via WiFi client mode, and all WiFi devices connect to the router access point as clients. The router then uses NAT to forward the clients over WiFi to the internet.

Unfortunately, there is a problem with this scenario when the router tries to connect as a client but fails. For example because the WiFi network disappeared altogether, or is 300km away (not unlikely given the usage scenario for this device), or because of a simple typo. If this happens, then somewhere in the combined WiFi driver, kernel network layer, and Openwrt WiFi-controlling daemon stack things get stuck such that the access point interface of the WiFi radio never goes up. This is clearly a bug, because a simple ifconfig down wlanX ; ifconfig up wlanX for the access point part of the interface fixes things.
While I definitely would like to get to the bottom of this someday, for now I put the following script in crontab as a bandaid:
for W in $(ubus  call network.wireless status | jsonfilter -e '@.*.interfaces[@.config.mode="ap"].ifname'); do
  if [ x$(ubus call network.device status | jsonfilter -e "@['$W'].up") = "xtrue" ] && ! iw $W info | grep -q ssid ; then
    ifconfig $W down
    logger -p daemon.info -t $0 poked $W
    ifconfig $W up
exit 0
This script finds all wireless interfaces in access point ("ap") mode, filters the ones that are up according to Openwrt but not according to the kernel (no ssid), and gives them a gentle nudge. By running this script every 5 minutes the access point WiFi is restored in this case without the need to press the reset button.

The project was finished by adding a sticker with a QR code for the access point network, and a RFID tag with the same. In that way people can simply tap their phone on the router, or scan the QR to connect. And yes, I also added the WiFi name and password in human-readible format, as a less impressive option.

So far the router is doing well, but I found that some WiFi networks intentionally or by accident drop the connection after some time, even if I try to keep it going with a wget job in crontab. In these cases it helps a bit to have a second radio because that makes the access point less sensitive to trouble on the internet side. The exact reason for this dropping the connection is unfortunately too hard to diagnose with only my phone to make connections (holidays, remember).
Router in action. Here I use an additional USB wifi stick to try to fix/diagnose a problem with the local internet access.

Wednesday, 10 August 2016

My home network

Over the years I have build a network of computers at my house that, when I explain it to others, seems a bit over the top . But please let me share it with you for entertainment and possible inspiration.

At the base of all computers is a TP-Link WDR4300 router running Openwrt. It is the firewall, DNS and DHCP server, and WiFi access point. On the first floor, a TP-Link TL-WR1043ND serves as an additional access point and Ethernet switch. Apart from our home WiFi network they also have a guest network, used by a.o. guests (duh), my employer's laptop and the family Wii. The guest network is shared between the two routers using a separate VLAN, providing isolation at the Ethernet level.

Partnering with the routers for core services is "shoebox", a by now venerable server running Ubuntu. It is based on an Intel D945GCLF2 mainboard with a dual core Atom processor and 1Gb of ram. For storage it has two 3Tb Toshiba/Hitachi drives in raid1 and two USB disks for additional storage.

Shoebox provides a few core functions: it acts as a CUPS server for our printer, it provides general network storage via SAMBA, it is used by duplicity/dejadup for storing backups of other systems, it pretends to be an Apple server so my wife's Macbook can do timemachine backups, it has NFS for netbooting, and it runs mythtv.

Now that we have the likes of Netflix, the added value of mythtv seems limited. And I probably would not bother getting it to work if I would start today. But since it is there, it now records whatever we would like to watch on TV using two dvb-c tuners. In our house, we are all used to watch what we want when we want it, and skip over those annoying commercials. And it has essentially been like that for the past 12 years or so (except that I switched from analog to digital tuners 6 years ago).

For watching TV in the living room, there is an ion2 based mini-ITX system that netboots off shoebox and runs the mythtv front-end on mythbuntu. In the bedroom, a RPi2 with kodi/openelec serves a similar purpose. Also this one stores its data on shoebox. Using NFS for these front-ends makes them far more robust for the kind of power cycling that happens when family members are dissatisfied with performance.

The last part of the infrastructure is my backup machine. That one is where harddisks go to spent their final years. The system runs off a compact flash card in an IDE to flash convertor, and currently has 6 disks providing about 6TB of raid1 btrfs storage (so 12 TB raw). By he way, I have become a believer in Asian brands of harddisks. I have had the same 8 Samsung, Toshiba and Hitachi disks running for many years without problems, while, in my perhaps limited experience, Maxtor, WD and Seagate start having problems after 2-3 years.

The backup machine is normally switched off. All other computers actually make their backups on shoebox. A script on shoebox wakes the backup machine and then uses rsync to backup data from shoebox to the backup system. When done, it again powers down the backup machine, after making a btrfs snapshot. Once I finish the snapshot retiring/removal code that should run on the backup machine, I will put the backup script in a cron job. For now it is manually triggered. And for the future I am also dreaming about making some kind of shared backup over the internet with my brother or parents, so that we all have an off site backup as well.
I could add many more details to this story but I will save that for another day.

Tuesday, 19 July 2016

Upgrading WiFi on a Lenovo Ideapad Y500

I have been the happy owner of a Lenovo Ideapad Y500 laptop for a few years now. Recently I noticed that 5 GHz dual band WiFi cards are getting really cheap on eBay. Because my laptop only had a 2.4 GHz WiFi adaptor, and there are about 40 neighbours competing for a 2.4 GHz signal in my living room, I figured the time had come to get a new WiFi card.

While Lenovo uses standard mini-PCIe WiFi adaptors in this laptop, they combine it with a thing called a whitelist, apparently to prevent me as a so-far happy owner from turning this laptop into an illegal radio device. Unfortunately this would also force me to only use the hard-to-get Lenovo-approved WiFi cards, instead of better and much cheaper alternatives. But fortunately the whitelist is stored in the BIOS of the laptop, and the BIOS is stored in a flash chip. So in principle, I could change it.

A quick search across the Internet found an extensive community of people dealing with the whitelist phenomenon. There even was a hint of a tool to automatically patch a BIOS dump and generate a new version ready for flashing. But to make things more interesting, after googling every relevant term I could think of, I had to accept that it was not available as an easy download for me. My next plan was to get a dump of the BIOS and patch that myself to make it behave. 

Conceptually, this whitelist-thing can be fixed in two ways: make the computer ignore it, or put my new WiFi card on the list. As these things go, the former is the nicest and the latter the easiest. Removing the whitelist would need figuring out where the code sits that checks hardware against the whitelist and bypass it. This would have taken some serious effort with IDA, which I hadn't touched for years.  Changing the whitelist itself is potentially easier, assuming that the check is done against PCI IDs. But my Internet search had already turned up that this was the case, so in principle an s/APPROVED_ID/MY_ID/ would be all that was needed.

Getting the BIOS dump itself was straightforward using something called fpt.exe in FreeDOS. Unfortunately, since the 80s, BIOSes are compressed and checksummed and whatnot, so a tool is needed to deal with this before modifications can be made. The good news here is that such a tool exists: PhoenixTool.exe a.k.a. Andy's tool. The less good news: it errors out under wine, so we need a real Windows. The only copy of Windows in my house spends its marginal existence on a small part of the harddisk of the Lenovo laptop, only to be woken in cases of need like this one.

After an hour of overdue updating Windows, I downloaded PhoenixTool. Using it I managed to extract a MOD (essentially a BIOS section) file that contained the whitelist. After matching a list of Lenovo-approved cards and their PCI IDs against the bytes in the file, I knew what to change and where. 

After a few weeks of waiting, the new WiFi card fell on my doormat, fresh from China. I inserted the card in a mini-PCIe  to PCIe converter, put that in my desktop computer and used lspci to get the PCI IDs of the new card. Both the system and subsystem IDs were needed.

lspci data of the new WiFi card: ID=8086:08b1/8086:4160.

Using Jeex, I patched the IDs of a card that I do not own with the new one in the whitelist. I left in the ID of card that came with the laptop alone, just in case. Then back to Windows and PhoenixTool to replace the original mod with the hopefully improved one. After the replacement step, PhoenixTool had made a backup of my original BIOS file ("biosback.bin.old") and had minted a new "biosback.bin". 

Flashing the new BIOS proved tricky, as some kind of flash write protection was enabled and fpt.exe failed to update my new BIOS. The solution was using "prr.exe" that removed the protection. The next fpt run reported everything a-ok, so I hit the power button to switch off (FreeDOS, remember).

After restarting the laptop I went from a feeling of enthusiasm and suspense, via mild alarm, to full panic within a time span of about ten seconds. After the initial boot, the keyboard backlight switched off, the screen stayed blank and the fan started spinning at full speed. The only response of the laptop was a shrill beep when I removed the power plug, and the same beep when I put it back in. Bricked as it is called.

Some searching revealed that these laptops have a recovery mode ("Hurray"). The procedure to follow here is to remove the battery, unplug the power brick, insert an USB stick with a replacement BIOS image, press and hold a magic key combination, plug in the power brick, press the power button and only release the magic keys after 6 seconds or so. Important additional information here is what key combination, and what to name the replacement BIOS image. Searching the Internet revealed that the most likely  key-combo for a Lenovo ideapad laptop would be Fn+R. The name of the BIOS image was a bit more tricky. 

When loading the BIOS image in PhoenixTool before, a dialog box popped up stating something about recovery. At the time I did not know nor care, so I just clicked it away. As it turned out, this was crucial information for recovering from a bad flash: it was the name of the recovery BIOS image file! Now please remember that this laptop was the only computer capable of running windows in my house, so I had no way to run PhoenixTool.

Fortunately I am often a bit stupid, but I do have my moments. Before flashing the BIOS, I had copied all files related to this adventure to another system. And one of these was a log-file generated by the PhoenixTool. Somewhere in there it stated "Recovery Filenames are: QIWY3.bi?". Yoohooo!

So I got an official Lenovo BIOS update file for this laptop, I managed to extract a rom-file from the .exe, put it on a FAT-formatted USB stick as qiwy3.bin, plugged the stick in the laptop, and followed the recovery procedure. And oh joy, the light on the USB stick flashed, there was a pause, and then a series of long flashes, consistent with reading a large file from the stick. After that there was a few seconds pause, and the laptop rebooted..... And it was still stuck. I gave it one more try and got the same results. Time to think things through.

By now, I knew I could start the recovery, that the USB stick was recognised, and that the BIOS image file was read (most likely). So the observed behaviour was consistent with an invalid BIOS image. After reading, it would be checksummed or otherwise verified (the few seconds pause), it would be rejected, and the flashing code would reboot the laptop.

So another BIOS image was needed. But the one I tried was from the manufacturer's website, and I had no way to get something else. Except for the original BIOS image that I started with, that is. So I tried that one, and... success! I had a working laptop again. And, for future experiments, I had a proven method to recover from a bad flash. So all in all this counted as a victory of sorts.

The next step was to figure out what went wrong with patching my BIOS. More searching on the Internet was sometimes confusing (for example: "Never start from a BIOS dump" according to one expert, "Start from a BIOS dump" according to another). But it turned out that my approach of editing mod files was somehow wrong. The proven way to make the modifications was to have PhoenixTool split the BIOS image into ROM-files, modify these, and let it reassemble the BIOS again from the ROM files. 

Once I figured this out, everything went smooth. I found the ROM file to patch, made the change, let PhoenixTool reassemble the BIOS, flashed it, and everything worked as it should. The new WiFi card reaches 300 MBps at 5GHz, and even gets better speeds than the original card in the 2.4GHz band. And I got this nice experience to share with you on this blog.

So in the end, I consider this a success...

(I am thinking about adding Tux as a boot logo, but for now I decided to keep things as they are.)