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