Successful hack to intel pro100/homieflash to flash >64K

[crust]

The intel pro100 (the one I used is based on the 82558 rev B) can't flash more than 64K. It can detect and their utilities will use flashes larger than that, but the part itself uses a muxed address and data bus and only brings out 16 bits total.

I saw some posts that led me to believe it could be done with said adapter out of the box, but after I looked at the data sheet, there is no way it is possible.

So from the controller to the flash you have A15:A0, there isn't any control of A16 so the flash programming is limited to 64K.

The particular flash I used is the SST 39VF010. homieflash works with CFI flashes and that is important for this hack to work.

After a couple of minutes of pondering, I decided it would be straight forward to attach a button to toggle A16 assertion / deassertion. I suspected that A16 was probably strapped on the PCB somewhere. I found that Intel graciously tied it low with a 1K resistor. That made the job even easier.

A bit about CFI flashes -- you issue them commands with an odd pattern of data and address patterns to get them to do your bidding. For instance, something like writing 555 to address AAA and then reversing it gives the first byte of an n-byte command. I thought that the strapping of A16 via my hack would send that into the weeds. However, it turns out that the high order address lines are dont cares when issuing CFI commands so there is no reason it shouldn't work.

I probed the board for a few minutes and found a place to tie a wire to Vdd (one of the bulk caps for the controller) and took that wire to a switch, from the other pole of the switch I went to the resistor. So when the switch is on, it applies vdd directly to A16 (would have been better to put a resistor, but I didn't have a low enough value in a usable size). When it is off, the 1K pull down deasserts A16. I just tacked a tiny toggle switch to the PCB with some hot glue.

Next I needed to modify homieflash ... basically I needed to change the code to pause after 64K are written / read and tell me to assert or deassert A16.

Booted my live ubuntu and successfully, programmed, verified, and then dumped the file to compare to my source binary. You have to flip the switch 4 or so times during the entire cycle so it is not difficult or tedious to do.

All told it took about 1/2 hour from start to finish.

Cheers ...

[crust]

Here is a patch for homieflash 1.6 ...
Gives you the prompts to tinker with A16 -- not the cleanest code, but it works. I did try not to break the existing code, but I have no way of testing it. There is a patch file attached.

--- a/homieflash.c 2010-08-04 21:55:11.000000000 -0500
+++ b//homieflash.c 2010-08-04 21:55:17.000000000 -0500
@@ -97,6 +97,7 @@
*/
extern int errno; /* System error code */
off_t flash_start = FLASH_START;
+uint8_t lim64k = 0; /* true if we are limited to prog 64k at a time */

void
fatal(char *fmt, ...)
@@ -318,6 +319,19 @@
}

