Results 1 to 11 of 11

Thread: Prom patches for Series 2

  1. #1
    Join Date
    Oct 2002
    Location
    Silicon Valley, CA
    Posts
    14

    Prom patches for Series 2

    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.

  2. #2
    Join Date
    Oct 2001
    Posts
    122
    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.

  3. #3
    Join Date
    Nov 2002
    Location
    Santa Clara (SF Bay area)
    Posts
    65

    Why can't '39's flash?!?

    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. ;-)

  4. #4
    Join Date
    Jan 2002
    Posts
    1,777
    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.)

  5. #5
    Join Date
    Feb 2002
    Posts
    345

    Re: Why can't '39's flash?!?

    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

  6. #6
    Join Date
    Jan 2002
    Posts
    1,777

    Re: Re: Why can't '39's flash?!?

    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/sh...threadid=23517

  7. #7
    Join Date
    Nov 2002
    Location
    Santa Clara (SF Bay area)
    Posts
    65

    Re: Re: Re: Why can't '39's flash?!?

    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.)

  8. #8
    Join Date
    Nov 2002
    Location
    Santa Clara (SF Bay area)
    Posts
    65

    Flash 39's

    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/showth...owar+AND+flash>

  9. #9
    Join Date
    Jul 2003
    Posts
    8
    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

  10. #10
    Join Date
    Jul 2003
    Posts
    8
    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

  11. #11
    Join Date
    Jul 2003
    Posts
    8

    simple plcc32 to dip32 adapter

    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •