Novena iCE40 Add-On Part 3

I’ve now got the iCE40 add-on board for the novena up and running. There are a couple of defects on the board design that need corrected before you can get one of these boards to run. These are:

Missing power to the VCC_SPI pin (pin 72, top pin on the right-hand side of the chip, nearest the 1.2V regulator) – this just needs jumpered to any available 3.3V point. Since it’s the very corner pin, there’s no difficulty connecting this by hand.

Bad footprint for the pass-through connector – the FX10A_80P_8 connector footprint I’ve used is too narrow,  and it makes it very difficult to solder by hand. Reflow should be OK as long as the solder resist layer isn’t excessively thick on your boards – the pads are in the right place, just too short.

I’ll do a revision of the board layout when I get some time, but for now, this is pretty functional.

I’ve written a basic loader for the iCE40 , which uses a slightly modified GPBB Xilinx bitstream for now. I hope to write a proper bus bridge for the Xilinx to interface between the two ICs, but for now it’s enough to get blinkenlights working. The sources (and a copy of the compiled Xilinx bitstream) are available here.

I’ve also included a basic blinkenlights demo for the GPBB when piggy-backed on the iCE40.

Novena iCE40 add-on part 2

I’ve received the boards for the iCE40 add-on back from DirtyPCBs, and they look good. As far as I can tell, everything seems to be functional, although I’ve got some coding to do before I can tell for certain – in particular, I need to put together a bootloader of some sort to feed the SPI port on the iCE40 with the bitstream.

In the meantime, I’ve put together one of these boards and got it powered up in a spare novena to test, and I’ve quickly thrown together enough Verilog code for the Xilinx to be able to bit-bang SPI to talk to the iCE40.

For anyone following along, the only mistake I’ve noticed on these boards has been the wrong footprint for the upper pass-through connector; the one I’ve used is close enough to fit, but there’s some definite overhang on the pins over the pads, and it’d be wise to redo that part if you’re considering making one of these boards.  I’d also recommend using the taller version of the lower connector, as I found the board sits slightly high at one side as a result of resting on the SATA connector. It’s flat enough to still make good contact, however, so if you only have the shorter connectors, you should be OK.

Here’s the board sitting in place in the novena (with a patch wire onto the reset pin during bringup):

and with the GPBB fitted on top:-

Novena iCE40 add-on

I’ve been working on an add-on board for the Novena open-source laptop, which provides an iCE40HX4K FPGA on a mezzanine board designed to fit in between the Novena and any add-on boards.

The reason this is useful is that Clifford Wolf’s icestorm project provides a fully open-source FPGA toolchain for the iCE40 that can run locally on the Novena, thereby removing the need for an x86 desktop machine when playing with FPGA projects. The Xilinx FPGA will act as a bus bridge between the iCE40 and the Novena, and (hopefully) provide access to RAM too, using a fixed, shared, FPGA design.

picture of the PCB layout for the novena mezzanine board

The board is intended to sit in the same location as the normal GPBB board would in a Novena laptop, and to provide a rotated FPGA header for the GPBB or other add-on boards to connect to, positioned such that it will sit above the SSD. This isn’t ideal, but the Novena layout is very tight for space around the FPGA connector, so it’s the best way I could fit in space for a whole second board.

At this point, I’ve drawn up a PCB design for the board, and I’ve ordered the first batch from to try out. If anyone’s curious to look at the schematics or board, they’re available here in DipTrace format. Everything’s under the Apache 2.0 license, to match the Novena itself.


Kyocera address book password decryption

I needed to extract the SMB password associated with some address book entries on our Kyocera printers today (Kyocera 4550i’s, specifically) because we’d lost the original password for an account they were using, and we needed to recover it without having to reconfigure every printer in the company. No problem, thinks I, I’ll use KMNet Viewer to dump out the address book to XML from the printer, and just read out the password in the XML.

No such luck. The password’s encrypted in the XML file.

Fortunately, with a little patience and RedGate’s brilliant .NET reflector, I managed to find where the encryption happens, and to extract the relevant keys. The story of how I got this out of the code isn’t particularly exciting, but the final result is that I got the keys to decrypt any password saved in a dump from KMNet viewer. Unfortunately, it’s a fixed key used every time, so you can’t even set your own password to protect your address book dumps – it’s only enough to deter casual snoopers. Not an impressive level of security.

Anyway, without further ado, the relevant information is:-

Passwords are encrypted with DES, in CBC mode, using a key of 41F4A305F38B468F, and an IV of 01820D0B383ECB7C. These are derived from a few variations on the theme of Kyocera’s name via RFC2898; rather than reproduce the original values here, I’ve just included the resulting keys. I found worked fine with these values if you want a quick and dirty online DES decryptor to let you read your address book files.

I hope that’s useful to someone!

Early floppy disks

