coreboot November 2022

coreboot@coreboot.org

31 participants
30 discussions

Cisco Meraki use coreboot in some MX products and will not provide the source code
by Hal Martin 22 Dec '22

22 Dec '22

Hello, Several Cisco Meraki products (MX84, MX250) are using the coreboot bootloader. Meraki are also distributing coreboot builds for these products via their update mechanism. In October 2021, I requested the corresponding coreboot source code for the MX84 from open-source(a)meraki.com. Another individual requested the coreboot source code for the MX250 around the same time. We own the devices in quesiton. To date, Meraki have not provided the source code or provided an explanation as to the delay in providing the source code. The last reply I received was in January, and they have not replied to any of my follow up requests. As coreboot is GPL licensed software, I wanted to inform the coreboot community that I believe Cisco Meraki are not acting in good faith and are, in my opinion, violating the GPL by not providing the coreboot source code upon request. Kind regards, Hal Martin

4 4

coreboot-gerrit failures ---> rm: cannot remove '/home/coreboot/node-root/workspace/coreboot-gerrit/abuild-scanbuild.xml': No such file or directory
by Mike Banon 04 Dec '22

04 Dec '22

Good day! Unfortunately, a lot of builds are failing with this error, and it would be nice if you could fix this soon. -- Best regards, Mike Banon Open Source Community Manager of 3mdeb - https://3mdeb.com/

1 1

[RFC] VGA Text mode in romstage
by Compostella, Jeremy 03 Dec '22

03 Dec '22

Dear coreboot developers, In order to improve the user experience we would like to display a message on the screen while memory training is in progress. As a first step, we are working on Alder Lake and Raptor Lake platforms and are leveraging the `libgfxinit' and VGA text mode. We have libgfxinit patches for Tiger Lake, Alder Lake (and Raptor Lake) support under review but this is not the object of this email (see <https://review.coreboot.org/c/libgfxinit/+/65087> if you are interested) In the last few weeks, we have been working on a proof-of-concept to ensure that we could overcome all the technical hardware challenges to initialize VGA text mode and setup the display before we jump into FSP memory. Even though we are still working on some stability issues, we have a "working" but hacky patch :-). But we have an aggressive timeline and it works good enough that we believe it is time to start an open discussion as the surface of the patch is important (linker scripts, configuration flags logic ...). The changes have been reduced to a unique patch after a lot of clean-up (<https://review.coreboot.org/c/coreboot/+/69757>). This patch will be split up in a couple of patches once we are done with some in progress development. We identified three majors "issues" for which we are seeking feedback, guidance or help. PCI resource allocation ======================= <https://review.coreboot.org/c/coreboot/+/69757/2/src/soc/intel/alderlake/ro…> We need to configure the graphics PCI device to perform graphic initialization. It requires to perform an early romstage PCI resource allocation. For the proof-of-concept, we assigned the same resources than the coreboot resource allocator would assign during ramstage. We cannot leave hardcoded values like these. Any suggestion on how to cleanly handle early PCI resources allocation ? Configuration flags and "duplicated" ==================================== <https://review.coreboot.org/c/coreboot/+/69757/2/src/drivers/intel/fsp2_0/K…> <https://review.coreboot.org/c/coreboot/+/69757/2/src/lib/Kconfig> <https://review.coreboot.org/c/coreboot/+/69757/2/src/device/Kconfig> We had to "duplicate" some configuration flags such as `MAINBOARD_USE_LIBGFXINIT' as a `ROMSTAGE_MAINBOARD_USE_LIBGFXINIT' for instance. We want to separate configuration between romstage and ramstage to offer flexibility to use to have VGA text mode in romstage without any graphics initialization in ramstage or a graphic initialization with the GOP driver in ramstage ... We would appreciate some review and feedback on our clearly not perfect `Kconfig' changes. Any suggestion is welcome. libgfxinit and global initialized variables =========================================== <https://review.coreboot.org/c/coreboot/+/69757/1/src/arch/x86/car.ld> `libgfxinit' has some initialized global variables ending up in the `.data' section. Global *initialized* variables are not permitted in cache-as-ram and with the current `car.ld' linker script I hit compilation link errors due the following list of variables. Using objdump I collected their initial value (note that I did not exhaustively checked all the `[...]_E' ones but only a sample of them). Address Type Name Value ----------------------------------------------------------------------------- ffffff60 d `hw__debug__register_write_delay_nanoseconds' 00 ffffff68 d `hw__debug__start_of_line' 01 ffffff2c d `hw__gfx__gma__registers__gtt_32__range_aXnnn' 00 20 00 00 ffffff28 d `hw__gfx__gma__registers__gtt_64__range_aXnnn' 00 80 00 00 ffffff30 d `hw__gfx__gma__registers__regs__range_aXnnn' 00 00 00 00 ffffff6e D `gma_E' 00 ... ffffff70 D `gma__gfx_init_E' 00 ... ffffff6a D `hw__debug_E' 00 ... ffffff6c D `hw__debug_sink_E' 00 ... ffffff02 D `hw__gfx__dp_aux_ch_E' 00 ... ffffff04 D `hw__gfx__dp_dual_mode_E' 00 ... ffffff06 D `hw__gfx__dp_info_E' 00 ... ffffff08 D `hw__gfx__dp_training_E' 00 ... ffffff0a D `hw__gfx__edid_E' 00 ... ffffff0c D `hw__gfx__framebuffer_filler_E' 00 ... ffffff3a D `hw__gfx__gma_E' 00 ... ffffff3c D `hw__gfx__gma__combo_phy_E' 00 ... ffffff00 D `hw__gfx__gma__config_E' 00 ... ffffff0e D `hw__gfx__gma__config_helpers_E' 00 ... ffffff10 D `hw__gfx__gma__connector_info_E' 00 ... ffffff42 D `hw__gfx__gma__connectors_E' 00 ... ffffff3e D `hw__gfx__gma__connectors__combo_phy_E' 00 ... ffffff40 D `hw__gfx__gma__connectors__tc_E' 00 ... ffffff12 D `hw__gfx__gma__display_probing_E' 00 ... ffffff14 D `hw__gfx__gma__dp_aux_request_E' 00 ... ffffff16 D `hw__gfx__gma__i2c_E' 00 ... ffffff38 D `hw__gfx__gma__initialized' 00 ... ffffff18 D `hw__gfx__gma__panel_E' 00 ... ffffff1a D `hw__gfx__gma__pch__fdi_E' 00 ... ffffff1c D `hw__gfx__gma__pch__sideband_E' 00 ... ffffff1e D `hw__gfx__gma__pch__transcoder_E' 00 ... ffffff20 D `hw__gfx__gma__pch__vga_E' 00 ... ffffff22 D `hw__gfx__gma__pcode_E' 00 ... ffffff24 D `hw__gfx__gma__pipe_setup_E' 00 ... ffffff48 D `hw__gfx__gma__plls_E' 00 ... ffffff44 D `hw__gfx__gma__plls__combo_phy_E' 00 ... ffffff46 D `hw__gfx__gma__plls__dkl_E' 00 ... ffffff4a D `hw__gfx__gma__port_detect_E' 00 ... ffffff50 D `hw__gfx__gma__power_and_clocks_E' 00 ... ffffff4c D `hw__gfx__gma__power_and_clocks__tgl_E' 00 ... ffffff4e D `hw__gfx__gma__power_and_clocks__xelpd_E' 00 ... ffffff34 D `hw__gfx__gma__registers_E' 00 ... ffffff36 D `hw__gfx__gma__transcoder_E' 00 ... ffffff52 D `hw__mmio_range_E' 00 ... ffffff56 D `hw__mmio_regs_E' 00 ... ffffff54 D `hw__pci__dev_E' 00 ... ffffff58 D `hw__pci__mmconf_E' 00 ... ffffff5a D `hw__port_io_E' 00 ... ffffff5c D `hw__time_E' 00 ... ffffff72 D `hw__time__timer_E' 00 ... The symbols ending with `_E' are empty and initialized by GNAT generated code (cf. `___elabs' functions) which is called using the `$stage_adainit()' function. Therefor, I think it is safe to places these into the `_bss' region of the `.car.data' section. What I don't understand though is why isn't the GNAT compiler placing them into the `.bss' region of the object file. Any idea ? I could not find any GNAT compiler option for this but I am clearly not an ADA compiler expert :-) Now we are left with the following symbols: - `hw__debug__register_write_delay_nanoseconds' is zero so installing it in the `_bss' region of the `.car.data' section is "technically" fine. - `hw__debug__start_of_line': Reverting the logic of this boolean makes it work - The following three symbols are the most challenging ones: - `hw__gfx__gma__registers__gtt_32__range_aXnnn' - `hw__gfx__gma__registers__gtt_64__range_aXnnn' - `hw__gfx__gma__registers__regs__range_aXnnn' They seem to be entirely by the compiler and I don't know how to control them. Surprisingly, putting them in the `_bss' region of the `.car.data' section which is making them zeros is not causing any apparent issue while their initial value should not be zeros. I am thinking that these could be used for code verification purposes only. Does anyone knows before I adventure in to assembly code to uncover their role ? Regards, -- *Jeremy* /One Emacs to rule them all/

