Hello,
Recently I have decided to give a try to coreboot for first time and
flashed my ThinkPad T420, but a few weeks ago I have swapped the USB
controller on the back, next to the battery, with a FireWire/USB controller
(40GAB5809-G200) from another T420. Nothing special, since some models have
been shipped like this. The controller is no longer accessible on my laptop.
It seems like it may have been detected as an "SD Host Controller" or not
detected at all. I will probably have to remove the chip and compare the
output of lspci and lshw. If nothing has changed, I will probably have to
return the stock BIOS and compare the results again. I have also tried to
load some of the firewire kernel modules manually with modprobe.
The operating systems I have tested so far are Arch Linux and Xubuntu. I am
willing to provide more useful information, boot into a fresh Windows
install, flash the chip again or whatever else. Correct me if I am wrong,
but if I go back to the stock BIOS, the next time I flash, I will have to
disassemble the laptop again and otherwise I must be fine with flashing
internally, right?
Thanks
Hello!
I just tried to synch my local tree with what's stored back there, and
instead of watching it update I saw this one:
fatal: unable to access 'https://review.coreboot.org/coreboot.git/':
SSL certificate problem: certificate has expired
Huh?
Is everyone else aware of this?
-----
Gregg C Levine gregg.drwho8(a)gmail.com
"This signature fought the Time Wars, time and again."
Hi everyone,
I've been working on improving the specification for the firmware and bootloader
log that Daniel Kiper has proposed and take into account most of the suggestions
that were made in these threads [1], [2].
The goal is to allow various boot components to pass logs to the running OS and
then to the user space for processing and analysis. These logs should be generic
enough so that it can work in multiple environments and be human readable.
It has yet to be decided where to put the final version of this specification.
It should be merged into an existing specification, e.g. UEFI, ACPI, Multiboot2,
or be standalone, such as a part of OASIS Standards.
Below is how the layout of these logs would store their data.
bf_log_header:
+-------------------+
u32 | version |
u32 | size |
u8[64] | producer |
u8[64] | log_format |
u64 | flags |
u64 | next_bflh_addr |
u64 | log_addr |
u32 | log_size |
+-------------------+
bf_log_buffer:
+-------------------+
u32 | version |
u32 | size |
u8[64] | producer |
u32 | next_msg_off |
bf_log_msg[l] | msgs |
+-------------------+
bf_log_msg:
+-------------------+
u32 | size |
u64 | ts_nsec |
u32 | level |
u32 | facility |
u32 | msg_off |
u8[n] | type |
u8[m] | msg |
+-------------------+
Where l is the number of msgs, n is the size of type, and m is the size of the
msg.
The bf_log_header structure forms a linked list. Each bf_log_header element in
the linked list points to the individual log buffer and the next bf_log_header
element in the linked list. The first element in the linked list points to the
last boot component in the boot chain. The last element points to the starting
boot component in the boot chain. The log buffers which contain the log
messages are produced by the various boot components, typically from the
firmware to the bootloader. The log message is stored in a log format that is
compatible with the boot component that produced it.
The fields in bf_log_header structure:
- version: the firmware and bootloader log header version number, 1 for now,
- size: the size of the bf_log_header to allow for backward compatibility if
other fields are added,
- producer: the producer/firmware/bootloader/... entity, NUL terminated
string, e.g. GRUB, Coreboot; the length allows for ASCII UUID storage,
- log_format: the format used to record the log messages, NUL terminated
string, e.g. bf_log_msg, cbmem_cons, etc.; various producers may generate
logs in various formats if needed,
- flags: bit field used to store information about the log state, if bit 0 has
been set it means the log was truncated,
- next_bflh_addr: the physical address of the next bf_log_header structure,
none if zero,
- log_addr: the physical address of where the log buffer is stored,
- log_size: the total size of the log buffer.
The bf_log_buffer is used to store log messages from the firmware and
bootloader. This format for storing messages is called the bf log format. The
bf_log_buffer contains the header information of the bf log format with the log
messages being stored in an array of bf_log_msg messages.
The fields in bf_log_buffer structure:
- version: the firmware and bootloader log version number, 1 for now,
- size: the total allocated space for the bf_log_buffer including the log
messages stored in msgs,
- producer: the producer/firmware/bootloader/... entity, NUL terminated
string, e.g. GRUB, Coreboot; the length allows for ASCII UUID storage; same
as the field in bf_log_header,
- next_msg_off: the byte offset from the beginning of the allocated space for
bf_log_buffer to the next byte after the last bf_log_msg in msgs,
- msgs: the array of log messages stored in the bf_log_msg structures.
The fields in bf_log_msg structure:
- size: the total size of the bf_log_msg entry,
- ts_nsec: the timestamp in nanoseconds starting from 0 (zero); the producer
using this log format defines the meaning of 0,
- level: similar to the syslog meaning; used to differentiate normal log
messages from debug log messages, but the exact interpretation depends on
the producer,
- facility: similar to the syslog meaning; used to differentiate the sources
of the log messages, but the exact interpretation depends on the producer,
- msg_off: the byte offset which the msg field starts in bf_log_msg,
- type: the log message type; similar to facility but NUL terminated string
instead of integer, but the exact interpretation depends on the producer,
- msg: the log message, NUL terminated string.
In bf_log_msg, the producers are free to use or ignore any of the level,
facility, and type fields. If level or facility are ignored, they should be set
to 0. If type is ignored, it should be set to an empty NUL terminated string.
Since it doesn't seem possible to have each boot component using the same log
format, we added a log_format and log_phys_addr fields to give flexibility in
how logs are stored. An example of a different log format that can be used is
the cbmem_console log format used by coreboot:
cbmem_console:
+-------------------+
u32 | size |
u32 | cursor |
u8[m] | body |
+-------------------+
There is still the outstanding issue of how the logs will be sent to the OS. If
UEFI is used, we can use config tables. If ACPI or Device Tree is used, we can
use bf_log_header.next_bflh_addr to present the logs. If none of these platforms
are used, it becomes a lot trickier to solve this issue.
Any suggestions are much appreciated and will be taken into consideration.
I will be presenting this work at the LPC System Boot and Security
Micro-conference on the 22nd of September at 7:50 AM PDT (14:50 UTC). Come and
join if you want to discuss the design. The schedule for the System Boot and
Security Micro-conference can be found here [3].
Thanks!
Alec Brown
[1] https://lists.gnu.org/archive/html/grub-devel/2020-11/msg00100.html
[2] https://lists.gnu.org/archive/html/grub-devel/2020-12/msg00021.html
[3] https://linuxplumbersconf.org/event/11/sessions/116/#20210922
Dear coreboot community,
I have encountered problem with silicon init on Tiger Lake RVP platform.
I managed to resolve previous issues with memory initialization and now
hitting an error with TCSS init. The FSP asserts on IOM ready check,
which is 0. The configuration has selected CONFIG_USE_INTEL_FSP_MP_INIT
(without MP PPI service).
When the CONFIG_USE_INTEL_FSP_TO_CALL_COREBOOT_PUBLISH_MP_PPI is
selected, then the FSP-S returns smoothly (at least from one of the
phases I guess) and resets after clearing MCEs in coreboot's CPU init:
CPU: vendor Intel device 806c0
CPU: family 06, model 8c, stepping 00
Clearing out pending MCEs
Setting up local APIC...
apic_id: 0x00 done.
Turbo is available but hidden
Turbo is available and visible
CPU #0 initialized
Initializing CPU #2
Initializing CPU #6
Initializing CPU #7
CPU: vendor Intel device 806c0
CPU: family 06, model 8c, stepping 00
CPU: vendor Intel device 806c0
CPU: family 06, model 8c, stepping 00
Clearing out pending MCEs
Cl (tutaj następuje reset)
Any ideas what may cause these issues? When I clean this up, I will
upstream the DDR4 variant of TGL UP3 RVP.
--
Michał Żygowski
Firmware Engineer
https://3mdeb.com | @3mdeb_com
Hi everybody,
Historically, coreboot avoided depending on python too much (we got rid of
an entire python based configuration and build system, for example), with
few minor exceptions.
The main reason has been that while python code is quick to slap together,
it has demonstrated a penchant for breaking in all kinds of mysterious ways
(python 2->3 really was just a slightly bigger instance of what's going on
in python all the time), and its users demonstrate a disregard for their
fellow developers as demonstrated by endless stack traces on trivial errors
(or is the language too complicated to properly catch them all?)
While probably nice for one-off prototypes, long term maintenance is a
concern: this project has over 20 years of history under its belt, with
more to come.
That said, python makes its way back into the tree every now and then
(typically as small snippets to compute and add hashes to binaries as
needed by ARM SoCs). Uncanny, but typically not a big deal.
There are two bigger initiatives proposed that would significantly increase
our python footprint:
1. Replacing Linux's kconfig with kconfiglib (
https://review.coreboot.org/c/coreboot/+/48679)
2. Using pytest for end-to-end testing utilities (
https://review.coreboot.org/c/coreboot/+/57869)
Compared to the "inject a hash value at a fixed location" scripts, these
would probably be here to stay, and sufficiently integrated that everybody
will have to deal with them.
People spending time working on python code when it has no chance to land
isn't a good use of their time and we should avoid that in the project.
People spending time arguing that python shouldn't be used (to avoid
the other outcome) even though the project's culture shifted and is now
accepting Python isn't creating a great community for anybody.
To avoid these scenarios, could we possibly nail down the policy on python
in coreboot?
Regards,
Patrick
--
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
Since it didn't look like I would be able to get coreboot working on
this laptop, I returned it. I still have all the hardware info I
collected. Is this useful to anyone?
Good morning from France!
I've been tinkering with computers for years, and got some (basic, yet
useful) skills. Recently, reading about the BIOS/EFI/UEFI standard, I
discovered CoreBoot. I tried and succeeded in compiling and using CoreBoot
on a QEmu virtual machine.
But now, I want to go deeper again, and install it on a real machine. The
computer I selected is an old laptop from 2005, a HP ze4111s (single-core
1.6Ghz 32-bit Intel Celeron, 512 Mb DDR RAM, ATI Radeon GPU, enough to run
Raspbian OS Buster). The BIOS is password protected, but I am on my way to
unlock it.
I read the article "CoreBoot porting guide". I understood it. But I still
need some help, and even if I do things right, I have no way to check it.
And if I did wrong, I want to know it before making my computer
irreversibly crashed.
So where can I find help to go through the steps and check if everything is
right? To teach me, in fact. Forums and tutorials are sometimes difficult
to understand, unclear and/or unusable with other machines than te example
one.
The computer I talk about is not my only one, I'm not this much crazy.
Friendly,
Patrick Charon
P.-S.: this address is my "professional" address; my personal address
patc(a)galaxyhit.com often goes to spam. But if you answer, please use this
personal address!
