Re: [U-Boot] [PATCH 097/126] x86: Add support for newer CAR schemes
Hi Bin, On Sun, 13 Oct 2019 at 19:58, Bin Meng wrote: > > Hi Simon, > > On Sun, Oct 13, 2019 at 1:53 AM Simon Glass wrote: > > > > Hi Bin, > > > > On Fri, 11 Oct 2019 at 22:48, Bin Meng wrote: > > > > > > Hi Simon, > > > > > > On Sat, Oct 12, 2019 at 11:38 AM Simon Glass wrote: > > > > > > > > Hi Bin, > > > > > > > > On Thu, 10 Oct 2019 at 03:50, Bin Meng wrote: > > > > > > > > > > Hi Simon, > > > > > > > > > > On Wed, Sep 25, 2019 at 10:59 PM Simon Glass > > > > > wrote: > > > > > > > > > > > > Newer Intel SoCs have different ways of setting up cache-as-ram > > > > > > (CAR). > > > > > > Add support for these along with suitable configuration options. > > > > > > > > > > > > > > > > I wonder why do we need do this in U-Boot. Isn't FSP-T doing the CAR > > > > > for us? > > > > > > > > Well actually I have not tried using FSP-T yet on apollolake. I'll see > > > > how it looks. > > > > > > It looks so far only FSP-M is used on your apollolake port. > > > > > > What I'd like to see is a complete FSP 2.0 support in U-Boot, which > > > means we need FSP-T for the CAR and FSP-S for the silicon-specific > > > initialization. With FSP-S, I believe most of your platform support > > > codes in this patch series are no longer needed. > > > > I have actually got FSP-S running - see u-boot-dm/coral2-working, > > along with display, MMC, etc. There is very little init in U-Boot > > itself and my feeling is that most of the TPL/SPL init is actually > > needed. We cannot run FSP-S until the CAR is turned off, so it has to > > run in U-Boot. > > OK, so why do we want to introduce TPL on ApolloLake? I think there is > no size limitation that you can just run U-Boot directly on > ApolloLake, no? More details here: https://gitlab.denx.de/u-boot/custodians/u-boot-dm/blob/coral2-working/doc/board/google/chromebook_coral.rst In short, APL only supports booting a 30KB image to start. Then we need to load something else that can set up DRAM, which is SPL. After that we can load U-Boot. So we have to have TPL on APL (and perhaps later) CPUs. > > > > > I also just got an Up board so can give that a try one day assuming I > > have the SPI adaptor. But I think you might have some apollolake > > boards too? > > Yes, I have one of the ApolloLake CRB from Intel and planned to try at > some point but some other stuff has been occupying my time :) Sounds good! I am not sure I will be able to get FSP-T going so may ask for help on that. - Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 097/126] x86: Add support for newer CAR schemes
Hi Simon, On Sun, Oct 13, 2019 at 1:53 AM Simon Glass wrote: > > Hi Bin, > > On Fri, 11 Oct 2019 at 22:48, Bin Meng wrote: > > > > Hi Simon, > > > > On Sat, Oct 12, 2019 at 11:38 AM Simon Glass wrote: > > > > > > Hi Bin, > > > > > > On Thu, 10 Oct 2019 at 03:50, Bin Meng wrote: > > > > > > > > Hi Simon, > > > > > > > > On Wed, Sep 25, 2019 at 10:59 PM Simon Glass wrote: > > > > > > > > > > Newer Intel SoCs have different ways of setting up cache-as-ram (CAR). > > > > > Add support for these along with suitable configuration options. > > > > > > > > > > > > > I wonder why do we need do this in U-Boot. Isn't FSP-T doing the CAR > > > > for us? > > > > > > Well actually I have not tried using FSP-T yet on apollolake. I'll see > > > how it looks. > > > > It looks so far only FSP-M is used on your apollolake port. > > > > What I'd like to see is a complete FSP 2.0 support in U-Boot, which > > means we need FSP-T for the CAR and FSP-S for the silicon-specific > > initialization. With FSP-S, I believe most of your platform support > > codes in this patch series are no longer needed. > > I have actually got FSP-S running - see u-boot-dm/coral2-working, > along with display, MMC, etc. There is very little init in U-Boot > itself and my feeling is that most of the TPL/SPL init is actually > needed. We cannot run FSP-S until the CAR is turned off, so it has to > run in U-Boot. OK, so why do we want to introduce TPL on ApolloLake? I think there is no size limitation that you can just run U-Boot directly on ApolloLake, no? > > I also just got an Up board so can give that a try one day assuming I > have the SPI adaptor. But I think you might have some apollolake > boards too? Yes, I have one of the ApolloLake CRB from Intel and planned to try at some point but some other stuff has been occupying my time :) Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 097/126] x86: Add support for newer CAR schemes
Hi Bin, On Fri, 11 Oct 2019 at 22:48, Bin Meng wrote: > > Hi Simon, > > On Sat, Oct 12, 2019 at 11:38 AM Simon Glass wrote: > > > > Hi Bin, > > > > On Thu, 10 Oct 2019 at 03:50, Bin Meng wrote: > > > > > > Hi Simon, > > > > > > On Wed, Sep 25, 2019 at 10:59 PM Simon Glass wrote: > > > > > > > > Newer Intel SoCs have different ways of setting up cache-as-ram (CAR). > > > > Add support for these along with suitable configuration options. > > > > > > > > > > I wonder why do we need do this in U-Boot. Isn't FSP-T doing the CAR for > > > us? > > > > Well actually I have not tried using FSP-T yet on apollolake. I'll see > > how it looks. > > It looks so far only FSP-M is used on your apollolake port. > > What I'd like to see is a complete FSP 2.0 support in U-Boot, which > means we need FSP-T for the CAR and FSP-S for the silicon-specific > initialization. With FSP-S, I believe most of your platform support > codes in this patch series are no longer needed. I have actually got FSP-S running - see u-boot-dm/coral2-working, along with display, MMC, etc. There is very little init in U-Boot itself and my feeling is that most of the TPL/SPL init is actually needed. We cannot run FSP-S until the CAR is turned off, so it has to run in U-Boot. I also just got an Up board so can give that a try one day assuming I have the SPI adaptor. But I think you might have some apollolake boards too? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 097/126] x86: Add support for newer CAR schemes
Hi Simon, On Sat, Oct 12, 2019 at 11:38 AM Simon Glass wrote: > > Hi Bin, > > On Thu, 10 Oct 2019 at 03:50, Bin Meng wrote: > > > > Hi Simon, > > > > On Wed, Sep 25, 2019 at 10:59 PM Simon Glass wrote: > > > > > > Newer Intel SoCs have different ways of setting up cache-as-ram (CAR). > > > Add support for these along with suitable configuration options. > > > > > > > I wonder why do we need do this in U-Boot. Isn't FSP-T doing the CAR for us? > > Well actually I have not tried using FSP-T yet on apollolake. I'll see > how it looks. It looks so far only FSP-M is used on your apollolake port. What I'd like to see is a complete FSP 2.0 support in U-Boot, which means we need FSP-T for the CAR and FSP-S for the silicon-specific initialization. With FSP-S, I believe most of your platform support codes in this patch series are no longer needed. Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 097/126] x86: Add support for newer CAR schemes
Hi Bin, On Thu, 10 Oct 2019 at 03:50, Bin Meng wrote: > > Hi Simon, > > On Wed, Sep 25, 2019 at 10:59 PM Simon Glass wrote: > > > > Newer Intel SoCs have different ways of setting up cache-as-ram (CAR). > > Add support for these along with suitable configuration options. > > > > I wonder why do we need do this in U-Boot. Isn't FSP-T doing the CAR for us? Well actually I have not tried using FSP-T yet on apollolake. I'll see how it looks. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 097/126] x86: Add support for newer CAR schemes
Hi Simon, On Wed, Sep 25, 2019 at 10:59 PM Simon Glass wrote: > > Newer Intel SoCs have different ways of setting up cache-as-ram (CAR). > Add support for these along with suitable configuration options. > I wonder why do we need do this in U-Boot. Isn't FSP-T doing the CAR for us? > Signed-off-by: Simon Glass > --- > > arch/x86/Kconfig| 16 + > arch/x86/cpu/intel_common/Kconfig | 18 + > arch/x86/cpu/intel_common/Makefile | 8 + > arch/x86/cpu/intel_common/car2.S| 490 > arch/x86/cpu/intel_common/car2_uninit.S | 87 + > 5 files changed, 619 insertions(+) > create mode 100644 arch/x86/cpu/intel_common/Kconfig > create mode 100644 arch/x86/cpu/intel_common/car2.S > create mode 100644 arch/x86/cpu/intel_common/car2_uninit.S > > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig > index 556e26080de..e34c71ec4cb 100644 > --- a/arch/x86/Kconfig > +++ b/arch/x86/Kconfig > @@ -876,4 +876,20 @@ config HIGH_TABLE_SIZE > Increse it if the default size does not fit the board's needs. > This is most likely due to a large ACPI DSDT table is used. > > +config INTEL_CAR_CQOS > + bool "Support Intel Cache Quality of Service" > + help > + Cache Quality of Service allows more fine-grained control of cache > + usage. As result, it is possible to set up a portion of L2 cache for > + CAR and use the remainder for actual caching. > + > +# > +# Each bit in QOS mask controls this many bytes. This is calculated as: > +# (CACHE_WAYS / CACHE_BITS_PER_MASK) * CACHE_LINE_SIZE * CACHE_SETS > +# > +config CACHE_QOS_SIZE_PER_BIT > + hex > + depends on INTEL_CAR_CQOS > + default 0x2 # 128 KB > + > endmenu > diff --git a/arch/x86/cpu/intel_common/Kconfig > b/arch/x86/cpu/intel_common/Kconfig > new file mode 100644 > index 000..a4f46b1108b > --- /dev/null > +++ b/arch/x86/cpu/intel_common/Kconfig > @@ -0,0 +1,18 @@ > +config INTEL_PMC > + bool "Intel Power-management Controller" > + select POWER_MGR > + help > + Enable support for the common Intel power-management controller > which > + provides features including checking whether the system started from > + resume, powering off the system and enabling/disabling the reset > + mechanism. > + > +config SPL_INTEL_PMC > + bool "Intel Power-management Controller in SPL" > + default y if SPL && INTEL_PMC > + select SPL_POWER_MGR > + help > + Enable support for the common Intel power-management controller > which > + provides features including checking whether the system started from > + resume, powering off the system and enabling/disabling the reset > + mechanism. I think the above 2 should not be in this patch > diff --git a/arch/x86/cpu/intel_common/Makefile > b/arch/x86/cpu/intel_common/Makefile > index 2de567dd9fe..f620747a7d2 100644 > --- a/arch/x86/cpu/intel_common/Makefile > +++ b/arch/x86/cpu/intel_common/Makefile > @@ -8,6 +8,14 @@ obj-$(CONFIG_$(SPL_TPL_)X86_32BIT_INIT) += me_status.o > obj-$(CONFIG_$(SPL_TPL_)X86_32BIT_INIT) += report_platform.o > obj-$(CONFIG_$(SPL_TPL_)X86_32BIT_INIT) += mrc.o > endif > + > +ifdef CONFIG_FSP_VERSION2 > +obj-$(CONFIG_TPL_BUILD) += car2.o > +ifndef CONFIG_SPL_BUILD > +obj-y += car2_uninit.o > +endif > +endif > + > obj-y += cpu.o > obj-$(CONFIG_SPI_FLASH_INTEL_FAST) += fast_spi.o > obj-y += lpc.o > diff --git a/arch/x86/cpu/intel_common/car2.S > b/arch/x86/cpu/intel_common/car2.S > new file mode 100644 > index 000..ac07fe5ea6a > --- /dev/null > +++ b/arch/x86/cpu/intel_common/car2.S > @@ -0,0 +1,490 @@ > +/* SPDX-License-Identifier: GPL-2.0+ */ > +/* > + * This file is part of the coreboot project. > + * > + * Copyright (C) 2015-2016 Intel Corp. > + * > + * 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; version 2 of the License. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + * nits: there is already SPDX license > + */ > + > +#include > +#include > +#include > +#include > +#include > + > +#define KiB 1024 > + > +.global car_init > +car_init: > + post_code(0x20) > + > + /* > +* Use the MTRR default type MSR as a proxy for detecting INIT#. > +* Reset the system if any known bits are set in that MSR. That is > +* an indication of the CPU not being properly reset. > +*/ > +check_for_clean_reset: > + mov $MTRR_DEF_TYPE_MSR, %ecx > + rdmsr > + and $(MTRR_DEF_TYPE_EN | MTRR_DEF_TYPE_FIX_EN), %eax > + cmp $0, %eax > + jz
[U-Boot] [PATCH 097/126] x86: Add support for newer CAR schemes
Newer Intel SoCs have different ways of setting up cache-as-ram (CAR). Add support for these along with suitable configuration options. Signed-off-by: Simon Glass --- arch/x86/Kconfig| 16 + arch/x86/cpu/intel_common/Kconfig | 18 + arch/x86/cpu/intel_common/Makefile | 8 + arch/x86/cpu/intel_common/car2.S| 490 arch/x86/cpu/intel_common/car2_uninit.S | 87 + 5 files changed, 619 insertions(+) create mode 100644 arch/x86/cpu/intel_common/Kconfig create mode 100644 arch/x86/cpu/intel_common/car2.S create mode 100644 arch/x86/cpu/intel_common/car2_uninit.S diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 556e26080de..e34c71ec4cb 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -876,4 +876,20 @@ config HIGH_TABLE_SIZE Increse it if the default size does not fit the board's needs. This is most likely due to a large ACPI DSDT table is used. +config INTEL_CAR_CQOS + bool "Support Intel Cache Quality of Service" + help + Cache Quality of Service allows more fine-grained control of cache + usage. As result, it is possible to set up a portion of L2 cache for + CAR and use the remainder for actual caching. + +# +# Each bit in QOS mask controls this many bytes. This is calculated as: +# (CACHE_WAYS / CACHE_BITS_PER_MASK) * CACHE_LINE_SIZE * CACHE_SETS +# +config CACHE_QOS_SIZE_PER_BIT + hex + depends on INTEL_CAR_CQOS + default 0x2 # 128 KB + endmenu diff --git a/arch/x86/cpu/intel_common/Kconfig b/arch/x86/cpu/intel_common/Kconfig new file mode 100644 index 000..a4f46b1108b --- /dev/null +++ b/arch/x86/cpu/intel_common/Kconfig @@ -0,0 +1,18 @@ +config INTEL_PMC + bool "Intel Power-management Controller" + select POWER_MGR + help + Enable support for the common Intel power-management controller which + provides features including checking whether the system started from + resume, powering off the system and enabling/disabling the reset + mechanism. + +config SPL_INTEL_PMC + bool "Intel Power-management Controller in SPL" + default y if SPL && INTEL_PMC + select SPL_POWER_MGR + help + Enable support for the common Intel power-management controller which + provides features including checking whether the system started from + resume, powering off the system and enabling/disabling the reset + mechanism. diff --git a/arch/x86/cpu/intel_common/Makefile b/arch/x86/cpu/intel_common/Makefile index 2de567dd9fe..f620747a7d2 100644 --- a/arch/x86/cpu/intel_common/Makefile +++ b/arch/x86/cpu/intel_common/Makefile @@ -8,6 +8,14 @@ obj-$(CONFIG_$(SPL_TPL_)X86_32BIT_INIT) += me_status.o obj-$(CONFIG_$(SPL_TPL_)X86_32BIT_INIT) += report_platform.o obj-$(CONFIG_$(SPL_TPL_)X86_32BIT_INIT) += mrc.o endif + +ifdef CONFIG_FSP_VERSION2 +obj-$(CONFIG_TPL_BUILD) += car2.o +ifndef CONFIG_SPL_BUILD +obj-y += car2_uninit.o +endif +endif + obj-y += cpu.o obj-$(CONFIG_SPI_FLASH_INTEL_FAST) += fast_spi.o obj-y += lpc.o diff --git a/arch/x86/cpu/intel_common/car2.S b/arch/x86/cpu/intel_common/car2.S new file mode 100644 index 000..ac07fe5ea6a --- /dev/null +++ b/arch/x86/cpu/intel_common/car2.S @@ -0,0 +1,490 @@ +/* SPDX-License-Identifier: GPL-2.0+ */ +/* + * This file is part of the coreboot project. + * + * Copyright (C) 2015-2016 Intel Corp. + * + * 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; version 2 of the License. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + */ + +#include +#include +#include +#include +#include + +#define KiB 1024 + +.global car_init +car_init: + post_code(0x20) + + /* +* Use the MTRR default type MSR as a proxy for detecting INIT#. +* Reset the system if any known bits are set in that MSR. That is +* an indication of the CPU not being properly reset. +*/ +check_for_clean_reset: + mov $MTRR_DEF_TYPE_MSR, %ecx + rdmsr + and $(MTRR_DEF_TYPE_EN | MTRR_DEF_TYPE_FIX_EN), %eax + cmp $0, %eax + jz no_reset + /* perform warm reset */ + movw$0xcf9, %dx + movb$0x06, %al + outb%al, %dx + +no_reset: + post_code(0x21) + + /* Clear/disable fixed MTRRs */ + mov $fixed_mtrr_list_size, %ebx + xor %eax, %eax + xor %edx, %edx + +clear_fixed_mtrr: + add $-2, %ebx + movzwl fixed_mtrr_list(%ebx), %ecx + wrmsr + jnz clear_fixed_mtrr + + post_code(0x22) + + /* Figure put how many MTRRs
