Am 04.04.2015 um 23:48 schrieb Chen Gang: > On 4/4/15 06:59, Richard Weinberger wrote: >> On Thu, Apr 2, 2015 at 11:25 PM, Chen Gang <xili_gchen_5...@hotmail.com> >> wrote: >>> For allmodconfig, it uses BF533 which will cause 3 issues for common >>> checking: >>> >>> - The first 2 issues are about PLL_BYPASS, it needs BF_REV_0_6 (which >>> just match the compiler's output for __SILICON_REVISION__). >>> >>> - The last issue is about MPU, it needs BF_REV_0_5 or BF_REV_0_6 (which >>> just match the compiler's output for __SILICON_REVISION__). >>> >>> The related error with allmodconfig: >>> >>> CC arch/blackfin/mach-common/arch_checks.o >>> arch/blackfin/mach-common/arch_checks.c:24:3: error: #error "Sclk value >>> selected is less than minimum. Please select a proper value for SCLK >>> multiplier" >>> # error "Sclk value selected is less than minimum. Please select a >>> proper value for SCLK multiplier" >>> ^ >>> arch/blackfin/mach-common/arch_checks.c:28:3: error: #error "ANOMALY >>> 05000273, please make sure CCLK is at least 2x SCLK" >>> # error "ANOMALY 05000273, please make sure CCLK is at least 2x SCLK" >>> ^ >>> arch/blackfin/mach-common/arch_checks.c:51:3: error: #error the MPU will >>> not function safely while Anomaly 05000263 applies >>> # error the MPU will not function safely while Anomaly 05000263 applies >>> ^ >>> >>> config PLL_BYPASS >>> bool "Bypass PLL" >>> - depends on BFIN_KERNEL_CLOCK && (!BF60x) >>> + depends on BFIN_KERNEL_CLOCK && (!BF60x) && ((!BF533) || BF_REV_0_6) >>> default n >>> >>> config CLKIN_HALF >>> @@ -1112,6 +1112,7 @@ endchoice >>> comment "Memory Protection Unit" >>> config MPU >>> bool "Enable the memory protection unit" >>> + depends on (!BF533) || BF_REV_0_6 || BF_REV_0_5 >>> default n >>> help >>> Use the processor's MPU to protect applications from accessing >> >> This answers my question wrt. allmodconfig. ;) >> I'm not sure if this is the correct way. Isn't this the reason why we >> have COMPILE_TEST? >> > > For me, COMPILE_TEST is for compiling test without the related hardware > supports, but the code should no any logical issues firstly (at least, > COMPILE_TEST itself should not generate additional logical bugs). > > In our case, I guess the first 2 issues are about logical issues (not > hardware supporting issues), so I guess, it is not suitable to use > COMPILE_TEST to bypass them.
So you have a blackfin board and successfully booted such a allmodconfig kernel on it? Thanks, //richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
