April 2018 - coreboot - mail.coreboot.org

Re: [coreboot] [URGENT] Full List of AMD-based boards that are going to be removed from coreboot unless people cough up a board status update
by Raphaël Jacquot April 30, 2018

April 30, 2018

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

2 1

Why do we have FSP-S
by Nico Huber April 30, 2018

April 30, 2018

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 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? 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. 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. 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% 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. 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/

3 2

Thinkpad X230, Coreboot 4.7 + SeaBIOS 1.11.0 flashing, memtest86+ 5.01, fancontrol and WoL
by Jan Malakhovski April 29, 2018

April 29, 2018

Hi. # Primary TOC * Thinkpad X230 seems to be a fairly common target for coreboot, but I though that another recent success report wouldn't hurt. * Flashing with "WoL on AC" trick (missing on the wiki). * Failure report on using Debian's memtest86+ and success report on using coreboot's memtest86+. * The laptop also overheats while running memtest86+ with coreboot (but not vendor BIOS) which, I think, is a bug/missing feature in coreboot. * There's also a Wake on LAN issue/question. # The Success Report I flashed Thinkpad X230 with Coreboot tagged 4.7 (fd470f7163709c1022ee6185134a2387812774ec) with a config that has the following diff from the default 4.7 X230 config (made by `cat configs/builder/config.lenovo_x230 > .config ; make menuconfig` followed by <ESC><ESC><RET>): --- config.x230.v4.7.def +++ config.x230.v4.7.my @@ -11,7 +11,7 @@ CONFIG_CBFS_PREFIX="fallback" CONFIG_COMPILER_GCC=y # CONFIG_COMPILER_LLVM_CLANG is not set -# CONFIG_ANY_TOOLCHAIN is not set +CONFIG_ANY_TOOLCHAIN=y # CONFIG_CCACHE is not set # CONFIG_FMD_GENPARSER is not set # CONFIG_UTIL_GENPARSER is not set @@ -112,6 +112,7 @@ CONFIG_MAX_CPUS=8 CONFIG_CACHE_ROM_SIZE_OVERRIDE=0x0 CONFIG_CBFS_SIZE=0x100000 +CONFIG_PAYLOAD_CONFIGFILE="" CONFIG_VGA_BIOS_ID="8086,0166" CONFIG_ONBOARD_VGA_IS_PRIMARY=y CONFIG_DIMM_SPD_SIZE=256 @@ -136,8 +137,8 @@ CONFIG_FMDFILE="" CONFIG_PRERAM_CBMEM_CONSOLE_SIZE=0xc00 # CONFIG_DRIVERS_UART_8250IO is not set -CONFIG_IFD_BIN_PATH="site-local/descriptor.bin" -CONFIG_ME_BIN_PATH="site-local/me.bin" +CONFIG_IFD_BIN_PATH="site-local/flashregion_0_flashdescriptor.bin" +CONFIG_ME_BIN_PATH="site-local/flashregion_2_intel_me.bin" # CONFIG_BOARD_LENOVO_G505S is not set # CONFIG_BOARD_LENOVO_L520 is not set # CONFIG_BOARD_LENOVO_R400 is not set @@ -338,6 +339,7 @@ # CONFIG_EC_ACPI=y CONFIG_EC_LENOVO_H8=y +CONFIG_SEABIOS_PS2_TIMEOUT=3000 CONFIG_H8_BEEP_ON_DEATH=y CONFIG_H8_FLASH_LEDS_ON_DEATH=y # CONFIG_H8_SUPPORT_BT_ON_WIFI is not set @@ -348,9 +350,9 @@ # Intel Firmware # # CONFIG_EM100 is not set -# CONFIG_CHECK_ME is not set +CONFIG_CHECK_ME=y # CONFIG_USE_ME_CLEANER is not set -CONFIG_GBE_BIN_PATH="site-local/gbe.bin" +CONFIG_GBE_BIN_PATH="site-local/flashregion_3_gbe.bin" # CONFIG_HAVE_EC_BIN is not set # CONFIG_MAINBOARD_HAS_CHROMEOS is not set # CONFIG_GOOGLE_SMBIOS_MAINBOARD_VERSION is not set @@ -621,17 +623,31 @@ # # Payload # -CONFIG_PAYLOAD_NONE=y +# CONFIG_PAYLOAD_NONE is not set # CONFIG_PAYLOAD_ELF is not set # CONFIG_PAYLOAD_BAYOU is not set # CONFIG_PAYLOAD_FILO is not set # CONFIG_PAYLOAD_GRUB2 is not set -# CONFIG_PAYLOAD_SEABIOS is not set +CONFIG_PAYLOAD_SEABIOS=y # CONFIG_PAYLOAD_UBOOT is not set # CONFIG_PAYLOAD_LINUX is not set # CONFIG_PAYLOAD_TIANOCORE is not set +CONFIG_PAYLOAD_FILE="payloads/external/SeaBIOS/seabios/out/bios.bin.elf" +CONFIG_SEABIOS_STABLE=y +# CONFIG_SEABIOS_MASTER is not set +# CONFIG_SEABIOS_REVISION is not set +# CONFIG_SEABIOS_THREAD_OPTIONROMS is not set +CONFIG_SEABIOS_VGA_COREBOOT=y +CONFIG_SEABIOS_BOOTORDER_FILE="" +CONFIG_PAYLOAD_VGABIOS_FILE="payloads/external/SeaBIOS/seabios/out/vgabios.bin" +CONFIG_SEABIOS_DEBUG_LEVEL=-1 + +# +# Using default SeaBIOS log level +# CONFIG_PAYLOAD_OPTIONS="" # CONFIG_PXE is not set +CONFIG_COMPRESSED_PAYLOAD_LZMA=y # CONFIG_PAYLOAD_IS_FLAT_BINARY is not set You should probably ignore CONFIG_ANY_TOOLCHAIN=y since I simply built gcc 6.3 with coreboot patches via nix package manager and then built coreboot using that, so I'm using exactly the same compiler, only packaged via nix (because it was simpler for me this way). # Flashing with "WoL on AC" trick A couple of words on reading/flashing X230's SPI Neither Raspberry Pi 3 B+, nor Beagle Bone Black can supply enough power to feed the MX chips to the board, so the wiki https://www.coreboot.org/Board:lenovo/x230 both recommends an external power supply and warns against using it at the same time (as it can brick the board). But there's a much simpler and safer method described in https://www.bios-mods.com/forum/Thread-REQUEST-Lenovo-Thinkpad-X230-Whiteli… and https://www.bios-mods.com/forum/Thread-REQUEST-Lenovo-Thinkpad-X230-Whiteli… that doesn't require an external power supply. In short: enable Wake On Lan on AC power in Lenovo BIOS, disconnect AC and battery, insert live Ethernet cable, connect AC, Ethernet port should go live (LEDs). Connect your external programmer _but leave VCC/3.3V line disconnected_ (i.e. connect all the data lines and the ground, but not the VCC). The Ethernet port is on the same power line as MX chips, hence flashing with RPi/BBB with VCC disconnected will work as with older models. The only difference with older models is that you have to cut coreboot.rom into 8M and 4M pieces and flash them separately. (You can flash the top 4M only, but then, apparently, you wouldn't be able to reflash the ME region internally). The system boots ok into Linux, VGA seems to work, suspend-resume works. # The whole process Set WoL on AC in Lenovo BIOS. Exit saving changes. Disconnect battery and AC (charger). Insert live Ethernet cable into laptop's Ethernet port. Connect AC. Confirm Ethernet LEDs blink but the screen stays blank, the fan is off and the laptop does not start booting (if it does you have "power-on on AC connect" or whatever enabled in vendor BIOS, disable, save and repeat). Disconnect everything. Remove keyboard, palm rest. I removed the hard disk too, just in case. Short flasher's (RPi/BBB/etc) and laptop's grounds (any metal part of the laptop, e.g. extension card bracket, will do). Connect the flasher's clip without the VCC line to the top SPI chip. Insert live Ethernet cable into laptop's Ethernet port. Connect AC. Confirm Ethernet LEDs blink. So you attached the flasher without VCC to the top SPI chip. Confirm flashrom sees the chip. $ flashrom -p linux_spi:dev=/dev/spidev0.0 Read the flash (chip model may vary, but the chip should be 4M). $ flashrom -c 'MX25L3206E/MX25L3208E' -p linux_spi:dev=/dev/spidev0.0 -r top.rom Repeat, diff/checksum. Reattach to the bottom chip. $ flashrom -c "MX25L6406E/MX25L6408E" -p linux_spi:dev=/dev/spidev0.0 -r bottom.rom Repeat, diff/checksum. $ cat bottom.rom top.rom > full.rom $ mv full.rom /path/to/site-local $ cd /path/to/coreboot/site-local $ ifdtool -x full.rom # to extract flashregion_* blobs $ cd .. $ make distclean $ cat config.x230.v4.7.my > .config $ make # build $ mv build/coreboot.rom site-local $ cd site-local $ diff -Nua <(hexdump -C full.rom) <(hexdump -C coreboot.rom) | less # zsh syntax To confirm that only about 4 or so bytes change in the IFD header (`make` does `ifdtool -u` automagically) in the first 8M and everything changes in the last 4M. $ dd if=coreboot.rom of=to_flash.bottom.rom bs=1M count=8 $ dd if=coreboot.rom of=to_flash.top.rom bs=1M skip=8 $ mv to_flash* /path/to/flasher Still attached to the bottom chip. $ flashrom -c "MX25L6406E/MX25L6408E" -p linux_spi:dev=/dev/spidev0.0 -w to_flash.bottom.rom Reattach to the top chip. $ flashrom -c 'MX25L3206E/MX25L3208E' -p linux_spi:dev=/dev/spidev0.0 -r to_flash.top.rom Done. Disconnect the flasher. Disconnect the AC. Attach the keyboard. Attach some bootable drive (HDD/SDD/USB). Connect AC. Press power button. It should boot. Worked like a charm for me. # Memtest86+ The problem was with running distro-supplied (equivalent to Debian's) memtest86+. The laptop has a single 4G stick of RAM. When running memtest86+ under vendor BIOS memtest86+ reports no errors after 24h of testing. Under coreboot and seabios memtest86+ starts as normal and draws its blue testing screen to the LVDS as expected, but 1) it reports a lot more memory (~300M or so) compared to running under vendor BIOS, 2) it immediately fails on test #2 with a bunch of errors at 000bfe8eXXX (which is around 3070.8M, XXX changes between runs), with bits in error mask 000000XX (XX changes too), 3) some tests make the screen flicker with black lines on some runs. PaulePanter on IRC suggested applying patches from https://review.coreboot.org/memtest86plus and that version then works as expected. But I looked through the changes and I don't understand why exactly the Debian's memtest86+ fails with such strange errors. Does coreboot/seabios report VGA memory region in some non-standard way? # Memtest86+ overheating issue The machine overheats while running memtest86+. People on IRC suggest that this is because coreboot has no fan control in SMM. Placing the laptop into a cold room "fixes" it, but SMM fan control would be nice to have. # Wake on LAN issue/question After flashing coreboot I expected "Wake on Lan on AC connect" to stop working since it was configured in vendor BIOS, but it still works. Why? What code enables it? Can I disable it? How? Also, does WoL need the GBE/ME blobs to work? It is kinda useful that it still works with coreboot since and I can now reflash with impunity using the same WoL method if I brick the ROM. But I want to know if I would be able to clean the ME region and wipe the GBE region (and use USB Ethernet instead) and still use the WoL trick for flashing. Cheers, Jan

