coreboot February 2014

coreboot@coreboot.org

52 participants
148 discussions

Re: [coreboot] Researching the SMM mode
by David Hubbard 05 Feb '14

05 Feb '14

On Wed, Feb 5, 2014 at 8:08 AM, Ramkumar Ramachandra <artagnon(a)gmail.com>wrote: > Hi, > > I'm currently researching the SMM mode, and would appreciate pointers > on what the code in src/cpu/x86/smm does. > > 1. It seems to me that smi_handler() is executed everytime there's an > SMI interrupt. When does this occur? How can I inspect what exactly > happens when an SMI is fired? Also, what is smm_handler_start(), and > when is it executed? > > 2. Isn't the firmware supposed to write thermal and power data to > SMRAM while in SMM mode? Where is the code for this? > > 3. Is smm_setup_relocation_handler() called when the SMBASE is > relocated? I see comments in smmrelocate.S justifying why SMBASE needs > to be relocated from the default value. What does the Intel manual > have to say about this (I'm reading Chapter 34 from 3C)? > > 4. How does coreboot ensure that SMRAM isn't accessible from a non-SMM > mode? Various papers talk about D_LOCK and D_OPEN registers; where are > these registers set? > > 5. How does Linux interact with software that is executed in SMM mode, > if at all? I could only find one reference to SMM in the codebase: > Documentation/dcdbas.txt; it talks about a Dell Systems Management > Base Driver. > > Thanks. > > Ram > > Although I can't speak to your exact questions, here is a general response: Coreboot's SMI handler is designed primarily for compatible operation. It is a no-frills approach to what the SMI handler must do, and does not include any extras (D_LOCK and D_OPEN are extras). It only has to do just barely enough so the OS kernel can load and the OS kernel will then take care of any higher level tasks such as thermal and power monitoring. That means the SMRAM is not protected, which makes sense since the only "threat" to SMRAM would be a rogue OS kernel. Linux probably doesn't interact with the SMI handler at all. David

1 0

Re: [coreboot] Acer c720p: seabios is gone after enabling write protection
by Yannick 05 Feb '14

05 Feb '14

Le mercredi 05 février 2014 à 09:36 -0600, Aaron Durbin a écrit : > On Wed, Feb 5, 2014 at 3:04 AM, Yannick <sevmek(a)free.fr> wrote: > > Hi, > > > > I'm the one who tried to help Carmelo. Unfortunately, after I opened > > this machine (Acer c720p, french keyboard) and removed the screw to > > enable writing on coreboot, it now refuses to access to seabios if I > > press CTRL + L has I did before so many times. It just emits a sound "bip" when doing so. > > I've put the screw back in, it's still the same. > > > > Thus the fedora 20 I installed is now out of reach. > > > > If I wait ~30 seconds, I've a second white screen proposing to reinstall > > ChromeOS using USB or SD. I hope I someone here can save me the trouble > > of reinstalling ChromeOS, then wipe it again, then reinstall Fedora 20 > > and reconfigure it... > > > > Process I'm trying to get it working back: > > 1- using a distro (ubuntu 12.04 in my case) prepare an USB stick with chromeos recovery using this script : > > https://support.google.com/chromebook/answer/1080595 > > -> https://dl.google.com/dl/edgedl/chromeos/recovery/linux_recovery.sh > > 2- turn on os verification in coreboot > > 3- reboot and at the warning screen telling you chromeos is missing insert the USB stick. > > 4- I've a "unexpected error" during recovery process. :/ > > > > I'm stuck... > > > > > > You need access to the chromeos-firmwareupdate script and flashrom as > documented here: > > http://www.coreboot.org/pipermail/coreboot/2014-February/077158.html > > You could ask your friend to copy chromeos-firmwareupdate as well as > flashrom to your machine. The script is self hosting and flashrom is > statically linked: > > # ldd /usr/sbin/flashrom > not a dynamic executable The current issue is I only have access to the white screen from coreboot, there is no seabios available. Thus I'm trying to reinstall Chrome OS. I find out there is a log on the USB flash drive I'm using for the Chrome OS recovery which might explain the failure and maybe solve my issue at the same time. In recovery.log, before running some diagnostics at the end of the file, there is this error: "Touch(/mnt/stateful_partition/.install_completed) FAILED Starting firmware updater (/tmp/install-mount-point/usr/sbin/chromeos-firmwareupdate --mode=recovery) Command: /tmp/install-mount-point/usr/sbin/chromeos-firmwareupdate --mode=recovery Starting Peppy firmware updater v4 (recovery)... - Updater package: [Google_Peppy.4389.81.0 / peppy_v1.5.114-5d52788] - Current system: [RO:Google_Peppy.4389.78.0 , ACT:Google_Peppy.4389.78.0 / peppy_v1.5.113-2d79820] - Write protection: Hardware: ON, Software: Main=off EC=ON Upgrading from early-MP firmware. RW firmware update is not compatible with current RO firmware. Starting full update... ERROR: You need to first disable hardware write protection. ERROR: Execution failed: ./updater4.sh (error code = 4) Finished after 2 seconds. Failed Command: /tmp/install-mount-point/usr/sbin/chromeos-firmwareupdate --mode=recovery - Exit Code 4 RO Firmware needs update, but is really marked RO. (error code: 4) Rolling back update due to failure installing required firmware. Successfully updated GPT with all settings to rollback. PostInstall Failed" Do you guys think the recovery fails because I do have the screw protecting coreboot in? Should I remove this screw and try again? > > -Aaron

