[coreboot] Thinkpad X230t + Windows 7 x64 UEFI-CSM Int 10h
Hello, I own a Thinkpad X230t and I encountered Coreboot project on the Internet. I enjoy FOSS stuff, and also I would like to change my WWAN/WLAN cards in my computer so I decided to switch from proprietary Lenovo UEFI firmware to Coreboot. By the way I found that those Thinkpads are well supported by the project and it is favorable model to use with Coreboot firmware. I use Windows 7 x64 in UEFI-CSM mode as my main OS. My disk is partitioned with GPT. By the way, unfortunately Windows 7 x64 only allows only these configurations: - BIOS or UEFI Legacy Mode firmware + MBR partition table and bootloader in MBR of the disk drive and/or VBR of the system partition - UEFI CSM (non-GOP, Int 10h) firmware + GPT partition table and bootloader in seperate EFI System Partition So I cannot get for example BIOS/UEFI-Legacy + GPT partition table + bootloader in Protective MBR with Windows 7. I started my experience with Coreboot building like 15 different image's using different parameters in 'make menuconfig' so I can find out what is well-suited for me. By the way I also bricked my laptop like 3 times, but that wasn't a problem because I have access to external programmer. All these builds I've made using SeaBIOS primary payload and like 1 with Tianocore. I used SeaBIOS at first because I recognized it simpler than Tianocore so first I can distinguish Coreboot features from primary payload features, and then switch to Tianocore. I got problems with libgfxinit on Xubuntu 20.04 LTS Installer (MBR SYSLINUX+grub) and also with Windows 7 x64 MBR installer, so I extracted VGA BIOS from proprietary Lenovo UEFI, included it as an Option ROM and it solved my problems. However, with SeaBIOS I couldn't access my Windows 7 x64 UEFI-CSM Int 10h HDD installation. It got stuck on Booting from Hard Drive probably because there is like NOP loop in the Protective MBR of GPT-partitioned drive. I made 3 different MBR/BIOS images on thumbdrives in order to test the SeaBIOS: - Xubuntu 20.04 Installer+LiveCD with SYSLINUX+GRUB - installed Xubuntu 20.04 LTS with GRUB - Windows 7 x64 Installer in MBR mode I got all of these running well, but I still have problem with my main OS on the HDD. Of course, with standard SeaBIOS I am not able to boot my Windows installation because it's GPT/ESP-enabled and it cannot boot from the MBR. So I changed my primary payload to Tianocore and chose to boot up the BOOTX64.EFI from Windows 7 ESP partition and it resulted with black screen having some different artifacts like few color strips. I guess that's because Tianocore is only supporting UEFI Level 3 (UEFI non-CSM) and thus it doesn't initialize Int 10h vector and assumes that the operating system will initialize graphics using UEFI GOP, which is not the case with Windows 7. In my earlier experiments, I had exactly the same artifacts when I tried to switch UEFI-CSM to UEFI-non CSM on Desktop Gigabyte motherboard with stock proprietary firmware and I gave it up, because I found out that it's impossible to have Windows 7 support UEFI Level 3 with GOP initialization. Before I found out about Coreboot I didn't even realize that BIOS/UEFI firmware can be split in 2 stages like it is in Coreboot + SeaBIOS/Tianocore. I'm looking for a solution so I can boot up my UEFI-CSM Int 10h Windows 7 x64 installation. I don't know what architecture should I be looking for: - run SeaBIOS as primary payload so it properly initializes the Int 10h along with Intel HD Graphics Option ROM, then run some sort of UEFI secondary payload - run Tianocore as primary load and force it to initialize the Int 10h using some hidden flags during compilation, or just run SeaBIOS somehow as an secondary payload By the way, how it's solved in usual proprietary UEFI-CSM firmware? Regarding first option, I found something such as DuetPkg from Tianocore/EDK-II project which allows to boot this stuff using BIOS from MBR thumbdrive/disk or even as secondary payload of SeaBIOS. Unfortunately I found out that this project was abandoned by Tianocore community like 2 years ago. I also found out patched version of Duet for Coreboot on https://www.notabs.org/coreboot/duet-payload/ , but it hasn't been maintained since 2014 and I don't know if I can trust these patches. I guess that would be the case for me, but since it hasn't been maintained for few years, maybe there's a more modern solution for my problem? As I understand Tianocore is something more than DuetPkg so I cannot use it as SeaBIOS secondary payload because some parts of it would double their responsibility with SeaBIOS routines? Regarding second option, I found on the Internet information that SeaBIOS can be compiled with option to be the CSM payload of something what is called OVMF which I understand to be Tianocore firmware for virtual machines such as qemu. Could some more experienced users (perhaps developers) give me a hint which solution I should be looking for, and
[coreboot] Re: Call for testing: Weird behavior of the EC on Thinkpad X230s
Hi Persmule, On Thu, Jul 16, 2020 at 5:17 PM Persmule wrote: > > Hi Angel Pons, > > It seems that we may copy ec/lenovo/h8 to ec/lenovo/mec16xx ( or separate > directory for different chips ) to start dedicated support to them, since > though they are different, their behavior are so similar that code for > ec/lenovo/h8 can work on them, though buggy. Nope. While it happens rather often, copying code to support a new chip is a terrible approach. Things get duplicated and get patched up independently, and then there are five copies of some file which only differ in cosmetics. If one wants to properly support the different ECs Lenovo uses on the Thinkpads, it's better to reverse engineer each platform again and add fresh code that is tested and known working. One also needs to remember that ECs are made of both hardware and software, and I doubt that any distinction is made in the case of ec/lenovo/h8. In case the software interface is the exact same for Lenovo laptops with different ECs, it should not go into either EC folder. > Best regards, > Persmule > > ‐‐‐ Original Message ‐‐‐ > On Thursday, July 16, 2020 5:10 PM, Angel Pons wrote: > > > Hi Persmule, > > > > On Thu, Jul 16, 2020 at 5:02 PM Persmule persm...@hardenedlinux.org wrote: > > > > > Hi Angel Pons, > > > ‐‐‐ Original Message ‐‐‐ > > > On Thursday, July 16, 2020 2:47 PM, Angel Pons th3fan...@gmail.com wrote: > > > > > > > I suspect that reusing the H8 EC code for the xx30 series Thinkpads is > > > > a source of bugs. There isn't any H8 EC on those mainboards anymore, > > > > the EC was replaced with a completely different SMSC MEC1619. The > > > > T440p port seems to have a few bugs which might be due to the > > > > different EC. > > > > > > Is the EC on the xx20 series Thinkpads (e.g. X220) an H8 EC or not? > > > > AFAIK, yes. The specific H8S model used varies, but they are similar. > > I re-checked the T440p and it uses a different SMSC MEC1633L EC. That > > would explain why only the T440p had some weird issues regarding EC > > stuff. > > > > Best regards, > > Angel Regards, Angel ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Call for testing: Weird behavior of the EC on Thinkpad X230s
Hi Angel Pons, It seems that we may copy ec/lenovo/h8 to ec/lenovo/mec16xx ( or separate directory for different chips ) to start dedicated support to them, since though they are different, their behavior are so similar that code for ec/lenovo/h8 can work on them, though buggy. Best regards, Persmule ‐‐‐ Original Message ‐‐‐ On Thursday, July 16, 2020 5:10 PM, Angel Pons wrote: > Hi Persmule, > > On Thu, Jul 16, 2020 at 5:02 PM Persmule persm...@hardenedlinux.org wrote: > > > Hi Angel Pons, > > ‐‐‐ Original Message ‐‐‐ > > On Thursday, July 16, 2020 2:47 PM, Angel Pons th3fan...@gmail.com wrote: > > > > > I suspect that reusing the H8 EC code for the xx30 series Thinkpads is > > > a source of bugs. There isn't any H8 EC on those mainboards anymore, > > > the EC was replaced with a completely different SMSC MEC1619. The > > > T440p port seems to have a few bugs which might be due to the > > > different EC. > > > > Is the EC on the xx20 series Thinkpads (e.g. X220) an H8 EC or not? > > AFAIK, yes. The specific H8S model used varies, but they are similar. > I re-checked the T440p and it uses a different SMSC MEC1633L EC. That > would explain why only the T440p had some weird issues regarding EC > stuff. > > Best regards, > Angel ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Call for testing: Weird behavior of the EC on Thinkpad X230s
Hi Persmule, On Thu, Jul 16, 2020 at 5:02 PM Persmule wrote: > > Hi Angel Pons, > > ‐‐‐ Original Message ‐‐‐ > On Thursday, July 16, 2020 2:47 PM, Angel Pons wrote: > > I suspect that reusing the H8 EC code for the xx30 series Thinkpads is > > a source of bugs. There isn't any H8 EC on those mainboards anymore, > > the EC was replaced with a completely different SMSC MEC1619. The > > T440p port seems to have a few bugs which might be due to the > > different EC. > > Is the EC on the xx20 series Thinkpads (e.g. X220) an H8 EC or not? AFAIK, yes. The specific H8S model used varies, but they are similar. I re-checked the T440p and it uses a different SMSC MEC1633L EC. That would explain why only the T440p had some weird issues regarding EC stuff. Best regards, Angel ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Call for testing: Weird behavior of the EC on Thinkpad X230s
Hi Angel Pons, ‐‐‐ Original Message ‐‐‐ On Thursday, July 16, 2020 2:47 PM, Angel Pons wrote: > > I suspect that reusing the H8 EC code for the xx30 series Thinkpads is > a source of bugs. There isn't any H8 EC on those mainboards anymore, > the EC was replaced with a completely different SMSC MEC1619. The > T440p port seems to have a few bugs which might be due to the > different EC. > Is the EC on the xx20 series Thinkpads (e.g. X220) an H8 EC or not? ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Call for testing: Weird behavior of the EC on Thinkpad X230s
Hi Persmule, I don't own any Thinkpads so I can't test anything. Still, here's my two cents about the issue at hand. On Thu, Jul 16, 2020 at 1:43 PM Persmule wrote: > > Hi all, > Days ago the coreboot port for Thinkpad X230s ( > https://review.coreboot.org/c/coreboot/+/41390 ) for one of my friends got > merged. Most stuffs on this laptop proves to work fine, but the interaction > between its EC and cellular modem installed in its internal M.2 socket is > detected to be a bit weird, and because of this the cellular modem installed > internally becomes hardly usable: I know there's some workaround for broken BDC detection. Maybe something similar is needed for the X230s. > If the laptop is connected to AC power, the cellular modem is disabled and > cannot be enabled with software. (e.g. Modem manager ) as if there were a > hardware switch set to flight mode; if the AC power is absent, whether the > cellular modem is usable depends on the operating system. > > The detailed testing result table collected by my friend is attached, in html > format. > > The direct cause of this phenomenon may be that the EC erroneously pull down > the GPIO pin for rfkill (Pin 8 of the M.2 socket with key B) when the AC > power gets present, but I cannot confirm whether the main board of this X230s > is faulty, or the EC firmware is buggy, or the EC of X230s should be treated > differently as the EC of X230, which I did not implement in my work. I suspect that reusing the H8 EC code for the xx30 series Thinkpads is a source of bugs. There isn't any H8 EC on those mainboards anymore, the EC was replaced with a completely different SMSC MEC1619. The T440p port seems to have a few bugs which might be due to the different EC. > Currently, this problem is walked around by blocking the Pin with a small > piece of insulating tape. > > Since I have experienced only one X230s, I cannot tell which one is the real > case. Could ye help me to confirm and/or improve this if ye have a chance to > access your own Thinkpad X230s? > > Regards, > Persmule > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org Best regards, Angel Pons ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Call for testing: Weird behavior of the EC on Thinkpad X230s
Hi all, Days ago the coreboot port for Thinkpad X230s ( https://review.coreboot.org/c/coreboot/+/41390 ) for one of my friends got merged. Most stuffs on this laptop proves to work fine, but the interaction between its EC and cellular modem installed in its internal M.2 socket is detected to be a bit weird, and because of this the cellular modem installed internally becomes hardly usable: If the laptop is connected to AC power, the cellular modem is disabled and cannot be enabled with software. (e.g. Modem manager ) as if there were a hardware switch set to flight mode; if the AC power is absent, whether the cellular modem is usable depends on the operating system. The detailed testing result table collected by my friend is attached, in html format. The direct cause of this phenomenon may be that the EC erroneously pull down the GPIO pin for rfkill (Pin 8 of the M.2 socket with key B) when the AC power gets present, but I cannot confirm whether the main board of this X230s is faulty, or the EC firmware is buggy, or the EC of X230s should be treated differently as the EC of X230, which I did not implement in my work. Currently, this problem is walked around by blocking the Pin with a small piece of insulating tape. Since I have experienced only one X230s, I cannot tell which one is the real case. Could ye help me to confirm and/or improve this if ye have a chance to access your own Thinkpad X230s? Regards, Persmule Distribution Kernel version Modem availability (battery) Can be enabled (battery) Modem availability (AC power) Can be enabled (AC power) Bluetooth availability Debian testing/unstable 5.7 Y - N N Y (require firmware) Fedora 32 5.6 N N N N Y Mint 20 5.4 Y - N N Y Debian 10.04 4.19 N Y N N Y (require firmware) PureOS 9 (2020-03) 4.19 N N N N Y (require firmware) ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Extended IvyBridge CPU configuration
Hi Angel, here are the read outs (-X -0) for the MSRs: 0x00CE -> 00080C10F0011C00 0x0194 -> 0009 0x01AD -> 24242526 I'd say the issue is because of how I determine the overclocking headroom that the CPU is capable of. On my CPUs, it happens that the number of OC bins is the same as the number of steps between the base frequency ratio and the maximum turbo ratio. I imagine this isn't the case for other CPUs (which I do not currently have any of nearby) and would explain why the gains aren't as high as expected. From what I've heard about Ivy Bridge Mobile CPUs it depends on the TDP (I don't know about the Sandy Bridge or ULV models): CPUs with 35W TDP should just work as you described. CPUs with 45W TDP can be "overclocked" by up to 400MHz on top of their maximum turbo ratio. In the case of my i7-3840QM it should reach around 4,2 GHz (without taking additional voltage into consideration). CPUs with 55W TDP (i.e. the extreme edition "XM") have a unlocked multiplier and may be considered as the equivalent to the "K" CPUs on the desktop. In its current state, my patch seems to achieve that :P It certainly does ;) I find it curious though that intel_pstate and acpi-cpufreq exhibit different behaviors in terms of maximum frequency. Kind regards, Lars ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] New on blogs.coreboot.org: [GSoC] Address Sanitizer, Part 1
A new post titled "[GSoC] Address Sanitizer, Part 1" has been published on the coreboot blog. Find the full post at https://blogs.coreboot.org/blog/2020/07/16/gsoc-address-sanitizer-part-1/ Hello everyone. My name is Harshit Sharma (hst on IRC). I am working on the project to add the “Address Sanitizer” feature to coreboot as a part of GSoC 2020. Werner Zeh is my mentor for this project and I’d like to thank him for his constant support and valuable suggestions. It’s been a fun couple of weeks since I started working on this project. Though I found the initial few weeks quite challenging, I am glad that I was able to go past that and learned some amazing stuff I’d cherish for a long time. Also, being a student, I find it incredible to have got a chance to work with and learn from such passionate, knowledgeable, and helpful people who are always available over IRC to assist. A few of you may already know about the progress we’ve made through Werner’s post on the mailing list. This is a much comprehensive report on the work we had done prior to the first evaluation period. What is Address Sanitizer ? Address Sanitizer (ASan) is a runtime memory debugging tool, designed to find out of bounds and use after free memory bugs. It is a part of toolset Google has developed which also includes Undefined Behaviour Sanitizer (UBSan), a Thread Sanitizer (TSan), and a Leak Sanitizer (LSan). This tool would help in improving code quality and thus would make our runtime code more robust. Compile with ASan The firstmost task was to ensure that coreboot compiles without any errors after Asan is enabled. For this, we created dummy functions and added the relevant GCC flags to build coreboot with ASan. We also introduced a Kconfig option (currently only available on x86 architecture) to enable this feature. (Patch [1]) Porting code from Linux The design of ASan in coreboot is based on its implementation in Linux kernel, also known as Kernel Address Sanitizer (KASAN). Linux code is GPL licensed and we intend to modify and relicense certain parts. However, coreboot differs a lot from Linux kernel due to multiple stages and that is what poses a challenge. Design of ASan ASan uses compile-time instrumentation that adds a run-time check before every memory instructions. The basic idea is to encode the state of each 8 aligned bytes of memory in a byte in the shadow region. As a consequence, the shadow memory is allocated to 1/8th of the available memory. The instrumentation of the compiler adds __asan_load and __asan_store function calls before memory accesses which seeks the address of the corresponding shadow memory and then decides if access is legitimate depending on the stored state. If the access is not valid, it throws an error telling the instruction pointer address, the address where a bug is found and whether it was read or write. Need for GCC patch Unlike Linux kernel which has a static shadow memory layout, coreboot has multiple stages with very different memory maps. Thus we require different shadow offset addresses for each stage. Unfortunately, GCC presently, only supports using a static shadow offset address which is specified at compile time using -fasan-shadow-offset flag. So, we came up with a GCC patch that introduces a feature to use a dynamic shadow offset address. Through this, we enable GCC to determine shadow offset address at runtime using a callback function __asan_shadow_offset(). Though we are trying to convince GCC developers to include this change in their upcoming versions, for now, ASan on coreboot only works if this patch is applied. (Patches [2] and [3]) Allocating and initializing shadow buffer Instead of allocating a shadow buffer for the whole memory region, we decided to only define shadow memory for data and heap sections. Since we don’t want to run ASan for hardware mapped addresses, this way we save a lot of memory space. Once the shadow region is allocated by the linker, the next task is to initialize it as early as possible at runtime. This is done by a call to asan_init() which unpoisons i.e. sets the shadow memory corresponding to the addresses in the data and heap sections to zero. ASan support for ramstage We decided to begin in a comparatively simpler stage i.e. ramstage. Since ramstage uses DRAM, the implementation is common across all platforms of a particular architecture. Moreover, ramstage provides enough room in the memory to place our shadow region. For now, we have only enabled this feature for x86 architecture and it is able to detect stack out of bounds and use after scope bugs. Though the patches are still in the review stage, we did a test on QEMU and siemens mc_apl3 (Apollo Lake based) and so far it looks good to us. (Patch [4]) Next steps.. In the second coding period, we’ve started working on adding ASan to romstage. I will push a change on
[coreboot] Re: Instruction to verify emulation on GEM5
Dear Vivek, Am 16.07.20 um 00:46 schrieb Vivek Gupta via coreboot: I am currently looking to setup AARCH64 platform simulation verification of coreboot on Gem5 simulation environment. Do we have any document/wikipage to understand the compilation and configuration process? The tutorial [1] should get you started. Basically, coreboot uses Kconfig, but there is also the tool abuild [2], you might want to look at. Kind regards, Paul [1]: https://doc.coreboot.org/tutorial/index.html [2]: https://doc.coreboot.org/util.html ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
