Series2 in PAL

[Darren King]

I know that like the post of "example3891" my post has once again been negative and unhelpful

On the contrary. It gives insight into what protection Broadcom has against such information leaking out. Hey, props to them. If you have trade secrets and are bound to secrecy by TiVo, inc then that is what they have to do. You've done quite a good job explaining rather than everyone else (and I mean everyone) who has "claimed" to know something but never produces any evidence.

Being the constructive thinker I am however it would not need the *whole* document passed onto anyone, although I can vouch for a particular name (note name as in singular) that to most here would just be "anybody" but to me is the direct person who would write the PAL module and also be a 100% secure "do not hand out this information" person. Even to that end all that would be required is the particular register(s) that need programming and nothing more. I've seen literally thousands of technical documents on chips and the table would not be something "re-written" by any document security system otherwise the chip wouldn't work as it should, would it? I'm sure other issues raised like watermarks and passwords can be circumvented simply by hand copying (as in hand writing) the relevant registers. While I am not expecting anyone within Broadcom to go off today and access the system and then hand it over tomorrow thus giving a direct lead to find out who provided the information I also highly doubt that the only copy of the relevant document in existence is locked away on a protected server. Someone, somewhere, must have the file on a local PC or a hardcopy that is gathering dust that was downloaded and/or printed YEARS ago that combined with manually copying down the relevant information would make the job of traceability almost impossible.

And besides, like Peter has mentioned, I highly doubt that TiVo would be that interested in pursuing how the information got out. We're not talking about a product that is being highly marketed anymore (they now have a Series 3) nor are we talking about the information being used to create a competing product. We're talking about utilising what is now relatively old hardware (it can't even do high def!) that a lot of units are now turning up on eBay as surplus or ending up in the trash if they are broken. In effect what is fast becoming (if not already) obsolete technology. If TiVo had a real problem with what OzTiVo is doing with their hardware they would have shut us down years ago. Why? Because even the Series 1 has the words "Private And Confidential" screen printed on the motherboard near the diagnostics connector. That never stopped people devising aftermarket add-on hardware, freely distributing hardware information on the units (of which even I am guilty of) or reverse engineering how the guide data works. All of which TiVo knows about and the only stipulation that I know of is TiVo expressly saying that it is for non-profit hobbyist use in areas a TiVo service is not provided. And at any rate like mentioned by the original poster the BCM7040 and BCM7020 is *not* a TiVo-Broadcom proprietary chipset. It has been used in other devices.

Take all of the above as you will. My intentions are not to argue or pressure anyone to do anything but merely looking at it from what is probably a very simplistic viewpoint.

Anyway, the offer still stands as it has done for years: If anyone has anything they wish to share on the information required then feel free to contact me anonymously and I'll 100% ensure your anonymity.

[inaxeon]

Perhaps you should mention how one may contact you anonymously because there may just be someone who has the right information reading this thread as we speak.

Here's another interesting thought for you - I've seen one silicon vendor (not Broadcom) have many many copies of the same registers, only disclosing the location of one set to each customer. That might sound extreme, but it really helps track down leaks :-)

Another thing I've found when working with these chips is that the vendor doesn't always give out the datasheets "Willy Nilly" usually all we get is a precompiled library with an easy to use API for performing the needed tasks on the chip and if there's any issues with that API the vendor will support that rather than giving out a register reference to fix it yourself. (Which does make me wonder, has TiVo been lazy and just used one of these libraries?) So it's not always as straight forward as getting register reference datasheets.

[Darren King]

Perhaps you should mention how one may contact you anonymously because there may just be someone who has the right information reading this thread as we speak.

My website (link is in each and every post I make in my signature) contains my email address. I am sure if one genuinely wanted to help they can find a public terminal, obtain an email address, and email me. From there I am happy to give out better ways of contacting myself. I used to publish my mobile (cell) phone number but although people could read the numbers to dial the correct number they could not read the correct numbers for the times you can and cannot contact me so I withdrew it. I do have a family and a real job so getting calls all hours into the evening is not the done thing.

Failing that one can always send me a private message on this forum.

I'm sure there are other ways people can contact me. I'm not a very private person and just reading my website can give a few more clues if one is genuinely interested in helping the cause.

Another thing I've found when working with these chips is that the vendor doesn't always give out the datasheets "Willy Nilly" usually all we get is a precompiled library with an easy to use API for performing the needed tasks on the chip and if there's any issues with that API the vendor will support that rather than giving out a register reference to fix it yourself. (Which does make me wonder, has TiVo been lazy and just used one of these libraries?) So it's not always as straight forward as getting register reference datasheets.

True. However I am assuming that there is more than simply a subset of registers or an API in the possession of "example3891" (and others) given the wording "As somebody who has access to the information you need".

However I could be wrong. Like I have said previously I've seen zero evidence of anything so therefore until someone wants to step up to the plate anyone could be telling OzTiVo any old story, including yourself with what you have already divulged about how Broadcom conducts their document control.

Cheers

[inaxeon]

However I could be wrong. Like I have said previously I've seen zero evidence of anything so therefore until someone wants to step up to the plate anyone could be telling OzTiVo any old story, including yourself with what you have already divulged about how Broadcom conducts their document control.
Cheers

That is true. I could just be making all of this up and there's no point in me trying to back up anything I've said because I don't have any useful information to start with. We'll never know until someone divulges anything useful.

[Islander]

And at any rate like mentioned by the original poster the BCM7040 and BCM7020 is *not* a TiVo-Broadcom proprietary chipset. It has been used in other devices.

Interesting reading.

I wonder if TiVo is not the only product using these devices then what are the other ones and could they provide some sort of insight into the problem.

[inaxeon]

If you found another product with that same MIPS processor running binaries compiled with a similar compiler, that product runs the chip in PAL mode and also happens to run linux then comparing binaries may provide some insight.

Although if all of the above were found then there are other approaches like trying to hook into the kernel register access stub and see what is written. for example changing the /dev/xxx (or whatever they're called on TiVo) nodes to point to your own kernel module, log them then redirect those to the appropriate Broadcom code (I'm sure all of this has been done by experienced OzTivo members before)

But then you've still got the problem where the TiVo software is quite possibly constantly trying to set the chip back into NTSC mode which totally screws that approach so the TiVo software is what needs to get modified.