I was talking on IRC to some people today about an old Apricot computer I had, which had some curious features. Among other things, it was PC compatible in all ways except the BIOS, which meant that it needed a special custom version of MSDOS to boot. I remembered, while thinking about this, that I had some unusual very early floppy disks that had come with it. These don’t quite look like your normal 3.5″ floppies, although they’re compatible with normal drives.
IMG_1383.JPGUnlike normal floppy disks, these ones have a latching shutter that can be held open. As far as I can tell, this was so that drives could be made without the extra arm/lever that flicks open the shutter, and therefore would reduce costs a little bit. For some reason I’ve never seen this style of disk anywhere else, so I thought I should photograph one of the ones I’ve got for posterity’s sake.


The latch itself is simply made from the plastic of the disk and an extra crease in the metal shutter blades. To latch the shutter open, you just push it open past the normal stop point where a normal floppy drive would push it to; beyond that point, it locks into place. To release it, you just squeeze the corner of the disk, which is slightly split, and the shutter pops closed again.


This also makes it a little easier to clean the disk surface if you manage to get some greasy finger-prints onto it somehow (although it obviously increases the possibility of that happening in the first place). I can only suppose that these were really early disks and predated the lever being standard in floppy drives, but I was sure that Sony invented the 3.5″ microfloppy, and that the first ones had that lever. Perhaps some clones omitted that detail for some reason? In any case, it’s an interesting and rare feature.

The same company supplied, at the same time, some disks without this feature too, and my Apricot machine didn’t actually need the latch, just to further confuse matters.

De-encapsulating ICs with a laser cutter

Closeup of dictionary ROM

I recently found, in an old box of random electronics, a pocket dictionary of the 12-in-one spellchecker variety. The board had two large chip-on-board ICs on it, both covered with the usual black epoxy of doom. The actual traces routing between the two were relatively sparse, and I was somewhat curious what the architecture of the device actually was, so I decided I’d like to de-encapsulate the chips to see what was making it tick.

I’ve heard many times in the past that the best way to do this is by careful application of fuming nitric acid. Unfortunately, that’s somewhat controlled in the UK as it’s considered a precursor for making explosives; as a result, I didn’t have any to hand. However, I thought it might be interesting to try a different approach – a laser cutter.

40W CO2 laser cutterI have a generic 40W chinese laser cutter, of the kind you can pick up cheaply on eBay. This particular laser has been upgraded very slightly with some better stepper control electronics and an air assist nozzle for the head; however, it’s still using all the original optics and laser. The air assist is the only relevant improvement for this job.


I set the PCB with the COB blob up under the laser, and fed in a simple half-inch square bitmap to the laser control software to be engraved. This made the laser perform a raster pattern across the surface of the COB device, neatly etching away the epoxy. If you’re trying this yourself, I used three passes, with the laser at full power and set to 300mm/sec and air assist on.

IMG_1369.JPGA single pass yielded a noticable depth of cut into the epoxy blob, with a fairly good surface; it was a little dusty (the various unpleasant byproducts of burning epoxy tend to recondense on nearby surfaces), but the laser was clearly cutting the epoxy fine. The question was whether it would trash the silicon underneath.IMG_1367.JPG

After the third pass, the die surface started to become visible, and so I stopped and cleaned off the surface with a brush. Unfortunately, I was a little heavy-handed with the brush, and some of the gold bond wires were broken as I did – they were actually intact before. However, I managed to get a pretty good view of the chip surface, and a look at the layout. Apologies for the poor photograph quality – I was using a biological microscope not intended for top illumination, and it has bad flare problems with the reflections from the IC surface.

View of the whole chip. The pinholes in the corner are from me lining the laser up with where I wanted it to start.
Sanyo logo on the corner, along with some of the pin buffer structures.

From this, I think it’s pretty clear that this chip is just a ROM of some sort, and any clever behaviour is implemented on the other chip on the board, Unfortunately I managed to shatter that chip while trying a different process for removing it from the epoxy blob of doom, so I have no photographs of that to show.

I hope this helps if anyone else needs urgently to deencapsulate a chip and work out what’s inside it; it’s faster (less than 5 minutes on the laser) and simpler than the nitric acid approach, and while it doesn’t yield a perfect result, it’s good enough for basic identification. Most importantly, the laser doesn’t seem to cut any of the metal on the chip, nor the bond wires, nor the silicon itself, despite chewing rapidly through the black epoxy.

Back again

Some of my colleagues are pretty enthusiastic about blogging, and in particular a couple of them are professional writers and seem to regard it as a necessary part of their trade. The resulting office chatter reminded me that I should really get around to blogging a bit more, but I never really find time to write properly; there’s always something more interesting to be done!

One of those things that I generally find more interesting is photography. I take a ridiculous number of photographs in an average month, so I’m intending restarting this over the next few weeks as more of a photo-blog rather than the exceedingly intermittent text updates that occupied the site previously. I’m hoping that this will let me keep up some reasonable sort of update schedule instead of the annual updates previously.