Bug#242866: updated tg3.c patch
The most recent tg3.c patch posted here (by Herbert Xu on Tue, 11 May
2004) does not apply cleanly to linux-2.6.17. No surprise, a lot has
changed in the last two years. I applied it by hand (it wasn't hard),
and I can verify that the result (freshened patch attached) compiles
without error. I can also set up tg3 files for the firmware-nonfree
package, and supply kernel images for i386 and/or amd64. Testers?
- Larry
--- linux-2.6-2.6.17/drivers/net/tg3.c 2006-06-17 18:49:35.0 -0700
+++ linux-17-hack/drivers/net/tg3.c 2006-08-17 20:23:34.0 -0700
@@ -5,6 +5,7 @@
* Copyright (C) 2001, 2002, 2003 Jeff Garzik ([EMAIL PROTECTED])
* Copyright (C) 2004 Sun Microsystems Inc.
* Copyright (C) 2005 Broadcom Corporation.
+ * Portions copyright 2004 Nathanael Nerode <[EMAIL PROTECTED]>
*
* Firmware is:
* Derived from proprietary unpublished source code,
@@ -40,6 +41,8 @@
#include
#include
+#include
+
#include
#include
@@ -4813,130 +4816,6 @@
return 0;
}
-#define TG3_FW_RELEASE_MAJOR 0x0
-#define TG3_FW_RELASE_MINOR0x0
-#define TG3_FW_RELEASE_FIX 0x0
-#define TG3_FW_START_ADDR 0x0800
-#define TG3_FW_TEXT_ADDR 0x0800
-#define TG3_FW_TEXT_LEN0x9c0
-#define TG3_FW_RODATA_ADDR 0x080009c0
-#define TG3_FW_RODATA_LEN 0x60
-#define TG3_FW_DATA_ADDR 0x08000a40
-#define TG3_FW_DATA_LEN0x20
-#define TG3_FW_SBSS_ADDR 0x08000a60
-#define TG3_FW_SBSS_LEN0xc
-#define TG3_FW_BSS_ADDR0x08000a70
-#define TG3_FW_BSS_LEN 0x10
-
-static u32 tg3FwText[(TG3_FW_TEXT_LEN / sizeof(u32)) + 1] = {
- 0x, 0x1003, 0x, 0x000d, 0x000d, 0x3c1d0800,
- 0x37bd3ffc, 0x03a0f021, 0x3c100800, 0x2610, 0x0e18, 0x,
- 0x000d, 0x3c1d0800, 0x37bd3ffc, 0x03a0f021, 0x3c100800, 0x26100034,
- 0x0e00021c, 0x, 0x000d, 0x, 0x, 0x,
- 0x27bdffe0, 0x3c1cc000, 0xafbf0018, 0xaf80680c, 0x0e4c, 0x241b2105,
- 0x9785, 0x97870002, 0x9782002c, 0x9783002e, 0x3c040800, 0x248409c0,
- 0xafa00014, 0x00021400, 0x00621825, 0x00052c00, 0xafa30010, 0x8f860010,
- 0x00e52825, 0x0e60, 0x24070102, 0x3c02ac00, 0x34420100, 0x3c03ac01,
- 0x34630100, 0xaf820490, 0x3c02, 0xaf820494, 0xaf830498, 0xaf82049c,
- 0x24020001, 0xaf825ce0, 0x0e3f, 0xaf825d00, 0x0e000140, 0x,
- 0x8fbf0018, 0x03e8, 0x27bd0020, 0x2402, 0xaf825404, 0x8f835400,
- 0x34630400, 0xaf835400, 0xaf825404, 0x3c020800, 0x24420034, 0xaf82541c,
- 0x03e8, 0xaf805400, 0x, 0x, 0x3c020800, 0x34423000,
- 0x3c030800, 0x34633000, 0x3c040800, 0x348437ff, 0x3c010800, 0xac220a64,
- 0x24020040, 0x3c010800, 0xac220a68, 0x3c010800, 0xac200a60, 0xac60,
- 0x24630004, 0x0083102b, 0x5040fffd, 0xac60, 0x03e8, 0x,
- 0x00804821, 0x8faa0010, 0x3c020800, 0x8c420a60, 0x3c040800, 0x8c840a68,
- 0x8fab0014, 0x24430001, 0x0044102b, 0x3c010800, 0xac230a60, 0x1443,
- 0x4021, 0x3c010800, 0xac200a60, 0x3c020800, 0x8c420a60, 0x3c030800,
- 0x8c630a64, 0x9124, 0x00021140, 0x00431021, 0x00481021, 0x25080001,
- 0xa044, 0x29020008, 0x1440fff4, 0x25290001, 0x3c020800, 0x8c420a60,
- 0x3c030800, 0x8c630a64, 0x8f84680c, 0x00021140, 0x00431021, 0xac440008,
- 0xac45000c, 0xac460010, 0xac470014, 0xac4a0018, 0x03e8, 0xac4b001c,
- 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
- 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
- 0, 0, 0, 0, 0, 0,
- 0x0208, 0x, 0x0a0001e3, 0x3c0a0001, 0x0a0001e3, 0x3c0a0002,
- 0x0a0001e3, 0x, 0x0a0001e3, 0x, 0x0a0001e3, 0x,
- 0x0a0001e3, 0x, 0x0a0001e3, 0x, 0x0a0001e3, 0x,
- 0x0a0001e3, 0x, 0x0a0001e3, 0x, 0x0a0001e3, 0x,
- 0x0a0001e3, 0x3c0a0007, 0x0a0001e3, 0x3c0a0008, 0x0a0001e3, 0x3c0a0009,
- 0x0a0001e3, 0x, 0x0a0001e3, 0x, 0x0a0001e3, 0x3c0a000b,
- 0x0a0001e3, 0x3c0a000c, 0x0a0001e3, 0x3c0a000d, 0x0a0001e3, 0x,
- 0x0a0001e3, 0x, 0x0a0001e3, 0x3c0a000e, 0x0a0001e3, 0x,
- 0x0a0001e3, 0x, 0x0a0001e3, 0x, 0x0a0001e3, 0x,
- 0x0a0001e3, 0x, 0x0a0001e3, 0x, 0x0a0001e3, 0x,
- 0x0a0001e3, 0x, 0x0a0001e3, 0x3c0a0013, 0x0a0001e3, 0x3c0a0014,
- 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
- 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
- 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
- 0x27bdffe0, 0x1821, 0x1021, 0xafbf0018, 0xafb10014, 0xafb00010,
- 0x3c010800, 0x00220821, 0xac200a70, 0x3c010800, 0x00220821, 0xac200a74,
- 0x3c010800, 0x00220821, 0xac200a78, 0x2463
Re: linux-2.6: includes nondistributable and non-free binary firmware
On Thu, Aug 17, 2006 at 10:06:44PM +0200, maximilian attems wrote: > enough time is lost with any of those dfsg firmware wankers, > that do _zero_ work upstream or on the licensing front. I repeat my offer to patch any (well, almost any) of these drivers to use request_firmware(). I need a volunteer who has the affected hardware and is willing to test my changes. It would also be nice if debian kernel developers expressed interest in incorporating such work (if any) for etch. One alternative sven mentioned is to move these drivers to non-free. I don't see any existing framework for such package(s), but that would indeed involve less coding and debugging. I am concerned about etch, and the pipeline from upstream to Debian is long enough that I think it's too late to work upstream. At least 12 of the 59 files are probably licensed "free enough" for upstream, so upstream will have limited interest in those cases. > the drivers are free not-*** non-free. I agree the drivers are free. That's why I hope we can eventually separate them from the non-free firmware they include. - Larry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: linux-2.6: includes nondistributable and non-free binary firmware
Kyle - On Thu, Aug 17, 2006 at 02:41:52PM -0400, Kyle McMartin wrote: > No wonder you're so *** enthusiastic about removing support for > hardware. You don't own any of it. How *** convenient. Can I deduce from this that _you_ own some of the affected hardware? If I patch in request_firmware() support for that driver, would you be willing to test it? > Since we seem to be pissing all over the spirit of the Social Contract > in the name of some holy quest for the unattainable goal of cooperative > vendors, Fully cooperative vendors would be nice, but I agree in most cases that's unattainable. Until that miraculous day arrives, the firmware that they supply needs to be removed from the free Linux kernel, have its license checked, and put into the firmware-nonfree package set up for that purpose. If you disagree with that process, say so. > Now, I don't think you understand what "preferred form of modification" is. Trust me, as someone who has written and maintained firmware, I know what the "preferred form of modification" is. > In all likelihood, the engineer who wrote, for example, the QLogic driver, > never even touched the firmware, never once questioned it, another engineer > simply gave him an array to copy to the card. The engineer who wrote the > driver didn't know, or care, about what should have just been on an EEPROM, > all he cared about was properly writing a Linux driver to talk to the > hardware. You're probably right, since the Linux driver was probably written after the Windows driver. In a small company there is usually good communication and shared debugging sessions between the firmware author(s) and their first "client", that is, the author of the first driver. > This is the difference between a piece of firmware, and an actual > binary blob that something calls into. I'm sorry if I used the word "blob" for something unusual. Binary blobs that get linked to by the kernel and executed are not firmware, and from a practical perspective are worse. Linus doesn't let those into the kernel, and taints kernels if they are loaded as modules. Legally, library blobs (executed by the Linux processor) and firmware blobs (executed by outboard controllers) are not all that different. > Now, don't you have something better to do than hurt our users? I can think of a few snide replies to this. Can we instead please keep emotion out of this discussion? Can we agree that etch must have a DFSG-free Linux kernel, and we need to work together to make that kernel work as well as possible for as many users as possible? > PS: I feel it again worth mentioning, that even if there were no firmware > in the driver, you would just get the exact same data if you pulled the > EEPROM and stuck it in a reader. The origin of our problem is that manufacturers have taken to saving themselves a little money by leaving the EEPROM off their boards, and putting the firmware on the MS-Windows[TM] driver CD instead. While they are presumably happy to let Linux users use that same firmware, the legal and practical mechanism to have that happen is (in the cases I flagged) broken. If you take an EEPROM and stick it in a reader, you (the owner of the hardware) probably have fair use rights to put it on a disk and boot your hardware from it. Since that firmware is copyrighted, and you don't own the copyright, you do not have the right to post it to the web or submit it to the mainline Linux kernel tree. - Larry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
linux-2.6: includes nondistributable and non-free binary firmware
Maks - On Thu, Aug 17, 2006 at 06:05:30PM +0200, maximilian attems wrote: > > Something about [bug #242866] seems broken, however, > > because RC-buggy linux-2.6 packages keep making it into > > testing. Is it obvious how to keep this from happening, > > without starting a new bug attached to linux-2.6? > > if you feel like it reassign it, > anyway linux-2.6 is frozen and propagation to testing > is coordinated with the release and the d-i team. Sorry, I don't understand this statement. > on the other side a good example to remove people access to > their discs. That's the argument that sent sarge out the door with DFSG violations. > anyway if you want to improve the legal situtation use: > http://wiki.debian.org/KernelFirmwareLicensing > dilinger succeeded in various firmware relicensing > thanks to his quest to the vendors. feel free to pick up. For each offending file, there are three possible solutions: 1. Get the author to release source code under a DFSG-free license 2. Move the firmware to non-free, patching the driver to use request_firmware() 3. Delete the driver and firmware entirely. AFAIK, the best outcome yet from the relicensing discussions on http://wiki.debian.org/KernelFirmwareLicensing is to properly permit the redistribution of the binary, without source code. That's fine for debian non-free, and a necessary step for making option (2) above work properly. Until and unless the entire Linux kernel is moved to non-free, such relicensing doesn't solve the fundamental bug. I agree that option (3) is bad, but I still recommend it for the short term. It's the quickest path to a legal and SC-conforming Linux release, and it will bring people out of the closet to volunteer to work on (2). I think (2) is the actual goal, but maybe not one that can be finished before the proposed etch freeze -- especially since most of the blobs need to be relicensed before they can be made part of firmware-nonfree. I would be amazed and impressed if option (1) could be made to work for any of these files. I don't volunteer to try. If the kernel team decides on (2) or (3), I'd be happy to help with the coding. (Note that, due to the unfortunate state of upstream, most of the patching/deletion has to happen in the creation of the .orig.tar.gz file, not the .diff.gz file) Unfortunately, due to a lack of hardware, I can't help with any testing (other than "does it compile"). - Larry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#383403: closed by maximilian attems <[EMAIL PROTECTED]> (Re: Bug#383403: linux-2.6: includes nondistributable and non-free binary firmware)
Maks - On Thu, Aug 17, 2006 at 12:48:15AM -0700, Debian Bug Tracking System wrote: > On Wed, Aug 16, 2006 at 05:17:34PM -0700, Larry Doolittle wrote: > > Package: linux-2.6 > > Severity: serious > > Justification: Policy 2.1 > > how about if you check for duplicate bug reports! > see #242866 for same style. I'm aware of #242866, and I'd be happy to work within that report. Something about it seems broken, however, because RC-buggy linux-2.6 packages keep making it into testing. Is it obvious how to keep this from happening, without starting a new bug attached to linux-2.6? > > The following 59 files, found in Debian's linux-2.6_2.6.17.orig.tar.gz, > > apparently contain software in binary form, for which Debian has no > > corresponding source code. Debian policy states that "The program > > must include source code, and must allow distribution in source code > > as well as compiled form." Therefore Debian must not distribute these > > files. > > you give zero prove that they are not register code, Huh. Have you actually looked at the files in question? I don't actually care what the data is called. Take a near-random example: drivers/scsi/qlogicpti_asm.c 1. The file represents approximately 18482 bytes of binary data. Nobody enters that in hex without machine help. 2. The file name refers to "asm", commonly understood shorthand for "assembler", the process of (or program for) converting human-legible code to such binaries. 3. Similar binaries from the same manufacturer, that are downloaded to boards serving a similar function, are provided with assembly source code. If you find any of those 59 files that does _not_ look like it was machine-generated from source code at some point in its history, or find comments from the author explaining how they wrote those files from scratch by typing in hex numbers, please let me know so I can correct my inventory. If you can even show hints that a file is miscategorized, I would be happy to participate in constructive discussion. Your throwaway one-liner above is not a good start. - Larry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: firmware blobs
Sven - On Wed, Aug 16, 2006 at 09:01:15PM +0200, Sven Luther wrote: > Ah, it has been argued, that since the driver depends on the firmware to work, > it should then go to contrib, but not stay in main, so moving the whole stuff > to non-free is lightyears easier to handle, and you don't need to do the > source-code modification work to remove the firmware. I don't buy that argument. There might be other means of loading the firmware (warm boot from windows, additional hardware, etc.). Once it's in, the driver will work fine. The driver depends on the hardware to work, too, and we don't require a way to stuff the hardware into the tarball. The source-code modification work is easy (in most cases). The hard part will be testing: you have to get the modified kernel, the firmware blob, and initrd scripting infrastructure in the hands of someone (relatively competent) who has the affected hardware. They also have to be willing to reboot a few times. > [chop] people where saying that we were fools to ask [for a real > firmware license] from > broadcom, given their non-free-software attitude and all, and they were rather > helpful and after some lengthy discussion and consulting of their legal > department, they agreed to change the licencing, so it is no more defacto > GPL2 (altough it remains non-free, but at least it is distributable). > > The main problems are those drivers where the copyright author is lost. I think the job is worth doing, but it's far more than I can accomplish in an afternoon. Just for fun, I might try to follow up on the two blobs I started chasing down. > > I already emailed Frederik Schueler, suggesting that the offending > > code get ripped out of 2.6.17 before its upcoming migration to testing. > > Hehe, but this public list is probably the best place to handle such stuff, > since we are a maintainer team. OK. I now publicly suggest "that the offending code get ripped out of 2.6.17 before its upcoming migration to testing." - Larry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: firmware blobs
Sven - On Wed, Aug 16, 2006 at 08:00:26PM +0200, Sven Luther wrote: > Thanks for this report, it is nice to see someone actually contributing useful > information instead of just complaining :) Quoting from the Beatles: "You say you want a contribution, well, you know, we're all doing what we can." > > Unless something changes soon, we're looking at 59 RC bugs > > in the linux-2.6 source package. The good news (AFAICT) is > Well, i think a single RC bug with info about all of them would be > enough. If the kernel maintainers agree to rip them all out at once, I agree. If they want to "fix" them one-by-one, we need 59 independent bugs filed. > > that ripping these non-SC-conforming files out of the kernel, > Well, i think it would be easier to move the whole drivers to non-free, this > is the way we have been doing this until now at least. Whatever. I'm neither a kernel maintainer, nor a firmware-nonfree maintainer. I see firmware, but no drivers, in firmware nonfree. I see two advantages to finally having a driver in the kernel without its firmware: (1) this can improve the legal situation of upstream. (2) it keeps the architecture-dependent and toolchain-sensitive stuff in one set of .debs (linux-*.deb), while the firmware-nonfree .deb is architecture independent. Otherwise, the firmware-laden modules end up with a pseudo-duplicate of the kernel's fancy build system. Finally, moving drivers to non-free only helps for the 12 files that are BSD-ish. The 44 GPL-ish files _have_ to have their firmware separated out. > BTW, if you have some time, and feel like doing it, could you identify the > copyright holders on the non-distributable parts of it ? It would make asking > them to clarify the licencing easier that way, as we already did for broadcom > and the ql-thingies. This is a big job, and unlikely to have much success. I actually tried on two of them (drivers/net/myri_code.h and drivers/media/dvb/ttusb-budget/dvb-ttusb-dspbootcode.h). In both cases, the manufacturer supplied hardware, documentation, and otherwise cooperated with the driver development. So the intent is (probably) there, but there is no known paper trail that would authorize redistribution of the copyrighted material. > Nice, but there is lengthy and non-negligible d-i work which needs to be done, > and as they want to freeze pretty early ... I already emailed Frederik Schueler, suggesting that the offending code get ripped out of 2.6.17 before its upcoming migration to testing. - Larry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
firmware blobs
Kernel team (and lurkers) - Binary-only firmware in the Linux kernel lives on in Debian's anxiety closet. I find 59 instances in linux-2.6_2.6.17.orig.tar.gz. Please review my analysis posted at http://doolittle.icarus.com/~larry/fwinventory/2.6.17.html Unless something changes soon, we're looking at 59 RC bugs in the linux-2.6 source package. The good news (AFAICT) is that ripping these non-SC-conforming files out of the kernel, or putting conforming replacements back in, doesn't change the kernel ABI, so this work could be considered consistent with a release freeze. - Larry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
