coreboot April 2018

coreboot@coreboot.org

68 participants
128 discussions

Re: [coreboot] Pseudonyms with board_status results and gerrit
by Peter Stuge 08 Apr '18

08 Apr '18

David Hendricks wrote: > As I understand the DCO is only required for code submissions, while > board_status results are auto-generated and don't require a sign-off. Not > sure how Patrick and others feel about allowing aliases to be used for > gerrit accounts though. I don't care who posts board_status results. I think it's absolutely fine to contribute them using a pseudonym and I feel the same way about gerrit accounts. They are just some entries in a database without any legal relevance for source code. There was never a requirement to show ID before getting a gerrit account and there shouldn't be. Take care and enjoy the weekend! //Peter

1 0

Re: [coreboot] coreboot is going to make kcma-d8 obsolete
by Taiidan＠gmx.com 07 Apr '18

07 Apr '18

On 04/06/2018 09:06 PM, ron minnich wrote: > On Fri, Apr 6, 2018 at 5:45 PM Thierry Laurion <thierry.laurion(a)gmail.com> wrote: > >> I agree. This is wrong. >> Kgpe-d16 and alike are the last resorts for x86 blob free hardware. >> >> This NEEDS to be kept maintained and upstreamed. > I like the board too. I have one. I have no time to keep it going. I have > not even turned it on in months. > > Now that I think about it, my board has an EM100. I can try to automate the > mess if I can remember where the directions are. I also need to work out > remote reset :-) -- any hints on what to buy to make that go? > > Realistically, though, if you want blob free, I think you need power9 or > riscv. Of course, but the D16/D8 are fine for legacy x86 applications that some people need to run and they are both blob free, the last x86 boards that are. > I've written x86 off for blob free. I'm sad about that, given where > we were in 2000 and where we are today, but there's not much to be done for > it. AMD and Intel just don't see this as a priority :-( Yeah x86 is dead freedomwise but that doesn't mean boards that people know are functional should be removed from coreboot just because. I highly doubt these policies happen in a vacuum.

3 2

Re: [coreboot] coreboot is going to make kcma-d8 obsolete
by Timothy Pearson 07 Apr '18

07 Apr '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I might be able to get a report in. Need to pull a machine out of production though to do it, so it could be a bit (have to wait for a maintainance window). On 04/06/2018 04:18 PM, Felipe Sanches wrote: > isn't git commit history forever? > > 2018-04-06 18:14 GMT-03:00 Leah Rowe <info(a)gluglug.org.uk > <mailto:info@gluglug.org.uk>>: > > hi, > > https://mail.coreboot.org/pipermail/coreboot/2018-April/086449.html > <https://mail.coreboot.org/pipermail/coreboot/2018-April/086449.html> > > please do all relevant tests and submit a "coreboot status" report on > asus kgpe-dcma8. you use this board for "critical" applications > relative to your own interests, > e.d.ghttps://mail.coreboot.org/pipermail/coreboot/2018-April/086449.html > <http://mail.coreboot.org/pipermail/coreboot/2018-April/086449.html> > . > asus kgpe dpge-d16 d16 > > coreboot has a policy of deleting source code (read: maintenance) of > "unmaintained" boards). please test coreboot (per coreboot policies) > on this board, and submit "board status" information, so that the asus > kcma-d8 source code isn't (literally. please read that literally) > deleted from coreboot.bit > > (by extension, this applies to ASUS KGPE D16) > > Don't blame me for coreboot's shortsightedness on this matter. I > simply wish for coreboot.git to continue remaining official > maintenance of what remains of the maintenance of libre-friendly > hardware, within the coreboot project) - -- coreboot mailing list: coreboot(a)coreboot.org <mailto:coreboot@coreboot.org> https://mail.coreboot.org/mailman/listinfo/coreboot <https://mail.coreboot.org/mailman/listinfo/coreboot> - -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 (direct line) +1 (512) 690-0200 (switchboard) https://www.raptorengineering.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJax+pAAAoJEK+E3vEXDOFbw4wIAKzCnhL5gO2CZQXzOMoEv8ft 94pMK5yBQvZZsgBvvWlE2AVHPDK0CWJlyji1e7qgHn8k0IDQRcHaCLWU6sQL+nFO DgRk00Kd503eOqV7Pf+vBs9WuxAmZSVvNMzFqjLJWiq+rcD/6rd9c8VFAcciVhop /0Cz3wa5aIDAhzlkFT9IV25DAkyjtEVpFKeBXJsKvubGuPGCQLGsquvNgqoWDWGO 7KgRSDYRHtkCmsAdZoTnVZYhSHDE/LOGct2HRx2yKtjeOfKuWgIJ3ra9/UOOvqIe 4shxpGhmJz6twXgHtIRM0zK0x9n6dEiOnD2/uROmjc67BuU6CG30hDkhyg15U3E= =k/Nm -----END PGP SIGNATURE-----

8 8

coreboot is going to make kcma-d8 obsolete
by Leah Rowe 07 Apr '18

07 Apr '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 hi, https://mail.coreboot.org/pipermail/coreboot/2018-April/086449.html please do all relevant tests and submit a "coreboot status" report on asus kgpe-dcma8. you use this board for "critical" applications relative to your own interests, e.d.ghttps://mail.coreboot.org/pipermail/coreboot/2018-April/086449.html . asus kgpe dpge-d16 d16 coreboot has a policy of deleting source code (read: maintenance) of "unmaintained" boards). please test coreboot (per coreboot policies) on this board, and submit "board status" information, so that the asus kcma-d8 source code isn't (literally. please read that literally) deleted from coreboot.bit (by extension, this applies to ASUS KGPE D16) Don't blame me for coreboot's shortsightedness on this matter. I simply wish for coreboot.git to continue remaining official maintenance of what remains of the maintenance of libre-friendly hardware, within the coreboot project) - -- Leah Rowe Libreboot developer and project founder. Use free software. Free as in freedom. https://www.gnu.org/philosophy/free-sw.html Use a free BIOS - https://libreboot.org/ Use a free operating system, GNU+Linux. Support computer user freedom https://sfconservancy.org/ https://fsf.org/ - https://gnu.org/ Minifree Ltd, trading as Ministry of Freedom | Registered in England, No. 9361826 | VAT No. GB202190462 Registered Office: 19 Hilton Road, Canvey Island, Essex SS8 9QA, UK | Web: https://minifree.org/ -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEE+JRrnG26iGmvPhSA/0W3TPnRz5QFAlrH4ykACgkQ/0W3TPnR z5Rshgf8C7+6PG6u6qTPEx+ObrA2ibQrJ37TjRau2J5OoCM5lfNf6A86OKbPB9sW 0fm5bD1vsGrEfyQsUxCqbrQ8WKMZ2j1yJXYSWJLfdq4Cltfvy+mzt4Fl0DSOpJ3s PAGyqTAK9+MUAxJxra6nVj0zrXznf1z+LgQxBCKaB+wM6yzbbq8jtpshSvaM/rAu q1ZDyk9M4VsIRxMY5/NqYvtp5pZ2nYFaKJoXGvk2pKA8wkcRN1I130YdbbDG4sOQ 7AEfOEb06nmcGAJDUmAmPTc+9ZzjoJZteDBjsv7WX6hGSW381tvlPAj9YujwUkng QwilQ2YQDp+m3J7W1yOfTWVivVMgow== =L20B -----END PGP SIGNATURE-----

2 3

Re: [coreboot] coreboot is going to make kcma-d8 obsolete
by ron minnich 07 Apr '18

07 Apr '18

On Fri, Apr 6, 2018 at 5:45 PM Thierry Laurion <thierry.laurion(a)gmail.com> wrote: > I agree. This is wrong. > Kgpe-d16 and alike are the last resorts for x86 blob free hardware. > > This NEEDS to be kept maintained and upstreamed. > > > I like the board too. I have one. I have no time to keep it going. I have not even turned it on in months. Now that I think about it, my board has an EM100. I can try to automate the mess if I can remember where the directions are. I also need to work out remote reset :-) -- any hints on what to buy to make that go? Realistically, though, if you want blob free, I think you need power9 or riscv. I've written x86 off for blob free. I'm sad about that, given where we were in 2000 and where we are today, but there's not much to be done for it. AMD and Intel just don't see this as a priority :-( ron

1 0

Re: [coreboot] Problem with tianocore compilation in coreboot-sdk:1.50
by Piotr Król 06 Apr '18

06 Apr '18

On 04/06/2018 12:20 PM, Patrick Georgi wrote: > Am Mi., 4. Apr. 2018 um 18:10 Uhr schrieb Aaron Durbin via coreboot > <coreboot(a)coreboot.org <mailto:coreboot@coreboot.org>>: > > > Agree, but coreboot use old commit from edk2. Is it fine to push > vUDK2018? > > I guess? I'm not really sure who uses edk2. I guess tianocore payload? > Patrick is on holiday right now, but he would probably the best person > to answer that. > > It's used for the tianocore payload, indeed. > And yes, updating to a newer commit is fine. > > > > I believe coreboot should stick to edk2 releases not to random commits > > in the tree. > > That sounds like a reasonable guideline. Ok, I will push vUDK2018. > However if a release isn't fit for use as a coreboot payload, I'd go for > (not so) random commits that fix problems rather than stick to another > project's schedule and keep things broken. > > > Can anyone tell what tests were made against tianocore payload? There > > are patches in payload/external/tianocore/patches and I'm not sure > > against what hardware those should be validated. > > The payload integration stuff is provided on a best-effort basis, > so right now "it builds and it boots on one system" is good enough. > If you want to support the default payload selection for your board(s), > I'll appreciate your effort, and we could tighten up the policy around > it (so that you, and others who volunteer to test, would have to sign > off on updates that might affect their supported systems). Can you tell what is this "one system"? I did ECC2017 presentation about support of tianocore payload on PC Engines apu{2,3,4,5}. With couple patches I was able to port that support on top of vUDK2018. https://github.com/3mdeb/edk2/pull/2/files Truly I just need one patch payloads/external/tianocore/1_CorebootPayloadPkg_pcinoenum.patch - other patches are not exactly needed for apu{2,3,4,5} support. My modification probably should lend somewhere in edk2, but I'm not sure how much they are interested. I just wonder how to solve situation where edk2 customization is needed to boot given platform and in the same case customization may affect behavior of other platforms. > Ideally we'd have automated hardware testing, but that's a sore point > for years now. :-( Internally we use RTE (Remote Test Environment) it is open hardware: https://github.com/3mdeb/rte-schematics Our plan is to create commercial service on top of that platform with firmware development, validation and remote debugging services. We are in preparation of marketing materials, so some offer should appear soon. I already had email discussion with Patrick, but we didn't moved forward. Some blog posts about RTE: https://3mdeb.com/firmware/minnowboard-turbot-remote-firmware-flashing-with… https://3mdeb.com/firmware/pc-engines-apu2-python-robot-framework-validatio… Best Regards, -- Piotr Król Embedded Systems Consultant http://3mdeb.com | @3mdeb_com

2 1

Re: [coreboot] Problem with tianocore compilation in coreboot-sdk:1.50
by Patrick Georgi 06 Apr '18

06 Apr '18

Am Mi., 4. Apr. 2018 um 18:10 Uhr schrieb Aaron Durbin via coreboot < coreboot(a)coreboot.org>: > > Agree, but coreboot use old commit from edk2. Is it fine to push > vUDK2018? > > I guess? I'm not really sure who uses edk2. I guess tianocore payload? > Patrick is on holiday right now, but he would probably the best person > to answer that. > It's used for the tianocore payload, indeed. And yes, updating to a newer commit is fine. > > I believe coreboot should stick to edk2 releases not to random commits > > in the tree. > That sounds like a reasonable guideline. However if a release isn't fit for use as a coreboot payload, I'd go for (not so) random commits that fix problems rather than stick to another project's schedule and keep things broken. > Can anyone tell what tests were made against tianocore payload? There > > are patches in payload/external/tianocore/patches and I'm not sure > > against what hardware those should be validated. > The payload integration stuff is provided on a best-effort basis, so right now "it builds and it boots on one system" is good enough. If you want to support the default payload selection for your board(s), I'll appreciate your effort, and we could tighten up the policy around it (so that you, and others who volunteer to test, would have to sign off on updates that might affect their supported systems). Ideally we'd have automated hardware testing, but that's a sore point for years now. :-( 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

Coreboot X230 Howto and Questions regarding GRUB and Qubes
by 799 06 Apr '18

06 Apr '18

Hello, I finally found the time to complete the first draft of my Coreboot x230 How-to. While I need to fill in some small gaps how to put the hardware parts together, all the other stuff is covered including extracting Blobs and vga.rom. The how-to is located here: https://github.com/Qubes-Community/Contents/blob/master/docs/coreboot/x230.… The coreboot config I have used is here: https://github.com/Qubes-Community/Contents/blob/master/docs/coreboot/x230-… I wrote the how-to as I need to look at several places to get everything together for example how to extract Blobs, how to merge two bios files into one etc. Having everything in one place is nice for a newbie if he owns exactly the same modell/x230. Questions: 1) Lots of info is spread in the Coreboot und Qubes Mailinglists, is there anything in Coreboot which is Qubes specific and which should be mentioned in the how-to? Someone one mentioned Anti-Evil-Maid-Protection might be an issue. 2) Also I'd like to include some information about SeaBIOS vs. GRUB. As far as I know the benefit of SeaBIOs is that it is possible to boot Windows (needing vga.rom etc.) and the benefit of grub is to be able to encrypt /boot. What would be the best practise configuration if a user is running Qubes OS as only Operating system? Are there any downsizes running an encrypted boot partition? 3) I have attached the config which was generated after running make nconfig. I'd like to see someone with more skills giving some hints about which are not really necessary when running a Qubes as the only Operating system. How-to was placed on GitHub so that it can be used/edited by everyone, if useful feel free to grab content for the Coreboot wiki. I just like to use GitHub as collaborative documentation hub ;-) [799]

1 0

Re: [coreboot] How to handle vbt.bin
by Nico Huber 05 Apr '18

05 Apr '18

On 05.04.2018 18:15, Matt DeVillier wrote: > my instinct is to put it in the 3rd party blobs repo, since it's added to > the CBFS w/o modification (ie, is treated like a blob), unlike the SPD hex > files which are selectively ordered and assembled into the spd.bin (ie, > treated as source). Files are concatenated, I don't see how this is treating sth. as source. > > For the example case you sited of users building coreboot images for > Chromebooks (eg), they still need numerous other platform/device specific > blobs (ie, FSP), so having the vbt alone in the main repo is really not of > any consequence. That's very wrong. For instance I would have added Skylake+ backlight support to coreboot over a year ago if the information wasn't hidden in a secret lair. Not having information published early and conveniently accessible is always of consequence. You might just not know in what ways yet. ;) > I'd also like to see those other required blobs in the > 3rd party blobs repo, but that's an entirely separate issue :) True. Nico

2 1

Re: [coreboot] Problem with tianocore compilation in coreboot-sdk:1.50
by Piotr Król 04 Apr '18

04 Apr '18

On 04/04/2018 05:31 PM, Aaron Durbin wrote: > On Wed, Apr 4, 2018 at 4:55 AM, Piotr Król <piotr.krol(a)3mdeb.com> wrote: >> Hi all, >> I can't compile tianocore payload using coreboot-sdk:1.50 and coreboot 4.7. >> >> VfrUtilityLib.cpp: In member function 'CHAR8* >> CVfrStringDB::GetVarStoreNameFormStringId(EFI_STRING_ID)': >> >> VfrUtilityLib.cpp:3375:26: error: ISO C++ forbids comparison between >> pointer and integer [-fpermissive] >> if (mStringFileName == '\0' ) { > > That's just an incorrect check. i.e. bad code. Current master seems to > not have that error. > > https://github.com/tianocore/edk2/blob/master/BaseTools/Source/C/VfrCompile… > > FWIW, comparing a char (integer) to a pointer is indeed incorrect. Agree, but coreboot use old commit from edk2. Is it fine to push vUDK2018? I believe coreboot should stick to edk2 releases not to random commits in the tree. Can anyone tell what tests were made against tianocore payload? There are patches in payload/external/tianocore/patches and I'm not sure against what hardware those should be validated. Best Regards, -- Piotr Król Embedded Systems Consultant http://3mdeb.com | @3mdeb_com

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot April 2018