lkml.org 
[lkml]   [2000]   [Mar]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:57    [W:0.094 / U:0.064 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site