Altera USB Blaster udev rules

October 14th, 2020

Just an aide-mémoire for how I got my Altera USB Blaster to work as a non-root user on CentOS Linux for use with with Quartus. Create /etc/udev/rules.d/51-usbblaster.rules with the following:

# Intel FPGA Download Cable
SUBSYSTEM=="usb", ATTR{idVendor}=="09fb", ATTR{idProduct}=="6001", MODE="0666"
SUBSYSTEM=="usb", ATTR{idVendor}=="09fb", ATTR{idProduct}=="6002", MODE="0666"
SUBSYSTEM=="usb", ATTR{idVendor}=="09fb", ATTR{idProduct}=="6003", MODE="0666"

# Intel FPGA Download Cable II
SUBSYSTEM=="usb", ATTR{idVendor}=="09fb", ATTR{idProduct}=="6010", MODE="0666"
SUBSYSTEM=="usb", ATTR{idVendor}=="09fb", ATTR{idProduct}=="6810", MODE="0666"

Run the following to reload the rules:

# udevadm control --reload

Find where the device is:

# lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 002: ID 09fb:6001 Altera Blaster
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

Confirm the device node now has the correct mode:

# ls -l /dev/bus/usb/002/002 
crw-rw-rw-. 1 root root 189, 129 Oct 14 11:56 /dev/bus/usb/002/002

Using a TL866II+ programmer to update GCDual firmware

January 20th, 2020

I have a GCDual board, which is a modification for a Nintendo Gamecube to give it HDMI output. Firmware updates for this little PCB come out occasionally and to apply them requires attaching an EEPROM/flash programmer to the various pins and rewriting the chip directly.

I got wind of the latest 3.0a firmware update that actually lays the groundwork for future updates to be applied through software instead and figured it would be good have this.

There is a video that shows how to do the firmware update however I had a few issues with that process:

  1. I haven’t actually installed the PCB yet, (it’s in my TODO pile). This isn’t actually a problem as in the video, the 3.3V is provided by the Gamecube PSU instead of the programmer, but the programmer can supply this. In theory it should also negate taking precautions to ensure that the programmer doesn’t accidentally short something on the main Gamecube board.
  2. The process is using a CH341A programmer which I don’t have, and if I did get one it seems to be poorly supported on macOS. The programmer looks like it just needs to be able write SPI flash devices.

I do have a TL866II+ programmer which has a 6-pin ICSP port and comparing the pinout of that and the CH341A programmer looks like both programmers have the same required pins. The TL866II+ comes with an ICSP harness that is terminated as 6 individual female sockets so with a piece of pin header I arranged the pins in the correct order. Here is how the programmer expects the pins to be arranged logically:

So it was just a case of marrying those up to the header on the GCDual PCB. For reference it was 1-3, 2-2, 3-1, 4-4, 5-6, 6-5 for each pin on the TL866II+ to the GCDual respectively, with pin #1 on the GCDual being GND. This is what it looks like:

You can then insert the pins into the GCDual PCB and use a bit of light pressure to make contact without the need to solder anything:

Note that you need to bridge the two solder pads marked JP2 at the top right of the PCB in order to do anything with the flash chip otherwise the FPGA will fight with your programmer on the SPI bus when power is applied and you’ll read and/or write garbage.

Now we just need to flash the chip. For driving the programmer, I use the open source minipro rather than the provided software. The only bit of required information is the make & model of the flash chip; the original video shows it being programmed as an M25PE40 but my PCB actually has an MX25L4006E. The datasheets show these two chips are mostly identical anyway however minipro likes to check the chip ID. Writing the new firmware is as simple as the following:

$ minipro -i -p MX25L4006E -s -w GCDual_ADV7125_3.0a.bin
Found TL866II+ 04.2.109 (0x26d)
Activating ICSP...
Chip ID OK: 0xC22013
Warning: Incorrect file size: 346144 (needed 524288)
Erasing... 1.71Sec OK
Protect off...OK
Writing Code...  5.19Sec  OK
Reading Code...  2.48Sec  OK
Verification OK
Protect on...OK

The flags used are: use ICSP instead of the ZIF socket (-i), choose the correct flash chip (-p MX25L4006E), don’t complain that the firmware is smaller than the capacity of the chip (-s), and provide the firmware itself (-w ...).

