A payload can be loaded either from a vboot region or from cbfs.
Provide a common place for choosing where the payload is loaded
from. Additionally, place the logic in the 'loaders' directory
similarly to the ramstage loader infrastructure.
Change-Id: I6b0034ea5ebd04a3d058151819ac77a126a6bfe2
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5296
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
There are 2 methods currently available in coreboot to load
ramstage from romstage: cbfs and vboot. The vboot path had
to be explicitly enabled and code needed to be added to
each chipset to support both. Additionally, many of the paths
were duplicated between the two. An additional complication
is the presence of having a relocatable ramstage which creates
another path with duplication.
To rectify this situation provide a common API through the
use of a callback to load the ramstage. The rest of the
existing logic to handle all the various cases is put in
a common place.
Change-Id: I5268ce70686cc0d121161a775c3a86ea38a4d8ae
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5087
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Haswell was the original chipset to store the cache
in another area besides CBMEM. However, it was specific
to the implementation. Instead, provide a generic way
to obtain the location of the ramstage cache. This option
is selected using the CACHE_RELOCATED_RAMSTAGE_OUTSIDE_CBMEM
Kconfig option.
BUG=chrome-os-partner:23249
BRANCH=None
TEST=Built and booted with baytrail support. Also built for
falco successfully.
Change-Id: I70d0940f7a8f73640c92a75fd22588c2c234241b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/172602
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/4876
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
There are 3 places rmodule stages are loaded in the
existing code: cbfs and 2 in vboot_wrapper. Much of the
code is the same except for a few different cbmem entry
ids. Instead provide a common implementation in the
rmodule library itself.
A structure named rmod_stage_load is introduced to manage
the inputs and outputs from the new API.
BUG=chrome-os-partner:22866
BRANCH=None
TEST=Built and booted successfully.
Change-Id: I146055005557e04164e95de4aae8a2bde8713131
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174425
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4897
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
The code is wrong (it's calling ntohl on an entry point that is actually
already le due to an old cbfs bug) and nothing calls it any more anyway.
Change-Id: Ief2c33faf99e3d2fc410524a5aae7bde378f088b
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: http://review.coreboot.org/4090
Tested-by: build bot (Jenkins)
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@google.com>
If ramstage is not compressed, the CBFS module in romstage doesn't
need to support LZMA. Removing the LZMA module in this case can save
about 3000 bytes in romstage.
Change-Id: Id6f7869e32979080e2985c07029edcb39eee9106
Signed-off-by: Andrew Wu <arw@dmp.com.tw>
Reviewed-on: http://review.coreboot.org/3878
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
For reasons explained in a previous CL, it might be necessary to "load" a file
from CBFS in place. The loading code in CBFS was, however, zeroing the area of
memory the stage was about to be loaded into. When the CBFS data is located
elsewhere this works fine, but when it isn't you end up clobbering the data
you're trying to load. Also, there's no reason to zero memory we're about to
load something into or have just loaded something into. This change makes it
so that we only zero out the portion of the memory between what was
loaded/decompressed and the final size of the stage in memory.
Change-Id: If34df16bd74b2969583e11ef6a26eb4065842f57
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3579
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Instead of returning 0 on success and -1 on error, return the decompressed
size of the data on success and 0 on error. The decompressed size is useful
information to have that was being thrown away in that function.
Change-Id: If787201aa61456b1e47feaf3a0071c753fa299a3
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3578
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
There were some cbfs calls that did not get transitioned
to the new cbfs API. Fix the callsites to conform to the
actual cbfs, thus fixing the copilation errors.
Change-Id: Ia9fe2c4efa32de50982e21bd01457ac218808bd3
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2880
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This patch implements support for vboot firmware selection. The vboot
support is comprised of the following pieces:
1. vboot_loader.c - this file contains the entry point,
vboot_verify_firmware(), for romstage to call in order to perform
vboot selection. The loader sets up all the data for the wrapper
to use.
2. vboot_wrapper.c - this file contains the implementation calling the vboot
API. It calls VbInit() and VbSelectFirmware() with the data supplied
by the loader.
The vboot wrapper is compiled and linked as an rmodule and placed in
cbfs as 'fallback/vboot'. It's loaded into memory and relocated just
like the way ramstage would be. After being loaded the loader calls into
wrapper. When the wrapper sees that a given piece of firmware has been
selected it parses firmware component information for a predetermined
number of components.
Vboot result information is passed to downstream users by way of the
vboot_handoff structure. This structure lives in cbmem and contains
the shared data, selected firmware, VbInitParams, and parsed firwmare
components.
During ramstage there are only 2 changes:
1. Copy the shared vboot data from vboot_handoff to the chromeos acpi
table.
2. If a firmware selection was made in romstage the boot loader
component is used for the payload.
Noteable Information:
- no vboot path for S3.
- assumes that all RW firmware contains a book keeping header for the
components that comprise the signed firmware area.
- As sanity check there is a limit to the number of firmware components
contained in a signed firmware area. That's so that an errant value
doesn't cause the size calculation to erroneously read memory it
shouldn't.
- RO normal path isn't supported. It's assumed that firmware will always
load the verified RW on all boots but recovery.
- If vboot requests memory to be cleared it is assumed that the boot
loader will take care of that by looking at the out flags in
VbInitParams.
Built and booted. Noted firmware select worked on an image with
RW firmware support. Also checked that recovery mode worked as well
by choosing the RO path.
Change-Id: I45de725c44ee5b766f866692a20881c42ee11fa8
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2854
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Dynamic cbmem is now a requirement for relocatable ramstage.
This patch replaces the reserve_* fields in the romstage_handoff
structure by using the dynamic cbmem library.
The haswell code is not moved over in this commit, but it should be
safe because there is a hard requirement for DYNAMIC_CBMEM when using
a reloctable ramstage.
Change-Id: I59ab4552c3ae8c2c3982df458cd81a4a9b712cc2
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2849
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Instead of hard coding the policy for how a relocated ramstage
image is saved add an interface. The interface consists of two
functions. cache_loaded_ramstage() and load_cached_ramstage()
are the functions to cache and load the relocated ramstage,
respectively. There are default implementations which cache and
load the relocated ramstage just below where the ramstage runs.
Change-Id: I4346e873d8543e7eee4c1cd484847d846f297bb0
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2805
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Accessing the flash part where the ramstage resides can be slow
when loading it. In order to save time in the S3 resume path a copy
of the relocated ramstage is saved just below the location the ramstage
was loaded. Then on S3 resume the cached version of the relocated
ramstage is copied back to the loaded address.
This is achieved by saving the ramstage entry point in the
romstage_handoff structure as reserving double the amount of memory
required for ramstage. This approach saves the engineering time to make
the ramstage reentrant.
The fast path in this change will only be taken when the chipset's
romstage code properly initializes the s3_resume field in the
romstage_handoff structure. If that is never set up properly then the
fast path will never be taken.
e820 entries from Linux:
BIOS-e820: [mem 0x000000007bf21000-0x000000007bfbafff] reserved
BIOS-e820: [mem 0x000000007bfbb000-0x000000007bffffff] type 16
The type 16 is the cbmem table and the reserved section contains the two
copies of the ramstage; one has been executed already and one is
the cached relocated program.
With this change the S3 resume path on the basking ridge CRB shows
to be ~200ms to hand off to the kernel:
13 entries total:
1:95,965
2:97,191 (1,225)
3:131,755 (34,564)
4:132,890 (1,135)
8:135,165 (2,274)
9:135,840 (675)
10:135,973 (132)
30:136,016 (43)
40:136,581 (564)
50:138,280 (1,699)
60:138,381 (100)
70:204,538 (66,157)
98:204,615 (77)
Change-Id: I9c7a6d173afc758eef560e09d2aef5f90a25187a
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2800
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The romstage_handoff structure can be utilized from different components
of the romstage -- some in the chipset code, some in coreboot's core
libarary. To ensure that all users handle initialization of a newly
added romstage_handoff structure properly, provide a common function to
handle structure initialization.
Change-Id: I3998c6bb228255f4fd93d27812cf749560b06e61
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2795
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This patch adds an option to build the ramstage as a reloctable binary.
It uses the rmodule library for the relocation. The main changes
consist of the following:
1. The ramstage is loaded just under the cmbem space.
2. Payloads cannot be loaded over where ramstage is loaded. If a payload
is attempted to load where the relocatable ramstage resides the load
is aborted.
3. The memory occupied by the ramstage is reserved from the OS's usage
using the romstage_handoff structure stored in cbmem. This region is
communicated to ramstage by an CBMEM_ID_ROMSTAGE_INFO entry in cbmem.
4. There is no need to reserve cbmem space for the OS controlled memory for
the resume path because the ramsage region has been reserved in #3.
5. Since no memory needs to be preserved in the wake path, the loading
and begin of execution of a elf payload is straight forward.
Change-Id: Ia66cf1be65c29fa25ca7bd9ea6c8f11d7eee05f5
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2792
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
The cbfs stage loading routine already zeros out the full
memory region that a stage will be loaded. Therefore, it is
unnecessary to to clear the bss again after once ramstage starts.
Change-Id: Icc7021329dbf59bef948a41606f56746f21b507f
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2865
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
In certain situations boot speed can be increased by providing an
alternative implementation to cbfs_load_payload(). The
ALT_CBFS_LOAD_PAYLOAD option allows for the mainboard or chipset to
provide its own implementation.
Booted baskingridge board with alternative and regular
cbfs_load_payload().
Change-Id: I547ac9881a82bacbdb3bbdf38088dfcc22fd0c2c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2782
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Some variables are using incorrect data type in debug messages.
Also corrects a typo (extra 'x').
Change-Id: Ia3014ea018f8c1e4733c54a7d9ee196d0437cfbb
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2294
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
For ARM platform, the bootblock may need more C source files to initialize
UART / SPI for loading romstage. To preventing making complex and implicit
dependency by using #include inside bootblock.c, we should add a new build class
"bootblock".
Also #ifdef __BOOT_BLOCK__ can be used to detect if the source is being compiled
for boot block.
For x86, the bootblock is limited to fewer assembly files so it's not using this
class. (Some files shared by x86 and arm in top level or lib are also changed
but nothing should be changed in x86 build process.)
Change-Id: Ia81bccc366d2082397d133d9245f7ecb33b8bc8b
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2252
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
Summary:
Isolate CBFS underlying I/O to board/arch-specific implementations as
"media stream", to allow loading and booting romstage on non-x86.
CBFS functions now all take a new "media source" parameter; use
CBFS_DEFAULT_MEDIA if you simply want to load from main firmware.
API Changes:
cbfs_find => cbfs_get_file.
cbfs_find_file => cbfs_get_file_content.
cbfs_get_file => cbfs_get_file_content with correct type.
CBFS used to work only on memory-mapped ROM (all x86). For platforms like ARM,
the ROM may come from USB, UART, or SPI -- any serial devices and not available
for memory mapping.
To support these devices (and allowing CBFS to read from multiple source
at the same time), CBFS operations are now virtual-ized into "cbfs_media". To
simplify porting existing code, every media source must support both "reading
into pre-allocated memory (read)" and "read and return an allocated buffer
(map)". For devices without native memory-mapped ROM, "cbfs_simple_buffer*"
provides simple memory mapping simulation.
Every CBFS function now takes a cbfs_media* as parameter. CBFS_DEFAULT_MEDIA
is defined for CBFS functions to automatically initialize a per-board default
media (CBFS will internally calls init_default_cbfs_media). Also revised CBFS
function names relying on memory mapped backend (ex, "cbfs_find" => actually
loads files). Now we only have two getters:
struct cbfs_file *entry = cbfs_get_file(media, name);
void *data = cbfs_get_file_content(CBFS_DEFAULT_MEDIA, name, type);
Test results:
- Verified to work on x86/qemu.
- Compiles on ARM, and follow up commit will provide working SPI driver.
Change-Id: Iac911ded25a6f2feffbf3101a81364625bb07746
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2182
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
- Prefix all CBFS output messages with CBFS:
- Add an option DEBUG_CBFS that is off by default. Without DEBUG_CBFS
enabled, the code will no longer print all the files it walks for
every file lookup.
- Add DEBUG() macro next to LOG() and ERROR() to specify which messages
should only be visible with DEBUG_CBFS printed.
- Actually print a message when the file we're looking for was found. :)
old:
Searching for fallback/coreboot_ram
Check cmos_layout.bin
Check pci8086,0106.rom
Check fallback/romstage
Check fallback/coreboot_ram
Change-Id: I2d731fae17a5f6ca51d435cfb7a58d6e017efa24
Stage: loading fallback/coreboot_ram @ 0x100000 (540672 bytes), entry @ 0x100000
Stage: done loading.
new:
CBFS: Looking for 'fallback/coreboot_ram'
CBFS: found.
CBFS: loading stage fallback/coreboot_ram @ 0x100000 (507904 bytes), entry @ 0x100000
CBFS: stage loaded.
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/993
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
also clean out a local copy of ntohl in yabel.
Change-Id: Iffe85a53c9ea25abeb3ac663870eb7eb4874a704
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/288
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
The core is data structures and basic file finding capabilities,
while option ROM handling, and loading stages and payloads is
"extended".
The core is rewritten to be BSD-l (its header already was), so
can be copied to libpayload verbatim.
It's also more robust in finding files in corrupted images, eg.
after partial erase or update.
Change-Id: Ic6923debf8bdf3c67c75746d3b31f3addab3dd74
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/114
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
while others dislike them being extra commits, let's clean them up once and
for all for the existing code. If it's ugly, let it only be ugly once :-)
Signed-off-by: Stefan Reinauer <stepan@coresystems.de>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5507 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Signed-off-by: Stefan Reinauer <stepan@coresystems.de>
Acked-by: Ronald G. Minnich <rminnich@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5266 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
This is needed on the IP1000T to get VGA output. The VGA option rom will ask
through an SMI for hardware specifics (in form of a VBT, video bios table)
which the SMI handler copies into the VGA option rom.
Signed-off-by: Stefan Reinauer <stepan@coresystems.de>
Acked-by: Ronald G. Minnich <rminnich@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5177 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
- drop x86emu + old biosemu in favor of YABEL
- Add YABEL_DIRECTHW to get the old biosemu behavior
- add support for vesa console using YABEL
- add coreboot table entry with console information
- add bootsplash support (reads /bootsplash.jpg from CBFS)
Signed-off-by: Stefan Reinauer <stepan@coresystems.de>
Acked-by: Pattrick Hueper <phueper@hueper.net>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5135 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
looks like unmapped memory, point to the wiki page with
more information.
Signed-off-by: Patrick Georgi <patrick.georgi@coresystems.de>
Acked-by: Peter Stuge <peter@stuge.se>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4933 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Check the return value. Minor formatting and LAR -> CBFS.
Signed-off-by: Myles Watson <mylesgw@gmail.com>
Acked-by: Peter Stuge <peter@stuge.se>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4752 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
CBFS uses sprintf, which requires vtxprintf, which requires (in the
current design) a nested function. That works on x86, but on PPC this
requires a trampoline. In the ROM stage, this is not available, so
remove the single use of sprintf and replace it with a direct string
handler - it's only used to fill in fixed-length hex values.
20090819-3-more-noreturns-in-romcc:
Mark two more functions in romcc as noreturn. Helps clang's scan-build a
bit
20090819-4-cbfsify-ppc:
Make PPC use CBFS. Support big endian ELF in cbfs-mkstage. Untested and
not complete yet.
20090819-5-fix-ppc-build:
The CBFS build system requires ROM_IMAGE_SIZE to have a somewhat
plausible value.
With fixes to tohex* functions as discussed on the list, and correct
function names.
Signed-off-by: Patrick Georgi <patrick.georgi@coresystems.de>
Acked-by: Myles Watson <mylesgw@gmail.com>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4558 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
- update, add, and improve comments
- whitespace here and there
- remove unused or write-only variables
- improve debug output
- only build payload.{nrv2b,lzma} for non-cbfs
- improved error checking in cbfstool
Signed-off-by: Stefan Reinauer <stepan@coresystems.de>
Acked-by: Peter Stuge <peter@stuge.se>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4466 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
(according to the spec) to change the string in-situ,
even if glibc doesn't do it.
This avoids errors on Mac OS and Solaris.
Kill nrv2b support in CBFS (we have lzma),
slightly improve debug output in CBFS,
properly declare all functions of CBFS in the header.
Signed-off-by: Patrick Georgi <patrick.georgi@coresystems.de>
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4436 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
reduce the size of the bootblock (done for kontron/986lcd-m)
Signed-off-by: Patrick Georgi <patrick.georgi@coresystems.de>
Acked-by: Ronald G. Minnich <rminnich@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4315 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
the only selfboot user in CBFS.
This way, CBFS can be used without importing selfboot.c, as long as
no payloads are loaded.
Signed-off-by: Patrick Georgi <patrick.georgi@coresystems.de>
Acked-by: Ronald G. Minnich <rminnich@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4304 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
I didn't try to remove "defined but not used" warnings because there are too
many ifdefs to be sure I wouldn't break something.
For shadowed variable declarations I renamed the inner-most variable.
The one in src/pc80/keyboard.c might need help. I didn't change the
functionality but it looks like a bug.
I boot tested it on s2892 and abuild tested it.
Signed-off-by: Myles Watson <mylesgw@gmail.com>
Acked-by: Ronald G. Minnich <rminnich@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4240 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
its way through it, looking for magic numbers.
For one, it should speed up file access, esp. with many entries,
but it also helps against false positives (eg. seabios, which
contains the magic number for its own CBFS support, which _might_
just be aligned properly)
Also avoid infinite loops and give up searching for new files for
invalid magic numbers.
Signed-off-by: Patrick Georgi <patrick.georgi@coresystems.de>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4210 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
(and, for the record: no more #ifdef in coreboot. We're not going to
have this happen again. If we do have it in v2, let's remove it.)
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Acked-by: Myles Watson <mylesgw@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4203 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
This also has the config tool changes in v2/util.
Rename romfs.[ch]->cbfs.[ch] and sed romfs->cbfs romtool->cbfstool ROMFS->CBFS
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@4113 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Marcelo Povoa