coreboot May 2020

coreboot@coreboot.org

43 participants
45 discussions

i440BX regression; P3B-F flashrom board enable is finally happening
by Keith Hui 14 May '20

14 May '20

Hi guys, I am still refining the P2B family of boards, now including the infamous P3B-F with an unusual appetite for hacks to make work. That said, I'm now finding that, on P3B-F, SeaBIOS hangs when it tries to relocate itself as part of its usual chores. Having just learned git bisect, I decided to try it out. It was commit 3b02006afe8a85477dafa1bd149f1f0dba02afc7 [1] that broke my SeaBIOS. It doesn't affect my newer toy the P8Z77-M as much as P3B-F, but I still want to blame that, and probably the very next commit as well, as they both deal with some very modern aspects of PCI that well predates the 440BX. Is there anything we can do to fix 3b02006afe? Meanwhile I ported the P3B-F board enable to flashrom [2], which got a heavy workout during this bisect, through vendor firmware and both good and bad builds of coreboot. In all cases I can flash internal, no longer having to haul out my P2B-LS just to use it as a flasher. Enjoy this long overdue board enable. If it gets submitted, I'll retract the ramstage hack[3] doing the same as redundant. Keith [1] https://review.coreboot.org/c/coreboot/+/39486 [2] https://review.coreboot.org/c/flashrom/+/41354 [3] https://review.coreboot.org/c/coreboot/+/41224

4 10

Asus P5Q experience
by edbatalha＠yahoo.com 13 May '20

13 May '20

