On 03.04.2018 03:16, Naresh G. Solanki wrote:
> coreboot-4.7-51-g2ca4ca3f21-dirty Thu Jan 18 22:05:03 UTC 2018
> romstage starting...
> pm1_sts: ffff pm1_en: ffff pm1_cnt: ffffffff
> gpe0_sts[0]: ffffffff gpe0_en[0]: ffffffff
> gpe0_sts[1]: ffffffff gpe0_en[1]: ffffffff
> gpe0_sts[2]: ffffffff gpe0_en[2]: ffffffff
> gpe0_sts[3]: ffffffff gpe0_en[3]: ffffffff
>
I've seen (and fixed) this before. I suspect you have to `select
SKYLAKE_SOC_PCH_H` in your Kconfig.
> It seems to me that PM base is not setup properly.(this should be fixed first)
>
Right, please fix things from top to bottom. You can't expect everything
to work if you have earlier problems in your log.
Nico
How soon after reset are port 0x80 messages available on a MiniPCIe
attached POST card? And would the POST card be expected to work with
a M.2 to MiniPCIe adapter? How is the ISA bus' I/O address space mapped
to PCIe devices?
I'm dealing an early bring-up problem on a modern architecture without
serial ports and wondering if that would a good way to debug it.
--
Trammell
> Hello everybody!
>
> I have problems with getting coreboot running on a Lenovo ThinkPad
> T430.
> Better to say: Running with the integrated second graphics adapter NVS
> 5400M. The Intel HD 4000 is working fine and from the wiki I know that
> NVidia Optimus is not supported for now. So what to do exactly getting
> the graphics adapter running? Even only NVidia only would be great.
> Both
> adapters are not needed on GNU-Linux for my usecase. I have two
> VGA-ROMs
> extracted and compiled this using the concurrent stable-version 4.7.
> Is
> this wrong? Some help and hints would be appreciated.
>
> Best regards,
> Tobias.
Hello Tobias,
You can switch between GPUs by changing the value of the
hybrid_graphics_mode CMOS setting using nvramcui or nvramtool.
Currently, for the T430 this field can be set to either Integrated only
or Dedicated only. Make sure you are using CMOS for configuration
values. Unfortunately, I was unable to switch the power for the dGPU
off at all, which resulted in rather high power consumption even if
only the integrated GPU is enabled.
Regards,
Michał Kopeć
Hi,
Looking at
coreboot-4.7-51-g2ca4ca3f21-dirty Thu Jan 18 22:05:03 UTC 2018
romstage starting...
pm1_sts: ffff pm1_en: ffff pm1_cnt: ffffffff
gpe0_sts[0]: ffffffff gpe0_en[0]: ffffffff
gpe0_sts[1]: ffffffff gpe0_en[1]: ffffffff
gpe0_sts[2]: ffffffff gpe0_en[2]: ffffffff
gpe0_sts[3]: ffffffff gpe0_en[3]: ffffffff
It seems to me that PM base is not setup properly.(this should be fixed first)
Also before you use SATA, make sure FspSUpd for sata is set to be
enabled. Also respective sata port is enabled.
Above that, also check in fit tool whether right setting is done for
flex io for sata port.
On Sun, Apr 1, 2018, 6:43 PM Zheng Bao <fishbaoz(a)hotmail.com> wrote:
> I met the same problem. I use the FSP1.1 and the 0:17h:0 disappears after
> raminit.
> It seems that the FSP disable the SATA.
>
> The SATA device can be disabled if SCFD is set. But it can not re-enable.
>
> SATA Controller Function Disable (SCFD): BIOS program this bit to 1 to
> disable
> the SATA Controller function. When 0, SATA Controller function is enabled.
> When
> disable, SATA Host Controller will not claimed the register access
> targeting its
> Configuration Space. In IOSF primary Fabric Decode scheme, it's expected
> BIOS also
> program the corresponding bit used by the Fabric Decoder accordingly hence
> both
> SATA SIP and Fabric Decoder are in sync, and BIOS need to program this bit
> before
> programming the one in Fabric Decoder. Once this bit is set, BIOS isnot
> able to revert
> it back to Function Enable until next round of platform reset.
>
> Zheng
>
> ------------------------------
> *From:* coreboot <coreboot-bounces(a)coreboot.org> on behalf of roman
> perepelitsin <perepelitsin.roman(a)gmail.com>
> *Sent:* Wednesday, March 28, 2018 2:51 PM
> *To:* coreboot(a)coreboot.org
> *Subject:* [coreboot] SATA init on FSP 2.0 for Skylake
>
> Hi!
> I got a little problem with SATA controller in H110 Skylake PCH (desktop).
> SATA device geographical address - 0:17h:0 on PCI, and it enabled via
> devicetree.cb. This params correctly send in FspSiliconInit. After this
> coreboot run PCI bus scan. And my SATA device return 0xffffffff on PCI read
> config cycles. I search in Intel datasheet for specific SATA disable pin or
> something else, but there is no methods that can make SATA inactive. Maybe
> somebody advice about it?
>
>
>
> --
> regards,
> Perepelitsin Roman
> --
> coreboot mailing list: coreboot(a)coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
On 23/03/2018, Thierry Laurion <thierry.laurion(a)gmail.com> wrote:
> If ... ME is disabled with its modules erased, could
> the maker pursue the seller for having made those modifications?
Interesting question. ThinkPenguin seems to be willing to take that
risk, but hedges it by voiding the warranty:
"Backdoors in modern computing devices are unfortunately a certainty
today and while we can't be sure of a fix here it is possible to
partially disable one component believed to be a problem. This option
does have side-effects and will void any return." [1]
(AFAICT, that laptop has the ME "disabled" if the buyer wishes, but it
does not ship with Coreboot or Libreboot.)
[1] https://www.thinkpenguin.com/gnu-linux/penguin-z-gnulinux-laptop
We ran into an issue where we were not getting a full coreboot log on
Denverton with the Harcuvar CRB, where it just abruptly stops the serial
console output during the assignment of the PCI resources.
Root Device assign_resources, bus 0 link: 0
DOMAIN: 0000 assign_resources, bus 0 link: 0
PCI: 00:09.0 1c <- [0x000000ffff - 0x000000fffe] size 0x00000000 gran 0x0c
bus 01 io
PCI: 00:09.0 24 <- [0x00dfffffff - 0x00dffffffe] size 0x00000000 gran 0x14
bus 01 prefmem
PCI: 00:09.0 20 <- [0x00dfffffff - 0x00dffffffe] size 0x00000000 gran 0x14
bus 01 mem
PCI: 00:09.0 10 <- [0x00df700000 - 0x00df71ffff] size 0x00020000 gran 0x11
mem64
PCI: 00:0e.0 1c <- [0x000000ffff - 0x000000fffe] size 0x00000000 gran 0x0c
bus 02 io
PCI: 00:0e.0 24 <- [0x00dfffffff - 0x00dffffffe] size 0x00000000 gran 0x14
bus 02 prefmem
PCI: 00:0e.0 20 <- [0x00dfffffff - 0x00dffffffe] size 0x00000000 gran 0x14
bus 02 mem
PCI: 00:0e.0 10 <- [0x00df720000 - 0x00df73ffff] size 0x00020000 gran 0x11
mem64
PCI: 00:10.0 1c <- [0x000000ffff - 0x000000fffe] size 0x00000000 gran 0x0c
bus 03 io
PCI: 00:10.0 24 <- [0x00dc000000 - 0x00ddffffff] size 0x02000000 gran 0x14
bus 03 prefmem
PCI: 00:10.0 20 <- [0x00de000000 - 0x00de8fffff] size 0x00900000 gran 0x14
bus 03 mem
PCI: 00:10.0 10 <- [0x00df740000 - 0x00df75ffff] size 0x00020000 gran 0x11
mem64
PCI: 00:10.0 assign_resources, bus 3 link: 0
PCI: 03:00.0 1c <- [0x000000ffff - 0x000000fffe] size 0x00000000 gran 0x0c
bus 04 io
PCI: 03:00.0 24 <- [0x00dc000000 - 0x00ddffffff] size 0x02000000 gran 0x14
bus 04 prefmem
PCI: 03:00.0 20 <- [0x00de000000 - 0x00de8fffff] size 0x00900000 gran 0x14
bus 04 mem
PCI: 03:00.0 assign_resources, bus 4 link: 0
PCI: 04:00.0 10 <- [0x00dc000000 - 0x00ddffffff] size 0x02000000 gran 0x19
prefmem
PCI: 04:00.0 14 <- [0x00de820000 - 0x00de823fff] size 0x00004000 gran 0x0e
mem
PCI: 04:00.0 18 <- [0x00de000000 - 0x00de7fffff] size 0x00800000 gran 0x17
mem
PCI: 04:00.0 30 <- [0x00de800000 - 0x00de81ffff] size 0x00020000 gran 0x11
romem
PCI: 03:00.0 assign_resources, bus 4 link: 0
PCI: 00:10.0 assign_resources, bus 3 link: 0
PCI: 00:12.0 10 <- [0x00df77b000 - 0x00df77b3ff] size 0x00000400 gran 0x0a
mem64
PCI: 00:14.0 10 <- [0x00df774000 - 0x00df775fff] size 0x00002000 gran 0x0d
mem
PCI: 00:14.0 14 <- [0x00df77c000 - 0x00df77c0ff] size 0x00000100 gran 0x08
mem
PCI: 00:14.0 18 <- [0x0000001c40 - 0x0000001c47] size 0x00000008 gran 0x03
io
PCI: 00:14.0 1c <- [0x0000001c60 - 0x0000001c63] size 0x00000004 gran 0x02
io
PCI: 00:14.0 20 <- [0x0000001c00 - 0x0000001c1f] size 0x00000020 gran 0x05
io
PCI: 00:14.0 24 <- [0x00df77a000 - 0x00df77a7ff] size 0x00000800 gran 0x0b
mem
PCI: 00:15.0 10 <- [0x00df760000 - 0x00df76ffff] size 0x00010000 gran 0x10
mem64
PCI: 00:16.0 1c <- [0x000000ffff - 0x000000fffe] size 0x00000000 gran 0x0c
bus 05 io
PCI: 00:16.0 24 <- [0x00dea00000 - 0x00deefffff] size 0x00500000 gran 0x14
bus 05 prefmem
PCI: 00:16.0 20 <- [0x00df500000 - 0x00df5fffff] size 0x00100000 gran 0x14
bus 05 mem
PCI: 00:16.0 assign_resources, bus 5 link: 0
PCI: 05:00.0 10 <- [0x00dea00000 - 0x00debfffff] size 0x00200000 gran 0x15
prefmem64
PCI: 05:00.0 20 <- [0x00dee00000 - 0x00dee03fff] size 0x00004000 gran 0x0e
prefmem64
PCI: 05:00.0 30 <- [0x00df500000 - 0x00df57ffff] size 0x00080000 gran 0x13
romem
PCI: 05:00.1 10 <- [0x00dec00000 - 0x00dedfffff] size 0x00200000 gran 0x15
prefmem64
PCI: 05:00.1 20 <- [0x00dee04000 - 0x00dee07fff] size 0x00004000 gran 0x0e
prefmem64
PCI: 05:00.1 30 <- [0x00df580000 - 0x00df5fffff] size 0x00080000 gran 0x13
romem
PCI: 00:16.0 assign_resources, bus 5 link: 0
PCI: 00:17.0 1c <- [0x000000ffff - 0x000000fffe] size 0x00000000 gran 0x0c
bus 06 io
PCI: 00:17.0 24 <- [0x00df000000 - 0x00df4fffff] size 0x00500000 gran 0x14
bus 06 prefmem
PCI: 00:17.0 20 <- [0x00df600000 - 0x00df6fffff] size 0x00100000 gran 0x14
bus 06 mem
PCI: 00:17.0 assign_resources, bus 6 link: 0
PCI: 06:00.0 10 <- [0x00df000000 - 0x00df1fffff] size 0x00200000 gran 0x15
prefmem64
PCI: 06:00.0 20 <- [0x00df400000 - 0x00df403fff] size 0x00004000 gran 0x0e
prefmem64
PCI: 06:00.0 30 <- [0x00df600000 - 0x00df67ffff] size 0x00080000 gran 0x13
romem
PCI: 06:00.1 10 <- [0x00df200000 - 0x00df3fffff] size 0x00200000 gran 0x15
prefmem64
PCI: 06:00.1 20 <- [0x00df404000 - 0x00df407fff] size 0x00004000 gran 0x0e
prefmem64
PCI: 06:00.1 30 <- [0x00df680000 - 0x00df6fffff] size 0x00080000 gran 0x13
romem
PCI: 00:17.0 assign_resources, bus 6 link: 0
PCI: 00:18.0 10 <- [0x00df776000 - 0x00df776fff] size 0x00001000 gran 0x0c
mem64
The boot continues, there's just no more console output from coreboot past
this point. The payload launches fine after coreboot is finished. If we use
a Linux kernel payload, it still successfully sends all of its kernel
console output to the serial console beginning immediately after where the
coreboot console output stopped.
The last device that has its resources assigned that is displayed in the log
is D24, F0 (PCI 00:18.0). The next device in the list to have its resources
assigned is D26, F0 (PCI 00:1a.0), which is UART 0, which is the UART used
for the serial console. So this is starting to make some sense.
Since the BARs are assigned in order, and the first BAR of the UART device
is the I/O BAR at offset 0x10, it's pretty clear that changing the I/O space
resource assigned to the UART is what's clobbering the console. I haven't
looked at it yet, but I'm assuming that the UART driver just caches the base
address early on and doesn't know that the base address changed during PCI
resource assignment later in the boot cycle.
Of course, not only do we lose the console output, but also the UART driver
is still writing the rest of the log to an I/O address that is no longer
associated with the UART, but now potentially assigned to some other PCI
device.
Fortunately, with Denverton, the UART mode can be changed from the default
Non Legacy Mode to Legacy Mode, which appears to have resolved the issue in
this particular case.
However, I can see this as being a general problem on any/all platforms that
don't have a legacy UART (or a UART that can be put in legacy mode). Any
platform with UARTs that strictly use I/O and/or memory mapped registers
that are accessed via PCI BARs have the potential of having the BARs
programmed with different addresses during PCI resource assignment, thus
terminating the console output and otherwise potentially causing other bad
things to happen.
I thought it best to bring this up to the coreboot community, since this
could easily be a problem on any/all platforms that don't have a legacy UART
(or a UART that can be put into legacy mode). Has anybody else run into this
and/or thought about a general solution to this potential problem?
- Jay
Jay Talbott
Principal Consulting Engineer
SysPro Consulting, LLC
3057 E. Muirfield St.
Gilbert, AZ 85298
(480) 704-8045
(480) 445-9895 (FAX)
<mailto:JayTalbott@sysproconsulting.com> JayTalbott(a)sysproconsulting.com
<http://www.sysproconsulting.com/> http://www.sysproconsulting.com
I met the same problem. I use the FSP1.1 and the 0:17h:0 disappears after raminit.
It seems that the FSP disable the SATA.
The SATA device can be disabled if SCFD is set. But it can not re-enable.
SATA Controller Function Disable (SCFD): BIOS program this bit to 1 to disable
the SATA Controller function. When 0, SATA Controller function is enabled. When
disable, SATA Host Controller will not claimed the register access targeting its
Configuration Space. In IOSF primary Fabric Decode scheme, it's expected BIOS also
program the corresponding bit used by the Fabric Decoder accordingly hence both
SATA SIP and Fabric Decoder are in sync, and BIOS need to program this bit before
programming the one in Fabric Decoder. Once this bit is set, BIOS isnot able to revert
it back to Function Enable until next round of platform reset.
Zheng
________________________________
From: coreboot <coreboot-bounces(a)coreboot.org> on behalf of roman perepelitsin <perepelitsin.roman(a)gmail.com>
Sent: Wednesday, March 28, 2018 2:51 PM
To: coreboot(a)coreboot.org
Subject: [coreboot] SATA init on FSP 2.0 for Skylake
Hi!
I got a little problem with SATA controller in H110 Skylake PCH (desktop). SATA device geographical address - 0:17h:0 on PCI, and it enabled via devicetree.cb. This params correctly send in FspSiliconInit. After this coreboot run PCI bus scan. And my SATA device return 0xffffffff on PCI read config cycles. I search in Intel datasheet for specific SATA disable pin or something else, but there is no methods that can make SATA inactive. Maybe somebody advice about it?
--
regards,
Perepelitsin Roman