2 1

Re: [coreboot] Motherboard Not on Support MB List -> Specs
by ron minnich 05 Feb '14

05 Feb '14

On Wed, Feb 5, 2014 at 4:41 AM, lee.changhan <changhanlee(a)gmail.com> wrote: > Thank you both for your responses. I hope I'm not beating the question to > death here, but is it possible to reverse engineer closed information on > things like Intel MBs' memory controller registers? How much time do you have? Given enough time and money it can be done. ron

1 0

Acer c720p: seabios is gone after enabling write protection
by Yannick 05 Feb '14

05 Feb '14

Hi, I'm the one who tried to help Carmelo. Unfortunately, after I opened this machine (Acer c720p, french keyboard) and removed the screw to enable writing on coreboot, it now refuses to access to seabios if I press CTRL + L has I did before so many times. It just emits a sound "bip" when doing so. I've put the screw back in, it's still the same. Thus the fedora 20 I installed is now out of reach. If I wait ~30 seconds, I've a second white screen proposing to reinstall ChromeOS using USB or SD. I hope I someone here can save me the trouble of reinstalling ChromeOS, then wipe it again, then reinstall Fedora 20 and reconfigure it... Process I'm trying to get it working back: 1- using a distro (ubuntu 12.04 in my case) prepare an USB stick with chromeos recovery using this script : https://support.google.com/chromebook/answer/1080595 -> https://dl.google.com/dl/edgedl/chromeos/recovery/linux_recovery.sh 2- turn on os verification in coreboot 3- reboot and at the warning screen telling you chromeos is missing insert the USB stick. 4- I've a "unexpected error" during recovery process. :/ I'm stuck... Best regards, Yannick

2 1

Re: [coreboot] Can't build ASUS F2A85-M for a 4 megabyte flash chip
by mrnuke 05 Feb '14

05 Feb '14