Dear all, I was given a computer with an ASUS P5Q last December and have been using as my main machine since then. About 2 months ago I discovered that it is supported by coreboot so I thought it would be fun to experiment with it. I ordered a usb programmer and a couple of EEPROM chips, followed the tutorial and shortly after was enjoying my new fast BIOS. (I have the P5Q variant from the P5QC family in the source code.) I was conservative at first with the .config and then started experimenting a bit. So I came across a few problems. Not being sure what to emailed Angel Pons who was very kind in providing comments and recommending me to contact the mailing list. So, here goes: 1) I configured coreboot so that the CMOS was used for configuration values. The test was to change the sata mode to Compatible. This made the board unbootable, not even reaching the Seabios message. The solution was to disable the CMOS battery for some seconds. I forgot to take a serial port log. The board has an ICH10R southbridge which is the consumer version that can also function as a RAID controller. The devices supported by the board are defined in the devicetree.cb file where the IDE device 1f.5 is explicitly switched off and that may be why the board did not boot. I did not investigate this further but the expectation here would be that the CMOS value could be used to decide how to configure the controllers. 2) I then decided to try out Windows XP but the Installation would stop with STOP: 0xA5 (0x11, 0x8, ... .. ., .... ). I could not figure it out... Then I used a usb pen with "Active Boot Disk 9.4" in it, based on WindowsPE / Windows7. For that I got STOP: 0xA5 (0x1000, 0x0, 0xFFFFFFF0, 0x400000) and that actually provided a clue. I searched in the ACPI tables and found this in the x4x.asl file " // Integrated graphics 0:2.0 #include <drivers/intel/gma/acpi/non-pch.asl " and this inside that file non-pch.asl file " Device (GFX0) { Name (_ADR, 0x00020000) OperationRegion (GFXC, PCI_Config, 0x00, 0x0100) Field (GFXC, DWordAcc, NoLock, Preserve) { Offset (0x10), BAR0, 64, Offset (0xe4), ASLE, 32, Offset (0xfc), ASLS, 32, } OperationRegion (GFRG, SystemMemory, And (BAR0, 0xfffffffffffffff0), 0x400000) Field (GFRG, DWordAcc, NoLock, Preserve) { Offset (0x61254), BCLV, 16, BCLM, 16, } " However the GFX0 device does not exist as my Northbridge is a 82P45 which is a model without integrated graphics. The solution was to comment the "#include <drivers/intel/gma/acpi/non-pch.asl" out of the x4x.asl file. I decided to try Win XP again and it no longer displayed the Stop: 0xA5 message. "Active Boot disk" also ran without problems. It does not seem correct to me for coreboot to assume that all the x4x northbridges have integrated graphics. Wouldn't it be better to have two versions of the asl file, one with and another without the GMA. 3) For the XP installation to proceed I needed the AHCI driver on diskette so I downloaded it from Intel. I use Linux from Scratch with XFCE as my main operating system but it as I tried to copy the files to diskette I realised that the Floppy was no longer showing in thunar. It was there with the ASUS BIOS, what could be wrong? I added the etc/floppy0 = 4 option to the coreboot.rom image which brought the floppy to the SEABIOS boot menu and I could even boot DOS from there. That did not work. So I though the problem was this issue in the devicetree.cb as I was also getting errors in the cbmem log. chip superio/winbond/w83667hg-a # Super I/O device pnp 2e.0 on # FDC # Global registers irq 0x2a = 0x00 irq 0x2c = 0x22 irq 0x2d = 0x00 # Floppy io 0x60 = 0x3f0 irq 0xf0 = 0x0e As we can see IRQ 0x70 = 0x06 and DRQ 0x74 = 0x02 are missing from the Floppy section. But Linux could still not see or talk with the floppy drive. I eventually fixed it by adding this option to the linux command line: floppy=0,4,cmos At this point I gave up on this problem and moved on. The Floppy is back in the thunar file manager. Angel suggested that the problem may be that there is no definition for the floppy drive in the ACPI tables. ... Lots of problems with bad sectors later I was able to continue with the XP installation. I stopped at the screen where I need to select a partition to install the system to and decided to continue later. The important thing here is that XP no longer bluescreens. 4) This one is more of an annoyance. My PS/2 mouse did not work. I was also seeing this message in the log: PNP: 002e.5 init w83667hg_a_init: Disable mouse controller.PNP: 002e.5 init finished in 3 msecs I had a good look at the source code around the error message and concluded that I needed the [*] PS/2 keyboard init option enabled. We have this in src/superio/winbond/w83667hg-a/superio.c " mouse_detected = pc_keyboard_init(PROBE_AUX_DEVICE); if (!mouse_detected && !acpi_is_wakeup_s3()) { printk(BIOS_INFO, "%s: Disable mouse controller.", __func__); " And we see this in src/drivers/pc80/pc/keyboard.c: " uint8_t pc_keyboard_init(uint8_t probe_aux) { u8 retries; u8 regval; enum cb_err err; uint8_t aux_dev_detected; if (!CONFIG(DRIVERS_PS2_KEYBOARD)) return 0; " So the function returns immediately and the probe for the mouse never happens with the option off. This was not obvious by looking at the help, which only talks about keyboards and states it is not needed if you use seabios: │ Enable this option to initialize PS/2 keyboards found connected │ │ to the PS/2 port. │ │ │ │ Some payloads (eg, filo) require this option. Other payloads │ │ (eg, GRUB 2, SeaBIOS, Linux) do not require it. │ │ Initializing a PS/2 keyboard can take several hundred milliseconds. │ │ │ │ If you know you will only use a payload which does not require │ │ this option, then you can say N here to speed up boot time. │ │ Otherwise say Y. Something is not quite right in the logic behind all of this. I guess "initialize PS/2 keyboards found connected" could be replaced with "initialize PS/2 keyboards and mice found connected." 5) None of the secondary payloads coreinfo, nvramcui and Memtest86+ worked for me. I managed to get Memtest86+ working by selecting the "Master" version but did not investigate any further. 6) I tried to follow the "coreboot Overview" in https://www.coreboot.org/Developer_Manual but found it difficult, the crt0_romcc_epilogue.inc for example does net exist in the source tree. Is there any other updated overview somewhere else? ------- Angel Pons suggested that I had a look at part 2 of the tutorial so that I could start proposing changes for review. I may start doing that, free time allowing... I'm not a programmer by trade (never worked with git for example) but I know C and learning about the PC architecture has been an hobby for me in the last few years. Coreboot has been amazing for that but I still have a lot to learn. I hope it's ok to report issues to the mailing list like this, apologies for the long email. Regards, Eduardo Batalha

2 1

Linux kernel says "do_IRQ: 1.55 No irq handler for vector"
by Zheng Bao 13 May '20

13 May '20

Hi, All, I am debugging the AMD Picasso board. When Linux kernel boots, there is some error message in dmesg. do_IRQ: 1.55 No irq handler for vector The kernel can still boot. What does this message mean? Can I just ignore this message? Completed dmesg is attached. Zheng [ 0.032000] ... value mask: 0000ffffffffffff [ 0.032000] ... max period: 00007fffffffffff [ 0.032000] ... fixed-purpose events: 0 [ 0.032000] ... event mask: 000000000000003f [ 0.032000] Hierarchical SRCU implementation. [ 0.032000] smp: Bringing up secondary CPUs ... [ 0.032000] x86: Booting SMP configuration: [ 0.032000] .... node #0, CPUs: #1 [ 0.004000] do_IRQ: 1.55 No irq handler for vector [ 0.032000] NMI watchdog: Enabled. Permanently consumes one hw-PMU counter. [ 0.032000] #2 [ 0.004000] do_IRQ: 2.55 No irq handler for vector [ 0.032070] #3 [ 0.004000] do_IRQ: 3.55 No irq handler for vector [ 0.036014] smp: Brought up 1 node, 4 CPUs [ 0.036014] smpboot: Max logical packages: 1 [ 0.036014] smpboot: Total of 4 processors activated (20761.52 BogoMIPS) [ 0.036664] devtmpfs: initialized [

5 6

Announcing coreboot 4.12
by Patrick Georgi 12 May '20

12 May '20