5 9

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

25 Nov '22

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 13 new defect(s) introduced to coreboot found with Coverity Scan. 1 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 13 of 13 defect(s) ** CID 1501089: Null pointer dereferences (FORWARD_NULL) /src/ec/clevo/it5570e/ec.c: 37 in pnp_configure_smfi() ________________________________________________________________________________________________________ *** CID 1501089: Null pointer dereferences (FORWARD_NULL) /src/ec/clevo/it5570e/ec.c: 37 in pnp_configure_smfi() 31 32 struct device dev = { 33 .path.type = DEVICE_PATH_PNP, 34 .path.pnp.port = 0x2e, 35 .path.pnp.device = IT5570E_SMFI, 36 }; >>> CID 1501089: Null pointer dereferences (FORWARD_NULL) >>> Dereferencing null pointer "dev.ops". 37 dev.ops->ops_pnp_mode = &pnp_conf_mode_870155_aa; 38 39 /* Configure SMFI for LGMR */ 40 pnp_enter_conf_mode(&dev); 41 pnp_set_logical_device(&dev); 42 pnp_set_enable(&dev, 1); ** CID 1501088: Code maintainability issues (UNUSED_VALUE) /src/cpu/intel/slot_1/l2_cache.c: 152 in calculate_l2_latency() ________________________________________________________________________________________________________ *** CID 1501088: Code maintainability issues (UNUSED_VALUE) /src/cpu/intel/slot_1/l2_cache.c: 152 in calculate_l2_latency() 146 printk(BIOS_DEBUG, "L2 latency type = %x\n", t); 147 148 /* Get CPUID family/model */ 149 signature = cpuid_eax(1) & 0xfff0; 150 151 /* Read EBL_CR_POWERON */ >>> CID 1501088: Code maintainability issues (UNUSED_VALUE) >>> Assigning value from "rdmsr(42U)" to "msr" here, but that stored value is overwritten before it can be used. 152 msr = rdmsr(EBL_CR_POWERON); 153 /* Get clock multiplier and FSB frequency. 154 * Multiplier is in [25:22]. 155 * FSB is in [19:18] in Katmai, [19] in Deschutes ([18] is zero 156 * for them). 157 */ ** CID 1501087: (STRING_OVERFLOW) ________________________________________________________________________________________________________ *** CID 1501087: (STRING_OVERFLOW) /src/arch/x86/smbios.c: 1138 in smbios_write_type39() 1132 1133 t->power_unit_group = unit_group; 1134 t->location = smbios_add_string(t->eos, loc); 1135 t->device_name = smbios_add_string(t->eos, dev_name); 1136 t->manufacturer = smbios_add_string(t->eos, man); 1137 t->serial_number = smbios_add_string(t->eos, serial_num); >>> CID 1501087: (STRING_OVERFLOW) >>> You might overrun the 2-character fixed-size string "t->eos" by copying "tag_num" without checking the length. 1138 t->asset_tag_number = smbios_add_string(t->eos, tag_num); 1139 t->model_part_number = smbios_add_string(t->eos, part_num); 1140 t->revision_level = smbios_add_string(t->eos, rev_lvl); 1141 t->max_power_capacity = max_pow_cap; 1142 1143 ps_type = ps_ch->power_supply_type & 0xF; /src/arch/x86/smbios.c: 1140 in smbios_write_type39() 1134 t->location = smbios_add_string(t->eos, loc); 1135 t->device_name = smbios_add_string(t->eos, dev_name); 1136 t->manufacturer = smbios_add_string(t->eos, man); 1137 t->serial_number = smbios_add_string(t->eos, serial_num); 1138 t->asset_tag_number = smbios_add_string(t->eos, tag_num); 1139 t->model_part_number = smbios_add_string(t->eos, part_num); >>> CID 1501087: (STRING_OVERFLOW) >>> You might overrun the 2-character fixed-size string "t->eos" by copying "rev_lvl" without checking the length. 1140 t->revision_level = smbios_add_string(t->eos, rev_lvl); 1141 t->max_power_capacity = max_pow_cap; 1142 1143 ps_type = ps_ch->power_supply_type & 0xF; 1144 ps_status = ps_ch->power_supply_status & 0x7; 1145 vol_switch = ps_ch->input_voltage_range_switch & 0xF; /src/arch/x86/smbios.c: 1134 in smbios_write_type39() 1128 sizeof(*t), *handle); 1129 1130 uint16_t val = 0; 1131 uint16_t ps_type, ps_status, vol_switch, ps_unplug, ps_present, hot_rep; 1132 1133 t->power_unit_group = unit_group; >>> CID 1501087: (STRING_OVERFLOW) >>> You might overrun the 2-character fixed-size string "t->eos" by copying "loc" without checking the length. 1134 t->location = smbios_add_string(t->eos, loc); 1135 t->device_name = smbios_add_string(t->eos, dev_name); 1136 t->manufacturer = smbios_add_string(t->eos, man); 1137 t->serial_number = smbios_add_string(t->eos, serial_num); 1138 t->asset_tag_number = smbios_add_string(t->eos, tag_num); 1139 t->model_part_number = smbios_add_string(t->eos, part_num); /src/arch/x86/smbios.c: 1139 in smbios_write_type39() 1133 t->power_unit_group = unit_group; 1134 t->location = smbios_add_string(t->eos, loc); 1135 t->device_name = smbios_add_string(t->eos, dev_name); 1136 t->manufacturer = smbios_add_string(t->eos, man); 1137 t->serial_number = smbios_add_string(t->eos, serial_num); 1138 t->asset_tag_number = smbios_add_string(t->eos, tag_num); >>> CID 1501087: (STRING_OVERFLOW) >>> You might overrun the 2-character fixed-size string "t->eos" by copying "part_num" without checking the length. 1139 t->model_part_number = smbios_add_string(t->eos, part_num); 1140 t->revision_level = smbios_add_string(t->eos, rev_lvl); 1141 t->max_power_capacity = max_pow_cap; 1142 1143 ps_type = ps_ch->power_supply_type & 0xF; 1144 ps_status = ps_ch->power_supply_status & 0x7; /src/arch/x86/smbios.c: 1135 in smbios_write_type39() 1129 1130 uint16_t val = 0; 1131 uint16_t ps_type, ps_status, vol_switch, ps_unplug, ps_present, hot_rep; 1132 1133 t->power_unit_group = unit_group; 1134 t->location = smbios_add_string(t->eos, loc); >>> CID 1501087: (STRING_OVERFLOW) >>> You might overrun the 2-character fixed-size string "t->eos" by copying "dev_name" without checking the length. 1135 t->device_name = smbios_add_string(t->eos, dev_name); 1136 t->manufacturer = smbios_add_string(t->eos, man); 1137 t->serial_number = smbios_add_string(t->eos, serial_num); 1138 t->asset_tag_number = smbios_add_string(t->eos, tag_num); 1139 t->model_part_number = smbios_add_string(t->eos, part_num); 1140 t->revision_level = smbios_add_string(t->eos, rev_lvl); /src/arch/x86/smbios.c: 1136 in smbios_write_type39() 1130 uint16_t val = 0; 1131 uint16_t ps_type, ps_status, vol_switch, ps_unplug, ps_present, hot_rep; 1132 1133 t->power_unit_group = unit_group; 1134 t->location = smbios_add_string(t->eos, loc); 1135 t->device_name = smbios_add_string(t->eos, dev_name); >>> CID 1501087: (STRING_OVERFLOW) >>> You might overrun the 2-character fixed-size string "t->eos" by copying "man" without checking the length. 1136 t->manufacturer = smbios_add_string(t->eos, man); 1137 t->serial_number = smbios_add_string(t->eos, serial_num); 1138 t->asset_tag_number = smbios_add_string(t->eos, tag_num); 1139 t->model_part_number = smbios_add_string(t->eos, part_num); 1140 t->revision_level = smbios_add_string(t->eos, rev_lvl); 1141 t->max_power_capacity = max_pow_cap; /src/arch/x86/smbios.c: 1137 in smbios_write_type39() 1131 uint16_t ps_type, ps_status, vol_switch, ps_unplug, ps_present, hot_rep; 1132 1133 t->power_unit_group = unit_group; 1134 t->location = smbios_add_string(t->eos, loc); 1135 t->device_name = smbios_add_string(t->eos, dev_name); 1136 t->manufacturer = smbios_add_string(t->eos, man); >>> CID 1501087: (STRING_OVERFLOW) >>> You might overrun the 2-character fixed-size string "t->eos" by copying "serial_num" without checking the length. 1137 t->serial_number = smbios_add_string(t->eos, serial_num); 1138 t->asset_tag_number = smbios_add_string(t->eos, tag_num); 1139 t->model_part_number = smbios_add_string(t->eos, part_num); 1140 t->revision_level = smbios_add_string(t->eos, rev_lvl); 1141 t->max_power_capacity = max_pow_cap; 1142 ** CID 1501086: API usage errors (BAD_COMPARE) /src/device/oprom/yabel/biosemu.c: 200 in biosemu() ________________________________________________________________________________________________________ *** CID 1501086: API usage errors (BAD_COMPARE) /src/device/oprom/yabel/biosemu.c: 200 in biosemu() 194 clr_ci(); 195 my_wrb((uintptr_t)mem_img + i, c); 196 } 197 #endif 198 copy_count++; 199 set_ci(); >>> CID 1501086: API usage errors (BAD_COMPARE) >>> Truncating the result of "memcmp" to "unsigned char" may cause it to be misinterpreted as 0. Note that "memcmp" may return an integer besides -1, 0, or 1. 200 cmp_result = memcmp(mem_img, rom_image, bios_device.img_size); 201 clr_ci(); 202 } 203 while ((copy_count < 5) && (cmp_result != 0)); 204 if (cmp_result != 0) { 205 printf ** CID 1501085: Control flow issues (DEADCODE) /src/device/oprom/yabel/interrupt.c: 299 in handleInt16() ________________________________________________________________________________________________________ *** CID 1501085: Control flow issues (DEADCODE) /src/device/oprom/yabel/interrupt.c: 299 in handleInt16() 293 /* TODO: we need getchar... */ 294 c = -1; //getchar(); 295 if (c == -1) { 296 // no key available 297 SET_FLAG(F_ZF); 298 } else { >>> CID 1501085: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "*keycode = c;". 299 *keycode = c; 300 301 // since after an ESC it may take a while to receive the next char, 302 // we send something that is not shown on the screen, and then try to get 303 // the next char 304 // TODO: only after ESC?? what about other multibyte keys ** CID 1501084: (UNUSED_VALUE) /src/device/oprom/x86emu/decode.c: 829 in decode_sib_address() /src/device/oprom/x86emu/decode.c: 834 in decode_sib_address() ________________________________________________________________________________________________________ *** CID 1501084: (UNUSED_VALUE) /src/device/oprom/x86emu/decode.c: 829 in decode_sib_address() 823 DECODE_PRINTF2("[%d]", displacement); 824 offset = displacement; 825 break; 826 case 1: 827 displacement = (s8)fetch_byte_imm(); 828 DECODE_PRINTF2("[%d][EBP]", displacement); >>> CID 1501084: (UNUSED_VALUE) >>> Assigning value from "_X86EMU_env.x86.spc.BP.I32_reg.e_reg + displacement" to "offset" here, but that stored value is overwritten before it can be used. 829 offset = M.x86.R_EBP + displacement; 830 break; 831 case 2: 832 displacement = (s32)fetch_long_imm(); 833 DECODE_PRINTF2("[%d][EBP]", displacement); 834 offset = M.x86.R_EBP + displacement; /src/device/oprom/x86emu/decode.c: 834 in decode_sib_address() 828 DECODE_PRINTF2("[%d][EBP]", displacement); 829 offset = M.x86.R_EBP + displacement; 830 break; 831 case 2: 832 displacement = (s32)fetch_long_imm(); 833 DECODE_PRINTF2("[%d][EBP]", displacement); >>> CID 1501084: (UNUSED_VALUE) >>> Assigning value from "_X86EMU_env.x86.spc.BP.I32_reg.e_reg + displacement" to "offset" here, but that stored value is overwritten before it can be used. 834 offset = M.x86.R_EBP + displacement; 835 break; 836 default: 837 HALT_SYS(); 838 } 839 DECODE_PRINTF("[EAX]"); ** CID 1501083: Null pointer dereferences (FORWARD_NULL) /src/device/oprom/yabel/biosemu.c: 246 in biosemu() ________________________________________________________________________________________________________ *** CID 1501083: Null pointer dereferences (FORWARD_NULL) /src/device/oprom/yabel/biosemu.c: 246 in biosemu() 240 my_wrl(0x1a * 4, 0xf000fe6e); 241 my_wrb(0x000ffe6e, 0xcf); 242 243 // setup BIOS Data Area (0000:04xx, or 0040:00xx) 244 // we currently 0 this area, meaning "we don't have 245 // any hardware" :-) no serial/parallel ports, floppys, ... >>> CID 1501083: Null pointer dereferences (FORWARD_NULL) >>> Passing null pointer "biosmem + 1024" to "memset", which dereferences it. [Note: The source code implementation of the function has been overridden by a builtin model.] 246 memset(biosmem + 0x400, 0x0, 0x100); 247 248 // at offset 13h in BDA is the memory size in kbytes 249 my_wrw(0x413, biosmem_size / 1024); 250 // at offset 0eh in BDA is the segment of the Extended BIOS Data Area 251 // see setup further down ** CID 1299819: (BAD_SHIFT) /src/device/oprom/x86emu/prim_ops.c: 2136 in idiv_long() /src/device/oprom/x86emu/prim_ops.c: 2136 in idiv_long() /src/device/oprom/x86emu/prim_ops.c: 2143 in idiv_long() /src/device/oprom/x86emu/prim_ops.c: 2136 in idiv_long() ________________________________________________________________________________________________________ *** CID 1299819: (BAD_SHIFT) /src/device/oprom/x86emu/prim_ops.c: 2136 in idiv_long() 2130 do { 2131 div <<= 1; 2132 carry = (l_dvd >= l_s) ? 0 : 1; 2133 2134 if (abs_h_dvd < (h_s + carry)) { 2135 h_s >>= 1; >>> CID 1299819: (BAD_SHIFT) >>> In expression "abs_s << --counter", shifting by a negative amount has undefined behavior. The shift amount, "--counter", is as little as -1. 2136 l_s = abs_s << (--counter); 2137 continue; 2138 } else { 2139 abs_h_dvd -= (h_s + carry); 2140 l_dvd = carry ? ((0xFFFFFFFF - l_s) + l_dvd + 1) 2141 : (l_dvd - l_s); /src/device/oprom/x86emu/prim_ops.c: 2136 in idiv_long() 2130 do { 2131 div <<= 1; 2132 carry = (l_dvd >= l_s) ? 0 : 1; 2133 2134 if (abs_h_dvd < (h_s + carry)) { 2135 h_s >>= 1; >>> CID 1299819: (BAD_SHIFT) >>> In expression "abs_s << --counter", shifting by a negative amount has undefined behavior. The shift amount, "--counter", is as little as -1. 2136 l_s = abs_s << (--counter); 2137 continue; 2138 } else { 2139 abs_h_dvd -= (h_s + carry); 2140 l_dvd = carry ? ((0xFFFFFFFF - l_s) + l_dvd + 1) 2141 : (l_dvd - l_s); /src/device/oprom/x86emu/prim_ops.c: 2143 in idiv_long() 2137 continue; 2138 } else { 2139 abs_h_dvd -= (h_s + carry); 2140 l_dvd = carry ? ((0xFFFFFFFF - l_s) + l_dvd + 1) 2141 : (l_dvd - l_s); 2142 h_s >>= 1; >>> CID 1299819: (BAD_SHIFT) >>> In expression "abs_s << --counter", shifting by a negative amount has undefined behavior. The shift amount, "--counter", is as little as -1. 2143 l_s = abs_s << (--counter); 2144 div |= 1; 2145 continue; 2146 } 2147 2148 } while (counter > -1); /src/device/oprom/x86emu/prim_ops.c: 2136 in idiv_long() 2130 do { 2131 div <<= 1; 2132 carry = (l_dvd >= l_s) ? 0 : 1; 2133 2134 if (abs_h_dvd < (h_s + carry)) { 2135 h_s >>= 1; >>> CID 1299819: (BAD_SHIFT) >>> In expression "abs_s << --counter", shifting by a negative amount has undefined behavior. The shift amount, "--counter", is as little as -1. 2136 l_s = abs_s << (--counter); 2137 continue; 2138 } else { 2139 abs_h_dvd -= (h_s + carry); 2140 l_dvd = carry ? ((0xFFFFFFFF - l_s) + l_dvd + 1) 2141 : (l_dvd - l_s); ** CID 1299818: (BAD_SHIFT) /src/device/oprom/x86emu/prim_ops.c: 2260 in div_long() /src/device/oprom/x86emu/prim_ops.c: 2260 in div_long() /src/device/oprom/x86emu/prim_ops.c: 2260 in div_long() /src/device/oprom/x86emu/prim_ops.c: 2267 in div_long() ________________________________________________________________________________________________________ *** CID 1299818: (BAD_SHIFT) /src/device/oprom/x86emu/prim_ops.c: 2260 in div_long() 2254 do { 2255 div <<= 1; 2256 carry = (l_dvd >= l_s) ? 0 : 1; 2257 2258 if (h_dvd < (h_s + carry)) { 2259 h_s >>= 1; >>> CID 1299818: (BAD_SHIFT) >>> In expression "s << --counter", shifting by a negative amount has undefined behavior. The shift amount, "--counter", is as little as -1. 2260 l_s = s << (--counter); 2261 continue; 2262 } else { 2263 h_dvd -= (h_s + carry); 2264 l_dvd = carry ? ((0xFFFFFFFF - l_s) + l_dvd + 1) 2265 : (l_dvd - l_s); /src/device/oprom/x86emu/prim_ops.c: 2260 in div_long() 2254 do { 2255 div <<= 1; 2256 carry = (l_dvd >= l_s) ? 0 : 1; 2257 2258 if (h_dvd < (h_s + carry)) { 2259 h_s >>= 1; >>> CID 1299818: (BAD_SHIFT) >>> In expression "s << --counter", shifting by a negative amount has undefined behavior. The shift amount, "--counter", is as little as -1. 2260 l_s = s << (--counter); 2261 continue; 2262 } else { 2263 h_dvd -= (h_s + carry); 2264 l_dvd = carry ? ((0xFFFFFFFF - l_s) + l_dvd + 1) 2265 : (l_dvd - l_s); /src/device/oprom/x86emu/prim_ops.c: 2260 in div_long() 2254 do { 2255 div <<= 1; 2256 carry = (l_dvd >= l_s) ? 0 : 1; 2257 2258 if (h_dvd < (h_s + carry)) { 2259 h_s >>= 1; >>> CID 1299818: (BAD_SHIFT) >>> In expression "s << --counter", shifting by a negative amount has undefined behavior. The shift amount, "--counter", is as little as -1. 2260 l_s = s << (--counter); 2261 continue; 2262 } else { 2263 h_dvd -= (h_s + carry); 2264 l_dvd = carry ? ((0xFFFFFFFF - l_s) + l_dvd + 1) 2265 : (l_dvd - l_s); /src/device/oprom/x86emu/prim_ops.c: 2267 in div_long() 2261 continue; 2262 } else { 2263 h_dvd -= (h_s + carry); 2264 l_dvd = carry ? ((0xFFFFFFFF - l_s) + l_dvd + 1) 2265 : (l_dvd - l_s); 2266 h_s >>= 1; >>> CID 1299818: (BAD_SHIFT) >>> In expression "s << --counter", shifting by a negative amount has undefined behavior. The shift amount, "--counter", is as little as -1. 2267 l_s = s << (--counter); 2268 div |= 1; 2269 continue; 2270 } 2271 2272 } while (counter > -1); ** CID 1198906: Integer handling issues (BAD_SHIFT) /src/device/oprom/x86emu/prim_ops.c: 835 in rcl_long() ________________________________________________________________________________________________________ *** CID 1198906: Integer handling issues (BAD_SHIFT) /src/device/oprom/x86emu/prim_ops.c: 835 in rcl_long() 829 { 830 u32 res, cnt, mask, cf; 831 832 res = d; 833 if ((cnt = s % 33) != 0) { 834 cf = (d >> (32 - cnt)) & 0x1; >>> CID 1198906: Integer handling issues (BAD_SHIFT) >>> In expression "d << cnt", left shifting by more than 31 bits has undefined behavior. The shift amount, "cnt", is as much as 32. 835 res = (d << cnt) & 0xffffffff; 836 mask = (1 << (cnt - 1)) - 1; 837 res |= (d >> (33 - cnt)) & mask; 838 if (ACCESS_FLAG(F_CF)) { /* carry flag is set */ 839 res |= 1 << (cnt - 1); 840 } ** CID 1198905: Integer handling issues (BAD_SHIFT) /src/device/oprom/x86emu/prim_ops.c: 904 in rcr_byte() ________________________________________________________________________________________________________ *** CID 1198905: Integer handling issues (BAD_SHIFT) /src/device/oprom/x86emu/prim_ops.c: 904 in rcr_byte() 898 This is effectively done by shifting the 899 object to the right. The result must be masked, 900 in case the object came in and was treated 901 as a negative number. Needed??? */ 902 903 mask = (1 << (8 - cnt)) - 1; >>> CID 1198905: Integer handling issues (BAD_SHIFT) >>> In expression "d >> cnt", right shifting "d" by more than 7 bits always yields zero. The shift amount, "cnt", is as much as 8. 904 res = (d >> cnt) & mask; 905 906 /* now the high stuff which rotated around 907 into the positions B_cnt-2 .. B_0 */ 908 /* B_(7) .. B_(8-(n-1)) <- b_(n-2) .. b_(0) */ 909 /* shift it downward, 7-(n-2) = 9-n positions. ** CID 1198904: Integer handling issues (BAD_SHIFT) /src/device/oprom/x86emu/prim_ops.c: 982 in rcr_long() ________________________________________________________________________________________________________ *** CID 1198904: Integer handling issues (BAD_SHIFT) /src/device/oprom/x86emu/prim_ops.c: 982 in rcr_long() 976 if (cnt == 1) { 977 cf = d & 0x1; 978 ocf = ACCESS_FLAG(F_CF) != 0; 979 } else 980 cf = (d >> (cnt - 1)) & 0x1; 981 mask = (1 << (32 - cnt)) - 1; >>> CID 1198904: Integer handling issues (BAD_SHIFT) >>> In expression "d >> cnt", right shifting by more than 31 bits has undefined behavior. The shift amount, "cnt", is as much as 32. 982 res = (d >> cnt) & mask; 983 if (cnt != 1) 984 res |= (d << (33 - cnt)); 985 if (ACCESS_FLAG(F_CF)) { /* carry flag is set */ 986 res |= 1 << (32 - cnt); 987 } ** CID 1198903: Integer handling issues (BAD_SHIFT) /src/device/oprom/x86emu/prim_ops.c: 950 in rcr_word() ________________________________________________________________________________________________________ *** CID 1198903: Integer handling issues (BAD_SHIFT) /src/device/oprom/x86emu/prim_ops.c: 950 in rcr_word() 944 if (cnt == 1) { 945 cf = d & 0x1; 946 ocf = ACCESS_FLAG(F_CF) != 0; 947 } else 948 cf = (d >> (cnt - 1)) & 0x1; 949 mask = (1 << (16 - cnt)) - 1; >>> CID 1198903: Integer handling issues (BAD_SHIFT) >>> In expression "d >> cnt", right shifting "d" by more than 15 bits always yields zero. The shift amount, "cnt", is as much as 16. 950 res = (d >> cnt) & mask; 951 res |= (d << (17 - cnt)); 952 if (ACCESS_FLAG(F_CF)) { 953 res |= 1 << (16 - cnt); 954 } 955 CONDITIONAL_SET_FLAG(cf, F_CF); ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0

New list member..and a project
by Wayne Stuart 21 Nov '22

21 Nov '22

Hi, I just joined this list. I have a project coming up where I need to coreboot a Lenovo W540. I have found a mention of using the t440p setup. I am new to coreboot, though I have used coreboot laptops for a few years. I am looking for direction. Wayne

3 2

Re: coreboot postcode cleanup proposal
by Martin Roth 21 Nov '22

21 Nov '22

The intel cache_as_ram postcodes actually wouldn't go into the bootblock area. The coreboot areas are meant to be common to all platforms. The CAR codes would mostly go into the "SoC specific area", which I've doubled from 16 to 32 codes based on your comment here. ``` * 0x00 : unregulated - 0x00 is not a good postcode. * * 0x01 - 0x07 : general coreboot startup code & common * 0x08 - 0x0b : general coreboot console * 0x0c - 0x0f : <RESERVED> * * 0x10 - 0x1f : general coreboot bootblock * 0x20 - 0x2f : general coreboot romstage * 0x30 - 0x33 : general coreboot postcar * 0x34 - 0x3f : general coreboot ramstage * 0x40 - 0x4f : coreboot ramstage hardwaremain boot stages * * 0x50 - 0x6f : SOC specific - Each SoC/CPU/Chipset can use as it chooses * * 0x70 - 0x7f : <Reserved for expansion> * * 0x80 - 0x87 : ACPI postcodes * 0x88 - 0x8f : Unregulated - may be used anywhere for any purpose. * 0x90 - 0x9f : Vendorcode calls: FSP, AGESA, etc. entry & exit. * * 0xa0 - 0xaf : Mainboard specific - Each mainboard can use as it chooses * * 0xb0 : Driver/SuperIO ID, followed by ID byte (serves as driver entry) * 0xb1 - 0xbf : Driver/SuperIO specific - Can use as the device chooses * * 0xc0 - 0xca : <Reserved for expansion> * * 0xcb : coreboot identifier - used when returning from FSP, AGESA, etc * * 0xcc - 0xcf : <Reserved for expansion> * * 0xd0 : Debug ID, followed by ID byte * 0xd1 - 0xdf : Debug postcodes - never enabled by default. * * 0xe0 - 0xef : Errors * 0xf0 - 0xf7 : general coreboot SMM * 0xf8 - 0xfe : end of coreboot code - resume and the like. * 0xff : coreboot finished - jump to payload ``` I've also moved some reserved area to just after the SoC postcode area in case we find we still need more than 32, we can easily expand it up to 48 postcodes for the SoC or CPU/NB/SB areas. If we find we need to reorganize more in the future, we should be able to do that without too much difficulty in the future. It was suggested in the leadership meeting last week that we could version the postcodes based on releases, but hopefully it'll settle down very shortly, and we won't need to do that. Martin Nov 16, 2022, 15:20 by maximilian.brune(a)9elements.com: > src/soc/intel/common/block/cpu/car/cache_as_ram.S is a candidate which hard codes all post codes (instead of using post_codes.h) and that file alone already uses more than your 16 propsed postcodes for bootblock (I think). Since bootblock is kind of relying on post codes for proper debug (since serial output may not be available at that time), it would make sense to use more post codes for bootblock I guess. > > On Wed, Nov 16, 2022, 17:23 Martin Roth via coreboot <> coreboot(a)coreboot.org> > wrote: > >> The current state of the coreboot postcodes is a mess. There’s no good way to give anyone a postcode table. The post_code() function is called with direct hardcoded values all over the codebase. The post_codes.h file is disorganized with values being added without regard for being contiguous or ordered. As an example, despite using hexadecimal values, console post codes go from 0x39 to 0x40. >> >> >> We can do better than this. >> >> >> Proposal >> -------- >> The postcodes should be better organized and standardized. Each stage should have its own block of postcodes, and they should be easily recognizable as a flow from early coreboot to late coreboot. >> common between blocks: >> - bootblock >> - verstage >> - romstage >> - postcar >> - ramstage >> - smm >> >> We should have blocks of postcodes for different sections as well. >> - SoC/CPU/Chipset >> - Mainboard >> - Drivers >> >> - A set of debug-specific postcodes that may be used in any area, but may not be enabled by default, but only by user request. >> - The debug and driver post codes should have identifiers to show what section of the codebase they're coming from. >> - Finally, there should be small section of uncontrolled values that can be used anywhere that doesn’t have an already allocated specific value. >> >> >> Additional Improvements >> ----------------------- >> - Postcodes should be able to be included in the timestamp table so we can grab timestamps for individual postcodes. >> - Specific Postcodes should have associated text names, similar to the timestamps, and should have a decode tool. >> - Multi-byte postcodes should be implemented for platforms that support them. >> >> >> Proposed postcode ranges >> ------------------------ >> >> ``` >> * 0x00 : unregulated - 0x00 is not a good postcode. >> * >> * 0x01 - 0x07 : coreboot startup code & common >> * 0x08 - 0x0b : coreboot console >> * 0x0c - 0x0f : <RESERVED> >> * >> * 0x10 - 0x1f : coreboot bootblock >> * 0x20 - 0x2f : coreboot romstage >> * 0x30 - 0x33 : postcar >> * 0x34 - 0x3f : coreboot ramstage >> * 0x40 - 0x4f : coreboot ramstage hardwaremain boot stages >> * >> * 0x50 - 0x5f : Mainboard specific - Each mainboard can use as it chooses >> * 0x60 - 0x6f : SOC specific - Each SoC/CPU/Chipset can use as it chooses >> * >> * 0x70 : Driver/SuperIO ID, followed by ID byte >> * 0x71 - 0x7f : Driver/SuperIO specific - Can use as the device chooses >> * >> * 0x80 - 0x87 : ACPI postcodes >> * 0x88 - 0x8f : Unregulated - may be used anywhere for any purpose. >> * 0x90 - 0x9f : Vendorcode calls: FSP, AGESA, etc. >> * >> * 0xa0 - 0xaf : <RESERVED> >> * 0xb0 - 0xbf : <RESERVED> >> * >> * 0xc0 - 0xca : <RESERVED> >> * >> * 0xcb : coreboot identifier - used when returning from FSP, AGESA, etc >> * >> * 0xcc - 0xcf : <RESERVED> >> * >> * 0xd0 - 0xdf : Debug postcodes - never enabled by default. >> * >> * 0xe0 - 0xef : Errors >> * 0xf0 - 0xf7 : SMM >> * 0xf8 - 0xfe : end of coreboot code - resume and the like. >> * 0xff : coreboot finished - jump to payload >> ``` >> >> Driver/SuperIO/Debug IDs >> ------------------------ >> >> Because there are many drivers, and a single board can use multiple of the drivers, we want a way to know which device is putting out postcodes. To handle this, the driver, superIO, or debug section should emit a DRIVER_ID_FOLLOWS or DEBUG_ID_FOLLOWS postcode, followed by the actual ID code. >> >> The ID code would currently be a single byte, with the bytes 0xf0 - 0xff being reserved as page and continue bytes. The continue bytes would tell the code that the ID is on a secondary or later page - See the method used by the SPD to identify Manufacturers as a similar concept. 0xF0 - 0xFE would each point to a page of 240 possible drivers, and 0xff would tell the code to look for the next level of pages, which would follow the same pattern. >> >> The driver IDs and debug IDs would all be contained in separate header files. >> >> This would allow for the area to be uniquely identified by a tool. >> >> Postcode rules >> -------------- >> >> - Don’t use postcodes other than the debug postcodes in loops. Spewing out postcodes isn’t helpful. >> - Don’t output bare numbers, a macro in post_codes.h must be used. A linter will be set up to look the macros and will give an error if it’s not one of the postcode files. >> - All postcode output should be able to be identified by an automatic parser tool (with the exception of unregulated codes) >> >> >> >> _______________________________________________ >> coreboot mailing list -- >> coreboot(a)coreboot.org >> To unsubscribe send an email to >> coreboot-leave(a)coreboot.org >>

