"Preston L. Bannister" <[EMAIL PROTECTED]> writes:
> Not to be obtuse or anything, but with regards to the enabling the L2
> cache I've just seen "there has never been a problem" and "frustrating".
>
> Are you saying that you know how to enable the L2 cache, but the NDA
> does not allow you publically release the sources?
>
> This is a bit tacky, but could you distribute a compiled object module
> for just that section of code?
>
> Since the code is in every BIOS chip, and anyone with any skill could
> disassemble a BIOS chip, you would not be exposing anything new.
>
> Another tack might be to come in through the side door. You have the
> information you need to enable the cache on Intel processors, Alphas
> and not AMD? If so this might make a good Slashdot article or the like.
>
> AMD Marketing might come down on your side :).
First look at what we is done in cpufixup for the K7.
Now to be clear about the current situation. There are Model Specific
Registers in the Athlon processor that AMD does not publicly
document. A few of these are crucial to actually using the chip.
If you read up on the EV6 bus that the Athlon uses you will see that
it has different transaction types for accessing memory and memory
mapped I/O devices. The SiS730 treats both transaction types the
same. The AMD Athlon does not. It will only do write back caching on
memory regions that generate memory access transactions on the AMD760
bus. This was experimentally confirmed. AMD does not actually
document that, anywhere.
The AMD760 chipset also unlike the SiS730 cares if a transaction is
a memory transaction or a io mapped memory devices. So at memory
address 0xf0000 if you do a memory tranaction you access RAM. If you
do an memory mapped IO device transaction you access your ROM BIOS.
So the big thing is how to generate what kind of transaction on the
bus. There are a few other minor bits that also need to get set for
reliable operation. But they are much less crucial.
The situation with the NDA is more interesting. AMD or at least some
parties in AMD are really sensitive about people breaking NDAs. Being
with a company that has signed a standard NDA, and received in confidence
AMD processor documentation, my hands are tied. A similiar situation
applies to Ollie Lho. While we do have a team member who has a better
arrangement with AMD, the NDA on the rest of us keeps us from talking
out all of the problems, and implimenting code in a timely manner.
At this point I would not mind it if someone went and reverse
engineered the few that are needed to support a chipset like the
AMD760. Saying anyone with any skill can do it, and having someone
with some skill doing it are two totally seperate things. That and
there was somone from AMD who was just about daring me to do it.
At this point I am doing everything that I honorably do. And just so
people think a little more. The stakes aren't just the AMD Athlon
processor. The stakes are building a working relationship with AMD so
we can also build linuxBIOS on their future processors. At least they
are for me :)
AMD has been good to work with. No one has told me they hate the idea
of linuxBIOS, or they are opposed to it. Asking for them to make
public parts of their processor documentation is just a little more
then AMD was prepared to do. It doesn't make sense to me.
Personally I think there would be some good publicty in it for AMD.
And I can see a lot of people building things like and embedded Duron
solution simply because they can do things like linuxBIOS, with it.
But for now we support the Athlon on some platforms and not on others.
Eric
