A pair of 1866MHz CL9 RAM modules* runs only as 1333MHz CL9 on 16h
AM1I-A with coreboot is installed, but worked faster when a
proprietary UEFI was installed. To fix this "turtle RAM" coreboot
problem I tried to play with buildOpts.c -
https://review.coreboot.org/c/coreboot/+/33920 , but the things like
"#define BLDCFG_MEMORY_CLOCK_SELECT DDR1866_FREQUENCY" sadly did not
Any ideas how to improve the RAM speeds? How I can force this RAM to run faster?
[*] Crucial Ballistix Tactical Series DDR3 1866MHz CL9 (PC3-14900
9-9-9-24) UDIMM 240-Pin modules, part number BLT8G3D1869DT1TX0
we want to participate again in FOSDEM 2020. Location: Brussels. Date: 1&2 February.
Own developer room: Expired...
Stand: 1 November
Main track talk: first batch 11 October, second batch 8 November
Lightning talk: 22 November
Talk/Demo in foreign devroom: probably end of October
If you want me to submit a stand request for a combine coreboot/flashrom/LinuxBoot stand, please have someone volunteer as backup organizer. We also need stand volunteers.
Side note: Should we reach out to the OpenBMC/u-bmc communities?
coreboot is shipping AMD's open sourced AGESA for a few generations
as part of its tree.
Some people advocate dropping the code due to its quality and lack
of maintenance while others are happy with using the code.
So: to help keep this code alive, we'd need maintainers - people
willing to work through issues, improve the code quality and generally
act as a point of contact if any questions arise.
One item to start with could be to work through Coverity
issues, where the largest proportion is now AGESA based
after Jacob cleaned up most of the rest of the tree. See
Drivers needs support to not get in the way of later development,
and AGESA is sorely lacking in that department. If you see value
in that code, please step up now, not only when we're looking into
removing that code for good.
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
I have ported coreboot to a custom design based on APL and have random
SATA problems with CFast cards. I am using the latest public APL FSP
from github with the latest coreboot master.
From time to time the SATA link 'dies' during runtime or I it is not
possible to establish the SATA link at all (in the used u-boot
payload). At the moment I am running out of ideas and I hope someone
can point me in the right direction.
Btw. with the vendor blob SATA works with out any problems :/
Christian Gmeiner, MSc
I own an Acer Aspire VN7-572G and have not been impressed with its OEM
firmware. After discovering that it does not utilise Intel's Boot Guard
technology, that several Skylake and Kabylake laptops (it has a Skylake
chip, but I read that the platforms are similar) have received successful
coreboot ports and reading the porting guide on the wiki, I figured that I
could give porting coreboot to my laptop a shot.
When I was done, I figured that I had an image that might boot so I flashed
it to my laptop with a Raspberry Pi and a SOIC clip. However, here's what
a) It powers on quietly, as expected;
b) The backlight and power LED light up;
c) The fans spin up to high and then it stays that way. It does nothing
else. The display is dark too.
After 15 minutes and a second attempt, I figured that I could no longer
blame anything on a long first boot-up and gave up and flashed back to
Now, in all honesty I should have tried first without cleaning Intel ME but
I find it so much more likely that I did something wrong than that cleaning
ME was the sole problem.
Can anyone advise me on how to continue? My code is here:
-----BEGIN PGP SIGNED MESSAGE-----
we see a lot of attention around KGPE-D16 maintainership problems.
After discussion with Thierry Laurion (Insurgo) at OSFC2019 3mdeb
decided to help in maintaining that platform by organizing crowd
founding campaign or getting founds in other ways (direct sponsors).
Since we are based in Poland there is chance that even with small
contribution from community we would be able to cover the costs.
Ideal plan would be to have structure similar to what we maintain for
Where we providing signed and reproducible binaries every month and
keep as close to mainline as possible. Of course if development will
be active, then there always would be delta of patches held in review.
Unfortunately we don't have hardware. During OSFC 2019 Stefan left one
board, but it was too late (and probably too expensive) for us to
organize any shipment to Poland. We looking to have 2 mainboards one
for development and one in our automated regression testing
environment. Of course we will start even with just one.
If anyone is willing to help in founding, sponsoring hardware or by
code development and testing we would be very grateful.
Please copy other people and share this post wherever is necessary to
keep this platform alive. Positive feedback will help things rolling.
Embedded Systems Consultant
https://3mdeb.com | @3mdeb_com
-----BEGIN PGP SIGNATURE-----
-----END PGP SIGNATURE-----
Dear coreboot community,
Please test and review the patch series .
It adds support for x86 long mode on qemu and allows to build test
most of coreboot's common code using the x86_64 toolchain.
It serves as reference implementation to migrate real hardware to long
Here some technical details, that can also be found in the
A new tool called pgtblgen create static page tables for a known
memory address. The page tables are placed in CBFS at the given address.
Due to the fixed and known address, they can easily be loaded in
It only works on platforms that memory map the SPI flash, which are
modern x86 platforms.
The advantage of page tables in ROM are:
* No runtime (assembly) code to generate page tables
* No need to find a (4K aligned) place in heap to store them
* Improved security for SMM, as page tables are always immutable
The page tables are loaded in bootblock and SMM and persist until
control is handed
over to the payload.
For the Proof-of-Concept only 4GiB are identity mapped, thus no stage
memory over 4GiB. That's not a problem for now as no coreboot code make
use of memory
above 4GiB yet.
I haven't done further tests on long mode.
It will be interesting to see if there are improvements on boot speed,
code size or
faster firmware decompression speeds.
I'm new to coreboot and this list, so please forgive and tell me if I'm
doing something wrong.
I've successfully compile coreboot and flash it to a Lenovo x220. I
tried seabios and tianocore as a payload and it works. So strange
compile errors as I'm used to when I compile an opensource project. So,
What I need now is to be able to set the graphic preallocated memory.
Usually in bios, it's "DVMT pre alloc" or something. I know it's
possible on this platform because the unlocked bios can do it.
Could anyone point me in the direction ?
Mainboard : x220, i7-2640M(a)2.80GHz
I'm trying to check the potential compatibility of the s1200kp intel server
board.  It's mini-itx and supports ECC ram, making it attractive for use
in a NAS device. (cases with multiple hotswap bays and room for an itx
board abound, but few itx boards have ECC capability)
The chipset is listed as the C206, which is part of cougar point. The
socket is FCLGA1155 and I've seen the board with an i3-3220 (3rd gen ivy
However, I'm having a really hard time finding information on whether
coreboot supports the chipset. (never mind the superio etc)
It seems the compatibility list  on the wiki is out of date (and slated
for retirement) and the docs at  are still mostly incomplete. From
grepping through the source and the coreboot blog  there's been a port
(in coreboot 4.2) to at least one other cougar point platform.
(apple/macbookair4_2) The blog post also mentions that support for ivy
bridge and cougar point come from an FSP binary. There is also a coreboot
blog entry linking to the following article  discussing support for
these chips being merged.
This lack of accessible documentation makes it difficult to find good
porting candidates for hardware of *any* generation. Are all ivy bridge
CPUs supported? Does the FSP binary support all cougar point chipsets?