[coreboot] Re: Question how to write protect flash

There are several ways to lock the flash. Two are "permanent": * Flash descriptor permission bits in the IFD * SPI flash chip non-volatile Block Protect Bits and grounding the !WP pin The IFD in the image that you're going to flash can be modified with ifdtool. I'm not sure of the best way to

Re: [coreboot] gRT->SetVariable ACCESS DENIED error

On July 3, 2018 5:23 AM, Toan Le manh wrote: > I'm facing the Status EFI_ACCESS_DENIED when using gRT->SetVariable() method. > > There is no description of this returned status forSetVariable()  in UEFI > spec. It looks like the SmmVariableHandler can return EFI_ACCESS_DENIED, even though it

[coreboot] ifdtool change layout and density simultaneously

I just noticed that ifdtool doesn't work correctly if the layout and density are changed simultaneously: % ./coreboot-4.6/util/ifdtool/ifdtool -n /tmp/layout.txt -D 16 /tmp/test.rom File /tmp/test.rom is 8388608 bytes The image has changed in size. The old image is 8388608 bytes. The new image is

Re: [coreboot] Fwd: POST cards, I/O ports and M.2 to MiniPCIe

On Tue, Apr 03, 2018 at 06:32:07PM +0300, Kyösti Mälkki wrote: > [...] > > I'm dealing an early bring-up problem on a modern architecture without > > serial ports and wondering if that would a good way to debug it. > > Probably M.2 is not very useful for you... try to look for LPC > signals, some

[coreboot] POST cards, I/O ports and M.2 to MiniPCIe

How soon after reset are port 0x80 messages available on a MiniPCIe attached POST card? And would the POST card be expected to work with a M.2 to MiniPCIe adapter? How is the ISA bus' I/O address space mapped to PCIe devices? I'm dealing an early bring-up problem on a modern architecture

[coreboot] inteltool and sys/io.h

When cross compiling inteltool with musl-libc the header is not included due to this test in inteltool.h: #if defined(__GLIBC__) #include #endif Unfortunately I'm not sure what the right test is here, since the musl libc team is opposed to having a __MUSL__ define:

Re: [coreboot] Server systems shipped with coreboot

On Tue, Jan 16, 2018 at 07:29:18PM +0100, Carl-Daniel Hailfinger wrote: > [...] > At 34C3 I was told by someone that a major vendor has been shipping > servers with coreboot without announcing this, and I unfortunately > neither remember the server model nor who told me about this. Hi,

[coreboot] History question: which LLNL clusters used LinuxBIOS?

Which of the LLNL clusters used LinuxBIOS? This page doesn't mention it: https://computing.llnl.gov/tutorials/linux_clusters/ Based on the LinuxNetworx slides, I know that MCR did and reached #3 on the top500. Did any of the others? -- Trammell -- coreboot mailing list:

Re: [coreboot] a blast from the past

On Sat, Oct 28, 2017 at 01:27:17PM +, ron minnich wrote: > 2005, los alamos, a talk on EFI I had forgotten I had done. > https://www.coreboot.org/images/d/d1/Openefi.pdf > relevant to the current era. I believe you could give that talk today with almost zero changes... Jethro Beekman's

Re: [coreboot] Recommendation for Flashing Clips / mass order

On Wed, Oct 18, 2017 at 07:27:50PM -0400, [799] via coreboot wrote: > I like that idea, I think I'll just choose a cheap one and in case it > breaks I just use another one. I've tried the really cheap ones and found that they do not work very well at all. Even brand new this one required

Re: [coreboot] Recommendation for Flashing Clips / mass order

On Wed, Oct 18, 2017 at 03:22:44PM +, Peter Stuge wrote: > [...] > I usually wire a small pin header to the flash chip on mainboards > that I want to do development on. Check out the Lenovo X3550-M5 mainboard: https://www.flickr.com/photos/osr/37497785771/in/photostream/lightbox/ ZIF socket

Re: [coreboot] Recommendation for Flashing Clips / mass order

On Wed, Oct 18, 2017 at 12:35:11PM +, Peter Stuge wrote: > [...] > These clips are test tools for occasional use, not development tools. Do you have a recommendation on better clips? The Pomona seems to last for a few months due to my above average number of clips. The 3M is much worse and

Re: [coreboot] USB problem with Haswell+LynxPointLP motherboards