On Wednesday, February 05, 2014 04:17:01 PM Idwer Vollering wrote: > Compiling for 8MB however works just fine. > > Error output: > > Created CBFS image (capacity = 4193256 bytes) > E: Could not add [build/coreboot_hudson_romsig.bin, 16 bytes (0 > KB)@0xffc20000]; too big? > E: Failed to add 'build/coreboot_hudson_romsig.bin' into ROM image. > make: *** [build/coreboot.pre1] Error 1 > I'll let you guess what's missing from here. (hint: cbfstool print). > $ egrep -e '^CONFIG.*SIZE' -e '^CONFIG_MAINBOARD' -e > '^CONFIG_HUDSON_.*' -e CONFIG_USE_BLOBS .config > CONFIG_USE_BLOBS=y > CONFIG_MAINBOARD_DIR="asus/f2a85-m" > CONFIG_MAINBOARD_PART_NUMBER="F2A85-M" > CONFIG_MAINBOARD_VENDOR="ASUS" > CONFIG_HW_MEM_HOLE_SIZEK=0x200000 > CONFIG_HEAP_SIZE=0xc0000 > CONFIG_DCACHE_RAM_SIZE=0x10000 > CONFIG_HUDSON_LEGACY_FREE=y > CONFIG_STACK_SIZE=0x1000 > CONFIG_XIP_ROM_SIZE=0x100000 > CONFIG_MAINBOARD_SMBIOS_MANUFACTURER="ASUS" > CONFIG_MAINBOARD_VERSION="1.0" > CONFIG_CACHE_ROM_SIZE_OVERRIDE=0 > CONFIG_BOARD_ROMSIZE_KB_8192=y > CONFIG_COREBOOT_ROMSIZE_KB_4096=y > CONFIG_COREBOOT_ROMSIZE_KB=4096 > CONFIG_ROM_SIZE=0x400000 > CONFIG_MAINBOARD_SERIAL_NUMBER="123456789" > CONFIG_MAINBOARD_SMBIOS_PRODUCT_NAME="F2A85-M" > CONFIG_HIGH_SCRATCH_MEMORY_SIZE=0xA1000 > CONFIG_SMM_TSEG_SIZE=0 > CONFIG_CBFS_SIZE=0x400000 > CONFIG_S3_DATA_SIZE=32768 > CONFIG_HUDSON_XHCI_ENABLE=y > CONFIG_HUDSON_XHCI_FWM=y > CONFIG_HUDSON_IMC_FWM=y > CONFIG_HUDSON_XHCI_FWM_FILE="3rdparty/southbridge/amd/hudson/xhci.bin" > CONFIG_HUDSON_IMC_FWM_FILE="3rdparty/southbridge/amd/hudson/imc.bin" > CONFIG_HUDSON_FWM=y > CONFIG_HUDSON_FWM_POSITION=0xFF820000 > CONFIG_HUDSON_SATA_IDE=y > CONFIG_HUDSON_SATA_MODE=0x0 Oh maan. Hudson hardcodes the sata move via config?

1 0

Can't build ASUS F2A85-M for a 4 megabyte flash chip
by Idwer Vollering 05 Feb '14

05 Feb '14

Compiling for 8MB however works just fine. Error output: Created CBFS image (capacity = 4193256 bytes) E: Could not add [build/coreboot_hudson_romsig.bin, 16 bytes (0 KB)@0xffc20000]; too big? E: Failed to add 'build/coreboot_hudson_romsig.bin' into ROM image. make: *** [build/coreboot.pre1] Error 1 $ egrep -e '^CONFIG.*SIZE' -e '^CONFIG_MAINBOARD' -e '^CONFIG_HUDSON_.*' -e CONFIG_USE_BLOBS .config CONFIG_USE_BLOBS=y CONFIG_MAINBOARD_DIR="asus/f2a85-m" CONFIG_MAINBOARD_PART_NUMBER="F2A85-M" CONFIG_MAINBOARD_VENDOR="ASUS" CONFIG_HW_MEM_HOLE_SIZEK=0x200000 CONFIG_HEAP_SIZE=0xc0000 CONFIG_DCACHE_RAM_SIZE=0x10000 CONFIG_HUDSON_LEGACY_FREE=y CONFIG_STACK_SIZE=0x1000 CONFIG_XIP_ROM_SIZE=0x100000 CONFIG_MAINBOARD_SMBIOS_MANUFACTURER="ASUS" CONFIG_MAINBOARD_VERSION="1.0" CONFIG_CACHE_ROM_SIZE_OVERRIDE=0 CONFIG_BOARD_ROMSIZE_KB_8192=y CONFIG_COREBOOT_ROMSIZE_KB_4096=y CONFIG_COREBOOT_ROMSIZE_KB=4096 CONFIG_ROM_SIZE=0x400000 CONFIG_MAINBOARD_SERIAL_NUMBER="123456789" CONFIG_MAINBOARD_SMBIOS_PRODUCT_NAME="F2A85-M" CONFIG_HIGH_SCRATCH_MEMORY_SIZE=0xA1000 CONFIG_SMM_TSEG_SIZE=0 CONFIG_CBFS_SIZE=0x400000 CONFIG_S3_DATA_SIZE=32768 CONFIG_HUDSON_XHCI_ENABLE=y CONFIG_HUDSON_XHCI_FWM=y CONFIG_HUDSON_IMC_FWM=y CONFIG_HUDSON_XHCI_FWM_FILE="3rdparty/southbridge/amd/hudson/xhci.bin" CONFIG_HUDSON_IMC_FWM_FILE="3rdparty/southbridge/amd/hudson/imc.bin" CONFIG_HUDSON_FWM=y CONFIG_HUDSON_FWM_POSITION=0xFF820000 CONFIG_HUDSON_SATA_IDE=y CONFIG_HUDSON_SATA_MODE=0x0

