Tag Archives: linux

AirMobi iReceiver Preliminary Software Hacking

Posted on by
4

I recently discovered and purchased an inexpensive, unofficial WiFi-enabled AirPlay and DNLA audio receiver called the AirMobi iReceiver. I couldn’t find much information on the device, but for $12, I thought it was worth buying and trying.

It works reasonably well, but that’s not really why I bought it. I bought it with the intention of taking it apart and seeing what makes it tick. And now, having done that, I plan to hack it to run OpenWRT so I can secure it, customize it, and update the software.

IMG_9667

It is based on a Ralink RT5305T WiFi SoC which suggests to me that it is running linux, and probably has a serial console exposed via some test points on the mother board. I only found handful of candidates during my teardown. My guess was that the Tx and Rx lines were available on the unpopulated 4-pin header at the edge of the circuit board. From visual inspection I could tell that the second pin from the left was a ground pin. A little continuity probing with a multimeter suggested the first pin provided power, a fact confirmed when I check its voltage when I powered up the device.

I hooked a logic analyzer up to the other two pins to see which one toggled on and off at boot, but that was really overkill. I could have done just as well figuring out which one was pulled high when I powered up the device.

Once I had the pins worked out, I hooked up a TTL level USB/serial converter to my laptop, connected the ground pins and cross connected the Tx and Rx pins between the adapter and the board. Once I powered everything up, my screen started to fill with garbage. I guessed that 115.2Kbps was too fast, and tried 57.6Kbps instead. Bingo!

After booting up, I hit return and was presented with a login prompt. I tried the password for the webui and was pleased to find that it worked. I poked around the filesystem, looking at various config files, the various files for the web UI, and checking what binaries were installed on the system.

One of them is a telnet daemon (implemented as part of busybox). So, I started it, connected to the WiFi, and was able to log in over the network.

From there, I gathered more information. I was dissapointed that there wasn’t really anything like zip, or tar, or an ftp or ssh server that would make it easy to pull a bunch of files off at once, so I dumped the web UI files to the terminal one at a time and then saved them for further inspection.

Hidden ate_test.asp page

Hidden test_ate.asp page

Once I did, I found hidden functions in the firmware update page for uploading the bootloader over the webui. Exposing it required tweaking the page using web developer tools, which is kind of tedious. Then I hit the jackpot, I found an unlinked file called test_ate.asp. When loaded, it has a button to fire up the telnet daemon, making a command line available with just a WiFI connection, no serial console necessary. It also has an option to update the boot loader and a mysterious ATE function. This discovery made it easier to return and poke at the device at my leisure.

From what I learned in my poking and prodding, it appears to be based on the Ralink provided SDK with some modifications. With any luck, the modifications will be minor, and it will be easy to load an OpenWRT firmware over the webUI.

Before I do that though, I’ll need to take special care since this device doesn’t have an ethernet port, and so recovering from non-working firmware will be more difficult.

A lot of details follow…

Continue reading →

AirMobi iReceiver Teardown

Posted on by
1

I’ve ended up with five small, inexpensive ($7-15 each) routers, running OpenWrt and only really need two of them, so I’ve been thinking of ways to use the others. One of my ideas was to get an external USB DAC, install Shairport-Sync, and use it as an AirPlay receiver for my car stereo, eliminating the need to connect an audio cable to my phone, and avoiding the mediocre sound quality of Bluetooth audio. It hasn’t quite worked out that way though…

While looking for an inexpensive (>$20), compact USB DAC with reasonable quality, I discovered there were integrated commercial products that already do what I planned to do. I already knew there were Apple-approved MFi-certified devices, but they tended to be expensive. I discovered there were cheaper devices using Shairport, but they tended to start at $30+.

Damaged while trying to open the case.

Damaged while trying to open the case.

With a little more digging though, I found a device called the iReceiver, from AirMobi that sells for as little as $12!!!. According to the scant marketing materials, it has a 24-bit Wolfson DAC. I was surprised I couldn’t find anyone who’d opened one up to see what was inside. I did find an Amazon review from someone complaining that the usb power connector had broken off on theirs, and the included photo showed it had a Ralink RT5350F WiFi SoC, which gave me hope that it would be hackable. So, I bought one.

Before opening it up, I tried it out. It works as promised. It defaults to broadcasting an unsecured WiFi network. Once connected, it shows up as an AirPlay receiver in iTunes, etc. From there, you can connect it to some powered speakers, select it and start playing music. The audio quality doesn’t suck (no obvious noise, clipping, or distortion), and in my limited use, there were fewer dropouts that I’m used to with Bluetooth.

