On 8/21/19 8:59 AM, Kyösti Mälkki wrote:
On Wed, Aug 21, 2019 at 9:23 AM Michal Zygowski email@example.com wrote:
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 -- firstname.lastname@example.org To unsubscribe send an email to email@example.com