[coreboot] Re: Final calls for S3 suspend support on amdfam10-15
On Thu, Aug 22, 2019 at 4:59 AM Matt B wrote: >> >> I believe S3 resume path is PSP assisted. When x86 core reset is deasserted >> some parts of the memory controller PHY have already been programmed by PSP >> or SMU firmwares. > > (No PSP present on the G505s) Perhaps my commentary was not so clear, this was meant in the context of amd/stoneyridged. > >> >> You should consider binaryPI mostly broken for the purpose of S3 >> suspend/resume. >> >> AMD never got S3 right for open-source AGESA and I think they struggled long >> to get it right for amd/stoneyridge. > > Does this and the above regarding the PSP mean that S3 is impossible on the > G505s (open-source AGESA), or would otherwise require changes to the AGESA > source? (even if C_ENVIRONMENT_BOOTBLOCK were implemented? If I understand > correctly the other two requirements are already fulfilled?) Absolutely not! G505s does have working S3 support. We (coreboot community) got it right while AMD did not. ACPI S3 support is not in the release requirements. For G505s and other open-source AGESA, C_ENVIRONMENT_BOOTBLOCK is what is currently lacking. For binaryPI, like mentioned, POSTCAR_STAGE=y support code is mostly there but the platform code is landing slowly. >> I have been told that later AGESAv5 firmwares do not have the capability of >> "MRC cache" to speed up cold boot as they lack the (x86) code to replay >> memory training parameters from non-volatile memory. > > Does this apply to the G505s? I presume that it's version of AGESA predates > that used to create the PI binaries. Different reason why it does apply to G505s; our copy of family15tn AGESA source was so old the feature was not yet implemented, at least correctly. For family16kb this feature does work [1]. asrock/imb-a180: 0:1st timestamp 1,923 1:start of romstage 1,972 (48) 2:before ram initialization 67,680 (65,707) 3:after ram initialization 2,572,863 (2,505,183) 4:end of romstage 2,584,322 (11,458) versus 0:1st timestamp 1,924 1:start of romstage 1,973 (48) 2:before ram initialization 67,988 (66,014) 3:after ram initialization 397,508 (329,520) 4:end of romstage 408,894 (11,386) [1] https://review.coreboot.org/c/coreboot/+/20597 Regards, Kyösti Mälkki ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Final calls for S3 suspend support on amdfam10-15
> > I believe S3 resume path is PSP assisted. When x86 core reset is > deasserted some parts of the memory controller PHY have already been > programmed by PSP or SMU firmwares. (No PSP present on the G505s) > You should consider binaryPI mostly broken for the purpose of S3 > suspend/resume. > AMD never got S3 right for open-source AGESA and I think they struggled > long to get it right for amd/stoneyridge. Does this and the above regarding the PSP mean that S3 is impossible on the G505s (open-source AGESA), or would otherwise require changes to the AGESA source? (even if C_ENVIRONMENT_BOOTBLOCK were implemented? If I understand correctly the other two requirements are already fulfilled?) I have been told that later AGESAv5 firmwares do not have the capability of > "MRC cache" to speed up cold boot as they lack the (x86) code to replay > memory training parameters from non-volatile memory. Does this apply to the G505s? I presume that it's version of AGESA predates that used to create the PI binaries. Sincerely, -Matthew Bradley On Wed, Aug 21, 2019 at 1:28 PM Kyösti Mälkki wrote: > On Wed, Aug 21, 2019 at 7:52 PM Raul Rangel wrote: > > > > You can grep for commits containing b:65442212 or b:111610455 to see the > work required to remove AGESA from bootblock. > > Thanks! > > Some of that seems very SoC or hardware specific. I think we will go > ahead with a bootblock that does nothing else but sets up CAR and > finds a romstage.elf to jump into. At this time verstage is not a > requirement so we'll just ignore any LPC or SPI PAD configurations TPM > might need. > > In general, changes from amd/stoneyridge do not apply to previous > binaryPI builds. A different set of modifications to StoneyPI were > made in comparison to the changes that SAGE had previously made to > MullinsPI, KaveriPI and CarrizoPI. Also AMD rolled out a custom PSP > firmware build for Chromebooks? So it is possible the implementation > of AGESAv5 API we have for amd/stoneyridge is only compatible with the > modified StoneyPI source tree and the modified PSP firmware. And the > PSP mailbox APIs are not exactly the same across different SoCs > either. > > Regards, > Kyösti Mälkki > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Final calls for S3 suspend support on amdfam10-15
On Wed, Aug 21, 2019 at 7:52 PM Raul Rangel wrote: > > You can grep for commits containing b:65442212 or b:111610455 to see the work > required to remove AGESA from bootblock. Thanks! Some of that seems very SoC or hardware specific. I think we will go ahead with a bootblock that does nothing else but sets up CAR and finds a romstage.elf to jump into. At this time verstage is not a requirement so we'll just ignore any LPC or SPI PAD configurations TPM might need. In general, changes from amd/stoneyridge do not apply to previous binaryPI builds. A different set of modifications to StoneyPI were made in comparison to the changes that SAGE had previously made to MullinsPI, KaveriPI and CarrizoPI. Also AMD rolled out a custom PSP firmware build for Chromebooks? So it is possible the implementation of AGESAv5 API we have for amd/stoneyridge is only compatible with the modified StoneyPI source tree and the modified PSP firmware. And the PSP mailbox APIs are not exactly the same across different SoCs either. Regards, Kyösti Mälkki ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Final calls for S3 suspend support on amdfam10-15
You can grep for commits containing b:65442212 or b:111610455 to see the work required to remove AGESA from bootblock. On Wed, Aug 21, 2019 at 10:22 AM Kyösti Mälkki wrote: > On Wed, Aug 21, 2019 at 6:53 PM Michal Zygowski > wrote: > >> I get the overall idea of C bootblock. The most fun is about the > > assembly to setup CAR early. But what about S3 suspend/resume for APU2 > > for example? It is not supported by the platform and does not seem to be > > needed at all there (it is just a router which should be always on). > > Maybe the check for RELOCATABLE_RAMSTAGE should be omitted when > > HAVE_ACPI_RESUME is not set for the platform? However the thing is all > > about southbridge/northbridge code still. > > You should consider binaryPI mostly broken for the purpose of S3 > suspend/resume. I did not understand what you mean about a > RELOCATABLE_RAMSTAGE check. > > AMD never got S3 right for open-source AGESA and I think they > struggled long to get it right for amd/stoneyridge. I believe S3 > resume path is PSP assisted. When x86 core reset is deasserted some > parts of the memory controller PHY have already been programmed by PSP > or SMU firmwares. I have been told that later AGESAv5 firmwares do not > have the capability of "MRC cache" to speed up cold boot as they lack > the (x86) code to replay memory training parameters from non-volatile > memory. > > >> That stoneyridge thing is interesting... Cannot imagine what it could be > > called for such early. > > A lot of that review is public in gerrit, maybe January-March 2017. > > Regards, > Kyösti Mälkki > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Final calls for S3 suspend support on amdfam10-15
On Wed, Aug 21, 2019 at 6:53 PM Michal Zygowski wrote: >> I get the overall idea of C bootblock. The most fun is about the > assembly to setup CAR early. But what about S3 suspend/resume for APU2 > for example? It is not supported by the platform and does not seem to be > needed at all there (it is just a router which should be always on). > Maybe the check for RELOCATABLE_RAMSTAGE should be omitted when > HAVE_ACPI_RESUME is not set for the platform? However the thing is all > about southbridge/northbridge code still. You should consider binaryPI mostly broken for the purpose of S3 suspend/resume. I did not understand what you mean about a RELOCATABLE_RAMSTAGE check. AMD never got S3 right for open-source AGESA and I think they struggled long to get it right for amd/stoneyridge. I believe S3 resume path is PSP assisted. When x86 core reset is deasserted some parts of the memory controller PHY have already been programmed by PSP or SMU firmwares. I have been told that later AGESAv5 firmwares do not have the capability of "MRC cache" to speed up cold boot as they lack the (x86) code to replay memory training parameters from non-volatile memory. >> That stoneyridge thing is interesting... Cannot imagine what it could be > called for such early. A lot of that review is public in gerrit, maybe January-March 2017. Regards, Kyösti Mälkki ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Final calls for S3 suspend support on amdfam10-15
On 8/21/19 8:59 AM, Kyösti Mälkki wrote: > On Wed, Aug 21, 2019 at 9:23 AM Michal Zygowski > wrote: >> Hello Kyösti, >> >> Giving such a "credit" to give a little more time to bring the platform >> to release requirements sounds like a good idea. >> >> 3mdeb will surely approach to implement those changes based on family >> 14h apu1, as well as for binary PI familty 16h based on apu2 (postcar >> support already slowly landing to the binaryPI). Although these are >> AGESA and binaryPI types, will the same approach be applicable here? >> > Nice, let's coordinate the efforts on PC Engines products. > > The principles are the same, move CAR init from the start of romstage > to start of bootblock. There are some things to consider about CAR > memory layout and stack, but nothing major there. An aspect for > possible future deployment of verstage is that calling vendorcode or > binaryPI blob from bootblock is discouraged. We should not need the > binaryPI blob to setup LPC routes or any SoC PAD configurations so > enabling console in bootblock should not be an issue for us. I can't > remember why the initial work on amd/stoneyridge called (unverified > but read-only) vendorcode blob already from within the bootblock. > Maybe it was something about GPIOs. I get the overall idea of C bootblock. The most fun is about the assembly to setup CAR early. But what about S3 suspend/resume for APU2 for example? It is not supported by the platform and does not seem to be needed at all there (it is just a router which should be always on). Maybe the check for RELOCATABLE_RAMSTAGE should be omitted when HAVE_ACPI_RESUME is not set for the platform? However the thing is all about southbridge/northbridge code still. That stoneyridge thing is interesting... Cannot imagine what it could be called for such early. Regards, Michał Żygowski > > Regards, > Kyösti Mälkki > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org -- Michał Żygowski Firmware Engineer http://3mdeb.com | @3mdeb_com ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Final calls for S3 suspend support on amdfam10-15
On Wed, Aug 21, 2019 at 9:23 AM Michal Zygowski wrote: > > Hello Kyösti, > > Giving such a "credit" to give a little more time to bring the platform > to release requirements sounds like a good idea. > > 3mdeb will surely approach to implement those changes based on family > 14h apu1, as well as for binary PI familty 16h based on apu2 (postcar > support already slowly landing to the binaryPI). Although these are > AGESA and binaryPI types, will the same approach be applicable here? > Nice, let's coordinate the efforts on PC Engines products. The principles are the same, move CAR init from the start of romstage to start of bootblock. There are some things to consider about CAR memory layout and stack, but nothing major there. An aspect for possible future deployment of verstage is that calling vendorcode or binaryPI blob from bootblock is discouraged. We should not need the binaryPI blob to setup LPC routes or any SoC PAD configurations so enabling console in bootblock should not be an issue for us. I can't remember why the initial work on amd/stoneyridge called (unverified but read-only) vendorcode blob already from within the bootblock. Maybe it was something about GPIOs. Regards, Kyösti Mälkki ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Final calls for S3 suspend support on amdfam10-15
Hello Kyösti, Giving such a "credit" to give a little more time to bring the platform to release requirements sounds like a good idea. 3mdeb will surely approach to implement those changes based on family 14h apu1, as well as for binary PI familty 16h based on apu2 (postcar support already slowly landing to the binaryPI). Although these are AGESA and binaryPI types, will the same approach be applicable here? Best regards, Michał Żygowski On 8/21/19 5:50 AM, Kyösti Mälkki wrote: > On Wed, Aug 21, 2019 at 5:43 AM Matt B wrote: >> Is a lack of C bootblock support common to all family 15h platforms? >> (Including the G505s and any others?) >> In other words, would it only need to be implemented once for all of these >> systems? >> > It's not really a CPU family thing at all, but about the > implementation otherwise. It's one fix for all AGESA, one for all > binaryPI, and a third one for native amdfam10-15. > > My suggestion on moving forwards with amdfam10-15 is as follows: > > The next release is scheduled for Oct 2019 (?). Regardless of when > that happens, I would introduce a flag on the October 1st that > disables all amdfam10-15 boards from the automatic build. Then, if we > have anyone capable and willing to have this amdfam10-15 stay on > master branch, she/he would get to select one mainboard for which the > build would remain enabled. The platform code then needs to go through > the transitions of =>RELOCATABLE_RAMSTAGE, =>POSTCAR_STAGE, > =>C_ENVIRONMENT_BOOTBLOCK. During that process, any remaining #include > <*.c> are to be removed and regressions other amdfam10-15 boards > __are__ allowed and will be ignored as the builds are disabled, Once > the reference platform reaches a state where it fulfills the release > requirements, interested parties can port the necessary changes to > individual motherboards. Providing boot-logs is a necessity. At the > time of next release, boards that don't build will have their source > files removed. > > Regards, > Kyösti Mälkki > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org -- Michał Żygowski Firmware Engineer http://3mdeb.com | @3mdeb_com ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Final calls for S3 suspend support on amdfam10-15
On Wed, Aug 21, 2019 at 5:43 AM Matt B wrote: > > Is a lack of C bootblock support common to all family 15h platforms? > (Including the G505s and any others?) > In other words, would it only need to be implemented once for all of these > systems? > It's not really a CPU family thing at all, but about the implementation otherwise. It's one fix for all AGESA, one for all binaryPI, and a third one for native amdfam10-15. My suggestion on moving forwards with amdfam10-15 is as follows: The next release is scheduled for Oct 2019 (?). Regardless of when that happens, I would introduce a flag on the October 1st that disables all amdfam10-15 boards from the automatic build. Then, if we have anyone capable and willing to have this amdfam10-15 stay on master branch, she/he would get to select one mainboard for which the build would remain enabled. The platform code then needs to go through the transitions of =>RELOCATABLE_RAMSTAGE, =>POSTCAR_STAGE, =>C_ENVIRONMENT_BOOTBLOCK. During that process, any remaining #include <*.c> are to be removed and regressions other amdfam10-15 boards __are__ allowed and will be ignored as the builds are disabled, Once the reference platform reaches a state where it fulfills the release requirements, interested parties can port the necessary changes to individual motherboards. Providing boot-logs is a necessity. At the time of next release, boards that don't build will have their source files removed. Regards, Kyösti Mälkki ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Final calls for S3 suspend support on amdfam10-15
On Wed, Aug 21, 2019 at 5:57 AM Thierry Laurion - Insurgo Technologies Libres / Open Technologies wrote: > > I could provide such resume logs for kgpe-d16. > > How do I produce them? > Cold boot, enter OS, enter S3 suspsnd. Wake up (probably toggle power button, moving mouse or anykey might not do it), then run 'sudo cbmem -1; sudo cbmem -c' after OS resumes and you have commandline. Also 'dmesg' would be nice. Kyösti ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Final calls for S3 suspend support on amdfam10-15
I could provide such resume logs for kgpe-d16. How do I produce them? On August 21, 2019 2:43:44 AM UTC, Matt B wrote: >Is a lack of C bootblock support common to all family 15h platforms? >(Including the G505s and any others?) >In other words, would it only need to be implemented once for all of >these >systems? > >Sincerely, >-Matthew Bradley > >On Thu, Aug 15, 2019 at 11:50 AM Kyösti Mälkki > >wrote: > >> Hi >> >> The decisions are out on 4.11 release requirements. Unless anyone >acts >> on it, amdfam10-15 boards will hit deprecation due to: >> * RELOCATABLE_RAMSTAGE=n >> * CAR_GLOBAL_MIGRATION=y >> * C_ENVIRONMENT_BOOTBLOCK=n >> >> To smooth down the path, should anyone want to attempt on fixing >> these, I have pushed a patchset [1] that removes S3 suspend support >> from said platform. Depending of what the response is, I hope to have >> that submitted already before 4.11 release. >> >> The latest info [2] I have is asus/kcma-d8 not working and >> asus/kgpe-d16 working in 4.6 but very slowly, for S3 resume boot, >that >> is. No resume logs have been brought to my knowledge for 12 months. I >> also had some suspicions that tests results were mistakenly from >> suspend-to-disk (S4). >> >> Affected boards are asus/kcma-d8 and asus/kgpe-d16. >> >> [1] https://review.coreboot.org/c/coreboot/+/15474 >> [2] >https://mail.coreboot.org/pipermail/coreboot/2018-June/086906.html >> >> Kind regards, >> Kyösti >> ___ >> coreboot mailing list -- coreboot@coreboot.org >> To unsubscribe send an email to coreboot-le...@coreboot.org >> -- Sent from /e/ Mail___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Final calls for S3 suspend support on amdfam10-15
Is a lack of C bootblock support common to all family 15h platforms? (Including the G505s and any others?) In other words, would it only need to be implemented once for all of these systems? Sincerely, -Matthew Bradley On Thu, Aug 15, 2019 at 11:50 AM Kyösti Mälkki wrote: > Hi > > The decisions are out on 4.11 release requirements. Unless anyone acts > on it, amdfam10-15 boards will hit deprecation due to: > * RELOCATABLE_RAMSTAGE=n > * CAR_GLOBAL_MIGRATION=y > * C_ENVIRONMENT_BOOTBLOCK=n > > To smooth down the path, should anyone want to attempt on fixing > these, I have pushed a patchset [1] that removes S3 suspend support > from said platform. Depending of what the response is, I hope to have > that submitted already before 4.11 release. > > The latest info [2] I have is asus/kcma-d8 not working and > asus/kgpe-d16 working in 4.6 but very slowly, for S3 resume boot, that > is. No resume logs have been brought to my knowledge for 12 months. I > also had some suspicions that tests results were mistakenly from > suspend-to-disk (S4). > > Affected boards are asus/kcma-d8 and asus/kgpe-d16. > > [1] https://review.coreboot.org/c/coreboot/+/15474 > [2] https://mail.coreboot.org/pipermail/coreboot/2018-June/086906.html > > Kind regards, > Kyösti > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
