[coreboot] Re: Intel EDK2 header files

2020-06-16 Thread Lance Zhao
@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

2020-06-16 Thread Julius Werner
> 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

2020-06-16 Thread Jonathan Zhang (Infra) via coreboot
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.

2020-06-16 Thread nitin . ramesh . singh
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.

2020-06-16 Thread Sumo
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

2020-06-16 Thread Gregg Levine
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

2020-06-16 Thread Lars Hochstetter
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

2020-06-16 Thread trabajo3 via coreboot
Hello!, I wantt to know if the Lenovo R500 has coreboot support without any 
blobs
https://phoronix.com/scan.php?page=news_item=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

2020-06-16 Thread andy . pont
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