User talk:MrNuke

From coreboot
Revision as of 06:29, 22 January 2014 by MrNuke (talk | contribs) (Example partition table)
Jump to: navigation, search

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 */


  1. 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) ?
  2. How do we connect the dots, such that most of the details can be handled transparently ?
  3. 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) ?
  4. 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
  5. More questions coming soon (TM)

Extending CBFS to support partitioning


  • 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);

MRC cache

void *mrc_cache = cbfs_get_partition("mrc.cache");
/* Access raw partition, there is no file in this partition */
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

All values are big endian

Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F
0x00 "CBPT" offset size region_name
0x10 region_name ...
  • region_name shall be null-terminated.
  • Each partition entry shall be 16 byte aligned.
  • Subsequent entries shall be placed at the closest 16-byte aligned offset

Proposed partition table

Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F
0x10 CBPT1
0x_0 CBPT2
0x_0 CBPT3
0x10 terminator all '1's
Example partition table
Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F
0x00 "CBPT" 0x00070000 0x00010000 'c' 'o' 'r' 'e'
0x10 'b' 'o' 'o' 't' '\0' 0xff
0x20 "CBPT" 0x00040000 0x00020000 't' 'h' 'i' 's'
0x30 '_' 'p' 'a' 'r' 't' 'i' 't' 'i' 'o' 'n' '_' 'h' 'a' 's' '_' 'a'
0x40 '_' 'l' 'u' 'd' 'i' 'c' 'r' 'o' 'u' 's' 'l' 'y' '_' 'l' 'o' 'n'
0x50 'g' '.' 'n' 'a' 'm' 'e' 0xff