3 6

Re: [coreboot] [RFH] Status of the Lenovo X201
by Nicola Corna April 29, 2018

April 29, 2018

April 28, 2018 5:40 PM, "Kyösti Mälkki" <kyosti.malkki(a)gmail.com> wrote: > I thought I had seen some other message [1] on the list regarding > X201(i) not booting or resuming. Looking at your boot log ending on > "0:1f.0 final", it appears we are looking at the same commit which > adds INTEL_CHIPSET_LOCKDOWN implementation in lpc_final(). The commit > message tells it was not tested for ibexpeak so you may want to try > revert that one before going for full bisect. > > [1] https://mail.coreboot.org/pipermail/coreboot/2018-April/086564.html > [2] https://review.coreboot.org/c/coreboot/+/21129 > > Kyösti You're right, that's the broken commit, see attached logs. 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

2 1

Re: [coreboot] [RFH] Status of the Lenovo X201
by Nico Huber April 28, 2018

April 28, 2018

On 28.04.2018 17:34, Kyösti Mälkki wrote: > On Sat, Apr 28, 2018 at 3:41 PM, Nicola Corna <nicola(a)corna.info> wrote: >> April 27, 2018 12:29 PM, "Nicola Corna" <nicola(a)corna.info> wrote: >> >>>> With config PARALLEL_CPU_INIT=y so SMP / SMM init in initialize_cpus() >>>> will never call wait_other_cpus() at all. That actually regressed in >>>> my commit 0cc2ce4 [1] but I can't test if reverting it solves this for >>>> you. I'll push a regression fix soonish for review. >>>> >>>> [1] https://review.coreboot.org/c/coreboot/+/21088 >>>> >>>> Kyösti >>> >>> I'm going to test https://review.coreboot.org/#/c/coreboot/+/25874 soon and >>> report back, thanks for your help. >> >> Unfortunately that patch dont't fix the issue (log attached). >> I've also tried 0cc2ce4 but with that revision it works correctly >> (log and config attached). >> >> If needed I can run a git bisect to find which commit broke the boot. >> > > I thought I had seen some other message [1] on the list regarding > X201(i) not booting or resuming. Looking at your boot log ending on > "0:1f.0 final", it appears we are looking at the same commit which > adds INTEL_CHIPSET_LOCKDOWN implementation in lpc_final(). The commit > message tells it was not tested for ibexpeak so you may want to try > revert that one before going for full bisect. 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

