coreboot

coreboot@coreboot.org

17 participants
39654 discussions

Re: coreboot postcode cleanup proposal
by Martin Roth 21 Nov '22

21 Nov '22

The intel cache_as_ram postcodes actually wouldn't go into the bootblock area. The coreboot areas are meant to be common to all platforms. The CAR codes would mostly go into the "SoC specific area", which I've doubled from 16 to 32 codes based on your comment here. ``` * 0x00 : unregulated - 0x00 is not a good postcode. * * 0x01 - 0x07 : general coreboot startup code & common * 0x08 - 0x0b : general coreboot console * 0x0c - 0x0f : <RESERVED> * * 0x10 - 0x1f : general coreboot bootblock * 0x20 - 0x2f : general coreboot romstage * 0x30 - 0x33 : general coreboot postcar * 0x34 - 0x3f : general coreboot ramstage * 0x40 - 0x4f : coreboot ramstage hardwaremain boot stages * * 0x50 - 0x6f : SOC specific - Each SoC/CPU/Chipset can use as it chooses * * 0x70 - 0x7f : <Reserved for expansion> * * 0x80 - 0x87 : ACPI postcodes * 0x88 - 0x8f : Unregulated - may be used anywhere for any purpose. * 0x90 - 0x9f : Vendorcode calls: FSP, AGESA, etc. entry & exit. * * 0xa0 - 0xaf : Mainboard specific - Each mainboard can use as it chooses * * 0xb0 : Driver/SuperIO ID, followed by ID byte (serves as driver entry) * 0xb1 - 0xbf : Driver/SuperIO specific - Can use as the device chooses * * 0xc0 - 0xca : <Reserved for expansion> * * 0xcb : coreboot identifier - used when returning from FSP, AGESA, etc * * 0xcc - 0xcf : <Reserved for expansion> * * 0xd0 : Debug ID, followed by ID byte * 0xd1 - 0xdf : Debug postcodes - never enabled by default. * * 0xe0 - 0xef : Errors * 0xf0 - 0xf7 : general coreboot SMM * 0xf8 - 0xfe : end of coreboot code - resume and the like. * 0xff : coreboot finished - jump to payload ``` I've also moved some reserved area to just after the SoC postcode area in case we find we still need more than 32, we can easily expand it up to 48 postcodes for the SoC or CPU/NB/SB areas. If we find we need to reorganize more in the future, we should be able to do that without too much difficulty in the future. It was suggested in the leadership meeting last week that we could version the postcodes based on releases, but hopefully it'll settle down very shortly, and we won't need to do that. Martin Nov 16, 2022, 15:20 by maximilian.brune(a)9elements.com: > src/soc/intel/common/block/cpu/car/cache_as_ram.S is a candidate which hard codes all post codes (instead of using post_codes.h) and that file alone already uses more than your 16 propsed postcodes for bootblock (I think). Since bootblock is kind of relying on post codes for proper debug (since serial output may not be available at that time), it would make sense to use more post codes for bootblock I guess. > > On Wed, Nov 16, 2022, 17:23 Martin Roth via coreboot <> coreboot(a)coreboot.org> > wrote: > >> The current state of the coreboot postcodes is a mess. There’s no good way to give anyone a postcode table. The post_code() function is called with direct hardcoded values all over the codebase. The post_codes.h file is disorganized with values being added without regard for being contiguous or ordered. As an example, despite using hexadecimal values, console post codes go from 0x39 to 0x40. >> >> >> We can do better than this. >> >> >> Proposal >> -------- >> The postcodes should be better organized and standardized. Each stage should have its own block of postcodes, and they should be easily recognizable as a flow from early coreboot to late coreboot. >> common between blocks: >> - bootblock >> - verstage >> - romstage >> - postcar >> - ramstage >> - smm >> >> We should have blocks of postcodes for different sections as well. >> - SoC/CPU/Chipset >> - Mainboard >> - Drivers >> >> - A set of debug-specific postcodes that may be used in any area, but may not be enabled by default, but only by user request. >> - The debug and driver post codes should have identifiers to show what section of the codebase they're coming from. >> - Finally, there should be small section of uncontrolled values that can be used anywhere that doesn’t have an already allocated specific value. >> >> >> Additional Improvements >> ----------------------- >> - Postcodes should be able to be included in the timestamp table so we can grab timestamps for individual postcodes. >> - Specific Postcodes should have associated text names, similar to the timestamps, and should have a decode tool. >> - Multi-byte postcodes should be implemented for platforms that support them. >> >> >> Proposed postcode ranges >> ------------------------ >> >> ``` >> * 0x00 : unregulated - 0x00 is not a good postcode. >> * >> * 0x01 - 0x07 : coreboot startup code & common >> * 0x08 - 0x0b : coreboot console >> * 0x0c - 0x0f : <RESERVED> >> * >> * 0x10 - 0x1f : coreboot bootblock >> * 0x20 - 0x2f : coreboot romstage >> * 0x30 - 0x33 : postcar >> * 0x34 - 0x3f : coreboot ramstage >> * 0x40 - 0x4f : coreboot ramstage hardwaremain boot stages >> * >> * 0x50 - 0x5f : Mainboard specific - Each mainboard can use as it chooses >> * 0x60 - 0x6f : SOC specific - Each SoC/CPU/Chipset can use as it chooses >> * >> * 0x70 : Driver/SuperIO ID, followed by ID byte >> * 0x71 - 0x7f : Driver/SuperIO specific - Can use as the device chooses >> * >> * 0x80 - 0x87 : ACPI postcodes >> * 0x88 - 0x8f : Unregulated - may be used anywhere for any purpose. >> * 0x90 - 0x9f : Vendorcode calls: FSP, AGESA, etc. >> * >> * 0xa0 - 0xaf : <RESERVED> >> * 0xb0 - 0xbf : <RESERVED> >> * >> * 0xc0 - 0xca : <RESERVED> >> * >> * 0xcb : coreboot identifier - used when returning from FSP, AGESA, etc >> * >> * 0xcc - 0xcf : <RESERVED> >> * >> * 0xd0 - 0xdf : Debug postcodes - never enabled by default. >> * >> * 0xe0 - 0xef : Errors >> * 0xf0 - 0xf7 : SMM >> * 0xf8 - 0xfe : end of coreboot code - resume and the like. >> * 0xff : coreboot finished - jump to payload >> ``` >> >> Driver/SuperIO/Debug IDs >> ------------------------ >> >> Because there are many drivers, and a single board can use multiple of the drivers, we want a way to know which device is putting out postcodes. To handle this, the driver, superIO, or debug section should emit a DRIVER_ID_FOLLOWS or DEBUG_ID_FOLLOWS postcode, followed by the actual ID code. >> >> The ID code would currently be a single byte, with the bytes 0xf0 - 0xff being reserved as page and continue bytes. The continue bytes would tell the code that the ID is on a secondary or later page - See the method used by the SPD to identify Manufacturers as a similar concept. 0xF0 - 0xFE would each point to a page of 240 possible drivers, and 0xff would tell the code to look for the next level of pages, which would follow the same pattern. >> >> The driver IDs and debug IDs would all be contained in separate header files. >> >> This would allow for the area to be uniquely identified by a tool. >> >> Postcode rules >> -------------- >> >> - Don’t use postcodes other than the debug postcodes in loops. Spewing out postcodes isn’t helpful. >> - Don’t output bare numbers, a macro in post_codes.h must be used. A linter will be set up to look the macros and will give an error if it’s not one of the postcode files. >> - All postcode output should be able to be identified by an automatic parser tool (with the exception of unregulated codes) >> >> >> >> _______________________________________________ >> coreboot mailing list -- >> coreboot(a)coreboot.org >> To unsubscribe send an email to >> coreboot-leave(a)coreboot.org >>

2 1

[coreboot - Bug #439] (New) Lenovo X201 Turbo Boost not working
by Lukas Karg 19 Nov '22

19 Nov '22

Issue #439 has been reported by Lukas Karg. ---------------------------------------- Bug #439: Lenovo X201 Turbo Boost not working https://ticket.coreboot.org/issues/439 * Author: Lukas Karg * Status: New * Priority: High * Target version: none * Start date: 2022-11-18 * Affected versions: master * Affected hardware: Lenovo X201 * Affected OS: Linux, Windows, ... ---------------------------------------- -- 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 6

FYI: Changing contents and compression for `config` file in CBFS
by Julius Werner 17 Nov '22

17 Nov '22

I don't know if anybody cares about this, so I thought I'd send an email just in case: I'd like to change the format of the `config` file that automatically gets included in CBFS: right now it just contains the output of Kconfig's `savedefconfig` command, i.e. the minimal `.config` file that is needed to reproduce the full config (with all the default options and options that get `select`ed by something else excluded). This is a problem if you want to use the file to just check if a certain option was enabled in the image or not, since many options are enabled by default in certain cases, and the rules for when exactly what is the default setting can be complicated and change frequently. I would like to have a `config` file that I can just extract and then grep for a certain CONFIG_XXX=y to check if that config was enabled or not. So I'm changing the generation of the `config` file to instead include all options that are not set to false in Kconfig (i.e. basically the full coreboot `.config` file, just with comments removed). Since this makes the file quite a bit bigger I think we should also start to compress it with LZMA, as it's only meant to be re-extracted with cbfstool anyway so there seems to be no reason not to. (Or does anyone care strongly about being able to read the config file when opening the raw image with a hex editor?) I've uploaded this CL as https://review.coreboot.org/69710 . Please comment there if anyone has a concern about this change.

2 1

coreboot postcode cleanup proposal
by Martin Roth 17 Nov '22

17 Nov '22

The current state of the coreboot postcodes is a mess. There’s no good way to give anyone a postcode table. The post_code() function is called with direct hardcoded values all over the codebase. The post_codes.h file is disorganized with values being added without regard for being contiguous or ordered. As an example, despite using hexadecimal values, console post codes go from 0x39 to 0x40. We can do better than this. Proposal -------- The postcodes should be better organized and standardized. Each stage should have its own block of postcodes, and they should be easily recognizable as a flow from early coreboot to late coreboot. common between blocks: - bootblock - verstage - romstage - postcar - ramstage - smm We should have blocks of postcodes for different sections as well. - SoC/CPU/Chipset - Mainboard - Drivers - A set of debug-specific postcodes that may be used in any area, but may not be enabled by default, but only by user request. - The debug and driver post codes should have identifiers to show what section of the codebase they're coming from. - Finally, there should be small section of uncontrolled values that can be used anywhere that doesn’t have an already allocated specific value. Additional Improvements ----------------------- - Postcodes should be able to be included in the timestamp table so we can grab timestamps for individual postcodes. - Specific Postcodes should have associated text names, similar to the timestamps, and should have a decode tool. - Multi-byte postcodes should be implemented for platforms that support them. Proposed postcode ranges ------------------------ ``` * 0x00 : unregulated - 0x00 is not a good postcode. * * 0x01 - 0x07 : coreboot startup code & common * 0x08 - 0x0b : coreboot console * 0x0c - 0x0f : <RESERVED> * * 0x10 - 0x1f : coreboot bootblock * 0x20 - 0x2f : coreboot romstage * 0x30 - 0x33 : postcar * 0x34 - 0x3f : coreboot ramstage * 0x40 - 0x4f : coreboot ramstage hardwaremain boot stages * * 0x50 - 0x5f : Mainboard specific - Each mainboard can use as it chooses * 0x60 - 0x6f : SOC specific - Each SoC/CPU/Chipset can use as it chooses * * 0x70 : Driver/SuperIO ID, followed by ID byte * 0x71 - 0x7f : Driver/SuperIO specific - Can use as the device chooses * * 0x80 - 0x87 : ACPI postcodes * 0x88 - 0x8f : Unregulated - may be used anywhere for any purpose. * 0x90 - 0x9f : Vendorcode calls: FSP, AGESA, etc. * * 0xa0 - 0xaf : <RESERVED> * 0xb0 - 0xbf : <RESERVED> * * 0xc0 - 0xca : <RESERVED> * * 0xcb : coreboot identifier - used when returning from FSP, AGESA, etc * * 0xcc - 0xcf : <RESERVED> * * 0xd0 - 0xdf : Debug postcodes - never enabled by default. * * 0xe0 - 0xef : Errors * 0xf0 - 0xf7 : SMM * 0xf8 - 0xfe : end of coreboot code - resume and the like. * 0xff : coreboot finished - jump to payload ``` Driver/SuperIO/Debug IDs ------------------------ Because there are many drivers, and a single board can use multiple of the drivers, we want a way to know which device is putting out postcodes. To handle this, the driver, superIO, or debug section should emit a DRIVER_ID_FOLLOWS or DEBUG_ID_FOLLOWS postcode, followed by the actual ID code. The ID code would currently be a single byte, with the bytes 0xf0 - 0xff being reserved as page and continue bytes. The continue bytes would tell the code that the ID is on a secondary or later page - See the method used by the SPD to identify Manufacturers as a similar concept. 0xF0 - 0xFE would each point to a page of 240 possible drivers, and 0xff would tell the code to look for the next level of pages, which would follow the same pattern. The driver IDs and debug IDs would all be contained in separate header files. This would allow for the area to be uniquely identified by a tool. Postcode rules -------------- - Don’t use postcodes other than the debug postcodes in loops. Spewing out postcodes isn’t helpful. - Don’t output bare numbers, a macro in post_codes.h must be used. A linter will be set up to look the macros and will give an error if it’s not one of the postcode files. - All postcode output should be able to be identified by an automatic parser tool (with the exception of unregulated codes)

3 2

[RFC] POC: Use FDT as payload handoff instead lb_tables
by Paul Menzel 16 Nov '22

16 Nov '22

Dear coreboot folks, Arthur pushed the proof of concept *Use FDT as payload handoff instead lb_tables* [1] to pass information to the payload via FDT instead of coreboot tables. Julius asked for more background, and Arthur replied. I am moving the discussion to the list for broader visibility, and better way of discussing these things than Gerrit comments. >> Were there any discussions about this that I missed (if so would >> you mind linking to them)? Can you explain who needs this and why, >> what's the overall goal? (I know there have been vague discussions >> about various new firmware handoff formats from Arm and Intel and >> others, but if this is related to those I missed the parts where >> there was suddenly consensus on how it should look, and why that is >> FDT.) > > Most of the discussion happened verbally at osfc, so I can't point to > any written communication. There is > https://www.osfc.io/2022/talks/collaborative-firmware-payload-handoff-desig… > if you have the time to listen to a talk. > So if I have to summarize the idea's/goals: > > * Intel Universal scalable firmware suggested using UEFI HOBs as a handoff structure > * coreboot won't do that as it's no improvement over coreboot tables > * USF won't make coreboot tables a standard either > * Maybe something new can be created that would fit both the needs of payload handoff and other binary information passing between programs (e.g. FSP)? > * USF people suggested using CBOR to encode data to so that serialization/deserialization of data is explicit instead of using structs. > * CBOR is an improvement for the data format, but not what coreboot/(other project) should tell the payload: i.e. what entries are needed > * FDT was suggested as an alternative as it covers both explicit serialization/deserialization + what payload tell each other since the spec already exists, with a lot of existing compatible node strings. (e.g. I reuse simple-framebuffer from Linux here to hand of the framebuffer) Also most payloads and firmware have code for working with FDT. > * (unrelated to payload handof but part of the discussions) Another idea is to also use FDT as an interface between coreboot and FSP. > * a lot of payloads already have code to work with FDT so having FDT as a handoff structure would not be a lot of work > * FDT should make compatibility between coreboot and payload easier when handoff entries are added or changed (plain structs are painful if they are updated as both payload and coreboot definitions need to match) > * debugging the handoff structure is easier with FDT as you can use DTC in the OS userspace or coreboot code can also print out the full structure in human readable format. > > What are your thoughts? > > * Is it a good idea to use FDT and eventually replace coreboot tables. > * If so, do we keep both for a while to make transitioning easier? I think maintaining two structures is not sustainable long term. > * How should the 'entries' be structured? I made compatible nodes that map somewhat to existing coreboot table structs. Kind regards, Paul [1]: https://review.coreboot.org/c/coreboot/+/68719

12 24

[RFC] Use (extended?) Multiboot as payload handoff
by Nico Huber 16 Nov '22

16 Nov '22

Hi all, you can stop staring at your calendar, it's not April 1st. But actually I'm not sure myself if I'm serious with this :D Recent discussions made me look at the current USF spec, in par- ticular the Universal Payload part [1]. Admittedly I only scrolled through it. There are some things in it (beside the HOBs that some would rather put in FDT) that seem incompatible to our current payload mechanism. For instance, payload modules. The whole thing seemed so similar to Multiboot (with HOBs) that I had another look at Multiboot2[2]. The spec looks odd, but it seems like another thing similar to coreboot tables. There are two types of `tags` which is confusing, but the interesting one is the one to pass information to the loaded program: +-------------------+ u32 | type | u32 | size | +-------------------+ It's also very flat. But most of all it's an existing open standard! Thoughts are tumbling in my head right now: The whole Multiboot spec thing seems too complex to put into ramstage. But so does the Universal Payload thing! If we'd end up with a shim after ramstage anyway, we could as well use the existing standard. This might also pave the way for more kernels as payloads... WDYT? Nico [1] https://universalscalablefirmware.github.io/documentation/2_universal_paylo… [2] https://www.gnu.org/software/grub/manual/multiboot2/multiboot.html

6 8

Coreboot porting possibilities on TOPTON N5105
by Mateusz Kuchta 13 Nov '22

13 Nov '22

Hi I have a mini PC with Intel N5105 processor (Jasper Lake) and 6-port NIC (Intel i225-V B3). Device is chinese brand TOPTON, inside Changwang CW-11 motherboard delivered with AMI 5.19 BIOS. There isn't much details about this device in Internet. I'm planning to use it as a firewall box utilizing OPNsense which I've already running virtualized on NAS but wanted to move it to separate box. Before I start with it I thought about porting Coreboot BIOS. Coreboot is actually new to me but I found it can be benefitial in terms of security especially in my case where I'm planning to run firewall on it. It also my tech curiousity whether I could manage that to port BIOS with benefit to other people who owns this device. I read some posts on Reddit and found that first obstacle is Intel Boot Guard technology which Intel N5105 CPU supports. In dmesg I can find mei_me module entry related log: > [ 5.936057] mei_me 0000:00:16.0: enabling device (0000 -> 0002) Using intelmetool I wanted to find out if I can get more details but I got following output. I'm running those commands on Fedora with iomem=relaxed GRUB option set. ./intelmetool -b > Can't find ME PCI device > Can't find ME PCI device ./intelmetool -m > Can't find ME PCI device Next I tried to use fwupdtool to gather security details and result is following. In HSI-2 section main 'Intel BootGuard' entry shows 'Enabled' but other 3 detailed entries shows 'Invalid'. I'm not sure whether it's valid result or can be kind of false-positive and I shouldn't consider it as sure result. FuPluginUefiCapsule skipping device that failed coldplug: ESRT GUID > '00000000-0000-0000-0000-000000000000' was not valid > Host Security ID: HSI:0! (v1.8.6) > HSI-1 > ✔ CSME override: Locked > ✔ Platform Debugging: Disabled > ✔ SPI write: Disabled > ✔ Supported CPU: Valid > ✔ UEFI platform key: Valid > ✘ CSME manufacturing mode: Unlocked > ✘ CSME v0:13.50.15.1436: Invalid > ✘ SPI BIOS region: Unlocked > ✘ SPI lock: Disabled > ✘ TPM v2.0: Not found > HSI-2 > ✔ Intel BootGuard: Enabled > ✔ Platform Debugging: Locked > ✘ IOMMU: Not found > ✘ Intel BootGuard ACM protected: Invalid > ✘ Intel BootGuard OTP fuse: Invalid > ✘ Intel BootGuard verified boot: Invalid > > HSI-3 > ✔ Pre-boot DMA protection: Enabled > ✘ Intel BootGuard error policy: Invalid > ✘ Intel CET Enabled: Not supported > ✘ Suspend-to-idle: Disabled > ✘ Suspend-to-ram: Enabled > > HSI-4 > ✔ Intel SMAP: Enabled > ✘ Encrypted RAM: Not supported > Runtime Suffix -! > ✔ Linux kernel: Untainted > ✔ Linux swap: Encrypted > ✔ fwupd plugins: Untainted > ✘ Linux kernel lockdown: Disabled > ✘ UEFI secure boot: Disabled My question is based on above details can you tell me if there is an ability to port Coreboot into this device? If that details aren't enough, can you tell me what tools I should use to be 100% sure? Currently I don't have BIOS programmer, I was planning to buy it after I confirm possibilities for this device, otherwise it's probably useless to me and I won't need it. Anyway I can get it if this may be required to confirm possibilities. As it's chinese device from minor manufacturer I doubt it may be as secured as devices from big companies on market. Kind regards Mateusz

1 0

New Defects reported by Coverity Scan for coreboot
by scan-admin＠coverity.com 11 Nov '22

11 Nov '22

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. 3 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 1500576: Null pointer dereferences (FORWARD_NULL) ________________________________________________________________________________________________________ *** CID 1500576: Null pointer dereferences (FORWARD_NULL) /src/ec/google/chromeec/ec.c: 90 in google_chromeec_kbbacklight() 84 .cmd_data_out = NULL, 85 .cmd_size_in = sizeof(params), 86 .cmd_size_out = 0, 87 .cmd_dev_index = 0, 88 }; 89 >>> CID 1500576: Null pointer dereferences (FORWARD_NULL) >>> Passing "&cmd" to "google_chromeec_command", which dereferences null "cmd.cmd_data_out". 90 if (google_chromeec_command(&cmd) != 0) 91 return -1; 92 93 return 0; 94 } 95 ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0

