summaryrefslogtreecommitdiff
path: root/src/arch/x86/prologue.inc
diff options
context:
space:
mode:
authorJulius Werner <jwerner@chromium.org>2016-05-12 14:40:57 -0700
committerJulius Werner <jwerner@chromium.org>2016-05-17 22:48:28 +0200
commit2296479dfd886d4cf4c145f1d3ed1ec64dc20630 (patch)
tree15b93696b4470064fb080efcbc04a260bddb8129 /src/arch/x86/prologue.inc
parent4bab6e79b078c76d0a42883c4b4c9c68615d5a1e (diff)
libpayload: cbfs: Add cbfs_handle API for more fine-grained accesses
The libpayload CBFS APIs are pretty old and clunky, primarily because of the way the cbfs_media struct may or may not be passed in and may be initialized inside the API calls in a way that cannot be passed back out again. Due to this, the only real CBFS access function we have always reads a whole file with all metadata, and everything else has to build on top of that. This makes certain tasks like reading just a file attribute very inefficient on non-memory-mapped platforms (because you always have to map the whole file). This patch isn't going to fix the world, but will allow a bit more flexibility by bolting a new API on top which uses a struct cbfs_handle to represent a found but not yet read file. A cbfs_handle contains a copy of the cbfs_media needed to read the file, so it can be kept and passed around to read individual parts of it after the initial lookup. The existing (non-media) legacy API is retained for backwards compatibility, as is cbfs_file_get_contents() (which is most likely what more recent payloads would have used, and also a good convenience wrapper for the most simple use case), but they are now implemented on top of the new API. TEST=Booted Oak, made sure that firmware screens and software sync worked okay. Change-Id: I269f3979e77ae691ee9d4e1ab564eff6d45b7cbe Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/14810 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Diffstat (limited to 'src/arch/x86/prologue.inc')
0 files changed, 0 insertions, 0 deletions