This patch changes the ram_media CBFS backend implementation to no longer detect an absolute address that is inside the "memory region" used to back the CBFS image (which on x86 is really just the memory-mapped flash due to a depthcharge implementation detail). This was (as far as I know only) used to support the ugly CBFS header pointer situation with SeaBIOS, which is now resolved. It is a very dangerous feature, since it's perfectly possible for a negative offset relative to the end of the image to overlap that region. We only get lucky that in our existing use cases the embedded CBFS is further away from the end of the ROM than it's own size... if we instead had a 3MB image from 0xfffd0000 to 0xffff0000, then we might want to pass in an address like 0xfffe8000 (interpreted as a relative offset from the end) to refer to the absolute address 0xfffd8000, but this feature would prevent that since it fits inside the window when interpreted absolutely. (Also, it is unlikely but possible that a non-memory-mapped architecture which starts DRAM at 0x0 may put its bounce buffer within the first few megabyte of the address space, so that a relative offset from the start of the image could be interpreted as an absolute offset inside the buffer. CQ-DEPEND=CL:229962 BRANCH=None BUG=None TEST=Built and booted on Falco and Nyan_Blaze, confirmed that legacy mode still works as well as before. Change-Id: I0c9149d725adeecef2520342b307ce7ea52990c1 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/229976 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Stefan Reinauer <reinauer@chromium.org> |
||
|---|---|---|
| .. | ||
| arch | ||
| bin | ||
| configs | ||
| crypto | ||
| curses | ||
| drivers | ||
| gdb | ||
| include | ||
| libc | ||
| libcbfs | ||
| liblzma | ||
| libpci | ||
| sample | ||
| tests | ||
| util | ||
| Config.in | ||
| Doxyfile | ||
| LICENSE_GPL | ||
| LICENSES | ||
| Makefile | ||
| Makefile.inc | ||
| README | ||
-------------------------------------------------------------------------------
libpayload README
-------------------------------------------------------------------------------
libpayload is a minimal library to support standalone payloads
that can be booted with firmware like coreboot. It handles the setup
code, and provides common C library symbols such as malloc() and printf().
Note: This is _not_ a standard library for use with an operating system,
rather it's only useful for coreboot payload development!
See http://coreboot.org for details on coreboot.
Installation
------------
$ git clone http://review.coreboot.org/p/coreboot.git
$ cd coreboot/payloads/libpayload
$ make menuconfig
$ make
$ sudo make install (optional, will install into /opt per default)
As libpayload is for 32bit x86 systems only, you might have to install the
32bit libgcc version, otherwise your payloads will fail to compile.
On Debian systems you'd do 'apt-get install gcc-multilib' for example.
Usage
-----
Here's an example of a very simple payload (hello.c) and how to build it:
#include <libpayload.h>
int main(void)
{
printf("Hello, world!\n");
return 0;
}
Building the payload using the 'lpgcc' compiler wrapper:
$ lpgcc -o hello.elf hello.c
Please see the sample/ directory for details.
Website and Mailing List
------------------------
The main website is http://www.coreboot.org/Libpayload.
For additional information, patches, and discussions, please join the
coreboot mailing list at http://coreboot.org/Mailinglist, where most
libpayload developers are subscribed.
Copyright and License
---------------------
See LICENSES.