coreboot

coreboot@coreboot.org

17 participants
39654 discussions

sources about coreboot devicetree
by bejjeh315＠yahoo.com 25 Jul '23

25 Jul '23

Hi I want to fully understand the structure of coreboot devicetree and to be able to make chenges, but I couldn't find much resources, only two pages helped me some.. my first question is about resources to learn this.. My second, there are other videos and things talking about devicetree in linux (which I know is different from the corebootie one), do you think reading these ones is helpful for me? or for example learning ASL helps? I'm a newbie in the hardware...

2 1

regarding virtualization support in coreboot
by ritul guru 25 Jul '23

25 Jul '23

Hi, Does coreboot support virtualization features like SVM, AMD SEV, hard level virtualization SR-IOV? *Thanks & RegardsRitul Guru*

2 1

Recent commit c202be7 ( payloads/external/LinuxBoot: Clean up ) breaks " make clean "
by Ivan Ivanov 24 Jul '23

24 Jul '23

Good day, friends! After getting this recent commit, doing " make clean " is not possible in a coreboot directory - I get this error now: ~/coreboot$ make clean /bin/sh: 1: go: not found /bin/sh: 1: go: not found /bin/sh: 1: [: -eq: unexpected operator Looks like there's a problem in some script Best regards, Ivan Ivanov

2 1

New Defects reported by Coverity Scan for coreboot
by scan-admin＠coverity.com 18 Jul '23

18 Jul '23

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 3 new defect(s) introduced to coreboot found with Coverity Scan. 1 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 3 of 3 defect(s) ** CID 1518044: API usage errors (SWAPPED_ARGUMENTS) ________________________________________________________________________________________________________ *** CID 1518044: API usage errors (SWAPPED_ARGUMENTS) /src/northbridge/intel/ironlake/northbridge.c: 125 in mc_read_resources() 119 pci_read_config32(pcidev_on_root(0, 0), IGD_BASE); 120 gtt_base = 121 pci_read_config32(pcidev_on_root(0, 0), GTT_BASE); 122 if (gtt_base > tseg_end) { 123 /* Reserve the gap. MMIO doesn't work in this range. Keep 124 it uncacheable, though, for easier MTRR allocation. */ >>> CID 1518044: API usage errors (SWAPPED_ARGUMENTS) >>> The positions of arguments in the call to "mmio_from_to" do not match the ordering of the parameters: * "tseg_end" is passed to "base". * "gtt_base" is passed to "end". 125 mmio_from_to(dev, index++, tseg_end, gtt_base); 126 } 127 mmio_range(dev, index++, gtt_base, uma_size_gtt * MiB); 128 mmio_range(dev, index++, igd_base, uma_size_igd * MiB); 129 130 upper_ram_end(dev, index++, touud * MiB); ** CID 1518043: Integer handling issues (OVERFLOW_BEFORE_WIDEN) /src/northbridge/intel/ironlake/northbridge.c: 128 in mc_read_resources() ________________________________________________________________________________________________________ *** CID 1518043: Integer handling issues (OVERFLOW_BEFORE_WIDEN) /src/northbridge/intel/ironlake/northbridge.c: 128 in mc_read_resources() 122 if (gtt_base > tseg_end) { 123 /* Reserve the gap. MMIO doesn't work in this range. Keep 124 it uncacheable, though, for easier MTRR allocation. */ 125 mmio_from_to(dev, index++, tseg_end, gtt_base); 126 } 127 mmio_range(dev, index++, gtt_base, uma_size_gtt * MiB); >>> CID 1518043: Integer handling issues (OVERFLOW_BEFORE_WIDEN) >>> Potentially overflowing expression "uma_size_igd * 1048576" with type "int" (32 bits, signed) is evaluated using 32-bit arithmetic, and then used in a context that expects an expression of type "uint64_t" (64 bits, unsigned). 128 mmio_range(dev, index++, igd_base, uma_size_igd * MiB); 129 130 upper_ram_end(dev, index++, touud * MiB); 131 132 /* This memory is not DMA-capable. */ 133 if (touud >= 8192 - 64) ** CID 1518042: Integer handling issues (OVERFLOW_BEFORE_WIDEN) /src/northbridge/intel/ironlake/northbridge.c: 127 in mc_read_resources() ________________________________________________________________________________________________________ *** CID 1518042: Integer handling issues (OVERFLOW_BEFORE_WIDEN) /src/northbridge/intel/ironlake/northbridge.c: 127 in mc_read_resources() 121 pci_read_config32(pcidev_on_root(0, 0), GTT_BASE); 122 if (gtt_base > tseg_end) { 123 /* Reserve the gap. MMIO doesn't work in this range. Keep 124 it uncacheable, though, for easier MTRR allocation. */ 125 mmio_from_to(dev, index++, tseg_end, gtt_base); 126 } >>> CID 1518042: Integer handling issues (OVERFLOW_BEFORE_WIDEN) >>> Potentially overflowing expression "uma_size_gtt * 1048576" with type "int" (32 bits, signed) is evaluated using 32-bit arithmetic, and then used in a context that expects an expression of type "uint64_t" (64 bits, unsigned). 127 mmio_range(dev, index++, gtt_base, uma_size_gtt * MiB); 128 mmio_range(dev, index++, igd_base, uma_size_igd * MiB); 129 130 upper_ram_end(dev, index++, touud * MiB); 131 132 /* This memory is not DMA-capable. */ ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0

New Defects reported by Coverity Scan for coreboot
by scan-admin＠coverity.com 14 Jul '23

14 Jul '23

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 4 new defect(s) introduced to coreboot found with Coverity Scan. 1 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 4 of 4 defect(s) ** CID 1517819: Integer handling issues (OVERFLOW_BEFORE_WIDEN) /src/soc/intel/common/block/systemagent/systemagent.c: 243 in imr_resource() ________________________________________________________________________________________________________ *** CID 1517819: Integer handling issues (OVERFLOW_BEFORE_WIDEN) /src/soc/intel/common/block/systemagent/systemagent.c: 243 in imr_resource() 237 size_k = ((~mask & 0x0fffffff) + 1); 238 /* 239 * IMRs sit in lower DRAM. Mark them cacheable, otherwise we run 240 * out of MTRRs. Memory reserved by IMRs is not usable for host 241 * so mark it reserved. 242 */ >>> CID 1517819: Integer handling issues (OVERFLOW_BEFORE_WIDEN) >>> Potentially overflowing expression "base_k * 1024U" with type "unsigned int" (32 bits, unsigned) is evaluated using 32-bit arithmetic, and then used in a context that expects an expression of type "uint64_t" (64 bits, unsigned). 243 reserved_ram_range(dev, idx, base_k * KiB, size_k * KiB); 244 } 245 246 /* 247 * Add IMR ranges that hang off the host bridge/memory 248 * controller device in case CONFIG(SA_ENABLE_IMR) is selected by SoC. ** CID 1517818: Integer handling issues (OVERFLOW_BEFORE_WIDEN) /src/northbridge/intel/i440bx/northbridge.c: 65 in i440bx_domain_read_resources() ________________________________________________________________________________________________________ *** CID 1517818: Integer handling issues (OVERFLOW_BEFORE_WIDEN) /src/northbridge/intel/i440bx/northbridge.c: 65 in i440bx_domain_read_resources() 59 tolmk = tomk; 60 } 61 62 /* Report the memory regions. */ 63 idx = 10; 64 ram_range(dev, idx++, 0, 0xa0000); >>> CID 1517818: Integer handling issues (OVERFLOW_BEFORE_WIDEN) >>> Potentially overflowing expression "tolmk * 1024UL" with type "unsigned long" (32 bits, unsigned) is evaluated using 32-bit arithmetic, and then used in a context that expects an expression of type "uint64_t" (64 bits, unsigned). 65 ram_from_to(dev, idx++, 0xc0000, tolmk * KiB); 66 } 67 } 68 69 static struct device_operations pci_domain_ops = { 70 .read_resources = i440bx_domain_read_resources, ** CID 1517817: Integer handling issues (OVERFLOW_BEFORE_WIDEN) /src/mainboard/emulation/qemu-riscv/mainboard.c: 17 in mainboard_enable() ________________________________________________________________________________________________________ *** CID 1517817: Integer handling issues (OVERFLOW_BEFORE_WIDEN) /src/mainboard/emulation/qemu-riscv/mainboard.c: 17 in mainboard_enable() 11 12 if (!dev) { 13 die("No dev0; die\n"); 14 } 15 16 dram_mb_detected = probe_ramsize((uintptr_t)_dram, CONFIG_DRAM_SIZE_MB); >>> CID 1517817: Integer handling issues (OVERFLOW_BEFORE_WIDEN) >>> Potentially overflowing expression "dram_mb_detected * 1048576U" with type "unsigned int" (32 bits, unsigned) is evaluated using 32-bit arithmetic, and then used in a context that expects an expression of type "uint64_t" (64 bits, unsigned). 17 ram_range(dev, 0, (uintptr_t)_dram, dram_mb_detected * MiB); 18 } 19 20 struct chip_operations mainboard_ops = { 21 .enable_dev = mainboard_enable, ** CID 1517816: Integer handling issues (OVERFLOW_BEFORE_WIDEN) /src/soc/intel/common/block/systemagent/systemagent.c: 243 in imr_resource() ________________________________________________________________________________________________________ *** CID 1517816: Integer handling issues (OVERFLOW_BEFORE_WIDEN) /src/soc/intel/common/block/systemagent/systemagent.c: 243 in imr_resource() 237 size_k = ((~mask & 0x0fffffff) + 1); 238 /* 239 * IMRs sit in lower DRAM. Mark them cacheable, otherwise we run 240 * out of MTRRs. Memory reserved by IMRs is not usable for host 241 * so mark it reserved. 242 */ >>> CID 1517816: Integer handling issues (OVERFLOW_BEFORE_WIDEN) >>> Potentially overflowing expression "size_k * 1024U" with type "unsigned int" (32 bits, unsigned) is evaluated using 32-bit arithmetic, and then used in a context that expects an expression of type "uint64_t" (64 bits, unsigned). 243 reserved_ram_range(dev, idx, base_k * KiB, size_k * KiB); 244 } 245 246 /* 247 * Add IMR ranges that hang off the host bridge/memory 248 * controller device in case CONFIG(SA_ENABLE_IMR) is selected by SoC. ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0

2023-07-12 - coreboot Leadership meeting minutes
by coreboot org 12 Jul '23

12 Jul '23

# 2023-07-12 - coreboot Leadership Attendees: David Hendricks, Felix Held, Jay Talbott, Jonathon Hall, Julius Werner, Martin Roth, Patrick Georgi, Simon Glass, Tim Crawford, Werner Zeh * [KyöstiM] Someone with access to Intel Meteor Lake documentation, is there a better workaround or documented errata for the XAPIC/X2APIC issue in bringing up AP CPUs? \ [https://review.coreboot.org/c/coreboot/+/76384](https://review.coreboot.org… * Nobody chimed in on the meeting. Hope folks follow up on the CL or mailing list * [FelixS] Doing some work on the toolchain and build system * [CB:76401](https://review.coreboot.org/c/coreboot/+/76401) reduces the build time for the coreboot-toolchain builder from ~6 hrs to 1.5 hrs * Awesome! * Clang / scan-build has support for the z3 solver for static analysis. Does anyone have experience with it? * It reports less false-positives, but it is slower. There seems to be some kind of hybrid mode. * Shouldn't be a problem since Martin will move it to another builder * Larger shuffle planned between build nodes * codechecker enables it by default if available * Let’s try it out? * FelixS visited Hetzner and used the chance to promote coreboot, they were quite positive and interested in helping us * Let’s set up a call with them? Martin seems interested but isn’t a server person (except for being a marvelous admin) * David, Ron, perhaps? * Werner wants clarity on what they want or what they can provide. Needs a contact and would reach out then. * [PaulM] Is there an overview of the received and spent money? * SFC provides bookkeeping service * Stefan has access * Is there a particular area of interest with this? * [PaulM] The changes regarding renaming master to main were never announced on the list. * It was likely buried in the meeting minutes * Nothing's been done yet, it's been a future objective for a while. Once we have a schedule it will be announced. * [PaulM] Besides OSFC, are people going to other conferences? * Companies aren't paying for people to go to conferences as much as before * Upcoming events: Coscup (Taiwan), OCP Fall Summit (San Jose area) the week after OSFC (also in San Jose area) * Martin: Add these events to the coreboot calendar * Martin can add them if somebody provides dates, times, info * Make sure to include specific talks that will be given relevant to coreboot * Call for papers for OSFC expires soon (July 16) * [Simon Glass] Implementing [Firmware Handoff](https://github.com/FirmwareHandoff/firmware_handoff) in coreboot * Moving some OS/FW communications into a common runtime * Helps do things like enable serial console in a universal manner * How is this different from universal payload? * Universal Payload uses a device tree as a handoff mechanism. This doesn't need device tree, it could be a C structure you can pass along * Not as heavyweight as full handoff * This is not competing with universal payload. DT is good when transferring complex information between projects. This is good when you're in a constrained (e.g. pre-RAM) environment or when it doesn't make sense to have the overhead of DT. * Trusted Firmware will use this, coreboot will have an implementation * "A coreboot table by another name" * The coreboot implementation would just write the tables needed by trusted firmware. * Would this replace coreboot tables? * Julius: We wouldn’t want to have two separate copies of the same information generated * Martin: Wouldn’t we want to generate once, into the coreboot tables, then translate into whatever we wanted, like we requested for the Universal Payload? * Would this replace the cmos setup options? * Not currently, but the android team has implemented something that does that. * This would pass information between stages, at least to the point that the universal payload * Julius: It would make more sense to expand cbmem and expand it into early environments. * Simon: cbmem isn’t set up in bootblock currently. * Would coreboot ever need to accept (consume) firmware handoff tables? * It’s not clear. * [Simon Glass] Drop corebook-sdk? * What coreboot-sdk does * Provides environment with tested toolchain * Can be used in Windows, FreeBSD, etc. * kernel.org publishes things used to build the kernel and other firmware projects * Faster to download than to build * Also need to support ADA (libgfxinit), Rust, Go (SBOM stuff, 9elements security tooling) * [David] Mainboard variants doc coming along nicely, will hopefully convert to markdown and upload to Gerrit in ~1-2 months: * [https://review.coreboot.org/c/coreboot/+/76200/](https://review.coreboot.or… * [https://docs.google.com/document/d/1ELrZ7WKkZn6zCA9mdpVC6Ze47pg-gvTHanDfLMU… * [Martin, FelixS] We're about 6 weeks out from the next release # Notice Decisions shown here are not necessarily final, and are based on the current information available. If there are questions or comments about decisions made, or additional information to present, please put it on the leadership meeting agenda and show up if possible to discuss it. Of course items may also be discussed on the mailing list, but as it's difficult to interpret tone over email, controversial topics frequently do not have good progress in those discussions. For particularly difficult issues, it may be best to try to schedule another meeting. # coreboot leadership meeting minutes https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgK…

1 0

New Defects reported by Coverity Scan for coreboot
by scan-admin＠coverity.com 07 Jul '23

07 Jul '23

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 1 new defect(s) introduced to coreboot found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 1 of 1 defect(s) ** CID 1516782: (TAINTED_SCALAR) ________________________________________________________________________________________________________ *** CID 1516782: (TAINTED_SCALAR) /util/cbmem/cbmem.c: 1051 in dump_tpm_std_log() 1045 1046 tcg_spec_entry = event_log; 1047 if (!strcmp((const char *)tcg_spec_entry->signature, TCG_EFI_SPEC_ID_EVENT_SIGNATURE)) { 1048 if (tcg_spec_entry->spec_version_major == 2 && 1049 tcg_spec_entry->spec_version_minor == 0 && 1050 le32toh(tcg_spec_entry->event_type) == EV_NO_ACTION) { >>> CID 1516782: (TAINTED_SCALAR) >>> Passing tainted expression "tcg_spec_entry->num_of_algorithms" to "parse_tpm2_log", which uses it as an offset. 1051 parse_tpm2_log(tcg_spec_entry); 1052 } else { 1053 fprintf(stderr, "Unknown TPM2 log specification.\n"); 1054 } 1055 unmap_memory(&log_mapping); 1056 return; /util/cbmem/cbmem.c: 1051 in dump_tpm_std_log() 1045 1046 tcg_spec_entry = event_log; 1047 if (!strcmp((const char *)tcg_spec_entry->signature, TCG_EFI_SPEC_ID_EVENT_SIGNATURE)) { 1048 if (tcg_spec_entry->spec_version_major == 2 && 1049 tcg_spec_entry->spec_version_minor == 0 && 1050 le32toh(tcg_spec_entry->event_type) == EV_NO_ACTION) { >>> CID 1516782: (TAINTED_SCALAR) >>> Passing tainted expression "tcg_spec_entry->digest_sizes" to "parse_tpm2_log", which uses it as a loop boundary. 1051 parse_tpm2_log(tcg_spec_entry); 1052 } else { 1053 fprintf(stderr, "Unknown TPM2 log specification.\n"); 1054 } 1055 unmap_memory(&log_mapping); 1056 return; /util/cbmem/cbmem.c: 1038 in dump_tpm_std_log() 1032 tspec_entry = event_log; 1033 if (!strcmp((const char *)tspec_entry->signature, TCPA_SPEC_ID_EVENT_SIGNATURE)) { 1034 if (tspec_entry->spec_version_major == 1 && 1035 tspec_entry->spec_version_minor == 2 && 1036 tspec_entry->spec_errata >= 1 && 1037 le32toh(tspec_entry->entry.event_type) == EV_NO_ACTION) { >>> CID 1516782: (TAINTED_SCALAR) >>> Passing tainted expression "tspec_entry->vendor_info_size" to "parse_tpm12_log", which uses it as an offset. 1038 parse_tpm12_log(tspec_entry); 1039 } else { 1040 fprintf(stderr, "Unknown TPM1.2 log specification\n"); 1041 } 1042 unmap_memory(&log_mapping); 1043 return; /util/cbmem/cbmem.c: 1038 in dump_tpm_std_log() 1032 tspec_entry = event_log; 1033 if (!strcmp((const char *)tspec_entry->signature, TCPA_SPEC_ID_EVENT_SIGNATURE)) { 1034 if (tspec_entry->spec_version_major == 1 && 1035 tspec_entry->spec_version_minor == 2 && 1036 tspec_entry->spec_errata >= 1 && 1037 le32toh(tspec_entry->entry.event_type) == EV_NO_ACTION) { >>> CID 1516782: (TAINTED_SCALAR) >>> Passing tainted expression "tspec_entry->vendor_info" to "parse_tpm12_log", which uses it as a loop boundary. 1038 parse_tpm12_log(tspec_entry); 1039 } else { 1040 fprintf(stderr, "Unknown TPM1.2 log specification\n"); 1041 } 1042 unmap_memory(&log_mapping); 1043 return; ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0

All Systems Go! 2023 (Berlin, 13/14. 09. 23): Call for Participation ends July 7th
by Paul Menzel 05 Jul '23

05 Jul '23

Dear coreboot folks, *Networking* is also a topic for the ASG! conference. > All Systems Go! 2023 Call for Proposals > > The Call for Participation (CFP) for All Systems Go! 2023 is now > open! Please submit your proposals for consideration. > > The CFP will close on July 7th, 2023. A response will be sent to all > submitters on or before July 14th, 2023. The conference takes place > in 🗺️ Berlin, Germany 🇩🇪 on Sept. 13-14th. > > All Systems Go! 2023 is all about foundational open-source Linux > technologies. We are primarily looking for deeply technical talks by > and for developers, engineers and other technical roles. > > We focus on the userspace side of things, so while kernel topics are > welcome they must have clear, direct relevance to userspace. The > following is a non-comprehensive list of topics encouraged for 2023 > submissions: > > * Image-Based Linux 🖼️ > * Secure and Measured Boot 📏 > * TPM-Based Local/Remote Attestation, Encryption, Authentication 🔑 > * Low-level container executors and infrastructure ⚙️. > * IoT, embedded and server Linux infrastructure > * Reproducible builds 🔧 > * Package management, OS, container 📦, image delivery and updating > * Building Linux devices and applications 🏗️ > * Low-level desktop 💻 technologies > * Networking 🌐 > * System and service management 🚀 > * Tracing and performance measuring 🔍 > * IPC and RPC systems 🦜 > * Security 🔐 and Sandboxing 🏖️ > > Format: submissions must be in one of three formats: 35min talk + 5 > min Q&A, 20min talk + 5 min Q&A, and 5min lightning talks. > > Please familiarize yourself with our Code of Conduct as all speakers > and attendees are expected to abide by it. > > You can enter proposals until 2023-07-07 23:59 (UTC) Some community members are even located in Berlin, and a lot in Germany or Poland, so it is a great way to make coreboot and FLOSS firmware more known. I am planning on submitting a lightning talk about coreboot, but if somebody is also interested in giving a longer talk, and does not want to do it alone, please ping me. Kind regards, Paul [1]: https://cfp.all-systems-go.io/all-systems-go-2023/cfp

1 0

DUG #2 + vPub v7 opensource online Party! - 6th July at 4 PM UTC
by Mike Banon 05 Jul '23

05 Jul '23

Dear friends, I invite you to a joint DUG #2 + vPub v7 event that will start this Thursday at 4PM UTC. Would you like to learn more about: * the opensource firmware world and its current events, i.e. the recent opensource firmware developments *(OpenSIL)* for new AMD PCs? * interesting open hardware devices like Nitrokey opensource security tokens? Then this upcoming event - is an excellent opportunity for you to have a great time in the company of fellow firmware enthusiasts. The 1st part of our event - DUG #2 - is dedicated to Dasharo distribution of coreboot opensource firmware with advanced features like GUI & FLASHBIOS and the ecosystem around it. DUG will take place between 4-6 PM UTC - and then around 6 PM UTC will switch to vPub. The past events have been highly successful, and I'm sure you will find this time interesting as well ;-) Both sound/video and text chats will be available for your convenience More details and Join links are available here - https://vpub.dasharo.com/e/7/dasharo-user-group-2 -- Best regards, Mike Banon Open Source Community Manager of 3mdeb - https://3mdeb.com/

1 0

Potential EC refactor for Lenovo laptops
by Avery 30 Jun '23

30 Jun '23

Hello, I've been reverse-engineering the ThinkPad X230's MEC 1619 EC firmware (G2HT35WW) and the UEFI binaries which interface with it on ports 62h/66h and 1600h/1604h. In particular I've been looking at the process for flashing new EC firmware, referencing the public MEC1618 datasheet[1], so I could try to flash new EC firmware on a corebooted ThinkPad; the relevant binaries are the following: * EcFwUpdateDxe 0C396FCA-6BDA-4A15-B6A3-A6FA4544BDB7 * EcIoDxe 114CA60C-D965-4C13-BEF7-C4062248E1FA * Installs a native protocol interface 3161DDAB-9600-4301-AAB2-93006395824A * EcIoSmm 03EBDB4B-96BA-4F40-8329-7F3AA8865707 * Installs a native protocol interface AADE7C97-98E7-4CFA-B4EF-BBE20506A31D From this, I found that these binaries uses at least some of the the EC register layout for Quanta's firmware for IT8518 ECs (ec/quanta/it8518/acpi/ec.asl), which is included in mb/google/stout. The stout codename refers to ThinkPad X131e, which are also Ivy Bridges, and also has a different mainboard tree in mb/lenovo/x131e which separately uses ec/lenovo/h8/acpi/ec.asl. The X230 mainboard also uses the H8S ASL. Both the H8S and IT8518 definitions line up pretty well for the most part, but here are also some evidence from my reversing on the X230: EcIoDxe exposes a function that appears to implement the SMBus Host Controller Interface specifications. The following are the EC registers used there: * 50h SMB_PRTCL * 51h SMB_STS * 52h SMB_ADDR * 53h SMB_CMD * 54h-73h SMB_DATA * 74h SMB_BCNT EcFwUpdateDxe also updates the register at 3Dh, bitwise-orring it with DFh. This action is said to restrict EC flash access past the boot sequence [2], and lines up with the description of "Password Control" given by the IT8518 ASL. Since the H8 configuration appears to be common across multiple boards, I believe these two can be merged seeing as the IT8518 definitions are a bit more detailed, potential mainboard-specific quirks notwithstanding. I'm curious to hear if there would be any issues or incompatibilities with this. Cheers, Avery [1]: https://ww1.microchip.com/downloads/aemDocuments/documents/OTH/ProductDocum… [2]: https://i.blackhat.com/USA-19/Thursday/us-19-Matrosov-Breaking-Through-Anot…

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot