coreboot February 2023

coreboot@coreboot.org

28 participants
52 discussions

[coreboot - Bug #457] (New) Haswell (t440p): CAR memory region should not conflict with CBFS_SIZE > 8mb
by Thierry Laurion 08 Feb '23

08 Feb '23

Issue #457 has been reported by Thierry Laurion. ---------------------------------------- Bug #457: Haswell (t440p): CAR memory region should not conflict with CBFS_SIZE > 8mb https://ticket.coreboot.org/issues/457 * Author: Thierry Laurion * Status: New * Priority: Normal * Target version: none * Start date: 2023-02-08 * Affected versions: 4.19, master ---------------------------------------- When neutering ME to pass freed space to IFD BIOS region (and having CBFS_SIZE match maximized IFD region), booting of the platform was reported to take an additional 20 seconds. A quick review at FOSDEM with a coreboot dev inspecting current Haswell code suggested that fixing DCACHE_RAM_BASE might fix the issue under src/northbridge/intel/haswell/Kconfig: 0xff7c0000 -> 0xfe7c0000 ----- Unfortunately, I have no access to a t440p to test the fix. It was also suggested that mrc.bin might need to be patched as well. But 4.19 is bringing native raminit, so that might not be an issue? Attached is the suggested change to be tested. ---Files-------------------------------- haswell_car_20230205233221.patch (369 Bytes) -- 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

2 1

New Defects reported by Coverity Scan for coreboot
by scan-admin＠coverity.com 07 Feb '23

07 Feb '23

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. 2 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 6 of 6 defect(s) ** CID 1504475: (PRINTF_ARGS) ________________________________________________________________________________________________________ *** CID 1504475: (PRINTF_ARGS) /util/cbfstool/eventlog.c: 492 in eventlog_print_data() 486 [ELOG_TYPE_FW_VBOOT_INFO] = sizeof(uint16_t), 487 [ELOG_TYPE_FW_EARLY_SOL] = sizeof(uint8_t), 488 [0xff] = 0, 489 }; 490 491 if (event->length <= sizeof(*event) + elog_type_to_min_size[event->type]) { >>> CID 1504475: (PRINTF_ARGS) >>> Argument "event->length - 8UL" to format specifier "%u" was expected to have type "unsigned int" but has type "unsigned long". 492 eventlog_printf("INVALID DATA (length = %u)", event->length - sizeof(*event)); 493 return 0; 494 } 495 496 switch (event->type) { 497 case ELOG_TYPE_LOG_CLEAR: { /util/cbfstool/eventlog.c: 626 in eventlog_print_data() 620 eventlog_printf("boot_mode=%s", vb2_boot_mode_string(info->boot_mode)); 621 622 if (info->boot_mode == VB2_BOOT_MODE_BROKEN_SCREEN || 623 info->boot_mode == VB2_BOOT_MODE_MANUAL_RECOVERY) { 624 if (event->length <= sizeof(*event) + sizeof(*info)) 625 eventlog_printf("INVALID DATA (length = %u)", >>> CID 1504475: (PRINTF_ARGS) >>> Argument "event->length - 8UL" to format specifier "%u" was expected to have type "unsigned int" but has type "unsigned long". 626 event->length - sizeof(*event)); 627 else 628 eventlog_printf("recovery_reason=%#x/%#x (%s)", 629 info->recovery_reason, info->recovery_subcode, 630 vb2_get_recovery_reason_string(info->recovery_reason)); 631 } ** CID 1451331: Null pointer dereferences (NULL_RETURNS) /util/goswid/vendor/gopkg.in/yaml.v3/parserc.go: 925 in yaml.v3.yaml_parser_parse_flow_sequence_entry(*yaml.v3.yaml_parser_t, *yaml.v3.yaml_event_t, bool)bool() ________________________________________________________________________________________________________ *** CID 1451331: Null pointer dereferences (NULL_RETURNS) /util/goswid/vendor/gopkg.in/yaml.v3/parserc.go: 925 in yaml.v3.yaml_parser_parse_flow_sequence_entry(*yaml.v3.yaml_parser_t, *yaml.v3.yaml_event_t, bool)bool() 919 // flow_sequence_entry ::= flow_node | KEY flow_node? (VALUE flow_node?)? 920 // * 921 // 922 func yaml_parser_parse_flow_sequence_entry(parser *yaml_parser_t, event *yaml_event_t, first bool) bool { 923 if first { 924 token := peek_token(parser) >>> CID 1451331: Null pointer dereferences (NULL_RETURNS) >>> Accessing field of null object "token". 925 parser.marks = append(parser.marks, token.start_mark) 926 skip_token(parser) 927 } 928 token := peek_token(parser) 929 if token == nil { 930 return false ** CID 1451317: Null pointer dereferences (NULL_RETURNS) /util/goswid/vendor/gopkg.in/yaml.v3/parserc.go: 816 in yaml.v3.yaml_parser_parse_block_mapping_key(*yaml.v3.yaml_parser_t, *yaml.v3.yaml_event_t, bool)bool() ________________________________________________________________________________________________________ *** CID 1451317: Null pointer dereferences (NULL_RETURNS) /util/goswid/vendor/gopkg.in/yaml.v3/parserc.go: 816 in yaml.v3.yaml_parser_parse_block_mapping_key(*yaml.v3.yaml_parser_t, *yaml.v3.yaml_event_t, bool)bool() 810 // BLOCK-END 811 // ********* 812 // 813 func yaml_parser_parse_block_mapping_key(parser *yaml_parser_t, event *yaml_event_t, first bool) bool { 814 if first { 815 token := peek_token(parser) >>> CID 1451317: Null pointer dereferences (NULL_RETURNS) >>> Accessing field of null object "token". 816 parser.marks = append(parser.marks, token.start_mark) 817 skip_token(parser) 818 } 819 820 token := peek_token(parser) 821 if token == nil { ** CID 1451316: Null pointer dereferences (NULL_RETURNS) /util/goswid/vendor/gopkg.in/yaml.v3/parserc.go: 789 in yaml.v3.yaml_parser_split_stem_comment(*yaml.v3.yaml_parser_t, int)() ________________________________________________________________________________________________________ *** CID 1451316: Null pointer dereferences (NULL_RETURNS) /util/goswid/vendor/gopkg.in/yaml.v3/parserc.go: 789 in yaml.v3.yaml_parser_split_stem_comment(*yaml.v3.yaml_parser_t, int)() 783 func yaml_parser_split_stem_comment(parser *yaml_parser_t, stem_len int) { 784 if stem_len == 0 { 785 return 786 } 787 788 token := peek_token(parser) >>> CID 1451316: Null pointer dereferences (NULL_RETURNS) >>> Accessing field of null object "token". 789 if token.typ != yaml_BLOCK_SEQUENCE_START_TOKEN && token.typ != yaml_BLOCK_MAPPING_START_TOKEN { 790 return 791 } 792 793 parser.stem_comment = parser.head_comment[:stem_len] 794 if len(parser.head_comment) == stem_len { ** CID 1451308: Null pointer dereferences (NULL_RETURNS) /util/goswid/vendor/gopkg.in/yaml.v3/parserc.go: 690 in yaml.v3.yaml_parser_parse_block_sequence_entry(*yaml.v3.yaml_parser_t, *yaml.v3.yaml_event_t, bool)bool() ________________________________________________________________________________________________________ *** CID 1451308: Null pointer dereferences (NULL_RETURNS) /util/goswid/vendor/gopkg.in/yaml.v3/parserc.go: 690 in yaml.v3.yaml_parser_parse_block_sequence_entry(*yaml.v3.yaml_parser_t, *yaml.v3.yaml_event_t, bool)bool() 684 // block_sequence ::= BLOCK-SEQUENCE-START (BLOCK-ENTRY block_node?)* BLOCK-END 685 // ******************** *********** * ********* 686 // 687 func yaml_parser_parse_block_sequence_entry(parser *yaml_parser_t, event *yaml_event_t, first bool) bool { 688 if first { 689 token := peek_token(parser) >>> CID 1451308: Null pointer dereferences (NULL_RETURNS) >>> Accessing field of null object "token". 690 parser.marks = append(parser.marks, token.start_mark) 691 skip_token(parser) 692 } 693 694 token := peek_token(parser) 695 if token == nil { ** CID 1451305: Null pointer dereferences (NULL_RETURNS) /util/goswid/vendor/gopkg.in/yaml.v3/parserc.go: 1060 in yaml.v3.yaml_parser_parse_flow_mapping_key(*yaml.v3.yaml_parser_t, *yaml.v3.yaml_event_t, bool)bool() ________________________________________________________________________________________________________ *** CID 1451305: Null pointer dereferences (NULL_RETURNS) /util/goswid/vendor/gopkg.in/yaml.v3/parserc.go: 1060 in yaml.v3.yaml_parser_parse_flow_mapping_key(*yaml.v3.yaml_parser_t, *yaml.v3.yaml_event_t, bool)bool() 1054 // flow_mapping_entry ::= flow_node | KEY flow_node? (VALUE flow_node?)? 1055 // * *** * 1056 // 1057 func yaml_parser_parse_flow_mapping_key(parser *yaml_parser_t, event *yaml_event_t, first bool) bool { 1058 if first { 1059 token := peek_token(parser) >>> CID 1451305: Null pointer dereferences (NULL_RETURNS) >>> Accessing field of null object "token". 1060 parser.marks = append(parser.marks, token.start_mark) 1061 skip_token(parser) 1062 } 1063 1064 token := peek_token(parser) 1065 if token == nil { ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0

[coreboot - Bug #449] ThinkPad T440p fail to start, continous beeping & LED blinking
by Angel Pons 07 Feb '23

07 Feb '23

Issue #449 has been updated by Angel Pons. https://review.coreboot.org/72806 fixes the UBSAN errors, please review. Note that UBSAN-enabled coreboot still dies later on: ``` Loading module at 0x00030000 with entry 0x00030000. filesize: 0x178 memsize: 0x178 Processing 16 relocs. Offset value of 0x00030000 unaligned access src/lib/rmodule.c:152:27 ubsan: unrecoverable error. ``` So, any users that desire to have a bootable system should keep UBSAN disabled when building coreboot. ---------------------------------------- Bug #449: ThinkPad T440p fail to start, continous beeping & LED blinking https://ticket.coreboot.org/issues/449#change-1394 * Author: Crazy Fox * Status: In Progress * Priority: Normal * Assignee: Angel Pons * Category: board support * Target version: 4.18 * Start date: 2023-01-14 * Affected versions: 4.19 * Related links: The USBAN error is: ``` [ERROR] shift out of bounds src/northbridge/intel/haswell/pcie.c:85:22 [EMERG] ubsan: unrecoverable error. ``` * Affected hardware: haswell ---------------------------------------- Hi, Team Being corebooted before and works fine on 4.17. After flashing 4.18 my t440p wont startup (black screen, constant beeping & LED blinking). I've tried and retried different nconfigs but result is the same. I know that it is lack of information, but I need to recover the laptop first to grab some logs from it. Log from FT232H's debug is attached, the rest of info (defconfig, flashrom command etc. will upload soon) ---Files-------------------------------- coreboot_t440p_emerg.log (7.85 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

Cr50 is not the only Google security chip
by Vadim Bendebury 06 Feb '23

06 Feb '23

Hello fellow Coreboot enthusiasts, I am not sure if I am the only one annoyed/confused when I see coreboot messages like "Error reading from Cr50" or "Did not recognize Cr50 version format", etc. while the device in fact is using a different GSC (Google Security Chip). Before I go for it - would there be objections to changing the source code (including path and file name changes) from Cr50 to GSC where appropiate? TIA, -vb

1 0

regarding nvme timeout while boot via SeaBIOS
by ritul guru 06 Feb '23

06 Feb '23

Hi All, I am trying to boot to Ubuntu OS on NVMe SSD, NVMe device does get detected but with SeaBIOS payload, observing timeout on nvme_wait, Appreciate any hint to debug this issue. Logs: All threads complete. Searching bootorder for: /pci@i0cf8/*@14,6 All threads complete. Searching bootorder for: HALT Found 0 lpt ports Found 0 serial ports Searching bootorder for: /pci@i0cf8/pci-bridge@2,4/*@0 All threads complete. Scan for option roms Press ESC for boot menu. Searching bootorder for: HALT drive 0x000f6720: PCHS=0/0/0 translation=lba LCHS=1024/255/63 s=1000215216 Space available for UMB: c0000-ed000, f5fe0-f6720 Returned 225280 bytes of ZoneHigh e820 map has 16 items: 0: 0000000000000000 - 000000000009fc00 = 1 RAM 1: 000000000009fc00 - 00000000000a0000 = 2 RESERVED 2: 00000000000f0000 - 0000000000100000 = 2 RESERVED 3: 0000000000100000 - 0000000002000000 = 1 RAM 4: 0000000002000000 - 0000000002182000 = 2 RESERVED 5: 0000000002182000 - 000000005aee7000 = 1 RAM 6: 000000005aee7000 - 000000005d000000 = 2 RESERVED 7: 000000005d790000 - 000000005d7f0000 = 2 RESERVED 8: 000000005d7f0000 - 000000005d7f5000 = 1 RAM 9: 000000005d7f5000 - 0000000060000000 = 2 RESERVED 10: 00000000e0000000 - 00000000f0000000 = 2 RESERVED 11: 00000000fec10000 - 00000000fec11000 = 2 RESERVED 12: 00000000fedc2000 - 00000000fedc6000 = 2 RESERVED 13: 00000000fedc9000 - 00000000fedca000 = 2 RESERVED 14: 0000000100000000 - 000000047e300000 = 1 RAM 15: 000000047f340000 - 00000004a0000000 = 2 RESERVED enter handle_19: NULL Booting from Hard Disk... Booting from 0000:7c00 WARNING - Timeout at nvme_wait:147! WARNING - Timeout at nvme_wait:147! WARNING - Timeout at nvme_wait:147! WARNING - Timeout at nvme_wait:147! WARNING - Timeout at nvme_wait:147! *Thanks & RegardsRitul Guru+91-9916513186*

2 2

regarding edk2 payload to boot to uefi aware OS
by ritul guru 06 Feb '23

06 Feb '23

Hi, In earlier coreboot, there was a tianocore payload which has 1. CorebootPayload 2. UEFIPayload I used to boot with CorebootPayload to UEFI aware OS. I see, now it is edk2 payload, is CorebootPayload deprecated? and building alone uefipayload.fd is enough to boot to UEFI aware OS with coreboot BIOS? *Thanks & RegardsRitul Guru+91-9916513186*

2 2

Recent board removal for deprecated features LEGACY_SMP_INIT and RESOURCE_ALLOCATOR_V3
by Paul Menzel 05 Feb '23

05 Feb '23

Dear coreboot folks, Two days ago, on November 7th, the change-sets of the topic *drop_LEGACY_SMP_INIT* [1] were submitted after being created on November 2nd [2]. The removal was announced on the list some time ago and was documented in the release notes. 1. RESOURCE_ALLOCATOR_V3 in the 4.16 release notes [3] 2. LEGACY_SMP_INIT in the 4.16, 4.17, and 4.18 release notes [4] (I think that planned deprecations should to be listed in each release note.) Despite the missing RESOURCE_ALLOCATOR_V3 deprecation announcement in 4.17 and 4.18, everything was done formally correct, nevertheless I would have wished, more time would have been given and the actions would have been announced once more on the mailing list. My understanding was always, that code removal will be handled more leniently, if the required changes are being worked on. This was the case here for parallel SMP init [5] and resource allocator v4 [6]. Some change-sets even had a +1 or +2. The request for testing was also fulfilled by the users. Some of the change-sets were even authored by “non-AGESA“ folks, which was awesome to see. Letting this effort go to waste without documenting somewhere, what needed to be done to finish these change-sets makes me sad. 3mdeb also invested resources into implementing some of the features. The last thing I noticed, that at least for the PC Engines board removal, the approval of the maintainers listed in `MAINTAINERS` was not given, and should have been waited for. The +2 itself were also by developers normally not (very) active with AMD AGESA Open Source boards. The points above are just my observations, and, hopefully, things can improve in the future to avoid bad feelings. I am thankful to everyone working on coreboot, and I also understand the frustration of having to maintain several code paths. Although I own and run two of the removed boards, I am fine to move to the branch *4.18_branch* although I am not happy about it, as branches also increase maintenance burden. The main reason for writing this message is to ask, if entities (read 3mdeb) have big interest in getting part of the boards back into the master branch, so that the already made investments are not in vain, and nobody is alienated from working upstream. If that is a goal, this effort should be coordinated as reverting commits is going to become harder and harder. mb/aopen/dxplplusu (Intel) is already worked on to be put back into the master branch [7]. Kind regards, Paul [1]: https://review.coreboot.org/q/topic:drop_LEGACY_SMP_INIT [2]: https://review.coreboot.org/c/coreboot/+/69111/2 [3]: https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/tags/4.18/Docum… [4]: https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/tags/4.18/Docum… [5]: https://review.coreboot.org/c/coreboot/+/64892 "cpu/amd/family15: Use parallel_mp init" [6]: https://review.coreboot.org/c/coreboot/+/53990 "nb/amd/agesa/family15tn: Enable RESOURCE_ALLOCATOR_V4" [7]: https://review.coreboot.org/c/coreboot/+/69339 "Revert "mb/aopen/dxplplusu: Remove board""

3 2

[coreboot - Bug #453] (New) Intel HDMI / DP Audio device not showing up after libgfxinit
by CoolStar Organization 05 Feb '23

05 Feb '23

Issue #453 has been reported by CoolStar Organization. ---------------------------------------- Bug #453: Intel HDMI / DP Audio device not showing up after libgfxinit https://ticket.coreboot.org/issues/453 * Author: CoolStar Organization * Status: New * Priority: Normal * Target version: none * Start date: 2023-02-05 * Affected versions: master * Needs backport to: 4.15 * Affected hardware: All boards with libgfxinit * Affected OS: Windows 8.1, Windows 10, macOS, Linux ---------------------------------------- Intel HDMI / DP Audio device does not appear on the HD Audio bus after running libgfxinit until after GPU driver initializes in the OS. This can cause a race condition on certain OS's, especially if HDA enumeration runs before the GPU driver initializes the card in the OS (or happens if the GPU driver doesn't run at all, which can happen on all OS's with boot args or uninstalling the GPU driver) -- 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 1

[coreboot - Bug #449] ThinkPad T440p fail to start, continous beeping & LED blinking
by Crazy Fox 05 Feb '23

05 Feb '23

Issue #449 has been updated by Crazy Fox. Affected versions 4.19 added Affected versions deleted (4.18) Felix Singer wrote in #note-4: > Does this issue also occur on 4.19 and/or master? Would be great if you could test this. Yes, yesterday I've checked it and still occur on 4.19 ---------------------------------------- Bug #449: ThinkPad T440p fail to start, continous beeping & LED blinking https://ticket.coreboot.org/issues/449#change-1392 * Author: Crazy Fox * Status: In Progress * Priority: Normal * Assignee: Angel Pons * Category: board support * Target version: 4.18 * Start date: 2023-01-14 * Affected versions: 4.19 * Related links: The USBAN error is: ``` [ERROR] shift out of bounds src/northbridge/intel/haswell/pcie.c:85:22 [EMERG] ubsan: unrecoverable error. ``` * Affected hardware: haswell ---------------------------------------- Hi, Team Being corebooted before and works fine on 4.17. After flashing 4.18 my t440p wont startup (black screen, constant beeping & LED blinking). I've tried and retried different nconfigs but result is the same. I know that it is lack of information, but I need to recover the laptop first to grab some logs from it. Log from FT232H's debug is attached, the rest of info (defconfig, flashrom command etc. will upload soon) ---Files-------------------------------- coreboot_t440p_emerg.log (7.85 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

Status of maintained boards and policies?
by Denis 'GNUtoo' Carikli 03 Feb '23

03 Feb '23

Hi, The MAINTAINERS file has the following: > PC ENGINES ALL MAINBOARDS > M: Piotr Król <piotr.krol(a)3mdeb.com> > M: Michał Żygowski <michal.zygowski(a)3mdeb.com> > S: Supported > F: src/mainboard/pcengines/ But the commit f9decbb0c720662d8e71fe221aef55b7ecf76196 ("mb/*/*: Remove AMD family14 boards") actually removed the apu1 (src/mainboard/pcengines/). Is there some policy somewhere that describes what kind of support to expect from maintained boards? Is there also a policy that explains when boards are removed? Or what to do to prevent boards from being removed? For instance u-boot warns when building that a boards needs to be adjusted to the newer driver model. So just by building u-boot you know in advance what needs to be fixed and for when. I've looked in the Coreboot documentation but I didn't find any information about that. Also is there some public information on how much work it is to avoid a board being removed? Does it require to dedicate someone full time on it? Or does it usually requires less time? Also how changes that break other people's code are decided? Can anyone submit these changes and get them accepted with very few people agreeing to them? Or is there another procedure for these special changes? Denis.

3 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot February 2023