Log in

No account? Create an account
Matthew Garrett's Journal
[Most Recent Entries] [Calendar View] [Friends]

Below are 20 journal entries, after skipping by the 20 most recent ones recorded in Matthew Garrett's LiveJournal:

[ << Previous 20 -- Next 20 >> ]
Monday, February 7th, 2011
3:34 pm
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.
Saturday, January 22nd, 2011
12:39 am
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.
Tuesday, January 18th, 2011
2:43 pm
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.
Friday, January 14th, 2011
10:13 pm
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.
9:52 pm
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.
Thursday, January 13th, 2011
6:57 pm
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.
Thursday, December 30th, 2010
2:44 pm
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)
Tuesday, December 28th, 2010
9:28 am
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)
Friday, December 24th, 2010
5:24 pm
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.
Monday, December 20th, 2010
2:44 pm
Dear internet
How do I disable dynamic contrast control on a Viewsonic VA2226w?
Friday, December 10th, 2010
5:00 pm
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.
Friday, December 3rd, 2010
10:55 am
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.
Wednesday, November 24th, 2010
12:59 am
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.
Tuesday, November 23rd, 2010
5:47 pm
Barnes and Noble response
"We are working on consolidating and will be distributing the open sourcecode in the coming weeks."

So, Barnes and Noble's release process doesn't include them ensuring that they have the source code that they're legally obliged to be able to provide to customers - even after they'd screwed this up once before. Their negligence leaves them open to potential litigation[1], so if you're a shareholder you probably ought to be asking questions about their corporate responsibility.

[1] No, I don't plan to sue them
Monday, November 22nd, 2010
1:09 pm
Fusion Garage GPL update
Fusion Garage have put up a website containing the source code for the kernel, bootloader and some miscellaneous tools (including their recovery system). As far as I can tell (by inspection - I haven't tried building binaries) it corresponds to what they were distributing, which is excellent. On the other hand, that's all the source they've provided. The pkgs.tgz binary they're providing is the binary packages shipped with the Joojoo, missing their source code. Many of these appear to simply be Ubuntu packages with the gpg signatures stripped, which is a GPL violation though not a terribly interesting one (GPLv2 only allows you to point at someone else's repositories if (a) you're not distributing commercially, (b) they gave you a written offer for the source code and (c) you pass on that written offer - however the source is out there, so it's not something I'm personally terribly upset about). In some other cases, there do seem to be genuine differences. udev, for instance, has a bunch of customisation. And finally there are packages that don't appear in Ubuntu at all, but which do contain GPLed or LGPLed material (such as webkit).

So, the take-home message is that even when given 6 months to provide source code, Fusion Garage are unable to adhere to the licenses of software they distribute. Don't give them any of your money, since unless they magically get significantly better it'll probably end up being spent on defending lawsuits.
Thursday, November 18th, 2010
5:32 pm
About this time last year, I spent a while talking about how Barnes and Noble were failing in their GPL obligations. It took them about two months to release some source code that didn't actually correspond to the hardware - they finally provided it in March, more than three months after shipping the device.

The Nook Color is now shipping. Guess what Barnes and Noble aren't providing yet?

The flood of generic Chinese Android devices with no source code makes it very easy to think that GPL adherence is something that's only problematic with devices sourced from countries with poor records in IP enforcement. In reality, it's a problem everywhere. Barnes and Noble are a US company and the contractors for the Nook were based in Canada. They're aware enough to include the GPL notice in their documentation, but not concerned enough to make sure that they actually posses the source code that they're legally obliged to provide.

I'm glad to see that the Linux Foundation are providing resources to ensure compliance, but it's likely that this is going to continue being a problem until we start engaging in more visible efforts to educate companies about their legal obligations. The idea that a company like Barnes and Noble would ship copies of Windows without paying the appropriate license fees is pretty implausible, but they seem perfectly happy to engage in for-profit copyright violation if nobody's going to chase them down. It'll be interesting to see if this trend continues, or if we start making a sincere effort to remind vendors of their obligations.

In other GPL violation news - Fusion Garage have promised me that they'll provide the source code to their GPLed components on Monday. Given that the device has been end of lifed this is obviously pretty inept. Investors should realise that they're putting money into a company that has knowingly been engaging in criminal behaviour for over 6 months. We'll see how they manage compliance for their Android devices.
Monday, November 15th, 2010
10:03 am
More hurrah
Somewhat anti-climatically (given that I originally submitted at the end of 2007), my corrected thesis has resulted in my being approved for my PhD. I'll probably get around to actually graduating around easter.
Monday, November 8th, 2010
9:39 am
Less hurrah
I would tell you about the phone call I had with a company where the CEO acknowledged that they were behaving in criminal activity in multiple jurisdictions but promised that they'd probably stop in a few weeks and so I shouldn't worry, but it seems that in the modern Internet I'm not allowed to because there were no independent witnesses and I haven't called the police, and also if I wanted people to respect my copyright I shouldn't have put my software on the internet where I'm just begging for it to be taken advantage of. Also, in future I won't be fixing any bugs unless they happen to me because you might just be making them up make my code look bad, and also you shouldn't accept any patches from me because I might by lying about things just to inflate my patch count and make myself look better at the expense of competing companies.

9:36 am
I got married to a wonderful woman this weekend and in an hour or so I'm going away for a week. The last couple of weeks have been pretty busy so sorry if I've dropped any patches on the floor, but I'll catch up once I'm back.
Wednesday, October 27th, 2010
7:07 pm
Other things
  • Running 24fps films at 23.976fps allows them to be converted to NTSC with a minimum of misery
  • Hulu's streams, despite film and NTSC both seeming to be pretty irrelevant, seem to be at 23.976fps
  • If mencoder is asked to remux one of these streams into another flv stream, it'll set the fps to 24
  • A 42 minute episode will end up about 3 seconds out of A/V sync due to this difference
Yes, of course this took far too long to work out.
[ << Previous 20 -- Next 20 >> ]
My Website   About LiveJournal.com