coreboot

coreboot@coreboot.org

6 participants
39686 discussions

[coreboot - Other #314] Please disable 'administrator approval' on ticket.coreboot.org
by Felix Singer 15 Feb '23

15 Feb '23

Issue #314 has been updated by Felix Singer. Tracker changed from Support to Other ---------------------------------------- Other #314: Please disable 'administrator approval' on ticket.coreboot.org https://ticket.coreboot.org/issues/314#change-1414 * Author: akjuxr3 akjuxr3 * Status: Response Needed * Priority: Normal * Category: infrastructure * Start date: 2021-07-30 ---------------------------------------- Please disable this 'administrator approval' on ticket.coreboot.org. It feels like discrimination. Before i have written the first word on ticket.coreboot.org i have to be approved by someone by hand without this person knowing anything from me. I had to wait several days for this approval. Its completely unclear what is been tracked. Have the IP-address used for registration been tracked? Have the used email-address been tracked? E-mail-address-discrimination is illegal in many countries and this is completely breaking the freedom of choice! Username? Choosing (user)names is up to the user and making decision based on what names are 'allowed' to enter a platform is the most racist thing possible. Conclusion: This 'administrator approval' is sort of discrimination i have not seen for years on free projects! There is no data available at the registration process that could or should be used to decide who is allowed to report a bug in the coreboot project. Please disable this discrimination that is stopping people for days or even forever to report a coreboot issue. -- 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 - Support #314] Please disable 'administrator approval' on ticket.coreboot.org
by Paul Menzel 15 Feb '23

15 Feb '23

Issue #314 has been updated by Paul Menzel. @akjuxr3, do you know of a solution to prevent the creation of spam accounts? ---------------------------------------- Support #314: Please disable 'administrator approval' on ticket.coreboot.org https://ticket.coreboot.org/issues/314#change-1412 * Author: akjuxr3 akjuxr3 * Status: Response Needed * Priority: Normal * Category: infrastructure * Start date: 2021-07-30 ---------------------------------------- Please disable this 'administrator approval' on ticket.coreboot.org. It feels like discrimination. Before i have written the first word on ticket.coreboot.org i have to be approved by someone by hand without this person knowing anything from me. I had to wait several days for this approval. Its completely unclear what is been tracked. Have the IP-address used for registration been tracked? Have the used email-address been tracked? E-mail-address-discrimination is illegal in many countries and this is completely breaking the freedom of choice! Username? Choosing (user)names is up to the user and making decision based on what names are 'allowed' to enter a platform is the most racist thing possible. Conclusion: This 'administrator approval' is sort of discrimination i have not seen for years on free projects! There is no data available at the registration process that could or should be used to decide who is allowed to report a bug in the coreboot project. Please disable this discrimination that is stopping people for days or even forever to report a coreboot issue. -- 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 #393] T500 restarts rather than waking up from suspend
by akjuxr3 akjuxr3 15 Feb '23

15 Feb '23

Issue #393 has been updated by akjuxr3 akjuxr3. I can confirm this issue on a T500. ---------------------------------------- Bug #393: T500 restarts rather than waking up from suspend https://ticket.coreboot.org/issues/393#change-1411 * Author: Robert Gruber * Status: New * Priority: Normal * Target version: master * Start date: 2022-06-28 * Affected versions: master * Related links: https://ticket.coreboot.org/issues/167 * Affected hardware: Lenovo Thinkpad T500 * Affected OS: xubuntu 22.04 LTS ---------------------------------------- I have a similar issue like Bug #167 on an T500 with coreboot master (c2b4f44100e3f4ee84ba40cf96305eb32a0def76). System is working fine except this issue. When I go to suspend the moon LED is shining but when I power on again the system reboots from scratch (but not always). I tried CONFIG_CONSOLE_SERIAL=n but this does not solve this issue. I did not have any moon LED blinking. Instead sometimes the moon LED is shining persistent after reboot. Does anybody have an idea why the system sometimes reboots after suspend to ram and sometimes the suspend to ram works just as it should ? -- 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 #435] Add the new memtest86+ v6.0 as secondary coreboot payload
by akjuxr3 akjuxr3 15 Feb '23

15 Feb '23

Issue #435 has been updated by akjuxr3 akjuxr3. Martin Roth wrote in #note-2: > I'll look at finishing this up in the next week or so. Version 6.1 got released few days ago: https://github.com/memtest86plus/memtest86plus/releases ---------------------------------------- Feature #435: Add the new memtest86+ v6.0 as secondary coreboot payload https://ticket.coreboot.org/issues/435#change-1409 * Author: akjuxr3 akjuxr3 * Status: New * Priority: Normal * Target version: none * Start date: 2022-10-25 * Related links: https://github.com/memtest86plus/memtest86plus https://www.memtest.org/ https://www.phoronix.com/news/memtest86-6.0-Released ---------------------------------------- Memtest86+ have been rewritten. The release of the final version 6.0 was on 23.10.2022 . Here the changelog: Rewrite code for UEFI 32 & 64 bits Add support for x64 Long Mode Paging Add support for up to 256 cores Add detection for DDR4 & DDR5 Add support for XMP 3.0 Add detection for AMD Zen 1/2/3/4 Add detection for Intel up to 13th Gen Add better support for AMD pre-ZEN CPUs Add support for older nVidia and AMD chipsets Add support for SDRAM Many enhancements Numerous bug fixes & optimization Since it work now with uefi, it would be great if it could be used with tianocore payload. -- 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 - Support #314] (Response Needed) Please disable 'administrator approval' on ticket.coreboot.org
by akjuxr3 akjuxr3 15 Feb '23

15 Feb '23

Issue #314 has been updated by akjuxr3 akjuxr3. Tracker changed from Bug to Support Status changed from Rejected to Response Needed Martin Roth wrote in #note-2: > Not a coreboot bug. closing I changed from 'Tracker=Bug' to 'Tracker=Support'. I hope its the correct section now. ---------------------------------------- Support #314: Please disable 'administrator approval' on ticket.coreboot.org https://ticket.coreboot.org/issues/314#change-1408 * Author: akjuxr3 akjuxr3 * Status: Response Needed * Priority: Normal * Category: infrastructure * Start date: 2021-07-30 ---------------------------------------- Please disable this 'administrator approval' on ticket.coreboot.org. It feels like discrimination. Before i have written the first word on ticket.coreboot.org i have to be approved by someone by hand without this person knowing anything from me. I had to wait several days for this approval. Its completely unclear what is been tracked. Have the IP-address used for registration been tracked? Have the used email-address been tracked? E-mail-address-discrimination is illegal in many countries and this is completely breaking the freedom of choice! Username? Choosing (user)names is up to the user and making decision based on what names are 'allowed' to enter a platform is the most racist thing possible. Conclusion: This 'administrator approval' is sort of discrimination i have not seen for years on free projects! There is no data available at the registration process that could or should be used to decide who is allowed to report a bug in the coreboot project. Please disable this discrimination that is stopping people for days or even forever to report a coreboot issue. -- 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 - Support #459] (New) Attempt to standardize LB_MEM_RESERVED
by Tim Wawrzynczak 13 Feb '23

13 Feb '23

Issue #459 has been reported by Tim Wawrzynczak. ---------------------------------------- Support #459: Attempt to standardize LB_MEM_RESERVED https://ticket.coreboot.org/issues/459 * Author: Tim Wawrzynczak * Status: New * Priority: Normal * Assignee: Tim Wawrzynczak * Category: coreboot common code * Target version: none * Start date: 2023-02-13 * Affected hardware: x86 * Affected OS: Linux ---------------------------------------- Regarding https://review.coreboot.org/c/coreboot/+/52585, we have gone ahead and created LB_MEM_SOFT_RESERVED (0xefffffff) to be used in e820 table for memory that is "soft reserved" (https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=…). This creates a coreboot+Linux specific configuration which is undesirable from an interoperability standpoint. We should work to create a standard indicator for these types of entries. -- 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 - Support #458] (New) Add support for F71868AD.
by shen Liu 11 Feb '23

11 Feb '23

Issue #458 has been reported by shen Liu. ---------------------------------------- Support #458: Add support for F71868AD. https://ticket.coreboot.org/issues/458 * Author: shen Liu * Status: New * Priority: Normal * Category: userspace utilities * Target version: none * Start date: 2023-02-11 * Affected versions: master * Needs backport to: master * Affected hardware: MSI B75A-IE35(B75A-E33,B75A-G43) * Affected OS: Manjaro Linux 22.0.2 (Kernel ver:6.1.11-1) ---------------------------------------- The current version of superiotool does not support F71868AD. I hope to add support for F71868AD. -- 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

SMMSTORE_V2 support for camelback mountain CRB
by Moorthi M.s 11 Feb '23

11 Feb '23

Hi, I am developing coreboot along with uefipayload for camelback mountain crb. Board booted and working but not able to store the NVRAM BIOS configuration details. I am using coreboot 4.11 and found that the SMMSTORE_V2 is not implemented in that particular version. I tried to add SMMSTORE_V2 feature, but failed. whether the broadwell DE supports SMMSTORE_V2? Is there any other way avilable to save the BIOS boot configuration? Regards, Moorthi S

1 0

[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

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