July 2020 - coreboot - mail.coreboot.org

How does coreboot support AMD X3421 (Carrizo)?
by Lenny July 9, 2020

July 9, 2020

Dear Madam or Sir, coreboot is so great! I have a HP MicroServer Gen10 with AMD Opteron X3421 (Carrizo) and 16GB ECC memory. Will coreboot work well with my hardware platform? Can I update to coreboot with AFUWIN? Many thanks! Sincerely, Lenny

2 1

Coreboot exception on Kabylake xeon-1505v6 and CM238
by roman perepelitsin July 9, 2020

July 9, 2020

Hi! I'm trying to exec Coreboot (4.12) on custom board. Previously, this board work on 1505v5 (skylake) CPU and coreboot don't have any problems. But after update CPU - I got exception at finalizing step. My 1st patch - change timeout value in mp_park_aps from 1000 to 3000 - no effect. My 2nd patch - I think, that ME didn't work correctly - and I updated it (no effect). My 3rd patch - I use me_cleaner.py to disable ME - but exception still rise. Maybe someone had similar problems on KBL and have some method fix it? Log with ME and without ME in attach. FSP version - latest from intel. P.S. On coreboot 4.7 I have similar exception, but it rised on CPU#0 initializing. Thanks! -- regards, Perepelitsin Roman

1 0

UEFI bios menu
by avinok＠gmail.com July 9, 2020

July 9, 2020

Hi I am a new in coreboot, but spent a some time with Slimboot to make our customized board (based Intel Apollo Lake ) to run. I would like to have a full UEFI BIOS menu, but can't find how can I do that in coreboot Although, as a test environment I have UP2 squared board, and I am able to run coreboot with tianocore payload and boot yocto Is UEFI Bios menu (GUI) is supported in coreboot ? Would you be able to navigate me how to add it ? Andrey

6 6

Issue-Tracker: Unable to reply
by Daniel Kulesz July 8, 2020

July 8, 2020

Hi, I wanted to reply in the Redmine issue tracker to a comment posted by Patrick Georgi [1], however, it seems like I can only open new issues and edit my own issue as well but not comment or reply to comments. At least I don't see any button for that. Is this a general permission issue (regarding roles) or is this specific to my account (kuleszdl) there? Cheers, Daniel [1] https://ticket.coreboot.org/issues/49

2 1

New Defects reported by Coverity Scan for coreboot
by scan-admin＠coverity.com July 7, 2020

July 7, 2020

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 4 new defect(s) introduced to coreboot found with Coverity Scan. 175 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 4 of 4 defect(s) ** CID 1430219: Security best practices violations (SECURE_TEMP) /3rdparty/vboot/host/lib/flashrom.c: 50 in write_temp_file() ________________________________________________________________________________________________________ *** CID 1430219: Security best practices violations (SECURE_TEMP) /3rdparty/vboot/host/lib/flashrom.c: 50 in write_temp_file() 44 vb2_error_t rv; 45 char *path; 46 47 *path_out = NULL; 48 path = strdup(P_tmpdir "/vb2_flashrom.XXXXXX"); 49 >>> CID 1430219: Security best practices violations (SECURE_TEMP) >>> Calling "mkstemp" without securely setting umask first. 50 fd = mkstemp(path); 51 if (fd < 0) { 52 rv = VB2_ERROR_WRITE_FILE_OPEN; 53 goto fail; 54 } 55 ** CID 1430218: Integer handling issues (BAD_SHIFT) /src/ec/google/chromeec/ec.c: 397 in google_chromeec_log_events() ________________________________________________________________________________________________________ *** CID 1430218: Integer handling issues (BAD_SHIFT) /src/ec/google/chromeec/ec.c: 397 in google_chromeec_log_events() 391 392 if (!CONFIG(ELOG)) 393 return; 394 395 events = google_chromeec_get_events_b() & mask; 396 for (i = 0; i < sizeof(events) * 8; i++) { >>> CID 1430218: Integer handling issues (BAD_SHIFT) >>> In expression "1ULL << i - 1", shifting by a negative amount has undefined behavior. The shift amount, "i - 1", is -1. 397 if (EC_HOST_EVENT_MASK(i) & events) 398 elog_add_event_byte(ELOG_TYPE_EC_EVENT, i); 399 } 400 401 google_chromeec_clear_events_b(events); 402 } ** CID 1429776: Memory - corruptions (OVERRUN) ________________________________________________________________________________________________________ *** CID 1429776: Memory - corruptions (OVERRUN) /src/soc/amd/picasso/fsp_params.c: 94 in fsp_fill_pcie_ddi_descriptors() 88 const fsp_ddi_descriptor *fsp_ddi; 89 size_t num_pcie; 90 size_t num_ddi; 91 92 mainboard_get_pcie_ddi_descriptors(&fsp_pcie, &num_pcie, 93 &fsp_ddi, &num_ddi); >>> CID 1429776: Memory - corruptions (OVERRUN) >>> Overrunning callee's array of size 1 by passing argument "num_pcie" (which evaluates to 3) in call to "fill_pcie_descriptors". 94 fill_pcie_descriptors(scfg, fsp_pcie, num_pcie); 95 fill_ddi_descriptors(scfg, fsp_ddi, num_ddi); 96 } 97 98 static void fsp_usb_oem_customization(FSP_S_CONFIG *scfg, 99 const struct soc_amd_picasso_config *cfg) ** CID 1072951: Memory - illegal accesses (BUFFER_SIZE) /tests/lib/string-test.c: 149 in test_strncpy() ________________________________________________________________________________________________________ *** CID 1072951: Memory - illegal accesses (BUFFER_SIZE) /tests/lib/string-test.c: 149 in test_strncpy() 143 /* n1 case */ 144 145 /* Needed for ensuring that characters behind the limit 146 are not overwritten */ 147 memset(dst, 'x', dst_len); 148 >>> CID 1072951: Memory - illegal accesses (BUFFER_SIZE) >>> Calling "strncpy" with a source string whose length (5 chars) is greater than or equal to the size argument (2) will fail to null-terminate "dst". 149 strncpy(dst, src, n1); 150 151 assert_int_equal(0, memcmp(dst, src, n1)); 152 153 for (i = n1; i < dst_len; i++) 154 assert_true(dst[i] == 'x'); ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/ls/click?upn=nJaKvJSIH-2FPAfmty-2BK5tYpPkl…

1 0

Address sanitizer - new feature in the scope of GSoC 2020
by werner.zeh＠siemens.com July 7, 2020

July 7, 2020

Dear coreboot community. A few of you may already have noticed that one of this years GSoC projects coreboot hosts is the adding of "Address Sanitizer" feature to our code base. This project has been taken by Harshit Sharma and he has spent the first period of coding on adding the needed code and enabling this feature for our ramstage on x86 platform. So far Harshit was very productive and the outcome of this first period is a working feature for ramstage that you can find in the patches [1]...[4]. Though these patches are not finally cleaned up yet they are good enough for first test and reviews. I did a first test by enabling this feature on mc_apl3. So far it looks good to me: The code is compliable (no surprise since Jenkins has proven that already) and it runs in qemu and real hardware (Apollo Lake based mc_apl3). I introduced a few out-of-bounds errors in mainboard_init() and mainboard_final() to test this feature and ASAN was able to detect both of them. I was surprised by the very low runtime overhead ASAN has introduced in my case, I would have expected more. I have attached the timestamps I have gathered with and without ASAN during my tests (with console log level ERR) so that you can have a look. In the case where an error has been caught by ASAN the log looks like the following snippet (this is the error I introduced in mainboard_final): ASan: stack-out-of-bounds in 0x7ab30c03 Write of 1 byte at addr 0x7ab90ef6 ASan: stack-out-of-bounds in 0x7ab30c03 Write of 1 byte at addr 0x7ab90ef5 ASan: stack-out-of-bounds in 0x7ab30c03 Write of 1 byte at addr 0x7ab90ef4 ASan: stack-out-of-bounds in 0x7ab30c03 Write of 1 byte at addr 0x7ab90ef3 I hope I was able to depict the current status Harshit have achieved in his first coding period. The second aim of my message is to encourage you to test this feature on your hardware to get a better test coverage and review the code. So you have a test lab with multiple PCs and laptops under your control: perfectly, please give this feature a try and see what it does on your diverse hardware. Or you just own a single mainboard which runs on coreboot and you have a way to program it properly: fine, too. Go ahead and pull in the patches. Wait, you do not own a proper hardware or don't have access to it right now: OK, there is still a way how you can help. Take a look at the patches and provide a review. The broader the feedback will be for this brand new feature the better we can ensure it has a high quality and holds what it promises. The next steps for the ASAN feature Harshit will work on will be support in romstage. Since romstage by nature have a very limited amount of RAM to use and this even varies from platform to platform, the enablement will take place now for just a few dedicated platforms (the ones Harshit and I have access to for test purposes). We though hope to design this feature as generic as possible so that further platforms can be added easily. Again, please help Harshit to get a broad test coverage and a wide code review so that we all will have a high quality feature in our code base. Thank you in advance for the support. Werner [1] https://review.coreboot.org/c/coreboot/+/42271 [2] https://review.coreboot.org/c/coreboot/+/42794 [3] https://review.coreboot.org/c/coreboot/+/43164 [4] https://review.coreboot.org/c/coreboot/+/42496

1 0

Booting Linux kernel with nosmp required on Lenovo T60 (ATI/AMD)
by Paul Menzel July 6, 2020

July 6, 2020

Dear coreboot folks, On the Lenovo T60 (with AMD/ATI graphics) the Linux kernel (4.9, 4.19, 5.3, 5.4) hangs after starting user space. As SeaBIOS, GRUB, payloads and FreeDOS work, I tried to limit the number of CPUs, and booting Linux with `nosmp` gave me a booting system. It worked with older coreboot versions, so I think it’s a regression. I am able to reproduce this with coreboot 4.11 and 4.11-422-g1a5c3bb7fa. Is somebody else seeing this issue? Maybe on some i945 desktop board, so it would be easier to bisect? Kind regards, Paul

3 5

Language matters
by Patrick Georgi July 6, 2020

July 6, 2020

Hi everybody, in last Wednesdays' leadership meeting we've been discussing how to deal with language in our code and community. I offered to report on our results and to start the wider discussion and so that's the aim of this email. You might have heard about calls to avoid certain terminology in tech. For those who haven't heard, here's a short re-cap: tech uses terminology like "slave" (in conjunction with "master") with little thought about the impact the non-tech interpretations of such terms can have for some people. The issue isn't exactly new, some open source projects retired the use of certain words years ago, but in light of recent developments (Black Lives Matter and all that) the topic has been brought up again. Since it's usually possible to find other terms to describe the same fact that come with no (or less) historical baggage, and often even _better_ terms, the proposal is to move away from troublesome words in favor of more neutral ones. In some cases such proposals don't come across as proposals (but rather as pretty forceful demands) and some of these debates ended badly, both things that we'd like to avoid. We discussed an approach at the leadership meeting and hope that it's nuanced enough to achieve a code base and community where people of all stripes can contribute and not run into stumbling blocks that make them feel not welcome, while also not making people feel like they're having to watch their words. So first and foremost, this isn't about playing some blame game. Words have been used and will be used while not taking into account the impact they may have on others, and as long as there's no bad intent, let's try to be gracious about it, point out where things go wrong, and on the receiving end, strive to improve. Overall I think this community did pretty well on that, and so I don't see a big issue with us continuing to do that. Second: This exercise isn't about achieving world peace by eliminating bad language or anything similar grandiose, obtuse or nonsensical. It's about ensuring that coreboot is one of those open source projects about which people, no matter their background, say that it's a pleasure to work with. From what I've heard people say after coming in to coreboot with experience from other firmware projects, we probably achieved that on the technical side (although there's always room to improve) but there's more than just technical merit. With that out of the way, here's what we came up with: There's a set of words that we'd try to avoid, and that set can grow over time as we identify terminology that is picked up badly by some. Not all such terms are equally bad, and that can certainly inform our approach with them. For now, we've identified "slave", "master", "black list", and "white list". "slave": There has been no contest in the meeting that this term carries _lots_ of baggage, and that we should look for alternatives. "master": This is troublesome due to its connection to "slave", but there are also different meanings of the term, some decidely positive (what's bad about being a "master of your trade"?), so it's probably the poster child of "not equally bad". "black list": These lists typically aren't "black", neither are the objects on these lists. I'd dare to say that they come in no color or at most in whatever color your text editor uses. I'd like to think that there's a better adjective for any given list to describe its purpose. "white list": The opposite to the "black list", with the same rationale. We even have an example for a descriptive rename for that in the tree: Duncan renamed some white list into "allow list", which is more descriptive for that particular use case while avoiding the blanket term. That doesn't mean that all white lists should become allow lists: Be descriptive and consider what best describes the object you're (re)naming. The way we want to proceed with such terms depends on the context: 1. Some internal representation within coreboot that's called "master" and "slave" could be renamed without confusing anybody and that's what we should do there. Luckily, we don't typically deal with multiple coordinating entities, so these specific terms aren't very widely used to describe actors within coreboot. A counter example is the Gerrit project that's developing our code review platform, and they have a much harder time with these specific words. For things in this category we'd propose that you think twice before using them (and if you're comfortable doing so, that you start a discussion when you see them during code review.) Again, such a discussion is not about assigning blame or creating any bad outcomes for your fellow developers, but to ensure a consistent style in our code. If something slips through, we can clean up later - it's the same approach we take with technical problems in our code. There needn't be a huge "stop the world, we'll purge the tree" event to get the code base into a certain form, but it's not verboten, either (except for the "stop the world" part - I don't think that would end well.) 2. Some terms are taken directly from standards or interfaces we deal with. We can't change the fact that JEDEC talks about SPI "masters" and "slaves", and changing them in our source code would only make readers do a double take, which even puts a spotlight on the very things we wanted to de-emphasize. It may be possible to hide such terms in abbreviations (talk about MOSI, not master-out-slave-in, which I think we already do,) but other than that, such instances are here to stay until JEDEC and the other sources of interface definitions reconsider - in which case we'd follow, to avoid confusion. 3. And then there's "master" as in "master branch" on git. There's no "slave" associated with it, so that's much less pressing, but there appears to be talk across the git developer (and user) communities to retire that name, with some preference emerging to use "main" as a replacement. I pitched the idea to the Gerrit developers to support branch aliases, to that "main" and "master" could point to the same branch transparently, with support for refs/for/master and all the other little places where branch names appear in git and Gerrit. They seem to have taken the idea pretty well and I expect that to eventually exist. Once Gerrit supports such branch aliases, we could rename master as main but at the same time establish the alias to ensure that we don't break any workflows. Please consider the proposal and the approach outlined here. Discuss, remain friendly and charitable. The issues that sparked this debate are, to a certain degree, specific to the USA, and if you're not living there it may seem to you that all this doesn't apply to you. Fact is that the language we're usually using to communicate here, on the list, IRC, code comments, and so on, is English, and the USA is a rather large part of the anglophone community. Therefore, when it comes to the English language, whatever happens there will also influence this project and there's little we can do about it. If you're flat-out opposed to retire words from active circulation, I'd like to know why. I prepared a good share of this initiative, and I've heard the position of those who stumble over words like the ones listed above and I've taken that into account. In the same way I'm interested in learning about your view on the matter. Due to the sensitive nature of such statements (as in: it may well be flame war material and our mailing list isn't exactly secret), please contact me directly about this, not through the list. I won't share any statements made to me (as far as the law allows), nor their authors, although I may try to compile an anonymized cohesive set of arguments to present the case if there's a need. Thanks, 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

Lenovo X1 Carboon touchscreen
by Christopher Intemann July 5, 2020

July 5, 2020

Hi, according to https://www.coreboot.org/Board:lenovo/x1_carbon_gen1 the X1 carbon gen1 is mostly supported. However, there is no mention about the touchscreen version. Is it possible to install coreboout on the touchscreen version and does the touchscreen work with coreboot? Thank you, Chris

1 0

Unable to clone all the repository of Coreboot for development
by NJONGDSI KOUAM Esaïe Ledoux July 3, 2020

July 3, 2020

Hey , good afternoon everybody ,... i have kali linux system and i want to clone the repository Coreboot , ... The problem is that i have don't receive all the files , some files doesn't dowload because of bad argument of some file. git clone https://review.coreboot.org/coreboot coreboot Clonage dans 'coreboot'... remote: Counting objects: 637, done remote: Finding sources: 100% (623/623) remote: Total 553974 (delta 86), reused 553737 (delta 86) Réception d'objets: 100% (553974/553974), 142.97 Mio | 1.51 Mio/s, fait. Résolution des deltas: 100% (421681/421681), fait. fatal: cannot create directory at 'src/drivers/intel/pmc_mux/con': Argument invalide warning: Le clone a réussi, mais l'extraction a échoué. Vous pouvez inspecter ce qui a été extrait avec 'git status' et réessayer avec 'git restore --source=HEAD :/' please i need help to continue ... thank you

1 0