I would appreciate any guidance on the proper way to reserve (arbitrary)
DRAM for a MMIO device in coreboot such that the Linux driver for that
device is also able to map the reserved DRAM.
Based on code inspection, my attempt is to add a cbmem entry via
cbmem_alloc and mark that memory as reserved via reserved_ram_resource in
the read_resources operation for the device driver.
static void foo_read_resources(struct device *dev)
{
void *buf;
const unsigned long size = 0x8000;
if (cbmem_entry_find(CBMEM_ID_FOO))
return;
buf = cbmem_add(CBMEM_ID_FOO, size);
if (!buf)
return;
reserved_ram_resource(dev, 0, ((unsigned long)buf) >> 10, size >>
10);
}
I can see that the resource is allocated during resource reading.
MMIO: fd110500 resource base *8de82000* size 8000 align 0 gran 0 limit 0
flags f0004200 index 0
I then pass this resource to the linux driver via an ACPI device entry.
acpigen_write_name("_CRS");
acpigen_write_resourcetemplate_header();
const struct cbmem_entry *ce = cbmem_entry_find(CBMEM_ID_FOO);
if (ce)
acpigen_write_mem32fixed(1, (uint32_t)cbmem_entry_start(ce),
(uint32_t)cbmem_entry_size(ce));
However, the memory is presented to Linux as "type 16" instead of
"reserved" in the physical RAM map.
[ 0.000000] BIOS-provided physical RAM map:
[ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x0000000000000fff] type
16
[ 0.000000] BIOS-e820: [mem 0x0000000000001000-0x000000000009ffff] usable
[ 0.000000] BIOS-e820: [mem 0x00000000000a0000-0x00000000000fffff]
reserved
[ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000008de34fff] usable
*[ 0.000000] BIOS-e820: [mem 0x000000008de35000-0x000000008fffffff] type
16*
[ 0.000000] BIOS-e820: [mem 0x0000000090000000-0x00000000cfffffff]
reserved
[ 0.000000] BIOS-e820: [mem 0x00000000f8000000-0x00000000fbffffff]
reserved
[ 0.000000] BIOS-e820: [mem 0x0000000100000000-0x000000022f33ffff] usable
[ 0.000000] BIOS-e820: [mem 0x000000022f340000-0x000000022fffffff]
reserved
The e820 type 16 is unknown to the linux kernel, causing it to mark the
region as busy. This subsequently causes devm_ioremap_resource to fail
when called on the DRAM address from the ACPI device entry.
Looking through the code, it seems that coreboot marks the entire cbmem as
type 16 in bootmem despite my (improper, it would seem) attempt to mark the
ram as reserved. What would be the proper way to reserve (arbitrary) DRAM
for a MMIO device such that the memory is marked as reserved in the BIOS
physical RAM map?
Thanks.
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
Hello,
I have migrated my work-in-progress project, adding a new mainboard,
from coreboot v4.12 to v4.13 and now the boot using Tianocore is now
broken!
Under v4.12 it would boot into Ubuntu but under v4.13 it is just putting
me at a menu screen with three options: “Default Boot”, “Boot Menu” and
“Boot Manager”. If I choose “Boot Menu” it doesn’t list any boot
devices.
Uisng "Boot Manager” -> “Boot from file” I can navigate into one of the
NVMe partitions and down the folders efi/boot/bootx64.efi and that will
boot into Ubuntu via the following messages being shown on the screen:
System BootOrder not found. Initialising defaults.
Creating boot entry “Boot0004” with label “ubuntu” for file
“EFI\ubuntu\shimx64.efi”
Could not create variable: Device Error
When I reboot I just get back to the menu screen.
I’m guessing there is a ne option in v4.13 that needs to be set or there
is something that has changed v4.12 -> v4.13 but half a day of staring
at it hasn’t shown it up. Given the messages are referring to
shimx64.efi I guess it is something to do with secure boot.
-Andy.
Hi,
Breaking this out from my other email for title clarity purposes, hope
that's ok.
Anyway, I think my issue comes down to coreboot not being able to access
(?) PCI extended registers in the current setup.
I guess this is a general question: CAN coreboot access the extended
capabilities registers of PCI devices? If yes, are there any special
options that need to be set or adjusted during the build?
I've attached a "pci -i" dump from the EFI shell for my device on stock
BIOS vs coreboot - as one can see, the coreboot log ends before outputting
any of the extended registers whereas the BIOS log dumps the full config
space.
Any ideas for what I could try here, or reasons why it might not (be
expected to) work?
Cheers,
R
Hello people,
This is a last reminder on the upcoming OSFC 2020 (www.osfc.io) which will start tomorrow noon CET.
If you are interested in attending the conference, please get your tickets via https://hopin.com/events/osfc-2020
Best regards,
Philipp
Hi!
This is my first post in this mailing list. Nice to meet you all.
I have a feature request. (I'm not sure if I'm the first to request this,
so feel free to direct me to any existing discussions about this topic, if
there is one.)
Would it be possible to add a payload option "Tianocore with SeaBIOS CSM"
in the config menu? Right now, we have to choose between a Tianocore
payload and a SeaBIOS payload, or otherwise provide our own manually built
payload.
It's possible for SeaBIOS to be built as a Compatibility Support Module
(CSM) FOR UEFI BIOSes, and Tianocore can be built with the resulting CSM.
However, right now people need to first build SeaBIOS as a CSM, then build
Tianocore with the CSM and then add it as a custom ELF executable payload
during the "make menuconfig" or "make nconfig" stage of the Coreboot build
procedure. Those are quite a few extra error-prone manual steps.
It would be really helpful if all these manual steps could be skipped by
adding this payload option to the existing payload options and doing all
the required intermediate building for us.
The vendor BIOS that I wish to replace with Coreboot already contains a
UEFI with a CSM, and I'd like to preserve that functionality once I switch
to Coreboot. I'm sure I'm not the only one who'd like to have the
flexibility of being able to boot both modern OSes through UEFI and legacy
OSes using the CSM.
Since new UEFI hardware will be shipping without CSMs as of 2020, having
this in Coreboot by default would make Coreboot even more attractive to
people who'd like to add back such legacy compatibility.
Thanks for considering this!
Hello,
With the stock BIOS in the board I am working on one of the nodes for
the ALC256 CODEC is:
Node 0x21 [Pin Complex] wcaps 0x40058d: Stereo Amp-Out
Control: name="Headphone Playback Switch", index=0, device=0
ControlAmp: chs=3, dir=Out, idx=0, ofs=0
Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
Amp-Out vals: [0x80 0x80]
Pincap 0x0001001c: OUT HP EAPD Detect
EAPD 0x2: EAPD
Pin Default 0x02214020: [Jack] HP Out at Ext Front
Conn = 1/8, Color = Green
DefAssociation = 0x2, Sequence = 0x0
Pin-ctls: 0xc0: OUT HP
Unsolicited: tag=01, enabled=1
Power states: D0 D1 D2 D3 EPSS
Power: setting=D0, actual=D0
Connection: 2
0x02 0x03*
In the real world we are finding that the detection of headphones being
plugged in aren’t being detected and the audio continues to be played
through the onboard speakers. Based on experimentation the customer has
determined that the alc256-asus-mic quirk in the Linux kernel gets it
work properly but I want to fix this issue properly in Coreboot.
The only change in the output of /proc/asound/card/codec#0 appears to
be:
Node 0x21 [Pin Complex] wcaps 0x40058d: Stereo Amp-Out
changes to:
Node 0x21 [Pin Complex] wcaps 0x03211020: Stereo Amp-Out
I’m assuming that this needs me to add some raw 32bit values into
cim_verb_data[] as well as the AZALIA_PIN_CFG() definitions that I
already have.
Based on what I have seen in files such
(src/mainboard/intel/coffeelake_rvp/variants/cml_u/include/variant/hda_verb.h
then I guess this is going to be multiple values that will be of the
form 0x021xxxxx. How do I convert the change I need to make to fill in
the xxxxx values?
-Andy.
Hello,
Using the VBT route for graphics initialisation and TianoCore as the
payload gives two options within .config for splash screen:
CONFIG_BOOTSPLASH:
This option shows a graphical bootsplash screen. The graphics are loaded
from the CBFS file bootsplash.jpg.
CONFIG_TIANOCORE_BOOTSPLASH_IMAGE:
Select this option if you have a bootsplash image that you would like to
be used. If this option is not selected, the default coreboot logo
(European Brown Hare) will used.
Do I need to define both? What are the requirements for the images in
terms of size, colour depth, etc?
-Andy.
Hello all,
When I boot my board (Intel Comet Lake based) using Coreboot I have one
too many I2C busses compared to the stock AMI BIOS. Using i2cdetect
under Ubuntu with the stock BIOS it shows:
$ i2cdetect -l
i2c-3 unknown i915 gmbus dpc N/A
i2c-1 unknown Synopsys DesignWare I2C adapter N/A
i2c-6 unknown DPDDC-A N/A
i2c-4 unknown i915 gmbus misc N/A
i2c-2 unknown i915 gmbus dpb N/A
i2c-0 unknown SMBus I801 adapter at efa0 N/A
i2c-7 unknown DPDDC-C N/A
i2c-5 unknown i915 gmbus dpd N/A
When I run the same command having booted using Coreboot then it gives:
$ i2cdetect -l
i2c-3 unknown i915 gmbus dpb N/A
i2c-1 unknown SMBus I801 adapter at efa0 N/A
i2c-8 unknown DPDDC-C N/A
i2c-6 unknown i915 gmbus dpd N/A
i2c-4 unknown i915 gmbus dpc N/A
i2c-2 unknown Synopsys DesignWare I2C adapter N/A
i2c-0 unknown Synopsys DesignWare I2C adapter N/A
i2c-7 unknown DPDDC-A N/A
i2c-5 unknown i915 gmbus misc N/A
I’m guessing these are controlled by the devices that are configured in
the devicetree.cb file. What I have currently that appears to be
related to I2C is:
register "SerialIoDevMode" = "{
[PchSerialIoIndexI2C0] = PchSerialIoPci,
[PchSerialIoIndexI2C1] = PchSerialIoPci,
[PchSerialIoIndexI2C2] = PchSerialIoPci,
[PchSerialIoIndexI2C3] = PchSerialIoPci,
[PchSerialIoIndexI2C4] = PchSerialIoDisabled,
[PchSerialIoIndexI2C5] = PchSerialIoDisabled,
}”
device pci 15.0 on end # I2C #0
device pci 15.1 off end # I2C #1
device pci 15.2 off end # I2C #2
device pci 15.3 off end # I2C #3
device pci 19.0 off end # I2C #4
device pci 19.1 off end # I2C #5
device pci 1f.4 on end # SMBus
The definitions of “on” and “off” are based on lspci only reporting PCI
devices 15.0 and 1f.4 when Linux is booted using the stock BIOS.
-Andy.
