Category Archives: software

Weird Trickery: Compiling verilog VPI extension and unit-testing it using cmake/ctest

A few months ago I needed to write a VPI extension for verilog HDL and (just as I would normally do) I needed a proper buildsystem for that stuff. Unfortunately in terms of build/debug/test tools the folks doing ASIC are living… Well, not in the stone age, but in their own small isolated world and keep reinventing the wheel over and over again. OpenSource iverilog simulator didn’t go far away from the proprietary counterparts that tend to ditch commonly used in linux environments best practices.
Okay, now let’s stop bitching about the way things are and decide how to deal with that kind of stuff. In this note I’ll try to describe how to make a CMakeLists.txt for compiling a VPI extension and unit-testing it with ctest.

Continue reading Weird Trickery: Compiling verilog VPI extension and unit-testing it using cmake/ctest

SkyForge: Creating Debian root filesystems in a Dockerfile-style

For a handful of projects work and hobby alike I use Debian. However, when you deal with embedded systems (e.g. ARM SoC) you normally don’t have the installer CD or even the disk drive. You end up creating a filesystem, compiling the kernel. Well, pretty much the usual way it goes.

The process can be somehow lengthy if done by hand using debootstrap and multistrap and especially mind-blowing if you are a total newbie. (Alas, I’m already no n00b here. Getting older, heh)
The worst part of it is that you not only need to create a root filesystem for debian, but set it up in a more or less sane way, e.g. set the default password, ssh keys… The usual thing.

In the Big Enterprise ™ we can see tools like vagrant creating us a base box in the VM and chef or puppet actually setting the system up. While we can use, say chef or chef-solo on an armhf board (why not?) we still have to make sure we have some base image it will set things up on, right?

Continue reading SkyForge: Creating Debian root filesystems in a Dockerfile-style

CMake + atom + .clang_complete

A few months ago I moved from emacs to atom that looked like a more modern replacement. Most important for me – it had awesome CMake code completion that was very good. I soon made use of automplete and lint with clang. Both were good, but needed a .clang_autocomplete in your project root to work properly. Apparently if your project file get a bunch of compiler flags from the build-system managing this file by hand is not something I wanted, so I ended up with this snipplet in CMake that gets the job done:

message(STATUS "Generarating ${CMAKE_SOURCE_DIR}/.clang_complete")
file(WRITE ${CMAKE_SOURCE_DIR}/.clang_complete "")
foreach(dir ${dirs})
  file(APPEND ${CMAKE_SOURCE_DIR}/.clang_complete "-I${dir}\n")
foreach(flag ${CMAKE_C_FLAGS_SPLIT})
  file(APPEND ${CMAKE_SOURCE_DIR}/.clang_complete "${flag}\n")

If you use C++ in your project you need to use the CMAKE_CXX_FLAGS variable. This code also has the obvious limitation: If you pass via -D directive options that have spaces – this won’t quite work (e.g. -DRELEASE_CODENAME=”Black Burned Cookies”)

Doxygen && gh-pages

Github has a cool feature – it allows you to attach html pages to your repo. And if the web pages designer that brings memories of early 00s is somewhat useless – storing doxygen html docs there is a very cool feature.

However we can’t store any history in gh-pages branch. It would be utterly useless and may heavily bloat the repo (especially if you generate a plenty of diagrams with graphviz). So ideally we should:

  • Make a clean branch each time, commit all the docs we’ve generated
  • Do –force push, so that we’d drop everything on the remote side
  • Do it from our development branch, without switching to gh-pages
  • Potentially integrate with CI/Jenkins: Build succeded, unit-tests passed, static analysis okay – bump the docs!

Can be achieved easier than it sounds. Here’s my quick sniplet for this hackery in GNU/Make:

	-rm -Rfv doxygen/
	( cat Doxyfile ; echo "PROJECT_NUMBER=0.1" ) | doxygen 
	cd doxygen/html;\
	rm -Rfv .git;\
	git init .; git checkout --orphan gh-pages;\
	git add *;\
	git commit -m "documentation-for-gh-pages";\
	git remote add origin;\
	git push -u -f origin gh-pages

