coreboot January 2019

coreboot@coreboot.org

39 participants
31 discussions

OpenBSD won't install on an x220 Thinkpad with Coreboot
by Robert Milton 12 Apr '20

12 Apr '20

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 OpenBSD.

4 4

Optiplex 790 now has preliminary support by coreboot
by Taiidan＠gmx.com 15 Jan '20

15 Jan '20

https://review.coreboot.org/21774 In case anyone else didn't notice - It is a sandy/ivy system with IOMMU. This is great and should help get coreboot in to the corporate user world.

2 1

Coreboot doesn't POST on ASUS KCMA-D8
by espionage724＠posteo.net 28 Mar '19

28 Mar '19

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…

8 8

Menu time-out missing when GRUB is loaded quickly and `at_keyboard`
by Paul Menzel 06 Feb '19

06 Feb '19

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 not shown. 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 the problem. 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 developers $ 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? Kind regards, Paul 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 grub-2.02-238-ga791dc0e3 $ ./autogen.sh $ ./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 ``` Kind regards, Paul

2 2

Braswell FPS memory init problems
by Michal Zygowski 01 Feb '19

01 Feb '19

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? Best regards, -- Michał Żygowski Embedded Systems Engineer http://3mdeb.com | @3mdeb_com

3 6

Re: [coreboot] [LinuxBoot] FOSDEM 2019 deadline today
by Carl-Daniel Hailfinger 01 Feb '19

01 Feb '19

In that case, I'd also like to point you to the deadline for submitting main track talks which is tomorrow(!). https://fosdem.org/2019/news/2018-08-10-call-for-participation/ 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. Regards, Carl-Daniel 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:linuxboot@googlegroups.com>> 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 > <c-d.hailfinger.devel.2006(a)gmx.net > <mailto:c-d.hailfinger.devel.2006@gmx.net>> 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. > >

6 9

Re: [coreboot-gerrit] Change in ...coreboot[master]: usbdebug: Fix reserve in CAR
by Aaron Durbin 31 Jan '19

31 Jan '19

On Thu, Jan 31, 2019 at 11:13 AM Kyösti Mälkki (Code Review) < gerrit(a)coreboot.org> wrote: > 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: > <https://review.coreboot.org/#/c/31174/1/src/arch/x86/car.ld> > - > > Patch Set #1, Line 70: > <https://review.coreboot.org/#/c/31174/1/src/arch/x86/car.ld@70> . > += 0x60; > > yes > > Done > > To view, visit change 31174 > <https://review.coreboot.org/c/coreboot/+/31174>. To unsubscribe, or for > help writing mail filters, visit settings > <https://review.coreboot.org/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 >

1 0

RTC issue
by Hilbert Tu(杜睿哲_Pegatron) 29 Jan '19

29 Jan '19

Hi, 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. -Hilbert 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. 本電子郵件及其附件可能含有機密或依法受特殊管制之資訊，僅供本電子郵件之受文者使用。台端如非本電子郵件之受文者或誤收本電子郵件，請立即回覆郵件通知寄件人，並銷毀本電子郵件之所有複本及附件。任何未經授權而使用、揭露、散佈或複製本電子郵件或其附件之行為，皆嚴格禁止。

1 0

Second call for mentor candidates and project ideas for Google Summer of Code 2019
by Patrick Georgi 29 Jan '19

29 Jan '19

Hi everybody, 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 to have. 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 well. 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. Thanks, Patrick -- 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

1 0

Re: [coreboot] Upgrade the 12 years old LZMA libraries - should we do it?
by Carl-Daniel Hailfinger 28 Jan '19

28 Jan '19

Hi Ivan, 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. Regards, Carl-Daniel

3 2

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot January 2019