XPS13 (9343) Ubuntu Linux

I broke my pre-Haswell XPS13 and had to quickly buy a replacement. Without much thought, I decided to get the new Broadwell XPS13. It was not until after I had made the purchase did I find out that there are a whole lot of complaints about the compatibility of this laptop with Linux.

Let me just say that I have full faith in Dell’s Project Sputnik and I’m sure that the team will get things ironed out soon enough.

However, I have to say that my Linux experience on this laptop is pretty good, far better than what I’ve read online. So, I thought that I’d document a few things of note here.

Bios Update
First thing I did when I obtained the new Broadwell XPS13 was to update the BIOS to A01. The way to do this is simple enough. Download the update from the DELL website and save it onto a USB drive. Then, start up the computer and hit F12 to access the boot menu. The BIOS can be updated from the boot menu itself, without having to boot into Windows/DOS.

Linux Install
Next, I opted to install the latest Ubuntu LTS (14.04.2) that went without a hitch. Even UEFI worked out of the box. Again, what I had to do was to download the ISO image from Ubuntu, flash it into a USB drive and reboot the computer while pressing F12 during boot up to get the boot menu.

Broadcom 4352 Wifi
The wireless AC wifi card that comes with the new XPS13 requires the proprietary Broadcom drivers to work. The good thing is that the bcmwl-kernel-source drivers are available in the Ubuntu repository. The command to install this is to run:

apt-get -y install bcmwl-kernel-source

Needless to say, this can only be done after installation by temporarily using a WiFi dongle since there is no wired ethernet port on this laptop. I used my old trusty TL-WN725N which uses the standard rlt8192cu driver in the kernel. After that, the wifi card worked like a charm.

Broadcom 216F BT
The built in Bluetooth module also requires a little tweaking. While the drivers are available in the kernel, the required firmware wasn’t. This required a little workaround to get the firmware from the Windows drivers. However, I had already wiped out Windows from my laptop. Good thing then that the drivers are available from Microsoft themselves.

The downloaded file is a CAB file that needs to be extracted. Then, the appropriate HEX firmware needs to be located and converted to a HCD file using the HEX2HCD tool.

# cabextract 20662520_6c535fbfa9dca0d07ab069e8918896086e2af0a7.cab
# hex2hcd BCM20702A1_001.002.014.1443.1572.hex /lib/firmware/brcm/BCM20702A0-0a5c-216f.hcd

That’s it. Bluetooth worked like a charm.

Touchpad
There are reports of problems with the built-in touchpad freezing and keyboard experiencing stuck keys. This can be fixed according to the official DELL blog by adding some kernel parameters.

psmouse.resetafter=0

Audio
The last thing to get working is the analogue audio but since I pipe most of my audio through HDMI, I have not really bothered with this one. But it turns out that the kernel parameters worked.

acpi_osi=!Windows\ 2013

Garmin GPS Update in Linux

I own a Garmin GPS that I wanted to update. It’s about a year old and the maps are not up-to-date. For example, it does not include the new second Penang bridge. Garmin provides updated maps on its website but the installer runs in Windows. Since I did not have a Windows machine available, I had to find another way.

Turns out that Microsoft gives away time-limited virtual machine images of Windows, primarily for browser testing. So, I downloaded the smallest one – IE6 on WinXP. After that, it had to be extracted from the archive. This can be done by:


$ chmod +x IE6.WinXP.For.LinuxVirtualBox.sfx
$ ./IE6.WinXP.For.LinuxVirtualBox.sfx

Next, the extracted OVA file needs to be imported into VirtualBox and run.

Screenshot - 13092014 - 12:23:52

After that, it’s just a matter of using the browser to download the update from Garmin and running the map.

Note: We just need to make sure that the Garmin is configured as a USB storage device and that it is attached to the virtual machine, instead of the host machine.

OpenWRT DIR615

I have a wonky DIR615-G2 that came standard with my UniFi subscription. It would randomly reboot and even fail to boot from time to time. Even trying to re-flash the firmware using the Emergency mode is iffy.

So, I figured out a way to at least get it to boot OpenWRT in a clean way. Essentially, I had to flash it with a DD-WRT image because the stock OpenWRT image does not work. Then, the standard method is to upgrade it to OpenWRT. However, that fails too.

So, I had to work out my own way, which does not require SSH running.

Essentially:

  1. Boot the router into emergency mode.
  2. Flash it with the stock DD-WRT firmware.
  3. Reboot the device.
  4. Telnet to the router.
    telnet 192.168.1.1
  5. Transfer the OpenWRT upgrade image using netcat
    nc -l -p 1234 > /tmp/dir620.bin
  6. Erase the nvram
    erase nvram
  7. Erase the flash
    mtd erase linux
  8. Flash the upgrade
    mtd -r write /tmp/dir620.bin linux
  9. Reboot the device.

ddwrtopenwrtdir615

8-bit Linux Machine

I respect the amount of dedication and genius that went into this effort. While nothing new, it’s totally CRAZY.

This project takes the Church-Turing thesis to an extreme. In essense, it states that “everything algorithmically computable is computable by a Turing machine.”

Some may wonder how he managed to get it all to work. So, let’s break it down a little:

CPU
According to the thesis, any CPU is able to emulate the operations of another CPU. So, while the AVR is an 8-bit micro, it can definitely be used to emulate all the complex functions available on the more powerful ARMv5 in software.

As an example, if I needed to do a 32-bit addition, all I would need to do is to do four 8-bit additions factoring in the Carry bits. So, depending on whether the 8-bit architecture supported a Add with Carry instruction, I might need to do an additional three 8-bit additions for a total of seven additions. In the end, I’d still end up with a 32-bit addition.

