Re: [gNewSense-users] KFV: possible firmware

[Bake Timmons]

> I found the following function in linux-ubuntu-modules
> ubuntu/media/cx88/cx88-blackbird.c. Is this nonfree?
> Also, are we only looking for tables like this? For example, I've also
> found things like:
> #define P1_MDATAO 0x390000
>
> Thanks
>  Peter
>
> static void dvico_fusionhdtv_hybrid_init(struct cx88_core *core)
> {
>       struct i2c_msg msg = { .addr = 0x45, .flags = 0 };
>       int i, err;
>       static u8 init_bufs[13][5] = {
>               { 0x10, 0x00, 0x20, 0x01, 0x03 },
>               { 0x10, 0x10, 0x01, 0x00, 0x21 },
>               { 0x10, 0x10, 0x10, 0x00, 0xCA },
>               { 0x10, 0x10, 0x12, 0x00, 0x08 },
>               { 0x10, 0x10, 0x13, 0x00, 0x0A },
>               { 0x10, 0x10, 0x16, 0x01, 0xC0 },
>               { 0x10, 0x10, 0x22, 0x01, 0x3D },
>               { 0x10, 0x10, 0x73, 0x01, 0x2E },
>               { 0x10, 0x10, 0x72, 0x00, 0xC5 },
>               { 0x10, 0x10, 0x71, 0x01, 0x97 },
>               { 0x10, 0x10, 0x70, 0x00, 0x0F },
>               { 0x10, 0x10, 0xB0, 0x00, 0x01 },
>               { 0x03, 0x0C },
>       };
>
>       for (i = 0; i < ARRAY_SIZE(init_bufs); i++) {
>               msg.buf = init_bufs[i];
>               msg.len = (i != 12 ? 5 : 2);
>               err = i2c_transfer(&core->i2c_adap, &msg, 1);
>               if (err != 1) {
>                       printk("dvico_fusionhdtv_hybrid_init buf %d failed (err 
> = %d)!\n", i,
> err);
>                       return;
>               }
>       }
> }

Thanks for catching this, but I think that this stuff is OK.  Thanks
for taking my section for me, BTW. :) (Seriously, please do go ahead
and adopt it.)

This code also caught my eye several days ago and I thought:
"nonfree!".  However, there are clues to the contrary.

>From what I have seen, a binary (machine code) blob is a more random
assortment of values.  Here, the table is dominated by some regular
patterns: 0x10 0x10 ... blah blah.  The second thing is that it looks
like the for loop is sending these values as *messages* to the
adapter, like a protocol (e.g., "are you ready?", "set this to that
value", etc.).  Binary blobs, on the other hand, seem to be loaded in
more of a bulk operation.  One more clue is that the blobs I have
noticed fall into one of two categories:

1.  They are associated with variables whose names contain words such
as "microcode", "firmware", "ucode".

2.  Or, they have very little if any names at all, unlike the "buf"
and "msg" we see here.

Each of these clues is not a big deal by itself, but taken together I
think that they suggest that the code is OK.

Nonetheless, we *certainly should be* on the lookout for tables like
this, and it is always good to discuss them if there are any doubts.

Now for this:

#define P1_MDATAO 0x390000

Blobs are obscure, but this is well-labelled with "P1_MDATAO",
suggesting that the programmer is clearly communicating the intent of
this data.  (That is, clear for those who know something about the
innards of cx88 type of hardware.)

Nonetheless, I am not sure, so I look at the file and see the context
around this value.  A pattern emerges in the lines that follow it:

#define P1_MDATA1 0x390001
#define P1_MDATA2 0x390002
#define P1_MDATA3 0x390003
#define P1_MADDR2 0x390004
#define P1_MADDR1 0x390005
#define P1_MADDR0 0x390006
#define P1_RDATA0 0x390008
#define P1_RDATA1 0x390009
#define P1_RDATA2 0x39000A
#define P1_RDATA3 0x39000B
#define P1_RADDR0 0x39000C
#define P1_RADDR1 0x39000D
#define P1_RRDWR  0x39000E

This does not look like random bytes that typify blobs.  Instead,
these look like labels to machine locations that the programmer is
defining for clarity and convenience.

In short, I would say that all of this code is OK, but that we
definitely need to be on the lookout for these kinds of things,
especially tables.