Lenovo T60p: Regression in master branch (resource allocator changes?)

[Paul Menzel]

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

[Nico Huber]

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

[Paul Menzel]

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