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.
Dear friends, I'm trying to properly program the IRQ tables for Lenovo
G505S, because the old IRQ routing is bad and doesn't work for a
simple OS like Kolibri. Full details are in the comments under this
change:
https://review.coreboot.org/c/coreboot/+/46587/
When I used the old picr_data/intr_data values of G505S for the new
structures, I got only 1 IRQ working. However, with a copy-paste of
AM1I-A - surprisingly 12 IRQs and a laptop boots, but still some
problems. Please advise how to compose mainboard_picr_data/_intr_data
and also a intel_irq_routing_table, your help will be very much
appreciated.
Best regards,
Mike Banon
Hi,
I study in AMD AGESA v9 boot in the coreboot.
So far, I boot to the FSP image failed as below log.
CBFS: Locating 'fspm.bin'
CBFS: 'fspm.bin' not found.
FSPM not available or failed to load!
And I google the related information, found the gerrit review information(https://review.coreboot.org/c/coreboot/+/34423/),
I want to query you how to make/create the FSP binary for AMD or FSP information to coreboot image.
Could you give me some instructions? Thanks.
Hello Everyone,
We are using SPI flash(Macronix) to program the BIOS. And we use an
external programmer to flash the BIOS (coreboot including FD+ME) into SPI
Flash (16384 kB, SPI), it works fine and boots well. The board is
functional and we have successfully booted a kernel on it.
Am working on adding a feature to upgrading the BIOS (complete
IFD+ME+Coreboot) using intel-spi driver at the OS level. Able to
successfully take the backup full 16MB spi nor flash data which
includes IFD+ME+BIOS using flashrom Internal Programmer option and it is
identified as Opaque flash chip and using dd command as well.
But we are seeing the erase fail through both flashrom and flash_erase
utility. I believe it fails to erase at the flash descriptor location.
As far as Read/Write access to the SPI regions, I have enabled the Host CPU
BIOS write access and ME Master Access as 0xFFFF through Intel FIT Tool but
still not able to erase it and it fails.
Is there anything that could be preventing to enable read/write access to
the Intel flash descriptor or any SOC SPI controller protection to access
the Flash descriptor?
Any pointers would be appreciated.
Thanks
Balaji
We are using SPI flash(Macronix) to program the BIOS. And we use an
external programmer to flash the BIOS (coreboot including FD+ME) into SPI
Flash (16384 kB, SPI), it works fine and boots well. The board is
functional and we have successfully booted a kernel on it.
Am working on adding a feature to upgrading the BIOS (complete
IFD+ME+Coreboot) using intel-spi driver at the OS level. Able to
successfully take the backup full 16MB spi nor flash data which
includes IFD+ME+BIOS using flashrom Internal Programmer option and it is
identified as Opaque flash chip and using dd command as well.
But we are seeing the erase fail through both flashrom and flash_erase
utility. I believe it fails to erase at the flash descriptor location.
As far as Read/Write access to the SPI regions, I have enabled the Host CPU
BIOS write access and ME Master Access as 0xFFFF through Intel FIT Tool but
still not able to erase it and it fails.
Is there anything that could be preventing to enable read/write access to
the Intel flash descriptor or any SOC SPI controller protection to access
the Flash descriptor?
--
Thanks,
Balaji
hello,
Is there a way to extract mrc.bin from a normal(not chromehook rom) bios
binary from the flash dump? There's no chromebook available with the Atom
N2600 chip. There is one with Atom N570, but will it work? If not then I
want to know if native ram init is supported in CedarTrail chipsets. I
think it should be because Sandy bridge is supported and they were
simillar(I think). CedarTail has no FSPs available on github so I must
have to build the non-FPS version.....which means I cannot get mrc.bin.
Hi!
Quick heads-up: In [1] I updated the submodule pointer of amd_blobs so
that it now tracks the new official repository [2]. Since the new
repository and the old don't have common ancestors, using the git sup
alias to update the submodules, that rebases the changes, will fail
causing git to fall back to a 3 way merge. Since the new repository
contains updated firmware blobs, that merge also fails.
To fix the issue run the following commands:
(cd 3rdparty/amd_blobs; git rebase --abort); git submodule update --checkout
Regards
Felix
[1] https://review.coreboot.org/c/coreboot/+/46594/
[2] https://github.com/amd/firmware_binaries
Dear coreboot, GRUB, and SeaBIOS folks,
In #coreboot(a)irc.freenode.net somebody mentioned the Universal Payload
Project [1].
> The goal of this project is to define an interface between a first
> stage platform initialization bootloader and a second stage payload.
As there also is a specification [2], I just wanted to make you aware of
it, in case you have comments. Please keep in mind, that I do not know
more details, so please do not jump to conclusions.
Kind regards,
Paul
[1]: https://github.com/universalpayload/Introduction
[2]: https://universalpayload.github.io/documentation/spec/spec.html
Hi folks,
As some of you may know, I've been working on a way to add
verification directly into CBFS (as opposed to the current vboot that
can only verify images as a whole) for a while (I have presented at
OSFC 2019: https://www.youtube.com/watch?v=Hs_EhewBgtM and published a
general design document:
https://osfc.io/uploads/talk/paper/47/The_future_of_firmware_verification_i…).
As part of this work I have been very careful to keep all these
changes fully backwards-compatible so that existing payloads with
their own CBFS implementations will continue to work.
I have now come across a fundamental problem that I cannot solve
without introducing a small backwards-incompatible change: the CBFS
"stage" format that is used to store the code for coreboot stages
(e.g. romstage, ramstage) consists of a small "stage header"
containing things like load address and size in front of the actual
binary code. From the point of view of the generic CBFS structure,
both that header and the code are part of the "file data" (and not the
generic CBFS "file header" that contains things like the file name or
generic CBFS attributes).
This creates a tough chicken-and-egg problem when verifying pre-RAM
stages, because (for platforms that actually load pre-RAM stages and
don't execute in-place, like Arm platforms running from SRAM) the
stage needs to be directly loaded into the final location it should
execute out of, but the load address containing that location is in
the stage header. My verification design works on whole files, so the
stage header cannot be trusted before the whole file was loaded and
hashed. But I can't load it without information from the stage header,
and there's generally not enough scratch space in these pre-RAM
environments to first load it somewhere else and then copy it over to
its final destination after verification.
My solution to this problem is to move the stage header out of the
file data into a CBFS attribute that is stored in the generic CBFS
file header. File headers are verified separately so they can already
be trusted by the time the file data needs to be loaded. I think this
is arguably a somewhat cleaner approach anyway (the concept of CBFS
attributes just didn't exist yet when the stage format was originally
designed, so it wasn't written that way to start with), but of course
these new stages will be incompatible to the old ones. I believe this
is okay because the "stage" format is generally only used for parts of
coreboot itself (e.g. romstage, ramstage), whereas the payload and
other binaries the payload may want to chain-load should be using the
"simple ELF" (SELF) format anyway. Since coreboot is always built as a
whole, when you're gonna build the new version all your stages will be
in the new format and all code that loads them will know how to load
the new format, so you should be fine. Tying this into a payload build
system that is not aware of these changes should be okay because that
payload shouldn't try to add extra files using the "stage" format, and
shouldn't try to load any stages (if it wants to chain-load things it
should be using the SELF format with cbfstool add-payload, not
add-stage).
But this file format has remained untouched for the whole 10+ years
CBFS existed, so I thought I should ask before I do it. If you know
any payloads that do use the "stage" format for files outside of
coreboot itself and that couldn't adapt to this change for some
reason, or have any other concerns about unexpected problems this
could be causing you, please let me know here or on the CL:
https://review.coreboot.org/46484
Note that for cbfstool, this will also mean that newer versions of
cbfstool will only support the new format. I think this should also be
okay because coreboot is built as a whole, i.e. all your stages are
added with a cbfstool version that was built from the same code base
version as the coreboot code trying to load these stages. But it does
mean that if you have an old version of cbfstool stashed away
somewhere and try to use it to cbfstool print -v or cbfstool extract a
new coreboot image, it won't be able to show load address or entry
point for the new stages or convert them back into an ELF file on
extraction (or vice versa for new versions of cbfstool on old images).
So if you do a lot of after-the-fact cbfstool manipulation on
different versions of coreboot images (which is probably only done by
people trying to debug something?), you may need to keep two cbfstool
versions to switch back-and-forth between for a while. It would be
possible to make the new cbfstool version support both formats for
reading/extracting but that's a bunch of extra work that I hope I can
avoid unless people really feel like this is gonna be a widespread
problem.
Also note that I'm not planning to touch the SELF (payload) format
(which also has a header in the "file data" part) -- I will keep that
as it is because I think it's much more likely that external payloads
are using it for their own purposes that I don't want to break. It's
also not necessary because SELFs are mostly just used in post-RAM
environments and the SELF loader code already requires it (on
non-memory-mapped platforms) to be loaded to a separate scratch buffer
before copying the individual pieces to where they need to go. When we
have that buffer anyway, it's easy to verify the whole file in there
before examining the header.
