So I've got linuxbios booting inside Bochs and I feel I'm confident enough to roll the dice and burn it to a real board (TSSOP package, no sockets) using /dev/bios.
After some head-scratching, I realize that the hardware RP# and VPP are tied together, and at a logic low, preventing any flash attempts. These are pins 10 and 11 on the TSSOP part. :-(
Now I imagine that these are tied to a MOSFET to +12V which is run off of a GPIO pin. The question is, without tracing an 8-layer board out to try and identify how exactly reflash is enabled, how to reflash this?
I can always cut the traces and hard-wire to +12V but I'd like to see if I can't do this programmatically. I have a number of boards I want to use and hardware hacking is something I'd like to avoid doing if possible.
Now I know that every motherboard is different and that there may be other things locking me out, but generally speaking is there an "industry standard" way of enabling/disabling BIOS reflash? It's currently a PhoenixBIOS, so I imagine if I located a reflash tool and ran it in a Bochs session with a lot of I/O debugging I could figure out what it's doing but before I embark on that I'd like to see if anyone has any hints that may save me a lot of time.
Regards, Andrew
On Sun, 1 Dec 2002, Andrew Kohlsmith wrote:
Now I imagine that these are tied to a MOSFET to +12V which is run off of a GPIO pin.
probably a good guess.
Another way I found it on one board was to try every combination of GPIOs until the FLASH started working. Not fun, but pretty fast if you write a program.
I can always cut the traces and hard-wire to +12V but I'd like to see if I can't do this programmatically. I have a number of boards I want to use and hardware hacking is something I'd like to avoid doing if possible.
get the flash burner for this board, run under a simulator of some sort, and watch the IOs. Or put a PCI bus analyzer on the machine, run the flash program, and watch the IOs. It's not going to be fun.
I still don't see how running under Bochs helps with the chipset but maybe I missed something.
Now I know that every motherboard is different and that there may be other things locking me out, but generally speaking is there an "industry standard" way of enabling/disabling BIOS reflash?
No, the goal is to make it hard for you to reflash. So the vendors keep coming up with new ways to hide this. Very annoying!
ron
Ronald G. Minnich wrote:
On Sun, 1 Dec 2002, Andrew Kohlsmith wrote:
Now I know that every motherboard is different and that there may be other things locking me out, but generally speaking is there an "industry standard" way of enabling/disabling BIOS reflash?
No, the goal is to make it hard for you to reflash. So the vendors keep coming up with new ways to hide this. Very annoying!
The two methods we use for the several motherboards we design a year to enable/disable flash writes are:
Method A - Use a jumper.
Method B - Use whatever GPIO is leftover on chipset or Super I/O.
Bari
Ron,
Another way I found it on one board was to try every combination of GPIOs until the FLASH started working. Not fun, but pretty fast if you write a program.
Do you have such a program??
-Andrew
On Wed, 4 Dec 2002, Andrew Ip wrote:
Ron,
Another way I found it on one board was to try every combination of GPIOs until the FLASH started working. Not fun, but pretty fast if you write a program.
Do you have such a program??
it varies for each and every motherboard.
I'll try to find my old one for the T23 (which failed, by the way, thanks to IBM).
ron
* Ronald G. Minnich rminnich@lanl.gov [021202 04:43]:
Another way I found it on one board was to try every combination of GPIOs until the FLASH started working. Not fun, but pretty fast if you write a program.
Some machines, like my Thinkpad A21p, reboot immediately on probing, if the right GPIO is not set. Pretty ugly.
get the flash burner for this board, run under a simulator of some sort, and watch the IOs. Or put a PCI bus analyzer on the machine, run the flash program, and watch the IOs. It's not going to be fun.
ouch! sounds like this gets nasty quickly.
I still don't see how running under Bochs helps with the chipset but maybe I missed something.
It doesn't. Basically most flasher programs use some kind of data structure the look for in the bios memory, that contains pointers to functions like "map flash to memory", "disable write protection", etc. This is at least the case with AMI and Award, probably Phoenix as well. These are 16bit calls, which makes it kind of hard/impossible to really use directly. It's possible to search for this structure and look at the code. However, this is likely to be illegal in many countries.
No, the goal is to make it hard for you to reflash. So the vendors keep coming up with new ways to hide this. Very annoying!
Especially after the first non-vendor-written flashers appeared, many people were scared of viruses destroying the flash data and such. Security by obscurity...
Stefan
It doesn't. Basically most flasher programs use some kind of data structure the look for in the bios memory, that contains pointers to functions like "map flash to memory", "disable write protection", etc. This is at least the case with AMI and Award, probably Phoenix as well. These are 16bit calls, which makes it kind of hard/impossible to really use directly. It's possible to search for this structure and look at the code. However, this is likely to be illegal in many countries.
Not in Canada. :-)
Yeah this does sound kind of ugly. Especially since the Orasis BIOS won't boot up in Bochs, as it seems to end up hanging due to some PIT simulator inconsistencies.
Especially after the first non-vendor-written flashers appeared, many people were scared of viruses destroying the flash data and such. Security by obscurity...
Well, if worse comes to worst I can just cut the trace and wire those pins to +12. The datasheet for the chip says that it operates normally under those circumstances, except that all "soft" boot block protection is disabled.
Regards, Andrew
Hello from Gregg C Levine Pardon me Andrew? It happens that I got the thing to work. This was in 1.4.1 and under Linux, Slackware Linux 8.0 if you're curious. I simply plugged the file that you made into the space provided, and adjusted the rest of the settings to match. If you mean that the elf boot program that everyone is proud of, and rightfully so, does not work under Bochs, I'll agree. I tabled it, because I could not figure out a way to make it work. I figured correctly that I'd need to make a port to a particular motherboard to make it work for me. Oh, and what did you mean? Anyway. ------------------- Gregg C Levine hansolofalcon@worldnet.att.net ------------------------------------------------------------ "The Force will be with you...Always." Obi-Wan Kenobi "Use the Force, Luke." Obi-Wan Kenobi (This company dedicates this E-Mail to General Obi-Wan Kenobi ) (This company dedicates this E-Mail to Master Yoda )
-----Original Message----- From: linuxbios-admin@clustermatic.org [mailto:linuxbios- admin@clustermatic.org] On Behalf Of Andrew Kohlsmith Sent: Wednesday, December 04, 2002 9:36 AM To: linuxbios@clustermatic.org Subject: Re: common flash hw write enable methods
It doesn't. Basically most flasher programs use some kind of data structure the look for in the bios memory, that contains pointers to functions like "map flash to memory", "disable write protection",
etc.
This is at least the case with AMI and Award, probably Phoenix as
well.
These are 16bit calls, which makes it kind of hard/impossible to
really
use directly. It's possible to search for this structure and look at the code. However, this is likely to be illegal in many countries.
Not in Canada. :-)
Yeah this does sound kind of ugly. Especially since the Orasis BIOS
won't
boot up in Bochs, as it seems to end up hanging due to some PIT
simulator
inconsistencies.
Especially after the first non-vendor-written flashers appeared,
many
people were scared of viruses destroying the flash data and such. Security by obscurity...
Well, if worse comes to worst I can just cut the trace and wire those
pins to
+12. The datasheet for the chip says that it operates normally under
those
circumstances, except that all "soft" boot block protection is
disabled.
Regards, Andrew _______________________________________________ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Pardon me Andrew? It happens that I got the thing to work. This was in 1.4.1 and under Linux, Slackware Linux 8.0 if you're curious. I simply plugged the file that you made into the space provided, and adjusted the rest of the settings to match. If you mean that the elf boot program that everyone is proud of, and rightfully so, does not work under Bochs, I'll agree. I tabled it, because I could not figure out a way to make it work. I figured correctly that I'd need to make a port to a particular motherboard to make it work for me. Oh, and what did you mean? Anyway.
The original 256k Dauphin Orasis v1 BIOS will not come up in Bochs; it seems to get stuck in a timing loop with the PIT. That is what I was referring to.
With the 430tx LinuxBIOS and the ELF IDE payload booter, I was able to get a lovely kernel panic in Bochs, which is good. Now I'm just trying to get these damned boards to enable the reflash of the BIOS so I can use /dev/bios and put LinuxBIOS there.
Regards, Andrew
On Wed, 4 Dec 2002, Stefan Reinauer wrote:
Some machines, like my Thinkpad A21p, reboot immediately on probing, if the right GPIO is not set. Pretty ugly.
yes, this is an iterative process with many landmines.
get the flash burner for this board, run under a simulator of some sort, and watch the IOs. Or put a PCI bus analyzer on the machine, run the flash program, and watch the IOs. It's not going to be fun.
ouch! sounds like this gets nasty quickly.
actually the PCI analyzer is the easiest, it allowed us to figure out L440GX flash and ASUS SMBUS issues in about 15 minutes.
ron
Greetings,
Security by obscurity is likely part of it, but either it's not the whole story or not well thought out. A simple jumper is much more secure and not at all obscure.
G'day, sjames
On Wed, 4 Dec 2002, Stefan Reinauer wrote:
- Ronald G. Minnich rminnich@lanl.gov [021202 04:43]:
Another way I found it on one board was to try every combination of GPIOs until the FLASH started working. Not fun, but pretty fast if you write a program.
Some machines, like my Thinkpad A21p, reboot immediately on probing, if the right GPIO is not set. Pretty ugly.
get the flash burner for this board, run under a simulator of some sort, and watch the IOs. Or put a PCI bus analyzer on the machine, run the flash program, and watch the IOs. It's not going to be fun.
ouch! sounds like this gets nasty quickly.
I still don't see how running under Bochs helps with the chipset but maybe I missed something.
It doesn't. Basically most flasher programs use some kind of data structure the look for in the bios memory, that contains pointers to functions like "map flash to memory", "disable write protection", etc. This is at least the case with AMI and Award, probably Phoenix as well. These are 16bit calls, which makes it kind of hard/impossible to really use directly. It's possible to search for this structure and look at the code. However, this is likely to be illegal in many countries.
No, the goal is to make it hard for you to reflash. So the vendors keep coming up with new ways to hide this. Very annoying!
Especially after the first non-vendor-written flashers appeared, many people were scared of viruses destroying the flash data and such. Security by obscurity...
Stefan
I still don't see how running under Bochs helps with the chipset but maybe I missed something.
Turn on excessive debugging on Bochs and watch for debug messages saying "accessing register x on PCI device abc:def" to help narrow it down.
Regards, Andrew
Hello from Gregg C Levine Good idea. But under which version of Bochs? The group over there, is having excessive problems in making 2.0 reachable by the end of the year. And how do you do that? ------------------- Gregg C Levine hansolofalcon@worldnet.att.net ------------------------------------------------------------ "The Force will be with you...Always." Obi-Wan Kenobi "Use the Force, Luke." Obi-Wan Kenobi (This company dedicates this E-Mail to General Obi-Wan Kenobi ) (This company dedicates this E-Mail to Master Yoda )
-----Original Message----- From: linuxbios-admin@clustermatic.org [mailto:linuxbios- admin@clustermatic.org] On Behalf Of Andrew Kohlsmith Sent: Wednesday, December 04, 2002 9:33 AM To: linuxbios@clustermatic.org Subject: Re: common flash hw write enable methods
I still don't see how running under Bochs helps with the chipset but
maybe
I missed something.
Turn on excessive debugging on Bochs and watch for debug messages
saying
"accessing register x on PCI device abc:def" to help narrow it down.
Regards, Andrew _______________________________________________ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Hello from Gregg C Levine Good idea. But under which version of Bochs? The group over there, is having excessive problems in making 2.0 reachable by the end of the year. And how do you do that?
You might want to try spacing out your emails a bit, the hello and long signature lines all mashed up against the actual body text make it difficult to read.
Having said that, it is easily done by editing the source to Bochs; in particular, iodev/pci.cc and just reporting PCI reads and writes and then going through them afterward.
Regards, Andrew
One i430TX board I have (Tyan S1571) had the DIP32's (Atmel AT29C010A) OE# in the normal place (ISA MEMR#), but the WE# at ISA SMEMW#. So you had to read from the high window, and write to the low. annoying to alter /dev/bios driver, so I removed the jumper and soldered WE# to ISA MEMW#.
Regards, Jeremy
----- Original Message ----- From: "Andrew Kohlsmith" akohlsmith-linuxbios@benshaw.com To: linuxbios@clustermatic.org Sent: Sunday, December 01, 2002 9:59 PM Subject: common flash hw write enable methods
After some head-scratching, I realize that the hardware RP# and VPP are
tied
together, and at a logic low, preventing any flash attempts. These are
pins
10 and 11 on the TSSOP part. :-(
Now I imagine that these are tied to a MOSFET to +12V which is run off of
a
GPIO pin. The question is, without tracing an 8-layer board out to try
and
identify how exactly reflash is enabled, how to reflash this?
I can always cut the traces and hard-wire to +12V but I'd like to see if I can't do this programmatically. I have a number of boards I want to use
and
hardware hacking is something I'd like to avoid doing if possible.
Now I know that every motherboard is different and that there may be other things locking me out, but generally speaking is there an "industry
standard"
way of enabling/disabling BIOS reflash? It's currently a PhoenixBIOS, so
I
imagine if I located a reflash tool and ran it in a Bochs session with a
lot
of I/O debugging I could figure out what it's doing but before I embark on that I'd like to see if anyone has any hints that may save me a lot of
time.
-
Andrew Ip -
Andrew Kohlsmith -
Bari Ari -
Gregg C Levine -
Jeremy Jackson -
Ronald G. Minnich -
Stefan Reinauer -
steven james