October 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] 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

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

Dec. 14, 2018

2 1

FOSDEM Hardware Enablement Devroom
by Paul Kocialkowski Dec. 4, 2018

Dec. 4, 2018

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 3

Re: [coreboot] Will a KCMA-D8 boot without the 8pin EPSV12 cable if you are using a 35W CPU?
by Nico Huber Nov. 17, 2018

Nov. 17, 2018

On 10/18/18 3:16 PM, Angel Pons wrote: > I believe the power traces are different, so the CPU VRM feeds only through > the EPS12V connector. However, if your PicoPSU is large enough, I guess a > EPS12V cable can be attached to it. Probably not for a 35W CPU, but generally: Using adapters for the EPS12V connector is dangerous. They have more than two pins for a simple reason: The electrical current through each pin/connection must not get too high. There are adapters that route the whole current through a single pin on the other end (e.g. a single old-school PATA drive connector). Never use these unless you know they can take the current you expect! (e.g. not much more than 3A for a 35W TDP, that might be ok for a single pin, but you should read each connectors specs) Same applies to the tiny connectors for (hard)-drives on the PicoPSU, if the current goes through less pins on the PicoPSU side, don't do it (unless you know what you are doing). There are PicoPSUs that have a 4-pin EPS12V connector btw. So I'm not sure what the original question was; would it work w/o full 8 pins? or would it work w/o any? The former likely yes, the latter likely no. Nico

3 3

Re: [coreboot] Hardware diagnostic
by Peter Stuge Nov. 6, 2018

Nov. 6, 2018

yanvasilij yan wrote: > I have two Intel Atom E3800 based boards. The first one is older version, > which woks properly, .. > The second one is modernized version, we added 89HPES5T5 PCIe I/O > expansion switch. And WGI210IT based Ethernet ports are connected > to switch. So the good news is that your log clearly shows the PCIe switch working correctly and both NICs behind reachable by software. > Further we rebuild a bit a power up circuit of the E3800 SOC. This is quite possibly the root cause, but I wouldn't exclude any other possibilities. > Launching stops when starts payload loading. The launch log of this board > see in attached “not_working_board_log.txt”. The log is very clear about why: (down near the end) --8<-- SELF segment doesn't target RAM: 0x00800000, 4259840 bytes -->8-- Looking at the coreboot table a little further up, we see: --8<-- Writing coreboot table at 0x3add3000 0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES 1. 0000000000e00000-0000000000e39fff: RAMSTAGE 2. 000000003ad9e000-000000003adfffff: CONFIGURATION TABLES 3. 00000000feb00000-00000000fec00fff: RESERVED 4. 00000000fed01000-00000000fed01fff: RESERVED 5. 00000000fed03000-00000000fed03fff: RESERVED 6. 00000000fed05000-00000000fed05fff: RESERVED 7. 00000000fed08000-00000000fed08fff: RESERVED 8. 00000000fed0c000-00000000fed0ffff: RESERVED 9. 00000000fed1c000-00000000fed1cfff: RESERVED 10. 00000000fef00000-00000000feffffff: RESERVED -->8-- Compare that with your working board: --8<-- Writing coreboot table at 0x3add3000 0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES 1. 0000000000001000-000000000009ffff: RAM 2. 00000000000a0000-00000000000fffff: RESERVED 3. 0000000000100000-0000000000dfffff: RAM 4. 0000000000e00000-0000000000e39fff: RAMSTAGE 5. 0000000000e3a000-000000003ad9dfff: RAM 6. 000000003ad9e000-000000003adfffff: CONFIGURATION TABLES 7. 000000003ae00000-000000003fffffff: RESERVED 8. 00000000e0000000-00000000efffffff: RESERVED 9. 00000000feb00000-00000000fec00fff: RESERVED 10. 00000000fed01000-00000000fed01fff: RESERVED 11. 00000000fed03000-00000000fed03fff: RESERVED 12. 00000000fed05000-00000000fed05fff: RESERVED 13. 00000000fed08000-00000000fed08fff: RESERVED 14. 00000000fed0c000-00000000fed0ffff: RESERVED 15. 00000000fed1c000-00000000fed1cfff: RESERVED 16. 00000000fee00000-00000000fee00fff: RESERVED 17. 00000000fef00000-00000000feffffff: RESERVED -->8-- The new board ends up with no RAM regions in the coreboot table. That results in the payload loader not finding RAM where the payload is to be loaded, so boot stops. Why are there no RAM regions? I don't know. Looking near the beginning of the log about FSP memory init: --8<-- Memory Down Data Existed : Enabled - Speed (0: 800, 1: 1066, 2: 1333, 3: 1600): 1 - Type (0: DDR3, 1: DDR3L) : 1 - DIMM0 : Enabled - DIMM1 : Disabled - Width : x16 - Density : 2Gbit - BudWidth : 64bit - Rank # : 1 - tCL : 0B - tRPtRCD : 0B - tWR : 0C - tWTR : 06 - tRRD : 06 - tRTP : 06 - tFAW : 14 Using 1066 MHz DDR3 settings. 1 GB Minnowboard Max detected. romstage_main_continue status: 0 hob_list_ptr: 3ae20000 FSP Status: 0x0 PM1_STS = 0x1 PM1_CNT = 0x0 GEN_PMCON1 = 0x1001808 romstage_main_continue: prev_sleep_state = S0 Baytrail Chip Variant: Bay Trail-I (ISG/embedded) MRC v0.102 1 channels of DDR3 @ 1066MHz -->8-- It appears OK - but do check that those numbers actually match the DRAM chips assembled on the board. Are DRAM parts identical between old and new? Were there *any* hardware changes between SoC and RAM? That's worth checking, but.. > nico_h in the IRC chat noticed that in non-working board appears a starnge > device with vid/did PCI: 00:00.0 [8086/0000]. The 0000 is a HUGE red sign, screaming to be thoroughly investigated. This also hints that the power up changes may be the problem. It's VERY unlikely that Intel has suddenly released a variant of this particular SoC with PCI DID=0000 when it used to be DID=0f00. In fact it's really unlikely that 0000 would be used in correct operation at all. Very likely on the other hand is that the SoC isn't being powered on correctly, and so it ends up in some half-initialized state, with the memory controller not working, and while some part of coreboot seems to notice (because no RAM regions in coreboot table) clearly that isn't causing a fatal error, which I think is a bug. Oh well. If you go through every single powerup hardware change together with a hardware engineer, starting with the previous circuit and manually applying one change at a time, maybe you can find one or even more changes causing that device ID symptom. It depends on how many changes you have there, but with a good hardware engineer you could perhaps go through them all in a couple days, which would be really fast results for a problem like this. Maybe even simpler, hack this into some early part of the code, maybe even console_init() works, if pci_early is available there. while (1) if (0x0f00 == pci_read_config32(PCI_DEV(0,0,0), PCI_VENDORID)) printk(BIOS_INFO, "PASS\n"); else printk(BIOS_INFO, "FAIL: want 0f00 is %04x\n", pci_read_config32(PCI_DEV(0,0,0), PCI_VENDORID)); Then hardware engineering can do analysis on their own. But make sure to confirm that your test is reliable, using the hardware you have (old and new) before you give a flash image to them. Oh, and test on multiple new boards, a single unit in a new batch isn't representative. New PCB; potentially the process has to be tuned. I don't know how early in bringup you are. Good luck and have fun! :) //Peter

3 2

Matrix instead (or additionally to) IRC
by Philipp Stanner Nov. 4, 2018

Nov. 4, 2018

Hey, have you guys already heard of Matrix? https://matrix.org/blog/home/ It's some sort of modern IRC, using JSON to format messages. It's more modern than IRC. Features are: * Source code formatting and highlighting in messages * multiple devices * history + history synchronization between multiple devices * possible E2C encryption and many more. In theory it will be a decentralized protocol, but there aren't that many servers yet and actually only one working server-software Many projects, especially tech-based ones like the Rust programming language already use the service. Personally I think it's an enormous progress to IRC. I would give it a chance if I were you :) P.

3 3

There are ASMB5's on fleabay right now for $30/ea (firmware storage module required for OpenBMC on the KGPE-D16/KCMA-D8)
by Taiidan＠gmx.com Nov. 3, 2018

Nov. 3, 2018

(This is the firmware storage module required to use OpenBMC on the KGPE-D16/KCMA-D8 boards - with it at last one can have feature equivalency with a proprietary system) Great opportunity if you need but don't have one - they appear to be brand new. Raptor says either the ASMB4 or the ASMB5 will work. While the facebook version of OpenBMC is stripped down (they used that one for smaller firmware size afaik) and not as nice as the IBM OpenBMC found on the various OpenPOWER machines it is still secure and much nicer than the exploit filled default BMC firmware from ASUS.

2 1