Integrity Porting

Tweet this Print

Have you ever been to Japan? My experience was very strange. Everything seemed familiar at first glance, but when I tried something – walk the streets, ride the train, buy at stores, use the washrooms – I realized that nothing is as it seems and everything is different. So different it might just as well be another planet – complete with strange glyph writing, unexpected underground passages, and strange stuff for sale. Remind me to tell you about the half Santa*.


A Japanese experience

Why am I bringing Japan into this techie blog? Because of software porting. Porting software from one operating system to another is much like visiting Japan: everything seems familiar – same concepts, same services, same methodologies. But when you try to use them, you realize you’re not in Kansas anymore. Take Integrity, for example. We just finished porting our SIP stack to Integrity 5.0, and by “we” I mean Igor Novoseltsev, our resident expert. I sat with him to chat a bit about his experiences and lessons.

When I say, “porting the SIP stack”, I actually mean porting the Common Core, our OS abstraction layer. All of our products use the Common Core layer to access the network, use threads and locks, allocate memory, log, for standard data structures, etc. It saves a lot of time and effort, especially when porting. Once the common core is ported, there is only a minor effort to port any of the products that use it.

Integrity OS

Integrity is an operating system developed by Green Hills Software (GHS). It is a real-time operating system for embedded systems, designed with reliability and security in mind – this is achieved by using hardware memory protection to protect tasks from accidental errors or malicious tampering. It is proudly non-compatible with existing “80′s” operating systems (I think they’re dissing MS Windows), having been designed from the ground up. Luckily, that does not stand for “an unfamiliar set of APIs”, since Integrity supports the POSIX standards, common to many UNIX systems.

As our SIP stack contains an OS abstraction layer we call “common core”, and our common core already supports the POSIX APIs and was compatible with Integrity 4.0, we recently embarked on a mission to port it to Integrity 5.0, the latest release of the Integrity OS. Why? Because a customer asked for it, of course.

GHS provided us with the operating system files for the embedded system and their equivalent to the Microsoft’s Visual Studio IDE, Multi. Unfortunately for us, we usually use make files to compile our projects on non-windows systems, and we were reluctant to create and maintain a workspace for Integrity – having too many build systems isn’t a lot of fun.

Of course, the compiler and linker allow command-line activation, and although it was documented, there were some options and flags (used by Multi) which were undocumented. We asked for a little help from Green Hills representatives here in Israel, which were very responsive and provided us with sample make files, allowing us to compile our SIP stack and run it on the provided simulator.

Now all we needed was to try it out for real.

Going Embedded

The first rule of embedded operating systems is, and anyone who has worked on those will tell you that: it’s not over until it the board runs. Simulators have come a long way, but nothing can simulate the nooks and crannies of an embedded, real-time OS running on the actual hardware. However, it is also true that nothing is as frustrating and time consuming as trying to setup some new embedded system that just won’t do what you want.

The board we used was an Atmel ARM-based board (AT91SAM9263). We tried to bring it to life, only to discover, after a few frustrating days of work and with the help of the excellent Atmel support, that the Integrity version we had supports the AT91SAM9261, which, of course, is non-compatible with its -3 variant.

Again, GHS support came to our rescue and provided us with a compatible version, yet we discovered (in the documentation) that the only way to configure the board was with some device called a probe, or with a data-flash card. We had neither, nor the available time to order any (the customer was waiting), and so we decided to move from the Atmel board to a TI DaVinci board – we had a few of those due to the BEEHD project.

Unfortunately, things didn’t go smoothly there either. Again, documentation insisted that we have to use a probe to burn the kernel on to the board. And so GHS came through for us once more: they invited us to their offices, where they can burn the OS on to the board for us.

And so we drove over, with the board in hand, only to discover that the exact version we used was not supported. No surprises there, as we got it straight from the TI presses. (We and the TI homies are like this – you can’t see, but I’m making the thing with the fingers right now. See picture for details). But, as it is brand new, no support yet.

But while we were there, we saw another Atmel board lying around, and we were, like, “can you lend us a data-flash card?”, and they were all, like, “we don’t usually do that”. And so, to make a long story short, we drove back to our office with an Integritized data-flash card.

From there it was easy to bootstrap U-Boot to the card and setup a TFTP server that will get our binary application, copy it to the correct memory location (0×2000000) and run it. The wonderful assistance from the AT91 SAM Portal community (supported by Atmel) and the U-Boot project didn’t hurt as well. Another few days of work and we had it eating from our palm, that is, running SIP. Customer happy, sale done, money in bank, nice PR to show for it (a PR is the sales equivalent of a T-shirt, isn’t it?)

So, What Did We Learn From All Of This?

  • Green Hills Software has a wonderful support team here in Israel. Thanks again, guys.
  • Atmel has a great support team as well. With the amount of products they provide worldwide support for, it is nothing short of miraculous.
  • Community sites are great for mental and actual support.
  • Document everything as you go. The next programmer to try the same thing will run into the same problems, so why not save him some of the bother? Here’s what we now have on Integrity: [Download not found]
  • We now have a solution for Integrity “out of the box” for customers.

Ran Arad

Ran Arad is a veteran developer in RADVISION's Technology Business Unit, dealing with protocols, media and everything in-between.
Tags: , , , , , , , , , , , , , , ,
Tweet this Print

One Response to Integrity Porting

  1. Pingback: INTEGRITY OS on ARM

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>