Where to go to get started...

[azhrei_fje]

Howdy.

I noticed in the description of this forum the phrase, "NO DTV HACKING TALK". Then I see discussion of killhdinitrd?! So I'm hoping that my question isn't taboo:

How do I go about learning about the TiVo? I've got a fair amount of EE and CompSci background (mostly CS) and I'm interested in learning everything I can about the TiVo as it relates to running Linux: the boot process, the MIPS processor, the memory model and architecture, the bus throughput, the changes TiVo made to the kernel (if any), and so on. I'm really looking for the gurus to chat with me for awhile (I'm not a Unix/Linux n00b: I've written filesystems and device drivers for both). I'll pay for the phone call. ;)

I have a couple of "home projects" in mind, but I don't know where to start. I have downloaded some of the PDFs from the http://tivoutils.sf.net/ home page, but I haven't gotten to reading them yet. I have opened up the 540 I have, but haven't looked at the chip information yet, either. All in good time...

Thanks for taking the time to read this!

[captain_video]

You can start by posting your questions in the newbie forum instead of the developer's forum. This section is for the discussion of hack development only. Check out the sticky threads at the top of the various forums and you'll find most everything you need to get you pointed in the right direction.

[fantmn]

I think the "NO DTV HACKING TALK" refers to theft of service type discussions.

I have seen a few excerpts from a book Hacking the Tivo 2nd edition by William von Hagen. http://www.amazon.com/gp/product/1592004814/sr=8-1/qid=1142449058/ref=pd_bbs_1/103-2795235-7422226?%5Fencoding=UTF8
It looks like it provides some good background information.
For "home projects" however, your time may be better spent looking at MythTV. It is an open source DVR project. If does not require subscriptions and you can do anything to the system you can conceive of. If you are interested in Tivo's a lot of the information seems to be proprietary and it seems to me that they are continually working to lock them down tighter.
Others can comment about how helpful the book I referenced is. It does not cover the most recent releases of the Tivo OS. But might make a good starting point.

From my perspective there are a lot of great folks here that will help with folks trying to learn, however this community does require that folks follow the forum's etiquette. As you read more threads here you will see what I mean.

[JJBliss]

Moved to Newbie

[azhrei_fje]

You can start by posting your questions in the newbie forum instead of the developer's forum. This section is for the discussion of hack development only.
My goal is development. But I see now that I did miss a link. In the "Newbie mini-FAQ" is a link to "Series2.5 / TCD540040 / ..." in which alldeadhomiez answers many of my questions. I will peruse that thread for the next day or so and see how much I can assimilate.

I'm sorry for the interruption; we now return you to your regularly scheduled programming. :cool:

[azhrei_fje]

My goal is development.
To that end, I'm looking to see if anyone else has done some of this research and can point me to the next step. I figured I'd document what I've done so far; maybe people who are new to Linux or the Series2.5 will gain something from this. Then my question is posed at the end of this posting.

I've grabbed the kernel out of my backup image from the TiVo (partition 3 on my 540). In trying to figure out where the initrd portion would start, I figured there must be a size field near the beginning of the image so that the PROM could give the kernel the correct start address. Sure enough, I found the beginning of the initrd image at 0x14d7a0 (the address in the header is 0x14d780, but I read somewhere on the forum that there's an extra 32 bytes now that didn't exist pre-Series2.5). That address makes sense, since the first four bytes there are 1f:8b:08:00 and that's the signature of a gzipped image.

So I used dd(1) to grab the initrd and dump the whole thing into a file (resulting size 2,828,384 bytes). I didn't know how big the initrd would be, but it didn't matter: gunzip(1) would stop when it reached the end of the compressed data stream and give me an error about extra data being ignored. That worked fine: when I ran "gunzip < initrd-from-part3 > initrd" I got a file that was 737,280 bytes. Running file(1) on the result tells me:initrd.romfs: romfs filesystem, version 1 737264 bytes, named rom 435806a1.
I'm thinking that the "name" must refer to the version of the PROM that this image is meant for. Probably an internal code that the company uses to refer to the PROM uniquely, perhaps a checksum or signature of some type.

Anyway, I now have a copy of the initrd that I can look at. I mounted it using the loopback device and I can see the files inside it ("mount -o loop initrd.romfs /mnt/initrd"). The two important ones are linuxrc since that's the startup code, and signatures (that's the one I'm looking at now).

Can anyone here tell me the format of the signatures file? I've reproduced the first few lines from the version I have:000094791DF2D794E63D7C5FAD1FF6746EA8F850 0x14138.tvbin
0019F5451381E655C09AD5FBE7FACBDD4446BC09 /etc/rc.d/StageC_MediaInitialization/rc.Sequence_200.DefineLoadInput.Platform_unknown.Implementation_Series2.sh
001C931A4A3E32E55126AF65B4CD233E3F8E3440 elmoreadsectors
002DEB3F1BBD142ADB62B8DCA6D01549A49DCB94 0x140b2.tvbin
006347D8905B4B542EE7057AB19545DD5F43EDC5 0x29b38.tvbin
006C6DA07F04D274073C743BDDF444907D331F82 TvPpvStatus.h
00738E820C400F18517821779044D5865EAAE7A4 0x2cec.tvbin
0073B9AA5B8ACA33D1FBF426A0313EC9F0517094 PhoneConfig.schema
00819F554004415BA55BB4100EF84735E866FA46 0x29ba7.tvbin
009024AE0FE133F43332BEE26E7ADCB413B2E0B6 TvCommonStatus.h
Basically, I'd like to find out what the ".tvbin" entries represent. Obviously, the other ones are filenames. It's also interesting how the ones below /etc/rc.d use absolute pathnames but others don't. Sorting the file on field 2 shows some interesting patterns at the beginning, but then the pattern deteriorates.

If I need to, I'll install the MIPS tools and run a disassembler on linuxrc, but that binary is 500K+ and I'd rather not reinvent the wheel if someone else has already deciphered this.

Thanks for any help!