Re: [yocto] is there a list of yocto-supported dev kits somewhere?
On Thu, 28 Aug 2014, Jeff Osier-Mixon wrote: I think the machines list is a great start, http://layers.openembedded.org/layerindex/branch/master/machines/?q= but it really lists actual machines, not dev kits. There isn't any way to see immediately from that list which are $99 dev boards and which are $ reference kits from the manufacturers. I think Robert is right that a list of inexpensive YP-supported boards would be extremely useful. I'll try to create such a list in the near future. that is kinda what i was after. i realize it's an open-ended request, but it would be great if there was a list of recommended dev kits representing various architectures/processors that people new to YP could purchase for experimentation, *knowing* that those dev kits had a YP build that would work out of the box. not necessarily technically complete, but that it would just boot and let them start playing. and as i once suggested (and jefro clearly appreciates), at this point, dev kits like that should rarely cost more than a couple hundred dollars. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] bitbake svn fetch download folder conflicts
On Fri, Aug 29, 2014 at 1:22 PM, Thomas Roos tho...@roosesweb.de wrote: Hi, I have several recipes checkout from one svn repo (same and other subfolders) - there are sometimes svn command conflicts. I guess it's because all svn data is stored in ONE FOLDER eg. downloads/svn/ip/reponame/folder and concurred svn command instances access this folder at the same time. Is there an solution for this?For instance an parameter to specify a tmp folder for an svn repo. Or global option to store svn repos locally by recipe names they used in. any help would be wonderful! thank you, cheers Thomas P.S: think of same svn subfolders with different revisions as well!!! not a very helpful answer... but i have faced the same issue and just created artificial dependencies to avoid the 2 fetch tasks to run concurrently... e.g. if x.bb and y.bb both fetch from same SVN repo, in y.bb: do_fetch[depends] += x:do_fetch it's a poor's man workaround... but that might help.. cheers -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [OE-core] [RFT] Moving on from eglibc to glibc 2.20
On Thu, 2014-08-28 at 18:46 -0700, Khem Raj wrote: On Thu, Aug 28, 2014 at 5:41 PM, Khem Raj raj.k...@gmail.com wrote: reproduced. will apprise as I have some fix. OK pushed another patch to the contrib tree that should take care of both xf86-input-synaptics xf86-input-vmmouse https://autobuilder.yoctoproject.org/main/builders/nightly-fsl-arm/builds/17/steps/BuildImages/logs/stdio xf86-video-imxfb has the same issue and will need the same fix. Otavio cc'd... Cheers, Richard -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [OE-core] [RFT] Moving on from eglibc to glibc 2.20
On Thu, 2014-08-28 at 18:46 -0700, Khem Raj wrote: On Thu, Aug 28, 2014 at 5:41 PM, Khem Raj raj.k...@gmail.com wrote: reproduced. will apprise as I have some fix. OK pushed another patch to the contrib tree that should take care of both xf86-input-synaptics xf86-input-vmmouse Also, meta-fsl-ppc fails: https://autobuilder.yoctoproject.org/main/builders/nightly-fsl-ppc/builds/17/steps/BuildImages/logs/stdio with a do_compile glibc failure. Cheers, Richard -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] is there a list of yocto-supported dev kits somewhere?
I think this is a great idea and I volunteer to help with the effort. that is kinda what i was after. i realize it's an open-ended request, but it would be great if there was a list of recommended dev kits representing various architectures/processors that people new to YP could purchase for experimentation, *knowing* that those dev kits had a YP build that would work out of the box. not necessarily technically complete, but that it would just boot and let them start playing. The work out of the box part is the tricky one. Unfortunately, many YP BSP layers do not include instructions on what to do after the build has completed. If you don't know what to do with boot loader and kernel images, flattened device tree files, root file system archives and images then you are at a loss. Commonly the boards also require a special boot media partitioning and the like. While this type of info should be in the BSP readme files I think it would be good to have step by step instructions that gets one from setting up the build environment to building and creating bootable media for each board. Cheers, Rudi -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] is there a list of yocto-supported dev kits somewhere?
On Fri, 29 Aug 2014, Rudolf Streif wrote: I think this is a great idea and I volunteer to help with the effort. that is kinda what i was after. i realize it's an open-ended request, but it would be great if there was a list of recommended dev kits representing various architectures/processors that people new to YP could purchase for experimentation, *knowing* that those dev kits had a YP build that would work out of the box. not necessarily technically complete, but that it would just boot and let them start playing. The work out of the box part is the tricky one. Unfortunately, many YP BSP layers do not include instructions on what to do after the build has completed. If you don't know what to do with boot loader and kernel images, flattened device tree files, root file system archives and images then you are at a loss. Commonly the boards also require a special boot media partitioning and the like. exactly true, but without that final bit of information, i contend that the YP build is utterly useless unless the developer is told what to do with the final image objects. While this type of info should be in the BSP readme files I think it would be good to have step by step instructions that gets one from setting up the build environment to building and creating bootable media for each board. and those step-by-step instructions don't need to be terribly verbose. remember, you're not trying to explain how to use YP; you're simply summarizing what it takes to get it running on a particular dev kit. all of that should fit on a single page at most. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] is there a list of yocto-supported dev kits somewhere?
Am 29.08.2014 18:01, schrieb Robert P. J. Day: On Fri, 29 Aug 2014, Rudolf Streif wrote: I think this is a great idea and I volunteer to help with the effort. that is kinda what i was after. i realize it's an open-ended request, but it would be great if there was a list of recommended dev kits representing various architectures/processors that people new to YP could purchase for experimentation, *knowing* that those dev kits had a YP build that would work out of the box. not necessarily technically complete, but that it would just boot and let them start playing. The work out of the box part is the tricky one. Unfortunately, many YP BSP layers do not include instructions on what to do after the build has completed. If you don't know what to do with boot loader and kernel images, flattened device tree files, root file system archives and images then you are at a loss. Commonly the boards also require a special boot media partitioning and the like. exactly true, but without that final bit of information, i contend that the YP build is utterly useless unless the developer is told what to do with the final image objects. While this type of info should be in the BSP readme files I think it would be good to have step by step instructions that gets one from setting up the build environment to building and creating bootable media for each board. and those step-by-step instructions don't need to be terribly verbose. remember, you're not trying to explain how to use YP; you're simply summarizing what it takes to get it running on a particular dev kit. all of that should fit on a single page at most. Robert Nelson has a good collection for ARM-Devkits in his eewiki: https://eewiki.net/display/linuxonarm/Home Maybe that could be a good starting point. rday -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-security][PATCH] tripwire: ppc64 build failure.
| configure: error: /bin/sh ./config.sub powerpc64-poky-linux failed
config.sub did not understand the powerpc64 par.
this patch adds that understanding.
Signed-off-by: Armin Kuster akuster...@gmail.com
---
.../tripwire/files/tripwire_add_ppc64.patch| 36 ++
recipes-security/tripwire/tripwire_2.4.2.2.bb | 1 +
2 files changed, 37 insertions(+)
create mode 100644 recipes-security/tripwire/files/tripwire_add_ppc64.patch
diff --git a/recipes-security/tripwire/files/tripwire_add_ppc64.patch
b/recipes-security/tripwire/files/tripwire_add_ppc64.patch
new file mode 100644
index 000..374e9ed
--- /dev/null
+++ b/recipes-security/tripwire/files/tripwire_add_ppc64.patch
@@ -0,0 +1,36 @@
+tripwire:
+
+Powerpc64 is not supported in the current tripwier release.
+
+ configure: error: /bin/sh ./config.sub powerpc64-poky-linux failed
+ | Configure failed. The contents of all config.log files follows to aid
debugging
+
+Submitted upstream to Tripwire devel mailing list
+
+http://sourceforge.net/p/tripwire/mailman/message/32776415/
+
+Signed-off-By: Armin Kuster akuster...@gmail.com
+
+
+Index: tripwire-2.4.2.2-src/config.sub
+===
+--- tripwire-2.4.2.2-src.orig/config.sub
tripwire-2.4.2.2-src/config.sub
+@@ -233,7 +233,7 @@ case $basic_machine in
+ | alpha | alphaev[4-8] | alphaev56 | alphapca5[67] \
+ | alphaev6[78] \
+ | we32k | ns16k | clipper | i370 | sh | sh[34] \
+- | powerpc | powerpcle |
++ | powerpc | powerpcle | powerpc64 \
+ | 1750a | dsp16xx | pdp10 | pdp11 \
+ | mips16 | mips64 | mipsel | mips64el \
+ | mips64orion | mips64orionel | mipstx39 | mipstx39el \
+@@ -280,7 +280,7 @@ case $basic_machine in
+ | we32k-* | cydra-* | ns16k-* | pn-* | np1-* | xps100-* \
+ | clipper-* | orion-* \
+ | sparclite-* | pdp10-* | pdp11-* | sh-* | sh[34]-* | sh[34]eb-* \
+-| powerpc-* | powerpcle-* | sparc64-* | sparcv9-* | sparcv9b-* |
sparc86x-* \
++| powerpc-* | powerpcle-* | powerpc64-* | sparc64-* | sparcv9-* |
sparcv9b-* | sparc86x-* \
+ | mips16-* | mips64-* | mipsel-* \
+ | mips64el-* | mips64orion-* | mips64orionel-* \
+ | mips64vr4100-* | mips64vr4100el-* | mips64vr4300-* |
mips64vr4300el-* \
diff --git a/recipes-security/tripwire/tripwire_2.4.2.2.bb
b/recipes-security/tripwire/tripwire_2.4.2.2.bb
index ad5363d..b9dc01c 100644
--- a/recipes-security/tripwire/tripwire_2.4.2.2.bb
+++ b/recipes-security/tripwire/tripwire_2.4.2.2.bb
@@ -13,6 +13,7 @@ SRC_URI =
${SOURCEFORGE_MIRROR}/project/${BPN}/${BPN}-src/${BPN}-${PV}/${BPN}-$
file://twcfg.txt \
file://twinstall.sh \
file://twpol-yocto.txt \
+ file://tripwire_add_ppc64.patch \
SRC_URI[md5sum] = 2462ea16fb0b5ae810471011ad2f2dd6
SRC_URI[sha256sum] =
e09a7bdca9302e704cc62067399e0b584488f825b0e58c82ad6d54cd2e899fad
--
1.9.1
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [OE-core] [RFT] Moving on from eglibc to glibc 2.20
On Fri, Aug 29, 2014 at 5:18 AM, Richard Purdie richard.pur...@linuxfoundation.org wrote: On Thu, 2014-08-28 at 18:46 -0700, Khem Raj wrote: On Thu, Aug 28, 2014 at 5:41 PM, Khem Raj raj.k...@gmail.com wrote: reproduced. will apprise as I have some fix. OK pushed another patch to the contrib tree that should take care of both xf86-input-synaptics xf86-input-vmmouse https://autobuilder.yoctoproject.org/main/builders/nightly-fsl-arm/builds/17/steps/BuildImages/logs/stdio xf86-video-imxfb has the same issue and will need the same fix. Otavio cc'd... I have sent a patch to meta-fsl-arm for this Cheers, Richard -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [OE-core] [RFT] Moving on from eglibc to glibc 2.20
On Fri, Aug 29, 2014 at 5:20 AM, Richard Purdie richard.pur...@linuxfoundation.org wrote: On Thu, 2014-08-28 at 18:46 -0700, Khem Raj wrote: On Thu, Aug 28, 2014 at 5:41 PM, Khem Raj raj.k...@gmail.com wrote: reproduced. will apprise as I have some fix. OK pushed another patch to the contrib tree that should take care of both xf86-input-synaptics xf86-input-vmmouse Also, meta-fsl-ppc fails: https://autobuilder.yoctoproject.org/main/builders/nightly-fsl-ppc/builds/17/steps/BuildImages/logs/stdio with a do_compile glibc failure. I have fixed this. The patchset is updated on the contrib tree. Cheers, Richard -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [OE-core] [RFT] Moving on from eglibc to glibc 2.20
On Fri, Aug 29, 2014 at 3:39 AM, Richard Purdie richard.pur...@linuxfoundation.org wrote: On Thu, 2014-08-28 at 18:46 -0700, Khem Raj wrote: On Thu, Aug 28, 2014 at 5:41 PM, Khem Raj raj.k...@gmail.com wrote: reproduced. will apprise as I have some fix. OK pushed another patch to the contrib tree that should take care of both xf86-input-synaptics xf86-input-vmmouse Thanks. I'm having one heck of a problem unentangling all the different build failures (from these and other patches) but this one looks like glibc: https://autobuilder.yoctoproject.org/main/builders/poky-tiny/builds/18/steps/BuildImages/logs/stdio Trying to reproduce it locally. Once I have, I will update. Cheers, Richard -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [OE-core] [RFT] Moving on from eglibc to glibc 2.20
On Fri, Aug 29, 2014 at 5:01 PM, Khem Raj raj.k...@gmail.com wrote: On Fri, Aug 29, 2014 at 3:39 AM, Richard Purdie richard.pur...@linuxfoundation.org wrote: On Thu, 2014-08-28 at 18:46 -0700, Khem Raj wrote: On Thu, Aug 28, 2014 at 5:41 PM, Khem Raj raj.k...@gmail.com wrote: reproduced. will apprise as I have some fix. OK pushed another patch to the contrib tree that should take care of both xf86-input-synaptics xf86-input-vmmouse Thanks. I'm having one heck of a problem unentangling all the different build failures (from these and other patches) but this one looks like glibc: https://autobuilder.yoctoproject.org/main/builders/poky-tiny/builds/18/steps/BuildImages/logs/stdio Trying to reproduce it locally. Once I have, I will update. Richard I have fixed this too and pushed the updates to same pull tree. Please give it another whirl -Khem -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [OE-core] [RFT] Moving on from eglibc to glibc 2.20
On Fri, Aug 29, 2014 at 4:59 PM, Khem Raj raj.k...@gmail.com wrote: On Fri, Aug 29, 2014 at 5:18 AM, Richard Purdie richard.pur...@linuxfoundation.org wrote: On Thu, 2014-08-28 at 18:46 -0700, Khem Raj wrote: On Thu, Aug 28, 2014 at 5:41 PM, Khem Raj raj.k...@gmail.com wrote: reproduced. will apprise as I have some fix. OK pushed another patch to the contrib tree that should take care of both xf86-input-synaptics xf86-input-vmmouse https://autobuilder.yoctoproject.org/main/builders/nightly-fsl-arm/builds/17/steps/BuildImages/logs/stdio xf86-video-imxfb has the same issue and will need the same fix. Otavio cc'd... I have sent a patch to meta-fsl-arm for this Until its installed, the patch is here http://patchwork.openembedded.org/patch/79443/ -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[linux-yocto] [PATCHv2 4/6] pinctrl-baytrail: unmap interrupt when free the gpio pin
From: Chew, Kean Ho kean.ho.c...@intel.com In to_irq() callback, we create the hwirq to linux irq mapping for the requested GPIO pin. Hence, we unamp the mapping when the gpio pin is being released. Signed-off-by: Chew, Kean Ho kean.ho.c...@intel.com Signed-off-by: Chew, Chiau Ee chiau.ee.c...@intel.com Signed-off-by: Sreeju Selvaraj sreeju.armughanx.selva...@intel.com --- drivers/pinctrl/pinctrl-baytrail.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/pinctrl/pinctrl-baytrail.c b/drivers/pinctrl/pinctrl-baytrail.c index ea17f0d..5dee6d7 100644 --- a/drivers/pinctrl/pinctrl-baytrail.c +++ b/drivers/pinctrl/pinctrl-baytrail.c @@ -196,11 +196,14 @@ static void byt_gpio_free(struct gpio_chip *chip, unsigned offset) struct byt_gpio *vg = to_byt_gpio(chip); void __iomem *reg = byt_gpio_reg(vg-chip, offset, BYT_CONF0_REG); u32 value; + unsigned int virq; /* clear interrupt triggering */ value = readl(reg); value = ~(BYT_TRIG_POS | BYT_TRIG_NEG | BYT_TRIG_LVL); writel(value, reg); + virq = irq_find_mapping(vg-domain, offset); + irq_dispose_mapping(virq); pm_runtime_put(vg-pdev-dev); } -- 1.9.1 -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
[linux-yocto] [PATCHv2 3/6] pinctrl-baytrail: add function mux checking in gpio pin request
From: Chew, Kean Ho kean.ho.c...@intel.com
The requested gpio pin must has the func_pin_mux field set
to GPIO function by BIOS/FW in advanced. Else, the gpio pin
request would fail. This is to ensure that we do not expose
any gpio pins which shall be used for alternate functions,
for eg: wakeup pin, I/O interfaces for LPSS, etc.
Signed-off-by: Chew, Kean Ho kean.ho.c...@intel.com
Signed-off-by: Chew, Chiau Ee chiau.ee.c...@intel.com
Reviewed-by: Darren Hart dvh...@linux.intel.com
Signed-off-by: Linus Walleij linus.wall...@linaro.org
(cherry picked from commit 42bd00706ce95d74ad6ebcb8528ee1fbbb992f6a)
Signed-off-by: Chang Rebecca Swee Fun rebecca.swee.fun.ch...@intel.com
---
drivers/pinctrl/pinctrl-baytrail.c | 42 +++---
1 file changed, 39 insertions(+), 3 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-baytrail.c
b/drivers/pinctrl/pinctrl-baytrail.c
index 2832576..ea17f0d 100644
--- a/drivers/pinctrl/pinctrl-baytrail.c
+++ b/drivers/pinctrl/pinctrl-baytrail.c
@@ -61,6 +61,10 @@
#define BYT_NGPIO_NCORE28
#define BYT_NGPIO_SUS 44
+#define BYT_SCORE_ACPI_UID 1
+#define BYT_NCORE_ACPI_UID 2
+#define BYT_SUS_ACPI_UID 3
+
/*
* Baytrail gpio controller consist of three separate sub-controllers called
* SCORE, NCORE and SUS. The sub-controllers are identified by their acpi UID.
@@ -103,17 +107,17 @@ static unsigned const sus_pins[BYT_NGPIO_SUS] = {
static struct pinctrl_gpio_range byt_ranges[] = {
{
- .name = 1, /* match with acpi _UID in probe */
+ .name = BYT_SCORE_ACPI_UID, /* match with acpi _UID in probe */
.npins = BYT_NGPIO_SCORE,
.pins = score_pins,
},
{
- .name = 2,
+ .name = BYT_NCORE_ACPI_UID,
.npins = BYT_NGPIO_NCORE,
.pins = ncore_pins,
},
{
- .name = 3,
+ .name = BYT_SUS_ACPI_UID,
.npins = BYT_NGPIO_SUS,
.pins = sus_pins,
},
@@ -146,9 +150,41 @@ static void __iomem *byt_gpio_reg(struct gpio_chip *chip,
unsigned offset,
return vg-reg_base + reg_offset + reg;
}
+static bool is_special_pin(struct byt_gpio *vg, unsigned offset)
+{
+ /* SCORE pin 92-93 */
+ if (!strcmp(vg-range-name, BYT_SCORE_ACPI_UID)
+ offset = 92 offset = 93)
+ return true;
+
+ /* SUS pin 11-21 */
+ if (!strcmp(vg-range-name, BYT_SUS_ACPI_UID)
+ offset = 11 offset = 21)
+ return true;
+
+ return false;
+}
+
static int byt_gpio_request(struct gpio_chip *chip, unsigned offset)
{
struct byt_gpio *vg = to_byt_gpio(chip);
+ void __iomem *reg = byt_gpio_reg(chip, offset, BYT_CONF0_REG);
+ u32 value;
+ bool special;
+
+ /*
+* In most cases, func pin mux 000 means GPIO function.
+* But, some pins may have func pin mux 001 represents
+* GPIO function. Only allow user to export pin with
+* func pin mux preset as GPIO function by BIOS/FW.
+*/
+ value = readl(reg) BYT_PIN_MUX;
+ special = is_special_pin(vg, offset);
+ if ((special value != 1) || (!special value)) {
+ dev_err(vg-pdev-dev,
+ pin %u cannot be used as GPIO.\n, offset);
+ return -EINVAL;
+ }
pm_runtime_get(vg-pdev-dev);
--
1.9.1
--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto
[linux-yocto] [PATCHv2 2/6] x86/byt: enable board file for Baytrail LPSS PCI mode
From: Chang Rebecca Swee Fun rebecca.swee.fun.ch...@intel.com
This commit enables the following:
- register SPI slave
- fix device name string for clkdev registration
- insert kernel module param to allow user to disable the BYT
PCI board file
Signed-off-by: Chew Chiau Ee chiau.ee.c...@intel.com
Signed-off-by: Maurice Petallo mauricex.r.peta...@intel.com
Signed-off-by: Chang Rebecca Swee Fun rebecca.swee.fun.ch...@intel.com
---
arch/x86/Kconfig | 9 +++-
arch/x86/platform/Makefile| 3 ++
arch/x86/platform/byt/Makefile| 1 +
arch/x86/platform/byt/byt-board.c | 92 +++
4 files changed, 104 insertions(+), 1 deletion(-)
create mode 100644 arch/x86/platform/byt/Makefile
create mode 100644 arch/x86/platform/byt/byt-board.c
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index f92273e..7a72641 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -460,7 +460,7 @@ config X86_MDFLD
select MFD_INTEL_MSIC
---help---
Medfield is Intel's Low Power Intel Architecture (LPIA) based Moblin
- Internet Device(MID) platform.
+ Internet Device(MID) platform.
Unlike standard x86 PCs, Medfield does not have many legacy devices
nor standard legacy replacement devices/features. e.g. Medfield does
not contain i8259, i8254, HPET, legacy BIOS, most of the io ports.
@@ -478,6 +478,13 @@ config X86_INTEL_LPSS
things like clock tree (common clock framework) and pincontrol
which are needed by the LPSS peripheral drivers.
+config BYT_LPSS_BRD
+ bool PCI mode LPSS support on BYT
+ depends on X86_INTEL_LPSS
+ ---help---
+ This option is needed if were to use Intel BayTrail LPSS in
+ PCI mode.
+
config X86_RDC321X
bool RDC R-321x SoC
depends on X86_32
diff --git a/arch/x86/platform/Makefile b/arch/x86/platform/Makefile
index 01e0231..da0017b 100644
--- a/arch/x86/platform/Makefile
+++ b/arch/x86/platform/Makefile
@@ -11,3 +11,6 @@ obj-y += sfi/
obj-y += ts5500/
obj-y += visws/
obj-y += uv/
+ifeq ($(CONFIG_BYT_LPSS_BRD),y)
+obj-y += byt/
+endif
diff --git a/arch/x86/platform/byt/Makefile b/arch/x86/platform/byt/Makefile
new file mode 100644
index 000..2d4af86
--- /dev/null
+++ b/arch/x86/platform/byt/Makefile
@@ -0,0 +1 @@
+obj-y+= byt-board.o
diff --git a/arch/x86/platform/byt/byt-board.c
b/arch/x86/platform/byt/byt-board.c
new file mode 100644
index 000..95db7a1
--- /dev/null
+++ b/arch/x86/platform/byt/byt-board.c
@@ -0,0 +1,92 @@
+#include linux/init.h
+#include linux/module.h
+#include linux/device.h
+#include linux/clk.h
+#include linux/clkdev.h
+#include linux/clk-provider.h
+#include linux/spi/spidev.h
+#include linux/spi/spi.h
+#include linux/spi/pxa2xx_spi.h
+#include linux/pwm.h
+
+static bool disable = 0;
+module_param(disable, bool, 0);
+MODULE_PARM_DESC(disable, set 1 to disable BYT brd file);
+
+static struct pxa2xx_spi_chip chip_data = {
+ .gpio_cs = -EINVAL,
+ .dma_burst_size = 32,
+};
+
+static struct spi_board_info byt_spi_slaves[] = {
+ {
+ .modalias = spidev,
+ .max_speed_hz = 5000,
+ .bus_num = 0,
+ .chip_select = 0,
+ .controller_data = chip_data,
+ .mode = SPI_MODE_0,
+ }
+};
+
+static int byt_spi_board_setup(void)
+{
+ int ret = -1;
+
+ /* Register the SPI devices */
+ if (!spi_register_board_info
+ (byt_spi_slaves, ARRAY_SIZE(byt_spi_slaves)))
+ ret = 0;
+
+ return ret;
+}
+
+static int byt_clk_setup(void)
+{
+ struct clk *clk;
+
+ /* Make clock tree required by the SPI driver */
+ clk = clk_register_fixed_rate(NULL, lpss_clk, NULL, CLK_IS_ROOT,
+ 1);
+ if (IS_ERR(clk))
+ return PTR_ERR(clk);
+
+ clk_register_clkdev(clk, hclk, :00:1e.0);
+
+ clk = clk_register_fixed_rate(NULL, spi_clk, lpss_clk, 0, 5000);
+ if (IS_ERR(clk))
+ return PTR_ERR(clk);
+
+ clk_register_clkdev(clk, NULL, :00:1e.5);
+
+ /* Make clock tree required by the PWM driver */
+ clk = clk_register_fixed_rate(NULL, pwm_clk, lpss_clk, 0, 2500);
+ if (IS_ERR(clk))
+ return PTR_ERR(clk);
+
+ clk_register_clkdev(clk, NULL, :00:1e.1);
+ clk_register_clkdev(clk, NULL, :00:1e.2);
+
+ return 0;
+}
+
+static int __init byt_board_init(void)
+{
+ int ret;
+
+ if (disable)
+ return 0;
+
+ ret = byt_clk_setup();
+ if (ret)
+ goto exit;
+
+ ret = byt_spi_board_setup();
+ if (ret)
+ goto exit;
+
+exit:
+ return ret;
+}
+arch_initcall(byt_board_init);
+MODULE_LICENSE(GPL);
--
1.9.1
--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
[linux-yocto] [PATCHv2 5/6] pinctrl-baytrail: enable platform device in the absent of ACPI enumeration
From: Chew, Kean Ho kean.ho.c...@intel.com
This is to cater the need for non-ACPI system whereby
a platform device has to be created in order to bind
with the BYT Pinctrl GPIO platform driver.
Signed-off-by: Chew, Kean Ho kean.ho.c...@intel.com
Signed-off-by: Chew, Chiau Ee chiau.ee.c...@intel.com
Signed-off-by: Sreeju Selvaraj sreeju.armughanx.selva...@intel.com
---
drivers/pinctrl/Kconfig| 19 +++-
drivers/pinctrl/Makefile | 1 +
drivers/pinctrl/pinctrl-baytrail-dev.c | 159 +
drivers/pinctrl/pinctrl-baytrail.c | 19 +++-
include/linux/pinctrl/pinctrl-byt.h| 16
5 files changed, 209 insertions(+), 5 deletions(-)
create mode 100644 drivers/pinctrl/pinctrl-baytrail-dev.c
create mode 100644 include/linux/pinctrl/pinctrl-byt.h
diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index 6585b37..f3b850a 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -60,7 +60,7 @@ config PINCTRL_AT91
config PINCTRL_BAYTRAIL
bool Intel Baytrail GPIO pin control
- depends on GPIOLIB ACPI X86
+ depends on GPIOLIB X86
select IRQ_DOMAIN
help
driver for memory mapped GPIO functionality on Intel Baytrail
@@ -68,7 +68,22 @@ config PINCTRL_BAYTRAIL
Most pins are usually muxed to some other functionality by firmware,
so only a small amount is available for gpio use.
- Requires ACPI device enumeration code to set up a platform device.
+ For ACPI platform, it would require ACPI device enumeration code
+ to set up a platform device. Else, say yes to PINCTRL_BAYTRAIL_DEVICE
+ as well to set up platform device in the absent of ACPI enumeration
+ code.
+
+config PINCTRL_BAYTRAIL_DEVICE
+ bool Intel Baytrail GPIO pin control Platform Device Emulation
+ depends on PINCTRL_BAYTRAIL
+ help
+ This driver is to set up platform device in the absent of ACPI
+ enumeration.
+
+ Say yes for non-ACPI platform. This will enable the platform devices
+ to be created and bind with the BayTrail GPIO pin control platform
+ driver.
+
config PINCTRL_BCM2835
bool
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index 80f5239..66efd3d 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -17,6 +17,7 @@ obj-$(CONFIG_PINCTRL_AB8505) += pinctrl-ab8505.o
obj-$(CONFIG_PINCTRL_AT91) += pinctrl-at91.o
obj-$(CONFIG_PINCTRL_BCM2835) += pinctrl-bcm2835.o
obj-$(CONFIG_PINCTRL_BAYTRAIL) += pinctrl-baytrail.o
+obj-$(CONFIG_PINCTRL_BAYTRAIL_DEVICE) += pinctrl-baytrail-dev.o
obj-$(CONFIG_PINCTRL_IMX) += pinctrl-imx.o
obj-$(CONFIG_PINCTRL_IMX35)+= pinctrl-imx35.o
obj-$(CONFIG_PINCTRL_IMX51)+= pinctrl-imx51.o
diff --git a/drivers/pinctrl/pinctrl-baytrail-dev.c
b/drivers/pinctrl/pinctrl-baytrail-dev.c
new file mode 100644
index 000..6754753
--- /dev/null
+++ b/drivers/pinctrl/pinctrl-baytrail-dev.c
@@ -0,0 +1,159 @@
+/*
+ * pinctrl-baytrail-dev.c: BayTrail pinctrl GPIO Platform Device
+ *
+ * (C) Copyright 2013 Intel Corporation
+ * Author: Kean Ho, Chew (kean.ho.c...@intel.com)
+ *
+ * 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.
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/init.h
+#include linux/types.h
+#include linux/bitops.h
+#include linux/interrupt.h
+#include linux/platform_device.h
+#include linux/seq_file.h
+#include linux/pci.h
+#include linux/pinctrl/pinctrl-byt.h
+
+/* PCI Memory Base Access */
+#define PCI_DEVICE_ID_INTEL_BYT_PCU0x0f1c
+#define NO_REGISTER_SETTINGS (BIT(0) | BIT(1) | BIT(2))
+
+/* Offsets */
+#define SCORE_OFFSET 0x0
+#define NCORE_OFFSET 0x1000
+#define SUS_OFFSET 0x2000
+#define SCORE_END 0x72C
+#define NCORE_END 0x970
+#define SUS_END0x98C
+
+static struct byt_pinctrl_port byt_gpio_score_platform_data = {
+ .unique_id = 1,
+};
+
+static struct resource byt_gpio_score_resources[] = {
+ {
+ .start = 0x0,
+ .end= 0x0,
+ .flags = IORESOURCE_MEM,
+ .name = io-memory,
+ },
+ {
+ .start = 49,
+ .end= 49,
+ .flags = IORESOURCE_IRQ,
+ .name = irq,
+ }
+};
+
+static struct byt_pinctrl_port byt_gpio_ncore_platform_data = {
+ .unique_id = 2,
+};
+
+static struct resource byt_gpio_ncore_resources[] = {
+ {
+ .start = 0x0,
+ .end= 0x0,
+ .flags = IORESOURCE_MEM,
+ .name = io-memory,
+ },
+ {
+ .start = 48,
+ .end= 48,
+ .flags =
[linux-yocto] [PATCHv2 6/6] pinctrl-baytrail: setup IOAPIC interrupt for GPIO clusters on non-ACPI system
From: Chew, Kean Ho kean.ho.c...@intel.com
BayTrail GPIO NORTH, SOUTH and SUS clusters use IRQ48,
49 and 50 respectively. On non-ACPI system, we need
to setup IOAPIC RTE for device that use interrupt
beyond IRQ23.
Signed-off-by: Chew, Kean Ho kean.ho.c...@intel.com
Signed-off-by: Chew, Chiau Ee chiau.ee.c...@intel.com
Signed-off-by: Sreeju Selvaraj sreeju.armughanx.selva...@intel.com
---
drivers/pinctrl/pinctrl-baytrail.c | 37 +
1 file changed, 37 insertions(+)
diff --git a/drivers/pinctrl/pinctrl-baytrail.c
b/drivers/pinctrl/pinctrl-baytrail.c
index 7a313f1..954418f 100644
--- a/drivers/pinctrl/pinctrl-baytrail.c
+++ b/drivers/pinctrl/pinctrl-baytrail.c
@@ -448,6 +448,36 @@ static const struct irq_domain_ops byt_gpio_irq_ops = {
.map = byt_gpio_irq_map,
};
+#ifdef CONFIG_PINCTRL_BAYTRAIL_DEVICE
+static int byt_gpio_irq_enable(unsigned hwirq, struct platform_device *pdev)
+{
+ struct io_apic_irq_attr irq_attr;
+ struct device *dev = pdev-dev;
+ /*
+* Since PCI BIOS is not able to provide IRQ mapping to
+* IRQ24 and onward, we need register to ioapic directly
+* and hardcode pci-irq= hwirq
+*/
+ irq_attr.ioapic = mp_find_ioapic(hwirq);
+ if (irq_attr.ioapic 0) {
+ dev_err(pdev-dev,
+ Unable to locate IOAPIC for IRQ=%d\n, hwirq);
+ return irq_attr.ioapic;
+ }
+ irq_attr.ioapic_pin = hwirq;
+ irq_attr.trigger = 1; /* level */
+ irq_attr.polarity = 1; /* active low */
+ io_apic_set_pci_routing(dev, hwirq, irq_attr);
+ return 0;
+
+}
+#else
+static int byt_gpio_irq_enable(unsigned hwirq, struct platform_device *pdev)
+{
+ return 0;
+}
+#endif
+
static int byt_gpio_probe(struct platform_device *pdev)
{
struct byt_gpio *vg;
@@ -523,6 +553,11 @@ static int byt_gpio_probe(struct platform_device *pdev)
if (irq_rc irq_rc-start) {
hwirq = irq_rc-start;
gc-to_irq = byt_gpio_to_irq;
+ ret = byt_gpio_irq_enable(hwirq, pdev);
+ if (ret) {
+ dev_err(pdev-dev, failed to add GPIO to APIC\n);
+ return ret;
+ }
vg-domain = irq_domain_add_linear(NULL, gc-ngpio,
byt_gpio_irq_ops, vg);
@@ -534,8 +569,10 @@ static int byt_gpio_probe(struct platform_device *pdev)
irq_set_handler_data(hwirq, vg);
irq_set_chained_handler(hwirq, byt_gpio_irq_handler);
+#ifndef CONFIG_PINCTRL_BAYTRAIL_DEVICE
/* Register interrupt handlers for gpio signaled acpi events */
acpi_gpiochip_request_interrupts(gc);
+#endif
}
pm_runtime_enable(dev);
--
1.9.1
--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto
[linux-yocto] [PATCHv2 0/6] [3.10] Feature branch for Baytrail IO
From: Chang Rebecca Swee Fun rebecca.swee.fun.ch...@intel.com Hi all, Patchv2: This is the 2nd revision of the feature branch I have submitted yesterday. I have used the outdated board file for Baytrail in previous submission. I have updated the tree with a latest board file to enable DMA clock for Baytrail. Change log summary: x86/byt: enable board file for Baytrail LPSS PCI mode Update with new board file to enable LPIO DMA 1. Thanks and regards. Rebecca Patchv1: This is the rebased feature branch for valley island BSP. The purpose of this feature branch is to stage the Baytrail I/O specific patches that is not encouraged to be upstream, for example, board file. This tree also consists of Baytrail pinctrl code base which it is not upstream. I intend to create a new branch, named: valleyisland-io-3.0. The old version feature branch (valleyisland-io-1.0 and valleyisland-io-2.0) shall be removed once everything has lined up accordingly. Sorry that the valleyisland-io-2.0 was created and not used until now. For future backport commits, we will target to merge in standard/base instead of putting them in feature branch. Please review and if no further comments, please help to put this patches into new branch: valleyisland-io-3.0. Sorry for any incovenient caused. Thanks in advance. Rebecca The following changes since commit aa677a2d02677ec92d59a8c36d001cf2f5cf3260: usb/core: fix merge issue (2014-06-16 12:24:47 -0400) are available in the git repository at: git://git.yoctoproject.org/linux-yocto-contrib rebeccas/rebase-feature-branch http://git.yoctoproject.org/cgit.cgi/linux-yocto-contrib/log/?h=rebeccas/rebase-feature-branch Chang Rebecca Swee Fun (1): x86/byt: enable board file for Baytrail LPSS PCI mode Chew, Chiau Ee (1): x86/Kconfig: add PCI dependency for CONFIG_X86_INTEL_LPSS Chew, Kean Ho (4): pinctrl-baytrail: add function mux checking in gpio pin request pinctrl-baytrail: unmap interrupt when free the gpio pin pinctrl-baytrail: enable platform device in the absent of ACPI enumeration pinctrl-baytrail: setup IOAPIC interrupt for GPIO clusters on non-ACPI system arch/x86/Kconfig | 11 ++- arch/x86/platform/Makefile | 3 + arch/x86/platform/byt/Makefile | 1 + arch/x86/platform/byt/byt-board.c | 92 +++ drivers/pinctrl/Kconfig| 19 +++- drivers/pinctrl/Makefile | 1 + drivers/pinctrl/pinctrl-baytrail-dev.c | 159 + drivers/pinctrl/pinctrl-baytrail.c | 101 +++-- include/linux/pinctrl/pinctrl-byt.h| 16 9 files changed, 393 insertions(+), 10 deletions(-) create mode 100644 arch/x86/platform/byt/Makefile create mode 100644 arch/x86/platform/byt/byt-board.c create mode 100644 drivers/pinctrl/pinctrl-baytrail-dev.c create mode 100644 include/linux/pinctrl/pinctrl-byt.h -- 1.9.1 -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
[linux-yocto] yocto-kernel-tools
Hello, I am trying to use the yocto-kernel-tools and when I run make install it errors out. install: cannot stat ‘tools/generate_cfg’: No such file or directory there is no 'generate_cfg' file in the sources. What am I missing? regards, Armin -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] yocto-kernel-tools
On 14-08-29 02:36 PM, akuster808 wrote: Hello, I am trying to use the yocto-kernel-tools and when I run make install it errors out. install: cannot stat ‘tools/generate_cfg’: No such file or directory there is no 'generate_cfg' file in the sources. What am I missing? only that I deleted that in May .. and didn't update the Makefile. Fixed now! Bruce regards, Armin -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] KMETA branch/directory redux (yocto #5090)
On 08/07/2014 11:16 AM, Bruce Ashfield wrote: On Thu, Aug 7, 2014 at 10:27 AM, Peter A. Bigot p...@pabigot.com wrote: First, some yak shaving: If something goes wrong with linux-yocto's do_patch, it prints: | ERROR. Could not apply patches for beaglebone. |Patch failures can be resolved in the devshell (bitbake -c devshell linux-yocto) In fact, you can't, because meta/classes/devshell.bbclass has: addtask devshell after do_patch so there's a chicken/egg thing here because bitbake never gets to devshell. No idea how to fix that. Now: What goes wrong with do_patch for me ultimately turns out to be https://bugzilla.yoctoproject.org/show_bug.cgi?id=5090 biting me again a year after I filed and forgot it, because I set KMETA=yocto-3.14/meta because that's the branch name in my local kernel directory. Various kgit-* tools still want to use KMETA to name the directory as well as the branch, and they are not happy when KMETA isn't meta. I'm going to try to do a patch for that, if it's agreed that KMETA really does only name the branch and something else needs to propagate the directory name among all the scripts. I have an entire series that addresses issues like this. The work with 3.16 delayed sending anything out. When I'm back from holidays, I'll be sending out those changes. So by about the M3 milestone of 1.7, most everything should be sorted. It definitely isn't trivial to break the branch == directory rule that has been around for 7 years, but I think I've sorted through most of the wreckage now. I see there are some patches that have already been merged into yocto-kernel-tools for this. At a glance, there's still a construct that breaks my use case: I have branch names like yocto-3.14/meta and the pattern: if [ ! -d .$checkpoint_dir ]; then mv $checkpoint_dir .$checkpoint_dir fi does not work in this situation because there is no directory .yocto-3.14 into which yocto-3.14/meta can be moved. I'd hoped to have a chance to try out your solution before it got merged, but please do announce once the full set of changes is available so if there are problems we can get them resolved before the feature freeze. Thanks. Peter Before I do that, is that the intended behavior? I was going to add KMETA_DIR as the companion variable, and probably have all the meta_dir() shell functions in the *me scripts export that. It is the intended behaviour. Adding another variable isn't the right fix either, I'm deleting linux-yocto specific variables, not adding more. Logic to determine the right directory name has been added to the scripts, when the directory and branch don't match. Are patches to yocto-kernel-tools to be sent to this list? To the linux-yocto mailing list. Also, is there a reason all the support scripts are present in the meta/scripts directory of the KMETA branches, even though when you run bitbake the versions that come from kern-tools are the ones that are actually used? Their presence tricked me into thinking that the ones in the meta branch were what I should be patching They are there as a snapshot / reference. They can be used in a pinch to regenerate tree, based only on a clone of the tree. But the default is to use the ones from the tools .. since that is where changes get pushed first. Bruce Peter -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] KMETA branch/directory redux (yocto #5090)
On 14-08-29 03:09 PM, Peter A. Bigot wrote: On 08/07/2014 11:16 AM, Bruce Ashfield wrote: On Thu, Aug 7, 2014 at 10:27 AM, Peter A. Bigot p...@pabigot.com wrote: First, some yak shaving: If something goes wrong with linux-yocto's do_patch, it prints: | ERROR. Could not apply patches for beaglebone. |Patch failures can be resolved in the devshell (bitbake -c devshell linux-yocto) In fact, you can't, because meta/classes/devshell.bbclass has: addtask devshell after do_patch so there's a chicken/egg thing here because bitbake never gets to devshell. No idea how to fix that. Now: What goes wrong with do_patch for me ultimately turns out to be https://bugzilla.yoctoproject.org/show_bug.cgi?id=5090 biting me again a year after I filed and forgot it, because I set KMETA=yocto-3.14/meta because that's the branch name in my local kernel directory. Various kgit-* tools still want to use KMETA to name the directory as well as the branch, and they are not happy when KMETA isn't meta. I'm going to try to do a patch for that, if it's agreed that KMETA really does only name the branch and something else needs to propagate the directory name among all the scripts. I have an entire series that addresses issues like this. The work with 3.16 delayed sending anything out. When I'm back from holidays, I'll be sending out those changes. So by about the M3 milestone of 1.7, most everything should be sorted. It definitely isn't trivial to break the branch == directory rule that has been around for 7 years, but I think I've sorted through most of the wreckage now. I see there are some patches that have already been merged into Yep. Some work in progress that I didn't want to lose, rebasing some old patches into a larger series. yocto-kernel-tools for this. At a glance, there's still a construct that breaks my use case: I have branch names like yocto-3.14/meta and directory names or branch names ? the pattern: if [ ! -d .$checkpoint_dir ]; then mv $checkpoint_dir .$checkpoint_dir fi does not work in this situation because there is no directory .yocto-3.14 into which yocto-3.14/meta can be moved. I'm not looking for completely flexibility, since my statement of not introducing any new variables to broadcast the directory name holds. But within that bound, I'm willing to tweak things more. The construct is simply to hide the top level meta directory from the content branches, git status, etc. So it take a directory name of foo, which should be where the meta data is stored on the meta branch, and renames it .foo. What exactly are you using as a directory to hold the meta-data ? I'll run some extra tests to make sure I hit those cases, but I'll send the bulk of the changes regardless, since small incremental changes aren't issues post feature freeze. Bruce I'd hoped to have a chance to try out your solution before it got merged, but please do announce once the full set of changes is available so if there are problems we can get them resolved before the feature freeze. Thanks. Peter Before I do that, is that the intended behavior? I was going to add KMETA_DIR as the companion variable, and probably have all the meta_dir() shell functions in the *me scripts export that. It is the intended behaviour. Adding another variable isn't the right fix either, I'm deleting linux-yocto specific variables, not adding more. Logic to determine the right directory name has been added to the scripts, when the directory and branch don't match. Are patches to yocto-kernel-tools to be sent to this list? To the linux-yocto mailing list. Also, is there a reason all the support scripts are present in the meta/scripts directory of the KMETA branches, even though when you run bitbake the versions that come from kern-tools are the ones that are actually used? Their presence tricked me into thinking that the ones in the meta branch were what I should be patching They are there as a snapshot / reference. They can be used in a pinch to regenerate tree, based only on a clone of the tree. But the default is to use the ones from the tools .. since that is where changes get pushed first. Bruce Peter -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] KMETA branch/directory redux (yocto #5090)
On 14-08-29 03:31 PM, Peter A. Bigot wrote: On 08/29/2014 02:17 PM, Bruce Ashfield wrote: On 14-08-29 03:09 PM, Peter A. Bigot wrote: On 08/07/2014 11:16 AM, Bruce Ashfield wrote: On Thu, Aug 7, 2014 at 10:27 AM, Peter A. Bigot p...@pabigot.com wrote: First, some yak shaving: If something goes wrong with linux-yocto's do_patch, it prints: | ERROR. Could not apply patches for beaglebone. |Patch failures can be resolved in the devshell (bitbake -c devshell linux-yocto) In fact, you can't, because meta/classes/devshell.bbclass has: addtask devshell after do_patch so there's a chicken/egg thing here because bitbake never gets to devshell. No idea how to fix that. Now: What goes wrong with do_patch for me ultimately turns out to be https://bugzilla.yoctoproject.org/show_bug.cgi?id=5090 biting me again a year after I filed and forgot it, because I set KMETA=yocto-3.14/meta because that's the branch name in my local kernel directory. Various kgit-* tools still want to use KMETA to name the directory as well as the branch, and they are not happy when KMETA isn't meta. I'm going to try to do a patch for that, if it's agreed that KMETA really does only name the branch and something else needs to propagate the directory name among all the scripts. I have an entire series that addresses issues like this. The work with 3.16 delayed sending anything out. When I'm back from holidays, I'll be sending out those changes. So by about the M3 milestone of 1.7, most everything should be sorted. It definitely isn't trivial to break the branch == directory rule that has been around for 7 years, but I think I've sorted through most of the wreckage now. I see there are some patches that have already been merged into Yep. Some work in progress that I didn't want to lose, rebasing some old patches into a larger series. yocto-kernel-tools for this. At a glance, there's still a construct that breaks my use case: I have branch names like yocto-3.14/meta and directory names or branch names ? Branch names. I don't have a separate repository for each kernel release, so I encode that into the branch name. In the version currently in oe-core, the directory name was taken from the branch name with no ability to override it. gotcha .. and that's a valid use case. The new code should definitely handle that, it did in my tests .. so I'll run some more on my remaining commits (my queue is larger than what I've staged). the pattern: if [ ! -d .$checkpoint_dir ]; then mv $checkpoint_dir .$checkpoint_dir fi does not work in this situation because there is no directory .yocto-3.14 into which yocto-3.14/meta can be moved. I'm not looking for completely flexibility, since my statement of not introducing any new variables to broadcast the directory name holds. But within that bound, I'm willing to tweak things more. The construct is simply to hide the top level meta directory from the content branches, git status, etc. So it take a directory name of foo, which should be where the meta data is stored on the meta branch, and renames it .foo. What exactly are you using as a directory to hold the meta-data ? I don't particularly care what the directory name is; meta would be fine regardless of the branch name, if there's some way to communicate that to the infrastructure. Great. So they can definitely all be 'meta' as the directory name, or something else. The tools will figure it out, and use whatever name it happens to be. The point is that issuing a mv like: mv $checkpoint_dir .$checkpoint_dir without ensuring that the value of the variable doesn't contain path components is fragile. I'm not really clear on the goals of the It can use some extra sanity checking, but since it is searching out directories already on the disk to use, we do know that the contents of the variable are safe for on disk representation. construct, especially as the dot-qualified name didn't appear to be referenced again when I solved this locally. If that's true, why not just delete it? If there's some reason it needs to continue to exist in the filesystem, why not move it to .checkpoint_dir (as a bare name, not as the value of a variable)? The dot directory isn't used by the checkpoint scripts after that point, but it is used by most of the tools/scripts that follow. So it does need to stay around. There can technically be multiple meta data directories in a single tree, hence why the name of the directory is reused in the .name format. The point of the checkpoint restored directory is to make it available to each and every branch in the tree during processing, since the update, patching and configuration steps use that meta data to manipulate the tree while changing branches, etc. To make it globally available .. without needing to have it be part of those branches (i.e. committed and merged to the branches), making it untracked content solves the problem. And to make it so it
Re: [linux-yocto] KMETA branch/directory redux (yocto #5090)
On 08/29/2014 03:02 PM, Bruce Ashfield wrote: On 14-08-29 03:31 PM, Peter A. Bigot wrote: The point is that issuing a mv like: mv $checkpoint_dir .$checkpoint_dir without ensuring that the value of the variable doesn't contain path components is fragile. I'm not really clear on the goals of the It can use some extra sanity checking, but since it is searching out directories already on the disk to use, we do know that the contents of the variable are safe for on disk representation. That's not the issue. The issue is that if $checkpoint_dir is a/b/c/d, the path .a/b/c probably doesn't exist into which d can be moved. You'd have to do something like: mkdir -p .$(dirname $checkpoint_dir) mv $checkpoint_dir .$checkpoint_dir and even that wouldn't do the right thing in all cases. construct, especially as the dot-qualified name didn't appear to be referenced again when I solved this locally. If that's true, why not just delete it? If there's some reason it needs to continue to exist in the filesystem, why not move it to .checkpoint_dir (as a bare name, not as the value of a variable)? The dot directory isn't used by the checkpoint scripts after that point, but it is used by most of the tools/scripts that follow. So it does need to stay around. There can technically be multiple meta data directories in a single tree, hence why the name of the directory is reused in the .name format. The point of the checkpoint restored directory is to make it available to each and every branch in the tree during processing, since the update, patching and configuration steps use that meta data to manipulate the tree while changing branches, etc. To make it globally available .. without needing to have it be part of those branches (i.e. committed and merged to the branches), making it untracked content solves the problem. And to make it so it doesn't show up in 'git status', and so that we can continue to check out and work with the meta branch itself, making the directory a .meta name solves the problem. OK. At this stage I just want bitbake linux-yocto to work with branches that look like path hierarchies in workspaces that don't attempt to share build areas among multiple meta configurations. Any other capabilities hidden in yocto-kernel-tools are things I haven't encountered yet. I'll wait until everything's available to comment more. Peter -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] KMETA branch/directory redux (yocto #5090)
On 14-08-29 04:32 PM, Peter A. Bigot wrote: On 08/29/2014 03:02 PM, Bruce Ashfield wrote: On 14-08-29 03:31 PM, Peter A. Bigot wrote: The point is that issuing a mv like: mv $checkpoint_dir .$checkpoint_dir without ensuring that the value of the variable doesn't contain path components is fragile. I'm not really clear on the goals of the It can use some extra sanity checking, but since it is searching out directories already on the disk to use, we do know that the contents of the variable are safe for on disk representation. That's not the issue. The issue is that if $checkpoint_dir is a/b/c/d, the path .a/b/c probably doesn't exist into which d can be moved. You'd have to do something like: There aren't any checkpoint directories of that name, at least not valid ones. mkdir -p .$(dirname $checkpoint_dir) mv $checkpoint_dir .$checkpoint_dir and even that wouldn't do the right thing in all cases. I'm restricting what is valid, so I don't have to worry about the case of deeply nested directories. I only get the top level directory name, and rename it. The subdirs don't matter. construct, especially as the dot-qualified name didn't appear to be referenced again when I solved this locally. If that's true, why not just delete it? If there's some reason it needs to continue to exist in the filesystem, why not move it to .checkpoint_dir (as a bare name, not as the value of a variable)? The dot directory isn't used by the checkpoint scripts after that point, but it is used by most of the tools/scripts that follow. So it does need to stay around. There can technically be multiple meta data directories in a single tree, hence why the name of the directory is reused in the .name format. The point of the checkpoint restored directory is to make it available to each and every branch in the tree during processing, since the update, patching and configuration steps use that meta data to manipulate the tree while changing branches, etc. To make it globally available .. without needing to have it be part of those branches (i.e. committed and merged to the branches), making it untracked content solves the problem. And to make it so it doesn't show up in 'git status', and so that we can continue to check out and work with the meta branch itself, making the directory a .meta name solves the problem. OK. At this stage I just want bitbake linux-yocto to work with branches that look like path hierarchies in workspaces that don't attempt to share build areas among multiple meta configurations. Any other capabilities hidden in yocto-kernel-tools are things I haven't encountered yet. And it already will. I'll confirm with a test, but the changes I have don't care what you name the branch anymore. They just look at the disk and see what the top level directory is called, and use it as is. Bruce I'll wait until everything's available to comment more. Peter -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
