coreboot

coreboot@coreboot.org

6 participants
39687 discussions

ThinkPad T420 and FireWire chip on Linux
by Alesandar Metodiev 09 Apr '22

09 Apr '22

Hello, Recently I have decided to give a try to coreboot for first time and flashed my ThinkPad T420, but a few weeks ago I have swapped the USB controller on the back, next to the battery, with a FireWire/USB controller (40GAB5809-G200) from another T420. Nothing special, since some models have been shipped like this. The controller is no longer accessible on my laptop. It seems like it may have been detected as an "SD Host Controller" or not detected at all. I will probably have to remove the chip and compare the output of lspci and lshw. If nothing has changed, I will probably have to return the stock BIOS and compare the results again. I have also tried to load some of the firewire kernel modules manually with modprobe. The operating systems I have tested so far are Arch Linux and Xubuntu. I am willing to provide more useful information, boot into a fresh Windows install, flash the chip again or whatever else. Correct me if I am wrong, but if I go back to the stock BIOS, the next time I flash, I will have to disassemble the laptop again and otherwise I must be fine with flashing internally, right? Thanks

6 28

Refactoring duplicate Embedded Controller code
by Abel Briggs 08 Apr '22

08 Apr '22

Hello, I was looking at the code and ACPI for a number of different embedded controllers while adding support for a Lenovo mainboard. The mainboard in question has an EC nearly identical to the Twist S230U (Compal KB9012), so I planned to factor out the S230U's EC code/ACPI into its own chip. While doing this, I noticed there were several duplicate functions across the `ec/` directory, so I'd like to potentially submit some patches to clean them up. However, I'm not sure of the best way to go about this. The following is what I currently have in mind: - Removing most individual `ec_write_cmd()` and similar functions andreplacing calls with their respective `ec/acpi/ec.c` library functions - Removing individual `kbc_` polling functions and sharing the ones defined in `drivers/pc80/keyboard.c` - Should public library functions for sending and receiving data from a PC80 keyboard controller be defined in the PC80 driver and exported in `include/pc80/keyboard.h`? - We already have `send_keyboard()` there, which sends a command and receives data - would it be good to add individual functions for those operations as well? Any suggestions or recommendations would be appreciated. I looked for guidelines on suggested code organization in the docs/commit history/ mailing list, but came up mostly empty-handed. Thanks!

2 2

New Defects reported by Coverity Scan for coreboot
by scan-admin＠coverity.com 08 Apr '22

08 Apr '22

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 1 new defect(s) introduced to coreboot found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 1 of 1 defect(s) ** CID 1487871: Control flow issues (DEADCODE) /src/vendorcode/google/chromeos/watchdog.c: 35 in reset_watchdog_tombstone() ________________________________________________________________________________________________________ *** CID 1487871: Control flow issues (DEADCODE) /src/vendorcode/google/chromeos/watchdog.c: 35 in reset_watchdog_tombstone() 29 BOOT_STATE_INIT_ENTRY(BS_POST_DEVICE, BS_ON_ENTRY, 30 elog_handle_watchdog_tombstone, NULL); 31 32 bool reset_watchdog_tombstone(void) 33 { 34 if (!REGION_SIZE(watchdog_tombstone)) >>> CID 1487871: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "return false;". 35 return false; 36 37 bool flag = (read32(_watchdog_tombstone) == WATCHDOG_TOMBSTONE_MAGIC); 38 write32(_watchdog_tombstone, 0); 39 return flag; 40 } ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0

Elkhart Lake board bring up questions
by Dubravko Moravski | Exor Embedded S.r.l. 08 Apr '22

08 Apr '22

