So Long, and Thanks for All the Fish - Alexandre Boeglin's Web Page

Don't buy from Netgear. Ever.

alex@boeglin.org (Alexandre Boeglin) — Tue, 01 Dec 2020 19:11:16 GMT

So, after a long string of bad decisions, I ended up buying a pair of PLP1000 PLC (powerline communication) adapters from Netgear.

And Netgear support is just shit, these adapters have been known for having issues waking up from sleep mode for years, with many users complaining about it on the support forum, and absolutely no solution offered by Netgear.

Fortunately for me, they use Broadcom BCM60333 chips, and they're not the only ones. And, after a few hours of digging around and a few assumptions, I managed to find 2 devices that seemed close enough of the one I was trying to fix: one from D-Link and one from TP-Link.

From D-Link, I took DHP-P701AV_PLC_Utility_5.00_WIN.ZIP, which is kind enough not to have a whitelist of products it is willing to upgrade.

From TP-Link, I took the firmware of the TL-PA7010P v2, as it is using the same chip, and its release notes explicitly mentions fixing the power saving mode related issue.

Also, using an utility from Zyxel, another PLC adapter manufacturer, the PLP1000 firmware version showed up as 3.2.2, while TP-Link's firmware filename contained 3.2.4, so I was pretty confident they were only slight variations of Broadcom's reference design using the same SDK.

And that's it. Using D-Link's utility, I flashed PA7010P v2's firmware onto my adapters in a matter of minutes (and a bit of relief after seeing that the first one I flashed was not bricked ;) ).
They are now fully functional, including their LEDs an push button (which confirms they are based on the same reference design), are properly recognized and configurable by TP-Link utility as their own, I'm guessing they won't exhibit the issue any longer, and it seems they even synchronize at a higher rate than with the years old Netgear firmware they shipped with.

And that was the story of the last piece of equipment I ever bought from Netgear.
Fuck you very much, Netgear.

Flashing a BenQ Z-series for free(dom)

alex@boeglin.org (Alexandre Boeglin) — Sun, 27 Apr 2014 22:18:19 GMT

DISCLAIMER: If you attempt to reflash your screen's firmware, there is always a chance that something goes wrong, and that you end up with a very expensive brick. As always, I cannot be held responsible in this case.

Note: for support, please head to the Blur Busters forum topic at http://forums.blurbusters.com/viewtopic ... &t=779

Important Note: as you can see by reading the above forum topic, people have had mixed results, depending on the hardware they used. So if the update fails the first time you attempt it, don't panic, and simply retry it using a different desktop or laptop.

Update (2014-05-04): A new version of the patch is available, that removes the hardcoded path and address, and has better error messages. The article has been updated.

Update (2014-05-07): A new version of the patch is available, that adds a "noreset" option. When set, the reset command will not be sent at the end of the read/write operation. Furthermore, the reset command will also be skipped in the event an error occurred during the process. This aims to prevent bricking the screen, since the reset command seems to do more than just exit the ISP mode. Simply run flashrom in chip identification mode, without the reset option, after a successful flash, to exit the ISP mode.

I recently bought a XL2411Z screen, but it turned out that Blur Reduction, its "key selling feature", wasn't working properly.

BenQ then released a V2 firmware, but no instruction or tool allowing to reflash the firmware. The only available options were to buy a 50$ USB flasher, or to build a parallel port one, and use some proprietary and windows-only tool by MSTAR, the company that provides the chip used in these screens.

MSTAR offers no datasheet for their products, so buying a one-time use flasher wasn't really interesting, and building yet another parallel port adapter to use a completely obscure utility wasn't really challenging (even if I had the possibility to borrow a computer with a parallel port, this isn't necessarily everyone's case nowadays).

After a dozen of hours spent ~~googling~~duckduckgoing, during which I could only find service manuals for MSTAR-equipped TVs and screens that consisted of "plug the flasher, use our windows tool", I finally found some useful information on github, thanks to the Linux kernel being GPL: two different drivers for completely unrelated chips by MSTAR, but which seemed to use the same protocol for flashing a SPI flash through I2C: https://github.com/varunchitre15/MT6589_kernel_source/blob/master/mediatek/kernel/drivers/nfc/msr3110.c and https://github.com/Nikopol2013/canvas2-4.2.2/blob/master/mediatek/custom/common/kernel/touchpanel/msg2133_ps/msg2133_driver.c.

