Dear coreboot folks,
following Patrick to test devices with the Firmware Test Suite , I
built fwts V15.08.00-7-g9ddce1f from the their Git repository  and
ran it on the ASRock E350M1 with coreboot  and SeaBIOS.
The first tests failing are the MTRR tests.
mtrr: MTRR tests.
Reg 0: 0x0000000000000000 - 0x0000000080000000 ( 2048 MB) Write-Back
Reg 1: 0x0000000080000000 - 0x00000000c0000000 ( 1024 MB) Write-Back
Reg 2: 0x00000000c0000000 - 0x00000000c8000000 ( 128 MB) Write-Back
Reg 6: 0x00000000ffc00000 - 0x0000000100000000 ( 4 MB) Write-Protect
Test 1 of 3: Validate the kernel MTRR IOMEM setup.
FAILED [MEDIUM] MTRRIncorrectAttr: Test 1, Memory range 0x100000000 to
0x21effffff (System RAM) has incorrect attribute Default (Most probably
FAILED [MEDIUM] MTRRLackingAttr: Test 1, Memory range 0x100000000 to 0x21effffff
(System RAM) is lacking attribute Write-Back.
Test 2 of 3: Validate the MTRR setup across all processors.
PASSED: Test 2, All processors have the a consistent MTRR setup.
Test 3 of 3: Test for AMD MtrrFixDramModEn being cleared by the BIOS.
PASSED: Test 3, No MtrrFixDramModEn error detected.
2 passed, 2 failed, 0 warning, 0 aborted, 0 skipped, 0 info only.
I’ll try to look into it in the coming weeks, but if somebody has an
idea and a suggestion for a fix, that would be great. Please also
comment, if fwts is not correct in this regard.)
 commit 6de27da3 (samsung/exynos5250: Enable bootblock console)
this week the Gerrit review score -2 was discussed again in
Several times, during the last two years, a review score of -2 was
given and dealing with it caused a lot of discussion and friction.
This thread is not about the usefulness of -2. Currently it is the way
it is set up and certain Gerrit users, those that can also submit
change sets, have the right to assign a -2. This prohibits submitting
the change set. The score of -2 has to be removed, and I think every
Gerrit user with submit rights can do that, so that the change set can
In contrast to a review score of -1, which is removed after every new
upload of a patch set, -2 is sticky.
To formalize that a little bit, I propose the following addition to the
1. A review score of -2 has to be assigned with a comment explaining,
why the change set is blocked. If such a comment is not published
within 24 hours after assigning -2, the -2 can be removed.
2. After answering to the comment, blocking the change set, a (useful)
respond has to be published within *four* weeks. If there is no
response, the change set can be submitted, if there are at least twice
as many scores of +2 than -2.
3. If the review discussion lasts longer than two months, the topic
should be brought up on the coreboot mailing list and, if there is no
consensus, a vote should be announced, where within a week people can
vote. There is no minimum participation number. The simple majority
wins. If the votes equal, then the change set is rejected and won’t be
Just a reminder, this is now active. If your commits to gerrit fail in the
builder, check if you need to rebase them to current master.
2015-07-31 20:07 GMT+02:00 Patrick Georgi <pgeorgi(a)google.com>:
> Hi all,
> I just changed the "coreboot" builder on http://qa.coreboot.org/ to use
> the just fixed "what-jenkins-does" build target (defined in
> $(top)/Makefile.inc), so all future builds will use that instead of the
> hard coded sequence of commands that used to be defined in our build
> I plan to move the "coreboot-gerrit" builder over in about a week. This
> means that from that point on, contributions on gerrit that predate the
> inclusion of http://review.coreboot.org/#/c/11097/ will break.
> Therefore if you have long-running development branches, please remember
> to rebase them to a current upstream or you'll get a build error after
> pushing them.
> Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
> Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
> Geschäftsführer: Graham Law, Christine Elizabeth Flores
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Geschäftsführer: Graham Law, Christine Elizabeth Flores
I've set up libreboot (and GuixSD) on a X200. I'm writing this from the
newly set up machine, so a lot worked already. Great!
However, now I want to switch Ctrl and Fn to have Ctrl to the left and
unfortunately the libreboot rom from the release on the libreboot
website used CONFIG_STATIC_OPTION_TABLE=y , which means I can't persist
the setting across reboots.
In order to find that out I had to somehow get the config options and
so after reading the docs I came across
$ grep CONFIG_ x200_8mb/x200_8mb_ukqwerty_vesafb.rom
Binary file x200_8mb/x200_8mb_ukqwerty_vesafb.rom matches
which didn't work. But
$ grep -a CONFIG_ x200_8mb/x200_8mb_ukqwerty_vesafb.rom |grep OPTION_
However, idwer mentioned a tool called "cbfstool" in coreboot which is
supposed to be the normal way to do that.
So I checked out coreboot from git, went into coreboot/util/cbfstool
command not found
Which is a GuixSD problem I guess. But after some prodding
$ make HOSTCC=gcc
lex -t --header-file=fmd_scanner.h fmd_scanner.l >fmd_scanner.c
command not found make: *** No rule to make target 'fmd_scanner.c',
needed by '.dependencies'. Stop.
$ ls -l fmd_scanner.c
-rw-r--r-- 1 dannym users 0 Aug 7 23:35 fmd_scanner.c
$ make HOSTCC=gcc
(endless loop that uses very little CPU commences)
$ make clean
doesn't get rid of fmd_scanner.c (which *does* exist) so it's difficult
to find the cause.
With kind regards,
I have some (yes, some) Acer C720 Chromebooks which are "rooted" to
enter SeaBIOS to boot any OS from USB or SSD. This works fine, in
I have one particular USB key, which says on attach to a FreeBSD system about itself:
Aug 5 20:55:13 c720-r276659 kernel: da0: <JetFlash Transcend 8GB 8.07> Removable Direct Access SCSI-4 device
Aug 5 20:55:13 c720-r276659 kernel: da0: Serial Number KWUQE9E8
Aug 5 20:55:13 c720-r276659 kernel: da0: 40.000MB/s transfers
Aug 5 20:55:13 c720-r276659 kernel: da0: 7487MB (15335422 512 byte sectors: 255H 63S/T 954C)
Aug 5 20:55:13 c720-r276659 kernel: da0: quirks=0x12<NO_6_BYTE,NO_RC16>
Aug 5 20:55:13 c720-r276659 kernel: GEOM: da0: the secondary GPT header is not in the last LBA.
Aug 5 20:55:13 c720-r276659 kernel: GEOM: diskid/DISK-KWUQE9E8: the secondary GPT header is not in the last LBA.
This one (and only this one in all my C720) on power-on is not reliable detected
as boot device. A press on ESC only offers the internal SSD to boot from. If
it is detected (in 1 of 10 power cycles), it boots fine.
What can I do, apart of trashing the USB key?
Matthias Apitz, ✉ guru(a)unixarea.de, http://www.unixarea.de/ ☎ +49-176-38902045
No! Nein! ¡No! Όχι! -- Ευχαριστούμε!
On 07/29/2015 01:54 PM, Patrick Georgi wrote:
> One server board that is for sale and can be equipped with coreboot would be the ASUS KGPE-D16.
I looked at that - those are 5 years old now.. I would worry about the age of the capacitors.
I'm no longer seeing any MB - desktop or server that are from the last 2 years? And no one selling
Also - I did some work with some UEFI BIOSs - I think there is an small OS running on top of
everything? (not something the lends itself to creating secure systems... ). Thus my quest for a
I had looked a few years ago and had the sense that there were rather current options - it appears
that the climate has changed? Or am I missing part of the bigger picture?
Link to our website and get free US-48 shipping on your next order.
Karl Schmidt EMail Karl(a)xtronics.com
Transtronics, Inc. WEB https://secure.transtronics.com
3209 West 9th Street Ph (785) 841-3089
Lawrence, KS 66049 FAX (785) 841-3089
The lack of a middle class is a good indicator of how corrupt a government is.