1. More Thunderbolt / PCIe adapter info

    Some additional information continuing from my past post on the TH05.

    Thunderbolt's implementation on Apple firmware does a few odd things that need to be worked around by Windows 7 and Linux. If your OS doesn't advertise itself as Darwin, the ACPI tables will not wake the controller unless a device is plugged in at boot. Exactly how the controller is woken up is still unknown, so waking it after boot isn't completely possible under Linux and I'm unaware of any Windows support (though it may exist with Windows laptops shipping Thunderbolt finally). Matthew Garrett has done the investation of how to replicate what happens when the OS is detected as Darwin during EFI loading, what's missing is later configuration of the controller once the OS has booted.

    The practical implication of this is you have to boot with a device attached, or you won't get a usable PCIe link once Windows or Linux has booted. Reconnecting a device doesn't work either. For an eGPU on Apple hardware you are restricted to devices that do not interfere with the EFI loader or BIOS emulation, which at least for my 2012 MacBook Air means almost everything I've tried doesn't work in BIOS mode. An AMD GPU (Radeon 5750) didn't crash the BIOS, but it didn't allocate memory under Linux successfully. Another AMD GPU (Radeon 5830) hangs it. Every Nvidia GPU I tried hangs the BIOS (9800 GT, GTS 450, GTX 550 Ti). All of these load fine in EFI mode, though I've only extensively tried the GTX 550 Ti.

    I'd like to try some other PCIe devices with less demanding memory requirements. Much like the laptops with crashing BIOS implementations using the PE4L, memory demands are probably why all these GPUs hang Apple's fragile BIOS emulation.


  2. eGPU Setup util with Grub and Linux

    Just a quick note on how to use the DIY eGPU Setup 1.x tool from Harmonic Inversion with a Linux system.

    Download the tool and place your image file (something like eGPU-Setup-110b5.img) in /boot. Then create a file, /etc/grub.d/50_eGPU, and put this Grub entry in it.

    menuentry "eGPU Setup" {
      linux16 /usr/lib/syslinux/memdisk
      initrd16 /boot/eGPU-Setup-110b5.img

    Make sure you have syslinux installed (apt-get install syslinux on Debian or Ubuntu). You may need to correct the path or copy the memdisk binary from /usr/lib to /boot if your /boot and /usr/lib do not share a mount point.

    From there, you can select the eGPU menu item in Grub. Set things up as normal for eGPU. Then select Chainload MBR and you can boot back into Linux with the DIY eGPU Setup 1.x changes active.


  3. Bplus TH05 Thunderbolt to PCIe adapter

    I like really small computers and I dislike having a seperate desktop for running games or other graphics intense software. My choice of an 11" MacBook Air 5,1 is a little odd for a gaming machine, but it satisfies the small requirement. But I had great success with a PE4L v2.1b and my old Vaio Z, so promise of the same setup but without the lag caused by ExpressCard's bandwidth issues drew me to the MBA.

    PE4L eGPU

    Bplus just started shipping engineering samples of the TH05 adapter last month. I've had mine for a few weeks. Physical setup is very easy, I used a GeForce 550 Ti and ordered the version that included a Thunderbolt cable from Bplus.

    TH05 eGPU

    Initially it didn't work at all. The Vaio Z never worked perfectly with the PE4L, many laptops are not designed to have their PCI layout change. This results in the BIOS failing to load in the worst case, or commonly a booting system where one or more of the GPUs fail to allocate resources. In Linux, you can sometimes get the dead GPU to live by echoing values into enable/remove/reset/rescan depending on what's not working in /sys/devices/pci//.

    On the Vaio, I had all these problems. The BIOS would crash unless you plugged the GPU in at Grub's screen. I could get the GPU closer to initializing by disabling the internal Nvidia GPU and init'ing the external GeForce 550 Ti, but it still didn't work. What did work, was using a shim called DIY eGPU Setup. This could load before Linux and do the equivalent of forcing the BIOS to use a 36-bit PCI address space, loading both Nvidia GPUs at the same time.

    With the TH05 and the MacBook Air, it would just instantly crash after the grey EFI screen disappeared. The solution was much simpler than the Vaio. Ubuntu by default installs using the BIOS module provided for Bootcamp. Plugging in the card after booting does sort of work in BIOS mode on the MacBook Air (the Thunderbolt PCI tree appears in Linux but doesn't function entirely). Booting in EFI mode however, works perfectly. The only trick besides that is adding a BusID to xorg.conf.

    Section "Device"
        Identifier "Device0"
        Driver     "nvidia"
        BusID      "8:0:0"

    With that, the eGPU works perfectly with the 2012 MacBook Air. Performance is much closer to using the 550 Ti in a 16x slot on a comparable desktop than it was with the Vaio. There's no lag like the PE4L setup had in some games. Stability is very good, I've tested a number of games native and with Wine and run into no issues specific to the eGPU setup.

    For Windows and OS X support, I suspect it's possible. I'm not very familiar with either but OS X does boot and see the GPU (sort of, some of the utilities stop working with it installed). There's probably driver configuration issues to work through there. I didn't test Windows 7, but EFI mode should be possible.


  4. AMLogic-M3 Smart TV Box Investigations

    I sold my aging HTPC being tired of lugging the ATX beast between apartments whenever I moved. Figured I would replace it with an ARM computer, being the cheapest available hardware decoding. First attempt was the MK802 out of sheer frugality. Not having investigated it very thoroughly, it turned out to be nearly useless because of a proprietary hardware decoding interface and otherwise unreplacable and terrible software.

    Attempt two for ARM is this thing from OvalElephant. It's actually made by Refee and is very similar to the Pivos Xios, two USB ports are not wired up and it has 1GB of memory instead of 512MB. AMLogic themselves is considerably better at the whole GPL thing, the decoder is supported by open source libraries and they have almost reasonable source available for their kernels. It's still a mess of custom device subtrees with little integration with the rest of the kernel, but at least it compiles and seems to work on the hardware targeted by the particular release. Few ARM platforms can say that.

    That kernel is for Meson6 dual core version of the chipset, so I've attempted to get it building for the Meson 3 SoC in the Oval Elephant box. There are some older kernels floating around and the device ships with 2.6.34 installed (UART dump of the default boot). From the log, it's obvious the hardware is using u-boot and it mentions reading a file called 'aml_autoscript'. This is just a u-boot script, but you have to use mkimage to create it.

    mkimage -A arm -O linux -T script -C none -d your_script.sh aml_autoscript

    The u-boot image on this hardware will load that from the root directory of a vfat formatted SD card. mkimage is from either your distro's uboot-tools package or the Meson6 kernel tree. Example script I've used:

    fatload mmc 0 82000000 uImage_linux
    setenv bootargs root=/dev/block/cardblksd2 rootfstype=ext3 androidboot.resolution=720p rootwait init=/bin/busybox console=ttyS0,115200n8 nohlt logo=osd1,0x84100000,loaded,720p a9_clk=600M clk81=187000000 mem=1024m mac=00:26:ea:99:3c:83
    bootm 82000000

    This doesn't enirely work. I've tried a number of root fs options, but it seems to ignore that option and simply load the Android image on the NAND flash with the stock kernel. Changing some of the options will result in failed boot of Android, so they do seem to be seen by the running kernel. I've tried Pivos Xios kernels and my own builds of the M6 tree hoping to get a pure Linux image loading but without any success. Pivos' kernels give a CRC error and crash if I repack them with mkimage. My kernels offer no output at all. The kernel from the SD card is loaded however, so it should be possible to modify the compiled image or build from whatever source tree that one is from.

    This is where I'm stuck. The hardware does do an okay job stock, but really I'd like to run XBMC without Android on it. Unless a new kernel tree pops up, I'd have to say that the Pivos Xios is a much better choice, especially if you want to hack the device at all. Even the Raspberry Pi offers a slightly better XBMC experience. There are several very annoying bugs in the stock firmware (Android buttons don't go away with videos and some of the up to date Android apps crash due to some malformed configurations), easily fixable with root access but I haven't been able to get that either.


« Page 2 / 2