On Tue, Oct 10, 2017 at 02:44:02PM +, ron minnich wrote: > [0.376881] ACPI Error: Hardware did not enter ACPI mode > (20160831/evxfevnt-113) > > is this the step where it tries to do an outb to 0xb2 to tell smm we are > taking over? Yes, it looks like it is attempting to write to 0xB2:

Re: [coreboot] USB problem with Haswell+LynxPointLP motherboards

On Mon, Oct 09, 2017 at 07:55:34PM -0700, Julius Werner wrote: > My gut feeling would be to blame ACPI. The Linux patch is about > caching a host controller register in the kernel, and in some cases > (e.g. ehci_reset()), the patch re-reads the cached version from the > hardware whereas the

Re: [coreboot] USB problem with Haswell+LynxPointLP motherboards

On Mon, Oct 09, 2017 at 12:58:25PM +0300, Аладышев Константин wrote: > I try to port coreboot on boards with Haswell CPU and Lynxpoint LP chipset > (IBASE IB908AF-4650 board, DFI HU968) and I've encountered a strange > problem. USB devices stop working shortly after OS boot (or after USB device >

Re: [coreboot] Suggestions for efficient development setup for Google Chromebooks

On Mon, Oct 02, 2017 at 05:02:40PM -0700, Vadim Bendebury wrote: > note that this debug header is going away in new Chrome OS designs. Its > functionality is going to be provided by the closed case debugging (aka > CCD) facility, where authorized user using a special debug cable can gain > access

[coreboot] Moving the command line for Linux kernel payloads

A minor installation improvement that I've found is to rearrange the Linux kernel command line to be last segment in the payload. This allows me to tweak boot time parameters without having to re-write the entire kernel and initrd in the flash. Is there a current or historical reason for the

Re: [coreboot] Anybody going to SHA hacker camp?

On Tue, Aug 01, 2017 at 06:47:18PM +0200, Nico Huber wrote: > On 01.08.2017 12:13, Nico Rikken wrote: > > Is anybody of the Coreboot community going to the SHA hacker camp the > > coming weekend? [...] > > I'll be there. Though, haven't organized anything but a train ticket > yet. You can ping me

Re: [coreboot] About Paging, Realmode and what is going on

On Tue, Aug 01, 2017 at 02:49:27PM +, Peter Stuge wrote: > Philipp Stanner wrote: > [...] > > * Why does every modern CPU still start in RM? > > Many industries run on DOS. Many system developers have created > in-house BIOS extensions. x86 will never fully lose its 16-bit legacy. And, just

[coreboot] REcon MTL 2017 talk on coreboot

Yuriy Bulygin and Oleksandr Bazhaniuk's coreboot presentation at REcon Montreal 2017: https://recon.cx/2017/montreal/resources/slides/RECON-MTL-2017-DiggingIntoTheCoreOfBoot.pdf They recap the MMIO BAR issue (previously disclosed at REcon Brussles), and identified two new vulnerabilities

[coreboot] kexec --reset-vga from an inteldrmfb frame buffer

When I have my coreboot payload Linux kernel setup a console framebuffer and then kexec into Xen + another kernel, the video glitches out quite a bit before falling back to text mode. The kexec --reset-vga option doesn't seem to have any effect. I read in the docs that kexec and framebuffers

Re: [coreboot] question on SMM

You can reduce the window of time that the flash is writable by setting the PRR registers and FLOCKDN bits before moving out of the bootblock -- this prevents even SMM from being able to write to the protected regions of the flash. If someone can get code execution in the bootblock or during S3

Re: [coreboot] Bootguard signing keys

On Thu, May 11, 2017 at 9:56 AM, Trammell Hudson <hud...@trmm.net> wrote: > Unlike the few startup ACM images that I've looked at have the same > public key for their signature, despite being on very different > CPU models and from different IBV. On Thu, May 11, 2017 at 10:30:48

Re: [coreboot] : AMT bug

On Thu, May 11, 2017 at 10:08:12PM +0200, Igor Skochinsky wrote: > TH> On Thu, May 11, 2017 at 10:30:48AM -0500, Allen Krell wrote: > >> [...] There are multiple keys > >> > >> ME - public/private key pair - Fused in by Intel and checked by Intel > >> silicon - Probably different across models >

Re: [coreboot] : AMT bug

On Thu, May 11, 2017 at 10:30:48AM -0500, Allen Krell wrote: > [...] There are multiple keys > > ME - public/private key pair - Fused in by Intel and checked by Intel > silicon - Probably different across models > > BIOS_ACM - public/private key pair - Fused in by Intel and checked by Intel >

