Dear coreboot folks,
On the Lenovo T60p (with external AMD/ATI graphics) there was unfortunately a regression in the master branch. As it is bricked now, I am only able to provide logs, and won’t be able to test or bisect for quite some time.
I successfully tested 4.11-1593-g49111cd2ba [1] as the last commit, and 4.12-406-g87e36c442e [2] has issues.
The first issue is, that SeaBIOS hangs in around 90 % of the time in:
Running option rom at c000:0003
The only remarkable difference in the logs is:
-PCI: 06:00.0 bridge ctrl <- 016b +PCI: 06:00.0 bridge ctrl <- 0143
I created ticket #266 [3] for that.
To debug this further, I tried to set up fallback/normal scheme, so switched from simple to normal bootblock, and added the “normal boot files”, but now it already hangs in coreboot when decompressing the payload. (I hadn’t reset the reboot counter yet, so it still uses the formerly working fallback files.)
``` coreboot-4.12-406-g87e36c442e Mon Jun 1 19:06:28 UTC 2020 bootblock starting (log level: 8)... […] CBFS: Locating 'fallback/payload' CBFS: Found @ offset 4d3c0 size 11109 Checking segment from ROM address 0xffe4d5f8 Checking segment from ROM address 0xffe4d614 Loading segment from ROM address 0xffe4d5f8 code (compression=1) New segment dstaddr 0x000dfac0 memsize 0x20540 srcaddr 0xffe4d630 filesize 0x110d1 Loading Segment: addr: 0x000dfac0 memsz: 0x0000000000020540 filesz: 0x00000000000110d1 using LZMA ```
``` FMAP REGION: COREBOOT Name Offset Type Size Comp cbfs master header 0x0 cbfs header 32 none fallback/romstage 0x80 stage 50076 none cpu_microcode_blob.bin 0xc480 microcode 86016 none fallback/ramstage 0x21500 stage 79299 none config 0x34b00 raw 589 none revision 0x34dc0 raw 674 none fallback/dsdt.aml 0x350c0 raw 12600 none cmos.default 0x38240 cmos_default 256 none cmos_layout.bin 0x38380 cmos_layout 1664 none pci1002,7149.rom 0x38a40 optionrom 64512 none fallback/postcar 0x486c0 stage 19616 none fallback/payload 0x4d3c0 simple elf 69897 none payload_config 0x5e540 raw 1621 none payload_revision 0x5ec00 raw 222 none etc/ps2-keyboard-spinup 0x5ed40 raw 8 none (empty) 0x5ed80 null 4568 none normal/romstage 0x5ff80 stage 50076 none normal/ramstage 0x6c380 stage 79299 none normal/dsdt.aml 0x7f980 raw 12600 none normal/postcar 0x82b00 stage 19616 none normal/payload 0x87800 simple elf 47498 none (empty) 0x931c0 null 1461208 none bootblock 0x1f7dc0 bootblock 32768 none ```
I created ticket #267 [4] for that, and attached the coreboot image and full logs there.
Kind regards,
Paul
[1]: https://review.coreboot.org/cgit/board-status.git/tree/lenovo/t60/4.12-406-g... [2]: https://review.coreboot.org/cgit/board-status.git/tree/lenovo/t60/4.11-1593-... [3]: https://ticket.coreboot.org/issues/266 [4]: https://ticket.coreboot.org/issues/267
Hi Paul,
On 28.06.20 11:35, Paul Menzel wrote:
The only remarkable difference in the logs is:
-PCI: 06:00.0 bridge ctrl <- 016b
this seems very suspicious. Bit 3 enables VGA decoding. It shouldn't matter because it's behind another bridge that hasn't the bit set, but still, WTF? I have no idea how this could end up being set (unless hardware is borked and the device wasn't reset properly). Was this on a cold boot? If yes, something in coreboot went wrong.
Nico
Dear Nico,
Am 28.06.20 um 13:21 schrieb Nico Huber:
On 28.06.20 11:35, Paul Menzel wrote:
The only remarkable difference in the logs is:
-PCI: 06:00.0 bridge ctrl <- 016b
this seems very suspicious. Bit 3 enables VGA decoding. It shouldn't matter because it's behind another bridge that hasn't the bit set, but still, WTF? I have no idea how this could end up being set (unless hardware is borked and the device wasn't reset properly). Was this on a cold boot? If yes, something in coreboot went wrong.
I am pretty sure it is, but probably with battery and power cable still connected. When it hung in SeaBIOS, I had to press the power button for around ten seconds, and then I started the system by pressing the power button again. It could also have been after the `LP S4# Assertion Width Violation` though [1].
LP S4# Assertion Width Violation. Reset required. full_reset() called!
Kind regards,
Paul
[1]: https://mail.coreboot.org/pipermail/coreboot/2017-January/083059.html
-
Nico Huber -
Paul Menzel