Mailing List archive

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

[linux-dvb] Re: Kernel OOPS



From: "Ralph Metzler" <rjkm@metzlerbros.de>
> Robert Schlabbach writes:
>  > the only type of CAM I can afford for development purposes (ZetaCAM,
>  > Free-X TV, IceCrypt) all happen to be incompatible with TechnoTrend's
>  > Budget-CI
>
> AFAIK, these are problems with the power supply for the CI
> module. They supposedly draw more power than usual cards. I don't know
> if they are actually outside the allowed range according to the CI specs.
> Older versions of the KNC card CI interfaces also had problems with
> those cards. The symptoms I have are that the card does not react to
> setting the configuration register (the one indicated in the CIS) and
> thus access to the IO ports does not work.

Aha, that's interesting! My symptoms are a bit different, though: Access to
the attribute memory and to the COR is fine, and the CAM _does_ correctly
map its I/O registers when I write the configuration value to it (0x0F).
CAM reset via the COR also works.

What doesn't work, though, it access to the I/O registers. I can read them
fine, but I cannot reset the I/O interface through the command/status
register (the status remains at 0x00, although it should go to 0x40 [FR]
after some time). When I skip resetting the I/O interface and start with
reading the CAM's buffer size by writing 0x04 to command/status, the LS/MS
registers correctly indicate a size of 2, but the data I read from the DATA
register is erroneous, and the command/status registers does not behave
like it should (it goes to 0x01 after the first read, but not back to 0x00
after the second read, but rather remains at 0x01 for about 240 read
operations). The erroneous data read appears to match the attribute memory
contents.

The response I got from TechnoTrend was that the CAM's I/O timings must be
incorrect somehow, and that they might have to use a different PLD
programming to fix this.

However, your suggestion about the power supply actually sounds more
plausible to me. After all, I'm quite sure that there is some standard
PCCard interface chip in that CAM, and why should that use incompatible
timings?

Do you think it is possible that the misbehavior I have observed could be
due to the CAM not getting enough power?

Also, do you know which pins of the CAM are not getting enough power? Maybe
I should look into a little "hardware hack" and solder an extra wire onto
the card to supply more current to a specific pin...?

Regards,
--
Robert Schlabbach
e-mail: robert_s@gmx.net
Berlin, Germany



-- 
Info:
To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe linux-dvb" as subject.



Home | Main Index | Thread Index