by Raptor Engineering Automated Coreboot Test Stand
The ASUS KFSN4-DRE fails verification as of commit b11be321a895aa70adeaa8cb92fcfcd5dcbd748c
The following tests failed:
Commits since last successful test:
b11be32 build system: use platform specific ar(1) for libverstage
7aafe53 timestamp: fix incremental linking error for !HAVE_MONOTONIC_TIMER
1d7b9de kbuild: Use wildcard for driver subdirectories
2e38cc5 MAINTAINERS: Add lint scripts
b2aee6f vboot2: Replace hard coded 'fallback' prefix with Kconfig variable
<39 commits skipped>
2436bda cpu: get rid of socket source code
99cc1aa Mediawiki editing warning
e9b7e25 util/xcompile/xcompile: Allow to override `HOSTCC` variable
939dc84 crossgcc: Re-download the archive if it is incomplete
6548ae9 cbfstool/Makefile*: Use `LDFLAGS` instead of `LINKFLAGS`
See attached log for details
This message was automatically generated from Raptor Engineering's ASUS KFSN4-DRE test stand
Raptor Engineering 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
I am trying to debug coreboot with qemu-x86 with the following command -
qemu-system-x86 -L . -bios coreboot.rom -nographic
I am getting output something like this - http://pastebin.com/Ae2X5sPe
(Also pasted below)
EAX=00000000 EBX=00000000 ECX=00000000 EDX=00000633
ESI=00000000 EDI=00000000 EBP=00000000 ESP=00000000
EIP=0000fff0 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0000 00000000 0000ffff 00009300
CS =f000 ffff0000 0000ffff 00009b00
SS =0000 00000000 0000ffff 00009300
DS =0000 00000000 0000ffff 00009300
FS =0000 00000000 0000ffff 00009300
GS =0000 00000000 0000ffff 00009300
LDT=0000 00000000 0000ffff 00008200
TR =0000 00000000 0000ffff 00008b00
GDT= 00000000 0000ffff
IDT= 00000000 0000ffff
CR0=60000010 CR2=00000000 CR3=00000000 CR4=00000000
DR0=00000000 DR1=00000000 DR2=00000000 DR3=00000000
I have build coreboot.rom with the following option in .config -
Payload ---> Add a payload ---> FILO ;
Payload ---> FILO version ---> HEAD
Kindly let me know if I am missing something here.
The issue was that qemu-x86 did not support u-boot.
Resolved it by picking up latest commits.
On Wed, May 6, 2015 at 11:26 AM, Ajoy Das <dasajoy80(a)gmail.com> wrote:
> what is the difficulty u r facing ?
> yes it is suppose to work
> On Tue, May 5, 2015 at 7:39 PM, Saket Sinha <saket.sinha89(a)gmail.com> wrote:
>> I am trying to run u-boot as a coreboot payload on qemu-x86.Currently
>> facing some difficulty in the process.
>> Has anyone tried running u-boot as a coreboot payload on qemu-x86 before?
>> Saket Sinha
>> coreboot mailing list: coreboot(a)coreboot.org
Hello Kyösti, hello Wim,
with AGESA source there is a file buildOpts.c in the mainboard directory. In this file you can overwrite seed values and they will be passed to AGESA build.
With binary Pi this file is absent. How is it possible to pass values to binary PI?
My AMD support comes from Aschheim-Dornach, Germany.
On to, 2015-05-07 at 13:19 +0000, Wolfgang Kamp - datakamp wrote:
> Hi Bruce,
> is it right that the AGESA Pi binary for AMD Olivehill+ board is not usable for custom board implementations of FT3B GSOC?
> For example, if we use memory down design in star topology, AGESA will fail to initialize DDR3.
I assume you have left out SPD eeproms from BOM, so have you already
created and double-checked the SPD files? We have some boards in the
tree doing that already.
I hope to upstream DB-FT3b-LC board sources to coreboot.org, possibly
next week. That may or may not help You further.
Do you have PI build with raminit logging enabled?
On Thu, May 7, 2015 at 1:42 PM Patrick Georgi <pgeorgi(a)google.com> wrote:
> One of these days...
well, that's kind of key ... one of these days. Once we came to that happy
time it might make sense to make this change, but until then, I think we
have to wait. Now I know how to vote.
On 2015-05-07 11:25, Anteja Vuk-Maček wrote:
> I'm begin with coreboot and seaBIOS. I have the problem with USB
> keyboard and mouse. When I boot the firmware my keyboard and mouse
> don't work.
> I use : coreboot, payload seaBios, MinnowMax board
> Problem: What I need to do for correct a firmware?
> Best regards,
> _Anteja _
What version of Coreboot are you using? Version number should look
like 4.0-9612-g7aafe53. What version of the Intel FSP are you
I'm running GIT commit d93bd263b66d83fff4e22826e465aae8fac326df + the
from the following review:
With my Apple USB keyboard connected to the USB 3.0 port I can enter the
boot menu and make a selection from there without a problem. That is on
core Minnowboard Max.
* ron minnich <rminnich(a)gmail.com> [150507 21:35]:
> one counter-question: is romcc ever going away, or at least is the usage
> gong to change such that no code would ever use the uint32 version of
> If it's *never* going away then I think the change makes no sense. If romcc is
> going away, then I would favor the change.
With our current bootblock concept, it is never going away on x86 (for
Since Edward started hijacking patches on gerrit to push his
agenda of getting rid of device_t without prior discussion,
I would like to start a poll on how people think about this,
and maybe find reasons for why it might be a good idea.
> The issue of 'device_t' has many heads. The primary issue I have here
> is that these patches introduce many more 'device_t' instances that
> make the job of sorting out which 'device_t' are 'uint32_t' and which
> are 'struct device *' significantly harder as this sort of thing
> If the author would just use 'struct device *' and there is (for some
> wrapped reasoning) a consensus to only use 'device_t' then it is trivial
> to go do 's/struct device * /device_t /g'.
> There is actually no reason needed here to use a opaque type which was
> invented to solve a particular issue however has now spilled over to
> becoming rampant though the tree.
The reality here is that device_t was a concept used ever since coreboot
v2 (LinuxBIOS v2 from 2003 actually) existed. It is indeed the use of
struct device that has accidently spilled over.
The reason this was done was to use the same driver code in romstage and
ramstage. While this can be achieved by other means, no doubt, I don't
think that this churn on the code base is particularly useful.
Before we continue on this path I would like to see a reason for not
using device_t or why the difference between the type has to be sorted
out. The whole idea is that it does not matter, and the code does not
have to know.
Check out the poll at https://doodle.com/vvqtyhdxr9yhvqci