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();
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.
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.
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.
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.
ron