Hello Coreboot, I work for a company that makes a board containing an Elkhart Lake CPU and we use Coreboot to boot it. We have started from Intel's document #626123 source files and document #641906 for instructions. Release notes say "This is the main release of the coreboot Boot Loader Proof of Concept for the Elkhart Lake (EHL) series. Date: May 2021; revision: PR 1; description: PR 1 release" We have already asked Intel for assistance, but they redirected us here. The final Coreboot binary works, but we are having some issues that so far we were unable to solve on our own. We are using latest Linux Mint x64 for most of our tests and soon we'll switch to Yocto. 1. There are roughly about 200 configurable pins on the CPU. We would like to use some as GPIOs. We can configure pin functionalities according to our needs in Coreboot source code (gpio.c, gpio_table[] definition), but Linux doesn't seem to know what to do with GPIO pins: in /sys/class/gpio we only see gpiochip445. To which of the EHL pins does 445 correspond? What should we do to see the rest of the pins? Some comments in the code suggest there can't be more than 32 pins per 'gpiochip'. 2. We have enabled CAN controllers in devicetree.cb: device pci 18.1 on end # Intel Programmable Services Engine CAN0 device pci 18.2 on end # Intel Programmable Services Engine CAN1 ... but in Linux we don't see devices 0:18.1 and 0:18.2. What else should we do to enable CAN controllers? 3. How do we enable eSPI in Coreboot and how it should be accessible afterwards in Linux? We did: device pci 1f.0 on end # eSPI Interface Device 0:1f.0 is visible. How should we access this bus in Linux or declare a device in SSDT table on this bus? 4. We have a TPM chip SLB9670 connected to FSPI, CS2. device pci 1f.5 on end # PCH SPI (flash & TPM) ... and device 0:1f.5 is visible, but Linux kernel reports it couldn't find any TPM chip. What do we need to do to get it working? $ dmesg | grep -i tpm [ 0.006614] ACPI: TPM2 0x0000000075AEF4B0 00004C (v04 COREv4 COREBOOT 00000000 CORE 20200717) [ 0.006640] ACPI: Reserving TPM2 table memory at [mem 0x75aef4b0-0x75aef4fb] [ 0.771703] ima: No TPM chip found, activating TPM-bypass! 5. We can't get audio to work. device pci 1f.3 on end # cAVS/HDA ... and device 0:1f.3 is visible. This is output from kernel: $ dmesg | grep -i hda [ 5.559993] snd_hda_intel 0000:00:1f.3: DSP detected with PCI class/subclass/prog-if info 0x040100 [ 5.560003] snd_hda_intel 0000:00:1f.3: NHLT table not found [ 66.698806] snd_hda_intel 0000:00:1f.3: couldn't bind with audio component [ 66.731030] snd_hda_codec_hdmi hdaudioC0D2: No i915 binding for Intel HDMI/DP codec [ 66.731465] snd_hda_intel 0000:00:1f.3: Cannot probe codecs, giving up We think Linux should see (up to) 3 audio devices: HDMI, DisplayPort and analog codec CS4207. Thank you in advance for any advice. Dubravko Moravski SW engineering Exor Embedded S.r.l. p: +38 512455659<tel:+38%20512455659> m: +38 5915402413<tel:+38%205915402413> a: Slavonska avenija, 50, Zagreb, Croatia, 10000 w: exorint.com<https://exorint.com/> [cid:x-sign_alone_89a12ff2-fa07-4acd-b9a0-8e9a8c2b3e4c.jpg] [cid:environment-verde_4010c4a3-6fcf-4e6d-8a58-167a2248b283.jpg] Prima di stampare pensa ai costi ambientali. Please consider the environment before printing this email. Privacy<https://www.exorint.com/it/privacy>

3 2

[GSoC] Introduction & project ideas
by Théo Jehl 06 Apr '22

06 Apr '22

Hello! I'm Théo, a 1st-year master's student, specializing in embedded system engineering from France. I'm interested in joining Coreboot with the Google Summer of Code program. Currently, I have little to no experience in the firmware/boot world as I'm only starting in this field. At university I've learned operating systems architecture, I know how to write C/C++ and I started doing some X86 ASM. I also developed a disk driver, a file system and virtual memory mapping using an emulated MMU as part of a university project. I'm interested in porting a payload to ARM or AARCH64 [1] but I'm open to other project ideas if you have any. Thanks in advance Théo [1] https://doc.coreboot.org/contributing/project_ideas.html#port-payloads-to-a…

1 0

2022-04-06 - coreboot Leadership Meeting Minutes
by coreboot org 06 Apr '22

06 Apr '22

# 2022-04-06 - coreboot Leadership Meeting Minutes Next meeting - 2022-04-20 - See the calendar on the coreboot website for more information. ## Attendees Felix Held, Jay Talbott, Arthur Heymans, David Hendricks, Christian Walter, Stefan Reinauer, Lean Sheng Tan, Martin Roth, Matt Papageorge, Piotr Krol, Tim Crawford, Julius Werner, Felix Singer, Patrick Georgi ## Decisions * Let’s look at adding code to be able to combine romstage and ramstage. This is similar to what is currently done with combining verstage with either romstage or bootblock. * Send out surveys to coreboot consultants. * No reason to move Quark to a branch unless there's actually an issue. Felix S will link to the problematic code. ## Minutes * [Arthur] Let's look at a single stage (ramstage) on AMD platforms * We discussed a hybrid romstage before, but we really only need a ramstage at this point. None of the currently required code really needs to be in romstage however. We can move all of the required code into ramstage, which would dramatically simplify the code by removing everything passing between stages. * One stage means we can reference symbols directly without requiring linker scripts, cbmem additions, etc. * How would this work with Ron’s idea of getting rid of ramstage? * It would generally be a different configuration. * How much re-architecture would this require? * The idea wasn’t to rearchitect coreboot, just to add the calls that would normally happen in romstage to the beginning of ramstage. * Make ramstage callable as a function rather than treating it as a separate blob to jump to. * Let’s not make this a requirement or try to move all platforms to this flow. * [Martinr] Coreboot approved vendors - update website. * Send out a survey to all coreboot consultants. * [Julius]: libpayload CBFS API deprecation; please port payloads to new API. See the notice on the mailing list for more information. [1] * [Martin]: Moving Quark to a branch. [2] * We’re not “Deprecating platforms”, we’re moving their support to a branch. * [Jay]: Syspro has pushed a number of platform changes to the 4.11 branch. Supporting platforms there is not a problem. * Why would we move this out of the main branch? It uses FSP 2.0, and it’s the only open source fsp. * [Felix S] There’s some quark-only code that should probably be improved if quark is not getting removed. * [Martin] See if we can gather some information about what’s getting built to help decide what’s not actually being used anymore. * Would need to consult lawyers * This might cause more confusion than we even have * [Arthur] Update sdk docker for latest clang * This will be updated this week. * [FelixS] Thinking about doing a firmware hackathon in Darmstadt, Germany. Poll and some more details at the link. [3] * [Chris] 9elements / Foundation can sponsor food/place/whatever * @Felix - Get in contact with Sheng or Chris on that * This would happen June 10 - 12 June * [Jay]: Martin, any sign of the ITRenew server? * Not yet. :( * [David]: Porting Up Extreme to coreboot - whiskey lake platform * Having issues flashing with a dediprog * The UP Extreme boards have a unique port for flashing that needs an adapter. * 9elements has adapters that will make this work. * Can we figure out a way that people can get these created easily? * qspimux: https://github.com/felixheld/qspimux * David had issues getting the qspiMux boards manufactured at oshpark. Outlines too close to board edge - small violations of design rules, probably due to the castellated holes on the board adapters; that usually costs extra and not all manufacturers can do that. # Next meeting * The coreboot leadership meeting minutes are available here: [4] * The next coreboot leadership meeting will be 2022-04-20: [5] # Notice Decisions shown here are not necessarily final, and are based on the current information available. If there are questions or comments about decisions made, or additional information to present, please put it on the leadership meeting agenda and show up if possible to discuss it. Of course items may also be discussed on the mailing list, but as it's difficult to interpret tone over email, controversial topics frequently do not have good progress in those discussions. For particularly difficult issues, it may be best to try to schedule another meeting. [1]: https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/VLMK… [2]: https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/YRJQ… [3]: https://terminplaner4.dfn.de/pBooK8FBDlM2zDwa [4]: https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgK… [5]: https://calendar.google.com/event?action=TEMPLATE&tmeid=MzNhYm9rMmtxMnU1aWV…

1 0

[GSoC] Console via SMBus
by Ahamed Husni 05 Apr '22

05 Apr '22

Hi everyone, I would like to work with bringing up the Console via SMBus project [1]. This project requires a mainboard with pluggable RAM for the development so that we can use a RAM breakout board [2] to access the SMBus interface. Preferably the mainboard should already support coreboot. Please add your thoughts and concerns about the project and suggest a mainboard for the project :) [1] https://www.coreboot.org/Project_Ideas#console_via_SMBus [2] https://www.joom.com/en/products/5fa9df2ea1684001068ec310 Thank you, Husni.

2 2

Memtest 86+ fork
by Sameeruddin Shaik 03 Apr '22

03 Apr '22

Hi all, I wanted to work on below ticket https://ticket.coreboot.org/issues/184 Is there anyone working on it. Any inputs/hints would be appreciated. --sameer.

3 2

New Defects reported by Coverity Scan for coreboot
by scan-admin＠coverity.com 01 Apr '22

01 Apr '22

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 6 new defect(s) introduced to coreboot found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 6 of 6 defect(s) ** CID 1487636: Resource leaks (RESOURCE_LEAK) /util/cbfstool/fmd_parser.y: 173 in parse_descriptor() ________________________________________________________________________________________________________ *** CID 1487636: Resource leaks (RESOURCE_LEAK) /util/cbfstool/fmd_parser.y: 173 in parse_descriptor() 167 struct descriptor_node *next_node = cur_node->next; 168 free(cur_node); 169 cur_node = next_node; 170 } 171 } else { 172 region->list = NULL; >>> CID 1487636: Resource leaks (RESOURCE_LEAK) >>> Variable "region" going out of scope leaks the storage it points to. 173 } 174 return region; 175 } 176 177 void yyerror(const char *s) 178 { 179 fprintf(stderr, "%s\n", s); ** CID 1487635: Incorrect expression (SIZEOF_MISMATCH) /src/soc/qualcomm/common/qclib.c: 172 in qclib_load_and_run() ________________________________________________________________________________________________________ *** CID 1487635: Incorrect expression (SIZEOF_MISMATCH) /src/soc/qualcomm/common/qclib.c: 172 in qclib_load_and_run() 166 memset(_ddr_training, 0, REGION_SIZE(ddr_training)); 167 } 168 qclib_add_if_table_entry(QCLIB_TE_DDR_TRAINING_DATA, 169 _ddr_training, REGION_SIZE(ddr_training), 0); 170 171 /* Attempt to read MEM CHIP information */ >>> CID 1487635: Incorrect expression (SIZEOF_MISMATCH) >>> Passing argument "mem_chip_addr" of type "void *" and argument "8U /* sizeof (mem_chip_addr) */" to function "qclib_add_if_table_entry" is suspicious. 172 qclib_add_if_table_entry(QCLIB_TE_MEM_CHIP_INFO, 173 mem_chip_addr, sizeof(mem_chip_addr), 0); 174 175 /* Attempt to load PMICCFG Blob */ 176 data_size = cbfs_load(CONFIG_CBFS_PREFIX "/pmiccfg", 177 _pmic, REGION_SIZE(pmic)); ** CID 1487634: Integer handling issues (SIGN_EXTENSION) /src/cpu/intel/common/common_init.c: 226 in set_energy_perf_pref() ________________________________________________________________________________________________________ *** CID 1487634: Integer handling issues (SIGN_EXTENSION) /src/cpu/intel/common/common_init.c: 226 in set_energy_perf_pref() 220 * prefer energy efficiency. 221 * This function needs to be called when HWP_ENABLE is set. 222 */ 223 void set_energy_perf_pref(u8 pref) 224 { 225 msr_unset_and_set(IA32_HWP_REQUEST, IA32_HWP_REQUEST_EPP_MASK, >>> CID 1487634: Integer handling issues (SIGN_EXTENSION) >>> Suspicious implicit sign extension: "pref" with type "u8" (8 bits, unsigned) is promoted in "pref << 24" to type "int" (32 bits, signed), then sign-extended to type "unsigned long long" (64 bits, unsigned). If "pref << 24" is greater than 0x7FFFFFFF, the upper bits of the result will all be 1. 226 pref << IA32_HWP_REQUEST_EPP_SHIFT); ** CID 1487633: Error handling issues (CHECKED_RETURN) /src/drivers/i2c/tpm/cr50.c: 257 in cr50_i2c_tis_ready() ________________________________________________________________________________________________________ *** CID 1487633: Error handling issues (CHECKED_RETURN) /src/drivers/i2c/tpm/cr50.c: 257 in cr50_i2c_tis_ready() 251 } 252 253 /* cr50 requires all 4 bytes of status register to be written */ 254 static void cr50_i2c_tis_ready(struct tpm_chip *chip) 255 { 256 uint8_t buf[4] = { TPM_STS_COMMAND_READY }; >>> CID 1487633: Error handling issues (CHECKED_RETURN) >>> Calling "cr50_i2c_write" without checking return value (as is done elsewhere 4 out of 5 times). 257 cr50_i2c_write(TPM_STS(chip->vendor.locality), buf, sizeof(buf)); 258 mdelay(CR50_TIMEOUT_SHORT_MS); 259 } 260 261 /* cr50 uses bytes 3:2 of status register for burst count and 262 * all 4 bytes must be read */ ** CID 1487632: Null pointer dereferences (REVERSE_INULL) /src/drivers/wifi/generic/acpi.c: 539 in wifi_ssdt_write_properties() ________________________________________________________________________________________________________ *** CID 1487632: Null pointer dereferences (REVERSE_INULL) /src/drivers/wifi/generic/acpi.c: 539 in wifi_ssdt_write_properties() 533 534 static void wifi_ssdt_write_properties(const struct device *dev, const char *scope) 535 { 536 bool is_cnvi_ddr_rfim_enabled = false; 537 538 const struct drivers_wifi_generic_config *config = dev->chip_info; >>> CID 1487632: Null pointer dereferences (REVERSE_INULL) >>> Null-checking "dev" suggests that it may be null, but it has already been dereferenced on all paths leading to the check. 539 if (dev && config) 540 is_cnvi_ddr_rfim_enabled = config->enable_cnvi_ddr_rfim; 541 542 /* Scope */ 543 acpigen_write_scope(scope); 544 ** CID 1487631: Memory - corruptions (OVERRUN) ________________________________________________________________________________________________________ *** CID 1487631: Memory - corruptions (OVERRUN) /src/mainboard/google/herobrine/bootblock.c: 14 in bootblock_mainboard_init() 8 9 void bootblock_mainboard_init(void) 10 { 11 setup_chromeos_gpios(); 12 13 if (CONFIG(MAINBOARD_HAS_I2C_TPM_CR50)) >>> CID 1487631: Memory - corruptions (OVERRUN) >>> Overrunning callee's array of size 12 by passing argument "14U" in call to "i2c_init". 14 i2c_init(CONFIG_DRIVER_TPM_I2C_BUS, I2C_SPEED_FAST); /* H1/TPM I2C */ 15 16 if (CONFIG(MAINBOARD_HAS_SPI_TPM_CR50)) 17 qup_spi_init(CONFIG_DRIVER_TPM_SPI_BUS, 1010 * KHz); /* H1/TPM SPI */ 18 19 if (CONFIG(EC_GOOGLE_CHROMEEC)) 20 qup_spi_init(CONFIG_EC_GOOGLE_CHROMEEC_SPI_BUS, 1010 * KHz); /* EC SPI */ ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0

Support to Openpower platforms
by ratatouille gamer 01 Apr '22

01 Apr '22

the openpower have created this new firmware for boot openpower platforms is possible to coreboot use this base to write a new code for best support in openpower socs? https://github.com/open-power/hostboot

4 3

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