Resignation From Network Time Foundation

I don't often quote Bible verses but this seems like an appropriate time for "to every thing there is a season, and a time to every purpose under the heaven." I have served on the Network Time Foundation (NTF) board since its inception in 2012. It has been interesting being involved in the start of the foundation. But as the verse says, everything has a season and a purpose.

My primary responsibilities should always be to my family, career, and to my own free software project RTEMS. All of these need more of my attention. I want to do right for everyone and everything I am involved with.

After years in the free software community, I am always happy to share experiences and provide advice to other projects. I have seen a lot happen since the inception of RTEMS and learned a lot of lessons the hard way. If I can help someone avoid those pains, I am happy to. That offer applies equally to projects under the NTF umbrella as well as any others.

I will close with one piece of advice for all free software projects. Remember that it is all about the code and community. Get those right and the rest will fall into place.

What Android Apps Do I Use?

There are so many Android applications out there but I suspect my choice of apps is probably very mundane in comparison to others. My usage has evolved some as the Android devices are much more powerful and capable than the G1 I first had, although I miss the physical keyboard of the G1 and G2. In fact, my wife used a G1 until it physically broke. She cursed the HTC One S that replaced it until recently moving to a Moto G. The Moto G is a very nice phone for the price and she is pleased with it. But this is not about how my family feels about their phones, it is about the apps I use so here are the apps I use:

• Google apps - I am just going to lump the ones I use into one bullet item. I use Gmail, Calendar, Messenger for SMS/MMS, Chrome, News, Maps, Drive for documents (not backup), Voice, Translate, YouTube occasionally, and am experimenting with Keep.
• K-9 Mail - I probably spend more time in this application than any other. I used the Google Email client for years until I started getting complaints that sometimes messages from me did not thread properly in the RTEMS mailing list discussions. Chris Johns had me send email from every computer and client I used. Turned out that the Google Email client does not send the proper headers. This means that the threading that is relied on by open source community mailing lists is broken, has had a long outstanding bug, and doesn't seem like it will ever get fixed. I tried K-9 and never looked back. It is a very capable Email client for "work" accounts. I used Gmail for my personal mail.
• Apps which help when traveling:
• TVFoodMaps - This is one I used when traveling to see which restaurants have been featured on television shows on the FoodTV network. It sounds kitschy but it is a neat way to find a local place I would never think of trying otherwise. Review sites often recommend the same places but often travelers don't find the truly historic, unique places, or know what a local specialty that shouldn't be missed.
• TripIt Travel Organizer - Another handy app for traveling which provides a mobile interface to the web site. TripIt works by you forwarding email with hotel reservations, car reservations, and plane tickets to it. It then builds an itinerary for you and reminds you of upcoming travel. When on travel, it makes it easy to get destination addresses, confirmation numbers, etc. This is much easier than carrying paper.
• Fly Delta -  This app has improved a lot since I first used it. Everyone hates some airline but Delta has the best options from Huntsville. This gives me notices on gates, arrival time, bar code for paperless boarding, and Sky Club locations. Not essential since I could likely do all this with the website (except paperless boarding) but handy.
• Utilities
• OpenIntents - This project has a collection of apps which include a Notepad, Shopping List, and a File Manager. The shopping list is one of those specialty apps which is very handy.
• Astro File Manager - Just a nice file browser.
• Miscelaneous
• Untappd - Log beers, earn badges, see what friends are drinking and get recommendations. I am a big fan of craft and unusual beers. I like to try different beers as much as I can and this helps me keep track. 
• Vintage Comic Droid - This is a neat application that lets you read comic books that have fallen into the public domain. I primarily use it in off-line mode to kill time. 
• TV Guide - An application with functionality that matches its name. It is nothing more than TV listings but it does know cable systems and highlights new shows as well as let you search, and set alerts. A bit painful to use on small screens but handy.

Probably not that unique a set of applications but it is how I get by. Most of these I have used for years and through multiple Android versions.

In most cases, I refuse to load apps which are only a front end to a website. I can just use Chrome and get there. And I get irritated when a site pushes me to load an app -- LinkedIn comes up high on this list. If anyone is listening, asking me every time if I want to load your stupid site specific app is a turn off for your site in general. If you want to lose me as a user, remember my preference.

Moving to a Nexus 6

Normally I blog about RTEMS and related embedded systems topics. This time is different. I ordered a 64 GB Jedi Blue Nexus 6 on November 25 and it just arrived today (December 22).  When I placed the order, the store person heard me complain about my Nexus 4 thinking a wired headset was randomly plugged in and I had some plan feature which let me get a replacement for USD5. That turned out to be an interesting adventure but I will summarize it in a few bullets:

• November 25 - order replacement Nexus 4 and Nexus 6 which was TBD delivery. You can see the box to the right and not have to wait as long as I did. 
• November 26 - replacement Nexus 4 arrives, migration goes smoothly, updates to Lollipop, and then I discover radio part of phone is bad. It won't connect to cell network. Back to old Nexus 4.
• November 28 - second (or third depending on how you count) Nexus 4 arrives. This time the transition is painful. I ended up spending almost two hours the next day manually loading applications and entering passwords. Luckily, I had a spare screen protector and used the old case. Back in action again.

I have been experiencing Lollilop with all of those Nexus 4's and even got the 5.0.1 upgrade last week. It is a nice experience with my only complaint being that I somehow can't seem to stay on the screen for a call in-session. That means I have to switch apps to hang up. My Nexus 7 upgraded smoothly but it went through another round of slow down and I had to another factory reset. This seems to be a common occurrence with the 2012 Nexus 7 models as they age and the Flash memory ages. I have seen reports on the net of switching apps taking a minute. Mine got that way under KitKat before I factory reset it. If someone has a good way to speed it back up, let me know. 

Today the Nexus 6 arrived while I was blowing leaves. Somehow I resisted abandoning the yard work. The first step was copying the files off my Nexus 4 yet AGAIN. The box has a nifty embossed "6" on it and that's the top side. The first picture is what I thought was the top side. When I opened it using "that" top side, it almost fell out. Glad I had a towel on the table, just in case.

Of course, the phone couldn't stay in the box like that very long. It would take all the fun out of it. I was concerned that the high speed charger was going to be an accessory that was not included with the phone. That would mean another order and I just didn't want to have to do that a few days before Christmas. On average, I travel a week every four to six weeks and keeping a phone charged can be a challenge. Many times I am in meetings in buildings which are very effective Faraday cages. Nothing drains a battery faster than spotty or no service. I have learned to keep it in airplane mode and rely on my old Nexus 7 tablet but still I need to recharge using my external battery or wall charger. The Turbo Charger was a feature I was really looking forward to.

The phone was in a tray so I pulled the tray out. There was more in the box than was included with the Moto G or replacement Nexus 4. I am pretty sure that the Nexus 4 included a similar set of accessories when it was new though.  Inside the box, there is the phone (obviously) along with an instruction packet, what I hope is the quick charger, and a USB cable. Not immediately seeing a tool to open the SIM slot, I am let wondering if it included a tool to eject the SIM slot, I opened the instruction packet and did find a tool to open the SIM slot. Unwrapping the wall charger, I see the magic words Turbo Power Supply and that makes me happy. That makes me two for two on this so far.

Now on to migrating my information to the new phone. I had forgotten to back up my SMS and MMS so ran Backup to Gmail one last time,  When this was done, I was ready to turn off cellular data on the Nexus 4, power it off, and remove the SIM. While this was running, I decided to compare the two phones in size. On paper, the sizes don't sound that different but when you see them side by side, the difference is very clear.

Side by side, the Nexus 6 is clearly quite a bit larger than my old Nexus 4. My concern with a phone this large was (1) would it fit in a dress shirt pocket (it does) and (2) will it tend to fall out of a shirt pocket since it is taller and thus has a higher center of gravity. I tested (1) at the T-Mobile store and only time will tell about (2). I have a screen protector and case for the Nexus 6 and hope this will be enough to protect it if it drops.

