coreboot June 2020

coreboot@coreboot.org

36 participants
38 discussions

New Defects reported by Coverity Scan for coreboot
by scan-admin＠coverity.com 26 Jun '20

26 Jun '20

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. New defect(s) Reported-by: Coverity Scan Showing 6 of 6 defect(s) ** CID 1429983: Control flow issues (DEADCODE) /src/drivers/uart/acpi/acpi.c: 104 in uart_acpi_fill_ssdt() ________________________________________________________________________________________________________ *** CID 1429983: Control flow issues (DEADCODE) /src/drivers/uart/acpi/acpi.c: 104 in uart_acpi_fill_ssdt() 98 reset_gpio_index >= 0 || enable_gpio_index >= 0) { 99 struct acpi_dp *dsd = acpi_dp_new_table("_DSD"); 100 if (config->compat_string) 101 acpi_dp_add_string(dsd, "compatible", 102 config->compat_string); 103 if (irq_gpio_index >= 0) >>> CID 1429983: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "acpi_dp_add_gpio(dsd, "irq-...". 104 acpi_dp_add_gpio(dsd, "irq-gpios", path, 105 irq_gpio_index, 0, 106 config->irq_gpio.polarity); 107 if (reset_gpio_index >= 0) 108 acpi_dp_add_gpio(dsd, "reset-gpios", path, 109 reset_gpio_index, 0, ** CID 1429982: Null pointer dereferences (NULL_RETURNS) ________________________________________________________________________________________________________ *** CID 1429982: Null pointer dereferences (NULL_RETURNS) /src/drivers/intel/pmc_mux/mux.c: 16 in mux_fill_ssdt() 10 { 11 return "MUX"; 12 } 13 14 static void mux_fill_ssdt(const struct device *dev) 15 { >>> CID 1429982: Null pointer dereferences (NULL_RETURNS) >>> Dereferencing a pointer that might be "NULL" "acpi_device_scope(dev)" when calling "acpigen_write_scope". 16 acpigen_write_scope(acpi_device_scope(dev)); 17 acpigen_write_device(acpi_device_name(dev)); 18 19 acpigen_write_name_string("_HID", TGL_PMC_MUX_HID); 20 acpigen_write_name_string("_DDN", dev->chip_ops->name); 21 ** CID 1429981: Null pointer dereferences (NULL_RETURNS) ________________________________________________________________________________________________________ *** CID 1429981: Null pointer dereferences (NULL_RETURNS) /src/soc/intel/tigerlake/pmc.c: 104 in soc_pmc_fill_ssdt() 98 res->limit = res->base + res->size - 1; 99 res->flags = IORESOURCE_IO | IORESOURCE_ASSIGNED | IORESOURCE_FIXED; 100 } 101 102 static void soc_pmc_fill_ssdt(const struct device *dev) 103 { >>> CID 1429981: Null pointer dereferences (NULL_RETURNS) >>> Dereferencing a pointer that might be "NULL" "acpi_device_scope(dev)" when calling "acpigen_write_scope". 104 acpigen_write_scope(acpi_device_scope(dev)); 105 acpigen_write_device(acpi_device_name(dev)); 106 107 acpigen_write_name_string("_HID", PMC_HID); 108 acpigen_write_name_string("_DDN", "Intel(R) Tiger Lake IPC Controller"); 109 ** CID 1429980: Null pointer dereferences (NULL_RETURNS) ________________________________________________________________________________________________________ *** CID 1429980: Null pointer dereferences (NULL_RETURNS) /src/soc/amd/picasso/root_complex.c: 138 in root_complex_fill_ssdt() 132 133 /* Used by \_SB.PCI0._CRS */ 134 static void root_complex_fill_ssdt(const struct device *device) 135 { 136 msr_t msr; 137 >>> CID 1429980: Null pointer dereferences (NULL_RETURNS) >>> Dereferencing a pointer that might be "NULL" "acpi_device_scope(device)" when calling "acpigen_write_scope". 138 acpigen_write_scope(acpi_device_scope(device)); 139 140 msr = rdmsr(TOP_MEM); 141 acpigen_write_name_dword("TOM1", msr.lo); 142 msr = rdmsr(TOP_MEM2); 143 /* ** CID 1429979: Null pointer dereferences (NULL_RETURNS) ________________________________________________________________________________________________________ *** CID 1429979: Null pointer dereferences (NULL_RETURNS) /src/drivers/intel/pmc_mux/con/con.c: 37 in con_fill_ssdt() 31 struct acpi_dp *dsd; 32 33 if (!dev->enabled) 34 return; 35 36 /* Reference the existing scope and write CONx device */ >>> CID 1429979: Null pointer dereferences (NULL_RETURNS) >>> Dereferencing a pointer that might be "NULL" "acpi_device_scope(dev)" when calling "acpigen_write_scope". 37 acpigen_write_scope(acpi_device_scope(dev)); 38 acpigen_write_device(acpi_device_name(dev)); 39 40 acpigen_write_name_integer("_ADR", dev->path.generic.id); 41 42 /* _DSD, Device-Specific Data */ ** CID 1420207: Null pointer dereferences (NULL_RETURNS) ________________________________________________________________________________________________________ *** CID 1420207: Null pointer dereferences (NULL_RETURNS) /src/superio/nuvoton/npcd378/superio.c: 328 in npcd378_ssdt_pwr() 322 323 acpigen_pop_len(); /* Pop SIOS method */ 324 325 acpigen_pop_len(); /* Pop Scope */ 326 327 /* Inject into parent: */ >>> CID 1420207: Null pointer dereferences (NULL_RETURNS) >>> Dereferencing a pointer that might be "NULL" "acpi_device_scope(dev)" when calling "acpigen_write_scope". 328 acpigen_write_scope(acpi_device_scope(dev)); 329 330 acpigen_write_name_integer("MSFG", 1); 331 acpigen_write_name_integer("KBFG", 1); 332 acpigen_write_name_integer("PMFG", 0); 333 ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/ls/click?upn=nJaKvJSIH-2FPAfmty-2BK5tYpPkl…

1 0

Re: libgfxinit quick starter guide
by Nico Huber 25 Jun '20

25 Jun '20

Hi Michal, hi Matt, On 15.03.20 06:41, Matt B wrote: > You probably want to speak with Nico. He's a libgfxinit expert afaik. thanks for the heads up :) > On Wed, Mar 11, 2020 at 9:45 AM Michal Zygowski <michal.zygowski(a)3mdeb.com> > wrote: > >> Particularly I would like to implement Braswell support for native >> graphics init with libgfxinit. Angel is also looking forward to Braswell support. He mentioned it as a possible summer-of-code stretch goal (after Bay Trail support), IIRC. But applications are not written yet (start tomorrow). > I see the programming manuals from Intel >> are in place: >> https://01.org/linuxgraphics/documentation/hardware-specification-prms Alas, this is a pitfall for Braswell. The only part that matters for libgfxinit (information about the display engine) is 100% scrubbed away. If you look into the `Display` chapter, it only contains legacy VGA registers and audio verbs, nothing about display at all. And if you search for any of "hdmi", "lvds", "mipi", "dsi", or "lane" in the `Register` chapter: nothing :-/ So for Braswell, the only public information source I know is the Linux driver i915. It's the one exception btw. All other chips have a proper `Display` chapter. Hence also the idea to add Bay Trail support first. Even if it turns out to be much different, we could at least tell if Brasswell is closer to Bay Trail or the newer Haswell/Apollo Lake engine. >> What do I need to implement a new microarchitecture in libgfxinit? Where >> to start and what should I focus on? This may get a little longer... but I knew I'll have to write it down eventually. In Ada, the code is organized in so called `packages`. In the way they are used in libgfxinit, one can simply see them as compilation units. Each package has a specification (.ads) file with declarations and a body (.adb) with code. Much like a header and a c file. Packages form a hierarchy and the name of the file has to reflect the package name, including its parents (stupid, imho). Libgfxinit has two major mechanisms in place to support different hardware generations: 1. Alternative implementations of packages. These are organized in sub-directories (also because every alternative package body has to have the same file name). For instance, we have different implementations for the package `HW.GFX.GMA.Connectors` in g45/, ironlake/, haswell_shared/ (the latter is shared with all newer generations since Haswell). Having alternative implementations of packages also means we can't build one binary that supports all generations. Luckily, we don't have to, so far :) 2. Configuration flags that are tested in shared code. Much like we have `if (CONFIG(FOO_BAR))` in coreboot, we have `if Config.Foo_Bar then` in libgfxinit. All these flags are gathered in a single package `HW.GFX.GMA.Config` which keeps conditions on specific hardware generations in a central place. The file, `hw-gfx-gma-config.ads.template`, is pre-processed with some sed-foo (see `common/Makefile.inc`). The comment from `hw-gfx-gma-config.ads.template:99` on explains some of the rea- soning. How much code sharing makes sense depends on the similarity to other hardware generations. I wouldn't be surprised if Bay Trail and Braswell end up using the g45/ code (no PCH and probably pre DDI which was intro- duced with Haswell), but I don't know that yet. Some more about the central packages: HW.GFX* (excluding HW.GFX.GMA*) =============================== There's some vendor-agnostic code around. Mostly for DP training and EDID interpretation. HW.GFX.GMA ========== This exposes the primary interface (procedure Update_Outputs()) and contains the overall control flow for setting up displays. Update_Outputs() takes a list of configurations for each graphics pipeline (up to three) and will try to set things up according to the configuration. Assuming a pipe is unconfigured, roughly the following steps are performed (by procedure Enable_Output()): * Optionally select a link configuration (e.g. for DP, how many lanes at what rate). * Allocate a PLL for the pixel/DP clock. * Try to train the selected link configuration (if there is none, the loops simply run once): - Prepare output connectors (Pre_On) - Enable the graphics pipeline (On) - Finalize the output-connector configuration (Post_On) This usually doesn't need changes for new hardware. HW.GFX.GMA.Pipe_Setup* (formerly Display_Controller) ==================================================== At the heart of the display engine is the pipe setup. Here we configure the framebuffer format (how to interpret bytes from DRAM), image pro- cessing (e.g. scaling) and the `Transcoders` that turn the image into a continuous stream of bits (including blank times) for a given pixel clock. IOW, everything from the framebuffer to a modeline. This was called `Display_Controller` earlier (probably for historical Linux reasons) and is still inside `hw-gfx-gma.adb` (easy to fix, but I didn't care to so far). It's mostly configured by flags from the `Config` package. Configu- ration of scalers is often implemented very differently, but most of it didn't change much over the years. HW.GFX.GMA.Connectors ===================== The `Connectors` package dispatches the Pre_On() and Post_On() calls (before and after configuring the graphics pipeline) to sub-packages for the individual connector types. This is a bit subtle. In a sense, `Connectors` reflect the outputs of the CPU package. In the first generations with a PCH (Ironlake including Sandy and Ivy Bridge) the CPU didn't have actual display outputs (like VGA, LVDS, HDMI etc.) but only links to the PCH which contained the final outputs. Later, the final outputs went back onto the CPU die. So we have three very different versions of this package: * g45/ outputs are in the GMCH (or CPU if one would add Bay Trail, it shouldn't matter). * ironlake/ FDI links in the CPU and (most) outputs in the PCH. * haswell_shared/ newer outputs (DDI) in the CPU (no legacy interfaces like VGA/LVDS, and HDMI/DP configuration changed since g45/). If none of these match the hardware to be added, one would have to write a new one. HW.GFX.GMA.PLLs =============== Usually there are some similarities but often changes between hardware generations. HW.GFX.GMA.Power_And_Clocks =========================== This started with some setup for generation specific things that didn't find another place. Newer generations have configurable clocks and can turn individual parts of the display engine on and off. Older ones often just have to report a pre-set Core Display Clock (CDClk). To wrap it up, `Power_And_Clocks` and `PLLs` most often need changes for new hardware. Followed by `Connectors` if these changed significantly, but most often one can add some code controlled by `Config` flags here. And, not to forget, all flags in the `Config` package need to be checked how they should be set for the new hardware. >> >> tl;dr; >> Haven't written anything in SPARK/Ada yet. It will be a new adventure >> for me. Can be fun but can also be exhausting ;) Depends much on how you can cope with nagging compilers and related tools. Nico

