December 2023 - coreboot - mail.coreboot.org

[coreboot - Bug #121] T520: Hangs in OS
by Anastasios Koutian Dec. 20, 2023

Dec. 20, 2023

Issue #121 has been updated by Anastasios Koutian. After upgrading to coreboot 4.22.01, the issue seems to have returned for me. Hardware is the same as above, however now there is no black screen and no graphical corruption. Instead the whole screen just freezes (along with the entire system). Also, it happens only after 1-2 days whereas before it would appear within 1-2 hours. I am now limiting package C-state to 2 using MSR_PKG_CST_CONFIG_CONTROL as you suggested. I can confirm ~0.7 - 1.0 W extra power usage when idle. If you would like me to test anything else, please let me know and I would be happy to help. If this issue could be eliminated, it would be great for these older laptops, since their battery life is already limited. ---------------------------------------- Bug #121: T520: Hangs in OS https://ticket.coreboot.org/issues/121#change-1718 * Author: Julz Buckton * Status: In Progress * Priority: Normal * Category: chipset configuration * Start date: 2017-06-09 * Affected hardware: SNB, IVY * Affected OS: - ---------------------------------------- I have been running coreboot since 2017.04.15 and have experienced hangs ever since then. It was suggested by folk on the IRC that I run memtest to check for incorrect raminit causing errors, however I have run memtest for 12 hours straight with no errors. Due to the ambiguous nature of the hangs (immediate freeze with no warning signs, audio gets stuck repeating the last 50ms or so of noise, not sure what this effect is called) I don't have much useful information other than the .config and dmesg. However one thing I can say with high confidence is that the hangs occur significantly more frequently in Linux (*buntu distros) than Windows 10. Within an hour of launching Linux a hang is likely, whereas Windows typically runs for many hours before a hang occurs. I considered this an insignificant anecdotal anomaly at first but over the course of the nearly 2 months I have been running coreboot it seems to be a solid trend. The hangs occur anywhere, typically during mere desktop usage or basic web browsing. Additionally there is another form of hang I experience where the screen goes black except for some sort of graphical corruption down the left side (http://i.imgur.com/4zWrlpX.jpg) whether this is related to the more common total freeze hangs I don't know but I figured I should include it nonetheless. These hangs only occur about 1:20 compared to the regular hangs. ---Files-------------------------------- config (20.7 KB) dmesg.txt (57.3 KB) cbmem-raminit.txt (62 KB) lspci.txt (29.6 KB) cpuinfo.txt (3.94 KB) defconfig (1023 Bytes) defconfig (699 Bytes) -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account

1 0

Re: ramstage video display on Chromebook?
by James Feeney Dec. 19, 2023

Dec. 19, 2023

Down the rabbit hole... > Geminilake devices use the FSP PEI GOP driver for display init Hmm - "Pre-EFI Initialization Graphics Output Protocol"? Is this something completely different from the coreboot gfxinit? INTEL_GMA_ADD_VBT help says: The VBT describes the integrated GPU and connections, and is needed by the GOP driver integrated into FSP and the OS driver in order to initialize the display. https://wiki.osdev.org/GOP tells me: GOP is an EFI Boot Time Service, meaning you can't access it after you call ExitBootServices(). However, the framebuffer provided by GOP persists, so you can continue to use it for graphics output in your OS. How does the payload find this framebuffer? Is that info in the VBT? Or, the payload ignores this framebuffer, starts over and completely re-initializes the graphics? > so the display backlight will come on during ramstage (when FSP-S runs) That's very useful to know. > but the platform does not currently support any output / proof of life prior to the payload, other than maybe an early boot splash screen (you'd have to look if GLK supports that) Could be fun - eye candy. Martin says "Intel better than others thanks to libgfxinit", so if GOP is not GFX, then maybe a splash screen will not work? Or GFX also knows how to write to the GOP framebuffer? > simply connecting the debug cable and flashing a serial output enabled build will tell you the same thing Geminilake has serial output? This bluebird chromebook has one USB-C and one USB-A. Is the serial output going through the debug cable? It's not just some buried header on the circuit board? > coreboot saves the console output to memory and to any other output you have enabled in Kconfig. "console output to memory" meaning RAM? Or only to ROM? Or either? > The ROM does have a limited write capacity, but it's typically 100K erase/write cycles at this point, which should be enough for anyone. > Worth to mention that the flash console driver never erases. When it's full, it's full, the user needs to erase it manually. In my case, I don't like to be writing and erasing the system ROM. > Would a live Q/A session help? I'd be happy to host something. Thanks, but email is fine. It gives me time to digest, and hopefully it may leave a useful trail for someone else. Mostly, I'm being curious. Sometimes I have to stumble around before I can ask a meaningful question, and everyone's patience is much appreciated.

2 1

ramstage video display on Chromebook?
by James Feeney Dec. 19, 2023

Dec. 19, 2023

On 12/18/2023 1:00 PM MST Matt DeVillier <matt.devillier(a)gmail.com> wrote: ... Thanks for all that, Matt. A little perspective helps me a lot! I'm wondering, with MrChrombox coreboot will anything normally show on a chromebook screen at ramstage, before payload? Or, if not, can anything be *made* to show on the screen, like status or debug info? I'm thinking, if a payload fails, at least something on the screen from coreboot ramstage would indicate that coreboot executed up through ramstage, without needing to connect a debug cable - and sort of geek eye-candy. Also, it looks like there is a way to save coreboot debug messages to a file. But, does that use CAR, or would messages be repeatedly written to the ROM with every boot? Maybe cache is too small to use for debug messages - geminilake? Or repeatedly writing to ROM reduces its life?

4 3

Re: Google Embedded Controller blob - how does that get to the EC?
by James Feeney Dec. 18, 2023

Dec. 18, 2023

> Since my MrChromebox firmware does not use vboot, I have ported the EC-RW firmware update code from vboot to coreboot, and check if an EC-RW update is needed on each boot as part of EC init in ramstage. This code is in my tree on github for inspection. Well, there are over 100 files named "ramstage.c" in the github repository. Do I understand correctly that the MrChromebox firmware generated will have a custom ramstage, different from the stock coreboot ramstage, just to check if an EC-RW update is needed? Coreboot would not typically try to do that? > It's not necessary to build your own EC-RW firmware or even update it unless there's a specific issue you're trying to resolve. But still, to play-around with different payloads, using mostly stock coreboot, the EC firmware could just be completely left out of the coreboot ROM image? And, if I still needed to update the EC firmware, I could use the Google flashrom fork, as in the Google example, just: flashrom -p internal:bus=lpc -w ec.bin ?

2 3

coreboot services are back up
by coreboot org Dec. 17, 2023

Dec. 17, 2023

This should have taken care of the issues we've been seeing recently with gerrit. If you see any issues with any of the services, other than the redmine service at ticket.coreboot.org, which is on a different server, please respond to this email and let us know what you're seeing. Martin

1 0

coreboot.org downtime for a couple of hours right *NOW*
by coreboot org Dec. 17, 2023

Dec. 17, 2023

Hi All, We're taking down the coreboot servers for a couple of hours to do some emergency maintenance. Sorry for the short notice - everything should be back up in a couple of hours. Martin

1 0

Re: Google Embedded Controller blob - how does that get to the EC?
by James Feeney Dec. 17, 2023

Dec. 17, 2023

> If you do need to update the EC firmware, just flash it manually. Don't bother with the automatic update. It doesn't make sense for you to build it into the firmware. Thanks. That makes more sense. Though still, I don't know where or when this "automatic update" happens. Maybe it happens when ChromeOS itself starts? If that is the case, then the EC update would *never* happen automatically if ChromeOS is replaced with something else. On the other hand, if the EC binary itself is somehow searching the CPU ROM for an EC ROM image, then it might get confused if there is no EC ROM image to find. Maybe Matt knows how this works? Matt? I also see that the Google flashrom fork seems to know how to do this update manually, if a filesystem exists, where http://goo.gl/i5sMq , "Flashrom @ Chromium.org", has: Similarly, to write the x86 and EC firmware ROMs (assume write-protection disabled): flashrom -p internal:bus=spi -w bios.bin # write x86 firmware flashrom -p internal:bus=lpc -w ec.bin # write EC firmware As far as I know, linux does not know how to directly mount a ROM coreboot filesystem.

2 1

Re: geminilake fsp on Google Chromebook?
by James Feeney Dec. 17, 2023

Dec. 17, 2023

>> Then, how do I find whether a particular fspm/fsps set is using the coreboot 2.2.0.0 headers or the 2.2.3.1 headers? Those headers are very similar. > you can't, without knowing the exact build they came from. If they are Google built firmware images, they are using the Google FSP binaries/headers. Is that to say that the Google FSP headers may not match *any* version of the coreboot headers available? The FSP headers look to be setting some address offsets, which would not end well, if the wrong values were being used by coreboot. > For anything else, you'd need to know the tree/hash it was built from and which header values were selected by the build. Hmm - so in the end, "trial and error", if I really wanted to use the extracted Google FSP binaries. I'm hoping that other extracted Google blobs are not so finicky - the Embedded Controller blob, for instance? >> Where your config is for the edk2 payload, is there any reason that these same edk2 FSP files would not also work with the LinuxBoot payload? > I have no idea what you are asking here - edk2 FSP files? That phrase does not make sense to me. I'm also not familiar with the LinuxBoot payload or how it would relate to edk2 Ha! I'm expecting that the FSP files being used should have nothing at all to do with the eventual coreboot payload. I was just asking for confirmation. Though I'm not completely unfamiliar with firmware generally, with coreboot and Google firmware, sometimes my assumptions are correct, and sometimes they are completely off-base and wrong. As far as playing with LinuxBoot itself, yes, I know that I may be on my own for that.

3 2

Google Embedded Controller blob - how does that get to the EC?
by James Feeney Dec. 17, 2023

Dec. 17, 2023

>> I'm hoping that other extracted Google blobs are not so finicky - the Embedded Controller blob, for instance? > As far as the EC, it's all open source, and in public repos at Google. You can rebuild it instead of using their binary. Thanks for that Martin. Still, I'm intimidated by the EC blob. On my board, Google's forked flashrom says: Found Nuvoton flash chip "NPCX796F". Some Nuvoton ECs, and probably this one, are ARM chips. 3rdparty/chromeec/README.md says: If you want instant gratification, you can fetch the source code directly. However, you will need the tool-chain provided by the Chromium OS development environment to build a binary. And then, at http://goo.gl/i5sMq, "Flashrom @ Chromium.org" says: For these examples, we assume the x86 firmware ROM is connected directly to the host via SPI and the EC ROM is connected via the EC to LPC. And then, no matter how this EC blob is acquired, that Google page does not seem to disclose exactly *how* this EC ROM image is suppose to get from the coreboot ROM image, and into the separate EC ROM. But, for instance, I see u-boot/cmd/Kconfig actually has: menu "Firmware commands" config CMD_CROS_EC bool "Enable crosec command" depends on CROS_EC default y help Enable command-line access to the Chrome OS EC (Embedded Controller). This provides the 'crosec' command which has a number of sub-commands for performing EC tasks such as updating its flash, accessing a small saved context area and talking to the I2C bus behind the EC (if there is one). So, even after going to the trouble of getting an EC ROM image into coreboot, how does this get into the EC ROM? Does coreboot have some "magic" that checks the EC ROM version, and then automatically flash the EC ROM? Or, does this have to be done manually? And, if manually, and if u-boot is not being used, does this "crosec" command have to be found or built, to run in an x86 linux for instance, and used to actually flash the EC ROM?

3 2

Re: geminilake fsp on Google Chromebook?
by Martin Roth Dec. 17, 2023

Dec. 17, 2023

Actually, Intel doesn't have much to do with this. I can look at adding the feature, but the chromeos team would need to evaluate the size differences and decide to whether to enable it. Dec 17, 2023 at 12:09 by coreboot(a)coreboot.org: > Dec 16, 2023 at 20:16 by coreboot(a)coreboot.org: > >> Just a thought, the FSP headers are pretty small. Maybe they can be compressed and added to the firmware image to make this easier, the way we do for the config file. >> > > Considering that coreboot needs to know these FSP address offsets, that would seem an excellent idea. Or, at least a reference to the actual version of the headers used could be added to the firmware image, if a unique header version number exists. > > I notice that in the documentation, referenced at 3rdparty/fsp/ApolloLakeFspBinPkg/Docs/Apollo_Lake_FSP_Integration_Guide.pdf, Intel mentions Coreboot specifically by name. So maybe the coreboot developers would hold some sway with this idea. > > _______________________________________________ > coreboot mailing list -- coreboot(a)coreboot.org > To unsubscribe send an email to coreboot-leave(a)coreboot.org >

1 0