I'm trying to get OpenBSD to install on an x220 Thinkpad with
Coreboot/SeaBIOS but I'm running into two problems: the ethernet device
doesn't work and OpenBSD doesn't detect my HDD. dmesg said em0 wouldn't
load because the EEPROM had an invalid signature. I have no idea why
OpenBSD doesn't see my HDD though. It's strange because everything works
fine under Linux. And I cannot seem to mount a usb drive under the
OpenBSD installer to attach dmesg errors.
I originally posted this as a bug report to bug report mailing list but
Theo said it would be better suited for Coreboot's and wasn't a bug in
I have a KCMA-D8 motherboard with two Opteron 4226s, and 6x4GB (24GB) Hynix HMT151R7BFR4C-H9 RAM sticks. All my attempts of getting Coreboot to POST with this board so far haven't worked. I'm compiling Coreboot from Git (master branch), and can build it without issue. A pre-built Libreboot ROM (20160907) POSTs and boots fine.
For Coreboot's config, I've tried including/excluding CPU microcode updates, along with some less important-sounding options. For hardware, I've tried unplugging everything external (KB/mouse), my GPU (RX 580), and only had a single RAM stick in (slot A1). I've also tried a single CPU being powered (kept the 2nd CPU in but only had a single 4-pin CPU going to the 1st CPU).
Can anyone else confirm Git builds of Coreboot booting on this board, or provide any tips as to anything I could be missing?
I see this issue https://ticket.coreboot.org/issues/151 but there's a board status months after that that looks like it boots: https://review.coreboot.org/cgit/board-status.git/tree/asus/kcma-d8/4.7-789…
Dear GRUB folks,
When the module `at_keyboard` is directly into the GRUB image
(`--modules`), and GRUB is loaded really quickly, then the timer, which,
after counting down to 0 (`GRUB_TIMEOUT`), starts the selected entry, is
I noticed this issue on the ASRock E350M1 with coreboot and a small GRUB
payload, and a PS/2 keyboard connected. Due to the missing time-out, I
manually have to confirm the selected entry. By chance, the keyboard
wasn’t connected setting up the system somewhere else, and that made it
work as expected. So, it looks like, it’s related to `at_keyboard`, and
some race, because the bigger default GRUB payload also does not show
Luckily, it’s easily reproducible with GRUB’s standard
`default_payload.elf` and QEMU.
Please find the instructions below to reproduce the issue.
$ git clone https://review.coreboot.org/coreboot
$ cd coreboot
$ # save attached grub.cfg in the directory
$ util/scripts/config -e PAYLOAD_GRUB2
grep: .config: Datei oder Verzeichnis nicht gefunden
$ util/scripts/config -e GRUB2_INCLUDE_RUNTIME_CONFIG_FILE
$ util/scripts/config -e GRUB2_MASTER
$ util/scripts/config -e CONFIG_COREBOOT_ROMSIZE_KB_2048 # default
of 512 KB too small for GRUB payload
$ util/scripts/config -e ANY_TOOLCHAIN
$ # or: make crossgcc-i386 CPUS=`nproc`
$ make olddefconfig
$ make -j`nproc`
$ qemu-system-x86_64 --version
QEMU emulator version 3.1.0 (Debian 1:3.1+dfsg-2+b1)
Copyright (c) 2003-2018 Fabrice Bellard and the QEMU Project
$ qemu-system-x86_64 -M pc -bios build/coreboot.rom -serial stdio
*No* time-out is shown. Telling QEMU to emulate a USB keyboard,
indirectly disabling the PS/2 keyboard, the time-out *is* shown.
$ qemu-system-x86_64 -M pc -bios build/coreboot.rom -serial stdio \
-usb -device usb-kbd
Not including `at_keyboard` directly in GRUB’s “core image”, modules
loaded automatically, the time-out is also shown.
`set debug=at_keyb` did not show anything interesting.
Can you reproduce that, and see what the problem is?
PS: Please find the instructions to build GRUB as a coreboot payload
done by coreboot’s Kconfig system automatically, and how put it into the
coreboot filesystem CBFS.
$ git clone https://git.savannah.gnu.org/git/grub.git/
$ cd grub
$ git describe --tags --dirty
$ ./configure --with-platform=coreboot
$ make default_payload.elf # this includes `at_keyboard`
$ cp default_payload.elf my/coreboot/folder/
$ cd my/coreboot/folder/
$ build/cbfstool build/coreboot.rom print
$ build/cbfstool build/coreboot.rom remove -n fallback/payload
$ build/cbfstool build/coreboot.rom add-payload -f payload.elf -n
fallback/payload -c lzma
Dear coreboot community,
I am experiencing problems with FSP Memory Init on Braswell SoCs. FSP
Memory Init is not returning. I have following processors that fail:
Celeron J3060 and Celeron J3160; both have the same issue.
The platform has 1 SODIMM module on channel 0. I am feeding the UPD
header with correct SPD, but still no luck. I have also tried FSP MR1
and MR2, but nothing works.
Is anyone here more experienced with Braswell platforms? Could You give
me some advices?
Embedded Systems Engineer
http://3mdeb.com | @3mdeb_com
In that case, I'd also like to point you to the deadline for submitting
main track talks which is tomorrow(!).
Having a coreboot/LinuxBoot talk there would be awesome. Ron/David,
could you submit something or do you have someone in mind who can do that?
There's also lightning talks, deadline is a bit later.
OK, I'm submitting a request for a stand. I need a backup contact for
the stand. Who is willing to do that? AFAICS we can still change the
backup contact later if life happens.
On 02.11.2018 20:48, David Hendricks wrote:
> On Fri, Nov 2, 2018 at 9:15 AM 'Ron Minnich' via linuxboot
> <linuxboot(a)googlegroups.com <mailto:firstname.lastname@example.org>> wrote:
> I"m leaning to yes, by which I mean if you do it, I'll show up.
> I can't believe I said that.
> On Fri, Nov 2, 2018 at 7:20 AM Carl-Daniel Hailfinger
> <mailto:email@example.com>> wrote:
> > Hi!
> > FOSDEM next year will be on 2 & 3 February 2019.
> > The deadline for applying for a stand is today.
> > Do we want a coreboot/flashrom/LinuxBoot stand/booth?
> Same as what Ron said. I think someone from FB can be there to talk
> about coreboot/LinuxBoot stuff and perhaps bring some hardware to demo.
On Thu, Jan 31, 2019 at 11:13 AM Kyösti Mälkki (Code Review) <
> Aaron, Julius; there is a bit of dilemma with car.ld.
> 1) We need consistent layout across PRE_RAM stages
> 2) We want RO bootblock, unaware of (future) RW romstage requirements
> 3) I don't like the semi-random size reserve, like done here for usbdebug
> Any ideas how to from improve this? Looking at CONFIG_COMMONLIB_STORAGE
> and CONFIG_PAGING_IN_CACHE_AS_RAM, I am not sure if the fixed locations are
> always maintained properly. There is some strong assumption at least, that
> bootblock and romstage are built with same set of Kconfig options set.
That definitely is the assumption. Kconfigs are global and there shouldn't
be guarding of entries in the car.ld linker script based on stage w.r.t. to
order and size of the allocated space.
> View Change <https://review.coreboot.org/c/coreboot/+/31174>
> 1 comment:
> File src/arch/x86/car.ld:
> Patch Set #1, Line 70:
> <https://review.coreboot.org/#/c/31174/1/src/arch/x86/car.ld@70> .
> += 0x60;
> To view, visit change 31174
> <https://review.coreboot.org/c/coreboot/+/31174>. To unsubscribe, or for
> help writing mail filters, visit settings
> Gerrit-Project: coreboot
> Gerrit-Branch: master
> Gerrit-Change-Id: Ib49fca781e55619179aa8888e2d859560e050876
> Gerrit-Change-Number: 31174
> Gerrit-PatchSet: 2
> Gerrit-Owner: Kyösti Mälkki <kyosti.malkki(a)gmail.com>
> Gerrit-Reviewer: Arthur Heymans <arthur(a)aheymans.xyz>
> Gerrit-Reviewer: Julius Werner <jwerner(a)chromium.org>
> Gerrit-Reviewer: Kyösti Mälkki <kyosti.malkki(a)gmail.com>
> Gerrit-Reviewer: Nico Huber <nico.h(a)gmx.de>
> Gerrit-Reviewer: Patrick Rudolph <siro(a)das-labor.org>
> Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org>
> Gerrit-CC: Paul Menzel <paulepanter(a)users.sourceforge.net>
> Gerrit-Comment-Date: Thu, 31 Jan 2019 18:13:01 +0000
> Gerrit-HasComments: Yes
> Gerrit-Has-Labels: No
> Comment-In-Reply-To: Patrick Rudolph <siro(a)das-labor.org>
> Comment-In-Reply-To: Arthur Heymans <arthur(a)aheymans.xyz>
> Gerrit-MessageType: comment
> coreboot-gerrit mailing list -- coreboot-gerrit(a)coreboot.org
> To unsubscribe send an email to coreboot-gerrit-leave(a)coreboot.org
My platform is Intel Denverton with Coreboot 4.8.1 and it can boot up successfully except RTC. There is always an error like “unable to open rtc device (rtc0)” when I try to set clock. But if I use BIOS to boot up again, this error will be disappeared and later boot up with Coreboot and setup hwclock successfully. Does anyone have same experience and know how to fix it? Thanks.
This e-mail and its attachment may contain information that is confidential or privileged, and are solely for the use of the individual to whom this e-mail is addressed. If you are not the intended recipient or have received it accidentally, please immediately notify the sender by reply e-mail and destroy all copies of this email and its attachment. Please be advised that any unauthorized use, disclosure, distribution or copying of this email or its attachment is strictly prohibited.
I just want to remind you that we're applying for GSoC this year and
for planning reasons they want us to state how many mentors we expect
So if you're interested to potentially help a student get up to speed
on a firmware related topic (coreboot or nearby projects), please
reach out to me until Sunday, so I can finalize the paper work (which
is due next week).
While students shall outline the project they want to work on in their
application to GSoC, it's normal and expected to provide guidance in
the form of project proposals. If you have ideas (and ideally are
prepared to mentor students working on them) please reach out to me as
I'll incorporate them in
https://review.coreboot.org/c/coreboot/+/30972 so we'll have a
maintained collection on our documentation site.
That list is also suitable for other situations but whatever the
occasion, it always help to have a point of contact listed with any
idea so that somebody interested in working on them knows who to
contact for details and help.
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
On 03.04.2018 20:03, Ivan Ivanov wrote:
> I have noticed that both coreboot and seabios are using the very old
> versions of LZMA SDK.
True. I introduced the lzma code in coreboot (back when it was called
LinuxBIOS) when we were working on OLPC XO-1 support.
> If we will upgrade our LZMA libraries from the
> outdated-by-12-years 4.42 to the current version 18.04 , speed and
> compression ratio should improve and maybe a few bugs will be fixed.
Do you have any numbers for this? An improved compression ratio and
improved speed would be nice indeed, but how does the size of the
decompression code change? If the decompression code grows more than the
size reduction from better compression, it would be a net loss. A
significantly reduced decompression speed would also be a problem.
Decompression speed would have to be measured both for stream
decompression (i.e. the decompressor gets the compressed data in
single-byte or multibyte chunks) as well as full-size decompression
(i.e. the decompressor can access all compressed data at once). We also
have to make sure that stream decompression still works after the change.
> Do you think it should be done, or you are OK with using such an
> outdated version?
A size benefit for the resulting image is a good reason to switch.