And if so, NV storage seems not required any more under schemes without
‐‐‐‐‐‐‐ 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
>> 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
>> 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.
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?
I'm trying to figure out how to build coreboot such that I can boot both
legacy and UEFI systems.
From what I can tell, most payloads will load either one or the other, but
not both (unless Grub2 can do this - unclear to me).
On the other hand, is it possible to use tianocore + SeaBIOS as the primary
and secondary payloads, respectively? Or vice versa, I guess. If so, how
would one go about setting that up?
Menuconfig doesn't let me set arbitrary secondary payloads, so I'm guessing
I'd have to stuff it in the CBFS manually somehow, yes?
The proprietary graphics drivers for AMD GPUs found at G505S (
integrated HD-8650G and optional discrete HD-8570M or R5-M230 ) - are
all deprecated, not supported by any modern (newer than Kubuntu
14.04.4) Linux distro. If you are using a modern Linux, you can't use
the proprietary drivers for these cards even if you want - so, if
these GPUs are working for you, you can be sure that they are working
thanks to the opensource graphics drivers. I think they are called
Mesa, although can be wrong.
On Tue, Aug 13, 2019 at 8:55 PM <bruts(a)netc.fr> wrote:
> Hi guys!
> Hope you having all a good summer period. I am testing some with my g505s laptops, now that I have a little time :-)
> The proprietary graphics drivers for amd on linux are in the non-free repository, firmware-amd-graphics and firmware-linux-nonfree if i'm not mistaken < obviously we not want to use the binary files.
> What are the open-source alternatives? using Mesa?
> I try to create a very minimalist build of debian or alpine linux with minimal xorg+xfce < you guys must have done this before i am sure < how did you implement the gpu drivers? anything you can share with me?
I found the typical fmap for a coreboot build using vboot (e.g. those for chromeos) is quite complex, at least with two RW sections containing CBFS, but I only want to use vboot to perform TPM measurement (like what head does with a patched coreboot), so
the simple scheme with a single CBFS containing all stages and payloads is prefered.
My question is: if vboot is only used to perform TPM measurement, at least which sections must be added to the fmap, in addition to default ones (RW_MRC_CACHE and CBFS), allowing vboot to work?
Hi there everybody! It's been a while!
I'm 'decommissioning' an Asrock E350M1/USB I used with coreboot long
time ago, but now it's been sitting idle around for years, and I want to
donate it to somebody that might use it for something more usefuk tahn
I know it's quite old, but you might do something useful with it. I
think I can throw some memory with it, and some empty 64Mbit bios chips
if I find them.
If anybody wants it, just have to pay for shipping, or walk around
Madrid and pick it :)
Sorry for the OT.
On the review of https://review.coreboot.org/c/flashrom/+/34488 you
suggested adding a check for order of entries in flashchips.c.
Sounds like a great idea, though I don't have much experience with Jenkins
and I'd like to make sure I get this right.
Did you have thoughts about how to implement it in a Jenkins-friendly way?
Two approaches I was thinking about:
(a) make a small C executable, that checks each entry is in order, and
outputs a short message about any failures, along with a pass/fail exit
(b) add that same functionality to the CLI, behind a flag.
Do you have a preference for either of these, or some other approach?
It's patch cleanup time again. This cleanup was last done almost 2
years ago, so there are a lot of old patches that haven't been touched
in a while.
Next week I'm going to abandon all of the open patches that haven't
been touched in over 18 months.
The list of roughly 250 patches to be abandoned is here:
If anyone wants to take over any of these patches, just mention it in
the patch and if the author doesn't respond in a day or two, feel free
to let them know that you've adopted the patch.
As always, if there's anything that is still useful and shouldn't be
abandoned, a comment in the patch is enough to keep it alive in