Visual Diff

I like the idea of doing a visual diff – particularly for circuit schematics and PCB layouts. This is quite interesting. Honestly, I have never actually thought of this before but it’s great that existing tools can be used to clearly record the diff between hardware revisions in a visual manner.

The general idea behind it is pretty simple and straight-forward:

  1. Using the circuit tools, output a standardised graphical output e.g. PDF, SVG, PNG etc.
  2. Use ImageMagick to convert those graphics to a standard black and white format.
  3. Use ImageMagick to do some fancy processing on both graphics.
  4. This will immediately highlight the differences with false colouring.

Now, it’d be great if someone wrote a git post-hook to auto-magically do this.

EVK1105 Gotchas

Source: atmel.comAs promised. After spending a day trying to download code onto the board, I’ve finally figure it out. Since it was such a pain, I thought that I should note things down here to help others.

While it was fraught with pain, it was a worthwhile journey. I learned a lot about the board and AVR32 platform. The biggest lesson that I took away was how much effort ATMEL had spent into building its libraries for its platforms. There is no wonder why Arduinos were birthed on this platform.

I will learn from this and hope to build a better platform for my processor, which is currently only usable by elite hackers.

Two AVR32
The first thing to note is that there are 2 AVR32 processors on the board. The one that is directly programmable via the USB DFU interface is the smaller one, hardly noticeable, sitting right next to the ethernet socket.

It is a AT32UC3B1256 processor. While it is entirely programmable, it is not really connected to much. The one that is connected to all the bells and whistles is the AT32UCA0512, which is the big one in the centre of the board. However, it’s not directly programmable. I’ll get to that in a bit.

It took me a while to figure this one out as I was successfully programming the smaller one but nothing seemed to be happening. All the while, I thought that I was programming the bigger one. Sigh.

Faulty AT32UC3B1256 Firmware
The smaller AVR shipped with a faulty firmware, which did not allow it to run in USB-RS232 bridge mode. I had to download the fixed firmware from ATMEL and reprogram the chip. Thankfully, I could program this smaller one easily and it worked.

This smaller one could also function in as a limited JTAG. Unfortunately, the resistors that connect the smaller AVR to the JTAG pins of the bigger AVR are not soldered on the board. They’re right at the back of the board and it’s just not there.

I discovered this when snooping around the official schematics for the board, without which I would not even know of the existence of this JTAG function. While snooping around the schematics, I discovered how to program the bigger AVR.

Programming the AT32UC3A0512
There are a number of ways to program the bigger AVR – using the JTAG port, which necessitates buying an expensive JTAG cable; or using the USB DFU boot-loader interface, which is not present. However, I could never get the bigger AVR to enter ISP mode regardless of how much button pressing voodoo I did.

There is a BOOTSEL button on the board, which is unfortunately connected to the smaller AVR. Therefore, it would only put the smaller AVR into ISP mode and not the bigger AVR. To get the big AVR into ISP mode, I had to use a resistor to short out pins J16.1 and J16.9 together.

Read that. I had to short out the pins on the board directly. It’s an ugly hack. Once I did that, the larger AVR would enter into ISP mode and I was able to program it to my hearts desire, accessing all the bells and whistles on the board.

Christian Hacking

I’ve just read an article on The Economist on how hacking is a very Christian thing to do – and so is Open-Source. Let me just quote a couple of parts of the article:

Mr Spadaro says he became interested in the subject when he noticed that hackers and students of hacker culture used “the language of theological value” when writing about creativity and coding, so he decided to examine the idea more deeply. “In a world devoted to the logic of profit,” wrote Mr Spadaro, hackers and Christians have “much to give each other” as they promote a more positive vision of work, sharing and creativity.

Catholic open-source advocates have founded a group called Elèutheros to encourage the church to endorse such software. Its manifesto refers to “strong ideal affinities between Christianity, the philosophy of free software, and the adoption of open formats and protocols”. Marco Fioretti, co-founder of the group, says open-source software teaches the “practical dimension of community and service to others that is already in the church message”.

Don Parris, a North Carolina pastor, wrote an article in Linux Journal in 2004 in which he argued that “proprietary software limits my ability to help my neighbour, one of the cornerstones of the Christian faith.”

While I agree that there are very theological and religious reasons to hacking, it is definitely not in-line with the Christian faith as mentioned in the article:

Moreover, hackers in particular have problematic traits from the perspective of the Catholic church, such as a distrust of authorities and scepticism toward received wisdom. And the idea of tweaking source materials to fit one’s needs doesn’t mesh well with the Catholic emphasis on authority and tradition.

Exactly. Most hackers identify more with Buddhist traditions as typified in Hacker’s Zen and enshrined in the Jargon File. Hacker culture can be easily reconciled with Buddhist traditions and in fact, I would go as far as to say that the Buddha, is a hacker himself – in the sense that he tinkered with and hacked the human condition.

The main reason is because of the fundamental clash of hacker and Christian traits – hackers generally do not take to faith – as mentioned by Eric S Raymond in the article:

Mr Raymond took to his own website to note that he had deliberately equated cathedrals with proprietary, closed-source software directed from above, by contrast with the more chaotic bazaar of equals which produces open-source code. “Cathedrals – vertical, centralising religious edifices imbued with a tradition of authoritarianism and ‘revealed truth’ – are the polar opposite of the healthy, sceptical, anti-authoritarian nous at the heart of the hacker culture,” Mr Raymond declared.

As for Mr Spadaro’s ideas, they possessed a “special, almost unique looniness”.

So, while Christians may want to lay some claim to the hacker culture, ethic and ethos, the hackers have already spoken.

Virt-io Networking

I have already been using virt-io for hard-disk emulation in my guest machines under KVM. However, I have never tried virt-io networking before. Seeing that I wanted to upgrade my machines, I thought that I’d give it a try and this is where I noticed the speed bump.

Following some of the instructions at the lib-virt page, I got virt-io networking working for all my VMs. This is the result:


------------------------------------------------------------
Client connecting to x.x.x.x, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[ 3] local x.x.x.x port 34610 connected with x.x.x.x port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 113 MBytes 94.4 Mbits/sec
[ 3] 10.0-20.0 sec 116 MBytes 97.3 Mbits/sec
[ 3] 20.0-30.0 sec 117 MBytes 97.8 Mbits/sec
[ 3] 30.0-40.0 sec 115 MBytes 96.8 Mbits/sec
[ 3] 40.0-50.0 sec 115 MBytes 96.4 Mbits/sec
[ 3] 50.0-60.0 sec 116 MBytes 97.7 Mbits/sec
[ 3] 60.0-70.0 sec 117 MBytes 97.9 Mbits/sec
[ 3] 70.0-80.0 sec 116 MBytes 97.6 Mbits/sec
[ 3] 80.0-90.0 sec 115 MBytes 96.3 Mbits/sec
[ 3] 90.0-100.0 sec 117 MBytes 98.0 Mbits/sec
[ 3] 0.0-100.0 sec 1.13 GBytes 97.0 Mbits/sec
virt-io activated.


------------------------------------------------------------
Client connecting to x.x.x.x, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[ 3] local x.x.x.x port 58218 connected with x.x.x.x port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 47.6 MBytes 39.9 Mbits/sec
[ 3] 10.0-20.0 sec 49.7 MBytes 41.7 Mbits/sec
[ 3] 20.0-30.0 sec 46.5 MBytes 39.0 Mbits/sec
[ 3] 30.0-40.0 sec 50.8 MBytes 42.6 Mbits/sec
[ 3] 40.0-50.0 sec 49.5 MBytes 41.5 Mbits/sec
[ 3] 50.0-60.0 sec 47.5 MBytes 39.8 Mbits/sec
[ 3] 60.0-70.0 sec 44.9 MBytes 37.6 Mbits/sec
[ 3] 70.0-80.0 sec 46.1 MBytes 38.7 Mbits/sec
[ 3] 80.0-90.0 sec 45.2 MBytes 37.9 Mbits/sec
[ 3] 90.0-100.0 sec 46.2 MBytes 38.8 Mbits/sec
[ 3] 0.0-100.0 sec 474 MBytes 39.8 Mbits/sec
virt-io deactivated.

As you can see, more than a 200% increase in through-put.

What is more amazing is that this increased bandwidth is not shared directly. This means that two guest VMs running under the same host both enjoy a 100Mbps speed simultaneously, not 100Mbps shared across the two. This is a massive performance boost, especially inter-VM.

Lesson learned – ALWAYS use virt-io for all I/O operations under KVM/libvirt.