Beyond that, there are various configuration options available through a browser based interface. There are no audio-related settings at all. Most of the settings are networking related. You can rename and secure the WiFi network with a password (good), WPS (bad) and by limited connections to specific devices by MAC address (meh). You can also connect to an existing network (good), and, optionally, extend it (meh). This seems like a good point to mention that it also works as a DNLA “renderer” (DNLA is a more open standard than AirPlay, making this useful to Windows and Linux devices, and Android phones with an appropriate app)

Of course, I didn’t buy it to use it with the stock firmware, so after trying it out, I opened it up to take a look inside. In the process, I managed to tear the translucent plastic that was affixed to the top of the case with adhesive. With the trim removed, it was easy to pry off the top, revealing the single PCB inside.

Version 2

As I expected, it is based on the obsolete but inexpensive and popular Ralink RT5350F WiFi SoC which includes a CPU and 802.11n WiFi.

  • Marked “RT5350F, TP08P40609, 1408STA”
  • 360MHz MIPS 24KEc CPU
  • 802.11n 1T/1R (1×1:1) 2.4 GHz 150Mbps MAC/BB/PA/RF
  • 5-port 10/100 Mbps Ethernet switch w/ 5 10/100 PHYs (unused)
  • USB 2.0 host/client (unused)

This is complimented by a modest, but sufficient 32MB of RAM and 8MB of flash memory to hold the firmware.

  • RAM
    • Marked: “EtronTech EM63A165TS-6G”
    • 255Mbit 16Mx16 5, 6, 7ns 166MHz SDRAM
  • Flash
    • Marked: “MXIC MX, 25L6406E, M2I-12G, 30392500, K141983”
    • Macronix MX25L6406E
    • 64Mbit NOR Flash
    • 4KB sector, 64KB block, 2.7-3.6v, H/W Hold
    • 1 or 2 bit bus, 86MHz x1 bus, 80MHz x2

The other major component is a Wolfson WM8960 CODEC to provide the audio output. This chip debuted in 2006, and includes 24-bit stereo DAC and ADC converters supporting sample rates up to 48Khz, a 40mW headphone driver, and a 1W Class D speaker driver.

Despite being a 24-bit DAC, the specified SnR of 98dBS matches that of the 16-bit TI/Burr Brown PCM2705 DAC used in the original AirportExpress, rather than of a modern, premium 24-bit DAC used in more recent AirportExpress’s. Oh well. Good enough for my purposes. Most of what I’m playing is compressed AAC files derived from 16-bit sources, and, AirPlay only passes 16-bit anyway. Beyond that, the design of the rest of the circuitry matters, and I’m not qualified to analyze it, nor am I equipped or inclined to try and measure it.

Beyond that, I see two inductors on the board (one of which is cracked). My guess is that these are part of some small switch mode power supplies, perhaps one for the digital section, and the other for the analog. There are two small LEDs to indicate device status and two momentary switches, one to reset the device, and the other to trigger WPS. It looks like it uses a single ceramic chip antenna for the WiFi.

There are a few unused pads for components, eight test points (half seemingly to do with power) and four unused holes for pin headers that I suspect provide a serial console.

That’s really it for the hardware. I’ve already started poking more deeply into the software and investigating the suspected serial console, and I hope to have another post soon documenting what I found.

IMG_9679

iReceiver Elsewhere

ASRock AM1B-ITX + AMD Kabini Sempron 3850 Linux Notes

Posted on by
4

Earlier this summer I built a new home server using an ASRock AM1B-ITX motherboard and a AMD Kabini Sempron 3850 CPU.

To make a long story short, this motherboard doesn’t work well for my intended use as a headless Linux server. The problems are manifold and interconnected:

  • If I boot headless, it decides the integrated GPU isn’t being used.
  • Once it decides the integrated GPU isn’t being used, it tries to use a PCI Express GPU, which it doesn’t find.
  • At some point, it also reactivates compatibility mode.
  • With compatibility mode activated it is, ironically, incompatible with my combination of hardware.
  • The combination of all of the above means that it won’t boot headless.

 

