coreboot February 2023

coreboot@coreboot.org

28 participants
52 discussions

Re: Status of maintained boards and policies?
by Denis 'GNUtoo' Carikli 23 Feb '23

23 Feb '23

Hi, For some reason I forgot to add coreboot(a)coreboot.org in Cc, so I'm forwarding the reply as well: Begin forwarded message: Date: Wed, 25 Jan 2023 00:32:39 +0100 From: Nico Huber <nico.h(a)gmx.de> To: Denis 'GNUtoo' Carikli <GNUtoo(a)cyberdimension.org> Subject: Re: [coreboot] Re: Status of maintained boards and policies? Hi Denis, did you drop the mailing list on purpose? If not, feel free to forward this message too. On 23.01.23 20:10, Denis 'GNUtoo' Carikli wrote: >> I've always estimated that it would take about $200k to get there for >> any of the older AMD platforms (assuming you can get experienced >> core- boot developers to do it). But once reasonable code for one >> platform would be written, the others should be a piece of cake in >> comparison. > Sorry for the delay I was sidetracked and I forgot to ask: the $200k > is for how many people for how long? Is it for 1 person full time > during one year? Or is it for 2 people?. It's a rough estimation of costs. Giving a more precise number how much money would be needed and how it is best spent would be up to whomever is taking a contract. How much time you get per $ also depends on where developers live. Nevertheless, here are some thoughts: A first implementation that could be discussed with more upstream developers might only take about 1/3. Until then, it shouldn't matter much if it's one deve- loper working alone or more. In this phase I assume it could be a full-time job. Once discussions and review start, things might slow down, and there will be waiting (for feedback) times. I would also reserve some amount in case reviewers need to get paid. I always guess about 1/3 of the job is done by reviewers. Overall this could mean you need one person for a full year and another for the second half. But the strategy could also look much differently, for instance upstreaming step by step, core- boot stage by stage (without first developing a booting PoC). Nico

1 0

Re: Status of maintained boards and policies?
by Martin Roth 23 Feb '23

23 Feb '23

Hey Denis, My reply got out of control here. Apologies for the length, feel free to ignore the top and just skip to my replies. :) The points you bring up are definitely valid, but coreboot isn't Linux. We don't have the same infrastructure, or investment from companies. coreboot has no "full time" contributors as such. We have a number of contributors from various companies who need to get their products shipped, but they all have varying amounts of time to spend on the project. It's a tiny tiny fraction of what Linux gets. I don't mean to say that coreboot is a small project - we're not. In the past year, we've gotten contributions from over 350 different people. Most of these contributions are from people who work on coreboot as a job. Those aren't the people who keep the project alive though. There are really just a couple of dozen people at any given time who actually do the work on the coreboot project outside of the individual patches they're assigned to do for their jobs. Unfortunately, that's simply not enough people to maintain all of the platforms and chips in the tree the way things are currently. We could do something like add a requirement that each platform added needs to donate two (or choose an arbitrary number) boards to the coreboot project that we install somewhere and test on a (daily/weekly/monthly) basis to make sure that they're working. Currently we don't have the funds or a place to do that. It also puts a burden on an individual who wants to add a board to the coreboot tree. It creates problems for companies that use coreboot for an embedded system that isn't easy to test. Looking forward: coreboot just got our first "large" donation from Google to support the build servers for the next year. Until now, the build servers have mainly been running from my house. We've reached the point where the project can no longer run as a hobby-project on a hobby-project budget. If we're going to actually be more than a hobby-project going forward, I think we're going to need to expand our scope and make changes to the way we do things. This is going to require making changes to better define how things like code deprecation is handled. I think you're right that we need some way to guarantee that boards added to coreboot aren't going to be dropped again in a short period of time, but that requires investment from companies using coreboot to make sure that it happens. When a chip is added to coreboot, how long is a company expected to maintain that chip in the coreboot repository? If we make it too short, nobody wants to develop mainboards for it. If we make that time too long, chip vendors aren't going to want to add their chips to the tree. I'm not sure how to balance that. Jan 3, 2023, 17:17 by GNUtoo(a)cyberdimension.org: > On Tue, 3 Jan 2023 18:38:02 +0100 (CET) > Martin Roth <gaumless(a)tutanota.com> wrote: > >> Hi Denis, >> - Responses inline >> > Hi, > > Thanks for the answers. > >> Jan 2, 2023, 17:16 by GNUtoo(a)cyberdimension.org: >> >> > Hi, >> > >> > The MAINTAINERS file has the following: >> > >> >> PC ENGINES ALL MAINBOARDS >> >> M: Piotr Król <piotr.krol(a)3mdeb.com> >> >> M: Michał Żygowski <michal.zygowski(a)3mdeb.com> >> >> S: Supported >> >> F: src/mainboard/pcengines/ >> >> >> > >> > But the commit f9decbb0c720662d8e71fe221aef55b7ecf76196 ("mb/*/*: >> > Remove AMD family14 boards") actually removed the apu1 >> > (src/mainboard/pcengines/). >> > >> > Is there some policy somewhere that describes what kind of support >> > to expect from maintained boards? >> Yes, It's in the maintainers file itself: >> >> Supported: Someone is continuously paid to look after >> this and a reaction to review requests can be expected >> within a few days, a month at most. >> > [...] > >> Because the maintainers may not notice the patches, it's always >> suggested to reach out to the maintainers directly for reviews. >> > As I understand that file tells only about patch review delays and not > what kind of patches are acceptable or not or who is supposed to do the > work of converting a board to the newer APIs. I'm mostly interested in > two last aspects. > > For instance as a Linux contributor, I can send a patch to add a > computer (like a smartphone for instance) or contribute fixes and new > support to existing drivers, and usually the code gets maintained > somehow automatically: > - New patches are required not to break existing code, so they have to > take care to either keep the compatibility with the old code or > update it along the way. > > Though older code doesn't necessarily benefit from new features (for > instance, for ARM, if nobody converts old C board code to the > devicetree, it will still works if people compile support for that > ARM computer, but the resulting kernel will only be able to boot on > that computer). > > The code quality requirements is usually very high in order to reduce > the amount of time required to maintain the code. > > - If I'd contribute a driver instead, I may end up being its maintainer > somehow, so I'd have to review patches. Who will maintain the driver > might also be part of the discussion when upstream will decide or not > to accept the patch for the new driver. > > - Users can test the code and report bugs. If the bugs are reported > during patch review, the burden to fix the bug is on the person who > sent the patch. > > Since there are different policies in Coreboot, I'm trying to > understand if it's possible to somehow find ways to get the same kind > of assurances than with Linux so that specific mainboards will not be > removed, and if so how to do it, how much resources it requires, etc. > We don't currently have any way to make this assurance. It depends on a number of things. Imagine that there's a mainboard maintainer, but no chipset maintainer. If the chipset isn't being maintained and is being removed from ToT because it's not supported and has become problematic, it's not like the mainboard can stay independently. As far as the resources needed, that's difficult for me to say. It depends on the chipset and the changes that are needed. Remember that the boards that are removed from ToT are not gone. We've created branches, and the boards that have been removed from ToT can be maintained on those branches. We have builders set up to test patches pushed to those branches for that reason. Those boards may not get all of the latest features automatically, but do they really need all of the latest features? Does the KGPE-D16 need an eSPI driver? No - it doesn't support eSPI. Because coreboot is a firmware project, it's very different than something that's pure software and can be tested easily. If people want to keep the chipsets and boards on ToT, we need to have people actually working to keep them there. There are a very few people at coreboot doing a LOT of work to keep the project running. We can't do everything for every board on our own. We need other volunteers who own the boards to test them, submit bugs and patches, and help with the project. Without that, coreboot has no way of even knowing if a board is actually working. > If I look at Linux, in the worst case scenario I can look at the number > of maintainers for a given driver and expect that the maintainers will > at worse, work full time on reviewing patches, so that can be roughly > calculated. > > There is also information on how to setup automatic test infrastructure > (for instance with LAVA) so the resources needed for that can also be > predicted somehow. > > Here this interest me because I'm trying to evaluate if it makes sense > for me and other interested people to contribute big changes to > Coreboot, for instance by adding back a mainboard like the Asus > KGPE-D16. If we do a lot of work and that this work is removed right > after, it's not worth it, so it's best to check beforehand than to have > some drama if the huge work is removed. > > The issue with Coreboot is that I'm unsure if I can do the same kind of > calculation than with Linux: The APU1 was removed despite the fact that > the mainboard was "supported". > As mentioned in the scenario above, the mainboard was marked as being supported, but the chipset was not. Unless someone is willing to step up as the supporter of the chipset, I don't know what to tell you. We can't really keep the mainboard without the chipset. I don't know if there's something similar in the linux hierarchy to look at, but if there is, I'd be interested in knowing how it's handled there. > So this is why I'm trying to understand how much work it is to convert > boards and for that understanding how deprecation are decided could > give me hints of the amount of work to expect in the worst case. > >> The usual reason is progress: Infrastructure module X has been >> replaced byinfrastructure module X+1. Removing X helps keep the >> sources manageableand likely opens opportunities to improve the >> codebase even more. >> > Here I am wondering precisely how the deprecation of module X is > decided. For instance can anyone convert some code in Rust and expect > everybody else to learn Rust and rewrite everything in Rust? > > Is it up to maintainers of each module to decide when to deprecate > module X in favor of module X+1? > This is typically suggested on the mailing list, beaten to a pulp, then discussed in the coreboot leadership meeting for a decision > If so what are usually the factors taken into account? I assume that if > there is too much change to do (like completely rewriting Coreboot in > Rust), I assume that they won't be able to force a change like that on > the rest of the Coreboot contributors. If that's the case it gives some > indication of the amount of work required to convert to newer modules. > > It also brings the question of what is taken into account when deciding > to deprecate module X. For instance is the maintainability of each > "modules" the only concern, or are the amount of supported mainboards > and end users a concern too? > > Is the amount of work needed to convert from module X to module X+1 > taken into account? And is there usually some documentation that > explains how to do the conversion? Or are do people need to find out by > looking at the release notes and other boards being converted? > We don't currently have a written policy about it. >> > Is there also a policy that explains when boards are removed? Or >> > what to do to prevent boards from being removed? >> > >> We do have that policy, though it could probably be written a bit >> more plainly. >> >> Here's the search in the coreboot documentation. >> https://doc.coreboot.org/search.html?q=deprecation&check_keywords=yes&area=… >> >> Here's the template for the release notes: >> >> Deprecation notices are part of release notes to act as a warning: at >> somepoint in the future some part of coreboot gets removed. That >> point must beat least 6 months after the release of the notice and it >> must be right aftersome release: That is, the specified release must >> still contain the part inquestion while one git commit later it might >> be removed. >> > That is good: at least we have a way to find that out. > >> > For instance u-boot warns when building that a boards needs to be >> > adjusted to the newer driver model. So just by building u-boot you >> > know in advance what needs to be fixed and for when. >> > >> > I've looked in the Coreboot documentation but I didn't find any >> > information about that. >> > >> >> Someone could definitely add something to put up a notice when doing >> the build, but that doesn't exist right now. If it's not something >> that you're interested in doing, you could file a bug if you think it >> should be added.` >> > I'm not sure I'm the right person to do that, and if so how I could do > it. I could probably propose a patch to the documentation though, if > it's the right place to do it. > > For the code, it's probably best if it's done in the commit that > deprecates something. For instance for CONFIG_LEGACY_SMP_INIT, we could > add the following to the Makefile in the top directory: > > ifneq ($(CONFIG_LEGACY_SMP_INIT),) > @echo "+----------------------- /!\ WARNING /!\ ---------------------+" > @echo "| CONFIG_LEGACY_SMP_INIT is deprecated. |" > @echo "| It will be removed in Coreboot release 4.18 (November 2022).|" > @echo "| Please migrate your mainboard to CONFIG_PARALLEL_MP, |" > @echo "| or it will be removed right after the Coreboot 4.18 release.|" > @echo "| See the Coreboot release notes[1] for more details. |" > @echo "| [1]Documentation/releases/coreboot-4.16-relnotes.md |" > @echo "+-------------------------------------------------------------+" > endif > > If we add that at the end of the Makefile, to have it show up at the > end of the build. We could also add a deprecation target if needed. > This way if we do that and that we use a similar format for all > deprecations, people building Coreboot will most likely see it. > > This way users will not have to read all the release notes at each > releases to catch that kind of issues, and if distributions start > packaging coreboot or other projects based on Coreboot, then they would > see that too. > I'm all in favor of that. I'll add it to the discussion of the coreboot leadership meeting on the 11th. Martin

4 6

[coreboot - Support #464] (New) Writes to AM29LV040B with -p satasii work properly
by Alex Perez 22 Feb '23

22 Feb '23

Issue #464 has been reported by Alex Perez. ---------------------------------------- Support #464: Writes to AM29LV040B with -p satasii work properly https://ticket.coreboot.org/issues/464 * Author: Alex Perez * Status: New * Priority: Normal * Target version: none * Start date: 2023-02-22 ---------------------------------------- When flashing the AM29LV040B with -p satasii (attached to a PCI SATA card) using the latest git checkout, writes work fine. Write Protect does NOT work. I've also reported this via e-mail to flashrom(a)flashrom.org, as per the command-line recommendation. -- 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

[coreboot - Bug #462] (New) Sandy Bridge Raminit failure, only half of the memory modules initialized.
by shen Liu 22 Feb '23

22 Feb '23

Issue #462 has been reported by shen Liu. ---------------------------------------- Bug #462: Sandy Bridge Raminit failure, only half of the memory modules initialized. https://ticket.coreboot.org/issues/462 * Author: shen Liu * Status: New * Priority: Normal * Category: infrastructure * Target version: master * Start date: 2023-02-16 * Affected versions: master * Needs backport to: master ---------------------------------------- ``` shell sudo dmidecode -t 17 # dmidecode 3.4 Getting SMBIOS data from sysfs. SMBIOS 3.3.0 present. Handle 0x000A, DMI type 17, 40 bytes Memory Device Array Handle: 0x0009 Error Information Handle: Not Provided Total Width: 64 bits Data Width: 64 bits Size: 8 GB Form Factor: DIMM Set: None Locator: Channel-0-DIMM-0 Bank Locator: BANK 0 Type: DDR3 Type Detail: Synchronous Unbuffered (Unregistered) Speed: 800 MT/s Manufacturer: Unknown (1383) Serial Number: 000002a0 Asset Tag: Channel-0-DIMM-0-AssetTag Part Number: CL11-11-11 D3-16 Rank: 2 Configured Memory Speed: 800 MT/s Minimum Voltage: Unknown Maximum Voltage: Unknown Configured Voltage: Unknown ``` ``` shell NOTE ] coreboot-4.19-424-geba1a35402-dirty Sun Feb 12 10:30:43 UTC 2023 x86_32 bootblock starting (log level: 7)... [DEBUG] FMAP: Found "FLASH" version 1.1 at 0xe50000. [DEBUG] FMAP: base = 0xff000000 size = 0x1000000 #areas = 5 [DEBUG] FMAP: area COREBOOT found @ e50200 (1768960 bytes) [INFO ] CBFS: mcache @0xfeff0e00 built for 12 files, used 0x2ac of 0x4000 bytes [INFO ] CBFS: Found 'fallback/romstage' @0x80 size 0x180f8 in mcache @0xfeff0e2c [DEBUG] BS: bootblock times (exec / console): total (unknown) / 45 ms [NOTE ] coreboot-4.19-424-geba1a35402-dirty Sun Feb 12 10:30:43 UTC 2023 x86_32 romstage starting (log level: 7)... [DEBUG] SMBus controller enabled [DEBUG] Setting up static northbridge registers... done [DEBUG] Initializing Graphics... [DEBUG] Back from systemagent_early_init() [INFO ] Intel ME early init [INFO ] Intel ME firmware is ready [DEBUG] ME: Requested 0MB UMA [DEBUG] Starting native Platform init [DEBUG] DMI: Running at X4 @ 5000MT/s [DEBUG] FMAP: area RW_MRC_CACHE found @ e00000 (65536 bytes) [DEBUG] Trying stored timings. [DEBUG] Starting Ivy Bridge RAM training (fast boot). [DEBUG] 100MHz reference clock support: yes [DEBUG] PLL_REF100_CFG value: 0x2 [DEBUG] Trying CAS 11, tCK 320. [DEBUG] Found compatible clock, CAS pair. [DEBUG] Selected DRAM frequency: 800 MHz [DEBUG] Selected CAS latency : 11T [DEBUG] MPLL busy... done in 10 us [DEBUG] MPLL frequency is set at : 800 MHz [DEBUG] XOVER CLK [c14] = 3000000 [DEBUG] XOVER CMD [320c] = 24000 [DEBUG] XOVER CLK [d14] = 0 [DEBUG] XOVER CMD [330c] = 4000 [DEBUG] DBP [4000] = 1cbbbb [DEBUG] RAP [4004] = cc187476 [DEBUG] OTHP [400c] = 68b4 [DEBUG] OTHP [400c] = 68b4 [DEBUG] REFI [4298] = 6cf01860 [DEBUG] SRFTP [42a4] = 41f88200 [DEBUG] DBP [4400] = 1cbbbb [DEBUG] RAP [4404] = cc187476 [DEBUG] OTHP [440c] = 68b4 [DEBUG] OTHP [440c] = 68b4 [DEBUG] REFI [4698] = 6cf01860 [DEBUG] SRFTP [46a4] = 41f88200 [DEBUG] Done dimm mapping [DEBUG] Update PCI-E configuration space: [DEBUG] PCI(0, 0, 0)[a0] = 0 [DEBUG] PCI(0, 0, 0)[a4] = 2 [DEBUG] PCI(0, 0, 0)[bc] = 82a00000 [DEBUG] PCI(0, 0, 0)[a8] = 7d600000 [DEBUG] PCI(0, 0, 0)[ac] = 2 [DEBUG] PCI(0, 0, 0)[b8] = 80000000 [DEBUG] PCI(0, 0, 0)[b0] = 80a00000 [DEBUG] PCI(0, 0, 0)[b4] = 80800000 [DEBUG] Done memory map [DEBUG] RCOMP...done [DEBUG] COMP2 done [DEBUG] COMP1 done [DEBUG] FORCE RCOMP and wait 20us...done [DEBUG] Done io registers [DEBUG] CPE [DEBUG] CP5b [DEBUG] CP5c [DEBUG] OTHP [400c] = 68b4 [DEBUG] t123: 1767, 6000, 7620 [NOTE ] ME: Wrong mode : 2 [NOTE ] ME: FWS2: 0x160a0140 [NOTE ] ME: Bist in progress: 0x0 [NOTE ] ME: ICC Status : 0x0 [NOTE ] ME: Invoke MEBx : 0x0 [NOTE ] ME: CPU replaced : 0x0 [NOTE ] ME: MBP ready : 0x0 [NOTE ] ME: MFS failure : 0x1 [NOTE ] ME: Warm reset req : 0x0 [NOTE ] ME: CPU repl valid : 0x1 [NOTE ] ME: (Reserved) : 0x0 [NOTE ] ME: FW update req : 0x0 [NOTE ] ME: (Reserved) : 0x0 [NOTE ] ME: Current state : 0xa [NOTE ] ME: Current PM event: 0x6 [NOTE ] ME: Progress code : 0x1 [NOTE ] PASSED! Tell ME that DRAM is ready [NOTE ] ME: ME is reporting as disabled, so not waiting for a response. [NOTE ] ME: FWS2: 0x160a0140 [NOTE ] ME: Bist in progress: 0x0 [NOTE ] ME: ICC Status : 0x0 [NOTE ] ME: Invoke MEBx : 0x0 [NOTE ] ME: CPU replaced : 0x0 [NOTE ] ME: MBP ready : 0x0 [NOTE ] ME: MFS failure : 0x1 [NOTE ] ME: Warm reset req : 0x0 [NOTE ] ME: CPU repl valid : 0x1 [NOTE ] ME: (Reserved) : 0x0 [NOTE ] ME: FW update req : 0x0 [NOTE ] ME: (Reserved) : 0x0 [NOTE ] ME: Current state : 0xa [NOTE ] ME: Current PM event: 0x6 [NOTE ] ME: Progress code : 0x1 [NOTE ] ME: Requested BIOS Action: No DID Ack received [DEBUG] ME: FW Partition Table : OK [DEBUG] ME: Bringup Loader Failure : NO [DEBUG] ME: Firmware Init Complete : NO [DEBUG] ME: Manufacturing Mode : YES [DEBUG] ME: Boot Options Present : NO [DEBUG] ME: Update In Progress : NO [DEBUG] ME: Current Working State : Initializing [DEBUG] ME: Current Operation State : Bring up [DEBUG] ME: Current Operation Mode : Debug or Disabled by AltDisableBit [DEBUG] ME: Error Code : No Error [DEBUG] ME: Progress Phase : BUP Phase [DEBUG] ME: Power Management Event : Pseudo-global reset [DEBUG] ME: Progress Phase State : Check to see if straps say ME DISABLED [DEBUG] memcfg DDR3 ref clock 133 MHz [DEBUG] memcfg DDR3 clock 1596 MHz [DEBUG] memcfg channel assignment: A: 0, B 1, C 2 [DEBUG] memcfg channel[0] config (00620020): [DEBUG] ECC inactive [DEBUG] enhanced interleave mode on [DEBUG] rank interleave on [DEBUG] DIMMA 8192 MB width x8 dual rank, selected [DEBUG] DIMMB 0 MB width x8 single rank [DEBUG] memcfg channel[1] config (00000000): [DEBUG] ECC inactive [DEBUG] enhanced interleave mode off [DEBUG] rank interleave off [DEBUG] DIMMA 0 MB width x8 single rank, selected [DEBUG] DIMMB 0 MB width x8 single rank [DEBUG] CBMEM: [DEBUG] IMD: root @ 0x7ffff000 254 entries. [DEBUG] IMD: root @ 0x7fffec00 62 entries. [DEBUG] FMAP: area COREBOOT found @ e50200 (1768960 bytes) [DEBUG] External stage cache: [DEBUG] IMD: root @ 0x803ff000 254 entries. [DEBUG] IMD: root @ 0x803fec00 62 entries. [DEBUG] CBMEM entry for DIMM info: 0x7ffdc000 [DEBUG] SMM Memory Map [DEBUG] SMRAM : 0x80000000 0x800000 [DEBUG] Subregion 0: 0x80000000 0x300000 [DEBUG] Subregion 1: 0x80300000 0x100000 [DEBUG] Subregion 2: 0x80400000 0x400000 [DEBUG] Normal boot [INFO ] CBFS: Found 'fallback/postcar' @0x3e7c0 size 0x5ed0 in mcache @0xfeff0fd4 [DEBUG] Loading module at 0x7ffd0000 with entry 0x7ffd0031. filesize: 0x5ae0 memsize: 0xbe78 [DEBUG] Processing 236 relocs. Offset value of 0x7dfd0000 [DEBUG] BS: romstage times (exec / console): total (unknown) / 567 ms [DEBUG] usbdebug: postcar starting... [DEBUG] Normal boot [DEBUG] FMAP: area COREBOOT found @ e50200 (1768960 bytes) [INFO ] CBFS: Found 'fallback/ramstage' @0x1ea40 size 0x1c796 in mcache @0x7fffe9bc [DEBUG] Loading module at 0x7ff83000 with entry 0x7ff83000. filesize: 0x39538 memsize: 0x4b6b0 [DEBUG] Processing 3842 relocs. Offset value of 0x7bf83000 [DEBUG] BS: postcar times (exec / console): total (unknown) / 48 ms [DEBUG] usbdebug: ramstage starting... [DEBUG] Normal boot [INFO ] Enumerating buses... [DEBUG] Root Device scanning... [DEBUG] CPU_CLUSTER: 0 enabled [DEBUG] DOMAIN: 0000 enabled [DEBUG] DOMAIN: 0000 scanning... [DEBUG] PCI: pci_scan_bus for bus 00 [DEBUG] PCI: 00:00.0 [8086/0150] enabled [DEBUG] PCI: 00:01.0 [8086/0151] disabled [DEBUG] PCI: 00:02.0 [8086/0152] enabled [DEBUG] PCI: 00:14.0 [8086/1e31] enabled [DEBUG] PCI: 00:16.0: Disabling device [DEBUG] PCI: 00:16.0 [8086/1e3a] disabled [DEBUG] PCI: 00:16.1: Disabling device [DEBUG] PCI: 00:16.2: Disabling device [DEBUG] PCI: 00:16.3: Disabling device [DEBUG] PCI: 00:19.0: Disabling device [DEBUG] PCI: 00:1a.0 [8086/1e2d] enabled [DEBUG] PCI: 00:1b.0 [8086/1e20] enabled [INFO ] PCH: PCIe Root Port coalescing is enabled [DEBUG] PCI: 00:1c.0 [8086/1e10] enabled [DEBUG] PCI: 00:1c.1 [8086/1e12] enabled [DEBUG] PCI: 00:1c.2: Disabling device [DEBUG] PCI: 00:1c.2 [8086/1e14] disabled [DEBUG] PCI: 00:1c.3: Disabling device [DEBUG] PCI: 00:1c.3 [8086/1e16] disabled [DEBUG] PCI: 00:1c.4: Disabling device [DEBUG] PCI: 00:1c.4: check set enabled [DEBUG] PCI: 00:1c.5: Disabling device [DEBUG] PCI: 00:1c.6: Disabling device [DEBUG] PCI: 00:1c.7: Disabling device [DEBUG] PCI: 00:1d.0 [8086/1e26] enabled [DEBUG] PCI: 00:1e.0 [8086/244e] enabled [DEBUG] PCI: 00:1f.0 [8086/1e49] enabled [DEBUG] PCI: 00:1f.2 [8086/1e00] enabled [DEBUG] PCI: 00:1f.3 [8086/1e22] enabled [DEBUG] PCI: 00:1f.5: Disabling device [DEBUG] PCI: 00:1f.5 [8086/1e08] disabled No operations [DEBUG] PCI: 00:1f.6: Disabling device [DEBUG] PCI: 00:1f.6 [8086/1e24] disabled No operations [WARN ] PCI: Leftover static devices: [WARN ] PCI: 00:01.1 [WARN ] PCI: 00:01.2 [WARN ] PCI: 00:04.0 [WARN ] PCI: 00:06.0 [WARN ] PCI: 00:16.1 [WARN ] PCI: 00:16.2 [WARN ] PCI: 00:16.3 [WARN ] PCI: 00:19.0 [WARN ] PCI: 00:1c.4 [WARN ] PCI: 00:1c.5 [WARN ] PCI: 00:1c.6 [WARN ] PCI: 00:1c.7 [WARN ] PCI: Check your devicetree.cb. [DEBUG] PCI: 00:1c.0 scanning... [DEBUG] PCI: pci_scan_bus for bus 01 [DEBUG] scan_bus: bus PCI: 00:1c.0 finished in 4 msecs [DEBUG] PCI: 00:1c.1 scanning... [DEBUG] PCI: pci_scan_bus for bus 02 [DEBUG] PCI: 02:00.0 [10ec/8168] enabled [INFO ] Enabling Common Clock Configuration [INFO ] ASPM: Enabled L1 [INFO ] PCIe: Max_Payload_Size adjusted to 128 [DEBUG] PCI: 02:00.0: No LTR support [DEBUG] scan_bus: bus PCI: 00:1c.1 finished in 25 msecs [DEBUG] PCI: 00:1e.0 scanning... [DEBUG] PCI: pci_scan_bus for bus 03 [DEBUG] scan_bus: bus PCI: 00:1e.0 finished in 4 msecs [DEBUG] PCI: 00:1f.0 scanning... [DEBUG] scan_bus: bus PCI: 00:1f.0 finished in 0 msecs [DEBUG] PCI: 00:1f.3 scanning... [DEBUG] scan_bus: bus PCI: 00:1f.3 finished in 0 msecs [DEBUG] scan_bus: bus DOMAIN: 0000 finished in 273 msecs [DEBUG] scan_bus: bus Root Device finished in 290 msecs [INFO ] done [DEBUG] BS: BS_DEV_ENUMERATE run times (exec / console): 0 / 305 ms [DEBUG] found VGA at PCI: 00:02.0 [DEBUG] Setting up VGA for PCI: 00:02.0 [DEBUG] Setting PCI_BRIDGE_CTL_VGA for bridge DOMAIN: 0000 [DEBUG] Setting PCI_BRIDGE_CTL_VGA for bridge Root Device [INFO ] Allocating resources... [INFO ] Reading resources... [DEBUG] Adding PCIe enhanced config space BAR 0xf0000000-0xf4000000. [DEBUG] TOUUD 0x27d600000 TOLUD 0x82a00000 TOM 0x200000000 [DEBUG] MEBASE 0x7ffff00000 [DEBUG] IGD decoded, subtracting 32M UMA and 2M GTT [DEBUG] TSEG base 0x80000000 size 8M [INFO ] Available memory below 4GB: 2048M [INFO ] Available memory above 4GB: 6102M [DEBUG] PCI: 00:1a.0 EHCI BAR hook registered [DEBUG] More than one caller of pci_ehci_read_resources from PCI: 00:1d.0 [INFO ] Done reading resources. [INFO ] === Resource allocator: DOMAIN: 0000 - Pass 1 (gathering requirements) === [DEBUG] PCI: 00:1c.1 io: size: 0 align: 12 gran: 12 limit: ffff [DEBUG] PCI: 02:00.0 10 * [0x0 - 0xff] io [DEBUG] PCI: 00:1c.1 io: size: 1000 align: 12 gran: 12 limit: ffff done [DEBUG] PCI: 00:1c.1 mem: size: 0 align: 20 gran: 20 limit: ffffffff [DEBUG] PCI: 00:1c.1 mem: size: 0 align: 20 gran: 20 limit: ffffffff done [DEBUG] PCI: 00:1c.1 prefmem: size: 0 align: 20 gran: 20 limit: ffffffffffffffff [DEBUG] PCI: 02:00.0 20 * [0x0 - 0x3fff] prefmem [DEBUG] PCI: 02:00.0 18 * [0x4000 - 0x4fff] prefmem [DEBUG] PCI: 00:1c.1 prefmem: size: 100000 align: 20 gran: 20 limit: ffffffffffffffff done [INFO ] === Resource allocator: DOMAIN: 0000 - Pass 2 (allocating resources) === [DEBUG] DOMAIN: 0000 io: base: 0 size: 0 align: 0 gran: 0 limit: ffff [DEBUG] update_constraints: PCI: 00:1f.0 10000000 base 00000000 limit 00000fff io (fixed) [DEBUG] update_constraints: PCI: 00:1f.3 20 base 00000400 limit 0000041f io (fixed) [INFO ] DOMAIN: 0000: Resource ranges: [INFO ] * Base: 1000, Size: f000, Tag: 100 [DEBUG] PCI: 00:1c.1 1c * [0x1000 - 0x1fff] limit: 1fff io [DEBUG] PCI: 00:02.0 20 * [0x2000 - 0x203f] limit: 203f io [DEBUG] PCI: 00:1f.2 20 * [0x2040 - 0x205f] limit: 205f io [DEBUG] PCI: 00:1f.2 10 * [0x2060 - 0x2067] limit: 2067 io [DEBUG] PCI: 00:1f.2 18 * [0x2068 - 0x206f] limit: 206f io [DEBUG] PCI: 00:1f.2 14 * [0x2070 - 0x2073] limit: 2073 io [DEBUG] PCI: 00:1f.2 1c * [0x2074 - 0x2077] limit: 2077 io [DEBUG] DOMAIN: 0000 io: base: 0 size: 0 align: 0 gran: 0 limit: ffff done [DEBUG] DOMAIN: 0000 mem: base: 0 size: 0 align: 0 gran: 0 limit: fffffffff [DEBUG] update_constraints: PCI: 00:00.0 60 base f0000000 limit f3ffffff mem (fixed) [DEBUG] update_constraints: PCI: 00:00.0 03 base 00000000 limit 0009ffff mem (fixed) [DEBUG] update_constraints: PCI: 00:00.0 04 base 00100000 limit 7fffffff mem (fixed) [DEBUG] update_constraints: PCI: 00:00.0 05 base 100000000 limit 27d5fffff mem (fixed) [DEBUG] update_constraints: PCI: 00:00.0 06 base 80000000 limit 829fffff mem (fixed) [DEBUG] update_constraints: PCI: 00:00.0 07 base 000a0000 limit 000bffff mem (fixed) [DEBUG] update_constraints: PCI: 00:00.0 08 base 000c0000 limit 000fffff mem (fixed) [DEBUG] update_constraints: PCI: 00:1f.0 10000100 base ff000000 limit ffffffff mem (fixed) [DEBUG] update_constraints: PCI: 00:1f.0 03 base fec00000 limit fec00fff mem (fixed) [INFO ] DOMAIN: 0000: Resource ranges: [INFO ] * Base: 82a00000, Size: 6d600000, Tag: 200 [INFO ] * Base: f4000000, Size: ac00000, Tag: 200 [INFO ] * Base: fec01000, Size: 3ff000, Tag: 200 [INFO ] * Base: 27d600000, Size: d82a00000, Tag: 100200 [DEBUG] PCI: 00:02.0 18 * [0x90000000 - 0x9fffffff] limit: 9fffffff prefmem [DEBUG] PCI: 00:02.0 10 * [0x82c00000 - 0x82ffffff] limit: 82ffffff mem [DEBUG] PCI: 00:1c.1 24 * [0x82a00000 - 0x82afffff] limit: 82afffff prefmem [DEBUG] PCI: 00:14.0 10 * [0x82b00000 - 0x82b0ffff] limit: 82b0ffff mem [DEBUG] PCI: 00:1b.0 10 * [0x82b10000 - 0x82b13fff] limit: 82b13fff mem [DEBUG] PCI: 00:1f.2 24 * [0x82b14000 - 0x82b147ff] limit: 82b147ff mem [DEBUG] PCI: 00:1a.0 10 * [0x82b15000 - 0x82b153ff] limit: 82b153ff mem [DEBUG] PCI: 00:1d.0 10 * [0x82b16000 - 0x82b163ff] limit: 82b163ff mem [DEBUG] PCI: 00:1f.3 10 * [0x82b17000 - 0x82b170ff] limit: 82b170ff mem [DEBUG] DOMAIN: 0000 mem: base: 0 size: 0 align: 0 gran: 0 limit: fffffffff done [DEBUG] PCI: 00:1c.1 io: base: 1000 size: 1000 align: 12 gran: 12 limit: 1fff [INFO ] PCI: 00:1c.1: Resource ranges: [INFO ] * Base: 1000, Size: 1000, Tag: 100 [DEBUG] PCI: 02:00.0 10 * [0x1000 - 0x10ff] limit: 10ff io [DEBUG] PCI: 00:1c.1 io: base: 1000 size: 1000 align: 12 gran: 12 limit: 1fff done [DEBUG] PCI: 00:1c.1 prefmem: base: 82a00000 size: 100000 align: 20 gran: 20 limit: 82afffff [INFO ] PCI: 00:1c.1: Resource ranges: [INFO ] * Base: 82a00000, Size: 100000, Tag: 1200 [DEBUG] PCI: 02:00.0 20 * [0x82a00000 - 0x82a03fff] limit: 82a03fff prefmem [DEBUG] PCI: 02:00.0 18 * [0x82a04000 - 0x82a04fff] limit: 82a04fff prefmem [DEBUG] PCI: 00:1c.1 prefmem: base: 82a00000 size: 100000 align: 20 gran: 20 limit: 82afffff done [INFO ] === Resource allocator: DOMAIN: 0000 - resource allocation complete === [DEBUG] PCI: 00:02.0 10 <- [0x0000000082c00000 - 0x0000000082ffffff] size 0x00400000 gran 0x16 mem64 [DEBUG] PCI: 00:02.0 18 <- [0x0000000090000000 - 0x000000009fffffff] size 0x10000000 gran 0x1c prefmem64 [DEBUG] PCI: 00:02.0 20 <- [0x0000000000002000 - 0x000000000000203f] size 0x00000040 gran 0x06 io [DEBUG] PCI: 00:14.0 10 <- [0x0000000082b00000 - 0x0000000082b0ffff] size 0x00010000 gran 0x10 mem64 [DEBUG] PCI: 00:1a.0 EHCI Debug Port hook triggered [DEBUG] PCI: 00:1a.0 10 <- [0x0000000082b15000 - 0x0000000082b153ff] size 0x00000400 gran 0x0a mem [DEBUG] PCI: 00:1a.0 EHCI Debug Port relocated [DEBUG] PCI: 00:1b.0 10 <- [0x0000000082b10000 - 0x0000000082b13fff] size 0x00004000 gran 0x0e mem64 [DEBUG] PCI: 00:1c.0 1c <- [0x000000000000ffff - 0x000000000000fffe] size 0x00000000 gran 0x0c bus 01 io [DEBUG] PCI: 00:1c.0 24 <- [0xffffffffffffffff - 0xfffffffffffffffe] size 0x00000000 gran 0x14 bus 01 prefmem [DEBUG] PCI: 00:1c.0 20 <- [0x00000000ffffffff - 0x00000000fffffffe] size 0x00000000 gran 0x14 bus 01 mem [DEBUG] PCI: 00:1c.1 1c <- [0x0000000000001000 - 0x0000000000001fff] size 0x00001000 gran 0x0c bus 02 io [DEBUG] PCI: 00:1c.1 24 <- [0x0000000082a00000 - 0x0000000082afffff] size 0x00100000 gran 0x14 bus 02 prefmem [DEBUG] PCI: 00:1c.1 20 <- [0x00000000ffffffff - 0x00000000fffffffe] size 0x00000000 gran 0x14 bus 02 mem [DEBUG] PCI: 02:00.0 10 <- [0x0000000000001000 - 0x00000000000010ff] size 0x00000100 gran 0x08 io [DEBUG] PCI: 02:00.0 18 <- [0x0000000082a04000 - 0x0000000082a04fff] size 0x00001000 gran 0x0c prefmem64 [DEBUG] PCI: 02:00.0 20 <- [0x0000000082a00000 - 0x0000000082a03fff] size 0x00004000 gran 0x0e prefmem64 [DEBUG] PCI: 00:1d.0 10 <- [0x0000000082b16000 - 0x0000000082b163ff] size 0x00000400 gran 0x0a mem [DEBUG] PCI: 00:1e.0 1c <- [0x000000000000ffff - 0x000000000000fffe] size 0x00000000 gran 0x0c bus 03 io [DEBUG] PCI: 00:1e.0 24 <- [0xffffffffffffffff - 0xfffffffffffffffe] size 0x00000000 gran 0x14 bus 03 prefmem [DEBUG] PCI: 00:1e.0 20 <- [0x00000000ffffffff - 0x00000000fffffffe] size 0x00000000 gran 0x14 bus 03 mem [DEBUG] PCI: 00:1f.2 10 <- [0x0000000000002060 - 0x0000000000002067] size 0x00000008 gran 0x03 io [DEBUG] PCI: 00:1f.2 14 <- [0x0000000000002070 - 0x0000000000002073] size 0x00000004 gran 0x02 io [DEBUG] PCI: 00:1f.2 18 <- [0x0000000000002068 - 0x000000000000206f] size 0x00000008 gran 0x03 io [DEBUG] PCI: 00:1f.2 1c <- [0x0000000000002074 - 0x0000000000002077] size 0x00000004 gran 0x02 io [DEBUG] PCI: 00:1f.2 20 <- [0x0000000000002040 - 0x000000000000205f] size 0x00000020 gran 0x05 io [DEBUG] PCI: 00:1f.2 24 <- [0x0000000082b14000 - 0x0000000082b147ff] size 0x00000800 gran 0x0b mem [DEBUG] PCI: 00:1f.3 10 <- [0x0000000082b17000 - 0x0000000082b170ff] size 0x00000100 gran 0x08 mem64 [INFO ] Done setting resources. [INFO ] Done allocating resources. [DEBUG] BS: BS_DEV_RESOURCES run times (exec / console): 1 / 782 ms [INFO ] Enabling resources... [DEBUG] PCI: 00:00.0 subsystem <- 1462/7758 [DEBUG] PCI: 00:00.0 cmd <- 06 [DEBUG] PCI: 00:02.0 subsystem <- 1462/2111 [DEBUG] PCI: 00:02.0 cmd <- 03 [DEBUG] PCI: 00:14.0 subsystem <- 1462/7758 [DEBUG] PCI: 00:14.0 cmd <- 102 [DEBUG] PCI: 00:1a.0 subsystem <- 1462/7758 [DEBUG] PCI: 00:1a.0 cmd <- 106 [DEBUG] PCI: 00:1b.0 subsystem <- 1462/d758 [DEBUG] PCI: 00:1b.0 cmd <- 102 [DEBUG] PCI: 00:1c.0 bridge ctrl <- 0013 [DEBUG] PCI: 00:1c.0 subsystem <- 1462/7758 [DEBUG] PCI: 00:1c.0 cmd <- 100 [DEBUG] PCI: 00:1c.1 bridge ctrl <- 0013 [DEBUG] PCI: 00:1c.1 subsystem <- 1462/7758 [DEBUG] PCI: 00:1c.1 cmd <- 107 [DEBUG] PCI: 00:1d.0 subsystem <- 1462/7758 [DEBUG] PCI: 00:1d.0 cmd <- 102 [DEBUG] PCI: 00:1e.0 bridge ctrl <- 0013 [DEBUG] PCI: 00:1e.0 subsystem <- 1462/7758 [DEBUG] PCI: 00:1e.0 cmd <- 100 [DEBUG] PCI: 00:1f.0 subsystem <- 1462/7758 [DEBUG] PCI: 00:1f.0 cmd <- 107 [DEBUG] PCI: 00:1f.2 subsystem <- 1462/7758 [DEBUG] PCI: 00:1f.2 cmd <- 03 [DEBUG] PCI: 00:1f.3 subsystem <- 1462/7758 [DEBUG] PCI: 00:1f.3 cmd <- 103 [DEBUG] PCI: 02:00.0 cmd <- 03 [INFO ] done. [DEBUG] BS: BS_DEV_ENABLE run times (exec / console): 0 / 122 ms [INFO ] Initializing devices... [DEBUG] CPU_CLUSTER: 0 init [DEBUG] MTRR: Physical address space: [DEBUG] 0x0000000000000000 - 0x000000000009ffff size 0x000a0000 type 6 [DEBUG] 0x00000000000a0000 - 0x00000000000bffff size 0x00020000 type 0 [DEBUG] 0x00000000000c0000 - 0x000000007fffffff size 0x7ff40000 type 6 [DEBUG] 0x0000000080000000 - 0x000000008fffffff size 0x10000000 type 0 [DEBUG] 0x0000000090000000 - 0x000000009fffffff size 0x10000000 type 1 [DEBUG] 0x00000000a0000000 - 0x00000000ffffffff size 0x60000000 type 0 [DEBUG] 0x0000000100000000 - 0x000000027d5fffff size 0x17d600000 type 6 [DEBUG] apic_id 0x0: MTRR: Fixed MSR 0x250 0x0606060606060606 [DEBUG] apic_id 0x0: MTRR: Fixed MSR 0x258 0x0606060606060606 [DEBUG] apic_id 0x0: MTRR: Fixed MSR 0x259 0x0000000000000000 [DEBUG] apic_id 0x0: MTRR: Fixed MSR 0x268 0x0606060606060606 [DEBUG] apic_id 0x0: MTRR: Fixed MSR 0x269 0x0606060606060606 [DEBUG] apic_id 0x0: MTRR: Fixed MSR 0x26a 0x0606060606060606 [DEBUG] apic_id 0x0: MTRR: Fixed MSR 0x26b 0x0606060606060606 [DEBUG] apic_id 0x0: MTRR: Fixed MSR 0x26c 0x0606060606060606 [DEBUG] apic_id 0x0: MTRR: Fixed MSR 0x26d 0x0606060606060606 [DEBUG] apic_id 0x0: MTRR: Fixed MSR 0x26e 0x0606060606060606 [DEBUG] apic_id 0x0: MTRR: Fixed MSR 0x26f 0x0606060606060606 [DEBUG] apic_id 0x0 setup mtrr for CPU physical address size: 36 bits [DEBUG] MTRR: default type WB/UC MTRR counts: 4/4. [DEBUG] MTRR: UC selected as default type. [DEBUG] MTRR: 0 base 0x0000000000000000 mask 0x0000000f80000000 type 6 [DEBUG] MTRR: 1 base 0x0000000090000000 mask 0x0000000ff0000000 type 1 [DEBUG] MTRR: 2 base 0x0000000100000000 mask 0x0000000f00000000 type 6 [DEBUG] MTRR: 3 base 0x0000000200000000 mask 0x0000000f80000000 type 6 [DEBUG] MTRR check [DEBUG] Fixed MTRRs : Enabled [DEBUG] Variable MTRRs: Enabled [DEBUG] CPU has 2 cores, 4 threads enabled. [DEBUG] Setting up SMI for CPU [INFO ] Will perform SMM setup. [DEBUG] FMAP: area COREBOOT found @ e50200 (1768960 bytes) [INFO ] CBFS: Found 'cpu_microcode_blob.bin' @0x18200 size 0x6800 in mcache @0x7fffe98c [DEBUG] microcode: sig=0x306a9 pf=0x2 revision=0x21 [INFO ] CPU: Intel(R) Core(TM) i3-3220 CPU @ 3.30GHz. [INFO ] LAPIC 0x0 in XAPIC mode. [DEBUG] CPU: APIC: 00 enabled [DEBUG] CPU: APIC: 01 enabled [DEBUG] CPU: APIC: 02 enabled [DEBUG] CPU: APIC: 03 enabled [DEBUG] Loading module at 0x00030000 with entry 0x00030000. filesize: 0x178 memsize: 0x178 [DEBUG] Processing 16 relocs. Offset value of 0x00030000 [DEBUG] Attempting to start 3 APs [DEBUG] Waiting for 10ms after sending INIT. [DEBUG] Waiting for SIPI to complete... [INFO ] LAPIC 0x1 in XAPIC mode. [DEBUG] done. [INFO ] AP: slot 1 apic_id 1, MCU rev: 0x00000021 [INFO ] LAPIC 0x2 in XAPIC mode. [INFO ] LAPIC 0x3 in XAPIC mode. [INFO ] AP: slot 3 apic_id 2, MCU rev: 0x00000021 [DEBUG] Waiting for SIPI to complete... [DEBUG] done. [INFO ] AP: slot 2 apic_id 3, MCU rev: 0x00000021 [DEBUG] Loading module at 0x00038000 with entry 0x00038000. filesize: 0x1e8 memsize: 0x1e8 [DEBUG] Processing 11 relocs. Offset value of 0x00038000 [DEBUG] smm_module_setup_stub: stack_top = 0x80001000 [DEBUG] smm_module_setup_stub: per cpu stack_size = 0x400 [DEBUG] smm_module_setup_stub: runtime.start32_offset = 0x4c [DEBUG] smm_module_setup_stub: runtime.smm_size = 0x10000 [DEBUG] SMM Module: stub loaded at 38000. Will call 0x7ffa0131 [DEBUG] Installing permanent SMM handler to 0x80000000 [DEBUG] FX_SAVE [0x802ff800-0x80300000] [DEBUG] HANDLER [0x802fb000-0x802ff268] [DEBUG] CPU 0 [DEBUG] ss0 [0x802fac00-0x802fb000] [DEBUG] stub0 [0x802f3000-0x802f31e8] [DEBUG] CPU 1 [DEBUG] ss1 [0x802fa800-0x802fac00] [DEBUG] stub1 [0x802f2c00-0x802f2de8] [DEBUG] CPU 2 [DEBUG] ss2 [0x802fa400-0x802fa800] [DEBUG] stub2 [0x802f2800-0x802f29e8] [DEBUG] CPU 3 [DEBUG] ss3 [0x802fa000-0x802fa400] [DEBUG] stub3 [0x802f2400-0x802f25e8] [DEBUG] stacks [0x80000000-0x80001000] [DEBUG] Loading module at 0x802fb000 with entry 0x802fbb88. filesize: 0x4150 memsize: 0x4268 [DEBUG] Processing 256 relocs. Offset value of 0x802fb000 [DEBUG] Loading module at 0x802f3000 with entry 0x802f3000. filesize: 0x1e8 memsize: 0x1e8 [DEBUG] Processing 11 relocs. Offset value of 0x802f3000 [DEBUG] smm_module_setup_stub: stack_top = 0x80001000 [DEBUG] smm_module_setup_stub: per cpu stack_size = 0x400 [DEBUG] smm_module_setup_stub: runtime.start32_offset = 0x4c [DEBUG] smm_module_setup_stub: runtime.smm_size = 0x300000 [DEBUG] SMM Module: placing smm entry code at 802f2c00, cpu # 0x1 [DEBUG] SMM Module: placing smm entry code at 802f2800, cpu # 0x2 [DEBUG] SMM Module: placing smm entry code at 802f2400, cpu # 0x3 [DEBUG] SMM Module: stub loaded at 802f3000. Will call 0x802fbb88 [INFO ] smm_do_relocation : curr_smbase 0x30000 perm_smbase 0x802eb000, cpu = 0 [DEBUG] In relocation handler: cpu 0 [DEBUG] New SMBASE=0x802eb000 IEDBASE=0x80400000 [DEBUG] Writing SMRR. base = 0x80000006, mask=0xff800800 [DEBUG] Relocation complete. [INFO ] microcode: Update skipped, already up-to-date [INFO ] smm_do_relocation : curr_smbase 0x30000 perm_smbase 0x802eac00, cpu = 1 [DEBUG] In relocation handler: cpu 1 [DEBUG] New SMBASE=0x802eac00 IEDBASE=0x80400000 [DEBUG] Writing SMRR. base = 0x80000006, mask=0xff800800 [DEBUG] Relocation complete. [INFO ] microcode: Update skipped, already up-to-date [INFO ] smm_do_relocation : curr_smbase 0x30000 perm_smbase 0x802ea800, cpu = 2 [DEBUG] In relocation handler: cpu 2 [DEBUG] New SMBASE=0x802ea800 IEDBASE=0x80400000 [DEBUG] Writing SMRR. base = 0x80000006, mask=0xff800800 [DEBUG] Relocation complete. [INFO ] microcode: Update skipped, already up-to-date [INFO ] smm_do_relocation : curr_smbase 0x30000 perm_smbase 0x802ea400, cpu = 3 [DEBUG] In relocation handler: cpu 3 [DEBUG] New SMBASE=0x802ea400 IEDBASE=0x80400000 [DEBUG] Writing SMRR. base = 0x80000006, mask=0xff800800 [DEBUG] Relocation complete. [INFO ] microcode: Update skipped, already up-to-date [INFO ] Initializing CPU #0 [DEBUG] CPU: vendor Intel device 306a9 [DEBUG] CPU: family 06, model 3a, stepping 09 [INFO ] CPU: Intel(R) Core(TM) i3-3220 CPU @ 3.30GHz. [INFO ] CPU: platform id 1 [INFO ] CPU: cpuid(1) 0x306a9 [INFO ] CPU: AES NOT supported [INFO ] CPU: TXT NOT supported [INFO ] CPU: VT supported [DEBUG] IA32_FEATURE_CONTROL already locked; VMX status: enabled [DEBUG] IA32_FEATURE_CONTROL already locked [DEBUG] cpu: energy policy set to 6 [DEBUG] model_x06ax: frequency set to 3300 [INFO ] Turbo is unavailable [INFO ] CPU #0 initialized [INFO ] Initializing CPU #1 [INFO ] Initializing CPU #3 [INFO ] Initializing CPU #2 [DEBUG] CPU: vendor Intel device 306a9 [DEBUG] CPU: family 06, model 3a, stepping 09 [DEBUG] CPU: vendor Intel device 306a9 [DEBUG] CPU: family 06, model 3a, stepping 09 [INFO ] CPU: Intel(R) Core(TM) i3-3220 CPU @ 3.30GHz. [INFO ] CPU: Intel(R) Core(TM) i3-3220 CPU @ 3.30GHz. [INFO ] CPU: platform id 1 [INFO ] CPU: platform id 1 [INFO ] CPU: cpuid(1) 0x306a9 [INFO ] CPU: cpuid(1) 0x306a9 [INFO ] CPU: AES NOT supported [INFO ] CPU: TXT NOT supported [INFO ] CPU: VT supported [INFO ] CPU: AES NOT supported [INFO ] CPU: TXT NOT supported [INFO ] CPU: VT supported [DEBUG] IA32_FEATURE_CONTROL already locked; VMX status: enabled [DEBUG] IA32_FEATURE_CONTROL already locked; VMX status: enabled [DEBUG] IA32_FEATURE_CONTROL already locked [DEBUG] IA32_FEATURE_CONTROL already locked [DEBUG] cpu: energy policy set to 6 [DEBUG] cpu: energy policy set to 6 [DEBUG] model_x06ax: frequency set to 3300 [INFO ] CPU #3 initialized [DEBUG] model_x06ax: frequency set to 3300 [INFO ] CPU #2 initialized [DEBUG] CPU: vendor Intel device 306a9 [DEBUG] CPU: family 06, model 3a, stepping 09 [INFO ] CPU: Intel(R) Core(TM) i3-3220 CPU @ 3.30GHz. [INFO ] CPU: platform id 1 [INFO ] CPU: cpuid(1) 0x306a9 [INFO ] CPU: AES NOT supported [INFO ] CPU: TXT NOT supported [INFO ] CPU: VT supported [DEBUG] IA32_FEATURE_CONTROL already locked; VMX status: enabled [DEBUG] IA32_FEATURE_CONTROL already locked [DEBUG] cpu: energy policy set to 6 [DEBUG] model_x06ax: frequency set to 3300 [INFO ] CPU #1 initialized [INFO ] bsp_do_flight_plan done after 558 msecs. [DEBUG] SMI_STS: [DEBUG] GPE0_STS: GPIO14 GPIO11 GPIO10 GPIO9 GPIO1 GPIO0 [DEBUG] ALT_GP_SMI_STS: GPI14 GPI13 GPI11 GPI10 GPI9 GPI5 GPI4 GPI3 GPI2 GPI1 GPI0 [DEBUG] TCO_STS: [DEBUG] Locking SMM. [DEBUG] CPU_CLUSTER: 0 init finished in 886 msecs [DEBUG] PCI: 00:00.0 init [DEBUG] Disabling PEG12. [DEBUG] Disabling PEG11. [DEBUG] Disabling PEG10. [DEBUG] Disabling Device 4. [DEBUG] Disabling PEG60. [DEBUG] Disabling Device 7. [DEBUG] Disabling PEG IO clock. [DEBUG] Set BIOS_RESET_CPL [DEBUG] CPU TDP: 55 Watts [DEBUG] PCI: 00:00.0 init finished in 29 msecs [DEBUG] PCI: 00:02.0 init [WARN ] CBFS: 'vbt.bin' not found. [WARN ] CBFS: 'pci8086,0152.rom' not found. [WARN ] CBFS: 'pci8086,0106.rom' not found. [DEBUG] PCI Option ROM loading disabled for PCI: 00:02.0 [DEBUG] GMA: locate_vbt_vbios: 76a2 280b 49 db 97 [7m[ERROR] GMA: VBT couldn't be found [DEBUG] GT Power Management Init [DEBUG] IVB GT1 Power Meter Weights [DEBUG] GT Power Management Init (post VBIOS) [INFO ] framebuffer_info: bytes_per_line: 5504, bits_per_pixel: 32 [INFO ] x_res x y_res: 1366 x 768, size: 4227072 at 0x90000000 [DEBUG] PCI: 00:02.0 init finished in 65 msecs [DEBUG] PCI: 00:14.0 init [DEBUG] XHCI: Setting up controller.. done. [DEBUG] PCI: 00:14.0 init finished in 4 msecs [DEBUG] PCI: 00:1a.0 init [DEBUG] EHCI: Setting up controller.. done. [DEBUG] PCI: 00:1a.0 init finished in 4 msecs [DEBUG] PCI: 00:1b.0 init [DEBUG] Azalia: base = 0x82b10000 [DEBUG] Azalia: codec_mask = 09 [DEBUG] azalia_audio: Initializing codec #3 [DEBUG] azalia_audio: codec viddid: 80862806 [DEBUG] azalia_audio: verb_size: 16 [DEBUG] azalia_audio: verb loaded. [DEBUG] azalia_audio: Initializing codec #0 [DEBUG] azalia_audio: codec viddid: 10ec0887 [DEBUG] azalia_audio: verb_size: 60 [DEBUG] azalia_audio: verb loaded. [DEBUG] PCI: 00:1b.0 init finished in 46 msecs [DEBUG] PCI: 00:1c.0 init [DEBUG] Initializing PCH PCIe bridge. [DEBUG] PCI: 00:1c.0 init finished in 4 msecs [DEBUG] PCI: 00:1c.1 init [DEBUG] Initializing PCH PCIe bridge. [DEBUG] PCI: 00:1c.1 init finished in 4 msecs [DEBUG] PCI: 00:1d.0 init [DEBUG] EHCI: Setting up controller.. done. [DEBUG] PCI: 00:1d.0 init finished in 4 msecs [DEBUG] PCI: 00:1e.0 init [DEBUG] PCI init. [DEBUG] PCI: 00:1e.0 init finished in 2 msecs [DEBUG] PCI: 00:1f.0 init [DEBUG] pch: lpc_init [INFO ] PCH: detected B75, device id: 0x1e49, rev id 0x4 [DEBUG] IOAPIC: Initializing IOAPIC at 0xfec00000 [DEBUG] IOAPIC: 24 interrupts [DEBUG] IOAPIC: Clearing IOAPIC at 0xfec00000 [DEBUG] IOAPIC: Bootstrap Processor Local APIC = 0x00 [INFO ] Set power off after power failure. [INFO ] NMI sources disabled. [DEBUG] PantherPoint PM init [DEBUG] RTC: failed = 0x0 [DEBUG] RTC Init [DEBUG] apm_control: Disabling ACPI. [DEBUG] APMC done. [DEBUG] pch_spi_init [DEBUG] PCI: 00:1f.0 init finished in 53 msecs [DEBUG] PCI: 00:1f.2 init [DEBUG] SATA: Initializing... [DEBUG] SATA: Controller in AHCI mode. [DEBUG] ABAR: 0x82b14000 [DEBUG] PCI: 00:1f.2 init finished in 10 msecs [DEBUG] PCI: 00:1f.3 init [DEBUG] PCI: 00:1f.3 init finished in 0 msecs [DEBUG] PCI: 02:00.0 init [DEBUG] PCI: 02:00.0 init finished in 0 msecs [INFO ] Devices initialized [DEBUG] BS: BS_DEV_INIT run times (exec / console): 324 / 912 ms [DEBUG] FMAP: area SMMSTORE found @ e10000 (262144 bytes) [INFO ] Manufacturer: c2 [INFO ] SF: Detected c2 2018 with sector size 0x1000, total 0x1000000 [DEBUG] smm store: 4 # blocks with size 0x10000 [INFO ] SMMSTORE: Setting up SMI handler [DEBUG] BS: BS_DEV_INIT exit times (exec / console): 0 / 25 ms [INFO ] Finalize devices... [DEBUG] PCI: 00:1f.0 final [DEBUG] apm_control: Finalizing SMM. [DEBUG] APMC done. [INFO ] Devices finalized [DEBUG] BS: BS_POST_DEVICE run times (exec / console): 0 / 16 ms [INFO ] CBFS: Found 'fallback/dsdt.aml' @0x3c280 size 0x24e7 in mcache @0x7fffea88 [WARN ] CBFS: 'fallback/slic' not found. [INFO ] ACPI: Writing ACPI tables at 7ff36000. [DEBUG] ACPI: * FACS [DEBUG] ACPI: * DSDT [DEBUG] ACPI: * FADT [DEBUG] ACPI: added table 1/32, length now 40 [DEBUG] ACPI: * SSDT [DEBUG] Found 1 CPU(s) with 4 core(s) each. [DEBUG] PSS: 3300MHz power 55000 control 0x2100 status 0x2100 [DEBUG] PSS: 2800MHz power 43981 control 0x1c00 status 0x1c00 [DEBUG] PSS: 2400MHz power 35986 control 0x1800 status 0x1800 [DEBUG] PSS: 2000MHz power 28563 control 0x1400 status 0x1400 [DEBUG] PSS: 1600MHz power 21721 control 0x1000 status 0x1000 [DEBUG] PSS: 3300MHz power 55000 control 0x2100 status 0x2100 [DEBUG] PSS: 2800MHz power 43981 control 0x1c00 status 0x1c00 [DEBUG] PSS: 2400MHz power 35986 control 0x1800 status 0x1800 [DEBUG] PSS: 2000MHz power 28563 control 0x1400 status 0x1400 [DEBUG] PSS: 1600MHz power 21721 control 0x1000 status 0x1000 [DEBUG] PSS: 3300MHz power 55000 control 0x2100 status 0x2100 [DEBUG] PSS: 2800MHz power 43981 control 0x1c00 status 0x1c00 [DEBUG] PSS: 2400MHz power 35986 control 0x1800 status 0x1800 [DEBUG] PSS: 2000MHz power 28563 control 0x1400 status 0x1400 [DEBUG] PSS: 1600MHz power 21721 control 0x1000 status 0x1000 [DEBUG] PSS: 3300MHz power 55000 control 0x2100 status 0x2100 [DEBUG] PSS: 2800MHz power 43981 control 0x1c00 status 0x1c00 [DEBUG] PSS: 2400MHz power 35986 control 0x1800 status 0x1800 [DEBUG] PSS: 2000MHz power 28563 control 0x1400 status 0x1400 [DEBUG] PSS: 1600MHz power 21721 control 0x1000 status 0x1000 [DEBUG] PCI space above 4GB MMIO is at 0x27d600000, len = 0xd82a00000 [DEBUG] Generating ACPI PIRQ entries [DEBUG] ACPI: added table 2/32, length now 44 [DEBUG] ACPI: * MCFG [DEBUG] ACPI: added table 3/32, length now 48 [DEBUG] ACPI: * MADT [DEBUG] IOAPIC: 24 interrupts [DEBUG] ACPI: added table 4/32, length now 52 [DEBUG] current = 7ff39d40 [DEBUG] ACPI: * HPET [DEBUG] ACPI: added table 5/32, length now 56 [INFO ] ACPI: done. [DEBUG] ACPI tables: 15744 bytes. [DEBUG] smbios_write_tables: 7ff2e000 [DEBUG] SMBIOS firmware version is set to coreboot_version: '4.19-424-geba1a35402-dirty' [INFO ] Create SMBIOS type 16 [INFO ] Create SMBIOS type 17 [INFO ] Create SMBIOS type 20 [DEBUG] SMBIOS tables: 803 bytes. [DEBUG] Writing table forward entry at 0x00000500 [DEBUG] Wrote coreboot table at: 0x00000500, 0x10 bytes, checksum dfe8 [DEBUG] Writing coreboot table at 0x7ff5a000 [DEBUG] 0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES [DEBUG] 1. 0000000000001000-000000000009ffff: RAM [DEBUG] 2. 00000000000a0000-00000000000fffff: RESERVED [DEBUG] 3. 0000000000100000-000000007ff2dfff: RAM [DEBUG] 4. 000000007ff2e000-000000007ff82fff: CONFIGURATION TABLES [DEBUG] 5. 000000007ff83000-000000007ffcefff: RAMSTAGE [DEBUG] 6. 000000007ffcf000-000000007fffffff: CONFIGURATION TABLES [DEBUG] 7. 0000000080000000-00000000829fffff: RESERVED [DEBUG] 8. 00000000f0000000-00000000f3ffffff: RESERVED [DEBUG] 9. 0000000100000000-000000027d5fffff: RAM [DEBUG] Wrote coreboot table at: 0x7ff5a000, 0x3fc bytes, checksum a64c [DEBUG] coreboot table: 1044 bytes. [DEBUG] IMD ROOT 0. 0x7ffff000 0x00001000 [DEBUG] IMD SMALL 1. 0x7fffe000 0x00001000 [DEBUG] CONSOLE 2. 0x7ffde000 0x00020000 [DEBUG] TIME STAMP 3. 0x7ffdd000 0x00000910 [DEBUG] MEM INFO 4. 0x7ffdc000 0x000007a8 [DEBUG] AFTER CAR 5. 0x7ffcf000 0x0000d000 [DEBUG] RAMSTAGE 6. 0x7ff82000 0x0004d000 [DEBUG] SMM BACKUP 7. 0x7ff72000 0x00010000 [DEBUG] SMM COMBUFFER 8. 0x7ff62000 0x00010000 [DEBUG] COREBOOT 9. 0x7ff5a000 0x00008000 [DEBUG] ACPI 10. 0x7ff36000 0x00024000 [DEBUG] SMBIOS 11. 0x7ff2e000 0x00008000 [DEBUG] IMD small region: [DEBUG] IMD ROOT 0. 0x7fffec00 0x00000400 [DEBUG] USBDEBUG 1. 0x7fffeba0 0x00000050 [DEBUG] RO MCACHE 2. 0x7fffe8e0 0x000002ac [DEBUG] FMAP 3. 0x7fffe7c0 0x0000010a [DEBUG] ROMSTAGE 4. 0x7fffe7a0 0x00000004 [DEBUG] ROMSTG STCK 5. 0x7fffe6e0 0x000000a8 [DEBUG] ACPI GNVS 6. 0x7fffe5e0 0x00000100 [DEBUG] BS: BS_WRITE_TABLES run times (exec / console): 2 / 424 ms [INFO ] CBFS: Found 'fallback/payload' @0x44700 size 0xbed49 in mcache @0x7fffeaf8 [DEBUG] Checking segment from ROM address 0xffe9492c [DEBUG] Checking segment from ROM address 0xffe94948 [DEBUG] Loading segment from ROM address 0xffe9492c [DEBUG] code (compression=1) [DEBUG] New segment dstaddr 0x00800000 memsize 0x590000 srcaddr 0xffe94964 filesize 0xbed11 [DEBUG] Loading Segment: addr: 0x00800000 memsz: 0x0000000000590000 filesz: 0x00000000000bed11 [DEBUG] using LZMA [DEBUG] Loading segment from ROM address 0xffe94948 [DEBUG] Entry Point 0x00801626 [DEBUG] BS: BS_PAYLOAD_LOAD run times (exec / console): 209 / 57 ms [DEBUG] ICH-NM10-PCH: watchdog disabled [DEBUG] Jumping to boot code at 0x00801626(0x7ff5a000) ``` There are actually two identical memory modules. ``` shell sudo ./inteltool -m CPU: ID 0x306a9, Processor Type 0x0, Family 0x6, Model 0x3a, Stepping 0x9 Northbridge: 8086:0150 (3rd generation (Ivy Bridge family) Core Processor (Desktop)) Southbridge: 8086:1e49 (B75) IGD: 8086:0152 (Intel(R) HD 2500 Graphics) ============= MCHBAR ============ MCHBAR = 0xfed10000 (MEM) 0x0004: 0x00001d70 0x0008: 0x00000206 0x000c: 0x00052a1b 0x0010: 0x0210222c 0x0014: 0x02002230 0x0020: 0x00018a25 0x0024: 0x00018a24 0x0030: 0x000000ff 0x0034: 0x00001011 0x0104: 0x00001d70 0x0108: 0x00000206 0x010c: 0x00052a1b 0x0110: 0x02502501 0x0114: 0x02402603 0x0120: 0x00018d25 0x0124: 0x00019029 0x0130: 0x000000ff 0x0134: 0x00001011 0x0204: 0x00001d70 0x0208: 0x00000206 0x020c: 0x00052a1b 0x0210: 0x0200233a 0x0214: 0x0200223b 0x0220: 0x00019c38 0x0224: 0x00019c3a 0x0230: 0x000000ff 0x0234: 0x00001011 0x0304: 0x00001d70 0x0308: 0x00000206 0x030c: 0x00052a1b 0x0310: 0x02202614 0x0314: 0x02402616 0x0320: 0x0001a03b 0x0324: 0x0001a33d 0x0330: 0x000000ff 0x0334: 0x00001011 0x0404: 0xffffffff 0x0408: 0x0000ffff 0x040c: 0x00052a1b 0x0410: 0x02012214 0x0414: 0x02012015 0x0420: 0x0009ae0b 0x0424: 0x0009b10e 0x0430: 0x000000ff 0x0434: 0x00001011 0x0504: 0xffffffff 0x0508: 0x0000ffff 0x050c: 0x00052a1b 0x0510: 0x02202525 0x0514: 0x02102628 0x0520: 0x0009b20c 0x0524: 0x0009b812 0x0530: 0x000000ff 0x0534: 0x00001011 0x0604: 0xffffffff 0x0608: 0x0000ffff 0x060c: 0x00052a1b 0x0610: 0x02212322 0x0614: 0x02112027 0x0620: 0x0009b712 0x0624: 0x0009b916 0x0630: 0x000000ff 0x0634: 0x00001011 0x0704: 0xffffffff 0x070c: 0x00052a1b 0x0710: 0x02402434 0x0714: 0x0230253b 0x0720: 0x0002031c 0x0724: 0x0002051f 0x0730: 0x000000ff 0x0734: 0x00001011 0x080c: 0x00052a1b 0x0830: 0x000000ff 0x0834: 0x00001011 0x090c: 0x00052a1b 0x0930: 0x000000ff 0x0934: 0x00001011 0x0a00: 0x00000003 0x0a04: 0x00064207 0x0a08: 0x00063a0e 0x0a0c: 0x01fe4048 0x0a10: 0x00003fff 0x0b00: 0x00000003 0x0b04: 0x00064207 0x0b08: 0x00063a0e 0x0b0c: 0x01fe4002 0x0b10: 0x00003fff 0x0c00: 0x00000003 0x0c04: 0x00063a10 0x0c14: 0x032cb30e 0x0c1c: 0x000002ff 0x0c20: 0x0000ff00 0x0c34: 0x00001011 0x0d00: 0x00000003 0x0d04: 0x00063a10 0x0d14: 0x032cb30c 0x0d1c: 0x000002ff 0x0d20: 0x0000ffff 0x0d34: 0x00001011 0x0e00: 0x00000003 0x0e04: 0x00064207 0x0e08: 0x00063a0e 0x0e0c: 0x01fe4048 0x0e10: 0x00003fff 0x0f00: 0x00000003 0x0f04: 0x00064207 0x0f08: 0x00063a0e 0x0f0c: 0x01fe4002 0x0f10: 0x00003fff 0x1004: 0xffffffff 0x100c: 0x00052a1b 0x1010: 0x02012036 0x1014: 0x01f12133 0x1020: 0x00020c29 0x1024: 0x00020d2a 0x1030: 0x000000ff 0x1034: 0x00001011 0x1104: 0xffffffff 0x110c: 0x00052a1b 0x1110: 0x02112406 0x1114: 0x0231230b 0x1120: 0x0002122e 0x1124: 0x00021835 0x1130: 0x000000ff 0x1134: 0x00001011 0x1204: 0xffffffff 0x120c: 0x00052a1b 0x1210: 0x01f1237e 0x1214: 0x0211233f 0x1220: 0x00021935 0x1224: 0x00021835 0x1230: 0x000000ff 0x1234: 0x00001011 0x1304: 0xffffffff 0x130c: 0x00052a1b 0x1310: 0x02312415 0x1314: 0x02412219 0x1320: 0x0002243d 0x1324: 0x0002253f 0x1330: 0x000000ff 0x1334: 0x00001011 0x1404: 0xffffffff 0x140c: 0x00052a1b 0x1410: 0x02022315 0x1414: 0x02022215 0x1420: 0x0002253f 0x1424: 0x000a2703 0x1430: 0x000000ff 0x1434: 0x00001011 0x1504: 0xffffffff 0x150c: 0x00052a1b 0x1510: 0x02312323 0x1514: 0x0211222a 0x1520: 0x000a2804 0x1524: 0x000a2f0a 0x1530: 0x000000ff 0x1534: 0x00001011 0x1604: 0xffffffff 0x160c: 0x00052a1b 0x1610: 0x02222122 0x1614: 0x02122221 0x1620: 0x000a2b05 0x1624: 0x000a2d0a 0x1630: 0x000000ff 0x1634: 0x00001011 0x1704: 0xffffffff 0x170c: 0x00052a1b 0x1710: 0x02112330 0x1714: 0x01e12633 0x1720: 0x000a3915 0x1724: 0x000a3b18 0x1730: 0x000000ff 0x1734: 0x00001011 0x1810: 0x24914924 0x1814: 0x0c6671e4 0x1818: 0x00000400 0x1910: 0x24914924 0x1914: 0x0c6671e4 0x1918: 0x00000400 0x4000: 0x001c8bbb 0x4004: 0x0c187476 0x4008: 0x0a042220 0x400c: 0x000058b4 0x401c: 0x00100000 0x4020: 0x00100005 0x4024: 0x20202828 0x4028: 0x000e0033 0x4034: 0x0000d7c9 0x4038: 0x8376a9fa 0x403c: 0x4e83c351 0x4044: 0x000000ff 0x4048: 0x00000000 0x4054: 0x000000ff 0x4058: 0x000000ff 0x405c: 0x000000ff 0x4060: 0x000000ff 0x40a8: 0x01000040 0x40ac: 0x00000040 0x40b0: 0x00000240 0x40b4: 0xffffffff 0x40b8: 0x00040000 0x40d4: 0x00000046 0x4160: 0x00000000 0x4200: 0x01460000 0x4204: 0x01000320 0x4208: 0x01000320 0x420c: 0x01060400 0x4210: 0x00000244 0x4214: 0x00000242 0x4218: 0x00000242 0x421c: 0x00000240 0x4220: 0x0001f006 0x4224: 0x0001f201 0x4228: 0x0001f105 0x422c: 0x0001f002 0x4230: 0x00282004 0x4234: 0x08281064 0x4238: 0x04281064 0x423c: 0x00280c01 0x4244: 0x000407e3 0x4248: 0x000407e3 0x4270: 0xeb19b77e 0x4274: 0xc40f374c 0x4284: 0x000c0000 0x428c: 0x00000044 0x4290: 0x00004080 0x4294: 0x0000980f 0x4298: 0x6cf01860 0x429c: 0x00004218 0x42a0: 0x00001003 0x42a4: 0x41f88200 0x42ac: 0x00000001 0x4364: 0x000ddfd2 0x4380: 0x00000aaa 0x4384: 0x009b6ea1 0x4388: 0x5f7003ff 0x438c: 0x551d1519 0x4400: 0x001c8bbb 0x4404: 0x0c187476 0x4408: 0x0a042220 0x440c: 0x000058b4 0x441c: 0x00100000 0x4420: 0x00100005 0x4424: 0x20202828 0x4428: 0x000e0022 0x4434: 0x0000f9f9 0x4438: 0x74c97d3d 0x443c: 0x58bc1fba 0x4448: 0x000000ff 0x444c: 0x000000ff 0x44a8: 0x01000040 0x44ac: 0x00000040 0x44b0: 0x00000240 0x44b4: 0xffffffff 0x44b8: 0x00040000 0x44d4: 0x00000046 0x4600: 0x01460000 0x4604: 0x01000320 0x4608: 0x01000320 0x460c: 0x01060400 0x4610: 0x00000244 0x4614: 0x00000242 0x4618: 0x00000242 0x461c: 0x00000240 0x4620: 0x0001f006 0x4624: 0x0001f201 0x4628: 0x0001f105 0x462c: 0x0001f002 0x4630: 0x00282004 0x4634: 0x08281064 0x4638: 0x04281064 0x463c: 0x00280c01 0x4644: 0x000407e3 0x4648: 0x000407e3 0x4670: 0xe389d4d6 0x4674: 0xb52d7f5e 0x4684: 0x000c0000 0x468c: 0x00000044 0x4690: 0x00004080 0x4694: 0x0000980f 0x4698: 0x6cf01860 0x469c: 0x00004218 0x46a0: 0x00001003 0x46a4: 0x41f88200 0x46ac: 0x00000002 0x4760: 0x000002bc 0x4764: 0x000c4e2a 0x4780: 0x00000aaa 0x4784: 0x009b6ea1 0x4788: 0x5f7003ff 0x478c: 0x551d1519 0x4c00: 0x001c8bbb 0x4c04: 0x0c187476 0x4c08: 0x0a042220 0x4c0c: 0x000058b4 0x4c1c: 0x00100000 0x4c20: 0x00100005 0x4c24: 0x20202828 0x4c28: 0x000e0033 0x4c34: 0x0000d7c9 0x4c38: 0x8376a9fa 0x4c3c: 0x4e83c351 0x4ca8: 0x01000040 0x4cac: 0x00000040 0x4cb0: 0x00000240 0x4cb4: 0xffffffff 0x4cb8: 0x00040000 0x4cd4: 0x00000046 0x4d48: 0x00000000 0x4e00: 0x01460000 0x4e04: 0x01000320 0x4e08: 0x01000320 0x4e0c: 0x01060400 0x4e10: 0x00000244 0x4e14: 0x00000242 0x4e18: 0x00000242 0x4e1c: 0x00000240 0x4e20: 0x0001f006 0x4e24: 0x0001f201 0x4e28: 0x0001f105 0x4e2c: 0x0001f002 0x4e30: 0x00282004 0x4e34: 0x08281064 0x4e38: 0x04281064 0x4e3c: 0x00280c01 0x4e44: 0x000407e3 0x4e48: 0x000407e3 0x4e70: 0xeb1ba423 0x4e74: 0xc41184af 0x4e84: 0x000c0000 0x4e8c: 0x00000044 0x4e90: 0x00004080 0x4e94: 0x0000980f 0x4e98: 0x6cf01860 0x4e9c: 0x00004218 0x4ea0: 0x00001003 0x4ea4: 0x41f88200 0x4eac: 0x00000001 0x4f64: 0x000ddfd2 0x4f80: 0x00000aaa 0x4f84: 0x009b6ea1 0x4f88: 0x5f7003ff 0x4f8c: 0x551d1519 0x5000: 0x00000024 0x5004: 0x00620020 0x5008: 0x00620020 0x500c: 0x00600000 0x5014: 0x20400000 0x5020: 0x00000006 0x5024: 0x00a030ce 0x5030: 0x0000019f 0x5034: 0x01070000 0x5040: 0x17160c9a 0x5044: 0x766caee7 0x5048: 0x24b543e2 0x5050: 0x7f0a5abb 0x5054: 0x32e68779 0x5058: 0x42b32512 0x5060: 0x000100ff 0x5064: 0x00073193 0x5074: 0x00000010 0x5080: 0x0000201a 0x5084: 0x00010898 0x5094: 0xffffffff 0x50fc: 0x0000008d 0x5418: 0x00000004 0x541c: 0x30000000 0x5500: 0x00100001 0x5880: 0xca9171e7 0x5888: 0x00e4dad0 0x5890: 0x003daf2c 0x5894: 0x003d98b8 0x5924: 0x00000010 0x5928: 0x02ab9264 0x592c: 0x0008636b 0x5930: 0x016001b8 0x5934: 0x000d0000 0x5938: 0x000a1003 0x593c: 0x0aad6c50 0x5940: 0x0008ab29 0x5944: 0x003ab8d8 0x5948: 0x00000700 0x5954: 0x00040000 0x5958: 0xe0012100 0x595c: 0x00081000 0x5960: 0x03c1a3dd 0x5964: 0x8f1d87f9 0x5968: 0x8f1d82e4 0x596c: 0x40cf5adf 0x5970: 0x12c27306 0x5974: 0x12c27304 0x5978: 0x00000017 0x597c: 0x00000017 0x5980: 0x00000016 0x5984: 0xd30f067a 0x5990: 0x000000ff 0x5994: 0x000000ff 0x5998: 0x00070d15 0x599c: 0x00691400 0x59a0: 0x001481b8 0x59a4: 0x00008220 0x59b0: 0x80001fff 0x59b4: 0x18141494 0x59b8: 0x80000190 0x59bc: 0x18141494 0x59c0: 0x88530000 0x5d10: 0x2010040c 0x5d14: 0x80000000 0x5d20: 0x00000005 0x5da8: 0x00000001 0x5e00: 0x00000006 0x5e04: 0x00000006 0x5efc: 0xffff0000 0x5f00: 0x8000270f 0x5f04: 0x7530001a 0x5f08: 0x0000001a 0x5f0c: 0x4e20001a 0x5f10: 0x1f425830 0x5f14: 0x801db100 0x5f18: 0x000000fa 0x5f20: 0x5dc20000 0x5f30: 0x00040001 0x5f38: 0xd2a84b03 0x5f3c: 0x00000021 0x5f44: 0x01600000 0x5f4c: 0x01600000 0x5f50: 0x80000000 0x6000: 0x00000004 0x6008: 0x800000d8 0x6010: 0xfff00000 0x6014: 0x0000007f 0x6020: 0x00000001 0x6030: 0x000700b0 0x6034: 0x000700b0 0x6200: 0x88520000 0x63fc: 0x00000001 0x6410: 0x00000c00 0x6430: 0x00fac688 0x6434: 0x00fac688 0x6800: 0x80000044 0x7000: 0x80444444 0x7030: 0x00000018 0x7400: 0x09249249 0x7404: 0x00120249 0x7408: 0x01ffffff 0x740c: 0xb1207851 0x7410: 0x00000019 0x7500: 0x000f0000 0x7504: 0x000000b0 0x77fc: 0x00000001 0x7800: 0x00444444 0x7804: 0x00004444 0x7ffc: 0x00000001 .tCK = TCK_MHZ800, .rankmap = { 0x3, 0x3 }, .mad_dimm = { 0x620020, 0x620020 }, .mobile = 1, .CAS = 11 /* 11 clocks = 13.750 ns */, .tWR = 12 /* 12 clocks = 15.000 ns */, .reg_4004_b30 = { 0, 0 }, .tFAW = 24 /* 24 clocks = 30.000 ns */, .tWTR = 7 /* 7 clocks = 8.750 ns */, .tCKE = 4 /* 4 clocks = 5.000 ns */, .tRTP = 7 /* 7 clocks = 8.750 ns */, .tRRD = 6 /* 6 clocks = 7.500 ns */, .tRAS = 28 /* 28 clocks = 35.000 ns */, .tCWL = 8 /* 8 clocks = 10.000 ns */, .tRP = 11 /* 11 clocks = 13.750 ns */, .tRCD = 11 /* 11 clocks = 13.750 ns */, .tXPDLL = 20 /* 20 clocks = 25.000 ns */, .tXP = 5 /* 5 clocks = 6.250 ns */, .tAONPD = 8 /* 8 clocks = 10.000 ns */, .tREFI = 6240 /* 6240 clocks = 7800.000 ns */, .tRFC = 240 /* 240 clocks = 300.000 ns */, .tMOD = 12 /* 12 clocks = 15.000 ns */, .tXSOffset = 8 /* 8 clocks = 10.000 ns */, .reg5064b0 = 0x193, .channel_size_mb = { ?, 8192 }, /* CH0S0: 8192 MiB */ /* CH1S0: 8192 MiB */ /* SPD matching current mode: */ /* CH0S0 */ 00: 92 11 0b 03 04 00 00 09 03 52 01 08 0a 00 80 00 10: 6e 78 6e 3c 6e 11 18 81 60 09 46 46 00 f0 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 65 00 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 51 da 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 /* CH1S0 */ 00: 92 11 0b 03 04 00 00 09 03 52 01 08 0a 00 80 00 10: 6e 78 6e 3c 6e 11 18 81 60 09 46 46 00 f0 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 65 00 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 51 da 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ``` -- 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

3 6

[coreboot - Bug #327] MBOX3, OperationRegion (OPRG, SystemMemory, ASLS, 0x2000) causes windows uefi tianocore BSOD ACPI_BIOS_ERROR
by Jason Stewart 19 Feb '23

19 Feb '23

Issue #327 has been updated by Jason Stewart. Know this thread is a bit old, but just wanted to add that this change fixed this issue for me. Just wanted to add some data points regarding my hardware and in hopes that it helps someone else in the future: Sandy Bridge Lenovo W520 + I7 3840QM + Quadro 2000m. No VGA roms were used. ---------------------------------------- Bug #327: MBOX3, OperationRegion (OPRG, SystemMemory, ASLS, 0x2000) causes windows uefi tianocore BSOD ACPI_BIOS_ERROR https://ticket.coreboot.org/issues/327#change-1434 * Author: xinhua wang * Status: New * Priority: Normal * Start date: 2021-12-30 ---------------------------------------- https://review.coreboot.org/c/coreboot/+/27711/7/src/drivers/intel/gma/acpi… this line .. OperationRegion (OPRG, SystemMemory, ASLS, 0x2000) the 0x2000 will cause BSOD ACPI_BIOS_ERROR when booting installer, os, etc When set to 0x1000 windows UEFI tianocore mode boots fine ---Files-------------------------------- dmesg.txt (76.9 KB) results.log (204 KB) -- 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

[coreboot - Bug #463] (New) nvramtool: coreboot table not found on Starbook Mark VI
by Felix Niederwanger 18 Feb '23

18 Feb '23

Issue #463 has been reported by Felix Niederwanger. ---------------------------------------- Bug #463: nvramtool: coreboot table not found on Starbook Mark VI https://ticket.coreboot.org/issues/463 * Author: Felix Niederwanger * Status: New * Priority: Normal * Target version: none * Start date: 2023-02-18 ---------------------------------------- The `nvramtool` on my Starbook Mark VI reports that it can't find the coreboot table: ``` # nvramtool -d nvramtool: coreboot table not found. coreboot does not appear to be installed on this system. Scanning for the table produced the following results: 0 valid signatures were found with bad header checksums. 0 valid headers were found with bad table checksums. ``` I compiled the `nvramtool` freshly on my Laptop using the documentation from -- 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

3 4

[coreboot - Bug #455] (New) superiotool recognizes the wrong chip and doesn't work.
by shen Liu 16 Feb '23

16 Feb '23

Issue #455 has been reported by shen Liu. ---------------------------------------- Bug #455: superiotool recognizes the wrong chip and doesn't work. https://ticket.coreboot.org/issues/455 * Author: shen Liu * Status: New * Priority: Normal * Category: userspace utilities * Target version: master * Start date: 2023-02-07 * Affected versions: master * Needs backport to: none * Related links: More discussion： https://www.reddit.com/r/coreboot/comments/10ud7tk/is_b85me45_ms7817_suppor… https://wiki.archlinux.org/title/Debuginfod * Affected hardware: MSI B85M-E45 * Affected OS: Manjaro Linux 22.0.2 (Kernel ver:6.1.9-1) ---------------------------------------- ``` shell sudo ./superiotool Found Aspeed AST2400 (id=0x00) at 0x4e sudo ./superiotool superiotool r4.19-306-g12ec7901b7 No Super I/O found ``` Does superiotool provide debug symbols? Without debug symbols I can't use gdb to provide more useful information. -- 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

4 7

[coreboot - Feature #461] (New) Replacing Haswell mrc.bin blob with free software
by akjuxr3 akjuxr3 16 Feb '23

16 Feb '23

Issue #461 has been reported by akjuxr3 akjuxr3. ---------------------------------------- Feature #461: Replacing Haswell mrc.bin blob with free software https://ticket.coreboot.org/issues/461 * Author: akjuxr3 akjuxr3 * Status: New * Priority: Normal * Target version: none * Start date: 2023-02-16 * Related links: https://review.coreboot.org/c/coreboot/+/52659 ---------------------------------------- Currently in case of the ability to run as less amount of closed source software as possible and still have Microcode updates the reduced Intel ME with disabled bit in IFD and the lga1155 or the mobile versions of those cpus are the only option for x86_64 out there. The next cpu generation (Haswell) inside for example T440p and W541 require the binary blob mrc.bin Are there any plans of replacing the Haswell mrc.bin with free software? Or have the x86_64 platform be given up when the goal is to run just free software and the people should move to aarch64 or risc-v? -- 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

2 2

[coreboot - Other #314] Please disable 'administrator approval' on ticket.coreboot.org
by akjuxr3 akjuxr3 16 Feb '23

16 Feb '23

Issue #314 has been updated by akjuxr3 akjuxr3. > To be very clear: For the future, I am asking you to think twice before you do such accusations and to write your requests in a polite manner. I do not want to read wrong accusations again, especially when there is not a single proof given. Please define 'polite'. I have not used useless(providing no information) and just emotional words like *hole or any other known slang-wording. The text i wrote is as rational as possible. You write 'wrong accusations'. Could you get in more detail with that? I would really like to know what is wrong. Thats why i use coreboot and free software. I like to 'be able' to get the whole picture at any time. I have the ability and thus the freedom to learn and read the sourcecode and get logfiles. If i have the knowledge and understanding to be able to understand that all is only related on my capabilities i am free to expand by training. When free access to knowledge (books, tutorials, ...) is combined with open source, its then up to the people to use this freedom. I know that this is a privileged point in the recent world, because if you have to deal the whole day to get food to survive or build up your home again after its gone because of some bombing in a war. I hope and would like to see every single human get the ability to get to this privileged point to have the time to deal with open knowledge instead of surviving. But with the registration-procedure there is no sourcecode and a fully and transparent(i am able to read logfiles, prove everything, ...) system approving the registration. Thats why i wrote that in 2021 and wait since then. I would like to know what the 'wrong accusations' are. I love to understand and fix things where i am wrong. I thus split now the accusations in numbers to be as exact as possible to be able to look at everything as rational as possible. 1. I got approved by hand after days waiting. <- this is what i experienced. Is this a wrong accusation? 2. Quote: Have the IP-address used for registration been tracked? <- this was a question that is still unanswered. Its based on a idea what could have been used for the manual approval. Is my idea IP addresses are been used for manual approval a wrong accusation? 3. Quote: Have the used email-address been tracked? <- this was a question that is still unanswered. Its based on a idea what could have been used for the manual approval. Is my idea email-addresses are been used for manual approval a wrong accusation? 3.1 Quote: E-mail-address-discrimination is illegal in many countries and this is completely breaking the freedom of choice! <- This is a legal (net neutrality laws) part of countries. Or is this a 'wrong accusation' you mentioned? 4. Quote: Username? <- this was a question that is still unanswered. Its based on a idea what could have been used for the manual approval. Is the idea usernames are been used for manual approval a wrong accusation? 4.1 Quote: Choosing (user)names is up to the user and making decision based on what names are 'allowed' to enter a platform is the most racist thing possible. <- This is also part of many laws in many countries. Telling a human that the human have the 'wrong name' is in general against many laws. Or is this part of a 'wrong accusation' you mentioned? I hope i would get the ability to understand how this 'administrator approval' is done because i like in general to understand everything and also to have the ability to understand everything. @ Paul Menzel: > do you know of a solution to prevent the creation of spam accounts? Thanks for the productive question. In general i try to first understand everything before i post a idea to something. Thats why i would still like to know what have been done to make this manual administration approval. But here is a answer in before: Prevent spam? No, this is impossible in capitalism. As long as there is a financial benefit of spam, there would always be spam. There should be no prevention. Prevention of anything that affect other people abilities is blocking freedom. Spam should be dealt with as off-topic. If i would ask in this ticket-instance how i could fix my vacuum cleaner (a model that have no firmware - something that have to be told this days) should be handled the same as some capitalistic offer of some pills for peoples private life. There are two common ways implemented by many websites for many years to handle the spam-situation. 1. Let the people register and post without any blockage. If the thing(s) that have been posted was some pills offer or something like this, it gets deleted. In general its easy for administators by selecting the username, delete everything from the user and then delete the registration that is made for posting spam. This solution represent in general the laws in all countries. At first you can (have the ability) to do anything you are capable of. And if a thing you did is not allowed, this thing gets reverted and you get punished if possible/required. Simple example: You want to use your right of free speech. You print stickers and stick them at the train windows. In general this stickers get removed because this is not how you are allowed to represent your right of free speech. 2. A second common implementation on websites is to let people post on the website what they want to post but its unlisted until the written post get approved. This is not in common with the laws in many free countries (it would be completely wrong in a democratic country if your words you want to say and your banners you want to show would have to be approved from the government first). But this is somewhat a not that great but ok'ish implementation on the internet. To compare what is recently implemented on this site (to my understanding, i still have no answers to the questions i asked in year 2021): 3. A person (and not what the person want to say, there is nothing the person have written to base the approval-decision on) is been checked. The decision if the person is allowed to fill up a bug for coreboot is done by checking the identity of the person (name), the area the person is from (IP-address) and the service the person is using (email address). This is by far the worst implementation possible. To give abilities (free speech) to people based on where they are from or what name they have is so bad, there is not a single more worse implementation of a system possible. There are history examples in Europe about 75 years ago. There decisions was made based on what name a human had and where the human was from. If the decision is made on the entered email address, this is still terrible. Net neutrality is a extremely important thing. There should never ever be made a decision based on if some other person like the e-mail provider that is been used for registration or not. Such decision break for example completely the federated, open idea e-mail is based on. ---------------------------------------- Other #314: Please disable 'administrator approval' on ticket.coreboot.org https://ticket.coreboot.org/issues/314#change-1422 * Author: akjuxr3 akjuxr3 * Status: Closed (locked) * Priority: Normal * Category: infrastructure * Start date: 2021-07-30 ---------------------------------------- Please disable this 'administrator approval' on ticket.coreboot.org. It feels like discrimination. Before i have written the first word on ticket.coreboot.org i have to be approved by someone by hand without this person knowing anything from me. I had to wait several days for this approval. Its completely unclear what is been tracked. Have the IP-address used for registration been tracked? Have the used email-address been tracked? E-mail-address-discrimination is illegal in many countries and this is completely breaking the freedom of choice! Username? Choosing (user)names is up to the user and making decision based on what names are 'allowed' to enter a platform is the most racist thing possible. Conclusion: This 'administrator approval' is sort of discrimination i have not seen for years on free projects! There is no data available at the registration process that could or should be used to decide who is allowed to report a bug in the coreboot project. Please disable this discrimination that is stopping people for days or even forever to report a coreboot issue. -- 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

[coreboot - Bug #456] (New) coreboot 4.19 tarballs are unusable
by Thierry Laurion 15 Feb '23

15 Feb '23

Issue #456 has been reported by Thierry Laurion. ---------------------------------------- Bug #456: coreboot 4.19 tarballs are unusable https://ticket.coreboot.org/issues/456 * Author: Thierry Laurion * Status: New * Priority: High * Category: infrastructure * Target version: 4.19 * Start date: 2023-02-08 * Affected versions: 4.19, master * Needs backport to: 4.19, master ---------------------------------------- As reported on #coreboot channel, coreboot 4.19 tarballs contain invalid timestamps (year 1901) for all contained files. Reproducility of issue: wget https://www.coreboot.org/releases/coreboot-4.19.tar.xz user@heads-tests:/tmp/test$ ls -al coreboot-4.19.tar.xz -rw-r--r-- 1 user user 56908588 Jan 26 21:46 coreboot-4.19.tar.xz user@heads-tests:/tmp/test$ tar Jxvf coreboot-4.19.tar.xz coreboot-4.19/ coreboot-4.19/.checkpatch.conf tar: coreboot-4.19/.checkpatch.conf: implausibly old time stamp -9223372036854775808 coreboot-4.19/.clang-format tar: coreboot-4.19/.clang-format: implausibly old time stamp -9223372036854775808 coreboot-4.19/.coreboot-version tar: coreboot-4.19/.coreboot-version: implausibly old time stamp -9223372036854775808 coreboot-4.19/.crossgcc-version tar: coreboot-4.19/.crossgcc-version: implausibly old time stamp -9223372036854775808 coreboot-4.19/.editorconfig tar: coreboot-4.19/.editorconfig: implausibly old time stamp -9223372036854775808 Cause: @icon investigated and said "d05ea79e40c4 util/release/build-release: Fix style issues at least that change to the tstamp variable looks very suspicious" flx suggested to recreate the archive: "I think 4.19-2 would be better. There are no changes to coreboot or anything. It also doesn't need a new git tag" -- 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

4 8

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot February 2023