coreboot August 2015

coreboot@coreboot.org

45 participants
86 discussions

by A. Veek

3 years, 6 months

Re: [coreboot] No VGA output on e350m1 after flashing. what to do?

by Reiner Luett

Hi! On 30.06.2013 19:28, Christian Weinz wrote: > Maybe I didn't include the VGA option in the make menuconfig process. > How can I solve this problem? You need to add the VGA Option ROM (VGA BIOS -> Add VGA BIOS image). I've extracted it from the UEFI, but you also could use these: http://www.coreboot.org/index.php?title=ASRock_E350M1&oldid=11114 at the end of the page or you also may be able to use the default AMD fam14 (Persimmon) vbios. You will need to agree to the click through: http://wwwd.amd.com/support/vbioslic.nsf/userverify?openform http://www.coreboot.org/AMD_DB-FT1_PERSIMMON It's a pity, that bios_extract didn't work for now. You could use the AMI Aptio EFI MMTool with wine: http://win-lite.de/benutzer/fernando/BIOS-Tools/AMI_Aptio_EFI_MMTool_v4.50.… You need to extract OntarioEFIVbios with PCI ID 1002,9802 as Option ROM. Regards, Reiner --

4 years, 9 months

Re: [coreboot] On Intel Boot Guard

by Alexander Couzens

Hi Iru, we aren't still sure which boards use Intel Boot Guard and which doesn't use it. But we expect most board use it, because it's "recommended" by intel - as we dont recommend it. Also there isn't yet a test script for Intel Boot Guard. Can you post a link to that forum post? I would like to look into a x240 flash image. If you have such board it would be nice if you can send me a copy of the flash image via private mail. Cheers, lynxis -- Alexander Couzens mail: lynxis(a)fe80.eu jabber: lynxis(a)jabber.ccc.de mobile: +4915123277221

6 years, 2 months

Porting Libreboot to the C201 Chromebook (veyron_speedy)

by Paul Kocialkowski

Over the past week or so, I've been working to get Libreboot running on the latest ARM Chromebook: the C201, manufactured by Asus (codename veyron_speedy). The laptop is running with a RK3288 SoC and ships with Google's version of Coreboot preinstalled. It should require no proprietary code nor any proprietary firmware load or microcode update to boot, thus it would be a good fit for Libreboot, as a fully free distribution of Coreboot. In addition to that, the device's embedded controller (that handles aspects of power management as well as the keyboard and a few other things) is a microcontroller that is also running free software: the free embedded controller firmware from Google. Aside from that, it has a soldered Wi-Fi/bluetooth BCM4354 chip (cannot be removed) that has a free driver but requires to load a proprietary firmware on the chip. However, it is easy to work around that issue and not use that chip at all, e.g. using an ath9k_htc dongle on one of the two USB ports. The GPU is a Mali T764, on which Luc has been doing some early work to have free software support for it. It is uncertain[0] how long it will take to have an usable free replacement for it, but now that there is that hardware available, free graphics for Mali T GPUs would mean having a recent laptop running fully free software, down to the firmware level, without losing any major hardware feature, something that has hardly ever been achieved yet. Thus, I believe it is of the utmost importance to back Luc up on this, even if big players like ARM are trying hard to make Lima not happen and to make it difficult for Luc to keep going. Another aspect that I still have to look at in-depth is the ability to use hardware video encoding/decoding. The RK3288 has an auxiliary processor for that task, but it is unclear whether it can be used with free software or not, though the first indications that I've gathered are positive. At this point, I've been able to boot up Debian on the device, and the xfce4 interface is quite usable. It even runs big programs like Iceweasel/Firefox and LibreOffice without inconveniences. However, it cannot run desktop environments that depend on GL acceleration, such as gnome-shell, which is a shame since those would be a good fit for it. The CPU is simply too slow for offering a decent experience with software rendering (llvmpipe). Overall, I truly hope this device creates an incentive to free the last remaining parts that can only work with proprietary software to this day. Its potential would be huge, especially since it's a good fit for travellers. With the security model inherited from Chromium OS, this would be one of the safest laptops to be used by journalists or activists. If Tails was to be ported to it, it would become easy to have a secure and anonymous setup. I have successfully fixed and compiled Coreboot and all the necessary bits and pieces for the C201, so I'll be spending the next few days sending patches, discussing how to integrate it to Libreboot and getting the actual work done. I also plan on documenting all my findings (especially things like how to access UART, how to remove the SPI flash's write protect, how to reflash it externally, etc) on my coding blog, for now. Cheers! References: [0]: http://libv.livejournal.com/27461.html -- Paul Kocialkowski, Replicant developer Replicant is a fully free Android distribution running on several devices, a free software mobile operating system putting the emphasis on freedom and privacy/security. Website: http://www.replicant.us/ Blog: http://blog.replicant.us/ Wiki/tracker/forums: http://redmine.replicant.us/

