Am Dienstag, den 06.01.2015, 12:30 +0100 schrieb Michał Masłowski:
Does somebody have a coreboot log from serial or USB for cold boot and resume, please? I am unable to get one right now, because the docking station is not here.
I have logs from EHCI debug: normal boot and resume from suspend to RAM.
Thanks a lot!
Using dd, grep and hexdump shows that the coreboot table entry at memory address 0x500 gets zeroed. /proc/iomem considers that address "reserved".
Guessing from searching the code: smm_setup_structures from src/southbridge/intel/i82801gx/smi.c overwrote it, called by acpi_resume in src/arch/x86/boot/acpi.c. I haven't checked how the (mentioned in the comment) GNVS relocation or coreboot table writing are done, nor how it's different when resuming.
Yes, that looks correct. Thank you for the analysis. Looking through the code, the function is implemented differently for Intel BD82x6x and later models. I tried to quickly backport this to Intel 82801Gx, but failed [1]. Stefan gave some good hints already:
I think on core / core2 SMM is not using TSEG (in our implementation), so you'll have to look at the ASEG.
Since you might be running on either a core cpu (32bit) or core2 (64bit) you might need to determine what CPU you're running on (at runtime) and use the according XXX_state_save_area_t. If the offsets for the registers you are looking at are the same for both CPU types, you can probably avoid that..
Look at src/cpu/x86/smm/smihandler.c for how stuff was set up there.
and
rbx doesn't exist on 32bit CPUs, so you'll have switch at runtime here depending on the CPU type.
Kyösti also replied:
FYI: I have an incompleted patchset to convert from SMM TSEG relocator to SMM_MODULES, and I do not see what would prevent from converting ASEG SMI handlers to SMM_MODULE too.
So, I guess I’ll wait until that work is done. If somebody else has another idea how to solve that for the Intel 82801Gx, please share.
Thanks,
Paul