Hi Ivan,
On 03.04.2018 20:03, Ivan Ivanov wrote:
> I have noticed that both coreboot and seabios are using the very old
> versions of LZMA SDK.
True. I introduced the lzma code in coreboot (back when it was called
LinuxBIOS) when we were working on OLPC XO-1 support.
> If we will upgrade our LZMA libraries from the
> outdated-by-12-years 4.42 to the current version 18.04 , speed and
> compression ratio should improve and maybe a few bugs will be fixed.
Do you have any numbers for this? An improved compression ratio and
improved speed would be nice indeed, but how does the size of the
decompression code change? If the decompression code grows more than the
size reduction from better compression, it would be a net loss. A
significantly reduced decompression speed would also be a problem.
Decompression speed would have to be measured both for stream
decompression (i.e. the decompressor gets the compressed data in
single-byte or multibyte chunks) as well as full-size decompression
(i.e. the decompressor can access all compressed data at once). We also
have to make sure that stream decompression still works after the change.
> Do you think it should be done, or you are OK with using such an
> outdated version?
A size benefit for the resulting image is a good reason to switch.
Regards,
Carl-Daniel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hi @ all,
is there a Coroboot for the Lenovo T410 Laptop?
Greetings
Alex Veek
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iF4EAREIAAYFAlNxKzsACgkQ53cWmi2XuzOOXAD8CNLPoycJNftQzeHnMQbl8ZG9
4y2SPIHwLota1/Gsfm0BAJzhG2M+MKXDBJgazHjt/HM2DyAeHi6S24sGcwd1W2GN
=sFKM
-----END PGP SIGNATURE-----
A Hardware Enablement devroom will be taking place at FOSDEM this year,
on Sunday 10 December 2017. This newly-created devroom is the result of
3 proposals that were merged together. It is co-organized by several
individuals.
The devroom covers all aspects related to hardware enablement and
support with free software, including aspects related to boot software,
firmwares, drivers and userspace tools and adaptation.
Proposals for talks related to these topics are welcome and can be
submitted until Sunday 26 November 2017 via the pentabarf interface.
Short talks are encouraged over longer ones in order to cover a wide
range of topics.
The announcement for the devroom, that contains all the useful
information, was published at:
https://lists.fosdem.org/pipermail/fosdem/2017-October/002649.html
Cheers and see you at FOSDEM!
--
Paul Kocialkowski, developer of free digital technology and hardware
support
Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/https://git.code.paulk.fr/
Hello coreboot community,
recently, I tried to use Hugo view some documentation in HTML form, but
I couldn't get it to work properly (some pages 404'd when they
shouldn't). So I decided to look into using Sphinx[1] again.
I configured[2] Sphinx and the recommonmark Markdown parser for our
Documentation directory. The result can be viewed here:
https://neuschaefer.github.io/coreboot/
Advantages of this approach:
- The "readthedocs" theme, which I used has a useful navigation
sidebar and allows full navigation without JavaScript (the search
box does need JavaScript, because the search is performed on the
client side.)
- The top-level table of contents (i.e. the navbar) is generated from
a markdown file[3] rather than a special configuration file[4].
- The necessary packages (sphinx-doc, python-recommonmark,
python-sphinx-rtd-theme) are available in Debian; but so is Hugo.
Disadvantages:
- recommonmark does not support tables[5]. This is a limitation of the
CommonMark[6] dialect of Markdown. We'd have to use HTML tables
(<table>...</table>) instead.
- If we decide to switch https://coreboot.org/Documentation to Sphinx,
that would mean some work for the admins, like any other change in
infrastructure.
Possible migration path:
- Merge Sphinx support
- Look how well it works, and decide whether it's worth keeping, or
drop it
- Switch https://coreboot.org/Documentation (or https://doc.coreboot.org/?)
to Sphinx
- Remove hugo support
Overall, I like this setup, and I'd like https://coreboot.org/Documentation
to switch to it, but it has a few limitations.
I'd like to hear your opinions!
Thanks,
Jonathan Neuschäfer
[1]: http://www.sphinx-doc.org/en/stable/
[2]: https://review.coreboot.org/#/c/coreboot/+/25787/
[3]: https://review.coreboot.org/#/c/coreboot/+/25787/1/Documentation/index.md
[4]: https://review.coreboot.org/cgit/coreboot.git/tree/util/hugo/config.toml#n30
[5]: https://github.com/rtfd/recommonmark/issues/3
[6]: http://commonmark.org/
Hello,
After testing the board for some weeks I bought another CPU (6276). I
installed this into CPU1 slot and a 6238 in CPU2.
I checked that both CPUs are shining and also the memory (Micron
MT18JSF25672PDZ-1G4F1DD, populated in A2/C2/E2/G2 slots).
The problem is that Coreboot seems to hang at the beginning. I attach
console.log.
I reinstalled all the devices twice, checked the vendor manual, docs in
coreboot.org, messages in mailing list, but I don't know what is causing
the problem.
Last test I've done is booting with vendor bios, and it boots without
problem.
Any ideas?
Thank you for your help.
Regards,
- Eli
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 04/28/2018 02:37 PM, Mike Banon wrote:
Hi Mike,
>
> PC Engines alix1c - AMD LX - 2017-09-17 PC Engines alix2d - AMD LX
> - 2017-09-17 PC Engines apu1 - AMD Family 14h (AGESA) - 2017-09-05
> PC Engines apu2 // apu3 // apu4 // apu5 - AMD 00730F01 (PI) -
> 2017-10-26
What is expected frequency of sending board status updates? We have
all those board and even some awaiting port to coreboot.
We are committed to keep those platforms on the master but I'm not
sure if I understand rules based on which platforms are planned for
removal.
We maintain coreboot tree with customer specific customizations that
will probably never lend in mainline, because of that we are rather
interested to make coreboot work with PC Engines platforms on tagged
releases and not exactly on any random commit in between. Any commit
approach would require firmware validation automation which we will
eventually have. So if release cycles take a lot of time then IMO
delayed board status update should be allowed.
Second thing that IMO is problematic in board status is assumption
that system have to boot with vanilla coreboot. This is problematic
when you have to use customized version of SeaBIOS or any other
payload used for booting system.
Because of long weekend we will send board status updates for boards
under 3mdeb maintainership before 11 May. Please let me know if feel
this is too late.
Best Regards,
- --
Piotr Król
Embedded Systems Consultant
https://3mdeb.com | @3mdeb_com
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEE4DCbLYWmfoRjKeNLsu5x6WeqnkwFAlrkdC8ACgkQsu5x6Weq
nkyuUQ/+M8tDEEw0Qfz91ceVlkmp82B7+0j1Ur0EEgalNTe8rGK0iULKyEUsNT/d
41pyblnUNzP/DVaogekJFsAi3/v9plblfUVsAhIpvaW2jS90vTxg/PQ/PXqubzZW
TES2JyQKc3lCvlDACERGY+gnS/hPMYab05gKdV/wdoQtlxucJbaMLFQGisRbUVFE
Wz6ormhxaz9D4M/UPQILg8Zdy669f7tBJ4FVF2ZdRvbJuia4c0H/i3tWRZ3+w5AB
Dexe/OTAFHVPPtDTn+PU+BplGqRKlNFNmZhDctubRzYCFMZn8qPyV1dxD34G5N31
b+IpyanonL4aie7XbAa3f3AImOuP+ECCx/jdU8eCFFwhvn8MxmxA1syW6cFoNvst
gAiedOvYjhZ7+pE6xWwVVmeFBb2tiO6oEeCQ6N3h9gj1dtMxmzjS++5bE/msNIT0
EWURF6S86DYL6SZLKNeEKYl/5aa+5JoifalpnuNe/+7QQcN2IEIPHS/2xgMBehGk
3lzGTueQS7N7y9OaMMTn+MUjzTB5L54rEji2MmHnbToaGEivqHquyAvmTYaSj5E2
tTD5L0AM6UN6ifEGlk7kyx5lnFhzqsrs5+pSBFmoMYVHym1NidJzZPNng114y086
YsgdrKhrer2oXHcF60uyTasq4eCVUKksXNh27ikIX7Sw5D5n4tk=
=dj/x
-----END PGP SIGNATURE-----
I wrote a patch [0] for the finalize code issue. With that my X201i is working fine on current master besides an regression introduced in commit 7f5efd90e598320791200e03f761309ee04b58a3 [1]. With that regression USB and SD card is not working anymore and it raises the following errors:
[ 17.986754] usb 1-1: device not accepting address 2, error -110
[ 18.110095] usb 1-1: new high-speed USB device number 3 using ehci-pci
[ 18.200089] usb 2-1: device not accepting address 2, error -110
[ 18.323421] usb 2-1: new high-speed USB device number 3 using ehci-pci
[ 34.200083] usb 1-1: device not accepting address 3, error -110
[ 34.200169] usb usb1-port1: attempt power cycle
[ 34.413364] usb 2-1: device not accepting address 3, error -110
[ 34.413439] usb usb2-port1: attempt power cycle
[ 34.636752] usb 1-1: new high-speed USB device number 4 using ehci-pci
[ 34.850085] usb 2-1: new high-speed USB device number 4 using ehci-pci
[ 45.293417] usb 1-1: device not accepting address 4, error -110
[ 45.416732] usb 1-1: new high-speed USB device number 5 using ehci-pci
[ 45.506783] usb 2-1: device not accepting address 4, error -110
[ 45.630088] usb 2-1: new high-speed USB device number 5 using ehci-pci
[ 56.173393] usb 1-1: device not accepting address 5, error -110
[ 56.173445] usb usb1-port1: unable to enumerate USB device
[ 56.386753] usb 2-1: device not accepting address 5, error -110
[ 56.386845] usb usb2-port1: unable to enumerate USB device
Additionally there are some IRQ errors inside the kernel messages like
can't derive routing for PCI INT A
PCI INT A: no GSI
for different devices which seem related to the change in [1].
Cheers,
Matthias
[0] https://review.coreboot.org/#/c/coreboot/+/25914/
[1] https://review.coreboot.org/#/c/coreboot/+/22859/
On 29/04/18 14:14, Kyösti Mälkki wrote:
> On Sun, Apr 29, 2018 at 1:35 PM, Nicola Corna <nicola(a)corna.info> wrote:
>> April 28, 2018 5:59 PM, "Nico Huber" <nico.h(a)gmx.de> wrote:
>>
>>> Yes, that's very likely a problem. It looks like the whole finalize code
>>> path of the X201 was untested all the time (even on resume). I don't
>>> remember if EHCI debug works in SMM? If it does, you could enable log-
>>> ging for the SMI handler as well (if you want to debug it).
>>>
>>> Nico
>> Attached you can find the log with the SMM debug enabled, but it doesn't seem
>> to me much different from the non-debug log.
>>
>> Nicola
> DEBUG_SMI does not output to EHCI, I have considered it too unstable.
>
> You can try your luck with attached patch to have DEBUG_SMI=y output
> on EHCI debug. EHCI console code does not take precautions against
> someone else touching the same register set so it's likely to fail
> once payload and/or OS loads its EHCI driver, possibly making USB
> media and keyboard unusable as well.
>
> Kyösti
You are just, with this desperate chit-chat, fueling INTEL's big EGO.
Please, continue to do so! INTEL, at the end of the day, will thank
you for that! :-))
Please keep things civil. Whatever you think of Intel and FSP, this is a good opportunity to improve support for coreboot and others reading this thread would like to see progress.
________________________________
From: coreboot <coreboot-bounces(a)coreboot.org> on behalf of Zoran Stojsavljevic <zoran.stojsavljevic(a)gmail.com>
Sent: Monday, April 30, 2018 9:58:33 AM
To: Nico Huber
Cc: Nathaniel L Desimone; Furquan Shaikh; Vincent Palatin; coreboot(a)coreboot.org; Aaron Durbin; Stefan Reinauer; Martin Roth; ron minnich; Shelley Chen; Julius Werner; Vadim Bendebury; Nick Vaccaro; Chris Ching; Duncan Laurie; Subrata Banik
Subject: Re: [coreboot] Why do we have FSP-S
Nico, Aaron,
You are just, with this desperate chit-chat, fueling INTEL's big EGO.
Please, continue to do so! INTEL, at the end of the day, will thank
you for that! :-))
Zoran
_______
On Mon, Apr 30, 2018 at 4:48 PM, Nico Huber <nico.h(a)gmx.de> wrote:
> Hello Aaron,
>
> thanks for your reply.
>
> On 30.04.2018 05:22, Aaron Durbin wrote:
>> On Sat, Apr 28, 2018 at 7:16 AM, Nico Huber <nico.h(a)gmx.de> wrote:
>>> Hello coreboot folks, hello Intel and Google coreboot developers,
>>>
>>> back on Tuesday, some of us discovered a commit on gerrit [1] that
>>> implements (another) foreign interface inside coreboot. Discussing
>>
>> It's more of a bridge into coreboot's infrastructure, imo.
>
> It is. Anyway, maybe discuss that in another thread or on gerrit.
>
>>
>>> it didn't go well and I kind of bursted. I feel sorry about that now
>>> (especially because I got too personal).
>>>
>>> One of the causes for this clash definitely was that things apparently
>>> were discussed before but not with coreboot (i.e. this coreboot mailing
>>> list). So I'll try to take the general discussion here, but I've to
>>> start some years back, where you lost me.
>>>
>>> Some questions (that I believe have to be answered) right away. I'll
>>> argue about why later, so these won't get lost (in an already too long
>>> email):
>>>
>>>
>>> TLDR;
>>> For Google:
>>> You kind of introduced blobs in coreboot (with Sandy Bridge) which was
>>> a simple jump-in-jump-out thing and kind of accepted. The argument was
>>> that the things it does aren't documented by Intel anymore, AFAIR. But
>>> with Broadwell suddenly another blob emerged (in ramstage) some
>>> `refcode.elf` AIUI. It turned out, later, that this blob (also) does
>>> things that were open source for Haswell (and would work verbatim on
>>> Broadwell). It seems to play a role comparable to FSP-S.
>>> o What's the story behind this blob?
>>> o Why was it introduced?
>>> o Was there more than IP concerns? Time to market pressure maybe?
>>
>> Saying it's comparable to FSP-S is apt. The story is, like most
>> things, that it has specific things that are not architectural that
>> Intel thinks they need to be secret. Typical settings are related to
>> power management. When needing to be competitive in the laptop space
>> power is a big concern. Time to market may have been a thing too, but
>> I don't recall all the specifics. I'll get to it later in the
>> response, but there are temporal components to decisions and/or how
>> things change over time that are not within Google's control when
>> working on a particular platform.
>>
>>>
>>> For Intel:
>>> It's hard for me to understand what parts of your silicon init you can
>>> open-source and what parts you can't. I know your BIOS Writer's Guides
>>> (BWG) / BIOS Spec, and many things therein are often published by you
>>> or Google. Please tell us.
>>> o Are the things that you can *not* open-source documented at all?
>>> o if so, in these BWG documents?
>>> o Or is everything in these documents generally publishable (with
>>> some NDA clearance, ofc)?
>>> o For a configuration of FSP-S that just runs the bare minimum to
>>> boot (e.g. skips questionable add-ons like TXT, SGX), is there
>>> anything not publishable?
>>> o Can anything be done to get more documentation published? e.g.
>>> for things that are done in open source (or were done in the past)
>>> but are not publicly documented.
>>
>> Based on my working history a lot of BWGs and/or specs are usually
>> wrong. They don't always contain the right information, but generally
>> contain quite a few things that are wrong where you second guess
>> everything in the docs. This should sound familiar: the 'reference
>> code' is the documentation. Most docs are not in sync with reality or
>> necessarily with how the silicon was actually designed. It's my belief
>> when there wasn't as much change from version to version, the
>> copy-pasting in docs just kinda worked. But as things have been
>> getting more complicated and incorporating more 'features' the
>> documentation has not been keeping up.
>
> Still these documents exist. And I deem them most valuable. I know there
> are flaws that can drive you crazy. But! they give a very good overview
> about what has to happen for silicon init. If published (for my sake w/o
> the secret ingredient bits) [2], they would be a great reference for
> discussions about the design of clean silicon-init code. We could har-
> ness the power of the community much better.
>
> It doesn't matter if somebody with access to the reference code has to
> fix some bugs later, once you have a decent maintainable code base.
> Neither would a blob that hides the secret ingredients if it only con-
> tains those (and no infrastructure / control flow; I think you, Aaron,
> and me share the same opinion on that).
>
>>
>>>
>>>
>>> So why ask? The original introduction of blobs in coreboot in general
>>> happened with the argument that the things it does (e.g. memory init)
>>> are not documented anymore by Intel. This is a valid argument because
>>> the lack of documentation makes it harder to write clean code. I also
>>> believe it's true (that no documentation exists) because I've seen a
>>> previous BWG that already referred a lot to the reference code.
>>>
>>> But, AFAIR, the introduction of blobs in coreboot's *ramstage* was never
>>> discussed. The blobs I've seen so far all did things that were already
>>> open source for earlier platforms. Plus they are twisting coreboot into
>>> something that isn't coreboot anymore. Architectural changes happen in
>>> chipset specific code instead of moving coreboot as a whole (after an
>>> open discussion). Also, most of the positive aspects about coreboot are
>>> lost.
>>
>> Purely business commentary: In order to develop a competitive laptop
>> on recent hardware one needs to include the features that consumers
>> expect. Intel also ties those features inside of FSP, but FSP has a
>> responsibility problem. It has traditionally attempted to do things it
>> should not. FSP should be a library of sorts, but it has things in
>> there it shouldn't. I mentioned some of this on the CL itself about
>> our usage of SkipMpInit. It trying to take over resources that it
>> shouldn't (among other things).
>>
>> What architectural changes are you referring to? And what is your
>
> You've got me there. I meant architectural things, not changes. Like
> that patch on gerrit. It doesn't seem to be Intel specific, I also
> can't find any soc_ reference in it. Yet, it's pushed to soc/intel/
> and to me that looks like somebody wants to sneak it it (without big
> discussion / being thought through for all of coreboot).
>
>> definition of coreboot (I know see you wrote it below :)? early
>> firmware that will initialize everything in open source for Intel
>> platforms? I wish that were the case, but it's not something that is
>> allowed by Intel currently. I'd love to see more granularity in FSP,
>> but as noted in the CL commentary Intel hasn't been accepting of my
>> suggestions for making things more granular such that one could do the
>> only things that are deemed 'super secret' by Intel. The muddling of
>> responsibility and lack of granularity are the current result.
>>
>>>
>>> Of course, it's hard to argument about whether something is coreboot
>>> or not without a clear definition of coreboot. But let me get this
>>> one straight: It's definitely not coreboot just because it happens on
>>> coreboot.org.
>>>
>>> I'll try to sum up what is coreboot to me, and compare that to a current
>>> coreboot with FSP. coreboot
>>>
>>> 1. is free software
>>> 2. is open source
>>> 3. is auditable
>>> 4. is lean (less code means less bugs)
>>> 5. gives control to the user
>>>
>>> but with FSP:
>>>
>>> 1. You can not fully adapt it, you can't even just download it (often
>>> have to steal the FSP binary):
>>> 0%
>>> 2. Comparing the sizes of open-source parts and FSP, maybe 30%. But
>>> if you don't count open-source code that is only needed to handle
>>> blob issues, rather
>>> 20%
>>
>> Is this 20-30% coreboot/open source of the total? Were you counting
>> the edk2 stuff in there? A lot of the bloat in FSP comes from open
>> source edk2.
>
> You can't count EDK2 into it. Once it's built into FSP, it's not open-
> source any more (unless somebody proves what parts match a reproducible
> compilation of the open-source code). And for an open-source experience
> you'd still need means to adapt these EDK2 parts in the binary. It was
> just a wild guess based on my experience with Kaby Lake FSP (~500KiB),
> and guessed 200KiB coreboot.
>
>>
>>> 3. If you are backed by a huge company or government, you can audit
>>> coreboot+FSP (I guess), if not than not, 50%? But given that the
>>> size of the whole package is about 10 times the size of a clean
>>> implementation, you have to audit 10 times more code (of much
>>> poorer quality), thus at most
>>> 5%
>>> 4. 0% (see above)
>>> 5. That seems to be my only point that Intel cares about. Still,
>>> coreboot compatible binaries are often not available. You need
>>> very weird workarounds if the one setting you miss is not there:
>>> 50%
>>>
>>> Numbers are just educated guesses, but might match reality. If you
>>> average these, you'll see that coreboot+FSP is only 15% of (my)
>>> coreboot. I would estimate that you can get up to 20% with the
>>> design of FPS2.0.
>>
>> I agree with the overall assessment above. As currently
>> deployed/supported FSP is not really geared to people who don't have a
>> more intimate relationship with Intel. It's been brought up numerous
>> times, but it's Intel's decision to make a better product.
>
> Right, quality of their products is up to them. But isn't it our re-
> sponsibility to decide whether they can do that (15%) in the name of
> coreboot?
>
> Nico
>
> [2] Assuming that the BWGs don't contain the secret ingredients, even
> an NDA offer to all coreboot developer's (both hired ones and indi-
> viduals) could help. If Intel allows to derive open-source code from
> it (e.g. after a private review on gerrit) people would have less
> doubts about signing an NDA, IMHO. Just a random thought; anything I
> can come up with atm seems to be better than the status quo.
>
>>>
>>> So it's time for an FSP3.0 that was designed with the community,
>>> I'd say.
>>>
>>> Best regards,
>>> Nico
>>>
>>> [1] https://urldefense.proofpoint.com/v2/url?u=https-3A__review.coreboot.org_...
>
> --
> coreboot mailing list: coreboot(a)coreboot.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.coreboot.org_ma...
--
coreboot mailing list: coreboot(a)coreboot.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.coreboot.org_ma...
Hello Aaron,
thanks for your reply.
On 30.04.2018 05:22, Aaron Durbin wrote:
> On Sat, Apr 28, 2018 at 7:16 AM, Nico Huber <nico.h(a)gmx.de> wrote:
>> Hello coreboot folks, hello Intel and Google coreboot developers,
>>
>> back on Tuesday, some of us discovered a commit on gerrit [1] that
>> implements (another) foreign interface inside coreboot. Discussing
>
> It's more of a bridge into coreboot's infrastructure, imo.
It is. Anyway, maybe discuss that in another thread or on gerrit.
>
>> it didn't go well and I kind of bursted. I feel sorry about that now
>> (especially because I got too personal).
>>
>> One of the causes for this clash definitely was that things apparently
>> were discussed before but not with coreboot (i.e. this coreboot mailing
>> list). So I'll try to take the general discussion here, but I've to
>> start some years back, where you lost me.
>>
>> Some questions (that I believe have to be answered) right away. I'll
>> argue about why later, so these won't get lost (in an already too long
>> email):
>>
>>
>> TLDR;
>> For Google:
>> You kind of introduced blobs in coreboot (with Sandy Bridge) which was
>> a simple jump-in-jump-out thing and kind of accepted. The argument was
>> that the things it does aren't documented by Intel anymore, AFAIR. But
>> with Broadwell suddenly another blob emerged (in ramstage) some
>> `refcode.elf` AIUI. It turned out, later, that this blob (also) does
>> things that were open source for Haswell (and would work verbatim on
>> Broadwell). It seems to play a role comparable to FSP-S.
>> o What's the story behind this blob?
>> o Why was it introduced?
>> o Was there more than IP concerns? Time to market pressure maybe?
>
> Saying it's comparable to FSP-S is apt. The story is, like most
> things, that it has specific things that are not architectural that
> Intel thinks they need to be secret. Typical settings are related to
> power management. When needing to be competitive in the laptop space
> power is a big concern. Time to market may have been a thing too, but
> I don't recall all the specifics. I'll get to it later in the
> response, but there are temporal components to decisions and/or how
> things change over time that are not within Google's control when
> working on a particular platform.
>
>>
>> For Intel:
>> It's hard for me to understand what parts of your silicon init you can
>> open-source and what parts you can't. I know your BIOS Writer's Guides
>> (BWG) / BIOS Spec, and many things therein are often published by you
>> or Google. Please tell us.
>> o Are the things that you can *not* open-source documented at all?
>> o if so, in these BWG documents?
>> o Or is everything in these documents generally publishable (with
>> some NDA clearance, ofc)?
>> o For a configuration of FSP-S that just runs the bare minimum to
>> boot (e.g. skips questionable add-ons like TXT, SGX), is there
>> anything not publishable?
>> o Can anything be done to get more documentation published? e.g.
>> for things that are done in open source (or were done in the past)
>> but are not publicly documented.
>
> Based on my working history a lot of BWGs and/or specs are usually
> wrong. They don't always contain the right information, but generally
> contain quite a few things that are wrong where you second guess
> everything in the docs. This should sound familiar: the 'reference
> code' is the documentation. Most docs are not in sync with reality or
> necessarily with how the silicon was actually designed. It's my belief
> when there wasn't as much change from version to version, the
> copy-pasting in docs just kinda worked. But as things have been
> getting more complicated and incorporating more 'features' the
> documentation has not been keeping up.
Still these documents exist. And I deem them most valuable. I know there
are flaws that can drive you crazy. But! they give a very good overview
about what has to happen for silicon init. If published (for my sake w/o
the secret ingredient bits) [2], they would be a great reference for
discussions about the design of clean silicon-init code. We could har-
ness the power of the community much better.
It doesn't matter if somebody with access to the reference code has to
fix some bugs later, once you have a decent maintainable code base.
Neither would a blob that hides the secret ingredients if it only con-
tains those (and no infrastructure / control flow; I think you, Aaron,
and me share the same opinion on that).
>
>>
>>
>> So why ask? The original introduction of blobs in coreboot in general
>> happened with the argument that the things it does (e.g. memory init)
>> are not documented anymore by Intel. This is a valid argument because
>> the lack of documentation makes it harder to write clean code. I also
>> believe it's true (that no documentation exists) because I've seen a
>> previous BWG that already referred a lot to the reference code.
>>
>> But, AFAIR, the introduction of blobs in coreboot's *ramstage* was never
>> discussed. The blobs I've seen so far all did things that were already
>> open source for earlier platforms. Plus they are twisting coreboot into
>> something that isn't coreboot anymore. Architectural changes happen in
>> chipset specific code instead of moving coreboot as a whole (after an
>> open discussion). Also, most of the positive aspects about coreboot are
>> lost.
>
> Purely business commentary: In order to develop a competitive laptop
> on recent hardware one needs to include the features that consumers
> expect. Intel also ties those features inside of FSP, but FSP has a
> responsibility problem. It has traditionally attempted to do things it
> should not. FSP should be a library of sorts, but it has things in
> there it shouldn't. I mentioned some of this on the CL itself about
> our usage of SkipMpInit. It trying to take over resources that it
> shouldn't (among other things).
>
> What architectural changes are you referring to? And what is your
You've got me there. I meant architectural things, not changes. Like
that patch on gerrit. It doesn't seem to be Intel specific, I also
can't find any soc_ reference in it. Yet, it's pushed to soc/intel/
and to me that looks like somebody wants to sneak it it (without big
discussion / being thought through for all of coreboot).
> definition of coreboot (I know see you wrote it below :)? early
> firmware that will initialize everything in open source for Intel
> platforms? I wish that were the case, but it's not something that is
> allowed by Intel currently. I'd love to see more granularity in FSP,
> but as noted in the CL commentary Intel hasn't been accepting of my
> suggestions for making things more granular such that one could do the
> only things that are deemed 'super secret' by Intel. The muddling of
> responsibility and lack of granularity are the current result.
>
>>
>> Of course, it's hard to argument about whether something is coreboot
>> or not without a clear definition of coreboot. But let me get this
>> one straight: It's definitely not coreboot just because it happens on
>> coreboot.org.
>>
>> I'll try to sum up what is coreboot to me, and compare that to a current
>> coreboot with FSP. coreboot
>>
>> 1. is free software
>> 2. is open source
>> 3. is auditable
>> 4. is lean (less code means less bugs)
>> 5. gives control to the user
>>
>> but with FSP:
>>
>> 1. You can not fully adapt it, you can't even just download it (often
>> have to steal the FSP binary):
>> 0%
>> 2. Comparing the sizes of open-source parts and FSP, maybe 30%. But
>> if you don't count open-source code that is only needed to handle
>> blob issues, rather
>> 20%
>
> Is this 20-30% coreboot/open source of the total? Were you counting
> the edk2 stuff in there? A lot of the bloat in FSP comes from open
> source edk2.
You can't count EDK2 into it. Once it's built into FSP, it's not open-
source any more (unless somebody proves what parts match a reproducible
compilation of the open-source code). And for an open-source experience
you'd still need means to adapt these EDK2 parts in the binary. It was
just a wild guess based on my experience with Kaby Lake FSP (~500KiB),
and guessed 200KiB coreboot.
>
>> 3. If you are backed by a huge company or government, you can audit
>> coreboot+FSP (I guess), if not than not, 50%? But given that the
>> size of the whole package is about 10 times the size of a clean
>> implementation, you have to audit 10 times more code (of much
>> poorer quality), thus at most
>> 5%
>> 4. 0% (see above)
>> 5. That seems to be my only point that Intel cares about. Still,
>> coreboot compatible binaries are often not available. You need
>> very weird workarounds if the one setting you miss is not there:
>> 50%
>>
>> Numbers are just educated guesses, but might match reality. If you
>> average these, you'll see that coreboot+FSP is only 15% of (my)
>> coreboot. I would estimate that you can get up to 20% with the
>> design of FPS2.0.
>
> I agree with the overall assessment above. As currently
> deployed/supported FSP is not really geared to people who don't have a
> more intimate relationship with Intel. It's been brought up numerous
> times, but it's Intel's decision to make a better product.
Right, quality of their products is up to them. But isn't it our re-
sponsibility to decide whether they can do that (15%) in the name of
coreboot?
Nico
[2] Assuming that the BWGs don't contain the secret ingredients, even
an NDA offer to all coreboot developer's (both hired ones and indi-
viduals) could help. If Intel allows to derive open-source code from
it (e.g. after a private review on gerrit) people would have less
doubts about signing an NDA, IMHO. Just a random thought; anything I
can come up with atm seems to be better than the status quo.
>>
>> So it's time for an FSP3.0 that was designed with the community,
>> I'd say.
>>
>> Best regards,
>> Nico
>>
>> [1] https://review.coreboot.org/#/c/coreboot/+/25634/
On 28/04/2018 14:37, Mike Banon wrote:
> There are a lot of nice AMD-based coreboot-supported boards which have
> an outdated board_status and are at risk of removal. The majority of
> these boards (with the exception of PC engines apu2//3//4//5) - do not
> require a closed source AMD PSP binary to run, and ( also compared to
> many Intel boards which require Intel ME proprietary binary ) these
> AMD boards are highly user-controllable - some of them are even
> supported by the libreboot project!
according to https://www.pcengines.ch:
> PC Engines alix1c - AMD LX - 2017-09-17
replaced by Alix1e - eol
> PC Engines alix2d - AMD LX - 2017-09-17
still produced but not recommended for new designs
> PC Engines apu1 - AMD Family 14h (AGESA) - 2017-09-05
APU1D and APU1D4 in active prodution
> PC Engines apu2 // apu3 // apu4 // apu5 - AMD 00730F01 (PI) - 2017-10-26
this is the most recent system and actively produced
