coreboot

coreboot@coreboot.org

6 participants
39686 discussions

coreboot Leadership Meeting
by mina＠coreboot.org 30 Oct '23

30 Oct '23

Dear coreboot Community, We are pleased to announce the upcoming coreboot leadership meeting scheduled for Wednesday, November 1, 2023.[1] Please feel free to add things you wish to see addressed during the meeting to the agenda.[2] [1] https://coreboot.org/calendar.html [2] https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgK… 3tcg8b

1 0

Compatibility
by Christopher Rigdon 30 Oct '23

30 Oct '23

Greetings, I was browsing you web site and saw that you have open source firmware for the Lenovo Thinkpad T430. I have an Ideapad Y430 and was wondering if it would be a compatible laptop as well? Your assistance is much appreciated. Thanks, -Chris Rigdon

1 0

New Defects reported by Coverity Scan for coreboot
by scan-admin＠coverity.com 29 Oct '23

29 Oct '23

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 1 new defect(s) introduced to coreboot found with Coverity Scan. 4 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 1 of 1 defect(s) ** CID 1523711: Memory - illegal accesses (BUFFER_SIZE) /src/mainboard/prodrive/hermes/mainboard.c: 114 in update_board_layout() ________________________________________________________________________________________________________ *** CID 1523711: Memory - illegal accesses (BUFFER_SIZE) /src/mainboard/prodrive/hermes/mainboard.c: 114 in update_board_layout() 108 /* Update CPU fields */ 109 for (struct device *cpu = all_devices; cpu; cpu = cpu->next) { 110 if (!is_enabled_cpu(cpu)) 111 continue; 112 layout.cpu_count++; 113 if (!layout.cpu_name[0]) >>> CID 1523711: Memory - illegal accesses (BUFFER_SIZE) >>> Calling "strncpy" with a maximum size argument of 50 bytes on destination array "layout.cpu_name" of size 50 bytes might leave the destination string unterminated. 114 strncpy(layout.cpu_name, cpu->name, sizeof(layout.cpu_name)); 115 } 116 117 if (cpuid_get_max_func() >= 0x16) 118 layout.cpu_max_non_turbo_frequency = cpuid_eax(0x16); 119 ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0

Re: RFC: generating more ACPI tables at buildtime
by niewoehner.michael 29 Oct '23

29 Oct '23

Heh, once I had that idea as well when working with ACPI. This really would help when debugging stuff. The way I did it was dumping the generated ASL from the live OS and then loading overriding stuff through Linux' means (boot dsdt override + runtime patching). That somehow worked but wasn't really stable and reliable. ---- Am Sa, 28 Okt 2023 16:28:45 +0200 schrieb Matt DeVillier <mailto:matt.devillier@gmail.com> ---- Funnily enough I had this thought as well when I first started working with acpigen, but now that I've used it more, I definitely appreciate the ability to generate tables/device status etc at runtime based on the actual hardware. I definitely agree that having more asl / more build-time tables makes debugging easier. I think the idea of a userspace program that can generate a mock SSDT (and/or any other runtime-generated tables) based on assumed hardware presence would be great, that way we can inspect and debug the ssdt without having to boot actual hardware and dump it. It could even generate a config file with all the "toggleable" hardware and we could set the status to on/off and then use that for the mock table generation. And we could expand our ACPI checks to validate the mock tables (or just run them through iasl), which would allow us to improve our ACPI to better handle "picky" OSes like Windows. re: setting various enable bits (or ACPI _STA) at runtime: we've actually started doing that already for a lot of things in soc/amd/common, where the devices are generated by static asl and the _STA() method returns a variable (eg, STAT) which defaults to off (0x0) and if present is overridden in the SSDT (by setting STAT to 0xF). I'm not sure this is the ideal way of doing it, so would love to hear other ideas as well. On Sat, Oct 28, 2023 at 7:39 AM Arthur Heymans <mailto:arthur@aheymans.xyz> wrote: _______________________________________________ coreboot mailing list -- mailto:coreboot@coreboot.org To unsubscribe send an email to mailto:coreboot-leave@coreboot.org Hi Except the DSDT most ACPI tables are generated at runtime in coreboot. For some tables runtime generation is actually desirable like SSDT. For other tables a lot of the data is known at buildtime, which makes it possible to create them at buildtime and simply load them into memory at runtime. Having the tables generated at runtime makes them hard to debug and inspect or even validate. A few examples: - MCFG: everything is known at buildtime - FADT: only pointers to DSDT and FACS need updating. The rest is typically known at buildtime. - MADT: Currently all LAPICs are generated in SSDT and in MADT. Maybe this could be changed to swapping the enabled 'bits' at runtime but having the table there at buildtime? This could avoid the complicated code to deal with SMP threads sorting and Intels hybrid infrastructure that currently happens at runtime. - TMP log tables: only the pointer to the table needs updating. What do you think about creating a userspace program that takes most of the ramstage sources, mocks a few functions, creates some meaningful data input values to make it usable/executable in userspace and runs the ACPI generation code with it and outputs it into a file or even multiple files? Then the coreboot ramstage could just load those tables from cbfs instead of generating them. Some thoughts: - It could mean more maintenance as you likely want to keep both runtime and buildtime options available for most tables. - code size is reduced (good) in favor of larger data. I am not sure what the overall impact is on the boot medium footprint. - Having a way to generate tables at buildtime makes writing ACPI code easier. You don't need to run it on actual hardware to develop them, even if the end goal is to eventually generate things at runtime. Let me know what you think. Arthur _______________________________________________ coreboot mailing list -- mailto:coreboot@coreboot.org To unsubscribe send an email to mailto:coreboot-leave@coreboot.org

3 2

RFC: generating more ACPI tables at buildtime
by Arthur Heymans 28 Oct '23

28 Oct '23

Hi Except the DSDT most ACPI tables are generated at runtime in coreboot. For some tables runtime generation is actually desirable like SSDT. For other tables a lot of the data is known at buildtime, which makes it possible to create them at buildtime and simply load them into memory at runtime. Having the tables generated at runtime makes them hard to debug and inspect or even validate. A few examples: - MCFG: everything is known at buildtime - FADT: only pointers to DSDT and FACS need updating. The rest is typically known at buildtime. - MADT: Currently all LAPICs are generated in SSDT and in MADT. Maybe this could be changed to swapping the enabled 'bits' at runtime but having the table there at buildtime? This could avoid the complicated code to deal with SMP threads sorting and Intels hybrid infrastructure that currently happens at runtime. - TMP log tables: only the pointer to the table needs updating. What do you think about creating a userspace program that takes most of the ramstage sources, mocks a few functions, creates some meaningful data input values to make it usable/executable in userspace and runs the ACPI generation code with it and outputs it into a file or even multiple files? Then the coreboot ramstage could just load those tables from cbfs instead of generating them. Some thoughts: - It could mean more maintenance as you likely want to keep both runtime and buildtime options available for most tables. - code size is reduced (good) in favor of larger data. I am not sure what the overall impact is on the boot medium footprint. - Having a way to generate tables at buildtime makes writing ACPI code easier. You don't need to run it on actual hardware to develop them, even if the end goal is to eventually generate things at runtime. Let me know what you think. Arthur

2 1

