Ron Krebs wrote:
> "Paul" <> wrote in message news:fbbosj$9j0$...
>> Steven Stone wrote:
>>> In article <Vq4Ci.29196$>,
>>> says...
>>> |Let's try a different approach. What is the problem with the serial
>>> port?
>>> |
>>> |
>>>
>>> I use the serial port to load programming to Ham radios and police
>>> scanners. The software used does not like USB serial port dongles. Has to
>>> be a real serial port.The serial port worked fine when I first powered up
>>> the motherboard. Shortly after the BIOS update the software refused to
>>> talk to the radios, saying it could not find anything attached to the
>>> port.. but the port exists in device manager. I tried different cables,
>>> connectors, and devices (old external modem, etc) and Hyperterm, setting
>>> port speeds in device manager, etc... still refuses to acknowledge
>>> anything is connected. Don't see anything obvious.. unless the heating /
>>> cooling cycles on the motherboard stressed a bad solder joint ???
>>>
>>> Steve
>> The latest "downgrading" recipe is here.
>>
>> http://groups.google.ca/group/alt.co...5?dmode=source
>>
>> Note that the method suggested, is only "safe" if the BIOS tool you
>> are interrupting in mid-flight, is *NOT* programming the boot block.
>> If the boot block is being programmed at the time, the motherboard
>> will no longer be able to POST. The desired effect, is to interrupt
>> the programming of the "Main BIOS" block, while leaving the "Boot
>> Block" intact. Then, the next time the computer POSTs, the Boot Block
>> code will checksum the Main BIOS block and find a checksum failure.
>> Then the CrashFree 3 module (described in the BIOS section of your
>> manual) takes over.
>>
>> Put a copy of P5KC.ROM or whatever the sample file name is that is
>> listed in the manual, on a CD at the root level (like it is on the
>> motherboard CD), or use a USB flash. CrashFree 3 will then read the
>> file and update the Main BIOS code, using the "downgraded" file you
>> provided.
>>
>> Is it dangerous ? Why, of course :-) Even if you get all the details
>> right, you might find yourself sending $25 to badflash.com for a
>> replacement programmed BIOS chip and socket extraction tool.
>>
>> Just for fun, you could ask Asus Tech Support for their latest
>> advice. Maybe they don't even know that downgrading is broken.
>> Normally, they'd tell you to "tick a box" on the Windows version
>> of the flasher, but that likely no longer works. Ask them if
>> they've tested it lately...
>>
>> HTH,
>> Paul
>
> That was my post you referenced. All is working well on this end after that
> procedure. I halted the programming AFTER the ROM was erased and midway
> through the subsequent programming's progress meter. There was no indication
> as to whether this was during the BIOS block OR Boot block. Actually, I
> don't believe there is anything to worry about as others have used this
> method successfully and I have yet to read where this hasn't worked or has
> rendered the BIOS chip or motherboard useless. In any event, if the current
> BIOS isnot working properly, what good is the board anyway then?
>
> Ron
>
>
I just want to point out, that the recovery mechanism relies on code in the
Boot Block. In the past, Asus, in their infinite wisdom, erase the whole
chip first, program boot block, program main BIOS etc., when the boot block
is requested to be updated. If you turn off the power, just after the whole
chip is erased, you'd be dead.
Some BIOS releases are bundled with a special version of the flashing tool
for example (contains a wrapper, with a command line option to erase the
boot block). Since the Asus track record on needing to do Boot Block updates
is so bad, I had to point out the possibility that for certain BIOS releases,
the Boot Block will be erased as part of the sequence. Thus, interrupting the
flashing sequence, by turning off the power, leaves you toasted.
I'm not saying there is anything wrong with your method. It is genius. Just
that if I was using it on my own motherboard, I'd need to convince myself that
Asus was not doing anything with the boot block when that flash proceeds. It
is possible the messages on the screen, might hint at what they are doing,
in a given situation. (Some of the Asus tools, indicate what they are about
to do.)
Badflash is also a possible way to fix the problem, by allowing you to
go back to a previous version. But your method does give the possibility of
fixing the problem for zero dollars.
And if Asus Tech Support is informed that the Windows flasher cannot revert
any of their screwups, maybe Asus will consider fixing the Windows flasher
to work right. In my investigation of one of these problems, I used MMTool,
and found there was a difference between older and newer BIOS files. The most
recent files could not be read by MMTool (caused MMTool to crash), while the
older release BIOS could. If the BIOS creation tool stream, was changed in
mid-product cycle, that could account for the BIOS flasher being unable to
"go backwards". But this could all be fixed via changes to the Windows flasher
tool, if Asus wanted to. The Windows flasher could always be set up to blow
away the whole ROM, if requested by the user. And the Windows flasher could
certainly have code added, to see that the tool used to create the BIOS
versions, was different, and that special treatment was needed to "go
backwards". So the problem is not insoluble. And the problem could have
been detected, with adequate testing at the factory. (Like testing that
they can "go backwards", just after their latest BIOS has been flashed into
a lab motherboard.)
This kind of crap has been going on for years. The purpose of a Boot Block,
is to be an immutable piece of code. The code is supposed to be simple. Its
only purpose, is to run the hardware well enough, to orchestrate a recovery
operation. Yet, Asus has seen fit to replace the Boot Block, on selected
BIOS releases, and that goes against the very design intent of a Boot Block.
If they never touched the Boot Block, then users could *always* recover
from a "bad flash". And that would make your method, guaranteed to work.
Paul
Similar Threads
Linear Mode
