Linus Torvalds <torvalds@transmeta.com> writes:
> On 4 May 2001, Eric W. Biederman wrote:
> >
> > There are a couple of options here.
> > 1) read the MTRRs unless the BIOS is braindead it will set up that area as
> > write-back. At any rate we shouldn't ever try to allocate a pci region
> > that is write-back cached.
>
> This one I'd really hesitate to use. We do _not_ want to trust the BIOS
> any more than necessary (obviously trusting even the e820 was too much),
> and especially wrt MTRR's we know that there are too many buggy bioses
> already out there.
O.k. I was simply thinking that if we weren't reprogramming the mtrrs, it
would be a good idea to make certain we didn't map any PCI drivers
into a write back area.
> > 2) read the memory locations from the northbridge. It's not possible
> > on every chipset (lack of documentation) but with the linuxBIOS
> > project we code for a couple of them, and we are working on more
> > all of the time.
>
> This will be easy.
O.k. If it easy.
Currently I can find information for some via chipsets. One
serverworks chipset, practically every intel chipset, the AMD 750
& 760 chipsets, current SIS chipsets, and the alpha tsunami chipset.
There is probably more that is just what I have actually seen.
There are complications of memory reserved for AGP, and memory
holes. But they shouldn't be too bad.
My only problem is I don't have the bandwidth to code it up at the
moment, but if it's the kind of patch that if done well you are
likely to accept I'll look at it.
Since it is only likely to be 30-40 lines per chipset it should
only take an hour or two per chipset. And after the first couple are
in the kernel others can clone the work.
This has the nice side effect that once we know where the ram is on a
chipset we can reprogram the MTRRs correctly ourselves, correcting bad
BIOS's.
> In fact, we can easily "mix" different heuristics. Ie we'd do the simple
> thing I suggested in setup_arch(), and use that as a "base guess", and
> then we can have incremental improvements on that guess that might be
> chipset-specific or might depend on other information that is not
> necessarily generic (things like existing PCI programming etc).
That sounds reasonable. Since we don't always have all the
documentation we need heuristics so we can run on boards where we are
just guessing.
On the not trusting the BIOS, would you accept patches to do more
of the lowlevel setup?
There is a pnp-os spec that basically says you should only need to
initialize devices necessary for booting. With linuxBIOS we are
working to take this to the extreme, and define devices necessary for
booting as: RAM, the bootstrap CPU, the Flash ROM chip, and possibly
a serial port for debugging. Currently I need to a little more setup
than this because of limitations in linux.
The more of the lowlevel set we can get into linux, the less you need
to trust the BIOS and the less I need to code to get linuxBIOS up on
an individual motherboard.
Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon May 07 2001 - 21:00:21 EST