Older blog entries for mjg59 (starting at number 286)

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.

BlApple.

[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

More Android source code

Telechips also appear to have released the source for their TCC89XX devices, which ought to provide at least some level of support for the Augen devices.

(I promise that I will talk about things that aren't GPL-related in the near future)

Syndicated 2010-12-28 14:28:44 from Matthew Garrett

Viewsonic GPL update

Viewsonic provided a patch to Nvidia's reference Tegra code to support their gtablet today. Which is progress! They still don't have anything for their (entirely unrelated) Viewpad Android devices, and there's no source for the userspace components, but there does seem to be a reasonable desire to do the right thing and I'm sure everything else will be sorted out soon. This still puts them ahead of Augen, who have now been violating since July and seem to be entirely at the mercy of their OEM vendor who'll sell them devices but won't give them source. Top tip: Don't buy Linux devices from companies who won't give you source code and then resell them, it tends to leave you open to all kinds of legal misery and then your children get poorly carved lumps of wood for Christmas. Don't make your children think that you're an inept parent. Pay attention to licensing obligations.

Syndicated 2010-12-24 22:24:59 from Matthew Garrett

Dear internet

How do I disable dynamic contrast control on a Viewsonic VA2226w?

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

Viewsonic gtab update

I had a nice conversation with the people at Tap N Tap (who produce the firmware image used on the Viewsonic gtab tablets) today, so with luck we'll see some progress on that front in the near future.

Syndicated 2010-12-10 22:00:53 from Matthew Garrett

Nook Color GPL update

Barnes and Noble posted the source code to the Nook Color here, which is a much faster turnaround than last time so some sort of progress has definitely been made. The appropriate config file for the kernel appears to be omap3621_evt1a and a cursory check implies that this is the source that corresponds to the binaries.

Syndicated 2010-12-03 15:56:00 from Matthew Garrett

Viewsonic and the GPL

Somebody linked me to this reddit story about the fact that Viewsonic appear to be engaging in the currently fashionable trend of shipping Android devices without providing any source. This one's more interesting though, in that Viewsonic appear to be entirely happy to publicly state that they have no intention of following their license obligations. I've pulled the kernel image for the device and confirmed that it contains code that's not present in the generic Android Tegra tree, so I don't think they have a leg to stand on here.

So of the companies I'm currently complaining about (Fusion Garage, Barnes and Noble, Viewsonic): One is in Singapore and two are based in the US. Chinese companies may be the current easy target when it comes to complaining about GPL violations, but the truth is that companies in countries with stronger IP enforcement are also either blissfully ignorant or feel that the risk of failing to follow their license obligations is low. This isn't a sustainable position. We've got three real choices here - do nothing, start lawsuits or start educating companies. The third is probably the most productive in the long run, though I wouldn't absolutely rule out the second if we don't get anywhere. I'm currently exploring the education possibilities. We'll see what happens next.

Syndicated 2010-11-24 05:59:36 from Matthew Garrett

277 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!