summaryrefslogtreecommitdiff
path: root/src/vendorcode/google/chromeos/fmap.c
AgeCommit message (Collapse)Author
2015-12-17vendorcode: google: chromeos: Remove old fmap.c fileJulius Werner
This file became obsolete when FMAP code moved to src/lib/ and is no longer built by any Makefile. Let's remove it to avoid confusing people. Change-Id: I55639af28f9f3d4c4cb0429b805e3f120ecc374e Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/12753 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins)
2015-10-31tree: drop last paragraph of GPL copyright headerPatrick Georgi
It encourages users from writing to the FSF without giving an address. Linux also prefers to drop that and their checkpatch.pl (that we imported) looks out for that. This is the result of util/scripts/no-fsf-addresses.sh with no further editing. Change-Id: Ie96faea295fe001911d77dbc51e9a6789558fbd6 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/11888 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2015-05-21Remove address from GPLv2 headersPatrick Georgi
As per discussion with lawyers[tm], it's not a good idea to shorten the license header too much - not for legal reasons but because there are tools that look for them, and giving them a standard pattern simplifies things. However, we got confirmation that we don't have to update every file ever added to coreboot whenever the FSF gets a new lease, but can drop the address instead. util/kconfig is excluded because that's imported code that we may want to synchronize every now and then. $ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, *MA[, ]*02110-1301[, ]*USA:Foundation, Inc.:" {} + $ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin Street, Suite 500, Boston, MA 02110-1335, USA:Foundation, Inc.:" {} + $ find * -type f -exec sed -i "s:Foundation, Inc., 59 Temple Place[-, ]*Suite 330, Boston, MA *02111-1307[, ]*USA:Foundation, Inc.:" {} + $ find * -type f -exec sed -i "s:Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.:Foundation, Inc.:" {} + $ find * -type f -a \! -name \*.patch \ -a \! -name \*_shipped \ -a \! -name LICENSE_GPL \ -a \! -name LGPL.txt \ -a \! -name COPYING \ -a \! -name DISCLAIMER \ -exec sed -i "/Foundation, Inc./ N;s:Foundation, Inc.* USA\.* *:Foundation, Inc. :;s:Foundation, Inc. $:Foundation, Inc.:" {} + Change-Id: Icc968a5a5f3a5df8d32b940f9cdb35350654bef9 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/9233 Tested-by: build bot (Jenkins) Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
2015-04-13chromeos: Reverse FMAP signature constant to avoid having it in .rodataJulius Werner
Even though coreboot always hardcodes the FMAP offset, the same is not possible for all other tools that manipulate ROM images. Some need to manually find the FMAP by searching for it's magic number (ASCII "__FMAP__"). If we do something like 'memcmp(fmap_buffer, "__FMAP__", ...) in coreboot code, it has the unfortunate side effect that the compiler will output that very same magic number as a constant in the .rodata section to compare against. Other tools may mistake this for the "real" FMAP location and get confused. This patch reverses the constant defined in coreboot and changes the only use of it correspondingly. It is not impossible but extremely unlikely (at the current state of the art) that any compiler would be clever enough to understand this pattern and optimize it back to a straight memcmp() (GCC 4.9 definitely doesn't), so it should solve the problem at least for another few years/decades. BRANCH=veyron BUG=chromium:447051 TEST=Made sure the new binaries actually contain "__PAMF__" in their .rodata. Booted Pinky. Independently corrupted both the first and the last byte of the FMAP signature with a hex editor and confirmed that signature check fails in both cases. Change-Id: I314b5e7e4d78352f409e73a3ed0e71d1b56fe774 Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: 1359d2d4502eb34a043dffab35cf4a5b033ed65a Original-Change-Id: I725652ef2a77f7f99884b46498428c3d68cd0945 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/240723 Original-Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org> Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/9562 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-10fmap: allocate memory as much as discovered fmap sizeDaisuke Nojiri
fmap_find used to read 4096 bytes from the fmap offset blindly. instead, we read the fmap header first to calcurate the size of the fmap. Then, we read flash again exactly as much as the discovered fmap. BUG=none BRANCH=ToT TEST=Booted Storm and Peppy. Built all current boards. Change-Id: Iaa50c1bc3401c77b433af11406d4b9d2e4e722e8 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 755ff66ab0a4d05e6d5410c11a6badb9fcb77a0d Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> Original-Change-Id: Ie5058d181e6565acb70bf108464682dd0e6c1f64 Original-Reviewed-on: https://chromium-review.googlesource.com/231685 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/9556 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-10fmap: use CBFS for all other than x86 platformsVadim Bendebury
The architectiure check in fmap.c is in fact used to delineate between platforms where SPI flash is mapped to memory address space and where it needs to be accessed through CBFS. In fact cosmos board uses an ARM SOC which also maps SPI flash to processor address space, this will have to be addressed when that SOC's support is introduced, for now let's just presume that all but X86 platforms require CBFS layer to access fmap. BRANCH=none BUG=chrome-os-partner:31438 TEST=none Original-Change-Id: Id135dc63278555a7fc5039a568fb28864f7cb8d1 Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/226180 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> (cherry picked from commit b3c04f84504380066c54a6dec93781a4f25a5fc6) Signed-off-by: Aaron Durbin <adurbin@chromium.org> Change-Id: I3a0a70fe583b69b1c9cd8729817bd7062126e1a9 Reviewed-on: http://review.coreboot.org/9436 Reviewed-by: Patrick Georgi <pgeorgi@google.com> Tested-by: build bot (Jenkins)
2015-04-07cbfs: Enforce media->map() result checking, improve error messagesJulius Werner
If you try to boot a VBOOT2_VERIFY_FIRMWARE with less than 4K CBFS cache right now, your system will try and fail to validate the FMAP signature at (u8 *)0xFFFFFFFF and go into recovery mode. This patch avoids the memcmp() to potentially invalid memory, and also adds an error message to cbfs_simple_buffer_map() to make it explicit that we ran out of CBFS cache space. BUG=None TEST=Booted on Veyron_Pinky with reduced CBFS cache, saw the message. Original-Change-Id: Ic5773b4e0b36dc621513f58fc9bd29c17afbf1b7 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/222899 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> (cherry picked from commit 0ed3c0c2b63be0d32e8162faf892e41cef1f1f23) Signed-off-by: Aaron Durbin <adurbin@chromium.org> Change-Id: I20ccac83bff4a377caca6327d0e21032efff44c1 Reviewed-on: http://review.coreboot.org/9373 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-03-09Add and consistently use wrapper macro for romstage static variablesJulius Werner
x86 systems run their romstage as execute-in-place from flash, which prevents them from having writable data segments. In several code pieces that get linked into both romstage and ramstage, this has been worked around by using a local variable and having the 'static' storage class guarded by #ifndef __PRE_RAM__. However, x86 is the only architecture using execute-in-place (for now), so it does not make sense to impose the restriction globally. Rather than fixing the #ifdef at every occurrence, this should really be wrapped in a way that makes it easier to modify in a single place. The chromeos/cros_vpd.c file already had a nice approach for a wrapper macro, but unfortunately restricted it to one file... this patch moves it to stddef.h and employs it consistently throughout coreboot. BRANCH=nyan BUG=None TEST=Measured boot time on Nyan_Big before and after, confirmed that it gained 6ms from caching the FMAP in vboot_loader.c. Original-Change-Id: Ia53b94ab9c6a303b979db7ff20b79e14bc51f9f8 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/203033 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org> (cherry picked from commit c8127e4ac9811517f6147cf019ba6a948cdaa4a5) Signed-off-by: Marc Jones <marc.jones@se-eng.com> Change-Id: I44dacc10214351992b775aca52d6b776a74ee922 Reviewed-on: http://review.coreboot.org/8055 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins)
2015-01-16fmap: Fix pointer related castsFurquan Shaikh
BUG=None BRANCH=None TEST=Compiles Original-Change-Id: I3a747cb562e7390bb81eca874d6c5aaa54b81e6e Original-Signed-off-by: Furquan Shaikh <furquan@google.com> Original-Reviewed-on: https://chromium-review.googlesource.com/209337 Original-Tested-by: Furquan Shaikh <furquan@chromium.org> Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org> (cherry picked from commit 5d3aef321a9313719308909ec40fdad0ec631a9f) Signed-off-by: Marc Jones <marc.jones@se-eng.com> Change-Id: Ia8edf54f65947be12a7ae69f6825545fb2aed0f1 Reviewed-on: http://review.coreboot.org/8222 Reviewed-by: Furquan Shaikh <furquan@google.com> Tested-by: build bot (Jenkins)
2014-09-08ARM: Generalize armv7 as arm.Gabe Black
There are ARM systems which are essentially heterogeneous multicores where some cores implement a different ARM architecture version than other cores. A specific example is the tegra124 which boots on an ARMv4 coprocessor while most code, including most of the firmware, runs on the main ARMv7 core. To support SOCs like this, the plan is to generalize the ARM architecture so that all versions are available, and an SOC/CPU can then select what architecture variant should be used for each component of the firmware; bootblock, romstage, and ramstage. Old-Change-Id: I22e048c3bc72bd56371e14200942e436c1e312c2 Signed-off-by: Gabe Black <gabeblack@google.com> Reviewed-on: https://chromium-review.googlesource.com/171338 Reviewed-by: Gabe Black <gabeblack@chromium.org> Commit-Queue: Gabe Black <gabeblack@chromium.org> Tested-by: Gabe Black <gabeblack@chromium.org> (cherry picked from commit 8423a41529da0ff67fb9873be1e2beb30b09ae2d) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> ARM: Split out ARMv7 code and make it possible to have other arch versions. We don't always want to use ARMv7 code when building for ARM, so we should separate out the ARMv7 code so it can be excluded, and also make it possible to include code for some other version of the architecture instead, all per build component for cases where we need more than one architecture version at a time. The tegra124 bootblock will ultimately need to be ARMv4, but until we have some ARMv4 code to switch over to we can leave it set to ARMv7. Old-Change-Id: Ia982c91057fac9c252397b7c866224f103761cc7 Reviewed-on: https://chromium-review.googlesource.com/171400 Reviewed-by: Gabe Black <gabeblack@chromium.org> Tested-by: Gabe Black <gabeblack@chromium.org> Commit-Queue: Gabe Black <gabeblack@chromium.org> (cherry picked from commit 799514e6060aa97acdcf081b5c48f965be134483) Squashed two related patches for splitting ARM support into general ARM support and ARMv7 specific pieces. Change-Id: Ic6511507953a2223c87c55f90252c4a4e1dd6010 Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6782 Tested-by: build bot (Jenkins)
2014-08-08chromeos: Add code to read FMAP on ARMStefan Reinauer
On ARM the SPI flash is not memory mapped. Use the CBFS interface to map the correct portion. Change-Id: I8ea9aa0119e90a892bf777313fdc389c4739154e Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: https://chromium-review.googlesource.com/169781 Reviewed-by: David Hendrix <dhendrix@chromium.org> (cherry picked from commit a263d3717e82c43fe91e7c4e82d167e74bf27527) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6522 Tested-by: build bot (Jenkins) Reviewed-by: David Hendricks <dhendrix@chromium.org>
2012-11-12Avoid using hardcoded values in MRC cache codeVadim Bendebury
The MRC cache code, as implemented, in some cases uses configuration settings for MRC cache region, and in some cases - the values read from FMAP. These do not necessarily match, the code should use FMAP across the board. This change also refactors mrccache.c to limit number of iterations through the cache area and number of fmap area searches. Change-Id: Idb9cb70ead4baa3601aa244afc326d5be0d06446 Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: http://review.coreboot.org/1788 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2012-11-07SandyBridge/IvyBridge: Use flash map to find MRC cacheStefan Reinauer
Until now, the MRC cache position and size was hard coded in Kconfig. However, on ChromeOS devices, it should be determined by reading the FMAP. This patch provides a minimalistic FMAP parser (libflashmap was too complex and OS centered) to allow reading the in-ROM flash map and look for sections. This will also be needed on some partner devices where coreboot will have to find the VPD in order to set up the device's mac address correctly. The MRC cache implementation demonstrates how to use the FMAP parser. Change-Id: I34964b72587443a6ca4f27407d778af8728565f8 Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/1701 Reviewed-by: Marc Jones <marcj303@gmail.com> Tested-by: build bot (Jenkins)
generated by cgit v1.2.3 (git 2.25.1) at 2024-07-15 13:16:16 +0000