Go to file
Ronald G. Minnich 6ce41c06cc This is transition code for cbfs to implement
cbfs files at fixed addresses.

I call this transitional as the approach I am taking is to add
capability to cbfstool but not change code in a way that will break
existing usages. Later, once we're sure nothing has broken, we can start to 
smooth the edges. 

Right now, fixed address file are only supported via the add command. 

There is one additional command syntax, so, example:
cbfstool add rom romstrap optionrom 0xffffd000

Will add the file to that fix location for a romstrap.

The assumption is that the ROM is based at the end of a 32-bit address
space. As you can see from the code, that assumption can easily be
over-ridden, if we ever need to, with a command option.

Here is one example output result.

rminnich@xcpu2:~/src/bios/coreboot-v2/util/cbfstool$ ./cbfstool x.cbf print
x.cbf: 1024 kB, bootblocksize 32768, romsize 1048576, offset 0x0
Alignment: 16 bytes

Name                           Offset     Type         Size
h                              0x0        optionrom   251
                             0x130      free         917120
h3                             0xdffe0    optionrom    251
                             0xe0110    free         97960

The way this is implemented is pretty simple. I introduce a new
operator, split, that splits an unallocated area into two unallocated
areas. Then, allocation merely becomes a matter of 0, 1, or 2 splits:
0 split -- the free area is the exact fit
1 splits -- need to split some off the front or back
2 splits -- need to split off BOTH the front and back

I think you'll be able to see what I've done. I call this transitional
because, in the end state, we only need one allocate function; for now
I've left two in, to make sure I don't break compatibilty.

Why I like this better than ldscript approach: I like having the
ROMSTRAP located by cbfs, not linker scripts. For one thing, it makes
romstrap visible as a first class object. I think I would have latched
onto a problem I was having much more quickly had I remembered the
ROMSTRAP. It gets lost in the linker scripts.

At this point, we should be able to start removing special ROMSTRAP location 
code from linker scripts. 

Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Acked-by: Patrick Georgi <patrick.georgi@coresystems.de>


git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4351 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2009-06-08 03:33:57 +00:00
documentation There's no 'svg2pdf' in Debian AFAICT, probably the same problem on 2009-05-12 14:24:25 +00:00
payloads Tell lpgcc about the target architecture directory. This slipped through since 2009-05-26 18:01:53 +00:00
src A bunch of additional EPIA-M700 cleanups and also some non-cosmetic changes: 2009-06-07 14:38:32 +00:00
targets Change the CBFS build process to use coreboot.rom 2009-06-06 07:19:53 +00:00
util This is transition code for cbfs to implement 2009-06-08 03:33:57 +00:00
COPYING
NEWS
README Improvements for the coreboot v2 README: 2009-04-17 17:11:39 +00:00

README

-------------------------------------------------------------------------------
coreboot README
-------------------------------------------------------------------------------

coreboot is a Free Software project aimed at replacing the proprietary
BIOS you can find in most of today's computers.

It performs just a little bit of hardware initialization and then executes
one of many possible payloads, e.g. a Linux kernel or a bootloader.


Payloads
--------

After the basic initialization of the hardware has been performed, any
desired "payload" can be started by coreboot.

See http://www.coreboot.org/Payloads for a list of supported payloads.


Supported Hardware
------------------

coreboot supports a wide range of chipsets, devices, and mainboards.

For details please consult:

 * http://www.coreboot.org/Supported_Motherboards
 * http://www.coreboot.org/Supported_Chipsets_and_Devices


Build Requirements
------------------

 * gcc / g++
 * make
 * python
 * perl

Optional:

 * doxygen (for generating/viewing documentation)
 * iasl (for targets with ACPI support)
 * gdb (for better debugging facilities on some targets)


Building coreboot
-----------------

Please consult http://www.coreboot.org/Documentation for details.


Testing coreboot Without Modifying Your Hardware
-------------------------------------------------

If you want to test coreboot without any risks before you really decide
to use it on your hardware, you can use the QEMU system emulator to run
coreboot virtually in QEMU.

Please see http://www.coreboot.org/QEMU for details.


Website and Mailing List
------------------------

Further details on the project, a FAQ, many HOWTOs, news, development
guidelines and more can be found on the coreboot website:

  http://www.coreboot.org

You can contact us directly on the coreboot mailing list:

  http://www.coreboot.org/Mailinglist


Copyright and License
---------------------

The copyright on coreboot is owned by quite a large number of individual
developers and companies. Please check the individual source files for details.

coreboot is licensed under the terms of the GNU General Public License (GPL).
Some files are licensed under the "GPL (version 2, or any later version)",
and some files (mostly those derived from the Linux kernel) are licensed under
the "GPL, version 2". For some parts, which were derived from other projects,
other (GPL-compatible) licenses may apply. Please check the individual
source files for details.

This makes the resulting coreboot images licensed under the GPL, version 2.