1 0

Re: [coreboot] [RFH] Status of the Lenovo X201
by Nicola Corna April 28, 2018

April 28, 2018

April 26, 2018 7:21 PM, "Kyösti Mälkki" <kyosti.malkki(a)gmail.com> wrote: > Well, smashed stack in romstage -error is no longer in the log, > possibly because this boot used MRC cache now. Could be, unfortunately I don't have first boot log, I'll grab it in the next test. > With config PARALLEL_CPU_INIT=y so SMP / SMM init in initialize_cpus() > will never call wait_other_cpus() at all. That actually regressed in > my commit 0cc2ce4 [1] but I can't test if reverting it solves this for > you. I'll push a regression fix soonish for review. > > [1] https://review.coreboot.org/c/coreboot/+/21088 > > Kyösti I'm going to test https://review.coreboot.org/#/c/coreboot/+/25874 soon and report back, thanks for your help. Nicola

2 2

Re: [coreboot] lenovo x220, tool to extract binary blobs from BIOS update
by Peter Stuge April 28, 2018

April 28, 2018

Mat wrote: > I was able to extract *.exe file with innoextract, but then running > ifdtool to each file from extracted directory does not bring any > success. Can you show a directory listing which includes file sizes? One idea is to try the bios_extract and/or uefi_extract utils. //Peter