1 0

Researching the SMM mode
by Ramkumar Ramachandra 05 Feb '14

05 Feb '14

Hi, I'm currently researching the SMM mode, and would appreciate pointers on what the code in src/cpu/x86/smm does. 1. It seems to me that smi_handler() is executed everytime there's an SMI interrupt. When does this occur? How can I inspect what exactly happens when an SMI is fired? Also, what is smm_handler_start(), and when is it executed? 2. Isn't the firmware supposed to write thermal and power data to SMRAM while in SMM mode? Where is the code for this? 3. Is smm_setup_relocation_handler() called when the SMBASE is relocated? I see comments in smmrelocate.S justifying why SMBASE needs to be relocated from the default value. What does the Intel manual have to say about this (I'm reading Chapter 34 from 3C)? 4. How does coreboot ensure that SMRAM isn't accessible from a non-SMM mode? Various papers talk about D_LOCK and D_OPEN registers; where are these registers set? 5. How does Linux interact with software that is executed in SMM mode, if at all? I could only find one reference to SMM in the codebase: Documentation/dcdbas.txt; it talks about a Dell Systems Management Base Driver. Thanks. Ram

1 0

Re: [coreboot] Latest SeaBIOS on Acer c720
by Carmelo Ingrao 05 Feb '14

05 Feb '14

Hello Kevin, I’m trying to do the same as you because I have done a mistake : I no longer ave seabios in ma rom chip … But I don’t understand "For those interested in reproducing, it will require the very latest seabios from the git repo. « Can you please help me ? Thanks Carmelo

2 2

Re: [coreboot] Motherboard Not on Support MB List -> Specs
by lee.changhan 05 Feb '14

05 Feb '14

Thank you both for your responses. I hope I'm not beating the question to death here, but is it possible to reverse engineer closed information on things like Intel MBs' memory controller registers? On Wed, Feb 5, 2014 at 12:16 AM, ron minnich <rminnich(a)gmail.com> wrote: > How long does it take? > > You need to do this in stages. > > - take a supported board, make some change to it (change the print > messages!), do the full build/burn/test > - take a new board, but which is almost identical to a supported > board, do it again > - take a new board, with some new chip, do it again. > > And then you're almost ready. And, you almost certainly still can't do > it if it's a new intel part, with ONE exception: > you can shoot for a board with an FSP-supported chipset, or you could > do the Quark, which would be truly wonderful to have. > > Or you could go for an ARM board. Want to help with one? > > Or an AMD board, which generally is far more friendly in the x86 world > than Intel at present. > > ron >

1 0

Re: [coreboot] Motherboard Not on Support MB List -> Specs
by ron minnich 05 Feb '14

05 Feb '14

How long does it take? You need to do this in stages. - take a supported board, make some change to it (change the print messages!), do the full build/burn/test - take a new board, but which is almost identical to a supported board, do it again - take a new board, with some new chip, do it again. And then you're almost ready. And, you almost certainly still can't do it if it's a new intel part, with ONE exception: you can shoot for a board with an FSP-supported chipset, or you could do the Quark, which would be truly wonderful to have. Or you could go for an ARM board. Want to help with one? Or an AMD board, which generally is far more friendly in the x86 world than Intel at present. ron

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot February 2014