On Thu, Oct 23, 2008 at 12:23:22PM -0500, Manoj Srivastava wrote:[color=blue]
> On Thu, Oct 23 2008, martin f krafft wrote:[/color]
[color=blue][color=green]
> > It's all a matter of defining what your priorities are, which brings
> > us back to the Social Contract, which says that these include:[/color][/color]
[color=blue][color=green]
> > - 100% freeness
> > - cater best to the interests of our users[/color][/color]
[color=blue]
> Frankly, this mindset infuriates me. It frames the discussion
> incorrectly, it implies that freeness and user interest are at
> odds.[/color]

No, it acknowledges that freeness and user interest are *sometimes* at
odds, and leaves it up to humans with faculties of reason to sort out which
of these two competing factors takes precedence in any given situation.

Otherwise, it might as well have just said "Our priority is our users"; if
you believe that what's best for free software is *always* what's best for
our users, and that what's best for our users is to use only free software,
then there's no need to spell this out as two *separate* priorities, right?

For users whose world is not circumscribed by the boundaries of the Debian
project, it is often the case that their short-term needs cannot be
satisfied by strictly free-software solutions. To demand, then, that users
make do with Free Software when it doesn't meet their needs is
self-defeating: it denies us the support of users who are potentially
sympathetic to the principles of Free Software, and it denies them the use
of the best OS on the planet.

To forestall the inevitable strawmen, I'll say plainly that I am *not*
arguing that this justifies including non-free software in Debian proper.
What I *am* arguing is that we are called by the Social Contract to help
ensure Debian's continued utility to the general population, because if
nothing else, that's where we find the next generations of developers who
will keep our project alive. This doesn't mean we should all drop what
we're doing and work on the firmware issue; but at the very least,
developers shouldn't be sanguine about proposing the outright removal of
firmware blobs, with no support for loading them from non-free, as a
"solution".
[color=blue]
> The same goes for people who are complaining oabout advocates
> of the social contract and libre software, calling them folks who do
> not care for users. I contend that people who stuff main with non-free
> stuff _are_ the ones acting against the interests of the users in the
> long term,[/color]

It's pretty insulting to suggest that there is a non-zero set of developers
who have been "stuffing" non-free stuff into main, particularly when the
very kernel team that's being maligned by this implication is the same group
that has already done the heavy lifting of as much of the sourceless
firmware removal as we've achieved so far.
[color=blue]
> Why is not putting non-free firmware in non-free not the right
> thing to do?[/color]

It is the right thing to do; and while I know there are people that
disagree, I haven't seen anyone in *this thread* disagree with that. But
there are lots of other things that are "right" to do, and not all of them
are possible to achieve at the same time with limited resources. Is it
still the Right Thing to remove non-free firmware if we don't also make it
possible to load it from non-free at the same time? Is it the Right Thing
to delay the next release indefinitely while the firmware problems are
sorted out?

Right now, I suspect the right thing to do might be for me to abandon this
thread and go fix some bugs instead.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer [url]http://www.debian.org/[/url]
[email]slangasek@ubuntu.com[/email] [email]vorlon@debian.org[/email]

--
To UNSUBSCRIBE, email to [email]debian-devel-REQUEST@lists.debian.org[/email]
with a subject of "unsubscribe". Trouble? Contact [email]listmaster@lists.debian.org[/email]

10-25-2008, 02:00 PM

unix

Re: [DRAFT] resolving DFSG violations

On Fri, Oct 24, 2008 at 22:22, Manoj Srivastava <srivasta@debian.org> wrote:
[color=blue]
> It should not take us an indefinite time to release with
> firmware blobs gone. I'll stake my reutation that the period involved
> is not indefinite, and there is a upper boundary to it.
>
> Testing out the patches that have been produced by Ben ought not
> to take "indefinite" time. It took me just a couple of hours to test
> the kernels on the four machines I own; and they worked just fine. Of
> course, my machines are not affected by the firmware issues, so I know
> this means little for the regression testing.[/color]

I'm willing to stake my reputation on betting you are _not_ a firmware
engineer. Your are totally wrong if you think all firmware blobs can
be replaced by human readable source.

There is hardware, for which to function, will always, for the
lifetime of the equipment, require a firmware blob to operate. This
will always be the case; there will never be a human readable version.
It will never be possible to compile it (with non-free compilers) from
source code. There seems to be the belief that there is some scary
bogeyman at the end of this tunnel; some deliberate evil firmware
engineer who refuses to release the "source" for the blob. This is
hardly the case.

In fact, the exact opposite is true; the most free pieces of hardware
in the world require a firmware blob! A good example: try out the pci
core from opencores.org. Even in that case, where you have the logic
for the actual chip, you still have no choice but to distribute a
firmware blob anyway.

