January 2019 - coreboot - mail.coreboot.org

Optiplex 790 now has preliminary support by coreboot

by Taiidan＠gmx.com

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.

1 week, 3 days

2
1
0 0

Coreboot doesn't POST on ASUS KCMA-D8

by espionage724＠posteo.net

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

10 months

8
8
0 0

Menu time-out missing when GRUB is loaded quickly and `at_keyboard`

by Paul Menzel

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

11 months, 3 weeks

2
2
0 0

Braswell FPS memory init problems

by Michal Zygowski

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

11 months, 4 weeks

3
6
0 0

Re: [coreboot] [LinuxBoot] FOSDEM 2019 deadline today

by Carl-Daniel Hailfinger

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

11 months, 4 weeks

6
9
0 0

Re: [coreboot-gerrit] Change in ...coreboot[master]: usbdebug: Fix reserve in CAR

by Aaron Durbin

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 >

11 months, 4 weeks

1
0
0 0

RTC issue

by Hilbert Tu(杜睿哲_Pegatron)

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

12 months

1
0
0 0

Second call for mentor candidates and project ideas for Google Summer of Code 2019

by Patrick Georgi

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

12 months

1
0
0 0

Re: [coreboot] Upgrade the 12 years old LZMA libraries - should we do it?

by Carl-Daniel Hailfinger

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

12 months

3
2
0 0

Fallback mechanisms on x86 with C_ENVIRONMENT_BOOTBLOCK

by Arthur Heymans

Hi 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 mechanism. 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 sysfs. 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 use. 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? Kind regards Arthur Heymans

1 year

4
9
0 0

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot January 2019