User talk:MrNuke: Difference between revisions
Jump to navigation
Jump to search
Line 42: | Line 42: | ||
* To be able to better handle the requirements of ChromeOS | * To be able to better handle the requirements of ChromeOS | ||
=== Tentative | === Tentative terminology === | ||
* Partition | * Partition |
Revision as of 04:59, 22 January 2014
Ideas for generic handling of devices
IMPORTANT! Feel free to edit this page to share your thoughts and ideas. This is the official MMC open brainstorming page.
Proposal 1: Unified API
Chan is an IO channel.
This struct is used in Inferno and has been for a long time; so it works. It's also in the opcodes somewhat like what we did for EMMC on ARM.
struct Dev { char* name; void (*reset)(void); void (*init)(void); void (*shutdown)(void); Chan* (*attach)(char*); /* tell the device you want to use it */ Walkqid* (*walk)(Chan*, Chan*, char**, int); /* walk to a name in the device's managed name space; return a handle */ int (*stat)(Chan*, uchar*, int); // status info Chan* (*open)(Chan*, int); /* get access to a resource in the device name space */ void (*close)(Chan*); /* tell it you are done with whatever it is. */ long (*read)(Chan*, void*, long, vlong); long (*write)(Chan*, void*, long, vlong); void (*power)(int); /* power mgt: power(1) ? on, power (0) ? off */ };
Questions
- Do we want to expose or hide the block nature of some devces (i.e. force reading multiples of blocksize, or allow reading any number of bytes, with no alignment requirement) ?
- How do we connect the dots, such that most of the details can be handled transparently ?
- How simple or complex do we want the API to be such that it can work in any stage (including bootblock, assuming some SRAM and a stack are available) ?
- Can we integrate this into libpayload such that the same sources can be used for both coreboot and libpayload ?
- think "Device specfic storage drivers -> [*] Allwinner A10 MMC driver" in libpayload config
- More questions coming soon (TM)
Extending CBFS to support partitioning
Reasoning
- To separate write-protected (RO) and writeable (RW) regions of flash chip
- To incorporate relevant FMAP features directly into CBFS
- To be able to better handle the requirements of ChromeOS
Tentative terminology
- Partition
- A region indexed by CBFS
- File
- Same meaning as before. A CBFS file that resides entirely within the boundaries of one partition.
Design constraints
- Backwards compatibility
- New CBFS structure should be backwards compatible with old structure
- Old payloads should still be able to access old features of CBFS
Tentative API
- cbfs_get_file(const char *name) <- Get file in main partition, also backwards compatible
- cbfs_get_partition(const char *name) <- Get location of partition other than main (or even main)
- cbfs_get_partition_file(cbfs_part_t partition, const char *name) <- Get file in given partition
Hypothetical examples
Partition in read-write portion of flash
Here, we assume that "rw1" is not in a write-protected area of flash.
void *rw1 = cbfs_get_partition("rw1"); file *romstage cbfs_get_partition_file(rw1, "fallback/romstage); load_and_run_stage(romstage);
MRC cache
void *mrc_cache = cbfs_get_partition("mrc.cache"); /* Access raw partition, there is no file in this partition */ mrc_cache_check(mrc_cache); mrc_cache_write(mrc_cache, data);