GNUBoot
/
coreboot-kgpe-d16
2
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

v2/documentation: romfs -> cbfs rename 

This is svn mv romfs.txt cbfs.txt and sed romfs->cbfs, ROMFS->CBFS along with
one manual change: CBFS_file->cbfs_file

Signed-off-by: Peter Stuge <peter@stuge.se>
Acked-by: Ronald G. Minnich <rminnich@gmail.com>                                


git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4109 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
This commit is contained in:
Peter Stuge 2009-04-14 00:01:34 +00:00
parent 299a00feb8
commit 450b23fb2e
1 changed files with 27 additions and 27 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

54
documentation/romfs.txt → documentation/cbfs.txt
View File

@ -18,20 +18,20 @@ My goal was to add small things to LAR while retaining the overall
scheme. Over time, the scheme evolved slightly, but I think you'll find scheme. Over time, the scheme evolved slightly, but I think you'll find
that it remains true to the original idea. Below is the beginnings of that it remains true to the original idea. Below is the beginnings of
an architecture document - I did it in text form, but if met with an architecture document - I did it in text form, but if met with
aclaim, it should be wikified. This presents what I call ROMFS - the aclaim, it should be wikified. This presents what I call CBFS - the
next generation LAR for next generation Coreboot. Its easier to next generation LAR for next generation Coreboot. Its easier to
describe what it is by describing what changed: describe what it is by describing what changed:
A header has been added somewhere in the bootblock similar to Carl A header has been added somewhere in the bootblock similar to Carl
Daniel's scheme. In addition to the coreboot information, the header Daniel's scheme. In addition to the coreboot information, the header
reports the size of the ROM, the alignment of the blocks, and the offset reports the size of the ROM, the alignment of the blocks, and the offset
of the first component in the ROMFS. The master header provides all of the first component in the CBFS. The master header provides all
the information LAR needs plus the magic number information flashrom needs. the information LAR needs plus the magic number information flashrom needs.
Each "file" (or component, as I style them) now has a type associated Each "file" (or component, as I style them) now has a type associated
with it. The type is used by coreboot to identify the type of file that with it. The type is used by coreboot to identify the type of file that
it is loading, and it can also be used by payloads to group items in the it is loading, and it can also be used by payloads to group items in the
ROMFS by type (i.e - bayou can ask for all components that are payloads). CBFS by type (i.e - bayou can ask for all components that are payloads).
The header on each "file" (or component, as I like to style them) has The header on each "file" (or component, as I like to style them) has
been simplified - We now only store the length, the type, the checksum, been simplified - We now only store the length, the type, the checksum,
@ -73,20 +73,20 @@ bucks, will you?
Jordan Jordan
Coreboot ROMFS Specification Coreboot CBFS Specification
Jordan Crouse <jordan@cosmicpenguin.net> Jordan Crouse <jordan@cosmicpenguin.net>
= Introduction = = Introduction =
This document describes the coreboot ROMFS specification (from here This document describes the coreboot CBFS specification (from here
referred to as ROMFS). ROMFS is a scheme for managing independent chunks referred to as CBFS). CBFS is a scheme for managing independent chunks
of data in a system ROM. Though not a true filesystem, the style and of data in a system ROM. Though not a true filesystem, the style and
concepts are similar. concepts are similar.
= Architecture = = Architecture =
The ROMFS architecture looks like the following: The CBFS architecture looks like the following:
/---------------\ <-- Start of ROM /---------------\ <-- Start of ROM
| /-----------\ | --| | /-----------\ | --|
@ -117,7 +117,7 @@ The ROMFS architecture looks like the following:
\---------------/ \---------------/
The ROMFS architecture consists of a binary associated with a physical The CBFS architecture consists of a binary associated with a physical
ROM disk referred hereafter as the ROM. A number of independent of ROM disk referred hereafter as the ROM. A number of independent of
components, each with a header prepended on to data are located within components, each with a header prepended on to data are located within
the ROM. The components are nominally arranged sequentially, though they the ROM. The components are nominally arranged sequentially, though they
@ -126,12 +126,12 @@ are aligned along a pre-defined boundary.
The bootblock occupies the last 20k of the ROM. Within The bootblock occupies the last 20k of the ROM. Within
the bootblock is a master header containing information about the ROM the bootblock is a master header containing information about the ROM
including the size, alignment of the components, and the offset of the including the size, alignment of the components, and the offset of the
start of the first ROMFS component within the ROM. start of the first CBFS component within the ROM.
= Master Header = = Master Header =
The master header contains essential information about the ROM that is The master header contains essential information about the ROM that is
used by both the ROMFS implementation within coreboot at runtime as well used by both the CBFS implementation within coreboot at runtime as well
as host based utilities to create and manage the ROM. The master header as host based utilities to create and manage the ROM. The master header
will be located somewhere within the bootblock (last 20k of the ROM). A will be located somewhere within the bootblock (last 20k of the ROM). A
pointer to the location of the header will be located at offset pointer to the location of the header will be located at offset
@ -143,7 +143,7 @@ need to read the pointer and do the appropriate math to locate the header.
The following is the structure of the master header: The following is the structure of the master header:
struct romfs_header { struct cbfs_header {
unsigned int magic; unsigned int magic;
unsigned int size; unsigned int size;
unsigned int align; unsigned int align;
@ -152,7 +152,7 @@ struct romfs_header {
The meaning of each member is as follows: The meaning of each member is as follows:
'magic' is a 32 bit number that identifies the ROM as a ROMFS type. The 'magic' is a 32 bit number that identifies the ROM as a CBFS type. The
magic magic
number is 0x4F524243, which is 'ORBC' in ASCII. number is 0x4F524243, which is 'ORBC' in ASCII.
@ -165,7 +165,7 @@ with
regards to the erase block sizes on the ROM - allowing one to replace a regards to the erase block sizes on the ROM - allowing one to replace a
component at runtime without disturbing the others. component at runtime without disturbing the others.
'offset' is the offset of the the first ROMFS component (from the start of 'offset' is the offset of the the first CBFS component (from the start of
the ROM). This is to allow for arbitrary space to be left at the beginning the ROM). This is to allow for arbitrary space to be left at the beginning
of the ROM for things like embedded controller firmware. of the ROM for things like embedded controller firmware.
@ -178,21 +178,21 @@ does not have a component header attached to it.
= Components = = Components =
ROMFS components are placed in the ROM starting at 'offset' specified in CBFS components are placed in the ROM starting at 'offset' specified in
the master header and ending at the bootblock. Thus the total size the master header and ending at the bootblock. Thus the total size
available available
for components in the ROM is (ROM size - 20k - 'offset'). Each ROMFS for components in the ROM is (ROM size - 20k - 'offset'). Each CBFS
component is to be aligned according to the 'align' value in the header. component is to be aligned according to the 'align' value in the header.
Thus, if a component of size 1052 is located at offset 0 with an 'align' Thus, if a component of size 1052 is located at offset 0 with an 'align'
value value
of 1024, the next component will be located at offset 2048. of 1024, the next component will be located at offset 2048.
Each ROMFS component will be indexed with a unique ASCII string name of Each CBFS component will be indexed with a unique ASCII string name of
unlimited size. unlimited size.
Each ROMFS component starts with a header: Each CBFS component starts with a header:
struct ROMFS_file { struct cbfs_file {
char magic[8]; char magic[8];
unsigned int len; unsigned int len;
unsigned int type; unsigned int type;
@ -226,7 +226,7 @@ structure of the header:
/--------\ <- start /--------\ <- start
| Header | | Header |
|--------| <- sizeof(struct romfs_file) |--------| <- sizeof(struct cbfs_file)
| Name | | Name |
|--------| <- 'offset' |--------| <- 'offset'
| Data | | Data |
@ -236,26 +236,26 @@ structure of the header:
== Searching Alogrithm == == Searching Alogrithm ==
To locate a specific component in the ROM, one starts at the 'offset' To locate a specific component in the ROM, one starts at the 'offset'
specified in the ROMFS master header. For this example, the offset will specified in the CBFS master header. For this example, the offset will
be 0. be 0.
From that offset, the code should search for the magic string on the From that offset, the code should search for the magic string on the
component, jumping 'align' bytes each time. So, assuming that 'align' is component, jumping 'align' bytes each time. So, assuming that 'align' is
16, the code will search for the string 'LARCHIVE' at offset 0, 16, 32, etc. 16, the code will search for the string 'LARCHIVE' at offset 0, 16, 32, etc.
If the offset ever exceeds the allowable range for ROMFS components, then no If the offset ever exceeds the allowable range for CBFS components, then no
component was found. component was found.
Upon recognizing a component, the software then has to search for the Upon recognizing a component, the software then has to search for the
specific name of the component. This is accomplished by comparing the specific name of the component. This is accomplished by comparing the
desired name with the string on the component located at desired name with the string on the component located at
offset + sizeof(struct romfs_file). If the string matches, then the offset + sizeof(struct cbfs_file). If the string matches, then the
component component
has been located, otherwise the software should add 'offset' + 'len' to has been located, otherwise the software should add 'offset' + 'len' to
the offset and resume the search for the magic value. the offset and resume the search for the magic value.
== Data Types == == Data Types ==
The 'type' member of struct romfs_file is used to identify the content The 'type' member of struct cbfs_file is used to identify the content
of the component data, and is used by coreboot and other of the component data, and is used by coreboot and other
run-time entities to make decisions about how to handle the data. run-time entities to make decisions about how to handle the data.
@ -286,7 +286,7 @@ The following is the format of a stage component:
The header is defined as: The header is defined as:
struct romfs_stage { struct cbfs_stage {
unsigned int compression; unsigned int compression;
unsigned long long entry; unsigned long long entry;
unsigned long long load; unsigned long long load;
@ -345,8 +345,8 @@ The following is the format of a stage component:
The header is as follows: The header is as follows:
struct romfs_payload { struct cbfs_payload {
struct romfs_payload_segment segments; struct cbfs_payload_segment segments;
} }
The header contains a number of segments corresponding to the segments The header contains a number of segments corresponding to the segments
@ -354,7 +354,7 @@ that need to be loaded for the payload.
The following is the structure of each segment header: The following is the structure of each segment header:
struct romfs_payload_segment { struct cbfs_payload_segment {
unsigned int type; unsigned int type;
unsigned int compression; unsigned int compression;
unsigned int offset; unsigned int offset;