static void
+check_limit(const uint32_t index)
+{
+ // just skip all this if we don't have the a16 limitation
+ if (!lim64k) return;
+
+ if ( (1<<16) == index )
+ {
+ printf("assert A16 and then press enter\n");
+ getchar();
+ }
+}
+
+static void
flash_write(volatile uint8_t *flash, size_t flash_mem_size, u_char flags,
uint8_t *newflash)
{
@@ -341,6 +355,10 @@
}
printf("programming...\n");
for (c = 0; c < flash_mem_size; c++) {
+
+ check_limit(c);
+
+
if (flags & FLASH_FLAG_INTEL) {
intel_writebyte(flash, c, newflash[c]);
} else {
@@ -351,8 +369,19 @@
/* Switch back to read mode */
flash[COMMAND1_ADDR] = 0x00;
}
+
+
+ if (lim64k)
+ {
+ printf("deassert A16 and then press enter\n");
+ getchar();
+ }
+
printf("verifying...\n");
for (c = 0; c < flash_mem_size; c++) {
+
+ check_limit(c);
+
if (flash[c] == newflash[c]) {
continue;
}
@@ -378,7 +407,7 @@
flash_mem_size = FLASH_SIZE;
dump = dowrite = 0;
filename = NULL;
- while ((ch = getopt(argc, argv, "f:d:w:")) != EOF) {
+ while ((ch = getopt(argc, argv, "f:d:w:g")) != EOF) {
switch (ch) {
case 'f':
if (sscanf(optarg, "%x", &addr) == EOF) {
@@ -398,6 +427,9 @@
filename = optarg;
dowrite = 1;
break;
+ case 'g':
+ lim64k = 1;
+ break;
default:
badarg(argv[0]);
}
@@ -424,23 +456,44 @@
if (newflash == NULL) {
fatal("can't malloc flash buffer");
}
+
+
if (dump) {
printf("Dumping flash contents to %s...\n", filename);
ofd = creat(filename, 0666);
if (ofd == -1) {
fatal("Cannot open output file %s", filename);
}
+
+
/* Read flash to memory, to be extra cautious */
- memcpy(newflash, flash, flash_mem_size);
+ if (lim64k)
+ {
+ printf("deassert A16 press enter to continue\n"); getchar();
+ memcpy(newflash, flash, (1<<16));
+ printf("assert A16 press enter to continue\n"); getchar();
+ memcpy(newflash + (1<<16), flash+(1<<16), (1<<16));
+ }
+ else
+ {
+ memcpy(newflash, flash, flash_mem_size);
+ }
if (write(ofd, newflash, flash_mem_size) != flash_mem_size) {
fatal("error writing %s", filename);
}
+
+
close(ofd);
printf("Saving to %s complete\n", filename);
} else if (dowrite) {
if (readfile(filename, newflash, flash_mem_size)) {
fatal("error reading %s", filename);
}
+ if (lim64k)
+ {
+ printf("deassert A16 press enter to continue\n"); getchar();
+ }
+
flash_write(flash, flash_mem_size, flash_ent->flags, newflash);
}

[crust]

This is an intel 82558B Pro/100+ adapter (as far as I can tell). I'd suspect they have multiple PCB revisions, but they are probably similar. I just probed around from A16 to find the resistor to ground.

Here is the board as it looks after the modification is done. You should probably mount the switch on the front so that it does not interfere with another board in the chassis. I put my switch as close to the front as possible so it was easy to reach.



This shows where the resistor that pulls A16 to ground is located. It is in an r-pack so you have to be careful not to bridge them (hence the use of the pad on the back of the board). Also note that the value is 1K. So if you want to pull the signal up with a resistor (to be safe), it would have to be fairly strong, no more than a few hundred ohms. I just tied it directly, but that is not the safest way to do it. If yours isn't the same you can ring out the location of A16 to the resistors around it. You can also ring it out to ground but I'm mostly certain that you will find a resistor of some type in there.



The next picture is the location on the back for the solder pad. You can also just ring this out to A16 on the PLCC part. The wire I use is the Kynar type, but anything should work.



This last picture shows how everything goes together. Basically you take the wire from the A16 net and wire it to one pole of the switch. Take a wire from Vdd to the other pole. Many of the large bulk caps around the controller will be between vdd and ground so it is pretty easy to tack a wire onto one of them.

I hotglued my switch and put a drop of hot glue to tame the wires -- I could not find the kapton tape anyway, the only other thing is just to know which way the switch is asserted and deasserted and you will be good to go.

[bcc]

Impressive that you were able to patch a card that apparently couldn't handle flash >64K. I don't think most users would be able to reproduce your work in 1/2 hour
Strange that your particular version of the card has that problem as the older full height 82557 card can write 128K no problem.

I know I've also mentioned this before as well, but one can use an existing socketed tivo to flash new sst39 chips. For example I've used hr10-250s to flash tivo series 3 bootroms. Just hotswap the proms and use homieflash on the tivo itself. If someone is making new proms, good chance they, or someone they know, already has an existing socketed tivo kicking around to work with.

[dcbarry]

I also had the boundary issue at the time. I ended up going with omicrons chips, so I've got about 5 unused proms here now.

Off hand, do you know if the tivo HDs can flash?

[bcc]

I also had the boundary issue at the time. I ended up going with omicrons chips, so I've got about 5 unused proms here now.

Off hand, do you know if the tivo HDs can flash?

I can't remember if I did any writing on my s3, but I believe it works; reading certainly does. I don't have an HD to test against so I can't say for certain for that model anyways.

[crust]

Yes, it is odd that the 82557 could program larger parts. Despite the 82558 and 82559 being supersets of the 82557, there were some changes. The 82558 was the "weakling" in terms of flash programming. I found the data in the 82558 data sheet, but a good comparison is here: http://download.intel.com/design/net...5X_OpenSDM.pdf

I didn't have another hacked tivo to use and I don't have a PLCC adapter for my programmer. I use the abatron most often now. So I was left with the choice of getting a PLCC adapter, an intel card, or using my motherboard prom socket. At less than $5 shipped, the intel card won out. But admittedly I didn't expect it to not work.

So I think if you can find an 82559 or 82557 board, those will work. However out of the box the 82558 boards certainly do not work.

@dcbarry, does your PCB look like the ones in my pictures?

[bcc]

So I think if you can find an 82559 or 82557 board, those will work. However out of the box the 82558 boards certainly do not work.

Hmm, p. 6-7 of that doc imply that only the 82558 has a 64k limit.

I have an 82559 as well, but on that one, the flash chip is soldered on without a socket.

Ah well, it's all pretty obsolete hardware at this point.

[crust]

Yes, the 82XXX cards are pretty much obsolete ... of course for the most part so are PLCC parts. For reference, I don't know which cards Pro100/B pro100+ etc have which controllers. I assume there is a chart somewhere, but I could not find it.