Re: [GNU-linux-libre] Nouveau: NONFSDG listing and current status?

[Brett Smith]

On 05/18/2011 05:08 PM, Rubén Rodríguez wrote:
> It is not an Ubuntu related problem. The first kernels after nouveau's
> inclusion on the main tree had a blob, which later was removed when
> they figured out how to generate the code at runtime. Since Ubuntu uses
> a fixed kernel version for every release, only jaunty and karmic were
> affected.

Ahhh, okay, I think I really get it now.  So if I were putting it in my
own words, I would say:

* Nouveau used to be shipped separately from mainline Linux.  When this
was true, it had a blob in it.  So if you're working from a distro that
has a separate Nouveau driver package, you need to be aware that package
probably has a blob in it.

* Nouveau still had the blob for a little while after it was
incorporated into mainline Linux, too.  If you're using linux-libre,
that will take the blob out for you, but otherwise you need to watch out
for this.

* Nowadays Nouveau generates the necessary code itself at runtime, so
it's in good shape.

Did I get all that right?

> Well, since the problematic part of nouveau is the kernel module I think
> it would make more sense to document it elsewere, as the list is for
> packages. But not all the distros listed as free are using linux-libre,
> so it would make sense to make this kind of problem more visible.

If what I wrote above is correct, then I agree with you that a listing
like the one we have is the right basic idea.  Now I'm thinking I'd like
to just add information to it.

>>> About the other free drivers, I've been looking into the Radeon
>>> blobs, and in most cases they are simple 2kb -with some padding
>>> zeroes- register dumps for a state machine initialization. If
>>> someone more skilled than me could break them into something
>>> documented we could have a lot more cards supported.
>>
>> If we know for *sure* that they're just initialization values
> 
> Well, that's what AMD's John Bridgman told me, more exactly:
> "They are state tables for hardware state machines.". When I asked for
> some documentation, he refused replying that "we are talking about
> horizontal microcode for hardware state machines so we would need to
> expose the internal design of our most complex hardware blocks."

I see.  I misunderstood what "state machine initialization" meant.  I
thought it was just setting up initial variable values for a state
machine that already existed in hardware -- not state tables that
described the entire state machine.  I agree with you that this is code.

> The thing is, I feel like we lack that doc just because nobody tried. :/

Mm, it's definitely not the case that nobody tried.  The FSF had a very
similar conversation with John Bridgman: same questions, same answers.
He's very adamant that they will not release the source for, or even
document, how that microcode works, because it will reveal the inner
details of the card's implementation (which I believe), and they're
convinced that all sorts of bad things will happen to the business if
that happens (which I can understand but I'm less impressed with).

-- 
Brett Smith
License Compliance Engineer, Free Software Foundation

Support the FSF by becoming an Associate Member: http://fsf.org/jf