"michael@camaronet.de" wrote:

Hi, !

>On Wed, 23 Feb 2000 carlini@bulean.lkg.dec.com wrote:
>> 
>> I've just (quickly) compared the KA48 and KA660 docs and there do seem to be
>> some slight differences. The most obvious one is that the VLC only has a
>> primary cache and no backup cache; so none of the registers associated with the
>> backup cache exist.

>I didn't enable backup cache on the KA660. There is only about half a page on
>this, and i didn't find the addresses of the BCIDX and his friends. But the
>KA660 ist very fast, maybe the PROM enables bcache ?

I'll look up the KA660 stuff when I get the chance but I won't be near any docs
until monday at the earliest. Typically the console will test out the hardware
and I would expect it to test the cache. However, I would expect the cahce to
be turned off so the OS can decide what to do with it.

>But if you have the docs for the KA48, what is wrong here:

>Set DIAG in CCR, check all 8 banks (enabled by the bits in BEHR) for good
>memory present, reset them to 0 in cache DATA and 0x80000000 in cache TAG, and
>if everything was OK, remeber this bank control bit. After checking all banks
>(all 8 are OK), i write the remembered bits to BEHR, say FLUSH in CCR and say
>ENA in CCR then. (This is the only bit left 1 then). This works on KA660, but
>not on KA48, so some, maybe very small, detail is different here.

Well maybe it works on KA48 too but something else goes wrong elsewhere. For
example, when the OS mucks with page tables it has to invalidate the TB
properly. And it may have to update the cache (depending on how things are
implemented). So your initialisation may be OK but something else just happens
to go wrong.

I assume that after flushing the cache and enabling it, you turn off the diag
bit so that there is no danger of a later stray access mucking with the cache?

My impression of reading the docs is that you can actually investigate the
wrokings of the bits and pieces - i.e. you can see tags and data get updated.
Thisis supposed to be for diagnostic use but it might be useful when things do
die to dump out the relevant portions of the cache info just to see what is
going on.

BTW: you don't need to write the data lines at all - although it probably does
not hurt - and if all banks are turned on at once then writing a tag writes it
to all banks in parallel. No need to do it one bank at a time. In fact the
manual suggests that you don't do it one bank at a time.

One thing that might matter is that you are not actually testing the banks -
whereas the console does. The manual implies that banks which fail
manufacturing tests are burnt so that they cannot be turned on. But banks that
go bad during the life of the chip can still (presumably) be turned on. So
since the console tests the banks you should not enable any extra banks in your
code. Leave BEHR alone and just write the tags. 

>If my VLC wouldn't run that fine under VMS, i would suspect a broken cache in
>my box. If someone wants to check it out, i could put a kernel with my cache
>routine somewhere, but i don't expect other results than i have on my box.

I'll have a closer read of the manuals on Monday and see if there is something
obvious I've missed.

Antonio