On Wed, Aug 21, 2019 at 9:23 AM Michal Zygowski <[email protected]> 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 -- [email protected] To unsubscribe send an email to [email protected]
