coreboot

coreboot@coreboot.org

6 participants
39686 discussions

[coreboot - Feature #7] gnawty support based on acer cb3-111
by Matt DeVillier 15 Jan '23

15 Jan '23

Issue #7 has been updated by Matt DeVillier. Martin Roth wrote in #note-14: > No updates in 7 years. Closing. also, gnawty has been supported as a rambi variant since early 2017 ---------------------------------------- Feature #7: gnawty support based on acer cb3-111 https://ticket.coreboot.org/issues/7#change-1350 * Author: Alexander Couzens * Status: Closed * Priority: Normal * Assignee: Alexander Couzens * Category: board support * Start date: 2015-11-20 ---------------------------------------- Adding google gnawty boards. This board is very similiar to rambi, the only difference known is the ram configuration. http://review.coreboot.org/#/c/12500 https://www.coreboot.org/Board:acer/cb3-111 SeaBIOS hangs with message: Press F12 ... but pressing f12 does nothing. ~~Booting ELF payload with openwrt fails because e820 isn't properly passed.~~ Using Linux Payload + x64 kernel openwrt boots up. ---Files-------------------------------- bootup_x86_64_openwrt (60 KB) vga_bios_hangs (29.1 KB) dmesg (63.6 KB) lspci_vvv (10.3 KB) lspci (789 Bytes) lspci_vvttnn (716 Bytes) booting_4.1 (58.7 KB) booting_4.1_with_ioapic (63.5 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 #12] (Closed) Use of CONFIG_MAINBOARD_POWER_ON_AFTER_POWER_FAIL is a mess
by Martin Roth 15 Jan '23

15 Jan '23

Issue #12 has been updated by Martin Roth. Status changed from New to Closed Closing as fixed. ---------------------------------------- Bug #12: Use of CONFIG_MAINBOARD_POWER_ON_AFTER_POWER_FAIL is a mess https://ticket.coreboot.org/issues/12#change-1349 * Author: Martin Roth * Status: Closed * Priority: Normal * Start date: 2015-11-27 ---------------------------------------- In Kconfig, the symbol MAINBOARD_POWER_ON_AFTER_POWER_FAIL is used in a few platforms. It is a bool. Because it's used in only a few mainboards, for MOST platforms, it's going to be defined as 0 (kconfig bools in coreboot are ALWAYS defined) Here are those mainboards: > src/mainboard/samsung/lumpy/Kconfig > src/mainboard/samsung/stumpy/Kconfig > src/mainboard/asus/kgpe-d16/Kconfig > src/mainboard/asus/kfsn4-dre/Kconfig > src/mainboard/asus/kfsn4-dre_k8/Kconfig > src/mainboard/msi/ms9652_fam10/Kconfig In a number of other platforms, CONFIG_MAINBOARD_POWER_ON_AFTER_POWER_FAIL is used as if it were a standard #define - with three states: from src/southbridge/intel/bd82x6x/pch.h: <pre><code class="c"> #define MAINBOARD_POWER_OFF 0 #define MAINBOARD_POWER_ON 1 #define MAINBOARD_POWER_KEEP 2 #ifndef CONFIG_MAINBOARD_POWER_ON_AFTER_POWER_FAIL #define CONFIG_MAINBOARD_POWER_ON_AFTER_POWER_FAIL MAINBOARD_POWER_ON #endif </code></pre> Similar patterns are seen in these files: > src/southbridge/amd/agesa/hudson/sm.c > src/southbridge/amd/amd8111/acpi.c > src/southbridge/amd/pi/hudson/sm.c > src/southbridge/amd/sb600/sm.c > src/southbridge/amd/sb700/sm.c > src/southbridge/amd/sb800/sm.c > src/southbridge/intel/bd82x6x/pch.h > src/southbridge/intel/fsp_bd82x6x/pch.h > src/southbridge/intel/fsp_i89xx/pch.h > src/southbridge/intel/fsp_rangeley/soc.h > src/southbridge/intel/i3100/lpc.c > src/southbridge/intel/i82801dx/i82801dx.h > src/southbridge/intel/i82801ex/lpc.c > src/southbridge/intel/i82801gx/i82801gx.h > src/southbridge/intel/i82801ix/i82801ix.h > src/southbridge/intel/ibexpeak/pch.h > src/southbridge/intel/lynxpoint/pch.h > src/southbridge/nvidia/ck804/lpc.c > src/southbridge/nvidia/mcp55/lpc.c > src/southbridge/sis/sis966/lpc.c > src/southbridge/via/vt8237r/vt8237r.h > src/superio/nuvoton/nct5572d/superio.c To fix: * Make sure definitions are the same across all the platforms and fix them to be consistent if they're not already: ** 0 = power off, 1 = power on, 2 = restore previous state * Add Kconfig symbols to show which platforms get these options based on which platforms are using the option - Everything using CONFIG_MAINBOARD_POWER_ON_AFTER_POWER_FAIL needs to be set. ** HAVE_POWER_STATE_ON_AFTER_FAIL - This gets set for platforms that get the option ** HAVE_POWER_STATE_RESTORE - This gets set for platforms that can actually restore the previous state * Turn the MAINBOARD_POWER_ON_AFTER_POWER_FAIL bool into a choice menu and move it to a higher level in the Kconfig tree. * Add the HAVE_POWER_STATE_ON_AFTER_FAIL and HAVE_POWER_STATE_RESTORE to the correct Kconfigs * Remove all of the existing #define stuff from the above files. * Remove the current MAINBOARD_POWER_ON_AFTER_POWER_FAIL Kconfig options from their current locations (with the exception of setting new defaults) * Test. -- 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 - Feature #14] (Closed) printout lenovo ec power cause register
by Martin Roth 15 Jan '23

15 Jan '23

Issue #14 has been updated by Martin Roth. Status changed from New to Closed Closing due to No updates in 7 years. Please reopen if needed. ---------------------------------------- Feature #14: printout lenovo ec power cause register https://ticket.coreboot.org/issues/14#change-1348 * Author: Alexander Couzens * Status: Closed * Priority: Normal * Assignee: Alexander Couzens * Category: board support * Start date: 2015-11-28 ---------------------------------------- -- 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 - Feature #7] (Closed) gnawty support based on acer cb3-111
by Martin Roth 15 Jan '23

15 Jan '23

Issue #7 has been updated by Martin Roth. Status changed from In Progress to Closed No updates in 7 years. Closing. ---------------------------------------- Feature #7: gnawty support based on acer cb3-111 https://ticket.coreboot.org/issues/7#change-1347 * Author: Alexander Couzens * Status: Closed * Priority: Normal * Assignee: Alexander Couzens * Category: board support * Start date: 2015-11-20 ---------------------------------------- Adding google gnawty boards. This board is very similiar to rambi, the only difference known is the ram configuration. http://review.coreboot.org/#/c/12500 https://www.coreboot.org/Board:acer/cb3-111 SeaBIOS hangs with message: Press F12 ... but pressing f12 does nothing. ~~Booting ELF payload with openwrt fails because e820 isn't properly passed.~~ Using Linux Payload + x64 kernel openwrt boots up. ---Files-------------------------------- bootup_x86_64_openwrt (60 KB) vga_bios_hangs (29.1 KB) dmesg (63.6 KB) lspci_vvv (10.3 KB) lspci (789 Bytes) lspci_vvttnn (716 Bytes) booting_4.1 (58.7 KB) booting_4.1_with_ioapic (63.5 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 - Feature #4] (Closed) Documentation for coreboot's public interface
by Martin Roth 15 Jan '23

15 Jan '23

Issue #4 has been updated by Martin Roth. Status changed from New to Closed We've done a significant amount of work on coreboot's documentation over the past 7 years. Closing this as completed. If there is any additional documentation needed, please file a new bug stating exactly what needs to be documented. ---------------------------------------- Feature #4: Documentation for coreboot's public interface https://ticket.coreboot.org/issues/4#change-1346 * Author: Patrick Georgi * Status: Closed * Priority: Normal * Start date: 2015-11-18 ---------------------------------------- We need some structured documentation on what can be expected to be the stable coreboot interface. This (probably) covers * cbfs (and in the future, fmap) format * cbtables (and its various table formats, incl. cbmem entries) * The calling convention into the payload (per arch) * references to ACPI, DMI, PIR, etc -- 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 - Support #387] (New) Support Framework Laptop
by Jun Aruga 15 Jan '23

15 Jan '23

Issue #387 has been reported by Jun Aruga. ---------------------------------------- Support #387: Support Framework Laptop https://ticket.coreboot.org/issues/387 * Author: Jun Aruga * Status: New * Priority: Normal * Category: board support * Target version: none * Start date: 2022-06-05 * Affected hardware: Framework Laptop ---------------------------------------- Dear coreboot developers, I am a user of Framework Laptop[1][2]. Thank you for working to make coreboot work on Framework Laptop! This ticket is to track the task, as I didn't see any other issue tickets about Framework Laptop here. According to the Framework founder's comment[3] below, Framework provided Framework Laptops to the coreboot community. > We've handed three systems that can boot unsigned bootloaders to folks in the coreboot community. Our plan in the near term is to help them create a shim loader that can be signed to run on any Framework Laptop, which then enables anyone to do further coreboot development. Then I saw Matthew's try to make the coreboot work on Framework Laptop,[4] but unfortunately it didn't work at that time.[5] How is the current status? What prevents coreboot from working on the Framework Laptop? How can we, people in the Framework community, help you? As a reference, there is a coreboot specific thread on the Framework community forum.[6] ## References * [1] https://frame.work/ * [2] Framework Computer - Wikipedia - https://en.wikipedia.org/wiki/Framework_Computer * [3] Framework Laptop Mainboard, Hacker News, April 20, 2022 - https://news.ycombinator.com/item?id=31097434 * [4] Matthew tries to port Coreboot to the Framework laptop - February 27, 2022 - https://www.youtube.com/watch?v=Jf_6xW-8tfQ * [5] Matthew Garrett on Twitter, February 27, 2022 - https://twitter.com/mjg59/status/1497788538212917250 * [6] Free the EC! and Coreboot Only - https://community.frame.work/t/free-the-ec-and-coreboot-only/791 -- 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

7 15

Thoughts on changing indentation for devicetree.cb files
by Martin Roth 15 Jan '23

15 Jan '23

I wanted to see what people think about changing the indentation for devicetree.cb files (including overridetree.cb and chipset.cb files) We currently use tabs to indent, which my editor has set to 8 spaces across all of coreboot, but these aren't C files, and maybe shouldn't be treated the same. We have deep indentations for the devicetree files, making the lines very long and causing them to wrap significantly when reviewing them in gerrit. I know I'm suggesting heresy here, but what do people think about changing the devicetree files to use indentation with spaces, at either 2 or 4 characters per level? I acknowledge that this could just be a me problem, but thought I'd bring it up. Martin

1 0

[coreboot - Cleanup #421] (New) Change API of functions taking hash as an argument
by Krystian Hebel 13 Jan '23

13 Jan '23

Issue #421 has been reported by Krystian Hebel. ---------------------------------------- Cleanup #421: Change API of functions taking hash as an argument https://ticket.coreboot.org/issues/421 * Author: Krystian Hebel * Status: New * Priority: Normal * Target version: none * Start date: 2022-10-12 ---------------------------------------- All existing functions that take a digest as an input assume that only one hashing algorithm is used at a time. Crypto agile format entry can (and should) log every used PCR bank in one entry for a given measurement. To make it work, some of the arguments must be changed, e.g.: - pass number of algorithms used; - instead of algorithm ID, pass a pointer to array of such IDs, with size equal to above; - instead of hash, pass a pointer to array of hashes, with size and order as above. -- 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 15

devicetree driven reference code / blob configuration
by Arthur Heymans 12 Jan '23

12 Jan '23

Hi all On most modern x86 systems a lot of the silicon init happens as part of blob (FSP, binaryPI) or some reference code (AGESA). Very often that silicon init enables or hides PCI devices. This means that this code needs to run before coreboot device enumeration code. With coreboot's current ramstage state machine running this binary can only happen as part of chip_ops->init or with a bootstate hook. As a quick reminder about the coreboot ramstage state machine: * start * | * BS_PRE_DEVICE * | * BS_DEV_INIT_CHIPS * | * BS_DEV_ENUMERATE * | the rest (device resource allocation, device init, ...) BS_DEV_INIT_CHIPS: - Call the .init from all the chip_ops from each "chip" once. FSP-S loading, configuring and calling is currently set up as a monolithic call inside such chip_ops->init. It has a lot of callbacks for soc and mainboard and consumes the devicetree in one big soc specific function, with little reuse between socs. All the silicon configuration can only be put into a monolithic soc chip_info and is translated into FSP UPDs. BS_DEV_ENUMERATE: - call static chip_ops->enable_dev on each static device on the devicetree. On older non-RC using code enabling or hiding PCI devices is done here. - scan the actual hardware (e.g. PCI bus) for what is there. What will be found is depends on the params passed to the reference code which will hide/enable devices Both the monolithic configuration, one big chip_info, and code flow don't follow coreboot's state machine philosophy, where the devicetree nodes drive the configuration process and codeflow. It would be nicer if device enabling and other configuration would be structured on a per node basis. So for instance all the USB configuration options would be below the xhci device node and not globally available to all nodes. Based on a discussion on IRC there are a few options, which are generally not mutually exclusive or share similar ideas: 1) Split up the DEV_ENUMERATE into a static devicetree part and a scan part. In combination with calling FSP between those two parts this would allow the chip_ops->enable_dev to be called on each device and so UPD setup could be modularised. This is still rather monolithic as the enable_dev is the same function callback for each device but it could be more modularised because the struct device is passed as an argument. So something like: switch (dev->path.pci.devfn) { case PCI_DEV(0, 0): do_something() case PCI_DEV(0x1f, 0): do_something_else() } is possible. So this at least removes all the current callbacks. 2) Move devices below separate chips and split up FSP loading, configuring and calling. Then then devicetree looks like this chip soc/intel/.../usb device ref xhci on end register "config_option_1" = "A" register "config_option_2" = "B" end If the FSP loading is separated from the calling, for instance by moving it earlier in a cbmem init hook or bootstate ENTRY hook, then each chip_ops .init could configure FSP UPDs based. The calling of FSP can then happen as part of bootstate EXIT hook. A disadvantage here would be that this would add a lot of "chips" which is not recommended for things that are not a separate physical chip. 3) Allow for a per device configuration. https://review.coreboot.org/c/coreboot/+/41745 implements this. This would easily allow per device configuration without introducing new chips. 4) Since it is now possible to hook up device ops directly in the devicetree we could add a new device specific entry to ops that a new bootstate executes before scanning buses. A enable_dev, but not on the chip_ops level but device level. One thing to note is that scan_bus will not give default PCI ops to devices anymore if ops is !NULL. This can be worked around by setting ops to NULL after calling this new ops on devices where the default pci ops are desirable. Another way would be to allow more finegrained control when writing the devicetree about which ops can be set directly in the devicetree. It looks like 3 + 4 would be the cleanest, but it should maybe not block trying out 1 and 2. The splitting of device specific configuration is possible in 1 and 2 and migrating to solutions of 3 and 4 would be rather trivial. Any thoughts on this? Arthur

1 0

Coreboot Machine-Check Exception
by Ahmet Fenerci 11 Jan '23

11 Jan '23

Hi, After I configure coreboot4.16 on my board(Intel Atom C3758) and run it, I'm having a problem with some runs (sometimes in rapid succession, sometimes very rarely). There are some machine-check exceptions (18- #MC) when I boot or reboot my operation system. You can have a detailed look at the link here : "https://drive.google.com/drive/folders/1TC_3OEooulHbGcRxybTuFz7oqkFpOf4B?us…" To solve the problem, I reviwed your guides "Intel® 64 and IA-32 Architectures Software Developer’s Manual Volume 1: Basic Architecture" and "Intel® 64 and IA-32 Architectures Software Developer’s Manual Volume 3 (3A, 3B, 3C & 3D): System Programming Guide". When I want to look at the source of the problem with the error code in "Intel® 64 and IA-32 Architectures Software Developer’s Manual Volume 3 (3A, 3B, 3C & 3D): System Programming Guide", here is the a information about machine-check exception. ( 6.15 EXCEPTION AND INTERRUPT REFERENCE - Interrupt 18- Machine-Check Exception (#MC) ) Lastly, I checked the "Intel® 64 and IA-32 Architectures Software Developer’s Manual Volume 4: Model-Specific Registers" to solve problem, but I couldn't find the source of the problem. I have a few questions ; 1- What is the source of the machine-check exception problem and why does it happen occasionally? 2- As seen in the MC Exception error content in the given google drive link ( Unexpected Exception:18 @ 10:7f998256 ) , at here ;18 indicates to Machine-Check Exception. What does 10 indicate here? ( 7f998256 is an address at Ramstage) 3- 0xdeadbeef errors are seen at some addresses of ramstage, what is the reason?

2 1

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