6 years, 6 months

coreboot ported to the ASUS KGPE-D16 (Libreboot: blobless, fully functional!)

by Timothy Pearson

All, I have successfully ported coreboot to the relatively modern ASUS KGPE-D16 server board (dual AMD socket G34, 16 DDR3 DIMMs, https://www.asus.com/us/Commercial_Servers_Workstations/KGPED16/)! This port uses native Family 10h initialization (_not_ AGESA or CIMX). The Libreboot folks will be interested to know that this board can run blob-free and still retain full functionality! Port specifications: CPU: Dual AMD G34 Magny-Cours (Family 10h) RAM: 16 DDR3 DIMM slots with ECC support (tested with x4 4G DDR3-1333 unbuffered DIMMs) Peripherals: PCIe slots: all functional PCI slot: functional RS-232: functional PS/2: expected to function, not tested (on SuperIO) ASpeed VGA device: functional (text mode, see below) IEEE1394: functional On-board USB: functional On-board NICs: functional ASUS PIKE SAS controller: functional PCIe ROMs: functional Power management: DDR3 voltage set: functional ACPI/APIC: functional Suspend/resume: broken Other: cbmem console: partial support (log truncated) cbmem timestamps: functional nvram: functional BIOS recovery jumper: functional ASpeed VGA: The ASpeed VGA device initialises in text mode via its (new) coreboot driver, however this initialisation is incomplete, leading to distorted but quite usable VGA output. When Linux boots and engages the graphical framebuffer all distortion disappears. This port was not trivial. Almost every device used was broken and required debugging/repair, with the notable exception of the SuperIO chip. The AMD DDR3 controller was severely broken to the point where large rewrites were needed in order to bring it in line with the BKDG. Even after the various component drivers were repaired Due to the labor-intensive nature of the port and the extensive changes throughout the entire source tree, it is not economically feasible to merge this port upstream at this time (I estimate upward of 30 independent patches would be required just to get the board booting!). Raptor Engineering will, however, be continuing to maintain this port internally, and I am currently looking into adding native Family 15h support on top of this internal tree. Additionally, while it was not a priority for the initial port, I will be attempting to enable suspend/resume functionality as I have time. If there is sufficient interest from the community in adding this board to coreboot I would consider merging the changes in exchange for a one-time contract payment in the vicinity of $35,000 USD. When considering this offer please bear in mind that this is a fully functional blobless board with a wide range of peripherals and expansion options available, and that once these large changes are merged I will continue to enhance coreboot functionality as before (e.g. with the KFSN4-DRE and the T400). I would also be willing to add this board to the test stand as the only fully supported 4-way Opteron board (socket G34 Magny-Cours CPUs contain two separate CPUs in one package, making this 2-socket board a 4-way system from a HyperTransport perspective). Please let me know if you have any questions! -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 http://www.raptorengineeringinc.com

6 years, 8 months

Acer Chromebook 15 debug

by John Lewis

Hi Guys, Coolstar Organisation wants to do his Windows thang with one of the Broadwell Chromebooks, so I'm trying to build a working ROM with chromium.googlesource.com/chromiumos/third_party/coreboot/+/firmware-yuna-6… to give him a hand. Luckily USB debug works with this, so here is what I'm getting. What could I do next? Incidentally, if I flash back my backup, it goes into recovery mode now every time I boot (flags are 0x489), I've tried pulling the battery to no avail. If anyone has a trick to get around that, I'd appreciate it, as the Acer is my main machine. -⁠John. coreboot-⁠5cbe3a8-⁠dirty romstage Sun Aug 23 12:18:55 BST 2015 starting... PM1_STS: 8910 PM1_EN: 0000 PM1_CNT: 00000000 TCO_STS: 0000 0000 GPE0_STS: 1ef82df0 187d4fdf 0005f240 00000000 GPE0_EN: 00000000 00000000 00000000 00000000 GEN_PMCON: 0200 2024 520b Previous Sleep State: S5 CPU: Intel(R) Core(TM) i3-⁠5005U CPU @ 2.00GHz CPU: ID 306d4, Broadwell E0 or F0, ucode: 0000001d CPU: AES supported, TXT NOT supported, VT supported MCH: device id 1604 (rev 09) is Broadwell F0 PCH: device id 9cc5 (rev 03) is Broadwell U Base IGD: device id 1616 (rev 09) is Broadwell U GT2 CPU: frequency set to 2000 MHz SPD: index 1 (GPIO47=0 GPIO9=0 GPIO13=1) SPD: module type is DDR3 SPD: module part is HMT425S6AFR6A-⁠PB SPD: banks 8, ranks 1, rows 15, columns 10, density 4096 Mb SPD: device width 16 bits, bus width 64 bits SPD: module size is 2048 MB (per channel) Boot Count incremented to 8 ME: FW Partition Table : OK ME: Bringup Loader Failure : NO ME: Firmware Init Complete : NO ME: Manufacturing Mode : NO ME: Boot Options Present : NO ME: Update In Progress : NO ME: Current Working State : Normal ME: Current Operation State : Bring up ME: Current Operation Mode : Normal ME: Error Code : No Error ME: Progress Phase : BUP Phase ME: Power Management Event : Pseudo-⁠global reset ME: Progress Phase State : Waiting for DID BIOS message ME: HSIO Version : 8705 (CRC 0xfbc2) No FMAP found at ffe10000. FMAP: area RW_MRC_CACHE not found No MRC cache found. Starting Memory Reference Code Initializing Policy Installing common PPI MRC: Starting... Initializing Memory MRC: Done. MRC Version 2.6.0 Build 0 memcfg DDR3 clock 1600 MHz memcfg channel assignment: A: 0, B 1, C 2 memcfg channel[0] config (00780008): enhanced interleave mode on rank interleave on DIMMA 2048 MB width x16 single rank, selected DIMMB 0 MB width x16 single rank memcfg channel[1] config (00780008): enhanced interleave mode on rank interleave on DIMMA 2048 MB width x16 single rank, selected DIMMB 0 MB width x16 single rank CBMEM: root @ 7cfff000 254 entries. MRC data at ff7d0d9c 6246 bytes Relocate MRC DATA from ff7d0d9c to 7cfeb000 (6246 bytes) create cbmem for dimm information

6 years, 10 months

QEMU Q35 about Linux booting problem

by Yu-Cheng Liu

Dear all: I can boot in Linux with default machine use : qemu-system-x86_64 -bios [ Path to coreboot with FILO ] -hda [ Path to Linux image ] -nographic when I use Q35 machine : qemu-system-x86_64 *-M q35* -bios [ Path to coreboot with FILO ] -hda [ Path to Linux image ] -nographic the FILO would tell us that "IDE channel 0 not found",and not boot in Linux how can I fix this problem ? Thank you ~

6 years, 10 months

Openbiosprog-spi

by Keith Emery

G,day all I just made an order on PCB cart for the OpenBiosprog_spi. As a result of mild brain damage on my part; I went ahead and ordered 200 boards. So in light of the above I am happy to mail out as many boards as anyone might want for the low low price of $1.20 AUD plus postage. Spread the word! http://keithtronics.tictail.com/

6 years, 10 months

Re: [coreboot] From wildcat linking to exploring new languages

by Nico Huber

On 29.08.2015 21:58, ron minnich wrote: > If people feel strongly enough about this then we can do an external repo > for now. Either way around, we would have to learn how to best integrate SPARK code in coreboot. There would still be some steps to go from linking with an adalib, to SPARK beeing a first class citizen of our build system. > Nico, do you want to set up a github repo and we can work out procedures > people use to try this out? As you know I'm more interested in Muen as a > replacement for the ramstage but this is a good first step. I guess, I'll just push things to gerrit, when the code is ready. Nico

6 years, 10 months

Re: [coreboot] From wildcat linking to exploring new languages

by Peter Stuge

Ron, ron minnich wrote: > I think this could prove to be a very important new direction for coreboot, I agree. > and I still think it belongs in the tree. No way. This is a library of device drivers. It has no place whatsoever as a subdirectory lost somewhere in the already too big coreboot repository. libsparkhw needs to live in its own repository, and be pulled into coreboot as well as other consumers (e.g. FILO as Nico mentioned) as a submodule. But putting the submodule under 3rdparty isn't a great fit, because the library is very much from the 1stparty, namely from the coreboot community. So it should be somewhere else, I suggest in lib/[lib]sparkhw. License-wise, in order to be maximally compatible and reusable together with libpayload I would welcome and support a simplified BSD license. I haven't ever used Ada, but used lots of Pascal long long ago. Fun! //Peter

6 years, 10 months

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot August 2015