coreboot

coreboot@coreboot.org

6 participants
39686 discussions

Re: Guidelines for using die()
by Martin Roth 15 Dec '22

15 Dec '22

From the leadership meeting: There was general agreement about creating a guideline to only die when coreboot cannot continue. This is strictly a guideline, and is up to the developers to do what makes sense. This means that if it's possible to continue booting, we should do our best. When possible, print a warning and try to continue. Notes: [Angel] We agree with the reasoning, especially because what CB:55690 fixed was quite embarrassing: it broke booting on the T440p until CB;55687 fixed it by adding one line... However, we’d like to ask everyone to be careful when considering removing die()’s in RAM init. Memory init is arcane magic, and it can fail in the most subtle of ways (see CB:48550 for a rather embarrassing example, and CB:47680 for the fix to a long-standing Sandy/Ivy NRI bug that could cause instability). The two errors shown here are about the installed memory modules: if a computer worked before, these errors can only occur if the installed memory modules are changed (or if the SPD data got corrupted somehow, which is even worse). In our honest opinion, it’s best for the user to immediately let them know that their newly-installed memory isn’t going to work properly rather than to risk memory-related instability for the sake of booting. We’d prefer to keep the “controller minimum freq” die() because it stops the RAM from being overclocked (we could add a Kconfig option to continue anyway, though), but we agree with reworking the “SPD mismatch” code as described, and we even volunteer to do so if we can test it. On a somewhat related note, it’s a good idea to avoid using die() within memory init code, but to propagate errors to the caller. This allows retrying memory init with different parameters or disabling failing channels, which increases the chances of booting. [Angel] TL;DR the 2nd example is fine, the rest are OK. Consider using WARN_ON and BUG_ON macros (assert, but allow handling the result in regular C code). For instance: if (BUG_ON(did_error_happen())) handle_error(); [Angel] TO DO: Add the aforementioned macros to coreboot. [Angel] TO DO: Figure out how to enable FATAL_ASSERTS for 9elements QA. [David] "Boots, not bricks" - Need a recovery path if at all possible. Use asserts - so fatal asserts will halt the system and if fatal-asserts are not set, the system will continue. * coreboot needs better document on asserts and error handling. * Julius will try to work on this. Angel can help. * Martin to add documentation to the header files so that information about assert() and die() for IDEs that support this feature. * We need a way to report failures for security issues to later in the boot process when that information can be given to the user or to reboot to whatever recovery mode is implemented. This needs to be designed and discussed separately.

2 1

Porting a board, how to get the overcurrent pin mapping for QM370?
by Jose Trujillo 15 Dec '22

15 Dec '22

Hello Ladies and Gentlemen: I am trying to do the porting of a computer module based on Intel CoffeeLake/QM370. I don't have the schematics. I was trying to find out how to extract/dump the overcurrent pin mapping from the system, but I was unable to find this information. I need this configuration to correctly set the USB configuration in the devicetree.cb. In older systems previous to Skylake this information was in the RCBA (dumped by inteltool), but there is no RCBA in newer chipsets. Anyone can help me in providing the steps? Thank you, Jose Trujillo.

2 4

Guidelines for using die()
by Martin Roth 14 Dec '22

14 Dec '22

I'd like to propose that we set up a guideline for when coreboot should use die(). My belief, and proposal for the guideline is that coreboot should *ONLY* die in 2 situations: 1) The system cannot continue booting. Examples: * coreboot needs to jump somewhere to continue, but doesn’t have a location to jump to. * The system needs to reset to continue, but reset failed or isn’t implemented. * Memory init failed. (SPD can't be read, Failed to initialize memory controller, etc.) 2) There’s a known security issue if booting continues. Even this shouldn’t be a hard die(), because there should still be a manual process to boot the system so that the firmware can be updated. (we can work that out later) Examples: * HASH table verification failed! * Can't verify flash protections! It looks like most die() calls are valid, but there are currently cases where coreboot dies for a “non-fatal” reason. The case I’m currently looking at is when running an FSP, and the FSP ID is not the expected ID. https://review.coreboot.org/c/coreboot/+/69412 My opinion is that coreboot should put out a warning, but jump to the FSP anyway. If it fails, it’s the FSP’s responsibility to return a failure code to coreboot to die. (More likely, it would die internally without returning, which is no worse than coreboot dying. coreboot has no idea what the FSP is going to do and isn’t responsible for it. This is a case of “there looks like there’s a problem, proceed with caution”, but is being treated as a situation where coreboot cannot continue. Other examples where maybe we shouldn’t be dying: * die("EHCI controller (00:1a.7) not listed in devicetree.\n"); We don’t need the EHCI controller to boot, at least not at this point. * die("RAM init: Decoded SPD DRAM freq is slower than the controller minimum!"); So try with the controller minimum and die if that fails. * die("Onboard SPDs must match each other"); Pick an SPD and try initializing memory with it. Die if that fails. * die("IGD is disabled!"); So try to boot without graphics… * die("Invalid GPIO pad number\n"); So put out a warning and skip the GPIO. An assert would be reasonable - a hard die() isn’t, in my opinion. * die("BUG: Increase ehci_dbg_info reserve in CAR"); Use an assert, bail out of ehci_dbg. coreboot doesn't even make ASSERT fatal by default because we don't have a good way to communicate errors to the user. This proposal aligns with that. I've added this topic to the leadership meeting minutes for tomorrow. Let me know what you think. Thanks! Martin

