coreboot January 2020

coreboot@coreboot.org

44 participants
44 discussions

[RFT] Linux fails to detect devices on AGESA board with `nosmp`
by Paul Menzel 28 Jan '20

28 Jan '20

Dear coreboot folks, My coreboot test S-ATA hard disk had `nosmp` on the Linux command line configured so that Linux boots on the Lenovo T60. Now, testing this on the AGESA board ASRock E350M1, Linux failed to detect the disk (/dev/sda), and was unable to boot (USB and AHCI devices got error -22). Removing `nosmp` from the command line made it boot. Using GRUB or SeaBIOS as payload didn’t make a difference, and the old coreboot image I had (before switching to C environment bootblock) *does* have the *same* problem, so the bug is there longer. It’s reproducible with Linux 4.16.x and Linux 5.4.x. It’s not reproducible on the Lenovo T60 (other way around), and QEMU i440fx and Q35. It’d be great, if you could test this on your coreboot boards, and report back. Adding `nosmp` to the Linux kernel command line, for example, by pressing e in the GRUB menu (and then Ctrl + x or F10 to boot) should be all that is needed. Kind regards, Paul

5 5

Significant slowdown for asus/p2b-* boards after moving to C environment bootblock
by Keith Hui 27 Jan '20

27 Jan '20

Earlier this month Paul reached out to me in private and asked me about a few of my board status uploads. We collectively noticed the romstage now takes significantly longer to the tune of 1.5 seconds. We were not quite sure where the problem was because I also tried reverting to romcc bootblock and I didn't see much improvement. Now that I have timestamps in i440bx ram init, I ran the tests again, and here are the results. (This time my board status is not uploading correctly...) With serial console: 0:1st timestamp 741 11:start of bootblock 4,763 (4,021) 12:end of bootblock 4,980 (216) 13:starting to load romstage 6,127 (1,146) 14:finished loading romstage 6,269 (142) 1:start of romstage 6,724 (454) 2:before ram initialization 500,006 (493,282) 3:after ram initialization 670,733 (170,726) 4:end of romstage 2,189,924 (1,519,190) 100:start of postcar 2,311,060 (121,136) 101:end of postcar 2,311,061 (0) 8:starting to load ramstage 2,318,690 (7,629) 15:starting LZMA decompress (ignore for x86) 2,322,877 (4,187) 16:finished LZMA decompress (ignore for x86) 2,361,147 (38,269) 9:finished loading ramstage 2,369,966 (8,818) 10:start of ramstage 2,381,486 (11,519) 30:device enumeration 2,381,490 (4) 40:device configuration 2,447,811 (66,321) 50:device enable 2,649,524 (201,713) 60:device initialization 2,672,956 (23,431) 65:Option ROM initialization 2,819,134 (146,178) 66:Option ROM copy done 2,895,605 (76,471) 67:Option ROM run done 3,249,285 (353,679) 70:device setup done 3,283,763 (34,478) 75:cbmem post 3,287,313 (3,550) 80:write tables 3,287,315 (1) 85:finalize chips 3,427,717 (140,401) 90:load payload 3,431,452 (3,735) 15:starting LZMA decompress (ignore for x86) 3,460,849 (29,396) 16:finished LZMA decompress (ignore for x86) 3,517,611 (56,762) 99:selfboot jump 3,528,778 (11,167) Total Time: 3,528,022 Without serial console: 0:1st timestamp 742 11:start of bootblock 4,763 (4,021) 12:end of bootblock 4,980 (216) 13:starting to load romstage 6,127 (1,146) 14:finished loading romstage 6,269 (142) 1:start of romstage 6,742 (472) 2:before ram initialization 315,196 (308,454) 3:after ram initialization 486,614 (171,417) 4:end of romstage 1,650,976 (1,164,362) 100:start of postcar 1,722,827 (71,851) 101:end of postcar 1,722,828 (0) 8:starting to load ramstage 1,722,929 (101) 15:starting LZMA decompress (ignore for x86) 1,722,952 (22) 16:finished LZMA decompress (ignore for x86) 1,761,057 (38,105) 9:finished loading ramstage 1,761,177 (119) 10:start of ramstage 1,762,626 (1,449) 30:device enumeration 1,762,631 (4) 40:device configuration 1,762,816 (185) 50:device enable 1,763,445 (628) 60:device initialization 1,763,542 (97) 65:Option ROM initialization 1,764,321 (778) 66:Option ROM copy done 1,826,366 (62,045) 67:Option ROM run done 2,175,483 (349,116) 70:device setup done 2,175,535 (52) 75:cbmem post 2,175,537 (1) 80:write tables 2,175,539 (2) 85:finalize chips 2,179,763 (4,223) 90:load payload 2,179,768 (5) 15:starting LZMA decompress (ignore for x86) 2,179,995 (226) 16:finished LZMA decompress (ignore for x86) 2,236,000 (56,005) 99:selfboot jump 2,236,034 (33) Total Time: 2,235,277 --- So much of the slowdown between after raminit and end of romstage. romstage also spent significant time before entering i440bx raminit. Since this is outside my area, I'll defer to the masters here. Thanks Keith

1 0

ME extracted from vendor BIOS update?
by Mogens Jensen 26 Jan '20

26 Jan '20

When compiling coreboot for my Intense PC, I used binary blobs extracted from stock firmware. The ME/TXE firmware version is 8.1.20.1336 and this contains multiple security vulnerabilities. Unfortunately, running me_cleaner on ME blob breaks SATA [1], so next best thing is updating to latest ME blob released by CompuLab. However, this seems not so straight forward. Latest BIOS update for Intense PC was downloaded from here: https://fit-iot.com/files/download/intense-pc/bios/16-04-2018/ipc_2.2.400.5… I unpacked and mounted the image like this: # mount -o loop,offset=16384 ipc_2.2.400.5.img /mnt/ This is the interesting files found in /mnt/ afterwards: 81723002.ME (7843840 bytes) BIOS_IMG.bin (16777216 bytes) I tried to extract intel fd modules from BIOS_IMG.bin: $ ifdtool -x BIOS_IMG.bin File BIOS_IMG.bin is 16777216 bytes Flash Region 0 (Flash Descriptor): 00000000 - 00000fff Flash Region 1 (BIOS): 00d00000 - 00ffffff Flash Region 2 (Intel ME): 00003000 - 00cfffff Flash Region 3 (GbE): 00001000 - 00002fff Flash Region 4 (Platform Data): 00fff000 - 00000fff (unused) However flashregion_2_intel_me.bin is just an empty file and the ME data is in 81723002.ME: $ hexdump flashregion_2_intel_me.bin 0000000 0000 0000 0000 0000 0000 0000 0000 0000 * 0cfd000 $ me_cleaner.py --check 81723002.ME ME/TXE image detected Found FPT header at 0x10 Found 23 partition(s) Found FTPR header: FTPR partition spans from 0x180000 to 0x24a000 ME/TXE firmware version 8.1.72.3002 Public key match: Intel ME, firmware versions 7.x.x.x, 8.x.x.x Checking the FTPR RSA signature... VALID Setting location of 81723002.ME in CONFIG_ME_BIN_PATH during configuration of coreboot seems not to work. Another important thing I found in coreboot documentation: "Warning: Sandybridge Chipsets need a matching ME blob and IFD ! The board won't boot at all if one of them is invalid." So if I understand correctly, I have to compile coreboot with the following files extracted from ipc_2.2.400.5.img: flashregion_0_flashdescriptor.bin flashregion_2_intel_me.bin 81723002.ME The flashregion_3_gbe.bin extracted from stock firmware, also used when compiling coreboot the first time. Does this sound right? Also, what is the correct way to convert 81723002.ME into the proper flashregion_2_intel_me.bin? Thanks in advance! Regards, Mogens Jensen [1]: https://github.com/corna/me_cleaner/issues/119

3 4

Need suggestions for SPI flash programmer, setting up to begin P8Z77-M port
by Keith Hui 26 Jan '20

26 Jan '20

Hi list, Seeing that my beloved i440BX platform will not support enough memory to run Windows 10, and with 7 EOLed, its days are numbered even though I enjoyed working on a blob-free platform. I am now setting myself up for porting coreboot to my P8Z77-M board, where a close cousin is already in the tree. First, I need a 8MB SPI flash chip. I picked up a two W25Q64JVSSIM from Digikey and some adapter as well since they don't carry any in DIP form anymore. :( I mounted one and it seems to physically work. It wasn't supported in flashrom yet, so I sent a patch there as well [1], flagged as untested, because an issue I'll get to later, and my reason for this email. Next, I need a SPI flash programmer. I'm trying to avoid making major purchases. The most handy thing I have is a 5V Arduino Mega 2560 r3, so I loaded frser-duino on it, and HoodLoader2 on its 16u2 for the fast USB. I also picked up a level shifter module [2] because the chips are 3.3V. When I wired up everything on a breadboard with the board's original chip it reads fine and I was actually able to save a backup of its contents. Of course I then wanted to build something that I can just plug the chip in and go, as I will need to use it quite often. I wired the level shifter and a DIP socket on a XBee shield (because it has a 3.3V regulator and a proto area), but it's not detecting the chip. I then reverted to the breadboard, this time using 3 resistor dividers for level shifting because the level shifter's legs are now soldered on the shield. I read the (still virgin) chip 3 times, and saw the read bytes periodically goes to 0x00 instead of being all 0xff, as expected from an unprogrammed chip. The connection is not working right. What else can I try? If I can't get this serprog-on-an-arduino setup working, what is my next best setup I can use? [1] https://review.coreboot.org/c/flashrom/+/38578 [2] https://www.velleman.eu/products/view/?id=435578

2 1

AGESA versions of fam15h/fam16h? Version string is v0.001
by Mike Banon 25 Jan '20

25 Jan '20

If you know, please tell the AGESA versions of fam15h/fam16h AMD vendorcode. For fam14h it is v1.103 - so no questions - but for fam15h and fam16h it says v0.001: #define AGESA_VERSION_STRING {'V', '0', '.', '0', '.', '0', '.', '1', ' ', ' ', ' ', ' '} Also, I wonder if there's an AGESA changelog somewhere, to learn if any security vulnerabilities or bugs have been fixed since AMD has shared some AGESA revision with coreboot. If these problems are serious enough, I could try to ask AMD to share the latest AGESA code available for these platforms.

3 2

OSFC videos
by Alexander 'lynxis' Couzens 23 Jan '20

23 Jan '20

Hey, is there a way to get the OSFC videos more directly? E.g. I would like to download them as a bunch. youtube is quite limited here. I perfectly understand, why it's on youtube, however having them as simple download similiar to https:// with index or plain old ftp would be nice! * Best, lynxis * similiar to https://media.ccc.de/ -- Alexander Couzens mail: lynxis(a)fe80.eu jabber: lynxis(a)fe80.eu gpg: 390D CF78 8BF9 AA50 4F8F F1E2 C29E 9DA6 A0DF 8604

3 3

Memory mapped IO UART for seabios sercon-port
by john brown 23 Jan '20

23 Jan '20

1 0

How can My linux kernel detect gpio or pinctrl on denverton platform ?
by cooljason0404＠gmail.com 20 Jan '20

20 Jan '20

Hi, Linux kernel- 4.14. confing debug gpio and pinctrl-denverton, pinctrl-intel. Coreboot-4.10 using denverton and harcuvar. However, linux kernel not dectect gpio and pinctrl. Thanks. Jason

3 2

SuzyQable - ChromeOS Debug Cable
by Gregg Levine 18 Jan '20

18 Jan '20

Hello! Does the thing at https://www.sparkfun.com/products/14746 create a response with regards to anyone? On their documents tab they present the now wrong link where to find more information about how the cable works. And of course they also link to those devices that might be interested in working with it. Call me curious, but I'm interested in seeing how many of us recognize the unique nature of it. ----- Gregg C Levine gregg.drwho8(a)gmail.com "This signature fought the Time Wars, time and again."

3 4

A Hardware enthusiast view on the usefulness of open source Firmwares like Coreboot
by zir_blazer＠hotmail.com 17 Jan '20

17 Jan '20

Here it is: https://zirblazer.github.io/htmlfiles/coreboot.html?ver=123 I took my time to write the linked Wall of Text® with the purpose of educating/influencing Hardware enthusiasts communities about the need to push for open source Firmwares, and perhaps with even more luck, Motherboards for x86 platforms with open Hardware designs. These are my personal thoughts and nearly all the input I have on this matter. You will notice that there is a major difference regarding my approach and nearly everyone else that you have read talking about this matter previously. I'm not of the "INTEL ME/AMD PSP VIOLATES MY PRIVACY!1!1!1" and "THE NSA AND USA GOVERMENT ARE SPYING ON ME!" crowd. I have an actual agenda regarding functional issues where I think that an open source Firmware could kick propietary Firmware butt, and I cover it with enough detail as to drive that point. Sadly, after having spammed it around for two weeks, I got almost no feedback. I found that extremely dissapointing, as I believe that Hardware enthusiasts are perhaps the widest audience that would love to be able to freely tinker with the Firmware. I have been personally affected with Firmware related bugs, limitations or issues on all the computers I built for myself, so I fail to understand why there isn't far more people from these communities attemping to push an open source Firmware as a major Motherboard feature, more so considering how used we are to see Motherboard manufacturers failing to give the expected level of support for their products. So, when you do hit these Firmware issues, is like headbutting a solid brick wall.

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot January 2020