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.