coreboot December 2022

coreboot@coreboot.org

28 participants
35 discussions

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

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot December 2022