Re: [meta-intel] [Patch v2 00/11] machinesetuptool commits
Hi Nitin, This description helps to identify _what_ the tool is intended to do, but it still does not address the _how_, which is important context to have when reviewing the patches. There was also no mention of the sources to the tool itself, also important for context. One gap below is Gummiboot serial support, which I had intended to switch meta-intel EFI support over too this release (looking like that may not happen... Will look into how invasive that would be). Another concern is the statement below about not allowing for a default configuration. Like other recent changes to meta-intel, this should be an opt-in thing, and as such, the BSPs need to be able to provide defaults. The intel-corei7-64 BSP works well as it is for a number of Intel platforms, and people using those may prefer not to use the machinesetuptool. -- Darren On 10/8/14, 5:32, nitin.a.kam...@intel.com nitin.a.kam...@intel.com wrote: From: Nitin A Kamble nitin.a.kam...@intel.com As this is totally new feature I am including some explanation as a simple design document for ease of understanding the implementation. Machine Setup Tool Q. Why is this feature implemented? A. Many of the BSPs from meta-intel are very similar differing only in the configuration of things such as serial port, X configuration, network, audio, kernel parameters etc. Now with the common kernel it is possible to support more platforms or boards with a single BSP. The only thing missing was the text configuration customization for a particular hardware platform. The machine setup tool fills this gap. Q. What the machine setup tool can do? A. It provides following capabilities: * Provide previously defined machine configurations. * Ability to select a target machine at runtime at the time of boot. * Ability to reconfigure a previously configured machine for another supported platform. * Ability to select a default machine when no user input is received at the boot time. * These configurations can be specified for machines * ALSA audio configuration file * ALSA Mixer state file * Network configuration file * xorg configuration file * Machine formfactor file * Kernel boot parameters * A list of blacklisted kernel modules * A list of kernel modules to autoload * Serial port configuration for syslinux boot loader * Serial port configuration for grub boot loader * Serial port configuration for setting up serial console * Any scripts to run at setup time * Any scripts to run on every boot Q. What the machine setup tool can not do? A. Anything, which can not be easily manipulated on the target image is outside of the scope of the machine setup tool. So things like providing a custom kernel, or providing any special binaries is outside the scope of the machine setup tool. Q. Is the machine setup tool arch specific? A. Even though, the tool is mainly designed for the BSPs from the meta-intel layer, there is no architecture specific logic in the tool. It can be used on other architecture hardware similarly. Q. What are the possible future extensions to the tool? A. * The tool can be extended to detect the target hardware automatically. * It can also be extended to support more machine configuration customizations. * It can be extended to take the target machine from the kernel boot parameter. * It can be extended to handle different versions of configuration files, to deal with differences in configurations in the future. Q. What is the history of the machine setup tool? A. The tool has taken few ideas from the zaurusd project. And to avoid any legacy it has started the code from scratch. Q. What kind of design decision are made while developing the tool? A. The following points are considered in the design of the code. * The processing logic and the configuration can be neatly separated in the different Yocto Project layers. This way all the BSP specific configuration can go in the individual BSP layers, and the common logic can be placed in the common layer. * If a target machine is not previously configured, then at the boot time a list of supported machines is displayed along with a prompt for the selection of target machine. * A default target machine can be specified, which becomes the selected machine when no user input is received at the boot time prompt. This helps in situations where serial ports may not be accessible at the 1st boot. * To get the ability of reconfiguration of image, complete machine configuration need to be specified for each supported machine It can not rely on any kind of default configuration. Q. What is missing in this pull request? A. The documentation changes for README is missing at this point. These will follow, once the structure and format of README for such kind of features is finalized with the microcode commits. Q. What kind of
Re: [meta-intel] [Patch v2 01/11] machinesetuptool: a new recipe for setup of a machine
On 10/8/14, 5:32, nitin.a.kam...@intel.com nitin.a.kam...@intel.com
wrote:
From: Nitin A Kamble nitin.a.kam...@intel.com
a new recipe which recipe provides the ability to setup a BSP image for a
specific machine or platform at the boot time. The base recipe does not
provide any machine configuration files, those are provided by individual
BSP layer.
Signed-off-by: Nitin A Kamble nitin.a.kam...@intel.com
---
.../machinesetuptool/machinesetuptool_git.bb | 48
++
1 file changed, 48 insertions(+)
create mode 100644
common/recipes-bsp/machinesetuptool/machinesetuptool_git.bb
diff --git a/common/recipes-bsp/machinesetuptool/machinesetuptool_git.bb
b/common/recipes-bsp/machinesetuptool/machinesetuptool_git.bb
Hrm, what was the policy on _git.bb again? Iirc we are trying to do away
with them and use the PV there?
new file mode 100644
index 000..8101526
--- /dev/null
+++ b/common/recipes-bsp/machinesetuptool/machinesetuptool_git.bb
@@ -0,0 +1,48 @@
+SUMMARY = Daemon to setup an image for a specific machine at boot time.
+SECTION = base
+LICENSE = GPLv3
+LIC_FILES_CHKSUM = file://COPYING;md5=d32239bcb673463ab874e80d47fae504
+RDEPENDS_${PN} = sysvinit sed
+
+PV = 1.0+git${SRCPV}
+
+SRCREV = 07f7c30b9ed5509087ad591ba4cb2543df9f08e2
+
+SRC_URI = git://git.yoctoproject.org/machinesetuptool.git
+
+S = ${WORKDIR}/git
+
+PACKAGE_ARCH = ${MACHINE_ARCH}
Heh... I *think* that's right... MACHINE_ARCH Yup
Kinda messes with your head a little bit doesn't it? :-)
+
+inherit autotools pkgconfig update-rc.d
+
+INITSCRIPT_NAME = machinesetuptool
+INITSCRIPT_PARAMS = start 00 S . stop 20 0 1 6 .
+
+# following variables are initialized to empty values now.
+# These need to be populated with the desired machine configurations
+# for each BSP in it's own layer.
+MACHINE_CONFIG_FILES ?=
+SUPPORTED_MACHINES ?=
+DEFAULT_MACHINE_SELECTION ?= none
+
+python __anonymous () {
+src_uri = d.getVar('SRC_URI', True)
+machine_config_files = (d.getVar('MACHINE_CONFIG_FILES', True) or )
+for file in machine_config_files.split():
+ src_uri += file:// + file
+d.setVar('SRC_URI', src_uri)
OK Why not just do this in the bbappend? Is it just so much shorter
this way and less to maintain?
There is a tradeoff here between easily debuggable explicit meta-data, and
cleaner optimization like this. It appears as though there are a lot of
files, which probably tips us toward this solution, but I wanted to raise
the question.
+}
+
+do_install_append() {
+ (cat EOF
+SUPPORTED_MACHINES=${SUPPORTED_MACHINES}
+DEFAULT_MACHINE_SELECTION=${DEFAULT_MACHINE_SELECTION}
+EOF
+ ) ${D}/${sysconfdir}/${BPN}/defaults
+
+ for file in ${MACHINE_CONFIG_FILES}
+ do
+ install -m 0644 ${S}/../${file}
${D}/${sysconfdir}/${BPN}/config/
Seems as though it would makes sense to have this broken out into MACHINE
subdirectories.
Where is the ${BPN}/config directory created? We typically see that in the
install I believe.
+ done
+}
--
1.8.1.4
--
Darren Hart
Intel Open Source Technology Center
--
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [PATCH 1/3] crownbay-noemgd: disable the gma500_gfx module
On 10/10/14, 6:37 AM, Zanussi, Tom tom.zanu...@intel.com wrote:
On Thu, 2014-10-09 at 15:11 -0700, nitin.a.kam...@intel.com wrote:
From: Nitin A Kamble nitin.a.kam...@intel.com
The gmx500 graphics driver does not work on this BSP, but it takes
the ownership of the graphics hardware at boot time, blocking other
drivers from using the graphics hardware.
Fix the issue by blacklisting the gma500_gfx kernel module in the kmod
configuration, so that it doesn't get loaded at boot time.
Is this really the right way to do this? It will only work if
CONFIG_XXX=m. If m-y at some point, the whole .bbappend becomes
useless at best.
That is why the gma500 is converted from y to m. And with the common
kernel,
It should be m anyway. If you have better way to solve you can share.
Nitin
Tom
Fixes Bug:
[YOCTO #6807]
Signed-off-by: Nitin A Kamble nitin.a.kam...@intel.com
---
meta-crownbay/recipes-kernel/kmod/kmod_git.bbappend | 3 +++
1 file changed, 3 insertions(+)
create mode 100644 meta-crownbay/recipes-kernel/kmod/kmod_git.bbappend
diff --git a/meta-crownbay/recipes-kernel/kmod/kmod_git.bbappend
b/meta-crownbay/recipes-kernel/kmod/kmod_git.bbappend
new file mode 100644
index 000..56d8fcb
--- /dev/null
+++ b/meta-crownbay/recipes-kernel/kmod/kmod_git.bbappend
@@ -0,0 +1,3 @@
+do_install_append () {
+echo blacklist gma500_gfx
${D}${sysconfdir}/modprobe.d/prohibit_gma500_gfx.conf
+}
--
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [Patch v2 02/11] machinesetuptool: add nuc machine config to the intel-corei7-64 BSP
On 10/8/14, 5:32, nitin.a.kam...@intel.com nitin.a.kam...@intel.com
wrote:
From: Nitin A Kamble nitin.a.kam...@intel.com
Add machine configuration for the NUC platform in the intel-corei7-64 BSP
image.
Hi Nitin,
A few comments inline below...
Signed-off-by: Nitin A Kamble nitin.a.kam...@intel.com
---
.../machinesetuptool/intel-corei7-64/nuc-alsa.conf | 24 ++
.../intel-corei7-64/nuc-alsa.state | 309
+
.../nuc-bootscript-hdmi_port_audio.sh | 19 ++
.../intel-corei7-64/nuc-formfactor.machconfig | 3 +
.../intel-corei7-64/nuc-network.interfaces | 20 ++
.../machinesetuptool/intel-corei7-64/nuc.vars | 14 +
.../machinesetuptool/machinesetuptool_git.bbappend | 18 ++
7 files changed, 407 insertions(+)
create mode 100644
common/recipes-bsp/machinesetuptool/machinesetuptool/intel-corei7-64/nuc-a
lsa.conf
create mode 100644
common/recipes-bsp/machinesetuptool/machinesetuptool/intel-corei7-64/nuc-a
lsa.state
create mode 100755
common/recipes-bsp/machinesetuptool/machinesetuptool/intel-corei7-64/nuc-b
ootscript-hdmi_port_audio.sh
create mode 100644
common/recipes-bsp/machinesetuptool/machinesetuptool/intel-corei7-64/nuc-f
ormfactor.machconfig
create mode 100644
common/recipes-bsp/machinesetuptool/machinesetuptool/intel-corei7-64/nuc-n
etwork.interfaces
create mode 100644
common/recipes-bsp/machinesetuptool/machinesetuptool/intel-corei7-64/nuc.v
ars
create mode 100644
common/recipes-bsp/machinesetuptool/machinesetuptool_git.bbappend
diff --git
a/common/recipes-bsp/machinesetuptool/machinesetuptool/intel-corei7-64/nuc
-bootscript-hdmi_port_audio.sh
b/common/recipes-bsp/machinesetuptool/machinesetuptool/intel-corei7-64/nuc
-bootscript-hdmi_port_audio.sh
new file mode 100755
index 000..3c77ac9
--- /dev/null
+++
b/common/recipes-bsp/machinesetuptool/machinesetuptool/intel-corei7-64/nuc
-bootscript-hdmi_port_audio.sh
@@ -0,0 +1,19 @@
+#!/bin/sh
+#
+# If both HDMI ports are connected then use HDMI0 for default ALSA audio
out..
+
+ALSA_CONF_FILE=/etc/asound.conf
+
+HDMI0_STATUS_FILE=/sys/class/drm/card0-HDMI-A-1/status
+HDMI1_STATUS_FILE=/sys/class/drm/card0-HDMI-A-2/status
+
+HDMI0_ALSA_CONF=hw:0,3
+HDMI1_ALSA_CONF=hw:0,7
+
+if [ -f ${HDMI0_STATUS_FILE} ] [ `cat ${HDMI0_STATUS_FILE}` ==
connected ]
+then
+ sed -i s/pcm *\hw:[0-9]*,[0-9]*\/pcm \${HDMI0_ALSA_CONF}\/
${ALSA_CONF_FILE}
+elif [ -f ${HDMI1_STATUS_FILE} ] [ `cat ${HDMI1_STATUS_FILE}` ==
connected ]
+then
+ sed -i s/pcm \hw:[0-9]*,[0-9]*\/pcm \${HDMI1_ALSA_CONF}\/
${ALSA_CONF_FILE}
+fi
This approach really strikes me as a hack. I understand it's coming from
the existing NUC BSP... But is this actually how this is done by the major
distros as well?
diff --git
a/common/recipes-bsp/machinesetuptool/machinesetuptool/intel-corei7-64/nuc
-formfactor.machconfig
b/common/recipes-bsp/machinesetuptool/machinesetuptool/intel-corei7-64/nuc
-formfactor.machconfig
new file mode 100644
index 000..ffce012
--- /dev/null
+++
b/common/recipes-bsp/machinesetuptool/machinesetuptool/intel-corei7-64/nuc
-formfactor.machconfig
@@ -0,0 +1,3 @@
+# Assume a USB mouse and keyboard are connected
+HAVE_TOUCHSCREEN=0
+HAVE_KEYBOARD=1
This is the default for basically all the BSPs, and it would be preferable
not to have to duplicate this across all the MACHINE config files. Having
this be the default for intel-corei7-64 and only overwrite it if the
configured machine provides the file seems like a reasonable approach to
me.
diff --git
a/common/recipes-bsp/machinesetuptool/machinesetuptool/intel-corei7-64/nuc
-network.interfaces
b/common/recipes-bsp/machinesetuptool/machinesetuptool/intel-corei7-64/nuc
-network.interfaces
new file mode 100644
index 000..4ed0a85
--- /dev/null
+++
b/common/recipes-bsp/machinesetuptool/machinesetuptool/intel-corei7-64/nuc
-network.interfaces
@@ -0,0 +1,20 @@
+# /etc/network/interfaces -- configuration file for ifup(8), ifdown(8)
+
+# The loopback interface
+auto lo
+iface lo inet loopback
+
+# Wireless interfaces
+iface wlan0 inet dhcp
+ wireless_mode managed
+ wireless_essid any
+ wpa-driver wext
+ wpa-conf /etc/wpa_supplicant.conf
+
+# Wired or wireless interfaces
+auto eth0
+iface eth0 inet dhcp
+
+# Bluetooth networking
+iface bnep0 inet dhcp
+
Same with this particular network interface.
--
Darren
diff --git
a/common/recipes-bsp/machinesetuptool/machinesetuptool/intel-corei7-64/nuc
.vars
b/common/recipes-bsp/machinesetuptool/machinesetuptool/intel-corei7-64/nuc
.vars
new file mode 100644
index 000..c6f373f
--- /dev/null
+++
b/common/recipes-bsp/machinesetuptool/machinesetuptool/intel-corei7-64/nuc
.vars
@@ -0,0 +1,14 @@
+FORMFACTOR_FILE=nuc-formfactor.machconfig
+ALSA_CONFIG_FILE=nuc-alsa.conf
+ALSA_STATE_FILE=nuc-alsa.state
+XORG_CONFIG_FILE=
+NETWORK_INTERFACES_FILE=nuc-network.interfaces
+AUTOLOAD_KERNEL_MODULES=uio iwlwifi
+PROHIBIT_KERNEL_MODULES=
+EXTRA_KERNEL_PARAMETERS=
Re: [meta-intel] [PATCH 1/3] crownbay-noemgd: disable the gma500_gfx module
On 10/10/14, 11:48, Kamble, Nitin A nitin.a.kam...@intel.com wrote: On 10/10/14, 1:34 PM, Darren Hart dvh...@linux.intel.com wrote: On 10/10/14, 10:46, Kamble, Nitin A nitin.a.kam...@intel.com wrote: On 10/10/14, 10:31 AM, Zanussi, Tom tom.zanu...@intel.com wrote: On Fri, 2014-10-10 at 12:25 -0500, Kamble, Nitin A wrote: On 10/10/14, 6:37 AM, Zanussi, Tom tom.zanu...@intel.com wrote: On Thu, 2014-10-09 at 15:11 -0700, nitin.a.kam...@intel.com wrote: From: Nitin A Kamble nitin.a.kam...@intel.com The gmx500 graphics driver does not work on this BSP, but it takes the ownership of the graphics hardware at boot time, blocking other drivers from using the graphics hardware. Fix the issue by blacklisting the gma500_gfx kernel module in the kmod configuration, so that it doesn't get loaded at boot time. Does gma500 work anywhere? If not, perhaps it doesn't belong in the intel-common BSPs. I really wanted it to be a reasonable fallback to EMGD, but it just doesn't seem to work anywhere. It does work on and needed for the emenlow-noemgd BSP. OK, glad it works somewhere! :-) -- Darren Hart Intel Open Source Technology Center -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [PATCH 1/3] crownbay-noemgd: disable the gma500_gfx module
On Fri, 2014-10-10 at 12:46 -0500, Kamble, Nitin A wrote:
On 10/10/14, 10:31 AM, Zanussi, Tom tom.zanu...@intel.com wrote:
On Fri, 2014-10-10 at 12:25 -0500, Kamble, Nitin A wrote:
On 10/10/14, 6:37 AM, Zanussi, Tom tom.zanu...@intel.com wrote:
On Thu, 2014-10-09 at 15:11 -0700, nitin.a.kam...@intel.com wrote:
From: Nitin A Kamble nitin.a.kam...@intel.com
The gmx500 graphics driver does not work on this BSP, but it takes
the ownership of the graphics hardware at boot time, blocking other
drivers from using the graphics hardware.
Fix the issue by blacklisting the gma500_gfx kernel module in the
kmod
configuration, so that it doesn't get loaded at boot time.
Is this really the right way to do this? It will only work if
CONFIG_XXX=m. If m-y at some point, the whole .bbappend becomes
useless at best.
That is why the gma500 is converted from y to m. And with the common
kernel,
It should be m anyway. If you have better way to solve you can share.
Why not a config fragment that turns it off for that BSP?
The more general question is whether the common kernel mandates
everything be 'm' for this reason.
Tom
This will be going backwards. We are trying to consolidate kernel and
What seems backwards to me is starting with a broken config and using a
band-aid to fix the brokenness.
BSPs.
And this suggested approach will make a separate kernel for this BSP.
The common kernel has lot of drivers enabled. And very few of them will be
actually used on any particular BSP. Not using kernel modules for these
many
drivers will be insane.
I guess I need to understand the new model where creating an embedded
system that only includes what it needs and which therefore doesn't need
to be a module is considered insane.
So what you're saying is that not only does everything in an Intel BSP
need to be configured as m, but also that an Intel BSP can't touch the
kernel, not even configuration.
Tom
Nitin
Nitin
Tom
Fixes Bug:
[YOCTO #6807]
Signed-off-by: Nitin A Kamble nitin.a.kam...@intel.com
---
meta-crownbay/recipes-kernel/kmod/kmod_git.bbappend | 3 +++
1 file changed, 3 insertions(+)
create mode 100644
meta-crownbay/recipes-kernel/kmod/kmod_git.bbappend
diff --git a/meta-crownbay/recipes-kernel/kmod/kmod_git.bbappend
b/meta-crownbay/recipes-kernel/kmod/kmod_git.bbappend
new file mode 100644
index 000..56d8fcb
--- /dev/null
+++ b/meta-crownbay/recipes-kernel/kmod/kmod_git.bbappend
@@ -0,0 +1,3 @@
+do_install_append () {
+ echo blacklist gma500_gfx
${D}${sysconfdir}/modprobe.d/prohibit_gma500_gfx.conf
+}
--
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [PATCH 1/3] crownbay-noemgd: disable the gma500_gfx module
On 10/10/14, 12:00, Tom Zanussi tom.zanu...@intel.com wrote:
On Fri, 2014-10-10 at 12:46 -0500, Kamble, Nitin A wrote:
On 10/10/14, 10:31 AM, Zanussi, Tom tom.zanu...@intel.com wrote:
On Fri, 2014-10-10 at 12:25 -0500, Kamble, Nitin A wrote:
On 10/10/14, 6:37 AM, Zanussi, Tom tom.zanu...@intel.com wrote:
On Thu, 2014-10-09 at 15:11 -0700, nitin.a.kam...@intel.com wrote:
From: Nitin A Kamble nitin.a.kam...@intel.com
The gmx500 graphics driver does not work on this BSP, but it takes
the ownership of the graphics hardware at boot time, blocking
other
drivers from using the graphics hardware.
Fix the issue by blacklisting the gma500_gfx kernel module in the
kmod
configuration, so that it doesn't get loaded at boot time.
Is this really the right way to do this? It will only work if
CONFIG_XXX=m. If m-y at some point, the whole .bbappend becomes
useless at best.
That is why the gma500 is converted from y to m. And with the common
kernel,
It should be m anyway. If you have better way to solve you can share.
Why not a config fragment that turns it off for that BSP?
The more general question is whether the common kernel mandates
everything be 'm' for this reason.
Tom
This will be going backwards. We are trying to consolidate kernel and
What seems backwards to me is starting with a broken config and using a
band-aid to fix the brokenness.
BSPs.
And this suggested approach will make a separate kernel for this BSP.
The common kernel has lot of drivers enabled. And very few of them will
be
actually used on any particular BSP. Not using kernel modules for these
many
drivers will be insane.
I guess I need to understand the new model where creating an embedded
system that only includes what it needs and which therefore doesn't need
to be a module is considered insane.
So what you're saying is that not only does everything in an Intel BSP
need to be configured as m, but also that an Intel BSP can't touch the
kernel, not even configuration.
Well, perhaps we need to sync up on this. We have a goal/vision of
simplifying what is a lot of per-board BSPs where it isn't necessary.
Since we don't know how each BSP is going to be used, we find we're often
adding USB drivers, etc. to the kernel configurations. To avoid a huge
bzImage, we do these as modules wherever feasible. The Linux kernel has
excellent support for Intel Architecture, which makes pervasive use of
enumerable and self describing buses and devices - this makes it possible
to use general purpose images across multiple boards and generations of
CPUs. Since the use-case tends to have a lot to say about which drivers
are needed - and we don't know what the use case will be - we serve users
best, IMO, but providing a highly functional kernel out of the box, and
enable them to tailor it themselves if they need a minimal image. This in
turn simplifies our maintenance and support effort through the use of the
intel-common package arch for the Linux kernel.
This particular driver challenges that vision, and there will be others,
but I don't think it defeats it. Worst case we have to drop gma500 from
the intel common kernel and build emenlow as an independent BSP. For now,
the blacklist seems like a reasonable workaround to maintain the
advantages of the common kernel mechanism.
At least, that's my take on it.
Thoughts?
--
Darren
Tom
Nitin
Nitin
Tom
Fixes Bug:
[YOCTO #6807]
Signed-off-by: Nitin A Kamble nitin.a.kam...@intel.com
---
meta-crownbay/recipes-kernel/kmod/kmod_git.bbappend | 3 +++
1 file changed, 3 insertions(+)
create mode 100644
meta-crownbay/recipes-kernel/kmod/kmod_git.bbappend
diff --git a/meta-crownbay/recipes-kernel/kmod/kmod_git.bbappend
b/meta-crownbay/recipes-kernel/kmod/kmod_git.bbappend
new file mode 100644
index 000..56d8fcb
--- /dev/null
+++ b/meta-crownbay/recipes-kernel/kmod/kmod_git.bbappend
@@ -0,0 +1,3 @@
+do_install_append () {
+ echo blacklist gma500_gfx
${D}${sysconfdir}/modprobe.d/prohibit_gma500_gfx.conf
+}
--
Darren Hart
Intel Open Source Technology Center
--
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [Patch v2 00/11] machinesetuptool commits
On 10 October 2014 22:18, Darren Hart dvh...@linux.intel.com wrote: The primary issue with eliminating the defaults from intel-corei7-64 and providing the default via machinesetuptool, is we then make machinesetuptool a requirement for that BSP for basic functionality. That isn't acceptable in my opinion. Agreed. The BSP should have sane defaults, and if a particular user wants to use machinesetup for a particular machine then that can override the defaults. But there should be sane (has keyboard, no touchscreen) defaults for the intel BSP. Ross -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [PATCH 1/3] crownbay-noemgd: disable the gma500_gfx module
On Fri, 2014-10-10 at 14:14 -0700, Darren Hart wrote:
On 10/10/14, 12:00, Tom Zanussi tom.zanu...@intel.com wrote:
On Fri, 2014-10-10 at 12:46 -0500, Kamble, Nitin A wrote:
On 10/10/14, 10:31 AM, Zanussi, Tom tom.zanu...@intel.com wrote:
On Fri, 2014-10-10 at 12:25 -0500, Kamble, Nitin A wrote:
On 10/10/14, 6:37 AM, Zanussi, Tom tom.zanu...@intel.com wrote:
On Thu, 2014-10-09 at 15:11 -0700, nitin.a.kam...@intel.com wrote:
From: Nitin A Kamble nitin.a.kam...@intel.com
The gmx500 graphics driver does not work on this BSP, but it takes
the ownership of the graphics hardware at boot time, blocking
other
drivers from using the graphics hardware.
Fix the issue by blacklisting the gma500_gfx kernel module in the
kmod
configuration, so that it doesn't get loaded at boot time.
Is this really the right way to do this? It will only work if
CONFIG_XXX=m. If m-y at some point, the whole .bbappend becomes
useless at best.
That is why the gma500 is converted from y to m. And with the common
kernel,
It should be m anyway. If you have better way to solve you can share.
Why not a config fragment that turns it off for that BSP?
The more general question is whether the common kernel mandates
everything be 'm' for this reason.
Tom
This will be going backwards. We are trying to consolidate kernel and
What seems backwards to me is starting with a broken config and using a
band-aid to fix the brokenness.
BSPs.
And this suggested approach will make a separate kernel for this BSP.
The common kernel has lot of drivers enabled. And very few of them will
be
actually used on any particular BSP. Not using kernel modules for these
many
drivers will be insane.
I guess I need to understand the new model where creating an embedded
system that only includes what it needs and which therefore doesn't need
to be a module is considered insane.
So what you're saying is that not only does everything in an Intel BSP
need to be configured as m, but also that an Intel BSP can't touch the
kernel, not even configuration.
Well, perhaps we need to sync up on this. We have a goal/vision of
simplifying what is a lot of per-board BSPs where it isn't necessary.
Since we don't know how each BSP is going to be used, we find we're often
adding USB drivers, etc. to the kernel configurations. To avoid a huge
bzImage, we do these as modules wherever feasible. The Linux kernel has
excellent support for Intel Architecture, which makes pervasive use of
enumerable and self describing buses and devices - this makes it possible
to use general purpose images across multiple boards and generations of
CPUs. Since the use-case tends to have a lot to say about which drivers
are needed - and we don't know what the use case will be - we serve users
best, IMO, but providing a highly functional kernel out of the box, and
enable them to tailor it themselves if they need a minimal image. This in
turn simplifies our maintenance and support effort through the use of the
intel-common package arch for the Linux kernel.
This particular driver challenges that vision, and there will be others,
but I don't think it defeats it. Worst case we have to drop gma500 from
the intel common kernel and build emenlow as an independent BSP. For now,
the blacklist seems like a reasonable workaround to maintain the
advantages of the common kernel mechanism.
At least, that's my take on it.
Thoughts?
Right, so I guess what it boils down to is that the whole common-kernel
philosophy is just fundamentally at odds with the concept of a BSP,
which is what we have here.
I don't object to the goal of a common image for all Intel, etc, but my
point was that if we do have a BSP, it should be allowed to modify the
kernel as needed, and making use of config fragments to directly address
the root problem seems the simplest and most straightforward way to do
that.
If the assumption here is that a dedicated crownbay BSP is going away
soon, then I have no problem pulling in whatever expedient hack works on
the grounds that it's temporary.
Tom
--
Darren
Tom
Nitin
Nitin
Tom
Fixes Bug:
[YOCTO #6807]
Signed-off-by: Nitin A Kamble nitin.a.kam...@intel.com
---
meta-crownbay/recipes-kernel/kmod/kmod_git.bbappend | 3 +++
1 file changed, 3 insertions(+)
create mode 100644
meta-crownbay/recipes-kernel/kmod/kmod_git.bbappend
diff --git a/meta-crownbay/recipes-kernel/kmod/kmod_git.bbappend
b/meta-crownbay/recipes-kernel/kmod/kmod_git.bbappend
new file mode 100644
index 000..56d8fcb
--- /dev/null
+++ b/meta-crownbay/recipes-kernel/kmod/kmod_git.bbappend
@@ -0,0 +1,3 @@
+do_install_append () {
+echo blacklist gma500_gfx
${D}${sysconfdir}/modprobe.d/prohibit_gma500_gfx.conf
+}
Re: [meta-intel] [Patch v2 00/11] machinesetuptool commits
On 10/10/14, 2:18 PM, Darren Hart dvh...@linux.intel.com wrote: On 10/10/14, 11:46, Kamble, Nitin A nitin.a.kam...@intel.com wrote: On 10/10/14, 9:40 AM, Darren Hart dvh...@linux.intel.com wrote: Another concern is the statement below about not allowing for a default configuration. Like other recent changes to meta-intel, this should be an opt-in thing, and as such, the BSPs need to be able to provide defaults. The intel-corei7-64 BSP works well as it is for a number of Intel platforms, and people using those may prefer not to use the machinesetuptool. As mentioned earlier, it was needed for the reconfiguration of images. The target machine which is configured as a default target machine can be used for this purpose. Which makes the tool transparent to them. So I am not seeing any significant issue here. I think ability to reconfigure an image is a great benefit for development and testing. The primary issue with eliminating the defaults from intel-corei7-64 and providing the default via machinesetuptool, is we then make machinesetuptool a requirement for that BSP for basic functionality. That isn't acceptable in my opinion. So what is the proposal? Disable machinesetuptool by default, and enable it if you need it? Nitin -- Darren Hart Intel Open Source Technology Center -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
