Raul Rangel wrote: > I'm currently working on improving the boot time for the AMD Cezanne > platform. .. > Another difference between the latest AMD SoCs (Picasso, Cezanne), is > that RAM is available in bootblock.
As I have understood, the PSP has both trained RAM and copied firmware from SPI to RAM when x86 comes out of reset. Is that accurate, false, or only partially accurate? If not fully accurate then how are you accessing the SPI chip? I guess it can't be memory mapped? > One place where we spend a decent amount of time is reading from SPI > flash. We have the SPI speed/modes set to the optimal settings for > our platforms, but there is still room for improvement. Please provide numbers? > The question is, how do we model these asynchronous operations, how is > data ownership handled, and how does the BSP know the operation is > done? I haven't yet reveiewed your API proposal, but find it an absolutely horrible idea to create a *general* API for asynchronous operations in coreboot, because - as you recognize - it can easily be misused to great detriment of the codebase, which already suffers chronically from such trivial problems as copy-paste:itis. Don't do it. There is zero incentive for developers to improve the source beyond making it work for their deadline; more complexity *will* create more problems. (I understand that you have good intentions proposing this change!) > I'm curious to see what the community thinks, and welcome any feedback. A special purpose DMA API is another matter to me, because it's very well defined. It could still be useful beyond x86 and I think a blocking "wait-for-DMA-to-finish" API is easy to understand, easy to implement and to use, and sufficient since runtime flow is serial, especially when measuring. //Peter _______________________________________________ coreboot mailing list -- [email protected] To unsubscribe send an email to [email protected]
