User talk:MrNuke: Difference between revisions

From coreboot
Jump to navigation Jump to search
 
(15 intermediate revisions by the same user 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:''' Change '''padding''' to a signed offset pointing to partition table; all '1's means no partition table is available
** The offset shall be from the start of "ORBC" signature.
** alternatively: limit number of partitions to something reasonable, move names into partitions (so partition entries are fixed size) and append the partition table to the master header. Existence proven by master_header's version field (cbfs_core ignores it right now, which is good).
 
==== Proposed partition entry ====
 
All values are big endian
 
===== Variable name length =====
 
{| 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
 
===== Fixed name length + partition flags =====
 
{| 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"| flags
 
|-
| 0x10
! colspan="16"| region_name
 
|-
| 0x20
! colspan="16"| region_name
 
|-
|}
 
* '''region_name''' shall be null-terminated.
** It is always 32-bytes, but can be null-terminated earlier
** Unused bytes will be all '1's
* This structure is marginally easier to parse as opposed to variable length
 
==== Questions ====
 
* Should region_name be fixed to 32-bytes, like in FMAP?
* Should we include a field for partition flags?
** What are the use-cases
** Would this really be useful?
** Would this '''actually''' get used in the wild?
* Should we just use the FMAP format?
 
==== Proposed partition table ====
 
===== Varlen name header =====
 
{| 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
 
|-
| 0x_0
! colspan="4"| terminator all '1's
 
|-
|}
 
* Generally, CBPT1 will point to the same region as the master header, but this is not required. The idea is that old payloads will still be able to read CBFS by using the region pointed to by the master header. Whether this region is the same as CBPT1 or not is not guaranteed. This is to not impose a specific order on the partition entries.
 
===== Fixlen name header =====
 
{| 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="16"| CBPT1
 
|-
| 0x30
! colspan="16"| CBPT2
 
|-
| 0x60
! colspan="16"| CBPT3
 
|-
| 0x90
! colspan="4"| terminator all '1's
 
|-
|}
 
* Generally, CBPT1 will point to the same region as the master header, but this is not required. The idea is that old payloads will still be able to read CBFS by using the region pointed to by the master header. Whether this region is the same as CBPT1 or not is not guaranteed. This is to not impose a specific order on the partition entries.
 
===== Example partition table =====
 
====== With variable name length ======
 
{| 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"| 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
 
|-
| 0x20
! colspan="4"| "CBPT"
! colspan="4"| 0x00040000
! colspan="4"| 0x00020000
! colspan="1"| t
! colspan="1"| h
! colspan="1"| i
! colspan="1"| s
 
|-
| 0x30
! colspan="1"| _
! colspan="1"| p
! colspan="1"| a
! colspan="1"| r
! colspan="1"| t
! colspan="1"| i
! colspan="1"| t
! colspan="1"| i
! colspan="1"| o
! colspan="1"| n
! colspan="1"| _
! colspan="1"| h
! colspan="1"| a
! colspan="1"| s
! colspan="1"| _
! colspan="1"| a
 
|-
| 0x40
! colspan="1"| _
! colspan="1"| l
! colspan="1"| u
! colspan="1"| d
! colspan="1"| i
! colspan="1"| c
! colspan="1"| r
! colspan="1"| o
! colspan="1"| u
! colspan="1"| s
! colspan="1"| l
! colspan="1"| y
! colspan="1"| _
! colspan="1"| l
! colspan="1"| o
! colspan="1"| n
 
|-
| 0x50
! colspan="1"| g
! colspan="1"| .
! colspan="1"| n
! colspan="1"| a
! colspan="1"| m
! colspan="1"| e
! colspan="1"| \0
! colspan="9"| 0xff
 
|-
| 0x60
! colspan="4"| "CBPT"
! colspan="4"| 0x00060000
! colspan="4"| 0x00010000
! colspan="1"| m
! colspan="1"| r
! colspan="1"| c
! colspan="1"| .
 
|-
| 0x70
! colspan="1"| c
! colspan="1"| a
! colspan="1"| c
! colspan="1"| h
! colspan="1"| e
! colspan="1"| \0
! colspan="10"| 0xff
 
|-
| 0x80
! colspan="4"| 0xffffffff
 
|-
|}
 
* "coreboot": 0x00070000 + 0x00010000
* "this_partition_has_a_ludicrously_long.name" 0x00040000 + 0x00020000
* "mrc.cache": 0x00070000 + 0x00010000
 
====== With fixed name length and flags ======
 
{| 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"| 0x00070000
! colspan="4"| 0x00010000
! colspan="4"| 0x00000000
 
|-
| 0x10
! colspan="1"| c
! colspan="1"| o
! colspan="1"| r
! colspan="1"| e
! colspan="1"| b
! colspan="1"| o
! colspan="1"| o
! colspan="1"| t
! colspan="1"| \0
! colspan="7"| 0xff
 
|-
| 0x20
! colspan="16"| 0xff
 
|-
| 0x30
! colspan="4"| "CBPT"
! colspan="4"| 0x00040000
! colspan="4"| 0x00020000
! colspan="1"| t
! colspan="1"| h
! colspan="1"| i
! colspan="1"| s
 
|-
| 0x40
! colspan="1"| _
! colspan="1"| p
! colspan="1"| a
! colspan="1"| r
! colspan="1"| t
! colspan="1"| i
! colspan="1"| t
! colspan="1"| i
! colspan="1"| o
! colspan="1"| n
! colspan="1"| _
! colspan="1"| h
! colspan="1"| a
! colspan="1"| s
! colspan="1"| _
! colspan="1"| a
 
|-
| 0x50
! colspan="1"| _
! colspan="1"| l
! colspan="1"| u
! colspan="1"| d
! colspan="1"| i
! colspan="1"| c
! colspan="1"| r
! colspan="1"| o
! colspan="1"| u
! colspan="1"| s
! colspan="1"| l
! colspan="1"| y
! colspan="1"| _
! colspan="1"| l
! colspan="1"| o
! colspan="1"| n
 
|-
| 0x50
! colspan="1"| g
! colspan="1"| .
! colspan="1"| n
! colspan="1"| a
! colspan="1"| m
! colspan="1"| e
! colspan="1"| \0
! colspan="9"| 0xff
 
|-
| 0x60
! colspan="4"| "CBPT"
! colspan="4"| 0x00060000
! colspan="4"| 0x00010000
! colspan="1"| m
! colspan="1"| r
! colspan="1"| c
! colspan="1"| .
 
|-
| 0x70
! colspan="1"| c
! colspan="1"| a
! colspan="1"| c
! colspan="1"| h
! colspan="1"| e
! colspan="1"| \0
! colspan="10"| 0xff
 
|-
| 0x80
! colspan="4"| 0xffffffff
 
|-
|}
 
* "coreboot": 0x00070000 + 0x00010000
* "this_partition_has_a_ludicrously_long.name" 0x00040000 + 0x00020000
* "mrc.cache": 0x00070000 + 0x00010000

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
Retrieved from "https://www.coreboot.org/index.php?title=User_talk:MrNuke&oldid=13306"