While doing research into the state of present day bionics technology I started thinking about the implied limits of the current technology. Just how far are we from the Matrix-like brain-in-a-jar philosophical thought exercise being a realistic possibility? From what I can make out, most of the technology, albeit crude and unwieldy in a lot of cases, appears to actually be available today.

Bionic limbs controlled by processed signals picked up from the brain and peripheral nerves have been around for a long time. While there are still issues with implanting sensors directly into the brain causing an inflammatory response in the tissue known as gliosis which causes electrodes to get insulated and prevents them from picking up the signal, the technology has been tested pretty successfully. If that can be done, then arguably the same technology could be used for all muscle control.

But what about other vital organs?

Heart: Permanent heart replacement devices have already been used.

Kidneys: Dialysis machines have been in use for decades, and although bulky they are capable of performing the function of kidneys indefinitely. Small, implantable devices are also becoming available.

Spleen: Considering that people who have had their spleens removed for various reasons (injury, cancer or other illness) live for decades without significant health consequences, spleen doesn’t appear to be a vital organ.

Liver: Since liver is one of the few vital organs that regenerates, most of the approaches to artificial replacements have been based on biotech and regenerative technologies. Still, it would appear that Extracorporeal Liver Assistance Devices (ELADs) do already exist.

Digestive system including pancreas: Intravenous provision of nutrients for coma patients appears to have been in use for a long time. Thus, in the context of what might be considered to be a full bionic chassis, the digestive system could be omitted and the appropriate nutrients introduced into the blood stream directly.

Lungs: Artificial lungs appear to be the most problematic part. The devices available today, both the bulky external ones and the more modern implantable ones all suffer from the same problem – blood clotting. The life expectancy on the large external devices is typically around a day, while the smaller implantable ones have been able to sustain animals in trials for around 5 days before they started to introduce blood clots into the blood stream that lead to problems like stroke.

In light of all that, it would appear that ghost-in-the-shell possibility is rapidly making a transition from science fiction to science fact. Sure – we aren’t quite there yet. But it is quite amazing just how close to plausibly implementable the very concept actually is today, at least from the point of view of a layman who only has limited information available.

If you are involved in this field of research and can confirm, deny, correct, extend or elucidate any of the above points, please, do post a comment.

RedSleeve Linux is a 3rd party ARM port of a Linux distribution of a Prominent North American Enterprise Linux Vendor (PNAELV). They object to being referred to by name in the context of clones and ports of their distribution, but if you are aware of CentOS and Scientific Linux, you can probably guess what RedSleeve is based on.

RedSleeve is different from CentOS and Scientific Linux in that it isn’t a mere clone of the upstream distribution it is based on – it is a port to a new platform, since the upstream distribution does not include a version for ARM.

The reason RedSleeve was created is because ARM is making inroads into mainstream computing, and although Fedora has supported ARM for a while, it is a bleeding edge distribution that puts the emphasis on keeping up with the latest developments, rather than long term support and stability. This was not an acceptable solution for the people behind this project, so we set out to instead port a distribution that puts more emphasis on long term stability and support.

What I came across is this: SuperTalent RC8 USB stick. It may look like a USB stick, but it is actually a full-on SSD, featuring a SandForce 1200 flash controller. I figured this was worth a shot, even though the specifications indicate it is rather large (far too large to fit inside an AC100 in it’s standard form). Stripped out of the casing, however, it looks like RC8 might just be fittable inside the Toshiba AC100.

This is what I ended up with. There appears to be only one place inside an AC100 where a bare RC8 circuit board could be fitted. You will need the following:

1) P3MU mini-PCIe USB break-out module

2) SuperTalent RC8 USB stick

3) Custom made USB cable (male and female type A USB connectors, some single core wire, and some skill with a soldering iron)

Measure out exactly how long you need the cable to be – there is no room to tuck away excess able inside an AC100. Here is what my cable layout ended up looking like.

AC100 motherboard with P3MU and custom USB cable fitted

This is what it looks like with the top panel fitted. Note the large cut-out that has been made below the mini-PCIe slot access hole.

