sigrok – cross-platform, open-source logic analyzer software with protocol decoder support

sigrok logo

I'm happy to finally announce an open-source (GNU GPL), cross-platform (Linux, Mac OS X, FreeBSD, Windows, ...) logic analyzer software package myself and Bert Vermeulen have been working on for quite a long time now: sigrok (it groks your signals).

History

I originally started working on an open-source logic analyzer software named "flosslogic" in 2010, because I grew tired of almost all devices having a proprietary and Windows-only software, often with limited features, limited input/output file formats, limited usability, limited protocol decoder support, and so on. Thus, the goal was to write a portable, GPL'd, software that can talk to many different logic analyzers via modules/plugins, supports many input/output formats, and many different protocol decoders.

The advantage being, that every time we add a new driver for another logic analyzer it automatically supports all the input/output formats we already have, you can use all the protocol decoders we already wrote, etc. It also works the other way around: If someone writes a new protocol decoder or file format driver, it can automatically be used with any of the supported logic analyzers out of the box.

Turns out Bert Vermeulen had been working on a similar software for a while too (due to exactly the same reasons, crappy Windows software, etc.) so it was only logical that we joined forces and worked on this together. We kept Bert's name for the software package ("sigrok"), set up a SourceForge project, mailing lists, IRC channel, wiki, etc. and started working.

Overview, Features

You can get the lastest sigrok source code from our main git repository:

  $ git clone git://sigrok.git.sourceforge.net/gitroot/sigrok/sigrok

