November 2018 - coreboot - mail.coreboot.org

Optiplex 790 now has preliminary support by coreboot
by Taiidan＠gmx.com Jan. 15, 2020

Jan. 15, 2020

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 1

Re: [coreboot] [LinuxBoot] FOSDEM 2019 deadline today
by Carl-Daniel Hailfinger Feb. 1, 2019

Feb. 1, 2019

In that case, I'd also like to point you to the deadline for submitting main track talks which is tomorrow(!). https://fosdem.org/2019/news/2018-08-10-call-for-participation/ Having a coreboot/LinuxBoot talk there would be awesome. Ron/David, could you submit something or do you have someone in mind who can do that? There's also lightning talks, deadline is a bit later. OK, I'm submitting a request for a stand. I need a backup contact for the stand. Who is willing to do that? AFAICS we can still change the backup contact later if life happens. Regards, Carl-Daniel On 02.11.2018 20:48, David Hendricks wrote: > > > On Fri, Nov 2, 2018 at 9:15 AM 'Ron Minnich' via linuxboot > <linuxboot(a)googlegroups.com <mailto:linuxboot@googlegroups.com>> wrote: > > I"m leaning to yes, by which I mean if you do it, I'll show up. > > I can't believe I said that. > On Fri, Nov 2, 2018 at 7:20 AM Carl-Daniel Hailfinger > <c-d.hailfinger.devel.2006(a)gmx.net > <mailto:c-d.hailfinger.devel.2006@gmx.net>> wrote: > > > > Hi! > > > > FOSDEM next year will be on 2 & 3 February 2019. > > The deadline for applying for a stand is today. > > Do we want a coreboot/flashrom/LinuxBoot stand/booth? > > > Same as what Ron said. I think someone from FB can be there to talk > about coreboot/LinuxBoot stuff and perhaps bring some hardware to demo. > >

6 9

Re: [coreboot] Upgrade the 12 years old LZMA libraries - should we do it?
by Carl-Daniel Hailfinger Jan. 29, 2019

Jan. 29, 2019

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

3 2

Re: [coreboot] AMD IMC open source firmware replacement
by Rudolf Marek Jan. 7, 2019

Jan. 7, 2019

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

4 5

Porting Qotom Q355G4 SBC (similar to Librem 13)
by John Keates Dec. 28, 2018

Dec. 28, 2018

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

6 9

Re: [coreboot] Asus Chromebox Panther: no HW RNG?
by Ivan Ivanov Dec. 24, 2018

Dec. 24, 2018

Sorry but I think that relying on Intel RNG is a _Terrible_ idea regarding the security and not sure you should be pursuing it. If you really want a hardware RNG that is also secure, why not take a look at some USB dongles like FST-01 or Librem key? Here is a ( sadly deleted recently! ) Wikipedia comparison page - https://web.archive.org/web/20180812092012/https://en.wikipedia.org/wiki/Co… - You can check it to find the best price/performance USB TRNG dongle which is also open hardware Best regards, Ivan Ivanov вт, 27 нояб. 2018 г. в 22:50, Grant Grundler <grantgrundler(a)gmail.com>: > > On Tue, Nov 27, 2018 at 4:10 AM Nico Huber <nico.huber(a)secunet.com> wrote: > > > > Hi Grant, > > > > I don't know how it is supposed to work on Haswell, but can give you > > some pointers anyway. > > > > tl;dr I don't think you are looking for a PCI device. > > If intel-rng support is required, a PCI device will be advertised > because of how the linux kernel binds PCI devices to drivers. See > "alias" field of "modinfo intel-rng" as an example. > > One of the search results pointed at a response that said "load > intel-rng driver" as the solution to this problem... that's the only > reason I'm exploring this path. > > > Am 27.11.18 um 08:11 schrieb Grant Grundler: > > > Asus Chromebox (Panther) with Celeron 2995U processor is supposed to > > > have a HW Random Number Generator: > > > https://ark.intel.com/products/75608/Intel-Celeron-Processor-2955U-2M-Cache… > > > > > > (Intel calls it Secure Key) > > > > > > But "modprobe intel-rng" is failing with "No such device" (Debian > > > 4.18.0-2-amd64 kernel). > > > > This driver is for very old Firmware Hub (FWH) hardware which would > > be controlled through the LPC PCI device. You have such a PCI device > > (00:1f.0) but there's no FWH to be expect with Haswell. > > Hrm. OK. But that would explain why intel-rng driver only binds with > PCI devices. > > > What you are probably looking for is the RDRAND instruction. I don't > > know if it can be controlled by the firmware, but would check first if > > your OS is prepared to make use of it. > > Linux kernel has supported RDRAND for a long time. There is even a > public debate about *excluding* RDRAND use since some people were > hypothesizing that RDRAND was "compromised" by Intel so "goverment > agencies" could break encrypted traffic which used RDRAND exclusively > to generate encryption keys. Linux kernel does NOT exclusively use > RDRAND and Ted Tyso made compelling arguments that RDRAND would still > add "entropy" to key generation. > > What I don't know is how linux figures out it can or should use > RDRAND. RDRAND appears to be a "CPU feature": > > arch/x86/include/asm/cpufeatures.h:#define X86_FEATURE_RDRAND > ( 4*32+30) /* RDRAND instruction */ > > And as notedin original email, Intel says this CPU (Celeron 2995U) > supports "Secure Key" which is the new marketing name for HW RNG > support (could be only via RDRAND now). > > > > > Why do I care about HW RNG? > > > Because of this: > > > ... > > > [ 8.560270] r8169 0000:01:00.0 enp1s0: link up > > > [ 8.560287] IPv6: ADDRCONF(NETDEV_CHANGE): enp1s0: link becomes ready > > > [19039.712644] random: crng init done > > > [19039.712649] random: 7 urandom warning(s) missed due to ratelimiting > > > [19044.485625] wlp2s0: authenticate with ... > > > ... > > > > > > Yes, several *hours* until the crng was initialized and then > > > wpa_supplicant could start talking on WIFI. :( > > > > > > The length of the delay varies...shortest was 7 minutes. > > > > Well, even without a hardware rng, I wouldn't expect that. > > Exactly. I didn't either. My NUC5 completes typically in 3 second from > the time the kernel is loaded. But this is a different CPU (Intel Core > i5 6260) and completely different firmware (If Coreboot was available > for this, I'd prefer Coreboot). > > > With antennas > > available, I would say after 10s for the paranoid there should be enough > > entropy available. But that's probably just how I'd do OS development > > (and depends on what the wifi driver can do). > > I don't know if the kernel has access to any radios (or antennas) > until the 80211 link is brought up... which in turn won't happen until > wpa_supplicant is running. So something else is wrong here. My > suspicion is still on Coreboot not providing something that tells the > linux kernel a quick method to generate random numbers. > > I saw Matt DeVillier's response as well and I'll follow up once I've > updated the SeaBIOS firmware, installed rng-tools5, and determined > which CPU features are advertised by both Panther and NUC CPUs. For > some reason my "phone home" (SSH) is getting rejected right now. :( > > cheers, > grant > > > Nico > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot

3 4

Lenovo T410 Coreboot
by A. Veek Dec. 14, 2018

Dec. 14, 2018

2 1

Re: [coreboot] Status Thinkpad T410
by kinky_nekoboi Dec. 14, 2018

Dec. 14, 2018

ok the problems start when i try to merge the patch found on https://review.coreboot.org/c/coreboot/+/11791 into a coreboot master clone ... any guide? i am not that advanced in git Am 08.11.18 um 17:40 schrieb Mike Banon: > Go to review.coreboot.org, search for the recently updated T410 > patches and apply them to your locally cloned coreboot, then build and > test it. Let us know if you have a trouble at any step > On Thu, Nov 8, 2018 at 7:35 PM kinky_nekoboi > <kinky_nekoboi(a)bluetardis.de> wrote: >> I have hardware to test, >> T410 with intel gpu + little flashing tool collection. >> i am waiting for instructions >> >> Am 8. November 2018 17:30:00 MEZ schrieb Peter Lemenkov <lemenkov(a)gmail.com>: >>> Hello! >>> >>> чт, 8 нояб. 2018 г. в 10:50, Angel Pons <th3fanbus(a)gmail.com>: >>>> >>>> Hello nekoboi, >>>> >>>> On Thu, Nov 8, 2018, 10:39 kinky_nekoboi <kinky_nekoboi(a)bluetardis.de wrote: >>>>> >>>>> is there any work going on in the T410 Port ? >>>>> >>>>> Hardware is simular to X201 >>>>> >>>>> I heard some people succesfully flashed x201 roms. >>>> >>>> >>>> I recall seeing a gerrit patch for it, though it is old. I would work on it but I don't have any Thinkpad (let alone a T410). >>> >>> Btw I've updated recently both t410 and t410s patches from gerrit >>> according to the recent coreboot changes, but I've got the same story >>> - I don't have hardware to test. >>> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> https://mail.coreboot.org/mailman/listinfo/coreboot

3 4

Kontron 986LCD-M support
by Petr Cvek Dec. 7, 2018

Dec. 7, 2018

Hello, I was trying to upgrade my Kontron 986LCD-M setup to AMD Radeon RX460 and I've found the vendor BIOS lack support for the video BIOS (RX460 requires UEFI). This incompatibility leads to x16 PCIe slot disable and no graphics in linux at all. I was able to re-enable the PCIe slot until now when I tried to upgrade to 2+2 GiB DDR2 modules (little more MB and dual channel). The RAM space is shared with PCI space and limited by 32bit so the top part of RAM is eaten by the regions of PCI devices. Problem is when vendor BIOS disables the card's slot it doesn't leave a hole for my GPU and it sets the TOLUD register (top of used RAM). This causes kernel to crash in GPU initialization. There is probably no way to fix TOLUD (and ACPI tables, SMI and other stuff) or force vendor's BIOS to reserve region for GPU, so I'm considering to switch to coreboot. My question is: does anybody know advanced information about TPM and SPI connectors? In the Kontron 986LCD-M datasheet (sections 4.16 and 4.17) there are only pin names and caption "unsupported". I understand these signals are likely buses from chipset, but it would be nice to know more details. Namely if the default LPC flash chip needs to be disconnected when using these busses and which pins of the chipset are connected to SPI pins BOOT0 and BOOT1 (I suppose they are LPC/SPI/PCI priority?). Thanks for any help. Petr Cvek

2 2

Configuration for Apollo Lake FSP (Github/MR5)
by Alexey Borovikov Dec. 4, 2018

Dec. 4, 2018

Hi, Nico! Is there an external superio on your board? At the moment I am trying to solve the problem of initializing the external superio chip for the SOC Baytrail processor, but so far without success.

2 2