coreboot June 2019

coreboot@coreboot.org

56 participants
49 discussions

Re: How would an open source vgabios work?
by Nico Huber 05 Jun '19

05 Jun '19

Hi Matt, TL;DR you can simply compile a VGA BIOS with GCC/Clang. You don't have to make the same mistakes as AMD and compile/interpret some byte code. Which, IMHO, would only make it harder to implement an open-source version. On 05.06.19 02:38, Matt B wrote: > I'm not talking about replacing a blob that nobody understands with a > technically different but equally incomprehensible one. It sounds like your > interpretation is to simply copy all the individual routines to a new blob. > (Some sort of strange Theseus' ship exercise?) But you don't develop an > open-source replacement for any a piece of software by a copying several > sequences of instructions from the original ELF file to another. well, I'm afraid that is what many people do. Most of the AtomBIOS code will be like: write magic number A into magic register B. If you do that too in your code, it works. If you don't do it, it doesn't work. I fear, without an unreasonably huge effort, the open-source version won't get much more comprehensible. I don't think the AMD hardware is worth it when you can get documentation from many other vendors. Or maybe the time is better spend on convincing AMD to release documentation. > Presumably (one would hope) somewhere AMD has un-obfuscated > (understandable) source code of some form that was compiled into the > vgabios roms that are frequently used. I recognize that it would be a > colossal pain to figure out how the chips work without documentation, but > in order to go through that process, tooling would presumably be > advantageous. > > Afaik, the only development tooling anyone has right now is a disassembler. > Nothing which can turn the source code one might try to write into a > vgabios blob that could be loaded into a build of coreboot and tried out. > This is important as the painful process typically works when replacing any > proprietary code is [1]: > a) try to write something that's a little bit correct > b) build and flash > c) test the result and make a few changes > d) go back to step B until a little bit more functionality is understood, > then go back to step A for more > > For that to work it's a big help to have a compiler that can turn > annotated, documented source code into the binary format that's stored in > flash. That same compiler also sees use in builds once things are complete > enough to start sharing source code. That's why I'm interested in the > question of whether such a tooling is available. Let's add some more background. AMD's VGA BIOS contains two code parts: 1. The AtomBIOS that is card/mainboard specific, compiled to some byte code. 2. An interpreter for the AtomBIOS byte code. There are already open-source implementations of 2. So I guess what you are asking for is a compiler for the AtomBIOS. But I wonder why? A new, clean implementation wouldn't have to keep this weird structure. You can simply skip AtomBIOS byte code and write your VGA BIOS in C, Rust or whatever you prefer; use GCC or Clang to compile it. Nico > [1] One example is the panfrost team's development of the panfrost GPU > driver. They started by recording and replaying command streams to > understand how things work, but to move beyond that they obviously had to > start writing the skeleton of a driver in C.

1 0

failed to run coreboot with opensbi on HiFive Unleashed
by Xiang W 05 Jun '19

05 Jun '19

I try to run coreboot + opensbi + linux kernel on HiFive Unleashed and separate hardware-initiated code for a simpler upgrade. To do this, a loader called riscv-gptl was added to load opensbi and linux from the sdcard and run as a coreboot payload. However, I have encountered a strange problem. After running the specific firmware, I ran the normal firmware again (without re-powering) and the normal firmware could run. The button reset has no effect and cannot be runned after power-on again. normal firmware, please refer to https://github.com/hardenedlinux/embedded-iot_profile/blob/master/docs/risc… Specific firmware (coreboot which payload is opensbi FW_JUMP) create by the following command ``` # get source code git clone git@github.com:hardenedlinux/coreboot-HiFiveUnleashed.git -b gptl coreboot git clone git@github.com:wxjstz/opensbi.git -b gptl # build opensbi cd opensbi make CROSS_COMPILE=riscv64-elf- PLATFORM=sifive/fu540 cd - # build coreboot cd coreboot make menuconfig # Mainboard->Mainboard vendor, select **SiFive** # Mainboard->Mainboard model, select **HiFive Unleashed** # Payload->Add a payload, select **An ELF executable payload** # Payload->Payload path and filename, Use default value **payload.elf** cp ../opensbi/build/platform/sifive/fu540/firmware/fw_jump.elf ./payload.elf make cd - # Burn sudo dd if=coreboot/build/coreboot.rom of=/dev/sdX; sync ```

