coreboot

coreboot@coreboot.org

6 participants
39687 discussions

Build breakage
by tcullen2018 11 Sep '21

11 Sep '21

Hi, I'm running into a problem following the steps at https://doc.coreboot.org/tutorial/part1.html on an Ubuntu 21.04 based system. The host compiler is gcc 10.3 and apparently CoreBoot has installed gcc 8.3.0 for its own usage but seems to be missing some required parts. Everything is good up until: tcullen@alien:~/src/coreboot$ make -C payloads/coreinfo ... LPGCC coreinfo.bin /home/tcullen/src/coreboot/util/crossgcc/xgcc/lib/gcc/x86_64-elf/8.3.0/../../../../x86_64-elf/bin/ld.bfd: build/cpuinfo_module.o: in function `cpuinfo_module_init': cpuinfo_module.c:(.text+0x45e): undefined reference to `__udivdi3' /home/tcullen/src/coreboot/util/crossgcc/xgcc/lib/gcc/x86_64-elf/8.3.0/../../../../x86_64-elf/bin/ld.bfd: build/timestamps_module.o: in function `timestamp_print_entry.constprop.1': timestamps_module.c:(.text+0x153): undefined reference to `__udivdi3' /home/tcullen/src/coreboot/util/crossgcc/xgcc/lib/gcc/x86_64-elf/8.3.0/../../../../x86_64-elf/bin/ld.bfd: timestamps_module.c:(.text+0x190): undefined reference to `__udivdi3' /home/tcullen/src/coreboot/util/crossgcc/xgcc/lib/gcc/x86_64-elf/8.3.0/../../../../x86_64-elf/bin/ld.bfd: /home/tcullen/src/coreboot/payloads/coreinfo/libpayload/libpayload.a(timer.libc.o): in function `get_cpu_khz_xtal': /home/tcullen/src/coreboot/payloads/libpayload/arch/x86/timer.c:121: undefined reference to `__udivdi3' /home/tcullen/src/coreboot/util/crossgcc/xgcc/lib/gcc/x86_64-elf/8.3.0/../../../../x86_64-elf/bin/ld.bfd: /home/tcullen/src/coreboot/payloads/libpayload/arch/x86/timer.c:121: undefined reference to `__udivdi3' /home/tcullen/src/coreboot/util/crossgcc/xgcc/lib/gcc/x86_64-elf/8.3.0/../../../../x86_64-elf/bin/ld.bfd: /home/tcullen/src/coreboot/payloads/coreinfo/libpayload/libpayload.a(timer.libc.o):/home/tcullen/src/coreboot/payloads/libpayload/arch/x86/timer.c:78: more undefined references to `__udivdi3' follow /home/tcullen/src/coreboot/util/crossgcc/xgcc/lib/gcc/x86_64-elf/8.3.0/../../../../x86_64-elf/bin/ld.bfd: /home/tcullen/src/coreboot/payloads/coreinfo/libpayload/libpayload.a(printf.libc.o): in function `print_number': /home/tcullen/src/coreboot/payloads/libpayload/libc/printf.c:261: undefined reference to `__udivmoddi4' /home/tcullen/src/coreboot/util/crossgcc/xgcc/lib/gcc/x86_64-elf/8.3.0/../../../../x86_64-elf/bin/ld.bfd: /home/tcullen/src/coreboot/payloads/coreinfo/libpayload/libpayload.a(time.libc.o): in function `update_clock': /home/tcullen/src/coreboot/payloads/libpayload/libc/time.c:59: undefined reference to `__udivdi3' /home/tcullen/src/coreboot/util/crossgcc/xgcc/lib/gcc/x86_64-elf/8.3.0/../../../../x86_64-elf/bin/ld.bfd: /home/tcullen/src/coreboot/payloads/libpayload/libc/time.c:64: undefined reference to `__udivdi3' /home/tcullen/src/coreboot/util/crossgcc/xgcc/lib/gcc/x86_64-elf/8.3.0/../../../../x86_64-elf/bin/ld.bfd: /home/tcullen/src/coreboot/payloads/libpayload/libc/time.c:67: undefined reference to `__udivdi3' /home/tcullen/src/coreboot/util/crossgcc/xgcc/lib/gcc/x86_64-elf/8.3.0/../../../../x86_64-elf/bin/ld.bfd: /home/tcullen/src/coreboot/payloads/coreinfo/libpayload/libpayload.a(time.libc.o): in function `arch_ndelay': /home/tcullen/src/coreboot/payloads/libpayload/libc/time.c:166: undefined reference to `__udivdi3' /home/tcullen/src/coreboot/util/crossgcc/xgcc/lib/gcc/x86_64-elf/8.3.0/../../../../x86_64-elf/bin/ld.bfd: /home/tcullen/src/coreboot/payloads/coreinfo/libpayload/libpayload.a(time.libc.o): in function `timer_us': /home/tcullen/src/coreboot/payloads/libpayload/libc/time.c:185: undefined reference to `__udivdi3' collect2: error: ld returned 1 exit status make: *** [../libpayload/Makefile.payload:91: build/coreinfo.bin] Error 1 make: Leaving directory '/home/tcullen/src/coreboot/payloads/coreinfo' Regards, Tim Cullen Sent with [ProtonMail](https://protonmail.com/) Secure Email.

2 1

ECC in native ram init? (sandy/ivy)
by Matt B 10 Sep '21

10 Sep '21

Greetings, I gather that while native ram init is very far along and quite featureful, it doesn't support ECC. I'm interested to know if there have been past attempts at it, and what might be required for it to work. In the unofficial mapping [1] it looks like there's just one register to turn it on, plus some registers to inject faults for testing. (I imagine you would also need to clear the memory to avoid lots of errors from random initial contents, and make sure all the DIMMS are the same type first) It certainly "looks" simple (famous last words) so I'm wondering in part if the unofficial register documentation is just very incomplete? Is there any intel guidance on ECC out there? I suppose having ECC is attractive for servers, though I don't think people would still run ivybridge/sandybridge in production. I'm more interested in it for the Optiplex 9010 which appears to support ECC on the factory BIOS. [2] Would make a really nice NAS (external SAS disk shelf) if ECC worked under coreboot. Would also get bonus points as a daily-driver/home server from me. [1] https://doc.coreboot.org/northbridge/intel/sandybridge/nri_registers.html Sincerely, -Matthew Bradley

4 7

Currently broken devicetrees (was Re: X200 dock has been broken since November 2019)
by Nico Huber 07 Sep '21

07 Sep '21

Hi all, that we had another case of a missing-device-below-chip in a devicetree made me write a patch for `sconfig` [1]. Now that it's checking for the issue, that uncovered a few (31) more cases [2] that need to be fixed before upstream can benefit from the patch. Please help to fix the devicetrees. Note, `sconfig` currently doesn't print the file name of override trees, e.g. when it says SCONFIG mainboard/.../devicetree.cb line 10: end: syntax error that might as well refer to line 10 in an override tree. Nico [1] https://review.coreboot.org/c/coreboot/+/51119 [2] https://qa.coreboot.org/job/coreboot-gerrit/164572/ Failing boards: board.AMD_BILBY board.AMD_CEREME board.AMD_MANDOLIN board.GETAC_P470 board.GOOGLE_BRYA0 board.GOOGLE_FALCO board.GOOGLE_PEPPY board.GOOGLE_WOLF board.KONTRON_BSL6 board.LENOVO_R500 board.LENOVO_T430S board.LENOVO_T431S board.LENOVO_T520 board.LENOVO_T530 board.LENOVO_W530 board.LENOVO_X1 board.LENOVO_X220 board.LENOVO_X220I board.LENOVO_X220_MRC_BIN board.LENOVO_X220_OPTION_TABLE_DEBUG_TPM_EXTENDED_CBFS board.LENOVO_X230 board.LENOVO_X230S board.LENOVO_X230T board.LENOVO_X301 board.LENOVO_X60 board.RODA_RK886EX board.SIEMENS_BOXER26

1 1

[coreboot - Bug #321] (New) NVME in X16 port issue
by coreboot＠fe80.eu 07 Sep '21

07 Sep '21

Issue #321 has been reported by Francois Ollonois. ---------------------------------------- Bug #321: NVME in X16 port issue https://ticket.coreboot.org/issues/321 * Author: Francois Ollonois * Status: New * Priority: Normal * Assignee: * Category: * Target version: ---------------------------------------- I have used latest git version of coreboot to build a rom for my ASUS P5QL-EM. I have some strange behavior: I use a **X16 nvme** Adapter in the X16 graphic card slot. I also want to use an add-on gpu card (nvidia GT710 **PCIe X1**) to be able to use higher resolution displays. With the bare board without any card everything works fine, but when I plug in the nvme adapter card with ssd, only the VGA output is working, but it is shiftet one character to the left. HDMI and DVI output are dead. It is possible to boot from the nvme ssd in this configuration. When the GT710 is pluged in, it is no longer possible to boot from the nvme ssd. (Read Error) ---Files-------------------------------- p5ql-em.config (17 KB) -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account

1 0

Supermicro X10SLM-F / Gerrit and how to contribute
by Andreas Bauer 07 Sep '21

07 Sep '21

Dear all, the other day I sucessfully flashed a X10SLM-F board to recent coreboot, and discovered an inaccuracy in coreboot src for that board. It seems that the original board support was developped on a X10SLM+-F which has two Intel I120-AT network chips. The board I flashed on the other hand is called X10SLM-F (missing the +) and has one I210 and one I217 network chip. To correct the error, I created a variant directory and overrode the devicetree.cb with the correct configuration for the board. Then I had a look at https://doc.coreboot.org/getting_started/gerrit_guidelines.html and now wonder how I can contribute a patch via Gerrit? I do not have any OpenID nor do I wish to use any commercial entity. Note that I am also in the process to divest all my data from Google, so I would prefer to not to use the parts of my Google account still left. Is there a way to contribute to Coreboot Gerrit in a privacy friendly manner using just an email address and not having my data shared with any commercial entity? Thanks, Andreas

2 1

New Kabylake-U Laptop (Acer Aspire F5-573)
by Andreas Bauer 07 Sep '21

07 Sep '21

Dear all, The Acer Aspire F5-573G is a low-cost laptop of the Kabylake-U platform with 6th gen i7-7500U CPU and Intel IGD 620. Stock it comes with an Insidesys H2O BIOS on a Macronix 64Mbit flash, which can be programmed in place with lastest flashrom. While low-cost in many aspects (including a really cheap display), one of the things I really like about the laptop is it's spectacular low power-consumption. It can idle at around 4.2W in a desktop environment with Wifi enabled and display at indoor brightness and go down to 2.3W at minimum brightness with Wifi disabled. I have made initial attempts to run the latest coreboot instead of the vendor bios, and based my attempts on similar Kabylake platforms. This is how far I got: | coreboot-4.14-1637-g51d0be751c-test6 Sat Sep 4 05:41:24 UTC 2021 romstage starting (log level: 8)... | pm1_sts: 0100 pm1_en: 0000 pm1_cnt: 00001c00 | gpe0_sts[0]: 00000000 gpe0_en[0]: 00000000 | gpe0_sts[1]: 00000000 gpe0_en[1]: 00000000 | gpe0_sts[2]: 00000000 gpe0_en[2]: 00000000 | gpe0_sts[3]: 00000000 gpe0_en[3]: 00000000 | TCO_STS: 0000 0000 | GEN_PMCON: d0040000 0000700a | GBLRST_CAUSE: 00000000 00000000 | prev_sleep_state 5 | FMAP: area COREBOOT found @ 630200 (1900032 bytes) | CBFS: Found 'fspm.bin' @0x9adc0 size 0x63000 in mcache @0xfef05080 | FMAP: area RW_MRC_CACHE found @ 620000 (65536 bytes) | MRC: no data in 'RW_MRC_CACHE' | bootmode is set to: 0 | SPD @ 0x52 | SPD: module type is DDR4 | SPD: module part number is | SPD: banks 8, ranks 1, rows 16, columns 10, density 8192 Mb | SPD: device width 16 bits, bus width 64 bits | SPD: module size is 4096 MB (per channel) | FspMemoryInit returned 0x80000007 | FspMemoryInit returned an error! | XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Here is romstage.c which I mostly copied from similar platforms and changed the I2C address of the SPD: | void mainboard_memory_init_params(FSPM_UPD *mupd) | { | const u16 rcomp_resistors[3] = { 121, 81, 100 }; | | const u16 rcomp_targets[5] = { 100, 40, 20, 20, 26 }; | | FSP_M_CONFIG *mem_cfg = &mupd->FspmConfig; | | struct spd_block blk = { | .addr_map = { 0x52 } | }; | | assert(sizeof(mem_cfg->RcompResistor) == sizeof(rcomp_resistors)); | assert(sizeof(mem_cfg->RcompTarget) == sizeof(rcomp_targets)); | | get_spd_smbus(&blk); | dump_spd_info(&blk); | assert(blk.spd_array[0][0] != 0); | | memcpy(mem_cfg->RcompResistor, rcomp_resistors, sizeof(mem_cfg->RcompResistor)); | memcpy(mem_cfg->RcompTarget, rcomp_targets, sizeof(mem_cfg->RcompTarget)); | | mem_cfg->DqPinsInterleaved = TRUE; | mem_cfg->MemorySpdDataLen = blk.len; | mem_cfg->MemorySpdPtr00 = (uintptr_t) blk.spd_array[0]; | } The DIMM is an A-DATA AM1P24HC4U1-B9RS. What could be the reason for the 0x80000007 (EFI_ERROR ?) return from FspMemoryInit()? If any other parameters are missing, how do you go to extract them from the vendor bios? Andreas

1 0

Which Mainboard for a gaming PC? Recommendations
by Paul Gerdes 06 Sep '21

06 Sep '21

Hi I am looking for a coreboot supported Mainboard for a midrange gaming PC. I would use it mostly for gaming with Steam on Linux, some Photo editing and work. Which Boards would you recommend for this? And how is your experience with gaming on a corebooted PC? Thanks a lot! P.G.

1 0

[coreboot - Feature #320] (New) T440p: Does not display fan RPM
by coreboot＠fe80.eu 04 Sep '21

04 Sep '21

Issue #320 has been reported by Daniel Kulesz. ---------------------------------------- Feature #320: T440p: Does not display fan RPM https://ticket.coreboot.org/issues/320 * Author: Daniel Kulesz * Status: New * Priority: Normal * Assignee: * Category: * Target version: ---------------------------------------- With the OEM firmware, the fan RPM are displayed in the `sensors` output in Linux. After flashing coreboot, this value is no longer displayed. The CPU temperatures etc. still work fine, only the fan RPMs are missing. Would be great to have it. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account

1 0

[coreboot - Feature #319] (New) denverton_ns: Add ASL to support Linux pinctrl driver (GPIO controller)
by coreboot＠fe80.eu 02 Sep '21

02 Sep '21

Issue #319 has been reported by King Sumo. ---------------------------------------- Feature #319: denverton_ns: Add ASL to support Linux pinctrl driver (GPIO controller) https://ticket.coreboot.org/issues/319 * Author: King Sumo * Status: New * Priority: Normal * Assignee: * Category: * Target version: ---------------------------------------- ASL code to support the Linux pinctrl driver is missing for denverton_ns platform, the below patch adds the very basic functionality in order to Linux driver find the GPIO controller via INTC3000 APCI id: https://review.coreboot.org/c/coreboot/+/56975 soc/intel/denverton_ns: Add GPIO controller ASL Add support for the pinctrl denverton Linux driver which provides an interface that allows configuring of Intel Denverton SoC pins and using them as GPIOs. Test using the sysfs interface: - Load the pinctrl-denverton module, sysfs interface available in the /sys/kernel/debug/pinctrl/INTC3000\:00 folder. - Export the GPIO (here we are using GPIO_10): ~> cd /sys/kernel/debug/pinctrl/INTC3000\:00/ ~> grep GPIO_10 pinconf-pins pin 139 (GPIO_10): input bias disabled ~> cat gpio-ranges GPIO ranges handled: 0: INTC3000:00 GPIOS [358 - 511] PINS [0 - 153] ~> echo $((358+139)) > /sys/class/gpio/export - Above GPIO's are starting at 358 with GPIO_10 at 139 offset, the sysfs folder for controlling the pin will be /sys/class/gpio/gpio497 (358+139). - Input mode: ~> cd /sys/class/gpio/gpio497 ~> echo in > direction ~> cat value 0 ~> cat value 1 - Output mode: ~> cd /sys/class/gpio/gpio497 ~> echo out > direction ~> echo 1 > value ~> echo 0 > value -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account

1 0

[coreboot - Bug #318] (New) denverton_ns: Fix MRC cache write
by coreboot＠fe80.eu 02 Sep '21

02 Sep '21

Issue #318 has been reported by King Sumo. ---------------------------------------- Bug #318: denverton_ns: Fix MRC cache write https://ticket.coreboot.org/issues/318 * Author: King Sumo * Status: New * Priority: Normal * Assignee: * Category: * Target version: ---------------------------------------- The RW_MRC_CACHE write is broken in denverton_ns platforms. More info: https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/message/26Y… https://review.coreboot.org/c/coreboot/+/57033 (patch set as abandoned, it was already agreed with Mariusz to proceed the codereview process). -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot