coreboot August 2018

coreboot@coreboot.org

43 participants
110 discussions

Optiplex 790 now has preliminary support by coreboot

by Taiidan＠gmx.com

https://review.coreboot.org/21774 In case anyone else didn't notice - It is a sandy/ivy system with IOMMU. This is great and should help get coreboot in to the corporate user world.

2 years

Re: [coreboot] Upgrade the 12 years old LZMA libraries - should we do it?

by Carl-Daniel Hailfinger

Hi Ivan, On 03.04.2018 20:03, Ivan Ivanov wrote: > I have noticed that both coreboot and seabios are using the very old > versions of LZMA SDK. True. I introduced the lzma code in coreboot (back when it was called LinuxBIOS) when we were working on OLPC XO-1 support. > If we will upgrade our LZMA libraries from the > outdated-by-12-years 4.42 to the current version 18.04 , speed and > compression ratio should improve and maybe a few bugs will be fixed. Do you have any numbers for this? An improved compression ratio and improved speed would be nice indeed, but how does the size of the decompression code change? If the decompression code grows more than the size reduction from better compression, it would be a net loss. A significantly reduced decompression speed would also be a problem. Decompression speed would have to be measured both for stream decompression (i.e. the decompressor gets the compressed data in single-byte or multibyte chunks) as well as full-size decompression (i.e. the decompressor can access all compressed data at once). We also have to make sure that stream decompression still works after the change. > Do you think it should be done, or you are OK with using such an > outdated version? A size benefit for the resulting image is a good reason to switch. Regards, Carl-Daniel

2 years, 11 months

Re: [coreboot] AMD IMC open source firmware replacement

by Rudolf Marek

Dne 30.5.2018 v 16:06 Mike Banon napsal(a): > Hi Rudolf, > > Regarding this part: > " To check if IMC is active check if PCI 0:14.3 0x40 bit7 set. " > what command do I need to use to check this? Try: sudo setpci -s 14.3 40.b Despite command name, it will print the value. Thanks Rudolf

3 years

Porting Qotom Q355G4 SBC (similar to Librem 13)

by John Keates

Hi, I’m new at the board porting game but I’m interested in making a port for a single board computer that is running very similar hardware to the Librem 13 laptop and the Google Pixel 2015. It seems this board is also rather close to Intel’s own Eval Kit hardware setup, both in hardware and software regard (almost bare defaults AMI Aptio firmware). Looking at the coreboot archives, this board might have been mentioned before: https://mail.coreboot.org/pipermail/coreboot/2018-July/087050.html <https://mail.coreboot.org/pipermail/coreboot/2018-July/087050.html> but that was HTML formatted in an attachment for some reason. Board specs: - CPU: i5-5250U - SuperIO: IT8784E-I - HDA: ALC662 - Flash: 8MByte Winbond SPI SOIC8 (but flashrom detects it as opaque when using internal programmer on-device, works correctly using external SPI flasher) - 4x Intel I211 Ethernet controllers more specifically, inteltool sees: CPU: ID 0x306d4, Processor Type 0x0, Family 0x6, Model 0x3d, Stepping 0x4 Northbridge: 8086:1604 (5th generation (Broadwell family) Core Processor ULT) Southbridge: 8086:9cc3 (unknown) IGD: 8086:1626 (unknown) Linux itself sees it as Wildcat Point-LP and Broadwell-U which makes sense. It has a running ME, but there is an unpopulated header (ME1) which when shorted seems to kill it or put it in manufacturing mode (soldered in a pin header and plugged in a jumper): MEI found: [8086:9cba] Wildcat Point-LP MEI Controller #1 ME Status : 0x1e040185 ME Status 2 : 0x10522106 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 : Security Override via Jumper ME: Error Code : No Error ME: Progress Phase : BUP Phase ME: Power Management Event : Clean Moff->Mx wake ME: Progress Phase State : 0x52 When not using the jumper, flashrom can’t read anything using the internal programmer mode, but when plugging the jumper in, it can read it. Output is not the same as reading the SPI flash chip offline externally, so some of the flash it probably still hidden by the PCH as it always does. There are exposed pads near the Realtek ALC chip which makes it really easy to pull GPIO33 to DVDD and disable flash descriptor security. So far so good, the hardware has easy-to-reach points to get to the flash, ME jumper and PCH straps. The firmware isn’t very custom, and neither is the board (except the four ethernet controllers/ports). My next steps were: cp -R the Purism directory to Qotom, remove all the Librem15 stuff, rename the Librem13 to Q3XXG4 and remove the EC references as this board doesn’t have an EC. At this point, I’m not sure what to do next, besides the text in board_info.txt (both the vendor directory and the variant directories) I’ll probably have to make sure: - acpi_tables.c has the correct tables, unless I can use the (generic looking) contents the Librem 13 uses, which doe acpi_init_gnvs, and acpi_create_madt_lapics + acpi_create_madt_ioapic - there is fadt.c which seems rather generic as well. - gpio.h is probably depending on the PCH used? Seems to be generic for this PCH as well - hda_verb.c seems to relate to the audio system, but I don’t care about it all that much at this time. The Librem 13 uses the ALC269 which has some differences to the ALC662, configuring it wrong probably just makes the chip sad and audio pin routing not work - mainboard.c contains mainboard_enable and some calls for the GMA chip (install_intel_vga_int15_handler and some constants), probably the same accross this broadwell series - romstage.c initialises the GPIOs does some PEI data copy/memset and then romstage_common (which probably is around or before the CAR stage?) - acpi/mainboard.asl is empty, not sure what part of the existing ACPI I should dump in there I turned the board into a variant, because Qotom has a number of boards that mostly differ in i3 vs i5 and more ethernet ports vs. more serial ports models. I named the variant q3xxg4 but I think we can do better as the PCB has a revision number printed on it, indicating more variants. It looks like I’ll need to build some sort of devicetree.cb, perhaps by hand or converted from a ACPI dump from a running system? Then there is pei_data.c which seems to set the specifics for the hardware, the labels and locations. While it is pretty close to the Librem 13 there as well (USB3 ports, USB2 ports) some of the locations need to be changed, and the camera, bluetooth, and speakers removed). Not sure how this relates to what is in the device tree and any *.asl files. The old wiki and it’s porting guide isn’t up to date as far as I know, but I haven’t found a new guide or set of docs that shows how to read/source information from a running system and write it into a new mainboard definition. I’ll probably need to get the GbE region from the old firmware, ME too, but what other parts of data (ACPI tables? PEI data?)I need to get and how to fill out that data into the mainboard definition isn’t very clear to me. This device has a GPIO header, and two serial ports (one external DB9, one internal header), so getting debug data out should be possible, but just randomly building an image and flashing it in to the SPI chip probably gets me nothing until I have at least configured the serial port for coreboot to spit out debug data. I’m not sure if I need to get the FSP from Intel or if I should extract the one from the current firmware. Any guidance would be appreciated. Regards, John

3 years

Lenovo T410 Coreboot

by A. Veek

3 years, 1 month

FOSDEM Hardware Enablement Devroom

by Paul Kocialkowski

A Hardware Enablement devroom will be taking place at FOSDEM this year, on Sunday 10 December 2017. This newly-created devroom is the result of 3 proposals that were merged together. It is co-organized by several individuals. The devroom covers all aspects related to hardware enablement and support with free software, including aspects related to boot software, firmwares, drivers and userspace tools and adaptation. Proposals for talks related to these topics are welcome and can be submitted until Sunday 26 November 2017 via the pentabarf interface. Short talks are encouraged over longer ones in order to cover a wide range of topics. The announcement for the devroom, that contains all the useful information, was published at: https://lists.fosdem.org/pipermail/fosdem/2017-October/002649.html Cheers and see you at FOSDEM! -- Paul Kocialkowski, developer of free digital technology and hardware support Website: https://www.paulk.fr/ Coding blog: https://code.paulk.fr/ Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/

3 years, 1 month

Intel G41 - Asrock G41M-GS: no coreboot screen output from Intel GPU on VGA

by h42＠memeware.net

I dont get anything on the screen from coreboot. The later os is displaying fine. How i build the image: ran on a fresh git cloned (from today) 'make menuconfig', chose just the mainboard manufacturer and the model, press esc, confirmed saving, ran 'make'. I installed this image and dont get any coreboot output on the screen. When i wait long enough, i get the output from the Linux OS on the screen. From the coreboot logfile: coreboot-4.8-1195-gb75a08b199 [...] FMAP: Found "FLASH" version 1.1 at 0. FMAP: base = fff00000 size = 100000 #areas = 4 FMAP: area RW_MRC_CACHE found @ 10000 (65536 bytes) MRC: No data in cbmem for 'RW_MRC_CACHE'. BS: BS_DEV_ENUMERATE times (us): entry 0 run 150329 exit 16016 found VGA at PCI: 00:02.0 Setting up VGA for PCI: 00:02.0 Setting PCI_BRIDGE_CTL_VGA for bridge DOMAIN: 0000 Setting PCI_BRIDGE_CTL_VGA for bridge Root Device Allocating resources... Reading resources... TOUUD 0x80000000 TOLUD 0x80000000 TOM 0x80000000 IGD decoded, subtracting 64M UMA and 4M GTT TSEG decoded, subtracting 8M Available memory below 4GB: 1972M Adding UMA memory area base=0x7b400000 size=0x04c00000 Adding PCIe config bar base=0xe0000000 size=0x10000000 Done reading resources. [...] [21.707417] CONFIG => [21.709411] (Primary => [21.711924] (Port => Analog , [21.715130] Framebuffer => [21.718076] (Width => 640, [21.721542] Height => 400, [21.725008] Start_X => 0, [21.728301] Start_Y => 0, [21.731594] Stride => 1, [21.734886] V_Stride => 1, [21.738179] Tiling => Linear , [21.741993] Rotation => No_Rotation, [21.746153] Offset => 0xffffffff, [21.749966] BPC => 8), [21.753085] Mode => [21.755424] (Dotclock => 148500000, [21.760192] H_Visible => 1920, [21.764524] H_Sync_Begin => 2008, [21.768857] H_Sync_End => 2052, [21.773190] H_Total => 2200, [21.777523] V_Visible => 1080, [21.781857] V_Sync_Begin => 1084, [21.786189] V_Sync_End => 1089, [21.790522] V_Total => 1125, [21.794855] H_Sync_Active_High => True, [21.799189] V_Sync_Active_High => True, [21.803521] BPC => 5)), [21.807767] Secondary => [21.810281] (Port => Disabled, [21.813487] Framebuffer => [21.816433] (Width => 1, [21.819727] Height => 1, [21.823020] Start_X => 0, [21.826313] Start_Y => 0, [21.829605] Stride => 1, [21.832899] V_Stride => 1, [21.836193] Tiling => Linear , [21.840006] Rotation => No_Rotation, [21.844166] Offset => 0x00000000, [21.847979] BPC => 8), [21.851098] Mode => [21.853438] (Dotclock => 24000000, [21.858118] H_Visible => 1, [21.862191] H_Sync_Begin => 1, [21.866263] H_Sync_End => 1, [21.870336] H_Total => 1, [21.874409] V_Visible => 1, [21.878482] V_Sync_Begin => 1, [21.882555] V_Sync_End => 1, [21.886629] V_Total => 1, [21.890702] H_Sync_Active_High => False, [21.895121] V_Sync_Active_High => False, [21.899541] BPC => 5)), [21.903787] Tertiary => [21.906300] (Port => Disabled, [21.909507] Framebuffer => [21.912453] (Width => 1, [21.915746] Height => 1, [21.919039] Start_X => 0, [21.922331] Start_Y => 0, [21.925624] Stride => 1, [21.928918] V_Stride => 1, [21.932211] Tiling => Linear , [21.936023] Rotation => No_Rotation, [21.940183] Offset => 0x00000000, [21.943996] BPC => 8), [21.947116] Mode => [21.949455] (Dotclock => 24000000, [21.954135] H_Visible => 1, [21.958207] H_Sync_Begin => 1, [21.962280] H_Sync_End => 1, [21.966353] H_Total => 1, [21.970427] V_Visible => 1, [21.974499] V_Sync_Begin => 1, [21.978572] V_Sync_End => 1, [21.982646] V_Total => 1, [21.986719] H_Sync_Active_High => False, [21.991138] V_Sync_Active_High => False, [21.995557] BPC => 5))); PCI: 00:02.0 init finished in 307222 usecs PCI: 00:02.1 init ... PCI: 00:02.1 init finished in 2009 usecs PCI: 00:1b.0 init ... [...] So it seems to have detected that my screen is 1920*1080. GPU + screen detection seems to be working. But i dont get any coreboot output on the screen. The output had worked fine on this screen with the OEM BIOS.

3 years, 4 months

Re: [coreboot] Coffee Lake FSP Released

by Nico Huber

On 8/23/18 11:47 PM, Zimmer, Vincent wrote: > We agree > > See https://github.com/IntelFsp/FSP/blob/master/FSP_License.pdf > This is great news. Nate, Vincent thank you very much! IMHO, you two just doubled what Intel did for coreboot so far; in one day! This is the first time in five years that we can again have a coreboot for current Intel systems that compiles to something bootable out of the box*. Just checkout, select your board, build, flash :D Thanks again, Nico * Disclaimer: It will take some time until we have the configs set up, but it's at least feasible now.

3 years, 4 months

Re: [coreboot] RISC-V HiFive Unleashed board added to coreboot - has PCI-e slots via exp board

by Jonathan Neuschäfer

On Fri, Jun 22, 2018 at 03:04:06PM +0800, Shawn wrote: > Hi Jonathan, > > On Thu, Jun 21, 2018 at 7:48 PM, Jonathan Neuschäfer [...] > > With the unfinished coreboot port, I want it to look like this (although > > *a lot* of work has to be done on coreboot first, and I'm currently not > > actively working on that, for a few months): > > > > MSEL (ROM0) -> ZSBL (ROM1) -> coreboot (+bbl?) -> Linux, or > > MSEL (ROM0) -> coreboot (+bbl?) -> Linux > > > > ZSBL can be skipped, so you don't need to run closed source ROM code, at > > least as far as the hardware is concerned. > > > Is ZSBL really can be skipped? I thought it was part of internal ROM > inside the chip. Yes. If you set the MSEL switches to 0001, the code in the MSEL ROM (aka. ROM0) jumps directly into the memory-mapped SPI flash, instead of into the big ROM1, where ZSBL is. Coreboot doesn't yet support this mode, but the hardware allows it. > > (And note that this is just the situation on this particular SoC. Other > > SoCs from SiFive or other vendors may boot differently.) > > > Well, if FSBL is the place where coreboot comes into play, we might > only have two options: 1, Reversing the FSBL which is ~9k assembly LOC > 2, SiFive make the FSBL open source( I don't see any reason why they > don't do it if they intend to build an open eco-system for RISC-V). A high-level list of tasks that FSBL performs is in the manual[1]: • Switch core frequency to 1 GHz (or 500 MHz if TLCLKSEL =1) by configuring and running off the on-chip PLL • Configure DDR PLL, PHY, and controller • Set GEM GXL TX PLL to 125 MHz and reset it • If there is an external PHY, reset it • Download BBL from a partition with GUID type 2E54B353-1271-4842-806F-E436D6AF69851 • Scan the OTP for the chip serial number • Copy the embedded DTB to DDR, filling in FSBL version, memory size, and MAC address • Enable 15 of the 16 L2 ways (this removes almost all of the L2 LIM memory) • Jump to DDR memory (0x8000_0000) Initializing the PLLs and reading the OTP ROM should be easy enough because both are documented in, I think, sufficient detail. Section 20.3 describes the initialization sequence for the DRAM controller, but leaves out the values for the register for "memory timing settings, PAD mode configuration, initialization, and training." It says: "Please contact SiFive directly to determine the complete register settings for your application." I will ask on the forum. Assuming that SiFive will tell us the values of the missing configuration registers, I don't think we need to reverse-engineer FSBL. Greetings, Jonathan Neuschäfer [1]: https://www.sifive.com/documentation/chips/freedom-u540-c000-manual/

3 years, 4 months

Microcode Updates PSA (New users please read)

by Taiidan＠gmx.com

I am making this due to seeing many mis-informed users that are engaging in dangerous practices. Microcode updates should ALWAYS be installed unless you are an expert user and have repeatedly verified that your CPU doesn't require them and you are prepared for the risks which include for instance on the piledriver CPU's (opteron 63xx/43xx and the G505S's laptop cpus) a userland to root exploit, a broken IOMMU and a timer issue that means games and certain applications don't work properly. Unfortunately x86 is stuck with non owner controlled undocumented proprietary microcode updates and in the case of intel they are encrypted for some reason - AFAIK only POWER has owner controlled microcode. Despite this it is still a good idea to install them - I do on my coreboot computers and thus I don't ruin my security for no good reason. NOTE: For microcode embedding in coreboot to work you must check both the "generate microcode update from tree" option and the "use non-free blob repo" option - doing the first but not the second will result in a silent fail.

3 years, 4 months

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot August 2018