1 0

New on blogs.coreboot.org: [GSoC] Coreboot Coverity, Introduction
by blogs.coreboot.org 05 Jun '19

05 Jun '19

1 0

IME: Alternatives for large companies?
by Philipp Stanner 04 Jun '19

04 Jun '19

Recently I had an interesting discussion with a system administrator who is responsible for several hundred PCs, Routers etc. His argument was: Imagine it would take you 15 minutes to install a patch on a computer (all windows machines of course...). If your company has 1000 computers and you send one admin to install the patches, it will take him >31 work days, working 8h a day. That's why, he said, companies are interested in software allowing them to install stuff on the OS / hard drive remotely through the firmware I, not dealing with large networks, had never thought about it this way. But it does make a lot of sense to me, it's about real money (as usual). So I guess that's indeed a huge reason why Intel and AMD created Frankenstein, running below UEFI and Kernel. It probably doesn't explain so much why it's necessary to disallow you switching IME off or why it needs control about absolutely everything, but that's a different story. So I'm wondering: What would you do about this reality? Could there be a different solution other than software in Ring -1 having its sausage fingers on everything? Sure, the programmers in a company could install their stuff on their own, but the office folks, the HR and PR guys and the lawyers? Hmm. And whether we like it or not, even awesome companies almost exclusively supply their employees with windows machines and they just demand solutions allowing their IT-departements to fix everything as cheap and as easy as possible P.

3 2

New on blogs.coreboot.org: [GSoC] Ghidra firmware utilities, weeks 1-2
by blogs.coreboot.org 04 Jun '19

04 Jun '19

1 0

Starting the coreboot 4.10 release process
by Patrick Georgi 03 Jun '19

03 Jun '19

Hi everybody, with this mail I'm officially starting the 4.10 release process. As per the first step of our checklist (Documentation/releases/checklist.md), I hereby announce the intent to release coreboot 4.10 in about 2 weeks. I'm aiming for May 28th to avoid releasing into the weekend or on Memorial Day in the US, but I'll likely lock down the commit we'll designate 4.10 during those days to give some room for testing. I created a copy of the checklist on https://piratenpad.de/p/coreboot4.10-release-checklist, also including the current state of the 4.10 release notes. Please test the boards you have around and provide fixes, please be careful with intrusive changes (and maybe postpone them until after the release) and please update the release notes (Documentation/releases/ coreboot-4.10-relnotes.md or near the bottom of the etherpad doc, I'll carry them over into our git repo then). As promised with the 4.9 release there won't be deprecations after 4.10. However we need to finalize our set of deprecations we want to announce with 4.10 that will happen after the 4.11 release (those also belong in the release notes). Regards, Patrick -- Google Germany GmbH, ABC-Str. 19, 20354 Hamburg Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

6 12

linux kernel > 4.9 hang at boot on ASUS KGPE-D16
by Kinky Nekoboi 03 Jun '19

03 Jun '19

After upgrading my Debian Stretch installation to Buster, i experienced this behaviour. acpi=off lets the kernel boot, but the system is still unusable as some controller do not work correctly. So i guess its something ACPI related. Also wrote an bugreport to debian. I can not give any usable debug output as the kernel hangs before giving any output.

1 1

Fwd: Re: ASUS KGPE-D16 ECC disabled by default
by Matt B 02 Jun '19

02 Jun '19