I then read a bit more about DDC, the I2C based protocol allowing to exchange information between screens and computers, and I guessed that since it uses I2C, and since MSTAR seem to provide a way to flash SPI flash chips through I2C for many of their products, there were good chances that the same protocol would also be exposed through the I2C bus used by DDC on my screen.

So, I decided to scan the I2C bus. I plugged the screen to my laptop using a VGA cable (so yeah, by the way, you'll need a PC or laptop running GNU/Linux, probably also a second screen (or remote shell) in the case it's a PC, since the one you'll be flashing has to be in standby mode during the operation, and the driver of your graphics card or chipset must register the DDC channel as an I2C bus to the Linux kernel. Intel and ATI hardware using the open source driver are OK, ATI proprietary driver is not as it doesn't expose I2C, I don't know about Nvidia open source or proprietary drivers), and ran the following commands:

alex@hadaly:~$ sudo modprobe i2c-dev
alex@hadaly:~$ sudo i2cdetect -l
i2c-0	i2c       	i915 gmbus ssc                  	I2C adapter
i2c-1	i2c       	i915 gmbus vga                  	I2C adapter
i2c-2	i2c       	i915 gmbus panel                	I2C adapter
i2c-3	i2c       	i915 gmbus dpc                  	I2C adapter
i2c-4	i2c       	i915 gmbus dpb                  	I2C adapter
i2c-5	i2c       	i915 gmbus dpd                  	I2C adapter
i2c-6	i2c       	DPDDC-B                         	I2C adapter
alex@hadaly:~$ sudo i2cdetect 1
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-1.
I will probe address range 0x03-0x77.
Continue? [Y/n] 
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- 37 -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- 49 -- -- -- -- -- -- 
50: 50 -- -- -- -- -- -- -- -- 59 -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --

Bingo! There were 4 I2C addresses responding. 0x37 and 0x50 are the "well known addresses" for DDC/CI and the EDID EEPROM, and as for 0x49 and 0x59, they are 7bit I2C addresses, which, when shifted for the R/W bit can also be represented as 0x92 and 0xb2, which appear in various service manuals of TV sets and monitors based on MSTAR chips (as well as in screenshots of the MSTAR ISP utility), and are described as 0x49/0x92 being the ISP (in-system programming) port, and 0x59/0xb2 being a debug port.

I then analyzed the two drivers that I mentioned earlier, and realized that the MSTAR ISP protocol is composed of 5 I2C commands (enable ISP, read/write, end r/w command, and reset) that merely encapsulate the SPI commands that can be found in the SPI flash chips' datasheets.

I then simply had to write a SPI programmer for the flashrom tool following the MSTAR I2C ISP protocol, and voilà!, moments later, I was flashing my screen's firmware.

The patch containing this SPI driver is available here: /static/benq/0001-Add-programmer-for-the-MSTAR-I2C-ISP-protocol.patch.

Also, please note that I2C works at 100kb/s, and thus, reading and writing the firmware takes a long time. Reading the 2MB takes 3 and a half minutes (and 8192 commands), and writing, which includes verifying afterwards, takes almost 10 minutes (and 32768 commands).

TL;DR:

# build
svn co svn://flashrom.org/flashrom/trunk@1846 flashrom
cd flashrom
wget -O- http://boeglin.org/static/benq/0001-Add-programmer-for-the-MSTAR-I2C-ISP-protocol.patch | patch -p1
make -j

# load i2c-dev driver
sudo modprobe i2c-dev

# list all i2c buses
sudo i2cdetect -l
# list i2c devices on bus 1
sudo i2cdetect 1
# get EDID (0x50) from bus 1
sudo i2cdump -r 0-127 1 0x50

# identify flash chip, on bus 1 (/dev/i2c-1) at address 0x49
sudo ./flashrom -p mstarddc_spi:dev=/dev/i2c-1:49

# dump current firmware
sudo ./flashrom -p mstarddc_spi:dev=/dev/i2c-1:49 -c "MX25L1605A/MX25L1606E" -r backup.bin

# extend firmware to 2MB, to match the flash chip size
tr '\000' '\377' < /dev/zero | dd of=firmware.bin bs=1k count=2k
dd if=XL2411Z_V2_20131209_8B72.BIN of=firmware.bin conv=notrunc

# write firmware
sudo ./flashrom -p mstarddc_spi:dev=/dev/i2c-1:49 -c "MX25L1605A/MX25L1606E" -w firmware.bin

Yet Another TV-B-Gone

alex@boeglin.org (Alexandre Boeglin) — Thu, 02 May 2013 17:58:48 GMT

Here's my quick and dirty version of the TV-B-Gone kit form Adafruit Industries, The open source version of Mitch Altman's TV-B-Gone.

This version is:
* derived from Firmware v1.2 sources
* ported MSP430 architecture
* tested on msp430g2452 and msp430g2211
* built from scrap parts

Following are a hand-drawn schematic and the accompanying "routing" diagram (note that there are a pull-up resistor and a pull-down capacitor missing on ¬RST, but the one on P1.3 is handled by P1REN):

You can have a look at the repository for my changes, its origin is the v1.2 sources.

There are currently three different branches:
* with_crystal_sync uses an external 32 KHz Xtal for clock calibration
* master uses the factory-calibrated values instead, eliminating the need for the external Xtal, and saving a few dozen bytes
* 8k_fill removes the debugging code to fill the 8 KB of ROM of the MSP430G2452 with as many TV codes as possible

Most of the changes are hardware related, and can be found in the following functions of main.c:
* main: clock setup, hardware configuration, main loop providing low power mode switching
* blast_code: timer setup for the carrier
* xmitCodeElement: output pin function selection depending on carrier usage

Note that I initially tried to use an interrupt to handle the carrier manually, instead of relying on the Capture/Compare Control Register, which turned out to not work so great, due to the delay function not accounting for the time spent in the interrupt handler.

Flashing a 2006 Mac Pro with a 2007 Mac Pro SMC Firmware

alex@boeglin.org (Alexandre Boeglin) — Wed, 09 Jan 2013 00:36:29 GMT

Disclaimer: This is totally unsupported! I won't be responsible if you Mac Pro catches fire or simply refuses to boot afterwards. I did the update on a 2006 Mac Pro, running the MP21.007F.B06 EFI firmware and 1.7f10 SMC firmware. Anything else, I can't guarantee.

Following MacEFIRom's work on his Mac Pro 2006-2007 Firmware Tool (you need to be registered to see the download link), here is a way to update the SMC, to complete the 2006-2007 conversion.

First, get the firmware update tool from Apple, at http://support.apple.com/kb/DL222 (md5 sum: 40c5e766f5b59c56501240f6cb732112).

Next, get the required resources from the included package/app:
- SmcFlasher.efi (md5 sum: 16d3c5337c0bfeb8549a034490617737);
- m43a.smc (md5 sum: 79aa57d97697860f70dbb37a1a6f7ee8).

SmcFlasher.efi is the EFI update tool, m43a.smc is the SMC firmware.

Then, using a hex editor, you'll have to modify the EFI updater, in order to bypass the hardware check (which prevents from flashing anything that doesn't follow the approved path).

