On Thu, Feb 4, 2016 at 2:29 AM Patrick Georgi via coreboot <
coreboot(a)coreboot.org> wrote:
>
>
> 1. TRUE/FALSE
> Do we want such defines? If so, TRUE/FALSE, or true/false, or
> True/False, or ...?
>
should we start using bool ...?
>
> 2. BIT16 vs BIT(16) vs (1 << 16) vs 0x10000
> I don't think it makes sense to go for a single one of these (0x3ff is
> certainly more readable than BIT11 | BIT10 | BIT9 | BIT8 | BIT7 | BIT8
> | BIT5 | BIT4 | BIT3 | BIT2 | BIT1 | BIT 0), but I doubt we need both
> BIT16 and BIT(16).
>
>
BIT16 is a constant. BIT(16) is a chance for things to go badly wrong, e.g.
BIT(x-y) might produce some very strange problems. I kind of prefer the
constant.
ron
Hi all,
during the review of some commits that are in the process of being
upstreamed from Chrome OS, people noticed that chipset drivers like to
define their own TRUE/FALSE defines (sometimes prefixed to), and I
have seen a bunch of #define BIT{0-31} ..., too, because that seems to
be the house rules in some firmware communities.
I think we should seek uniformity here: decide on some style,
recommend it, clean up the tree to match, and help people stay
consistent through lint tests. What I don't know however is what that
style should look like.
So, two topics:
1. TRUE/FALSE
Do we want such defines? If so, TRUE/FALSE, or true/false, or
True/False, or ...?
2. BIT16 vs BIT(16) vs (1 << 16) vs 0x10000
I don't think it makes sense to go for a single one of these (0x3ff is
certainly more readable than BIT11 | BIT10 | BIT9 | BIT8 | BIT7 | BIT8
| BIT5 | BIT4 | BIT3 | BIT2 | BIT1 | BIT 0), but I doubt we need both
BIT16 and BIT(16).
Patrick
--
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle
Dear Sir.
Thank's your advise.
This time, I'm downloaded the intel FSP from
http://www.intel.com/content/www/us/en/intelligent-systems/intel-firmware-s…
FSP file name is "333407_RANGELEY_POSTGOLD_4_001US.tgz".
and unpack this file, can see some files. see below
poplinux@raw RANGELEY_POSTGOLD_4 $ > find
.
./FSP
./FSP/RangeleyFsp.bsf
*./FSP/RANGELEY_POSTGOLD4_FSP_004_20150924.fd*
./FSP/include
./FSP/include/fspffs.h
./FSP/include/fspinfoheader.h
./FSP/include/fspguid.h
./FSP/include/fsptypes.h
./FSP/include/fspplatform.h
./FSP/include/fspfv.h
./FSP/include/fspvpd.h
./FSP/include/fspapi.h
./FSP/include/fspbootmode.h
./FSP/include/fspsupport.h
./FSP/include/fsphob.h
./FSP/srx
./FSP/srx/fsphob.c
./FSP/srx/fsp_support.c
./FSP Kit Production RULAC click-through License.pdf
./ReadMe.pdf
./DOCUMENTATION
./DOCUMENTATION/ReleaseNotes.pdf
./DOCUMENTATION/C2000_FSP_Integration_Guide_Rev1_2.pdf
./DOCUMENTATION/license.txt
./Microcode
./Microcode/microcode-m01406d000e.h
./Microcode/microcode-m01406d8128.h
The "ReadME.pdf" is said to me that
"*./FSP/RANGELEY_POSTGOLD4_FSP_004_20150924.fd*" is a FSP release binary
file.
Next,
I'm enable the "*[ ] Configure defaults for the Intel FSP package* "
option.
Mainboard
Mainboard vendor (Intel) --->
Mainboard model (Mohon Peak CRB) --->
*[ ] Configure defaults for the Intel FSP package*
ROM chip size (2048 KB (2 MB)) --->
(0x00200000) Size of CBFS filesystem in ROM
() fmap description file in fmd format
And try to make for core boot. But occured the error.
poplinux@raw build $ > make
GEN generated/bootblock.ld
CP bootblock/arch/x86/bootblock.ld
LINK cbfs/fallback/bootblock.debug
OBJCOPY cbfs/fallback/bootblock.elf
OBJCOPY bootblock.raw.bin
make: *** No rule to make target `../intel/fsp/rangeley/FvFsp.bin',
needed by `build/coreboot.pre'. Stop.
Question.
Is equal the *./FSP/RANGELEY_POSTGOLD4_FSP_004_20150924.fd
*and*FvFsp.bin ?? *
or How to get the *FvFsp.bin ??*
Thank you.
2016-02-02 오후 9:24에 WANG FEI 이(가) 쓴 글:
> Mohon Peak coreboot can only power on your system with a Rangeley SoC
> FSP included in your coreboot.
>
> Please download the Rangeley FSP binary from
> http://www.intel.com/content/www/us/en/intelligent-systems/intel-firmware-s…,
>
> *Intel® Atom™ processor C2000 product family* (formerly Rangeley,
> Compliant with FSP v1.0 Specification)
>
> * Windows* release version 004 >
> <http://www.intel.com/content/www/us/en/embedded/software/fsp/atom-c2000-fsp…>
> * Linux* release version 004 >
> <http://www.intel.com/content/www/us/en/embedded/software/fsp/atom-c2000-fsp…>
> * Release notes >
> <http://www.intel.com/content/www/us/en/embedded/software/fsp/atom-c2000-fsp…>
> * Platform guide >
> <http://www.intel.com/content/www/us/en/embedded/software/fsp/atom-c2000-crb…>
> * Integration guide >
> <http://www.intel.com/content/www/us/en/embedded/software/fsp/atom-c2000-fsp…>
>
> And following the steps described on FSP integration guide to include
> FSP into coreboot, for example, when you run "make menuconfig", you
> should select "configure defaults for the Intel FSP package", you
> possible need to configure more, please follow the instruction of FSP
> integration guide.
>
> * Mainboa**rd*
> Mainboard vendor (*Intel*) --->
> Mainboard model (*Mohon Peak CRB*) --->
> [ ] Configure defaults for the Intel FSP package
> ROM chip size (2048 KB (2 MB)) --->
> (0x00200000) Size of CBFS filesystem in ROM
> () fmap description file in fmd format
>
>
> On Tue, Feb 2, 2016 at 7:40 AM, 김유석 <poplinux0(a)gmail.com
> <mailto:poplinux0@gmail.com>> wrote:
>
> Dear sir.
>
> My ENV is see below.
>
> *EVB : Intel rangeley Mohon Peak CRB*
>
>
> This time, I was download the coreboot from git.
>
> poplinux@raw work $ > git clone
> http://review.coreboot.org/coreboot.git ./
> poplinux@raw work $ > cd coreboot
> poplinux@raw coreboot $ > git submodule update --init --checkout
>
> Next, *run make menuconfig* and set-up to mohon peak CRB and save
> & exit
>
> *Mainboa**rd*
> Mainboard vendor (*Intel*) --->
> Mainboard model (*Mohon Peak CRB*) --->
> [ ] Configure defaults for the Intel FSP package
> ROM chip size (2048 KB (2 MB)) --->
> (0x00200000) Size of CBFS filesystem in ROM
> () fmap description file in fmd format
>
> Next, I'm try to build core boot.
>
> poplinux@raw coreboot $ > make
> GEN generated/bootblock.ld
> CP bootblock/arch/x86/bootblock.ld
> LINK cbfs/fallback/bootblock.debug
> OBJCOPY cbfs/fallback/bootblock.elf
> OBJCOPY bootblock.raw.bin
> Checking out SeaBIOS revision
> 01a84bea2d28a19d2405c1ecac4bdef17683cc0c
> Switched to branch 'master'
>
> Performing operation on 'COREBOOT' region...
> Name Offset Type Size
> cbfs master header 0x0 cbfs header 32
> fallback/romstage 0x80 stage 22684
> cpu_microcode_blob.bin 0x5980 microcode 0
> config 0x5a00 raw 127
> revision 0x5ac0 raw 570
> cmos_layout.bin 0x5d40 cmos_layout 1316
> fallback/dsdt.aml 0x62c0 raw 7952
> payload_config 0x8240 raw 1574
> payload_revision 0x88c0 raw 237
> (empty) 0x8a00 null 29848
> mrc.cache 0xfec0 mrc_cache 65536
> fallback/ramstage 0x1ff00 stage 46922
> fallback/payload 0x2b6c0 payload 61122
> (empty) 0x3a5c0 null 1856216
> bootblock 0x1ff8c0 bootblock 1528
>
> Finally, I'm got a coreboot image.
>
>
> poplinux@raw build $ > ls build/coreboot.rom
> build/coreboot.rom
> poplinux@raw build $ > ./build/cbfstool build/coreboot.rom print
> Performing operation on 'COREBOOT' region...
> Name Offset Type Size
> cbfs master header 0x0 cbfs header 32
> fallback/romstage 0x80 stage 22684
> cpu_microcode_blob.bin 0x5980 microcode 0
> config 0x5a00 raw 127
> revision 0x5ac0 raw 570
> cmos_layout.bin 0x5d40 cmos_layout 1316
> fallback/dsdt.aml 0x62c0 raw 7952
> payload_config 0x8240 raw 1574
> payload_revision 0x88c0 raw 237
> (empty) 0x8a00 null 29848
> mrc.cache 0xfec0 mrc_cache 65536
> fallback/ramstage 0x1ff00 stage 46922
> fallback/payload 0x2b6c0 payload 61122
> (empty) 0x3a5c0 null 1856216
> bootblock 0x1ff8c0 bootblock 1528
>
>
> And I'm write image to my EVB using *ALL-100 Gang-writ**er*.
> spi flash's write *start address is set 0x00000000*. write it success.
>
> And I'm attach the flash memory to my EVB.
>
> And power-up the my EVB. But can't see any message on my monitor
> and serial port both.
>
>
> *Why did not display any message? **
> **A**nd could you support correct configuration file for my EVB?*
>
> Thank you.
>
>
>
>
>
>
>
> --
> coreboot mailing list: coreboot(a)coreboot.org
> <mailto:coreboot@coreboot.org>
> http://www.coreboot.org/mailman/listinfo/coreboot
>
>
by Raptor Engineering Automated Coreboot Test Stand
The ASUS KGPE-D16 fails verification as of commit e3f47eada383defcc31b41cc4931c3cf3234c37d
The following tests failed:
BOOT_FAILURE
Commits since last successful test:
e3f47ea vendorcode/amd/agesa/f1{4,2,0} Sync Include directory
c389635 vendorcode/amd/agesa/f15?tn: Strip false/redudant AMD ver tag
11a262c util/kconfig:xconf(QT): Update QT version of xconf
420caaf include/device: Move inline functions from pci_def.h to pci.h
See attached log for details
This message was automatically generated from Raptor Engineering's ASUS KGPE-D16 test stand
Want to test on your own equipment? Check out https://www.raptorengineeringinc.com/content/REACTS/intro.html
Raptor Engineering also offers coreboot consulting services! Please visit https://www.raptorengineeringinc.com for more information
Please contact Timothy Pearson at Raptor Engineering <tpearson(a)raptorengineeringinc.com> regarding any issues stemming from this notification
Dear sir.
My ENV is see below.
*EVB : Intel rangeley Mohon Peak CRB*
This time, I was download the coreboot from git.
poplinux@raw work $ > git clone http://review.coreboot.org/coreboot.git ./
poplinux@raw work $ > cd coreboot
poplinux@raw coreboot $ > git submodule update --init --checkout
Next, *run make menuconfig* and set-up to mohon peak CRB and save & exit
*Mainboa**rd*
Mainboard vendor (*Intel*) --->
Mainboard model (*Mohon Peak CRB*) --->
[ ] Configure defaults for the Intel FSP package
ROM chip size (2048 KB (2 MB)) --->
(0x00200000) Size of CBFS filesystem in ROM
() fmap description file in fmd format
Next, I'm try to build core boot.
poplinux@raw coreboot $ > make
GEN generated/bootblock.ld
CP bootblock/arch/x86/bootblock.ld
LINK cbfs/fallback/bootblock.debug
OBJCOPY cbfs/fallback/bootblock.elf
OBJCOPY bootblock.raw.bin
Checking out SeaBIOS revision 01a84bea2d28a19d2405c1ecac4bdef17683cc0c
Switched to branch 'master'
Performing operation on 'COREBOOT' region...
Name Offset Type Size
cbfs master header 0x0 cbfs header 32
fallback/romstage 0x80 stage 22684
cpu_microcode_blob.bin 0x5980 microcode 0
config 0x5a00 raw 127
revision 0x5ac0 raw 570
cmos_layout.bin 0x5d40 cmos_layout 1316
fallback/dsdt.aml 0x62c0 raw 7952
payload_config 0x8240 raw 1574
payload_revision 0x88c0 raw 237
(empty) 0x8a00 null 29848
mrc.cache 0xfec0 mrc_cache 65536
fallback/ramstage 0x1ff00 stage 46922
fallback/payload 0x2b6c0 payload 61122
(empty) 0x3a5c0 null 1856216
bootblock 0x1ff8c0 bootblock 1528
Finally, I'm got a coreboot image.
poplinux@raw build $ > ls build/coreboot.rom
build/coreboot.rom
poplinux@raw build $ > ./build/cbfstool build/coreboot.rom print
Performing operation on 'COREBOOT' region...
Name Offset Type Size
cbfs master header 0x0 cbfs header 32
fallback/romstage 0x80 stage 22684
cpu_microcode_blob.bin 0x5980 microcode 0
config 0x5a00 raw 127
revision 0x5ac0 raw 570
cmos_layout.bin 0x5d40 cmos_layout 1316
fallback/dsdt.aml 0x62c0 raw 7952
payload_config 0x8240 raw 1574
payload_revision 0x88c0 raw 237
(empty) 0x8a00 null 29848
mrc.cache 0xfec0 mrc_cache 65536
fallback/ramstage 0x1ff00 stage 46922
fallback/payload 0x2b6c0 payload 61122
(empty) 0x3a5c0 null 1856216
bootblock 0x1ff8c0 bootblock 1528
And I'm write image to my EVB using *ALL-100 Gang-writ**er*.
spi flash's write *start address is set 0x00000000*. write it success.
And I'm attach the flash memory to my EVB.
And power-up the my EVB. But can't see any message on my monitor and
serial port both.
*Why did not display any message? **
**A**nd could you support correct configuration file for my EVB?*
Thank you.
I meant to send this to the mailing list on Saturday, but ended up just
sending it to Paul by accident.
Paul,
This thread quickly followed one point that you commented on, but
has so far not touched much on one of your other issues. This is the
issue of leadership of the coreboot community. You might want to look
at Stefan's blog post "on coreboot leadership" from May of last year -
http://blogs.coreboot.org/blog/2015/05/11/on-coreboot-leadership/
The way that I read it is that anyone is welcome to contribute ideas
and opinions. Stefan may poll people for their opinions at times as
well. What I don't read in that blog post is anything about the
coreboot project being a democracy. I think that Stefan makes it
pretty clear that the coreboot project has a leader, even though he
believes in a hands-off approach.
If people think that there are things that need to be discussed, I've
found that Stefan, Ron and the rest are very welcoming of reasonable
and constructive discussion.
Regarding announcements of changes to policy, maybe something could be
set up so that changes to certain wiki pages would automatically be
posted to the mailing list.
Please note that these are just my own personal thoughts on these
subjects, and are in no way trying to state any official coreboot
policy.
Martin
On Mon, Feb 1, 2016 at 11:30 AM, Alex Gagniuc <mr.nuke.me(a)gmail.com> wrote:
> On Sun, Jan 31, 2016 at 2:24 PM, Stefan Reinauer
> <stefan.reinauer(a)coreboot.org> wrote:
>>
>> That is a really surprising statement coming from you, Alex, as you and I
>> have discussed this very topic in person several times
>
> And as I have said in those very same discussions, decisions about
> coreboot shold be done publicly. You're also portraying a distorted
> picture of what was actually discussed, but it was still a private
> conversation and has no bearing towards what Paul pointed out.
>
> Going back to Paul's proposal, he noted that an official project
> guideline had been modified with neither public mail discussion, nor
> community oversight. This was not a "minor typo fix" or
> "clarification". I count three different changes which were made this
> way. And I think Paul nailed it with his proposal.
>
> I fully support Paul's proposal.
>
> On Sat, Jan 30, 2016 at 6:54 PM, Martin Roth <gaumless(a)gmail.com> wrote:
>> There was significant discussion in several
>> meetings about the reasons for and against standardizing on AT&T
>> syntax.
>
> As I've explained above, private conversations are not the proper
> forum to make decisions related to coreboot. I realize you and others
> involved are wearing two hats, and sometimes it's hard to tell which
> hat you're wearing, either for you, or observers. Please consider the
> image portrayed on your employer, when a group of its employees
> unilaterally discusses, changes, then enforces rules in a public
> project. I think Paul's proposal fixes this issue.
>
>> If you have a reason for using Intel syntax that is really more
>> persuasive than keeping the asm code in the project consistent, feel
>> free to state it.
>
> While I have a lot to say of the matter, this is not the appropriate
> place. This discussion is about a change to a policy, not a
> development guideline. Let's focus on what Paul is saying here.
>
> Alex
On 01/30/2016 11:30 AM, ron minnich wrote:
> The change to the guidelines is hence a codification of a practice that
> goes back to the project's beginnings.
I find that statement inaccurate. This practice had not been an issue in
the past, on patches that you yourself approved. Mixed syntaxes have
been present in the codebase for a while. See EXHIBIT A.
EXHIBIT B shows a patch, mid last year, when a new intel_syntax code was
introduced. There was only one comment (following) about the syntax. The
patch was approved by you, Ron, without mentioning what you claim has
been a practice.
> Patrick Georgi, Jul 13, 2015
> follow up patch: we don't really want two _syntaxes in one file_, right?
(emphasis added)
The comment clearly addresses the issue of mixing two syntaxes within a
file. It does not mention "a practice that goes back to the project's
beginnings", nor does it mention that either "AT&T syntax is to be used
through-out the project", or "No new Intel syntax code is allowed into
the project."
EXHIBIT C, shows another such patch that, you, have also approved, Ron.
The comment got no replies.
> Ronald G. Minnich, Oct 30 10:43 AM
> why intel syntax _in a file that is att syntax_? it's a real
oportunity for a buggy time.+2'ing because you promised me you're
rewrite it.
(emphasis added)
Notice how the issue here is strictly the mixing of syntaxes within the
same file.
EXHIBIT D shows another such patch, this time approved by me. I have
made a comment about the issue of mixed syntax.
> Alexandru Gagniuc, Jul 17, 2015
> Really? Mixed syntax in the same file?
This also addresses strictly the issue of mixing of syntaxes within the
same file.
EXHIBIT E shows another patch, that you yourself approved. This time,
there was not even a mention of mixed syntaxes.
I conclude from these, that your assertion that this has been an
unspoken rule, is not true. Furthermore, I believe that this arbitrary
change was done as an act of spite towards a set of engineers. Also,
since you, and the rest of the coreboot leadership have shown a pattern
of first discussing changes to the project publicly, on the mailing
list, I conclude that a discussion about this issue was deliberately
avoided in order to prevent those engineers, as well as other coreboot
community members, from presenting their arguments.
Alex
### EXHIBIT A: Presence of .intel_syntax ###
* 4a30ab9 cpu/amd: remove .intel_syntax
* 0302b06 arch/x86: remove .intel_syntax
* c7b2b7c cbfstool: Fix potential error when using hash attribute
$ git reset --hard c7b2b7c67dc8afb52c3dc8e9297e5ed81fa22674
$ git grep intel_syntax
src/arch/x86/boot.c: ".intel_syntax noprefix\n\t"
src/arch/x86/c_start.S:.intel_syntax noprefix
src/arch/x86/wakeup.S: .intel_syntax noprefix
src/cpu/amd/agesa/cache_as_ram.inc: .intel_syntax noprefix
src/cpu/amd/pi/cache_as_ram.inc: .intel_syntax noprefix
### EXHIBIT B: src/arch/x86/[boot.c, c_start.S] ###
$ git blame src/arch/x86/boot.c |grep intel_syntax
9693885a src/arch/x86/boot/boot.c (Stefan Reinauer 2015-06-18 01:23:48
-0700 63) ".intel_syntax noprefix\n\t"
$ git blame src/arch/x86/c_start.S |grep intel_syntax
9693885a src/arch/x86/lib/c_start.S (Stefan Reinauer
2015-06-18 01:23:48 -0700 403) .intel_syntax noprefix
$ git show 9693885a
commit 9693885ad88d21ead7bd9ebc32f3e4901841b18b
Author: Stefan Reinauer <stefan.reinauer(a)coreboot.org>
Date: Thu Jun 18 01:23:48 2015 -0700
x86: Port x86 over to compile cleanly with x86-64
Change-Id: I26f1bbf027435be593f11bce4780111dcaf7cb86
Signed-off-by: Stefan Reinauer <stefan.reinauer(a)coreboot.org>
Signed-off-by: Scott Duplichan <scott(a)notabs.org>
Reviewed-on: http://review.coreboot.org/10586
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand
<noreply(a)raptorengineeringinc.com>
Reviewed-by: Ronald G. Minnich <rminnich(a)gmail.com>
### EXHIBIT C: src/arch/x86/wakeup.S ###
$ git blame src/arch/x86/wakeup.S |grep intel_syntax
ac901e6b src/arch/x86/wakeup.S (Stefan Reinauer 2015-07-31
16:46:28 -0700 32) .intel_syntax noprefix
$ git show ac901e6b
commit ac901e6bedc98d115ebb8089afd8f67aef39c000
Author: Stefan Reinauer <reinauer(a)chromium.org>
Date: Fri Jul 31 16:46:28 2015 -0700
wakeup: Switch back to 32bit mode first
On x86_64 we need to leave long mode before we can switch to 16bit
mode. Oh joy! When's my 64bit resume pointer coming?
Why didn't this get caught earlier? Seems the Asrock E350M2 didn't
do Suspend/Resume?
Yes, I know it's Intel syntax. Will be converted to AT&T syntax
as soon as the whole thing actually works.. 8)
Change-Id: Ic51869cf67d842041f8842cd9964d72a024c335f
Signed-off-by: Stefan Reinauer <stefan.reinauer(a)coreboot.org>
Reviewed-on: http://review.coreboot.org/11106
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich(a)gmail.com>
### EXHIBIT D: src/cpu/amd/agesa/cache_as_ram.inc ###
$ git blame src/cpu/amd/agesa/cache_as_ram.inc |grep intel_syntax
67b9430b src/cpu/amd/agesa/cache_as_ram.inc (Stefan Reinauer
2015-06-18 01:14:01 -0700 66) .intel_syntax noprefix
$ git show 67b9430b
commit 67b9430b367a9f9a884043f14365a55b7ef3c45c
Author: Stefan Reinauer <stefan.reinauer(a)coreboot.org>
Date: Thu Jun 18 01:14:01 2015 -0700
cpu: port amd/agesa to 64bit
Change-Id: I8644b04f4b57db5fc95ec155d3f78d53c63c9831
Signed-off-by: Stefan Reinauer <stefan.reinauer(a)coreboot.org>
Signed-off-by: Scott Duplichan <scott(a)notabs.org>
Reviewed-on: http://review.coreboot.org/10579
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me(a)gmail.com>
Tested-by: Raptor Engineering Automated Test Stand
<noreply(a)raptorengineeringinc.com>
### EXHIBIT E: src/cpu/amd/pi/cache_as_ram.inc ###
$ git blame src/cpu/amd/pi/cache_as_ram.inc |grep intel_syntax
f7613eca (Stefan Reinauer 2015-07-21 13:34:01 -0700 67) .intel_syntax
noprefix
$ git show f7613eca
commit f7613ecacc02d486caa868a1f494dc46983aeb3d
Author: Stefan Reinauer <reinauer(a)chromium.org>
Date: Tue Jul 21 13:34:01 2015 -0700
cpu: port amd/pi to 64bit
Change-Id: I66ef081fa1a520f0199366587800783ea1ef8719
Signed-off-by: Stefan Reinauer <stefan.reinauer(a)coreboot.org>
Reviewed-on: http://review.coreboot.org/11023
Reviewed-by: Ronald G. Minnich <rminnich(a)gmail.com>
Tested-by: build bot (Jenkins)
by Raptor Engineering Automated Coreboot Test Stand
The ASUS KGPE-D16 fails verification as of commit 68e3f6dd371ced6963802295e1e176dca5729d2f
The following tests failed:
BOOT_FAILURE
Commits since last successful test:
68e3f6d util/release: extend release script
See attached log for details
This message was automatically generated from Raptor Engineering's ASUS KGPE-D16 test stand
Want to test on your own equipment? Check out https://www.raptorengineeringinc.com/content/REACTS/intro.html
Raptor Engineering also offers coreboot consulting services! Please visit https://www.raptorengineeringinc.com for more information
Please contact Timothy Pearson at Raptor Engineering <tpearson(a)raptorengineeringinc.com> regarding any issues stemming from this notification
