coreboot November 2019

coreboot@coreboot.org

52 participants
51 discussions

Re: [SeaBIOS] Booting Memtest86+ from CBFS fails
by Mike Banon 08 Nov '19

08 Nov '19

Perhaps a bit late, but I've found a coreboot's memtest86+ payload is buggy compared to memtest86+ floppy (which could be downloaded from memtest.org and added to CBFS to be accessible as SeaBIOS menu entry). In addition to your observed problem: at AMD Lenovo G505S and maybe some other coreboot laptops, the USB devices like keyboard are not working at coreboot's memtest86+ while working fine at all the other payloads using "libpayload" (i.e. coreinfo or tint) - so it's not a libpayload problem - and also the same USB keyboards are working at memtest86+ floppy. So it is obvious something is broken at 86+ payload source code. Also, with LZMA compression 86+ floppy occupies much less space than 86+ payload. So, aside from academic/research purposes, I do not see any advantages of 86+ payload compared to 86+ floppy - only disadvantages: larger size and troubled USB. I've seriously considered submitting a patch which replaces coreboot's memtest86+ payload with a floppy (download, compare its' checksum and then insert to CBFS), but then I thought that maybe someone could need 86+ payload as a coding example. If you would like to try out a floppy (e.g. because something else - like 2GB support - could be also broken at 86+ payload, while working fine at 86+ floppy booted through SeaBIOS) , here are the instructions: 1) Download the latest 5.01 version of memtest86+ from memtest86.org : wget https://www.memtest.org/download/5.01/memtest86+-5.01.floppy.zip 2) Calculate its' sha256 : sha256sum ./memtest86+-5.01.floppy.zip should be 2a2d4c1234c9130e1da5fea941ccfbaa343739d5b3302b5f3f9b24077868f8ee ./memtest86+-5.01.floppy.zip 3) If sha256 is correct, unzip ./memtest86+-5.01.floppy.zip . You'll get a "floppy" directory with these files: ls ./floppy/ dd.exe install64.bat install.bat memtestp.bin rawrite.exe README.txt You only need memtestp.bin , sha256 of which is " ddd4a2ba44c312aa4f2c7506a388cc2ca7f1caec60c3c6d80ed8a9f0b43d529c " 4) Size of memtestp.bin file is 150024 bytes. To be understood by SeaBIOS, it needs to be expanded to 1474560 bytes (by zeroes), which could be done with this command: dd if=/dev/zero of=./memtestp.bin bs=1 count=1 seek=1474559 conv=notrunc sha256 of expanded memtestp.bin file will be " 364535abd0d105da9396df6015e480c4d4c52b07dcc4e1d4756bde8ef87a30f1 " 5) Now it could be added to the compiled coreboot.rom with this command: ./build/cbfstool ./build/coreboot.rom add -f ./floppy/memtestp.bin -n floppyimg/memtestp.lzma -t raw -c lzma If done everything correctly, it will be available at SeaBIOS boot menu as Ramdisk [memtestp] Best regards, Mike Banon On Sun, Jul 28, 2019 at 8:40 AM Martin Kepplinger <martink(a)posteo.de> wrote: > > Hi, > > I use the simple coreboot config > https://github.com/merge/skulls/blob/master/x230/free-defconfig-555419f356 > > on today's coreboot master branch HEAD (403f433238), using SeaBIOS 1.12.1. > > When choosing memtest86+ in SeaBIOS' menu, "Booting from CBFS" gets > printed but nothing else happens. > > Booting into nvramcui or coreinfo works though. > > (earlier, at least on coreboot 555419f356, using the same version of > SeaBIOS, things were fine). > > Can you imagine why? > > thanks, > martin > _______________________________________________ > SeaBIOS mailing list -- seabios(a)seabios.org > To unsubscribe send an email to seabios-leave(a)seabios.org

2 1

Re: LAVA support
by Patrick Rudolph 07 Nov '19

07 Nov '19

Hi Wim, the lava as QA system is still being worked on, but currently has the lowest priority. While some hardware has been automated for firmware testing, some glue code is still missing. Some details can be found here: https://9esec.io/blog/bios-test-station/ Regards, Patrick On 2019-11-01 04:58 PM, Alexander 'lynxis' Couzens wrote: > Hi Wim, > > >> The coreboot site refers to the LAVA site as the QA system. It looks >> like some attempts have been made and then abandoned. > > that's so far true. I've setted up a lava environment some years ago, > but didn't had the time to continue and maintain it. > >> Does anyone know the current status? Did this not work out or is >> there another reason not to add additional platforms to the >> environment? > > It worked out to test coreboot. Patrick was also looking into it this > year. (CC: Patrick/siro). > > Maybe it's time to do another run of integrating it into the coreboot > CI? > > > Best, > lynxis > > _______________________________________________ > coreboot mailing list -- coreboot(a)coreboot.org > To unsubscribe send an email to coreboot-leave(a)coreboot.org

3 2

How does SMI handling designed in Coreboot and how does payload behave?
by Naveen Chaudhary 06 Nov '19

06 Nov '19

Hi, I am using Linux bzImage as the payload for coreboot with a minimal initrd that gives me a shell to play with (or even kexec the bigger kernel on disk). I could see that Coreboot has SMI handler at src/cpu/x86/smm/smihandler.c which I am yet to explore more. 1. But by design, who is expected to handle the SMI? Does this linux payload also receive this SMI interrupt? Or its handled by coreboot alone? 2. What effect does it have on the payload on runtime? 3. After SMM mode is over, does the payload resume? I have minimal knowledge on SMM, so consider me noob. Maybe my questions doesn't make sense, so please correct me. Regards, Naveen

2 2

Re: Looking for INTEL board compatible with Coreboot
by Naveen Chaudhary 06 Nov '19

06 Nov '19

You can go with MinnowMax which is based on Baytrail SoC and its compatible with core boot. In fact, I tested that yesterday only and I am actively using it with core boot from past few weeks. The latest version of the same board is Minnow3 that is I believe based on ApolloLake, though I am not sure if the HEAD of core boot works or not. I haven’t tested the core boot on Minnow3, but definitely the core boot supports Minnow3. UP-Square is another board which recently came out and that should also be compatible with Coreboot as the support was added recently. >>using flashrom if you type: -L | --list-supported print supported devices it says: Supported flash chips (total: 391): This doesn’t list the boards. They are actually SPI flash chips present on the board. e.g. MinnowMax has 8MB Winbond flash chip and that is supported by flashrom. Regards, Naveen

2 1

Proposal to add teeth to our Gerrit guidelines
by Nico Huber 05 Nov '19

05 Nov '19

Hello coreboot fellows, first I want to say, I feel pretty awkward bringing this up. I'm not a fan of regulations. But as it turns out, our community is growing (\o/) and with that growth the number of situations where regulation seems necessary increases too. So, we already have Gerrit guidelines [1]. While they are most often not worth a look (common sense usually is enough), some people like to be reminded of them regularly. The latter is pretty annoying and doesn't seem to help. I propose to add some lines what should happen when somebody delibe- rately ignores the guidelines. One such case that I often see is rubber-stamping of huge commits. Our guidelines say "As a reviewer who approves (+2) a patch, you are responsible for the patch and the effect it has on the codebase." I've never seen anyone taking responsibility for rubber-stamped code. Bigger additions seem to be always cleaned up by other folks. This led me to the following idea: Reviewers who rubber-stamp bigger code additions will be demoted by one group on Gerrit. They can only return to the higher group after one hour per rubber-stamped, added line. Sounds easy and fair, I'd say. What do you think? Of course, there are many other kinds of violations; feel free to bring more up. I just want to start the discussion. Nico [1] https://doc.coreboot.org/getting_started/gerrit_guidelines.html -- M. Sc. Nico Huber Senior Consultant SINA Software Development and Verification Division Defence secunet Security Networks AG Phone: +49-201-5454-3635, Fax: +49-201-5454-1325 E-Mail: nico.huber(a)secunet.com Mergenthalerallee 77, 65760 Eschborn, Deutschland www.secunet.com _____________________________________________________________________ secunet Security Networks AG Registered at: Kurfuerstenstraße 58, 45138 Essen, Germany Amtsgericht Essen HRB 13615 Management Board: Axel Deininger (CEO), Torsten Henn, Dr. Kai Martius, Thomas Pleines Chairman of Supervisory Board: Ralf Wintergerst ______________________________________________________________________

3 3

[RFC] Logging boot_state times
by Kyösti Mälkki 05 Nov '19

05 Nov '19

Hi In case someone is parsing coreboot logs and boot_state times in particular, I am suggesting a change [1] to that format to report in milliseconds rather than microseconds. Another (but yet unimplemented) change is to accumulate for each boot_state the times spent in printk() and udelay(). I think it will be more meaningful to report estimated execution time, rather than realtime there. I don't plan to remove the latter, though. [1] https://review.coreboot.org/c/coreboot/+/36528 Regards, Kyösti

1 1

Re: Any live usb for recovery flash coreboot?
by Branden Waldner 05 Nov '19

05 Nov '19

I tested Nico's method for you with a Debian bios install, but it might be different for the Manjaro live usb. To stall grub from booting, you can press the left arrow key repeatedly, assuming that doesn't mess with tianocore loading first. Then you press e to edit the boot parameters. For my debian/grub2 install the kernel line was 14 lines down, so you just press the down 14 times. Then press end to go to the end of the line and add a space and iomem=relaxed and press ctrl+x or F10 to boot. As for rescue systems with flashrom neither grml (debian based rescue usb) or the old gentoo based systemrescuecd worked for me without adding iomem=relaxed. Most live systems seem to use a udf/iso setup making it hard to just edit the kernel command line directly. The old systemrescuecd actually uses a fat formatted partition and would let you edit it, but it is more complicated to set up then the usual livecds. You could also probably just chroot into your primary manjaro install from your live usb and then install the efi version of grub2 and use your extra usb as the boot drive, possibly copying over your /boot directory as well. Of course, just installing a full system to the extra usb with a ufi bootloader like you said you already did should have worked as well. Does tianocore use/respect using boot/bootx64.efi? If so, you could copy grubx64.efi which should be on your efi partition, probably in a directory called manjaro, into a new directory called boot and rename it to bootx64.efi. See https://wiki.gentoo.org/wiki/GRUB2#Alternative:_using_the_default_UEFI_firm… or https://wiki.archlinux.org/index.php/GRUB#Default/fallback_boot_path for more information on that. That seems like a lot of rambling. Hopefully some of it helps you though. Branden

5 5

G505S : S3 resume freezes without CONFIG_CBMEM_STAGE_CACHE
by Mike Banon 03 Nov '19

03 Nov '19

Good day! Starting with commit 0a4457ff44b10f22b711f64e88888c757fbedf32 which introduced a disabled-by-default CONFIG_CBMEM_STAGE_CACHE option - https://github.com/coreboot/coreboot/commit/0a4457ff44b10f22b711f64e88888c7… - S3 resume freezes on G505S if this option isn't enabled. Commit message tells that "AGESA platforms without TSEG will experience slower S3 resume speed unless they explicitly select the option.", however I've waited for like an hour but it's still stuck and can't be turned on later without a force shutdown and full laptop discharge. Here is a diff for S3 resume log obtained with USB FT232H dongles, left side - before this commit, right side - after it but with this option disabled - http://www.mergely.com/MOfZeDPX/ . Where the left side had "usbdebug: ramstage starting... S3 Resume.", right side gave a sudden restart of romstage initialization and soon got stuck after APIC 00: ** Enter AmdInitEarly [00020002]. Force shutdown without a full discharge gave "RAM INIT FAILURE" after "APIC 00: ** Exit AmdInitResume [00020008]" soon after that, and only a full discharge helps to get this laptop working again. There's the same behavior for a fresh coreboot as well. Here is my coreboot config I've used as a base - https://pastebin.com/6Nj6e6xZ . Is this problem expected? If not, I could help by testing your debug builds aimed on fixing it. In addition, S3 resume is also not working with CONFIG_SECURITY_CLEAR_DRAM_ON_REGULAR_BOOT even if CONFIG_CBMEM_STAGE_CACHE is enabled. Maybe we should introduce a Kconfig "switch" for G505S CONFIG_HAVE_ACPI_RESUME option at ./src/mainboard/lenovo/g505s/Kconfig ? A new option CONFIG_ACPI_RESUME , which could be enabled only with CONFIG_CBMEM_STAGE_CACHE and without CONFIG_SECURITY_CLEAR_DRAM_ON_REGULAR_BOOT Best regards, Mike Banon

2 3

LAVA support
by Wim Vervoorn 01 Nov '19

01 Nov '19

Hello, The coreboot site refers to the LAVA site as the QA system. It looks like some attempts have been made and then abandoned. Does anyone know the current status? Did this not work out or is there another reason not to add additional platforms to the environment? Best regards, Wim

2 1

Any live usb for recovery flash coreboot?
by Dalao 01 Nov '19

01 Nov '19

Hi, I was using Seabios but recently switched to Tianocore. However, the tianocore can't boot my Manjaro linux distribution which was installed using the non-uefi method. So I want to flash back. I only have a Manjaro live usb at hand. The tianecore can boot it. However this live usb is not set with iomem=relaxed, so I can't read or write the bios using flashrom. I don't know how to set the live usb's grub settings because when it boots, it's already running commands. When using this tianocore with vgabios I can't see the grub screen when booting. So how to set the live usb with iomem=relaxed? Is there any live usb that already have the iomem=relaxed set? Could anyone help me build a usb image dedicated for automatically recover flashing?

7 12

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot November 2019