On Wed, Jul 7, 2021 at 12:49 PM Peter Stuge <[email protected]> wrote: > > 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?
It's partially accurate. The PSP will load bootblock into RAM. So coreboot still needs to access the SPI flash to load everything else. > > > 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? Sorry, that sentence didn't come out how I wanted. I was just saying that we could improve the boot time by exploring other avenues. > > > 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!) There has been a lot of work in refactoring the AMD codebases and fixing things throughout the stack. We have reduced a good amount of copy/paste when bringing up a new AMD SoC. So I don't agree that we are all writing abandonware. Please have a look at the proposal before making such hasty judgments. > > > 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. That was my original thought, but there are plenty of other things that can be modeled as asynchronous operations. Stuffing it into the rdev API felt wrong. Thanks, Raul p.s., Just to add some more data. I performed an experiment where I switched the payload compression from LZMA to LZ4. Since we no longer pay the SPI read cost (thanks async!), we essentially load the payload for free: ## Payload LZMZ compression (current) ``` Name Offset Type Size fallback/payload 0x224dc0 simple elf 131417 (128 KiB) ``` ``` 90:starting to load payload 1,123,962 (13) 15:starting LZMA decompress 1,123,967 (5) 16:finished LZMA decompress 1,131,201 (7,234) ``` ## Payload LZ4 compression ``` Name Offset Type Size fallback/payload 0x224dc0 simple elf 173233 (169 KiB) ``` ``` 90:starting to load payload 1,130,877 (12) 17:starting LZ4 decompress 1,130,882 (5) 18:finished LZ4 decompress 1,131,091 (209) ``` ``` Payload increase: KiB: 169 - 128 = 41 KiB %: (169 - 128) / 128 = 0.3203125 Decompression decrease: us: 209 - 7234 = -7025 %: (209 - 7234) / 7234 = -0.9711086535803152 ``` _______________________________________________ coreboot mailing list -- [email protected] To unsubscribe send an email to [email protected]