[coreboot - Bug #121] (In Progress) T520: Hangs in OS
by Patrick Rudolph 21 Oct '23

21 Oct '23

Issue #121 has been updated by Patrick Rudolph. Category set to chipset configuration Status changed from New to In Progress Affected hardware set to SNB, IVY Affected OS set to - Limiting the package C-state to C2 using MSR MSR_PKG_CST_CONFIG_CONTROL seems to work around the issue. With this workaround the CPU cores can still enter C7 and no cmdline fix in Linux is required. It draws about 1-2Watts more power in idle. **The issue is thus related to the 'package C-state', not the 'CPU C-state'.** I was trying to figure out what happens on package C-states: - Package C2: - CPUs are in C3 or higher - bus traffic or device latency requirements keep it in C2 - Package C3: - DRAM is in self refresh - Primary (IA Core power) and secondary plane (Graphics) VR are switched into light mode - Package C6: - CPU voltage is turned off - Package C7: - L3 cache is turned off - Chipset doesn't snoop It is possible that the issue is DRAM / native ram init related. When Package C3 is entered and the DRAM is placed in self refresh. ---------------------------------------- Bug #121: T520: Hangs in OS https://ticket.coreboot.org/issues/121#change-1682 * 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

2023-10-18 - coreboot Leadership Meeting Minutes
by mina＠coreboot.org 19 Oct '23

19 Oct '23

# 2023-10-18 - coreboot Leadership Meeting Minutes ## Attendees: Wilhelmina Asante, Jon Murphy, Werner Zeh, Arthur Heymans, David Hendricks, Felix Singer, Matt Devillier, Jeremy Compostella, Martin Roth, Simon Glass, Marshall Dawson, Christian Walter ## Open Action Items * [New]-MartinR & FelixS:Build a POC website. * [New]-Arthur:Ask Philip about how to use company logos. * [New]-MattD and WernerZ :Work on compiling list requirements from the mailing list. * [In Progress]-Martin:Write a tutorial for gerrit - Feel free to help. * [Not Started]- Martin:Write a documentation about vendorcode submodules. * [Not Started] - OSFF:Look into making a video about using gerrit. *Discussed with Christian who felt this was a good plan. ## Minutes: ### [Arthur] - OCP is good, but nobody wants to be the first to embrace open source firmware. * [David] - Bytedance is happy to be first - direct people/companies to them. * Bytedance is very interested in future platforms using AMD and openSIL with coreboot - at least 2 other OEMs were interested. Ampere is also interested but needs interest from customers before they want to invest in it. ### [Martin] - OSFC last week was fantastic. It was great to see everyone who could attend. Hopefully the economy is better next year so we can have more attendees. * Videos of presentations will be out shortly. ~2 weeks ### [Martin (for Ron)] - Our current website looks like an open source project’s website. If we want to convince people to use or work with coreboot, it should look like a company’s website. Ron pointed to [https://go.dev/] with their table of “Companies using go” as an example of what he thinks might be better. Listing these companies makes other companies feel like they may be missing out by not using go. * Logo discussion * AI: [MartinR & FelixS] - will make a POC website. * AI: [Arthur] - Will ask Philip about how to use company logos. * [David] - Find 8 or 10 companies willing to let us use their logos. * This may take a while due to legal reviews * [Jon] - Do we want to split into “support and built with”? * Would AMD and Intel allow their logos to be added to show that you can use coreboot with their chipsets? * [Martin] - I think this is a good plan - We could look at even having sections for “used by, supported by, and sponsored by”. * [FelixS] - Thought about the idea of implementing a sliding functionality. This way not a limited number of companies can be added since the logos don’t take endless space, but still everyone who wants can be added since only a limited number are shown at a time. * Jon is POC for Google. * Werner is POC for Siemens. * Arthur will ask Bytedance. * FelixS will ask secunet * 3mdeb? Novacustom? Star-Labs? System76? * 9elements :) ### FelixS has been working on generating an updated website. This is a statically generated site. * Brief Preview: https://imgur.com/a/LagBrft (Note, this is safe for work) * Differentiate between coreboot documentation and project documentation. * [Jon] - Can we add a leadership page? * https://zephyrproject.org/governing-board/ * https://www.linuxfoundation.org/about/leadership * [Martin] - Sounds great. * [Jeremy] - Search in documentation is sub-par, and it’s frequently easier to find documentation via a google search directly. * [Werner] - Would coreboot like to pay for this? Do it as a contract? If we want a professional website, we might want to get a professional to design it. * [Jon] ++ * [FelixS] - we’d want to make sure it’s something that we can maintain. Would like to use a static website generator if possible. Open to professional designers, but feels like it might make us depend on them. * [Werner] - We can negotiate this. We could ask for a static generation model. * [Martin] - We probably don’t want a CMS - that becomes much more difficult for us to maintain. * [MattD] - Consider requesting that they do initial design elements. * [Jeremy] - Like the idea of using markdown. * [Matt] - Next step is to come up with a small list of requirements. * [Matt] - will take this with Werner - will put this out on the mailing list - compile input from the mailing list - review at next meeting. ### [Martin] - coreboot gerrit statistics: https://docs.google.com/spreadsheets/d/1q_OdePsm1DHUUJxrO1cWce99lOFd9wKiEZC… 60 * This is a set of statistics that I’ve been keeping unofficially for a while. I showed it to some people at OSFC, and they suggested sharing it more widely. * The data is collected from gerrit with the gerrit_stats perl script in the util/release directory: https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/heads/main/util… * Please note - These statistics are terrible for specifics, and can definitely be gamed. Patches vary in quality, and some people choose to spread their patches into a large number, while others choose to do everything in a single patch. Please don’t read too much into anything in these charts. *[Arthur] - Look at adding these statistics to future release notes or announcements. * [Martin] - Please feel free to share this sheet or statistics with others. *[Jon] - We can compile general statistics, similar to Zephyr * 80,202 Commits * 1,629 Contributors * 129 Repositories * 39,634 Pull Requests Closed * Visit https://zephyrproject.org/ for more information. *[Martin] - Other interesting sites related to coreboot: https://docs.google.com/document/d/1Sp1f4ABYqsRhXFbW3dzaJXO4lmj2TFfDHCAY1qG… sdpaqo ### [Martin] - We have a new coreboot store - https://coreboot.myspreadshop.com. This is in the US, but we can create a similar store with their European group. Unfortunately, that needs to be set up and configured separately. This is just a typical swag store where you can get the coreboot logo printed on random stuff. Anyone need a coreboot apron? * This is being run by Martin, not the coreboot project, so that the project doesn’t have to deal with taxes and such. Any profits made will be donated to coreboot through the SFC. * If anyone wants a new design added, let me know. ### [Stefan] - Matt DeVillier will be taking over my position on the coreboot leadership team. Matt has garnered strong endorsements from David and Werner, who are also part of the coreboot leadership, along with many other community members. His noteworthy contributions, such as providing coreboot builds for a multitude of machines under the moniker "MrChromebox," have made coreboot accessible to hundreds of thousands of individuals. Matt boasts a well-established presence within the community, coupled with an in-depth understanding of coreboot's architecture, ecosystem, and a wide array of hardware generations from numerous silicon vendors. Please join me in extending a warm welcome to Matt D as he embarks on his new role, and don't hesitate to share any feedback you may have with David, Werner, Matt, or myself. * [Martin] - I’d just like to note that there was a lengthy discussion about whether to have open nominations like we did last time when MarcJ left the leadership group. MattD was discussed as an early nominee, even before Stefan was ready to make an announcement. Because Matt was such a strong candidate and received strong support from everyone in the discussions, it was felt like it would be disingenuous to have open nominations, since we didn’t feel like there were any candidates interested in running who would receive the same level of support. Everyone involved understands that this decision may be seen negatively by some, but we were trying to keep things honest in this decision. ### [Martin] - Felix Singer is joining Martin, Stefan, and Patrick as an admin for the coreboot project. It will take a week or so before he has full permissions as we’re walking him through the various pieces of software we run, but please feel free to pester Felix with any issues you see going forward. ### [Wilhelmina] - I want to say thank you to the coreboot community for their patience while I learn my new role. **Closed action Items** * [Done] Martin: Work with David to create a staging repo for intel. * https://review.coreboot.org/plugins/gitiles/intel-dev-pub * Intention is to have a repo where they can stage patches (clean-up, squash, etc) before sending to Gerrit, and have a buildable/testable branch while patches are pending. * [Done] Simon: Will send patches related to RFCv2 for post-build control of the serial console. * https://www.mail-archive.com/coreboot@coreboot.org/msg58246.html * [Martin] - We can Discuss the proposal in documents, reviews or on the mailing list, and address here more when thoughts are more finished. # Next meeting * November 1st, 2023 * [Meeting link] * https://meet.google.com/pyt-newq-rbb * [coreboot Calendar] * https://coreboot.org/calendar.html # Notice Decisions shown here are not necessarily final, and are based on the current information available. If there are questions or comments about decisions made, or additional information to present, please put it on the leadership meeting agenda and show up if possible to discuss it. Of course items may also be discussed on the mailing list, but as it's difficult to interpret tone over email, controversial topics frequently do not have good progress in those discussions. For particularly difficult issues, it may be best to try to schedule another meeting. # coreboot leadership meeting minutes https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgKj...

1 0

[coreboot - Bug #121] T520: Hangs in OS
by Patrick Rudolph 19 Oct '23

19 Oct '23

Issue #121 has been updated by Patrick Rudolph. Issue still occurs on ThinkPad X220 using https://review.coreboot.org/c/coreboot/+/78293 using Linux 6.5.6 ---------------------------------------- Bug #121: T520: Hangs in OS https://ticket.coreboot.org/issues/121#change-1679 * Author: Julz Buckton * Status: New * Priority: Normal * Start date: 2017-06-09 ---------------------------------------- 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: RFC: Post-build control of serial console
by Martin Roth 18 Oct '23

18 Oct '23

Hi Simon, Sep 29, 2023, 13:04 by sjg(a)chromium.org: > Hi Martin, > > On Mon, 25 Sept 2023 at 13:51, Martin Roth <gaumless(a)tutanota.com> wrote: > >> >> Hey Simon, I think this is a good summary of the current situation, though the table doesn't come through in the text version of the email at all. Maybe upload an RFC to the documentation directory so it can be commented on in gerrit? >> > > Can you see this? > > https://docs.google.com/document/d/17vLMUFYuUVZnJkHdG2My4iyX_FJW185HosHSIwR… > Yes, thanks. > > I did upload a PoC but I think I was ahead of the game as it needed an > RFC first. > >> As I mentioned in the leadership meeting, I have concerns about a solution that relies solely on embedding this in bootblock. Some of these issues are specific to AMD, but if we're doing this, it should be a solution that we can use across different platforms and architectures. >> >> Issues I see with embedding it the option mechanism in bootblock:1) Bootblock can be signed for verification by cbfs. Modifying the bootblock will cause the CBFS verification to fail. >> 2) The AMD bootblock is part of the overall AMDFW binary, and not at the top of the ROM as it used to be. This makes locating it and modifying it more difficult - it's not a separate CBFS area as you specified. >> 3) For AMD, the bootblock can be compressed, which makes it difficult (or impossible) to update this table.4) AMD has 3 copies of the bootblock. Which one gets updated? If all need to be updated, that's very inconvenient and creates issues keeping them in sync. >> 5) Assuming that you want this to be available to the 1st stage that's run, on AMD, that doesn't have to be bootblock, that can be PSP_verstage instead. >> 6) What happens when there's only one bootblock and it's in RO, so the options can't be updated? Maybe that's not an issue for ChromeOS because the table would only be used for debug, but if we're adding something new, let's design it so that it's useful for everyone. >> >> >> I think it would be better to have a single table at a known fixed location in the firmware boot media so that it can be accessed before CBFS is enabled. This can be a separate partition in FMAP and parsed out by Make at build-time, or set as a Kconfig option and put anywhere in flash that is convenient to the architecture or platform (while still being writable). As Arthur said, it's inconvenient when the firmware boot media isn't memory mapped, so we probably need to design this with both options in mind. >> >> I'm fine with an option that lets us choose between embedding something in the bootblock and placing the table somewhere else, so long as we use the same format in either place and only have a single copy in any given coreboot.rom image. >> > > OK, got it. > >> >> Also, I'd really like to see this use an existing configuration mechanism instead of adding yet another configuration API. Here are 3 options I see: >> >> CMOS_BUT_IN_FLASH >> One option is to use the same interface inside coreboot that we currently use for CMOS. We should be able to just read the options from the boot media (or memory after copying it from flash) instead of CMOS, but use the rest of the parsing mechanisms as they already exist. CCB would just be added as another OPTION_BACKEND in Kconfig. I do like the way we have a method of adding default values for CMOS, so I'd prefer to see the exact same mechanism that we use in CMOS, but stored in flash instead. This would work well as an option for either putting into the bootblock or somewhere else in flash. >> > > It looks like only one backend can be active, but for x86 boards we > would want CMOS RAM (for normal settings) as well as SPI flash for > CCB). Also the options are accessed using strings which is less > efficient than an enum. > I'm not sure why we'd need to use multiple backends, or why we need CMOS for "normal" settings. Is there a reason we couldn't use the SPI flash for all of the settings instead of CMOS? I guess if you want to store the information just in the bootblock, that could be problematic, or we'd have to come up with a way to keep that data around for other stages. >> SMMSTORE_VIA_ANOTHER_MECHANISM >> If that's not practical, we could use the same partition and format used by SMMstore, and create non-SMM routines to be cross-platform and allow it to be used earlier. It looks like SMMstore can already be used as another OPTION_BACKEND. I haven't looked into SMMstore, so I don't know if this is practical, but this still seems better than creating something completely new. Obviously, this doesn't work well to embed into the bootblock. >> > > That looks like a ramstage thing that does some sort of system call to > access the data. See for example smmstore_exec(). I am not sure how I > could use that here. > I was really suggesting that we implement a new routine to access the SMMSTORE data directly from flash early in the boot process. Just from the name, I assumed that it wasn't available to pre-memory stages. >> >> CBI_IN_FLASH >> Even extending CBI to read data from the firmware boot media instead of (or in addition to) the EC would be better than creating an entirely new interface. There's a CBI interface to read the bits directly, but CBI also hooks into devicetree allowing devices to be enabled or disabled at runtime. CBI is currently limited to 64 bits, but that could be extended. This also works well for either embedding into bootblock or placing somewhere else in flash. >> > > That looks more plausible, since it allows reading from multiple > places in fw_config_get(). As you say it is only a 64-bit word. Plus > it doesn't seem to be standardised across boards. Each one defines its > own bits! > > Having said that, it looks like the top bit is free in all cases, so I > could perhaps add a 'global' config which is used by all boards? > > Alternatively, I could rename perhaps fw_config_get() to > fw_config_get_base() and add an enum parameter to fw_config_get(). > But I would need to plumb this into coreboot's 'devicetree'. That > doesn't seem to allow for configs which are common to all boards. > > What do you think? > Well, There's a reason that CBI was my 3rd option. If we're implementing something new, it would be really nice to implement something that can store an "arbitrarily large" amount of data in various different formats. CBI is perfect for flags and options that can be stored in a few bits, but it wasn't designed to handle strings or really even byte values. We might be able to overcome that, but since the offsets are currently bit-based, it'd take some rearchitecting or it could get ugly quickly. Maybe we could just update the fields from bit#s to dword:bit pairs. I think current implementations all only use the first dword, so that shouldn't be too difficult. If we do go with CBI, I think having a global list of names that could be used for CBI settings to enable/disable common code blocks makes sense. If you want a setting to affect something like enabling/disabling serial console, you would use a specific CBI name for it. If a platform doesn't have that name in CBI, it just gets ignored, and no option is used. One of the things that I like about the CMOS option mechanism is that it allows for a clean fallback path if an option is not defined for a board or if the options feature is disabled. Whatever setting options method we use, I'd like to continue that architecture. Allowing a clean fallback if a name isn't in CBI kind of implies that as well. Since CBI was a Google implementation and there's a Google internal spec, if we go that route, I think we'd want that spec to be public. Actually, since it's implemented in coreboot, and a part of devicetree, I think it probably should be public anyway. And maybe renamed from "CrOS board information" to "coreboot board information". We could then extend the CBI spec to be able to handle more than just the EC. We'd need to define a way to identify, read from and update different storage mediums based on the dword. It would definitely be nice to have something that can actually handle multiple storage mediums at the same time. I could definitely see a lot of use to having something so that different options are read from various size areas in EC, flash, CMOS, a data segment in the code, hardcoded build-time values, or any other future mechanism, all at the same time. Take careMartin

