CBFS document is a little old since the structure of it has changed a lot specially CBFS master header. This patch updated the document to show the newest structure of CBFS.
Signed-off-by: Yang Bai hamo.by@gmail.com
Index: documentation/cbfs.txt =================================================================== --- documentation/cbfs.txt (revision 6534) +++ documentation/cbfs.txt (working copy) @@ -144,10 +144,13 @@ The following is the structure of the master header:
struct cbfs_header { - unsigned int magic; - unsigned int size; - unsigned int align; - unsigned int offset; + u32 magic; + u32 version; + u32 romsize; + u32 bootblocksize; + u32 align; + u32 offset; + u32 pad[2]; };
The meaning of each member is as follows: @@ -156,9 +159,14 @@ magic number is 0x4F524243, which is 'ORBC' in ASCII.
-'size' is the size of the ROM in bytes. Coreboot will subtract 'size' from +'version' is a 32 bit number that shows the version of CBFS master header. +Since only one version exists now, it should always be 0x31313131. + +'romsize' is the size of the ROM in bytes. Coreboot will subtract 'romsize' from 0xFFFFFFFF to locate the beginning of the ROM in memory.
+'bootblocksize' is the size of the bootblock in bytes. + 'align' is the number of bytes that each component is aligned to within the ROM. This is used to make sure that each component is aligned correctly with @@ -193,11 +201,11 @@ Each CBFS component starts with a header:
struct cbfs_file { - char magic[8]; - unsigned int len; - unsigned int type; - unsigned int checksum; - unsigned int offset; + char magic[8]; + u32 len; + u32 type; + u32 checksum; + u32 offset; };
'magic' is a magic value used to identify the header. During runtime, @@ -287,11 +295,11 @@ The header is defined as:
struct cbfs_stage { - unsigned int compression; - unsigned long long entry; - unsigned long long load; - unsigned int len; - unsigned int memlen; + u32 compression; /** Compression type */ + u64 entry; /** entry point */ + u64 load; /** Where to load in memory */ + u32 len; /** length of data to load */ + u32 memlen; /** total length of object in memory */ };
'compression' is an integer defining how the data is compressed. There @@ -355,12 +363,12 @@ The following is the structure of each segment header:
struct cbfs_payload_segment { - unsigned int type; - unsigned int compression; - unsigned int offset; - unsigned long long load_addr; - unsigned int len; - unsigned int mem_len; + u32 type; + u32 compression; + u32 offset; + u64 load_addr; + u32 len; + u32 mem_len; };
'type' is the type of segment, one of the following:
On Thu, Apr 21, 2011 at 09:22:39PM +0800, Hamo wrote:
CBFS document is a little old since the structure of it has changed a lot specially CBFS master header. This patch updated the document to show the newest structure of CBFS.
Signed-off-by: Yang Bai hamo.by@gmail.com
Index: documentation/cbfs.txt
--- documentation/cbfs.txt (revision 6534) +++ documentation/cbfs.txt (working copy) @@ -144,10 +144,13 @@ The following is the structure of the master header:
struct cbfs_header {
- unsigned int magic;
- unsigned int size;
- unsigned int align;
- unsigned int offset;
- u32 magic;
u32 version;u32 romsize;u32 bootblocksize;- u32 align;
- u32 offset;
- u32 pad[2];
};
Any particular reason to not use the C99 uintXX_t types in the docs?
Jonathan Kollasch
On Fri, Apr 22, 2011 at 3:46 AM, Jonathan A. Kollasch jakllsch@kollasch.net wrote:
On Thu, Apr 21, 2011 at 09:22:39PM +0800, Hamo wrote:
CBFS document is a little old since the structure of it has changed a lot specially CBFS master header. This patch updated the document to show the newest structure of CBFS.
Signed-off-by: Yang Bai hamo.by@gmail.com
Index: documentation/cbfs.txt
--- documentation/cbfs.txt (revision 6534) +++ documentation/cbfs.txt (working copy) @@ -144,10 +144,13 @@ The following is the structure of the master header:
struct cbfs_header {
- unsigned int magic;
- unsigned int size;
- unsigned int align;
- unsigned int offset;
- u32 magic;
- u32 version;
- u32 romsize;
- u32 bootblocksize;
- u32 align;
- u32 offset;
- u32 pad[2];
};
Any particular reason to not use the C99 uintXX_t types in the docs?
Jonathan Kollasch
I don't know. The code style is a little strange. In file src/include/cbfs.h, uXX is used but in file util/cbfstool/common.h, C99 style is used.
Ping... Comments are welcome...
On Fri, Apr 22, 2011 at 8:03 AM, Hamo hamo.by@gmail.com wrote:
On Fri, Apr 22, 2011 at 3:46 AM, Jonathan A. Kollasch jakllsch@kollasch.net wrote:
On Thu, Apr 21, 2011 at 09:22:39PM +0800, Hamo wrote:
CBFS document is a little old since the structure of it has changed a lot specially CBFS master header. This patch updated the document to show the newest structure of CBFS.
Signed-off-by: Yang Bai hamo.by@gmail.com
Index: documentation/cbfs.txt
--- documentation/cbfs.txt (revision 6534) +++ documentation/cbfs.txt (working copy) @@ -144,10 +144,13 @@ The following is the structure of the master header:
struct cbfs_header {
unsigned int magic;unsigned int size;unsigned int align;unsigned int offset;
u32 magic;u32 version;u32 romsize;u32 bootblocksize;u32 align;u32 offset;u32 pad[2];};
Any particular reason to not use the C99 uintXX_t types in the docs?
Jonathan KollaschI don't know. The code style is a little strange. In file src/include/cbfs.h, uXX is used but in file util/cbfstool/common.h, C99 style is used.
-- """ Keep It Simple,Stupid. """
Chinese Name: 白杨 Nick Name: Hamo Homepage: http://hamobai.com/ GPG KEY ID: 0xA4691A33 Key fingerprint = 09D5 2D78 8E2B 0995 CF8E 4331 33C4 3D24 A469 1A33
-
Hamo -
Jonathan A. Kollasch