QEMU 2.0.0 is now released.

The full list of changes are available at: http://wiki.qemu.org/ChangeLog/2.0

It appears that doing a checkout of tag ‘v2.0.0’, build and install will produce a binary that reports version 1.7.9

1
2
3
4
5

git status
HEAD detached at v2.0.0
nothing to commit, working directory clean
qemu-system-arm --version
QEMU emulator version 1.7.93, Copyright (c) 2003-2008 Fabrice Bellard

I did a quick look and they are pulling the version during the ./configure stage so since I am always on the master (bleed-edge) branch, my installed version shows up as 1.7.9. You will need to checkout, configure, build and install to produce a binary that has the correct version (QEMUVERSION) assigned:

1
2

qemu-system-arm --version
QEMU emulator version 2.0.0, Copyright (c) 2003-2008 Fabrice Bellard

I do not do a lot of product promotions, but this Logic Analyser from Dangerous Prototypes is so sweet! It is such a simple hardware design, pulled together with some great programming and serial ram overclocking. For $30USD you get an 8 channel, 256k sample, 60 Mhz(!!! - overclocked) logic analyser that supports the SUMP logic analyzer protocol and thus can use the Logic Sniffer (An alternative OLS client), another great open source product.

This item is on my list now for future debugging of my bare-metal ARM designs.

So check it out yourself:

DP Blog post: http://dangerousprototypes.com/2014/04/15/new-prototype-logic-pirate-8-channel-256k-sample-60msps-logic-analyzer/

Product page: http://dangerousprototypes.com/docs/Logic_Pirate

Available from Seeed @ http://www.seeedstudio.com/depot/Logic-Pirate-p-1750.html

Client Software: Logic Sniffer (An alternative OLS client)

Point releases are coming to the LLVM compiler infrastructure with the LLVM 3.4.1 release just a few days away.

Doing point releases have been talked a lot about in the past but they’ve never materialized up to now with this open-source compiler infrastructure seeing major releases once every six months. Fortunately, in covering the time until LLVM 3.5 in three months, LLVM 3.4.1 will finally be made. Tom Stellard at AMD who has been working a lot on the AMD LLVM GPU back-end and other open-source Radeon OpenCL code, has been organizing this point release management. The LLVM 3.4.1 release plans were originally shared last month. LLVM 3.4.1 just incorporates stable bug-fixes while all major feature development is focused on landing for LLVM 3.5.

The official LLVM 3.4.1 release is planned for 4-18 assuming that all of the testing goes well. Details for testing can be found via the LLVM mailing list.

I am staying on the bleeding-edge for my bare metal ARM work, so I will continue to stay on the master branch (3.5.0):

1
2
3
4

./clang --version
clang version 3.5.0 
Target: arm-none--eabi
Thread model: posix

If you have not checked and/or patched your OpenSSL deployment, better get to it: Heartbleed

XKCD does it again and provides the best explanation of how Heartbleed, one of the worst (THE worst?), Internet security flaw, works:

What versions of the OpenSSL are affected?

* OpenSSL 1.0.1 through 1.0.1f (inclusive) are vulnerable

* OpenSSL 1.0.1g is NOT vulnerable

* OpenSSL 1.0.0 branch is NOT vulnerable

* OpenSSL 0.9.8 branch is NOT vulnerable

* Bug was introduced to OpenSSL in December 2011 and has been out in the wild since OpenSSL release 1.0.1 on 14th of March 2012. OpenSSL 1.0.1g released on 7th of April 2014 fixes the bug.

As a follow up to my last post about ARM’s annoucement concerning their move to clang/LLVM.

Seems that more of the GPL-only mindset are upset that ARM is another company that is picking up and carrying the LLVM torch for their future development activities.

My take on it is it is a good thing, something they could not do with GCC without violating the GPL license that they would have to follow. Clang/LLVM is licensed with a BSD-style license and not wanting to get in to a religious war over open source licensing, their LLVM selection and thus license choice allows them to keep things proprietary while working on new designs and code and releasing that to development partners like they currently do with their in-house ARM/Keli development environment. Then there is the problem of linking and including non-open code in end-user projects if they would have chosen GCC, this is a non-trivial problem for private and public companies dealing with IP that has extreme competition.

As ARM’s new designs become public, they can then push LLVM changes to the public branch and, we as end-users, then get to enjoy the benefits of what they can release. Will there be code components that they alway keep private and/or charge for in their commerical ‘ulitmate’ compiler version, maybe, but the code that does make it to the git repo will be vetted by the company that actually produces the MCU designs. Good enough for me, GPL be damned in this case…

