coreboot-kgpe-d16/util/cbfstool/cbfs.h

140 lines
4.0 KiB
C
Raw Normal View History

/*
* cbfstool
*
* Copyright (C) 2008 Jordan Crouse <jordan@cosmicpenguin.net>
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; version 2 of the License.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA, 02110-1301 USA
*/
#ifndef _CBFS_H_
#define _CBFS_H_
/** These are standard values for the known compression
alogrithms that coreboot knows about for stages and
payloads. Of course, other LAR users can use whatever
values they want, as long as they understand them. */
#define CBFS_COMPRESS_NONE 0
#define CBFS_COMPRESS_LZMA 1
#define CBFS_COMPRESS_NRV2B 2
/** These are standard component types for well known
components (i.e - those that coreboot needs to consume.
Users are welcome to use any other value for their
components */
#define CBFS_COMPONENT_STAGE 0x10
#define CBFS_COMPONENT_PAYLOAD 0x20
#define CBFS_COMPONENT_OPTIONROM 0x30
I have made a very simple mod to cbfstool that is compatible with the src/lib/ code in coreboot. I.e. the tool changes but the coreboot code does not. Currently, as cbfstool manages the ROM, there are files and empty space. To allocate files, the code does, first, a walk of the headers and, if that fails, does a brute-force search of the rest of the space. We all agree that the brute-force search has lots of problems from a performance and correctness standpoint. I've made a slight change. Instead of an "empty space" area with no valid headers, I've made a header for the empty space. So cbfs creation looks like this: - set up the boot block - create a file, of type CBFS_COMPONENT_NULL, that contains the empty space. CBFS_COMPONENT_NULL was already defined in cbfs.h Here's an example: [rminnich@xcpu2 cbfstool]$ ./cbfstool testcbfs create 1048576 2048 (cbfstool) E: Unable to open (null): Bad address [rminnich@xcpu2 cbfstool]$ ./cbfstool testcbfs print testcbfs: 1024 kB, bootblocksize 2048, romsize 1048576, offset 0x0 Alignment: 16 bytes Name Offset Type Size 0x0 0xffffffff 1046456 So how do we create a new file? It's easy: walk the files and find a file of type CBFS_COMPONENT_NULL, which is as large or larger than the file you are trying to create. Then you use that file. - if the file is the same size as the NULL file, then it's easy: take it - if the file is smaller than the NULL file, you split the NULL file into two parts. note that this works in the base case: the base case is that the whole storage is CBFS_COMPONENT_NULL. Here's an example of adding a file. [rminnich@xcpu2 cbfstool]$ ./cbfstool testcbfs add-stage testfixed t [rminnich@xcpu2 cbfstool]$ ./cbfstool testcbfs print testcbfs: 1024 kB, bootblocksize 2048, romsize 1048576, offset 0x0 Alignment: 16 bytes Name Offset Type Size t 0x0 stage 23176 0x5ab0 0xffffffff 1023240 Note that the NULL split and got smaller. But the entire ROM is still contained by the two files. To walk this entire rom will require two FLASH accesses. Add another file: [rminnich@xcpu2 cbfstool]$ ./cbfstool testcbfs add-stage testfixed tt [rminnich@xcpu2 cbfstool]$ ./cbfstool testcbfs print testcbfs: 1024 kB, bootblocksize 2048, romsize 1048576, offset 0x0 Alignment: 16 bytes Name Offset Type Size t 0x0 stage 23176 tt 0x5ab0 stage 23176 0xb560 0xffffffff 1000024 [rminnich@xcpu2 cbfstool]$ So, taking current ROMs as an example, I can reduce FLASH accesses for cbfs from (potentially) thousands to (typically) less than 10. Index: fs.c Changes for readability and cleanliness. Move common blobs of code to functions. New function: rom_alloc,which allocates files by finding NULL files and using/splitting. Other changes as needed to support this usage. Index: util.c Creating a cbfs archive now requires creation of a NULL file covering the file system space. Index: cbfs.h Add a DELETED file type with value 0. Any file can be marked deleted by zero its type; this is a FLASH-friendly definition for all known FLASH types. Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> I think it is a step in the right direction. Could you add the function prototype to cbfstool.h? Acked-by: Myles Watson <mylesgw@gmail.com> (I added the prototype) git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4261 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2009-05-08 21:23:00 +02:00
/* The deleted type is chosen to be a value
* that can be written in a FLASH from all other
* values.
*/
#define CBFS_COMPONENT_DELETED 0
/* for all known FLASH, this value can be changed
* to all other values. This allows NULL files to be
* changed without a block erase
*/
#define CBFS_COMPONENT_NULL 0xFFFFFFFF
/** this is the master cbfs header - it need to be
located somewhere in the bootblock. Where it
actually lives is up to coreboot. A pointer to
this header will live at 0xFFFFFFF4, so we can
easily find it. */
#define HEADER_MAGIC 0x4F524243
/* this is a version that gives the right answer in any endian-ness */
#define VERSION1 0x31313131
struct cbfs_header {
unsigned int magic;
unsigned int version;
unsigned int romsize;
unsigned int bootblocksize;
unsigned int align;
unsigned int offset;
unsigned int pad[2];
} __attribute__ ((packed));
/** This is a component header - every entry in the CBFS
will have this header.
This is how the component is arranged in the ROM:
-------------- <- 0
component header
-------------- <- sizeof(struct component)
component name
-------------- <- offset
data
...
-------------- <- offset + len
*/
#define COMPONENT_MAGIC "LARCHIVE"
struct cbfs_file {
char magic[8];
unsigned int len;
unsigned int type;
unsigned int checksum;
unsigned int offset;
} __attribute__ ((packed));
/*** Component sub-headers ***/
/* Following are component sub-headers for the "standard"
component types */
/** This is the sub-header for stage components. Stages are
loaded by coreboot during the normal boot process */
struct cbfs_stage {
unsigned int compression; /** Compression type */
unsigned long long entry; /** entry point */
unsigned long long load; /** Where to load in memory */
unsigned int len; /** length of data to load */
unsigned int memlen; /** total length of object in memory */
} __attribute__ ((packed));
/** this is the sub-header for payload components. Payloads
are loaded by coreboot at the end of the boot process */
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;
} __attribute__ ((packed));
struct cbfs_payload {
struct cbfs_payload_segment segments;
};
#define PAYLOAD_SEGMENT_CODE 0x45444F43
#define PAYLOAD_SEGMENT_DATA 0x41544144
#define PAYLOAD_SEGMENT_BSS 0x20535342
#define PAYLOAD_SEGMENT_PARAMS 0x41524150
#define PAYLOAD_SEGMENT_ENTRY 0x52544E45
#define CBFS_NAME(_c) (((unsigned char *) (_c)) + sizeof(struct cbfs_file))
#endif