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
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 kyosti.malkki@gmail.com 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-leave@coreboot.org
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 matthewwbradley6@gmail.com 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 kyosti.malkki@gmail.com 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.
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-leave@coreboot.org
-- Sent from /e/ Mail
On Wed, Aug 21, 2019 at 5:57 AM Thierry Laurion - Insurgo Technologies Libres / Open Technologies thierry.laurion@gmail.com 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
On Wed, Aug 21, 2019 at 5:43 AM Matt B matthewwbradley6@gmail.com 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
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 matthewwbradley6@gmail.com 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-leave@coreboot.org
On Wed, Aug 21, 2019 at 9:23 AM Michal Zygowski michal.zygowski@3mdeb.com 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
On 8/21/19 8:59 AM, Kyösti Mälkki wrote:
On Wed, Aug 21, 2019 at 9:23 AM Michal Zygowski michal.zygowski@3mdeb.com 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-leave@coreboot.org
On Wed, Aug 21, 2019 at 6:53 PM Michal Zygowski michal.zygowski@3mdeb.com 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
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 kyosti.malkki@gmail.com wrote:
On Wed, Aug 21, 2019 at 6:53 PM Michal Zygowski michal.zygowski@3mdeb.com 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-leave@coreboot.org
On Wed, Aug 21, 2019 at 7:52 PM Raul Rangel rrangel@chromium.org 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
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 kyosti.malkki@gmail.com wrote:
On Wed, Aug 21, 2019 at 7:52 PM Raul Rangel rrangel@chromium.org 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-leave@coreboot.org
On Thu, Aug 22, 2019 at 4:59 AM Matt B matthewwbradley6@gmail.com 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
-
Kyösti Mälkki -
Matt B -
Michal Zygowski -
Raul Rangel -
Thierry Laurion - Insurgo Technologies Libres / Open Technologies