Hi everybody, I just release coreboot 4.12, with release notes as follows: Since 4.11 there were 2692 new commits by over 190 developers and of these, 59 contributed for the first time, which is quite an amazing increase. Thank you to all developers who again helped made coreboot better than ever, and a big welcome to our new contributors! Maintainers ----------- This release saw some activity on the MAINTAINERS file, showing more persons, teams and companies declare publicly that they intend to take care of mainboards and subsystems. To all new maintainers, thanks a lot! Documentation ------------- Our documentation efforts in the code tree are picking up steam, with some 70 commits in that general area. Everything from typo fixes to documenting mainboard support or coreboot APIs. There's still room to improve, but the contributions are getting more and better. Hardware support ---------------- The removals due to the announced deprecations as well as the deduplication of boards into variants skew the stats a bit, so at a top level view this is a rare coreboot release in that it removes more boards (51) than it adds (49). After accounting for the variant moves the numbers in favor of more hardware supported than the previous version. Besides a whole lot of Chrome OS devices (again), this release features a whole bunch of retrofits for devices originally shipping with non-coreboot OEM firmware, but also support for devices that come with coreboot right out of the box. For that, a shout out to System76, Protectli, Libretrend and the Open Compute Project! Cleanup -------- We simplified the header that comes at the top of every file: Instead of a lengthy reference to the license any given file is under, or even the license text itself, we opted for simple [SPDX](https://www.spdx.org) identifiers. Since people also handled copyright lines differently, we now opt for collecting authors in AUTHORS and let git history tell the whole story. While at it, the content-free "This file is part of this-and-that project" header was also dropped. Besides that, there has also been more work to sort out the headers we include across the tree to minimize the code impacting every compilation unit. Now that our board-variant mechanism matured, many boards that were individual models so far were converted into variants, making it easier to maintain families of devices. Deprecations ------------ For the 4.12 release a few features on x86 became mandatory. These are relocatable ramstage, postcar stage and C_ENVIRONMENT_BOOTBLOCK. ### Relocatable ramstage Relocatable stages are a feature implemented only on x86, where stages can be relocated at runtime. This is used to place ramstage in a better location that does not collide with memory the OS or the payload tends to use. The rationale behind making this mandatory is that you always want cbmem to be cached so it's a good location to run ramstage from. It avoids using lower memory altogether so the OS can make use of it and no backing up needs to happen on S3 resume. ### Postcar stage With Postcar stage tearing down Cache-as-Ram is done in a separate stage. This means that romstage has a clean program boundary and that all variables in romstage can be accessed via their linked addresses without runtime resolution. There is no need to link global and static variables via the CAR_GLOBAL macro and no need to access them with car_set/get_var/ptr functions. ### C_ENVIRONMENT_BOOTBLOCK Historically the bootblock on x86 platforms has been compiled with romcc. This means that the generated code only uses CPU registers and therefore no stack. This 20K+ LOC compiler is limited and hard to maintain and so is the code that one has to write in that environment. A different solution is to set up Cache-as-Ram in the bootblock and run GCC compiled code in the bootblock. The advantages are increased flexibility and consistency with other architectures as well as other stages: e.g. printing to console is possible and VBOOT can run before romstage, making romstage updatable via RW FMAP regions. ### Platforms dropped from master The following platforms did not implement those feature are dropped from master to allow the master branch to move on: - AMDFAM10 - all FSP1.0 platforms: BROADWELL_DE, FSP_BAYTRAIL, RANGELEY - VIA VX900 In particular on FSP1.0 it is impossible to implement POSTCAR stage. The reason is that FSP1.0 relocates the CAR region to the HOB before returning to coreboot. This means that after FSP returns to coreboot accessing variables via their original address is not possible. One way of obtaining that behavior would be to set up Cache-as-Ram again (but with open source code) and copy the relocated data from the HOB there. This solution is deemed too hacky. Maybe a lesson can be learned from this: blobs should not interfere with the execution environment, as this makes proper integration much harder. ### 4.11_branch Given that some platforms supported by FSP1.0 are being produced and popular, the 4.11 release was made into a branch in which further development can happen. Significant changes ------------------- ### SMMSTORE is now production ready See [smmstore](../drivers/smmstore.md) for the documentation on the API, but note that there will be an update to it featuring a much-improved but incompatible API. ### Unit testing infrastructure Unit testing of coreboot is now possible in a more structured way, with new build subsystem and adoption of [Cmocka](https://cmocka.org/) framework. Tree has new directory `tests/`, which comprises infrastructure and examples of unit tests. See [Unit testing coreboot](../technotes/2020-03-unit-testing-coreboot.md) for the design document. Final Notes ----------- Your favorite new feature or supported board didn't make it to the release notes? They're maintained collaboratively in the coreboot tree, so when you land something noteworthy don't be shy, contribute to the upcoming release's document in Documentation/releases! Best regards, Patrick Georgi -- Google Germany GmbH, ABC-Str. 19, 20354 Hamburg Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

1 0

About support for my netbook
by Alif Ilhan 12 May '20

12 May '20

I have attached all the log files releated to the dmidecode ectool inteltool etc. Can you read those out and tell me if it is possible to port coreboot to my netbook? If it is then how hard will it be?

5 7

Introduction and a little about my GSoC project
by Harshit Sharma 12 May '20

12 May '20

Hello everyone, My name is Harshit. I am a computer engineering student selected to be a part of this year’s GSoC. I will be working on the project to add kernel address sanitizer functionality to coreboot. Once this feature is implemented, it would be possible to build with ASan and use it to find memory corruption bugs. I am quite excited to have an opportunity to contribute. Also, I look forward to having fruitful interaction with the developers here and learning from them. Thanks, Harshit

2 2

beginner's despair ;) coreboot update via internal fails
by JPT 11 May '20

11 May '20

Hi, I want to contribute to the board status database. For this I did a build from 4.11 branch. This is flashing from the OS for the first time. the SPI command I used was: ./flashrom/flashrom -p ch341a_spi -l firmware/orig/X220/x220-orig.bin.layout -i bios -w coreboot/build/coreboot.rom -c MX25L6436E/MX25L6445E/MX25L6465E/MX25L6473E/MX25L6473F For internal flash I modified this command to this: sudo ./flashrom/flashrom -p internal:boardmismatch=force -l firmware/orig/X220/x220-orig.bin.layout -i bios -w coreboot/build/coreboot.rom -c MX25L6436E/MX25L6445E/MX25L6465E/MX25L6473E/MX25L6473F But it doesn't work. What am I doing wrong? thanks JPT flashrom v1.1-rc1-125-g728062f on Linux 5.4.0-29-generic (x86_64) flashrom is free software, get the source code at https://flashrom.org Using region: "bios". Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns). coreboot table found at 0xbff6a000. Found chipset "Intel QM67". Enabling flash write... SPI Configuration is locked down. FREG0: Flash Descriptor region (0x00000000-0x00000fff) is read-only. FREG2: Management Engine region (0x00003000-0x004fffff) is locked. Not all flash regions are freely accessible by flashrom. This is most likely due to an active ME. Please see https://flashrom.org/ME for details. At least some flash regions are read protected. You have to use a flash layout and include only accessible regions. For write operations, you'll additionally need the --noverify-all switch. See manpage for more details. OK. Found Macronix flash chip "MX25L6436E/MX25L6445E/MX25L6465E/MX25L6473E/MX25L6473F" (8192 kB, SPI) mapped at physical address 0x00000000ff800000. This coreboot image (LENOVO:ThinkPad X220) does not appear to be correct for the detected mainboard (X220:ThinkPad X220). Proceeding anyway because user forced us to. Reading old flash chip contents... Transaction error! FAILED.

5 5

Re: Need help with getting KGPE-D16 working.
by Daniel Kulesz 10 May '20

10 May '20

Hi Ragnaros, to solve (some of) the hangs I highly recommend disabling the serial console completely as discussed here: https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/GA3W… Using 16 GB sticks did not work for me either, but I found a configuration that works if you use only some of them together with 8 GB slots resulting in at least 96 GB of fully working memory in a single-cpu configuration. This might also work with 192 GB in a dual-cpu configuration. See my posting here for details: https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/message/A63… If you have only 16 GB sticks available, use the orange slots only or just a single DIMM in the first orange slot before going any further. It doesn't make sense to diagnose issues such a graphics output or non-booting payloads when you don't rule out inproperly working memory first. Gfx initialization with a dedicated nvidia GPU and booting from NVMe works fine for me, although I'm not using 4.11 but an older version (master somewhere between 4.8 and 4.9). I just use a text-based ("legacy") graphics without splash and boot the kernel from there which then initializes the graphics properly and switches them to graphics mode. No issues with this so far. Regarding the fans: If you run linux, you can control them in userland using a tool such as "fancontrol" if you don't want to control them by the BMC or don't have it installed. The fancontrole profile I created for this (attached) results in the following RPM and temperature levels at the moment in my (computer) case: GPU core: +0.90 V (min = +0.90 V, max = +0.90 V) temp1: +60.0°C (high = +95.0°C, hyst = +3.0°C) (crit = +105.0°C, hyst = +5.0°C) (emerg = +135.0°C, hyst = +5.0°C) fam15h_power-pci-00c4 Adapter: PCI adapter power1: 51.28 W (crit = 114.49 W) ... fan1: 596 RPM (min = 329 RPM) fan2: 584 RPM (min = 329 RPM) fan3: 0 RPM (min = 329 RPM) ALARM fan4: 0 RPM (min = 329 RPM) ALARM fan5: 585 RPM (min = 329 RPM) fan6: 696 RPM (min = 329 RPM) fan7: 0 RPM (min = 329 RPM) ALARM fan8: 0 RPM (min = 329 RPM) ALARM temp1: +68.2°C (high = +70.0°C, hyst = +65.0°C) (crit = +85.0°C, hyst = +80.0°C) sensor = thermal diode temp7: +25.8°C (high = +70.0°C, hyst = +65.0°C) (crit = +85.0°C, hyst = +80.0°C) sensor = AMD AMDSI temp8: +0.0°C (high = +70.0°C, hyst = +65.0°C) (crit = +85.0°C, hyst = +80.0°C) sensor = AMD AMDSI ... k10temp-pci-00cb Adapter: PCI adapter temp1: +22.9°C (high = +70.0°C) Normally, my fans run at around 350-400 RPM in idle and are hardly hearable. The increased rotation levels are probably due to the fact that I didn't clean the dust filters for a while. If you use the profile you might need to adjust the devpath probably, but you can try to create your own with pwmconfig and then tweak the values. Cheers, Daniel

2 3

problems on X220
by JPT 10 May '20

10 May '20

Hi, I got several problems with coreboot on X220. I report them for you to improve coreboot. I's not important for me. If you need more details on a specific problem, tell me please. This is a build from today 4.11 branch with seabios and memtest payload I've got several boot media ready to test how coreboot behaves. that is an original DOS 5.0 installation, like 30 years old. a fresh Kubuntu 20.4 installation Memtest86 4.3.7 (latest BIOS version) - DOS 5.0 does not boot, it stops just before the C:> prompt - Kubuntu 20.4: systemd-udevd runs amok all the time. this might be because it tries modprobe nvidia-uvm. - Kubuntu 20.4: Shutdown does not work AE_NOT_FOUND - Kubuntu 20.4: reboot just switches off AE_NOT_FOUND - Kubuntu 20.4: Going to standby does not work. Switches off the screen, but leaves on the CPU and cannot wake up again. - Ctrl-Alt-Del does not work? - ESC for reboot from payload memtest or USB memtest just stops (crashes?) - access to CMOS using nvramtool does not work. complains about missing HAVE_OPTION_TABLE. but both USE_ and HAVE_OPTION_TABLE are set. this makes it impossible enabling the debug boot log for the board status database - I somehow cannot enter the grub boot menu. might this be related to missing graphics bios? so, is this normal? I expected coreboot to be more production ready to be honest... :( regards Jan

4 7

Boot order?
by Mogens Jensen 10 May '20

10 May '20

I have experimentet with coreboot on my CompuLab Intense PC (Ivy Bridge) for some time, and I think everything is working now, with Intel ME disabled. Although, I have some troubles with boot selection. I'm currently running coreboot [4cea00a64] with default SeaBIOS payload and a bootorder file. The boot device search order is this: 1. USB 2.0 device 2. USB 3.0 device 3. SATA devices (in order: 2.5″ internal, mSATA, eSATA, FACE module) During testing I have been running the system from a USB 3.0 flash disk. This worked as expected and system would automatically select this device during boot/reboot. I then wanted to use the internal 2.5" SATA disk, so I installed an OS and confirmed it working by manually selecting the SATA disk in boot menu. I then removed boot sector from flash disk, reboot and expected that the system would now automatically boot from internal SATA disk, but this happened instead: === Booting from Hard Disk... Boot failed: not a bootable disk Booting from Floppy... Boot failed: not a bootable disk No bootable device. Retrying in 60 seconds. === Not sure what is going on with "Floppy". No such thing exists on the system. If I remove flash disk from USB port before power on, the system will boot correctly from internal SATA disk. Is this correct behaviour? I would expect that it should not matter that flash disk is inserted in USB port, as long as no boot sector is present on the device. If this is NOT correct behaviour, then what could be the problem here? Thanks in advance. Regards, Mogens Jensen

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot May 2020