Going and flapping around and irritating hardware engineers with
totally impossible requests (Give us your psoc firmware sourcecode or
you suck! Thanks, the debian project.) makes us look like a bunch of
clueless and irrational software engineers. You think there must be
some magic way, well there is not.

I doubt anyone reading this uses coreboot which means that the first
instruction anyone ran today was a binary only firmware blob. Where is
all your concern about that? Doubly annoying is that that firmware is
actually x86 code and it is possible to get source code that can be
compiled with gcc. That would actually be fruitful and practical.

--
To UNSUBSCRIBE, email to [email]debian-devel-REQUEST@lists.debian.org[/email]
with a subject of "unsubscribe". Trouble? Contact [email]listmaster@lists.debian.org[/email]

10-25-2008, 03:00 PM

unix

Re: [DRAFT] resolving DFSG violations

On Sat, Oct 25, 2008 at 10:21 PM, Manoj Srivastava <srivasta@debian.org> wrote:
[color=blue]
> Your argument boils down to: There is function that will never
> be supported by free software.[/color]

This is an incorrect assumption too, there are several pieces of free
firmware already:

Motorola DSP56001 (assembler for it is ITPed in #502508)

prism54 wireless, the FreeMAC firmware (still in progress upstream)

CHDK, firmware for some kinds of digital cameras

rockbox, firmware for some kinds of digital music players

--
bye,
pabs

[url]http://wiki.debian.org/PaulWise[/url]

--
To UNSUBSCRIBE, email to [email]debian-devel-REQUEST@lists.debian.org[/email]
with a subject of "unsubscribe". Trouble? Contact [email]listmaster@lists.debian.org[/email]

10-25-2008, 04:30 PM

unix

Re: [DRAFT] resolving DFSG violations

"Jeff Carr" <basilarchia@gmail.com> wrote:
[color=blue]
> There is hardware, for which to function, will always, for the
> lifetime of the equipment, require a firmware blob to operate. This
> will always be the case; there will never be a human readable version.
> It will never be possible to compile it (with non-free compilers) from
> source code. [/color]

How can that be? (That is an ernest question)

The engineers will have some description of what the firmware should do
(in terms of what to read and write from which register etc., not only
in terms of "initialize communication"), and some rules how to translate
these procedures into a binary blob.

I doubt the translation needs to be done by hand, instead of by a
compiler, but even if it was, wouldn't the software be useful? And
couldn't the "description of what the firmware should do" be treated as
the source, then?

I mean, your argument seems to be "there is no such thing as source for
firmware, so we cannot possibly require it". But isn't that description
of the function just the source?

--
To UNSUBSCRIBE, email to [email]debian-devel-REQUEST@lists.debian.org[/email]
with a subject of "unsubscribe". Trouble? Contact [email]listmaster@lists.debian.org[/email]

10-27-2008, 01:50 AM

unix

Re: [DRAFT] resolving DFSG violations

On Sat, Oct 25, 2008 at 09:21, Frank KĂĽster <frank@debian.org> wrote:
[color=blue]
> How can that be? (That is an ernest question)[/color]

Because that's how the hardware works. If you are making a widget and
you need a fpga or hybrid chip of any sort, then you generate a binary
blob using the chip manufacturers tools.

So, no matter how good you intend on being, how much you love free
software, you don't have any choice. Again, this is ironic since
things like the opencores project are the most free hardware of all
and are not given credit for it in this thread.

10-27-2008, 03:20 AM

unix

Re: [DRAFT] resolving DFSG violations

On Sat, Oct 25, 2008 at 07:21, Manoj Srivastava <srivasta@debian.org> wrote:
[color=blue]
> Your argument boils down to: There is function that will never
> be supported by free software. Annoying people by asking them to expose
> their function by freeing the software just irritates them, so we
> should just suck it up and accept it.[/color]

I don't think I'm explaining this well, as it seems you are still not
getting it: there isn't any source code to get.
[color=blue]
> Guess how we cater to people who need non-free software for
> some functionality they must have? We put it into a place called the
> non-free archive.[/color]

Great; totally useless raw data the chips on the machine need so we
can write free device drivers to talk to them. Excellent. So the plan
is: "Debian is only for hardware manufacturers that embed the firmware
in flash. If you hide your non-free stuff, that'd be great because
then we could pretend it doesn't really exist. Please don't disrupt
our perfect version of how the world works."
[color=blue]
> You do not have to be a "firmware engineer" to grok that.[/color]

I guess I'll find out. I think this proposal is just trying to pretend
that there isn't firmware in the machines now. How does it help the
free software movement if we try to ignore the non-free firmware
booting our machines now? Why are we trying to shuffle that under the
rug?
[color=blue]
> ps: back in the day, before I became a quantum mechanic, I toyed around
> with seeing if designing microprocessors was for me. I did design a 27
> instructions, 4 bit microprocessor with microcode, so I get what
> firmware is.[/color]

It depends,

I'm talking about the synthesized image of the microprocessor (for the
xlinux, altera, etc). I'm not talking about if you emulated it on
solaris to check your processor (CS courses often do processor
projects of that sort). I'm also not talking uboot/coreboot like
firmware or psos-like things (also firmware but they _do_ have source
code).