---------- Forwarded message --------- From: Matt B <matthewwbradley6(a)gmail.com> Date: Sat, Jun 1, 2019 at 12:17 PM Subject: Re: [coreboot] Re: ASUS KGPE-D16 ECC disabled by default To: Kinky Nekoboi <kinky_nekoboi(a)nekoboi.moe> Hi, So configuring ECC to be on by default in nvram has no effect? Sincerely, -Matt On Sat, Jun 1, 2019 at 11:08 AM Kinky Nekoboi <kinky_nekoboi(a)nekoboi.moe> wrote: > OK i flashed a recompiled version with nvram options enabled. > > ECC is enabled by default: > boot_option = Fallback > reboot_counter = 0x0 > interleave_chip_selects = Enable > interleave_nodes = Disable > interleave_memory_channels = Enable > max_mem_clock = DDR3-1600 > multi_core = Enable > debug_level = Debug > ecc_scrub_rate = 1.28us > slow_cpu = off > nmi = Disable > gart = Enable > power_on_after_fail = On > ECC_memory = Enable > ECC_redirection = Enable > hypertransport_speed_limit = Auto > minimum_memory_voltage = 1.5V > compute_unit_siblings = Enable > cpu_c_states = Enable > cpu_cc6_state = Enable > sata_ahci_mode = Enable > sata_alpm = Disable > dimm_spd_checksum = Enforce > probe_filter = Auto > l3_cache_partitioning = Disable > ieee1394_controller = Enable > iommu = Enable > cpu_core_boost = Enable > ehci_async_data_cache = Enable > experimental_memory_speed_boost = Disable > maximum_p_state_limit = 0xf > > Still i need to force the kernel to enable ECC. > Am 01.06.19 um 14:10 schrieb Kinky Nekoboi: > > Hello everybody, i just setup an ASUS KGPE-D16 with coreboot in my > fileserver today. > > CPU: Opteron 6380 with newest microcode loaded in coreboot > > 1x 8GB Hynix DDR3 ECC > > 1x 8GB Samsung DDR3 ECC > > ECC works after you force the linux kernel / the amd_edac module to > enable ECC as you can see on this dmesg output : > > root@lain:~# dmesg | grep -i edac > [ 44.487132] EDAC MC: Ver: 3.0.0 > [ 44.520632] EDAC amd64: DRAM ECC disabled. > [ 44.520670] EDAC amd64: ECC disabled in the BIOS or no ECC > capability, module will not load. > [ 44.520670] EDAC amd64: Forcing ECC on! > [ 44.520747] EDAC amd64: DRAM ECC disabled on this node, enabling... > [ 44.520749] EDAC amd64: Hardware accepted DRAM ECC Enable > [ 44.520750] EDAC amd64: F15h detected (node 0). > [ 44.520802] EDAC MC: DCT0 chip selects: > [ 44.520804] EDAC amd64: MC: 0: 0MB 1: 0MB > [ 44.520805] EDAC amd64: MC: 2: 0MB 3: 0MB > [ 44.520806] EDAC amd64: MC: 4: 0MB 5: 0MB > [ 44.520807] EDAC amd64: MC: 6: 0MB 7: 0MB > [ 44.520808] EDAC MC: DCT1 chip selects: > [ 44.520809] EDAC amd64: MC: 0: 0MB 1: 0MB > [ 44.520810] EDAC amd64: MC: 2: 0MB 3: 0MB > [ 44.520811] EDAC amd64: MC: 4: 0MB 5: 0MB > [ 44.520812] EDAC amd64: MC: 6: 0MB 7: 0MB > [ 44.520813] EDAC amd64: using x4 syndromes. > [ 44.520813] EDAC amd64: MCT channel count: 0 > [ 44.520903] EDAC MC0: Giving out device to module amd64_edac > controller F15h: DEV 0000:00:18.2 (INTERRUPT) > [ 44.520904] EDAC amd64: DRAM ECC enabled. > [ 44.520916] EDAC amd64: F15h detected (node 1). > [ 44.520958] EDAC MC: DCT0 chip selects: > [ 44.520959] EDAC amd64: MC: 0: 0MB 1: 0MB > [ 44.520961] EDAC amd64: MC: 2: 4096MB 3: 4096MB > [ 44.520962] EDAC amd64: MC: 4: 0MB 5: 0MB > [ 44.520963] EDAC amd64: MC: 6: 0MB 7: 0MB > [ 44.520964] EDAC MC: DCT1 chip selects: > [ 44.520965] EDAC amd64: MC: 0: 0MB 1: 0MB > [ 44.520966] EDAC amd64: MC: 2: 4096MB 3: 4096MB > [ 44.520967] EDAC amd64: MC: 4: 0MB 5: 0MB > [ 44.520968] EDAC amd64: MC: 6: 0MB 7: 0MB > [ 44.520969] EDAC amd64: using x4 syndromes. > [ 44.520969] EDAC amd64: MCT channel count: 2 > [ 44.521294] EDAC MC1: Giving out device to module amd64_edac > controller F15h: DEV 0000:00:19.2 (INTERRUPT) > [ 44.521313] EDAC PCI0: Giving out device to module amd64_edac > controller EDAC PCI controller: DEV 0000:00:18.2 (POLLED) > [ 44.521314] AMD64 EDAC driver v3.4.0 > > Is there an NVRAM Option for ECC and should i rebuild coreboot with > nvram options enabled ? > > best regards > > kinky_nekoboi > > > > > _______________________________________________ > coreboot mailing list -- coreboot(a)coreboot.org > To unsubscribe send an email to coreboot-leave(a)coreboot.org > > _______________________________________________ > coreboot mailing list -- coreboot(a)coreboot.org > To unsubscribe send an email to coreboot-leave(a)coreboot.org >

