PDA

View Full Version : Prom patches for Series 2



doc_u
11-03-2002, 01:55 PM
Posted by MuscleNerd over at AVS forums...

11-01-2002 @ 10:19 AM

Here's a PROM patch for S2 for those of you with access to a burner. The patch will allow you to boot any kernel, whether it's signed correctly or not.

Somewhere within your TiVoProm.bin image, you should see the following instruction word:

0x1043000c

You want to change that 0x43 to a 0x42. Just that one byte change is all you need...it changes a conditional branch to an unconditional one. This essentially discards the results of the signature checking routine.

The above 4-byte word will probably appear as 0x43100c00 in the image file itself (endian issues). I've only hand-verified the patch on 1.15 and 1.18 images (1.18 came out with version 3.2 of the software. 1.15 was posted on this board but it wasn't completely there). In 1.18, the file offset of the byte to change is 0x2b40.

Edit: And no I don't have an S2 box yet, so I haven't completely verified this. But I will when I do.

Last edited by MuscleNerd on 11-01-2002 at 10:29 AM


11-03-2002 @ 12:56 AM
As it turns out, before the boot code even verifies the kernel signature, it verifies itself. It computes the sha1 hash of its own in-memory image (after a certain offset) and compares the result to one stored in its own image (before that certain offset). So in addition to patching over the signature checking results as I showed 2 posts back, you have to patch over this too.

This second patch also consists of a single byte change. Somewhere in your 1.15 or 1.18 image you should find the following instruction word:
0x14830004
You want to change that 0x83 byte to 0x84. This word will probably appear as 0x83140400 in the .bin image file itself.

yngdiego
11-19-2002, 12:29 AM
What is the easiest way to implement this hack? I'm an engineer, so I'm a technical person. But I'm not up for desoldering and resoldering a flash chip.

geowar
05-22-2003, 12:43 PM
According to the spec sheet (.pdf) on this part we should be able to flash it. Since we can't I initially assumed that TiVo just disabled (or disconnected) the write-enable (WE#) signal to the flash part. Just to be sure I pulled out my o'scope and took a look at WE#. Looked like it was changing so it wasn't just a simple disconnect. So maybe it was just never getting genereted at the same time as the chip select (CE#). Back to the scope and... Nope; that wasn't it. There are times when both are low. (I wrote a test program that repeatly tries to write to the flash for one second and then delays for one second and then loops.) Ok, if they're both low then why isn't it accepting writes? Reading thru the spec sheet again I noticed that a writing sequence can be aborted by any read access that happens before the write sequence finishes. So back to the scope.

Long story short, (too late) what I discovered suprised me; There weren't any unexpected reads BUT there were times when WE# AND output enable (OE#) were both low. And according to the specs this will disable the write.

So now the question is: "Why is the TiVo generating OE# when it's trying to write?!?

Tracing the OE# around I find that it only goes to the Modem chip and the TiVo "Mediaswitch" ASIC (I'm guessing that it's generated there).

So what I want to do next is figure out a way to disable the flash's OE#while WE# is low. I'll disconnect (dike) it from the motherboard trace and qualify it (inverted) thru a NAND gate:

OE# WE# `OE#
L L H Write (fixed!)
L H L Read
H L H Write
H H H no access

I'll just double-sticky-tape a 74'00 "legs up" on top of the flash and make the connections with wire-wrap wire.

This seems MUCH simpler than de-soldering the flash and then re-soldering it PLUS it will allow me to re-flash the ROM anytime I want. ;-)

alldeadhomiez
05-22-2003, 07:42 PM
Hey, since you have a scope, maybe you can help me out here. Do you know approximately how long each access to ROM takes during the startup sequence? I'm wondering how feasible it might be to rig a commodity microcontroller to watch for patterns on a few (1-3) data lines, and use that to predict the correct time to pull one or more of them low. (This would essentially be an implementation of the "modchip" that was previously discussed.)

cali
05-23-2003, 12:54 AM
Originally posted by geowar
According to the spec sheet (.pdf) on this part we should be able to flash it. Since we can't I initially assumed that TiVo just disabled (or disconnected) the write-enable (WE#) signal to the flash part. Just to be sure I pulled out my o'scope and took a look at WE#. Looked like it was changing so it wasn't just a simple disconnect. So maybe it was just never getting genereted at the same time as the chip select (CE#). Back to the scope and... Nope; that wasn't it. There are times when both are low. (I wrote a test program that repeatly tries to write to the flash for one second and then delays for one second and then loops.) Ok, if they're both low then why isn't it accepting writes? Reading thru the spec sheet again I noticed that a writing sequence can be aborted by any read access that happens before the write sequence finishes. So back to the scope.

Long story short, (too late) what I discovered suprised me; There weren't any unexpected reads BUT there were times when WE# AND output enable (OE#) were both low. And according to the specs this will disable the write.

So now the question is: "Why is the TiVo generating OE# when it's trying to write?!?

Tracing the OE# around I find that it only goes to the Modem chip and the TiVo "Mediaswitch" ASIC (I'm guessing that it's generated there).

So what I want to do next is figure out a way to disable the flash's OE#while WE# is low. I'll disconnect (dike) it from the motherboard trace and qualify it (inverted) thru a NAND gate:

OE# WE# `OE#
L L H Write (fixed!)
L H L Read
H L H Write
H H H no access

I'll just double-sticky-tape a 74'00 "legs up" on top of the flash and make the connections with wire-wrap wire.

This seems MUCH simpler than de-soldering the flash and then re-soldering it PLUS it will allow me to re-flash the ROM anytime I want. ;-)
Got a schematic all done up ?
I'm interested in doing this, but with me time is hard to find.
heck I am just getting around to setting up my turbo net which I have had for months :)

alldeadhomiez
05-23-2003, 01:28 AM
Originally posted by cali
Got a schematic all done up ?
I'm interested in doing this, but with me time is hard to find.
heck I am just getting around to setting up my turbo net which I have had for months :)

Do "we" even have software to do the flashing?

http://www.dealdatabase.com/forum/showthread.php?s=&threadid=23517

geowar
05-23-2003, 12:28 PM
Originally posted by alldeadhomiez
Do "we" even have software to do the flashing?


I believe that the existing flashing program will also flash the '39. The '39's software protocall is the same for the flash in the series 1 TiVo's. (The problem is in the series 2 hardware that generates the write enable signal to the flash.)

But just in case I'm wrong (about the old program supporting the '39's) I do have working source for a (series 2) program that will test & flash the '39's. PM me (at <geowar@apple.com> your email if you want it. (Little too big to paste here.)

geowar
06-20-2003, 01:43 PM
I couldn't find this thread to update my flashing experences (don't go there!) so I started a new thread. (URL below)

I determined that the mips processor was write combining which prevents the flash from seeing all the necessary writes used by the protocal sequence to put it into flash mode. Adding lines to flush the cache after each write I managed to get past this and I can flash some pages but not others. It appears that any attempt to flash addresses between 0 & 0x13000 will reboot the TiVo.

All this info (and some source code) is in my other thread at: <http://dealdatabase.com/forum/showthread.php?s=&threadid=25116&highlight=geowar+AND+flash>

egghead
07-12-2003, 10:08 PM
regaurding musclenerds post;

i have a hdvr2, and dumped the prom, a 37vf010, and could not find the hex string called out:
1st) 43100c00
or the
2nd) 83140400

i think i got a good dump, im using a needhams 11 programmer to get the dump, using a plcc adapter i made, btw if anyone needs a gerber of the simple adpter brd, il be glad to send it to you. the offset 2b40 contains:
3C12AC5300008821000080218D020000

so im confusid on what to do, i will appreciate any help. thanks

egghead
07-14-2003, 01:55 AM
Well i figured it out, it was user head gap. Didnt clean the adpter/plcc part well enough. the dump was exactly a stated by musclenerd. thanks musclenerd for your great contributions :)

egghead
10-08-2003, 08:26 PM
i used this to interface to me needhams programer. worked great just select the dip version of the 37vf010 and ignore the product code warning. hope this help :) i included a post script file and a gerber file.