coreboot

coreboot@coreboot.org

6 participants
39687 discussions

compatability between two similar motherboards
by cykaxzy＠tutanota.com 28 Dec '20

28 Dec '20

Hello all, There are two/three devices which I would like to run coreboot on, which are variants of devices explicitly supported by coreboot. These document pages, however, are a little ambiguous as to which variants of the supported devices would work. I seek clarification. On the page https://doc.coreboot.org/mainboard/asrock/h110m-dvs.html is linked ASRock's information page about the H110M-DVS R2.0. I should like to run coreboot on the H110M-DVS R3.0, as this one is of the mini-DTX form-factor, which the R2.0 is not. Does anyone know if coreboot's H110M-DVS port would function on the R3.0? There is no indication (other than the fact that the doc page links to the R2.0's info) that this would not be the case. Indeed, the documentation page consistently refers to the motherboard as merely the 'H110M-DVS,' without the revision specifier. Another, related question, is whether the very-similar H110M-DGS would be supported by this coreboot port. http://www.asrock.com/mb/Intel/H110M-DGS/index.asp Note that the H81M-DGS is supported by coreboot. On the page https://doc.coreboot.org/mainboard/libretrend/lt1000.html is linked Libretrend's purchase website for their 'Librebox.' Libretrend is, quite sadly, defunct - it was the maker of the 'librebox' which to my knowledge is the sole 'thin mini-ITX' motherboard supported by coreboot. However, Libretrend did not manufacture their own hardware, but instead seemingly ordered it from an external OEM - indeed this OEM is linked to in the coreboot docs. The page for their version of the board is here: http://www.minicase.net/product_LR-i7S65T1.html Indeed the OEM version, the LR-i7S65T1, looks exactly the same as the Libretrend Librebox. Would anyone happen to know if the OEM LR-i7S65T1 would be supported by the Libretrend Librebox coreboot port? Or is the hardware between the OEM (minicase) and distributor (libretrend) versions of this board different somehow? Thanks all, - Daniel C.

1 0

retroboot: new coreboot distro with automated build system
by Leah Rowe 27 Dec '20

27 Dec '20

Posted this in #coreboot IRC just now Retroboot is a new build system forked from Libreboot build system. It provides an automated build system around coreboot, GRUB, SeaBIOS, and all the other components needed, and provides ROMs for users. it provides documentation aimed at non-technical users, and user support. Unlike Libreboot, it allows blobs and includes the 3rdparty repo. It is a very competent build system and can have *any* coreboot system added to it. Boards specify a revision aswell, so it's possible to specify older coreboot revisions if you want to add a board that was removed from coreboot. 06:12 <unoccupied> https://retroboot.org/ launched yesterday 06:13 <unoccupied> it's a new coreboot distribution. it tries to use the latest version of coreboot at all times, and provides an automated build system around coreboot that integrates many other things such as payloads 06:13 <unoccupied> the aim is to provide pre-built ROMs, utilities and user-friendly documentation, with user-friendly support, but developer documentation is also provided which explains the entire build system 06:13 <unoccupied> there are no releases yet, just the website and the git repo, but build instructions are provided. 06:14 <unoccupied> it is a fork of the libreboot 20160907 build system, with many improvements. i've worked on it non-stop for 2 weeks. 06:14 <unoccupied> it's based on libreboot build system, but allows blobs from coreboot and includes the 3rdparty repo. 06:14 <unoccupied> it can support any board from coreboot, and i welcome any and all coreboot users who wish to give it a try! 06:15 <unoccupied> This is build instructions: https://retroboot.org/docs/git/ 06:15 <unoccupied> This is maintenance instructions (shows how to add new boards and maintain them): https://retroboot.org/docs/maintain/ 06:15 <unoccupied> adding boards is basicall: add a config, specify what payload you want, add whatever customer patches you want. then build! 06:16 <unoccupied> IRC is #retroboot if you wish to discuss development. though no actual coreboot development is allowed; coreboot dev must be done in coreboot, with your coreboot work mergede downstream in retroboot 06:16 <unoccupied> enjoy! 06:16 <unoccupied> just thought i'd post this here -- Leah Rowe, Company director. And now, a song: https://blog.vimuser.org/free-firmware-song.html Minifree Ltd, trading as RetroFreedom, Registered in England, No. 9361826, VAT No. GB202190462, Registered Office: 19 Hilton Road, Canvey Island, Essex SS8 9QA, UK

1 0

Will coreboot work on my Getac B360
by Christopher Rau 22 Dec '20

22 Dec '20

Hi, I have an Getac B360 Laptop with these Specs: sudo lspci -tvnn -[0000:00]-+-00.0 Intel Corporation Comet Lake-U v1 4c Host Bridge/DRAM Controller [8086:9b61] +-02.0 Intel Corporation UHD Graphics [8086:9b41] +-12.0 Intel Corporation Comet Lake Thermal Subsytem [8086:02f9] +-13.0 Intel Corporation Comet Lake Integrated Sensor Solution [8086:02fc] +-14.0 Intel Corporation Comet Lake PCH-LP USB 3.1 xHCI Host Controller [8086:02ed] +-14.2 Intel Corporation Comet Lake PCH-LP Shared SRAM [8086:02ef] +-15.0 Intel Corporation Serial IO I2C Host Controller [8086:02e8] +-15.1 Intel Corporation Comet Lake Serial IO I2C Host Controller [8086:02e9] +-15.2 Intel Corporation Device [8086:02ea] +-16.0 Intel Corporation Comet Lake Management Engine Interface [8086:02e0] +-17.0 Intel Corporation Comet Lake SATA AHCI Controller [8086:02d3] +-1c.0-[01]----00.0 Realtek Semiconductor Co., Ltd. RTS522A PCI Express Card Reader [10ec:522a] +-1c.7-[02]----00.0 Intel Corporation Wi-Fi 6 AX200 [8086:2723] +-1d.0-[03-07]-- +-1d.4-[08]----00.0 Sandisk Corp WD Black 2019/PC SN750 NVMe SSD [15b7:5006] +-1f.0 Intel Corporation Comet Lake PCH-LP LPC Premium Controller/eSPI Controller [8086:0284] +-1f.3 Intel Corporation Comet Lake PCH-LP cAVS [8086:02c8] +-1f.4 Intel Corporation Comet Lake PCH-LP SMBus Host Controller [8086:02a3] +-1f.5 Intel Corporation Comet Lake SPI (flash) Controller [8086:02a4] \-1f.6 Intel Corporation Ethernet Connection (6) I219-LM [8086:15bd] Getting SMBIOS data from sysfs. SMBIOS 3.2.0 present. Table at 0x9A241000. Handle 0x0000, DMI type 0, 26 bytes BIOS Information Vendor: INSYDE Corp. Version: R1.15.070520 Release Date: 11/18/2020 Address: 0xE0000 Runtime Size: 128 kB ROM Size: 12 MB Characteristics: PCI is supported BIOS is upgradeable BIOS shadowing is allowed Boot from CD is supported Selectable boot is supported EDD is supported Japanese floppy for NEC 9800 1.2 MB is supported (int 13h) Japanese floppy for Toshiba 1.2 MB is supported (int 13h) 5.25"/360 kB floppy services are supported (int 13h) 5.25"/1.2 MB floppy services are supported (int 13h) 3.5"/720 kB floppy services are supported (int 13h) 3.5"/2.88 MB floppy services are supported (int 13h) 8042 keyboard services are supported (int 9h) CGA/mono video services are supported (int 10h) ACPI is supported USB legacy is supported BIOS boot specification is supported Targeted content distribution is supported UEFI is supported I didnt find Comet Lake on you Motherboard site. regards DevMcLin

2 1

Why is AGESA blob necessary when AMD Secure Processor initializes DRAM?
by Paul Menzel 21 Dec '20

21 Dec '20

