danh-arm
commented
8 years ago In terms of existing support, there's the IO framework (drivers/io), which aims to abstract any IO read/write operation. As you know there's a Pull Request to add a new IO_BLOCK type and an eMMC driver. Potentally other flash drivers could sit under the IO_BLOCK type.
If BL1/BL2 requires dynamic configuration data to be read from NV storage, then I'd expect that data to be stored with the images/certificates and authenticated as part of the normal boot process. Framework support for this is something we intend looking at later this year.
If BL3X images require dynamic configuration data during cold boot, I would expect BL2 platform code to pass this to the platform BL3X code, perhaps with the help of the framework support I just mentioned (e.g. for parsing variables in the config data).
I would not expect BL31 to read/write from flash at any time. I would expect any storing/retrieving of (authenticated) NV parameters at runtime to be done by the Secure Payload (BL32); it may even provide an interface to the normal world for this.
I hadn't really considered the need for BL2 code to write paramaters back to NV storage (e.g. in your DDR tuning use-case). In theory, once the framework support for reading dynamic configuration data is in place, it would be a small additional step to support writing that configuration back to NV storage, although it's likely this would only be done on a file-by-file basis rather than a parameter-by-parameter basis. This should be OK if all the DDR config data were in a single file (separate to any other config data). I'm using the term "file" loosely here - I don't mean file system support.
Has there been any thought put into providing a driver for storing and retrieving nv parameters from flash devices? Here is the current use case:
If infrastructure existed to fetch such parameters from flash and store the parameters to flash at appropriate locations in the ATF boot flow it would solve having to fetch/store (and authenticate) inside each image. In order to minimize flash usage we need infrastructure to support (at least) 2 erase blocks and determine which block is active. We also need to be able to read/write/update parameters as needed. Some parameters may even be erased/updated at later times when the rich os is running.
Does adding such generic infrastructure fit anywhere in the ATF framework?