coreboot July 2016

coreboot@coreboot.org

47 participants
135 discussions

Thinkpad x230 video glitches during boot
by Trammell Hudson 23 Jul '16

23 Jul '16

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. https://www.youtube.com/watch?v=3BJ5qLlNTRg Or in GIF form: https://j.gifs.com/M8qkKB.gif My .config is attached. Any ideas on what might be causing it? -- Trammell

2 1

Building Coreboot on ARM
by Paul Kocialkowski 23 Jul '16

23 Jul '16

Just a quick announcement to let the community know that it is now possible to build Coreboot on ARM (including building the toolchain). I was able to produce bit-to-bit identical images from an x86 laptop and an ARM laptop, which I find pretty cool! This way, it's also possible to build Coreboot for an ARM-supported device on that same device. Cheers, -- Paul Kocialkowski, developer of low-level free software for embedded devices Website: https://www.paulk.fr/ Coding blog: https://code.paulk.fr/ Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/

1 0

New on blogs.coreboot.org: [GSOC] Panic Room, week #4/5/6
by WordPress 22 Jul '16

22 Jul '16

2 1

Fwd: X230 VGA BIOS issues
by Matthew Kirk 22 Jul '16

22 Jul '16

Hi, I know there have been threads about this before, which I have followed, but I'm still having a lot of issues getting a VGA BIOS image to work. I've extracted the VGA bios using uefitool, and I've attached both the vgabios.bin and my (non-working) .config. I honestly cannot figure out what I'm doing wrong. Flashing without the VGA bios and using native initialization seems to work fine. However, my current config just gives me a black screen. Maybe I'm doing something wrong in the config file? Really, the only thing I need with this bios is virtualization support (VMX) and VGA BIOS so I can boot graphical operating systems from usb drives. Anyone here have an X230 with VGABIOS and virtulization working on coreboot? Thanks for any help, Matthew Kirk

1 0

grub2 payload: not including additional modules
by Arian Sanusi 22 Jul '16

22 Jul '16

Hi all, I try to build coreboot-4.4 with grub2 payload for a thinkpad T420. Which largely works, but I'm unable to get it to build coreboot.rom with extra grub modules, in particular cryptodisk.mod relevant .config: > arian@jira:coreboot-4.4$ grep GRUB .config > CONFIG_PAYLOAD_GRUB2=y > CONFIG_PAYLOAD_FILE="payloads/external/GRUB2/grub2/build/default_payload.elf" > CONFIG_GRUB2_MASTER=y > CONFIG_GRUB2_EXTRA_MODULES="luks cryptodisk crypto pbkdf2 extcmd procfs archelp" (I put in the additional modules since I thought it's maybe dependency resolution, but of these crypt, pbkdf2, procfs and archelp make their way into the image, while luks, cryptodisk, and extcmd don't. There is no error. I think this is a coreboot problem since the modules themselves are getting built, I can find them in payloads/external/GRUB2/grub2/build/grub-core/cryptodisk.mod Could anyone help? Thanks and best regards, Arian

1 0

Re: [coreboot] w83627 uart port is not workable with coreboot in linux
by Nico Huber 22 Jul '16

22 Jul '16

Hi Cheng, On 22.07.2016 12:14, cheng yichen wrote: > Hi all > > My platform is braswell SOC with W83627dhg superIO. In post stage I can get > debug message over w83627 uart1(3f8/irq4). but after boot to linux, uart > port is not woarkable. I test the function by minicom but I can't receive > and send data. I can get uart information by dmesg command. > How to initial it in corebooot? You generally have to configure two things 1st the IO resources through the device tree (like src/mainboard/kontron/ktqm77/devicetree.cb lines 78..81) 2nd on an Intel chipset route these resources to LPC (you obviously already done that, as you see debug messages, but make sure no later stage in coreboot overwrites it) Hope that helps, Nico

1 0

Re: [coreboot] w83627 uart port is not workable with coreboot in linux
by Zoran Stojsavljevic 22 Jul '16

22 Jul '16

Hello Cheng, It seems from 37000 feet (commercial plane altitude) view that you do not have the following: [1] Appropriate Linux drivers for your W83627dhg superIO enabled in .config (make menuconfig options); [2] These drivers (maybe) are missing from your Linux distro; [3] If drivers are there, something fishy with these drivers, something with them is not right/correct. I have couple of questions here: [1] Which Linux distro are you using? [2] Could you attach your kernel .config file? [3] Could you attach your dmesg traces/records? Thank you, Zoran On Fri, Jul 22, 2016 at 12:14 PM, cheng yichen <blessyichen(a)gmail.com> wrote: > Hi all > > My platform is braswell SOC with W83627dhg superIO. In post stage I can > get debug message over w83627 uart1(3f8/irq4). but after boot to linux, > uart port is not woarkable. I test the function by minicom but I can't > receive and send data. I can get uart information by dmesg command. > How to initial it in corebooot? > Thank you > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot >

1 0

w83627 uart port is not workable with coreboot in linux
by cheng yichen 22 Jul '16

22 Jul '16

Hi all My platform is braswell SOC with W83627dhg superIO. In post stage I can get debug message over w83627 uart1(3f8/irq4). but after boot to linux, uart port is not woarkable. I test the function by minicom but I can't receive and send data. I can get uart information by dmesg command. How to initial it in corebooot? Thank you

1 0

QubesOS 4 hardware requirements
by Trammell Hudson 21 Jul '16

21 Jul '16

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 exception is the use of > a (properly authenticated) CPU-vendor-provided blobs for silicon and > memory initialization (see Intel FSP) as well as other internal > operations (see Intel ME). However, we specifically require all code > used for and dealing with the System Management Mode (SMM) to be > open-source. > > While we well recognize the potential problems that proprietary > CPU-vendor code can cause, we are also pragmatic enough to realize > that we need to take smaller steps first, before we can implement > even stronger countermeasures such as the stateless laptop I > proposed a few months ago. A switch to open source boot firmware is > one such very important step on this roadmap. > > Of course, to be compatible with Qubes OS, the BIOS must properly > expose all the VT-x, VT-d, and SLAT functionality that the > underlying hardware offers (and which we require). Among other > things, this implies proper DMAR ACPI table construction. -- Trammell

1 0

Re: [coreboot] ARM Trusted Firmware build issue
by Stefan Reinauer 21 Jul '16

21 Jul '16

* Martin Roth <gaumless(a)gmail.com> [160713 16:57]: > We can't roll the entire toolchain back to binutils 2.25 because of > the RISC-V work. Is it reasonable to roll back to binutils 2.25 for > just the ARM toolchain builds? No, that is not feasible. The cross toolchain builder has seen a fair amount of bloat already in the last couple of months. Let's fix this in ARM TF. Stefan

2 1

← Newer
1
...
5
6
7
8
9
10
11
...
14
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot July 2016