These issues weren’t immediately obvious. The storage issues showed up early on, once I added the extra drives, but others took longer to show their face because, while I’ve been using it for its intended purpose for a couple of weeks now, I only just finally got around to moving it off the corner of my desk and into its final position on a shelf in a closet. I assumed this move would be relatively uneventful. It wasn’t, it was frustrating and tedious.

By way of context, I thought I’d give a few more details on my installation.

The system drive is a 256gb Crucial MX100 SSD. The root volume is relatively small, like 8GB or so. There is a small swap partition, an EFI partition, a good chunk of unused space  as a lazy sort of SSD over-provisioning for longer life, but the bulk of the drive is set aside as for SSD caching of various volumes using Bcache. The root volume is un-exotic though, straight ext4. I’d intially set the system up to boot using legacy BIOS, but after some backflips, managed to convert it to use gpt partitions, and UEFI booting.

The SSD is connected to the main SATA3 controller on the Kabini SoC, as is a 3TB Western Digital Red drive. There are two other motherboard SATA3 ports provided by an ASMedia chip. These are attatched to  3TB and 1TB WD Green drives. None of this is very exotic.

The CPU/Motherboard has integrated video, which I had attached over DVI to an external monitor. The machine is intended to run headless, but I want to run some OpenCL stuff on the GPU, so I had to install video card drivers. By default, the system installed the open source radeon driver, but, from what I could tell, this doesn’t yet have OpenCL support, so I switched to the proprietary binary flgrx driver.

With that background out of the way, I’ll detail the many annoyances I’ve had with this system.

First off, I found that it would often boot slowly, or hang all together, and this tended to involve drives connected to the ASMedia SATA controller. Sometimes it would hang or take forever to detect connected drives. Other times, it would hang on the main BIOS screen, while lighting an activity light on one of those drives. After some trial and error, I figured out it worked much better if I disabled “Compatibility Support Mode” (CSM) in the boot section of the BIOS setup.

The next problem came when I shut the machine down, detached it, and moved the machine to its final location. When I rebooted it, it emitted 5 sharp beeps and then didn’t seem to do much of anything else, except light up the activity light on one of the drives connected to the ASMedia controller. I tried leaving it for a while, to see if it proceeded to boot, but finally gave up and tried resetting it. That didn’t work either, no beeps this time, but it still seemed to hang with the drive light activated. I moved it back to the desk, hooked up the monitor and tried to figure out what had gone wrong.

I found that the BIOS seemed to have reverted back to compatibility mode, moreover, the primary GPU was listed as being PCI Express, rather than integrated. A little digging and I learned that the 5 beeps meant “without vga card.” I mucked around a bit more, trying different things, before reaching the conclusion that this board has major problems, at least for my application.

I’m not sure what I’m going to do next. I realize it might be worth disabling the boot recovery mode, because that may be part of the reason it is falling back to a problematic BIOS configuration. My guess is that I may still have trouble with the internal video, but I might be able to address that with an explicit kernel option (assuming that the boot process still continues). Another option is to see if I can hook something to one of video ports that tricks it into thinking a monitor is connected.

Ubuntu Linux on the Rockchip RK3066 SoC

Posted on by
Reply

Those interested in running Linux on a cheap Chinese “MiniPC” with an ARM SoC have had much reason for hope, and just as much reason for disappointment.

The hope springs from the low cost and rapid pace of development of these devices. Earlier this year, the state of the art were devices based on the Allwinner A10 SoC, which had a single ARM Cortex-A8 Core and a dual-core Mali400 GPU, which went for ~$100, now there are products well under $100 with single- or dual-core Cortex-A9 CPUs and a up to a quad core GPU.

The disappointment comes from the fact that these SoCs are targeted at Android, with terrible documentation, and that most of the manufacturers are terrible about complying with the GPL. Add to this the fact that important parts of the chip, like the GPU and the video compression accelerator are under NDA from the original holders of the IP.

Still, there is reason for continued hope. Over on the SlateDroid forums, “AndrewDB” has posted about his progress with getting Ubuntu running on the UG802, which has a RK3066 SoC.

Current status, to the best of my knowledge:

  • Boots with Linux Kernel in Flash and RootFS on an SD card.
  • Framebuffer video out over HDMI
  • WiFi networking
What’s more, Andrew Kirby from Rikomagic, which sells a device based on this chip has been providing recent Kernel source. In addition, there is a working binary-blob based Linux driver for the video processing unit on an earlier Rockchip SoC that may be easily ported to this one.
Update: It looks like the most of the action is actually in the ARM TV tech forum.

via CNX-Software