Intel has been kind enough to show us how to use WolfSSL on the Galileo board, but only in a client mode. Turns out that, there are some issues that will be encountered when running a WolfSSL server on the Galileo with the EthernetServer mode.
I’ve had to learn this the hard way.
Date
The EthernetServer will fail to load the server certificate as the internal clock is stuck in the past. Therefore, we need to set the system date of the Galileo board to the present. Since there is no NTP client built into the Galileo 2 board, we are forced to use rdate instead.
So, telnet into the Galileo board and run the following command:
$ rdate tick.greyware.com
I suppose that the best way to do this is to incorporate a system() command into the setup() code of the Arduino sketch to automatically synchronise the date.
ECC Support
WolfSSL has removed static key based cipher-suites since 3.6.6. Therefore, it needs to be configured to support say, ECDHE based cipher-suites. Unfortunately, this is not automatically enabled during library configuration unless you’re using x86_64, which the Galileo board isn’t.
Therefore, the solution is to configure the library with the –enable-ecc option enabled.
Otherwise, we will face the inability to communicate with the Galileo board when debugging using OpenSSL with the Galileo board complaining that there are no matching cipher suites right after receiving a Client Hello. The Galileo board then teminates the handshake without sending a Server Hello.
I bought the last unit of the Acer RevoCenter RC111 at a local store a couple of days ago, for a steal – RM799 (US$263). It came with a 1TB harddisk that has Windows pre-installed on it. I wanted to install Linux on the RC111 but the Internet seems to be scant on details. So, I thought that I’d blog about how I did it.
Pre-installation
It would be a pain to install an OS onto the RC111 without a VGA port. Fortunately, the VGA port of the RC111 can be easily exposed by removing the tab covering it. Just use a sharp blade to cut the edges and press down on it slightly to break the thin strip of metal holding it in. Once that is done, the VGA port is exposed on the back.
Power up the device and you will see a minimal BIOS boot from American Megatrends. If you use a paper-clip to depress the reset button on the back of the unit when you hear a beep, the RC111 will boot from USB instead of the internal HDD.
That is the technique that I used to install Linux on the RC111.
Installation Image
It turns out that it is easier to prepare a USB installation image for Debian than it is for Centos. Therefore, I just went with Debian instead. Simply download the latest netinstall ISO and flash it onto a small USB thumb drive.
Once that is completed, slot the USB drive into the back of the RC111 and power on the device. The indicator light on the front of the unit should flash white. The main hard-disk needs to be inserted in the RC111, otherwise it won’t boot.
At the sound of the beep, press the reset button with a bent paper clip. The indicator light on the front of the device should turn a stable purple and the RC111 will boot from the USB thumb drive.
Installation
The rest of the Debian install proceeded as normal. However, the ethernet network will not work correctly at the moment. So, it is only possible to install a bare minimal install of Debian on the device.
Post-installation
The built-in gigabit ethernet chip requires firmware that is not installed by default. It requires the firmware-realtek package that is in the non-free repository. Since the ethernet port would not work properly without the firmware, this package needs to be downloaded separately and copied over to the device and installed manually.
# dpkg -i firmware-realtek_0.28+squeeze1_all.deb
After that, the on-board gigabit ethernet will work and can be configured as usual.
All in all, it was simple enough to install an alternative OS onto the RC111. There is no reason why this should be any problem as the RC111 is basically a standard PC design with standard PC parts but with a custom BIOS.
Final Notes
At RM799 with a 1TB HDD, this is a steal and will work splendidly as a file server. I plan to stick in another 3x2TB HDD in the future for expansion.
The indicator light keeps blinking white while the machine is running. This doesn’t seem to be a problem. None of the individual HDD lights blink when in use. This is a small WMI issue that doesn’t affect the operation of each drive.
The system sometimes hangs or reboots on its own during startup. However, once it has successfully started up, it will stay running as normal.
I respect the amount of dedication and genius that went into this effort. While nothing new, it’s totally CRAZY.
This project takes the Church-Turing thesis to an extreme. In essense, it states that “everything algorithmically computable is computable by a Turing machine.”
Some may wonder how he managed to get it all to work. So, let’s break it down a little:
CPU
According to the thesis, any CPU is able to emulate the operations of another CPU. So, while the AVR is an 8-bit micro, it can definitely be used to emulate all the complex functions available on the more powerful ARMv5 in software.
As an example, if I needed to do a 32-bit addition, all I would need to do is to do four 8-bit additions factoring in the Carry bits. So, depending on whether the 8-bit architecture supported a Add with Carry instruction, I might need to do an additional three 8-bit additions for a total of seven additions. In the end, I’d still end up with a 32-bit addition.
For many 8-bit microprocessors, there are already existing libraries to do such things because it is a fairly common requirement as 8-bit microprocessors find use in all sorts of unexpected applications where they might need to do 32-bit calculations anyway.
Take this analogy further, you can also do floating-point calculations emulated in software on a pure integer machine. This is done all the time, even on full fledged ARM architectures. In actual fact, all you’d need to build any computer in this world is a 1-bit computer.
RAM
This is where the 16KB RAM in the 8-bit micro has serious deficiencies. Linux would typically need several megabytes of RAM. Therefore, the project included an external 16MB of RAM. While some may argue that we still need more than 16MB of RAM, it isn’t exactly true. The internal 16KB would be used to emulate more of a cache than primary memory.
In a modern computer, memory is just a hierarchy of storage devices. RAM is just a convenient method of doing it. If there isn’t enough RAM, we can always emulate the RAM as well, using virtual memory, which is what most desktop PCs used to do in the past by exploiting some of the hard disk.
From all indications, this project had a 1GB SD card attached to it for storage needs. This included the Linux OS plus file-system. So, it could boot off this SD card and also use part of it as a swap if necessary. Swapping can both be done in the OS or even emulated by the 8-bit micro.
However, the speed of the device would be another limiting factor. Most 8-bit micro communicate with SD cards using the SPI protocol at a maximum clock of 25MHz. This means that it has a theoretical maximum transfer rate of only 3MB per second – about the speed of a 20x CD-ROM drive.
If I were adventurous, I might even emulate a CD-ROM drive. This way, I could run a Live-CD Linux distribution on one partition, while using another partition to emulate a mass storage device such as a hard-disk drive. That might prove interesting as well.
I/O
This is where I think that he had to emulate a lot more stuff. While 8-bit micros may be low on brain power, they are typically full of all sorts of I/O devices. However, the project would need to emulate a whole bunch of things to get Linux started.
I gather from the video that the standard inputs and outputs are routed through the serial port of the AVR. This can typically be done in Linux by simply specifying a kernel parameter console=/dev/ttyS0. Then, the emulator would need to emulate the necessary calls to read from and write to the console.
If he wanted to emulate the mouse and keyboard, it would also be very possible as the PS/2 protocols used have been emulated in 8-bit micros for a while. There are some devices that use 8-bit micros as pretend keyboards and mice e.g. a key-logger or a password dongle.
If he wanted to emulate a video card, it is also possible as 8-bit micros have been used to generate full frame video in emulation, largely by using PWM signals to emulate the analogue signals of a VGA connection. While it will be severely speed limited, it should be able to do at least a low-level VGA frame buffer.
He could even go as far as adding in ethernet if he so wished. Some 8-bit micros these days have built in ethernet MACs. However, adding USB host capability might be a bit tricky as most 8-bit micros do not have USB OTG capabilities as yet.
So, there we have it. A quick and dirty run-down of it.
I’ve just completed a 4-day training course on embedded systems development using FreeRTOS. I had a few days to prepare the training material for it and through the course of the training, I learned the virtues of writing on an RTOS platform.
Some of my trainees were from the ‘old skool’ of embedded development and are used to the traditional paradigm of using a state machine loop with a bunch of interrupt service routines to make things work.
That’s all fine and dandy except that once you discover the power of coding on an RTOS platform, it blows your mind. And to thoroughly exploit the power of an RTOS, you need to do a paradigm shift and move up one level of abstraction in application design.
A typical embedded developer would be in control of everything in a chip, which puts all the responsibility and power in the hands of the developer. Every little thing needed to be taken care of in order to avoid problems.
But with an RTOS, one moves up the ladder and thinks merely in terms of tasks, priorities and synchronisation. That’s it! (Blows your mind)
As part of AESTE’s platform development, I had FreeRTOS ported to our AEMB platform. However, I still had never actually done any RTOS platform development before this. Through the course of developing the training material, I was forced to jump in head-first into FreeRTOS.
It was an educational experience and I now understand the guts of FreeRTOS inside out. As a result, I can appreciate all the complexity that went into and and have now learned why it is a useful tool to have in our arsenal. We will continue to devote more resources to developing it into a full fledged product.
I will try to set things down in a structured way and write a tutorial into getting a basic FreeRTOS application working in 5-minutes.
As 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.
I bought the last unit of the Acer RevoCenter RC111 at a local store a couple of days ago, for a steal – RM799 (US$263). It came with a 1TB harddisk that has Windows pre-installed on it. I wanted to install Linux on the RC111 but the Internet seems to be scant on details. So, I thought that I’d blog about how I did it.
As 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.
Technical Intercourse 