[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gNewSense-users] KFV: possible firmware

From: Bake Timmons
Subject: Re: [gNewSense-users] KFV: possible firmware
Date: Thu, 19 Jun 2008 15:20:26 -0400
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux)

> Great. Thanks, Bake. Last question, and then this directory is done
> (sorry, I probably should have put this all on one email).
>  has the following introduction:
> Lot of voodoo here.  Even the data sheet doesn't help to
>      understand what is going on here, the documentation for the audio
>      part of the cx2388x chip is *very* bad.
>      Some of this comes from party done linux driver sources I got from
>      [undocumented].
>      Some comes from the dscaler sources, one of the dscaler driver guy works
>      for Conexant ...
> And it has long static structs like this:
> static const struct rlist nicam_bgdki_common[] = {
>               {AUD_AFE_12DB_EN, 0x00000001},
>               {AUD_RATE_ADJ1, 0x00000010},
>               {AUD_RATE_ADJ2, 0x00000040},
>               {AUD_RATE_ADJ3, 0x00000100},
>               {AUD_RATE_ADJ4, 0x00000400},
>               {AUD_RATE_ADJ5, 0x00001000},
>               {AUD_ERRLOGPERIOD_R, 0x00000fff},
>               {AUD_ERRINTRPTTHSHLD1_R, 0x000003ff},
>               {AUD_ERRINTRPTTHSHLD2_R, 0x000000ff},
>               {AUD_ERRINTRPTTHSHLD3_R, 0x0000003f},
>               {AUD_POLYPH80SCALEFAC, 0x00000003},
>               {AUD_DEEMPHGAIN_R, 0x000023c2},
>               {AUD_DEEMPHNUMER1_R, 0x0002a7bc},
>               {AUD_DEEMPHNUMER2_R, 0x0003023e},
>               {AUD_DEEMPHDENOM1_R, 0x0000f3d0},
>               {AUD_DEEMPHDENOM2_R, 0x00000000},
>               {AUD_PDF_DDS_CNST_BYTE2, 0x06},
>               {AUD_PDF_DDS_CNST_BYTE1, 0x82},
>               {AUD_QAM_MODE, 0x05},
>               { /* end of list */ },
>       };
> There doesn't seem to be any other signs of firmware.

A relatively interesting section, huh Peter? :)

Yeah, I noticed that bit also.  I doubt that the struct is a problem,
since those values seem to have to do with *high-level*
characteristics of a device and not low-level machine code of some
chip.  The comment about it being voodoo is interesting and suggests
the kind of reverse engineering work that we might find in some
drivers.  This can be a gray area wrt to licensing, but I think that
it is OK here.

The more worrying part to me is the vague statement about where the
code comes from.  You might feel like double checking with the author,
but I am not worried enough about this case to think of it as a
problem.  I did a little digging around on the net about cx88 but
spotted no doubts regarding its licensing.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]