If you did synthesize it, you might not have even "seen" it if you put
it on a cpld. Then you might have just thought you were "programming"
the chip. No; you were just writing it to flash. Thus bypassing the
dilemma. If you build a product and don't want to pay to have the
extra chip onboard (common on cheap low end parts) then you have to
load it via software. Thus the firmware blob. And yes, for the 50th
time: THERE IS NOT SOURCE CODE. There can not be source code, it
didn't start as source code. You can't "compile" it because there
isn't a compiler. It's not instructions for a microprocessor -- in
your case -- it is the microprocessor itself. That's right, lets say
that again, the firmware blob is your 4 bit microprocessor.

So this whole free 4 bit microprocessor you just made, you can publish
the source and everything (see also: openrisc & opensparc). But, to
run it, you have to give people a firmware blob so they can run it.
Perhaps you can't even make an installer for it because you can't
initialize the chip in the installer because you can't put the fimware
you need in the installer. So you can only support hardware where you
can flash the firmware on the motherboard. Also not ideal because you
might have a version out of sync with the kernel device driver you
wrote. Great, thanks a lot freedom.

So yes, I think most people aren't going to "get" the issue unless
they may have been firmware engineers.

--
To UNSUBSCRIBE, email to [email]debian-devel-REQUEST@lists.debian.org[/email]
with a subject of "unsubscribe". Trouble? Contact [email]listmaster@lists.debian.org[/email]

10-27-2008, 10:20 AM

unix

Re: [DRAFT] resolving DFSG violations

On Mon, 2008-10-27 at 18:31 +1100, Ben Finney wrote:[color=blue]
> "Jeff Carr" <basilarchia@gmail.com> writes:
> [color=green]
> > On Sat, Oct 25, 2008 at 07:21, Manoj Srivastava <srivasta@debian.org> wrote:
> > [color=darkred]
> > > Your argument boils down to: There is function that will
> > > never be supported by free software. Annoying people by asking
> > > them to expose their function by freeing the software just
> > > irritates them, so we should just suck it up and accept it.[/color]
> >
> > I don't think I'm explaining this well, as it seems you are still
> > not getting it: there isn't any source code to get.[/color][/color]

I just want to find out: Under what circumstances does the blob need to
be modified and who gets to do that modification?

From earlier thread:
[color=blue]
> Because that's how the hardware works. If you are making a widget and
> you need a fpga or hybrid chip of any sort, then you generate a binary
> blob using the chip manufacturers tools.[/color]

Are these "chip manufacturer tools" physical tools/machines or software
programs? (i.e. something I need to pick up in my hands or something I
need to execute?) Is there any way that someone else can use the same or
similar tools to modify the blob (even if it is only useful to do so on
a different board / with a different chipset)?
[color=blue]
> If so, I don't get it either.
>
> If we use the â€śpreferred form of the work for making modifications to
> itâ€ť definition of source code, what is the form that best meets that
> definition?[/color]

If the chip is used on a different board with different configuration,
is the blob going to need to be changed and who gets to change it? Can
Debian include software that supports porting Debian to the new board or
can the blob be used to lock Debian out? If I build a customised board
myself, is the blob / lack of blob going to prevent me running free
software on the chip/board?
[color=blue]
> If the vendor is able to send out a bit stream and (with or without
> the owner's intervention) load that bit stream onto the
> already-purchased hardware to modify its behaviour, then we just
> crossed into the realm where the recipients of those bytes (the owners
> of the hardware) deserve all the free-software freedoms in order to
> retain ownership of their hardware.[/color]

Sounds like a DRM type intervention.
[color=blue]
> If the bit stream is contained in hardware such that it not feasible
> for the user *or* the vendor to modify, then they are both on equal
> footing and it's much less important to demand free-software rights,
> since the vendor doesn't have them either.
> [color=green]
> > So yes, I think most people aren't going to "get" the issue unless
> > they may have been firmware engineers.[/color]
>
> Thank you for continuing to discuss it; I'm genuinely interested in
> testing the principles of software freedom to ensure they continue to
> apply as computer designs change.[/color]

From an embedded perspective - so am I. I admit, I know very little
about the minutiae of hardware but I know I'm going to come up against
these problems and I want to know more about fixing them - *without*
needing to get permission from the chip manufacturers or getting their
software tools or needing expensive hardware tools.

Neil Williams <codehelp@debian.org> writes:
[color=blue]
> On Mon, 2008-10-27 at 18:31 +1100, Ben Finney wrote:[color=green]
> > If the vendor is able to send out a bit stream and (with or
> > without the owner's intervention) load that bit stream onto the
> > already-purchased hardware to modify its behaviour,[/color][/color]

That qualifier in parentheses would perhaps be better worded as
â€ś(it's irrelevant for this distinction whether the user's
intervention is required or not)â€ť.

In other words, I'm intending for this test to apply irrespective of
whether we're talking about a firmware loading program that the user
runs manually, or an automated phone-home update mechanism, or
anything else. The test is only whether there is an intentional
pipeline from â€śvendor distributes new bit streamâ€ť to â€śexisting
device now operating with newer vendor-supplied bit streamâ€ť.
[color=blue][color=green]
> > then we just crossed into the realm where the recipients of those
> > bytes (the owners of the hardware) deserve all the free-software
> > freedoms in order to retain ownership of their hardware.[/color][/color]

Further, if that bit stream is something we're proposing to be
distributed as part of Debian, I'm saying this means that the Social
Contract promises that the bit stream will be free.
[color=blue]
> Sounds like a DRM type intervention.[/color]

Yes, that's one possible case, but I'm drawing a different line that
may or may not encompass DRM. I hope that's clearer with the above
expansion.
[color=blue][color=green]
> > If the bit stream is contained in hardware such that it not
> > feasible for the user *or* the vendor to modify, then they are
> > both on equal footing and it's much less important to demand
> > free-software rights, since the vendor doesn't have them either.[/color][/color]

--
\ â€śHere is a test to see if your mission on earth is finished. If |
`\ you are alive, it isn't.â€ť â€”Francis Bacon |
_o__) |
Ben Finney

--
To UNSUBSCRIBE, email to [email]debian-devel-REQUEST@lists.debian.org[/email]
with a subject of "unsubscribe". Trouble? Contact [email]listmaster@lists.debian.org[/email]

10-27-2008, 12:40 PM

unix

Re: [DRAFT] resolving DFSG violations

On Mon, Oct 27, 2008 at 10:10:19AM +0000, Neil Williams wrote:[color=blue]
> On Mon, 2008-10-27 at 18:31 +1100, Ben Finney wrote:[/color]
[color=blue][color=green]
> > Because that's how the hardware works. If you are making a widget and
> > you need a fpga or hybrid chip of any sort, then you generate a binary
> > blob using the chip manufacturers tools.[/color][/color]
[color=blue]
> Are these "chip manufacturer tools" physical tools/machines or software
> programs? (i.e. something I need to pick up in my hands or something I
> need to execute?) Is there any way that someone else can use the same or[/color]

Software.
[color=blue]
> similar tools to modify the blob (even if it is only useful to do so on
> a different board / with a different chipset)?[/color]

Ish. Someone else should be able to use the same tools (barring
development environment issues) but modern FPGAs provide encryption
mechanisms which mean that only someone posessing a security key blown
into the hardware during the manufacturing process can generate an image
that will be accepted.

--
"You grabbed my hand and we fell into it, like a daydream - or a fever."

--
To UNSUBSCRIBE, email to [email]debian-devel-REQUEST@lists.debian.org[/email]
with a subject of "unsubscribe". Trouble? Contact [email]listmaster@lists.debian.org[/email]

10-27-2008, 06:30 PM

unix

Re: [DRAFT] resolving DFSG violations

On Sat, Oct 25, 2008 at 06:46:14AM -0700, Jeff Carr wrote:[color=blue]
> I'm willing to stake my reputation on betting you are _not_ a firmware
> engineer. Your are totally wrong if you think all firmware blobs can
> be replaced by human readable source.
>
> There is hardware, for which to function, will always, for the
> lifetime of the equipment, require a firmware blob to operate. This
> will always be the case; there will never be a human readable version.
> It will never be possible to compile it (with non-free compilers) from
> source code. There seems to be the belief that there is some scary
> bogeyman at the end of this tunnel; some deliberate evil firmware
> engineer who refuses to release the "source" for the blob. This is
> hardly the case.
>
> In fact, the exact opposite is true; the most free pieces of hardware
> in the world require a firmware blob! A good example: try out the pci
> core from opencores.org. Even in that case, where you have the logic
> for the actual chip, you still have no choice but to distribute a
> firmware blob anyway.[/color]

I would expect anything on opencores.org to be perfectly readable VHDL
code, which is the prefered format for manipulating it. So what was
your point again? Besides FPGA's can work with eeproms, so no binary
blob has to be distributed with the OS to work with the device.
[color=blue]
> Going and flapping around and irritating hardware engineers with
> totally impossible requests (Give us your psoc firmware sourcecode or
> you suck! Thanks, the debian project.) makes us look like a bunch of
> clueless and irrational software engineers. You think there must be
> some magic way, well there is not.[/color]

For some firmware it does make sense, for others it does not.
[color=blue]
> I doubt anyone reading this uses coreboot which means that the first
> instruction anyone ran today was a binary only firmware blob. Where is
> all your concern about that? Doubly annoying is that that firmware is
> actually x86 code and it is possible to get source code that can be
> compiled with gcc. That would actually be fruitful and practical.[/color]

Yes the BIOS doesn't include source code, but there also is no need for
Debian to distribute the BIOS code in main for Debian to be able to
install and run on my system.

This whole debate is about Debian having to ship said firmware, not
about whether hardware needs firmware or not. That is a different
debate, but not one that directly involves the Debian distribution.

So much as closed source binaries and firmware on flash chips in raid
controllers may be annoying, it does not in any way affect the freeness
of the code _distributed_ by Debian.

--
Len Sorensen

--
To UNSUBSCRIBE, email to [email]debian-devel-REQUEST@lists.debian.org[/email]
with a subject of "unsubscribe". Trouble? Contact [email]listmaster@lists.debian.org[/email]

10-27-2008, 06:40 PM

unix

Re: [DRAFT] resolving DFSG violations

On Sun, Oct 26, 2008 at 06:38:53PM -0700, Jeff Carr wrote:[color=blue]
> Because that's how the hardware works. If you are making a widget and
> you need a fpga or hybrid chip of any sort, then you generate a binary
> blob using the chip manufacturers tools.[/color]

But you provide input to the tool, usually VHDL code or similar. That
would be the source, and you can provide that. That is the prefered
format for editing. We use plenty of FPGAs at work, and I have seen how
they are programmed, and yes I have seen what the source looks like. It
is certainly human readable source code. If you think otherwise, then
you don't know how FPGAs and CPLDs work.

The tool doesn't have a magic buttong labeled 'make the chip do what I
am thinking of now".
[color=blue]
> So, no matter how good you intend on being, how much you love free
> software, you don't have any choice. Again, this is ironic since
> things like the opencores project are the most free hardware of all
> and are not given credit for it in this thread.[/color]

And opencores.org distributes source, not binary blobs. Gee whiz.

--
Len Sorensen

--
To UNSUBSCRIBE, email to [email]debian-devel-REQUEST@lists.debian.org[/email]
with a subject of "unsubscribe". Trouble? Contact [email]listmaster@lists.debian.org[/email]

10-27-2008, 07:30 PM

unix

Re: [DRAFT] resolving DFSG violations

On Mon, Oct 27, 2008 at 11:35, Lennart Sorensen
<lsorense@csclub.uwaterloo.ca> wrote:[color=blue]
> On Sun, Oct 26, 2008 at 06:38:53PM -0700, Jeff Carr wrote:[color=green]
>> Because that's how the hardware works. If you are making a widget and
>> you need a fpga or hybrid chip of any sort, then you generate a binary
>> blob using the chip manufacturers tools.[/color]
>
> But you provide input to the tool, usually VHDL code or similar. That
> would be the source, and you can provide that. That is the prefered
> format for editing. We use plenty of FPGAs at work, and I have seen how
> they are programmed, and yes I have seen what the source looks like. It
> is certainly human readable source code. If you think otherwise, then
> you don't know how FPGAs and CPLDs work.[/color]

True, I certainly feel like that at times with the opencores project
I've been trying to maintain.

On the other hand, I sure know that I know a pile more than you do or
we wouldn't be having this discussion :)
[color=blue]
> The tool doesn't have a magic buttong labeled 'make the chip do what I
> am thinking of now".
>[color=green]
>> So, no matter how good you intend on being, how much you love free
>> software, you don't have any choice. Again, this is ironic since
>> things like the opencores project are the most free hardware of all
>> and are not given credit for it in this thread.[/color]
>
> And opencores.org distributes source, not binary blobs. Gee whiz.[/color]

Yes Gee whiz. You're not getting it. The firmware is a binary blob.
You can distribute the source but you can't synthesize it. So, in the
debian installer, you can't include it according to this insane
policy.

But the opencore case is the easy case, hybrid chips don't even have
source. The firmware blob is often generated when you fabricate the
chip & changes with the physical board layout. You guys just don't
understand the issues here. There isn't some nafarious intent; you
have little flash chips holding these bits all over in your machine
now. You just don't know it. And now, because someone is giving you
the luxury of actually loading them via software (with gpl software no
less) you seem to be all ticked off. You seem to want to stick your
head in the sand and pretend this doesn't exist.

And no, it's not about telling users "This is all free". That's a lie
at this level anyway. None of it is free. Whether you load it from
/lib/firmware/ or if it's already stored on your motherboard doesn't
change anything. It just makes us Debian look ridiculous. The message
should be: "There are some firmware blobs for some hardware that there
is no known way to generate code for, nor any way to compile such code
if we had it or any way to figure out how we would write a compiler
for it either. This firmware is also hidden in flash for most of the
chips on your machine. Some modern devices let the OS load this code
into the chip then we are able to write fully GPL drivers for the
device. Debian's focus is on free software; not free hardware designs
(although we love those too).

--
To UNSUBSCRIBE, email to [email]debian-devel-REQUEST@lists.debian.org[/email]
with a subject of "unsubscribe". Trouble? Contact [email]listmaster@lists.debian.org[/email]

Hardly perfectly readable - I put up code there too :)
[color=blue]
> code, which is the prefered format for manipulating it. So what was
> your point again? Besides FPGA's can work with eeproms, so no binary
> blob has to be distributed with the OS to work with the device.[/color]

Which is often not the case on cheap devices (often usb) because of
cost, space, power, etc for another chip.

--
To UNSUBSCRIBE, email to [email]debian-devel-REQUEST@lists.debian.org[/email]
with a subject of "unsubscribe". Trouble? Contact [email]listmaster@lists.debian.org[/email]

10-27-2008, 08:00 PM

unix

Re: [DRAFT] resolving DFSG violations

On Mon, Oct 27, 2008 at 05:36, Mark Brown <broonie@sirena.org.uk> wrote:
[color=blue][color=green]
>> similar tools to modify the blob (even if it is only useful to do so on
>> a different board / with a different chipset)?[/color]
>
> Ish. Someone else should be able to use the same tools (barring
> development environment issues) but modern FPGAs provide encryption
> mechanisms which mean that only someone posessing a security key blown
> into the hardware during the manufacturing process can generate an image
> that will be accepted.[/color]

What you said here doesn't make any sense. Barring development
environment issues? That's just skimming the surface of the issues.

--
To UNSUBSCRIBE, email to [email]debian-devel-REQUEST@lists.debian.org[/email]
with a subject of "unsubscribe". Trouble? Contact [email]listmaster@lists.debian.org[/email]

10-27-2008, 08:10 PM

unix

Re: [DRAFT] resolving DFSG violations

Jeff Carr wrote:
[color=blue]
> But the opencore case is the easy case, hybrid chips don't even have
> source. The firmware blob is often generated when you fabricate the
> chip & changes with the physical board layout. You guys just don't
> understand the issues here.[/color]

Please explain what the issues are, then. The firmware blob has to be generated
*somehow*. There is a tool that generates the blob. Which data does the tool
need to generate it?

--

Felipe Sateler

--
To UNSUBSCRIBE, email to [email]debian-devel-REQUEST@lists.debian.org[/email]
with a subject of "unsubscribe". Trouble? Contact [email]listmaster@lists.debian.org[/email]

10-27-2008, 08:10 PM

unix

Re: [DRAFT] resolving DFSG violations

On Mon, Oct 27, 2008 at 03:10, Neil Williams <codehelp@debian.org> wrote:
[color=blue]
> I just want to find out: Under what circumstances does the blob need to
> be modified and who gets to do that modification?[/color]

Probably only the hardware engineers.
[color=blue]
> Are these "chip manufacturer tools" physical tools/machines or software
> programs? (i.e. something I need to pick up in my hands or something I
> need to execute?)[/color]

kind of. Modern machines are designed on older machines using software
of some sort or another.
[color=blue]
> Is there any way that someone else can use the same or
> similar tools to modify the blob (even if it is only useful to do so on
> a different board / with a different chipset)?[/color]

no, not usually unless you are the one that designed the board.
[color=blue]
> If the chip is used on a different board with different configuration,[/color]

then you would generate your own firmware blob
[color=blue]
> is the blob going to need to be changed and who gets to change it? Can[/color]

you as the board designer
[color=blue]
> Debian include software that supports porting Debian to the new board or[/color]

thats where you write a gpl kernel driver
[color=blue]
> can the blob be used to lock Debian out? If I build a customised board
> myself, is the blob / lack of blob going to prevent me running free
> software on the chip/board?[/color]

yes, if you don't load the blob into the chip, the chip stays
un-initialized. Thats what /lib/firmware is for.

You can put the blob on a flash chip in hardware to avoid software
needing to load it, but on cheap devices, the manufacturers are
usually trying to save on the cost of another chip.
[color=blue]
> Sounds like a DRM type intervention.[/color]

no, that's something totally different. This firmware blob just tells
the chip what it's wires do (electriclly/logically)
[color=blue]
> From an embedded perspective - so am I. I admit, I know very little
> about the minutiae of hardware but I know I'm going to come up against
> these problems and I want to know more about fixing them - *without*
> needing to get permission from the chip manufacturers or getting their
> software tools or needing expensive hardware tools.[/color]

If you what to change how the chip works outside of the device you
purchased you wouldn't be purchasing that device. For instance, you
aren't going to be able to take a usb/ethernet device and turn it into
a usb/sata device even if the chip was capable of it -- you'd have to
change the board layout so changing the firmware blob there doesn't
make any sense.

In any case, all of this is theoretical; it's just doesn't make any
sense to change the manufacturer firmware blob. If you want to do that
and are smart and experienced enough, you would start your own company
building hardware devices and compete with whatever device it is that
isn't doing what you need it to do. That would be much easier than
trying to change a chip/board you don't have schematics for.

--
To UNSUBSCRIBE, email to [email]debian-devel-REQUEST@lists.debian.org[/email]
with a subject of "unsubscribe". Trouble? Contact [email]listmaster@lists.debian.org[/email]

10-27-2008, 08:20 PM

unix

Re: [DRAFT] resolving DFSG violations

On Mon, Oct 27, 2008 at 00:31, Ben Finney <ben+debian@benfinney.id.au> wrote:
[color=blue]
> If we use the "preferred form of the work for making modifications to
> it" definition of source code, what is the form that best meets that
> definition?
>
> What form of the work do the copyright holders use to make changes to
> it?[/color]

Usually it's whatever the chip manufacturer provides.

--
To UNSUBSCRIBE, email to [email]debian-devel-REQUEST@lists.debian.org[/email]
with a subject of "unsubscribe". Trouble? Contact [email]listmaster@lists.debian.org[/email]

10-28-2008, 01:50 AM

unix

Re: [DRAFT] resolving DFSG violations

"Jeff Carr" <basilarchia@gmail.com> writes:
[color=blue]
> On Mon, Oct 27, 2008 at 00:31, Ben Finney <ben+debian@benfinney.id.au> wrote:
>[color=green]
> > If we use the "preferred form of the work for making modifications
> > to it" definition of source code, what is the form that best meets
> > that definition?
> >
> > What form of the work do the copyright holders use to make changes
> > to it?[/color]
>
> Usually it's whatever the chip manufacturer provides.[/color]

That doesn't seem to address my question. Here, â€śthe copyright
holdersâ€ť means the copyright holders in the work under question; i.e.
the work whose freedom is being discussed: the bundle of bits that get
redistributed with the driver for loading onto the hardware.

Whoever the copyright holder of that work is (I read your remark above
to mean that the hardware manufacturer is that copyright holder),
there must be a â€śpreferred form of the work for making modifications
to itâ€ť. What form is that? *Someone* must have it, in order to make
modifications that become new releases of the work to run on the same
hardware.

--
To UNSUBSCRIBE, email to [email]debian-devel-REQUEST@lists.debian.org[/email]
with a subject of "unsubscribe". Trouble? Contact [email]listmaster@lists.debian.org[/email]

10-28-2008, 03:40 AM

unix

Re: [DRAFT] resolving DFSG violations

On Mon, Oct 27, 2008 at 18:41, Ben Finney <ben+debian@benfinney.id.au> wrote:
[color=blue]
> Whoever the copyright holder of that work is (I read your remark above
> to mean that the hardware manufacturer is that copyright holder),
> there must be a "preferred form of the work for making modifications
> to it". What form is that? *Someone* must have it, in order to make
> modifications that become new releases of the work to run on the same
> hardware.[/color]

I guess it's really hard to explain because there is a massive gap; I
can't teach you to be an electrical engineer or logician here :) I
think if you had the time to go through and synthesize "firmware
blobs" for some chips then you would see why this doesn't make sense.
It would also expose you to the tools that the hardware and logic
engineers use to do this process. It would also expose you to the
pre-requisite knowledge of the board design (layout, etc) that you
have to have. Then I think it would make sense to you why this
conversation doesn't make sense right now. It's that these "binary
only blobs" only make sense to the chip. It's like they are a map of
how the transistors are to function -- an oversimplification -- but
generally that's the nature of it. *

For example, lets say you have a pci device. If you don't load the
firmware blob, the pins will just remain in an uninitialized state.
That is; the chip default. Programming in the firmware blob will tell
the chip how to work as a pci bus. Now you are good to go. It's now
possible to write a pci device & there are registers, etc. As a
hardware engineer I can give you all the registers and an API and even
some sample GPL code so you can write a device driver. Now, some
people are smucks like nvidia and they don't give out diddly. Still,
the firmware blob that you load into the chip isn't x86 code for the
host -- it's raw junk for the chip. It's a totally different issue
than distributing a binary only nvidia driver. That's not what I'm
talking about here. I'm only trying to explain there are binary only
firmware blobs for most chips, you have them for most of the chips on
your motherboard and in many cases, there is no human readable form.
Even the chip manufacturers don't know what they are. It's totally
machine generated chip garbage as far as they are concerned. Once you
have the chip initialized then you can hook it up to an oscilloscope
to debug it (or maybe you're lucky and you can already talk to it from
your device driver).

--
To UNSUBSCRIBE, email to [email]debian-devel-REQUEST@lists.debian.org[/email]
with a subject of "unsubscribe". Trouble? Contact [email]listmaster@lists.debian.org[/email]

10-28-2008, 05:20 AM

unix

Re: [DRAFT] resolving DFSG violations

On Mon, Oct 27, 2008 at 08:30:38PM -0700, Jeff Carr wrote:[color=blue]
> I guess it's really hard to explain because there is a massive gap; I
> can't teach you to be an electrical engineer or logician here :) I[/color]

You are assuming there is gap when there may be not.
[color=blue]
> think if you had the time to go through and synthesize "firmware
> blobs" for some chips then you would see why this doesn't make sense.
> It would also expose you to the tools that the hardware and logic
> engineers use to do this process. It would also expose you to the[/color]

Would those be tools like a Verilog or VHDL synthetizer distributed by a
FPGA manufacturer? Considering the hardware is FPGA, of course. In the
case it is not, I assume there would still be procedures like logic
design, routing, etc.
[color=blue]
> pre-requisite knowledge of the board design (layout, etc) that you
> have to have. Then I think it would make sense to you why this
> conversation doesn't make sense right now. It's that these "binary
> only blobs" only make sense to the chip. It's like they are a map of[/color]

So, why do they only make sense to the chip? Is it because there is no
current implementation of a software simulator? And why would a software
simulator not be feasible? The binary blobs would make sense to the
simulator.
[color=blue]
> how the transistors are to function -- an oversimplification -- but
> generally that's the nature of it. *
>
> For example, lets say you have a pci device. If you don't load the
> firmware blob, the pins will just remain in an uninitialized state.
> That is; the chip default. Programming in the firmware blob will tell
> the chip how to work as a pci bus. Now you are good to go. It's now
> possible to write a pci device & there are registers, etc. As a
> hardware engineer I can give you all the registers and an API and even
> some sample GPL code so you can write a device driver. Now, some
> people are smucks like nvidia and they don't give out diddly. Still,
> the firmware blob that you load into the chip isn't x86 code for the
> host -- it's raw junk for the chip. It's a totally different issue[/color]

If it's not clear by now, people are not arguing that hardware should
not be used if it is not free hardware (either it is feasible or not to
distribute or exist source code). The matter is whether source for code
that will not execute in the main CPU is needed for those codes in the
main section. So, your point that it is not x86 code is moot in the case
"firmware" is considered to be the same as other software in Debian. If
source code isn't available or "possible" for the chip carries the same
requirements for DFSG as the case would be for the x86 code, in the case
"firmware" should still follow DFSG.
[color=blue]
> than distributing a binary only nvidia driver. That's not what I'm
> talking about here. I'm only trying to explain there are binary only
> firmware blobs for most chips, you have them for most of the chips on
> your motherboard and in many cases, there is no human readable form.[/color]

Even machine readable form would still be considered source if its
interpretation by the machine could be presented to someone to make
modifications to it. If it is not modifiable for some reason and every
design should be done from scratch, perhaps there is a problem with the
tools and/or processes used.
[color=blue]
> Even the chip manufacturers don't know what they are. It's totally
> machine generated chip garbage as far as they are concerned. Once you[/color]

Which machines do generate this "garbage"? Do they do it all by
themselves? Are there machines designing new hardware now without human
intervention? Or are those chips magically enhanced so they could make
some sense of any random bitstream and there is no real mistery in
generating this "garbage"?

If the manufacturers are unaware of it, I doubt the designer is unaware
of it.
[color=blue]
> have the chip initialized then you can hook it up to an oscilloscope
> to debug it (or maybe you're lucky and you can already talk to it from
> your device driver).
>
> * [url]http://en.wikipedia.org/wiki/Floorplan_(microelectronics[/url])
> * [url]http://en.wikipedia.org/wiki/Logic_synthesis[/url]
> * [url]http://en.wikipedia.org/wiki/Place_and_route[/url]
>
>
> --
> To UNSUBSCRIBE, email to [email]debian-devel-REQUEST@lists.debian.org[/email]
> with a subject of "unsubscribe". Trouble? Contact [email]listmaster@lists.debian.org[/email]
> [/color]