On 13.12.2007 01:58, ron minnich wrote:
On Dec 12, 2007 4:50 PM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
I don't like this. disable_car() should just be able to return without problems. If it can't do that, fix it.
I've never found the fix. What if it is a hardware limitation on LX? Note that on several LX platforms on V2, we have this: src/mainboard/digitallogic/msm800sev/cache_as_ram_auto.c: done_cache_as_ram_main();
Oh. I admit that my cycles belong to v3 only, so I had not researched the v2 code.
And it's because I could never get it to work any other way. CAR is very tricky sometimes. Just take a deep look at the opteron code -- you'll see that we do some things that make CAR fail on most systems, due to a known limitation in the K8.
Dumb question: We know the location of the stack when we enter disable_car(). We also know that all memory belongs to us. Can we copy CAR stack contents to some safe location and restore them after wbinvd()?
Otherwise we have to document the call to stage1_end() as a requirement of any diable_car() function and *justify* it.
only those architectures that we can't get it to work on.
OK, but my goal is to reduce the amount of these architectures to zero.
Why exactly do we invalidate the stack? If the stack is clobbered, the contents of variables should be in a clobbered state as well. In that case, I suspect parts of our v3 code would misbehave as well.
no, because what happens here is you are essentially dropping all local variables etc. -- this is a jump to a new context, and all the variables in that context are re-initialized.
But the reinitialization is not equivalent to keeping the old values. I'd go to great lengths to keep the old values.
Anyway, maybe Marc can tell us what is wrong. I just don't know. I never solved it on the LX either. I'm happy to see it solved but, at the same time, I don't want to burn my next month of limited cycles on something i have a workaround for.
Marc?
Regards, Carl-Daniel