[coreboot] Why my ACPI device conflicts with "PCI Bus"
Hi, All,
I am debugging the UART device on Bettong(AMD Carrizo).
The device
"
Device(FUR0) {
Name(_HID,"AMD0020")
Name(_UID,0x0)
Name(_CRS, ResourceTemplate() {
IRQ(Edge, ActiveHigh, Exclusive) {10}
Memory32Fixed(ReadWrite, 0xFEDC6000, 0x2000)
})
Method (_STA, 0x0, NotSerialized) {
Return (0x0F)
}
}
"
is added to DSDT. On linux, it doesnt show any error or warning. On Windows,
the device manager can show the DEVICE "AMD0020". But it says the 0xFEDC6000
is used by other device "PCI Bus".
I checked the whole DSDT and can not find which device conflicts with that?
Any suggestion what else I can check?
Zheng
dsdt-bettong-coreboot.dsl
Description: dsdt-bettong-coreboot.dsl
ssdt1-bettong-coreboot.dsl
Description: ssdt1-bettong-coreboot.dsl
--
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] ASUS KFSN4-DRE (K8) Automated Test Failure [master]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/21/2016 03:48 PM, Raptor Engineering Automated Coreboot Test Stand wrote: > The ASUS KFSN4-DRE (K8) fails verification for branch master as of commit > 6268e2eecf235af9dd77b5f6cee8c0365fc5 > > The following tests failed: > BOOT_FAILURE Due to the continued presence of this regression in coreboot, and the fact that no one has stepped up to work on it, we have disabled the AMD K8 tests on our REACTS system. This should restore the REACTS to its intended functionality. Should someone step up to work on the AMD K8 CAR and/or MCT code, which appears to be at fault here, please send an Email with your proposed changeset so that it can be tested and the K8 board re-added. Thank you, - -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 (direct line) +1 (512) 690-0200 (switchboard) https://www.raptorengineering.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJXuyO5AAoJEK+E3vEXDOFb0cAIAIWD6Y7KBQIHxhAD1MP2PchG JZYxNkHLbFk+ziENXd8zB74HFwsUiz2f1vdGuB2XlYv+aDMgBSvVhkb3NLBUSMXM nOrJZvXtwoWOoZdHhCg/Htk9I4Qrg13+oV07YVriew5wsep1e0g4DNhs0tKLhYEV 1Wu+EKsgHxzSfVeqKKePV7b/Y4/zgbaoRRO058fAMdmZ16/QSkcndIhv8ZLepKuZ B9tvxEfG66VJwDn6R4URCCBKJkoEtkan2QKYMltpTCU1EbMRb6tB3qDUQI35UcNr oDqKoo9ybkoQHpb2L5pTVx5pCsz24Qw/pg74FNcbUK4lDyG+X+yEorEGW/f2byg= =QH75 -END PGP SIGNATURE- -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Why my ACPI device conflicts with "PCI Bus"
Hi Zheng,
What version of Windows are you using? I've seen differences in the
behavior of the arbiters as Windows has matured. I don't notice anything
incorrect in your ASL. Does your FUR1 device come up with no conflicts,
and only FUR0 has problems?
Are you able to run WinDbg and get the failure? Depending on the
generation, you might have Ethernet or USB available for debug as well, if
you need a different option. I might start with this:
https://msdn.microsoft.com/en-us/library/windows/hardware/ff562124(v=vs.85).aspx
... using "!arbiter 2" to dump the memory assigned in the system. That
would hopefully show you the conflict ('C' flag) and ownership, possibly
giving you additional clues and a direction to look. In theory, this
should be somewhat identical to looking at resources-by-connection in the
Device Manager, but you'll have more options for debugging.
Maybe also dump the device tree with "!devnode 0 1" and make sure items are
scoped where you believe they should be.
The fact that FEDC6000 is used by PCI Bus seems pretty odd, like the bus
consumes the memory without bridging or arbitrating it. Unless I missed
it, I don't see anything like that in your DSDT. As an experiment, maybe
try adding a ResourceProducer for FEDC6000 under PCI0 and see if the
problem goes away. If it does, I'll have to think more about what that
means.
Thanks,
Marshall
On Mon, Aug 22, 2016 at 6:20 AM, Zheng Bao wrote:
> Hi, All,
>
> I am debugging the UART device on Bettong(AMD Carrizo).
>
>
> The device
>
> "
> Device(FUR0) {
> Name(_HID,"AMD0020")
> Name(_UID,0x0)
> Name(_CRS, ResourceTemplate() {
> IRQ(Edge, ActiveHigh, Exclusive) {10}
> Memory32Fixed(ReadWrite, 0xFEDC6000, 0x2000)
> })
> Method (_STA, 0x0, NotSerialized) {
> Return (0x0F)
> }
> }
> "
>
> is added to DSDT. On linux, it doesnt show any error or warning. On
> Windows,
>
> the device manager can show the DEVICE "AMD0020". But it says the
> 0xFEDC6000
>
> is used by other device "PCI Bus".
>
> I checked the whole DSDT and can not find which device conflicts with that?
>
>
> Any suggestion what else I can check?
>
>
> Zheng
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot
>
--
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] New on blogs.coreboot.org: [GSOC] Panic Room, week #8, *
A new post titled "[GSOC] Panic Room, week #8,*" has been published on the coreboot blog. Find the full post at http://blogs.coreboot.org/blog/2016/08/22/gsoc-panic-room-week-8-onward/ What have you worked on during the past few weeks? I tried to finish one of the optional goals of my proposal: a way to access a payload (possibly a recovery) after the hardware initialisation is complete but the OS has still not taken over. To define it in more practical terms, I wanted to replace the running payload at the press of a predefined button. I started by looking into the SMM (System Management Mode) and in particular the SMI (System Management Interrupts) handlers defined by each target board in the coreboot tree. That was the easy part, it took just a bit of probing my board (Lenovo x60) and a serial cable to retrieve some of the SMI button codes (I planned on using the ThinkAdvantage button, code 0x19). I added it to the appropriate smihandler.c file, defined the behaviour and that was about it. The more difficult part was actually implementing a way to make it possible to boot a new payload while in SMM. SMM can be considered a separate “module” from romstage, etc, this consequently means that it does not have access to all of the same functions. In particular it cannot access the load_payload() and run_payload() functions defined inside prog_loaders.c, which, as the name implies, are necessary in order to use a payload. In order to solve the problem I came up with two designs: The first design is quite simple, but in my opinion a bit messy. It involves including all of the missing source files into the SMM module at compile time, a.k.a adding more entries inside the Makefile.inc scattered around the source tree. I went down this route for a while until I stumbled on a function that needed to use a malloc(), this was expected so I included the definition of that function. It then asked to have access to the heap (_eheap) in order to allocate the memory requested, the problem is that the heap is not defined inside SMM. I grepped through the source code and found very little about what I was supposed to do in order to define it, so I had to let it go. (To add a little bit of context, this was yesterday and if you take a look at this post’s date you’ll realise that there is only 1 day left of GSoC, panic!) The second approach consists of leaving SMM mostly as it is now, and instead find a way to communicate with ramstage, in order to boot the desired payload. The thought process was that, if cannot call a function directly from SMM, I would have to use the functions already in place in ramstage, unfortunately those functions are called only once, after the initialisation is done. This is where the CMOS memory comes in, I modified the payload loading process and instead of using an hard-coded path defined at compile-time, I made it check for a string inside CMOS and use that as the payload path. This method, however, also presented some problems: – It seems that currently cmos.defaults is completely ignored and the CMOS string values are not initialised as intended (at least on my board), therefore the payload path resulted always blank. – There needs to be quite a bite of space in the CMOS to keep the path there. The usual path (fallback/payload), occupies around 160 contiguous bits of the 1024 available ones, which also need to share space with other important configuration bits such as RTC, etc. In order to circumvent these limitations it would be possible to replace the string path in the CMOS with an enumeration of the possible paths, this however would need to be defined, maintained and shared both in the CMOS and the rest of coreboot. However, same as above, I ran out of time. That about sums it up for the past few weeks. Thank you for reading and have a nice week. -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
