Ronald G Minnich <[EMAIL PROTECTED]> writes:
> here's something to worry about. given a certain type of writeback (WB)
> set-associative cache, we're going to be assuming that we won't ever have
> some sort of cache line collision that would trigger a WB. If we do
> trigger WB, and ram is not up, it's all over. The processor will write
> data out, causing very bad things to happen to the not-set-up sdram, and
> at some point might try to read that line back in again -- still worse. I
> realize this is unlikely in the current setup, but as linuxbios evolves,
> who knows what might change.
For the current cache setup I can prevent this by disabling the
addition of new cache blocks to the cache. The downside is that if I
garantee this I can't cache instructions during memory init.
> I'm not sure I'm comfortable modifying linuxbios to assume this will work
> across all the processors we might ever use. So, I want to make it
> continue to work both ways.
This sounds good. The trick is generally applicable but at least for
now we don't want to depend on the ability to do this.
> I'd like to stick with the current structure, but modify the low-level
> assembly to have the option to call out to C for ram init, so that we can
> easily turn the cache feature on and off.
>
> that said, I'm really looking forward to trying this out. It could be a
> real lifesaver.
O.k. That sounds reasonable. The tricky bit is that we will need to
be very careful of what we call because of static data issues. In
practice this means we will need to clone printk and it's subordinate
routines so can properly handle the modifyable memory issues.
Eric