Dear Marshall, dear Felix, dear coreboot folks, As documented in *AMD Family 17h in coreboot* [1][2], the AMD Secure Processor [3], formerly known as Platform Security Processor [4], now discovers, enables and trains DRAM [5]. Ron compared it to the QEMU Q35 target in his OSFC 2020 talk *pure open source on an AMD Zen* [6]. My question is, why is the AGESA proprietary blob still integrated into coreboot (using the FSP driver)? I thought, the blobs were only needed for memory initialization, and the rest could be done in coreboot. From *AMD Family 17h in coreboot* [1]: > Support in coreboot for modern AMD products is based on AMD’s > reference code: AMD Generic Encapsulated Software Architecture > (AGESA™). AGESA contains the technology for enabling DRAM, configuring > proprietary core logic, assistance with generating ACPI tables, and > other features. Could this be done in coreboot? Shouldn’t Ron’s approach be the way forward for future devices seeing to depend on as few blobs as necessary? Kind regards, Paul [1]: https://doc.coreboot.org/soc/amd/family17h.html [2]: https://review.coreboot.org/cgit/coreboot.git/tree/Documentation/soc/amd/fa… [3]: https://www.amd.com/en/technologies/pro-security [4]: https://en.wikipedia.org/wiki/AMD_Platform_Security_Processor [5]: https://doc.coreboot.org/soc/amd/family17h.html#problem-statements [6]: https://cfp.osfc.io/osfc2020/talk/TBSHA8/

2 1

I NEED HELP
by Nez Civil 18 Dec '20

18 Dec '20

Hi I have an Acer aio device that has a BIOS type COREBOOT version 4.9 acer chromebace CA5W1 Chrome OS is installed by default, now I have installed the Windows operating system from the BIOS, but the sound card driver is not installed, and also to enter Windows, you must first enter the BIOS and enter Windows from the BIOS I wanted to ask, is there a way to solve the sound card problem? And entered Windows directly without the BIOS Photo of the device specifications and stickers on the back of the device are attached. Thank you for your guidance

2 1

Tiger Lake FSP Released
by Desimone, Nathaniel L 17 Dec '20

17 Dec '20

Hi All, Intel is pleased to announce that Tiger Lake FSP is now available at https://github.com/intel/FSP. With Best Regards, Nate

1 0

Master currently broken on Thinkpad X230 when using option table
by Merlin Büge 16 Dec '20

16 Dec '20

Hi, on my Thinkpad X230 coreboot master does not boot when using the option CONFIG_USE_OPTION_TABLE=y. The screen just stays black. I have no log. This may also affect other platforms(?). I git-bisected the issue and it seems the following commit has introduced it: 9d0cc2aea9 cbfs: Introduce cbfs_ro_map() and cbfs_ro_load() https://review.coreboot.org/c/coreboot/+/39306 Attached is a working an non-working defconfig. Note that CONFIG_NVRAMCUI_SECONDARY_PAYLOAD=y pulls in CONFIG_USE_OPTION_TABLE=y as a dependency. Regards, -- Merlin Büge

4 6

[SPECIFICATION RFC] The firmware and bootloader log specification
by Daniel Kiper 15 Dec '20

15 Dec '20

