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
help.
Any ideas how to improve the RAM speeds? How I can force this RAM to run faster?
Best regards,
Mike Banon
[*] Crucial Ballistix Tactical Series DDR3 1866MHz CL9 (PC3-14900
9-9-9-24) UDIMM 240-Pin modules, part number BLT8G3D1869DT1TX0
I'd like to open discussion on a revamp of the text on the main coreboot.org Web site. I had a brief discussion on IRC recently with some basic agreement from a couple of people that the text on that page has likely bitrotted enough compared to the current status and goals of coreboot to no longer be useful.
I bring this up due to confusion in less technical circles that I've been having to correct over the past week or so. Specifically, these statements taken in isolation:
"Fast, secure and flexible OpenSource firmware"
"coreboot is an extended firmware platform that delivers a lightning fast and secure boot experience on modern computers and embedded systems. As an Open Source project it provides auditability and maximum control over technology."
present a very different picture than the reality of the project at the moment for modern platforms. If people are not aware of the ME, PSP, AGESA, FSP, BinaryPI, and a host of other proprietary components, they naturally take the statements above at face value and assume that installing coreboot on their machine (or paying for coreboot support for their system) allows them to replace the entire proprietary firmware with an auditable, fast, secure OpenSource firmware. As those of us dealing with the reality of modern x86 and ARM platforms understand more fully, this could not be farther from the truth.
One of the problems as I see it is that coreboot is really two different projects with two different goals right now, under the same label. One is the native init project, which at the moment is only viable for RISC-V, POWER, and certain ARM SoCs. The other is the open glue project for vendor binaries, which is not well understood at this time among much of the open source community, but seems to have significant support from vendors like Google, Intel, and AMD.
Complicating matters, the trademark "coreboot" is currently known to some members of the public as a trusted (albeit limited in compatibility) fully open source replacement for their exiting board level firmware. When the word "coreboot" is used, very few people think of the glue project. Do we want to dilute / shift the coreboot trademark / branding to the glue part of the project, or do we want to somehow reserve "coreboot" for the native init part of the project? I don't have an answer here, I'm just trying to state the facts as I currently see them for further discussion.
I would propose the following changes, and welcome discussion on these topics:
The heading could read something like "Flexible, open source frameworks for system firmware"
and the detailed description could read "coreboot is an extensible firmware platform that aims to provide a minimal boot environment for modern computers and embedded systems. As an Open Source project it provides a flexible framework for insertion of vendor specific firmware modules, and on open ISA platforms aims to provide a fully open, auditable boot process with maximum control over the technology."
Thoughts?
--
Timothy Pearson
Raptor Engineering, LLC
https://www.raptorengineering.com
Open letter to coreboot leadership
I have spent some time helping out sort some fundamentals on the tree
to bring up that new amd/picasso platforms. During the reviews I found
some proceedings there somewhat alarming, so I am hoping for coreboot
leadership and trademark holder to make some clear statements on the
topic.
Now, I may know a bit more than I can write here in public, I try
defer from disclosing information received in private emails and stick
with the information that can be found in gerrit review commits. In
short; appers it has been decided verstage will run on PSP instead of
x86 cores.
So which of the following approaches do You find acceptable:
a) Platform shall use proprietary ARM TrustZone instead of vboot for
any cryptographics and measurements of firmware. This may be the AMD
endorsed way of doing things.
b) Platform shall use vboot, built and signed internally at AMD, for
the Security Processor (aka PSP), using their choice of proprietary
tools. While GPL compliance may say build scripts are to be published
in such case (IANAL!!), that does not mean the used compiler is
available for purchase on open market.
c) Platform shall use vboot, built using an extended __and published__
coreboot toolchain. Built PSP vboot binary shall be reproducible and
signed with OEM key. Community developers will not be able to run
custom verstage builds, but are able to audit integrity of the source.
d) Platform shall use vboot, built using an extended __and published__
coreboot toolchain. Built PSP vboot binary should be reproducible.
Community developers are able to run custom verstage builds, but state
of PSP/TPM/etc may reveal to the OS that sections of the firmware does
not originate from the OEM, as detected by the lack of signage or use
of insecure key published for experimental use only. User experience
or DRM might suffer.
e) Platform shall use vboot, built using an extended __and published__
coreboot toolchain. Developers can run whatever they want on PSP,
without OS ever noticing it.
f) Something else in between the presented choices or outside of them?
Regards,
Kyösti Mälkki
Greetings,
From what I can find, Linux can only chainload another linux kernel. (via
kexec) Does this mean that a Linux payload like LinuxBoot cannot be used to
boot Windows or another OS, either directly or by chainloading another
payload from CBFS?
It's nice that a Linux payload can provide superior flexibility and
configurability than UEFI with the added benefit of a battle-hardened
environment, but the ability to only boot a Linux OS seems like a pretty
significant limitation (if this is indeed the case).
Sincerely,
-Matt
Hi,
I'm running a Tianocore payload on coreboot and I'm not able to boot
Windows (or Windows installers). I eventually get errors like
"UNMOUNTABLE_BOOT_VOLUME" and "DRIVER_PNP_WATCHDOG".
Some searching leads me to the conclusion that in some cases putting one's
SATA controller in IDE mode allows these devices to boot.
Is there a KConfig option that enables this?
Thanks,
Rafael
Hi
The decisions are out on 4.11 release requirements. Unless anyone acts
on it, amdfam10-15 boards will hit deprecation due to:
* RELOCATABLE_RAMSTAGE=n
* CAR_GLOBAL_MIGRATION=y
* C_ENVIRONMENT_BOOTBLOCK=n
To smooth down the path, should anyone want to attempt on fixing
these, I have pushed a patchset [1] that removes S3 suspend support
from said platform. Depending of what the response is, I hope to have
that submitted already before 4.11 release.
The latest info [2] I have is asus/kcma-d8 not working and
asus/kgpe-d16 working in 4.6 but very slowly, for S3 resume boot, that
is. No resume logs have been brought to my knowledge for 12 months. I
also had some suspicions that tests results were mistakenly from
suspend-to-disk (S4).
Affected boards are asus/kcma-d8 and asus/kgpe-d16.
[1] https://review.coreboot.org/c/coreboot/+/15474
[2] https://mail.coreboot.org/pipermail/coreboot/2018-June/086906.html
Kind regards,
Kyösti
Hi folks,
Currently there are only 2 boards using Cavium's ThunderX (CN81xx) and
both aren't available on the free market.
Cavium haven't upstreamed their Arm Trusted Firmware, so it's a bit of
maintenance work to keep it alive.
If nobody wants to take care of if, it will marked deprecated with he
next release (4.11) and removed before the 4.12 release.
Regards,
Patrick Rudolph
9elements GmbH, Kortumstraße 19-21, 44787 Bochum, Germany
Email: patrick.rudolph(a)9elements.com
Phone: +49 234 / 68 94 188
Sitz der Gesellschaft: Bochum
Handelsregister: Amtsgericht Bochum, HRB 13207
Geschäftsführung: Eray Basar, Sebastian Deutsch
Hi folks,
for improved runtime ACPI generation I would like to introduce a new member in
struct device_operations.
It would return the ACPI HID for the given device similar to the ACPI
NAME that's already implemented:
const char *(*acpi_name)(const struct device *dev);
It would look like this:
const char *(*acpi_hid)(const struct device *dev);
How about that?
Regards,
Patrick Rudolph
9elements GmbH, Kortumstraße 19-21, 44787 Bochum, Germany
Email: patrick.rudolph(a)9elements.com
Phone: +49 234 / 68 94 188
Sitz der Gesellschaft: Bochum
Handelsregister: Amtsgericht Bochum, HRB 13207
Geschäftsführung: Eray Basar, Sebastian Deutsch
And if so, NV storage seems not required any more under schemes without
RW slot.
Best regards,
Persmule
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Monday, August 19, 2019 7:57 AM, Persmule <persmule(a)hardenedlinux.org> wrote:
> Thanks. Though I would rather push a change ( https://review.coreboot.org/c/coreboot/+/34977 ) to make vboot step into "recovery mode" directly when no RW slots is present, since I believe letting vboot "verify" a non-existing RW slot is mostly pointless.
>
> Is it convenient for me to bother you to review my change mentioned above?
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Sunday, August 18, 2019 4:43 PM, Michal Zygowski <michal.zygowski(a)3mdeb.com> wrote:
>
>> Yes, vboot requires NV storage to keep its context across boots, it is typically done in CMOS or SPI or EC memory. One of these 3 options must be selected.
>>
>> For example, in your mainboard Kconfig you should have something like this:
>>
>> config VBOOT
>> bool
>> default y
>> select VBOOT_VBNV_CMOS
>> select VBOOT_NO_BOARD_SUPPORT
>> select GBB_FLAG_DISABLE_LID_SHUTDOWN
>> select GBB_FLAG_DISABLE_PD_SOFTWARE_SYNC
>> select GBB_FLAG_DISABLE_EC_SOFTWARE_SYNC
>> select GBB_FLAG_DISABLE_FWMP
>> select RTC
>>
>> config VBOOT_VBNV_OFFSET
>> hex
>> default 0x2D8 if VBOOT
>>
>> The options you have to select highly depend on the hardware you are trying to run vboot on. For example vboot can start in bootblock or in romstage (depends on C_ENVIRONMENT_BOOTBLOCK support for the microarchitecture). The example shows sample configuration for CMOS stored vboot flags, however following options for vboot storage are also available (and have their own dependencies as well):
>> - VBOOT_VBNV_EC
>> - VBOOT_VBNV_FLASH
>>
>> I advise to look at src/security/vboot/Kconfig, help sections for the options might be helpful for you.
Hi,
I've just been bitten by build problems with outdated MIPS code for
one of my CLs (not for the first time), and I've been wondering if
it's maybe time that we drop the architecture port completely. It was
added 5 years ago to support a Chrome OS project that never ended up
going anywhere and has been sitting in the tree unused and unsupported
ever since. The only SoC/board building it is that old abandoned
Chrome OS project for which there's probably not even any hardware
around anymore (or if there is, nobody wants to spend time with it).
There's no maintainer or even anybody who really reads MIPS assembly
or understands the architecture's intricacies paying attention to it,
and it keeps causing trouble when we try to pull it along with
overarching refactorings. I think at some point, if nobody wants to
use it and there's no future use case on the horizon, we should
consider pulling the plug.
Some examples of stuff that causes problems:
1. There's no 64-bit division support (even soft-division) because we
have no code to implement the required libgcc function, and nobody
knows enough MIPS assembly to fix that. We need to keep several hacks
around in generic code (e.g. printf()) where code doesn't use 64-bit
division even though it probably should or has a special #if
CONFIG(ARCH_MIPS) case to deal with this.
2. The read/write8/16/32() functions in libpayload take arguments in
(value, addr) order, whereas for all other architectures they have
long since been standardized to take (addr, value). This means you
can't submit any generic code that does direct MMIO without wrapping
it in #if !CONFIG(ARCH_MIPS). There are a bunch of depthcharge drivers
left still using that old convention... I don't have time/interest
refactoring all of those and I don't think anybody else does either.
We could either drop it right away, or (if we think that's too sudden)
schedule it for deletion after the next coreboot release (4.11 in
December(?)). What do people think?