Re: [coreboot] coreboot Digest, Vol 147, Issue 17

On Thu, May 11, 2017 at 07:01:47AM -0500, Allen Krell wrote: > One thing I am still confused about is the relationship between Intel Boot > Guard and the regions of flash. My understanding is that Boot Guard only > applies to the legacy BIOS region of flash, not the ME/AMT region. It seems to be

Re: [coreboot] kernel payload

On Mon, May 08, 2017 at 06:11:52PM -0400, Healer64 via coreboot wrote: > So the question still remains as to how big the initrd image will be > assuming it has to have the necessities to mount root on lvm encrypted > drive. Any idea? The Heads Linux runtime can mount lvm encrypted drives (along

Re: [coreboot] Remote security exploit in all 2008+ Intel platforms

On Mon, May 01, 2017 at 10:44:45PM +, ron minnich wrote: > On Mon, May 1, 2017 at 1:17 PM Rene Shuster > > Yes Puri.sm has been debunked. > > I disagree. I've seen the systems. From what I can see, Puri.sm has made a > good faith effort to go as far possible *with

Re: [coreboot] Remote security exploit in all 2008+ Intel platforms

On Mon, May 01, 2017 at 05:13:10PM +0100, Sam Kuper wrote: > Has anyone here got a link describing or including the fix, either > directly from Intel, or from an OEM? Intel just posted one: https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00075=en-fr -- Trammell -- coreboot

Re: [coreboot] ThinkPad X230 alternative flash chips?

4 MB was quite limiting and it seemed like an artificial restriction, especially since all the other machines have larger space available. Since flashing both chips with an external programmer is a bit of a pain, there is still a 4 MB version built with just flashrom and the USB drivers. So you

[coreboot] Retrieving additional payload files from CBFS

Is there an easy way for a running payload to extract additional files from its CBFS image in ROM? I'd like to have a reproducible kernel and initrd as the primary payload, with user data (and keys) stored in a separate payload section of the CBFS. On the build host I can use cbfstool to

Re: [coreboot] VGA and Graphics

On Sun, Apr 02, 2017 at 09:18:10AM -0700, Todd Weaver wrote: > [...] > One of the three reasons we are including TPM in hardware is because of > your great talk at 33c3 on Heads! I'm glad to hear that it inspired you to include it! > But I failed to see that it offered "boot menu type thing"

Re: [coreboot] VGA and Graphics

On Sat, Apr 01, 2017 at 07:43:40PM +, ron minnich wrote: > Annnd with the linux payload we're back to linuxbios :-) It was a good idea in 1999, and it is still a good idea. > For a payload chooser and such I can offer two options: > 1) petitboot has a boot menu type thing > 2) u-root

[coreboot] Intel ME and the onboard e1000e

As a very belated data point to disabling the ME on the x230, it appears that it also disables the e1000e wired ethernet. The Linux kernel's ich8lan.c file reports an error that "No valid NVM bank present" and won't bring up eth0 if the ME has been flashed with a minimal firmware. Since the ME

[coreboot] cbfstool and initrd.cpio.xz

I was having a problem with adding compressed initrd images to my Linux payload with cbfstool. What I noticed is that if I build my initrd.cpio file and compress/link it into the bzImage via the Linux kernel's .config file, the kernel starts up just fine and executes out of the initrd.

[coreboot] PCI BAR attacks on SMM at RECon Brussels

Intel ATR presented "Baring the system: New vulnerabilities in SMM of coreboot and UEFI based systems" at RECon Brussels last month: https://recon.cx/2017/brussels/talks/baring_the_system.html The slides are online now:

Re: [coreboot] Passing CFLAGS to coreboot make (and reproducible builds)

On Thu, Feb 02, 2017 at 09:10:09PM +0100, Patrick Georgi via coreboot wrote: > coreboot is normally reproducible: > https://tests.reproducible-builds.org/coreboot/coreboot.html Hmm. I must have messed up someting in my earlier tests (maybe they ran without BUILD_TIMELESS=1?). You're right; the

Re: [coreboot] Passing CFLAGS to coreboot make (and reproducible builds)

On Thu, Feb 02, 2017 at 08:55:56PM +0100, Zoran Stojsavljevic wrote: > > Is there a right way to pass additional compiler flags to the coreboot > > makefiles? We've been working on making the Heads firmware reproducible > > and found that the -fdebug-prefix-map option is necessary to deal with >

[coreboot] Passing CFLAGS to coreboot make (and reproducible builds)

Is there a right way to pass additional compiler flags to the coreboot makefiles? We've been working on making the Heads firmware reproducible and found that the -fdebug-prefix-map option is necessary to deal with different build directories. To make this work with coreboot we ended passing in

Re: [coreboot] Fund a TALOS Secure Workstation as coreboot build system

On Tue, Jan 17, 2017 at 02:24:16PM -0600, Timothy Pearson wrote: > [...] > Regarding the BMC work, we're looking to enable a fully libre BMC on the > KGPE-D16. This is a complex process involving significant reverse > engineering efforts, writing new kernel drivers for the BMC, etc. With > the

Re: [coreboot] [Resend] Tapping into the core (33C3)

On Mon, Jan 16, 2017 at 04:40:33PM +0100, Denis 'GNUtoo' Carikli wrote: > [...] > As I understand from the slides DCI can be activated trough: > - The flash descriptor > - UEFI > - The P2SB register Aren't there two different things being discussed here? There is DCI, which requires BIOS or

[coreboot] Trusting coreboot versus trusting the FSP

At 33c3 a question came up about "how can we trust and audit coreboot?" compared to things like the Intel Firmware Support Package (FSP). I'm relaying it to the list for discussion. The FSP is a x86 binary blob that has an init function that writes magic values to magic registers to bring up the

Re: [coreboot] Building 4.5 from release sources

On Thu, Jan 05, 2017 at 06:34:42AM -0700, Trammell Hudson wrote: > When I build coreboot 4.5 from the release sources it is necessary > to download the coreboot-blobs-4.5.tar.xz file and it looks like there > might be a dependency now on the 3rdparty/vboot tree as well since > cbf

[coreboot] Building 4.5 from release sources

When I build coreboot 4.5 from the release sources it is necessary to download the coreboot-blobs-4.5.tar.xz file and it looks like there might be a dependency now on the 3rdparty/vboot tree as well since cbfs.h includes vb2_api.h:

Re: [coreboot] coreboot assembly at 33c3

Is the position on the wiki accurate? It has a warning that makes it sound like the location has not been set. On Tue, Dec 27, 2016 at 05:19:28AM +0100, Zaolin wrote: > Hall 4 (Chaos West Assembly Hackcenter) towards hall 3. > > > On 12/27/2016 05:16 AM, Jonathan Neuschäfer wrote: > > On Tue,

[coreboot] coreboot assembly at 33c3

Does the coreboot assembly have a location at 33c3 yet? I want to include a pointer to it in my slides for my talk on Tuesday -- Trammell -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] TPM device has gone missing