Enough with the pictures already. I want to use the phone. I eject the SIM from the Nexus 4 and eject the holder on the Nexus 6. First surprise! The SIM in the Nexus 6 is smaller than that in the Nexus 4. I smile when I notice there is a SIM in the Nexus 6 already so I don't 'have to make an extra affort to acquire one. That was a nice touch. Now to call T-Mobile and get the new SIM activated.

All calls for support to any large company start with an automated system asking you all sorts of questions that eventually lead you to a human if you are lucky. T-Mobile is usually better than most companies for support and this time was no different. It took all of about two minutes before he asked me to boot the new phone. I stayed on the line with them through this. I get to the screen where it asks me if I want to Tap my old device and transfer settings. I turn on NFC on the Nexus 4 and tap the back of the devices. After a few seconds, it went on to set itself up quickly.

It immediately found an LTE tower, asked me for my Google account, and began synchronizing.  By the time I went to check on the status of WiFi, it had connected to the 2.4 Ghz channel of my access point. I switched it to the 5.0 Ghz and apps continued to update. One of the first updates was Android 5.0.1 which required a reboot. The phone had about 40% remaining on the battery when it first powered up and I expect that will be enough to finish the app installations. After clicking accept a few times, I decided to quit watching them download and begin to transfer files from my PC back onto the device. 

Then began the tedious process of entering account and passwords for various applications that were not covered by Google. I had done this a month ago when I went through the Nexus 4 swap and it is just as tedious this time. After a while doing this, I began to put the apps back on the main screen. In doing this, I noticed the Hilton app says it is incompatible with my device and refuses to load. Odd since it worked with the Nexus 4 on Lollipop. After about an hour from first power on, it is mostly setup.

I left it attached to the computer and it charged to 90% while downloading applications and updates. After the downloads stopped, I started playing with it. It is definitely large enough where it is more like a tablet when browsing. It is much faster than my Nexus 5 or Nexus 7. I am finishing this up the next morning and I have no complaints so far. I still need to tweak the notifications so I recognize the apps and go back to the ring tone I had before my phone got stolen last year but those are my problems.

If anyone cares, I will write another blog entry on what apps I have on my phone.

Intel Edison and RTEMS - Road Forward

The Intel Edison is now (11 December 2014) is now running RTEMS but there are issues to resolve and features which need adding. This post is a list of what needs to be done.

In the near term, the current code needs clean up before it can be submitted to the RTEMS Community. The following is a list of some of the activities which need to be performed before the code can be submitted:

• Break conditionals in build system and C code from "if Edison" to more features oriented conditionals. This requires being able to disable at least VGA, IDE, and legacy COM ports at BSP configure time.
• Split the current Edison specific polled console code into its own file. 
• Review dynamic console selection code and see if the current code can be improved so Edison specific conditionals are not needed.
• Generally split the one large patch into smaller discrete patches and try to not make them Edison specific.
• Write instructions.

There may be other clean up but that should be enough to get the current Edison support into the tree.

Longer term, there is more to do and it involves coding. Some of this can be done without access to Edison System On Chip documentation. But other parts will require having access to the details.

• Add support for APIC interrupt controller.
• Figure out why clock tick isn't working. This may require using different hardware for the clock tick driver.
• Provide access routines for the memory mapped PCI configuration space.
• Provide glue so hacked NS16550 console support can use libchip driver like COM[1-4] do. There is support already for PCI cards with multiple NS16550s so this should just be a matter of having the information once PCI configuration space is working.
• Test this driver polled
• Test this driver interrupt driven

That will get a complete basic BSP working with no hackery. Beyond this, RTEMS needs support for the other peripherals on the Edison:

• Add support for the discrete I/O and analog inputs.
• Evaluate supporting the Flash. We may want to be careful to not destroy the Linux installation or we may want to simply take over the entire Flash as long as we avoid conflicts with other uses. Having the Linux and USB file loading is nice. 
• Add WiFi support. This is a more involved project as RTEMS currently does not support TCP/IP over USB or WiFi. 
• Since the new FreeBSD 9.x TCP/IP  stack came with the USB stack, supporting wired Ethernet over USB is a logical first step and is also needed to support Ethernet on the Raspberry Pi.
• Once wired Ethernet over USB works, then the wireless part can be addressed including applications to manage connecting to access points.