Here's how a diff should look like. Sorry, but I won't host proprietary licensed binaries here.

Here is the list of modifications you have to make:
- at 0x1797, replace 5 bytes with "33 C0 90 90 90";
- at 0x17AC, replace 9 bytes with "90 90 90 90 90 90 90 90 90";
- at 0x1805, replace 5 bytes with "33 C0 40 90 90".

The first 5 bytes replace the call to the function that checks whether the upgrade path is approved by Apple (isValidConfig) by xor eax, eax; nop; nop; nop.
The next 9 bytes replace a comparison and a conditional jump (related to a global variable set by isValidConfig) by 9 nops.
And the last 5 bytes replace the call to the function that prevents from downgrading the SMC firmware by xor eax, eax; inc eax; nop; nop.

If you edited the file properly, its md5 sum should now be 84dbe9708eafc0c29653414b06292f8e.

In order to use it, copy the two files to a EFI accessible partition (FAT or HFS), boot to the EFI Shell, and simply issue the command:

SmcFlasher.efi -LoadApp m43a.smc

To boot the EFI Shell, simply install rEFIt. you can also take a shell.efi binary (for instance, from rEFIt's tools), rename it to boot.efi and copy it at the root of a FAT formatted USB key. You can then boot the key using the Mac Pro built-in boot selector (holding Alt before the chime).

And voilà, you're set. Simply turn off your Mac Pro, reset the SMC, restart it, and start partying like it's 2007!

Handling magnet URIs with w3m

alex@boeglin.org (Alexandre Boeglin) — Wed, 14 Mar 2012 20:49:17 GMT

Since The Pirate Bay moved from distributing torrent files to providing magnet links only, it became impractical to browse using w3m.
Here's a fix.

First, you'll need the following lines in your ~/.w3m/config file:

urimethodmap ~/.w3m/urimethodmap
cgi_bin ~/.w3m/cgi-bin

1st one points to a file that describes how to handle particular URI schemes.
2nd one points to a folder that will contain cgi scripts that w3m can handle on its own, acting as a HTTP server.

Then, you'll need to add a handler for magnet URIs in ~/.w3m/urimethodmap:

magnet: file:/cgi-bin/magnet.py?%s

And finally, a script that will handle the URIs, named ~/.w3m/cgi-bin/magnet.py:

#!/usr/bin/python
# coding=utf-8

import sys
import os
import subprocess

uri = os.environ.get('QUERY_STRING')
referer = os.environ.get('HTTP_REFERER')

if not uri:
    print
    print "Error: No URI"
    sys.exit()

cmd_list = ("transmission-remote", "-a", uri)

subprocess.call(cmd_list)

if referer:
    print "HTTP/1.1 303 See Other"
    print "Location: %s" % referer

Don't forget to chmod +x ~/.w3m/cgi-bin/magnet.py, modify the cmd_list tuple to match your host, port, and authentication parameters, and you should be set. Hitting "Enter" on a magnet link should now add it to your queue.

How to flash a PC 4870 for a Mac Pro, using only Mac OS X

alex@boeglin.org (Alexandre Boeglin) — Fri, 18 Sep 2009 01:17:02 GMT

This solution is so simple it will blow your mind away. Twice.

I have tested it on my 2006 Mac Pro, using a Sapphire 4870 with 512MB VRAM (early model, based on ATI's reference design). The machine is running Snow Leopard 10.6.1.

The test might be a little biased, as I originally installed Snow Leopard using the 4870 card. I only reflashed it with its original non-EFI BIOS for the purpose of this test.

You'll need the iMac Graphics Update 1.0.2 and Pacifist.

First, mount the graphics update image and use Pacifist to open it. You'll need to extract two files from here, using administrator privileges: ATIROMFlasher.kext and ATIFacelessFlash.app.

After extracting them, we'll first need to make sure the kext is able to load. Open a Terminal, and run "sudo kextutil -nt ATIROMFlasher.kext" to check whatever problems it might have.

On my system, it complained about authentication failures, and also showed a few warnings. The warnings can be ignored, but the auth issues have to be fixed, using those two commands: "sudo chown -R root:wheel ATIROMFlasher.kext" and "sudo chmod -R 644 ATIROMFlasher.kext".

Then, we'll remove the iMac firmwares from the archive: "sudo rm ATIFacelessFlash.app/Contents/Resources/*IMG" and add the correct firmware to the flash utility: "sudo cp 4870.ROM ATIFacelessFlash.app/Contents/Resources/".

Note: removing the other firmwares is only important if you have other ATI cards in your mac. When ran, the ATIFacelessFlash application looks for all files in the Resources directory, tries to find a match in your PCI devices, and when one is found, initiates the flashing. So it could "harm" one of your other ATI cards. And I don't know how it behaves with a 4870X2 card, *IF* it is seen by the system as two cards with the same ID, *BUT* each need a different firmware for the card to work fine. From a quick disassembly, I'd say that only the first one would be flashed.

Now, time to plug the PC 4870 card in your machine. I had it in the 1st PCI Excodess slot, with no display connected, and the 7300 GT that originally came with my Mac in the 3rd PCI Excodess slot, driving my display. I don't know if MacOS X can boot without any graphics card, but if it does, you could also use ssh instead of a second card, if you have a second machine available.

Restart your mac, and flash the card: "sudo kextload ATIROMFlasher.kext" (loads the interface to the card), "sudo open ATIFacelessFlash.app" (flashes the card. The app should appear in your Dock, wait for it to complete), "sudo kextunload ATIROMFlasher.kext" (unloads the interface).

Then reboot once more, and voilà, your 4870 is now a Mac card. No need to boot a FreeDOS CD, no need to create a FAT partition on your disks.

The Shitbot

alex@boeglin.org (Alexandre Boeglin) — Tue, 24 Mar 2009 22:02:26 GMT

The company I'm currently working for is regularly growing, and it happens more often than before that you go to the bathroom, only to find it already occupied by someone else.

Someone in the company pointed us to a post on meebo's blog where they described having the same issue, and the way they fixed it, but without any technical details. We of course agreed that it would be nice to have something like this, and I started to think about it.

Since I had an unused Linksys WRT54GL, the project should be based on it. Then, I went shoppping for a cheap motion sensor, which happened to behave as a switch : current passes when it's idle, and the circuit is broken for about one second when a motion is detected.

Since I didn't want to do massive polling, I decided to put an RS latch between the sensor and the motion detector. It ended up looking like this:

- the white part is the motion sensor,
- the green part is the RS latch and inverters I added
- the blue part is (probably) the Linksys PCB : GPIOs and hardwired component,
- the orange part is (probably) where the CPU is on the PCB, with its actual GPIO pins.

I "hijacked" GPIO3 (the amber light) and GPIO4 (the Cisco button) to interface the CPU and the RS latch, and this is how it works:

- when the system is idle, both R, S and Q are Low, GPIO4 and GPIO4_INT are high (just like when the Cisco button is not pressed),
- when some movement is detected, S becomes High for one second, Q becomes and stays High, and GPIO4 and GPIO4_INT become Low (just like they would when the button is pressed)
- when a GPIO3 is put to Low for a short moment, the LED blinks, R becomes High then Low again, but Q becomes and stays Low, and the system is back to idle mode (previously memorized movements are forgotten).

Basically, the goal is: once a movement is detected, it is memorized until a reset is sent.

I then did the soldering part, as can be seen on the two following pictures, and closed back the Linksys case (with a simple 3 pins connector added to its side, going to the sensor, for power supply and the switch-like output)

I finally built a simple kernel driver, compiled it using OpenWrt's build system, that creates a file in /proc. When the file is read, it returns "0" if no movement was detected since the last reset, and "1" otherwise.

Then, two simple CGI scripts were added to the mix to expose this /proc file through HTTP. As this device can act as a wireless client, talks HTTP, and does not require frequent polling, it can now be integrated with any intranet technology the company is or will be using.

A prebuilt binary package and a source package are available for the driver.

Update: Mac Pro AHCI hack

alex@boeglin.org (Alexandre Boeglin) — Tue, 24 Mar 2009 20:40:16 GMT

I recently received an email form Bela Lubkin, who pointed out some mistakes I made in my previous hack:

In grub-0.97_macrpro_esb2_ahci_stage1.patch, I happened to randomly notice a bug. (Ran across it while googling information to get my Dell notebook w/Ubuntu 8.10 to use ahci rather than ata_piix driver...)

The bug: you've moved the setup of the stack segment register (%ss) after the setup of the stack pointer (%sp). I don't have full context (didn't bother to find the stage1.S full file you're patching), so I don't know if it's OK that you are pushing %edx onto [%old-ss:$STAGE1_STACKSEG]. But probably not. But even worse is the "sti /* we're safe again */". Ancient 8086 mistake. You can't enable interrupts until the stack is setup correctly. Move the %ss setup code back to where it was.

I assume you moved it because you wanted to preserve the fact that %ax == 0 on exit of this bit of code. Well, I did find the grub 0.97 source to make sure: both %al and %ah are subsequently overwritten before being used. You don't have to preserve it.

You can save the whole push/pop %dx: find the comment "%dl may have been clobbered ...", move your code immediately before its `popw %dx; pushw %dx'. This does mean your hack isn't effective if grub is being booted from a floppy, but ... not a problem.

You can also save a few more code bytes. I assume this is being compiled as 16-bit (8086) code, e.g. with ".code16" GNU `as` directive. Thus, the instructions `push %edx' and `pop %edx' need a code32 prefix; replace with `push %dx; pop %dx'. Replace `mov $0xcfc,%dx' with `mov $0xfc,%dl'. Replace `xorl %eax,%eax' with `xor %ax,%ax'.

And he was even kind enough to send me a fix for these, so many thanks to him.

Here are links for the new patch he sent me, and an updated stage1 binary.

Enabling AHCI in legacy (BIOS) OS on a Mac Pro

alex@boeglin.org (Alexandre Boeglin) — Tue, 18 Dec 2007 20:28:38 GMT

The Mac Pro is a really nice workstation, which comes with the really nice EFI instead of BIOS.

EFI needs an adaptation layer (the Compatibility Support Module, or CSM) that emulates the BIOS, to be able to boot legacy OS, like Microsoft ones, or any GNU/Linux distribution without EFI support (which is nearly all of them, afaik).

Unfortunately, the CSM provided by apple does not contain an AHCI OpRom, and has to put the disk controller into IDE mode, instead of using the (also really nice) AHCI mode (whereas the controller's default mode is AHCI, and MacOSX uses this mode).

So far, Linux driver developers put the hack in the driver: when initialized, it puts back the controller to AHCI mode. But this does not work with other OS, so I had to put it at a lower level.

As Apple's EFI part of BootCamp is quite simple (just "chainloads" to a legacy bootloader), I decided to use the GNU GRUB to load legacy OS, and modified it to put back the controller in AHCI mode before any OS tries to load a driver for it.

Here is the patch, and here is a stage1 binary built from patched Grub 0.97 sources.

Please note that this is extremely ugly! As I didn't want to spend too much time on this, I decided to go the fastest way: adding the hack as x86 assembly in stage1. But as stage1 has a really strict size constraint (must fit in the first block), I had to remove some other hacks from it, to be able to add mine in.

UPDATE: This OnMac.net forum thread contains a bit more detailled information on how to set this up.

IMPORTANT UPDATE: The patch posted here contains a few mistakes (the binary has been updated, and includes fixes). For a fixed version of the patch, please read this blog entry.

Intel 8051 control flow graph generator

alex@boeglin.org (Alexandre Boeglin) — Tue, 11 Dec 2007 20:51:56 GMT

Here is a script I wrote about two years ago, that produces a graph (using Graphviz) of branches and calls from a 8051 hex file, disassembled with Dis51. This µC can be found, for instance, in Cypress USB bridges, that load the firmware from USB when the device is plugged in, and are used for many kinds of applications (I have a DSL modem and a TV tuner that use them, for instance).

It can be used like this:

dis51 -l [entrypoints list] < firmware.hex > firmware.a51
python graphviz_generator.py firmware.a51 [entrypoints list] > graph.gv
dot -Tgif graph.gv > firmware_graph.gif

("entrypoints list" being a list of whitespace separated addresses, like "0x0000 0x0010", without the quotes)

The graph will look as follows:

- Red circles are functions (branches that update the stack pointer)
- Grey circles are RET statements (end of functions, also modify the SP)
- Blue circles are entrypoints
- Squares are normal branch instruction
- plain lines mean the branch is always taken (or when the branch condition is false)
- dashed lines mean the branch is taken if the branch condition is true (JZ, JNZ ...)
- red dashed lines mean a function call

As a small picture usually talks more than a long text, so here is a really BIG picture.

And finally, the script.