AC100 modified to receive RC8 USB SSD

And again with the screws fitted. Note that one of the screw holes is in the area that had to be cut out. This shouldn’t affect the structural integrity of the AC100, though. Also note that the right speaker cable has been re-routed slightly to now go over the LED ribbon cable.

AC100 modified to receive RC8 SSD

This is what it looks like with the RC8 attached. Now you can see why the cut-out in the top panel was exactly the shape it was – I specifically cut out the minimum possible amount to allow the RC8 to fit.

Toshiba AC100 with the SuperTalent RC8 USB SSD installed

I also put a piece of thin transparent sticky tape over it to hold in in place, just to make sure nothing can short out against the underside of the keyboard.

Toshiba AC100 with the SuperTalent RC8 SSD

And that is pretty much it. Put the keyboard back in and bolt it all together. The metal part of the USB connector will sit a tiny bit above the line of the panel, but the only way you’ll notice it once you put the keyboard back on is by knowing that there is a tiny bulge there.

Your AC100 should now be able to handle ~ 2000 IOPS on both random reads and random writes, along with much better life expectancy that having proper flash management brings.

At this point I would like to point out just how impressed I am with the SuperTalent RC8 USB SSD. Not only is the performance fenomenal (especially for a USB stick), but it really behaves like a SATA SSD – to the point where you can use tools like hdparm and smartctl on it (yes, it even supports SMART).

Unfortunately, virtually all SD/microSD (referred to as uSD from now on), CF and USB flash modules have truly atrocious performance for use as normal disks (e.g. when running the OS from them on a small, low power or embedded device), regardless of what their advertised performance may be. The performance problem is specifically related to their appalling random-write performance, so this is the figure that you should be specifically paying attention to in the tables below.

As you will see, the sequential read and write performance of flash modules is generally quite good, as is random-read performance. But on their own these are largely irrelevant to overall performance you will observe when using the card to run the operating system from, if the random-write performance is below a certain level. And yes, your system will do several MB of writing to the disk just by booting up, before you even log in, so don’t think that it’s all about reads and that writes are irrelevant.

For comparison, a typical cheap laptop disk spinning at 5400rpm disk can typically achieve 90 IOPS on both random reads and random writes with typical (4KB) block size. This is an important figure to bear in mind purely to be able to see just how appalling the random write performance of most removable flash media is.

All media was primed with two passes of:

 dd if=/dev/urandom of=/dev/$device bs=1M oflag=direct

in order to simulate long term use and ensure that the performance figures reasonably accurately reflect what you might expect after the device has been in use for some time.

There are two sets of results:

1) Linear read/write test performed using:

dd if=/dev/$device of=/dev/null    iflag=direct
dd if=/dev/zero    of=/dev/$device oflag=direct

The linear read-write test script I use can be downloaded here.

2) Random read/write test performed using:

iozone -i 0 -i 2 -I -r 4K -s 512m -o -O +r +D -f /path/to/file

In all cases, the test size was 512MB. Partitions are aligned to 2MB boundaries. File system is ext4 with 4KB block size (-b 4096) and 16-block (64KB) stripe-width (-E stride=1,stripe-width=16), no journal (-O ^has_journal), and mounted without access time logging (-o noatime). The partition used for the tests starts at half of the card’s capacity, e.g. on a 16GB card, the test partition spans the space from 8GB up to the end. This is in done in order to nullify the effect of some cards having faster flash at the front of the card.

The data here is only the first modules I have tested and will be extensively updated as and when I test additional modules. Unfortunately, a single module can take over 24 hours to complete testing if their performance is poor (e.g. 1 IOPS) – and unfortunately, most of them are that bad, even those made by reputable manufacturers.

The dd linear test is probably more meaningful if you intend to use the flash card in a device that only ever performs large, sequential writes (e.g. a digital camera). For everything else, however, the dd figures are meaningless and you should instead be paying attention to the iozone results, particularly the random-write (r-w). Good random write performance also usually indicates a better flash controller, which means better wear leveling and better longevity of the card, so all other things being similar, the card with faster random-write performance is the one to get.

Due to WordPress being a little too rigid in it’s templates to allow for wide tables, you can see the SD / CF / USB benchmark data here. This table will be updated a lot so check back often.

What can be done about this? Well, models that have a 3G modem have it on a mini-PCIe USB card. Even though Tegra 2 has a PCIe controller built into it, the mini-PCIe slot isn’t fully wired up – only USB lines are connected. Since most of us can tether a data connection via our phones, and since this is more cost effective than paying for two separate mobile connections, the 3G module isn’t particularly vital. The main issue that the slot only has USB wired up. So what we would need is a USB mini-PCIe SSD. Is there such a thing? It turns out that there is. I have been able to find two:

1. EMPhase Mini PCIe USB S1 SSD
2. InnoDisk miniDOM-U SSD

The specification of the two modules is virtually identical (both use SLC flash among other similarities), so I decided to investigate both of them. Unfortunately, having contacted an EMPhase re-seller, they called me back having spoken to the manufacturer and talked me out of buying one, citing unspecified issues.

My local InnoDisk re-seller was more interested in selling me a product, but there were two reasons why despite very good pre-sales service I ultimately decided against buying one of these. The first and foremost was the performance specification. According to the manufacturer’s own figures, the random access performance with 4KB blocks is 1440 random read IOPS and 30 random write IOPS. Considering the price per GB of these modules is approximately 4x that of similarly performing SLC SD cards, this module was discarded on the basis of cost effectiveness.

Having discarded the above modules, there are still a few alternative options available. The low risk, tidy options include an SD mini-PCIe USB adapter and a micro-SD mini-PCIe USB adapter. They are very reasonably priced so I got one of each for testing, and I am pleased to say that they work absolutely fine in the AC100. Here is what they look like fitted.

Dual micro-SD mini-PCIe USB Adapter

SD mini-PCIe USB Adapter

The SD cards will appear as USB disks. If you use the dual micro-SD adapter you can RAID the two cards together.

Unfortunately, I have found that the best results are achieved using a single SD card, purely because I haven’t found any micro-SD cards that have reasonable performance when it comes to random-write IOPS. SD cards fare a little better, but the best SD card I have found in terms of random write IOPS still tops out at 133 random write IOPS using 4KB blocks. Still, it is over 4x of the marketed figures for the InnoDisk SSD at 4x lower price per GB, and the performance does scrape past what I would consider minimal requirements for pleasant use.

I am currently putting together a list of SD, micro SD and USB flash devices and consistent benchmark performance figures for them, which should hopefully help you to choose the ones most suitable for your application. I hope to have the article up reasonably soon, but don’t expect it too soon – benchmarking SD cards takes a long time to do properly.

So, other than increasing the physical amount of memory, can we actually do anything to improve the situation? Well, as a matter of fact, there are a few things.

Clawing Back Some Memory

By default, the GPU gets allocated a hefty 64MB of RAM out of 512MB that we have. This is quite a substantial fraction of our memory, and it would be nice to claw some of it back if we are not using it. I find the Nvidia’s Tegra binary accelerated driver to be too buggy to use under normal circumstances, so I use the basic unaccelerated frame buffer driver instead. There are two frame buffer allocations on the AC100: the internal display and the HDMI port. The latter is only intended for use with TVs which means we shouldn’t need a resulition of more than 1920×1080 on that port. The highest resolution display we can have on the internal port is 1280×720. That means that the maximum amount of memory used by those two frame buffers is 8100KB + 3600KB 11700KB. To be on the safe side, let’s call that 16MB. That still leaves us 48MB that we should be able to safely reclaim. We can do that by telling the kernel that there is extra memory at certain addresses using the following boot parameters:

mem=448M@0M mem=48M@464M

Make sure the accelerated binary Tegra driver is disabled in your xorg.conf, reboot and you should now have 496MB of usable RAM instead of 448MB. It’s just over an extra 10%, which should make a noticeable difference given how tight the memory is to begin with.

If you aren’t using the HDMI interface, my tests show that it is in fact possible to reduce the GPU memory to just 2MB with no ill effects, when using the 1280×720 display panel, because the frame buffer seems to operate in 16-bit mode by default:

mem=448M@0M mem=62M@450M

That leaves a total of 510MB of for applications.

Memory Compression

In the recent kernels, there are two modules that are very useful when we have plenty of CPU resources but very little memory – just the case on the AC100. They are zcache and zram. On the 3.0 kernels instead of zram we can use frontcache which is similar but has the advantage that it is aware and cooperates with zcache. Since at the time of writing this 3.0 isn’t quite as polished and stable for the AC100 as 2.6.38, let’s focus on zram instead.

Assuming you have compiled zcache support into your kernel, all you need to do to enable it is add the kernel boot paramter “zcache”. From there on, your caches should be compressed, thus increasing the amount they can store.

zram provides a virtual block device backed by RAM, but the contents are compressed, so it should always end up using less than the amount of memory it presents as a block device (unless all of the data is uncompressible, which is very unlikely). To err on the side of caution we shouldn’t set this to more than half of the total memory across all the zram devices. To ensure optimal performance, we should also set the number of zram devices to be the same as the number of CPUs cores in the system to make sure that all CPUs end up being used (each zram device handler is a single thread).

To set the number of zram devices to 2 (Tegra2 has 2 CPU cores), we need to create the file /etc/modprobe.d/zram.conf containing the following line:

options zram num_devices=2

Then once we load the zram module (modprobe zram), we should see device nodes called /dev/zram*. We can configure the devices:

echo <memory_size_in_bytes> > /sys/block/<zram_device>/disksize

The amount of memory assigned to each zram device should be such that their total combined size doesn’t exceed half of the total physical memory in the system.

Then we can create swap headers on those zram devices using mkswap (e.g. mkswap /dev/zram0) and enable swapping to them (swapon -p100 /dev/zram0).

We should now have some compressed RAM for swapping to instead of swapping to a slow SD card.

Tweaks

It turns out that some of the default settings on Linux distributions aren’t as sensible as they could be. By default the amount of stack space each thread is allocated is 8MB. This is unnecessarily large and results in more memory consumption than is necessary. Instead we can set the soft limit to 256KB using “ulimit -s 256″. Ideally we should make this happen automatically at startup by creating a file /etc/security/limits.d/90-stack.conf containing the following:

* soft stack 256

Some users have reported that this can increase the amount of available memory after booting by a a rather substantial amount. Since this is a soft limit, programs that require more stack space can still allocate it by asking for it.

Choice of Software

One of the most commonly used types of software nowdays is a web browser, and unfortunately, most web browsers have become unreasonably bloated in recent years. This is a problem when the amount of memory is as limited as in it is on most ARM machines. Firefox and to a somewhat lesser extent Chrome require a substantial amount of memory. However, there is another reasonably fully featured alternative that works on ARM – Midori. Midori is based on the Webkit rendering engine, the same one that is used by Chrome and Safari. However, it’s memory footprint is approximately half of the other browsers. Unfortunately, it’s JavaScript support isn’t quite as good as on Firefox and Chrome yet, but it is sufficiently good for most things, and if memory pressure is a serious issue, you might want to try it out.

Before I continue the usual disclaimer applies: if you are doing this – on your head be it. I am not responsible for what you do to your hardware and am making no promises that doing this will not damage it, destroy it, shorten it’s life, or cause you injury in some way. And it most definitely WILL void your warranty.

Software-only OC

This part you can achieve purely by modifying the kernel. It is assumed here that the kernel you are using is Marc Dietrich’s 2.6.38 ChromeOS kernel modified specifically for the AC100. You will need the following patches:

1) Toshiba AC100 Tegra2 Overclocking Patch, the common part – this only adds additional clock speeds and makes an increased range of voltages available. You will need to apply this regardless of whether you are aiming for a 1200MHz software-only overclock or a full overclock to 1404MHz which requires a hardware modification to improve the CPU core cooling. This patch doesn’t apply any overclocking on it’s own and shouldn’t break any existing functionality of the kernel if applied on it’s own.

