[coreboot] alix1c and v3

[Marc Jones]

Carl-Daniel Hailfinger wrote:
> On 28.01.2008 21:57, Marc Jones wrote:
>> ron minnich wrote:
>>   
>>> coreboot seems to by dying in VSM on some config access as well.
>>>
>>> Carl-Daniel pointed out to me:
>>> "IIRC there is also a VSM stack which is located in a place differing
>>> from the one clobbered between 0x1000 and 0x2000.
>>>
>>> Notice how it blows up exactly at the time where the first virtual PCI
>>> access happens. That means it blows up inside VSM."
>>>
>>> So we need to get a complete idea of the needs of VSA/VSM for memory and stack.
>>>     
>> VSA needs a real mode stack for init. As Tom pointed out that is setup 
>> in real_mode_switch_call_vsm in src/cpu/amd/model_lx/vsmsetup.c. I don't 
>> think that the location matters. It could move instead ov moving stage2.
>>   
> 
> We place that stack at 0x1000, however Ron saw during VSA init that
> memory directly above 0x1000 was clobbered as well. Since the stack is
> growing down, that suggests that the VSA writes to memory outside the
> VSA init stack.

I don't think so. It is coreboot that sets the stack for VSA 
initialization. The more I think about it, the stack shouldn't be moved. 
Just switch to real mode and VSA can use the same stack as LinuxBIOS 
(maybe pad it a little if you are worried about alignment). This is how 
it works in a standard BIOS.


> IIRC the VSA also has a runtime stack to save registers when called via
> SMI. The Geode GX VSA2 programmer's guide is not completely clear on
> that or I skipped over the wrong pages.
> MSR_SMM_HDR is the location of the runtime stack, or rather the SMM
> header in which at least some part of the SMM runtime stack is stored.
> Do we set that anywhere?
> 
It is in the VSA memory area. It is setup by VSA during init.

> Ron, can you provide us with logs of the last revision before VSA
> support went in and of your current local codebase? I hope to pinpoint
> the location of the explosion better.

I should be building shortly and be able to find what is blowing up.
Marc

-- 
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:Marc.Jones at amd.com
http://www.amd.com/embeddedprocessors