5 4

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

13 Dec '22

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 3 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 3 of 3 defect(s) ** CID 1501510: Integer handling issues (OVERFLOW_BEFORE_WIDEN) /src/commonlib/bsd/include/commonlib/bsd/mem_chip_info.h: 104 in mem_chip_info_total_density_bytes() ________________________________________________________________________________________________________ *** CID 1501510: Integer handling issues (OVERFLOW_BEFORE_WIDEN) /src/commonlib/bsd/include/commonlib/bsd/mem_chip_info.h: 104 in mem_chip_info_total_density_bytes() 98 { 99 uint64_t bytes = 0; 100 int i; 101 102 for (i = 0; i < info->num_entries; i++) { 103 const struct mem_chip_entry *e = &info->entries[i]; >>> CID 1501510: Integer handling issues (OVERFLOW_BEFORE_WIDEN) >>> Potentially overflowing expression "e->density_mbits * (e->channel_io_width / e->io_width)" with type "unsigned int" (32 bits, unsigned) is evaluated using 32-bit arithmetic, and then used in a context that expects an expression of type "uint64_t" (64 bits, unsigned). 104 bytes += e->density_mbits * (e->channel_io_width / e->io_width) * (MiB / 8); 105 } 106 107 return bytes; 108 } 109 ** CID 1501509: (CONSTANT_EXPRESSION_RESULT) /src/soc/amd/cezanne/fsp_m_params.c: 160 in platform_fsp_memory_init_params_cb() /src/soc/amd/morgana/fsp_m_params.c: 162 in platform_fsp_memory_init_params_cb() /src/soc/amd/mendocino/fsp_m_params.c: 161 in platform_fsp_memory_init_params_cb() /src/soc/amd/glinda/fsp_m_params.c: 162 in platform_fsp_memory_init_params_cb() ________________________________________________________________________________________________________ *** CID 1501509: (CONSTANT_EXPRESSION_RESULT) /src/soc/amd/cezanne/fsp_m_params.c: 160 in platform_fsp_memory_init_params_cb() 154 /* devicetree config is const, use local copy */ 155 static struct usb_phy_config lcl_usb_phy; 156 lcl_usb_phy = config->usb_phy; 157 lcl_usb_phy.Version_Major = FSP_USB_STRUCT_MAJOR_VERSION; 158 lcl_usb_phy.Version_Minor = FSP_USB_STRUCT_MINOR_VERSION; 159 lcl_usb_phy.TableLength = sizeof(struct usb_phy_config); >>> CID 1501509: (CONSTANT_EXPRESSION_RESULT) >>> "(uintptr_t)&lcl_usb_phy <= 4294967295UL /* (uint32_t)4294967295U */" is always true regardless of the values of its operands. This occurs as the logical operand of "if". 160 if ((uintptr_t)&lcl_usb_phy <= UINT32_MAX) { 161 mcfg->usb_phy_ptr = (uint32_t)(uintptr_t)&lcl_usb_phy; 162 } else { 163 printk(BIOS_ERR, "USB PHY config struct above 4GB; can't pass USB PHY " 164 "configuration to 32 bit FSP.\n"); 165 mcfg->usb_phy_ptr = 0; /src/soc/amd/morgana/fsp_m_params.c: 162 in platform_fsp_memory_init_params_cb() 156 /* devicetree config is const, use local copy */ 157 static struct usb_phy_config lcl_usb_phy; 158 lcl_usb_phy = config->usb_phy; 159 lcl_usb_phy.Version_Major = FSP_USB_STRUCT_MAJOR_VERSION; 160 lcl_usb_phy.Version_Minor = FSP_USB_STRUCT_MINOR_VERSION; 161 lcl_usb_phy.TableLength = sizeof(struct usb_phy_config); >>> CID 1501509: (CONSTANT_EXPRESSION_RESULT) >>> "(uintptr_t)&lcl_usb_phy <= 4294967295UL /* (uint32_t)4294967295U */" is always true regardless of the values of its operands. This occurs as the logical operand of "if". 162 if ((uintptr_t)&lcl_usb_phy <= UINT32_MAX) { 163 mcfg->usb_phy_ptr = (uint32_t)(uintptr_t)&lcl_usb_phy; 164 } else { 165 printk(BIOS_ERR, "USB PHY config struct above 4GB; can't pass USB PHY " 166 "configuration to 32 bit FSP.\n"); 167 mcfg->usb_phy_ptr = 0; /src/soc/amd/mendocino/fsp_m_params.c: 161 in platform_fsp_memory_init_params_cb() 155 /* devicetree config is const, use local copy */ 156 static struct usb_phy_config lcl_usb_phy; 157 lcl_usb_phy = config->usb_phy; 158 lcl_usb_phy.Version_Major = FSP_USB_STRUCT_MAJOR_VERSION; 159 lcl_usb_phy.Version_Minor = FSP_USB_STRUCT_MINOR_VERSION; 160 lcl_usb_phy.TableLength = sizeof(struct usb_phy_config); >>> CID 1501509: (CONSTANT_EXPRESSION_RESULT) >>> "(uintptr_t)&lcl_usb_phy <= 4294967295UL /* (uint32_t)4294967295U */" is always true regardless of the values of its operands. This occurs as the logical operand of "if". 161 if ((uintptr_t)&lcl_usb_phy <= UINT32_MAX) { 162 mcfg->usb_phy_ptr = (uint32_t)(uintptr_t)&lcl_usb_phy; 163 } else { 164 printk(BIOS_ERR, "USB PHY config struct above 4GB; can't pass USB PHY " 165 "configuration to 32 bit FSP.\n"); 166 mcfg->usb_phy_ptr = 0; /src/soc/amd/glinda/fsp_m_params.c: 162 in platform_fsp_memory_init_params_cb() 156 /* devicetree config is const, use local copy */ 157 static struct usb_phy_config lcl_usb_phy; 158 lcl_usb_phy = config->usb_phy; 159 lcl_usb_phy.Version_Major = FSP_USB_STRUCT_MAJOR_VERSION; 160 lcl_usb_phy.Version_Minor = FSP_USB_STRUCT_MINOR_VERSION; 161 lcl_usb_phy.TableLength = sizeof(struct usb_phy_config); >>> CID 1501509: (CONSTANT_EXPRESSION_RESULT) >>> "(uintptr_t)&lcl_usb_phy <= 4294967295UL /* (uint32_t)4294967295U */" is always true regardless of the values of its operands. This occurs as the logical operand of "if". 162 if ((uintptr_t)&lcl_usb_phy <= UINT32_MAX) { 163 mcfg->usb_phy_ptr = (uint32_t)(uintptr_t)&lcl_usb_phy; 164 } else { 165 printk(BIOS_ERR, "USB PHY config struct above 4GB; can't pass USB PHY " 166 "configuration to 32 bit FSP.\n"); 167 mcfg->usb_phy_ptr = 0; ** CID 1501508: Null pointer dereferences (FORWARD_NULL) /src/drivers/intel/fsp2_0/memory_init.c: 61 in do_fsp_post_memory_init() ________________________________________________________________________________________________________ *** CID 1501508: Null pointer dereferences (FORWARD_NULL) /src/drivers/intel/fsp2_0/memory_init.c: 61 in do_fsp_post_memory_init() 55 /* ramstage uses the FSP-M version when updating the MRC cache */ 56 if (CONFIG(CACHE_MRC_SETTINGS) && !s3wake) { 57 fsp_version_cbmem = cbmem_add(CBMEM_ID_FSPM_VERSION, 58 sizeof(fsp_version)); 59 if (!fsp_version_cbmem) 60 printk(BIOS_ERR, "Failed to add FSP-M version to cbmem.\n"); >>> CID 1501508: Null pointer dereferences (FORWARD_NULL) >>> Dereferencing null pointer "fsp_version_cbmem". 61 *fsp_version_cbmem = fsp_version; 62 } 63 64 /* Create romstage handof information */ 65 romstage_handoff_init(s3wake); 66 } ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0

FOSDEM23 Open Source Firmware, BMC and Bootloader Devroom CFP - last call
by Michał Żygowski 12 Dec '22

12 Dec '22

Hi all, Just a reminder that FOSDEM23 Open Source Firmware, BMC and Bootloader Devroom CfP ends today. If you have any coreboot topics you would like to present, feel free to send a submission: https://lists.fosdem.org/pipermail/fosdem/2022q4/003467.html Best regards, -- Michał Żygowski Firmware Engineer GPG: 6B5BA214D21FCEB2 https://3mdeb.com | @3mdeb_com

1 0

Joining the mailing list, also NUC?
by Mac Wynkoop 04 Dec '22

04 Dec '22

Hello all, I see that at one point someone was able to flash Coreboot onto a 6th gen Intel NUC? Are there any instructions floating around on how to do that? Thanks all, Mac

1 0

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 02 Dec '22

02 Dec '22

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 2 new defect(s) introduced to coreboot found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 2 of 2 defect(s) ** CID 1501187: Control flow issues (DEADCODE) /src/drivers/intel/fsp2_0/ppi/mp_service_ppi.c: 40 in mp_get_processor_info() ________________________________________________________________________________________________________ *** CID 1501187: Control flow issues (DEADCODE) /src/drivers/intel/fsp2_0/ppi/mp_service_ppi.c: 40 in mp_get_processor_info() 34 if (processor_number >= MIN(get_cpu_count(), CONFIG_MAX_CPUS)) 35 return FSP_NOT_FOUND; 36 37 extern struct cpu_info cpu_infos[]; 38 struct cpu_info *info = &cpu_infos[processor_number]; 39 if (!info) >>> CID 1501187: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "return 2147483655U;". 40 return FSP_DEVICE_ERROR; 41 42 if (processor_info_buffer == NULL) 43 return FSP_INVALID_PARAMETER; 44 apicid = info->cpu->path.apic.apic_id; 45 ** CID 1501186: (DEADCODE) /src/mainboard/google/herobrine/mainboard.c: 105 in mainboard_needs_pcie_init() /src/mainboard/google/herobrine/mainboard.c: 102 in mainboard_needs_pcie_init() ________________________________________________________________________________________________________ *** CID 1501186: (DEADCODE) /src/mainboard/google/herobrine/mainboard.c: 105 in mainboard_needs_pcie_init() 99 uint32_t sku = sku_id() & sku_bits_mask; 100 101 if (sku == CROS_SKU_UNKNOWN) { 102 printk(BIOS_WARNING, "Unknown SKU (%#x); assuming PCIe", sku); 103 return true; 104 } else if (sku == CROS_SKU_UNPROVISIONED) { >>> CID 1501186: (DEADCODE) >>> Execution cannot reach this statement: "printk(4, "Unprovisioned SK...". 105 printk(BIOS_WARNING, "Unprovisioned SKU (%#x); assuming PCIe", sku); 106 return true; 107 } 108 109 if ((sku % 3) == 2) 110 return true; /src/mainboard/google/herobrine/mainboard.c: 102 in mainboard_needs_pcie_init() 96 * each tristate, so we can represent numbers up to 27, or 5 bits 97 */ 98 uint32_t sku_bits_mask = 0xff; 99 uint32_t sku = sku_id() & sku_bits_mask; 100 101 if (sku == CROS_SKU_UNKNOWN) { >>> CID 1501186: (DEADCODE) >>> Execution cannot reach this statement: "printk(4, "Unknown SKU (%#x...". 102 printk(BIOS_WARNING, "Unknown SKU (%#x); assuming PCIe", sku); 103 return true; 104 } else if (sku == CROS_SKU_UNPROVISIONED) { 105 printk(BIOS_WARNING, "Unprovisioned SKU (%#x); assuming PCIe", sku); 106 return true; 107 } ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0

Regarding Google Summer of Code (Introduction)
by Sarthak Rohatgi 01 Dec '22

01 Dec '22

Greetings, I am Sarthak Rohatgi, a third year student from India. I am very much interested in Google Summer of Code (GSOC) for 2023, would you be able to guide me into it? About myself - I am Sarthak Rohatgi, currently a 3rd year student pursuing Computer Science Engineering. I am really passionate about programming and have been doing it for 4-5 years. I have worked with many different technologies and languages for example C, C++, JavaScript (NodeJS), Flutter, React, Django, GoLang, MySQL, PostgreSQL, WebRTC, WebSockets Bash and more. I did my Apprenticeship for 1 month from Microsoft and created and deployed multiple websites on the web. I also have experience in cross-platform development using Flutter Framework and have developed 3 apps which are in production. My preferred tech stack includes, C++, Flutter, GoLang and JavaScript. I have been interested in open-source for a long time but haven't had the chance to get started with it. I would love to know how I can get started with it and get selected as a GSOC Contributor as well. (Attached Below is my resume which has all the links including my GitHub, Hackerrank, Project links, Leetcode, etc.) Resume <https://sarthakrohatgi012201-dot-mindful-primer-357708.uc.r.appspot.com/?c=…> Thanks & Regards Sarthak Rohatgi [image: sarthakrohatgi012201]sarthakrohatgi012201

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