Robert Schlabbach writes: > 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
That also works fine for me. > map its I/O registers when I write the configuration value to it (0x0F). > CAM reset via the COR also works. This does not work for me. The value is not written (stays the same as before writing) and I/O registers are all 0xff. Other modules (Viaccess, Cryptoworks, Alphacrypt) work fine at this point. Only Icecrypt, Magic and their clone modules make problems. > 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? Well, the TT CI card does not use a standard chip like CIMAX (I guess for cost reasons). So, maybe they did something wrong with timing. The same might be true for those cheaper CI-CAMs. The KNC card also uses its own interface hardware. > 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...? Sorry, no idea. I also cannot say for 100% that the power supply explanation is correct. That's only what I heard indirectly. Maybe there really is more to it. Hmm, I did not test the Twinhan card with those modules yet. Let's see how it reacts ... Ralph -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