Here's a short overview of sigrok and its features as of today. The software consists of the following components:

  • libsigrok, a shared library written in C, which contains the general infrastructure for handling logic analyzer data in a streaming fashion.
    sigrok logic analyzer collection 2011
    It also contains the individual hardware drivers which add support for various logic analyzers. Currently supported hardware includes: Saleae Logic, CWAV USBee SX, Openbench Logic Sniffer (OLS), ZEROPLUS Logic Cube LAP-C, ASIX Sigma/Sigma2, ChronoVu LA8, and others. Many more devices are on our TODO list (and we already own them), it's just a matter of time to reverse engineer the USB protocols and implement a driver for them.

    Thanks ASIX for being open and helping with the ASIX Sigma driver, and many thanks to ChronoVu for being open as well and providing information about the ChronoVu LA8 protocol! Thanks to Håvard Espeland, Martin Stensgård, and Carl Henrik Lunde (who contributed the ASIX Sigma driver), Sven Peter and "Haxx Enterprises"/bushing (for contributing the ZEROPLUS Logic Cube LAP-C driver, ported from their zerominus tool). Also, thanks to Daniel Ribeiro and Renato Caldas who worked on the Link Instruments MSO-19 driver (still work in progress).

    Finally, libsigrok also contains the individual input/output file format drivers. Currently supported are: sigrok session (the default format, which contains all metadata), bits, hex, ASCII, binary, gnuplot, the OpenBench Logic Sniffer format, the ChronoVu LA8 format, Value Change Dump (VCD) viewable in gtkwave, and Comma-separated values (CSV).
    sigrok VCD file in gtkwave

  • libsigrokdecode, a shared library written in C, which contains the protocol decoder infrastructure and the protocol decoders themselves, which are written in Python (>= 3.0).

    The list of currently supported protocol decoders includes:

      dcf77                DCF77 time protocol
  lpc                  Low-Pin-Count
  mx25lxx05d           Macronix MX25Lxx05D
  jtag_stm32           Joint Test Action Group / ST STM32
  i2s                  Integrated Interchip Sound
  spi                  Serial Peripheral Interface
  edid                 Extended display identification data
  pan1321              Panasonic PAN1321
  mlx90614             Melexis MLX90614
  jtag                 Joint Test Action Group
  rtc8564              Epson RTC-8564 JE/NB
  transitioncounter    Pin transition counter
  usb                  Universal Serial Bus
  i2cdemux             I2C demultiplexer
  i2c                  Inter-Integrated Circuit
  i2cfilter            I2C filter
  mxc6225xu            MEMSIC MXC6225XU
  uart                 Universal Asynchronous Receiver/Transmitter

    Many more decoders are on our TODO list, and we especially welcome contributed protocol decoders, of course! We intentionally chose Python as implementation language for the decoders, to make them as easy to write (and understand) as possible, even if that means that performance suffers a bit. Have a look at the SPI decoder for example, to get a feeling for the implementation.

    Protocol decoders can be stacked on top of each other, e.g. you can run the i2c decoder and pipe its output into the rtc8564 (Epson RTC-8564 JE/NB) decoder for further processing of the RTC-specific, higher-level protocol. We also plan to support more complex stacking and combining of decoders in various ways in the nearer future.

  • sigrok-cli, is a command-line frontend, which uses both libsigrok and libsigrokdecode. It can acquire samples from logic analyzers and output them in various formats into files or to stdout, and/or run protocol decoders on the aquired data.

    Example: Data acquisition with 1MHz samplerate into a file.

     $ sigrok-cli -d chronovu-la8:samplerate=1mhz --time 1ms -o test.sr

    Example: Protocol decoding (JTAG).

     $ sigrok-cli -i test.sr -a jtag:tdi=5:tms=2:tck=3:tdo=7
 [...]
 jtag: "New state: EXIT1-IR"
 jtag: "IR TDI: 11111110, 8 bits"
 jtag: "IR TDO: 11110001, 8 bits"
 jtag: "New state: UPDATE-IR"
 jtag: "New state: RUN-TEST/IDLE"
 [...]

  • sigrok-qt, a Qt-based GUI for sigrok, using both libsigrok and libsigrokdecode.

    This is intended to be a cross-platform GUI (runs fine and looks "native" on Linux, Windows, Mac OS X) supporting data acquisition and protocol decoding.

    NOTE: The Qt GUI is not yet usable! We're working on getting it out of alpha-stage for the next release.

  • sigrok-gtk, a GTK+-based GUI for sigrok, using both libsigrok and libsigrokdecode (soon).
    sigrok-gtk
    This is a cross-platform GUI contributed by Gareth McMullin (thanks!), supporting data aqcuisition (and soon protocol decoding).

    NOTE: The GTK+ GUI is not yet fully usable (but it's more usable than sigrok-qt)! Consider it alpha-stage software for now.

We're happy to hear about other (maybe special-purpose) frontends you may want to write using libsigrok/libsigrokdecode as helper libs!

Firmware

Saleae Logic

Some logic analyzer devices require firmware to be uploaded before they can be used. As always, firmware is a bit of a pain, but here's what we currently do: For non-free firmware we provide instructions how to extract it from the vendor software or from USB dumps, if possible. For distributable firmware we have a git repo where you can get it (thanks ASIX for allowing us to distribute the ASIX Sigma/Sigma2 firmware files!).

  $ git clone git://sigrok.git.sourceforge.net/gitroot/sigrok/sigrok-firmwares

Finally, for all Cypress FX2 based logic analyzers we have an open-source (GNU GPL) firmware named fx2lafw, started by myself, but most work (and finishing the firmware) was then done by Joel Holdsworth, thanks! The support list includes Saleae Logic, CWAV USBee SX, CWAV USBee AX, Robomotic Minilogic/BugLogic3, Braintechnology USB-LPS, and many others. Get the code from the fw2lafw git repository:

  $ git clone git://sigrok.git.sourceforge.net/gitroot/sigrok/fx2lafw

Example dumps

We collect various captured logic analyzer signals / protocol dumps in the sigrok-dumps git repository:

  $ git clone git://sigrok.git.sourceforge.net/gitroot/sigrok/sigrok-dumps

They can be useful for testing the sigrok command-line application, the sigrok GUIs, or the protocol decoders.

We're happy to include further contributed example data in our repository, please send us .sr files of any interesting data/protocol you may come across (even if sigrok doesn't yet have a protocol decoder for that protocol). See the Example dumps wiki page for details.

Packages, distros, installers

sigrok Windows installer

I'm currently working on updated Debian packages for sigrok (will be apt-get install sigrok to get everything), and we're happy about further packaging efforts for other distros. We have preliminary Windows installer files (using NSIS), but the Windows code needs some more fixes and portability improvements before it's really usable. On Mac OS X you can use fink/Macports to install as usual, fancier .app installer files are being worked on.

Future

Apart from support for more logic analyzers, input/output formats, and protocol decoders, we have a number of other plans for the next few releases. This includes support for analog data, i.e. support for (USB) oscilloscopes, multimeters, spectrum analyzers, and such stuff. This will also require additional GUI support (which could take a while). Also, we want to improve/fix the Windows support, and test/port sigrok to other architectures we come across. Performance improvements for the protocol decoding as well as more features there are also planned.

Contact

Feel free to contact us on the sigrok-devel mailing list, or in the IRC channel #sigrok on Freenode. There's also an identi.ca group for sigrok. We're always happy about feedback, bug reports, suggestions for improving sigrok, and patches of course!

Google releases Intel Sandybridge support for coreboot

Exciting times! In the last couple of days, Google has released a major piece of coreboot support for the Intel Sandybridge processor and Cougar Point southbridge. This is the first time that coreboot supports the latest generation of Intel chipsets. In the next weeks more code will be released to support a number of mainboards with this processor/chipset combination. Stay tuned!

Check out the article on Phoronix.

 

Flip Bits, Not Burgers – coreboot GSoC 2012 – Update

Update –

coreboot was not selected to participate in GSoC 2012. This is
disappointing new for the project. I do not know why we were not
selected this year. I will attend the post selection meeting to see
what we can do to improve our chances of selection next year.

Students, thank you for your interest in coreboot. We are happy that
you are engaging with our community. I hope that you continue
exploring your interest in coreboot. Please let us know what we can do
to assist you in your learning.

Feel free to send me questions, comments, or concerns.

Regards,
Marc

http://google-opensource.blogspot.com/

Continue reading Flip Bits, Not Burgers – coreboot GSoC 2012 – Update

Intel i5000 northbridge code commited

I’ve started that port in November 2011, and made it finally working in January. Well, at least working on my Supermicro X7DB8 Board. Compared to the vendor BIOS which takes about 30 seconds from power-on to grub, coreboot finishes the same task in 3s. Unfortunately the VGA BIOS takes about 2 seconds to program the register to do 80×25 resolution, so eventually we end up with 5s. If you don’t need a VGA console, and prefer a serial console, you can save even these two seconds.

Actually i didn’t expect the port progressing so fast. One tool that was a great help was serialice. I used it to watch the original BIOS initializing memory. To get serialice running, all you have to do is writing a few lines of board specific C code, which initializes the serial port and some basic chipset parts required for accessing the serial port registers. On the host side, a patched QEMU is running, executing the vendor BIOS while redirecting HW accesses to the target computer. Which HW accesses are redirected can be configured by a small lua script. LUA can also be used to pretty print the output from serialice.

Continue reading Intel i5000 northbridge code commited

Coreboot in shipping products

We are starting to see coreboot in more shipping products this summer and I expect even more in the fall. The exciting thing is that coreboot is becoming a piece of technology that vendors are starting to advertise. A recent example is the Portwell PCS-8277:

PORTWELL ANNOUNCES REVOLUTIONARY IN-VEHICLE PC
WITH THE BOOT SPEED OF AN APPLIANCE New PCS-8277 telematics system based on Coreboot® technology with HD graphics processing engine 

I think that we are starting to see vendors and customers becoming more knowledgeable about what is going into their products and how coreboot is an advantage in many situations. I hope to see more announcements in the coming months.

Flashrom 0.9.4 released – Flashing BIOS/ROM chips from the Unix/Linux command line using various programmers

flashrom logo

Forgot to mention this here: We released flashrom 0.9.4 a few days ago, the latest release of the open-source, GPL'd ROM chip flashing software for Linux, *BSD, DOS, and partially also Windows (work in progress, though).

Here's a quick summary of the release announcement. Some of the noteworthy news items include:

  • Support for new programmers: OpenMoko Neo1973/Neo FreeRunner debug board version 2 or 3, Olimex ARM-USB-TINY, ARM-USB-TINY-H, ARM-USB-OCD, and ARM-USB-OCD-H, Open Graphics Project development card (OGD1), Angelbird Wings PCIe SSD/88SX7042, ITE IT85xx embedded controllers, Intel NICs with parallel flash.
  • Dozens of added flash chips, chipsets, mainboards.
  • Improved Dediprog SF100 support.
  • Add support for more than one Super I/O or EC per machine.
  • Always read the flash chip before writing, for improved error checking and faster programming.
  • Enable write support on NVIDIA MCP6x/MCP7x.
  • Lots of bugfixes, documentation fixes, internal improvements, etc.

Get the latest release tarball, or download and build the most recent version via Subversion:

  $ svn co svn://flashrom.org/flashrom/trunk flashrom
  $ cd flashrom
  $ make

I already updated the Debian package to 0.9.4 (it has also already migrated to Debian testing and Ubuntu), other people have updated Fedora, Gentoo, NetBSD etc. etc.

There's already a huge amount of patches queued for the next release, including support for even more programmers, PowerPC support (tested on Mac Mini and others), and of course the usual "more boards, more chips" items...

GSoC: Spice Payload report

Yeah! it`s came the time to write another report on GSoC status. In fact I`ve – intentionally – postponed it for quite some time and it doesn`t exactly mean there was a lack of informative emails between me and Marc(my mentor).

The need to finish some stuffs justifies – in some ways – the aforementioned delay. I understand you don`t need to report you aren`t done with something, a mail stating “I`m not done yet” would be enough – well, maybe not anyway…

