[coreboot] Acer c720p: seabios is gone after enabling write protection
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 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Motherboard Not on Support MB List - Specs
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 rminn...@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 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Latest SeaBIOS on Acer c720
On Tue, Feb 04, 2014 at 09:49:20AM +0100, Carmelo Ingrao wrote: 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 ? I understand you were able to restore your rom. Let me know if you still need assistance. For reference, the SeaBIOS source code can be obtained via following the information at: http://seabios.org/Download and the steps to build SeaBIOS for coreboot is at: http://www.coreboot.org/SeaBIOS -Kevin -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Latest SeaBIOS on Acer c720
Le 5 févr. 2014 à 15:38, Kevin O'Connor ke...@koconnor.net a écrit : On Tue, Feb 04, 2014 at 09:49:20AM +0100, Carmelo Ingrao wrote: 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 ? I understand you were able to restore your rom. Let me know if you still need assistance. For reference, the SeaBIOS source code can be obtained via following the information at: http://seabios.org/Download and the steps to build SeaBIOS for coreboot is at: http://www.coreboot.org/SeaBIOS -Kevin Hello Kevin, Yes I was able to restore it with the help of Aaron on IRC. thanks anyway :) Carmelo -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Researching the SMM mode
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 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Can't build ASUS F2A85-M for a 4 megabyte flash chip
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)@0xffc2]; 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=0x20 CONFIG_HEAP_SIZE=0xc CONFIG_DCACHE_RAM_SIZE=0x1 CONFIG_HUDSON_LEGACY_FREE=y CONFIG_STACK_SIZE=0x1000 CONFIG_XIP_ROM_SIZE=0x10 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=0x40 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=0x40 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=0xFF82 CONFIG_HUDSON_SATA_IDE=y CONFIG_HUDSON_SATA_MODE=0x0 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Can't build ASUS F2A85-M for a 4 megabyte flash chip
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)@0xffc2]; 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=0x20 CONFIG_HEAP_SIZE=0xc CONFIG_DCACHE_RAM_SIZE=0x1 CONFIG_HUDSON_LEGACY_FREE=y CONFIG_STACK_SIZE=0x1000 CONFIG_XIP_ROM_SIZE=0x10 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=0x40 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=0x40 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=0xFF82 CONFIG_HUDSON_SATA_IDE=y CONFIG_HUDSON_SATA_MODE=0x0 Oh maan. Hudson hardcodes the sata move via config? -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Acer c720p: seabios is gone after enabling write protection
On Wed, Feb 5, 2014 at 3:04 AM, Yannick sev...@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 -Aaron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Motherboard Not on Support MB List - Specs
On Tuesday, February 04, 2014 09:16:31 PM ron minnich wrote: you can shoot for a board with an FSP-supported chipset, or you could Please avoid FSP like the plague. Programatically, it will be the worst pain you will have ever dealt with. do the Quark, which would be truly wonderful to have. Quark comes with firmware source code IIRC. Shouldn't be hard to integrate that under vendorcode/ and do a proper coreboot port. Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Motherboard Not on Support MB List - Specs
On Wed, Feb 5, 2014 at 4:41 AM, lee.changhan changhan...@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 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Motherboard Not on Support MB List - Specs
ron minnich wrote: you could do the Quark, which would be truly wonderful to have. mrnuke wrote: Quark comes with firmware source code IIRC. I read a little about the quark soc and it seems to have some pretty tight signature checks on firmware. I got the impression that it was unpossible to use any other firmware than the UEFI it comes with. //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Motherboard Not on Support MB List - Specs
On Wed, Feb 5, 2014 at 7:53 AM, Peter Stuge pe...@stuge.se wrote: I read a little about the quark soc and it seems to have some pretty tight signature checks on firmware. I got the impression that it was unpossible to use any other firmware than the UEFI it comes with. I'm forwarding a question to intel. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Motherboard Not on Support MB List - Specs
On Wed, Feb 5, 2014 at 7:53 AM, Peter Stuge pe...@stuge.se wrote: I read a little about the quark soc and it seems to have some pretty tight signature checks on firmware. I got the impression that it was unpossible to use any other firmware than the UEFI it comes with. Word from Intel: hook up a dediprog and reprogram. The signature check only applies if UEFI is controlling the flashing. Likely for secure boot parts... Should not be for base (non-ecc and non secure). For Galileo, hook up dediprog and reprogram. Sounds like a documentation clarification is needed on release notes. So we're good to go. Makes sense, there's no EC on galileo, it's more like our original targets (e.g. i440bx) than the newer stuff. It's a nice simple embedded CPU. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Acer c720p: seabios is gone after enabling write protection
Le mercredi 05 février 2014 à 09:36 -0600, Aaron Durbin a écrit : On Wed, Feb 5, 2014 at 3:04 AM, Yannick sev...@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 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Acer c720p: seabios is gone after enabling write protection
On Wed, Feb 5, 2014 at 12:08 PM, Yannick sev...@free.fr wrote: Le mercredi 05 février 2014 à 09:36 -0600, Aaron Durbin a écrit : On Wed, Feb 5, 2014 at 3:04 AM, Yannick sev...@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? Yes. Can't you just get the two files from your friend. You wouldn't need to recover ChromeOS. Should I remove this screw and try again? You can. It will re-write the entire SPI. I'd go with the above first. -Aaron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Researching the SMM mode
On Wed, Feb 5, 2014 at 8:08 AM, Ramkumar Ramachandra artag...@gmail.comwrote: 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 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Acer c720p: seabios is gone after enabling write protection
On Wed, Feb 5, 2014 at 12:51 PM, Yannick sev...@free.fr wrote: Le mercredi 05 février 2014 à 12:41 -0600, Aaron Durbin a écrit : Do you guys think the recovery fails because I do have the screw protecting coreboot in? Yes. Can't you just get the two files from your friend. You wouldn't need to recover ChromeOS. There is something I do not understand here: I can't run any software on the machine except chrome OS recovery, which fails. How am I supposed to run this script? Duh. My apologies. Try removing the WP screw and recover. -Aaron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Researching the SMM mode
Am Mittwoch, den 05.02.2014, 11:44 -0700 schrieb David Hubbard: It is a no-frills approach to what the SMI handler must do, Yes. We don't do crazy stuff like writing to flash from SMM. and does not include any extras (D_LOCK and D_OPEN are extras). No. Locking down SMM would provide a trivial way to undermine system integrity. Look for D_LCK in src/southbridge/intel (various southbridges) to see what we do in that regard. I think the handling on AMD and Via is similar. Linux probably doesn't interact with the SMI handler at all. We don't just support Linux, but also real operating systems. Patrick -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Motherboard Not on Support MB List - Specs
ron minnich wrote: On Wed, Feb 5, 2014 at 7:53 AM, Peter Stuge pe...@stuge.se wrote: I read a little about the quark soc and it seems to have some pretty tight signature checks on firmware. I got the impression that it was unpossible to use any other firmware than the UEFI it comes with. Word from Intel: hook up a dediprog and reprogram. https://communities.intel.com/servlet/JiveServlet/downloadBody/21828-102-2-25120/329676_QuarkDatasheet.pdf https://communities.intel.com/docs/DOC-21828 The top of page 38 (1.2 Component Overview) reads: To enable secure applications, the SoC features an on-die Boot ROM that is used to establish a hardware Root of Trust (RoT). The immutable code located within the Boot ROM is used to initiate an iterative firmware authentication process ensuring only trusted code is executed when taking the platform out of reset. Sounds like a documentation clarification is needed on release notes. Sounds like it.. //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Motherboard Not on Support MB List - Specs
On Wednesday, February 05, 2014 04:53:26 PM Peter Stuge wrote: mrnuke wrote: Quark comes with firmware source code IIRC. I read a little about the quark soc and it seems to have some pretty tight signature checks on firmware. I got the impression that it was unpossible to use any other firmware than the UEFI it comes with. Hey, if you can modify the firmware at will, you can kill those checks. I don't remember where I found the source. Someone on IRC pointed it out. IIRC, it was a non-copyleft license, similar to BSD. For someone that has both the time and knowledge, it's worth a shot to port coreboot to it. The board is only $60. It's one of those things where the sum of the parts blows up... We ask intel to tell us how to init their memory controller... they tell us how to init their memory controller on the quark... we ignore the quark because of unverified concerns. This is a pretty good chance to tell intel, libre software works, bitch! rather than have them tell us open source doesn't work, bitch! You all think about it, Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Motherboard Not on Support MB List - Specs
On Wednesday, February 05, 2014 08:26:46 PM Peter Stuge wrote: the SoC features an on-die Boot ROM that is used to establish a hardware Root of Trust (RoT). RoT sounds about right. Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Acer c720p: seabios is gone after enabling write protection
Le mercredi 05 février 2014 à 12:41 -0600, Aaron Durbin a écrit : On Wed, Feb 5, 2014 at 12:08 PM, Yannick sev...@free.fr wrote: Le mercredi 05 février 2014 à 09:36 -0600, Aaron Durbin a écrit : On Wed, Feb 5, 2014 at 3:04 AM, Yannick sev...@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? Yes. Can't you just get the two files from your friend. You wouldn't need to recover ChromeOS. Should I remove this screw and try again? You can. It will re-write the entire SPI. I'd go with the above first. Removing the screw allowed the recovery process to fully completed. Chrome OS is now reinstalled. Thank you for your help. -Aaron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Motherboard Not on Support MB List - Specs
So I'm continuing my discussion with intel, they are being quite responsive. Peter, thanks for pushing on this, we need the answer! ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Motherboard Not on Support MB List - Specs
ron minnich wrote: So I'm continuing my discussion with intel, they are being quite responsive. Peter, thanks for pushing on this, we need the answer! I'm looking forward to the outcome of the discussion! //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] UNTIN casting errors
Hello all Well the corebootPkg has been one of the best to be incorporated in the edk2 source code. For those who contain large EEPROMs would actually be lucky to try it out on real hardware. Well coming to the point the corebootpkg had some fixes done last time like the toolchain errors on X64 architectures. But some like the casting errors contained in the PlatformPie/Memdect.c have not been fixed yet. Suggestions were last time given of UNTIN cast prior to casting to a pointer but the edk2 corebootpkg gitrepo contains no changes pushed. I hope so someone on this mailing list would pay heed and do the needful. I had mailed the author directly concerning the changes but nothing has been reflected. Neo -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Unable to start correctly coreboot on Asus f2a85-m REV 1.02
OK. Please can you enable AGESA debug stuff. It should produce more output. You can do that by uncommenting #define IDSOPT_IDS_ENABLED in mainboard directory OptionsIds.h file. We dont have a menuconfig for that yet. I made it. There is in my file: grep #define IDSOPT_IDS_ENABLED coreboot/src/mainboard/asus/f2a85-m/OptionsIds.h #define IDSOPT_IDS_ENABLED TRUE I get exactly the same result with this option... I also tested the following options without success. : CONFIG_DEBUG_CBFS CONFIG_DEBUG_MALLOC CONFIG_DEBUG_ACPI CONFIG_DEBUG_SPI_FLASH What can I do now? Thanks. Best regards, -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