Very cool news from ARM Holding the other day. They are formally adopting clang/LLVM as their future compiler. If you have been following LLVM commits, you might have noticed that AArch64 support has been making progress for quite some time, and now ARM is publicly releasing v6 of their compiler:

ARM announces the availability of version 6 of the ARM Compiler, the reference code generation toolchain for the ARM® architecture. ARM Compiler 6 adopts the Clang and LLVM open source compiler framework, channeling contributions from the whole ARM Partnership to improve code quality, performance and power efficiency of software on ARM processors.

The flexible and modern Clang and LLVM infrastructure provides a solid foundation for ARM’s code generation tools. Clang is a C/C++ compiler front end based on a modular architecture with well-defined interfaces for applying complimentary tools such as code analyzers and code generators. Clang also offers improved diagnostic capabilities, leading to higher quality code and shorter development cycles.

ARM’s Press Release

I am really looking forward to when they start contributing on the existing Cortex-M backend in LLVM. :-)

I merged the latest changes from QEMU 2.0 RC master into the changes that I am making and noticed that since there is no default ARM ‘machine’ any more, you can not get a cpu listing without giving it a machine:

1
2
3

qemu-system-arm -cpu help
No machine specified, and there is no default.
Use -machine help to list supported machines!

So now, you will need to include any machine (–machine help) in order to see the cpu listing, using the ARM Cortex-M0+ dev board that I am putting together (sushi-m0plus-board), you can get the cpu listing.

The cores; cortex-m0, cortex-m0+ and machine; sushi-m0plus-board, are my additions and not apart of the QEMU main-line code.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

qemu-system-arm --machine sushi-m0plus-board -cpu help
Available CPUs:
  arm1026
  arm1136
  arm1136-r2
  arm1176
  arm11mpcore
  arm926
  arm946
  cortex-a15
  cortex-a8
  cortex-a9
  cortex-m0
  cortex-m0plus
  cortex-m3
  pxa250
  pxa255
  pxa260
  pxa261
  pxa262
  pxa270-a0
  pxa270-a1
  pxa270
  pxa270-b0
  pxa270-b1
  pxa270-c0
  pxa270-c5
  sa1100
  sa1110
  ti925t

I tend to use semi-hosting via QEMU simluation and OpenJTAG/OpenOCD a lot; i.e.: for debugging, simulating sensor input and output, setting the RTC on a board for the first time and while the RMI Monitor interface is built-in to newlib stdio functions like printf, using a library like stdio is not really an option when a core only has 8k of ROM and 2k of RAM. So I need a really small printf routine to use on cores like the Kinetis KL03 (MKL03Z32CAF4R)

1
2
3
4
5

MEMORY
{
  FLASH (rx)      : ORIGIN = 0x00000000, LENGTH = 0x02000 /* 8K */
  RAM (xrw)       : ORIGIN = 0x20000000, LENGTH = 0x00800 /* 2K */
}

There are a lot of embedded printf routines posted with a variety of features and mine is just a collection/combo of various standard practices. The main difference of mine is it normally uses SVC/BKPT routines to perform the ‘print’ output and I try to make sure that optimizations via LLVM are taken advantage of.

So the question of how small of a routine is it as otherwise it is useless on something like the ‘world’s smallest ARM’ KL03? Lets start with a newlib stdio version that uses the default syscalls that have RMI enabled. First you have to some heap as newlib printf using malloc.

1
2
3
4
5
6
7
8
9
10
11
12

#include <stdio.h>
#include "printf_svc.h"

int main (void)
{
  printf("BKPT Hello World\n");
  printf("How small is this?\n");
  
  svcExit(); // QEMU system exit
  
  while (1) { };
}

The code size of the complete program above is huge if you are trying to run it on a Cortex-M0+ that only has 8K of ROM and 2k of RAM. Over 32K of ROM and 2+K of RAM just to output two lines of code!

1
2

text    data     bss     dec     hex filename
  33160    2304    1256   36720    8f70 bin/main.axf

So lets use a printf that is self-contained and uses no heap (malloc) and update our test code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

#include "printf.h"
#include "printf_svc.h"

void putc (void* p, char c)
{
  svcPutChar(&c);
}

int main (void)
{
  set_putc(putc);
  printf("BKPT Hello World\n");
  printf("How small is this?\n");
  
  svcExit(); // QEMU system exit
  
  while (1) { };
}

Now that is more like it, 2k of ROM and 64 bytes of RAM: Debug code size:

1
2

text    data     bss     dec     hex filename
   2102      64      10    2176     880 bin/main.axf

In release configuration it is even better, ~1k of ROM is use, RAM is the same as expected; Release code size, LLVM compiled with -Os, linked with -O4:

1
2

text    data     bss     dec     hex filename
   1106      64      10    1180     49c bin/main.axf

Adding 10 more printf statements that each contain a different but static 10 char string only adds 210 bytes to the ROM. Removing the 100 bytes for static string allocation, that breaks down to 10 bytes for the printf call. This can be improved upon a little, but 10 bytes is acceptable for now.

1
2

text    data     bss     dec     hex filename
   1316      64       8    1388     56c bin/main.axf

A quick break down of elf size:

text: your code, vector table plus constants.

data: Initialized variables, and it counts for RAM and FLASH. The linker allocates data in FLASH which then is copied from ROM to RAM in the startup code (in startup.c via the Reset_Handler function in my case)

bss: Uninitialized data in RAM which is initialized with zero in the startup code (again see the Reset_Handler function)

I have been mainly using clang/llvm and GNU binutils for my ARM coding, along with arm-none-eabi-gcc for code comparisions against llvm.

But I was wondering how much ARM’s DS-5 (Keil) IDE and compiler cost and found a couple of places in the ‘net that actually publish the prices (like Newark / Element14):

ARM DS-5 PROFESSIONAL:

Floating license price: $10,750.00 (USD)

Node locked price: $6,600.00 (USD)

Ouch! I used their eval offer and if I was doing ARM coding full-time, yes, 10 grand for what they offer would be a no-brainer.

What I really would like to have is the ARM/Keil DStream (debug & trace unit) at only $3,500 USD (DigiKey)…. damn is it nice, 4GB of trace buffer, 60 Mhz JTAG, etc… But again like so many other embedded vendors they only offer Windows and Linux support. Never understood the standpoint of supporting Linux and not OS-X. Windows only support I actually understand from a marketshare point of view and optimizing drivers and software is a lot of work, but if you are going to support Linux, you might as well add another 5% to your dev budget and support OS-X.

Mfg Part No: DSTRM-KT-0181A : Price: $3500

I been using QEMU a lot recently to model some Cortex-M0+ software that I am working on.

While technically speaking QEMU does not have a “Cortex-M0(+)” cpu in its feature set, it does have a M3 core and I have used it to create some Cortex-M0+ cpus that model some cores from a couple of ARM vendors, and then added some supporting dev boards (‘machines’ per QEMU nomenclature). I’ve been waiting till the QEMU 2.0 release to get my new ARM coding sorted out as major versions usually cause large changes in APIs, C headers, usage patterns, etc… and well, QEMU is tough enough to work through and I did not plan on doing it twice…

Well, we are getting close, QEMU 2.0 RC0 just released as a tar ball (not in the git repo?), so I did the download, configured and built on OS-X for “arm-softmmu”. Everything is great so far, ran some of my work through it and have not found anything amiss. Interesting that the version that shows up as QEMU emulator version 1.7.90 (BTW: the version on the git master branch is 1.7.5?)

1
2

qemu-system-arm -version
QEMU emulator version 1.7.90, Copyright (c) 2003-2008 Fabrice Bellard

There are a few new machines available: * canon-a1100 Canon PowerShot A1100 IS * cubieboard cubietech cubieboard * virt ARM Virtual Machine

The cubie board makes sense as you can use it to test Linux image builds and what-not. I am not sure of the usage pattern for the “Canon PowerShot A1100 DIGIC”, is the DIGIC 4 Image Processor available for purchuse? I’ll have to look into this one as it leaves me confused.

The interesting one is the fact that there is now a ‘virt’ machine for ARM. I’m not sure that I will personally have a use for using virtio devices in any embedded ARM dev work, but you never know.

Nothing new in the ARM cpu listing, so I guess I will continue with my ARM core and machine work…

The change log for ARM shows the following: * Support for “-M virt”, a board type that only uses virtio devices * Support for “-cpu host” when running under KVM * Support for new 32-bit mode ARMv8 instructions in TCG * Support for AArch64 disassembling (requires a C++ compiler to be installed on the host) * Support for AArch64 user-mode emulation * Initial support for KVM on AArch64 systems (some features such as migration are not yet implemented) * Support for the Canon PowerShot A1100 DIGIC board using “-M canon-a1100” * Support for the allwinner-a10-based board “-M cubieboard” * Support for flow control in the Cadence UART