GNUBoot/coreboot-kgpe-d16
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity
coreboot-kgpe-d16/src/soc/intel/apollolake/car.c

37 lines
964 B
C
Raw Normal View History

soc/intel/apollolake: use CAR code coherency for all CAR stages The flush L1D to L2 operation was only being used when loading romstage from bootblock. However, when the FSP-M component is loaded no code coherency actions are taken. I suspect this is because the FSP-M component is larger than the 24KiB L1D and the entry point is early in the image. Thus, when loading the FSP-M component the earlier part of the image is flushed out to L2 in the process of loading the latter part of the component. Also, once verstage is introduced the same code coherency actions need to be taken as well. Therefore, position the apollolake code to handle all these cases. Change-Id: Ie71764f1b420a6072c4f149ad3e37278b6cb70e1 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/14210 Tested-by: build bot (Jenkins) Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
2016-03-31 18:38:13 +02:00
/*
* This file is part of the coreboot project.
*
* Copyright (C) 2016 Intel Corp.
* Copyright 2016 Google Inc.
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*/
#include <arch/cpu.h>
#include <program_loading.h>
#include <soc/cpu.h>
/*
* This file supports the necessary hoops one needs to jump through since
* early FSP component and early stages are running from cache-as-ram.
*/
static void flush_l1d_to_l2(void)
{
msr_t msr = rdmsr(MSR_POWER_MISC);
msr.lo |= (1 << 8);
wrmsr(MSR_POWER_MISC, msr);
}
soc/intel/apollolake: use platform_segment_loaded() for CAR coherency Instead of using arch_segment_loaded() implement platform_segment_loaded() so as not to tangle the notion of arch and the chipset. Lastly, add a TODO to allow filtering of the L1D to L2 flush depending on the region loaded. Change-Id: I52e7cd2ae6e2d95f21bdd2fe1a471a10565309cb Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/14215 Reviewed-by: Furquan Shaikh <furquan@google.com> Tested-by: build bot (Jenkins) Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
2016-03-31 21:00:47 +02:00
void platform_segment_loaded(uintptr_t start, size_t size, int flags)
soc/intel/apollolake: use CAR code coherency for all CAR stages The flush L1D to L2 operation was only being used when loading romstage from bootblock. However, when the FSP-M component is loaded no code coherency actions are taken. I suspect this is because the FSP-M component is larger than the 24KiB L1D and the entry point is early in the image. Thus, when loading the FSP-M component the earlier part of the image is flushed out to L2 in the process of loading the latter part of the component. Also, once verstage is introduced the same code coherency actions need to be taken as well. Therefore, position the apollolake code to handle all these cases. Change-Id: Ie71764f1b420a6072c4f149ad3e37278b6cb70e1 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/14210 Tested-by: build bot (Jenkins) Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
2016-03-31 18:38:13 +02:00
{
soc/intel/apollolake: use platform_segment_loaded() for CAR coherency Instead of using arch_segment_loaded() implement platform_segment_loaded() so as not to tangle the notion of arch and the chipset. Lastly, add a TODO to allow filtering of the L1D to L2 flush depending on the region loaded. Change-Id: I52e7cd2ae6e2d95f21bdd2fe1a471a10565309cb Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/14215 Reviewed-by: Furquan Shaikh <furquan@google.com> Tested-by: build bot (Jenkins) Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
2016-03-31 21:00:47 +02:00
/* TODO: filter on address to see if L1D flushing required. */
soc/intel/apollolake: use arch_segment_loaded() for CAR code coherency Instead of using platform_prog_run() for flushing programs from L1D to L2 for code coherency purposes use arch_segment_loaded() instead as that it's primary purpose. The arch_segment_loaded() is called within the infrastructure at the appropriate places when loading programs. Therefore use that to perform the L1D flush instead of when something is just about to run. Change-Id: Ib0a6be6f676dcf2c946ef5702471af65d89133e9 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/14212 Reviewed-by: Furquan Shaikh <furquan@google.com> Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
2016-03-31 20:26:46 +02:00
/* Flush L1D cache to L2 on final segment loaded */
if (flags & SEG_FINAL)
flush_l1d_to_l2();
soc/intel/apollolake: use CAR code coherency for all CAR stages The flush L1D to L2 operation was only being used when loading romstage from bootblock. However, when the FSP-M component is loaded no code coherency actions are taken. I suspect this is because the FSP-M component is larger than the 24KiB L1D and the entry point is early in the image. Thus, when loading the FSP-M component the earlier part of the image is flushed out to L2 in the process of loading the latter part of the component. Also, once verstage is introduced the same code coherency actions need to be taken as well. Therefore, position the apollolake code to handle all these cases. Change-Id: Ie71764f1b420a6072c4f149ad3e37278b6cb70e1 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/14210 Tested-by: build bot (Jenkins) Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
2016-03-31 18:38:13 +02:00
}
Reference in a new issue Copy permalink