| Message ID | 1464816714-3900-1-git-send-email-nm@ti.com |
|---|---|
| State | New |
| Headers | show |
On Wednesday, June 1, 2016 4:31:54 PM CEST Nishanth Menon wrote: > Introduce ARCH_KEYSTONE_TYPICAL which is common for all Keystone > platforms. This is particularly useful when custom optimized defconfig > builds are created for Keystone architecture platforms. > > An example of the same would be a sample fragment ks_only.cfg: > http://pastebin.ubuntu.com/16904991/ - This prunes all arch other than > keystone and any options the other architectures may enable. > > git clean -fdx && git reset --hard && \ > ./scripts/kconfig/merge_config.sh -m \ > ./arch/arm/configs/multi_v7_defconfig ~/tmp/ks_only.cfg &&\ > make olddefconfig > > The above unfortunately will disable options necessary for KS2 boards > to boot to the bare minimum initramfs. > > Hence the "KEYSTONE_TYPICAL" option is designed similar to commit 8d9166b519fd > ("omap2/3/4: Add Kconfig option to compile in typical omap features") > that can be enabled for most boards keystone platforms > without needing to rediscover these in defconfig all over again - > examples include multi_v7_defconfig base and optimizations done on top > of them for keystone platform. I'd rather remove the option for OMAP as well, it doesn't really fit in with how we do things for other platforms, and selecting a lot of other Kconfig symbols tends to cause circular dependencies. > > NOTE: the alternative is to select the configurations under > ARCH_KEYSTONE. However, that would fail multi_v7 builds on ARM > variants that dont work with LPAE. Please no arbitrary selects from the platform. > Cc: Bill Mills <wmills@ti.com> > Cc: Murali Karicheri <m-karicheri2@ti.com> > Cc: Grygorii Strashko <grygorii.strashko@ti.com> > Cc: Tero Kristo <t-kristo@ti.com> > Cc: Lokesh Vutla <lokeshvutla@ti.com> > Signed-off-by: Nishanth Menon <nm@ti.com> > --- > > Based on: next-20160601 > > Tested for basic initramfs boot for K2HK/K2G platforms with the > http://pastebin.ubuntu.com/16904991/ fragment + multi_v7_defconfig > > Side note on LPAE: > For our current device tree and u-boot, LPAE is mandatory to bootup > for current Keystone boards - but this is not a SoC requirement, > booting without LPAE/HIGHMEM results in non-coherent DDR accesses. This sounds like a regression, I thought we had this working when keystone was initially merged and we got both the coherent and non-coherent mode working with the same DT. > Currently: > - U-Boot assumes that lpae is always enabled in kennel and updates the > DT memory node with higher addresses. Because of which you are not > detecting any memory without lpae and kernel crashed very early, hence > no prints. So, make mem_lpae env setting as 0 in U-boot. We could work around this in the kernel by detecting the faulty u-boot behavior and fixing up the addresses in an early platform callback. > - DT also assumes that lpae is always enabled, and always asks for > dma-address translation for higher addresses to lower addresses. > Just delete the "dma-ranges" property or create a one-on-one mapping > like dma-ranges = <0x80000000 0x0 0x80000000 0x80000000> This may be a bit trickier, I think originally keystone ignored the dma-ranges property and hacked up its own offset by adding a magic constant to the dma address using a bus notifier. We probably don't want to bring that hack back, but maybe we can come up with another solution. Arnd
On 06/01/2016 05:31 PM, Arnd Bergmann wrote: > On Wednesday, June 1, 2016 4:31:54 PM CEST Nishanth Menon wrote: >> Introduce ARCH_KEYSTONE_TYPICAL which is common for all Keystone >> platforms. This is particularly useful when custom optimized defconfig >> builds are created for Keystone architecture platforms. >> >> An example of the same would be a sample fragment ks_only.cfg: >> http://pastebin.ubuntu.com/16904991/ - This prunes all arch other than >> keystone and any options the other architectures may enable. >> >> git clean -fdx && git reset --hard && \ >> ./scripts/kconfig/merge_config.sh -m \ >> ./arch/arm/configs/multi_v7_defconfig ~/tmp/ks_only.cfg &&\ >> make olddefconfig >> >> The above unfortunately will disable options necessary for KS2 boards >> to boot to the bare minimum initramfs. >> >> Hence the "KEYSTONE_TYPICAL" option is designed similar to commit 8d9166b519fd >> ("omap2/3/4: Add Kconfig option to compile in typical omap features") >> that can be enabled for most boards keystone platforms >> without needing to rediscover these in defconfig all over again - >> examples include multi_v7_defconfig base and optimizations done on top >> of them for keystone platform. > > I'd rather remove the option for OMAP as well, it doesn't really fit in with > how we do things for other platforms, and selecting a lot of other Kconfig > symbols tends to cause circular dependencies. Hmm, fair enough -> adding Tony as well if he sees an problem with dropping ARCH_OMAP2PLUS_TYPICAL. > >> >> NOTE: the alternative is to select the configurations under >> ARCH_KEYSTONE. However, that would fail multi_v7 builds on ARM >> variants that dont work with LPAE. > > Please no arbitrary selects from the platform. > Agreed. >> Cc: Bill Mills <wmills@ti.com> >> Cc: Murali Karicheri <m-karicheri2@ti.com> >> Cc: Grygorii Strashko <grygorii.strashko@ti.com> >> Cc: Tero Kristo <t-kristo@ti.com> >> Cc: Lokesh Vutla <lokeshvutla@ti.com> >> Signed-off-by: Nishanth Menon <nm@ti.com> >> --- >> >> Based on: next-20160601 >> >> Tested for basic initramfs boot for K2HK/K2G platforms with the >> http://pastebin.ubuntu.com/16904991/ fragment + multi_v7_defconfig >> >> Side note on LPAE: >> For our current device tree and u-boot, LPAE is mandatory to bootup >> for current Keystone boards - but this is not a SoC requirement, >> booting without LPAE/HIGHMEM results in non-coherent DDR accesses. > > This sounds like a regression, I thought we had this working when > keystone was initially merged and we got both the coherent and > non-coherent mode working with the same DT. > >> Currently: >> - U-Boot assumes that lpae is always enabled in kennel and updates the >> DT memory node with higher addresses. Because of which you are not >> detecting any memory without lpae and kernel crashed very early, hence >> no prints. So, make mem_lpae env setting as 0 in U-boot. > > We could work around this in the kernel by detecting the faulty u-boot > behavior and fixing up the addresses in an early platform callback. > >> - DT also assumes that lpae is always enabled, and always asks for >> dma-address translation for higher addresses to lower addresses. >> Just delete the "dma-ranges" property or create a one-on-one mapping >> like dma-ranges = <0x80000000 0x0 0x80000000 0x80000000> > > This may be a bit trickier, I think originally keystone ignored the > dma-ranges property and hacked up its own offset by adding a magic > constant to the dma address using a bus notifier. We probably don't > want to bring that hack back, but maybe we can come up with another > solution. > Santosh, Bill, Lokesh, Grygorii: could you help feedback on the above comments from Arnd? -- Regards, Nishanth Menon
On 6/1/2016 3:31 PM, Arnd Bergmann wrote: > On Wednesday, June 1, 2016 4:31:54 PM CEST Nishanth Menon wrote: >> Introduce ARCH_KEYSTONE_TYPICAL which is common for all Keystone >> platforms. This is particularly useful when custom optimized defconfig >> builds are created for Keystone architecture platforms. >> >> An example of the same would be a sample fragment ks_only.cfg: >> http://pastebin.ubuntu.com/16904991/ - This prunes all arch other than >> keystone and any options the other architectures may enable. >> >> git clean -fdx && git reset --hard && \ >> ./scripts/kconfig/merge_config.sh -m \ >> ./arch/arm/configs/multi_v7_defconfig ~/tmp/ks_only.cfg &&\ >> make olddefconfig >> >> The above unfortunately will disable options necessary for KS2 boards >> to boot to the bare minimum initramfs. >> >> Hence the "KEYSTONE_TYPICAL" option is designed similar to commit 8d9166b519fd >> ("omap2/3/4: Add Kconfig option to compile in typical omap features") >> that can be enabled for most boards keystone platforms >> without needing to rediscover these in defconfig all over again - >> examples include multi_v7_defconfig base and optimizations done on top >> of them for keystone platform. > > I'd rather remove the option for OMAP as well, it doesn't really fit in with > how we do things for other platforms, and selecting a lot of other Kconfig > symbols tends to cause circular dependencies. > Yes. >> >> NOTE: the alternative is to select the configurations under >> ARCH_KEYSTONE. However, that would fail multi_v7 builds on ARM >> variants that dont work with LPAE. > > Please no arbitrary selects from the platform. > >> Cc: Bill Mills <wmills@ti.com> >> Cc: Murali Karicheri <m-karicheri2@ti.com> >> Cc: Grygorii Strashko <grygorii.strashko@ti.com> >> Cc: Tero Kristo <t-kristo@ti.com> >> Cc: Lokesh Vutla <lokeshvutla@ti.com> >> Signed-off-by: Nishanth Menon <nm@ti.com> >> --- >> >> Based on: next-20160601 >> >> Tested for basic initramfs boot for K2HK/K2G platforms with the >> http://pastebin.ubuntu.com/16904991/ fragment + multi_v7_defconfig >> >> Side note on LPAE: >> For our current device tree and u-boot, LPAE is mandatory to bootup >> for current Keystone boards - but this is not a SoC requirement, >> booting without LPAE/HIGHMEM results in non-coherent DDR accesses. > > This sounds like a regression, I thought we had this working when > keystone was initially merged and we got both the coherent and > non-coherent mode working with the same DT. > Yes and it works. The coherent memory space itself is beyond 4GB so I don't understand a requirement of having coherent memory without LPAE. >> Currently: >> - U-Boot assumes that lpae is always enabled in kennel and updates the >> DT memory node with higher addresses. Because of which you are not >> detecting any memory without lpae and kernel crashed very early, hence >> no prints. So, make mem_lpae env setting as 0 in U-boot. > > We could work around this in the kernel by detecting the faulty u-boot > behavior and fixing up the addresses in an early platform callback. > U-boot is already doing that and I don't see any issue with it. >> - DT also assumes that lpae is always enabled, and always asks for >> dma-address translation for higher addresses to lower addresses. >> Just delete the "dma-ranges" property or create a one-on-one mapping >> like dma-ranges = <0x80000000 0x0 0x80000000 0x80000000> > > This may be a bit trickier, I think originally keystone ignored the > dma-ranges property and hacked up its own offset by adding a magic > constant to the dma address using a bus notifier. We probably don't > want to bring that hack back, but maybe we can come up with another > solution. > I don't think we should go on this path ever. U-boot should modify this parameter as done previously. Regards, Santosh
On 6/1/2016 3:49 PM, Nishanth Menon wrote: > On 06/01/2016 05:31 PM, Arnd Bergmann wrote: [...] > > Santosh, Bill, Lokesh, Grygorii: could you help feedback on the above > comments from Arnd? > Already responded to Arnds email.
On 06/01/2016 06:26 PM, Santosh Shilimkar wrote: [...] >>> Side note on LPAE: >>> For our current device tree and u-boot, LPAE is mandatory to bootup >>> for current Keystone boards - but this is not a SoC requirement, >>> booting without LPAE/HIGHMEM results in non-coherent DDR accesses. >> >> This sounds like a regression, I thought we had this working when >> keystone was initially merged and we got both the coherent and >> non-coherent mode working with the same DT. >> > Yes and it works. The coherent memory space itself is beyond 4GB so Hmm... True, I just tested next-20160602 with mem_lpae set to 0 in u-boot and it seems to boot just fine. > I don't understand a requirement of having coherent memory without > LPAE. Looks like a messed up description on my end, Looks like I have to update my automated test framework to incorporate the manual steps involved. -- Regards, Nishanth Menon
On 6/2/2016 5:34 AM, Nishanth Menon wrote: > On 06/01/2016 06:26 PM, Santosh Shilimkar wrote: > [...] >>>> Side note on LPAE: >>>> For our current device tree and u-boot, LPAE is mandatory to bootup >>>> for current Keystone boards - but this is not a SoC requirement, >>>> booting without LPAE/HIGHMEM results in non-coherent DDR accesses. >>> >>> This sounds like a regression, I thought we had this working when >>> keystone was initially merged and we got both the coherent and >>> non-coherent mode working with the same DT. >>> >> Yes and it works. The coherent memory space itself is beyond 4GB so > > Hmm... True, I just tested next-20160602 with mem_lpae set to 0 in > u-boot and it seems to boot just fine. > >> I don't understand a requirement of having coherent memory without >> LPAE. > > Looks like a messed up description on my end, Looks like I have to > update my automated test framework to incorporate the manual steps > involved. > No worries. Am glad you got your setup working. Regards, Santosh
* Nishanth Menon <nm@ti.com> [160601 15:51]: > On 06/01/2016 05:31 PM, Arnd Bergmann wrote: > > On Wednesday, June 1, 2016 4:31:54 PM CEST Nishanth Menon wrote: > >> > >> Hence the "KEYSTONE_TYPICAL" option is designed similar to commit 8d9166b519fd > >> ("omap2/3/4: Add Kconfig option to compile in typical omap features") > >> that can be enabled for most boards keystone platforms > >> without needing to rediscover these in defconfig all over again - > >> examples include multi_v7_defconfig base and optimizations done on top > >> of them for keystone platform. > > > > I'd rather remove the option for OMAP as well, it doesn't really fit in with > > how we do things for other platforms, and selecting a lot of other Kconfig > > symbols tends to cause circular dependencies. > > Hmm, fair enough -> adding Tony as well if he sees an problem with > dropping ARCH_OMAP2PLUS_TYPICAL. Yes there's a problem. Removing that is going to make all the custom .config files unbootable almost certainly. Just search around on issues related to not having REGULATOR_FIXED_VOLTAGE selected. I agree we should not force select things though. And the I2C selection at least is wrong, we can have PMICs that are not on I2C bus. Anybody got better ideas what we should do to make the configuration options more intuitive? Regards, Tony
On Tue, Jun 07, 2016 at 10:09:46AM +0200, Arnd Bergmann wrote: Please start new threads for things like this - there's no obvious relevance to me in either the subject or even the first couple of pages of the message so it very nearly got deleted unread. It's very common to get copied on irrelevant stuff so things with no obvious motivation. > REGULATOR_FIXED_VOLTAGE is needed by a lot of platforms that usually > don't select it, so it might be good to add a 'default y' to its Kconfig > symbol, or we could add 'select REGULATOR_FIXED_VOLTAGE if REGULATOR' > to all platforms that need it. The driver is about 1.5KB in size, compared > to about 50KB for the regulator core. The platforms should do this - I wouldn't say it's *that* common, especially not as a build time dependency with things moving to DT.
Hi, * Arnd Bergmann <arnd@arndb.de> [160607 01:11]: > A lot of these options are typical for all ARMv7 machines: AEABI, I2C, NEON, > PM, REGULATOR and VFP are things that we probably want to default to enabled > whenever we build a MULTI_V7 kernel, some also for V5 or V6, we just > need to come up with a good way to do that while (probably for most of > them) still allowing them to be disabled with CONFIG_EXPERT. I would > feel more comfortable with having an ARCH_MULTIPLATFORM_TYPICAL > Kconfig symbol than with the ARCH_OMAP2PLUS_TYPICAL one that ends up > turning things on unconditionally whenever you add ARCH_OMAP2PLUS > to some other configuration. We still need to be careful about not changing the Kconfig option name for something like this as it will cause the custom .config files to fail unless the default is y. But yeah I agree, it would be nice to have some multiarch sane default selects, then also do the platform specific selects as needed. Naturally this needs to be kept down to minimum ideally limited to silent options. So we could have ARCH_MULTIPLATFORM_TYPICAL, then have the old ARCH_OMAP2PLUS_TYPICAL select that one. That should keep things behaving just fine if the old .config had ARCH_OMAP2PLUS_TYPICAL. > For I2C_OMAP, MENELAUS and TWL4030, we could just add a > 'default ARCH_OMAP3 || ARCH_OMAP4' or whatever is appropriate for > each of them. I assume we want to handle TWL6040 the same way, though > we currently don't do that. MENELAUS seems to be only needed for > omap2420-n8x0. We could yeah. TWL4030 is omap2430 to omap3, I don't think we currently have any omap3 based ones not using twl4030.. But there certainly are tons of usable devices with the Motorola CPCAP PMIC instead. Then REGULATOR_FIXED_VOLTAGE we can have platform select like Mark seems to prefer. HIGHMEM too should be platform specific. The original reason for ARCH_OMAP2PLUS_TYPICAL was that if omap2plus is selected with that you actually get a bootable system. Regards, Tony
On Wednesday, June 8, 2016 2:47:48 AM CEST Tony Lindgren wrote: > > * Arnd Bergmann <arnd@arndb.de> [160607 01:11]: > > A lot of these options are typical for all ARMv7 machines: AEABI, I2C, NEON, > > PM, REGULATOR and VFP are things that we probably want to default to enabled > > whenever we build a MULTI_V7 kernel, some also for V5 or V6, we just > > need to come up with a good way to do that while (probably for most of > > them) still allowing them to be disabled with CONFIG_EXPERT. I would > > feel more comfortable with having an ARCH_MULTIPLATFORM_TYPICAL > > Kconfig symbol than with the ARCH_OMAP2PLUS_TYPICAL one that ends up > > turning things on unconditionally whenever you add ARCH_OMAP2PLUS > > to some other configuration. > > We still need to be careful about not changing the Kconfig option > name for something like this as it will cause the custom .config files > to fail unless the default is y. But yeah I agree, it would be nice > to have some multiarch sane default selects, then also do the platform > specific selects as needed. Naturally this needs to be kept down to > minimum ideally limited to silent options. > > So we could have ARCH_MULTIPLATFORM_TYPICAL, then have the old > ARCH_OMAP2PLUS_TYPICAL select that one. That should keep things > behaving just fine if the old .config had ARCH_OMAP2PLUS_TYPICAL. If we make ARCH_MULTIPLATFORM_TYPICAL 'default y', it will be always enabled in this case, and I think we can drop ARCH_OMAP2PLUS_TYPICAL. The downside would be any users that want the options we enable there turned off and have them silently enabled when upgrading the kernel. > > For I2C_OMAP, MENELAUS and TWL4030, we could just add a > > 'default ARCH_OMAP3 || ARCH_OMAP4' or whatever is appropriate for > > each of them. I assume we want to handle TWL6040 the same way, though > > we currently don't do that. MENELAUS seems to be only needed for > > omap2420-n8x0. > > We could yeah. TWL4030 is omap2430 to omap3, I don't think we currently > have any omap3 based ones not using twl4030.. But there certainly > are tons of usable devices with the Motorola CPCAP PMIC instead. So should we enable both then? > Then REGULATOR_FIXED_VOLTAGE we can have platform select like Mark > seems to prefer. Ok > HIGHMEM too should be platform specific. I still don't see a good way to handle that, we should certainly not just 'select' it, because we often want to leave it disabled. > The original reason for ARCH_OMAP2PLUS_TYPICAL was that if omap2plus > is selected with that you actually get a bootable system. I understand. It's just not very scalable to have every platform do this, in particular if they want to select conflicting options (none of the ones you select should conflict, but we'd get there eventually). Arnd
* Arnd Bergmann <arnd@arndb.de> [160608 09:06]: > On Wednesday, June 8, 2016 2:47:48 AM CEST Tony Lindgren wrote: > > > > So we could have ARCH_MULTIPLATFORM_TYPICAL, then have the old > > ARCH_OMAP2PLUS_TYPICAL select that one. That should keep things > > behaving just fine if the old .config had ARCH_OMAP2PLUS_TYPICAL. > > If we make ARCH_MULTIPLATFORM_TYPICAL 'default y', it will be always > enabled in this case, and I think we can drop ARCH_OMAP2PLUS_TYPICAL. Having "default y" there seems safe enough for me. > The downside would be any users that want the options we enable there > turned off and have them silently enabled when upgrading the kernel. I think the long term solution here might be to generate the .config out of dts files.. > > > For I2C_OMAP, MENELAUS and TWL4030, we could just add a > > > 'default ARCH_OMAP3 || ARCH_OMAP4' or whatever is appropriate for > > > each of them. I assume we want to handle TWL6040 the same way, though > > > we currently don't do that. MENELAUS seems to be only needed for > > > omap2420-n8x0. > > > > We could yeah. TWL4030 is omap2430 to omap3, I don't think we currently > > have any omap3 based ones not using twl4030.. But there certainly > > are tons of usable devices with the Motorola CPCAP PMIC instead. > > So should we enable both then? No CPCAP support currently in mainline kernel.. And with most of initcall level issues out of the way, any future support should not be added to the TYPICAL because of all the issues discussed. > > HIGHMEM too should be platform specific. > > I still don't see a good way to handle that, we should certainly not > just 'select' it, because we often want to leave it disabled. Right. Leaving it out produces a bootable kernel though that could produce some warning if configured memory is > 768MB. > > The original reason for ARCH_OMAP2PLUS_TYPICAL was that if omap2plus > > is selected with that you actually get a bootable system. > > I understand. It's just not very scalable to have every platform do > this, in particular if they want to select conflicting options (none > of the ones you select should conflict, but we'd get there eventually). Yeah. Seems like generating the base .confing out of the dts file is better in the long run. Regards, Tony
On Wed, Jun 08, 2016 at 11:50:35PM -0700, Tony Lindgren wrote: > * Arnd Bergmann <arnd@arndb.de> [160608 09:06]: > > The downside would be any users that want the options we enable there > > turned off and have them silently enabled when upgrading the kernel. > I think the long term solution here might be to generate the .config > out of dts files.. That would be cool!
diff --git a/arch/arm/mach-keystone/Kconfig b/arch/arm/mach-keystone/Kconfig index ea955f6db8b7..a151f878143f 100644 --- a/arch/arm/mach-keystone/Kconfig +++ b/arch/arm/mach-keystone/Kconfig @@ -14,3 +14,22 @@ config ARCH_KEYSTONE help Support for boards based on the Texas Instruments Keystone family of SoCs. + +if ARCH_KEYSTONE + +menu "TI Keystone Specific Features" + +config ARCH_KEYSTONE_TYPICAL + bool "Typical Keystone configuration" + depends on ARM_LPAE + default y + select AEABI + select HIGHMEM + select NEON + select PM + select VFP + help + Compile a kernel suitable for booting most boards on Keystone + architecture to at least a simple initramfs +endmenu +endif
Introduce ARCH_KEYSTONE_TYPICAL which is common for all Keystone platforms. This is particularly useful when custom optimized defconfig builds are created for Keystone architecture platforms. An example of the same would be a sample fragment ks_only.cfg: http://pastebin.ubuntu.com/16904991/ - This prunes all arch other than keystone and any options the other architectures may enable. git clean -fdx && git reset --hard && \ ./scripts/kconfig/merge_config.sh -m \ ./arch/arm/configs/multi_v7_defconfig ~/tmp/ks_only.cfg &&\ make olddefconfig The above unfortunately will disable options necessary for KS2 boards to boot to the bare minimum initramfs. Hence the "KEYSTONE_TYPICAL" option is designed similar to commit 8d9166b519fd ("omap2/3/4: Add Kconfig option to compile in typical omap features") that can be enabled for most boards keystone platforms without needing to rediscover these in defconfig all over again - examples include multi_v7_defconfig base and optimizations done on top of them for keystone platform. NOTE: the alternative is to select the configurations under ARCH_KEYSTONE. However, that would fail multi_v7 builds on ARM variants that dont work with LPAE. Cc: Bill Mills <wmills@ti.com> Cc: Murali Karicheri <m-karicheri2@ti.com> Cc: Grygorii Strashko <grygorii.strashko@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Cc: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> --- Based on: next-20160601 Tested for basic initramfs boot for K2HK/K2G platforms with the http://pastebin.ubuntu.com/16904991/ fragment + multi_v7_defconfig Side note on LPAE: For our current device tree and u-boot, LPAE is mandatory to bootup for current Keystone boards - but this is not a SoC requirement, booting without LPAE/HIGHMEM results in non-coherent DDR accesses. Currently: - U-Boot assumes that lpae is always enabled in kennel and updates the DT memory node with higher addresses. Because of which you are not detecting any memory without lpae and kernel crashed very early, hence no prints. So, make mem_lpae env setting as 0 in U-boot. - DT also assumes that lpae is always enabled, and always asks for dma-address translation for higher addresses to lower addresses. Just delete the "dma-ranges" property or create a one-on-one mapping like dma-ranges = <0x80000000 0x0 0x80000000 0x80000000> These are probably the reasons for the kernel not booting without LPAE enabled in .config. but then, the TI recommended operation for Keystone platforms is with LPAE and HIGHMEM enabled for coherent architecture behavior. arch/arm/mach-keystone/Kconfig | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) -- 2.8.0