coreboot January 2016

coreboot@coreboot.org

38 participants
74 discussions

FlexICE github (was: Issue with internal access to the W39V040FB)
by Stefan Tauner 24 Jan '16

24 Jan '16

On Sat, 23 Jan 2016 17:51:27 +0100 Stefan Tauner <stefan.tauner(a)alumni.tuwien.ac.at> wrote: > On Sat, 23 Jan 2016 19:32:14 +0300 > Andrey Korolyov <andrey(a)xdel.ru> wrote: > > > BTW, are there still any FWH-capable romulators in production? Looks > > like most of sockets from this era has been designed without bearing > > in mind possibility of the in-scheme reprogramming, but the only > > romulators I`ve seen on ebay are ancient devices bundled with software > > on floppies... > > You might be interested in https://www.coreboot.org/FlexyICE > I have just discovered that project a few weeks ago myself so I cannot > give much more information than that. It is probably not purchasable > anymore but open enough that one could build something new from that. > Sooner or later I am planning to give a related projected out as > Bachelor or Master thesis but that will take a while (and would > probably be SPI-related). I have freed the two repositories of the project from opencores (they require registration just to download and the registration process is manual!). Currently they reside in the flashrom realm of github: https://github.com/flashrom/artec_dongle_fpga https://github.com/flashrom/artec_dongle_ii_fpga -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

1 0

Adding new Intel SoC Apollo Lake
by Petrov, Andrey 23 Jan '16

23 Jan '16

Hello, We have just pushed patches that add support for successor of Braswell, new SoC Apollo Lake. This is a minimal, barebones implementation that can run several payload and boot into Linux. Since new FSP 2.0 spec is not yet final we anticipate changes in the FSP harness. Notable changes compared to Braswell: Booting ------- Boot mechanism has changed. The hardware natively supports eMMC (SPI flash is supported as well) as boot media. This is done with assistance of a minuteIA block called CSE. Early after powering on this block accesses boot media and fetches 32KiB code block and puts it SRAM that is shared (read-only) with CPU. This block is mapped at the bottom of 4 GiB address space. The bootblock code is supposed to set up CAR and utilize CSE services to copy media into CAR and then continue execution in CAR. FSP 2.0 ------- Since eMMC can not be memory mapped it makes it impractical to implement 1.x spec and new FSP 2.0 is introducted. Notable differences from previous specifications: - TempRamInit and TempRamExit are now optional - Instead of big monster blob file, there are a several little bloblings called FSP-T (CAR setup, BARs, early GPIOs), FSP-M (MemoryInit) and FSP-S (SiliconInit) - Blobs are expected to be run in CAR although xip is still possible Implementation notes -------------------- This implementation uses memory-mapped SPI flash as boot media through media driver abstraction. FSP blobs and romstage are executed entirely in CAR. There is no execution-in-place. This makes it possible to add eMMC and other boot options either with CSE service or by adding driver into bootblock. We believe it also reduces complexity associated with image creation. In order to be able to run romstage in CAR and fit FSP 2.0 bootflow we had to pay extra attention in our romstage-to-ramstage transition. In essence we had to have memory caching enabled, run in the CAR and be able to teardown CAR at the same time. We did our best to find an elegant solution that would also fit nicely into coreboot boot flow model. We found it somewhat difficult to use code from older FSP 1.x driver, so we wrote new one largely from scratch. Since TempRamInit/TempRamExit are optional we build new shiny bootblock. It setups CAR, uses minimal assembly, can run C code, does not depend on blobs, comes with serial console and is pretty compact. We look forward to work on integrating these changes. Andrey Petrov on behalf on Intel CSS coreboot team.

1 0

ASUS KGPE-D16 Automated Test Failure
by Raptor Engineering Automated Coreboot Test Stand 22 Jan '16

22 Jan '16

The ASUS KGPE-D16 fails verification as of commit e9995f1469504a61ba548f29fb16dc32cf9a3dea The following tests failed: BOOT_FAILURE Commits since last successful test: e9995f1 cbfstool: Add attributes for position and alignment constraints. See attached log for details This message was automatically generated from Raptor Engineering's ASUS KGPE-D16 test stand Want to test on your own equipment? Check out https://www.raptorengineeringinc.com/content/REACTS/intro.html Raptor Engineering also offers coreboot consulting services! Please visit https://www.raptorengineeringinc.com for more information Please contact Timothy Pearson at Raptor Engineering <tpearson(a)raptorengineeringinc.com> regarding any issues stemming from this notification

2 1

Re: [coreboot] [RFC] Common license header guideline should prefer GPLv2+ over GPLv2 only
by Alex G. 22 Jan '16

22 Jan '16

On 01/22/2016 08:21 AM, Patrick Georgi wrote: > I'm uneasy > with recommending that when not strictly necessary (I'd consider a > project that's based on "or later" licensing to be such a case). I'm not sure if you mean "something I'm uneasy about", or "an example I'd consider" when you say "project that's based on 'or later'". u-boot is v2+. Does that count? Alex

2 1

[RFC] Common license header guideline should prefer GPLv2+ over GPLv2 only
by Alex G. 22 Jan '16

22 Jan '16

I think this would be a good move for interoperability, so that GPLv3 projects (e.g. SeaBIOS) may take code from coreboot where needed (e.g. device drivers). I'm strictly talking about listing the preferred license; it's still up to contributors whether they want v2 or v2+. [1] Listed GPLv2+ as preferred, but it was recently changed without any explanation. Stefan, do you have more details on that? Alex [1] https://www.coreboot.org/Development_Guidelines#Common_License_Header

2 2

ASUS KFSN4-DRE Automated Test Failure
by Raptor Engineering Automated Coreboot Test Stand 22 Jan '16

22 Jan '16

The ASUS KFSN4-DRE fails verification as of commit 9cfb40adb72b34d55e8eee70f54152ca942810cf The following tests failed: DMESG_ACCESS_FAILURE ACPI_DSDT_ACCESS_FAILURE ACPI_SSDT_ACCESS_FAILURE Commits since last successful test: See attached log for details This message was automatically generated from Raptor Engineering's ASUS KFSN4-DRE test stand Want to test on your own equipment? Check out https://www.raptorengineeringinc.com/content/REACTS/intro.html Raptor Engineering also offers coreboot consulting services! Please visit https://www.raptorengineeringinc.com for more information Please contact Timothy Pearson at Raptor Engineering <tpearson(a)raptorengineeringinc.com> regarding any issues stemming from this notification

1 0

ASUS KFSN4-DRE (K8) Automated Test Failure
by Raptor Engineering Automated Coreboot Test Stand 22 Jan '16

22 Jan '16

The ASUS KFSN4-DRE (K8) fails verification as of commit 9cfb40adb72b34d55e8eee70f54152ca942810cf The following tests failed: DMESG_ACCESS_FAILURE ACPI_DSDT_ACCESS_FAILURE ACPI_SSDT_ACCESS_FAILURE Commits since last successful test: 9cfb40a skylake mainboards: Enable CONFIG_VBOOT_EC_SLOW_UPDATE 1249f05 intel/fsp1_1: Fix for passing VBT when vboot requests it 6324de1 vboot2: Handle slow EC SW sync and graphics driver loading See attached log for details This message was automatically generated from Raptor Engineering's ASUS KFSN4-DRE (K8) test stand Want to test on your own equipment? Check out https://www.raptorengineeringinc.com/content/REACTS/intro.html Raptor Engineering also offers coreboot consulting services! Please visit https://www.raptorengineeringinc.com for more information Please contact Timothy Pearson at Raptor Engineering <tpearson(a)raptorengineeringinc.com> regarding any issues stemming from this notification

1 0

Re: [coreboot] Linux kernel as payload?
by ron minnich 21 Jan '16

21 Jan '16

I think JELTKA is a model of how it can be done. Consider talking to John Lewis. Ron, Satisfied JELTKA user. On Thu, Jan 21, 2016 at 9:58 AM Patrick Georgi via coreboot < coreboot(a)coreboot.org> wrote: > 2016-01-21 18:49 GMT+01:00 Kitestramuort <kitestramuort(a)autistici.org>: > > Can I compile it 64bit? > As long as you keep the 32bit entry point around, yes (which I think > is the default configuration for x86_64 kernels). > In kconfig/menuconfig/..., select a linux payload, and point to the > bzImage file. That should work (and this part of coreboot is pretty > well testable with our QEmu targets, in case you want to try it out > first). > > > Is there any further documentation on this? > Sadly documentation is not a strength in this project. > > > I found something on the wiki > > https://www.coreboot.org/Board:tyan/s2891#LAB_payload > The kexec information there is probably still useful, the buildrom > stuff is horribly outdated. > > > Patrick > -- > Google Germany GmbH, ABC-Str. 19, 20354 Hamburg > Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: > Hamburg > Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle > > -- > coreboot mailing list: coreboot(a)coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot

1 0

Re: [coreboot] Linux kernel as payload?
by Kitestramuort 21 Jan '16

21 Jan '16

On Thu, 21 Jan, 2016 at 4:08 PM, Aaron Durbin via coreboot <coreboot(a)coreboot.org> wrote: > > > You can always kexec() into your new kernel. The one sitting in flash > can be smart enough to interrogate your boot media and determine what > to load. Then just kexec(). > This is very interesting. So basically I should build a minimal kernel with kexec support to launch the "normal" kernel living in /boot. But what exactly needs to be compiled in the payload kernel? I guess some hardware has to be initialised at this stage... Can I compile it 64bit? Is there any further documentation on this? I found something on the wiki https://www.coreboot.org/Board:tyan/s2891#LAB_payload Thanks

4 3

Linux kernel as payload?
by Kitestramuort 21 Jan '16

21 Jan '16

Hello, I am preparing to flash coreboot on a Thinkpad X230. Currently I use UEFI and systemd to boot Linux as the only operating system and I wish to change my configuration as little as possible. The most natural option for me would be to use TianoCore as payload, however Tiano seems to be still unstable and is not particularly well documented. As an alternative I was considering using the kernel itself as payload. But what happens when I need to update the kernel? Will I need to hardware reflash coreboot with the new kernel? I wouldn't mind recompiling coreboot with a different kernel and software flashing, but I'd like to avoid having to dismantle the laptop every time I update the kernel. Can anybody clarify this for me please? best regards

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot January 2016