Nico Huber has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/31822 )
Change subject: soc/intel/braswell/acpi/lpc.asl: Allocate used ROM size only ......................................................................
Patch Set 4:
Patch Set 4:
Patch Set 4:
This looks like a severe compiler bug, please don't just work around it. It seems the compiler precalcu- lates the correct numbers, but places 0s into the Memory32Fixed resource and the numbers after it, amidst the bytestream:
Buffer that contains 14B: 11 11 0a 0e The memory range filled with 0s: 86 09 00 00 00 00 00 00 00 00 00 00 End Tag: 79 00 After the buffer our numbers: 00 00 80 ff 00 00 80 00
Please let me know if you don't want to check if the issue persists upstream and report this.
(How did you generate this bytestream?)
Make deletes the file after the failed build, but you should be able to get it back with:
cd build/; /path/to/your/xgcc/bin/iasl -vw 3150 -we -p dsdt.aml dsdt.asl
I would expect this behavoir. Compiler will create RBUF with 0s. Run-time this buffer will be filled.
There is no runtime code and Memory32Fixed only contains 32-bit numbers and never code by definition.
Can you clarify why it looks like a bug?
After the buffer ends, _CRS is done and we are back at the device scope. And there it puts these numbers. Not even encoded as AML integers but plain 32-bit words. If the compiler wanted to do it at runtime, it would have to emit code like yours in patch set 4.
Now that I think about it again, somehow you managed to build patch set 1 and also Jenkins to build patch set 2. So maybe it is fixed already in a newer version of the compiler and some Jenkins node still runs an old version?