2 1

[coreboot - Bug #439] (New) Lenovo X201 Turbo Boost not working
by Lukas Karg 19 Nov '22

19 Nov '22

Issue #439 has been reported by Lukas Karg. ---------------------------------------- Bug #439: Lenovo X201 Turbo Boost not working https://ticket.coreboot.org/issues/439 * Author: Lukas Karg * Status: New * Priority: High * Target version: none * Start date: 2022-11-18 * Affected versions: master * Affected hardware: Lenovo X201 * Affected OS: Linux, Windows, ... ---------------------------------------- -- 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 6

FYI: Changing contents and compression for `config` file in CBFS
by Julius Werner 17 Nov '22

17 Nov '22

I don't know if anybody cares about this, so I thought I'd send an email just in case: I'd like to change the format of the `config` file that automatically gets included in CBFS: right now it just contains the output of Kconfig's `savedefconfig` command, i.e. the minimal `.config` file that is needed to reproduce the full config (with all the default options and options that get `select`ed by something else excluded). This is a problem if you want to use the file to just check if a certain option was enabled in the image or not, since many options are enabled by default in certain cases, and the rules for when exactly what is the default setting can be complicated and change frequently. I would like to have a `config` file that I can just extract and then grep for a certain CONFIG_XXX=y to check if that config was enabled or not. So I'm changing the generation of the `config` file to instead include all options that are not set to false in Kconfig (i.e. basically the full coreboot `.config` file, just with comments removed). Since this makes the file quite a bit bigger I think we should also start to compress it with LZMA, as it's only meant to be re-extracted with cbfstool anyway so there seems to be no reason not to. (Or does anyone care strongly about being able to read the config file when opening the raw image with a hex editor?) I've uploaded this CL as https://review.coreboot.org/69710 . Please comment there if anyone has a concern about this change.

2 1

coreboot postcode cleanup proposal
by Martin Roth 17 Nov '22

17 Nov '22

The current state of the coreboot postcodes is a mess. There’s no good way to give anyone a postcode table. The post_code() function is called with direct hardcoded values all over the codebase. The post_codes.h file is disorganized with values being added without regard for being contiguous or ordered. As an example, despite using hexadecimal values, console post codes go from 0x39 to 0x40. We can do better than this. Proposal -------- The postcodes should be better organized and standardized. Each stage should have its own block of postcodes, and they should be easily recognizable as a flow from early coreboot to late coreboot. common between blocks: - bootblock - verstage - romstage - postcar - ramstage - smm We should have blocks of postcodes for different sections as well. - SoC/CPU/Chipset - Mainboard - Drivers - A set of debug-specific postcodes that may be used in any area, but may not be enabled by default, but only by user request. - The debug and driver post codes should have identifiers to show what section of the codebase they're coming from. - Finally, there should be small section of uncontrolled values that can be used anywhere that doesn’t have an already allocated specific value. Additional Improvements ----------------------- - Postcodes should be able to be included in the timestamp table so we can grab timestamps for individual postcodes. - Specific Postcodes should have associated text names, similar to the timestamps, and should have a decode tool. - Multi-byte postcodes should be implemented for platforms that support them. Proposed postcode ranges ------------------------ ``` * 0x00 : unregulated - 0x00 is not a good postcode. * * 0x01 - 0x07 : coreboot startup code & common * 0x08 - 0x0b : coreboot console * 0x0c - 0x0f : <RESERVED> * * 0x10 - 0x1f : coreboot bootblock * 0x20 - 0x2f : coreboot romstage * 0x30 - 0x33 : postcar * 0x34 - 0x3f : coreboot ramstage * 0x40 - 0x4f : coreboot ramstage hardwaremain boot stages * * 0x50 - 0x5f : Mainboard specific - Each mainboard can use as it chooses * 0x60 - 0x6f : SOC specific - Each SoC/CPU/Chipset can use as it chooses * * 0x70 : Driver/SuperIO ID, followed by ID byte * 0x71 - 0x7f : Driver/SuperIO specific - Can use as the device chooses * * 0x80 - 0x87 : ACPI postcodes * 0x88 - 0x8f : Unregulated - may be used anywhere for any purpose. * 0x90 - 0x9f : Vendorcode calls: FSP, AGESA, etc. * * 0xa0 - 0xaf : <RESERVED> * 0xb0 - 0xbf : <RESERVED> * * 0xc0 - 0xca : <RESERVED> * * 0xcb : coreboot identifier - used when returning from FSP, AGESA, etc * * 0xcc - 0xcf : <RESERVED> * * 0xd0 - 0xdf : Debug postcodes - never enabled by default. * * 0xe0 - 0xef : Errors * 0xf0 - 0xf7 : SMM * 0xf8 - 0xfe : end of coreboot code - resume and the like. * 0xff : coreboot finished - jump to payload ``` Driver/SuperIO/Debug IDs ------------------------ Because there are many drivers, and a single board can use multiple of the drivers, we want a way to know which device is putting out postcodes. To handle this, the driver, superIO, or debug section should emit a DRIVER_ID_FOLLOWS or DEBUG_ID_FOLLOWS postcode, followed by the actual ID code. The ID code would currently be a single byte, with the bytes 0xf0 - 0xff being reserved as page and continue bytes. The continue bytes would tell the code that the ID is on a secondary or later page - See the method used by the SPD to identify Manufacturers as a similar concept. 0xF0 - 0xFE would each point to a page of 240 possible drivers, and 0xff would tell the code to look for the next level of pages, which would follow the same pattern. The driver IDs and debug IDs would all be contained in separate header files. This would allow for the area to be uniquely identified by a tool. Postcode rules -------------- - Don’t use postcodes other than the debug postcodes in loops. Spewing out postcodes isn’t helpful. - Don’t output bare numbers, a macro in post_codes.h must be used. A linter will be set up to look the macros and will give an error if it’s not one of the postcode files. - All postcode output should be able to be identified by an automatic parser tool (with the exception of unregulated codes)

3 2

[RFC] POC: Use FDT as payload handoff instead lb_tables
by Paul Menzel 16 Nov '22

16 Nov '22

Dear coreboot folks, Arthur pushed the proof of concept *Use FDT as payload handoff instead lb_tables* [1] to pass information to the payload via FDT instead of coreboot tables. Julius asked for more background, and Arthur replied. I am moving the discussion to the list for broader visibility, and better way of discussing these things than Gerrit comments. >> Were there any discussions about this that I missed (if so would >> you mind linking to them)? Can you explain who needs this and why, >> what's the overall goal? (I know there have been vague discussions >> about various new firmware handoff formats from Arm and Intel and >> others, but if this is related to those I missed the parts where >> there was suddenly consensus on how it should look, and why that is >> FDT.) > > Most of the discussion happened verbally at osfc, so I can't point to > any written communication. There is > https://www.osfc.io/2022/talks/collaborative-firmware-payload-handoff-desig… > if you have the time to listen to a talk. > So if I have to summarize the idea's/goals: > > * Intel Universal scalable firmware suggested using UEFI HOBs as a handoff structure > * coreboot won't do that as it's no improvement over coreboot tables > * USF won't make coreboot tables a standard either > * Maybe something new can be created that would fit both the needs of payload handoff and other binary information passing between programs (e.g. FSP)? > * USF people suggested using CBOR to encode data to so that serialization/deserialization of data is explicit instead of using structs. > * CBOR is an improvement for the data format, but not what coreboot/(other project) should tell the payload: i.e. what entries are needed > * FDT was suggested as an alternative as it covers both explicit serialization/deserialization + what payload tell each other since the spec already exists, with a lot of existing compatible node strings. (e.g. I reuse simple-framebuffer from Linux here to hand of the framebuffer) Also most payloads and firmware have code for working with FDT. > * (unrelated to payload handof but part of the discussions) Another idea is to also use FDT as an interface between coreboot and FSP. > * a lot of payloads already have code to work with FDT so having FDT as a handoff structure would not be a lot of work > * FDT should make compatibility between coreboot and payload easier when handoff entries are added or changed (plain structs are painful if they are updated as both payload and coreboot definitions need to match) > * debugging the handoff structure is easier with FDT as you can use DTC in the OS userspace or coreboot code can also print out the full structure in human readable format. > > What are your thoughts? > > * Is it a good idea to use FDT and eventually replace coreboot tables. > * If so, do we keep both for a while to make transitioning easier? I think maintaining two structures is not sustainable long term. > * How should the 'entries' be structured? I made compatible nodes that map somewhat to existing coreboot table structs. Kind regards, Paul [1]: https://review.coreboot.org/c/coreboot/+/68719

12 24

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot November 2022