3 4

No boards are removed from coreboot (was Re: [URGENT] ... BS ...)
by Nico Huber April 28, 2018

April 28, 2018

Hello, to say it one more time: It was never intended to remove boards from coreboot. All that was discussed is to stop pretending that things work (that don't) and instead keep them on branches where it's easier to keep them working (if somebody has interest). If that will happen again, it will be right after a release. And most likely due to the state of the code and *less likely* because of missing board-status uploads. You can expect that it will be announced in advance. Nico

1 0

Re: [coreboot] x220: cannot modify nvramcui options with newest coreboot (git a96e31b)
by Andrew A. I. April 28, 2018

April 28, 2018

1 0

[URGENT] Full List of AMD-based boards that are going to be removed from coreboot unless people cough up a board status update
by Mike Banon April 28, 2018

April 28, 2018

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! To avoid the possible removal of these wonderful boards, we need to update their board_status. To upload your own report, check out https://www.coreboot.org/Board_Status . See also https://www.mail-archive.com/coreboot@coreboot.org/msg51438.html for a way to review information prior to uploading it. Although I am also CC'ing these message to the previous reporters, maybe some of them do not have these boards at the moment - so, if you still have any of these boards and still care about them - please do not rely on others. We are waiting for your report Laptops: HP Pavilion m6 1035dx - AMD Family 15h TN (AGESA) - 2014 (but it is quite similar to G505S, and hopefully is still working as well) Servers: ASUS KFSN4-DRE_K8 - AMD K8 - 2016-08-22 Desktop/workstations: ASROCK 939A785GMH/128M - AMD K8 - 2017-11-19 ASUS A8N-E // A8N-SLI // A8V-E SE - AMD K8 - 2014 ASUS F2A85-M - AMD Family 15h TN (AGESA) - 2017-09-04 ASUS M2V-MX SE - AMD K8 - 2017-12-09 ASUS M4A785T-M - AMD Family 10h - 2015-10-22 GIGABYTE GA-M57SLI-S4 - AMD K8 - 2017-04-17 GIGABYTE GA-MA785GMT-UD2H - AMD Family 10h - 2015-07-02 MSI MS-7135 (K8N Neo3) - AMD K8 - 2017-05-10 Embedded / PC/104 / Half-size boards: ADLINK CoreModule2-GF - AMD Family 14h (AGESA) - 2017-09-01 GizmoSphere Gizmo - AMD Family 14h (AGESA) - 2017-08-25 LiPPERT FrontRunner-AF - AMD Family 14h (AGESA) - 2017-09-01 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 Mini-ITX / Micro-ITX / Nano-ITX boards: ASROCK IMB-A180 - AMD Family 16h KB (AGESA) - 2017-08-24 Biostar AM1ML - AMD Family 16h KB (AGESA) - 2015-04-13 Jetway NF81-T56N-LF - AMD Family 14h (AGESA) - 2014 After you will submit your report, it will be mentioned at this page in about 1 hour: https://www.coreboot.org/Supported_Motherboards Best regards, Mike Banon On Fri, Apr 27, 2018 at 8:52 PM, Denis 'GNUtoo' Carikli <GNUtoo(a)no-log.org> wrote: > Hi, > > On Wed, 4 Apr 2018 18:36:56 -0400 > "Taiidan(a)gmx.com" <Taiidan(a)gmx.com> wrote: > >> This is a great board that many use and it DOES work - it needs a >> status update ASAP to prevent it from being removed in the next >> release. > Is there more details on the policy? For instance how can I know in > advance which of the board I have are affected? Does it applies to the > boards in yellow in the Supported Motherboards[1] page? What is the > deadline? > I have the following 'yellow' 'boards', and I'm interested in > refreshing them. However I cannot do it before the beginning of next > week: > - M4A785T-M: last status: October 2015 > - T400: Last status: Aug 2017 > > I also have a beagle bone green, but I'm not sure it's compatible. > > References: > ----------- > [1]https://www.coreboot.org/Supported_Motherboards > > Denis. > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot

1 0