coreboot February 2017

coreboot@coreboot.org

66 participants
212 discussions

coreboot community meeting minutes for February 16, 2017
by Martin Roth 17 Feb '17

17 Feb '17

Here are the meeting minutes of today's coreboot community meeting. Info about the next meeting (March 2) is at the bottom. ################################################################## General coreboot news * coreboot is working on joining the Software Freedom Conservancy in a fiscal sponsorship agreement. Work on this is moving forward, and is speeding up. Several announcements about this should be posted soon. - Summary by Martin; there will be a blog post - goal is April, or early May at the very latest Infrastructure Issues & News * Updated coverity tools from 8.5.0.5 to 8.7.0 - coreboot's coverity testing is run twice a week by Jenkins - Tested projects: flashrom, ChromeEC, vboot, Memtest86+ - All other projects are tested daily or when commits happen * Having problems with merging users in gerrit - We plan to email people with multiple existing accounts and merge them, but due to gerrit upgrades, there are currently issues that we need to figure out before we can make progress on this. * Discussions on the current Mailing list vs switching to a forum * coreboot is evaluating the idea switching from the mailing list to a forum package. A poll on this will be posted shortly. - Switch to reddit? - Switch to google groups? - Look for a forum software package that integrates well with the mailing list. - Skepticism was expressed about ditching the mailing list. * Because jenkins builders build in tmpfs, memory was getting filled, and builds were failing. We've taken steps to mitigate this. * IRC/Mattermost - Mattermost was set up to help make it easier for people who aren't familiar with irc - To reduce spam on irc, only allow registered nicks to talk? - How big is the spam/abuse problem? - Deprecate IRC channel? - Not being planned right now, but in the future? - Mattermost's default channel doesn't have irc bridged. It sounds like the latest version of mattermost can add multiple default channels, so we can add the irc channel as a default. Development * Review of commits - Martin has been busy and hasn't been able to review things as much - The best way to get a quick review is to post in chat/irc asking for reviews on specific patches. - How do we get more people to review patches? * Discussion *Add coreboot storage driver* https://www.coreboot.org/pipermail/coreboot/2017-February/thread.html#83218 - How will a decision on this be made? - If we're going to come to any conclusion, the decision will probably need to be made by Stefan. Interesting External news items * Raptor engineering looking for support in porting openbmc for the ASUS KGPE-D16 board - http://www.phoronix.com/scan.php?page=news_item&px=KGPE-D16-OpenBMC-Effort and https://firmwaresecurity.com/tag/coreboot/ coreboot community meeting related * Attendance has been spotty. Is this worthwhile? - Yes - The community meeting is useful to people - Ten participants today \o/ * Very few people actually add agenda items. * Is the time the issue? Should we try switching time again? * Announcing it on IRC (about one hour before it begins) helps * We should announce it on the mailing list, the day before too * Several people weren't aware that we had bi-weekly coreboot conference meetings. ################################################################## Next meeting is March 2, 2017 Check the coreboot calendar for the time in your timezone: https://www.coreboot.org/calendar.html Join using the bluejeans web app or the phone bridge: https://bluejeans.com/616384323 Phone bridge call in numbers: https://www.bluejeans.com/numbers Meeting ID: 616384323 Current agenda & history: https://coreboot-meeting.pads.ccc.de/CommunityMeetingTopics

1 0

Does have X220 SOIC8, WSON or either flash chip form factor?
by Leah Rowe 16 Feb '17

16 Feb '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, Pretty much as the subject suggests. Can someone advise? I'm informed that X220 laptops with the M25PX64 flash chip are WSON instead of SOIC8. - -- Leah Rowe Libreboot developer Use free software. Free as in freedom. https://en.wikipedia.org/wiki/Free_software Use a free operating system, GNU+Linux. https://libreboot.org/docs/distros/ Or BSD: https://libreboot.org/docs/bsd/ Use a free BIOS. https://libreboot.org/ Support computer user freedom. https://peers.community/ 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/0W3TPnRz5QFAlil4KYACgkQ/0W3TPnR z5ReuwgAwJPU8o9Rx1nId5X3Xwozu8FoiyCmpRbQf14YXg62eNn6DDGHxN6uSaT9 4b7DmQ3eLgdidFzmxqyUIQT+wfmdb48tWl3jet6ikPNdtaKdZBytoHi9MpeW5Kjk NzCWGobRKdklcZutOOktrKQQccqasO1fPlsvmFTlvclC5lWFxhnnEAsnTD/+qKx0 zOp6Up3TRCx1u+64PP9syA+awxua+cMd4/SqBkeHY2qMzHPTY8Gnua0dQyVVMq7w obXUwILZEr9XspccoHnQNZDmTWHMfhnE1AUk5FUX9C531S8dEpCYoq3qJbj+kr/v jd5SvmjtoR4qvfFnjilW0ITPK7/MXA== =I+4j -----END PGP SIGNATURE-----

2 2

Corboot on IPC-FP4-DP G Series
by giuseppe.ferrigni＠inwind.it 16 Feb '17

16 Feb '17

Hi, I'm trying to flash corboot on a IPC-FP4-DP G Series. The system has the following components (from CPU-Z software tool): CPU: AMD GX-224IJ - 00670F00 - Prairie Falcon (Family 15h Model 70h - Stoney Ridge) MOTHERBOARD: Gardenia CRB CHIPSET: AMD K15IMC SOUTHBRIDGE: Carrizo FCH LPCIO: Fintek F81803 It seems that the actual coreboot release is compatible with each component, so I configured it as in the attached file. Obviously, nothing is so simple. After flashing, nothing on video, nothing on COM port. I have now some simple questions: - is my configuration correct? - how can I start debugging, since I have no feedback? - Can I test the boot process of the rom in some way using qemu? - How can I know if the COM ports are connected to the APU or to the superIO? Which is the right configuration in the first case and in the second one? I appreciate any help to make something work...even partially. Giuseppe

1 0

coreboot and Software Freedom Conservancy
by Karen Sandler 16 Feb '17

16 Feb '17

Hi, I'm Executive Director of the Software Freedom Conservancy. I am excited to write that Conservancy's Project Evaluation Committee has approved coreboot for membership in Conservancy. Conservancy will begin negotiating a document with coreboot leadership called a "fiscal sponsorship agreement" (FSA). You can find a template of the agreement available on Conservancy's website at: https://sfconservancy.org/members/apply/ConservancyFSATemplate.pdf (there are .odf and .tex files available too). If you have questions or concerns, we suggest you discuss them on this forum or with Conservancy privately if you prefer. Conservancy's "Project Intake group" can be reached by the alias project-intake(a)sfconservancy.org and is comprised of the following people: Bradley M. Kuhn, Karen Sandler, Tony Sebro, Jeremy Allison, Tom Callaway, Martin Michlmayr. All of us are members of Conservancy's Project Evaluation Committee and will be happy to answer questions. We look forward to coreboot joining Conservancy! Karen M. Sandler Executive Director, Software Freedom Conservancy __________ Become a Supporter today! http://sfconservancy.org/supporter/

2 1

Re: [coreboot] [PUBLIC INFO] Intel's Atom C2000 chips are bricking products – and it's not just Cisco hit
by Zoran Stojsavljevic 16 Feb '17

16 Feb '17

Hm... The saga continues! As additional info to ones who are using C2000 (formerly known as Rangeley). http://www.fudzilla.com/news/processors/42876-intel-s-atom-c2000-chip-flaw-… Common sense would dictate QA and clock circuit designer get fired on spot. But, how now INTEL logic works, they will be fast path promoted. ;-) Zoran _______ On Tue, Feb 7, 2017 at 12:47 PM, Zoran Stojsavljevic < zoran.stojsavljevic(a)gmail.com> wrote: > Intel's Atom C2000 chips are bricking products – and it's not just Cisco > hit > http://www.theregister.co.uk/2017/02/06/cisco_intel_ > decline_to_link_product_warning_to_faulty_chip/ > > Just read it on the news. Since I have noticed that some people here use > Coreboot with C2000 microservers' FSP products, they should read this > article, and see if it helps them, anyhow?! > > The comments for this article are here... All on your own peril! > https://forums.theregister.co.uk/forum/1/2017/02/06/cisco_ > intel_decline_to_link_product_warning_to_faulty_chip/ > > (and, this is the public info - please, no one should say that I am > bashing INTEL, I am not) :-) > > Zoran > >

1 0

KGPE-D16: More insights on the PCI hang failure
by Daniel Kulesz 16 Feb '17

16 Feb '17

