Page 1 of 2

Intel 28F001BX/BN-T/12V - Cannot write last 2 blocks

Posted: Sat Apr 15, 2006 11:20 am
by JT
Hi guys,

Need some advice here. I have a SanLi SP-P2BXA motherboard that I would like to upgrade the BIOS in (with modified BIOS to support more CPUs and up to 128GB hard drives, right now it cannot support >32GB). The flash chip is an Intel 28F001BX/BN-T/12V according to UniFlash.

When I use Awdflash and UniFlash version 1.40, the programming fails on the last 2 blocks. I believe one of the Awdflash utilities I tried had said that the Boot Block protect was on.

The jumper on the motherboard is set to 12V and using a voltimeter, the Vpp pin has 12V. Is there another pin that needs to have power to unprotect the Boot Block or whatever the last 2 blocks of programming?

Posted: Sat Apr 15, 2006 1:41 pm
by Denniss
AFAIK there to be a special pin either grounded or supplied with 12V to remove protection. Most board supporting this Flashrom have a jumper to unblock
AFAIR boards have to suport this flashrom or it won't be able to reflash it.

Posted: Sun Apr 16, 2006 6:32 am
by JT
Does anyone know what that special pin is? The motherboard I'm using now only has jumpers to change the Flashrom programming voltage and does not have any undocumented jumper settings.

Putting 12v on any pin is not a problem for me, but I need to know which one, otherwise the flash chip will go up in smoke :?

Posted: Sun Apr 16, 2006 9:45 pm
by Denniss
Did this board have this flashrom from start or is it a replacement chip ?

Is there a Bios protection option within Bios ?

Does Award show flash fail (AFAIK red blocks) or only not updated (AFAIK blue blocks)

Posted: Sun Apr 16, 2006 10:03 pm
by JT
This is the original flash chip that came with the motherboard, it is not a replacement.

The Bios does not have a protection option that is available.

UniFlash and Award flasher fail for the last blocks. Award flasher shows 2 red blocks at the end of flash and UniFlash shows 2 X's.

Posted: Sun Apr 16, 2006 10:21 pm
by cp
from the intel datasheet:
"RP# = VHH allows programming of the boot block."

RP# is pin 30 on the DIP version.
VHH is 11.4-12.6 V

happy hacking :)

Posted: Mon Apr 17, 2006 10:31 am
by JT
Thanks for all your help guys!

I just tried it. I ran a wire from and old molex fan connector and carefully wrapped it around pin 30 after I pulled out the flash chip. Then I isolated the pin from the socket, reinserted it, but just let it sit on the socket.

Had a few problems booting the system, but eventually it came to life again and I plugged in the fan connector and held my breath. The chip didn't melt so I ran UniFlash and started flashing my modified Bios. When it got to the last two blocks, it programmed them and the blocks were green and UniFlash reported a successful flash!! :D

Turned the system off and reinserted the flash chip, turned it on, still survived. Now my Coppermine CPU detects properly and I can have drives up to 128GB!

Posted: Mon Apr 17, 2006 12:35 pm
by cp
congrats :)

i guess this is the way they do apply a bootblock write protection on other boards, too. on those boards the jumper serves the same purpose: applying +12v to RP# (aka pin 30).
case closed i guess

Posted: Sat Apr 22, 2006 5:17 pm
by KenH
Hey, i'm not sure if it applies here,, but would running uniflash with the
-unlock command, eg: "uniflash -unlock" have been the way around
this boot block lock problem..?
Iv'e had chips in the past where the last 2 blocks wouldn't write until
I unlocked them 1st...

Damn I love uniflash,, it's the next best program to have along
with the Willem Programmer I bought off ebay..

Everytime I use uniflash I say to myself, I must donate something to
whoever wrote it one day...

Posted: Tue Apr 25, 2006 1:04 pm
by NickS
KenOath wrote:Hey, i'm not sure if it applies here,, but would running uniflash with the
-unlock command, eg: "uniflash -unlock" have been the way around
this boot block lock problem..?
Iv'e had chips in the past where the last 2 blocks wouldn't write until
I unlocked them 1st...

Damn I love uniflash,, it's the next best program to have along
with the Willem Programmer I bought off ebay..

Everytime I use uniflash I say to myself, I must donate something to
whoever wrote it one day...
Rainbow wrote:added -UNLOCK parameter to unlock bootblocks on some chips (like Winbond W29C020)
... normally
a sequence of writes of data to specific locations to unlock. I don't think that would help where it needs 12v to unlock.

Posted: Fri Apr 28, 2006 6:20 am
by JT
I did try the -unlock switch with UniFlash, but it made no difference, the flash chip needed 12v to disable the protection.

Posted: Fri Apr 28, 2006 10:14 pm
by Denniss
Yep, this Intel Flashropm has some kind of hardwqre protection. It needs the 12V to unlock.
I also have several boards unable to completely flash these Intel flashroms, that's why I still have my old Asus P2L97.

Posted: Sat Apr 29, 2006 11:39 am
by cp
actually there IS another way (besides the VHH->RP#) to unlock the bootblock. i'll have a look at the datasheet again if i'm back @ my machine. anyways i don't have a clue yet what this -unlock option is all about..i'd better have a look at the sourcecode of uniflash.

just for your information: the VHH->RP# on the Intel 28F001BX/BN-T works on any mainboard. you can even set RP# to VHH permanently disabling the lock always and forever.

Posted: Sat Apr 29, 2006 3:05 pm
by Denniss
The -Unlock is to unprotect Flashroms that have a software protection. AFAIK this is a special routine to disable such kind of software protection.

Posted: Sun Apr 30, 2006 1:44 pm
by cp
"For PROM programming equipment that cannot bring RP# to high voltage, OE# provides an alternate boot block access mechanism. OE# must transition to VHH a minimum of 480 ns before the initial program/erase setup command and held at VHH at least 480 ns after program or erase confirm commands are issued to the device. After this interval, OE# can return to normal TTL levels." (Intel 1-MBIT (128K x 8) BOOT BLOCK FLASH MEMORY 28F001BX-T/28F001BX-B/28F001BN-T/28F001BN-B datasheet)

i suggest to use the RP# method anyways.