3 3

New Defects reported by Coverity Scan for coreboot
by scan-admin＠coverity.com 18 Oct '23

18 Oct '23

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 8 new defect(s) introduced to coreboot found with Coverity Scan. 32 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 8 of 8 defect(s) ** CID 1522885: (CHECKED_RETURN) /src/northbridge/intel/e7505/romstage.c: 17 in mainboard_romstage_entry() /src/mainboard/emulation/qemu-i440fx/romstage.c: 8 in mainboard_romstage_entry() /src/mainboard/emulation/qemu-q35/romstage.c: 17 in mainboard_romstage_entry() ________________________________________________________________________________________________________ *** CID 1522885: (CHECKED_RETURN) /src/northbridge/intel/e7505/romstage.c: 17 in mainboard_romstage_entry() 11 /* FIXME: Keep until flashed bootblock has these. */ 12 i82801dx_early_init(); 13 i82801dx_lpc_setup(); 14 15 sdram_initialize(); 16 >>> CID 1522885: (CHECKED_RETURN) >>> Calling "cbmem_recovery" without checking return value (as is done elsewhere 13 out of 16 times). 17 cbmem_recovery(0); /src/mainboard/emulation/qemu-i440fx/romstage.c: 8 in mainboard_romstage_entry() 2 3 #include <arch/romstage.h> 4 #include <cbmem.h> 5 6 void mainboard_romstage_entry(void) 7 { >>> CID 1522885: (CHECKED_RETURN) >>> Calling "cbmem_recovery" without checking return value (as is done elsewhere 13 out of 16 times). 8 cbmem_recovery(0); /src/mainboard/emulation/qemu-q35/romstage.c: 17 in mainboard_romstage_entry() 11 { 12 i82801ix_early_init(); 13 14 if (!CONFIG(BOOTBLOCK_CONSOLE)) 15 mainboard_machine_check(); 16 >>> CID 1522885: (CHECKED_RETURN) >>> Calling "cbmem_recovery" without checking return value (as is done elsewhere 13 out of 16 times). 17 cbmem_recovery(0); ** CID 1522884: Control flow issues (DEADCODE) /src/security/vboot/vboot_logic.c: 192 in extend_pcrs() ________________________________________________________________________________________________________ *** CID 1522884: Control flow issues (DEADCODE) /src/security/vboot/vboot_logic.c: 192 in extend_pcrs() 186 187 static tpm_result_t extend_pcrs(struct vb2_context *ctx) 188 { 189 tpm_result_t rc; 190 rc = vboot_extend_pcr(ctx, CONFIG_PCR_BOOT_MODE, BOOT_MODE_PCR); 191 if (rc) >>> CID 1522884: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "return rc;". 192 return rc; 193 return vboot_extend_pcr(ctx, CONFIG_PCR_HWID, HWID_DIGEST_PCR); 194 } 195 196 #define EC_EFS_BOOT_MODE_VERIFIED_RW 0x00 197 #define EC_EFS_BOOT_MODE_UNTRUSTED_RO 0x01 ** CID 1522883: (DEADCODE) /src/soc/intel/common/block/graphics/graphics.c: 90 in get_external_display_status() /src/soc/intel/common/block/graphics/graphics.c: 81 in get_external_display_status() ________________________________________________________________________________________________________ *** CID 1522883: (DEADCODE) /src/soc/intel/common/block/graphics/graphics.c: 90 in get_external_display_status() 84 * Dual display detected: both DDI-A(eDP) and 85 * DDI-B(HDMI) pipes are active 86 */ 87 return 1; 88 } else { 89 if (ddi_a_func_ctrl == TRANS_DDI_SELECT_PORT(PORT_A)) >>> CID 1522883: (DEADCODE) >>> Execution cannot reach this statement: "return 0;". 90 return 0; 91 else 92 return 1; 93 } 94 } 95 } /src/soc/intel/common/block/graphics/graphics.c: 81 in get_external_display_status() 75 * Check if transcoder is none or connected to DDI-A port (aka eDP). 76 * Report no external display in both cases. 77 */ 78 if (ddi_a_func_ctrl == TRANS_DDI_PORT_NONE) { 79 return 0; 80 } else { >>> CID 1522883: (DEADCODE) >>> Execution cannot reach the expression "ddi_b_func_ctrl == 268435456U" inside this statement: "if (ddi_a_func_ctrl == 0U &...". 81 if ((ddi_a_func_ctrl == TRANS_DDI_SELECT_PORT(PORT_A)) && 82 (ddi_b_func_ctrl == TRANS_DDI_SELECT_PORT(PORT_B))) { 83 /* 84 * Dual display detected: both DDI-A(eDP) and 85 * DDI-B(HDMI) pipes are active 86 */ ** CID 1522882: Control flow issues (UNREACHABLE) /src/mainboard/google/brya/variants/pirrha/variant.c: 12 in variant_generate_s0ix_hook() ________________________________________________________________________________________________________ *** CID 1522882: Control flow issues (UNREACHABLE) /src/mainboard/google/brya/variants/pirrha/variant.c: 12 in variant_generate_s0ix_hook() 6 #include <acpi/acpigen.h> 7 8 void variant_generate_s0ix_hook(enum s0ix_entry entry) 9 { 10 return; 11 >>> CID 1522882: Control flow issues (UNREACHABLE) >>> This code cannot be reached: "if (entry == S0IX_ENTRY) ...". 12 if (entry == S0IX_ENTRY) 13 acpigen_soc_clear_tx_gpio(SD_CARD_POWER); 14 else if (entry == S0IX_EXIT) 15 acpigen_soc_set_tx_gpio(SD_CARD_POWER); ** CID 1522881: Error handling issues (CHECKED_RETURN) /src/northbridge/intel/i945/gma.c: 102 in intel_gma_init_lvds() ________________________________________________________________________________________________________ *** CID 1522881: Error handling issues (CHECKED_RETURN) /src/northbridge/intel/i945/gma.c: 102 in intel_gma_init_lvds() 96 printk(BIOS_SPEW, 97 "i915lightup: graphics %p mmio %p addrport %04x physbase %08x\n", 98 (void *)pgfx, mmiobase, piobase, pphysbase); 99 100 intel_gmbus_read_edid(mmiobase + GMBUS0, GMBUS_PORT_PANEL, 0x50, 101 edid_data, sizeof(edid_data)); >>> CID 1522881: Error handling issues (CHECKED_RETURN) >>> Calling "decode_edid" without checking return value (as is done elsewhere 10 out of 11 times). 102 decode_edid(edid_data, sizeof(edid_data), &edid); 103 mode = &edid.mode; 104 105 hpolarity = (mode->phsync == '-'); 106 vpolarity = (mode->pvsync == '-'); 107 hactive = edid.x_resolution; ** CID 1522880: Resource leaks (RESOURCE_LEAK) /util/cbfstool/cbfs-mkstage.c: 431 in parse_elf_to_xip_stage() ________________________________________________________________________________________________________ *** CID 1522880: Resource leaks (RESOURCE_LEAK) /util/cbfstool/cbfs-mkstage.c: 431 in parse_elf_to_xip_stage() 425 } 426 427 ret = 0; 428 429 out: 430 rmodule_cleanup(rmodctx); >>> CID 1522880: Resource leaks (RESOURCE_LEAK) >>> Variable "toload" going out of scope leaks the storage it points to. 431 return ret; ** CID 1522879: Error handling issues (CHECKED_RETURN) /src/mainboard/google/brya/bootblock.c: 16 in bootblock_mainboard_early_init() ________________________________________________________________________________________________________ *** CID 1522879: Error handling issues (CHECKED_RETURN) /src/mainboard/google/brya/bootblock.c: 16 in bootblock_mainboard_early_init() 10 size_t num; 11 pads = variant_early_gpio_table(&num); 12 gpio_configure_pads(pads, num); 13 14 /* Init TPM in non-vboot case so ready in early ramstage before i2c init */ 15 if (!CONFIG(VBOOT)) >>> CID 1522879: Error handling issues (CHECKED_RETURN) >>> Calling "tlcl_lib_init" without checking return value (as is done elsewhere 11 out of 12 times). 16 tlcl_lib_init(); 17 } 18 19 void bootblock_mainboard_init(void) 20 { 21 variant_update_descriptor(); 22 } 23 ** CID 1522878: Control flow issues (DEADCODE) /src/security/vboot/vboot_logic.c: 280 in verstage_main() ________________________________________________________________________________________________________ *** CID 1522878: Control flow issues (DEADCODE) /src/security/vboot/vboot_logic.c: 280 in verstage_main() 274 timestamp_add_now(TS_TPMINIT_START); 275 rv = vboot_setup_tpm(ctx); 276 if (rv == TPM_SUCCESS) { 277 antirollback_read_space_firmware(ctx); 278 antirollback_read_space_kernel(ctx); 279 } else { >>> CID 1522878: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "vb2api_fail(ctx, VB2_RECOVE...". 280 vb2api_fail(ctx, VB2_RECOVERY_RO_TPM_S_ERROR, rv); 281 if (CONFIG(TPM_SETUP_HIBERNATE_ON_ERR) && 282 rv == TPM_CB_COMMUNICATION_ERROR) { 283 printk(BIOS_ERR, "Failed to communicate with TPM\n" 284 "Next reboot will hibernate to reset TPM"); 285 /* Command the EC to hibernate on next AP shutdown */ ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0

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