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-7...
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.
As more and more x86 platforms are moving to C_ENVIRONMENT_BOOTBLOCK
and therefore don't use a romcc compiled bootblock anymore a certain
question arises. With the romcc bootblock there was a normal/fallback
It works the following way:
It uses RTC cmos to select between the normal and the fallback
bootpaths. So depending on that bit the bootblock selected either
normal/romstage or fallback/romstage which also load postcar stage,
ramstage and payloads with the same prefix from there. There is also a
reboot counter which makes sure that it actually gets to the point it
can load the payload and depending on CONFIG_SKIP_MAX_REBOOT_CNT_CLEAR
it resets that the counter.
This mechanism is not very robust and is more intended to be used to be
able to test things without needing a hardware programmer to flash
images in the case something goes wrong. I use it for instance to test
changes on laptops which take a long time to disassemble.
Currently C_ENVIRONMENT_BOOTBLOCK lacks such generic mechanism on x86
platforms. On the first sight it looks like VBOOT with verstage running
after the bootblock, might be able to achieve a similar boot
scheme. VBOOT seems to lack documentation and while not that hard to get
working, it looks like it is not falling back when there is problem on a
RW_A/B boot path (I called die die(); somewhere in the ramstage to
test). Also the tools around vboot (crossystem) are quite chromeos
specific, requiring Chromeos specific ACPI code exposing the VBNV
variables and also a Linux kernel exposing those ACPI methods via
My understanding of VBOOT might be incorrect or incomplete, so it would
be great if someone more knowledgeable could fill in here.
So at the moment it looks like VBOOT does not fit the bill to be able to
quickly test things while having a fallback mechanism.
Now being able to run GCC compiled code in the bootblock does have the
advantage of allowing much more flexibility over romcc compiled code.
So it is possible to simply reimplement the same behavior with different
prefixes for bootpaths but it would also be possible to do something
similar to what vboot does, namely using separate FMAP regions for boot
paths. This would require a simple cbfs_locator. Upstream flashrom
master now supports using FMAP as a layout so it would be rather easy to
Using FMAP requires a little bit more work (generating a proper default
FMAP, populate the CBFS FMAP regions, implementing a cbfs_locator) but
does allow for nice features like locking the fallback CBFS region to
make sure the fallback can't be erased by accident.
Any thought or suggestions?