User talk:MrNuke: Difference between revisions

Revision as of 06:29, 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);

Technical stuff

Current CBFS master header

All values are big endian

Offset	0	1	2	3	4	5	6	7	8	9	A	B	C	D	E	F
0x00	"ORBC"				version				romsize				bootblocksize
0x10	align				offset				arch				padding

Proposed partition entry