2 1

ASUS KGPE-D16 ECC disabled by default
by Kinky Nekoboi 01 Jun '19

01 Jun '19

Hello everybody, i just setup an ASUS KGPE-D16 with coreboot in my fileserver today. CPU: Opteron 6380 with newest microcode loaded in coreboot 1x 8GB Hynix DDR3 ECC 1x 8GB Samsung DDR3 ECC ECC works after you force the linux kernel / the amd_edac module to enable ECC as you can see on this dmesg output : root@lain:~# dmesg | grep -i edac [ 44.487132] EDAC MC: Ver: 3.0.0 [ 44.520632] EDAC amd64: DRAM ECC disabled. [ 44.520670] EDAC amd64: ECC disabled in the BIOS or no ECC capability, module will not load. [ 44.520670] EDAC amd64: Forcing ECC on! [ 44.520747] EDAC amd64: DRAM ECC disabled on this node, enabling... [ 44.520749] EDAC amd64: Hardware accepted DRAM ECC Enable [ 44.520750] EDAC amd64: F15h detected (node 0). [ 44.520802] EDAC MC: DCT0 chip selects: [ 44.520804] EDAC amd64: MC: 0: 0MB 1: 0MB [ 44.520805] EDAC amd64: MC: 2: 0MB 3: 0MB [ 44.520806] EDAC amd64: MC: 4: 0MB 5: 0MB [ 44.520807] EDAC amd64: MC: 6: 0MB 7: 0MB [ 44.520808] EDAC MC: DCT1 chip selects: [ 44.520809] EDAC amd64: MC: 0: 0MB 1: 0MB [ 44.520810] EDAC amd64: MC: 2: 0MB 3: 0MB [ 44.520811] EDAC amd64: MC: 4: 0MB 5: 0MB [ 44.520812] EDAC amd64: MC: 6: 0MB 7: 0MB [ 44.520813] EDAC amd64: using x4 syndromes. [ 44.520813] EDAC amd64: MCT channel count: 0 [ 44.520903] EDAC MC0: Giving out device to module amd64_edac controller F15h: DEV 0000:00:18.2 (INTERRUPT) [ 44.520904] EDAC amd64: DRAM ECC enabled. [ 44.520916] EDAC amd64: F15h detected (node 1). [ 44.520958] EDAC MC: DCT0 chip selects: [ 44.520959] EDAC amd64: MC: 0: 0MB 1: 0MB [ 44.520961] EDAC amd64: MC: 2: 4096MB 3: 4096MB [ 44.520962] EDAC amd64: MC: 4: 0MB 5: 0MB [ 44.520963] EDAC amd64: MC: 6: 0MB 7: 0MB [ 44.520964] EDAC MC: DCT1 chip selects: [ 44.520965] EDAC amd64: MC: 0: 0MB 1: 0MB [ 44.520966] EDAC amd64: MC: 2: 4096MB 3: 4096MB [ 44.520967] EDAC amd64: MC: 4: 0MB 5: 0MB [ 44.520968] EDAC amd64: MC: 6: 0MB 7: 0MB [ 44.520969] EDAC amd64: using x4 syndromes. [ 44.520969] EDAC amd64: MCT channel count: 2 [ 44.521294] EDAC MC1: Giving out device to module amd64_edac controller F15h: DEV 0000:00:19.2 (INTERRUPT) [ 44.521313] EDAC PCI0: Giving out device to module amd64_edac controller EDAC PCI controller: DEV 0000:00:18.2 (POLLED) [ 44.521314] AMD64 EDAC driver v3.4.0 Is there an NVRAM Option for ECC and should i rebuild coreboot with nvram options enabled ? best regards kinky_nekoboi

1 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot June 2019