ESP8266: Say ‘hello’ to Frankenstein

Since I’ve got some homebrew development boards ready, it’s time to get hacking.
I stocked on coffee and gave esp8266 SDK a deep dive this weekend. The code is really weird, lots of things are unknown, API is shitty, blobs all around the place. First of all, to make things clear – I’m not going to fix or do anything with AT-command firmware. It sucks. Period. Sucks so much it can’t even prove useful as a reference most of the times. So… we need a replacement.

This is what I’m working on and that is now, after a weekend of hacking is in early alpha stage.

Say hello to Frankenstein Firmware for ESP8266.

Continue reading ESP8266: Say ‘hello’ to Frankenstein

rf24boot v0.2 released!


It was a busy month, but I finally managed to find a minute and update the rf24boot. Yes, the very thing that can push firmware updates via nRF24L01 wireless modules. Along is a regular bunch of updates to rf24 library in antares. One of the big news I finally took some 20 minutes and layed out a proper programming dongle. Since I didn’t have a cheap stm32 with usb around, and stm32f103ret6 looked like an overkill for this purpose this dongle still uses avr, vusb, but has a 16M (20M is possible as well) crystal. The lengthy changelog’s under the cut, but it’s big.

Continue reading rf24boot v0.2 released!

USB PCB Toner Transfer machine with Web Interface

I had planned on getting a lamination machine to do toner transfers for a long time. Unfortunately, I never came across anything that had manual temperature regulation, so I decided to take whatever was available and try it. As expected, the temperature was NOT enough for toner to even melt, no matter how many times you tried.

Great, time for an upgrade.

Continue reading USB PCB Toner Transfer machine with Web Interface

Antares 0.2-rc1 released!

That’s it! It’s out. After two years of slow and steady development in my free time. Antares is a free and open source (GPLv2) buildsystem bundled with library code, aimed at bare metal targets. Sounds scary? Well, consider this an arduino for kernel hackers. If you are one – you have all the regular tools here: kconfig, GNU/Make, and no need to write Makefiles from scratch or collect sparse instructions over the web – just bootstrap a project, adjust the config to your needs and go!
0.2-rc1 is the first release that can be considered (more or less) stable for every day use. To find more about what it is and how it works – check out the README in Russian or English


Continue reading Antares 0.2-rc1 released!


Don’t ask why. I just though it might be a cool idea.

So what’s the catch? Packet writing over CD/DVD-/+RW media is pretty much the same as writing to a block device. The only bad thing is that:

  • Writes MUST be aligned
  • Writes must be of a fixed packet size
  • Before reading you must issue a flush command.

To hide this from the upper level pktcdvd module exists that assembles packets and sends them to the media. Well, this whole pktcdvd machinery reminded me of a NAND device actually, so I wondered if we could actually make an MTD device out of a CD or DVD. AND run UBIFS on top of it. (Or yaffs2. whatever). Details&code under the cut

Continue reading UBIFS over DVD+RW

Ditching the x86 – moving on to armv7l

My home server has a long story. It all started with a Pentium 4, an old 20GB HDD and FreeBSD 6.2 … hell, I don’t even remember the exact year.
Anyway, after a few years, the hardware was finally put to rest, since it died and got resurrected thrice, I got an Intel Atom D410-based miniATX board, switched to linux, first debian, then agilia, then arch… Anyway, it used to be a nice server for personal needs, that crashed only on occasional HAD-effect, so it was… sufficient.
Now, the time has come to move on, to arm. The benefits were simple and straight:

  • 10W peak power consumption
  • Fully passive cooling
  • eMMC for the root partition
  • 4 cores!
  • Always a serial terminal, starting from uboot phase, so that I don’t have to carry a monitor to the closet where it is stationed.

I picked ODROID-X2 based around Exynos4212 Prime. ODROID-U2 looked worse, since had NAND soldered onboard. eMMC looked easier to replace. And the benchmarks said eMMC was faster.


So, here go my adventures with this hardware.
Continue reading Ditching the x86 – moving on to armv7l