coreboot October 2017

coreboot@coreboot.org

66 participants
140 discussions

ECC2017: organized dinner on Thursday?
by Goetz Salzmann 10 Oct '17

10 Oct '17

Dear list, looking at the ECC2017 Schedule there is an organized "Social Event" on Friday. For Sat./Sun. we will probably have pizza in the hackcenter. But after the great experience with organized dinners during the EuroBSDCon 2017, I would like to ask someone from Bochum to organize a dinner on Thursday, please. Thanks, Goetz.

1 0

Problems changing payload on Intel Leaf Hill
by Tahnia Lichtenstein 10 Oct '17

10 Oct '17

Hi, I am trying to build coreboot for the Intel Apollo Lake-I reference board (Oxbow Hill, similar to Leaf Hill). Intel has provided an implementation for this reference board based on an outdated coreboot version. Along with the coreboot implementation, they provided a compatible pre-compiled UEFI payload (with no source, but run-time boot menu looks like Tianocore's) and a compatible pre-compiled U-Boot payload (with links to U-Boot source on Github along with patch so as to reproduce the pre-compiled binary). The pre-compiled binaries have associated .config files for coreboot integration. When building coreboot with either of the precompiled binaries, and stitching the coreboot output binaries together with Intel-provided blobs (using Intel provided FIT application) to produce the final firmware image, the firmware works as expected. Then I built this version of coreboot with a self-compiled payload, such as Tianocore UDK2017 CorebootPayloadPkg or SeaBIOS, using the .confg files provided by Intel for UEFI payloads or legacy payloads respectively (just modified for specific payload type and path, and disabling verified and measured boot). I stitched the coreboot output with the Intel-provided blobs using the exact same method as before. Then, in run-time, coreboot transitions to the payload and nothing happens from then on (i.e. no further serial debug messages, no change to display monitor). I also built U-Boot from github, applying Intel's patch to match Intel's precompiled binary, and this self-compiled binary works in run-time (well, sort of, there are a couple of problems but point is the payload runs). A notable build difference is that this build uses the .config file provided by Intel as is, and that the payload that was built is the binary equivalent of the Intel pre-compiled binary. Am I not specifying the correct configuration options for Tianocore and SeaBIOS? I.e. is there more to it than just selecting the payload type and specifying the payload path? Do I need to configure or update memory addresses or ranges to match payload sizes, or some such? Do I need to make specific changes to the payloads' source code to support the platform? Any advice on how/where to start debugging? (Serial debug logs and .config files attached.) Best regards, Tahnia

1 0

Re: [coreboot] USB problem with Haswell+LynxPointLP motherboards
by Аладышев Константин 10 Oct '17

10 Oct '17

I've dumped original ACPI tables from original BIOS, but I can't see any such hooks. https://pastebin.com/Mniskv3f part1 of dsdt https://pastebin.com/hnpgvCMN part2 of dsdt (starts from EHCI/XHCI controllers) I hope it is not in SMM cause I really have no idea how to edit it to solve this problem -----Original Message----- From: jwerner(a)google.com [mailto:jwerner@google.com] On Behalf Of Julius Werner Sent: Tuesday, October 10, 2017 5:56 AM To: Аладышев Константин Cc: Coreboot Subject: Re: [coreboot] USB problem with Haswell+LynxPointLP motherboards > And now I'm kinda stuck. The effect of this commit doesn't seem to > interface with bios for me. So how does original IBASE/DFI bios can > overcome code error before this commit? > > What can be the source of my problem? What should I investigate more > precise based on result that I've got? My gut feeling would be to blame ACPI. The Linux patch is about caching a host controller register in the kernel, and in some cases (e.g. ehci_reset()), the patch re-reads the cached version from the hardware whereas the previous code didn't. If some BIOS ACPI mucks with that register, it's possible that this got the kernel's cached copy out of sync before this patch, but with the patch the kernel will re-read it from the hardware at the right time. Maybe only coreboot's ACPI routines touch the register in that path, or maybe the vendor BIOS' routines were more careful to restore the original state afterwards. Besides ACPI this could also be in SMM code, I guess (especially if the problem occurs around system suspend/resume, although it sounds like it doesn't for you).

1 0

Re: [coreboot] greetings and laptop questions
by Patrick Georgi 10 Oct '17

10 Oct '17

Hi Youness, 2017-10-10 1:54 GMT+02:00 Youness Alaoui <kakaroto(a)kakaroto.homelinux.net>: > it uses FSP, but you fail to mention that anything using coreboot will > use the FSP unless it's 10 year old hardware (Sandybridge is the > latest FSP-free supported CPU). While I understand your frustration, and agree with the general thrust of your email, and disregarding the "10 years", the Samsung Chromebook Plus (and many other devices of similar age) beg to differ. There are devices from 2016 and 2017 shipping with coreboot and no CPU level blobs in the firmware (the only CPU side blob would be the kernel's GPU driver). 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

1 0

USB problem with Haswell+LynxPointLP motherboards
by Аладышев Константин 09 Oct '17

09 Oct '17

I try to port coreboot on boards with Haswell CPU and Lynxpoint LP chipset (IBASE IB908AF-4650 board, DFI HU968) and I've encountered a strange problem. USB devices stop working shortly after OS boot (or after USB device replug in OS) with flooding system with messages: hub 1-1:1.0: cannot reset port 5 (err = -110) hub 1-1:1.0: cannot reset port 5 (err = -110) hub 1-1:1.0: Cannot enable port 5. Maybe the USB cable is bad? hub 1-1:1.0: cannot disable port 5 (err = -110) hub 1-1:1.0: connect-debounce failed, port 5 disabled hub 1-1:1.0: unable to enumerate USB device on port 5 hub 1-1:1.0: cannot disable port 5 (err = -110) hub 1-1:1.0: hub_port_status failed (err = -110) hub 1-1:1.0: hub_port_status failed (err = -110) Through some digging I've found out that this problem persist on kernels <3.5. I've investigated this problem more closely and come down to the fact that the kernel commit that solves this problem is: 3d9545c EHCI: maintain the ehci->command value properly https://github.com/torvalds/linux/commit/3d9545cc375d117554a9b35dfddadf9189c 62775?diff=split And now I'm kinda stuck. The effect of this commit doesn't seem to interface with bios for me. So how does original IBASE/DFI bios can overcome code error before this commit? What can be the source of my problem? What should I investigate more precise based on result that I've got?

5 5

Re: [coreboot] greetings and laptop questions
by Taiidan＠gmx.com 09 Oct '17

09 Oct '17

On 10/08/2017 11:06 AM, Jim Hendrick wrote: > Just subscribed - I will mostly "lurk" but I do have a few questions for > the group. > > I am looking at a new laptop, and one of my options is a Dell Precision > 7510 (I like the quad-core and loads of RAM available) but I would like to > not use a vendor BIOS. > > Has anyone put coreboot on one of these? Assuming there is no hardware code signing enforcement anti-feature ("boot guard") for the firmware enabled you would have to port coreboot to it, this would take around 6 months for a skilled firmware engineer. > Anyone tried and failed? > > Any recommendations for something similar (a good laptop ~15 in. quad-core, > 32GB RAM and fast SSD storage)? > I will be running multiple virtual machines - hence the RAM and cores... W530, supports open source hardware init coreboot and me cleaner. Buy one, install your own SSD, RAM upgrade and W520 keyboard/armrest if you don't like the chiclet layout. Alternatively you could get a G505S (owner controlled) if you don't want ME/PSP - but that only supports 16GB RAM. > (I also am looking at system76 and Purism but I am bit leery of spending a > lot with a small / new company - comments appreciated) Purism dishonestly markets their products - while they claim that their laptops "respect freedom and privacy" their version of coreboot is nothing more than a wrapper layer for intel FSP (binary blob that does all the hardware init) which is next to pointless for the amount of money you would spend on one as all it does is move trust from vendor to OEM not avoiding the hypothetical OEM firmware backdoors. System76 is a fine choice if all you want is a laptop that runs linux without difficulty.

4 5

OCP Winterfell, NERF, Linux and u-root (was: Ability to remotely debug the grub menu in case of boot failure)
by Paul Menzel 09 Oct '17

09 Oct '17

Dear Ron, Am Freitag, den 06.10.2017, 16:10 +0000 schrieb ron minnich: > 2 weeks ago I started an OCP winterfell node booting this way. This was > NERF with linux and u-root in flash. it was about 20 seconds for a full > cycle of linux in flash, dhclient, wget, kexec. I ran it 10,000 times, got > bored, turned it off. It works really, really well. Do you have more information about that system, and the setup? I’d be very much interested in that. Thanks, Paul

2 1

Re: [coreboot] greetings and laptop questions
by Zoran Stojsavljevic 08 Oct '17

08 Oct '17

> I am looking at a new laptop, and one of my options is a Dell Precision 7510 (I like the quad-core and loads of RAM available) > but I would like to not use a vendor BIOS. I see... SKL-S -> Intel® Core™ i7-6820HQ INTEL claims on these babies to have the following: https://www.kitguru.net/components/cpu/anton-shilov/intel-alters-design-of-… SGX: Intel Software Guard Extensions (Intel SGX <https://software.intel.com/en-us/blogs/2013/09/26/protecting-application-se…> ) What are the requirements? Why you do not want UEFI BIOS on the machine? Any specific reasons for that? I see only one serious reason: you don't want ME to work on this machine, since you do not trust to ME as the base of the unknown arc/x86 (quark ?) based applications running in its own 32MB space close to TOLUD. If you do have bare metal (type 1) HYP and run several VMs, does this assure the security and well protected VM space, regardless UEFI BIOS below? Anyone? Thank you, Zoran _______ On Sun, Oct 8, 2017 at 5:06 PM, Jim Hendrick <james.r.hendrick(a)gmail.com> wrote: > Just subscribed - I will mostly "lurk" but I do have a few questions for > the group. > > I am looking at a new laptop, and one of my options is a Dell Precision > 7510 (I like the quad-core and loads of RAM available) but I would like to > not use a vendor BIOS. > > Has anyone put coreboot on one of these? > > Anyone tried and failed? > > Any recommendations for something similar (a good laptop ~15 in. > quad-core, 32GB RAM and fast SSD storage)? > I will be running multiple virtual machines - hence the RAM and cores... > > (I also am looking at system76 and Purism but I am bit leery of spending a > lot with a small / new company - comments appreciated) > > Thanks all! > > Jim > > > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot >

1 0

greetings and laptop questions
by Jim Hendrick 08 Oct '17

08 Oct '17

Just subscribed - I will mostly "lurk" but I do have a few questions for the group. I am looking at a new laptop, and one of my options is a Dell Precision 7510 (I like the quad-core and loads of RAM available) but I would like to not use a vendor BIOS. Has anyone put coreboot on one of these? Anyone tried and failed? Any recommendations for something similar (a good laptop ~15 in. quad-core, 32GB RAM and fast SSD storage)? I will be running multiple virtual machines - hence the RAM and cores... (I also am looking at system76 and Purism but I am bit leery of spending a lot with a small / new company - comments appreciated) Thanks all! Jim

1 0

Re: [coreboot] SMM save area in MSRs on newer intel CPUs
by Aaron Durbin 07 Oct '17

07 Oct '17

haswell and on has this. You can see it in the haswell code. We actually opted not to use it but for relocation so we could look at each cpu's save state from a single cpu to see who caused the smi, etc. On Sat, Oct 7, 2017 at 8:38 AM, ron minnich <rminnich(a)gmail.com> wrote: > can someone point me at the documents that describe how this works? > > thanks > > ron > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot

1 0

← Newer
1
...
6
7
8
9
10
11
12
13
14
Older →

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 October 2017