Messages in this thread | | | Date | Wed, 29 Mar 2000 09:16:29 -0500 (EST) | From | "Richard B. Johnson" <> | Subject | Re: Answer (Re: Cylinder limits jumper for drives over 32GB) |
| |
On Wed, 29 Mar 2000, Andre Hedrick wrote:
> On Tue, 28 Mar 2000, H. Peter Anvin wrote: > > > Andre... what we're trying to figure out if there is a way to this > > *TRANSIENTLY*, so that a reset will set it back to the old value. > > > > However, if plugging in manual values in the BIOS works then that's > > probably the recommended way, unless there really is an easy way to work > > around. > > > > Remember... most hardware/firmware is broken. Part of what makes a good > > OS is to work with broken hardware without sacrificing working with > > properly working hardware. God knows I've messed lots with BIOS bugs. > > Peter, > > Please trust that I know the world is full of broken hardware, and even > if you follow the exact OEM directions for the hardware, it still can go > wrong. I see some of the worst night/day-mares in ATA hardware than > anyone can imagine. >
Yes. Most hardware is broken. The purpose of the BIOS is/was to fix the hardware bugs in "cheaper" software so that the OS can interface with something that is logically correct. 32-bit OSs don't/can't use the BIOS so they have to discover, and fix, the corruption in their drivers.
I am currently writing a BIOS. I have most of the generic stuff done. I can boot an old '486 with it, and I can boot this Pentium with it. However, there isn't any other machine in the lab that will boot because they all require different numbers of clock-cycles to wait before the NEC Floppy chip (same devices) will provide reliable status. If I wait too long, the status is wrong, if I wait too short a time, the status is wrong. There is a window of between 12 and 15 microseconds in which the status is correct. This means that every machine will have to be "tuned", based upon its clock-frequency. FYI, this is only one chip! Fortunately, the target machine has a fixed clock frequency.
One machine comes up with the DMA enabled and doing memory-to-memory transfers, etc., so, in principle, I should wait long enough for such an occurance to terminate before I enable/test memory. However, I'm testing my stuff with a PROM emulator which is really RAM, so upon startup, my virtual-PROM sometimes gets corrupt. These motherboards are designed to be just good enough to be fixed in software. Some, they don't even bother.
That said, the "Ide-guy" really has his hands full. IDE spells "cheap". The idea was to absolutely minimize the amount of hardware and make it all up in software. Unfortunately, a XYZ disk drive on a ABC mother- board is not the same thing as a XYZ disk drive on a DEF mother-board.
This is why DMA sometimes doesn't work with the same drive on a different motherboard, or sometimes UDMA drives seem to work better than PIO when logic says that this shouldn't be. Basically, on the mother-board you have an I/O port. The bus-timing to the port is probably whatever it turned out to be, not what it is supposed to be. It was presumed that a BIOS writer would do a few 'LOOP $' instructions between every I/O with that port until the transients (from bus contention) died down.
One of the major problems with an asynchronous bus is that it seems to work even when it's badly designed. The last device to put its data on the bus wins. However, the bus contention that occurs when an addressed device enables its data, before the previous device has gotten off the bus, causes transients that take a long time to die out. This corrupts data.
Bus contention also increases power consumption. When several devices are driving the bus at the same time, in different directions, you are trying to short out your power supply! One of the first instruments that I helped design, that had a CPU in it, had a problem. It didn't meet its power consumption specifications although it worked otherwise.
The power out of the 5 volt supply was supposed to be 1/2 A. It was about 1.5 A. At 5 volts, this isn't much power, but for a portable instrument this is a killer. I looked at the bus with a scope, spent a few hours with the designer, then came back with a new PAL. The power drain was now 1/4 A. It was all fixed in "firmware" in the PAL by adding a few gate-delays to get the bus timing correct.
Nobody bothers to do this with mass-produced motherboards where the factory cost is $85, with the parts cost $80! Yep, 5 bux per board is all the guys on the Pacific rim make.
Cheers, Dick Johnson
Penguin : Linux version 2.3.41 on an i686 machine (800.63 BogoMips).
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |