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
On Thu, Jun 14, 2018 at 4:38 AM, qtux mail@qtux.eu 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
-
Kyösti Mälkki -
qtux