[LinuxBIOS] patch for making system run past disable_car

Carl-Daniel Hailfinger c-d.hailfinger.devel.2006 at gmx.net
Thu Dec 13 02:14:43 CET 2007

On 13.12.2007 01:58, ron minnich wrote:
> On Dec 12, 2007 4:50 PM, Carl-Daniel Hailfinger
> <c-d.hailfinger.devel.2006 at 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.



More information about the coreboot mailing list