coreboot

coreboot@coreboot.org

6 participants
39686 discussions

[coreboot - Bug #327] MBOX3, OperationRegion (OPRG, SystemMemory, ASLS, 0x2000) causes windows uefi tianocore BSOD ACPI_BIOS_ERROR
by Mat Phillips 19 Jun '22

19 Jun '22

Issue #327 has been updated by Mat Phillips. Matt DeVillier wrote in #note-6: > > When set to 0x1000 windows UEFI tianocore mode boots fine > > This seems to be a board-specific issue rather than platform or tree-wide issue. The IGD OpRegion spec published by Intel themselves specifies that the reserved region starting at ASLS is 0x2000 in size - see: https://01.org/sites/default/files/documentation/acpi_igd_opregion_spec_0.p… p16. I can agree that I tried this 0x1000 change and it had no affect on the problem. ---------------------------------------- Bug #327: MBOX3, OperationRegion (OPRG, SystemMemory, ASLS, 0x2000) causes windows uefi tianocore BSOD ACPI_BIOS_ERROR https://ticket.coreboot.org/issues/327#change-973 * Author: xinhua wang * Status: New * Priority: Normal * Start date: 2021-12-30 ---------------------------------------- https://review.coreboot.org/c/coreboot/+/27711/7/src/drivers/intel/gma/acpi… this line .. OperationRegion (OPRG, SystemMemory, ASLS, 0x2000) the 0x2000 will cause BSOD ACPI_BIOS_ERROR when booting installer, os, etc When set to 0x1000 windows UEFI tianocore mode boots fine ---Files-------------------------------- dmesg.txt (76.9 KB) results.log (204 KB) -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account

1 0

[coreboot - Bug #327] MBOX3, OperationRegion (OPRG, SystemMemory, ASLS, 0x2000) causes windows uefi tianocore BSOD ACPI_BIOS_ERROR
by Matt DeVillier 19 Jun '22

19 Jun '22

Issue #327 has been updated by Matt DeVillier. > When set to 0x1000 windows UEFI tianocore mode boots fine This seems to be a board-specific issue rather than platform or tree-wide issue. The IGD OpRegion spec published by Intel themselves specifies that the reserved region starting at ASLS is 0x2000 in size - see: https://01.org/sites/default/files/documentation/acpi_igd_opregion_spec_0.p… p16. Additionally, other SNB/IVB boards (such as google/link and samsung/stumpy) have no issues booting Windows via Tianocore with the correct OpRegion size set. So, I suspect something else in the x230 ACPI code is overlapping with the IGD OpRegion and causing the BSOD ---------------------------------------- Bug #327: MBOX3, OperationRegion (OPRG, SystemMemory, ASLS, 0x2000) causes windows uefi tianocore BSOD ACPI_BIOS_ERROR https://ticket.coreboot.org/issues/327#change-972 * Author: xinhua wang * Status: New * Priority: Normal * Start date: 2021-12-30 ---------------------------------------- https://review.coreboot.org/c/coreboot/+/27711/7/src/drivers/intel/gma/acpi… this line .. OperationRegion (OPRG, SystemMemory, ASLS, 0x2000) the 0x2000 will cause BSOD ACPI_BIOS_ERROR when booting installer, os, etc When set to 0x1000 windows UEFI tianocore mode boots fine ---Files-------------------------------- dmesg.txt (76.9 KB) results.log (204 KB) -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account

1 0

[coreboot - Bug #327] MBOX3, OperationRegion (OPRG, SystemMemory, ASLS, 0x2000) causes windows uefi tianocore BSOD ACPI_BIOS_ERROR
by Pawel Radomychelski 19 Jun '22

19 Jun '22

Issue #327 has been updated by Pawel Radomychelski. xinhua wang wrote: > https://review.coreboot.org/c/coreboot/+/27711/7/src/drivers/intel/gma/acpi… > > this line .. OperationRegion (OPRG, SystemMemory, ASLS, 0x2000) > the 0x2000 will cause BSOD ACPI_BIOS_ERROR when booting installer, os, etc > > When set to 0x1000 windows UEFI tianocore mode boots fine For the reference: It might be the same (or similar) bug like Bug #392 (same bug but in SeaBIOS). Setting ``` shell OperationRegion (OPRG, SystemMemory, ASLS, 0x1000 ``` doesn't solve the Bug #392 ---------------------------------------- Bug #327: MBOX3, OperationRegion (OPRG, SystemMemory, ASLS, 0x2000) causes windows uefi tianocore BSOD ACPI_BIOS_ERROR https://ticket.coreboot.org/issues/327#change-971 * Author: xinhua wang * Status: New * Priority: Normal * Start date: 2021-12-30 ---------------------------------------- https://review.coreboot.org/c/coreboot/+/27711/7/src/drivers/intel/gma/acpi… this line .. OperationRegion (OPRG, SystemMemory, ASLS, 0x2000) the 0x2000 will cause BSOD ACPI_BIOS_ERROR when booting installer, os, etc When set to 0x1000 windows UEFI tianocore mode boots fine ---Files-------------------------------- dmesg.txt (76.9 KB) results.log (204 KB) -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account

1 0

[coreboot - Bug #318] (Resolved) denverton_ns: Fix MRC cache write
by Angel Pons 18 Jun '22

18 Jun '22

Issue #318 has been updated by Angel Pons. Status changed from Response Needed to Resolved Marked as resolved, I don't know if backports are done yet. ---------------------------------------- Bug #318: denverton_ns: Fix MRC cache write https://ticket.coreboot.org/issues/318#change-967 * Author: King Sumo * Status: Resolved * Priority: Normal * Start date: 2021-09-02 ---------------------------------------- The RW_MRC_CACHE write is broken in denverton_ns platforms. More info: https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/message/26Y… https://review.coreboot.org/c/coreboot/+/57033 (patch set as abandoned, it was already agreed with Mariusz to proceed the codereview process). -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account

1 0

NULL pointer deref in soc/intel/skylake/irq.c
by Benjamin Doron 18 Jun '22

18 Jun '22

Hi all, `src/soc/intel/skylake/irq.c:soc_irq_settings()` dereferences NULL by memcpy'ing devintconfig to params->DevIntConfigPtr. As far as I can tell, this happens because we're copying a structure onto a UPD that's actually just the pointer, rather than assigning the UPD to the buffer. devintconfig is static, so will `params->DevIntConfigPtr = devintconfig` work? It would point inside the data section, as I understand. Alternatively, calling `malloc()` first should work. I'm away from my computer now, so I can't test these alternatives yet. Best regards, Benjamin

2 1

Automated Engineering Notes was Re: Deprecation of the Intel Quark SoC
by Karl Semich 18 Jun '22

18 Jun '22

I'm not working on this but am still interested in the idea, in my hobby capacity. The below emails were exchanged. I didn't yet receive further reply. ---------- Forwarded message --------- Date: Sun, Apr 24, 2022, 10:31 AM Subject: Re: [coreboot] Re: Deprecation of the Intel Quark SoC To: Karl Semich <0xloem(a)gmail.com> I'm very interested in your ideas. Yep, I"m interested, I've been trying to find someone interested in this for 5 years now ---------- Forwarded message --------- Date: Sun, Apr 24, 2022, 10:32 AM Subject: Re: [coreboot] Re: Deprecation of the Intel Quark SoC To: Karl Semich <0xloem(a)gmail.com> I think we should start with a binary blob for an open system like the allwinner d1. We have the blob, it's pretty simple code. ---------- Forwarded message --------- From: *Karl Semich* <0xloem(a)gmail.com> Date: Sun, Apr 24, 2022, 2:41 PM Subject: Re: [coreboot] Re: Deprecation of the Intel Quark SoC hi is this too many words below? are you still interested? how do you feel about making the conversation more public? my biggest issue is neurological and psychological, it's had for me to do things, so the more people the better the transformer model approach works on data. they need a lot of examples of something to begin copying well, thousands or millions or more. it seems fewer and fewer examples are needed the more similar data a model has been trained on already, down to finally needing none. ("few-shot", "zero-shot"). so one could take a pretrained model and e.g. adjust it (via training) to predict comments from uncommented code, or predict source from binaries of an architecture where more binaries are available, or from a specific set of compilers compiler where many training binaries could be generated from commented code. then by combining these separate models one might likely be able to perform a task on which less data is available. for me at this point, finding or generating that data, and finding paths to fit the model better to the target tasks, seems equally challenging compared to just setting up a basic training framework to fine tune models. there are a few different infrastructures, and sometimes people make their own if doing a new kind of task. most people are using jupyter notebooks via various online portals. there are also compute servers at places like vast.ai. but I am out of money and most of my devices are very low end. I expect this to happen and am interested in helping it happen but i'll be pretty slow and flaky on my own :) do you have any thoughts on generating or finding data similar to many pairings of embedded binary blobs and license-free interface specifications? is the allwinner d1 much data? most of the similar models I know of out there continue streams of human text or source code pick selecting up to 2048 words from a fixed vocabulary maybe 10k to 100k words large. There are many known techniques to extend this to more words but finding and implementing them is part of the effort. This also informs how to pick or develop a training framework: something that makes it easier to rearchitect the models will be needed to work with or generate data larger than 2048 symbols long. the challenge of lengthening may also be postponeable if the meaningful patterns of the data can be squeezed to fit within that size, as is done for human text in the mainstream. the model may learn appropriate patterns and then take only a little further adjustment to handle larger ones once rearchitectured to do so. ---------- Forwarded message --------- From: *Karl Semich* <0xloem(a)gmail.com> Date: Sun, Apr 24, 2022, 2:58 PM Subject: Re: [coreboot] Re: Deprecation of the Intel Quark SoC Basically, there's a class of neural networks called transformer models that have become mainstream for successfully solving problems across domains. Common systems used to work with them that I'm aware of include pytorch, jax, huggingface transformers, keras, and tensorflow: all python libraries. A number of groups are offering hubs where people share pretrained models for others to use. I've heard https://fast.ai/ has a good starting course, but it didn't quite seem for me, I haven't taken it. I think most people are learning from example jupyter notebooks. I've mostly learned by skimming the huggingface transformers source code and occasional research papers. Each transformer model is roughly made of "layers" of "self attention" , which is roughly just a class of a few operations performed on data represented as matrices, and then passed to the next layer where the operations are performed again. Each layer has many "weights" -- coefficients -- which are how the model "learns", by backpropagating gradients to adjust their values. A big thing appears to have been how to organise the beginning and end of the chain. The models usually have something different on both ends, to process the input or output data between the internal representation of huge matrices of floating point numbers. It seems important to do this in a way that preserves the meaning of the data well, and often a couple other neural network parts are used -- very short algorithms that can operate with trainable coefficients on large matrices. The basic takeaway is that transformer models use an algorithm called "self attention" to combine mutating data matrices with trained matrices, in sequential layers like a pipeline, and these chunks of attention have been found to be able to adjust themselves to pretty much any task, if they have good data and enough quantity. As stated previously most of the mainstream code out there gets unwieldy if there are more than 2048 input or output elements, and there are many changes explored around that but I'm not aware of one having been settled upon. ---------- Forwarded message --------- Date: Sun, Apr 24, 2022, 2:49 PM Subject: Re: [coreboot] Re: Deprecation of the Intel Quark SoC To: Karl Semich <0xloem(a)gmail.com> you don't want to RE a binary, that gets you into trouble. But you are allowed to RE from the activity, basically memory reads and writes. That's turning observation into code. So, that's the first challenge. ---------- Forwarded message --------- From: *Karl Semich* <0xloem(a)gmail.com> Date: Sun, Apr 24, 2022, 3:01 PM Subject: Re: [coreboot] Re: Deprecation of the Intel Quark SoC I agree that's preferable, but I don't have a simulator or a circuit logger at this time. Do you have these things? I understand it's legal to re-engineer if the reverse engineer keeps their work private, sharing only an interface specification. Is this your experience? ---------- Forwarded message --------- From: *Karl Semich* <0xloem(a)gmail.com> Date: Mon, Apr 25, 2022, 5:34 AM Subject: Re: [coreboot] Re: Deprecation of the Intel Quark SoC On Sun, Apr 24, 2022, 10:31 AM wrote: I'm very interested in your ideas. Yep, I"m interested, I've been trying to find someone interested in this for 5 years now I think I kind of glossed over this; what approaches have you pursued already? What challenges did you encounter? On Sun, Apr 24, 2022, 2:49 PM wrote: you don't want to RE a binary, that gets you into trouble. But you are allowed to RE from the activity, basically memory reads and writes. That's turning observation into code. So, that's the first challenge. I didn't realize that serialice does this already. It looks like serialice's qemu patches make it pretty easy to probe firmware behavior. We could start training on normal open-source blobs and generate random working code to augment the data. ---------- Forwarded message --------- From: *Karl Semich* <0xloem(a)gmail.com> Date: Mon, Apr 25, 2022, 5:40 AM Subject: Re: [coreboot] Re: Deprecation of the Intel Quark SoC On Sun, Apr 24, 2022, 10:32 AM wrote: I think we should start with a binary blob for an open system like the allwinner d1. We have the blob, it's pretty simple code. I websearched this chip; it seems it's RISC-V. I think that means that serialice's qemu patches wouldn't work with it out of the box. Do you know how to hook i/o accesses for RISC-V in qemu? If the first step is patching qemu it seems it might make more sense to start with an x86 chip? ---------- Forwarded message --------- Date: Mon, Apr 25, 2022, 10:02 AM Subject: Re: [coreboot] Re: Deprecation of the Intel Quark SoC The x86 are fiendishly complex. There is in development an open source version of the memory setup code for the D1, so it would be possible to create a proof of concept by logging all the memory rights that are done to set up dram. I'm pretty familiar with the many types of dram startup and I would prefer if possible to start with the all winter D1 startup. ---------- Forwarded message --------- From: *Karl Semich* <0xloem(a)gmail.com> Date: Mon, Apr 25, 2022, 10:30 AM Subject: Re: [coreboot] Re: Deprecation of the Intel Quark SoC I websearched but didn't find the open firmware yet. Where's it at? You didn't mention an emulation environment, so I was thinking of how the logging would be done. I think the cpu or architecture actually wouldn't matter at all if you have enough example source, and instrument them to log their writes and reads. The relevent task here seems to be collecting firmware examples that can be expressed in blocks smaller than 2048 tokens, and logging their runs on host hardware with instrumented reads and writes. I'm thinking on this a little, not quite sure yet how to approach it. ---------- Forwarded message --------- Date: Mon, Apr 25, 2022, 10:34 AM Subject: Re: [coreboot] Re: Deprecation of the Intel Quark SoC To: Karl Semich <0xloem(a)gmail.com> You are helping me refine my thinking. We need a cheap platform, that has lots of people involved, that would let us do this test. I would still suggest something like the lichee r5 or similar allwinner-based platform ---------- Forwarded message --------- From: *Karl Semich* <0xloem(a)gmail.com> Date: Mon, Apr 25, 2022, 10:40 AM Subject: Re: [coreboot] Re: Deprecation of the Intel Quark SoC the hits I get for lichee r5 seem to mostly be in chinese, a language I haven't learned what do you think of the idea of setting up some scripts to instrument firmware sources for a lot of different platforms? ---------- Forwarded message --------- From: *Karl Semich* <0xloem(a)gmail.com> Date: Mon, Apr 25, 2022, 11:17 AM Subject: Re: [coreboot] Re: Deprecation of the Intel Quark SoC here is my present nascent idea, unsure: - instrument sources to log their writes and reads, and use the logs as input data - during compilation, use inotify to log which files are read from, and use these files as output data to train - change to different source history points and shuffle configuration options to produce more data - if needed, a larger model is bigbird: https://huggingface.co/docs/transformers/model_doc/bigbird_pegasus this can handle 4096 tokens of input+output - when input data is too large, add further trainable models to shrink it to fewer inputs as their output - when output data is too large, parameterise the generation to generate only part at once - run the code in qemu for the architecture so as to generate data for multiple architectures - if timing is important and the instrumentation changes the timing, this could be measured and compensated for arithmetically i'm a little confused on how logging might work in qemu. thinking of changing bootblock assembler to log things. seems this would best be done via a debugger with qemu that can act on the instructions themselves, not sure. it seems it might also be good to measure code coverage so as to train only around code that is actually executed. given there is a lot of hidden behavior, structures mutated without port writes, it could be good to err on the side of more data and more training expense. or if things are limited to ordered port writes, it could be incredibly simple. it seems to me x86 or arm makes more sense, so the code blocks could be executed on a normal consumer system.

2 2

[BUG] clear_memory triggers handle_deref_breakpoint()
by Petr Cvek 17 Jun '22

17 Jun '22

Clearing the memory creates a situation, where an access to NULL pointer is actually valid. This causes a warning in the log: clear_memory: Clearing DRAM 0000000000000000-0000000000005000 Null dereference at eip: 0x7f3ca51d clear_memory: Clearing DRAM 000000000000a000-00000000000a0000 Should the test be disabled during clear_mem()? Petr

1 0

New Defects reported by Coverity Scan for coreboot
by scan-admin＠coverity.com 17 Jun '22

17 Jun '22

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 1490122: Integer handling issues (OVERFLOW_BEFORE_WIDEN) /src/soc/intel/alderlake/systemagent.c: 305 in get_dpr_size() ________________________________________________________________________________________________________ *** CID 1490122: Integer handling issues (OVERFLOW_BEFORE_WIDEN) /src/soc/intel/alderlake/systemagent.c: 305 in get_dpr_size() 299 } 300 uint64_t get_dpr_size(struct device *dev) 301 { 302 uint64_t size; 303 uint32_t dpr_reg = pci_read_config32(dev, DPR_REG); 304 uint32_t size_field = (dpr_reg & MASK_DPR_LENGTH) >> MASK_DPR_LENGTH_LSB; >>> CID 1490122: Integer handling issues (OVERFLOW_BEFORE_WIDEN) >>> Potentially overflowing expression "size_field * 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). 305 size = size_field * MiB; 306 return size; ** CID 1490121: Integer handling issues (OVERFLOW_BEFORE_WIDEN) /src/soc/intel/alderlake/systemagent.c: 254 in get_dsm_size() ________________________________________________________________________________________________________ *** CID 1490121: Integer handling issues (OVERFLOW_BEFORE_WIDEN) /src/soc/intel/alderlake/systemagent.c: 254 in get_dsm_size() 248 uint32_t reg32 = pci_read_config32(dev, GGC); 249 uint64_t size; 250 uint32_t size_field = (reg32 & MASK_DSM_LENGTH) >> MASK_DSM_LENGTH_LSB; 251 if (size_field <= 0x10) { // 0x0 - 0x10 252 size = size_field * 32 * MiB; 253 } else if ((size_field >= 0xF0) && (size_field >= 0xFE)) { >>> CID 1490121: Integer handling issues (OVERFLOW_BEFORE_WIDEN) >>> Potentially overflowing expression "(size_field - 239U) * 4U * 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). 254 size = (size_field - 0xEF) * 4 * MiB; 255 } else { 256 switch (size_field) { 257 case 0x20: 258 size = 1 * GiB; 259 break; ** CID 1490120: Resource leaks (RESOURCE_LEAK) /payloads/libpayload/tests/libcbfs/cbfs-verification-test.c: 217 in test_cbfs_map_valid_hash_impl() ________________________________________________________________________________________________________ *** CID 1490120: Resource leaks (RESOURCE_LEAK) /payloads/libpayload/tests/libcbfs/cbfs-verification-test.c: 217 in test_cbfs_map_valid_hash_impl() 211 mapping = cbfs_map(TEST_DATA_1_FILENAME, &size); 212 assert_non_null(mapping); 213 assert_int_equal(TEST_DATA_1_SIZE, size); 214 assert_memory_equal(test_data_1, mapping, size); 215 cbfs_unmap(mapping); 216 } >>> CID 1490120: Resource leaks (RESOURCE_LEAK) >>> Variable "mapping" going out of scope leaks the storage it points to. 217 } 218 219 static void test_cbfs_map_valid_hash(void **state) 220 { 221 test_cbfs_map_valid_hash_impl(state, false); 222 } ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0

[coreboot - Bug #318] denverton_ns: Fix MRC cache write
by King Sumo 15 Jun '22

15 Jun '22

Issue #318 has been updated by King Sumo. King Sumo wrote in #note-1: > Fixed: > > ommit 3990da0bfe18e3b76751fd35fef9e5ec55c2fd29 > Author: Kyösti Mälkki <kyosti.malkki(a)gmail.com> > Date: Mon Nov 15 17:25:54 2021 +0200 > > soc/intel/denverton_ns: Fix MRC_RW_CACHE > > It is required to set WPD (Write Protect Disable) bit > to make it possible to use MRC_RW_CACHE region with > CACHE_MRC_SETTINGS=y. > > Change-Id: Iacab44b00d08c9bdc18bc3bdcb88833634c0b02e > Signed-off-by: Kyösti Mälkki <kyosti.malkki(a)gmail.com> > Reviewed-on: https://review.coreboot.org/c/coreboot/+/60091 > Tested-by: build bot (Jenkins) <no-reply(a)coreboot.org> > Reviewed-by: Angel Pons <th3fanbus(a)gmail.com> Please someone close this ticked, I guess only may developers can do this. ---------------------------------------- Bug #318: denverton_ns: Fix MRC cache write https://ticket.coreboot.org/issues/318#change-960 * Author: King Sumo * Status: Response Needed * Priority: Normal * Start date: 2021-09-02 ---------------------------------------- The RW_MRC_CACHE write is broken in denverton_ns platforms. More info: https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/message/26Y… https://review.coreboot.org/c/coreboot/+/57033 (patch set as abandoned, it was already agreed with Mariusz to proceed the codereview process). -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account

1 0

[coreboot - Bug #318] (Response Needed) denverton_ns: Fix MRC cache write
by King Sumo 15 Jun '22

15 Jun '22

Issue #318 has been updated by King Sumo. Status changed from New to Response Needed ---------------------------------------- Bug #318: denverton_ns: Fix MRC cache write https://ticket.coreboot.org/issues/318#change-959 * Author: King Sumo * Status: Response Needed * Priority: Normal * Start date: 2021-09-02 ---------------------------------------- The RW_MRC_CACHE write is broken in denverton_ns platforms. More info: https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/message/26Y… https://review.coreboot.org/c/coreboot/+/57033 (patch set as abandoned, it was already agreed with Mariusz to proceed the codereview process). -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account

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