Difference between revisions of "User talk:MrNuke"

From coreboot
Jump to navigation Jump to search
 
(32 intermediate revisions by 2 users not shown)
Line 1: Line 1:
== Ideas for generic handling of devices ==
== Sections deserving their own page ==
* [[User_talk:MrNuke/Block_Device_API | IDEAPAGE: Generic handling of storage devices]]
* [[User_talk:MrNuke/CBFS_Ideas | IDEAPAGE: CBFS partitioning support]]


IMPORTANT! Feel free to edit this page to share your thoughts and ideas. This is the official MMC open brainstorming page.
== Testing ARM coreboot under qemu-system-arm ==


=== Proposal 1: Unified API ===
Launch qemu with '''-serial stdio''' and pass kernel the '''console=tty''' option. (UNTESTED).
Chan is an IO channel.  


This struct is used in Inferno and has been for a long time; so it works.
Run qemu-arm:
It's also in the opcodes somewhat like what we did for EMMC on ARM.
  '''$ qemu-system-arm -M vexpress-a9 -m 1024M -serial stdio -kernel build/coreboot.rom'''
 
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
 
{| class="wikitable"
! style="width: 3em;" | Offset
! style="width: 3em;" | 0
! style="width: 3em;" | 1
! style="width: 3em;" | 2
! style="width: 3em;" | 3
! style="width: 3em;" | 4
! style="width: 3em;" | 5
! style="width: 3em;" | 6
! style="width: 3em;" | 7
! style="width: 3em;" | 8
! style="width: 3em;" | 9
! style="width: 3em;" | A
! style="width: 3em;" | B
! style="width: 3em;" | C
! style="width: 3em;" | D
! style="width: 3em;" | E
! style="width: 3em;" | F
 
|-
| 0x00
! colspan="4"| "ORBC"
! colspan="4"| version
! colspan="4"| romsize
! colspan="4"| bootblocksize
 
|-
| 0x10
! colspan="4"| align
! colspan="4"| offset
! colspan="4"| arch
! colspan="4"| padding
 
|-
|}
 
==== Proposed partition entry ====
 
All values are big endian
 
{| class="wikitable"
! style="width: 3em;" | Offset
! style="width: 3em;" | 0
! style="width: 3em;" | 1
! style="width: 3em;" | 2
! style="width: 3em;" | 3
! style="width: 3em;" | 4
! style="width: 3em;" | 5
! style="width: 3em;" | 6
! style="width: 3em;" | 7
! style="width: 3em;" | 8
! style="width: 3em;" | 9
! style="width: 3em;" | A
! style="width: 3em;" | B
! style="width: 3em;" | C
! style="width: 3em;" | D
! style="width: 3em;" | E
! style="width: 3em;" | F
 
|-
| 0x00
! colspan="4"| "CBPT"
! colspan="4"| offset
! colspan="4"| size
! colspan="4"| region_name
 
|-
| 0x10
! colspan="16"| 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 ====
 
{| class="wikitable"
! style="width: 3em;" | Offset
! style="width: 3em;" | 0
! style="width: 3em;" | 1
! style="width: 3em;" | 2
! style="width: 3em;" | 3
! style="width: 3em;" | 4
! style="width: 3em;" | 5
! style="width: 3em;" | 6
! style="width: 3em;" | 7
! style="width: 3em;" | 8
! style="width: 3em;" | 9
! style="width: 3em;" | A
! style="width: 3em;" | B
! style="width: 3em;" | C
! style="width: 3em;" | D
! style="width: 3em;" | E
! style="width: 3em;" | F
 
|-
| 0x10
! colspan="16"| CBPT1
 
|-
| 0x_0
! colspan="16"| CBPT2
 
|-
| 0x_0
! colspan="16"| CBPT3
 
|-
| 0x10
! colspan="16"| terminator all '1's
 
|-
|}
 
===== Example partition table =====
 
{| class="wikitable"
! style="width: 3em;" | Offset
! style="width: 3em;" | 0
! style="width: 3em;" | 1
! style="width: 3em;" | 2
! style="width: 3em;" | 3
! style="width: 3em;" | 4
! style="width: 3em;" | 5
! style="width: 3em;" | 6
! style="width: 3em;" | 7
! style="width: 3em;" | 8
! style="width: 3em;" | 9
! style="width: 3em;" | A
! style="width: 3em;" | B
! style="width: 3em;" | C
! style="width: 3em;" | D
! style="width: 3em;" | E
! style="width: 3em;" | F
 
|-
| 0x10
! colspan="4"| "CBPT"
! colspan="4"| 0x00070000
! colspan="4"| 0x00010000
! colspan="1"| 'c'
! colspan="1"| 'o'
! colspan="1"| 'r'
! colspan="1"| 'e'
 
|-
| 0x10
! colspan="1"| 'b'
! colspan="1"| 'o'
! colspan="1"| 'o'
! colspan="1"| 't'
! colspan="1"| '\0'
! colspan="11"| 0xff
 
|-
|}

Latest revision as of 19:55, 6 February 2014

Sections deserving their own page

Testing ARM coreboot under qemu-system-arm

Launch qemu with -serial stdio and pass kernel the console=tty option. (UNTESTED).

Run qemu-arm:

$ qemu-system-arm -M vexpress-a9 -m 1024M -serial stdio -kernel build/coreboot.rom