coreboot May 2018

coreboot@coreboot.org

51 participants
137 discussions

AMD IMC open source firmware replacement
by Mike Banon 25 May '18

25 May '18

Good day Rudolf, This page [1] tells that you have developed a open source firmware replacement of AMD IMC firmware and it is available under request. Please tell, did it made to a coreboot? If not, 1) why? (stability problems, or something else) 2) is the source code available somewhere publicly? I have Lenovo G505S coreboot-supported laptop with AMD Richland 15h CPU (A10-5750M) and it is probably using this IMC blob - thats why I am curious [1] - https://www.coreboot.org/AMD_IMC Best regards, Mike Banon

1 0

Asus Vivobook 14 E406SA 1.0 - Intel ME
by permanentjpeg＠firemail.cc 25 May '18

25 May '18

Hi, I recently acquired an Asus Vivobook E406SA 1.0, which I have been investigating to see if there is a possibility to port to coreboot. While doing this, I seem to have found some weird information about Intel ME on this laptop. Although the CPU was produced in 2016 and it can be assumed that it includes Intel ME, all the tests I've done come up with the conclusion that it doesn't. I've included some detailed logs in an attachment 'me.txt'. Going forward, what can I do to verify if this laptop does have Intel ME or not? Flashrom doesn't support laptops well and I don't have the ability to risk bricking this laptop currently, is there another option to read the flash chip in this? - permanentjpeg

3 3

Re: [coreboot] Who is still using a 1980's tty for coreboot development?
by Goetz Salzmann 25 May '18

25 May '18

On Fri, May 25 '18 at 10:15, Patrick Georgi via coreboot wrote: > That is, who would unbearably suffer from 132 characters per line of code? See https://mobile.twitter.com/changelog/status/999652792707858433 Sorry, could not resist. But more seriously, I still prefer 80 chars per line, but have no problems with longer lines. Oh the other hand I do so little coreboot development, that you should not base any decision on my humble opinion. Cu, Goetz.

2 1

Who is still using a 1980's tty for coreboot development?
by Patrick Georgi 25 May '18

25 May '18

That is, who would unbearably suffer from 132 characters per line of code? 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

Re: [coreboot] When does AMD release the fam15 spectre microcode updates?
by Andrew Luke Nesbit 23 May '18

23 May '18

On 23/05/2018 20:55, ron minnich wrote: > > > On Wed, May 23, 2018 at 12:54 PM Rudolf Marek <r.marek(a)assembler.cz > <mailto:r.marek@assembler.cz>> wrote: > > Hi all, > > Dne 22.5.2018 v 07:03 Taiidan(a)gmx.com <mailto:Taiidan@gmx.com> > napsal(a): > > > > don't they have those in this update? Would it be possible to > easily add > > the support flags without microcode for those who use libreboot? > > So libreboot guys don't want any fixes for a CPU? > > > I've been wondering about this. IIRC the original motivation for the > libreboot fork was microcode. > Is microcode still out of bounds for libreboot? I don't know if the original motivation still applies. This is an important discussion to have. I've pinged the folks in #libreboot and #vikings on Freenode to alert them to this discussion. There are probably other relevant channels I've missed. Hopefully somebody with a wider and deeper understanding of the issue than I have is reading this list. Hopefully they will chime in and provide a more authoritative answer. If not I will keep pestering them because I don't want to see this unresolved, but I would like to help out however I can and learn whatever is needed to make a positive contribution. Andrew -- OpenPGP key: EB28 0338 28B7 19DA DAB0 B193 D21D 996E 883B E5B9

1 0

Re: [coreboot] FSP 2.0 headers in coreboot
by Aaron Durbin 22 May '18

22 May '18

On Tue, May 22, 2018 at 2:25 PM, Youness Alaoui <kakaroto(a)kakaroto.homelinux.net> wrote: > On Fri, May 18, 2018 at 2:59 PM, Nico Huber <nico.h(a)gmx.de> wrote: >> >> I have to admit, I don't like your patch. While it gets the job done, >> it brings `MemInfoHob.h` and `FspsUpd.h` out of sync, so the state in >> coreboot as a whole would match neither version. >> > Good point. It is a Frankenstein, but it was either that or have > #ifdefs in the fsp vendorcode itself to determine if attribute X is > available or not, etc.. > >>> - or abandon my patch (which means I can never send a working >>> board-status for the librems without having a dirty tree or a version >>> commit hash that doesn't match upstream) >>> - or have the possibility to choose between the two (either via >>> #ifdefs or via a variants method). >> >> If we can't get a new, fitting binary out of Intel, I would prefer this, >> or, more bluntly, just copy the GitHub version and revert the changes >> that need the additional UPD. >> >> In other words, whatever happens, I think we should have the headers >> of the latest public release in the tree. >> > > I agree, that's probably the cleanest solution, but I didn't suggest > it because I figured people would be yelling about removing > functionality that might need to be re-added eventually if Intel end > up doing an updated release. > >>> - or, if Intel people are reading this right now (or someone here can >>> poke them directly), have the public release updated so this matter >>> can be dropped entirely (the public update would need to be released >>> *very* soon though). >> >> Even if you (Purism) poke them about it, that might help. But I would >> like to see that Google does that too (IMHO, they profit most from the >> mess). Any of you should have more leverage than the customer of a >> customer of a customer of a potential customer of Intel has, that I >> work for ;) > I know no-one at Intel to poke them about. I'll ask if Todd has > contacts that might be able to help. I'm hoping that some of the > people that are working for Intel are following this email thread but > if they are, they haven't raised their hands. Anyone knows or can > suggest the name of someone that we might poke ? I'm guessing those > working for Google who actually received the newer FSP from Intel > might know who to ask, and since they are the ones that would be > affected by their code/features being removed if we revert to github > version of header, it might help put some pressure on this issue (so > far, I haven't seen any incentive to make them do that). I thought I said something somewhere -- maybe on a code review? Anyway, I've been pushing on this from my end. I don't have an answer yet, though. > >> >>> Should we put this to a vote now, or should we discuss the >>> possibilities/alternatives some more, if anyone has ideas on how to >>> tackle this specific issue ? >> >> Well, my vote, in order of preference: >> >> 1. Poke Intel. >> 2. Get a verbatim copy of the GitHub headers in (in a way of [least] effort for >> the community). Maybe in a month from now? no matter the outcome >> from 1. >> >> Nico > > I agree, and I give my 100% vote for that as well. It will be much > better than an #ifdef mess and would be a good incentive for the > people from Intel not saying "no, too much hassle to update the file, > we got nothing to lose anyway if we just ignore this". > So let's see who can poke who from Intel, let's give a deadline (1 or > 2 months? if bureaucracy means it will take longer, we might revisit > if we at least got a confirmation that the issue is being looked at on > Intel's side), then once deadline is reached, we revert to public > headers and remove functionality that prevents building (access to > nonexistent fields in UPD) and in the future, reject patches on gerrit > for non public blobs. > > Thanks!

1 0

Re: [coreboot] FSP 2.0 headers in coreboot
by Nico Huber 22 May '18

22 May '18

On 11.05.2018 21:18, Youness Alaoui wrote: > I feel like this discussion is getting slightly out of hand, so let's > try to regroup a bit and move the discussion back to the original > topic : how to handle the FSP headers in coreboot. > I fully understand and agree with Nico's frustration about the blobs > situation and I think that's a bigger conversation than needed right > now. I do encourage discussing it and finding a good solution to avoid > having a similar mess in the future (or now, but in a different thread > to avoid going off-topic). I think Nico's idea of setting up rules for > how/what to merge in the future is a good idea and needs to be further > discussed until everyone is happy with the rules defined. Yep, sorry. I'll try again in another thread, I guess. > > Now, back to the discussion about the "incompatible FSP headers", here > are the possibilities : > - should we merge my patch that makes the FSP header compatible with > the public blob, and let the CrOs coreboot clone have its own commit > that reverts it, I have to admit, I don't like your patch. While it gets the job done, it brings `MemInfoHob.h` and `FspsUpd.h` out of sync, so the state in coreboot as a whole would match neither version. > - or abandon my patch (which means I can never send a working > board-status for the librems without having a dirty tree or a version > commit hash that doesn't match upstream) > - or have the possibility to choose between the two (either via > #ifdefs or via a variants method). If we can't get a new, fitting binary out of Intel, I would prefer this, or, more bluntly, just copy the GitHub version and revert the changes that need the additional UPD. In other words, whatever happens, I think we should have the headers of the latest public release in the tree. > - or, if Intel people are reading this right now (or someone here can > poke them directly), have the public release updated so this matter > can be dropped entirely (the public update would need to be released > *very* soon though). Even if you (Purism) poke them about it, that might help. But I would like to see that Google does that too (IMHO, they profit most from the mess). Any of you should have more leverage than the customer of a customer of a customer of a potential customer of Intel has, that I work for ;) > Should we put this to a vote now, or should we discuss the > possibilities/alternatives some more, if anyone has ideas on how to > tackle this specific issue ? Well, my vote, in order of preference: 1. Poke Intel. 2. Get a verbatim copy of the GitHub headers in (in a way of effort for the community). Maybe in a month from now? no matter the outcome from 1. Nico

2 2

Re: [coreboot] Building coreboot for Apollo Lake: missing 'IFWI' region
by Nico Huber 22 May '18

22 May '18

Hi, On 19.05.2018 02:27, Julius Werner wrote: > Apollolake looks quite different, and I don't really know all the details, > but somehow the reset vector is interwoven with that IFWI thing near the > front of the ROM. You can see an example Chrome OS Apollolake FMAP in > src/mainboard/google/reef/chromeos.fmd, and compare it to a normal Chrome > OS x86 FMAP like src/mainboard/google/glados/chromeos.fmd . The Apollolake > support was added by Chrome OS folks, so maybe they didn't bother adapting > the default-x86.fmd mechanism to work with it because all the Chrome OS > boards have their own FMAP anyway. You may be able to get further in your > build if you copy the reef/chromeos.fmd file, adapt it to your mainboard if > necessary, and then point to it with CONFIG_FMDFILE. I'm not an expert for Apollo Lake either, but I know other Intel plat- forms and my way around their documentation. I too believe that adding an .fmd file like Julius described, will fix your problem. Though, there are already some non-CrOS boards in the tree. Might be more worth looking at their (simpler) .fmd (e.g. `src/mainboard/siemens/mc_apl1/mc_apl1.fmd`). Regarding the details, I've digged around a little. Here is what I found out so far (stop reading here unless you really want to know, it might confuse you even more): Apollo Lake uses a Firmware Descriptor (IFD) like other Intel platforms, but the IFD's layout is used much less. One region amidst this layout is the IFWI. The IFWI is partitioned by other means and contains code for some integrated controllers and also what used to be the BIOS. The latter is divided into IBB and OBB. The IBB partition is used for core- boot's bootblock. The OBB partition for everything else in coreboot. The OBB is the last part of the IFWI. To make the situation even more confusing, somebody had the great idea to use the same term, IFWI, for something slightly different. I guess to separate the read-only from updateable parts better, IFWI in the notion of coreboot's .fmd files is the actual IFWI minus the OBB. I will refer to it as the RO_CORE_IFWI (might not be the worst idea to rename it like this in coreboot). So what happens during build (cf. `soc/intel/ apollolake/Makefile.inc:125`): - coreboot is provided an IFWI image (that has to contain all the coreboot-unrelated code for the extra chipset controllers, those are just passed through by our build system). - Our build system crafts the RO_CORE_IFWI with the provided IFWI: o The OBB is stripped off. o The IBB is replaced with coreboot's bootblock. - The final image is build with o the RO_CORE_IFWI in place of IFWI in the .fmd and o all other coreboot parts in their respective place in the .fmd. Looking at the `mc_apl1.fmd` again: - SI_DESC is like the Intel Firmware Descriptor. - IFWI is the RO_CORE_IFWI (IFWI minus OBB with replaced IBB). - Everything else before DEVICE_EXTENSION is the OBB. - DEVICE_EXTENSIONS is another partition in the IFD, that I've just learned about. Nico PS. This is how I would have written such .fmd (currently not compatible to `apollolake/Makefile.inc`): FLASH 16M { SI_DESC@0x0 0x1000 IFWI@0x1000 0xefe000 { RO_CORE_IFWI@0x0 0x2ff000 OBB@0x2ff000 0xbff000 { FMAP@0x0000 0x800 COREBOOT(CBFS)@0x800 0xb9d800 UNIFIED_MRC_CACHE@0xb9e000 0x21000 { RECOVERY_MRC_CACHE@0x0 0x10000 RW_MRC_CACHE@0x10000 0x10000 RW_VAR_MRC_CACHE@0x20000 0x1000 } BIOS_UNUSABLE@0xbbf000 0x40000 } } DEVICE_EXTENSION@0xeff000 0x100000 UNUSED_HOLE@0xfff000 0x1000 }

2 1

Re: [coreboot] Exception on Skylake after enabling ACPI timer emulation
by Piotr Król 21 May '18

21 May '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 05/21/2018 07:35 AM, Youness Alaoui wrote: > Hi Piotr, Hi Youness, > > Great, I'm glad the ucode was indeed the issue, and that I was > lucky enough to spot it. I think it doesn't get added correctly > because the path might be wrong ? unless you put the ucode bin file > in the root directory of coreboot, then it might not find it, or > maybe it's another option to actually tell it to add the file to > cbfs. See our ucode related configs in : > https://code.puri.sm/kakaroto/coreboot-files/src/master/configs/config .librem13v2 > > CONFIG_SUPPORT_CPU_UCODE_IN_CBFS=y > CONFIG_CPU_MICROCODE_CBFS_GENERATE=y > CONFIG_CPU_UCODE_BINARIES="3rdparty/blobs/mainboard/$(MAINBOARDDIR)/cp u_microcode_blob.bin" > > Also note these two options which get passed to the FSP so the > microcode can get applied : CONFIG_CPU_MICROCODE_CBFS_LEN=0x18000 > CONFIG_CPU_MICROCODE_CBFS_LOC=0xFFE115A0> That location address > makes cbfstool add the ucode binary in cbfs at the right offset so > it's at that address, and the len has to match (or be superior) to > the ucode file size. I managed to fix things by adding to my defconfig: CONFIG_USE_BLOBS=y CONFIG_HAVE_IFD_BIN=y CONFIG_HAVE_ME_BIN=y CONFIG_FSP_M_FILE="3rdparty/blobs/mainboard/$(MAINBOARDDIR)/fspm.bin" CONFIG_FSP_S_FILE="3rdparty/blobs/mainboard/$(MAINBOARDDIR)/fsps.bin" CONFIG_CPU_UCODE_BINARIES="3rdparty/blobs/mainboard/$(MAINBOARDDIR)/cpu_ microcode_blob.bin" Of course I had to create correct directory in blobs repository. Thanks for help. I know see other issues in log that I have to deal with, but I think I can deal with those now. Best Regards, - -- Piotr Król Embedded Systems Consultant https://3mdeb.com | @3mdeb_com -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEE4DCbLYWmfoRjKeNLsu5x6WeqnkwFAlsDKvIACgkQsu5x6Weq nkymcQ/8CxwALrrbnjWRN11z98v2Dd+gG52HEcD4nR/hemFsvTvRpLkQes77gQrn TIuTtJw8jYafWmzimsd4ghwChdXfGH80U/DaNgTKmpg6t2zJaxMOJA94rkce46I/ udauUmNT9SKK62qfIE60mmxBJOJtxgBmrL3n1ABqce5QQm5r4/o7o5bF16iTtNwd c943QOOHRqW5/P44MvFNO70aXXIXyIUXNHnUPR/UIek33Sjn6955cEe7uP60Osu7 NKVY3pYmzMPjbVeLxGm+hcZyuZCLy4G3RwfqtAM3/Sjoi8tCrVjjNw6s52vji7iv 2yoTdIqUAKR0E0f8q9Q8+X9VAROLqTcllzxZ27u7wAIkLlz72umFUJDjq/7Znum/ uUjIMLfIe1Agy+hR2BqZZFb9/18ZwYUZ6bBW5b+rWjRNLG5o8Gy5g6FnBrgnVihe MJs3Hs6akWGltrgjOZ0IusHwk2pl86gCqCRr3vcgVUaJOMvff3exNwSEIesSMDc0 1f6RzTCj3KiYuPEu4urajJmzenqrI65S/1MkCy2XYLDYikkM3f4HICViLWTYSTvj 4hCXZ8b1C7l0zMHeQ5da2gQdt7Ko+q1aI8xE+CdmFhkUJW+1+fBe/s+O03+8GUjB OYKVB9sFvLehGgus4OVh7LUn4ciSIplw5jcCb9SEI2J8AeRfxTk= =QWlj -----END PGP SIGNATURE-----

1 0

ThinkPad W530 support
by Evgeny 21 May '18

21 May '18

I am pleased to announce a working patch for the W530. https://review.coreboot.org/#/c/coreboot/+/26136/ Regards, Evgeny Zinoviev

3 2

← Newer
1
2
3
4
5
6
7
...
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 May 2018