aboutsummaryrefslogtreecommitdiff
path: root/src/northbridge/intel/sandybridge/mrccache.c
AgeCommit message (Collapse)Author
2013-06-20sandybridge: Store MRC cache in CBFSPatrick Georgi
Location is hard-coded right now, which isn't optimal. It must be chip erase block aligned, which might fail on some flash chips (it's 64k aligned which should work for most cases). Change-Id: I6fe0607948c5fab04b9ed565a93e00b96bf44986 Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/3497 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2013-05-01boot: remove cbmem_post_handling()Aaron Durbin
The cbmem_post_handling() function was implemented by 2 chipsets in order to save memory configuration in flash. Convert both of these chipsets to use the boot state machine callbacks to perform the saving of the memory configuration. Change-Id: I697e5c946281b85a71d8533437802d7913135af3 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3137 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-01GPLv2 notice: Unify all files to just use one space in »MA 02110-1301«Paul Menzel
In the file `COPYING` in the coreboot repository and upstream [1] just one space is used. The following command was used to convert all files. $ git grep -l 'MA 02' | xargs sed -i 's/MA 02/MA 02/' [1] http://www.gnu.org/licenses/gpl-2.0.txt Change-Id: Ic956dab2820a9e2ccb7841cab66966ba168f305f Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-on: http://review.coreboot.org/2490 Tested-by: build bot (Jenkins) Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
2013-02-11spi.h: Rename the spi.h to spi-generic.hZheng Bao
Since there are and will be other files in nb/sb folders, we change the general spi.h to a file name which is not easy to be duplicated. Change-Id: I6548a81206caa608369be044747bde31e2b08d1a Signed-off-by: Zheng Bao <zheng.bao@amd.com> Signed-off-by: zbao <fishbaozi@gmail.com> Reviewed-on: http://review.coreboot.org/2309 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
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)
2012-07-24Fix MRC cache update delaysStefan Reinauer
When no valid MRC cache area is found, the mrc_cache data structure was used without prior initialization. This sometimes caused a long delay when booting because compute_ip_checksum would checksum up to 4GB of memory. Change-Id: I6a0ca1aa618838bbc3d042be425700fc34b427f2 Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/1277 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2012-05-29Sandybridge: Remove remnants of FDT support from MRC cache codeStefan Reinauer
Originally, ChromeBooks would get the offset of the MRC cache from an entry in the u-boot device tree. Not everyone wants to use u-boot on Sandybridge systems, however. Since the new code (based on Kconfig) is now fully working, we can drop the u-boot device tree remnants. Change-Id: I4e012ea981f16dce9a4d155254facd29874b28ef Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/1051 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2012-05-29Sandybridge: Fix MRC cache calculationStefan Reinauer
The MRC region is described by Kconfig variables, no further math or parsing is required at this point. Change-Id: I290d8788b69ef007e9ea2317ce55aefa2d791883 Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/1046 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2012-05-11Rework Sandybridge MRC cache handlingStefan Reinauer
- Separate Sandybridge from ChromeOS a bit The Sandybridge code depends on chromeos features a whole lot. As a first step, provide a code path to look up the MRC cache without depending on u-boot. - Move mrc cache handling to separate file This enables us to handle the MRC cache from ramstage, where we can write the flash safely (eg. to update the cache). Also teach it to lookup the current MRC cache from CBMEM, as the original data block isn't available anymore. After all the preparations, finally write to the SPI as necessary. It's a simple round robin wear levelling that erases the entire MRC cache region when it's full and starts from the beginning. Change-Id: I4751385574cf709b03d5c9d153b7481ffc90ce12 Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-on: http://review.coreboot.org/1001 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>