There is probably more to do to fully support the Intel Edison board but it does work now and provides a baseline for future enhancements. At this point, interested users can fund core developers to add capabilities or volunteer to add it. That is how open source works.

Intel Edison and RTEMS - Day Three

Overnight, I realized that the error the RTEMS hello world sample was failing with was RTEMS_UNSATISFIED (13) likely indicated a miscalculation in the RTEMS Workspace by . A quick look showed that the primary difference between the pc586-sse BSP variant and all other pc386 variant was that because of SSE, all tasks were forced to be floating point tasks. This results in the allocation of floating point contexts for all tasks and apparently the calculation is a bit too low on the x86 port. I switched the edison BSP variant to be compiled like the non-SSE pc586 and this solved the problem. A short time later, this output was posted to the RTEMS Users mailing list.

## Starting application at 0x0010000c ...
024rtemsWorkAreaStart=12FD40 MemSize=0x08x/0

bspstart.c
work_area_start = 0x12FD40
work_area_size = 1072497344 0x3FED02C0
end = 0x40000000
current stack pointer = 0x12FD18
heap_start = 0x133B72
heap_size = 1072481422
initialize device drivers
probe
Checking on /dev/main
probe
Register /dev/main
Register /dev/main as console
Console initialize complete
post driver hook
rtems start multitasking


*** BEGIN OF TEST HELLO WORLD ***
Hello World
*** END OF TEST HELLO WORLD ***

EXECUTIVE SHUTDOWN! Any key to reboot...

At this point, the next step was simply to remove most of the debug output and get a clean run. Then we tackled seeing if enabling the timer calibration code in the pc386/startup/bspstart.c file would work. The calibration failed and likely indicates some combination of interrupt controller or timer hardware is different from legacy PCs. Fixing this is left for future work.

The failure to have a working clock tick meant that we needed a fall back. RTEMS has a target independent fake clock tick driver which is a special IDLE thread which repeatedly calls rtems_clock_tick() each time it is executed. When a "clock tick" occurs which wakes up another task, the IDLE thread is preempted. This is an effective way to run most RTEMS tests on a simulator with no interrupt sources.

With the IDLE thread clock tick in place, Jeff and I ran the ticker example which has three tasks executing every 5, 10, or 15 seconds. It runs for 35 seconds. Jeff and I tuned a delay in the IDLE thread until time appeared to pass reasonably close to it would on real target hardware if the system were lightly loaded.

After a few iterations, we moved on to the fileio sample test. This demonstrates the shell, IDE file access, and requires user input. On the first run, the test hung and we had to disable the IDE driver because the Edison does not have one. On the second run, it just worked.

That was midday on day three (11 Dec) and that was all that could be done without writing new code. Plus Jeff needed to get the Edison, a BeagleBone Black, and a Raspberry Pi working from a small laptop and then boxed up with cables. OAR has a table and will show them at the Flight Software Workshop in a few days )16-18 December  )

Intel Edison and RTEMS - Day One

It was Monday afternoon when an Intel Edison board showed up in the mail. It is quite small with an expansion board needed to have access to I/O. From an RTEMS perspective, it looks interesting because it has 40 discrete I/O pins and six analog inputs. The challenge was to see

how long it took to get the RTEMS up on this board.

It wasn't long at it was unboxed, that we were looking at a GNU/Linux prompt in a PuTTY window. Poking around, it quickly became apparent that the Edison didn't use Grub so my first hope that we could just add an RTEMS executable as an option on the boot menu was off the table. We had to identify a way to boot an RTEMS executable.

We had already noticed that U-Boot was on the board. Now the question was how to get an executable image into a bootable location and what the magic commands were to boot it. I came across this thread which had a lot of information on the Edison. It quickly became apparent that the Edison did not have much low-level public documentation yet and that support for most (if not all) legacy peripherals was not present. I posted an email to the RTEMS Users mailing list which summarized what we knew so far:

• SoC documentation won't be out until later this month.
• Has U-Boot and doesn't appear to have a 16-bit mode at all.
• Looks like U-Boot will want a binary image to boot.
• This turned out to be wrong. We figured out how to boot an ELF executable.
• There is a comment in the OS Dev forum that the PCI configuration space is memory mapped and not IO mapped like a regular PC. This means the PCI initialization and support code needs to be different for Edison from other PCs.
• All serial ports are on the PCI bus. It looks like the PCI layout is constant so for a start, we are hacking a simple polled driver for one UART and go from there. U-Boot initializes that port so we can skip initialization. Besides the person on the forum couldn't figure out the clock rate for the UART. This should be enough to at least temporarily get around the lack of PCI config space code.
• There is a watchdog on it that needs to be disabled or managed.
• Looks like it doesn't have a legacy i8254 timer and may not have legacy interrupt controller.

A user named mutex on the OS Dev forum had poked and prodded at the Edison board and managed to post a few very useful pieces of information.

• Base address of the UART and the U-Boot command to force a character out:
• mw.b 0xff010180 0x21 1
• Address of the watchdog control register along with commands to disable it:
• mw.l 0xff009000 0x10f8 1
• And to reset the board
• mw.l 0xff009000 0x10f8 0xf8
• Commands to boot a binary image.
• load emmc 0:9 0x100000 /kernel.img
• go 0x100000

I contacted this user. It was clear that he had been the most successful in booting something that wasn't the Linux that came with the board. He quickly replied. Thomas Nilsen has his own kernel and was kind enough to send me a binary which we were able to run. He is owed a big thank you.

This was the end of Monday with the board. 

RTEMS Texinfo Tools Update

A couple of years ago, Chris Johns and I began to discuss that RTEMS has had a long and successful history as a free software project. One aspect of this discussion resulted in the Open Source and Generational Differences. This post reflected on how new developers can have a tendency to avoid projects that use "uncool" tools. They want to be on the leading edge of technology. However, another aspect of using uncool tools is that they are old. RTEMS-based applications often have lifespans measured in decades from development, through fielding, to long term sustainment. This insight lead us to begin to review the tools we depended upon for long-term viability and that they continued to offer a high quality solution. The transition from CVS to git has been the most visible outcome of this effort.

But lurking within the RTEMS source tree was a dependency on a long dead tool - texi2www. RTEMS was the last user of this and had to include the source code in our own tree. This was exactly the type of situation Chris and I had realized could happen and it already had without us noticing. In November 2011, I posted to the GNU Texinfo Help Mailing list asking for advice on converting to the more modern texi2html program. Unfortunately, I learned that texi2html was considered deprecated and being re-implemented in Perl and the new implementation would be known as texi2any. This led to me converting us away from the stone cold dead texi2www to texi2html. With the recent release of texinfo 5.0, I began to ensure that our documentation would build with either texi2html 1,82 or texi2any from texinfo 5.0 and that the build infrastructure could detect which to use.

The goal of this post is to point out how we invoke tools, initialization file differences and the minor changes to our documentation required to support both tools. The other tools in the texinfo package such as makeinfo did require us to make changes to the source but did not change their invocation. I will detail the changes to our texinfo source files after showing the command line differences for the html converters.

The commands executed by our build infrastructure are generated by an autoconf based build infrastructure. This sometimes leads to longer than absolutely necessary command lines. I have made no attempt to shorten or clean these command lines up. These are for the RTEMS C User's Guide whose main texinfo file is c_user.texi.

The following is the invocation of texi2html 1.82:

 texi2html -D use-html --split node --node-files -o ./ --top-file index.html --init-file=../texi2html_init \  
   -I /home/joel/rtems-4.11-work/rtems//doc/user -I /home/joel/rtems-4.11-work/rtems//doc \  
   -I .. -I . --menu /home/joel/rtems-4.11-work/rtems//doc/user/c_user.texi \  
   /home/joel/rtems-4.11-work/rtems//doc/user/c_user.texi  

This is the corresponding invocation of texi2any from texinfo 5.0:

 texi2any --html -D use-html --split node -o ./ --init-file=../texi2any_init \  
   -I /home/joel/rtems-4.11-work/rtems//doc/user -I /home/joel/rtems-4.11-work/rtems//doc \  
   -I .. -I . /home/joel/rtems-4.11-work/rtems//doc/user/c_user.texi  

Notice that both command lines are quite similar. However, texi2html requires the --node-files argument to produce individual html file names which are based on the section or chapter name. By default, they will be named using a pattern line DOC_nnn.html.

The other thing to note is that they both accept initialization files. However, the format of the initialization files is very different between the two implementations. Texinfo supports hierarchically structured documents and allows the author to provide links to the next section, previous section, and the section that contains or is logically above the current one. The RTEMS Project has a tool which automatically constructs the node markups based on chapter, section, and subsection headings. Thus, the RTEMS documentation is fully hierarchically linked with no manual node definition required. The RTEMS documentation build system uses the initialization file to define a custom header, footer and to modify the navigation buttons.

This is the file texi2html_init generated by our build infrastructure:

 my $button_text = '<a href="../index.html">Library</a>';  
 push @SECTION_BUTTONS, \$button_text;  
 push @CHAPTER_BUTTONS, \$button_text;  
 push @MISC_BUTTONS, \$button_text;  
 push @TOP_BUTTONS, \$button_text;  
 $AFTER_BODY_OPEN =  
 '<A HREF="http://www.rtems.com" target="Text Frame">  
 <IMG align=right BORDER=0 SRC="../images/rtems_logo.jpg" ALT="RTEMS  
 Logo"> </A>  
 <H1>RTEMS 4.10.99.0 On-Line Library</H1>  
 ';  
 $PRE_BODY_CLOSE =  
 'Copyright &copy; 1988-2011  
 <A HREF="http://www.oarcorp.com" target="Text Frame">OAR Corporation</A>  
 ';  
 1;  

The initialization files reflects the internal implementation of the two programs and the format used by texi2any is different. We have an initialization file which accomplishes similar things in the generated HTML files but looks different. For example, the texi2html output has navigation icons while the texi2any output has textual links.

This is the file texi2any_init generated by our build infrastructure:

 set_from_init_file ('AFTER_BODY_OPEN',  
 '<A HREF="http://www.rtems.com" target="Text Frame">  
 <IMG align=right BORDER=0 SRC="../images/rtems_logo.jpg" ALT="RTEMS  
 Logo">  </A>  
 <H1>RTEMS 4.10.99.0 On-Line Library</H1>  
 ');  
 texinfo_register_handler('setup', \&add_button);  
 my $button_text = '<a href="../dir.html">Directory</a>';  
 sub add_button($)  
 {  
  my $self = shift;  
  foreach my $button_type ('SECTION_BUTTONS', 'CHAPTER_BUTTONS',   
               'MISC_BUTTONS', 'TOP_BUTTONS') {  
   my $buttons = $self->get_conf($button_type);  
   push @$buttons, \$button_text;  
  }  
  return 1;  
 }  

There were only a couple of issues encountered with our use of texinfo which required modifying the source.

• Missing @item in @itemize lists now results in warnings. 
• The order of menu definition, @top and its @node, and file @include statements in the top level texinfo files had to be reordered. Texinfo 5.0 is not as forgiving on this.

In addition, I spotted mistakes in our documentation when reviewing the various output forms. The entire range of patches can be viewed online here.

NOTE: As of 24 February 2013, these have not been committed. When they are committed, links will be provided to the git repository.

We would like to take advantage of features in the newer tools and are investigating using a print on demand service for RTEMS manuals. I hope there is experience in the texinfo community about this but, if not, I suppose I will pester the maintainers until the results are satisfactory and report on what I had to do.

Thanks to the Texinfo maintainers Patrice Dumas, Karl Berry, and Eli Zaretskii folyzr being incredibly patient and helpful through this process.