For many 8-bit microprocessors, there are already existing libraries to do such things because it is a fairly common requirement as 8-bit microprocessors find use in all sorts of unexpected applications where they might need to do 32-bit calculations anyway.

Take this analogy further, you can also do floating-point calculations emulated in software on a pure integer machine. This is done all the time, even on full fledged ARM architectures. In actual fact, all you’d need to build any computer in this world is a 1-bit computer.

RAM
This is where the 16KB RAM in the 8-bit micro has serious deficiencies. Linux would typically need several megabytes of RAM. Therefore, the project included an external 16MB of RAM. While some may argue that we still need more than 16MB of RAM, it isn’t exactly true. The internal 16KB would be used to emulate more of a cache than primary memory.

In a modern computer, memory is just a hierarchy of storage devices. RAM is just a convenient method of doing it. If there isn’t enough RAM, we can always emulate the RAM as well, using virtual memory, which is what most desktop PCs used to do in the past by exploiting some of the hard disk.

From all indications, this project had a 1GB SD card attached to it for storage needs. This included the Linux OS plus file-system. So, it could boot off this SD card and also use part of it as a swap if necessary. Swapping can both be done in the OS or even emulated by the 8-bit micro.

However, the speed of the device would be another limiting factor. Most 8-bit micro communicate with SD cards using the SPI protocol at a maximum clock of 25MHz. This means that it has a theoretical maximum transfer rate of only 3MB per second – about the speed of a 20x CD-ROM drive.

If I were adventurous, I might even emulate a CD-ROM drive. This way, I could run a Live-CD Linux distribution on one partition, while using another partition to emulate a mass storage device such as a hard-disk drive. That might prove interesting as well.

I/O
This is where I think that he had to emulate a lot more stuff. While 8-bit micros may be low on brain power, they are typically full of all sorts of I/O devices. However, the project would need to emulate a whole bunch of things to get Linux started.

I gather from the video that the standard inputs and outputs are routed through the serial port of the AVR. This can typically be done in Linux by simply specifying a kernel parameter console=/dev/ttyS0. Then, the emulator would need to emulate the necessary calls to read from and write to the console.

If he wanted to emulate the mouse and keyboard, it would also be very possible as the PS/2 protocols used have been emulated in 8-bit micros for a while. There are some devices that use 8-bit micros as pretend keyboards and mice e.g. a key-logger or a password dongle.

If he wanted to emulate a video card, it is also possible as 8-bit micros have been used to generate full frame video in emulation, largely by using PWM signals to emulate the analogue signals of a VGA connection. While it will be severely speed limited, it should be able to do at least a low-level VGA frame buffer.

He could even go as far as adding in ethernet if he so wished. Some 8-bit micros these days have built in ethernet MACs. However, adding USB host capability might be a bit tricky as most 8-bit micros do not have USB OTG capabilities as yet.

So, there we have it. A quick and dirty run-down of it.

UM3100 Linux Modem

The Aztech UM3100 USB modem is the easiest USB modem that I’ve gotten to work with Linux. It worked amazingly straight out of the box with Ubuntu 10.04 LTS. I am going to try it with Debian Squeeze this weekend but I’m assuming that it’ll work just as well too.


Nov 3 21:35:24 1810TZ kernel: [15232.924056] usb 4-2: new full speed USB device using uhci_hcd and address 3
Nov 3 21:35:27 1810TZ kernel: [15235.530776] usb 4-2: configuration #1 chosen from 2 choices
Nov 3 21:35:27 1810TZ kernel: [15235.533700] cdc_acm 4-2:1.0: ttyACM0: USB ACM device

I tried making a call and receiving a call from the modem using AT commands and they work. So, I’m guessing that it’ll work okay for fax operations, which is the reason why I bought the modem to begin with.

I’m going to set up hylafax at the office this weekend because, for some reason, everyone still expects you to have a fax machine in this day and age. I plan to just hook the modem to my print server and set it up as a soft fax – receiving faxes as email and sending faxes as a print job.

Hope it all works.

ARM Macs?

There has been some rumours that Apple might switch their notebooks to ARM processors away from Intel ones. Does it make sense to me?

While I have a lot of respect for the ARM processor, it is not yet as powerful as the Intel ones. It can probably give the low-end Intel machines like the Atoms, a run for its money, it does not have the necessary processing power to compete against the higher end Intel parts.

That said, there are product niches where the ARM might make better sense than Intel parts. Apple is already very familiar with ARM processors used in their A4/A5 processor for the iPhones and iPads. However, there is the issue of compatibility.

I will say that if there is anyone who can make an architectural shift painless for the user, it has to be Apple, who managed to maintain backwards compatibility from 68K to PowerPC and Intel. They can definitely do it for ARM too, if they want to.

Except that performance will likely take a hit unless they have some spiffy ARM chips coming up in the A6/A7.

Personally, I hope that they do pull it off because it would just further integrate the Apple hardware. With its own ARM based microprocessors, Apple would be able to do things that they wouldn’t, with Intel processors. For example, they can build in DRM into their microprocessors.

I think that Apple definitely wants to go there. They have always loved doing their own hardware. By switching to ARM, this gives them the opportunity to tightly integrate both software and hardware, making projects like OSX86 obsolete.

From a technical stand-point, it can definitely be done. While the ARM processors are slower than Intel parts, the bottleneck in most computing systems today is I/O and a super high-end Intel processor is no use if coupled with a slow harddisk. A combined SSD-ARM system might actually be pretty speedy for most intents and purposes.

All we need is a decently fast processor, speedy flash storage, high speed RAM. That will create a faster over-all computing experience even if it may be slower for specific computationally intensive applications.

I hope that Apple actually does it. Let’s call it the MacBook Hand or the HandBook (get it?). 😀

Magic.