Novena I/O slots

One of the very few complaints I have with the Novena laptop relates to the positioning of the FPGA header on the board. The header is next to an edge of the case, which is important for devices that need external I/O headers, but unfortunately it’s nowhere near the Novena’s Peek array, and therefore hard to combine with internal add-ons. (It’s also a bit close to the CPU heatsink and wireless cards, so you can’t easily use large boards on the FPGA header).

To work around that somewhat, and to try and address some wish-list features I’d have liked on the general-purpose breakout board on the Novena, I’ve been toying with the idea of a bus breakout of sorts, designed to sit in the Peek array, and provide a few buffered I/O slots. Ideally, we want an iCE40 FPGA in there too, to make it easier to build custom FPGA code directly on the Novena – to build for the Xilinx part needs the proprietary Xilinx tools running on a remote machine.

I’d set myself a few basic requirements before starting designing a board for this;

  1. Add-on devices can appear memory-mapped into the Novena’s address space – this is one of the unique abilities of the Novena FPGA slot vs. devices plugged in over USB or I2C.
  2. Add-on devices should be able to be 3V, 5V, or any other reasonable voltage without needing to incorporate level-shifting buffers into the device (so you can, for example, use simple 74-series buffers as GPIO for either voltage, selectably)
  3. At least two, and preferably more, add-on devices should fit into the Peek array, and be able to be mounted securely.
  4. 0.1″ pitch headers, only, so that add-ons can be made up on Veroboard or perfboard.
  5. I2C, parallel data, and SPI should all be supported (at any voltage).

When I mentioned some of the details of what I was planning on IRC, Sean Cross (xobs) noted that he’d been considering building something similar with an iCE40 as a catch-all factory test device. I realised that nothing about Pi connectivity fundamentally clashes with the Novena requirements, so I’ve been experimenting with board layouts to try and accommodate both. For the raspberry pi, the main way to talk to the device will be over the SPI port, with both chip selects on the Pi connected up and usable. The same SPI interface allows both reprogramming the FPGA and communicating with it after setup (using two different CS pins). For the Novena, the same approach can be taken, using the SPI port brought out to the front panel board. It’s also possible to use some of the GPBB pins as another SPI port. In both cases the Xilinx FPGA can mediate and present whatever’s attached to the iCE40 as a memory-mapped device. Several extra pins are connected to allow QSPI, UART, and I2C interfaces between the host computer and the iCE40. Of course, since the Pi connector’s pins all go into the iCE40 FPGA, there’s no real requirement that the protocol spoken is SPI at all!

My current work-in-progress is based on a board that fits in a 90mm x 60mm region of the peek array, as shown below, and provides three slots on 30mm spacing. To allow add-on boards as much room adjacent to each other as possible, and a secure mounting directly to the peek array, the boards have notched corners, and a single screw in each corner (which may be shared with the adjacent board) secures them.

My current proposed pin-out for each slot includes a reference voltage pin sandwiched between a 5V pin and a 3.3V pin; this allows a simple jumper to be used to select a suitable voltage, or an external regulator can be used to feed some other reference into the reference pin. Each slot has I2C, SPI, a simple 8-bit bus, and an interrupt pin to allow it to signal for attention.

The 8 bit data pins are connected to a bidirectional (switched) level shifter, which can therefore be used for QSPI as well as for a normal 8 bit bus. The other pins are wired to single-direction level shifters as appropriate for the signal role.

As a first “will this even fit” test, I’ve dropped all the key components onto a PCB layout and run the DipTrace autorouter against it; this succeeds even on a 2 layer board, so this design looks achievable. I’d love to hear any feedback on the idea; you can reach me as MadHacker on #kosagi at, at the obvious email address, or you can leave a comment below.



Novena iCE40 Add-On Part 5

Today, I got the revision 2 boards back from DirtyPCBs, and they work well. The new pads for the FX10 connectors line up much better, and the FPGA started up first time without any trouble. The extra connectors make it a bit easier to debug, or to use the board without a Novena attached. The larger-diameter mounting holes also make it much easier to attach. At this point, I’m happy to declare these boards a success; now I just need to get some Verilog written for the bus-bridge between the Xilinx and iCE40 FPGAs.

To help anyone else writing code to run on these boards, I’ve written a spreadsheet that’ll allow you to map the iCE40 FPGA pins to the Novena standard name for them, and to the GPBB role, on both sides. It will also produce the set_io statements for IceStorm’s .pcf constraints files, which simplifies getting something up and running quickly.

I’m not intending to manufacture any of these for general supply, but if anyone else is interested in these boards, you can get the bare PCBs from DirtyPCBs (file’s already uploaded and ready to go at this link – I’ve set up a zero cut for myself, so you’re only paying DirtyPCBs prices, no extra fees for me). The rest of the parts are listed in the BOM and are all available from both RS and Farnell – I’m sure the usual other suppliers will be able to provide something suitable as well. As the board is under the Apache 2.0 license, there’s no problem if anyone else wants to manufacture for others – feel free.

As I make progress on the bus bridge code, I’ll post it here, but in the meantime, have some blinkenlights. 🙂

Final schematics, layout, gerbers, DipTrace files, BOM, and basic demo code are all available here. – please let me know if you build one or do anything interesting with them. I’m @james_a_craig on twitter, or you can reach me on the #kosagi IRC channel on as MadHacker, or by email to any address at this domain.

Previously about this board:

Novena iCE40 Add-On Part 4

I’ve now redrawn this board to correct the problems found with the previous version, and the new board’s schematics and layouts are now available at this link. As well as correcting the problems I had before, I’ve also managed to add in a few extra features. I’ve found two pins from each FPGA that weren’t sensibly routable, and connected one to an LED and one to a 0.1″ header for each FPGA. This helps a bit with debug, as you can more easily see what’s going on. I’ve also added the FPGA reset pin to the SPI header, which means that it’s now possible to bring up the FPGA without a Novena attached. Previously, you couldn’t do this because you couldn’t bring the FPGA out of reset without a bodge wire, but the extra pin makes it straightforward. Finally, I’ve added a 1.2V header, so you can access the FPGA core voltage if you want.

I’ve uploaded the schematics as a PDF as well as the original DipTrace and Gerber files in case anyone wants to take a look without having to download Diptrace.

The new board is, as before, under the Apache 2.0 license. I’ll be getting a few of these made up at Dirty PCBs, and will post again here when I’ve got one assembled and tested.

Also about this board:

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.

Also about this board:

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:-

Also about this board:

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.

Also about this board:

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.