2.1) AC100 1200MHz Patch – this only adds a 1200MHz mode on top of the standard 1000MHz mode. I tested this on 5 AC100s so far and have found no stability problems with the settings in the patch. Temperatures are only slightly higher than at 1000MHz and there is no need to open the AC100 to modify it.

2.2) AC100 1404MHz Patch – This adds additional overclock speeds: 1248MHz, 1352MHz, and 1404MHz. For this you WILL need to modify your AC100.

You can only apply one of the latter two patches – either the 1200MHz patch or the 1404MHz patch.

Both of these patches only apply to the two SKUs of Tegra2 found in the AC100:

Tegra Revision: A02 SKU: 8 CPU Process: 2 Core Process: 1 Speedo ID: 0; these are found in the models with Micron memory. These run at lower voltages (975mV@1000MHz).

Tegra Revision: A02 SKU: 8 CPU Process: 1 Core Process: 1 Speedo ID: 0; these are found in the models with Hynix memory. These seem to run at higher voltages (1100mV@1000MHz, but they also, bizzarely, often run cooler.

If your AC100 has a different SKU, please leave a comment with the details.

Hardware Modification to Improve Cooling

The modification is very simple. The standard cooling setup inside in AC100 is no good. It’s fine for the standard clock speeds, since the CPU will never get hot, but for anything significantly faster it desperately needs to be improved. The standard setup only has some thermal putty between the CPU core and the spring plate above it.

You will need:

1) Good thermal grease (I used Arctic Silver 5)

2) Good thermal epoxy (I used Arctic Silver Thermal Adhesive)

3) 2 copper shims, each measuring 25mm x 25mm x 1.2mm

Take a look at this excellent, detailed article on how to disassemble the bottom half of the AC100.

Once you get to the CPU, remove the thermal putty and VERY carefully clean up the top of the CPU core. I cannot stress enough the amount of care you have to take. There are tiny capacitors on top of the CPU package and if you damage any of them it will never work again.

Toshiba AC100 CPU Core

Then apply some thermal compound (not adhesive!) to the top of the CPU.

Tegra2 CPU Core in Toshiba AC100 with thermal compound applied

Look at the underside of the panel to which the spring plate is attached. Clean up the underside of the spring plate. Mix up enough thermal epoxy to do two copper shims. Use it to attach a copper shim to the the underside of the spring plate. I have found the position in the following photo to be optimal.

Toshiba AC100 CPU-side shim in place on the spring plate

Before the epoxy starts to set use it to glue the other copper shim to the top of the spring plate.

Keyboard side copper shim on the Toshiba AC100

Apply good pressure to the two copper shims and wait for the adhesive to set. It typically takes about 5 minutes from the point of mixing, so you have to work reasonably quickly.

Replace the top half of the AC100 casing, make sure all the clips have clicked into position, and apply reasonable pressure to the shim you can see to make sure that the stack is making good thermal contact with the CPU.

Apply a reasonably generous amount of thermal grease (not adhesive!) to the top of the copper shim. This will transfer heat to the underside of the keyboard. Re-attach the ribbon cables and clip the keyboard back into position. Apply a bit of pressure to the are on top of where the shim is to make sure the thermal compound makes good contact.

Re-fit the 5 screws on the bottom of the AC100, and the two screws at the back that hold the back of the keyboard in place.

Power back up and verify that the temperatures under load are now at least 10-20C lower. Apply patches 1) and 2.2), and verify the temperatures under load.

Overheat Protection Shutdown

AC100 has a thermal protection shutdown feature built in. If the CPU core hits 100C, the machine will power off and will not let you power it back on until the CPU temperature drops below 90C. If you find that you are getting over 90C under load, there is a 3rd, still somewhat experimental solution to this.

The idea is simple. We have a userspace daemon that checks the temperature once per second and if the temperature exceeds a certain configurable threshold (default is 90C), it will reduce the maximum clock speed to a configurable level (default is 1000MHz). Once the temperature drops below the threshold, the daemon will re-enable the configurable top speed (default is whatever the kernel says is the maximum available, in the case of patch 3 that is 1456MHz).

The concept of the throttling daemon is similar to Intel’s Turbo Boost technology in the Core i series of processors. When the thermal limits allow, it can boost the speed, as long as the CPU doesn’t overheat. It took me a while to come up with a name for this daemon, but seen as it is for an Nvidia chip, and considering that they used to write their name on the logo as nVIDIA, I called this daemon nITRO. You can download nITRO here.

In the ideal world, the thermal throttling could more cheaply be done in the kernel. The current version of nITRO is written in bash and typically consumes approximately 0.3% of CPU, whereas the kernel implementation would be almost free (assuming you consider 0.3% to be expensive). Unfortunately, the thermal throttling for Tegra in the current ChromeOS kernel is stubbed out at the moment.

If you experience a stability issue that you can verifiably and repeatably pin on the overclock, please post what you did to create the load that causes the stability problem and I will try to reproduce it and adjust the patches accordingly.

Remove the two rubber covers circled in the picture below, and remove the two screws underneath.

Toshiba AC100 Screen Bezel Screws

Gently pry the bezel apart using your fingernails or a plastic scraper. If you use something metal like a screwdriver, you are likely to leave unsightly gauge marks around the edges. The trick is to push the inner bezel inward to allow the clips to detach without breaking.

Prying the screen bezel of the Toshiba AC100 apart

Perhaps you may get a better of idea from this photo regarding which direction you should be gently bending the bezel in to pry it apart.

Prying apart the screen bezel on the Toshiba AC100

Eventually the bezel will open up and you will be able to get to the display panel.

Bezel on the Toshiba AC100 opened up

Gently bend the inner part of the bezel toward you and remove the four screws marked in the photo. Be careful – if your screw driver slips you are likely to damage the screen panel. Needless to say, this applies both while removing the old screen and fitting the new one.

Bend the bezel out of the way and remove the four screws holding the screen panel

Flip the screen toward you, and you will see the LVDS cable plugged into it. It is held on with tape, so you will first need to pry the tape off the screen. Be very careful when doing this – the connector is quite fragile.

Unplug the LVDS connector

When you have unglued the tape, unplug the LVDS connector and remove the screen.

Unplugged LVDS connector

Here is a picture of the removed screen. There are several variants of these panels, and the main thing to look for when getting a replacement panel is to make sure that the LVDS connector is in the same place (or as near as possible). Otherwise the cable won’t reach it.

Standard Toshiba AC100 display panel

The problem with the replacement 1280×720 panel (AU Optronics B101EW01) is that the mounting points are about 2mm narrower than the original panel. This isn’t strictly a problem, but if you don’t modify it, you will only be able to get two of the four screws back in, and the screen will be about 1mm off-center.

Screen mounts don't quite line up

To correct this, you will need to modify the mounts on the replacement panel by cutting the screw holes open on the outside. To be able to center the screen, you will have to modify all mounts.

Modifying the mounting points on the replacement screen panel

This is what it will look like when you are finished. Be careful – the bits of metal you will remove are tiny and will try to fly off in a random direction. You don’t want these flying off into something they can short out!

Modified screen panel mounts

