YES YOU CAN SOFTWARE FLASH 39's!

[mrblack51]

I think I located the correct chip - mine says:

CBOM
00008-
000
LOC v34
Rev 1.0

Does anyone know if this is the right chip (it seems to have 32 leads out) and what version it might be?

um, thats the sticker dude. yes, thats the right chip, but the chip identification stuff is under the sticker

[dethpulse]

DOH - I uncovered the chip and found....

I have a 37 . BOOO!!

[bcc]

I made a couple tweaks to homieflash, so that one can dump out the flash contents (like getprom -dump used to provide). I also changed it so that, as suggested, it raises its priority before doing a flash write.

Also I found that older intel etherexpress pro PCI cards have PLCC sockets that can be used to program SST flash blanks. (The 82557 models have the socket, the 82559 models don't). According to intel's web page this includes the SST39VF010, but I haven't tried it, tho I have the card. Someone already wrote the burning program: ftp://scyld.com/pub/diag/eepro100-diag.c. For me this looks like a cheap way to re-do any flash changes should it become necessary. I'm not a EE-type so I don't have any real flash programmers laying around.

Hope this info is useful.

[DarkHelmet]

Also I found that older intel etherexpress pro PCI cards have PLCC sockets that can be used to program SST flash blanks. (The 82557 models have the socket, the 82559 models don't). According to intel's web page this includes the SST39VF010, but I haven't tried it, tho I have the card. Someone already wrote the burning program: ftp://scyld.com/pub/diag/eepro100-diag.c.

Hope this info is useful.

Well, almost... there's one problem with that file:

/*
  Reading and programming the EEPro100 flash requires a kernel extension
  that allocates a memory region and mmaps the PCI boot ROM space.
  The current (mid-2002) code that does this only works on a few kernel
  versions, and thus is not enabled by default.
*/
...
int flash_pci_rom_program(long ioaddr, long data, const char *filename)
{
        printf("Flash operations not configured into this program.\n");
        return -1;
}

Oh well. I wonder if the intel flash program can be co-oerced into putting an 'alien' rom image on it?

[bcc]

Doh! I was thinking the code at read_eeprom()/write_eeprom() was doing the work.

[farlz]

I found this: http://www.han.de/~gero/netboot/archive/msg00383.html

Which references this utility from Intel: http://ftp.iasi.rdsnet.ro/drivers/ni...pters/ef32.exe

Maybe you can use the Intel 82557 card as a programmer?

[speter]

I was thinking about using the flash program for my abit motherboard by
swapping the prom chip after it is booted I read somewhere it is the same chip
as the abit be6 socketed prom


checked it out.the chip isn't the same,5 volt vs 3.9

[bcc]

Reading and programming the EEPro100 flash requires a kernel extension that allocates a memory region and mmaps the PCI boot ROM space.

Actually I finally tried it, and this wasn't true. I've found that SST39s can indeed be flashed in plcc sockets of eepro100 cards, on unpatched linux hosts, with 1 tweak to my version of homieflash.
Just change the FLASH_START constant to use the flash memory address reported by lspci -v. Then homieflash can read, erase, write and report the ID of SST39 flash chips. I tried to read an SST37 as well, but my eepro100 doesn't seem to accept it, unfortunately.

[AlphaWolf]

I am assuming you can still use getprom to properly flash a hot-swapped SST39 with a hacked image in an S2 dtivo with the newer 6.x software correct?

[bcc]

Last time I did on-tivo flashing I used homieflash, not getprom. I don't think I'd trust getprom, as tivo last used it some time around 2000 on s1 systems I believe.

BTW, there's a newer homieflash thread here:
http://dealdatabase.com/forum/showthread.php?t=60293

[AlphaWolf]

Is there a mips binary of homieflash anywhere then? (didn't find one in that thread) And with that, any one that has been tested to work on a s2 dtivo?

EDIT: Just successfully flashed an SST39 using the hot swap method with getprom. Took me about 10 minutes to try to find where the hash was stored (even decompressed the gz image by cutting it out by hand in a hex editor) only to later happen to notice just by sheer luck (familiar looking ascii string caught my eye) that it was big endian byte flipped (yet nothing else seems byte flipped?) right near the beginning of the image.

Anyways now to socket my Tivo HD tomorrow and try this out. Crossing my fingers that I don't ruin it. Have yet to lift a pad during prom extraction, and done it 5 times so far without ever leaving a single scorch mark. (Though I did lift a pad once while foolishly trying to use a solder pump to remove solder on an S1 I was practicing on, and this was after I had already cleaned it once, just accidentally got more on it while installing the socket...NEVER USE A SOLDER PUMP ON SMC COMPONENTS, SOLDER WICK IS YOUR FRIEND )

My long blabbering aside, I would like to know where a mips compiled homieflash binary is, I can't find it anywhere and I've still yet to get a cross compiler up in my new setup.

[bcc]

Is there a mips binary of homieflash anywhere then? (didn't find one in that thread) And with that, any one that has been tested to work on a s2 dtivo?

There are several posted in this very thread, scroll up about 6 posts

[AlphaWolf]

None of them seem to run on my tivo. Oh well its no big deal, programming them with getprom seems to have worked fine, just had to fix the hash and it was good to go.

[healeydave]

There are several posted in this very thread, scroll up about 6 posts

None of them seem to run on my tivo. Oh well its no big deal, programming them with getprom seems to have worked fine, just had to fix the hash and it was good to go.

I know this is dragging up an old thread, but I too haven't been able to find a version of homieflash that will run on an old S1 TiVo.
I want to use the old S1 Tivo to program some S3 PROM's.
I made adjustments to getprom to skip the "Bad Magic Number" and "Bad Reset Vector" errors as suggested by alldeadhomiez in another thread.
This seemed to work fine and getprom proceeded to erase and flash the chip fine.
It does balk at the end when it tries to report the version number, but I figured that would be ok.

The only problem I have is when I dump the prom back out and compare it to the original in a hex editor, the first 304 bytes are different, the rest is a perfect match to the original.
I'm nearly there, I just don't know why the first bytes are being corrupted by getprom.