I am experiencing a problem with building filo. I am getting the
/........../coreboot/payloads/filo/build/libpayload/lib/libpayload.a(keyboard.libc.o): In function `keyboard_disconnect':
keyboard.c:(.text+0x208): undefined reference to `keyboard_wait_write'
make: *** [/........../coreboot/payloads/filo/build/filo] Error 1
I have tried various guides to try to build but I cannot get it to work.
Does anybody else have the same problem? Or how can I fix it?
On Monday, January 20, 2014 02:59:24 PM you wrote:
> Recently came across this. Provided is a coreboot ROM and payload, with
> instructions on how to generate the segfault. I won't have time to look into
> this anytime soon.
ML server didn't like first email. segfault generating files are at .
I've been following and promoting Coreboot for a few years now, but never have had a computer with one, since I'm not technical enough to do it myself.
I understand that the newer crop of Chromebooks has support for Coreboot, but then I still see many references to flashing it yourself.
Since the commercial availability of Coreboot is a big deal for many people, could someone in the project put up a quick list of vendor-supplied (no hacking required) Coreboot machines, starting with the Chromebooks?
ruik, do you have a working setup with a f2a85-m motherboard at the
moment (i.e. .config file, graphics card, distro/kernel version being
used?) if nothing is working for you right now, how can we narrow this down?
to anyone else: do you find that using one graphics card with coreboot,
works while others do not? any ideas on how i can resolve this issue?
the problems i've been seeing are quite reliable. they happen when using
coreboot + one of a couple graphics card models i've tried + extended
high disk i/o, all together. at other times, these issues are more rare.
also, a somewhat older compilation of coreboot with a vga_bios and
without an external graphics card is crashing multiple times per day,
during that person's day-to-day work flow.
i would like to get coreboot with this motherboard working, so more
people here can use it. :)
below, i give details of the crashes i've observed, their timing and the
type of stress test. (i haven't bisected this problem as well as i could
have so far, but there may be multiple interacting and non-interacting
issues here that i've tried to pin down.) i've attached kernel and
coreboot logs to this email.
my guess is that this is an issue with option roms playing nasty with
coreboot, and that this issue is for some reason brought forth by the
high i/o test. if any of those factors are absent, crashes are far less
frequent, if at all.
- - - - - - - - -
i've been seeing crashing with f2a85-m motherboards with an a8-5600k
processor. vga bioses have not been compiled in to coreboot.
kernel-loading of recent amd microcode has not solved the problem.
option roms get loaded by seabios (or coreboot, in the case of using
grub2 as a payload.) the distro is debian. i've moved from wheezy to
sid, with kernel 3.12. this did not seem to change much.
most of the tests were based on this commit:
the stress test i've been using is mostly running badblocks on repeat
using a couple sata drives. the other test has been building four
kernels at once.
the symptom of crashing under high disk i/o is usually xscreensaver
(grinding to a halt then...) freezing, with unresponsive keyboard and
ssh. the kernel generally continues dumping over serial.
* with coreboot/seabios and an nvidia graphics card under high disk i/o,
the crash generally happens within a few hours, perhaps later
occasionally. (one time, xscreensaver continued for 20 hours, but ssh
and keyboard access failed.)
* with *uefi* and an nvidia graphics card under high disk i/o, i haven't
recorded a crash yet. my first formal test lasted 23h before i rebooted
to enable serial output by the kernel.
* with coreboot/seabios and an nvidia card under high *cpu/mem* usage,
but *low disk i/o*, a box lasted for 2.5 *days* before i decided to shut
* with coreboot/seabios and *without* a graphics card under high disk
i/o, one test lasted 36h before crashing.
* with coreboot/*grub2* payload and an nvidia graphics card under high
disk i/o, the crash was after about 1.5h. (strangely, one badblocks
process thought it had run for about 2x the uptime of the machine.)
* with coreboot/seabios and an msi graphics card under high disk i/o,
the crash happened around 4.5 hours later.
* a machine running an older coreboot/seabios/vga bios without an
external card, and running the latest version of trisquel: has been
crashing multiple times per day under heavy, or even very light work load.
i had other data points, but wasn't always recording details. recent
coreboot/kernel logs are attached to this email.
if anyone has any idea of what the issue(s) may be here, or how i could
try narrowing this down, please help me out. thanks! :)
I have some questions about this little guy. Fear not, your answers will be
ported to the coreboot wiki at my earliest convenience.
1. What is the maximum amount of RAM that it supports? Can in take in 2 x 8GiB
modules? If so, are there any limitations as to the number of ranks?
2. Are the slots dual channel, or are both slots routed to same channel? (From
the source, I think it's dual.)
3. If I install 1.35 V capable DIMMs, will coreboot run them at 1.35 V, or is
1.5 V the only option?
4. If ECC modules are installed, will coreboot be able to enable ECC, or are
those pins not even routed ?
5. Why is SATA speed limited to 6Gbps (see devicetree.cb) ? From my
understanding, the first SATA port on the chipset is 6G capable, as is the SSD
shipping inside. Is this a board routing limitation, or copypasta? I can
submit a patch if it's the latter.
On Sat, Jan 18, 2014 at 12:52 AM, Ky?sti M?lkki wrote:
> On 01/17/2014 01:01 PM, Timothy Potter wrote:
> > Hi,
> > I'm trying to get Coreboot with SeaBIOS running on a Chromebox. I
> > followed the page about compiling Coreboot for a Chomebook 550, assuming
> > they are similar in some respects. Unfortunately none of the builds have
> > booted. Just the blue power light comes on at best.
> > I'm wondering if anyone knows which is the USB Debug Port or the pin
> > of the LPC bus connector? I've got one of those cheap Mini PCI Express
> > POST diagnostic cards but can't work out how to wire up. I've also got
> > old Android phone with the ECHI debug gadget compiled into the kernel.
> > tried connecting that to every USB port on the Chromebox but never get
> > output.
> > Hope someone can help.
> > Cheers,
> > Tim.
> Hi Tim
> Did you apply the two patches for EHCI gadget available here:
> Try this without Chromebox first: Connect phone with any normal USB
> host. Run lsusb -v on the host to verify your Android exports USB debug
> descriptor. Then post system logs from both sides of the connection.
> Now for the physical USB port to use. If you can boot your Chromebox
> with the original flash image, a working port should appear as "usb
> 1-1.2" or "usb 2-1.2" in the system log when you connect any USB device.
> For coreboot configuration with Intel platform, HCD_INDEX=1 maps to
> 0:1d.0 and HCD_INDEX=2 maps to 0:1a.0. It's reversed order, like in the
Yes, I applied the patches, although I'm using kernel 2.6.32 so I had to
add some of the chunks manually. You can see the changes here:
I may have got something wrong.
I suspect it's a problem on the phone side as the EHCI debug gadget doesn't
show up in lsusb. When I have more time I'll post the system logs and try
patching and building a 3.0.3 kernel for the phone. It's a Motorola Defy.
There doesn't appear to be any working kernel new than that.
On Sat, Jan 18, 2014 at 12:52 AM, John Lewis wrote:
> On 17/01/14 11:01, Timothy Potter wrote:
> > I've
> > also got an old Android phone with the ECHI debug gadget compiled into
> > the kernel. I've tried connecting that to every USB port on the
> > Chromebox but never get any output.
> Hi Tim,
> Have you got "USB 2.0 EHCI debug dongle support" compiled on the
> coreboot side? If so, did you select "NET20DC and compatible" or
> What kernel is the phone running? I assume because you have the EHCI
> debug gadget complied in the Android gadget is not? How does your phone
> react to the missing Android gadget?
I had a bit of time to review what how I'd set things up this weekend.
Yes. I compiled the debug dongle support into Coreboot, and left the
default 'NET20DC and compatible' selected.
On the phone side. Yes, the EHCI debug gadget replaces the Android
gadget, so the phone won't even charge while booted, but otherwise seems to
work as normal minus USB functionality. The kernel is version 2.6.32. I
suspect the problem is on the phone side as the phone doesn't show up in
the output of lsusb when connected to a Linux box.
I saw your video with the BeagleBone and HP laptop. Thanks for making
it. Good to see how things should work.
Please can anyone with access to AGESA check what version of AGESA and CIMX (FCH
module) was used for coreboot release?
I want to check some erratas and AMD 48671 document
Refers to CIMX versions, however there is no define with CIMX version in
coreboot only some define for CIMX header.
Second q is more about the CPU itself. What revision of AMD errata document
corresponds with fixes implemented in coreboot AGESA.
And last q is. Will anyone backporting fixes from AMD agesa to coreboot agesa?