Hey, This is next attempt to create firmware and bootloader log specification. Due to high interest among industry it is an extension to the initial bootloader log only specification. It takes into the account most of the comments which I got up until now. The goal is to pass all logs produced by various boot components to the running OS. The OS kernel should expose these logs to the user space and/or process them internally if needed. The content of these logs should be human readable. However, they should also contain the information which allows admins to do e.g. boot time analysis. The log specification should be as much as possible platform agnostic and self contained. The final version of this spec should be merged into existing specifications, e.g. UEFI, ACPI, Multiboot2, or be a standalone spec, e.g. as a part of OASIS Standards. The former seems better but is not perfect too... Here is the description (pseudocode) of the structures which will be used to store the log data. struct bf_log { uint32_t version; char producer[64]; uint64_t flags; uint64_t next_bf_log_addr; uint32_t next_msg_off; bf_log_msg msgs[]; } struct bf_log_msg { uint32_t size; uint64_t ts_nsec; uint32_t level; uint32_t facility; uint32_t msg_off; char strings[]; } The members of struct bf_log: - version: the firmware and bootloader log format version number, 1 for now, - producer: the producer/firmware/bootloader/... type; the length allows ASCII UUID storage if somebody needs that functionality, - flags: it can be used to store information about log state, e.g. it was truncated or not (does it make sense to have an information about the number of lost messages?), - next_bf_log_addr: address of next bf_log struct; none if zero (I think newer spec versions should not change anything in first 5 bf_log members; this way older log parsers will be able to traverse/copy all logs regardless of version used in one log or another), - next_msg_off: the offset, in bytes, from the beginning of the bf_log struct, of the next byte after the last log message in the msgs[]; i.e. the offset of the next available log message slot; it is equal to the total size of the log buffer including the bf_log struct, - msgs: the array of log messages, - should we add CRC or hash or signatures here? The members of struct bf_log_msg: - size: total size of bf_log_msg struct, - ts_nsec: timestamp expressed in nanoseconds starting from 0, - level: similar to syslog meaning; can be used to differentiate normal messages from debug messages; the exact interpretation depends on the current producer type specified in the bf_log.producer, - facility: similar to syslog meaning; can be used to differentiate the sources of the messages, e.g. message produced by networking module; the exact interpretation depends on the current producer type specified in the bf_log.producer, - msg_off: the log message offset in strings[], - strings[0]: the beginning of log message type, similar to the facility member but NUL terminated string instead of integer; this will be used by, e.g., the GRUB2 for messages printed using grub_dprintf(), - strings[msg_off]: the beginning of log message, NUL terminated string. Note: The producers are free to use/ignore any given set of level, facility and/or log type members. Though the usage of these members has to be clearly defined. Ignored integer members should be set to 0. Ignored log message type should contain an empty NUL terminated string. The log message is mandatory but can be an empty NUL terminated string. There is still not fully solved problem how the logs should be presented to the OS. On the UEFI platforms we can use config tables to do that. Then probably bf_log.next_bf_log_addr should not be used. On the ACPI and Device Tree platforms we can use these mechanisms to present the logs to the OSes. The situation gets more difficult if neither of these mechanisms are present. However, maybe we should not bother too much about that because probably these platforms getting less and less common. Anyway, I am aware that this is not specification per se. The goal of this email is to continue the discussion about the idea of the firmware and booloader log and to find out where the final specification should land. Of course taking into the account assumptions made above. You can find previous discussions about related topics at [1], [2] and [3]. Additionally, I am going to present this during GRUB mini-summit session on Tuesday, 17th of November at 15:45 UTC. So, if you want to discuss the log design please join us. You can find more details here [4]. Daniel [1] https://lists.gnu.org/archive/html/grub-devel/2019-10/msg00107.html [2] https://lists.gnu.org/archive/html/grub-devel/2019-11/msg00079.html [3] https://lists.gnu.org/archive/html/grub-devel/2020-05/msg00223.html [4] https://twitter.com/3mdeb_com/status/1327278804100931587

14 13

Why a size of MPTABLE is limited by 600 bytes? Where this number comes from?
by Mike Banon 13 Dec '20

13 Dec '20

Some boards, including my AMD Lenovo G505S laptop, have a MPTABLE size which is slightly larger than 600, and I'm seeing the lines like Skipping MPTABLE copy due to large size (628 bytes) at the coreboot logs. Do you think MPTABLE size could be bumped to i.e. 700 bytes, or there's some internal limitation which prevents from doing this? Best regards, Mike Banon

1 0

nasm.us is currently down. temporary fix is to use fossies.org
by Mike Banon 13 Dec '20

13 Dec '20

nasm is a part of coreboot's toolchain. For those who are in a hurry, could open ./coreboot/util/crossgcc/buildgcc and replace a NASM_ARCHIVE line with NASM_ARCHIVE="https://fossies.org/linux/misc/nasm-${NASM_VERSION}.tar.bz2" (its' checksum is going to be verified, so no trust issues) Best regards, Mike Banon

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