Tuesday, November 19, 2013

Supermicro BIOS Shenanigans

Let me take you on a small journey. You receive a large number of Supermicro workstations with X9SRG-F boards. You get them connected and racked up, try to install something and the keyboard doesn't work. You try another, same thing.

OK, it's a USB keyboard, maybe there is a problem with the BIOS reading USB, I'll just plug in a PS/2 keyboard. Oh there isn't a PS/2 port on this board. Right lets try IPMI to get into the BIOS using the console. Great, this works, but you cannot mount any USB devices at all. I'll just plug in a SATA drive and get the BIOS flashed to see if it's something up with the BIOS.

I download the latest (X9SRG3_801) and only version available on the Supermicro website which doesn't come with any release notes whatsoever. I'm sure this version will fix it, it's the latest right? I boot a DOS boot CD, loaded with the update and flash the BIOS (and IPMI). Reboot.....F9 BIOS error code. This means the main BIOS block is corrupt. In this instance you need to recover the BIOS by renaming the BIOS file to SUPER.ROM, place it on the root drive of a FAT32/16/12 formatted USB flash drive and hold down Ctrl+Home on the keyboard when the machine turns on.

After recovering via the recovery option screen, this would still not get past the above error once rebooted, so I can only surmise that the latest BIOS version is to blame. Unfortunately Supermicro doesn't release older versions on their site, you have to email support to get these. Although, you can use Wayback machine to view the cached version of the BIOS download page, to obtain older versions (click the date you think is right, go through the agreement and then modify the link when it cannot find the file). I downloaded the previous version (X9SRG3_306) and recovered with this instead.

It works! The BIOS "recovered"....but USB devices nor SATA devices would detect after the update.

So now this machine doesn't boot from any device and it just goes straight into the BIOS. Triple checking through and trying different BIOS options didn't help. But there is a "dxe bs driver unrecognised" error in the BIOS log (BS indeed).

By the looks of things this board is well and truly toast. The only thing I can sum up is that the BIOS startup block and the main block are mismatched and causing issues (the recovery mode only flashes the main block). I spoke to our distributor and they said just RMA it. But we don't have time to do this as these machines need to go into service and I cannot trust any updates at this time to work on the other machines.

Let's check what type of chip this is:

It's a Windbond 25Q64CV. Hmm, lets see if flashrom supports this:

Oh wonderful! Well, I do still have my buspirate from my previous flashing endeavors. I get the soldering iron out and whip the chip out. Using an SOIC ZIF socket I got on ebay a few years back I checked the pinout:
Here is the buspirate to 25Q64CV pinout (notice it's exactly the same as the MX25L8005PC from the previous blog post):

Bus Pirate     25Q64CV - Pin#
CS             CS   - 1
MISO           DO   - 2
V+ 3.3v        WP   - 3
GND            GND  - 4
MOSI           DI   - 5
CLK            SCK  - 6
V+ 3.3v        HOLD - 7
V+ 3.3v        VCC  - 8
Vpullup        VCC  - 8

I updated the buspirate firmware to the latest just to be sure:
Grabbed the lasted svn release of flashrom (0.9.7-r1763), connected it up and read the chip:


Note that this flashing process did take a little time and I created a script to read, flash and verify (run this script as root/sudo):
flashrom -p buspirate_spi:dev=/dev/ttyUSB0,spispeed=8M -r ./OLD.ROM  -V | tee ./read
flashrom -p buspirate_spi:dev=/dev/ttyUSB0,spispeed=8M -w ./X9SRG3.306  -V | tee ./write

This will create two text files once complete with the output for you to check (the write also verifies), plus another with the data originally on the chip.

There is a more recent patch that might not have made it's way into the buspirate firmware which makes the reading and flashing much faster too:


Erase/write done.
Verifying flash... VERIFIED.
Raw bitbang mode version 1
Bus Pirate shutdown completed.

I solder the chip back into the machine.

Even more success! The machine boots, can once again see devices AND USB NOW WORKS!

Thank you so much Supermicro for not releasing different BIOS revisions and not even having the decency to have release notes for the different revisions. Really bloody helpful!

Tuesday, July 2, 2013

Rigol DS2072 200Mhz Bandwidth and Full Option Hack


You can now generate keys and permanently activate all of the options and bandwidth without any extra hardware. Here is the c code which will generate the keys (it is the most up to code from the thread with a couple of modifications). All you have to do under Linux is place the above code (and fill out the private key value from the forum or use the pastebin link's code) into rigolkey.c. Alternatively there is also a Windows exe floating around on the forum there too which you can use.  

Make sure you have g++ installed and perform the following:
mkdir miracl
cd miracl/
wget https://github.com/CertiVox/MIRACL/archive/master.zip
unzip -j -aa -L master.zip
bash linux (or bash linux64 if running 64bit OS)
cd ..
gcc rigolkey.c -I ./miracl/ ./miracl/miracl.a -o rigolkey

Now run:
./rigolkey [your device serial] [option parameter]
Use "DSA9" for the option parameter to convert to a DS2202 with all options enabled. There are more options available here. The device serial number is located on your about screen, or on the back of the scope. If you have somehow managed to reset your serial number to a default value on the about scree (DS2A0000000001), then use that rather than the sticker at the back.

It is recommended to have at least firmware version before entering the licence. Now apply the licence key that the keygen spits out. This is located under Utility>Options>Setup>Editor=ON. Enter the code using the intensity dial and button then hit Apply. It should then say "Option Installed!" if you entered this correctly. You now have all options enabled including 200MHz bandwidth.
 Reboot and your options will remain:

This should continue to work with future updates. It is currently working with the latest

This also works to unlock the extra features with the DS4000 series by using DSH9 as the option value for the key generator.

Based on the great work over at the EEVBlog forums, I have successfully unlocked my DS2072 to have 200MHz bandwidth and all options enabled (increased memory depth MEM-DS2, serial data decode SD-DS2, advanced triggering AT-DS2).

This does not require any modifications to the scope and the options reset after power down, so there is no worry of voiding your warranty with this method. Basically the hack works by sending an engineering unlock code via USB after the scope has booted. This is done by connecting a Raspberry Pi (or any other SBC with USB and python for that matter) to the USB device port on the back. For convenience I also power the Pi with the front USB host port (so the Pi turns on when the scope does).

I chose Arch Linux for the Pi for this as it boots very quickly. For this I used archlinux-hf-2013-06-06.zip.

You will need to update the scope's firmware to (edit: apparently the latest also works with this too) by placing the firmware image in the root directory of a memory stick formatted with FAT32 (be careful with this easier method though, you can lock up the scope and wipe your factory calibration/trial options, more info/alternative here). Then place the USB stick into the scope (it will autodetect it). If you already have this version, then leave it be.


The following setup is based on "Harvs" post here. Which is based on the work by "cybernet" (and others of course) in the thread.

Boot the Raspi and run the following:
pacman -Syy
pacman -S python
pacman -S python-pip
pip install pyusb

With this version of python 3, some small changes to the python code posted need to be made.

Line 52 of rigol.py from:
command = bytearray(SCPI_command)
command = bytearray(SCPI_command, 'latin1')

Line 35 of applyCode.py from:
read_data = ":SYST:SET " + response.tostring
read_data = ":SYST:SET " + str(response)

Line 38 of applyCode.py from:
read_data += response.tostring
read_data += str(response)

Here are the fully modified versions:

Place these in /root/

ArchLinux uses systemd rather than initscripts. So we have to enable rc.local for this next part (or create a systemd script for it, it's up to you).

Create /etc/systemd/system/rc-local.service with the following:
Description=/etc/rc.local Compatibility

Create /etc/rc.local with the following
#!/bin/bash python
Now run "chmod 555 /etc/rc.local"

You could also put "shutdown -h now" at the end of /etc/rc.local and if you needed to edit the python script/change anything on the system you could just boot into single user mode by putting the following in cmdline.txt "init=/bin/sh" on the first (FAT32) partition of the SD card (alternatively don't plug the Rigol in and boot the Pi without making the change to cmdline.txt) . This would serve to save some power.

Only do this though when everything is running correctly.

Now run "systemctl enable rc-local.service" to enable the rc.local "service". Setup is now done. Halt the Pi and disconnect.

Connect the rear USB port on the scope to the Raspberry Pi. Now plug the Pi's microusb power connector into the front port on the scope.

Turn on the scope:

You should, after a few seconds, get the following if you browse the installed options:

If you look at the about screen you will also notice that it now has the DS2202 Model designation. Enjoy your fully optioned DS2202!

You can unplug the Pi completely if you need to use the USB ports at all at this stage. Although you will need to plug it back in when you restart.

Note, this also works for the other DS2000 series scopes (DS2102 and DS2202; except it doesn't upgrade bandwidth on the DS2202) and the DS4000 series as well by modifying the python script with one of the following option codes:

Sunday, February 3, 2013

More Raspberry Pi Power Saving (Part 3)

Be sure to read part 1 and part 2.
Further adding to the Raspberry Pi's superfluous power draw are the linear 1.8V and 3.3V regulators (RG1 and RG2 respectively). Currently in place of the 3.3V regulator is the NCP1117/SE8117TA (which in turn feeds the 1.8V regulator in series). People are reporting that a modification of RG2 to a switch mode variant sees reductions in power consumption between 10 to 25%. I will not be looking to replace the 1.8V regulator as it seems to only offer marginal improvement on top of replacing RG2).

Thursday, January 24, 2013

Raspberry Pi Model B to Model A Conversion Cleanup - Part 2

Be sure to see part 1. A lot of the components on the board are now redundant as they are no longer used/connected, so for cosmetic reasons we can now remove these from the board. The easiest way to remove them is to load a soldering iron tip with solder and flood the SMD components. They should just flow away and join with the solder lump on the tip and leave a nice clean finish.

Firstly on the top, you will want to remove the components in the spaces marked red. You can also remove the RJ45 connector if you wish.

First Raspberry Pi Model A 512MB Off The (Re-)Production Line - Part 1

Who wants to wait (or pay highly inflated prices for pre-production run) for the Raspberry Pi Model A, when you can have it now for a low price of $36AUD complete with a 512 MB RAM update?

Cosmetically and functionally the Model A has removed the LAN9512 IC, Ethernet port and the secondary USB port. Under the hood, they have also designed the PCB to accommodate both Model A and B configurations, depending on the placement of a couple of components. In this series, I will be converting the Raspberry Pi Model B to a Model A with 512MB RAM.

Let's first compare the two boards by eye. On this page they have nice pictures of the Model A board. Looking at these pictures and our current board, we essentially want to remove the extra components from the Model B to match the Model A.

Thursday, May 5, 2011

Samsung GT-I9000 (Galaxy S) Touch Screen and Keypad Repair

A mate of mine recently left his Galaxy S outside in the rain, floating in a puddle overnight after some overzealous drunken antics which rendered the home button unresponsive. Sending it back to Samsung for repair would obviously require payment as it had easily set off the water damage sensors.

Wednesday, May 4, 2011

Windows Hidden/Not Connected Device Removal Script And Devcon Musings

I recently needed to create a quick script that uninstalls any devices that have since been disconnected from the system (or fail to be seen). Normally these devices can only be found if you open a command prompt and enter the following (then show hidden devices):

set devmgr_show_nonpresent_devices=1
start devmgmt.msc

The problem arose when I had a large number of touchy USB data aquisition devices that required this to be performed regularly, which becomes very tedious. This is where the devcon utility comes in handy. Although there are a few small problems; the devcon utility has issues removing hidden devices. A lot of people claim this is because it just in fact doesn't do it, as there is apparenly a flag in the program that prevents you from doing it out of the box and modifying the source is the only way to go (I have looked through the source, and I could find no such thing that would cause this behaviour). This is flat out incorrect, you can indeed remove hidden devices with devcon out of the box (provided you have the correct version for your Windows installation, more on this later).