3 17

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

23 Jun '20

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 1 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 1 of 1 defect(s) ** CID 1429974: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /src/soc/amd/picasso/bootblock/bootblock.c: 93 in write_resume_eip() ________________________________________________________________________________________________________ *** CID 1429974: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /src/soc/amd/picasso/bootblock/bootblock.c: 93 in write_resume_eip() 87 enable_cache(); 88 } 89 90 static void write_resume_eip(void) 91 { 92 msr_t s3_resume_entry = { >>> CID 1429974: Integer handling issues (CONSTANT_EXPRESSION_RESULT) >>> "(uint64_t)(uintptr_t)bootblock_resume_entry >> 32" is 0 regardless of the values of its operands. This occurs as an initializer. 93 .hi = (uint64_t)(uintptr_t)bootblock_resume_entry >> 32, 94 .lo = (uintptr_t)bootblock_resume_entry & 0xffffffff, 95 }; 96 97 /* 98 * Writing to the EIP register can only be done once, otherwise a fault is triggered. ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/ls/click?upn=nJaKvJSIH-2FPAfmty-2BK5tYpPkl…

1 0

Re: Supporting blobs with licenses that you agree to on download
by Julius Werner 18 Jun '20

18 Jun '20

[resend to mailing list with approved address] On Tue, Jun 9, 2020 at 6:41 PM Julius Werner <jwerner(a)google.com> wrote: > > Trying to generalize the discussion from > https://review.coreboot.org/c/blobs/+/41379 here. > > Some of the blobs in our 3rdparty/blobs repository have license > language that basically says you have to agree to the license terms to > even download the file, and otherwise you're not allowed to possess > it. Some example language from the fbg1701 license: > > > Do not use or load software from this site or any associated materials (collectively, the "Software") until you have carefully read the following terms and conditions. By loading or using the Software, you agree to the terms of this Agreement. If you do not wish to so agree, do not install or use the Software. > > As far as I can tell this affects > 3rdparty/blobs/mainboard/facebook/fbg1701/license.txt and (with > slightly more ambiguous language) almost all AMD licenses (e.g. > 3rdparty/blobs/soc/amd/stoneyridge/license.txt). We're trying to add a > new blob needed to support a Qualcomm platform that comes with similar > language. > > Some people pointed out on that CL that they are uncomfortable with > licenses like this in the blobs directory, since it means they cannot > clone the whole repository without agreeing to all licenses with this > sort of language in the repo (even if they only want to use a > completely unrelated blob). The concern was also raised that this > violates the binary policy (the "unlimited redistribution" part)... I > guess it's a matter of interpretation whether a license that allows > you to redistribute the binary *if you agree to it* is still > "unlimited". It seems that there were already similar concerns raised > when the fbg1701 license landed (https://review.coreboot.org/34441) > but it was submitted despite the unresolved disagreement. > > Can we come up with and implement a solution here that both respects > people's concerns and still allows us to support the affected > platforms? Clearly, the rules should be the same for all blobs, so if > some blobs with language like this are already in the repository, it > shouldn't be grounds to reject new blobs from landing. If we can come > up with an alternative that people would feel more comfortable with, > we should also apply it to those existing cases. > > Would it be enough to just create a second repository > (3rdparty/restrictive_blobs or something like that) which is not > automatically checked out by CONFIG_USE_BLOBS so people can make a > separate conscious decision if they want to check it out? It seems > that something similar to this was already attempted with the > 3rdparty/amd_blobs repository (but it looks like the work wasn't > finished because those blobs are still in 3rdparty/blobs as well?). Is > it enough to put all these blobs into a single separate repository or > do we need to make a separate repository per license (that might be > okay for the big AMD case but it probably wouldn't scale well for > small one-offs)?

5 9

Lenovo R500
by trabajo3 18 Jun '20

18 Jun '20

Hello!, I wantt to know if the Lenovo R500 has coreboot support without any blobs https://phoronix.com/scan.php?page=news_item&px=Coreboot-4.10-Released Here it says that is supported but https://coreboot.org/status/board-status.html doesnt appear and in the tree also no Another question is if there is any tool like in the libreboot proyect to change mac address and if there is any complete video tutorial to install libreboot, because in youtube there are full videos about libreboot but for coreboot i didnt find anyone with good explanation. Thanks for ur time! Best Regards Sent with [ProtonMail](https://protonmail.com) Secure Email.

3 3

Fwd: Anyway to change BIOSWE, BLE, SMM_BWP & PR0-5 protection bits?
by Alan K.L. Mok 18 Jun '20

18 Jun '20

Hi Nico, Sorry for this late report. I am still fiddling with the coreboot code to setup the SMM_BWP bit you suggested but with not much progress. Beside the SMM_BWP, I followed your recommendation and was able to successfully turn on the PR0 & FLOCKDN protections. I can confirm these by running chipsec against the compiled image. [chipsec_main(a)Controller_locked.txt] I think I am fine at the moment and am somehow confident to put my X1 Carbon onto the internet. I will further explore coreboot codes for additional flash memory write protections on my own. I just want to express my gratitude for your help and towards the people who make this project even possible and freely available to the whole world, Thank you!! My warmest regards, Alan ---------- Forwarded message --------- From: Alan K.L. Mok <alanmok1(a)gmail.com> Date: Sat, Jun 6, 2020 at 5:35 PM Subject: Fwd: [coreboot] Anyway to change BIOSWE, BLE, SMM_BWP & PR0-5 protection bits? To: <nico.h(a)gmx.de>, <coreboot(a)coreboot.org> Hello Nico, Just a quick update that the platform I rely on (Debian 11 testing live) for Coreboot compilation messed up itself after package updates and my progress is retarded. [Debian.jpg] I had some readings on the PRx registers and now I understand that those are registers accepting base, limit & range of address in memory to protect from read/write and is provided and enforced by the SPI controller. I completely agree with you that the protection bits I asked in my previous email are not effective security measures since SMM code is privileged enough to freely change those bits anytime and as you mentioned there is presently not yet any secure SMM implementation (I think that the UEFI spec makes everyones' life more difficult.....). I will report back in next week on the menu makeconfig options you mentioned in your previous email. Thanks for your help, Alan ---------- Forwarded message --------- From: Alan K.L. Mok <alanmok1(a)gmail.com> Date: Sun, May 31, 2020 at 11:56 PM Subject: Re: [coreboot] Anyway to change BIOSWE, BLE, SMM_BWP & PR0-5 protection bits? To: Nico Huber <nico.h(a)gmx.de> Cc: <coreboot(a)coreboot.org> Hello Nico, Thank you very much for your reply, it is informative and helpful! I will read more regarding the PRx registers and try to compile with the menuconfig options you mentioned. Will also scrutinize the southbridge C code and see if I can comprehend it. I will report back again within the next few days. Hope this email finds you are having a wonderful day, Alan On Sun, May 31, 2020 at 6:01 PM Nico Huber <nico.h(a)gmx.de> wrote: > Hello Alan, > > On 31.05.20 06:20, Alan K.L. Mok wrote: > > 1. Can anyone please tell let me know how can I achieve the captioned > > objectives? I looked into ifdtool & uefitool but found nothing related to > > my goal. I also tried the "lock ME/TXE" option during make menuconfig but > > Intel chipsec is still reporting the captioned bits not set on my > > Coreboot-flashed X1 Carbon > > this option sets access permissions in the Flash Descriptor (IFD). They > act like the PR0-5 registers but on top of them. > > The default settings (only valid ones as by Intel for production > machines) will write-protect the IFD, read- and write-protect the > ME region. > > > 2. Is it correct to say that once the PR0-5 bits are set and Coreboot > > flashed into the machine, the values of the PR registers will be > configured > > accordingly after machine boot up (when OS is having control)? > > I'm not sure if I follow. Why do you call PR0-5 bits? those are > registers that may or may not be filled with a flash range to > protect. It is the host firmware's (coreboot's) responsibility > to write these registers. But what values are to be written is > up to you. > > Chipsec is a nice tool to check what things are configured and how. > But the user still has to know how these things work. Otherwise they > might make wrong assumptions about security. One good example is the > FLOCKDN (flash lockdown) bit. When it's set, one cannot change the > flash controller's configuration (including PR0-5 ranges) anymore > until the next reboot. But it doesn't tell you if the locked confi- > guration is secure, only that it can't be changed. > > > BIOSWE, BLE, SMM_BWP & PR0-5 protection bits > > BIOSWE, BLE, and SMM_BWP shift the blame from the OS to SMM (which is > supposed to be controlled by the firmware). However, to my knowledge, > nobody has yet achieved a secure SMM implementation. So many people > ignore this. And IMHO, any good security concept shouldn't treat SMM > more privileged than the OS. > > If you want to set these bits anyway, have a look at your south- > bridge's code (src/southbridge/intel/bd82x6x/lpc.c), around > pch_disable_smm_only_flashing(). This function clears SMM_BWP, > I guess. > > The PR0-5 ranges can protect your flash efficiently, AFAIK. Not even > SMM should be able to get around these. If you just want to write > protect your whole flash chip (you won't be able to flash internally > anymore), have a look at "Boot media protection mechanism" in the > "Security" config menu. If set to "Lock boot media using the con- > troller", it should use one of the PR0-5 ranges. > > FLOCKDN should be set when "Lock down chipset in coreboot" ("Chipset" > menu) is enabled. > > Hope that helps, > Nico >

1 0

Regarding Intel CPU frequency.
by nitin.ramesh.singh＠gmail.com 17 Jun '20

17 Jun '20

Hi, I am using coreboot to boot Denverton cpu (CPU C3558) based board. I can see that the cpu frequency is set to the correct value i.e. "2200 Mhz" under the coreboot logs. . " CPU #3 initialized bsp_do_flight_plan done after 146 msecs. cpu: frequency set to 2200 " Later when I check the frequency reading under linux (kernel version 4.19) , It comes out as 800 Mz: model name : Intel(R) Atom(TM) CPU C3558 @ 2.20GHz stepping : 1 microcode : 0x24 cpu MHz : 800.000 When I reprogram the board with BIOS, the cpu frequency gets reflected correctly (i.e. 2200 MHz) with the same kernel image. I have also tried out the different Grub command line options like disabling the pstate, and idle state e.t.c, but the end result remains same. Can anyone please provide me some suggestions. Is there is any cpu specific settings which needs to enabled under coreboot or with Intel-FSP ? Thanks, Nitin.

7 12

Intel EDK2 header files
by Jonathan Zhang (Infra) 16 Jun '20

16 Jun '20

Hi coreboot colleagues, Intel EDK2 header files are needed to build coreboot that depends on FSP. So far the practice is to keep such header files under src/vendorcode/intel/edk2 directory, and each EDK2 version takes a different directory (we have uefi_2.4, UDK2015, UDK2017). Since CPX-SP FSP is based on latest EDK2 code base, I would like to add EDK2 quarterly release (edk2-stable202005) header files to coreboot code base, and created [CB: 42239] accordingly. Idwer commented that an alternative is to keep EDK2 header files as a submodule, and this should be discussed in coreboot community. Thanks, Jonathan

2 1

I just tried to download from the repo a completely new tree it gave an error
by Gregg Levine 16 Jun '20

16 Jun '20

Hello! And now a new problem. (Think Monty Python!) Basically having installed a later distribution level, I attempted to download from the repo in an empty directory, a new tree. It created an error message instead. lroot@pike7:/usr/src/lobos# cd work4 root@pike7:/usr/src/lobos/work4# ls root@pike7:/usr/src/lobos/work4# git clone https://review.coreboot.org/coreboot.git Initialized empty Git repository in /usr/src/lobos/work4/coreboot/.git/ fatal: https://review.coreboot.org/coreboot.git/info/refs download error - The requested URL returned error: 406 root@pike7:/usr/src/lobos/work4# dumpgpio.tar.bz2 qemu-0.10.4/ filo-0.1/ qemu-0.10.4.tar.gz filo-0.1.tar sgabios/ filo-0.1.tar.bz2 sgabios.tar.bz2 freebios/ stb/ freebios-0.1.43cvs20000306.tar.gz stpc-bios-0.1.42.1.1.tgz freebios-20000602.tar.gz test.rom freebios-20001018.tar.gz test.rom.gz freebios-20001108.tar.gz testsystem/ freebios-20001123.tar.gz tmp/ freebios-20010321.tar.gz trunk/ freebios-20010708.tar.gz work/ freebios-30-June-2001.tar.gz work2/ geode-vsa/ work3/ gpl_vsa_lx_102.bin.gz work4/ gplvsa_ii/ root@pike7:/usr/src/lobos# cd work4 root@pike7:/usr/src/lobos/work4# ls root@pike7:/usr/src/lobos/work4# git clone https://review.coreboot.org/coreboot.git Initialized empty Git repository in /usr/src/lobos/work4/coreboot/.git/ fatal: https://review.coreboot.org/coreboot.git/info/refs download error - The requested URL returned error: 406 root@pike7:/usr/src/lobos/work4# clear root@pike7:/usr/src/lobos/work4# git --version git version 1.6.1.3 root@pike7:/usr/src/lobos/work4# And that's my Git version. Last time I had Slackware-12.2 up it did work. ----- Gregg C Levine gregg.drwho8(a)gmail.com "This signature fought the Time Wars, time and again."

2 3

Intel i3-10110u and i7-10710u
by andy.pont＠sdcsystems.com 16 Jun '20

16 Jun '20

Hello, I’m trying to make sense of the information on the Intel website, and the Coreboot source code, regarding the i3-10110u and i7-10710u processors. If I have interpreted things correctly, these are Comet Lake U devices and that the Comet Lake U DDR4 RVP reference board is supported as a variant within the Coffee Lake RVP. It appears that the low-power Comet Lake U LPDDR3 board isn’t supported. I can’t see anything in the sources that would confirm / deny whether those two specific processors are supported. Can anyone point me in the right direction? Thanks, Andy.

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot June 2020