[coreboot] Re: Fwd: Issues with ACPI _CRS and E820 memory map
We will need to define the "hidden" entry in host _crs to be match with E820 "reserved" entry? They may cause some manual work, maybe we can have some code change to make it automatically? Tim Wawrzynczak via coreboot 于2022年8月23日周二 04:27写道： > Hello fellow coreboot folks, > > I recently received this message from some associates in the Linux kernel > community which describes > a bug in coreboot firmware for many Intel boards. The gist of it related > to inconsistencies between the > hostbridge's _CRS method in ACPI and the E820 table (although technically > generated by the payload, > the e820 table is generally, AFAIK, converted straight from the > LB_TAG_MEMORY entry > in the coreboot table by most payloads). > > I have some thoughts on how to address this, but I would like to hear the > community's thoughts first. > > Thanks, > -Tim > > -- Forwarded message - > From: Bjorn Helgaas > Date: Thu, Aug 11, 2022 at 12:30 PM > Subject: Issues with ACPI _CRS and E820 memory map > To: > Cc: Hans de Goede , Myron Stowe , > Kai-Heng Feng , Andy Shevchenko < > andriy.shevche...@linux.intel.com>, , < > linux-ker...@vger.kernel.org> > > > This is a heads-up about what I think is a firmware defect in the way > some platforms build _CRS methods. We've had a Linux workaround for > several years, but the workaround breaks some new machines, so the > workaround will be disabled for 2023 and newer machines. > > Machines that depend on the workaround include: > > - Dell Precision T3500 > - Lenovo ThinkPad X1 Gen 2 > - Asus C523NA (Coral) Chromebook > - Likely any machine using coreboot firmware > > The current versions of the machines above work fine, but 2023 > versions with similar firmware are likely to break unless the firmware > changes. Please forward this to any firmware folks who may be able to > help with this issue. > > Bjorn > > > SUMMARY > > A Linux change will break future platforms that rely on the E820 memory > map to exclude portions of the PCI host bridge windows reported by ACPI > _CRS methods. > > Linux discovers PCI host bridge MMIO windows by evaluating the _CRS > method of the ACPI PNP0A03 device that describes the host bridge. It > uses these windows to assign address space to PCI BARs. > > In some cases these _CRS methods are incomplete or incorrect, and it's > hard for an OS to work around this. > > Below are examples of typical problems with _CRS methods. > > PLATFORMS REPORT NON-WINDOW SPACE VIA _CRS > > Sometimes _CRS includes host bridge register space or space assigned to > hidden PCI devices that are not enumerable by the OS. When an OS assigns > this space to PCI devices, it may cause conflicts or devices may not > work. This appears to be a firmware defect. > > Many platforms report this non-window space as "reserved" in the E820 > memory map, and since 2010, Linux has worked around the _CRS defect by > excluding these E820 "reserved" regions from the host bridge MMIO > windows [4]. > > Example 1: > > _CRS includes space that's not usable for PCI devices [1]: > > E820: [mem 0xdceff000-0xdfa0] reserved > PNP0A08 _CRS: [mem 0xdfa0-0xfebf] > > Note that [mem 0xdfa0-0xdfa0] is included in both the E820 > entry and _CRS. > > If Linux assigns [mem 0xdfa0-0xdfbf] to a PCI device, the > system doesn't resume correctly from suspend. If Linux avoids the > [mem 0xdfa0-0xdfa0] area and instead assigns > [mem 0xdfb0-0xdfcf], resume works correctly. > > Example 2: > > _CRS includes space assigned to a "hidden" PCI device [2, 5]: > > PCI: 00:0d.0 10 base d000 limit d0ff mem (fixed) # BIOS log > > E820: [mem 0xd000-0xd0ff] > PNP0A08 _CRS: [mem 0x8000-0xe000] > > The 00:0d.0 device is assigned the [mem 0xd000-0xd0ff] space, > but the device is hidden so the OS cannot enumerate it, so the OS > doesn't know what space the device consumes. > > PLATFORMS SUPPLY E820 ENTRIES COVERING ENTIRE _CRS WINDOWS > > Some recent platforms supply E820 "reserved" regions that cover entire > PCI host bridge windows. If Linux excludes these E820 regions from the > windows, it cannot assign space to PCI BARs, which means hot-added > devices don't work. > > Example 3: > > E820 has a "reserved" region that completely covers the 32-bit MMIO > window from _CRS [3]: > > E820: [mem 0x4bc5-0xcfff] reserved > PNP0A08 _CRS: [mem 0x6540-0xbfff] > > Historically, Linux has avoided putting PCI devices in E820 reserved > regions to avoid the problems in examples 1 and 2. Avoiding those > regions in this case means Linux can't assign space for hot-added > devices, so they don't work. > > LINUX PLANS > > As far as I know, the ACPI spec does not require an OS to exclude space > from _CRS resources based on the E820 memory map,
[coreboot] [coreboot - Bug #392] coreboot 4.17 - SeaBIOS Windows 10 BSOD "ACPI Error"
Issue #392 has been updated by Lance Zhao. Do we believe we need to have extra protection to check A4GB is not zero as well? Need to see the debug print about A4GB and A4GS at this point. Lance Pawel Radomychelski 于2022年7月24日周日 17:00写道： > Issue #392 has been updated by Pawel Radomychelski. > > > дуже дякую, Олексанре! > > Thank you very much, Oleksandr for bisecting the problem! > > hope the fix will be applied to the master branch! > > Kind regards > > Pawel Radomychelski > > On July 24, 2022 at 9:19 AM Olexandr Nesterenko < [coreb...@fe80.eu]( > http://coreb...@fe80.eu) > wrote: > > Issue #392 has been updated by Olexandr Nesterenko. > > I use t420 with Ivy Bridge CPU > Run bisect 4.16 - 4.17 and result: > `# first bad commit: [f8daf86282c1be33643ace4e9f453e7548cab41c] > nb/intel/sandybridge/acpi: Support setting PCI bars above 4G` > After this commit i have BSOD ACPI Error. > > > Bug #392: coreboot 4.17 - SeaBIOS Windows 10 BSOD "ACPI Error" > [ > https://ticket.coreboot.org/issues/392#change-1048](https://ticket.coreboot.org/issues/392#change-1048) > > * Author: Pawel Radomychelski > * Status: New > * Priority: Normal > * Category: board support > * Target version: 4.17 > * Start date: 2022-06-18 > * Affected versions: 4.17, master > * Related links: [ > https://ticket.coreboot.org/issues/327](https://ticket.coreboot.org/issues/327) > * Affected hardware: Lenovo ThinkPad X230 Tablet > * Affected OS: Windows 10 > > Since CoreBoot 4.16 my Windows 10 cant boot from SeaBios, i get BSOD with > "ACPI Error" very early. > > Don't know which commit exactly brakes ACPI, but i can say, that in my > CoreBoot 4.15 Image from 11/09/2021 Windows 10 is booting just fine from > SeaBIOS. > Some time later under CoreBoot 4.16 i saw that windows is BSODing. Tried > yesterday with CoreBoot 4.17 and its still broken. > > I think, since CB4.16 there is something broken in ACPI. As i read, the > problem is, that ACPI reserves some memory area, which in Windows is > reserved for the system. > > This [[ [ > https://ticket.coreboot.org/issues/327](https://ticket.coreboot.org/issues/327) > ]] seems to be a similar problem, but the guy is using TianoCore instead of > SeaBIOS. > Changing the line > OperationRegion (OPRG, SystemMemory, ASLS, 0x2000) > to > OperationRegion (OPRG, SystemMemory, ASLS, 0x1000) > doesnt fix it for SeaBios, but fix it for TianoCore. > > ---Files > dmesg_cb415.txt (78.9 KB) > dmesg_cb417.txt (79.9 KB) > .config (19.7 KB) > CB4.17_BSOD.jpg (143 KB) > CB415.log (46.4 KB) > CB417.log (128 KB) > CB416.log (128 KB) > dmesg_cb416.txt (81.8 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](https://ticket.coreboot.org/my/account) > > > Bug #392: coreboot 4.17 - SeaBIOS Windows 10 BSOD "ACPI Error" > https://ticket.coreboot.org/issues/392#change-1049 > > * Author: Pawel Radomychelski > * Status: New > * Priority: Normal > * Category: board support > * Target version: 4.17 > * Start date: 2022-06-18 > * Affected versions: 4.17, master > * Related links: https://ticket.coreboot.org/issues/327 > * Affected hardware: Lenovo ThinkPad X230 Tablet > * Affected OS: Windows 10 > > Since CoreBoot 4.16 my Windows 10 cant boot from SeaBios, i get BSOD with > "ACPI Error" very early. > > Don't know which commit exactly brakes ACPI, but i can say, that in my > CoreBoot 4.15 Image from 11/09/2021 Windows 10 is booting just fine from > SeaBIOS. > Some time later under CoreBoot 4.16 i saw that windows is BSODing. Tried > yesterday with CoreBoot 4.17 and its still broken. > > I think, since CB4.16 there is something broken in ACPI. As i read, the > problem is, that ACPI reserves some memory area, which in Windows is > reserved for the system. > > This [[https://ticket.coreboot.org/issues/327]] seems to be a similar > problem, but the guy is using TianoCore instead of SeaBIOS. > Changing the line > OperationRegion (OPRG, SystemMemory, ASLS, 0x2000) > to > OperationRegion (OPRG, SystemMemory, ASLS, 0x1000) > doesnt fix it for SeaBios, but fix it for TianoCore. > > ---Files > dmesg_cb415.txt (78.9 K
[coreboot] [coreboot - Bug #392] coreboot 4.16 & 4.17 - SeaBIOS Windows 10 BSOD "ACPI Error"
Issue #392 has been updated by Lance Zhao. To save time, you can install a windbg yourself and run !anlyze -v to get the detailed information. Then use !amli dl or other acpi debug provided by windbg itself. Bug #392: coreboot 4.16 & 4.17 - SeaBIOS Windows 10 BSOD "ACPI Error" https://ticket.coreboot.org/issues/392#change-998 * Author: Pawel Radomychelski * Status: New * Priority: Normal * Category: board support * Target version: 4.17 * Start date: 2022-06-18 * Affected versions: 4.16, 4.17, master * Related links: https://ticket.coreboot.org/issues/327 * Affected hardware: Lenovo ThinkPad X230 Tablet * Affected OS: Windows 10 Since CoreBoot 4.16 my Windows 10 cant boot from SeaBios, i get BSOD with "ACPI Error" very early. Don't know which commit exactly brakes ACPI, but i can say, that in my CoreBoot 4.15 Image from 11/09/2021 Windows 10 is booting just fine from SeaBIOS. Some time later under CoreBoot 4.16 i saw that windows is BSODing. Tried yesterday with CoreBoot 4.17 and its still broken. I think, since CB4.16 there is something broken in ACPI. As i read, the problem is, that ACPI reserves some memory area, which in Windows is reserved for the system. This [[https://ticket.coreboot.org/issues/327]] seems to be a similar problem, but the guy is using TianoCore instead of SeaBIOS. Changing the line OperationRegion (OPRG, SystemMemory, ASLS, 0x2000) to OperationRegion (OPRG, SystemMemory, ASLS, 0x1000) doesnt fix it for SeaBios, but fix it for TianoCore. ---Files dmesg_cb415.txt (78.9 KB) dmesg_cb417.txt (79.9 KB) .config (19.7 KB) CB4.17_BSOD.jpg (143 KB) CB415.log (46.4 KB) CB417.log (128 KB) 062322-6125-01.dmp (719 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 ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] [coreboot - Bug #392] coreboot 4.16 & 4.17 - SeaBIOS Windows 10 BSOD "ACPI Error"
Issue #392 has been updated by Lance Zhao.
Output of minidump shows that's not acpi bios error.
4: kd> !analyze -v
***
* *
*Bugcheck Analysis*
* *
***
**DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)**
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If kernel debugger is available get stack backtrace.
Arguments:
Arg1: dd80db3e1760, memory referenced
Arg2: 0002, IRQL
Arg3: , value 0 = read operation, 1 = write operation
Arg4: f8036dea1981, address which referenced memory
Debugging Details:
BUGCHECK_CODE: d1
BUGCHECK_P1: dd80db3e1760
BUGCHECK_P2: 2
BUGCHECK_P3: 0
BUGCHECK_P4: f8036dea1981
READ_ADDRESS: Unable to get NonPagedPoolStart
Unable to get NonPagedPoolEnd
Unable to get PagedPoolStart
Unable to get PagedPoolEnd
dd80db3e1760
CUSTOMER_CRASH_COUNT: 1
PROCESS_NAME: notmyfault64.exe
TRAP_FRAME: fe87853e24a0 -- (.trap 0xfe87853e24a0)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=00730055 rbx= rcx=dd80d340
rdx=0890 rsi= rdi=
rip=f8036dea1981 rsp=fe87853e2630 rbp=0002
r8=dd80e25e2da0 r9= r10=dd80d2c0
r11=dd80db3c1750 r12= r13=
r14= r15=
iopl=0 nv up ei ng nz na po nc
myfault+0x1981:
f803`6dea1981 8b03mov eax,dword ptr [rbx]
ds:`=
Resetting default scope
STACK_TEXT:
fe87`853e2358 f803`70609d69 : `000a dd80`db3e1760
`0002 ` : nt!KeBugCheckEx
fe87`853e2360 f803`70606069 : ` ca09`b6b03740
`0f4d ` : nt!KiBugCheckDispatch+0x69
fe87`853e24a0 f803`6dea1981 : ` ca09`af887080
fe87`853e2730 `0aa0 : nt!KiPageFault+0x469
fe87`853e2630 ` : ca09`af887080 fe87`853e2730
`0aa0 ` : myfault+0x1981
fe87`853e2638 ca09`af887080 : fe87`853e2730 `0aa0
` f803`6dea1d3d : 0x`
fe87`853e2640 fe87`853e2730 : `0aa0 `
f803`6dea1d3d dd80`00730055 : 0xca09`af887080
fe87`853e2648 `0aa0 : ` f803`6dea1d3d
dd80`00730055 `000f00ff : 0xfe87`853e2730
fe87`853e2650 ` : f803`6dea1d3d dd80`00730055
`000f00ff 0001` : 0xaa0
SYMBOL_NAME: myfault+1981
MODULE_NAME: myfault
IMAGE_NAME: myfault.sys
STACK_COMMAND: .cxr; .ecxr ; kb
BUCKET_ID_FUNC_OFFSET: 1981
FAILURE_BUCKET_ID: AV_myfault!unknown_function
OS_VERSION: 10.0.19041.1
BUILDLAB_STR: vb_release
OSPLATFORM_TYPE: x64
OSNAME: Windows 10
FAILURE_ID_HASH: {9745090a-9bce-ccba-c096-ca6e9ca04c64}
Followup: MachineOwner
Bug #392: coreboot 4.16 & 4.17 - SeaBIOS Windows 10 BSOD "ACPI Error"
https://ticket.coreboot.org/issues/392#change-997
* Author: Pawel Radomychelski
* Status: New
* Priority: Normal
* Category: board support
* Target version: 4.17
* Start date: 2022-06-18
* Affected versions: 4.16, 4.17, master
* Related links: https://ticket.coreboot.org/issues/327
* Affected hardware: Lenovo ThinkPad X230 Tablet
* Affected OS: Windows 10
Since CoreBoot 4.16 my Windows 10 cant boot from SeaBios, i get BSOD with "ACPI
Error" very early.
Don't know which commit exactly brakes ACPI, but i can say, that in my CoreBoot
4.15 Image from 11/09/2021 Windows 10 is booting just fine from SeaBIOS.
Some time later under CoreBoot 4.16 i saw that windows is BSODing. Tried
yesterday with CoreBoot 4.17 and its still broken.
I think, since CB4.16 there is something broken in ACPI. As i read, the problem
is, that ACPI reserves some memory area, which in Windows is reserved for the
system.
This [[https://ticket.coreboot.org/issues/327]] seems to be a similar problem,
but the guy is using TianoCore instead of SeaBIOS.
Changing the line
OperationRegion (OPRG, SystemMemory, ASLS, 0x2000)
to
OperationRegion (OPRG, SystemMemory, ASLS, 0x1000)
doesnt fix it for SeaBios, but fix it for TianoCore.
---Files
dmesg_cb415.txt (78.9 KB)
dmesg_cb417.txt
[coreboot] [coreboot - Bug #392] coreboot 4.16 & 4.17 - SeaBIOS Windows 10 BSOD "ACPI Error"
Issue #392 has been updated by Lance Zhao. If we can get a windows crash dump will be easier to debug the issue, we can use windbg to open generated dump file(memory.dmp most of the time). Then the detail info normally included, Bug #392: coreboot 4.16 & 4.17 - SeaBIOS Windows 10 BSOD "ACPI Error" https://ticket.coreboot.org/issues/392#change-988 * Author: Pawel Radomychelski * Status: New * Priority: Normal * Category: board support * Target version: 4.17 * Start date: 2022-06-18 * Affected versions: 4.16, 4.17, master * Related links: https://ticket.coreboot.org/issues/327 * Affected hardware: Lenovo ThinkPad X230 Tablet * Affected OS: Windows 10 Since CoreBoot 4.16 my Windows 10 cant boot from SeaBios, i get BSOD with "ACPI Error" very early. Don't know which commit exactly brakes ACPI, but i can say, that in my CoreBoot 4.15 Image from 11/09/2021 Windows 10 is booting just fine from SeaBIOS. Some time later under CoreBoot 4.16 i saw that windows is BSODing. Tried yesterday with CoreBoot 4.17 and its still broken. I think, since CB4.16 there is something broken in ACPI. As i read, the problem is, that ACPI reserves some memory area, which in Windows is reserved for the system. This [[https://ticket.coreboot.org/issues/327]] seems to be a similar problem, but the guy is using TianoCore instead of SeaBIOS. Changing the line OperationRegion (OPRG, SystemMemory, ASLS, 0x2000) to OperationRegion (OPRG, SystemMemory, ASLS, 0x1000) doesnt fix it for SeaBios, but fix it for TianoCore. ---Files dmesg_cb415.txt (78.9 KB) dmesg_cb417.txt (79.9 KB) .config (19.7 KB) CB4.17_BSOD.jpg (143 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 ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Request help and Support
https://github.com/intel/FSP I am not sure you can use tiger lake fsp on rocket lake or not. Regards, Lance rainhe...@savelife-tech.com 于2022年4月21日周四 17:55写道： > Hello: > I'm Rainhenry Wang from SAVELIFE Technology of Yunnan Co., LTD > Company. We are currently developing a computer motherboard. > Also want to use Coreboot to develop its BIOS firmware. It is based on > Intel's Rocket Lake platform. The PCH model is FH82H510, > and the spec code is SRKM2. However, I did not find Rocket Lake platform > support code in all versions of Coreboot. > So we want to understand and learn in detail how to add the code of > another platform into Coreboot. > I am not sure whether you have relevant learning resources or documents to > share with us? > > Looking forward to your reply. > Thank you very much. > > -- > *SAVELIFE® Technology of Yunnan Co., LTD* > *云南赛莱福科技有限公司* > *王祥福* (Rainhenry Wang) > Tel: +86-13104051251 (Voice calls only support Chinese) > E-mail: rainhe...@savelife-tech.com > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Multi domain PCI resource allocation: How to deal with multiple root busses on one domain
Stack idea is from https://www.intel.com/content/www/us/en/developer/articles/technical/utilizing-the-intel-xeon-processor-scalable-family-iio-performance-monitoring-events.html . In linux, sometimes domain is same as "segment", I am not sure current coreboot on xeon_sp already cover the case of multiple segment yet. Nico Huber 于2022年3月18日周五 02:50写道： > Hi Arthur, > > On 17.03.22 19:03, Arthur Heymans wrote: > > Now my question is the following: > > On some Stacks there are multiple root busses, but the resources need to > be > > allocated on the same window. My initial idea was to add those root > busses > > as separate struct bus in the domain->link_list. However currently the > > allocator assumes only one bus on domains (and bridges). > > In the code you'll see a lot of things like > > > > for (child = domain->link_list->children; child; child = child->sibling) > > > > this is correct, we often (if not always by now) ignore that `link_list` > is a list itself and only walk the children of the first entry. > > > > > This is fine if there is only one bus on the domain. > > Looping over link_list->next, struct bus'ses is certainly an option here, > > but I was told that having only one bus here was a design decision on the > > allocator v4 rewrite. I'm not sure how common that assumption is in the > > tree, so things could be broken in awkward ways. > > I wouldn't say it was a design choice, probably rather a convenience > choice. The old concepts around multiple buses directly downstream of > a single device seemed inconsistent, AFAICT. And at the time the allo- > cator v4 was written it seemed unnecessary to keep compatibility around. > > That doesn't mean we can't bring it back, of course. There is at least > one alternative, though. > > The currently common case looks like this: > > > PCI bus 0 > | > v > > domain 0 --. > |-- PCI 00:00.0 > | > |-- PCI 00:02.0 > | > : > > > Now we could have multiple PCI buses directly below the domain. But > instead of modelling this with the `link_list`, we could also model > it with an abstract "host" bus below the domain device and another > layer of "host bridge" devices in between: > > host bus > | > v > > domain 0 --. > |-- PCI host bridge 0 --. > | |-- PCI 00:00.0 > | | > | `-- PCI 00:02.0 > | > | > |-- PCI host bridge 1 --. > | |-- PCI 16:00.0 > | | > | : > : > > > I guess this would reduce complexity in generic code at the expense of > more data structures (devices) to manage. OTOH, if we'd make a final > decision for such a model, we could also get rid of the `link_list`. > Basically, setting in stone that we only allow one bus downstream of > any device node. > > I'm not fully familiar with the hierarchy on Xeon-SP systems. Would > this be an adequate solution? Also, does the term `stack` map to our > `domain` 1:1 or are there differences? > > Nico > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: "Private" changes on Gerrit are now disabled and removed
Yes, private is a state in between but not a result. I may want to have a "private" commit first before set it to public visible. Christian Walter 于 2021年11月12日周五 下午6:18写道： > Yeah - no. > > The GPL allows you do keep your modifications private as long as you do > not release them in any way. So if these private changes are not released > somewhere they do not need to be public. > > Chris > > > > > Am 12.11.2021 um 11:06 schrieb Keith Emery >: > > > > Your well within your rights not to. I don't believe anyone should be > compelled to expend effort for which they are not compensated. > > > > But would anyone else like to explain why this isn't a GPL violation? > Because it really seems like it is. > > > > > >> On 12/11/21 8:44 pm, Patrick Georgi wrote: > >> 12. November 2021 10:31, "Keith Emery" > schrieb: > >>> I'm fairly sure it say's 'you must publish the source code AND any > changes'. Did that change at some point? > >> I'm fairly sure that you don't understand the conditions under which > the GPL takes effect. Since I'm not your lawyer, I won't discuss this with > you any further. > > ___ > > coreboot mailing list -- coreboot@coreboot.org > > To unsubscribe send an email to coreboot-le...@coreboot.org > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: How to enable SERIRQ reliably?
Thanks for let us know the result. But the explanation will be the warm reboot path will modify the GPIO setting? Or the GPIO setting is floating at the moment? Lance Zhiwen Zheng 于2021年11月8日周一 下午7:31写道： > Add gpio.c from > https://u8209486.ct.sendgrid.net/ls/click?upn=5-2BjrOL6Sde2a9aQLMiEgaLzceDV6ek3hr5PekV6loyqk65QWgl6iFUXTzf0xmiYdaz1dP39rwh5BPgTpUyb-2Bsg-3D-3DxXBW_L-2FDzr14mnrsJO5b1wX1hp9b1MAQygl7x-2B74RAaH2cn2wBxw68JrPs9IxSJmJXQAva-2BUY65aZPvVauIf67M-2FgY9v12g9aQMGCk5eA9Kfw56r9XM2u-2FaXeM-2BCATfg8F03n6hRRS2ALwig078oKTn98eD3mF3Nc4exuyMJHuj8HL7ofdtZVNmKCRPZMP4f4iftjmAtZ5uqmqkFdpVYLpOPb8A-3D-3D > solve the problem. > SMbus also works. > > > On Mon, 08 Nov 2021 08:54:39 + (UTC) > Zhiwen Zheng wrote: > > > I just looked at the patch, it does not reenable continuous mode in > ramstage. > > So what I do is basically the same with that patch, but that doesn't > work after a warm reset for me. > > > > I am wondering whether the gpio configuration of the soc is related to > this issue, I don't have access > > to the BWG doc, can anybody send me a copy? > > > > SMbus also doesn't working, don't know if it is related to the gpio > setting. > > > > On Mon, 8 Nov 2021 15:31:34 +0800 > > Lance Zhao wrote: > > > > > > https://u8209486.ct.sendgrid.net/ls/click?upn=5-2BjrOL6Sde2a9aQLMiEgaNTszOAtW4XhTn6W2SA205kvAu3ZGQzvptG1uDSnI8JF7kkyk2JqFP7dBXWpdpeHv9Yv-2Fvss-2FV2wjt8sgJcQOIRkU0sHSj-2FWobKz5LhWN4ga49r7nWEe-2FvDvFIiuR4qVBf8HfzR11G-2BtZUn0u3kqyGWm4TfcRW9S7sGaAG69IJDqo3EBcC80PXmq6K-2Bph6bMX780-2B18A1TkGpLJwNSXYKHcE8-2BfSsFMU0HhvOuAC1zDktawL3GzsuPoXKWM-2FOO2SIdUTU58yYVXPmgTv-2BR9fR4WOBGFVLDlTaxGZZcnOlXYyai5ctsO8XNSyLlCi2nDOqnNyZglcwgz7x1aCj1iDSzmwFM36PJ-2BK96mWStSy27LqhQYJVTJeDLpjCzyPwrKO-2FonlRHrBOKXg0IqBkNb59fPdYBlsq-2FbPrYTbOeR1mYj9DqMb8xLZ8Uyf3kXr9s5XY-2BFN0lVlvZr1k1t-2F-2FZybX0UIxYiJ3UA3SkAzKKCkgD6UpwvBFXrbYS0m-2B-2Bb-2BQKZuL9wHKC7NC6p2ojmkVh4cRts-3DcgJN_L-2FDzr14mnrsJO5b1wX1hp9b1MAQygl7x-2B74RAaH2cn2wBxw68JrPs9IxSJmJXQAvCYx6XXmU-2FGiLdxAtU9IExnHLs-2FVK4Y7Al7Jsuft6zvEeA59g-2Fe7YNYwPZpihMxhi87O-2F0wsxDfYcmxFQqag-2BZwwqZQBQW1LkKW17E6-2B-2FDzENuZdz15TTGE5sZ2z9y3CtZm7vT7NDMScTSUSkWRTueg-3D-3D > > > Have similar implementation on braswell, so as long as sc_init get > > > executed in ramstage the serial irq mode programming shall be working. > > > > > > Zhiwen Zheng 于2021年11月6日周六 下午6:29写道： > > > > > > > I add the following code to sc_init() in southcluster.c to enable > SERIRQ, > > > > and it works as expected when doing cold boot. With SERIRQ enabled, > the > > > > uart in superio can function correctly, and I can login into the > linux > > > > serial console. But after a reboot initiated from linux cmdline, the > linux > > > > boot hang in getty serial(same as without SERIRQ enabled), only a > power > > > > cycle can resolve the issue. I take the following code from > coreboot-4.11 > > > > fsp-baytrail. I also tried the check_for_warm_reset() in bootblock.c > to > > > > hardreset the machine, but the check condition in that procedure > doesn't > > > > catch this situation, linux reset by default use keyboard controller > > > > seemingly. > > > > > > > > u32 *oic = (u32 *)(ILB_BASE_ADDRESS + 0x60); > > > > u8 *serirq_cntl = (u8 *)(ILB_BASE_ADDRESS + 0x10); > > > > > > > > > > > > /* Enable SERIRQ */ > > > > write32(oic, (read32(oic) | (1 << 12))); > > > > /* Enable continuous mode */ > > > > write8(serirq_cntl, (1 << 7)); > > > > ___ > > > > coreboot mailing list -- coreboot@coreboot.org > > > > To unsubscribe send an email to coreboot-le...@coreboot.org > > > > > > ___ > > coreboot mailing list -- coreboot@coreboot.org > > To unsubscribe send an email to coreboot-le...@coreboot.org > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: How to enable SERIRQ reliably?
https://review.coreboot.org/c/coreboot/+/29398 Have similar implementation on braswell, so as long as sc_init get executed in ramstage the serial irq mode programming shall be working. Zhiwen Zheng 于2021年11月6日周六 下午6:29写道： > I add the following code to sc_init() in southcluster.c to enable SERIRQ, > and it works as expected when doing cold boot. With SERIRQ enabled, the > uart in superio can function correctly, and I can login into the linux > serial console. But after a reboot initiated from linux cmdline, the linux > boot hang in getty serial(same as without SERIRQ enabled), only a power > cycle can resolve the issue. I take the following code from coreboot-4.11 > fsp-baytrail. I also tried the check_for_warm_reset() in bootblock.c to > hardreset the machine, but the check condition in that procedure doesn't > catch this situation, linux reset by default use keyboard controller > seemingly. > > u32 *oic = (u32 *)(ILB_BASE_ADDRESS + 0x60); > u8 *serirq_cntl = (u8 *)(ILB_BASE_ADDRESS + 0x10); > > > /* Enable SERIRQ */ > write32(oic, (read32(oic) | (1 << 12))); > /* Enable continuous mode */ > write8(serirq_cntl, (1 << 7)); > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: GDB stub & bootblock dependencies (CONFIG_IDT_IN_EVERY_STAGE=y)
Hi Werner, Shall we need to include other stage as well? Like verstage and postcar, since IDT_IN_EVERY_STAGE. Lance Samek, Jan 于2021年7月23日周五 下午4:26写道： > Hi Werner, > > Thanks for the patch - I now have a successful GDB connection over UART on > TGL. > > I was not sure whether to include the GDB functions to every stage or > exclude them from the boot block - now I have the answer. > I'd like to provide a fix in a form of the patch but the paperwork on my > side is still not complete to allow me to upstream the code so I guess I'll > leave the opportunity to you or the others. > > Regards, > Jan > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: GDB stub & bootblock dependencies (CONFIG_IDT_IN_EVERY_STAGE=y)
Then those console.c and uart.h need to follow to include in every stage? Samek, Jan 于2021年7月23日周五 上午12:15写道： > Hello, > > I am currently developing on Intel TGLRVP-UP3, but this should be relevant > for other TGL-based platforms and possibly all other that set > CONFIG_IDT_IN_EVERY_STAGE=y: > > When I try to use the GDB stub for my debug attempts on TGL > (CONFIG_GDB_STUB=y), I get the following 'undefined reference' errors > during the bootblock linkage process: > > src/arch/x86/exception.c:225: undefined reference to `gdb_tx_byte' > src/arch/x86/exception.c:225: undefined reference to `gdb_tx_byte' > src/arch/x86/exception.c:225: undefined reference to `gdb_tx_byte' > src/arch/x86/exception.c:230: undefined reference to `gdb_tx_flush' > src/arch/x86/exception.c:230: undefined reference to `gdb_tx_flush' > src/arch/x86/exception.c:230: undefined reference to `gdb_tx_flush' > src/arch/x86/exception.c:235: undefined reference to `gdb_rx_byte' > util/crossgcc/xgcc/bin/i386-elf-ld.bfd: src/arch/x86/exception.c:225: > undefined reference to `gdb_tx_byte' > util/crossgcc/xgcc/bin/i386-elf-ld.bfd: src/arch/x86/exception.c:225: > undefined reference to `gdb_tx_byte' > util/crossgcc/xgcc/bin/i386-elf-ld.bfd: src/arch/x86/exception.c:225: > undefined reference to `gdb_tx_byte' > util/crossgcc/xgcc/bin/i386-elf-ld.bfd: src/arch/x86/exception.c:225: > undefined reference to `gdb_tx_byte' > util/crossgcc/xgcc/bin/i386-elf-ld.bfd: src/arch/x86/exception.c:235: > undefined reference to `gdb_rx_byte' > util/crossgcc/xgcc/bin/i386-elf-ld.bfd: src/arch/x86/exception.c:235: > undefined reference to `gdb_rx_byte' > util/crossgcc/xgcc/bin/i386-elf-ld.bfd: src/arch/x86/exception.c:235: > undefined reference to `gdb_rx_byte' > util/crossgcc/xgcc/bin/i386-elf-ld.bfd: src/arch/x86/exception.c:235: > undefined reference to `gdb_rx_byte' > > The gdb_*() functions used in exception.c are defined in > src/console/console.c. Nevertheless, the problem with the functions in > question is that they're defined under '#if CONFIG(GDB_STUB) && > (ENV_ROMSTAGE || ENV_RAMSTAGE)' which obviously doesn't allow them to be > compiled into the bootblock code while they're unconditionally (there's > only the IDT_IN_EVERY_STAGE condition) referenced in exception.c > > Looking at src/arch/x86/Makefile.inc (filtering out only the lines of > interest), it's apparent that exception.c is linked in all stages when the > IDT_IN_EVERY_STAGE option is set: > > 76: bootblock-$(CONFIG_IDT_IN_EVERY_STAGE) += exception.c > 111: verstage-$(CONFIG_IDT_IN_EVERY_STAGE) += exception.c > 148: romstage-$(CONFIG_IDT_IN_EVERY_STAGE) += exception.c > 187: postcar-$(CONFIG_IDT_IN_EVERY_STAGE) += exception.c > 229: ramstage-y += exception.c > 291: smm-$(CONFIG_IDT_IN_EVERY_STAGE) += exception.c > > The behavior appears in revision b90aba43c1405d3d2cb7cba05e68906e979dcda3 > (master). > > To reproduce, > - run 'make menuconfig', > - select 'Mainboard ->Mainboard Vendor': 'Intel', > - select 'Mainboard -> Mainboard Model': 'Tiger Lake UP3 RVP', > - select 'Debugging -> GDB debugging support': 'y'. > - run 'make'. > > What do you think would be the best approach to make the GDB stub work on > these platforms? > > P.S. My bug tracker registration is currently pending an approval, I could > be able to create a ticket afterwards. > > Regards, > Jan > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Coreboot and Tianocore
I have commit https://review.coreboot.org/c/coreboot/+/28542/ before, though I can't remember that's the same error behavior. Lance Zhao 于2021年2月5日周五 下午10:30写道： > Can't remember the detail but that maybe related to timer, i believe we > have that build flag set when build payload from coreboot. > > 于 2021年2月5日周五 下午9:11写道： > >> Hi, >> >> I have generated a payload from edk2 2017. When i booting with payload i >> got struck after the below message. The keyboard is not detecting so i >> can't press any key. Mouse got powered up. Even i exchanged the usb ports >> but still keyboard not detecting. I am using coreboot and edk2 payload. I >> am using Coffeelake processor. If i use the uefi payload binary from Intel. >> Everything is working and able to select device in the boot manager and >> load OS. >> >> LastBlock : 4F >> [0m [37m [40m >> F2 or Down to enter Boot Manager Menu. >> ENTER to boot directly. >> >> [Bds]OsIndication: >> [Bds]=Begin Load Options Dumping ...= >> Driver Options: >> SysPrep Options: >> Boot Options: >> Boot: UiApp 0x0109 >> Boot0001: UEFI SM659GXC CDZ A051902261706001 0x0001 >> Boot0002: UEFI Shell 0x0001 >> PlatformRecovery Options: >> PlatformRecovery: Default PlatformRecovery 0x0001 >> [Bds]=End Load Options Dumping= >> [Bds]BdsWait ...Zzzz... >> [Bds]BdsWait(3)..Zzzz... >> ___ >> coreboot mailing list -- coreboot@coreboot.org >> To unsubscribe send an email to coreboot-le...@coreboot.org >> > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Coreboot and Tianocore
Can't remember the detail but that maybe related to timer, i believe we have that build flag set when build payload from coreboot. 于 2021年2月5日周五 下午9:11写道： > Hi, > > I have generated a payload from edk2 2017. When i booting with payload i > got struck after the below message. The keyboard is not detecting so i > can't press any key. Mouse got powered up. Even i exchanged the usb ports > but still keyboard not detecting. I am using coreboot and edk2 payload. I > am using Coffeelake processor. If i use the uefi payload binary from Intel. > Everything is working and able to select device in the boot manager and > load OS. > > LastBlock : 4F > [0m [37m [40m > F2 or Down to enter Boot Manager Menu. > ENTER to boot directly. > > [Bds]OsIndication: > [Bds]=Begin Load Options Dumping ...= > Driver Options: > SysPrep Options: > Boot Options: > Boot: UiApp 0x0109 > Boot0001: UEFI SM659GXC CDZ A051902261706001 0x0001 > Boot0002: UEFI Shell 0x0001 > PlatformRecovery Options: > PlatformRecovery: Default PlatformRecovery 0x0001 > [Bds]=End Load Options Dumping= > [Bds]BdsWait ...Zzzz... > [Bds]BdsWait(3)..Zzzz... > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Debugging Windows 10 BSOD
Do you have the failed DSDT table dumped? Even there's recent change around
NVSA, but looks that's different.
Raul Rangel 于2021年1月21日周四 上午4:24写道：
> Over the weekend I had the realization that SMI logging was enabled
> and interfering with WinDbg. Once I flashed a non-serial firmware
> WinDbg became a lot more stable and I was able to reliably attach to
> the boot loader debugger i.e., `/bootdebug {default}`. The OS debugger
> (`/debug {default} on`) was still not functioning though. I wasn't
> sure If the BSOD was happening in the boot loader or the OS kernel, so
> I stepped through the boot loader until I saw it jump to the OS. From
> there WinDbg failed to restore the connection. The exception happens
> before the OS is capable of writing a kernel dump. I was also
> suspecting it was happening before the debugger was set up since the
> connection could not be re-established.
>
> I then saw Felix's reply:
> > To decode the bug check values and their parameters, see
> https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/bug-check-0xa5--acpi-bios-error
>
> > The third parameter you posted decodes to _UID (that one is 4 char ASCII
> stored as little endian number).
>
> The parameters I gathered last week:
>
> > 0x
> > OxD38AC66EC7FO
> > Ox4449555F
> > 0x
>
> The first parameter 0x0 wasn't listed in the table. So this led me to
> believe that maybe there was a problem parsing the ACPI tables. Felix
> suggested I use the [Microsoft ASL
> compiler](
> https://docs.microsoft.com/en-us/windows-hardware/drivers/bringup/microsoft-asl-compiler
> )
> to decompile the AML and verify if the tables were valid.
>
> I used linux to dump the ACPI tables via `/sys/firmware/acpi/tables/`,
> added the `.AML` suffix, and ran `asl.exe /u DSDT.AML`. This printed
> an error saying `NVSA was already defined`. Using iasl to decompile
> the table I saw the following:
>
> ```
> External (NVSA)
> Name (NVSA, 0xCA6B2000)
> OperationRegion (GNVS, SystemMemory, NVSA, 0x1000)
> ```
>
> The external reference was defined in `.asl`:
>
> https://source.chromium.org/chromiumos/chromiumos/codesearch/+/master:src/third_party/coreboot/src/soc/amd/picasso/acpi/globalnvs.asl;l=12
> The `Name` node was created by acpigen:
>
> https://source.chromium.org/chromiumos/chromiumos/codesearch/+/master:src/third_party/coreboot/src/soc/amd/picasso/acpi.c;l=429
>
> Removing the External from the `.asl`. results in the `iasl` compiler
> complaining about a missing reference. So I move the `Name` node to
> the SSDT table. This resulted in linux complaining that `GVNS` was
> invalid because it couldn't find `NVSA`. The ACPI spec says the
> following:
>
> > OperationRegion (RegionName, RegionSpace, Offset, Length)
> > Operation regions are regions in some space that contain hardware
> registers for exclusive use by ACPI
> control methods. ...
> > The entire Operation Region can be allocated for exclusive use to the
> ACPI subsystem in the host OS.
> > Operation Regions that are defined within the scope of a method are the
> exception to this rule. These Operation Regions are known as “Dynamic”
> since the OS has no idea that they exist or what registers they use until
> the control method is executed.
>
> I'm guessing that we can't move the `NVSA` node to the SSDT because
> the value is required when instantiating `OperationRegion`.
>
> I'm not quite sure how to solve this. For now I just hard coded the
> address in the `OperationRegion`. I'm open to suggestions.
>
> The second problem was `OIPG`. It is also defined twice:
>
>
> https://source.chromium.org/chromiumos/chromiumos/codesearch/+/master:src/third_party/coreboot/src/vendorcode/google/chromeos/acpi/chromeos.asl;l=8
>
>
> https://source.chromium.org/chromiumos/chromiumos/codesearch/+/master:src/third_party/coreboot/src/vendorcode/google/chromeos/acpi.c;l=15
>
> Changing the callback to write to the SSDT table fixed that problem
> and I was finally able to decode `DSDT.AML` using the `Microsoft ASL
> Compiler`.
>
> I then disabled `/bootdebug` and `/debug` since they weren't providing
> any value and were preventing me from seeing the BSOD error codes. One
> thing I noticed was that rebooting after a BSOD the boot loader would
> boot a "system restore" image. This image used a different registry
> than the OS so the error codes were not printed on the screen.
> Rebooting again the boot loader would load the OS. So each test
> required a double reboot. I'm also using Tianocore to boot Windows,
> which is super slow...
>
> The BSOD this time looked identical to the previous one... But upon
> closer inspection the error code was different:
>
> > 0x000D
>
> ... I went back and looked at the photo I took of the original BSOD
> and it was indeed 0x000D! The font made this easy to miss
> the first time around. Google Lens didn't pick it up either.
>
> The exception now made sense:
>
> > ACPI could not find a required method or
[coreboot] Re: Debugging Windows 10 BSOD
Highly possible you don't need to connect live sessions using windbg, you
can analysis the generated dump file to simply open with windbg.
Raul Rangel 于2021年1月14日周四 上午6:21写道：
> I'm trying to boot the Windows 10 Installer on a picasso based device
> using coreboot + tianocore. I keep getting a BSOD after the windows logo
> shows with the very descriptive stop code `ACPI BIOS ERROR`.
>
> I've enabled bootdebug on the USB stick using the following:
>
> bcdedit /store H:\boot\bcd /bootdebug {bootmgr} on
> bcdedit /store H:\boot\bcd /bootdebug {default} on
> bcdedit /store H:\boot\bcd /debug {debug} on
>
> Here is the BCD:
>
> C:\Windows\system32>bcdedit /store h:\boot\bcd
> Windows Boot Manager
>
> identifier {bootmgr}
> description Windows Boot Manager
> locale en-US
> inherit {globalsettings}
> bootdebug Yes
> default {default}
> displayorder{default}
> toolsdisplayorder {memdiag}
> timeout 30
>
> Windows Boot Loader
> ---
> identifier {default}
> device
> ramdisk=[boot]\sources\boot.wim,{7619dcc8-fafe-11d9-b411-000476eba25f}
> path\windows\system32\boot\winload.exe
> description Windows Setup
> locale en-US
> inherit {bootloadersettings}
> bootdebug Yes
> osdevice
> ramdisk=[boot]\sources\boot.wim,{7619dcc8-fafe-11d9-b411-000476eba25f}
> systemroot \windows
> bootmenupolicy Standard
> detecthal Yes
> winpe Yes
> debug Yes
> ems No
>
> C:\Windows\system32>bcdedit /store h:\boot\bcd /dbgsettings
> debugtype Serial
> debugport 1
> baudrate115200
>
>
> I have also added the SPCR table:
>
> [000h 4]Signature : "SPCR"[Serial Port
> Console Redirection table]
> [004h 0004 4] Table Length : 0050
> [008h 0008 1] Revision : 02
> [009h 0009 1] Checksum : F1
> [00Ah 0010 6] Oem ID : "COREv4"
> [010h 0016 8] Oem Table ID : "COREBOOT"
> [018h 0024 4] Oem Revision : 002A
> [01Ch 0028 4] Asl Compiler ID : "CORE"
> [020h 0032 4]Asl Compiler Revision : 20200925
>
> [024h 0036 1] Interface Type : 00
> [025h 0037 3] Reserved : 00
>
> [028h 0040 12] Serial Port Register : [Generic Address
> Structure]
> [028h 0040 1] Space ID : 00 [SystemMemory]
> [029h 0041 1]Bit Width : 20
> [02Ah 0042 1] Bit Offset : 00
> [02Bh 0043 1] Encoded Access Width : 03 [DWord Access:32]
> [02Ch 0044 8] Address : FEDC9000
>
> [034h 0052 1] Interrupt Type : 03
> [035h 0053 1] PCAT-compatible IRQ : 04
> [036h 0054 4]Interrupt : 0004
> [03Ah 0058 1]Baud Rate : 00
> [03Bh 0059 1] Parity : 00
> [03Ch 0060 1]Stop Bits : 00
> [03Dh 0061 1] Flow Control : 00
> [03Eh 0062 1]Terminal Type : 00
> [04Ch 0076 1] Reserved : 00
> [040h 0064 2]PCI Device ID :
> [042h 0066 2]PCI Vendor ID :
> [044h 0068 1] PCI Bus : 00
> [045h 0069 1] PCI Device : 00
> [046h 0070 1] PCI Function : 00
> [047h 0071 4]PCI Flags :
> [04Bh 0075 1] PCI Segment : 00
> [04Ch 0076 4] Reserved :
>
> And the DBG2 table:
>
> [000h 4]Signature : "DBG2"[Debug Port
> table type 2]
> [004h 0004 4] Table Length : 005C
> [008h 0008 1] Revision : 00
> [009h 0009 1] Checksum : 78
> [00Ah 0010 6] Oem ID : "COREv4"
> [010h 0016 8] Oem Table ID : "COREBOOT"
> [018h 0024 4] Oem Revision :
> [01Ch 0028 4] Asl Compiler ID : "CORE"
> [020h 0032 4]Asl Compiler Revision : 20200925
>
> [024h 0036 4] Info Offset : 002C
> [028h 0040 4] Info Count : 0001
>
> [02Ch 0044 1] Revision : 00
> [02Dh 0045 2] Length : 0030
> [02Fh 0047
[coreboot] Re: Reserve Device DRAM
Why not force that in ACPI _CRS directly? And Linux OSPM will reassign the
memory resource base on CRS any way? You can take a reference from any DSDT
or
https://review.coreboot.org/c/coreboot/+/31822/5/src/soc/intel/braswell/acpi/lpc.asl
.
Lance
Rocky Phagura via coreboot 于2021年1月4日周一 下午2:45写道：
> Hello,
>
> Can anyone provide guidance on the previous email? It seems in bootmem.c,
> the memory is marked type 16, LB_MEM_TABLE. Is there a way to explicitly
> add an entry (cbmem_add) for reserved memory that is not type 16? Thank you,
>
>
>
>
>
> #define LB_MEM_RAM 1 /* Memory anyone can use */
>
> #define LB_MEM_RESERVED2 /* Don't use this
> memory region */
>
> #define LB_MEM_ACPI3 /* ACPI Tables */
>
> #define LB_MEM_NVS 4 /* ACPI NVS Memory */
>
> #define LB_MEM_UNUSABLE 5 /* Unusable address
> space */
>
> #define LB_MEM_VENDOR_RSVD 6 /* Vendor Reserved */
>
> #define LB_MEM_TABLE 16/* Ram configuration
> tables are kept in */
>
>
>
>
>
>
>
> *From:* Bryan Angelo
> *Sent:* Wednesday, September 16, 2020 4:16 PM
> *To:* coreboot@coreboot.org
> *Subject:* [coreboot] Reserve Device DRAM
>
>
>
> I would appreciate any guidance on the proper way to reserve (arbitrary)
> DRAM for a MMIO device in coreboot such that the Linux driver for that
> device is also able to map the reserved DRAM.
>
>
>
> Based on code inspection, my attempt is to add a cbmem entry via
> cbmem_alloc and mark that memory as reserved via reserved_ram_resource in
> the read_resources operation for the device driver.
>
>
>
> static void foo_read_resources(struct device *dev)
>
> {
>
> void *buf;
>
> const unsigned long size = 0x8000;
>
>
>
> if (cbmem_entry_find(CBMEM_ID_FOO))
>
> return;
>
>
>
> buf = cbmem_add(CBMEM_ID_FOO, size);
>
> if (!buf)
>
> return;
>
>
>
>
> reserved_ram_resource(dev, 0, ((unsigned long)buf) >> 10, size >>
> 10);
>
> }
>
>
>
> I can see that the resource is allocated during resource reading.
>
>
>
> MMIO: fd110500 resource base *8de82000* size 8000 align 0 gran 0 limit 0
> flags f0004200 index 0
>
>
>
> I then pass this resource to the linux driver via an ACPI device entry.
>
>
>
> acpigen_write_name("_CRS");
>
> acpigen_write_resourcetemplate_header();
>
> const struct cbmem_entry *ce = cbmem_entry_find(CBMEM_ID_FOO);
>
> if (ce)
>
> acpigen_write_mem32fixed(1, (uint32_t)cbmem_entry_start(ce),
> (uint32_t)cbmem_entry_size(ce));
>
>
>
> However, the memory is presented to Linux as "type 16" instead of
> "reserved" in the physical RAM map.
>
>
>
> [0.00] BIOS-provided physical RAM map:
>
> [0.00] BIOS-e820: [mem 0x-0x0fff] type
> 16
>
> [0.00] BIOS-e820: [mem 0x1000-0x0009]
> usable
>
> [0.00] BIOS-e820: [mem 0x000a-0x000f]
> reserved
>
> [0.00] BIOS-e820: [mem 0x0010-0x8de34fff]
> usable
>
> *[0.00] BIOS-e820: [mem 0x8de35000-0x8fff]
> type 16*
>
> [0.00] BIOS-e820: [mem 0x9000-0xcfff]
> reserved
>
> [0.00] BIOS-e820: [mem 0xf800-0xfbff]
> reserved
>
> [0.00] BIOS-e820: [mem 0x0001-0x00022f33]
> usable
>
> [0.00] BIOS-e820: [mem 0x00022f34-0x00022fff]
> reserved
>
>
>
> The e820 type 16 is unknown to the linux kernel, causing it to mark the
> region as busy. This subsequently causes devm_ioremap_resource to fail
> when called on the DRAM address from the ACPI device entry.
>
>
>
> Looking through the code, it seems that coreboot marks the entire cbmem as
> type 16 in bootmem despite my (improper, it would seem) attempt to mark the
> ram as reserved. What would be the proper way to reserve (arbitrary) DRAM
> for a MMIO device such that the memory is marked as reserved in the BIOS
> physical RAM map?
>
>
>
> Thanks.
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
>
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Coreboot computer doesn't boot with 2 CPU
What's the does not boot point to? Stuck in POST with some serial log, or not even CPU is running. d.verdi via coreboot 于2020年11月24日周二 上午6:49写道： > Hi to all, > I had this problem: when I start the computer with 1 cpu (opteron 6282se) > everything is fine, if I add the second CPU, the computer doesn't boot, did > you have any suggestions? I put only 2 rams module, following the Asus kgpe > d16 manual, is that the correct order (one in the first and one in the last > orange socket)? > > Thank you very much > Dave > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Intel EDK2 header files
@Subrata Banik must have done so on other Intel project. In the near future, I think highly possible that CPX FSP will stick with edk2-stable202005 for quite some time. Jonathan Zhang (Infra) via coreboot 于2020年6月17日周三 上午3:15写道： > Hi coreboot colleagues, > > Intel EDK2 header files are needed to build coreboot that depends on FSP. > So far the practice is > to keep such header files under src/vendorcode/intel/edk2 directory, and > each EDK2 version takes > a different directory (we have uefi_2.4, UDK2015, UDK2017). > > Since CPX-SP FSP is based on latest EDK2 code base, I would like to add > EDK2 quarterly release > (edk2-stable202005) header files to coreboot code base, and created [CB: > 42239] accordingly. > > Idwer commented that an alternative is to keep EDK2 header files as a > submodule, and this should > be discussed in coreboot community. > > Thanks, > Jonathan > > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Please guys repair coreboot to support my laptop motherboard. https://github.com/coreboot/coreboot/pull/18
Drop Win 7 for your case will be more realistic in the meantime. Marshall Dawson 于2020年1月13日周一 上午9:09写道： > > Please guys repair coreboot to support my laptop motherboard. > https://github.com/coreboot/coreboot/pull/18 > > Ryzen support is still a work in progress. Having coreboot work on your > laptop is currently impossible. > > > On Sun, Jan 12, 2020 at 5:13 PM awokd via coreboot > wrote: > >> 王一凡: >> > Please guys repair coreboot to support my laptop motherboard. >> > https://github.com/coreboot/coreboot/pull/18 >> >> Please see >> https://www.coreboot.org/FAQ#Will_coreboot_work_on_my_machine.3F : >> >> "If your board is not already supported, it will likely take you years >> of work to port coreboot to operate correctly on it unless you have >> experience with firmware level C development and good knowledge of the >> underlying (x86 or ARM) architecture." >> >> -- >> - don't top post >> Mailing list etiquette: >> - trim quoted reply to only relevant portions >> - when possible, copy and paste text instead of screenshots >> ___ >> coreboot mailing list -- coreboot@coreboot.org >> To unsubscribe send an email to coreboot-le...@coreboot.org >> > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Trying to check potential compatibility of intel server board
https://github.com/IntelFsp/FSP that shall have all the current platform that FSP can supported, Matt B 于2019年9月29日周日 上午10:52写道： > Hello, > > I'm trying to check the potential compatibility of the s1200kp intel > server board. [1] It's mini-itx and supports ECC ram, making it attractive > for use in a NAS device. (cases with multiple hotswap bays and room for an > itx board abound, but few itx boards have ECC capability) > > The chipset is listed as the C206, which is part of cougar point. The > socket is FCLGA1155 and I've seen the board with an i3-3220 (3rd gen ivy > bridge). > > However, I'm having a really hard time finding information on whether > coreboot supports the chipset. (never mind the superio etc) > > It seems the compatibility list [2] on the wiki is out of date (and slated > for retirement) and the docs at [3] are still mostly incomplete. From > grepping through the source and the coreboot blog [4] there's been a port > (in coreboot 4.2) to at least one other cougar point platform. > (apple/macbookair4_2) The blog post also mentions that support for ivy > bridge and cougar point come from an FSP binary. There is also a coreboot > blog entry linking to the following article [5] discussing support for > these chips being merged. > > This lack of accessible documentation makes it difficult to find good > porting candidates for hardware of *any* generation. Are all ivy bridge > CPUs supported? Does the FSP binary support all cougar point chipsets? > > Sincerely, > -Matt > > [1] > https://ark.intel.com/content/www/us/en/ark/products/60637/intel-server-board-s1200kp.html > [2] https://www.coreboot.org/Supported_Chipsets_and_Devices > [3] https://doc.coreboot.org/northbridge/intel/index.html > [4] https://blogs.coreboot.org/blog/2015/10/30/announcing-coreboot-4-2/ > [5] https://www.phoronix.com/scan.php?page=news_item=MTA4Mjg > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Proposal: Improved ACPI generation
I agree as well, that will be more clear in implementation. Lance Felix Held 于2019年8月20日周二 上午3:26写道： > Hi Patrick! > > > for improved runtime ACPI generation I would like to introduce a new > member in > > struct device_operations. > > It would return the ACPI HID for the given device similar to the ACPI > > NAME that's already implemented: > > Sounds good to me. > > Regards > Felix > > -- > Felix Held > c/o cyberkombinat23 > Steinstraße 23 > 76133 Karlsruhe > Germany > > m...@felixheld.de > > Ust-ID: DE301814366 > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Does Coreboot support the following options to enable/disable?
https://github.com/IntelFsp/FSP/tree/master/BroadwellDEFspBinPkg/include I don't believe FSP UPD have everything, they do have P-state I believe. 于2019年7月5日周五 下午1:30写道： > Hi Lance, > > The settings are meant for BroadwellDE not Denverton. > > Are these options too supported in BroadwellDE for coreboot? > uncore power management > Uncore frequency scaling -enabled > performance p-limit -enabled > > > > cpu p-state control > enhanced intel speedstep technology -disabled > > > Hardware P-States > > Hardware P-States -Disabled > HardwarePM nInterrupts -Disabled > EPP Enable -Enabled > > Memory > NUMA Optimized -Enabled > > > Regards, > AC > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Does Coreboot support the following options to enable/disable?
That's Denverton? If the selection is not part of fspupd file https://github.com/IntelFsp/FSP/tree/master/DenvertonNSFspBinPkg/Include, then probably they only have default setting. We can't enable/disable those option through FSP didn't mean those feature is not available. Lance Ashmita Chakraborty 于2019年7月3日周三 上午2:10写道： > Hi Ranga, > > Exactly, only Hyperthreading is available. I could not find Intel > Virtualization Tech , MLC streamer, etc. So here's my question if all these > options support coreboot for Xeon D-15xx? > > > Thanks, > > Ashmita Chakraborty > -- > *From:* Ranga Rao > *Sent:* Wednesday, July 3, 2019 1:15:07 PM > *To:* Ashmita Chakraborty; coreboot@coreboot.org > *Subject:* RE: [coreboot] Re: Does Coreboot support the following options > to enable/disable? > > > Hi Ashmita, > > > > I could see HyperThreading Enable/Disable in Upd_Data_region > > FSP-master\BroadwellDEFspBinPkg\include\fspvpd.h > > > > Regards > > Ranga > > > > *From:* Ranga Rao > *Sent:* Wednesday 3 July 2019 08:18 > *To:* Ashmita Chakraborty ; > coreboot@coreboot.org > *Subject:* [coreboot] Re: Does Coreboot support the following options to > enable/disable? > > > > Hi Ashmita, > > > > Broadwell-DE / Xeon D support still depends Intel's closed-source FSP > (Firmware Support Package) binary-only blobs. > > Broadwell-DE SoC / Xeon D Support Added To Coreboot > > > > Hope you could configure them through fsp_upd_data? > > > > Regards > > Ranga > > > > > > > > > > *From:* Ashmita Chakraborty > *Sent:* Wednesday 3 July 2019 08:14 > *To:* Ranga Rao ; coreboot@coreboot.org > *Subject:* Re: [coreboot] Does Coreboot support the following options to > enable/disable? > > > > Dear Ranga, > > > > These options are meant for Xeon D-15xx series family. So will the > coreboot support these options? The coreboot will be built for Xeon D-15xx > processor. Yes, I have access to them in fsp_early_init through > fsp_upd_data. > > > > Thanks, > > Ashmita Chakraborty > > > -- > > *From:* Ranga Rao > *Sent:* Tuesday, July 2, 2019 8:41 PM > *To:* Ashmita Chakraborty; coreboot@coreboot.org > *Subject:* RE: [coreboot] Does Coreboot support the following options to > enable/disable? > > > > Hi, > > > > As these features are processor/SoC specific and they are part of FSPM, > they should be configurable > > during fsp early init in coreboot, though you may not find a KConfig > option to enable/disable > > > > Do you have access to them in *fsp_early_init* through *fsp_upd_data?* > > > > Regards > > Ranga > > > > -Original Message- > From: ashmita.chakrabo...@ltts.com > Sent: Tuesday 2 July 2019 07:34 > To: coreboot@coreboot.org > Subject: [coreboot] Does Coreboot support the following options to > enable/disable? > > > > Does the coreboot support the following options to enable/disable: > > > > HyperThreading- Disabled > > Execute Disable Bit - Enabled > > Intel Virtualization Tech- Enabled > > Intel (R) TXT- Disabled > > Enhanced Error Containment Mode -Disabled > > MLC Streamer -Enabled > > MLC Spatial Prefetcher -Enabled > > DUC Data Prefetcher -Enabled > > DUC Instruction Prefetcher-Enabled > > LLC Prefetch - Enabled > > Intel Configurable TDB -Enabled > > TDP Level -level 2 > > > > > > Please let me know. > > > > Thanks in advance. > > > > Regards, > > Ashmita Chakraborty > > ___ > > coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an > email to coreboot-le...@coreboot.org > > *L Technology Services Ltd* > > www.LTTS.com > > This Email may contain confidential or privileged information for the > intended recipient (s). If you are not the intended recipient, please do > not use or disseminate the information, notify the sender and delete it > from your system. > > *L Technology Services Ltd* > > www.LTTS.com > > This Email may contain confidential or privileged information for the > intended recipient (s). If you are not the intended recipient, please do > not use or disseminate the information, notify the sender and delete it > from your system. > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: compiler/toolchain issue?
https://doc.coreboot.org/lessons/lesson1.html got followed? 于2019年6月19日周三 下午10:12写道： > On 2019-06-14 13:47, Patrick Georgi wrote: > > Hey Mike, > >> > > > /local/mnt/workspace/mturney/gitrepos/qualcomm/chromebook/cbdc-meta/standalone/coreboot/util/cbfstool/cbfstool.c:546:19: > >> > >> note: in expansion of macro 'MAX' > >> uint32_t size = MAX(hs, param.padding); > > > > This is built with your host compiler. Probably an old compiler? > > As I am currently stuck on using 14.04 Ubuntu which has an old version > of GCC, I am curious what gcc versions are in use that folks are using > to build coreboot in standalone tree? > > gcc is already the newest version. > gcc set to manually installed. > 0 upgraded, 0 newly installed, 0 to remove and 7 not upgraded. > mturney@mturney-linux:~$ gcc --version > gcc (Ubuntu 4.8.4-2ubuntu1~14.04.4) 4.8.4 > Copyright (C) 2013 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is > NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR > PURPOSE. > > mturney@mturney-linux:~$ > > > > > > Patrick > > > > Links: > > -- > > [1] http://review-android.quicinc.com:29418/coreboot/chrome-ec.git > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: ACPI_BIOS_ERROR windows boot error with PCIe GPU
It is hard to debug an ACPI problem from code I believe, but I would recommend to capture the memory dump and using windbg to analyze the dump file directly. That shall be easy for you as the following step 1.When system can boot up with GPU,Select "Complete Memory Dump" in "Start and Recovery" and then shutdown. 2.Plug in GPU and boot up system to hit 0xA5 BSOD, waiting for crash dump to be finished and then shutdown system. 3.Take out the GPU card and boot up into system again, using windbg to analyze the dump file, normally that will be much easier to get useful information. You can share the dump file if you want, people can take a look at it together. Lance vladocb via coreboot 于2019年6月14日周五 上午1:26写道： > Hi, > I'm trying to boot Windows 10 with Coreboot 4.9.2002 using Tianocore + a > PCIe GPU and I always get an strange ACPI_BIOS_ERROR. > > Without the PCIe GPU, works ok. > > I'm pretty sure is an error with my DSDT or the southbridge code. > Sadly, I cannot debug Windows to know determine the exact ACPI problem. > I also tested with other boards like the Asus Maximus IV GeneZ and the > problem is there too: with the IGP only works, but when I attach a PCIe GPU > then it crashes. > > Take a look to my code if you want, any help about this will be welcome. > https://review.coreboot.org/c/coreboot/+/33328 > > Thanks. > > > > > > > > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Starting the coreboot 4.10 release process
Tianocore master branch build from edk2 will break, but that had been quite some time. Stable branch is working fine though. On Mon, Jun 3, 2019, 3:28 AM Matt DeVillier wrote: > On Sun, Jun 2, 2019 at 1:27 PM Mike Banon wrote: > >> >> Also, regarding the significant changes: " ### Tianocore UEFI >> integrated as payload " . I hope it doesn't mean that Tianocore will >> become the default payload, since there are ideological/technical >> reasons against this ( I think there's a significant overlap between >> the groups of people who love / interested in coreboot and hate UEFI ) >> > > the change could be reworded better I think: instead of the stable tag for > Tianocore being pulled from the upstream edk2 github repo and a series of > patches applied, it's now pulled directly from my fork/repo, which is > actually functional on most (x86_64) devices. A few tweaks (like > customizable boot splash) were added as well. > > there is no change to the default payload, only to the defaults for > Tianocore > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: lewisburg GPIO
https://lore.kernel.org/patchwork/patch/822662/ It's same as earlier PCH like sunrisepoint ron minnich 于2019年4月17日周三 下午3:46写道： > I need some gpio experts. > > On an (e.g.) lewisburg, how does one enumerate the GPIOs and make them > visible in sysfs as one does on ARM? Is the info in ACPI in some magic > spot? > > thanks > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Removal of mainboard Intel/Strago
I am not sure how many of receiver still working at Intel or still working in chrome team, but I think that's okay abandon support for Strago. Nico Huber 于2019年4月13日周六 上午6:59写道： > Hi all, > > I just noticed that there is a seemingly abandoned board that creates > a lot of maintenance burden for coreboot, also because it's using FSP > UPDs that are not present in the upstream header files. > > Does anybody still care about Intel/Strago? If not, I'd prefer to drop > it immediately. It's only a reference board, so likely never had many > users. > > If somebody at Intel still cares about coreboot support for this board, > please have a look at this issue [1]. > > Nico > > [1] https://github.com/IntelFsp/FSP/issues/14 > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Coding style and automatic code formatting
I have make quiet some mistake on coding style before and had been point out several times on review :-). I still fell like an automatic formatting can help myself and new comers. Ron Minnich via coreboot 于2019年3月27日周三 上午10:03写道： > On Wed, Mar 27, 2019 at 6:13 AM Patrick Georgi wrote: > > > > Am Di., 19. März 2019 um 21:53 Uhr schrieb Julius Werner < > jwer...@chromium.org>: > > > I'm not really a fan of auto-formatters because they can just never be > > > as good as a human in all cases. > > As I understand Ron's argument, the idea is to accept being "less > > good" than any single expert person, because it's traded in for more > > consistency and less friction over everything code formatting since > > the Machine Is Right[tm]. > > I repeat Rob Pike's comment: > "nobody likes the output of the Go formatter, everyone likes the Go > formatter" > > meaning that while the output doesn't always meet everyone's standard > of perfection, it removes the arguments based on people's different > ideas of what is good. And, plus, none of you agree with me or even > each other in ALL cases on what "looks good", so at some point these > arguments boil down to "because I like it." > > I watched this roll out in the Go community in 2011 or so. gofmt was > required. There were lots of arguments. In the end, people realized > that it was nice to delegate formatting to a robot, because these > arguments get exhausting. > > Nobody now remembers a time when robots did not format Go code. Nobody > wants to go back. > > This is true of many projects, in particular those using Rust or Go. > > ron > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Coreboot hang when under control of Intel System Debugger
The time I am using XDP on bay trail platform it was fine, but i was not using coreboot then. What about you don't run any system debuger, just simply hook up xdp to see the issue still there or not? If so, maybe some xdp config itself. On Wed, Mar 13, 2019, 7:33 AM Perkins, Graham (GB) wrote: > Hello, > > I would be grateful for some advice on the problem described below. > > > > I have coreboot running successfully on our own hardware based around the > Intel Atom E3805. Recently I wanted to debug our boot process to determine > the settings of some PCU iLB Low Pin Count (LPC) Bridge PCI Configuration > Registers. I have the Intel System Debugger connect via the Itel ITP XDP > BR3 probe. If I simply run coreboot from the debugger it hangs. I cannot > pause the debugger since the target is reported as still running (reported > in its debug logs). > > > > The console log extract is: > > > > = PEIM FSP (VLYVIEW0 0x0304) = > > Register PPI Notify: DCD0BE23-9586-40F4-B643-06522CED4EDE > > Install PPI: 8C8CE578-8A3D-4F1C-9935-896185C32DD3 > > Install PPI: 5473C07A-3DCB-4DCA-BD6F-1E9689E7349A > > The 0th FV start address is 0x000FFFE0400, size is 0x00017C00, handle is > 0x0 > > Register PPI Notify: 49EDB1C1-BF21-4761-BB12-EB0031AABB39 > > Register PPI Notify: EA7CA24B-DED5-4DAD-A389-BF827E8F9B38 > > Install PPI: B9E0ABFE-5979-4914-977F-6DEE78C278A6 > > Install PPI: DBE23AA9-A345-4B97-85B6-B226F1617389 > > > > þInstall PPI: 06E81C58-4AD7-44BC-8390-F10265F72480 > > Install PPI: 01F34D25-4DE2-23AD-3FF3-36353FF323F1 > > > > Install PPI: 49EDB1C1-BF21-4761-BB12-EB0031AABB39 > > Notify: PPI Guid: 49EDB1C1-BF21-4761-BB12-EB0031AABB39, Peim notify entry > point: FFFE0FD4 > > The 1th FV start address is 0x000FFFB, size is 0x0002F400, handle is > 0xFFFB > > > > øInstall PPI: A55D6970-1306-440C-8C72-8F51FAFB2926 > > > > þPcdMrcInitTsegSize = 8 > > PcdMrcInitMmioSize = 800 > > PcdMrcInitSPDAddr1 = A0 > > PcdMrcInitSPDAddr2 = A2 > > Setting BootMode to 0 > > Install PPI: 1F4C6F90-B06B-48D8-A201-BAE5F1CD7D56 > > Register PPI Notify: F894643D-C449-42D1-8EA8-85BDD8C65BDE > > About to call MrcInit(); > > BayleyBay Platform Type > > RID = 0x11. > > Reg_EFF_DualCH_EN = 0x40030040. > > CurrentMrcData.BootMode = 4 > > Configuring Memory Start... > > > > Without using the debugger everything is fine: > > > > = PEIM FSP (VLYVIEW0 0x0304) = > > Register PPI Notify: DCD0BE23-9586-40F4-B643-06522CED4EDE > > Install PPI: 8C8CE578-8A3D-4F1C-9935-896185C32DD3 > > Install PPI: 5473C07A-3DCB-4DCA-BD6F-1E9689E7349A > > The 0th FV start address is 0x000FFFE0400, size is 0x00017C00, handle is > 0x0 > > Register PPI Notify: 49EDB1C1-BF21-4761-BB12-EB0031AABB39 > > Register PPI Notify: EA7CA24B-DED5-4DAD-A389-BF827E8F9B38 > > Install PPI: B9E0ABFE-5979-4914-977F-6DEE78C278A6 > > Install PPI: DBE23AA9-A345-4B97-85B6-B226F1617389 > > > > þInstall PPI: 06E81C58-4AD7-44BC-8390-F10265F72480 > > Install PPI: 01F34D25-4DE2-23AD-3FF3-36353FF323F1 > > > > Install PPI: 49EDB1C1-BF21-4761-BB12-EB0031AABB39 > > Notify: PPI Guid: 49EDB1C1-BF21-4761-BB12-EB0031AABB39, Peim notify entry > point: FFFE0FD4 > > The 1th FV start address is 0x000FFFB, size is 0x0002F400, handle is > 0xFFFB > > > > ðInstall PPI: A55D6970-1306-440C-8C72-8F51FAFB2926 > > > > þPcdMrcInitTsegSize = 8 > > PcdMrcInitMmioSize = 800 > > PcdMrcInitSPDAddr1 = A0 > > PcdMrcInitSPDAddr2 = A2 > > Setting BootMode to 0 > > Install PPI: 1F4C6F90-B06B-48D8-A201-BAE5F1CD7D56 > > Register PPI Notify: F894643D-C449-42D1-8EA8-85BDD8C65BDE > > About to call MrcInit(); > > BayleyBay Platform Type > > RID = 0x11. > > Reg_EFF_DualCH_EN = 0x40030040. > > CurrentMrcData.BootMode = 4 > > Configuring Memory Start... > > START_RMT: > > RxDqLeft RxDqRight RxVLow RxVHigh TxDqLeft > TxDqRight CmdLeft CmdRight > > > > > Channel 0 Rank 0 -23 24 -24 16 -27 > 28 0 0 > > STOP_RMT: > > CMD module is per channel only and without Rank differentiation > > Configuring Memory End > > UpperTotalMemory = 0x8000 > > dBMBOUND = 0x8000 > > dBMBOUNDHI = 0x8000 > > dGFXBase = 0x7BE0 > > dTSegBase= 0x7B00 > > Save MRC params. > > > > Coreboot is version coreboot-4.5 > > Intel FSP is Baytrail_FSP_Gold4 > > > > I realise I am in the Intel FSP so do not think it is a direct coreboot > problem but has anybody got a similar debug setup and can confirm it works? > If it should work maybe we have a board fault in the jtag area. It just > seems weird at this point. > > > > Many thanks, > > Graham Perkins. > > > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org > ___ coreboot mailing list --
[coreboot] Re: Intel Braswell uploads
She's not working at Intel any more, so I don't think there will be response there. On Wed, Feb 27, 2019 at 4:00 PM Frans Hendriks wrote: > Hi, > > Still no response from MAINTAINERS. > > Is there a way have to trigger review/merge/reply? > Or just keep waiting? > > Best regards, > Frans > > -Original Message- > From: Angel Pons [mailto:th3fan...@gmail.com] > Sent: vrijdag 1 februari 2019 11:13 > To: Frans Hendriks > Cc: coreboot@coreboot.org; hannah.willi...@intel.com > Subject: Re: [coreboot] Intel Braswell uploads > > Hello, > > On Fri, Feb 1, 2019 at 10:53 AM Frans Hendriks > wrote: > > > > Hi, > > > > I'm working on Intel Braswell implementation and uploaded several > patches. > > > > It seems that the maintainer of the Intel Braswell is not active for > review/merge/reply of the uploads. > > Is the maintainer in MAINTAINERS document correct and still active? > > > > Met vriendelijke groet / Best regards, > > Frans Hendriks > > Eltan B.V. > > ___ > > coreboot mailing list -- coreboot@coreboot.org > > To unsubscribe send an email to coreboot-le...@coreboot.org > > There are mail addresses on MAINTAINERS. I CC'd this message to the > maintainer for braswell so that they can reply to it. > > Best regards, > > Angel Pons > > > > > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: hang in walkcbfs.S on skylake SP
Yes you are right, .s is purely assembly file. On Wed, Feb 13, 2019, 4:20 PM Kyösti Mälkki wrote: > > > I am not sure you have access to some kind of XDP or Jtag, but an general >> idea is after romcc complied the code may looks different. You may use >> objdump to double check that, such as compare the disasemble on DUT and >> disasemble from objdump. > > > Well the first suspect was .S file so it does not go thru C compiler. It > was also skylake platform so it would not be romcc even for bootblock. > > Sometimes system watchdogs can fool you to believe a fault between two > POST codes, when it's really hitting some timeout. > > Kyösti > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: hang in walkcbfs.S on skylake SP
I am not sure you have access to some kind of XDP or Jtag, but an general idea is after romcc complied the code may looks different. You may use objdump to double check that, such as compare the disasemble on DUT and disasemble from objdump. I have not been able to work on that platform before, just a general idea. On Wed, Feb 13, 2019, 3:32 PM Jonathan Zhang wrote: > Hi, I am working on porting coreboot to Skylake SP and OCP Tiogapass > with FSP 2.0. I have a strange issue that I hope to get some wisdom. > The boot hangs when executing this line "sub %ecx, %ebx" in > src/arch/x86/walkcbfs.S; the post code showing up is 0xb1. > > When I add a spinloop before this statement "sub %ecx, %ebx", the > postcode stays at 0x21, which means code execution till this point is > smooth. > > My codebase is based on current tip of upstream code. In the .config > file, following are set (greping BOOTBLOCK): > CONFIG_C_ENV_BOOTBLOCK_SIZE=0x1 > CONFIG_BOOTBLOCK_CPU_INIT="soc/intel/fsp_skylake_fsp/bootblock/bootblock.c" > CONFIG_ARCH_BOOTBLOCK_X86_32=y > CONFIG_BOOTBLOCK_SIMPLE=y > CONFIG_BOOTBLOCK_SOURCE="bootblock_simple.c" > CONFIG_BOOTBLOCK_CONSOLE=y > CONFIG_C_ENVIRONMENT_BOOTBLOCK=y > > Any pointer is appreciated. Let me know if you need any additional > information. > > Thank you, > Jonathan > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: To modify MCTRL.SPDDIS of Intel Denvertion in coreboot
set PcdSmbusSpdWriteDisable to disable? On Mon, Jan 14, 2019 at 8:28 PM Hilbert Tu(杜睿哲_Pegatron) < hilbert...@pegatroncorp.com> wrote: > Hi, > > Is there anyone can tell me how to change MCTRL.SPDDIS in Coreboot? > > > > The Intel Denverton blocks write permission to address A0~AE due to > security concern of DIMM SPD, but this also restricts the write access to > generic EEPROM access in our platform. So I need to modify the SPDDIS bit > to bypass the protection. But I don’t know how to do that in Coreboot. > Please help and thanks in advance. > > > > -Hilbert > This e-mail and its attachment may contain information that is > confidential or privileged, and are solely for the use of the individual to > whom this e-mail is addressed. If you are not the intended recipient or > have received it accidentally, please immediately notify the sender by > reply e-mail and destroy all copies of this email and its attachment. > Please be advised that any unauthorized use, disclosure, distribution or > copying of this email or its attachment is strictly prohibited. > 本電子郵件及其附件可能含有機密或依法受特殊管制之資訊，僅供本電子郵件之受文者使用。台端如非本電子郵件之受文者或誤收本電子郵件，請立即回覆郵件通知寄件人，並銷毀本電子郵件之所有複本及附件。任何未經授權而使用、揭露、散佈或複製本電子郵件或其附件之行為，皆嚴格禁止。 > > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
Re: [coreboot] Can we please remove the FSP TempRamInit option (where applicable)
Yes, I believe we should let mainboard to select CAR implementation instead of force selection in soc Kconfig. I will suggest to remove that line. On Tue, Nov 6, 2018 at 10:12 AM Nico Huber wrote: > Hi coreboot fellows, > > I have always been confused that we have the option to use FSP's > TempRamInit (CAR setup) even when a native coreboot implementation is > available. Now, what I'm really concerned about is the low quality of > the code in coreboot surrounding it. There are often Kconfig prompts > that don't add up, and about every related, merged commit I've been > looking at today seemed somehow flawed. > > So if we can't keep the quality we are used to when trying to maintain > two (or even more) CAR options, why not focus on a single one? After > all, coreboot is a firmware framework, not an FSP testing framework. > > Here's just one weird example of what I was confronted with today: > > default USE_CANNONLAKE_CAR_NEM_ENHANCED if > MAINBOARD_HAS_CHROMEOS > > I don't understand it, but somehow feel offended. Does that mean I have > to work with ChromeOS now to get reasonable defaults? > > Nico > > -- > coreboot mailing list: coreboot@coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot > -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] CoffeeLake RVP11: Post code 0x7A "SELF Payload doesn't target RAM:
The "Invalid FSPM signature" at this stage, if FspUpd.h for coffeelake already there. maybe "XIP mode" had not been selected in config file? On Tue, Oct 30, 2018 at 10:42 PM Jose Trujillo wrote: > Thank you Lance; > > I got back to 4.8.1 because on master of 2 weeks ago I was getting post > code 0x34 "Invalid FSPM signature"; but I will try again. > Coreboot engineers have been doing much work on integrating FSP to > coreboot and may be the reason has been unstable. > > Jose. > > ‐‐‐ Original Message ‐‐‐ > On Wednesday, October 31, 2018 4:08 AM, Lance Zhao > wrote: > > Feels like CoffeeLake RVP11 still been actively uploaded with newer > changes. But at least your coreboot code seems to be outdated, all of those > coffeelake-h related ID(CPUID and MCH/PCHID) had been up-streamed recently. > I will suggest you to sync up your code base and try again. > > Lance > > On Tue, Oct 30, 2018 at 7:10 AM Jose Trujillo via coreboot < > coreboot@coreboot.org> wrote: > >> Hello coreboot engineers: >> >> I am using the "coffeelake RVP11" to test the code on my "non RVP" system. >> The payload doesn't load. >> >> I found several errors in the attached log: >> >> 1.- Device ID's of the system are still not existant in coreboot. >> 2.- Misconfigured # of MAX CPU CORES. >> 3.- Maybe memory is still not properly initialized because RVP platform >> uses LPDDR4 and use SPD.bin VS my system that use DDR4 SO-UDIMM on SMB SPD >> channel. >> >> Please help me to identify the root of the problem that causes RAM >> "Failed Segment" >> Thank you in advance. >> Jose Trujillo. >> -- >> coreboot mailing list: coreboot@coreboot.org >> https://mail.coreboot.org/mailman/listinfo/coreboot >> > > -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] CoffeeLake RVP11: Post code 0x7A "SELF Payload doesn't target RAM:
Feels like CoffeeLake RVP11 still been actively uploaded with newer changes. But at least your coreboot code seems to be outdated, all of those coffeelake-h related ID(CPUID and MCH/PCHID) had been up-streamed recently. I will suggest you to sync up your code base and try again. Lance On Tue, Oct 30, 2018 at 7:10 AM Jose Trujillo via coreboot < coreboot@coreboot.org> wrote: > Hello coreboot engineers: > > I am using the "coffeelake RVP11" to test the code on my "non RVP" system. > The payload doesn't load. > > I found several errors in the attached log: > > 1.- Device ID's of the system are still not existant in coreboot. > 2.- Misconfigured # of MAX CPU CORES. > 3.- Maybe memory is still not properly initialized because RVP platform > uses LPDDR4 and use SPD.bin VS my system that use DDR4 SO-UDIMM on SMB SPD > channel. > > Please help me to identify the root of the problem that causes RAM "Failed > Segment" > Thank you in advance. > Jose Trujillo. > -- > coreboot mailing list: coreboot@coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot > -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Bootblock CMOS default and the checksum algo
1) Will CMOS reset typically result in zeroed out CMOS? Should we assume that it probably does? Is this a common case? I don't think so, RTC will kepp on counting. We may assume so if only use extended CMOS like 0x72/0x73. On Sat, Oct 6, 2018 at 7:28 PM William McCall wrote: > Hey all-- > > Recently, I started the process of enabling CMOS-based runtime config > on a board. As this board is native coreboot and it had never used the > CMOS in any meaningful sense, the CMOS was wholly zeroed out. > > Based on this, the bootblock never programs the defaults. Why? Because > the checksum algorithm sums with a constant of 0 and simply sums the > bytes. This wasn't always the case, but was changed here: > http://review.coreboot.org/279 > > Downstream effects of this can be seen in nvramcui. As the CMOS is > zeroed, some enums (like debug_level) do not define a value at zero. > As a result, nvramcui ends up with a null pointer deref when trying to > set these enums. > > Questions for the list: > 1) Will CMOS reset typically result in zeroed out CMOS? Should we > assume that it probably does? Is this a common case? > > 2) To fix this, bootblock could look at options table checksum and use > a different constant or NOT the result. Is this reasonable to do in > bootblock? (My opinion is probably not) > > 3) As a workaround, an image could be used with > CONFIG_STATIC_OPTION_TABLE to force initial programming. Is a special > image acceptable if we assume question 1 is answered "yes"? > > 4) Should nvramcui be fixed to handle bogus enums? > > 5) What documentation of this behavior makes sense? > > Also open to other solutions, thoughts, etc. Depending on the results > of this convo, I'll send patches/doc updates over that make sense. > > TIA, > -- > William McCall > > -- > coreboot mailing list: coreboot@coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot > -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Is this fake news or not? Bloomberg says China is using a rice-sized chip to hack amazon servers.
Well said about open and auditable, On Thu, Oct 4, 2018 at 10:53 AM wrote: > If there are any mailing lists which are more suitable to this discussion, > please mention them so we may subscribe to them and discuss this there. > > > > David Hendricks hat am 4. Oktober 2018 um > 19:00 geschrieben: > > > > > > On Thu, Oct 4, 2018 at 9:22 AM Patrick Georgi via coreboot < > > coreboot@coreboot.org> wrote: > > > > > But generally speaking: that discussion is rather off topic for this > > > mailing list. > > > Please look for some more suitable venue to discuss "people potentially > > > tampering other people's devices (with no obvious connection to > coreboot)". > > > > > > > Patrick is right that the Bloomberg article is not particularly > well-suited > > for the coreboot mailing list. > > > > However, it's still worth pointing out that supply chain attacks are a > > serious threat. This could be in the form of added hardware (like the > > Bloomberg article suggests) or it could be in the form of firmware that > > contains malicious code from any of the many parties involved in creating > > it. > > > > Traditionally, firmware contains modules from the silicon vendor, a > > software vendor (IBV/ISV) who packages it with their SDK and value-add > > software, and ODMs/OEMs who make further product-specific additions. > Modern > > firmware can easily contain over a million lines (or multiple millions of > > lines) of code from several parties, and this code runs at the highest > > privilege level before any OS-based security mechanism comes into play. > > Anyone in that part of the supply chain can slip in malicious code, and > the > > customer usually doesn't have any way of viewing the code or tracing > where > > it came from due to its closed nature. > > > > That is relevant to coreboot insofar as coreboot has been leading the > > charge (with varying levels of success) for open and auditable firmware > on > > x86 platforms for nearly two decades. > > -- > > coreboot mailing list: coreboot@coreboot.org > > https://mail.coreboot.org/mailman/listinfo/coreboot > > -- > coreboot mailing list: coreboot@coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot > -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SPI controller and Lock bits
Okay, then I believe we should leave the decision on CONFIG instead of force lockdown blindly. As of now, that's still optional I believe. On Thu, Sep 27, 2018 at 3:49 AM Nico Huber wrote: > Am 26.09.18 um 22:26 schrieb Lance Zhao: > > I am reading the "flash security recommendation" from PCH BIOS writer > > guide now, it did say strongly recommend to take those actions. The EISS > > feature to ensure BIOS region can only get modfiyed from SMM. > > The EISS bit is a highly questionable feature. It's part of the lost > cause of security by treating SMM more privileged than the OS. AFAIK, > coreboot vendors have secured flash access properly in the past without > SMM features and never failed [1]. OTOH, UEFI vendors often granted SMM > full flash access in the past and failed to secure SMM [2]. > > To my knowledge, EISS is incompatible to vboot btw. (not by design but > to the current implementation). > > So I "strongly recommend" to ignore Intel's SMM recommendations wrt. > flash access and recommend instead to never grant SMM more privileges > than the OS. > > Nico > > [1] At least since the introduction of SPI flash chips. Earlier there > were possible race conditions regarding the BIOS Write Enable bit > where you needed SMM for protection, or had to use the flash chip's > own security features. But that was before/maybe why EISS became a > feature. > [2] e.g. https://github.com/Cr4sh/ThinkPwn (the list of vulnerable > systems is long and incomplete) > -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SPI controller and Lock bits
I am reading the "flash security recommendation" from PCH BIOS writer guide now, it did say strongly recommend to take those actions. The EISS feature to ensure BIOS region can only get modfiyed from SMM. On Wed, Sep 26, 2018 at 7:01 AM Nico Huber wrote: > Am 26.09.18 um 10:50 schrieb Patrick Rudolph: > > Hi Youness, > > On 2018-09-26 01:30 AM, Youness Alaoui wrote: > >> Hi, > >> > >> I'm trying to add a way to lock the SPI flash to be read-only via > >> software *after* coreboot boots. The scenario is basically with using > >> Heads, you could authenticate to it (with a yubikey/nitrokey/librem > >> key) then be able to flash a new rom (update your BIOS), but once you > >> boot an OS, Heads would first lock the flash so it can't be written > >> to. > >> This should add some security to avoid any malware writing to the > >> flash, or someone booting into a USB stick and using that to flash a > >> malicious BIOS, but still gives the user the freedom of updating their > >> flash whenever they want to. > >> > >> The problem is that I can't make the flash read-only because the SPI > >> interface is already locked down by coreboot (see > >> src/soc/intel/skylake/lockdown.c and > >> src/soc/intel/common/block/fast_spi/fast_spi.c). > >> > >> There's a couple of things happening here : > >> First, the FLOCKDN bit is set which prevents us from enabling the > >> write protection. the BIOS Interface lock down is controlled by the > >> chipset_lockdown config variable, but the FLOCKDN is not behind a > >> config variable. > >> The second thing is that if I wanted to use the protected ranges > >> feature to lock specific regions, they are all getting locked using > >> the discrete lock register even while being unused. The locking of the > >> protected ranges was added in this change : > >> https://review.coreboot.org/c/coreboot/+/21064 and it passed without > >> notice among the move that the commit was supposed to do. > >> > >> The commit states that the lockdown is meant to "support platform > >> security guidelines", but I think that this is not actually good > >> because coreboot leaves everything read-write and locks down the > >> registers so we can't make it read-only. I think that the security > >> guidelines would say to disable the write protection before locking > >> the registers down. > >> > > Feel free to propose a new "security guideline", but document it in the > > tree. > > > > A similar mechanism is already implemented on Intel: > > https://review.coreboot.org/#/c/coreboot/+/21327/ > > Please note this is about having the whole chip protected. But not about > the decision whether or not to lock this configuration. It reminds me of > something, though: If you want to do such configuration in the payload, > both coreboot and payload code/configuration have to be kept in sync > if you have suspend-to-ram. Because coreboot has to do the same confi- > guration as the payload on the resume path (where the payload is not > executed). > > One way would be to let coreboot decide, e.g. prepare the configuration > and don't lock it, and let the payload lock. The payload could validate > this configuration before locking (and issue a warning if coreboot > didn't set the expected bits). > > Nico > -- > coreboot mailing list: coreboot@coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Recovery
I know UEFI payload have shell, where you can run disk operation or select alternative boot device. On Tue, Sep 18, 2018 at 12:51 PM Sebastian wrote: > Could there be some mechanism to repair broken OS setups? > Maybe chroot or like android does with factory reset? > > I mean, I've been using Arch on Pi3 and updated libidn but not systemd and > now I've got access to Coreboot only. My fault, but some mechanism for > repairing broken installs seems vital as various things might happen. > > On the other hand I could just forget all that and...-- > coreboot mailing list: coreboot@coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] how to change PCI device's PFA
Those devices have been fixed from chipset, I don't think any software side can change that. I will prefer to have a quick scan of PCI spec 2.2 first, which mentioned that clearly. On Thu, Aug 30, 2018 at 11:44 PM Hilbert Tu(杜睿哲_Pegatron) < hilbert...@pegatroncorp.com> wrote: > Hi, > > In my devicetree.cb of Intel Harcuvar CRB, I see the following PCI > configuration: > device pci 14.0 on end # SATA Controller 1 > device pci 15.0 on end # XHCI USB Controller > > Can I change the device number for each different PCI device? For example, > device pci 16.0 on end # SATA Controller 1 > device pci 17.0 on end # XHCI USB Controller > > Is this PCI enumeration same in Coreboot and kernel? Or can I change it > dynamically? > > Thanks. > -Hilbert > This e-mail and its attachment may contain information that is > confidential or privileged, and are solely for the use of the individual to > whom this e-mail is addressed. If you are not the intended recipient or > have received it accidentally, please immediately notify the sender by > reply e-mail and destroy all copies of this email and its attachment. > Please be advised that any unauthorized use, disclosure, distribution or > copying of this email or its attachment is strictly prohibited. > > 本電子郵件及其附件可能含有機密或依法受特殊管制之資訊，僅供本電子郵件之受文者使用。台端如非本電子郵件之受文者或誤收本電子郵件，請立即回覆郵件通知寄件人，並銷毀本電子郵件之所有複本及附件。任何未經授權而使用、揭露、散佈或複製本電子郵件或其附件之行為，皆嚴格禁止。 > -- > coreboot mailing list: coreboot@coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] x86 SMM handler Local APIC assumptions
Without x2apic mode, APIC_ID register will not be moved by OS. Those address normally had been tagged as reserved and will not be touched. I believe that x2apic will apply for processors number more than 255, so majority cases in coreboot didn't touch that area yet. On Tue, Aug 28, 2018 at 7:50 AM Andrew Cooper wrote: > Hello, > > While looking at some code, I noticed that twice (once in asm, and again > later in C), the SMM handler assumes that 0xfee00020 is the APIC_ID > reigster in the xAPIC MMIO window. > > This isn't true if the OS has moved the MMIO window, or switched to > x2apic mode (on supporting hardware). > > As a result, it looks like its rather easy to feed a kernel-controlled > value into Coreboot's idea of its Local APIC id, which can either be the > same on all cores (reuse of the same stack) or wildly out of range > (albeit, at least bounded to 255). > > To fix, I'd expect Coreboot to read MSR_APIC_BASE, and either cope with > x2apic mode (which is surely easier than switching APIC mode, as you've > got to cycle through off to switch back to xAPIC mode), or > save/remap/restore the APIC MMIO window. > > Without paging, you can't address an APIC MMIO window above the 4G > boundary. > > Is this something you care about? > > Thanks, > > ~Andrew > > -- > coreboot mailing list: coreboot@coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot > -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