Remember to remove the solder bridge with some wick prior to installing the PCB.

HP Remote Management card and newer versions of Java

October 17th, 2019

I was having some problems with DKMS and the ZFS kernel modules on my HP Microserver and I figured when it came to the inevitable reboot, this would be when the OS decides to kernel panic because the modules weren’t built properly and not boot back up again.

“No problem, I have the Remote Management card, I’ll just connect to that and watch it boot to make sure everything works.”, I thought. So once I remembered the password and logged in, clicked to launch the KVM Viewer, then discovered this Mac doesn’t have Java installed, (and I’ve managed for this long without it), go off to the Oracle website, relinquish all rights to my soul, and finally download and install Java 8.

I then retried launching the KVM Viewer and was met with a “Connection Failed” error. Now, this definitely used to work, so I went searching for clues. Nobody else had reported problems specifically with the Microserver card, but plenty were having problems with the iLO cards that are fitted to the Microserver’s bigger siblings, and also the iDRAC cards fitted to Dell servers; they all use pretty much the same Avocent-based Java client.

Some people suggested downgrading to Java 7 would get things working however Oracle have pulled all downloads of Java 7 unless you also promise them your first-born. Then I got the clue that it might simply be that the client is trying to use some crypto algorithm that has since been disabled in newer Java versions. Given the last firmware release for the management card was released in 2014, a lot has changed in the crypto landscape since then.

The security policy for Java is configured in a file named which for the default Java install on a Mac, lives under /Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/lib/security/. In that file, I found the following lines:

jdk.tls.disabledAlgorithms=SSLv3, RC4, DES, MD5withRSA, DH keySize < 1024, \
    EC keySize < 224, 3DES_EDE_CBC, anon, NULL

So for a first attempt, I commented both lines out and retried the KVM Viewer, and bingo, it worked again. Through a process of elimination, I figured out that it’s the 3DES_EDE_CBC algorithm that needs to be re-enabled. So here is that pro-tip for anyone else that is still using one of these, you should amend the line to:

jdk.tls.disabledAlgorithms=SSLv3, RC4, DES, MD5withRSA, DH keySize < 1024, \
    EC keySize < 224, anon, NULL

And in the end after all of that faffing, the Microserver rebooted without a hiccup, no kernel panic. Typical.

Commodore 128 Keyboard Repair

September 18th, 2016

My Commodore 128, (a “flat” C128CR), has suffered with a few temperamental keys on the keyboard; the symptoms being that keys are either slow to return after being pressed or don’t return at all and stay pressed resulting in undesired input, i.e. they’re “sticky”.

This can be caused either by spilling something, usually sugary, into the keyboard which leaves a sticky residue, or a failure of the plunger for each affected key. As I’m fairly sure I’ve never spilt anything I assumed it was the latter.

To get at the keyboard the machine needs to be opened up first which is simply a case of unscrewing the six screws on the underside; three along the front edge with the middle one usually underneath a warranty disclaimer sticker, two at each of the rear corners and one in the centre. The top half of the case will pop off with a bit of persuasion which allows you enough clearance to reach in and disconnect the power LED and then the top of the case can be hinged open along the right hand side of the machine which allows you to gently disconnect the keyboard cable and unscrew the grounding cable from the RF shielding of the main board. This should leave you with the following:


You might not necessarily need to remove the keyboard from the case but the size of the case makes it more unwieldy to work on. To remove the keyboard, just unscrew the six visible screws. Note the four black plastic spacers and their orientation for the screws along the top edge:


Once the keyboard is loosened the power LED will likely drop out along with the small plastic part that holds it in place. Keep all of these bits safe, ready for reassembly. You should now be left with just the keyboard itself:


Next the hardest step, which requires the use of a soldering iron. You need to desolder the wires from the three stateful keys; “Shift Lock”, “Caps Lock” and “40/80 Display”. It’s important not to let the soldering iron heat the keys up too much to prevent damaging them and thankfully the wires are not twisted together so with some tweezers and the quick application of the soldering iron the wires should separate easily:


There are now 27 small screws holding the circuit board in place to undo and then the circuit board should just lift away. Don’t miss this tiny spring that is situated above the ‘+’ key on the numeric keypad:


The circuit board can be gently cleaned with something like isopropyl alcohol if it’s dirty. To get at the plungers for each key, you just need to pull off the keycap on the top side of the keyboard, put that and the spring underneath it to one side, and then the plunger should just drop out:


The keycap snaps into the top of the plunger which rides up and down through a hole in the keyboard chassis with the spring making the plunger return and stay up. What happens is that the plunger can develop a split which means when the keycap is fitted the diameter of the plunger grows enough that it doesn’t move smoothly in the hole and becomes an interference fit causing the key to stick. Here’s one of the damaged plungers from mine with my nail showing where the split is:


It’s simply a case of replacing each damaged plunger, (I ended up replacing five along with two springs), and then reassembling the keyboard. Leave the re-soldering of the stateful keys until last and that you’ve checked all the other keys travel properly. You should now have a reassembled keyboard:


Fitting the keyboard back into the case is fairly straightforward, the trickiest bit is keeping the power LED stable while you drop the keyboard in place as it’s just sandwiched in, here’s how it should be fitted:


Reconnect the keyboard cable making sure not to bend any pins, reattach the grounding cable to the RF shielding and finally reconnect the power LED, (apparently it can be reconnected in either orientation), as you close the two halves of the case together. Then it’s just a case of powering on the machine and testing the keyboard. Make sure that you also test the stateful keys work correctly after you’ve de- & re-soldered them.

Reviving a DEC Vaxstation 4000/90

August 4th, 2016

I recently powered up my old DEC Vaxstation 4000/90 out of curiosity to see if it still worked and discovered that no, it didn’t. The fans in the power supply spun up, the noisy SCSI hard disk whirred and clicked into life but nothing else happened. Anyone familiar with these and similar DEC machines knows there’s a bank of eight diagnostic LED’s that provide error reporting as the machine initialises and tests its various bits of hardware. All eight were lit and weren’t changing, it looked dead.

A lot of machines of this era have what is known as a timekeeper chip which is some non-volatile RAM with a crystal and battery piggy-backed on top and encased in resin. It keeps time and the battery allows the RAM to retain its contents whilst the machine is powered off. The contents are usually important machine settings, such as which disk to boot from, etc.

The 4000/90 has a Dallas Semiconductor DS1287 which is a fairly ubiquitous part and the batteries in these chips are only supposed to last for about 10 years so given the 4000/90 was introduced in the early 1990’s, chances are by 2016 the battery is flat. Early Sun Microsystems machines are plagued with a similar problem however they tend to still power up, but then report bad values for their host ID, MAC address, etc.

There’s two possible fixes. One, fit a new timekeeper chip which given they’re not manufactured any longer may mean fitting a “new” chip that has sat on the shelf for a number of years and so the battery has already lost much of its charge. Alternatively, and what I ended up doing, is to add a new battery to the existing chip.

The first job is to locate and extract the chip. Here is the DS1287 fitted to the 4000/90:


Note the dot identifying pin 1. Thankfully it’s in a socket so with a bit of careful coercion it should come out. The next step is to use a dremel or file to grind away the plastic and resin above where pins 16 & 20 would normally be, (they’re still present but bent up inside the package and attached to the battery):


Using a multimeter across these two terminals showed there was only 220-230 mV left in the battery so it was almost flat. Now the battery needs to be disconnected by breaking the contact on pin 16 so that the multimeter shows no voltage when placed across the exposed contacts near the base of the chip. With that done add some small wires, soldering them to the same contacts with the aim of attaching them to a battery holder:


Then add the battery holder and battery; I used a standard CR2032 Lithium coin cell. The positive terminal goes to pin 20 and the negative terminal goes to pin 16. I also put some more hot glue over the exposed contacts:


Now reinstall the chip back into the 4000/90 taking care to both orientate it correctly and not bend any of the pins:


At this point it was time to try and power on the Vaxstation and this time it worked and emitted its little warble and dropped me to the SRM console:


It was a bit confused as it had lost all of its settings so didn’t know where to boot from, etc. but other than that seemed fine. After fixing this I figured my DEC 3000/600 Alpha might also have the same issue so powered that up to find yes it did, but it at least boots to the SRM console and reports an NVR (Non-Volative RAM) fault. Here’s the timekeeper chip hidden underneath the middle TURBOchannel expansion slot and bingo, it’s another DS1287:


I performed the exact same steps as before and refitted the modified chip:


The NVR fault has now disappeared. Both machines should now be good for another 10 years or so, although it’s likely the elderly hard disks will seize up, or maybe a capacitor in the power supply will leak.

Further Soekris net6501 improvements for OpenBSD

April 30th, 2015

The release of OpenBSD 5.7 brings the latest batch of improvements I made for Soekris net6501 users.

The first change adds platform detection that should in fact work on all Soekris boards, (I think this change actually went in circa 5.4 but I never posted about it). Normally this information comes via the SMBIOS extensions but Soekris boards have a much stripped-down BIOS that lacks any of this support. There are however some vendor and product strings embedded in the BIOS image (probably used for printing on the serial console at POST) so they get picked out and used. For example:

# sysctl hw.vendor hw.product
hw.vendor=Soekris Engineering

The second change adds the skgpio(4) driver which provides access to the GPIO & LEDs on the net6501. Two GPIO devices are provided; gpio0 for the 16 real GPIO pins, (JP8 in the net6501 manual); and gpio1 for the error and ready LEDs coerced into the GPIO framework as output-only pins. Here is what is displayed in dmesg at boot:

skgpio0 at isa0 port 0x680/32                                                  
gpio0 at skgpio0: 16 pins                                                      
gpio1 at skgpio0: 2 pins

You still need to configure the GPIO pins prior to raising the securelevel so add the following to /etc/rc.securelevel as a minimum:

gpioctl -q gpio1 0 set out error_led
gpioctl -q gpio1 1 set out ready_led

Now once the system is booted you can toggle the error LED with the following:

# gpioctl gpio1 error_led 2
pin error_led: state 0 -> 1
# gpioctl gpio1 error_led 2
pin error_led: state 1 -> 0

Exporting Mobile Configuration Profiles from Apple Configurator

January 9th, 2015

As I’ve secured my main Wi-Fi network with WPA2 Enterprise, my Apple Airport devices are pointed at a RADIUS server, which in turn is pointed at an LDAP directory which contains the user details. The LDAP directory does not store the password in the clear which means that authentication methods like CHAP, MSCHAP and MSCHAPv2 don’t work as they require the original password. I need to use EAP-TTLS with PAP authentication however iOS and OS X clients will not attempt this method by default.

It’s theoretically easy to make iOS and OS X clients use this method, you simply install a Mobile Configuration Profile (a file with a .mobileconfig extension) which amongst other things instructs the client how to connect to a given Wi-Fi network. The tricky part is generating this file if you maybe don’t have access to an OS X Server. Apple originally provided the iPhone Configuration Utility (iPCU) which has been deprecated in favour of the Apple Configurator utility. This works fine for iOS devices that you can attach directly by USB but sometimes you might want to transfer a profile to someone via e-mail or install it on an OS X client. It’s not obvious how to export a profile from the tool, but there is a way.

When you open Apple Configurator it looks like this:


If you enable Supervision the Profiles section changes to allow you to click + and create a new profile:


In my profile as a minimum I needed to import the root certificate of the authority used to sign the certificate on my RADIUS server. Then configure my Wi-Fi network with the SSID, Security Type, EAP Type of TTLS and then select PAP as the Inner Authentication. I also trusted the certificate I’d just imported which prevents iOS and OS X prompting you to trust it. By not setting the Username and Password this keeps the profile generic for any user. Then after saving the profile you can then export it:


This gives you the familiar .mobileconfig profile which can then be imported on any iOS or OS X client.

Apple Airport devices and guest networks in bridging mode

January 9th, 2015

The feature of being able to configure a separate guest Wi-Fi network has been present for a while now on Apple Airport gear. However, the documentation only ever alludes to this feature working when the Airport device is running in router/NAT mode, i.e. it’s in charge of connecting directly to the Internet and sharing the connection from your ISP.

