On Wed, Jul 7, 2021 at 12:49 PM Peter Stuge peter@stuge.se 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 ```