coreboot October 2017

coreboot@coreboot.org

66 participants
140 discussions

Re: [coreboot] Problems changing payload on Intel Leaf Hill
by Melissa Yi 11 Oct '17

11 Oct '17

Hi Tahnia, Have you tried 32-bit UEFI payload? I met this problem in Denverton platfrom too with 64-bitUEFI payload. Thanks. Regards, Melissa Yi BIOS Lead Engineer Celestica(Shanghai) R&D Center, China www.celestica.com Solid Partners, Flexible Solutions 2017-10-10 16:29 GMT+08:00 Tahnia Lichtenstein <unlich(a)gmail.com>: > 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 > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot >

1 0

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

11 Oct '17

The lenovo G505S is the latest owner controlled coreboot x86-64 laptop, running the FT3 platform which is 4 years old. It supports VMX, RVI and IOMMU. While it does have a blob for video and power both of those have no hardware code signing features (thus replaceable), and unlike ivy bridge it doesn't have a black box supervisor processor. Had the folks from purism asked me what they should do, I would have suggested FT3. On 10/09/2017 07:54 PM, Youness Alaoui wrote: > I don't get why you constantly try to discredit Purism and insult > everything we do. You complain about coreboot being "useless" because > 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). The original email asked about a > coreboot port, not a libreboot port. Every time I see purism > mentioned, you have to jump in to insult and dishonestly say that > Purism is dishonest. If you want to claim bullshit like that, at least > find something real and concrete to back it up. I've ignored you many > times, but I'm fed up of your one-man vendetta against Purism. What > happened to you for you to have so much hate against us? In the efforts of not getting moderated again we can continue this off list but it boils down to the dishonest crowdfunding style "some day we will do X" marketing. I would have recommended your devices at least once if you were selling them as they were instead of as they could be. I dislike: * Aspirational marketing "LibreM" "every chip hand selected to respect your privacy" "continued efforts to remove ME" that confuses even linux veterans and detracts from competitors products. * The lobbying for the FSF to decrease the RYF standards * (although most companies do this) Not asking the target audience for advice on what to do next. I wouldn't have said anything but on the other lists I visit for every person like me there are 5 others who constantly talk up your products. I believe everyone needs critical voices. On 10/09/2017 08:42 PM, Nico Huber wrote: > On 09.10.2017 00:15, Taiidan(a)gmx.com wrote: >> 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. > I've seen that mentioned a lot and can only say: Please stop spreading > that FUD about coreboot. Even with blobed silicon init, coreboot still > gives you about 80% of the freedom of a free firmware. You only have > to trust in one party that provides the blob and not in n parties that > put their code into the usual Windows booting firmware. coreboot, even > blobed, also gives you much more freedom about the platform configu- > ration and the boot process as a whole. > > Don't get me wrong, I don't like FSP either (from a developer point of > view, it makes coreboot porting twice as hard and 10 times more frus- > trating if something doesn't work right away). You can stomp on it as > you wish. But please don't disgrace coreboot. Can you suggest a better way of saying it? People with EE/CS degrees (non-laymen I suppose) I have conversed with over the years still consider "coreboot" to mean what it did circa 2011 where the only real difference between coreboot and libre* was philosophical not technical, when someone says "our devices have coreboot" they believe that it is entirely "free firmware". While an FSP coreboot "port" is still technically superior to an entirely closed source firmware no one I have talked to would consider spending an extra 1K per device just to cut the vendor out of the trust picture (they and I desire silicon init) I propose a kind of freedom-level badge certification system (like "Intel Inside" stickers) for this situation with everything clearly explained on a central website to solve this situation, similar to the one currently on the coreboot wiki.

2 1

Re: [coreboot] greetings and laptop questions
by Rene Shuster 10 Oct '17

10 Oct '17

I actually appreciated your super-long post, as it provided me insight in the development process that I wasn't aware prior and it changed my view on Puri.sm from 'they have been debunked' to 'I want to support their efforts'. Keep up the good work. On Tue, Oct 10, 2017 at 2:02 PM, Youness Alaoui < kakaroto(a)kakaroto.homelinux.net> wrote: > > 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). > > Sorry, I'm so deep into Intel stuff right now that I completely missed > the possibility of non-x86 hardware. Yes, there is newer hardware with > no blobs in coreboot, my statement is only true for intel-related > hardware. I don't even know about AMD actually, but I believe it's a > similar situation for AMD. But in the case of the Chromebook Plus, I > checked, and it's an ARM based CPU, which is why coreboot is blob free > for it. > The original post was about a laptop to run virtual machines, so I > assume x86 is a requirement, but my statement was about coreboot > itself, not about the laptop requirement, which made it false. Thanks > for the correction! > > > > > > > Please keep the dimension right, newest is Ivy Bridge and that is 5 > > years old. > > My bad, you're right. The '10 years old' was in reference to ME-less > CPU designs and I confused it with FSP-less coreboot. > As for the ivybridge being the newest, that's again my bad, I used > this to look up when the native intel raminit stopped being supported > ; > https://www.coreboot.org/Intel_Native_Raminit#Sandybridge.2FIvybridge > and it said sandybridge/ivybridge, and I thought they were the same, > not one being successor of the other. > > I guess that will teach me to email while I'm tired and busy/distracted. > > > > > > >> The original email asked about a > >> coreboot port, not a libreboot port. Every time I see purism > >> mentioned, you have to jump in to insult and dishonestly say that > >> Purism is dishonest. If you want to claim bullshit like that, at least > >> find something real and concrete to back it up. I've ignored you many > >> times, but I'm fed up of your one-man vendetta against Purism. What > >> happened to you for you to have so much hate against us? > > > > It's not him alone, you might remember our discussion about it (it > > ended with you writing poems that I didn't even had the time to read > > in the end, please don't do that again). > > You're not hateful from what I could see. You disagree with Purism and > you don't like it, but I haven't seen you jumping at every occasion to > talk bad about it. > As for our last discussion, that's what it was, a discussion, which > unfortunately, I got a little over-verbose in my last response and > killed the discussion, but I don't feel like Taiidan wants to discuss > anything. Either way, I don't plan on opening any new discussions > about Purism here. > > > > >> > >> Extremely funny how you then say that System76 is "a fine choice" > >> considering that System76 doesn't even come with coreboot, and even if > >> it did come with coreboot, it would of course, still depend on the > >> FSP. Also, System76 hardware depends on components which do require > >> binary blobs, as opposed to Purism laptops, so I don't get why > >> System76 is "a fine choice" if Purism isn't. > > > > It's pretty simple, System76 seems to advertise what say sell, Purism > > doesn't. I'd say they do most things right, but not the advertisement. > > Most Linux supporting vendors are honest about their products. Yet, > > Purism makes claims such as: > > > > "Only by selecting each and every chip in our Librem laptops can > > we guarantee your privacy, security and freedom are protected." > > > > Where I still argue, it's the opposite with Intel inside. > > > > Everything else, they seem to do alright. I'd fully support them if > > they'd stop the false advertisement of being super secure. They are > > not, just a little better than the rest (by hardware design, don't > > know about the details of their software and how secure the hard- > > ware is configured). > > > > So my conclusion, Purism draws customers from other Linux supporting > > vendors with dishonest marketing. If that doesn't bother you, fine. > > But please don't get angry if it bothers honest people. > > I disagree with your statement that it's false advertisement and that > it's dishonest marketing. I won't explain why I think you're wrong > here, because : > 1 - I already explained it in length in my previous long email that > you never read > 2 - It doesn't market itself as "being super secure" as you said, but > rather as being "security and privacy focused", which it is. You are > free to find anywhere on the website where it says security or privacy > without stating "a focus on" or "<attribute>-focused" along with it. > 2 - It's my opinion/interpretation and you have a different one, and > that's fine, you are entitled to it. Your view/interpretation of a > statement does not mean everyone needs to see it your way and that the > conclusion that it's being dishonest which your drew from it, is going > to be the absolute truth. > 3 - By stating that it "bothers honest people", right after saying > that it doesn't bother me, you're implying that I'm not an honest > person (at least that's how I read it) and that kind of statement > doesn't lead to cool headed discussions, so I'll simply withdraw from > this one. > > ... > Yeay, looks like I managed to not write another long email. > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot > -- Tech III * AppControl * Endpoint Protection * Server Maintenance Buncombe County Schools Technology Department Network Group ComicSans Awareness Campaign <http://comicsanscriminal.com>

1 0

Re: [coreboot] greetings and laptop questions
by Nico Huber 10 Oct '17

10 Oct '17

On 10.10.2017 01:54, Youness Alaoui wrote: > On Sun, Oct 8, 2017 at 6:15 PM, Taiidan(a)gmx.com <Taiidan(a)gmx.com> wrote: >> >>> >>> (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. >> > > I don't get why you constantly try to discredit Purism and insult > everything we do. You complain about coreboot being "useless" because > 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). Please keep the dimension right, newest is Ivy Bridge and that is 5 years old. > The original email asked about a > coreboot port, not a libreboot port. Every time I see purism > mentioned, you have to jump in to insult and dishonestly say that > Purism is dishonest. If you want to claim bullshit like that, at least > find something real and concrete to back it up. I've ignored you many > times, but I'm fed up of your one-man vendetta against Purism. What > happened to you for you to have so much hate against us? It's not him alone, you might remember our discussion about it (it ended with you writing poems that I didn't even had the time to read in the end, please don't do that again). > > Extremely funny how you then say that System76 is "a fine choice" > considering that System76 doesn't even come with coreboot, and even if > it did come with coreboot, it would of course, still depend on the > FSP. Also, System76 hardware depends on components which do require > binary blobs, as opposed to Purism laptops, so I don't get why > System76 is "a fine choice" if Purism isn't. It's pretty simple, System76 seems to advertise what say sell, Purism doesn't. I'd say they do most things right, but not the advertisement. Most Linux supporting vendors are honest about their products. Yet, Purism makes claims such as: "Only by selecting each and every chip in our Librem laptops can we guarantee your privacy, security and freedom are protected." Where I still argue, it's the opposite with Intel inside. Everything else, they seem to do alright. I'd fully support them if they'd stop the false advertisement of being super secure. They are not, just a little better than the rest (by hardware design, don't know about the details of their software and how secure the hard- ware is configured). So my conclusion, Purism draws customers from other Linux supporting vendors with dishonest marketing. If that doesn't bother you, fine. But please don't get angry if it bothers honest people. Nico

2 1

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

10 Oct '17

Hello Zoran! Yes, I'm working with the same board, but the problem is different. Last time I was solving a problem of OS suspend-resume sequence with modern kernels and now it is about working with old kernels From: Zoran Stojsavljevic [mailto:zoran.stojsavljevic@gmail.com] Sent: Tuesday, October 10, 2017 9:48 AM To: Аладышев Константин Cc: coreboot Subject: Re: [coreboot] USB problem with Haswell+LynxPointLP motherboards Hello Kostja, We already had this discussion a while ago, didn't we? https://mail.coreboot.org/pipermail/coreboot/2016-December/082772.html (BTW, ATOM BYT has exactly the same problem) Zoran On Mon, Oct 9, 2017 at 11:58 AM, Аладышев Константин <aladyshev(a)nicevt.ru> wrote: 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? -- coreboot mailing list: coreboot(a)coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot

2 1

Re: [coreboot] USB problem with Haswell+LynxPointLP motherboards
by Trammell Hudson 10 Oct '17

10 Oct '17

On Mon, Oct 09, 2017 at 07:55:34PM -0700, Julius Werner wrote: > 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. Even with reversing the patch (modifying the ehci code to always read from the command register), my Haswell board still won't enumerate the USB devices. I'm going to try the hack to disable xhci, as suggested by Zoran and Аладышев's earlier email. Likely unrelated, I'm also having a problem enabling ACPI from the Linux kernel, although most everything else seems to work with interrupts and PCIe, so for the time being I have a hack in acpi_enable to pretend things worked. [ 0.017031] ACPI: Core revision 20160831 [ 0.264132] ACPI: 4 ACPI AML tables successfully acquired and loaded [ 0.271241] ACPI: setting ELCR to 0200 (from 0a00) [ 0.376881] ACPI Error: Hardware did not enter ACPI mode (20160831/evxfevnt-113) [ 0.385158] acpi_enable:114 faking ACPI mode https://github.com/osresearch/heads/issues/260 https://github.com/osresearch/heads/issues/248 -- Trammell

3 2

Re: [coreboot] OCP Winterfell, NERF, Linux and u-root (was: Ability to remotely debug the grub menu in case of boot failure)
by ron minnich 10 Oct '17

10 Oct '17

Here's a bit more info. NERF is the project I mentioned at the coreboot meeting a few months back. This is my linuxcon talk a few weeks back. https://docs.google.com/presentation/d/1rz6ATJ6PNf_iJeDlqJvLqYZmyuJIN5SMli8… HOWTO on the winterfell node, incomplete: https://docs.google.com/document/d/1jtJ267pGxqWwEopNJsXzR1jOaOPAhulX_PaidKz… repos for current state of life: https://github.com/nerfirmware Trammell's work is really interesting: https://github.com/osresearch /heads/tree/nerf ron

1 0

Re: [coreboot] USB problem with Haswell+LynxPointLP motherboards
by Trammell Hudson 10 Oct '17

10 Oct '17

On Tue, Oct 10, 2017 at 02:44:02PM +0000, ron minnich wrote: > [ 0.376881] ACPI Error: Hardware did not enter ACPI mode > (20160831/evxfevnt-113) > > is this the step where it tries to do an outb to 0xb2 to tell smm we are > taking over? Yes, it looks like it is attempting to write to 0xB2: acpi_hw_write_port(acpi_gbl_FADT.smi_command, (u32) acpi_gbl_FADT.acpi_enable, 8); Which is in the FACP table: [030h 0048 4] SMI Command Port : 000000B2 Since there in no SMM right now, it looks like Linux would be happy if that value were zero: /* * ACPI 2.0 clarified that if SMI_CMD in FADT is zero, * system does not support mode transition. */ if (!acpi_gbl_FADT.smi_command) { return_UINT32(ACPI_SYS_MODE_ACPI); } (this is getting a little further afield from the Haswell USB problems...) -- Trammell

1 0

Re: [coreboot] ECC2017: organized dinner on Thursday?
by Zaolin 10 Oct '17

10 Oct '17

Hey, I have already organized the Dinner for Thursday and Friday. ;) Best Regards, Philipp On 10.10.2017 10:46, Goetz Salzmann wrote: > 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

Re: [coreboot] how to implement variable read/write variable in coreboot
by Nico Huber 10 Oct '17

10 Oct '17

Hi Melissa, On 28.09.2017 07:59, Melissa Yi wrote: > Hi All, > Does anyone know how to implement variable read/write in coreboot? > like: how to create a block nvram to be accessed by uefipayload? I don't know any quick solution. Though, here are my thoughts on the matter: AFAIK, coreboot currently doesn't have any specified format for in-flash, mutable configuration variables. Tianocore (or UEFI in general) might already have a format for that, but I would rather introduce something more native to coreboot that can easily be used in coreboot and all its payloads. I'll try to describe my ideas for a complete solution (and where we already have parts implement and where not) in some layers from bot- tom up: Flash-chip access ================= You need read/write access to the firmware flash chip. It's save to assume that coreboot at least knows how to read from its flash. And I would argue that writing variables from coreboot itself can be considered optional (or should even be discouraged). Though, when it comes to payloads, flash support is scarce. One option, and my preferred, is to use libflashrom that can currently be compiled and linked with libpayload. I guess it's not feasible to link the latter together with Tianocore (which seems to have its own implementation of the C library), so porting libflashrom to Tianocore is probably the way to go. (One alternative would be to only integrate drivers for the specific chipsets / chips one needs. But I can only advice against it. We should focus on one sophisticated code base for the matter and that is flashrom.) Flash-chip partitioning ======================= coreboot uses its native FMAP to describe the layout of the flash chip. libpayload has some code for it. Should be easy to find a place and add a new entry for variables. In-flash variable format ======================== I like to keep things simple and assume that a key=value approach suffices (for this layer). Though, as we have certainly to deal with NOR flash chips (and their erase blocks), we can't just store things in a table that would require an erase cycle for every change of a variable. Here is a random proposal: VARIABLE MAGIC (4 bytes, for sanity checks) COMPLETE LENGTH (4 bytes, length in bytes of this entry) KEY LENGTH (4 bytes, length of the key name, if 0 or 0xffffffff, entry is invalidated) KEY NAME (KEY LENGTH bytes) VALUE (COMPLETE LENGTH - KEY_LENGTH - 12 bytes) Read strategy: Either cache and index the whole thing, or read until the first valid entry with matching key. Write strategy: Invalidate any entry with matching key, append after last entry if there is enough space in the current erase block. If not, finalize current erase block with an invalid entry spanning the free space of the block, write variable into next erase block. If we run out of erase blocks, defragment the whole thing (needs one com- plete erase block size to cache things, afaics)? Application layer ================= Up to the use case. Could be anything from simple flags over UEFI runtime variables to full programs (e.g. tint easter-egg), I sup- pose. Hope there is anything helpful in this mail, Nico

4 10

← Newer
1
...
5
6
7
8
9
10
11
...
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