Re: [coreboot] [RFH] Native AMD fam10-15 support

[taii...@gmx.com]

Another regression I have noticed is that my 4th SATA hard drive doesn't
appear in linux for some reason, although it does appear in grub...ideas?

Also kyosti what logs and tests would you like? For now I have
re-flashed my old 4.6 coreboot but I will flash master again soon for you.

Tim - Yes I have CC6 enabled in my CMOS and my CMOS.default

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [RFH] Native AMD fam10-15 support

[Kyösti Mälkki]

On Sat, Jul 14, 2018 at 1:46 AM, taii...@gmx.com  wrote:

> Another regression I have noticed is that my 4th SATA hard drive doesn't
> appear in linux for some reason, although it does appear in grub...ideas?
>
> Also kyosti what logs and tests would you like? For now I have
> re-flashed my old 4.6 coreboot but I will flash master again soon for you.
>
>
Output of following after having done S3 resume would be of my interest:
`cbmem -c (or -1)` `cbmem -t` and `dmesg`.

Better have those collected for normal boot path as well.

Also it's worth having low_memory_corruption_check=1 and
low_memory_corruption_check_size=512k as kernel parameters when checking
S3, we have had regressions there for both Intel and AMD, and cases where
initial implementation was just wrong (AGESA).

Kyösti
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [RFH] Native AMD fam10-15 support

[taii...@gmx.com]

Hi guys!

I have just tested my KGPE-D16's suspend a few times with the latest
master and it works fine - takes around a minute to get back to my linux
terminal.

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [RFH] Native AMD fam10-15 support

[taii...@gmx.com]

I will provide logs soon! what do you want exactly?

One apparent regression I have noticed is that "sensors" reports CPU
power usage at idle is now steady at 101W vs the usual 50W (which used
to be 40 before a kernel update) while I am not sure if it is accurate
as the cpu temp doesn't reach high levels expected for such wattage it
does have one bad effect in that Turbo 2 no longer works...and even
before this update with my v4.6 to get Turbo 1 on all cores as AMD
advertises I must use "tpc -psmax 1"[1] which brings up the sensors
reported TDP to 125W whereas normally it wouldn't work due to maxing out
at 115W and 3.35ghz rather than T1 3.5ghz the TDP determining when the
CPU enters full turbo 1.

I use Turbo 2 to obtain better performance on non-multithreaded games so
this is disappointing but I will investigate further.

[1] turionpowercontrol, an overclocking software

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [RFH] Native AMD fam10-15 support

[Kyösti Mälkki]

On Fri, Jul 13, 2018 at 6:44 AM, Timothy Pearson <
tpear...@raptorengineering.com> wrote:

> On 07/12/2018 10:41 PM, Kyösti Mälkki wrote:
> > On Fri, Jul 13, 2018 at 5:41 AM, Timothy Pearson
> > mailto:tpear...@raptorengineering.com>>
> > wrote:
> >
> > Good to know, thanks for testing!  I've been looking into
> relocateable
> > ramstage in case suspend was still failing, but if things fell back
> into
> > place, so to speak, in master we should also look at reactivating
> REACTS
> > with the suspend tests enabled.
> >
> >
> > I never suspected RELOCATABLE_RAMSTAGE=n would be a reason for
> > (possible) S3 regressions. The motivation for having
> > RELOCATABLE_RAMSTAGE=y goes beyond the improvement it has on not having
> > to do low-mem backup S3 resume path. I am also wondering how S3 resume
> > path is taking one minute and how that relates to normal boot path time.
> >
> > Kyösti
>
> My understanding is that without relocateable ramstage, there are
> additional bounce buffers involved that not only slow things down, but
> also introduce new code paths that could be responsible for regressions
> in resume.  I think avph on IRC is looking into an initial port of the
> CAR code for relocateable support, and if things are stable enough in
> master to reactivate the REACTS tests on the KGPE-D16 that would help
> him iterate more quickly.
>
>
Right, with RELOCATABLE_RAMSTAGE=n there is a back-and-forth of low-memory
region ramstage occupies on S3 resume path. Also you do not have benefit of
executing a copy of ramstage that was cached in RAM already on normal boot
path, but have to decompress it again from flash.

The low-memory copy is not that big, RAMBASE..RAMTOP is 3 MiB, so this does
not explain one minute.

Indeed RELOCATABLE_RAMSTAGE=n is already in the minority now and
bounce-buffer logic recently had some regressions for loading some payloads.

Kyösti
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [RFH] Native AMD fam10-15 support

[Timothy Pearson]

On 07/12/2018 11:04 PM, taii...@gmx.com wrote:
> I will provide logs soon! what do you want exactly?
> 
> One apparent regression I have noticed is that "sensors" reports CPU
> power usage at idle is now steady at 101W vs the usual 50W (which used
> to be 40 before a kernel update) while I am not sure if it is accurate
> as the cpu temp doesn't reach high levels expected for such wattage it
> does have one bad effect in that Turbo 2 no longer works...and even
> before this update with my v4.6 to get Turbo 1 on all cores as AMD
> advertises I must use "tpc -psmax 1"[1] which brings up the sensors
> reported TDP to 125W whereas normally it wouldn't work due to maxing out
> at 115W and 3.35ghz rather than T1 3.5ghz the TDP determining when the
> CPU enters full turbo 1.
> 
> I use Turbo 2 to obtain better performance on non-multithreaded games so
> this is disappointing but I will investigate further.
> 
> [1] turionpowercontrol, an overclocking software

This sounds like CC6 broke.  Can you check to see if CC6 is enabled in
your NVRAM settings?

-- 
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645 (direct line)
+1 (512) 690-0200 (switchboard)
https://www.raptorengineering.com

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [RFH] Native AMD fam10-15 support

[Timothy Pearson]

On 07/12/2018 10:41 PM, Kyösti Mälkki wrote:
> On Fri, Jul 13, 2018 at 5:41 AM, Timothy Pearson
> mailto:tpear...@raptorengineering.com>>
> wrote:
> 
> Good to know, thanks for testing!  I've been looking into relocateable
> ramstage in case suspend was still failing, but if things fell back into
> place, so to speak, in master we should also look at reactivating REACTS
> with the suspend tests enabled.
> 
> 
> I never suspected RELOCATABLE_RAMSTAGE=n would be a reason for
> (possible) S3 regressions. The motivation for having
> RELOCATABLE_RAMSTAGE=y goes beyond the improvement it has on not having
> to do low-mem backup S3 resume path. I am also wondering how S3 resume
> path is taking one minute and how that relates to normal boot path time.
> 
> Kyösti

My understanding is that without relocateable ramstage, there are
additional bounce buffers involved that not only slow things down, but
also introduce new code paths that could be responsible for regressions
in resume.  I think avph on IRC is looking into an initial port of the
CAR code for relocateable support, and if things are stable enough in
master to reactivate the REACTS tests on the KGPE-D16 that would help
him iterate more quickly.

-- 
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645 (direct line)
+1 (512) 690-0200 (switchboard)
https://www.raptorengineering.com

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [RFH] Native AMD fam10-15 support

[Kyösti Mälkki]

On Fri, Jul 13, 2018 at 5:41 AM, Timothy Pearson <
tpear...@raptorengineering.com> wrote:

> Good to know, thanks for testing!  I've been looking into relocateable
> ramstage in case suspend was still failing, but if things fell back into
> place, so to speak, in master we should also look at reactivating REACTS
> with the suspend tests enabled.
>
>
I never suspected RELOCATABLE_RAMSTAGE=n would be a reason for (possible)
S3 regressions. The motivation for having RELOCATABLE_RAMSTAGE=y goes
beyond the improvement it has on not having to do low-mem backup S3 resume
path. I am also wondering how S3 resume path is taking one minute and how
that relates to normal boot path time.

Kyösti
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [RFH] Native AMD fam10-15 support

[Kyösti Mälkki]

On Fri, Jul 13, 2018 at 5:40 AM, taii...@gmx.com  wrote:

> Hi guys!
>
> I have just tested my KGPE-D16's suspend a few times with the latest
> master and it works fine - takes around a minute to get back to my linux
> terminal.
>

Thanks

And logs please.

My previous mails had some pointers to commits which I believe had
regressions and fixes. I would like to know if those were accurate.

Kyösti
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [RFH] Native AMD fam10-15 support

[Timothy Pearson]

Good to know, thanks for testing!  I've been looking into relocateable
ramstage in case suspend was still failing, but if things fell back into
place, so to speak, in master we should also look at reactivating REACTS
with the suspend tests enabled.

On 07/12/2018 09:40 PM, taii...@gmx.com wrote:
> Hi guys!
> 
> I have just tested my KGPE-D16's suspend a few times with the latest
> master and it works fine - takes around a minute to get back to my linux
> terminal.


-- 
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645 (direct line)
+1 (512) 690-0200 (switchboard)
https://www.raptorengineering.com

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [RFH] Native AMD fam10-15 support

[taii...@gmx.com]

On 06/27/2018 05:17 PM, Timothy Pearson wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> On 06/20/2018 03:39 PM, taii...@gmx.com wrote:
>> On 06/15/2018 03:33 AM, Kyösti Mälkki wrote:
>>> On Fri, Jun 15, 2018 at 8:58 AM, taii...@gmx.com  wrote:
>>>
 On 06/14/2018 08:42 PM, Kyösti Mälkki wrote:
> On Thu, Jun 14, 2018 at 4:38 AM, qtux  wrote:
> Now, since commit babb2e6 that claims to add S3 support on kgpe-d16 is
> within the latter period, I do not quite see how S3 support could have
> worked with that commit on kgpe-d16.  Or maybe this feature was never
> retested once it was rebased and upstreamed. Nor can I see how it
> could have worked for any commit in 4.6

 I just tested S3 again and it worked fine on my v4.6 D16.

>>>
>>> Please state the commit hash of the source tree you built and booted from,
>>> we don't literally have such tag as "v4.6".
>>
>> I was using the coreboot-4.6.tar.xz from the coreboot download page
>> which is why I didn't include the hash.
>>
>> [0.00] DMI: ASUS KGPE-D16/KGPE-D16, BIOS
>> 4.6-db508565d2483394b709654c57533e55eebace51 07/10/2017
>>
>>>
>>> Repeat tests with current master.
>>
>> Thanks, I will have info for you by the end of the this weekend and I
>> will also investigate things myself if S3 doesn't work...
>>
> 
> 
> Just wanted to follow up on the bisect offer for thisI'm back in the
> D16 code for a different reason and if there's a general commit range
> where the issue started, I'm happy to investigate.

I got the flu so I had to put this off for a little while, I will start
next week.

Sorry! and thanks!

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [RFH] Native AMD fam10-15 support

[Timothy Pearson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 06/20/2018 03:39 PM, taii...@gmx.com wrote:
> On 06/15/2018 03:33 AM, Kyösti Mälkki wrote:
>> On Fri, Jun 15, 2018 at 8:58 AM, taii...@gmx.com  wrote:
>>
>>> On 06/14/2018 08:42 PM, Kyösti Mälkki wrote:
 On Thu, Jun 14, 2018 at 4:38 AM, qtux  wrote:
 Now, since commit babb2e6 that claims to add S3 support on kgpe-d16 is
 within the latter period, I do not quite see how S3 support could have
 worked with that commit on kgpe-d16.  Or maybe this feature was never
 retested once it was rebased and upstreamed. Nor can I see how it
 could have worked for any commit in 4.6
>>>
>>> I just tested S3 again and it worked fine on my v4.6 D16.
>>>
>>
>> Please state the commit hash of the source tree you built and booted from,
>> we don't literally have such tag as "v4.6".
> 
> I was using the coreboot-4.6.tar.xz from the coreboot download page
> which is why I didn't include the hash.
> 
> [0.00] DMI: ASUS KGPE-D16/KGPE-D16, BIOS
> 4.6-db508565d2483394b709654c57533e55eebace51 07/10/2017
> 
>>
>> Repeat tests with current master.
> 
> Thanks, I will have info for you by the end of the this weekend and I
> will also investigate things myself if S3 doesn't work...
> 


Just wanted to follow up on the bisect offer for thisI'm back in the
D16 code for a different reason and if there's a general commit range
where the issue started, I'm happy to investigate.

Thanks!

- -- 
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

iQEcBAEBCAAGBQJbM/7nAAoJEK+E3vEXDOFbTXAH/1A5n3tVNLw7vHfZl+RknmGS
H66JAxqLH5oxjJwoJNsnK13LSnNDID7aL6VHbtkJFhDHHgnl6mofWwHldVU2igDG
31reRutYFGrNFzZvQyw5lLFa7dEW1xyZqex7LPO03ZKJFfW7y3ziAgMJNCDSKclM
xA8Qf2+N/bkQN3YV0eiGbe/vbE0B9NijwTxm1ycHlLRqIrWqJsZ6bw5HYBugquO0
FLbadXROjfgxQ8B5LAzOcJgA7ErBY6ZVL6xvH+H0Q/iQzhgsZ/s+hm0hhMZNfRML
uRs44iGy2Y2NsPes9MtK31iVG/BIvI854L+5NShG+sfzUddLrXabqB0C5ZQb7h8=
=c+c9
-END PGP SIGNATURE-

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [RFH] Native AMD fam10-15 support

[Timothy Pearson]

On 06/20/2018 03:39 PM, taii...@gmx.com wrote:
> On 06/15/2018 03:33 AM, Kyösti Mälkki wrote:
>> On Fri, Jun 15, 2018 at 8:58 AM, taii...@gmx.com  wrote:
>>
>>> On 06/14/2018 08:42 PM, Kyösti Mälkki wrote:
 On Thu, Jun 14, 2018 at 4:38 AM, qtux  wrote:
 Now, since commit babb2e6 that claims to add S3 support on kgpe-d16 is
 within the latter period, I do not quite see how S3 support could have
 worked with that commit on kgpe-d16.  Or maybe this feature was never
 retested once it was rebased and upstreamed. Nor can I see how it
 could have worked for any commit in 4.6
>>>
>>> I just tested S3 again and it worked fine on my v4.6 D16.
>>>
>>
>> Please state the commit hash of the source tree you built and booted from,
>> we don't literally have such tag as "v4.6".
> 
> I was using the coreboot-4.6.tar.xz from the coreboot download page
> which is why I didn't include the hash.
> 
> [0.00] DMI: ASUS KGPE-D16/KGPE-D16, BIOS
> 4.6-db508565d2483394b709654c57533e55eebace51 07/10/2017
> 
>>
>> Repeat tests with current master.
> 
> Thanks, I will have info for you by the end of the this weekend and I
> will also investigate things myself if S3 doesn't work...
> 

If you can isolate the commit I have time blocked off this week to work
on bringing the D16 back up to date...

Thanks!

-- 
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645 (direct line)
+1 (512) 690-0200 (switchboard)
https://www.raptorengineering.com

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [RFH] Native AMD fam10-15 support

[taii...@gmx.com]

On 06/15/2018 03:33 AM, Kyösti Mälkki wrote:
> On Fri, Jun 15, 2018 at 8:58 AM, taii...@gmx.com  wrote:
> 
>> On 06/14/2018 08:42 PM, Kyösti Mälkki wrote:
>>> On Thu, Jun 14, 2018 at 4:38 AM, qtux  wrote:
>>> Now, since commit babb2e6 that claims to add S3 support on kgpe-d16 is
>>> within the latter period, I do not quite see how S3 support could have
>>> worked with that commit on kgpe-d16.  Or maybe this feature was never
>>> retested once it was rebased and upstreamed. Nor can I see how it
>>> could have worked for any commit in 4.6
>>
>> I just tested S3 again and it worked fine on my v4.6 D16.
>>
> 
> Please state the commit hash of the source tree you built and booted from,
> we don't literally have such tag as "v4.6".

I was using the coreboot-4.6.tar.xz from the coreboot download page
which is why I didn't include the hash.

[0.00] DMI: ASUS KGPE-D16/KGPE-D16, BIOS
4.6-db508565d2483394b709654c57533e55eebace51 07/10/2017

> 
> Repeat tests with current master.

Thanks, I will have info for you by the end of the this weekend and I
will also investigate things myself if S3 doesn't work...

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [RFH] Native AMD fam10-15 support

[Timothy Pearson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 06/15/2018 01:36 PM, qtux wrote:
> On 15/06/18 13:51, Kyösti Mälkki wrote:
>> On Fri, Jun 15, 2018 at 2:14 PM, qtux  wrote:
>>
>>>
> Coreboot did work well, but froze sometimes when booting during the
> assigning resources step (more or less exactly after assigning the PCI
> 14.3 or PNP 002e.2 device, which happen to be close to each other inside
> the devicetree). I had to remove the power cord in order to be able to
> boot again (or to get the next random freeze...). Rarely, after such an
> recovery, I have got flooded by IOMMU warnings in Linux which would only
> disappear after another reboot.

 Ah, that resume reboot-loop issue. The bit that tells to do S3 resume
 is a sticky register backed up by Vstb rail. With [2] you should not
 need to do full power-cycling at least. We should extend this work to
 other platforms.

>>>
>>> I am not sure whether the term resume reboot-loop applies for my issue
>>> (side note: I used a serial connection to monitor the boot process):
>>>
>>> Rebooting (via holding the power button for some seconds) after
>>> encountering a freeze (aka stopping at the assign resource step)
>>> resulted into having no output from serial at all. I could repeat this
>>> with no effect at all, the computer seemed to be dead. Only removing the
>>> power cord could solve the issue.
>>>
>>> This issue could occur when rebooting but even when cold booting.
>>>
>>
>> One of these boards had LPC related lockups. I think the solution was to
>> disable serial console or to set console to low loglevel.
>>
> 
> If that is the case I would suggest to alter the default board
> configuration to reflect this. Nevertheless, it seems strange to me that
> such a lockup disappeared after changing SPI chips.
> 
>>
>>
>>> Answers are inside the text.
>>> I forgot to mention that I am currently on commit 793ae846e8.
>>>
>>
>> Let's take the parent of that, commit 4a027e6e -- the one you refer to only
>> appears on gerrit review branch.
>>
>> Kyösti
>>
>>
>>
> 
> That is fine, sorry for the misleading commit hash.
> 
> Cheers,
> Matthias
> 

I've actually done a lot of investigation of this issue over time,
including work with a protocol analyzer.  What happens is that at some
point (not sure where or why) the SPI flash reads start occurring at
addresses that are completely invalid -- basically, the board starts
reading compressed ramstage data during early romstage execution.  This
could be down to an SPI misread somewhere, but more importantly it
appears that:

1.) The SPI controller in the southbridge receives at least some leakage
power from +5VSB, and retains state as a result while the PSU is plugged in.
2.) The board reset lines don't fully reset the SPI controller in the
southbridge
3.) There is an as-of-yet undetermined command sequence that will hard
lock the SPI controller.

Much of this had been mitigated by making sure the ROM bridge in the
southbridge never switched to LPC Flash mode, and I'm surprised to hear
these issues are still happening.

- -- 
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

iQEcBAEBCAAGBQJbJCi+AAoJEK+E3vEXDOFbVPYIAJWT6y/0LuTAK1V9rNz9uav/
6SKomv6W4GcsV4gRg9j/ROA2hK64ljsfFVZzcEwMVLi6mE6iYG5vnLHM/MGTUOJT
emQ2nqXNkzrovhgxFL1Xw6cpnhqIvCBqRz0ILMeRiXBniHXYW4AtNWsdh9rXIAOB
uhQSg3HMFqF9mXdBV3PUB0mn1FfEUcsHYcrYwu2A7JJtESYrWHV/IXaFfsC431J1
u6tcapbqNv2sfeDRcIkafxoE1IuVO17KT35UNQLauShsHr/R+519x17k3Bx2RoRN
9YsdjwCfmWtIaokAx3PGRbStlqXa790yONDVIU4+8SpDxzqeB6XgKCXfGyyIo7A=
=tO92
-END PGP SIGNATURE-

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [RFH] Native AMD fam10-15 support

[qtux]

On 15/06/18 13:51, Kyösti Mälkki wrote:
> On Fri, Jun 15, 2018 at 2:14 PM, qtux  wrote:
> 
>>
 Coreboot did work well, but froze sometimes when booting during the
 assigning resources step (more or less exactly after assigning the PCI
 14.3 or PNP 002e.2 device, which happen to be close to each other inside
 the devicetree). I had to remove the power cord in order to be able to
 boot again (or to get the next random freeze...). Rarely, after such an
 recovery, I have got flooded by IOMMU warnings in Linux which would only
 disappear after another reboot.
>>>
>>> Ah, that resume reboot-loop issue. The bit that tells to do S3 resume
>>> is a sticky register backed up by Vstb rail. With [2] you should not
>>> need to do full power-cycling at least. We should extend this work to
>>> other platforms.
>>>
>>
>> I am not sure whether the term resume reboot-loop applies for my issue
>> (side note: I used a serial connection to monitor the boot process):
>>
>> Rebooting (via holding the power button for some seconds) after
>> encountering a freeze (aka stopping at the assign resource step)
>> resulted into having no output from serial at all. I could repeat this
>> with no effect at all, the computer seemed to be dead. Only removing the
>> power cord could solve the issue.
>>
>> This issue could occur when rebooting but even when cold booting.
>>
> 
> One of these boards had LPC related lockups. I think the solution was to
> disable serial console or to set console to low loglevel.
> 

If that is the case I would suggest to alter the default board
configuration to reflect this. Nevertheless, it seems strange to me that
such a lockup disappeared after changing SPI chips.

> 
> 
>> Answers are inside the text.
>> I forgot to mention that I am currently on commit 793ae846e8.
>>
> 
> Let's take the parent of that, commit 4a027e6e -- the one you refer to only
> appears on gerrit review branch.
> 
> Kyösti
> 
> 
> 

That is fine, sorry for the misleading commit hash.

Cheers,
Matthias

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [RFH] Native AMD fam10-15 support

[Kyösti Mälkki]

On Fri, Jun 15, 2018 at 2:14 PM, qtux  wrote:

>
> >> Coreboot did work well, but froze sometimes when booting during the
> >> assigning resources step (more or less exactly after assigning the PCI
> >> 14.3 or PNP 002e.2 device, which happen to be close to each other inside
> >> the devicetree). I had to remove the power cord in order to be able to
> >> boot again (or to get the next random freeze...). Rarely, after such an
> >> recovery, I have got flooded by IOMMU warnings in Linux which would only
> >> disappear after another reboot.
> >
> > Ah, that resume reboot-loop issue. The bit that tells to do S3 resume
> > is a sticky register backed up by Vstb rail. With [2] you should not
> > need to do full power-cycling at least. We should extend this work to
> > other platforms.
> >
>
> I am not sure whether the term resume reboot-loop applies for my issue
> (side note: I used a serial connection to monitor the boot process):
>
> Rebooting (via holding the power button for some seconds) after
> encountering a freeze (aka stopping at the assign resource step)
> resulted into having no output from serial at all. I could repeat this
> with no effect at all, the computer seemed to be dead. Only removing the
> power cord could solve the issue.
>
> This issue could occur when rebooting but even when cold booting.
>

One of these boards had LPC related lockups. I think the solution was to
disable serial console or to set console to low loglevel.



> Answers are inside the text.
> I forgot to mention that I am currently on commit 793ae846e8.
>

Let's take the parent of that, commit 4a027e6e -- the one you refer to only
appears on gerrit review branch.

Kyösti
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [RFH] Native AMD fam10-15 support

[qtux]

On 15/06/18 02:42, Kyösti Mälkki wrote:
> On Thu, Jun 14, 2018 at 4:38 AM, qtux  wrote:
>> On 13/06/18 22:12, Kyösti Mälkki wrote:
>> Hi,
>>
>> S3 is __not__ working on my KCMA-D8. The last time I tried, I had to
>> remove the power cord for a couple of seconds to be able to boot again.
>>
>> Interestingly, this issue looks similar to another one I had with a
>> flash chip which seems not to be supported by coreboot. Here the
>> relevant part of the logs regarding the bad chip:
>> Manufacturer: ef
>> SF: Unsupported Winbond ID 4014
>> SF: Unsupported manufacturer!
>>
> 
> Thanks, [1] should take care of this.
> 

Thank you! I will test the Winbond chip when I find some time to do so.

>> Coreboot did work well, but froze sometimes when booting during the
>> assigning resources step (more or less exactly after assigning the PCI
>> 14.3 or PNP 002e.2 device, which happen to be close to each other inside
>> the devicetree). I had to remove the power cord in order to be able to
>> boot again (or to get the next random freeze...). Rarely, after such an
>> recovery, I have got flooded by IOMMU warnings in Linux which would only
>> disappear after another reboot.
> 
> Ah, that resume reboot-loop issue. The bit that tells to do S3 resume
> is a sticky register backed up by Vstb rail. With [2] you should not
> need to do full power-cycling at least. We should extend this work to
> other platforms.
> 

I am not sure whether the term resume reboot-loop applies for my issue
(side note: I used a serial connection to monitor the boot process):

Rebooting (via holding the power button for some seconds) after
encountering a freeze (aka stopping at the assign resource step)
resulted into having no output from serial at all. I could repeat this
with no effect at all, the computer seemed to be dead. Only removing the
power cord could solve the issue.

This issue could occur when rebooting but even when cold booting.

>> Replacing the chip seems to have solved this random boot freeze problem.
>> But maybe the S3 issue and the issue I had with the wrong chip are
>> related as they both lock down the machine until I remove the power cord.
> 
> Yes, it's connected. Having a non-supported SPI part ID there would
> prevent ACPI S3 resume, and likely enter the loop.>

Just to be sure: The S3 resume does not work with the __supported__ SPI
chip. I did not test S3 with the unsupported one.

> If someone takes the task of testing and/or bisecting please note:
> 
> Regression present between: 714709f .. a26377b
> 
> Regression present between: 9e94dbf .. c2a921b (for kcma-d8) 8a8386e
> (for kgpe-d16)
> 
> Now, since commit babb2e6 that claims to add S3 support on kgpe-d16 is
> within the latter period, I do not quite see how S3 support could have
> worked with that commit on kgpe-d16.  Or maybe this feature was never
> retested once it was rebased and upstreamed. Nor can I see how it
> could have worked for any commit in 4.6, so I must be missing
> something here. So I will need some logs.
> 
> 
> [1] https://review.coreboot.org/#/c/coreboot/+/27107
> [2] https://review.coreboot.org/#/c/coreboot/+/27108
> 
> Kyösti
> 

Answers are inside the text.
I forgot to mention that I am currently on commit 793ae846e8.

Cheers,
Matthias

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [RFH] Native AMD fam10-15 support

[Kyösti Mälkki]

On Fri, Jun 15, 2018 at 8:58 AM, taii...@gmx.com  wrote:

> On 06/14/2018 08:42 PM, Kyösti Mälkki wrote:
> > On Thu, Jun 14, 2018 at 4:38 AM, qtux  wrote:
> > Now, since commit babb2e6 that claims to add S3 support on kgpe-d16 is
> > within the latter period, I do not quite see how S3 support could have
> > worked with that commit on kgpe-d16.  Or maybe this feature was never
> > retested once it was rebased and upstreamed. Nor can I see how it
> > could have worked for any commit in 4.6
>
> I just tested S3 again and it worked fine on my v4.6 D16.
>

Please state the commit hash of the source tree you built and booted from,
we don't literally have such tag as "v4.6".

Repeat tests with current master.

Thanks
Kyösti
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [RFH] Native AMD fam10-15 support

[taii...@gmx.com]

On 06/14/2018 08:42 PM, Kyösti Mälkki wrote:
> On Thu, Jun 14, 2018 at 4:38 AM, qtux  wrote:
> Now, since commit babb2e6 that claims to add S3 support on kgpe-d16 is
> within the latter period, I do not quite see how S3 support could have
> worked with that commit on kgpe-d16.  Or maybe this feature was never
> retested once it was rebased and upstreamed. Nor can I see how it
> could have worked for any commit in 4.6

I just tested S3 again and it worked fine on my v4.6 D16.

My Win10 guest with IOMMU-GFX also resumes properly as long as it is
suspended first before the host which places the assigned devices in S3.

It takes a LONG time (around a minute) to resume so it isn't quick but
it does work.

> so I must be missing something here. So I will need some logs.

Ah tell me what you want and I will provide it ASAP :D

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [RFH] Native AMD fam10-15 support

[taii...@gmx.com]

On 06/14/2018 02:45 AM, Kyösti Mälkki wrote:
> On Thu, Jun 14, 2018 at 7:23 AM, taii...@gmx.com  wrote:
>> On 06/13/2018 04:12 PM, Kyösti Mälkki wrote:
>>> Hi
>>>
>>> Now that we wiped out K8, I'd like to put my eyes on fam10-15 boards.
>> What exactly do you mean by wiped out?
>>
>>>
>>> Couple questions for board owners:
>>>
>>> First, about asus/kcma-d8 and asus/kgpe-d16: Do these have working S3
>>> support? I remember rumours they originally worked at some point, but
>>> regressed during the rebase / upstream process. Anyone willing to
>>> bisect/fix it if necessary?
>>>
>>
>> I have a D16 with v4.6 that I regularly use suspend with and it works
>> absolutely fine - I can also suspend a host featuring a guest with IOMMU
>> graphics and then resume that host later on and continue playing video
>> games on the guest.
> 
> So you are committed to bisect this and make it work on current
> master, thank you.

Yes I am, like I said this worked quite recently so I doubt it will be
that difficult to fix although I will have to have someone else publish
whatever I find. I own both of these and value them quite a bit so I
will be putting efforts in to this - In reference to my previous offer
to support the H8SCM I abandoned that effort as it went from $30 used to
over $200 and I didn't see the point after that (as one should just get
a KCMA-D8 or KGPE-D16 at that point)

The D8 and D16 are the last and best owner controlled x86 boards the
only coreboot boards left with 100% open source hardware initiation.

Like I have said before at this rate there will be no boards in master
besides *brand new* purism laptops and un-obtainable development boards
where half the features don't work anyway - I fail to see how that makes
for a healthy project if no one (again remember I have said you do quite
a bit already) is willing to support the two boards that I would argue
are the best examples of coreboot and modern computing freedom efforts.

>>
>> I again state my for-some-reason controversial opinion that at this rate
>> there will soon be no non-development boards in coreboot due to the
>> choices of the current leadership in determining standards.
> 
> I hear you and weigh your opinion according to the number of commits I
> can recognize you have authored on the repo.

I didn't mean it like that man - you have done quite a bit for computing
freedom and I have recognized that on various occasions.

As I am unwilling to provide my "real" name I am not allowed to
contribute code so I help in other ways - I have spent countless hours
assisting many many people with recommending boards to purchase and then
getting coreboot running on them.

Contributing code isn't the only measure of worth, every project needs
people to provide tech support and documentation and I do just that.

I do feel as though lately there has been a turn for elitism where
anyone who doesn't contribute code is discounted and made to feel
unwelcome as if our opinion doesn't really matter and I do not like
this...but again I say you are one of my favorites.

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [RFH] Native AMD fam10-15 support

[Timothy Pearson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I should probably step up here and just get this fixedlet me see
what I can do with it next week.

On 06/14/2018 08:28 PM, Kyösti Mälkki wrote:
> On Thu, Jun 14, 2018 at 8:28 PM, Merlin Büge  > wrote:
>>
>>
>> On Thu, 14 Jun 2018 09:45:49 +0300
>> Kyösti Mälkki  > wrote:
>>
>>>
>>> I hear you and weigh your opinion according to the number of commits I
>>> can recognize you have authored on the repo.
>>
>> I just want to mention:
>> Generally, helping out with documentation and (especially) code review
>> and even ordinary users who report bugs are also a value-add to the
>> coreboot project.
>>
> 
> Agreed and Talidan should not get offended by previous comment. I get
> way more rude and personal in some of my reviews towards commercial
> vendors. Apologies for that.
> 
> Just recently, cases of RELOCATABLE_RAMSTAGE=n started to fail to boot
> certain payload builds. The accumulated developers time it took to
> bisect, discuss and come up with a sub-standard solution for that;
> should I say 8 hours across 5 active developers. That time is better
> spent elsewhere, I consider the discussion of why we deprecate older
> boards from master just not productive at all.
> 
> Notice that even the little details Matthias provided earlier already
> moves us forwards.
> 
> The criteria I listed was my personal wishlist as flipping to
> RELOCATABLE_RAMSTAGE=y has proven to be quite easy and the remaining
> platforms are:
> 
>   northbridge/amd/amdfam10
>   northbridge/amd/lx  <- waiting for EARLY_CBMEM_INIT
>   northbridge/intel/i440bx<- already tested
>   northbridge/via/vx900   <- I know competent person to do this
>   soc/intel/fsp_baytrail  <- I have hardware and know person to
> double-check
>   soc/intel/fsp_broadwell_de  <- I know competent person to do this
> 
> 
> Kyösti
> 


- -- 
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

iQEcBAEBCAAGBQJbI050AAoJEK+E3vEXDOFbV9UH+wdDms4AhQq4GBrLbBmuFh+v
VxTMir4PTXlUh1Li/JhYWSV6ZMzOwrRo4JOQJp4BpnkvfAxZZ6vvnm1Bu2xR2sba
BRF01zk1ZJxoMaE1lUANkKlVOBTfog7nNElBHXRCZJ832Qsc3SpMGuWlap9mBd9L
J7e4yNAvBvW9/cRzh7jHUOzrWxB1ESuyOCEN03OPpxfG37nOHmtGQNKwwifm419d
YxoDwBnQ2vuJpj3ynQC1maX/t4RIqJacTfxfHIcQz7+S2U7Dem+n3lrq2gTl3OY/
e7NEmBevdAgaNiUIMC7pprWTsrthMw0oirmTXX8jVWFLAVIbZ0blSZVzjmfzkYU=
=amyM
-END PGP SIGNATURE-

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [RFH] Native AMD fam10-15 support

[Kyösti Mälkki]

On Thu, Jun 14, 2018 at 8:28 PM, Merlin Büge  wrote:
>
>
> On Thu, 14 Jun 2018 09:45:49 +0300
> Kyösti Mälkki  wrote:
>
>>
>> I hear you and weigh your opinion according to the number of commits I
>> can recognize you have authored on the repo.
>
> I just want to mention:
> Generally, helping out with documentation and (especially) code review
> and even ordinary users who report bugs are also a value-add to the
> coreboot project.
>

Agreed and Talidan should not get offended by previous comment. I get way
more rude and personal in some of my reviews towards commercial vendors.
Apologies for that.

Just recently, cases of RELOCATABLE_RAMSTAGE=n started to fail to boot
certain payload builds. The accumulated developers time it took to bisect,
discuss and come up with a sub-standard solution for that; should I say 8
hours across 5 active developers. That time is better spent elsewhere, I
consider the discussion of why we deprecate older boards from master just
not productive at all.

Notice that even the little details Matthias provided earlier already moves
us forwards.

The criteria I listed was my personal wishlist as flipping to
RELOCATABLE_RAMSTAGE=y has proven to be quite easy and the remaining
platforms are:

  northbridge/amd/amdfam10
  northbridge/amd/lx  <- waiting for EARLY_CBMEM_INIT
  northbridge/intel/i440bx<- already tested
  northbridge/via/vx900   <- I know competent person to do this
  soc/intel/fsp_baytrail  <- I have hardware and know person to
double-check
  soc/intel/fsp_broadwell_de  <- I know competent person to do this


Kyösti
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [RFH] Native AMD fam10-15 support

[Kyösti Mälkki]

On Thu, Jun 14, 2018 at 4:38 AM, qtux  wrote:
> On 13/06/18 22:12, Kyösti Mälkki wrote:
> Hi,
>
> S3 is __not__ working on my KCMA-D8. The last time I tried, I had to
> remove the power cord for a couple of seconds to be able to boot again.
>
> Interestingly, this issue looks similar to another one I had with a
> flash chip which seems not to be supported by coreboot. Here the
> relevant part of the logs regarding the bad chip:
> Manufacturer: ef
> SF: Unsupported Winbond ID 4014
> SF: Unsupported manufacturer!
>

Thanks, [1] should take care of this.

> Coreboot did work well, but froze sometimes when booting during the
> assigning resources step (more or less exactly after assigning the PCI
> 14.3 or PNP 002e.2 device, which happen to be close to each other inside
> the devicetree). I had to remove the power cord in order to be able to
> boot again (or to get the next random freeze...). Rarely, after such an
> recovery, I have got flooded by IOMMU warnings in Linux which would only
> disappear after another reboot.

Ah, that resume reboot-loop issue. The bit that tells to do S3 resume
is a sticky register backed up by Vstb rail. With [2] you should not
need to do full power-cycling at least. We should extend this work to
other platforms.

> Replacing the chip seems to have solved this random boot freeze problem.
> But maybe the S3 issue and the issue I had with the wrong chip are
> related as they both lock down the machine until I remove the power cord.

Yes, it's connected. Having a non-supported SPI part ID there would
prevent ACPI S3 resume, and likely enter the loop.

If someone takes the task of testing and/or bisecting please note:

Regression present between: 714709f .. a26377b

Regression present between: 9e94dbf .. c2a921b (for kcma-d8) 8a8386e
(for kgpe-d16)

Now, since commit babb2e6 that claims to add S3 support on kgpe-d16 is
within the latter period, I do not quite see how S3 support could have
worked with that commit on kgpe-d16.  Or maybe this feature was never
retested once it was rebased and upstreamed. Nor can I see how it
could have worked for any commit in 4.6, so I must be missing
something here. So I will need some logs.


[1] https://review.coreboot.org/#/c/coreboot/+/27107
[2] https://review.coreboot.org/#/c/coreboot/+/27108

Kyösti

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [RFH] Native AMD fam10-15 support

[Patrick Georgi via coreboot]

Merlin Büge  schrieb am Do., 14. Juni 2018, 19:30:

> I just want to mention:
> Generally, helping out with documentation and (especially) code review
> and even ordinary users who report bugs are also a value-add to the
> coreboot project.
>
Indeed. Not necessarily when it comes deciding about the maintenance of
code that they never touched, ran, documented or tested though.


Regards,
Patrick
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [RFH] Native AMD fam10-15 support

[Merlin Büge]

On Thu, 14 Jun 2018 09:45:49 +0300
Kyösti Mälkki  wrote:

> On Thu, Jun 14, 2018 at 7:23 AM, taii...@gmx.com 
> wrote:
> > On 06/13/2018 04:12 PM, Kyösti Mälkki wrote:
> >> Hi
> >>
> >> Now that we wiped out K8, I'd like to put my eyes on fam10-15
> >> boards.
> > What exactly do you mean by wiped out?
> >
> >>
> >> Couple questions for board owners:
> >>
> >> First, about asus/kcma-d8 and asus/kgpe-d16: Do these have working
> >> S3 support? I remember rumours they originally worked at some
> >> point, but regressed during the rebase / upstream process. Anyone
> >> willing to bisect/fix it if necessary?
> >>
> >
> > I have a D16 with v4.6 that I regularly use suspend with and it
> > works absolutely fine - I can also suspend a host featuring a guest
> > with IOMMU graphics and then resume that host later on and continue
> > playing video games on the guest.
> 
> So you are committed to bisect this and make it work on current
> master, thank you.
> 
> >
> > I again state my for-some-reason controversial opinion that at this
> > rate there will soon be no non-development boards in coreboot due
> > to the choices of the current leadership in determining standards.
> 
> I hear you and weigh your opinion according to the number of commits I
> can recognize you have authored on the repo.

I just want to mention:
Generally, helping out with documentation and (especially) code review
and even ordinary users who report bugs are also a value-add to the
coreboot project.

> 
> Kyösti
> 



-- 
Merlin Büge

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [RFH] Native AMD fam10-15 support

[Kyösti Mälkki]

On Thu, Jun 14, 2018 at 7:23 AM, taii...@gmx.com  wrote:
> On 06/13/2018 04:12 PM, Kyösti Mälkki wrote:
>> Hi
>>
>> Now that we wiped out K8, I'd like to put my eyes on fam10-15 boards.
> What exactly do you mean by wiped out?
>
>>
>> Couple questions for board owners:
>>
>> First, about asus/kcma-d8 and asus/kgpe-d16: Do these have working S3
>> support? I remember rumours they originally worked at some point, but
>> regressed during the rebase / upstream process. Anyone willing to
>> bisect/fix it if necessary?
>>
>
> I have a D16 with v4.6 that I regularly use suspend with and it works
> absolutely fine - I can also suspend a host featuring a guest with IOMMU
> graphics and then resume that host later on and continue playing video
> games on the guest.

So you are committed to bisect this and make it work on current
master, thank you.

>
> I again state my for-some-reason controversial opinion that at this rate
> there will soon be no non-development boards in coreboot due to the
> choices of the current leadership in determining standards.

I hear you and weigh your opinion according to the number of commits I
can recognize you have authored on the repo.

Kyösti

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [RFH] Native AMD fam10-15 support

[taii...@gmx.com]

On 06/13/2018 04:12 PM, Kyösti Mälkki wrote:
> Hi
> 
> Now that we wiped out K8, I'd like to put my eyes on fam10-15 boards.
What exactly do you mean by wiped out?

> 
> Couple questions for board owners:
> 
> First, about asus/kcma-d8 and asus/kgpe-d16: Do these have working S3
> support? I remember rumours they originally worked at some point, but
> regressed during the rebase / upstream process. Anyone willing to
> bisect/fix it if necessary?
> 

I have a D16 with v4.6 that I regularly use suspend with and it works
absolutely fine - I can also suspend a host featuring a guest with IOMMU
graphics and then resume that host later on and continue playing video
games on the guest.

> I am asking, because these are the last two remaining boards with
> combination of HAVE_ACPI_RESUME=y and RELOCATABLE_RAMSTAGE=n, and we
> have to drag along some back-and-forth memory copy code to keep OS
> memory intact for these two.
> 
> Second, I would like to move forwards with AMD fam10 to have
> RELOCATABE_RAMSTAGE=y, that would also solve above-mentioned issue and
> open up doors for some new features.
> 
> If it was my decision, RELOCATABLE_RAMSTAGE for x86 would be one
> criteria to survive the next (October 2018?) release. POSTCAR_STAGE
> for May 2019. I am probably too late to make such wishes, but I hope
> these will happen in the next two years nevertheless.

I again state my for-some-reason controversial opinion that at this rate
there will soon be no non-development boards in coreboot due to the
choices of the current leadership in determining standards.

Removing something from master is in fact removal from coreboot - one of
the reasons is as over time the older versions of software required to
compile older versions of coreboot will become un-obtainable already to
compile master critical old GPL code is only obtainable from one obscure
non-US site.

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [RFH] Native AMD fam10-15 support

[qtux]

On 13/06/18 22:12, Kyösti Mälkki wrote:
> Hi
> 
> Now that we wiped out K8, I'd like to put my eyes on fam10-15 boards.
> 
> Couple questions for board owners:
> 
> First, about asus/kcma-d8 and asus/kgpe-d16: Do these have working S3
> support? I remember rumours they originally worked at some point, but
> regressed during the rebase / upstream process. Anyone willing to
> bisect/fix it if necessary?
> 
> I am asking, because these are the last two remaining boards with
> combination of HAVE_ACPI_RESUME=y and RELOCATABLE_RAMSTAGE=n, and we
> have to drag along some back-and-forth memory copy code to keep OS
> memory intact for these two.
> 
> Second, I would like to move forwards with AMD fam10 to have
> RELOCATABE_RAMSTAGE=y, that would also solve above-mentioned issue and
> open up doors for some new features.
> 
> If it was my decision, RELOCATABLE_RAMSTAGE for x86 would be one
> criteria to survive the next (October 2018?) release. POSTCAR_STAGE
> for May 2019. I am probably too late to make such wishes, but I hope
> these will happen in the next two years nevertheless.
> 
> Kyösti
> 

Hi,

S3 is __not__ working on my KCMA-D8. The last time I tried, I had to
remove the power cord for a couple of seconds to be able to boot again.

Interestingly, this issue looks similar to another one I had with a
flash chip which seems not to be supported by coreboot. Here the
relevant part of the logs regarding the bad chip:
Manufacturer: ef
SF: Unsupported Winbond ID 4014
SF: Unsupported manufacturer!

Coreboot did work well, but froze sometimes when booting during the
assigning resources step (more or less exactly after assigning the PCI
14.3 or PNP 002e.2 device, which happen to be close to each other inside
the devicetree). I had to remove the power cord in order to be able to
boot again (or to get the next random freeze...). Rarely, after such an
recovery, I have got flooded by IOMMU warnings in Linux which would only
disappear after another reboot.

Replacing the chip seems to have solved this random boot freeze problem.
But maybe the S3 issue and the issue I had with the wrong chip are
related as they both lock down the machine until I remove the power cord.

Cheers,
Matthias

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot