Skip to main content

Posts

Protocol agnostic socket programming

This is more of a mental note for myself. Now and then I need boilerplate code for socket setup which always ends with me having to hunt down all the gems that are hiding. This isn't your normal boilerplate code, this will assume very little regarding protocol and address family. Instead the only real argument is the service which to bind to. Feel free to use/steal it freely - if I can prevent more hard coded AF_INET applications the world will be a prettier place.

A non-intrusive way of storing LUKS keys on PKCS #15 smart cards

If you ever wanted to store your LUKS key on a smart card and started to search the internet for solutions, you'd be disappointed. The best guide I managed to find is https://wiki.ubuntu.com/SmartCardLUKSDiskEncryption which wants you to change your transport AUT1 key and uses a whole bunch of various scripts. It's written for usplash as well which isn't really used anymore. I was amazed of the state of things and after a bit of tinkering I got everything running as a standard PKCS#15 data object and with only two scripts needed. Oh, and it has support for the awesome plymouthd. You'll need: An initialized (PINs etc.) PKCS#15 capable smart card A reader supported by OpenSC opensc, pcscd

Bootloader for DE-2 board with OpenRISC

The last days have been filled with a lot of Verilog and ModelSim, so I thought it would be nice with some softer programing for a change. After spending more time than I care to admit on hunting down the architecture reference guide (it is here if you need it) I figured I could as well write the bootloader that my OpenRISC platform will require. Since I haven't written anything about what I have in mind, here is a quick overview what I'm looking at creating: Implement OpenRISC Make the platform fit the DE-2 board from Terasic It must be able to boot Linux It would be awesome if I can get the DM9000 network controller working That is the very formal (hmm) requirement specification I have in mind. Anyhow, to boot Linux on the DE-2 platform I would need to have a big RAM (hence the SDRAM controller) of a couple megabytes at least. I would also need to have some permanent storage to boot from; the flash memory will be good for that I think. When booting ...

Basic SDRAM controller for Terasic DE2 board

I think I pulled this one off quite nicely. The following is a controller for the 8 Megabyte SDRAM that the DE2 board uses. Features: Basic command queue ("run this when possible") Read / write support Automatic refresh Gotchas: Uses burst of only one word, it is in other words quite slow Hardcoded to work with 50 MHz and CAS 2 The controller is very very simple and always executes the read and write operations as pre-charge variants which will close the activated row after the operation. The result of this is that a single read of 2 bytes will take 5 clock cycles (activate, read, CAS 2, actual read) - a write will take 3 (activate, write, recovery). I'm inclined to create something more intelligent, faster and using the other features that this SDRAM module has to offer - but this will do for now.

SDRAM is my friend

I read a lot of blogs about people doing hardware work just as I like to do. A long time ago a person who I have the utmost respect for failed to create a SDRAM (or DRAM, I can't really recall) controller which made me sure that I wouldn't be able to do it. In order to continue with OpenRISC I will need some sort of big RAM, and after a slight nudge from a friend of mine I began reading about the SDRAM my DE2 board ships with. Two days of tinkering produced this ugly (but working!) FSM. It is locked to using row 0x0 but writes a pattern to each column address (there are 256 of them on this SDRAM). After the write it will jump to a read / refresh loop which basically proves that it is capable of holding on the data. Pretty neat, this will make a great start for a SDRAM controller.