OpenEmbedded Journey

With the second half of my project I jumped in the OpenEmbedded ecosystem and believe it, I`ve loved to get in touch with.

Putting my hands on OE is something I`ve planned for some time, I just hadn`t had the time to do so.

OpenEmbedded is something amazing, and it does what I realized years ago when I worked with gentoo. I always saw gentoo as a great meta-distribution, something you can bend and forge as you need – customizing it according to your needs.

Despite all the conceptual things touching OE wasn`t as easy as I initially tought it would. Bitbake(the great maestro behind OE) was designed with portage in mind and theoretically it was I good advantaged to me – look, theoretically.

Nothing is exactly smooth as you plan, you`ll always get troubles in the way – with OE wasn`t an exception.

OE transitions and yocto project

One of the biggest problems I faced was mainly due the transition the OE project is getting through. The docs(Getting started wiki page for example) are out dated and you get conducted by the old code base, and trust me, it`s not a good way to get started.

My first two weeks was full of crazy hacks, searching for old tarballs, setting up local source repositories, doing everything I could to make that thing to work – it was a bad race doing my best to proof the howtos.

The true is OpenEnbedded has moved to what we name bblayer, it`s a bitbake feature to ease to extend a base system. The intention(as I see) is to keep a minimal, clean and stable set of core packages and yet make it possible to “third party” vendors to append it to fit their needs.

The yocto project has extensively used OpenEmbedded as their base system, both the projects have exchanged a lot and sometimes you loose yourself if you`re touching one or the other. One of the tools provided by yocto project is Poky – which`s actually an OE layer.

There isn`t plenty of docs describing how the bblayer and bbappend work – the bitbake docs aren`t much precise and the OpenEmbedded barely mention it, yocto just describes how it`s fit within poky(or something close to that).

I would really like to recommend newcomers to first play with poky then later consider starting a new third-party layer.

The project as a bblayer

A third party layer is what best fits my project, not exactly a full yocto/poky layer, maybe and extension of it or not even that but an own layer itself, to accomplish that I had to experiment a lot, setting the environment up and watching how everything get together.

Packaging

After many years not touching a single ebuild and having never touched a bb package I jumped in the task to pack some components. The spice client has a bunch of dependencies – of course, I hadn`t to pack everything myself, a great number of things were already done.

Among the things that got me longer then I expected was cyrus-sasl, the old OE tree had it packaged but it was an old version – should I mention it was broken as well?

So, bringing the recipes wouldn`t be enough but I would have to fix things up, once fixing stuffs was the only alternative I decided to upgrade it to the latest version 2.1.31.

Anyway, it brought me a lot of work to pick patches to fix its building and fixing what hadn`t got fixed already. My final PR was 177 what means I came through 177 builds, debugging, testing and working everything around.

The cyrus-sasl code has a bug introduced after 2.1.21, it wasn`t possible to build it –with-static. I did an ugly and ridiculous fix. Everything I found out there – searching the internet – was even uglier. Suggestions to run make twice was one of them. The build system was kind of messed up.

The other packages weren`t so painful and I could quickly move forward.

Slimming the image

I still have to slim few things, I need to cut some X11 packages I included in the image, append the yocto kernel with my own .config and write a small shell script(or something smarter than that) to launch the spice client.

BuildRom

The first thing I worked on in the beginning of my project was buildRom, I wanted to bring all the tasks involved on building the OS image and bios/firmware into to it. But, with my move to OE for building the OS image I realized I could go the reversed way and bring the tasks for building the bios/firmware to OE.

Now I`ve manually packaged the things but have already started to write bbclass to controll bios/firmware + image building and packaging them. I see it as a second generation to BuildRom project, a OE layer with coreboot bb packages and recipes plus the needed bb classes.

Conclusion

After the great effort I had, getting in touch by the first time with OE, I feel comfortable to say it was a good experience to me, I realized many possibilities. I`m really happy with everything I learned on the path and I`m sure I still have a lot to contribute to Coreboot and OE as well.

GSoC 2011: flashrom part 5 – Dear Intel

As mentioned in my GSoC recap, Carl-Daniel and i have sent a letter to Intel to get more information regarding the descriptor section and unlocking the ME flash protection (my official GSoC main project). It was sent about 3 weeks ago (2011-07-29). No reply was received so far. This is the whole message we have sent them: Continue reading GSoC 2011: flashrom part 5 – Dear Intel