Older blog entries for mjg59 (starting at number 292)

Archos tablets

Has anyone tried to obtain the kernel source for the Archos 7 home tablet V2 or the Arnova range (ie, anything Archos is shipping that's based on the RK2818 rather than the RK2808)? If so, what was the response? The source from their site only appears to be for the RK2808 devices.

Syndicated 2011-03-20 14:25:14 from Matthew Garrett

Further adventures in mobile Linux

I picked up a couple of cheap Linux devices at the weekend. First of all, a $99 Android tablet from CVS, made by Craig. It's a generic RK2818 device and of course it's lacking any kind of GPL offer in the documentation. As far as I know the only company that's released any Rockchip source so far has been Archos, and even then they haven't released the tools you need to actually build an image - they seem to be floating around the internet anyway. But it's straightforward to get it to run the Android market, and it runs Shortyz quite well, so fit for purpose from my point of view. I am, obviously, attempting to contact Craig to find out how they're going to satisfy their obligations but haven't got past their bizarre text-to-speech based support menu system that dumps you to answerphone after 5 minutes of being on hold. Next attempt will involve pressing more buttons.

The other one was a Sharper Image Literati e-reader, $49 from Macy's (on clearance, obviously). This one's interesting by virtue of not being an Android device. Instead it's got a fairly recognisable Busybox-based Linux environment that's even got udev and dbus running. It brings up a framebuffer and just dumps a QTE-based reader (from Kobo) onto it. Other than being woefully underpowered and slow, it actually seems very competent. There seem to be several versions of the hardware - the one I got has an ARM SoC from SiRF on it. SiRF make GPS chipsets, and it turns out that their Atlas 5 platform is actually intended for Linux-based GPS units. The embedded world always seems to find a way. What surprised me more is that it's probably the most polished looking Linux I've bought for under $300. No bizarre kernel spew. echo mem >/sys/power/state works. Standard backlight interface.

Oh, and no source. Obviously. But an interesting device regardless.

Syndicated 2011-02-28 23:46:21 from Matthew Garrett

LCA 2011

I'm both back from LCA 2011 and also over the associated brutal jetlag, so if you sent me mail and I still haven't replied then it's fallen down some sort of cliff and you should probably shout at me until I do something about it. LCA was, as usual, excellent. Especially given that the original venue was the same distance above the river as the now somewhat misleadingly described dry dock on the opposite bank.

I did a bunch of talks this year, and they're now all online, so without further ado:

Enterprise power management - a discussion of power management with a focus on enterprise users, given at the plumbers miniconf. LWN did a writeup here, and every time I say "Tera" you should pretend that I'm saying "Giga". I have no good excuse.

Linux license compliance - about the poor observance of the GPL's conditions by vendors, given at the business miniconf. A useful example presented itself in the form of a GPL-violating Android tablet that I bought in literally the first store I went into in Australia this year. Probably also the last appearance of my Knuth t-shirt, because it appears to have several holes in places where it shouldn't.

Making laptops work in Linux - talking about identifying how laptop-specific functionality is wired up, with an emphasis on reverse-engineering ACPI methods to figure out how to make things work. This one was my presentation at the main conference.

The organisers and volunteers deserve incredible gratitude for the way the conference was managed, especially considering that the CBD was underwater a week and a half earlier.

Syndicated 2011-02-09 19:50:21 from Matthew Garrett

Hardware vexation

My laptop (an HP 2530p) gets quite a lot of abuse. It's been with me enough to have done the equivalent of going round the world 4 or 5 times, and it's typically just thrown in a bag without any particular care or attention being given to its care or wellbeing. It's been dropped a couple of times with the only damage being some corners that aren't really as even as they should be. All in all, it's survived amazingly well. But it recently started refusing to boot, merely flashing its LEDs. After finally finding a list of what these mean, I narrowed it down to the memory. Taking it apart and putting it back together again got things working for a while, but then it happened again. And again. So, since I have one memory module and two slots, I decided to just move the RAM in the hope that there's something physically wrong with the slot. It worked! Until I got to the BIOS splash and it informed me that Intel AMT requires that there be memory in slot 0. And didn't give me an opportunity to continue without AMT.

My hardware is conspiring against me.

Syndicated 2011-02-07 20:34:21 from Matthew Garrett

Open embedded GPUs

Luke: It's great to see open code for the 6410, but I'm pretty sure that that chip uses Samsung's own GPU design rather than being anything PowerVR based. What makes you think it's an SGX? The listing here implies that it's an unrelated part.

Syndicated 2011-01-22 05:39:34 from Matthew Garrett

LCA 2011 has moved

I haven't seen this widely publicised yet, so just to help make sure people know: Linux Conf AU 2011 is going ahead in Brisbane next week, but due to the flooding it's been moved to the QUT Kelvin Grove campus about 4KM north of the original venue. There are good bus links between it and the CBD. More details here.

Syndicated 2011-01-18 19:43:46 from Matthew Garrett

In other news

I'm thrilled to discover that GNU-Darwin, which carried the bold claim that "GNU-Darwin aims to be the most free software distribution", distributes copies of the XNU source code with Apple's additional license rider of "The rights granted to you under the License may not be used to create, or enable the creation or redistribution of, unlawful or unlicensed copies of an Apple operating system, or to circumvent, violate, or enable the circumvention or violation of, any terms of an Apple operating system software license agreement", which certainly sounds like a restriction of use to me.

Free software's awfully like sausages - wonderfully tasty, but sometimes you suddenly discover that you've been eating sheep nostrils for the past 15 years of your life. The typical direction is realising that you've build your entire business model on something that you're actually legally obliged to give to your customers and now they're actually trying to assert their rights, but sometimes people make assumptions about freedom that don't hold. Apple last released a free version of their kernel source in 2006. Everything since then has been encumbered by additional use restrictions.

Still, much better than Microsoft - huge portions of the OS source code are available for anyone to download, examine, modify and rebuild. Apple's to be commended for dropping so much code to the community despite it having bought them almost nothing in return. But if anyone from Apple's reading, I'd love to fix up the thermal handling on your hardware under Linux. I suspect we're doing something horrible to your machines, but I don't really know what yet.

Syndicated 2011-01-15 03:13:34 from Matthew Garrett

Joojoo, once more

Having complained about the GPL compliance of the Fusion Garage Joojoo tablet in the past, I'm thrilled to say that I spoke to their new CTO earlier in the week and they now have full source availability here[1]. Previous engineering practices involved editing binary Debian packages rather than rebuilding from the Debian source packages, so there may be a small number of cases where it's awkward to rebuild an identical binary, but I think it's pretty clear at this point that they've done everything practical to make up for past mistakes. I've been assured that all further product development will take license compliance into account from the start, so while things may have taken a little longer than I'd have liked I think everything has worked out for the best. I'd like to say thanks to Fusion Garage and Megan Alpers at McGrath Power for their help in getting all of this resolved.

[1] I've taken a brief look at their new downloadable tarballs. If anyone does find anything missing, let me know and I'll be sure to pass it onto the right people.

Syndicated 2011-01-15 02:52:04 from Matthew Garrett

EFI implementation bugs

I'm working on improving various bits of Apple hardware support, which includes trying to make EFI booting on Macs more sensible. One of my test machines is an 11" Macbook Air, which is a beautiful piece of hardware. If you want something small and light that's approximately a proper computer rather than a netbook, there's nothing else in the x86 market to touch it. Nothing.

So it's a shame that while Apple employs hardware designers who are absolutely the best in their field, their firmware developers are utterly incompetent. The EFI spec describes a protocol called GOP (Graphics Output Protocol) which allows the operating system to find out things like the screen resolution, framebuffer location and stride. This machine kindly passes everything back correctly, except for stride being wrong. Like, utterly wrong. Implausibly wrong. Obviously, terrifyingly wrong. So wrong that if you trust it, your screen image looks like it's been involved in some sort of awful pasta making accident. But never mind, that's a single line workaround.

But there's far, far worse. EFI has three modes of operation - boot services, runtime services, and runtime services with a virtual memory map. Boot services are, as the name implies, intended to be used by the bootloader. They're contained within memory marked with a type of either BOOT_SERVICES_CODE or BOOT_SERVICES_DATA. Once the bootloader has loaded the OS, just before handing over to it, it calls ExitBootServices() and the firmware is then at liberty to clear those areas of memory. The OS never executes boot services code and can use the memory that was allocated to them.

So then we have runtime services. EFI is, depending on how you want to look at it, either saner or much less sane than traditional BIOS access. The firmware gives you a bunch of function pointers and you then simply call them with native calling convention (this, incidentally, is why it's pretty much impossible to run a 32-bit OS on 64-bit EFI, or a 64-bit OS on a 64-bit system that happens to have 32-bit EFI). To begin with the firmware assumes flat physical mapping, which isn't entirely ideal when you're an OS with virtual address space - so there's a SetVirtualAddressMap() call which lets the OS pass a memory map to the firmware, and from then on everything just works.

Except on this machine. On this machine, you call SetVirtualAddressMap() and the kernel faults because it's just tried to execute code from a region of address space that's marked as non-executable. Closer examination revealed that, yes, this area of address space is marked as RAM and so the kernel's doing the right thing. Except, obviously, the right thing generally doesn't involve crashing the machine at boot time, so there was something else up.

That something else turned out to be SetVirtualAddressMap() calling into boot services code. The boot services code that's not supposed to be touched after ExitBootServices() has been called. The boot services code that's flagged as BOOT_SERVICES_CODE and was therefore mapped as RAM by us because, well, nothing's there any more. The boot services code that we're ignoring exactly as the spec says we should.

So, a quick change to the bootloader to pass us an e820 map[1] that marks the boot services regions as reserved, a quick change to the kernel to mark BOOT_SERVICES_CODE regions as executable and we're in business. Except that when we call SetVariable() to configure the bootloader, the firmware tries to read from an address that's approximately 54TB above anything else.


[1] Oh, yes, despite E820 being an x86 BIOS-specific thing, we use it for the in-kernel representation of the address map under EFI as well. So despite the EFI memory map being available to the kernel, the bootloader has to construct something that looks like an E820 map, losing information in the process. So even though it's been given the E820 map, the kernel has to look through the EFI memory map in order to find the EFI runtime services section in order to mark it executable. This is, arguably, insane, but so is the entirety of EFI so that's ok then.

Syndicated 2011-01-13 23:57:43 from Matthew Garrett

Android tablet GPL summary

It's after Christmas, and the stores are full of Android tablets ranging in quality from mediocre to competent. Obviously, they're also ranging in terms of GPL compliance from "utter failure" to "pretty good". I've written a summary page here so you have:

  • Some idea of whether you're funding the theft of sweets from innocent children
  • Some idea of whether there's any realistic chance of you getting further updates once the vendor has decided that last year's devices are, well, last year
  • Some idea of just how bad the situation is
The vast majority of Android tablets I've been able to find are shipping without any source being made available, and that includes devices from well-known vendors. It's pretty much a given from the ones you've never heard of.

It's probably also worth noting that many of the devices in this list are probably rebadged versions of identical hardware, and that in some cases the same model may in fact refer to wildly different devices. There's a few cases where I've ended up with model numbers without any idea who the vendor is. If anyone has any corrections or updates, please feel free to let me know.

(Side note: People sometimes ask why Google aren't doing more to prevent infringing devices. For the vast majority of these cases, Google's sole contribution has been to put Android source code on a public website. Red Hat own more of the infringing code than Google do. There's no real reason why Google should be the ones taking the lead role here, and there's fairly sound business reasons why it's not in their interest to do so)

Syndicated 2010-12-30 19:44:20 from Matthew Garrett

283 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!