Quite often people (like myself) use the Airport device(s) in bridging mode, i.e. as regular access points to attach Wi-Fi clients onto the Local Area Network and then some other device handles the routing and NAT function, (in my case an OpenBSD host), and it would be nice if you could also create a guest Wi-Fi network in this mode. The obvious way I would expect it to work is to utilise VLANs; the Airport device uses a single unique VLAN ID to tag Ethernet frames from clients on the guest Wi-Fi network. As the administrator you can then use that tag to segregate the traffic on your network; usually to allow guests some form of heavily-restricted Internet-only access, and not be able to access the rest of the network. The Airport Utility lets you create the guest network in bridging mode but doesn’t give you any details as to the mechanics of it.

Well it turns out my hunch was correct, it does use VLANs; Ethernet frames from clients on the normal Wireless network stay untagged so they Just Work on your network as before, however Ethernet frames from clients on your guest network are tagged with the VLAN ID 1003. This ID is not mentioned anywhere, nor can it be changed so you’d better hope you’ve not already used that ID for something else.

Armed with that information, I configured my Cisco SG300 switch like so:

switch#configure terminal
switch(config)#vlan database
switch(config-vlan)#vlan 1003
switch(config)#interface vlan 1003
switch(config-if)#name wifi
switch(config)#interface GigabitEthernet 1
switch(config-if)#switchport mode trunk
switch(config-if)#switchport trunk allowed vlan add 1003
switch(config)#interface GigabitEthernet 2
switch(config-if)#switchport mode trunk
switch(config-if)#switchport trunk allowed vlan add 1003
switch#show vlan
Created by: D-Default, S-Static, G-GVRP, R-Radius Assigned VLAN, V-Voice VLAN
Vlan       Name           Tagged Ports      UnTagged Ports      Created by    
---- ----------------- ------------------ ------------------ ---------------- 
 1           1                               gi1-8,Po1-8            D         
1003       wifi             gi1,gi2                                 S

This creates the VLAN, names it, configures two trunk ports where my Airport and OpenBSD router are attached and adds the new VLAN to the list of allowed ones on each port. Finally all that is left to do is to create a VLAN interface on the OpenBSD router:

# cat /etc/hostname.vlan1003
inet vlan 1003 vlandev em0

Providing any DHCP and/or DNS services and firewalling the traffic is outside the scope of this post but you now have a separate interface and subnet that you can treat it like any other regular network.

So now I have two separate wireless networks; one that gives me access to my LAN which I can secure using WPA2 Enterprise and another that can only reach the Internet which can be unrestricted or more likely secured with WPA2 Personal.

Monitoring file modifications with auditd with exceptions

November 19th, 2014

Playing with auditd, I had a need to monitor file modifications for all files recursively underneath a given directory. According to the auditctl(8) man page there are two ways of writing a rule to do this:

-w /directory/ -p wa
-a exit,always -F dir=/directory/ -F perm=wa

The former rule is basically a shortcut for the latter rule; the latter rule is also potentially more expressive with the addition of extra -F conditions. I also needed to ideally exclude certain files and/or sub-directories in the directory from triggering the audit rule and it turns out you do this:

-a exit,never -F dir=/directory/directory-to-exclude/
-a exit,never -F path=/directory/file-to-exclude
-a exit,always -F dir=/directory/ -F perm=wa

According to this post order is important; list the exceptions before the main rule.

Building mod_proxy_wstunnel for CentOS 6

August 6th, 2014

I had a need to be able to put an Apache-based reverse proxy in front of an install of Uchiwa which is a Node.js-based dashboard for Sensu. The only problem is that it uses WebSockets which means it doesn’t work with the regular mod_proxy_http module. In version 2.4.5 onwards there is mod_proxy_wstunnel which fills in the gap however CentOS 6 only has a 2.2.15 (albeit heavily patched) package.

There are various instructions on how to backport the module for 2.2.x (mostly for Ubuntu) but these involve compiling the whole of Apache from source again with the module added via an additional patch. I don’t want to maintain my own Apache packages but more importantly Apache has provided apxs a.k.a the APache eXtenSion tool to compile external modules without requiring the whole source tree available.

So, I have created a standalone RPM package for CentOS 6 that just installs the mod_proxy_wstunnel module alongside the standard httpd RPM package. In order to do this I took the original patch and removed the alterations to the various build files and also flattened the source into a single file, (the code changes were basically adding whole new functions so they were fine to just inline together). The revised source file and accompanying RPM spec file are available in this Github gist.