Hi folks, as we know, the KGPE-D16 is likely to hang during PCI init, especially if the serial console is enabled (Timothy mentioned that he did not observe failures with the debug level of the console lowered - however, for me this did not work). Typical symptoms look like the following: ERROR: PNP: 002e.b 70 irq size: 0x0000000001 not assigned After discussing the issue with Timothy and doing a (huge) number of experiments in different settings I am of the opinion that the issue *does* seem to be memory/clock related. I tried various memory configurations and found some interesting correlations between memory configuration and the rate of failures. Also, I found another trigger which makes the hang *much* more likely. For testing, I used the current coreboot master with the proposed revert which made the MC4 errors go away. After some experimenting, I found two settings which made the PCI-hangs go away: 1. Setting minimum memory voltage to 1.5V (probably unrelated) 2. Setting maximum memory clock down to 400 MHz (DDR3-800 instead of DDR3-1600) With this setting, the number of PCI hangs went considerably down on a number of different configurations (all using two Opteron 6276 CPUs). The numbers are (#hangs / #boot attempts): 1xCK0 (in slot A2): warm (0/8), cold (0/3) => no failures! 1xYK0 (in slot A2): warm (0/6), cold (0/3) => no failures! 8xYK0 (in all orange slots): warm (1/8), cold (1/5) => rare 16xYK0 (in all slots): warm (3/8), cold (1/5) => more likely Specs of the memory modules (all from Samsung): CK0: 8GB DDR3-1600, 1.5V YK0: 8GB DDR3L-1600, 1.35V However, there is one more and quite severe issue: If I set the following option, I am get a hang in like 70% of the boot attempts: Chipset => Enable PCI-E MMCONFIG Support I wouldn't care too much about leaving this disabled. Unfortunately, I am getting a "force reboot" of the Kernel each time it tries to initialize the nouveau driver. Not sure if this is really related to this option or the fact that I'm running the RDIMMs at such low settings, but we'll have to find out. Cheers, Daniel

1 0

ASUS KGPE-D16 Automated Test Failure [master]
by Raptor Engineering Automated Coreboot Test Stand 15 Feb '17

15 Feb '17

The ASUS KGPE-D16 fails verification for branch master as of commit 901efea8abbb3131685fd69fd4ad7c5093c8cb3c The following tests failed: BOOT_FAILURE Commits since last successful test: 901efea libpayload: x86/exec - fix return value passing d42c38b libpayload: x86/exec - fix libpayload API magic value 6abdbcd siemens/mc_apl1: Make basic settings for booting the mainboard See attached log for details This message was automatically generated from Raptor Engineering's ASUS KGPE-D16 test stand Want to test on your own equipment? Check out https://www.raptorengineering.com/content/REACTS/intro.html Raptor Engineering also offers coreboot consulting services! Please visit https://www.raptorengineering.com for more information Please contact Timothy Pearson at Raptor Engineering <tpearson(a)raptorengineering.com> regarding any issues stemming from this notification

2 1

Re: [coreboot] Understand vboot logic to select FW_B
by tturne＠codeaurora.org 15 Feb '17

15 Feb '17

On 2017-02-15 09:45, Aaron Durbin via coreboot wrote: > On Wed, Feb 15, 2017 at 11:38 AM, <tturne(a)codeaurora.org> wrote: >> On 2017-02-15 07:46, Aaron Durbin via coreboot wrote: >>> >>> On Tue, Feb 14, 2017 at 8:26 PM, <tturne(a)codeaurora.org> wrote: >>>> >>>> >>>> Folks, >>>> I'm working on coreboot on ARMv8 architecture and recently attempted >>>> to >>>> verify FW_B can be selected if FW_A is corrupted. >>>> >>>> In reviewing the code-path through coreboot vboot wrapper and >>>> vboot_reference library I'm not understanding the logic. >>>> >>>> The logic appears to be that vboot_reference library determines FW_A >>>> is >>>> corrupt and forces a reboot. >>>> >>>> After reboot, early in verstage_main(), both the NVRAM (flash) and >>>> vb2_context structures are initialized, wiping out any history of >>>> failure >>>> condition. >>>> >>>> I know I must be missing something in my analysis but don't see it. >>>> >>>> Can anybody on this list share their experiences in confirming the >>>> FW_B >>>> boot >>>> path if FW_A is corrupt? >>> >>> >>> >>> ctx->flags & VB2_CONTEXT_FW_SLOT_B determines which slot to use. The >>> vbnv (vboot non-volatile) storage keeps counts for slots to try. >>> vb2_select_fw_slot() will do that work for you. It's located in >>> firmware/2lib/2misc.c. That function is called from >>> vb2api_fw_phase2() >>> in firmware/2lib/2api.c. All this logic lives in vboot_reference >>> code >>> repository. >>> >> >> Thanks for this recap, I had identified most of this path previously. >> >> I can clearly see the corrupted A slot being detected and the status >> updated >> and vboot requesting a reboot. >> The reboot causes verstage to go through its initialization sequence, >> which >> in my case blows away the history of the reboot, so the cycle repeats >> endlessly. >> FW_A slot detected as corrupt reboot requested to boot from FW_B, >> reboot >> blows away this data and FW_A is detected to be corrupt and reboot >> requested, etc. >> >> I have verstage configured to run from bootblock, no DRAM/CBMEM >> available, >> just the RW_NVRAM fmap partition on the flash. >> I haven't made any change in vboot_reference or the coreboot vboot >> wrapper >> layer so for me, out of the box, something is amiss. > > > The try count should drop on each reset. And then it should swap to > slot B. All of our ARMv8 and x86 boards utilize the same path. Have > you ensured your vbnv bindings are working? And dumping the vbnv > contents to the terminal each time might be helpful. I'm not sure what > platform you are running so it's hard to know what configuration and > support files you are including. Do you have serial console logging > enabled? What's it say? > > If you don't have one of these set then you wouldn't be reading any > vbnv -- or saving: > > CONFIG_VBOOT_VBNV_CMOS > CONFIG_VBOOT_VBNV_EC > CONFIG_VBOOT_VBNV_FLASH > > Check out read_vbnv() and save_vbnv() in src/vboot/vbnv.c. CONFIG_VBOOT_VBNV_FLASH is set in our system. I think the key point I was missing before is the vboot reset has to retain vboot bss data. The vbnv_flash variable (static struct vbnv_flash_ctx) has to remain initialized across the reboot. > >> >> I would be interested in hearing from anybody on the list on an ARMv8 >> target >> who has run the same test I'm trying to reproduce here. >> Specifically, I'm not running the test code in vboot_reference, I am >> manually corrupting partition A before flashing it. >> Cheers, >> T.mike >> >> >>> >>>> Cheers, >>>> T.mike >>>> >>>> -- >>>> coreboot mailing list: coreboot(a)coreboot.org >>>> https://www.coreboot.org/mailman/listinfo/coreboot

2 1

Re: [coreboot] KGPE-D16 and Samsung DDR3L memory sticks
by Daniel Kulesz 15 Feb '17

15 Feb '17

Hi folks, after a lengthy bisection run I was able to nail down the commit which is causing the MC4 errors in the configurations I tested. I reverted the commit on top of current master, and now my KGPE-D16 fully works without MC4 errors in both 1-CPU-package und 2-CPU-package configurations - that is, with all 16 memory slots populated with the 8GB DDR3L Samsung RDIMMs (PC12800 variant) mentioned in my initial post. However, the issue with memory clock (being reported at) 667MHz in dmidecode still remains. I submitted a request for reverting the causing commit [1]. Cheers, Daniel [1] https://review.coreboot.org/#/c/18369/

2 2

Re: [coreboot] Understand vboot logic to select FW_B
by tturne＠codeaurora.org 15 Feb '17

15 Feb '17

On 2017-02-15 07:46, Aaron Durbin via coreboot wrote: > On Tue, Feb 14, 2017 at 8:26 PM, <tturne(a)codeaurora.org> wrote: >> >> Folks, >> I'm working on coreboot on ARMv8 architecture and recently attempted >> to >> verify FW_B can be selected if FW_A is corrupted. >> >> In reviewing the code-path through coreboot vboot wrapper and >> vboot_reference library I'm not understanding the logic. >> >> The logic appears to be that vboot_reference library determines FW_A >> is >> corrupt and forces a reboot. >> >> After reboot, early in verstage_main(), both the NVRAM (flash) and >> vb2_context structures are initialized, wiping out any history of >> failure >> condition. >> >> I know I must be missing something in my analysis but don't see it. >> >> Can anybody on this list share their experiences in confirming the >> FW_B boot >> path if FW_A is corrupt? > > > ctx->flags & VB2_CONTEXT_FW_SLOT_B determines which slot to use. The > vbnv (vboot non-volatile) storage keeps counts for slots to try. > vb2_select_fw_slot() will do that work for you. It's located in > firmware/2lib/2misc.c. That function is called from vb2api_fw_phase2() > in firmware/2lib/2api.c. All this logic lives in vboot_reference code > repository. > Thanks for this recap, I had identified most of this path previously. I can clearly see the corrupted A slot being detected and the status updated and vboot requesting a reboot. The reboot causes verstage to go through its initialization sequence, which in my case blows away the history of the reboot, so the cycle repeats endlessly. FW_A slot detected as corrupt reboot requested to boot from FW_B, reboot blows away this data and FW_A is detected to be corrupt and reboot requested, etc. I have verstage configured to run from bootblock, no DRAM/CBMEM available, just the RW_NVRAM fmap partition on the flash. I haven't made any change in vboot_reference or the coreboot vboot wrapper layer so for me, out of the box, something is amiss. I would be interested in hearing from anybody on the list on an ARMv8 target who has run the same test I'm trying to reproduce here. Specifically, I'm not running the test code in vboot_reference, I am manually corrupting partition A before flashing it. Cheers, T.mike > >> Cheers, >> T.mike >> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> https://www.coreboot.org/mailman/listinfo/coreboot

2 1

← Newer
1
...
9
10
11
12
13
14
15
...
22
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 February 2017