[coreboot] Re: Intel EDK2 header files
@Subrata Banik must have done so on other Intel project. In the near future, I think highly possible that CPX FSP will stick with edk2-stable202005 for quite some time. Jonathan Zhang (Infra) via coreboot 于2020年6月17日周三 上午3:15写道: > 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 > > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Supporting blobs with licenses that you agree to on download
> Here is what I suggested somewhere on Gerrit [1]: > > I was thinking we could move the current `3rdparty/blobs` > to something like `3rdparty/limited_blobs` or `3rdparty/ > restrictive_blobs`. And guard it like the `amd_blobs`. > Then move anything without doubts about redistribution > to a new `3rdparty/blobs`. > > I guess this would be a good first step. If we want to further separate > the restrictive blobs by their licenses, we can still do that later. > However, if it turns out that there is close to nothing to move to the > new repository, we could as well just keep the current one and disable > its automatic download (and announce that people should stop mirroring > it). Okay, sounds like we have general agreement on the second repository approach? I don't think we'd want to disable automatic downloading for the primary blobs repository because I think many people value that for convenience. I agree that we can start with a single restricted_blobs repo for now and see if there is a need to split it up further later. Patrick, any further concerns from your side? If not, would you mind creating a new repository for this? I can write the patches to move blobs and adjust the Makefiles afterwards. > That would have been me on Gerrit. I'm not 100% sure where distribution > ends and redistribution starts. But some of the AMD licenses in the old > blobs repository are either absolutely limited in redistribution or not > redistributable at all (by any meaningful definition of the term). They > explicitly limit distribution to be used with the distributors products > "that incorporate AMD products". That thing is written for ODMs/OEMs but > no-one else. And said distribution would not happen under the terms of > the same license but an EULA embedded into it. Yeah, upon reading the AMD license a bit more closely I agree the redistribution parts look a bit concerning to me as well. I don't know exactly what we'd want to do with that, but let's please keep that discussion separate from the one about other blobs that only have the "must agree to license when downloading" problem (I am mostly just trying to find a way to get my Qualcomm board supported right now). The amd_blobs already have a separate repo, so I guess someone should clean up the affected stuff from the main blobs repo for now and then we can decide what to do with the amd_blobs repo (maybe we put a big warning on it not to clone and rehost this publicly or something). ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Intel EDK2 header files
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 ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Regarding Intel CPU frequency.
Hi Sumo, Thanks for your reply. As mentioned in my previous mail,. There are two different fixes which are required for c3558. a.) The SPEED STEP needs to enabled separately. b.) APIC id has to be changed under the device tree. Thanks, Nitin. ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Regarding Intel CPU frequency.
Hi, Looks like for this SoC turbo state is not available, so try the following (enable speedstep regardless if turbo state is available or not, as you need speedstep!) : --- a/src/soc/intel/denverton_ns/cpu.c +++ b/src/soc/intel/denverton_ns/cpu.c @@ -71,11 +71,11 @@ static void denverton_core_init(struct device *cpu) enable_turbo(); /* Enable speed step. */ - if (get_turbo_state() == TURBO_ENABLED) { +// if (get_turbo_state() == TURBO_ENABLED) { msr = rdmsr(IA32_MISC_ENABLE); msr.lo |= SPEED_STEP_ENABLE_BIT; wrmsr(IA32_MISC_ENABLE, msr); - } +// } } King regards, Sumo ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: I just tried to download from the repo a completely new tree it gave an error
Hello! Okay Patrick your advice and my decision to upgrade the system worked. I was able to completely download a new one from the repo. - Gregg C Levine gregg.drw...@gmail.com "This signature fought the Time Wars, time and again." On Mon, Jun 15, 2020 at 7:31 PM Gregg Levine wrote: > > Hello! > Understood Patrick. As it happens I am in the process of doing that. > That system is in fact the one where I first discovered the original > LinuxBIOS project. Now? I've got it waiting on me to do just what > you're suggesting. Oh and you can ignore the one which suggests a > comedy situation response to the problem. > - > Gregg C Levine gregg.drw...@gmail.com > "This signature fought the Time Wars, time and again." > > On Mon, Jun 15, 2020 at 4:59 PM Patrick Georgi wrote: > > > > Am Mo., 15. Juni 2020 um 22:27 Uhr schrieb Gregg Levine > > : > >> > >> 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. > > > > That git version is from 2009. The world didn't stop turning. > > It's surprising enough that your system has support for sufficiently new > > SSL that it could receive that HTTP error instead of already failing at the > > SSL handshake. > > > > tl;dr: update your system. > > > > > > Patrick > > -- > > Google Germany GmbH, ABC-Str. 19, 20354 Hamburg > > Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: > > Hamburg > > Geschäftsführer: Paul Manicle, Halimah DeLaine Prado ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Extended IvyBridge CPU configuration
Sorry for the long silence - I finally found some time to test the HT patch. I used coreboot v4.11 as a basis since at this point in time the patch produced merge conflicts with newer commits. I used memtest86+ v5.01 (forced SMP, RAM: 16GB @ 1600MHz, CPU: Intel i7-3840QM) as mentioned in my last mail. When HT is enabled memtest86+ runs just fine. When I disable HT it gets reproducibly stuck at test #7 (block move), at 4096M-6144M, with cores 0-2 working, core 3 just switched to "W". I'll test some other workloads which were problematic in the past (compiling coreboot, watching videos using Firefox). Shall I provide my .config or any other information? Regards lhochstetter On 11/02/2020 15:23, Lars Hochstetter wrote: I managed to find some time to run memtest86+ v5.01 as a SeaBIOS payload [1]. As it turns out the RAM went bad - I made sure to check with another pair of sticks. I'll replace the RAM and retry the HT patch when my free time allows for it. Sorry for creating so much noise over something so simple. Regards lhochstetter [1] https://mail.coreboot.org/pipermail/coreboot/2018-November/087713.html On 2/8/20 4:23 PM, Lars Hochstetter wrote: Unfortunately I'll be rather busy until mid April this year - here is my plan for the time being: I'll reinstall Linux Mint Cinnamon, integrate memtest86+ into coreboot and run it. I'll report back if it's just bad RAM or something else. Since my T430 was modified a couple times I'd also suggest we try to find someone with a more stock T430 to see if your HT patch works. The X230 somewhere in this thread worked and I'd argue that it does work properly on unmodified Thinkpads. Sorry for a long reply too. About mrc.bin: no, it's actually possible to use mrc blob on Sandy/Ivy, but as I see it's not supported across all boards. X220 has support, other boards needs patching (or maybe patches are already on gerrit, I'm not sure). It shouldn't be hard to get it working, though. Can you elaborate on this one? Why does the X220 has support and other Sandy/IvyBridge based laptops are not supported? Wasn't one of the ideas for coreboot to have a more common code base or am I missing something obvious? Regards lhochstetter ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Lenovo R500
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.___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Intel i3-10110u and i7-10710u
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. ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org