Fwd: Re: [RFC] POC: Use FDT as payload handoff instead lb_tables
by Arthur Heymans 09 Nov '22

09 Nov '22

Forgot to add coreboot(a)coreboot.org in cc. ---------- Forwarded message --------- From: Arthur Heymans <arthur(a)aheymans.xyz> Date: Wed, Nov 9, 2022 at 6:41 PM Subject: Re: [coreboot] Re: [RFC] POC: Use FDT as payload handoff instead lb_tables To: ron minnich <rminnich(a)gmail.com> I think it is possible that, over a few years, we might see fdt replace > coreboot tables. It might be a natural evolution. > If you go with the stage approach, it will never happen. We'll always need > coreboot tables as input to the fdt stage. > > I'm not seeing a natural evolution happening anytime soon. There really isn't a good enough technical reason to replace coreboot tables. If those 2 solutions live side by side in the same stage it will 100% end up in a case of https://xkcd.com/927/ > I think the stage is the wrong way to go. I want it to be possible to have > the option to build without coreboot tables. > This is more messy than you might think. A lot of code that is used in creating data structures to create coreboot tables would need to be rewritten to fit the needs to just generate FDT. https://review.coreboot.org/c/coreboot/+/68768 is one example. In the end it also boiled down to parsing a coreboot table entry struct into FDT. So if creating an FDT handoff boils down to parsing coreboot table structures even when implemented in ramstage, I don't see good arguments why it cannot live in a separate stage, as you effectively end up needing both data structures. Or is avoiding consuming a few 100's of bytes for the coreboot tables really worth it? Creating FDT handoff == parsing coreboot tables anyway, whether it lives in ramstage or separate stage... > To some extent I think the stage mechanism is overused. In fact, in > oreboot, we removed stages. > I agree and I removed some from coreboot ( https://review.coreboot.org/c/coreboot/+/55068), but in this case I could see a separate payload/stage as a good way to separate 2 things trying to achieve the same purpose. Maintaining both solutions in the same program is messy and something I'd like to avoid. Another advantage is that you don't need to rebuild coreboot to generate your needed handoff if you change payloads. If I want to change out the EDK2 FDT payload with a LinuxBoot added with cbfstool, that will just work. With FDT/coreboot tables behind Kconfig it won't. Arthur On Wed, Nov 9, 2022 at 5:07 PM ron minnich <rminnich(a)gmail.com> wrote: > I think it is possible that, over a few years, we might see fdt replace > coreboot tables. It might be a natural evolution. > If you go with the stage approach, it will never happen. We'll always need > coreboot tables as input to the fdt stage. > > I think the stage is the wrong way to go. I want it to be possible to have > the option to build without coreboot tables. > > To some extent I think the stage mechanism is overused. In fact, in > oreboot, we removed stages. > > On Tue, Nov 8, 2022 at 11:48 PM Arthur Heymans <arthur(a)aheymans.xyz> > wrote: > >> >>> So just to be clear, to make sure we weren't taking different things >>> away from that meeting: I said I'm okay with adding the FDT option as >>> a separate, isolated compile-time option for those that want to try it >>> out. But I care that the coreboot tables continue to be supported on >>> equal footing in the long term, and I don't want there to be some >>> pre-formed understanding that they'll be "deprecated eventually" or >>> that payloads will be slowly pressured to move to the FDT handoff, >>> particularly not with any specific timeline attached. >>> >>> With this in mind I don't see any reasons why generating the FDT handoff >> needs to happen in the coreboot ramstage. >> A libpayload based payload could just as well generate that FDT handoff >> and chainload the next payload. >> All the infrastructure is there in libpayload to cleanly do this. >> The coreboot code for dealing with FDT is exactly the same as deptcharge >> code (it comes from that project). >> This is a better technical solution than to introduce new Kconfig guarded >> code and maintenance overhead inside the coreboot tree to maintain 2 >> solutions for the same problem. >> As a matter of fact that solution is even more 'universal' as you could >> still swap out payloads without recompiling the coreboot part of things. >> >> Arthur >> >> On Tue, Nov 8, 2022 at 11:55 PM Julius Werner <jwerner(a)chromium.org> >> wrote: >> >>> > As mentioned by Julius, we had a candid discussion yesterday on this, >>> while he still reserves his opinions on FDT, he will not block the >>> implementation. For now we will guard it with kconfig and give it a year of >>> trial to see how it turns out. >>> >>> So just to be clear, to make sure we weren't taking different things >>> away from that meeting: I said I'm okay with adding the FDT option as >>> a separate, isolated compile-time option for those that want to try it >>> out. But I care that the coreboot tables continue to be supported on >>> equal footing in the long term, and I don't want there to be some >>> pre-formed understanding that they'll be "deprecated eventually" or >>> that payloads will be slowly pressured to move to the FDT handoff, >>> particularly not with any specific timeline attached. >>> >>

1 0

[patch] x11ssh-f hanging in fsp, probably IGD init
by Valentin Kleibel 08 Nov '22

08 Nov '22

Hi, After some failures i was successful booting coreboot on a supermicro x11ssh-f [CPU: Xeon E3-1220 v5]. Built from the most recent git coreboot hangs indefinitely at: > [DEBUG] BS: BS_DEV_INIT_CHIPS entry times (exec / console): 283 / 381 ms > [DEBUG] IA32_FEATURE_CONTROL status: locked > [INFO ] POST: 0x71 > [DEBUG] WEAK: src/soc/intel/skylake/chip.c/mainboard_silicon_init_params called > [ERROR] Null dereference at eip: 0x7f317e15 > [INFO ] POST: 0x93 We noticed the proposed change https://review.coreboot.org/c/coreboot/+/51332 from over a year ago and updated the patch. The attached igd_disabled.patch applies cleanly on the current tree and built with the attached config the board boots as expected incl. video out via AST2400. (This was our final config, previous tests were done without mecleaner) Maybe this helps someone to get coreboot running or a fix could be applied upstream. Cheers, Valentin

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