On Mon, Dec 12, 2016 at 03:08:53PM -0600, Aaron Durbin via coreboot wrote: > What about the SSDT? With the patch I think the device is in the SSDT > -- not DSDT. Whups, forgot to include it. There is far less change: --- ./no-tpm/SSDT.dsl 2016-12-12 17:23:51.314355365 -0500 +++

Re: [coreboot] TPM device has gone missing

On Mon, Dec 12, 2016 at 01:14:58PM -0600, Aaron Durbin via coreboot wrote: > Can you provide the isal -d dumps of before and after for your board? > I think in one they'll be in SSDT and the other in DSDT. They should > reside in /sys/firmware/acpi/tables/ that you can copy them and run > them

Re: [coreboot] TPM device has gone missing

On Mon, Dec 12, 2016 at 11:37:30AM -0700, Trammell Hudson wrote: > My x230's TPM has gone missing somewhere between 4.5 and the current head. > CONFIG_LPC_TPM is still set, but neither coreboot nor the Linux payload > detects it. Based on a tip, I reverted this patch: https://review.cor

[coreboot] TPM device has gone missing

My x230's TPM has gone missing somewhere between 4.5 and the current head. CONFIG_LPC_TPM is still set, but neither coreboot nor the Linux payload detects it. Bisecting will take a while since it requires reflashing; does anyone know where it might have gone? -- Trammell -- coreboot mailing

Re: [coreboot] Linux 4.7 kernel payload with CoreBoot 4.4

On Wed, Aug 10, 2016 at 07:03:58AM -0600, Trammell Hudson wrote: > The Linux 4.7 kernel payload crashes early in the boot process > with CoreBoot 4.4. [...] The recently released 4.9 kernel does not require any patches to boot as coreboot's payload. The diffs in head_64.S appear to be r

Re: [coreboot] latest greatest thinkpad with coreboot

On Thu, Dec 01, 2016 at 11:20:00PM +, ron minnich wrote: > If people are trying native graphics init I still think it's worth trying > the SPARK stuff from nico at least once. I'm intrigued by the use of Ada and excited about applying more formal methods as well as safer languages to the

Re: [coreboot] latest greatest thinkpad with coreboot

On Thu, Dec 01, 2016 at 06:50:13PM +0100, Klemens Nanni wrote: > On Thu, Dec 01, 2016 at 05:04:36PM +, ron minnich wrote: > >what's the latest best one? [...] > > X230 if you'd ask me: 16G RAM, 12M ROM. runs fine with reduced (830K) ME You can also retrofit the proper x220 keyboard into the

Re: [coreboot] your preferred method for supplying power to chip for RPi spi flashing?

On Thu, Dec 01, 2016 at 01:15:59PM +, Peter Stuge wrote: > Michael Carbone wrote: > > I have been attempting to use a raspberry pi for spi flashing and when I > > use the 3.3v pin the raspberry pi doesn't power up as the chip draws too > > much power through the 3.3v pin for the raspberry pi

Re: [coreboot] Rettungsboot

On Sun, Nov 27, 2016 at 07:30:07PM -0500, Charlotte Plusplus wrote: > [...] > With the amount of flash we have, sharing the kernel and initrd doesn't > seem like a bad idea. The problem is if a bad kernel or initrd is flashed then there is no way to recover without hardware intervention. Having

Re: [coreboot] Rettungsboot

On Sat, Nov 26, 2016 at 10:46:33PM +, ron minnich wrote: > [...] > Every bootloader starts simple, and becomes an OS. Every single one starts > with the intent of being small and compact and only supporting some needed > subset of file systems/devices/protocols and ends up implementing >

Re: [coreboot] using overlayfs to have several coreboot dev envs

On Sun, Nov 20, 2016 at 08:20:51PM +, ron minnich wrote: > [...] > There's also no fundamental reason for using the name .config other than > tradition. We could, for example, create > build/vendor/mainboard/config and use that. One minor concern with that placement is that I enjoy the

Re: [coreboot] using overlayfs to have several coreboot dev envs

On Sun, Nov 13, 2016 at 03:34:49PM -0500, Charlotte Plusplus wrote: > With the cross compiling tool chain, coreboot takes 1G. If you are a bit > short on space, or if you want to save writes to your SSD, instead of > having multiple copies of the coreboot source folder, I have found out >

Re: [coreboot] Support for student project

On Sun, Nov 20, 2016 at 01:08:30AM +, Peter Stuge wrote: > [...] > Given your focus on USB, a Linux payload with custom initramfs is > especially interesting. Tobias -- I've been working on building a Linux payload with a focus on how to integrate with the TPM and other security research.

Re: [coreboot] More experiments with disabling the ME

fficial (Lenovo or > other) bios is very interesting because it extends also to hardware not > supported by coreboot, and probabily to CPUs newer than Ivy Bridge > (Trammell Hudson tested it on a Skylake mobile CPU > https://www.coreboot.org/pipermail/coreboot/2016-November/082335.html) Th

Re: [coreboot] More experiments with disabling the ME

On Fri, Nov 04, 2016 at 09:20:24PM +, Nicola Corna wrote: > [...] > * Sandy Bridge accepts an Intel ME firmware with just the FTPR partition, > both > with and without a valid FPT (the partition table of the Intel ME image). > The system doesn't power off after 30 minutes, and the ME

Re: [coreboot] Petitboot based bootloader

On Wed, Oct 26, 2016 at 03:18:44AM +0200, Arthur Heymans wrote: > I have been working on building a Petitboot, a kexec bootloader, [0] > based Linux payload using the Buildroot build system to produce a nice > bzImage that contains both linux and the initrd. It is inspired by the > Raptor

[coreboot] Fixing payload address

I'm working with a fairly large Linux payload in my coreboot image and one of my targets (the x230) has two separate ROM chips. I'd like to have the top 4 MB SPI flash reserved for coreboot (bootblock, romstage, ramstage, mrc, etc) and the bottom 8 MB chip just for Linux. Most of my changes now

[coreboot] Firmware image with Intel Bootguard enabled?

Does anyone have one of the Thinkpads with Bootguard enabled that prevented coreboot installation? I'm interested in poking at the full firmware image (including the ME region) to verify my understanding of how it is implemented. -- Trammell -- coreboot mailing list: coreboot@coreboot.org

Re: [coreboot] Skylake ME power down mitigation timer

On Wed, Oct 12, 2016 at 10:08:38AM -0700, Duncan Laurie wrote: > I wouldn't read too much into the data in there, it turns out the ME > release that added this output detail (which we shipped in this device) > also got it wrong so the data is not reliable. Interesting. Do you mean the ME

[coreboot] Skylake ME power down mitigation timer

Does anyone have experience with how long the Management Engine's "Power Down Mitigation" timer is on Skylake? My Chell Chromebook with modified ME firmware reports this on bootup / S3 resume: ME: FW Partition Table : BAD ME: Bringup Loader Failure : YES ME: Firmware Init Complete : YES

Re: [coreboot] Skylake S3 resume failure (without relocatable ramstage)

On Mon, Oct 10, 2016 at 09:40:49AM -0600, Trammell Hudson wrote: > [...] > I filed an issue on the tracker related to the ramstage problem > and am trying to debug it with Aaron: > > https://ticket.coreboot.org/issues/78 And it appears to be a bug of my own creation...

[coreboot] Skylake S3 resume failure (without relocatable ramstage)

When my Skylake system comes out of S3 it fails to resume and ends up going back through the normal boot path. Console output durng resume: coreboot-4.4-1781-g2fcabb8-heads Wed Oct 5 01:45:23 UTC 2016 ramstage starting... FSP_INFO_HEADER not set! Enumerating buses... Enabling Common Clock

[coreboot] IOMMU on Skylake / Chell?

I've successfully built a coreboot firmware and Linux bootloader payload for the Chell Chromebook with Skylake, which then kexec's Xen / Qubes from the eMMC. Both of them are reporting that the IOMMU is not in use, and there is no DMAR entry in the ACPI table, which I believe is what they are

Re: [coreboot] Servo debug uart in Linux?

On Thu, Oct 06, 2016 at 11:27:01AM -0700, Duncan Laurie wrote: > I may be mis-remembering and this might come up as ttyS0 in linux for > skylake. (it is ttyS2 on apollolake...) Or just use a custom command line > like console=uart,mmio32,0xd1134000,115200n8 That commandline doesn't produce any

[coreboot] Servo debug uart in Linux?

Is it possible to use the Skylake Servo debug UART in Linux or Xen? It doesn't show up as a normal 16550 (setserial reports "uart type unknown"), which is making debugging the payload kernel a little frustrating. I've added lots of "outb $0x80" calls to trace the Xen hypervisor and have figured

Re: [coreboot] Skylake FSP 1.1 without verstage?

On Thu, Oct 06, 2016 at 01:33:53AM +0200, Zaolin wrote: > Could you please submit a bug report at ticket.coreboot.org for that issue. There seem to be two separate issues (infinite loop in romstage, fault in relocatable ramstage): https://ticket.coreboot.org/issues/77

Re: [coreboot] Skylake FSP 1.1 without verstage?

On Wed, Oct 05, 2016 at 03:19:11PM -0500, Aaron Durbin wrote: > On Wed, Oct 5, 2016 at 3:08 PM, Trammell Hudson <hud...@trmm.net> wrote: > > CBFS: 'Master Header Locator' located CBFS at [a00100:c0) > > CBFS: Locating 'fallback/ramstage' > > CBFS: Fou

Re: [coreboot] Skylake FSP 1.1 without verstage?

On Wed, Oct 05, 2016 at 01:59:08PM -0500, Aaron Durbin wrote: > > Does the car stage code exist somewhere else in the tree? > > Try this? [...] > > -romstage-$(CONFIG_SEPARATE_VERSTAGE) += romstage_after_verstage.S > +romstage-y += romstage_after_verstage.S That works to make it past the

[coreboot] Skylake FSP 1.1 without verstage?

On Skylake with no verstage and FSP 1.1 there is no car_stage_entry function, only a weak symbol with an infinite loop in src/arch/x86/assembly_entry.S, and as a result coreboot hangs after jumping into the romstage. There is one defined in src/soc/intel/skylake/romstage/car_stage.S, but this is

Re: [coreboot] Experiments with disabling the ME on Sandybridge x230

Zoran -- Thanks for your insights on the ME. It's quite a messy bit of HW and it makes no sense to me why Intel has it shrouded in such secrecy. There is no reason that I can see for it to be undocumented. > [...] > Link to the very useful presentation (I clipped the above figure): >

Re: [coreboot] Experiments with disabling the ME on Sandybridge x230

On Mon, Sep 12, 2016 at 09:27:18PM +, Peter Stuge wrote: > Trammell Hudson wrote: > > I've experimented with clearing additional bits, from 0x3000 to 0x1 > > with the same results. If I were really motivated I might binary search > > how much of the firmware it nee

Re: [coreboot] weird problem with KGPE-D16

On Tue, Sep 13, 2016 at 11:43:08PM +, ron minnich wrote: > I've been trying to find a problem in linux that makes it not boot when > used as the payload in the KGPE-D16. The symptom is that I get no output at > all on serial when linux starts. That sounds related to the decompression problem

Re: [coreboot] Experiments with disabling the ME on Sandybridge x230

On Mon, Sep 12, 2016 at 07:11:41PM +, Peter Stuge wrote: > [...] It would be interesting to find out more about > the state of the ME in this case. Maybe the cleared section isn't part > of it's firmware, or maybe it really doesn't care, though that would > surprise me. The $FPT has pointers

Re: [coreboot] Experiments with disabling the ME on Sandybridge x230

On Mon, Sep 12, 2016 at 06:13:16PM +, Peter Stuge wrote: > > If I just erase the first 4KB of its region (0x3000, starts with "$FPT"), > > coreboot boots up fine and reports that "WARNING: ME has bad firmware". > > My Linux payload initializes without any complaints. > > Does it stay

[coreboot] Experiments with disabling the ME on Sandybridge x230

I'm experimenting with what happens if I remove the ME firmware from from the lower SPI flash chip on my Thinkpad x230. If I just erase the first 4KB of its region (0x3000, starts with "$FPT"), coreboot boots up fine and reports that "WARNING: ME has bad firmware". My Linux payload initializes

Re: [coreboot] How is CONFIG_TPM selected?

On Mon, Aug 15, 2016 at 03:54:49PM -0700, Julius Werner wrote: > I think the answer is that CONFIG_TPM doesn't do anything by itself > (it just compiles extra libraries that offer functions to access > TPMs), so there's no point in selecting it directly from menuconfig. > Any feature that uses the

[coreboot] How is CONFIG_TPM selected?

Is it possible to enable CONFIG_TPM with the current head in git? On my Lenovo x230, CONFIG_MAINBOARD_HAS_LPC_TPM is selected, as is CONFIG_LPC_TPM, but there does not appear to be any way to enable CONFIG_TPM in menuconfig. In order to enable it, I had to change src/Kconfig to default to y.

Re: [coreboot] Measuring the bootblock and adding a verstage

On Thu, Aug 11, 2016 at 05:00:00PM +0200, Zaolin wrote: > The whole TPM stack needs to be reworked until it can used for a > measured boot. Is it necessary to import the entire complexity of TSS for the measured boot task of hashing the various components? Once the Linux payload starts up it can

[coreboot] Measuring the bootblock and adding a verstage

I'd like to add a tlcl_measure() function to hash a region of code and extend a PCR with the result. I see that the Chromebook systems use a verstage that links in src/lib/tlcl.c and there are sha1 functions in 3rdparty/chromeec/common/sha1.c, but neither of these are available from the romstage

[coreboot] Linux 4.7 kernel payload with CoreBoot 4.4

The Linux 4.7 kernel payload crashes early in the boot process with CoreBoot 4.4. I traced it to these instructions that are finding a safe spot to decompress the rest of the kernel and patched around it with a hard coded location: diff -u --recursive

[coreboot] buildgcc certs and signature hashes

It looks like the util/crossgcc/buildgcc script disables HTTPS cert checks and doesn't have a way to verify the signatures or hashes of the files that it receives. download_showing_percentage() { url=$1 printf " ..${red} 0%%" wget --no-check-certificate $url 2>&1 | while

Re: [coreboot] initrd in 4.4 versus head

On Thu, Jul 28, 2016 at 10:04:56PM +0200, Stefan Reinauer wrote: > * Trammell Hudson <hud...@trmm.net> [160727 13:58]: > > It looks like 4.4 is adding the initrd as a separate section > > named "(empty)" with type "null" and the kernel can't find

[coreboot] initrd in 4.4 versus head

I see a difference in the way 4.4 handles initrd images for linux payloads versus the way it is done in head. With 4.4 my Linux kernel can not find the external initrd, so it is necessary to build it as part of the kernel. With head it works fine. It looks like 4.4 is adding the initrd as a

Re: [coreboot] kexec of Xen hypervisor from a Linux payload

On Tue, Jul 26, 2016 at 02:48:42PM -0400, Ward Vandewege wrote: > Oh, wow, thank you! Sorry that I didn't spend time tracking that down > properly back in 2008. I'd be interested to know if Xen takes the patch. Thank *you* for isolating it to the change between 3.1.0 and 3.1.3 so many years ago.

Re: [coreboot] kexec of Xen hypervisor from a Linux payload

On Tue, Jul 26, 2016 at 09:37:20AM -0600, Trammell Hudson wrote: > [...] > Unfortunately 3.1.3 is ancient; I'm going to build the more modern > Xen 4.6.x to see if I can repeat these fixes to boot into Qubes. This required a few more hacks, but it works now. The problem is not with

Re: [coreboot] kexec of Xen hypervisor from a Linux payload

On Mon, Jul 25, 2016 at 03:56:22PM -0600, Trammell Hudson wrote: > # There seems to be a regression with regard to kexec'ing into > # a Xen kernel between Xen 3.1.0 (confirmed working) and 3.1.3 > # (confirmed not working). I was able to reproduce this in qemu, which allowed me to debu

Re: [coreboot] kexec of Xen hypervisor from a Linux payload

On Mon, Jul 25, 2016 at 01:27:22PM -0600, Trammell Hudson wrote: > I did find this note from 2008 that mentioned a similar > issue regarding xen, kexec and coreboot: > > http://ward.vandewege.net/blog/2008/08/kexecing-into-a-xen-kernel/ Following the links to the xen-devel mailing l

Re: [coreboot] Thinkpad x230 video glitches during boot

On Mon, Jul 25, 2016 at 05:30:07PM +, ron minnich wrote: > [...] I'm starting to worry about my toolchain. My build machine is a stock Ubuntu 15.10: diamond:~/build/coreboot: gcc -v -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper

Re: [coreboot] kexec of Xen hypervisor from a Linux payload

On Mon, Jul 25, 2016 at 02:42:11PM +0200, Zoran Stojsavljevic wrote: > [...] > *Probably some module required for your baremetal fedora is missing > in initramfs. First of all, remove "quiet" option to receive more > details. If that's about missing module, you can regenerate initramfs: The

[coreboot] kexec of Xen hypervisor from a Linux payload

I've successfully built a 4.6.4 Linux kernel payload for CoreBoot and flashed it onto the top 4 MB of the boot ROM on my Thinkpad x230. The runtime is a dynamic linked busybox with glibc, as well as a copy of the kexec binary from my Ubuntu laptop. kexec of a xen kernel (multiboot-x86) results in

Re: [coreboot] Thinkpad x230 video glitches during boot

On Sun, Jul 24, 2016 at 06:42:42PM +, ron minnich wrote: > [...] I'm hitting one problem: I need to get a working > 4.7.0 kernel as a payload. I have a 3.18 working fine, as > payload, but the 4.7.0 never puts out any serial output. > If you have a 4.x.+ kernel config that works as a payload,

Re: [coreboot] Thinkpad x230 video glitches during boot

On Sat, Jul 23, 2016 at 08:27:17PM +, ron minnich wrote: > I"m assuming this is native graphics? That's sometimes a sign that the > graphics hardware can't get to memory for an image, either due to the page > remapping on the graphics hardware being wrong or maybe BME is not set on > the

[coreboot] Thinkpad x230 video glitches during boot

I've built CoreBoot from git and flashed it onto an x230 running Qubes. It works great, once things are up and running (and after I re-assigned the PCI devices to the sys-net vm). However, during startup it produces pretty crazy video glitches that some would call a feature.

[coreboot] QubesOS 4 hardware requirements

Exciting news from the team at Qubes: https://www.qubes-os.org/news/2016/07/21/new-hw-certification-for-q4/ > Another important requirement we’re introducing today is that > Qubes-certified hardware should run only open-source boot firmware > (aka "the BIOS"), such as coreboot. The only

  1   2   >