Once you have completed this, the refitting is the reverse of removal. Plug in the LVDS connector, and re-apply the tape – there should be enough stickyness left in it to keep the connector in place. When putting the screws that hold the screen back in, make sure you center the screen – after all, that is why we modify the mounting brackets. Clip the bezel back shut (again, bending it gently toward the inside when pressing it back together will allow the clips to engage more easily. Replace the screws, and the rubber pads (they should still be sticky enough after one removal to remain in place – if they are not, you can use a tiny bit of double sided tape).

That is all you need to do from the hardware point of view, but if you leave it there, you will end up with a 1280×720 panel that only displays 1024×600 in the top left corner. If you look at the splash screen, you will get the idea – notice the white border at the bottom of the splash screen – that is the bottom edge of the 1024×600 area.

Truncated resolution

Unfortunately, the screen is initially configured by the boot loader, and since the specification and the source code for this are not open, it is not possible to change it. What we can change, however, is the kernel’s frame buffer driver to re-initialize the screen to the correct resolution. You can do this by applying this kernel patch.

Note: The screen will appear garbled between the splash screen and the point where the userspace re-initializes the display. This will typically happen when your rc.sysinit sets the display font, early during the boot process. Unfortunately, the driver currently doesn’t re-set the display panel as soon as the frame buffer is initialized.

That is pretty much it. I find that upgrading the screen makes a big difference in usability. As far as I am concerned, 1024×600 is completely useless. In comparison, 1280×720 is livable with.

Since Efika MX‘s major problems – the painfully low screen resolution (a problem it shares with the AC100) and the completely unusable touchpad – turned out to be easily fixable, the AC100 went on the shelf for a while. This was a shame since the AC100 had about three times the CPU power of the Efika MX (dual core Cortex A9 1GHz vs Efika’s single core Cortex A8 800MHz), but having a fully working, usable system was more important.

All that changed recently. ChromeOS 2.6.38.3 kernel brought with it more support for Tegra2 based devices, including the development board that the AC100 is based on, and shortly afterwards thanks to the awesome people in the AC100 community, a lot of things fell into place, including stable NVEC support (what keyboard/mouse/LEDs are connected to on the AC100) and sound support. But most importantly for me, the recent kernel also came with the kernel level display panel setup. No longer entirely at the mercy of what the boot loader configures, it became possible to use a higher resolution screen!

So, I carried out the upgrade to 1280×720 using the same TFT panel that I used to upgrade the Efika. All that was required was a small kernel patch. Without a change to the boot loader data the machine still starts up in 1024×600, and the kernel boot-up output is corrupted until the console font is re-set, but since setfont is called very early during the Fedora boot-up sequence, it is a problem that isn’t hard to live with. From there on, everything works absolutely fine in 1280×720. An article on the details of the upgrade procedure and the required kernel patch will follow shortly.

The nvidia binary driver works OK-ish – most of the time, but it isn’t particularly stable – every once in a while you will do something that causes the screen output to get partially corrupted. This is not related to the higher resolution, all the problems occur at 1024×600, too. Unfortunately, it doesn’t look like nvidia are showing that much interest in improving this quickly, and since their approachability and interest in helping their user community is as non-existent as ever, I wouldn’t expect driver improvements any time soon. Still, for normal use the standard unaccelerated frame buffer driver is rock solid, and the acceleration in the nvidia driver does work well enough if you want to play videos at full screen resolution, and there is even a Tegra accelerated version of flash available so YouTube works, too. All of this is a considerable improvement on the Efika MX.

Power management is also completely functional on the AC100 now, so it’s battery life is virtually identical to the Efika MX.

It is amazing how much difference 5 months can make. AC100 went from being the underdog to being an outright winner. It now matches the Efika on battery life and screen resolution, and soundly beats it by a large margin on the touchpad (the touchpad on the AC100 is actually extremely good), performance and features (no YouTube without Flash).

Best of all, it is no more expensive than the Efika MX. Here in UK – new ones can be had for as little as £170, which is less than you’ll pay for an Efika with a non-US keyboard.

In fact, the price/performance in terms of CPU power is actually better on the AC100 than it is on the SheevaPlug, and that’s before the added convenience of also having a screen/keyboard attached for troubleshooting. Because of this, AC100s are now used for extending my ARM compile farm.

I did, however, manage to procure some DL-DVI adapters that saved the day. They come with their own EDID modes programmed in, and they don’t report 3840×2400 modes, only 1920×2400@48Hz. So the AA doesn’t go into full tiled resolution mode and thus, you can see both halves of the monitor detect separately and the tiled 3840×2400@48Hz mode becomes available. The end result is quite awesome and worth the cost and the effort. Not only is this monitor fantastic for coding work (I like having lots of terminals open), but the monitor is in fact fully gaming capable (assuming you have a powerful enough card to drive it). As you can see, Crysis looks pretty amazing on it.

Crysis at 3840x2400

If you are getting one of these monitors, make sure you get the DL-DVI adapters to go with it, unless you are using a G9x series Nvidia card.