Bug 11426 - yocto-bsp: several kernel configurations are ignored when creating a new bsp based on ARM
Summary: yocto-bsp: several kernel configurations are ignored when creating a new bsp ...
Status: RESOLVED FIXED
Alias: None
Product: Meta-yocto
Classification: Build System, Metadata & Runtime
Component: meta-yocto (show other bugs)
Version: 2.3
Hardware: x86 Multiple
: Medium+ normal
Target Milestone: 2.4 M1
Assignee: Alejandro Hernandez
QA Contact:
URL:
Whiteboard:
Depends on:
Blocks:
 
Reported: 2017-04-27 02:44 UTC by Alejandro Hernandez
Modified: 2017-06-15 15:56 UTC (History)
4 users (show)

See Also:
OS type for building Yocto: ---
Type of Regression: ---
Verified:
Documentation change: No (bug/feature does not impact docs)

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Alejandro Hernandez 2017-04-27 02:44:05 UTC 
Similarly to bug #10362, after creating a new BSP based on ARM using the yocto-bsp script, when building the kernel several warnings are shown indicating that many of our kernel configurations were ignored.

Steps to reproduce:
1 yocto-bsp create myqemuarm qemu
2 chose ARM arch as base
3 change MACHINE to myqemuarm and include the new layer into bblayers.conf
4 bitbake virtual/kernel.


The following warnings are shown:
---------- CONFIG_SMP -----------------
Config: CONFIG_SMP
From: /home/aehernan/yocto/poky_master/builds/qemuarm/tmp/work-shared/myqemuarm/kernel-source/.kernel-meta/configs/standard/arm-versatile-926ejs/myqemuarm/standard/arm-versatile-926ejs/myqemuarm/cfg/smp.cfg
Requested value:  CONFIG_SMP=y
Actual value:     


---------- CONFIG_SCHED_SMT -----------------
Config: CONFIG_SCHED_SMT
From: /home/aehernan/yocto/poky_master/builds/qemuarm/tmp/work-shared/myqemuarm/kernel-source/.kernel-meta/configs/standard/arm-versatile-926ejs/myqemuarm/standard/arm-versatile-926ejs/myqemuarm/cfg/smp.cfg
Requested value:  CONFIG_SCHED_SMT=y
Actual value:     


---------- CONFIG_NR_CPUS -----------------
Config: CONFIG_NR_CPUS
From: /home/aehernan/yocto/poky_master/builds/qemuarm/tmp/work-shared/myqemuarm/kernel-source/.kernel-meta/configs/standard/arm-versatile-926ejs/myqemuarm/standard/arm-versatile-926ejs/myqemuarm/cfg/smp.cfg
Requested value:  CONFIG_NR_CPUS=64
Actual value:     

All these kernel configs have to be analyzed on a one by one basis, to see what dependency is missing for each.
Comment 1 Alejandro Hernandez 2017-05-12 22:02:58 UTC 
As mentioned all these warnings need to be analyzed one by one, here's why each CONFIG is missing:
--------------------------
CONFIG_SMP=y
Dependencies Missing:
  - CPU_V6K or CPU_V7:
    These are selected by setting:
    CONFIG_ARCH_MULTI_V7=y
    or
    CONFIG_ARCH_MULTI_V6=7

    BUT!, out ARM BSPs are based on armv4/v5 (via TUNEFEATURES), which are incompatible with SMP, we can either upgrade to armv6/v7 or simply avoid setting SMP for ARM based BSPs

  - HAVE_SMP=y
    This value is also set by setting:
    CONFIG_ARCH_MULTI_V7=y
    or
    CONFIG_ARCH_MULTI_V6=7

--------------------------

CONFIG_SCHED_SMT=y
Dependencies Missing:
  - CPU_V7
  - SMP

Again, this would be fixed by selecting CONFIG_ARCH_MULTI_V7=y

--------------------------

CONFIG_NR_CPUS=64
According to Kconfig, this is the description for NR_CPUS:

config NR_CPUS
        int "Maximum number of CPUs (2-32)"
        range 2 32 supports 32
        depends on SMP
        default "4"

So, for starters this value is wrong since for ARM the maximum supported value is 32 and not 64 (I checked and once fixed, it will automatically be set to the maximum (32).

Since this one also depends on SMP=y, it would be fixed in the same fashion as the previous one, by using an ARM architecture (ARMv6 or ARMv7) that actually supports Symmetric Multiprocessing (SMP).

There needs to be a discussion on why we are using armv4/v5 (I'm not aware, there could be a good reason) and if we decide not to upgrade to V7 (preferrably), we need to make sure we avoid setting the previous values for BSPs based on this.

If we do decide to upgrade, a patch to kernel-meta would fix the problem.