Re: [yocto] [meta-rockchip][PATCH v2 2/5] u-boot-rockchip: add
On Wed 2017-02-22 @ 10:06:23 PM, Eddie Cai wrote:
> Build Configuration:
> BB_VERSION= "1.32.0"
> BUILD_SYS = "x86_64-linux"
> NATIVELSBSTRING = "universal"
> TARGET_SYS= "arm-poky-linux-gnueabi"
> MACHINE = "firefly-rk3288"
> DISTRO= "poky"
> DISTRO_VERSION= "2.2.1"
> TUNE_FEATURES = "arm armv7ve vfp neon vfpv4 callconvention-hard
> cortexa17"
> TARGET_FPU= "hard"
> meta
> meta-poky
> meta-yocto-bsp= "HEAD:6a1f33cc40bfac33cf030fe41e1a8efd1e5fad6f"
> meta-rockchip =
> "review-uboot-gtpimg-v2:5e181d4e74c50e290b507b1a990b1517eaffcea6"
>
> BBLAYERS ?= " \
> ${BSPDIR}/src/poky/meta \
> ${BSPDIR}/src/poky/meta-poky \
> ${BSPDIR}/src/poky/meta-yocto-bsp \
> ${BSPDIR}/src/meta-rockchip \
I can't reproduce the issue you're seeing, and your meta-rockchip branch
sounds suspicious. In a completely fresh location with a fresh shell could you
please try the following?
$ mkdir -p ~/tmp/rockchip/layers
$ cd ~/tmp/rockchip/layers
$ git clone git://git.openembedded.org/openembedded-core
$ git clone git://git.openembedded.org/bitbake
$ git clone git://git.yoctoproject.org/meta-rockchip
$ cd meta-rockchip
$ git checkout devs/twoerner/feb-updates-2
$ cd ~/tmp/rockchip
$ . layers/openembedded-core/oe-init-build-env build layers/bitbake
$ echo "BBLAYERS += \"$HOME/tmp/rockchip/layers/meta-rockchip\"" >>
conf/bblayers.conf
set conf/local.conf to:
MACHINE ?= "firefly-rk3288"
DISTRO ?= "nodistro"
DL_DIR = "/opt/Downloads"
DEFAULTTUNE_rk3288 = "cortexa17hf-neon-vfpv4"
PACKAGE_CLASSES ?= "package_ipk"
EXTRA_IMAGE_FEATURES ?= "debug-tweaks"
USER_CLASSES ?= "buildstats image-mklibs image-prelink"
PATCHRESOLVE = "noop"
BB_DISKMON_DIRS = "\
STOPTASKS,${TMPDIR},1G,100K \
STOPTASKS,${DL_DIR},1G,100K \
STOPTASKS,${SSTATE_DIR},1G,100K \
STOPTASKS,/tmp,100M,100K \
ABORT,${TMPDIR},100M,1K \
ABORT,${DL_DIR},100M,1K \
ABORT,${SSTATE_DIR},100M,1K \
ABORT,/tmp,10M,1K"
PACKAGECONFIG_append_pn-qemu-native = " sdl"
PACKAGECONFIG_append_pn-nativesdk-qemu = " sdl"
ASSUME_PROVIDED += "libsdl-native"
CONF_VERSION = "1"
$ bitbake virtual/bootloader
The build configuration should look like:
Build Configuration:
BB_VERSION= "1.33.1"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING = "opensuse-42.2"
TARGET_SYS= "arm-oe-linux-gnueabi"
MACHINE = "firefly-rk3288"
DISTRO= "nodistro"
DISTRO_VERSION= "nodistro.0"
TUNE_FEATURES = "arm armv7ve vfp neon vfpv4 callconvention-hard
cortexa17"
TARGET_FPU= "hard"
meta = "master:65cfc8aca3ff7e39453977a0215a350d13cb85ef"
meta-rockchip =
"devs/twoerner/feb-updates-2:c252843cf2bf8326ccf2b552b59209f7a2ac3f16"
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] couple questions about kernel-dev manual, section 2.6, "emenlow" branch
still working my way through the kernel-dev manual, and a couple oddities in section 2.6. first, the example given uses the (alleged) standard/emenlow branch, which i'm pretty sure doesn't exist anymore, yes? if one is going to use an example, i suggest one base that example on one of the YP reference BSPs that's guaranteed to always exist, such as beagleboard or arm-versatile-926ejs. next, i'm assuming that one would be running those "git whatchanged" commands in the project directory, under tmp/work-shared//kernel-source, yes? it's just not made clear in that section where a reader would be doing those things. finally, section 2.6.1 reads: "Here is an example that looks at what has changed in the emenlow branch of the linux-yocto-3.19 kernel." what does the kernel version of 3.19 have to do with those git commands? how do those commands depend on the particular version of the linux-yocto recipe you're using? 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
[yocto] [PATCH] yocto-docs: kernel-dev, update "3.19" versions to "4.4"
Update the remaining references to kernel version 3.19 to version 4.4, restricted to the section "kernel-dev-common.xml". Signed-off-by: Robert P. J. Day --- if my earlier patch hasn't already been applied, this one can be folded in since it simply adds more "3.19" -> "4.4" updates to the same kernel-dev-common.xml file, which is already part of the commit message for that earlier patch. diff --git a/documentation/kernel-dev/kernel-dev-common.xml b/documentation/kernel-dev/kernel-dev-common.xml index a9aafd3..97e2a0b 100644 --- a/documentation/kernel-dev/kernel-dev-common.xml +++ b/documentation/kernel-dev/kernel-dev-common.xml @@ -645,8 +645,8 @@ recipe to your layer and give it a meaningful name. The name should include the version of the Linux kernel you are using (e.g. -linux-yocto-myproject_3.19.bb, -where "3.19" is the base version of the Linux kernel +linux-yocto-myproject_4.4.bb, +where "4.4" is the base version of the Linux kernel with which you would be working). In the same directory inside your layer, create a matching directory @@ -698,7 +698,7 @@ LINUX_VERSION: The Linux kernel version you are using (e.g. -"3.19"). +"4.4"). LINUX_VERSION_EXTENSION: The Linux kernel CONFIG_LOCALVERSION that is compiled into the resulting kernel and visible @@ -724,7 +724,7 @@ The combined results are a string with the following form: - 3.19.11+git1+68a635bf8dfb64b02263c1ac80c948647cc76d5f_1+218bd8d2022b9852c60d32f0d770931e3cf343e2 + 4.4.11+git1+68a635bf8dfb64b02263c1ac80c948647cc76d5f_1+218bd8d2022b9852c60d32f0d770931e3cf343e2 While lengthy, the extra verbosity in PV helps ensure you are using the exact -- 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] Python3 partial rootfs installation
You are right. It's working now.
Den 26. feb. 2017 10.04 PM skrev "Paul Eggleton" <
paul.eggle...@linux.intel.com>:
> On Sunday, 26 February 2017 12:10:24 AM NZDT Jakob Simon-Gaarde wrote:
> > Thanks for the answer. I tried adding it as a dependency but I get this:
> > ERROR: Nothing PROVIDES 'python3-modules'
>
> Based on your email, this is a runtime situation you are trying to resolve
> -
> and python3-modules is a runtime target, but that error suggests you are
> adding to DEPENDS which is for build-time dependencies.
>
> You probably want to add python3-modules to IMAGE_INSTALL in your image
> recipe
> or perhaps to RDEPENDS_${PN} in the recipe for the custom software you're
> building.
>
> Cheers,
> Paul
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre
>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] kernel-dev manual, section 2.6.2, do tags like "systemtap" exist?
section 2.6.2 refers to how to display changes based on a tag, and uses the alleged tag name "systemtap" ... do tags like that even exist anymore? i see no such tag in my current build directories. 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
[yocto] [meta-raspberrypi] [PATCH 2/2] rpi-base: wic: generate entries for device tree files
Augment IMAGE_BOOT_FILES with entries picking up proper dtb[o]s. This allows for
building usable wic images once again.
Signed-off-by: Maciej Borzecki
---
conf/machine/include/rpi-base.inc | 32 +++-
1 file changed, 31 insertions(+), 1 deletion(-)
diff --git a/conf/machine/include/rpi-base.inc
b/conf/machine/include/rpi-base.inc
index
e069e7039f166b4503d6709df7bf770dadc6af5d..092cbeb1f7f2ce51b79acb44951373a600e97573
100644
--- a/conf/machine/include/rpi-base.inc
+++ b/conf/machine/include/rpi-base.inc
@@ -51,7 +51,37 @@ MACHINE_EXTRA_RRECOMMENDS += " kernel-modules"
# Set Raspberrypi splash image
SPLASH = "psplash-raspberrypi"
-IMAGE_BOOT_FILES ?= "bcm2835-bootfiles/*
${KERNEL_IMAGETYPE};${SDIMG_KERNELIMAGE}"
+def make_dtb_boot_files(d):
+# Generate IMAGE_BOOT_FILES entries for device tree files listed in
+# KERNEL_DEVICETREE.
+alldtbs = d.getVar('KERNEL_DEVICETREE')
+imgtyp = d.getVar('KERNEL_IMAGETYPE')
+
+def transform(dtb):
+if dtb.endswith('dtb'):
+# eg: bcm2708-rpi-b.dtb has:
+# DEPLOYDIR file: ${KERNEL_IMAGETYPE}-bcm2708-rpi-b.dtb
+# destination: bcm2708-rpi-b.dtb
+src = '{}-{}'.format(imgtyp, dtb)
+dst = dtb
+return '{};{}'.format(src, dst)
+elif dtb.endswith('dtbo'):
+# overlay dtb:
+# eg: overlays/hifiberry-amp.dtbo has:
+# DEPLOYDIR file: ${KERNEL_IMAGETYPE}-hifiberry-amp.dtbp
+# destination: overlays/hifiberry-amp.dtbo
+base = os.path.basename(dtb)
+src = '{}-{}'.format(imgtyp, base)
+dst = dtb
+return '{};{}'.format(src, dtb)
+
+return ' '.join([transform(dtb) for dtb in alldtbs.split(' ') if dtb])
+
+
+IMAGE_BOOT_FILES ?= "bcm2835-bootfiles/* \
+ ${@make_dtb_boot_files(d)} \
+ ${KERNEL_IMAGETYPE};${SDIMG_KERNELIMAGE} \
+ "
# The kernel image is installed into the FAT32 boot partition and does not need
# to also be installed into the rootfs.
--
2.5.5
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-raspberrypi] [PATCH 1/2] wic: move sdimage-raspberrypi to toplevel wic location
Wic supports picking up image files from toplevel LAYERDIR/wic directory. Using
this location has the benefit that image files are easier to find (compare that
to previously used scripts/lib/image/canned-wks/ location).
Signed-off-by: Maciej Borzecki
---
{scripts/lib/image/canned-wks => wic}/sdimage-raspberrypi.wks | 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename {scripts/lib/image/canned-wks => wic}/sdimage-raspberrypi.wks (100%)
diff --git a/scripts/lib/image/canned-wks/sdimage-raspberrypi.wks
b/wic/sdimage-raspberrypi.wks
similarity index 100%
rename from scripts/lib/image/canned-wks/sdimage-raspberrypi.wks
rename to wic/sdimage-raspberrypi.wks
--
2.5.5
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-raspberrypi] [PATCH 0/2] wic: fixes for wic support
A small series with 2 patches that enable using wic (once again).
The first patch moves sdimage-wks to ${LAYERDIR}/wic. This is already
implemented in meta-yocto-bsp. The goal is to make wks files easier to
find. Since Yocto is in general dumping custom image building methods in
favor of wic, one would expect that wic is also usable with
meta-raspberrypi.
The second patch adds support for KERNEL_DEVICETREE to IMAGE_BOOT_FILES.
Currently, DTs will be copied over to boot partition when building
rpi-sdimg. However, when building a wic image, none of this happens and
once the process comlpetes, one will get an unbootable image. The patch
adds proper entries to IMAGE_BOOT_FILES also taking care of proper file
name transformation.
With these 2 patches, a wic image can be built by adding the following
settings to conf/local.conf:
IMAGE_FSTYPES_append = " wic"
# or with your favourite compression, eg. wic.xz
WKS_FILES = "sdimage-raspberrypi.wks"
Maciej Borzecki (2):
wic: move sdimage-raspberrypi to toplevel wic location
rpi-base: wic: generate entries for device tree files
conf/machine/include/rpi-base.inc | 32 +-
.../canned-wks => wic}/sdimage-raspberrypi.wks | 0
2 files changed, 31 insertions(+), 1 deletion(-)
rename {scripts/lib/image/canned-wks => wic}/sdimage-raspberrypi.wks (100%)
--
2.5.5
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] couple questions about kernel-dev manual, section 2.6, "emenlow" branch
On Mon, Feb 27, 2017 at 4:54 AM, Robert P. J. Day wrote: > > still working my way through the kernel-dev manual, and a couple > oddities in section 2.6. > > first, the example given uses the (alleged) standard/emenlow branch, > which i'm pretty sure doesn't exist anymore, yes? if one is going to > use an example, i suggest one base that example on one of the YP > reference BSPs that's guaranteed to always exist, such as beagleboard > or arm-versatile-926ejs. > I can't say that one will always exist .. but the arm-versatile branch has been around for years, and until the qemuarm target changes to use something else, it will continue to be around. > > next, i'm assuming that one would be running those "git whatchanged" > commands in the project directory, under > tmp/work-shared//kernel-source, yes? it's just not made clear > in that section where a reader would be doing those things. > Correct. > > finally, section 2.6.1 reads: > > "Here is an example that looks at what has changed in the emenlow > branch of the linux-yocto-3.19 kernel." > > what does the kernel version of 3.19 have to do with those git > commands? how do those commands depend on the particular version of > the linux-yocto recipe you're using? > At one point I was changing the branching structure, and the kernel meta data was in the same repo as the kernel source, so that could change some of the commands. But nothing has changed on that front in quite some time, so the answer is "they don't depend on the version you are using" .. so the version reference could be dropped. Bruce > > 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 > -- "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end" -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] kernel-dev manual, section 2.6.2, do tags like "systemtap" exist?
On Mon, Feb 27, 2017 at 5:27 AM, Robert P. J. Day wrote: > > section 2.6.2 refers to how to display changes based on a tag, and > uses the alleged tag name "systemtap" ... do tags like that even exist > anymore? i see no such tag in my current build directories. > Correct. The tagged features were dropped a few years ago. So any section that references them could be dropped. Bruce > > 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 > -- "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end" -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH] yocto-docs: kernel-dev, update "3.19" versions to "4.4"
On Mon, Feb 27, 2017 at 5:07 AM, Robert P. J. Day wrote: > > Update the remaining references to kernel version 3.19 to version 4.4, > restricted to the section "kernel-dev-common.xml". > I just sent a patch to drop 4.4 from master. I'd suggest 4.9 as a version to use that will persist in master for a bit longer. Bruce > > Signed-off-by: Robert P. J. Day > > --- > > if my earlier patch hasn't already been applied, this one can be > folded in since it simply adds more "3.19" -> "4.4" updates to the > same kernel-dev-common.xml file, which is already part of the commit > message for that earlier patch. > > diff --git a/documentation/kernel-dev/kernel-dev-common.xml > b/documentation/kernel-dev/kernel-dev-common.xml > index a9aafd3..97e2a0b 100644 > --- a/documentation/kernel-dev/kernel-dev-common.xml > +++ b/documentation/kernel-dev/kernel-dev-common.xml > @@ -645,8 +645,8 @@ > recipe to your layer and give it a meaningful name. > The name should include the version of the Linux > kernel you > are using (e.g. > -linux-yocto-myproject_3.19.bb, > -where "3.19" is the base version of the Linux kernel > +linux-yocto-myproject_4.4.bb, > +where "4.4" is the base version of the Linux kernel > with which you would be working). > In the same directory inside your layer, > create a matching directory > @@ -698,7 +698,7 @@ > > url='&YOCTO_DOCS_REF_URL;#var-LINUX_VERSION'> > LINUX_VERSION: > The Linux kernel version you are using (e.g. > -"3.19"). > +"4.4"). > url='&YOCTO_DOCS_REF_URL;#var-LINUX_VERSION_EXTENSION'>< > filename>LINUX_VERSION_EXTENSION: > The Linux kernel > CONFIG_LOCALVERSION > that is compiled into the resulting kernel > and visible > @@ -724,7 +724,7 @@ > The combined results are a string with > the following form: > > - 3.19.11+git1+68a635bf8dfb64b02263c1ac80c948647cc76d5f_1+ > 218bd8d2022b9852c60d32f0d770931e3cf343e2 > + 4.4.11+git1+68a635bf8dfb64b02263c1ac80c948647cc76d5f_1+ > 218bd8d2022b9852c60d32f0d770931e3cf343e2 > > While lengthy, the extra verbosity in > PV > helps ensure you are using the exact > > -- > > > 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 > -- "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end" -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] couple questions about kernel-dev manual, section 2.6, "emenlow" branch
On Mon, 27 Feb 2017, Bruce Ashfield wrote: > On Mon, Feb 27, 2017 at 4:54 AM, Robert P. J. Day > wrote: > > still working my way through the kernel-dev manual, and a > couple oddities in section 2.6. > > first, the example given uses the (alleged) standard/emenlow > branch, which i'm pretty sure doesn't exist anymore, yes? if > one is going to use an example, i suggest one base that > example on one of the YP reference BSPs that's guaranteed to > always exist, such as beagleboard or arm-versatile-926ejs. > > I can't say that one will always exist .. but the arm-versatile > branch has been around for years, and until the qemuarm target > changes to use something else, it will continue to be around. i might have skipped those possibilities since they produced no output, which made the examples rather vacuous. :-) i'll check again, want to make sure one picks a branch that actually generates output. > next, i'm assuming that one would be running those "git > whatchanged" commands in the project directory, under > tmp/work-shared//kernel-source, yes? it's just not > made clear in that section where a reader would be doing those > things. > > Correct. ok, i will add that note to the imminent patch. > finally, section 2.6.1 reads: > > "Here is an example that looks at what has changed in the > emenlow branch of the linux-yocto-3.19 kernel." > what does the kernel version of 3.19 have to do with those git > commands? how do those commands depend on the particular > version of the linux-yocto recipe you're using? > > At one point I was changing the branching structure, and the kernel > meta data was in the same repo as the kernel source, so that could > change some of the commands. > > But nothing has changed on that front in quite some time, so the > answer is "they don't depend on the version you are using" .. so the > version reference could be dropped. roger that. 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] kernel-dev manual, section 2.6.2, do tags like "systemtap" exist?
On Mon, 27 Feb 2017, Bruce Ashfield wrote: > On Mon, Feb 27, 2017 at 5:27 AM, Robert P. J. Day > wrote: > > section 2.6.2 refers to how to display changes based on a > tag, and uses the alleged tag name "systemtap" ... do tags > like that even exist anymore? i see no such tag in my current > build directories. > > Correct. The tagged features were dropped a few years ago. So any > section that references them could be dropped. okey dokey. 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] [PATCH] yocto-docs: kernel-dev, update "3.19" versions to "4.4"
On Mon, 27 Feb 2017, Bruce Ashfield wrote: > On Mon, Feb 27, 2017 at 5:07 AM, Robert P. J. Day > wrote: > > Update the remaining references to kernel version 3.19 to > version 4.4, restricted to the section > "kernel-dev-common.xml". > > I just sent a patch to drop 4.4 from master. I'd suggest 4.9 as a > version to use that will persist in master for a bit longer. in that case, one can drop those earlier patches i sent in, and i will submit newer ones. 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
[yocto] Shared library question
I trying to create a package am335x-pru-support which creates a shared library used by another package pru-examples. The library files installed with am335x-pru-support are (from /image) -rwxr-xr-x 4 gthomas gthomas 17074 Feb 27 13:40 usr/lib/libprussdrv.a lrwxrwxrwx 1 gthomas gthomas16 Feb 27 13:40 usr/lib/libprussdrv.so -> libprussdrv.so.1 lrwxrwxrwx 1 gthomas gthomas18 Feb 27 13:40 usr/lib/libprussdrv.so.1 -> libprussdrv.so.1.0 -rwxr-xr-x 1 gthomas gthomas 22092 Feb 27 13:40 usr/lib/libprussdrv.so.1.0 -rw-r--r-- 4 gthomas gthomas 8074 Feb 27 13:40 usr/include/pruss/prussdrv.h -rw-r--r-- 4 gthomas gthomas 4286 Feb 27 13:40 usr/include/pruss/pruss_intc_mapping.h These files are split by the packager as: gthomas@europa:packages-split$ find am335x-pru-support | sort am335x-pru-support am335x-pru-support/usr am335x-pru-support/usr/lib am335x-pru-support/usr/lib/libprussdrv.so.1 am335x-pru-support/usr/lib/libprussdrv.so.1.0 gthomas@europa:packages-split$ find am335x-pru-support-dev | sort am335x-pru-support-dev am335x-pru-support-dev/usr am335x-pru-support-dev/usr/include am335x-pru-support-dev/usr/include/pruss am335x-pru-support-dev/usr/include/pruss/prussdrv.h am335x-pru-support-dev/usr/include/pruss/pruss_intc_mapping.h am335x-pru-support-dev/usr/lib am335x-pru-support-dev/usr/lib/libprussdrv.so These files get staged correctly to pru-examples recipe-specific-sysroot and I can build and link against them, using DEPENDS="am335x-pru-support". The problem is that when my build (target recipe) uses $(CC) my_target_program.c $(LDFLAGS) -lprussdrv it gets satisfied by /usr/lib/libprussdrv.so and not /usr/lib/libprussdrv.so.1 This in turn appears to keep the pru-examples package from having a runtime dependency against the am335x-pru-support package and the necessary library file does not end up on my target. I've tried to work through this, following many recipes as examples, e.g. meta/recipes-multimedia/libogg (pattern for am335x-pru-support) and meta/recipes-multimedia/flac (pattern for pru-examples). The libogg/flac combo works correctly, mine does not :-( Any pointers on what I might be doing wrong? I'm so close to getting this stuff going, it's just the packaging that's going to claim the last hairs from my head... Thanks n.b. I'm happy to share any of the recipes, I just left them out for brevity. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] add users doesn't work
Hello, I tried to add a user to my image, like described in the FAQ here: https://wiki.yoctoproject.org/wiki/FAQ:How_do_I_set_or_change_the_root_password However, if I added that two lines to my recipe, it doesn't have any effect (still only root user available). What else do I need to change to make this work? And is the recipe the right place for this line (FAQ doesn't mention this)? Kind Regards, Jakob -- Jakob Hasse Software Developement E: jakob.ha...@smart-home-technology.ch T: +41 44 552 02 66 Smart Home Technology GmbH www.smart-home-technology.ch -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] add users doesn't work
Hi Jakob, On Mon, Feb 27, 2017 at 03:34:59PM +0100, Jakob Hasse wrote: > Hello, > > I tried to add a user to my image, like described in the FAQ here: > https://wiki.yoctoproject.org/wiki/FAQ:How_do_I_set_or_change_the_root_password > > However, if I added that two lines to my recipe, it doesn't have any effect > (still only root user available). > What else do I need to change to make this work? And is the recipe the right > place for this line (FAQ doesn't mention this)? The "extrausers" class is generally used for image level user/group configuration. "useradd" class is recommended for recipe level user/group configurations. So, please use it in your local.conf as below: eg: INHERIT += "extrausers" EXTRA_USERS_PARAMS = "\ useradd -p '' tester1; \ " Hope this helps. > Kind Regards, > Jakob > > -- > Jakob Hasse > Software Developement > > E: jakob.ha...@smart-home-technology.ch > T: +41 44 552 02 66 > > Smart Home Technology GmbH > www.smart-home-technology.ch Best Regards, Maxin -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] build signature file automatically for ipk
In bitbake process when building complete image all packages are build, my local.conf is set to create IPK packages for opkg. Additionally I overloaded PACKAGECONF_append_pn_opkg = "gpg sha256 openssl". Now when using opkg on the target platform and downloading package list using "opkg update" I get the error that .sig isn't found. Correct, I need to create a signature for packages or depending on opkg.conf for even each packet (that's what I want). How to add in build process automatic creation of signature for each file/package? Br, Martin... - Leopold KOSTAL GmbH & Co. KG - Sitz Lüdenscheid, Registergericht Iserlohn HRA 2854, phG Kostal Verwaltungsgesellschaft mbH, Registergericht Iserlohn HRB 4061 - USt-Id-Nr./Vat No.: DE 125800885 Post- und Werksanschrift: An der Bellmerei 10, D-58513 Lüdenscheid * Telefon: +49 2351 16-0 * Telefax: +49 2351 16-2400 Bellmerei Geschäftsführung: Dipl.-Oec. Andreas Kostal (Vorsitzender), Dipl.-Ing. Marwin Kinzl, Dr.-Ing. Ludger Laufenberg, Dipl.-Kfm. Ulrich Zimmermann -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Yocto Project Status WW09’17
Current Dev Position: YP 2.3 M3 Next Deadline: YP 2.3 M3 by Feb. 27, 2017 *** FEATURE FREEZE for 2.3 is now in effect. *** SWAT team rotation: Anibal -> Todor on Feb. 24, 2017. SWAT team rotation: Todor -> Tracy on Mar. 4, 2017. https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team Key Status/Updates: ·We’re now into feature freeze for 2.3. ·We need to decide which recently submitted items should be merged. Some major items In particular: o rpm v4/dnf to replace rpm v5/smart? o Merging go into OE-Core? o Separate out elderly GPLv2 into a separate layer? o Graphics stack vulkan changes? o Large queue of wic changes? I am leaning towards trying to take these even if they do delay the M3 release slightly as we do have some time left in M4 to stabilize. ·Unfortunately we continue to have stability issues in testing. There appear to be some intermittent failures which have crept into master and M3 merging will likely be delayed until those issues have been tracked down. They seem to affect sdk image size, breaking the 4GB limit and eSDKs stopping containing libxml2 under unknown circumstances, possibly amongst other issues. ·YP 2.2.1 has been released Proposed upcoming dot releases: YP 2.1.3 Cut off May 15, 2017 YP 2.1.3 Release by May 26, 2017 YP 2.2.2 Cut off May 29, 2017 YP 2.2.2 Release by June 9, 2017 Key YP 2.3 Dates: YP 2.3 M3 Cutoff is Feb 27, 2017 YP 2.3 M3 Release is Mar. 10, 2017 YP 2.3 M4 Cutoff is April 10, 2017 YP 2.3 M4 Release is May 5, 2017 Tracking Metrics: WDD 2747 (last week 2682) (https://wiki.yoctoproject.org/charts/combo.html) Key Status Links for YP: https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.3_Status https://wiki.yoctoproject.org/wiki/Yocto_2.3_Schedule https://wiki.yoctoproject.org/wiki/Yocto_2.3_Features [If anyone has suggestions for other information you’d like to see on this weekly status update, let us know!] Thanks, Stephen K. Jolley Yocto Project Program Manager INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124 • Work Telephone:(503) 712-0534 •Cell: (208) 244-4460 • Email:stephen.k.jol...@intel.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-rockchip][PATCH v3] classes: rockchip-gpt-img: add
This bbclass was taken from the Rockchip team's work at
https://github.com/rockchip-linux/meta-rockchip/commit/53d2e2e474a3014e3013d0059fd1da773fb0e2b7
It was mostly written by Jacob Chen . I've made some
small modifications and added it.
Older images used (what Rockchip calls) the "legacy parameter" format. Newer
images use u-boot and a GPT partitioning scheme. This class allows the build
to generate a gpt-img file that can either be flashed to eMMC or written to an
SDcard (the same image is used for both).
This is the new image format used for rk3288 SoCs (e.g. the Firefly board).
Reviewd-by: Eddie Cai
Signed-off-by: Jacob Chen
Signed-off-by: Trevor Woerner
---
classes/rockchip-gpt-img.bbclass | 132 +++
1 file changed, 132 insertions(+)
create mode 100644 classes/rockchip-gpt-img.bbclass
diff --git a/classes/rockchip-gpt-img.bbclass b/classes/rockchip-gpt-img.bbclass
new file mode 100644
index 000..0a0ccb8
--- /dev/null
+++ b/classes/rockchip-gpt-img.bbclass
@@ -0,0 +1,132 @@
+# Copyright (C) 2017 Fuzhou Rockchip Electronics Co., Ltd
+# Copyright (C) 2017 Trevor Woerner
+# Released under the MIT license (see COPYING.MIT for the terms)
+
+inherit image_types
+
+# Use an uncompressed ext4 by default as rootfs
+IMG_ROOTFS_TYPE = "ext4"
+IMG_ROOTFS = "${IMGDEPLOYDIR}/${IMAGE_NAME}.rootfs.${IMG_ROOTFS_TYPE}"
+
+# This image depends on the rootfs image
+IMAGE_TYPEDEP_rockchip-gpt-img = "${IMG_ROOTFS_TYPE}"
+
+GPTIMG_SUFFIX = "gpt-img"
+GPTIMG = "${IMAGE_NAME}.${GPTIMG_SUFFIX}"
+GPTIMG_SIZE ?= "4096"
+BOOT_IMG = "boot.img"
+MINILOADER = "loader.bin"
+UBOOT = "u-boot.out"
+TRUST = "trust.out"
+GPTIMG_APPEND ?= "console=tty1 console=ttyS2,115200n8 rw root=/dev/mmcblk2p7
rootfstype=ext4 init=/sbin/init"
+
+# default partitions [in Sectors]
+# More info at http://rockchip.wikidot.com/partitions
+LOADER1_SIZE = "8000"
+RESERVED1_SIZE = "128"
+RESERVED2_SIZE = "8192"
+LOADER2_SIZE = "8192"
+ATF_SIZE = "8192"
+BOOT_SIZE = "229376"
+
+IMAGE_DEPENDS_rockchip-gpt-img = "parted-native \
+ u-boot-mkimage-native \
+ mtools-native \
+ dosfstools-native \
+ virtual/kernel:do_deploy \
+ virtual/bootloader:do_deploy"
+
+PER_CHIP_IMG_GENERATION_COMMAND_rk3288 = "generate_rk3288_loader1_image"
+
+IMAGE_CMD_rockchip-gpt-img () {
+ # Change to image directory
+ cd ${DEPLOY_DIR_IMAGE}
+
+ # Remove the existing image symlink
+ rm -rf *${GPTIMG_SUFFIX}
+
+ create_rk_image
+
+ ${PER_CHIP_IMG_GENERATION_COMMAND}
+
+ cd ${DEPLOY_DIR_IMAGE}
+ ln -s ${GPTIMG} "${IMAGE_BASENAME}-${MACHINE}.${GPTIMG_SUFFIX}"
+}
+
+create_rk_image () {
+
+ # Initialize sdcard image file
+ dd if=/dev/zero of=${GPTIMG} bs=1M count=0 seek=${GPTIMG_SIZE}
+
+ # Create partition table
+ parted -s ${GPTIMG} mklabel gpt
+
+ # Create vendor defined partitions
+ LOADER1_START=64
+ RESERVED1_START=`expr ${LOADER1_START} + ${LOADER1_SIZE}`
+ RESERVED2_START=`expr ${RESERVED1_START} + ${RESERVED1_SIZE}`
+ LOADER2_START=`expr ${RESERVED2_START} + ${RESERVED2_SIZE}`
+ ATF_START=`expr ${LOADER2_START} + ${LOADER2_SIZE}`
+ BOOT_START=`expr ${ATF_START} + ${ATF_SIZE}`
+ ROOTFS_START=`expr ${BOOT_START} + ${BOOT_SIZE}`
+
+ parted -s ${GPTIMG} unit s mkpart loader1 ${LOADER1_START} `expr
${RESERVED1_START} - 1`
+ parted -s ${GPTIMG} unit s mkpart reserved1 ${RESERVED1_START} `expr
${RESERVED2_START} - 1`
+ parted -s ${GPTIMG} unit s mkpart reserved2 ${RESERVED2_START} `expr
${LOADER2_START} - 1`
+ parted -s ${GPTIMG} unit s mkpart loader2 ${LOADER2_START} `expr
${ATF_START} - 1`
+ parted -s ${GPTIMG} unit s mkpart atf ${ATF_START} `expr ${BOOT_START}
- 1`
+
+ # Create boot partition and mark it as bootable
+ parted -s ${GPTIMG} unit s mkpart boot ${BOOT_START} `expr
${ROOTFS_START} - 1`
+ parted -s ${GPTIMG} set 6 boot on
+
+ # Create rootfs partition
+ parted -s ${GPTIMG} unit s mkpart root ${ROOTFS_START} 100%
+
+ parted ${GPTIMG} print
+
+ # Delete the boot image to avoid trouble with the build cache
+ rm -f ${WORKDIR}/${BOOT_IMG}
+
+ # Create boot partition image
+ BOOT_BLOCKS=$(LC_ALL=C parted -s ${GPTIMG} unit b print | awk '/ 6 / {
print substr($4, 1, length($4 -1)) / 512 /2 }')
+ BOOT_BLOCKS=`expr $BOOT_BLOCKS / 63 \* 63`
+
+ mkfs.vfat -n "boot" -S 512 -C ${WORKDIR}/${BOOT_IMG} $BOOT_BLOCKS
+ mcopy -i ${WORKDIR}/${BOOT_IMG} -s
${DEPLOY_DIR_IMAGE}/${KERNEL_IMAGETYPE}-${MACHINE}.bin ::${KERNEL_IMAGETYPE}
+
+ DEVICETREE_DEFAULT=""
+ for DTS_FILE in ${KERNEL_DEVICETREE}; do
+ [ -n "${DEVICETREE_DEFAULT}"] &&
DEVICETREE_DEFAULT="${DTS_FILE}"
+ mcopy -i ${WORKDIR}/${BOOT_IMG} -s
${DEPLOY_DIR_IMAGE}/${KERNEL_IMAGETYPE}-${DTS_FILE} ::${DTS_FILE}
+ done
+
+ # Create extl
[yocto] [meta-rockchip][PATCH v3 0/1] classes: rockchip-gpt-img: add
Here is my v3 of this patch, based on feedback from earlier reviews.
Changes since v2:
- change commit message and call the "old" layout "legacy parameter"
format instead of "rk-boot" format
- rename generate_rk3288_image() to generate_rk3288_loader1_image()
- leave any older gpt image files (with datestamp) in the deploy
directory but just move the symlink so it always points to the most
recent
- leave size variable as GPTIMG_SIZE
- leave the boot image name as BOOT_IMG since trying to add ${MACHINE}
and ${DATETIME} causes the build to fail with "the basehash value
changed... metadata is not deterministic...". I think what was
wanted was that older gpt image files be left around, and this new
logic does that in a different way and maintains a symlink to the
latest
Changes since v1:
- break large commits into smaller ones
- rename the class and improve the commit message
Trevor Woerner (1):
classes: rockchip-gpt-img: add
classes/rockchip-gpt-img.bbclass | 132 +++
1 file changed, 132 insertions(+)
create mode 100644 classes/rockchip-gpt-img.bbclass
--
2.12.0.rc1.48.g076c053
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-rockchip][PATCH v3] classes: rockchip-gpt-img: add
Oops!! Please ignore, sent wrong file...
On Mon, Feb 27, 2017 at 2:15 PM, Trevor Woerner wrote:
> This bbclass was taken from the Rockchip team's work at
> https://github.com/rockchip-linux/meta-rockchip/commit/53d2e2e474a3014e3013d0059fd1da773fb0e2b7
> It was mostly written by Jacob Chen . I've made some
> small modifications and added it.
>
> Older images used (what Rockchip calls) the "legacy parameter" format. Newer
> images use u-boot and a GPT partitioning scheme. This class allows the build
> to generate a gpt-img file that can either be flashed to eMMC or written to an
> SDcard (the same image is used for both).
>
> This is the new image format used for rk3288 SoCs (e.g. the Firefly board).
>
> Reviewd-by: Eddie Cai
> Signed-off-by: Jacob Chen
> Signed-off-by: Trevor Woerner
> ---
> classes/rockchip-gpt-img.bbclass | 132
> +++
> 1 file changed, 132 insertions(+)
> create mode 100644 classes/rockchip-gpt-img.bbclass
>
> diff --git a/classes/rockchip-gpt-img.bbclass
> b/classes/rockchip-gpt-img.bbclass
> new file mode 100644
> index 000..0a0ccb8
> --- /dev/null
> +++ b/classes/rockchip-gpt-img.bbclass
> @@ -0,0 +1,132 @@
> +# Copyright (C) 2017 Fuzhou Rockchip Electronics Co., Ltd
> +# Copyright (C) 2017 Trevor Woerner
> +# Released under the MIT license (see COPYING.MIT for the terms)
> +
> +inherit image_types
> +
> +# Use an uncompressed ext4 by default as rootfs
> +IMG_ROOTFS_TYPE = "ext4"
> +IMG_ROOTFS = "${IMGDEPLOYDIR}/${IMAGE_NAME}.rootfs.${IMG_ROOTFS_TYPE}"
> +
> +# This image depends on the rootfs image
> +IMAGE_TYPEDEP_rockchip-gpt-img = "${IMG_ROOTFS_TYPE}"
> +
> +GPTIMG_SUFFIX = "gpt-img"
> +GPTIMG = "${IMAGE_NAME}.${GPTIMG_SUFFIX}"
> +GPTIMG_SIZE ?= "4096"
> +BOOT_IMG = "boot.img"
> +MINILOADER = "loader.bin"
> +UBOOT = "u-boot.out"
> +TRUST = "trust.out"
> +GPTIMG_APPEND ?= "console=tty1 console=ttyS2,115200n8 rw root=/dev/mmcblk2p7
> rootfstype=ext4 init=/sbin/init"
> +
> +# default partitions [in Sectors]
> +# More info at http://rockchip.wikidot.com/partitions
> +LOADER1_SIZE = "8000"
> +RESERVED1_SIZE = "128"
> +RESERVED2_SIZE = "8192"
> +LOADER2_SIZE = "8192"
> +ATF_SIZE = "8192"
> +BOOT_SIZE = "229376"
> +
> +IMAGE_DEPENDS_rockchip-gpt-img = "parted-native \
> + u-boot-mkimage-native \
> + mtools-native \
> + dosfstools-native \
> + virtual/kernel:do_deploy \
> + virtual/bootloader:do_deploy"
> +
> +PER_CHIP_IMG_GENERATION_COMMAND_rk3288 = "generate_rk3288_loader1_image"
> +
> +IMAGE_CMD_rockchip-gpt-img () {
> + # Change to image directory
> + cd ${DEPLOY_DIR_IMAGE}
> +
> + # Remove the existing image symlink
> + rm -rf *${GPTIMG_SUFFIX}
> +
> + create_rk_image
> +
> + ${PER_CHIP_IMG_GENERATION_COMMAND}
> +
> + cd ${DEPLOY_DIR_IMAGE}
> + ln -s ${GPTIMG} "${IMAGE_BASENAME}-${MACHINE}.${GPTIMG_SUFFIX}"
> +}
> +
> +create_rk_image () {
> +
> + # Initialize sdcard image file
> + dd if=/dev/zero of=${GPTIMG} bs=1M count=0 seek=${GPTIMG_SIZE}
> +
> + # Create partition table
> + parted -s ${GPTIMG} mklabel gpt
> +
> + # Create vendor defined partitions
> + LOADER1_START=64
> + RESERVED1_START=`expr ${LOADER1_START} + ${LOADER1_SIZE}`
> + RESERVED2_START=`expr ${RESERVED1_START} + ${RESERVED1_SIZE}`
> + LOADER2_START=`expr ${RESERVED2_START} + ${RESERVED2_SIZE}`
> + ATF_START=`expr ${LOADER2_START} + ${LOADER2_SIZE}`
> + BOOT_START=`expr ${ATF_START} + ${ATF_SIZE}`
> + ROOTFS_START=`expr ${BOOT_START} + ${BOOT_SIZE}`
> +
> + parted -s ${GPTIMG} unit s mkpart loader1 ${LOADER1_START} `expr
> ${RESERVED1_START} - 1`
> + parted -s ${GPTIMG} unit s mkpart reserved1 ${RESERVED1_START} `expr
> ${RESERVED2_START} - 1`
> + parted -s ${GPTIMG} unit s mkpart reserved2 ${RESERVED2_START} `expr
> ${LOADER2_START} - 1`
> + parted -s ${GPTIMG} unit s mkpart loader2 ${LOADER2_START} `expr
> ${ATF_START} - 1`
> + parted -s ${GPTIMG} unit s mkpart atf ${ATF_START} `expr
> ${BOOT_START} - 1`
> +
> + # Create boot partition and mark it as bootable
> + parted -s ${GPTIMG} unit s mkpart boot ${BOOT_START} `expr
> ${ROOTFS_START} - 1`
> + parted -s ${GPTIMG} set 6 boot on
> +
> + # Create rootfs partition
> + parted -s ${GPTIMG} unit s mkpart root ${ROOTFS_START} 100%
> +
> + parted ${GPTIMG} print
> +
> + # Delete the boot image to avoid trouble with the build cache
> + rm -f ${WORKDIR}/${BOOT_IMG}
> +
> + # Create boot partition image
> + BOOT_BLOCKS=$(LC_ALL=C parted -s ${GPTIMG} unit b print | awk '/ 6 /
> { print substr($4, 1, length($4 -1)) / 512 /2 }')
> + BOOT_BLOCKS=`expr $BOOT_BLOCKS / 63 \* 63`
> +
> + mkfs.vfat -n "boot" -S 512 -C ${WORKDIR}/${BOOT_IMG} $BOOT_BLOCKS
> + mcopy -i ${WORKDIR}/${BOOT_IMG} -s
> ${DEPLOY_DIR_IMAGE}/${KERNEL_IMAG
[yocto] [meta-rockchip][PATCH v4] classes: rockchip-gpt-img: add
This bbclass was taken from the Rockchip team's work at
https://github.com/rockchip-linux/meta-rockchip/commit/53d2e2e474a3014e3013d0059fd1da773fb0e2b7
It was mostly written by Jacob Chen . I've made some
small modifications and added it.
Older images used (what Rockchip calls) the "legacy parameter" format. Newer
images use u-boot and a GPT partitioning scheme. This class allows the build
to generate a gpt-img file that can either be flashed to eMMC or written to an
SDcard (the same image is used for both).
This is the new image format used for rk3288 SoCs (e.g. the Firefly board).
Reviewd-by: Eddie Cai
Signed-off-by: Jacob Chen
Signed-off-by: Trevor Woerner
---
classes/rockchip-gpt-img.bbclass | 133 +++
1 file changed, 133 insertions(+)
create mode 100644 classes/rockchip-gpt-img.bbclass
diff --git a/classes/rockchip-gpt-img.bbclass b/classes/rockchip-gpt-img.bbclass
new file mode 100644
index 000..ba83c8a
--- /dev/null
+++ b/classes/rockchip-gpt-img.bbclass
@@ -0,0 +1,133 @@
+# Copyright (C) 2017 Fuzhou Rockchip Electronics Co., Ltd
+# Copyright (C) 2017 Trevor Woerner
+# Released under the MIT license (see COPYING.MIT for the terms)
+
+inherit image_types
+
+# Use an uncompressed ext4 by default as rootfs
+IMG_ROOTFS_TYPE = "ext4"
+IMG_ROOTFS = "${IMGDEPLOYDIR}/${IMAGE_NAME}.rootfs.${IMG_ROOTFS_TYPE}"
+
+# This image depends on the rootfs image
+IMAGE_TYPEDEP_rockchip-gpt-img = "${IMG_ROOTFS_TYPE}"
+
+GPTIMG_SUFFIX = "gpt-img"
+GPTIMG = "${IMAGE_NAME}.${GPTIMG_SUFFIX}"
+GPTIMG_SYMLK = "${IMAGE_BASENAME}-${MACHINE}.${GPTIMG_SUFFIX}"
+GPTIMG_SIZE ?= "4096"
+BOOT_IMG = "boot.img"
+MINILOADER = "loader.bin"
+UBOOT = "u-boot.out"
+TRUST = "trust.out"
+GPTIMG_APPEND ?= "console=tty1 console=ttyS2,115200n8 rw root=/dev/mmcblk2p7
rootfstype=ext4 init=/sbin/init"
+
+# default partitions [in Sectors]
+# More info at http://rockchip.wikidot.com/partitions
+LOADER1_SIZE = "8000"
+RESERVED1_SIZE = "128"
+RESERVED2_SIZE = "8192"
+LOADER2_SIZE = "8192"
+ATF_SIZE = "8192"
+BOOT_SIZE = "229376"
+
+IMAGE_DEPENDS_rockchip-gpt-img = "parted-native \
+ u-boot-mkimage-native \
+ mtools-native \
+ dosfstools-native \
+ virtual/kernel:do_deploy \
+ virtual/bootloader:do_deploy"
+
+PER_CHIP_IMG_GENERATION_COMMAND_rk3288 = "generate_rk3288_loader1_image"
+
+IMAGE_CMD_rockchip-gpt-img () {
+ # Change to image directory
+ cd ${DEPLOY_DIR_IMAGE}
+
+ # Remove the existing image symlink
+ rm -f "${GPTIMG_SYMLK}"
+
+ create_rk_image
+
+ ${PER_CHIP_IMG_GENERATION_COMMAND}
+
+ cd ${DEPLOY_DIR_IMAGE}
+ ln -s ${GPTIMG} "${IMAGE_BASENAME}-${MACHINE}.${GPTIMG_SUFFIX}"
+}
+
+create_rk_image () {
+
+ # Initialize sdcard image file
+ dd if=/dev/zero of=${GPTIMG} bs=1M count=0 seek=${GPTIMG_SIZE}
+
+ # Create partition table
+ parted -s ${GPTIMG} mklabel gpt
+
+ # Create vendor defined partitions
+ LOADER1_START=64
+ RESERVED1_START=`expr ${LOADER1_START} + ${LOADER1_SIZE}`
+ RESERVED2_START=`expr ${RESERVED1_START} + ${RESERVED1_SIZE}`
+ LOADER2_START=`expr ${RESERVED2_START} + ${RESERVED2_SIZE}`
+ ATF_START=`expr ${LOADER2_START} + ${LOADER2_SIZE}`
+ BOOT_START=`expr ${ATF_START} + ${ATF_SIZE}`
+ ROOTFS_START=`expr ${BOOT_START} + ${BOOT_SIZE}`
+
+ parted -s ${GPTIMG} unit s mkpart loader1 ${LOADER1_START} `expr
${RESERVED1_START} - 1`
+ parted -s ${GPTIMG} unit s mkpart reserved1 ${RESERVED1_START} `expr
${RESERVED2_START} - 1`
+ parted -s ${GPTIMG} unit s mkpart reserved2 ${RESERVED2_START} `expr
${LOADER2_START} - 1`
+ parted -s ${GPTIMG} unit s mkpart loader2 ${LOADER2_START} `expr
${ATF_START} - 1`
+ parted -s ${GPTIMG} unit s mkpart atf ${ATF_START} `expr ${BOOT_START}
- 1`
+
+ # Create boot partition and mark it as bootable
+ parted -s ${GPTIMG} unit s mkpart boot ${BOOT_START} `expr
${ROOTFS_START} - 1`
+ parted -s ${GPTIMG} set 6 boot on
+
+ # Create rootfs partition
+ parted -s ${GPTIMG} unit s mkpart root ${ROOTFS_START} 100%
+
+ parted ${GPTIMG} print
+
+ # Delete the boot image to avoid trouble with the build cache
+ rm -f ${WORKDIR}/${BOOT_IMG}
+
+ # Create boot partition image
+ BOOT_BLOCKS=$(LC_ALL=C parted -s ${GPTIMG} unit b print | awk '/ 6 / {
print substr($4, 1, length($4 -1)) / 512 /2 }')
+ BOOT_BLOCKS=`expr $BOOT_BLOCKS / 63 \* 63`
+
+ mkfs.vfat -n "boot" -S 512 -C ${WORKDIR}/${BOOT_IMG} $BOOT_BLOCKS
+ mcopy -i ${WORKDIR}/${BOOT_IMG} -s
${DEPLOY_DIR_IMAGE}/${KERNEL_IMAGETYPE}-${MACHINE}.bin ::${KERNEL_IMAGETYPE}
+
+ DEVICETREE_DEFAULT=""
+ for DTS_FILE in ${KERNEL_DEVICETREE}; do
+ [ -n "${DEVICETREE_DEFAULT}"] &&
DEVICETREE_DEFAULT="${DTS_FILE}"
+ mcopy -i ${WORKDIR}/${BOOT_IMG} -s
${DEPLOY_DIR_IMAGE}/${KERNEL_IMAGETYP
[yocto] [meta-rockchip][PATCH v4 0/1] classes: rockchip-gpt-img: add
Here is my v4 of this patch, based on feedback from earlier reviews.
Changes since v3:
- I sent the wrong file when emailing v3
Changes since v2:
- change commit message and call the "old" layout "legacy parameter"
format instead of "rk-boot" format
- rename generate_rk3288_image() to generate_rk3288_loader1_image()
- leave any older gpt image files (with datestamp) in the deploy
directory but just move the symlink so it always points to the most
recent
- leave size variable as GPTIMG_SIZE
- leave the boot image name as BOOT_IMG since trying to add ${MACHINE}
and ${DATETIME} causes the build to fail with "the basehash value
changed... metadata is not deterministic...". I think what was
wanted was that older gpt image files be left around, and this new
logic does that in a different way and maintains a symlink to the
latest
Changes since v1:
- break large commits into smaller ones
- rename the class and improve the commit message
Trevor Woerner (1):
classes: rockchip-gpt-img: add
classes/rockchip-gpt-img.bbclass | 132 +++
1 file changed, 132 insertions(+)
create mode 100644 classes/rockchip-gpt-img.bbclass
--
2.12.0.rc1.48.g076c053
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Shared library question
Hi
Am Montag, den 27.02.2017, 15:03 +0100 schrieb Gary Thomas:
> I trying to create a package am335x-pru-support which creates a
> shared library used by another package pru-examples. The library
> files installed with am335x-pru-support are (from /image)
> -rwxr-xr-x 4 gthomas gthomas 17074 Feb 27 13:40 usr/lib/libprussdrv.a
> lrwxrwxrwx 1 gthomas gthomas16 Feb 27 13:40 usr/lib/libprussdrv.so ->
> libprussdrv.so.1
> lrwxrwxrwx 1 gthomas gthomas18 Feb 27 13:40 usr/lib/libprussdrv.so.1 ->
> libprussdrv.so.1.0
> -rwxr-xr-x 1 gthomas gthomas 22092 Feb 27 13:40 usr/lib/libprussdrv.so.1.0
> -rw-r--r-- 4 gthomas gthomas 8074 Feb 27 13:40 usr/include/pruss/prussdrv.h
> -rw-r--r-- 4 gthomas gthomas 4286 Feb 27 13:40
> usr/include/pruss/pruss_intc_mapping.h
>
> These files are split by the packager as:
> gthomas@europa:packages-split$ find am335x-pru-support | sort
> am335x-pru-support
> am335x-pru-support/usr
> am335x-pru-support/usr/lib
> am335x-pru-support/usr/lib/libprussdrv.so.1
> am335x-pru-support/usr/lib/libprussdrv.so.1.0
> gthomas@europa:packages-split$ find am335x-pru-support-dev | sort
> am335x-pru-support-dev
> am335x-pru-support-dev/usr
> am335x-pru-support-dev/usr/include
> am335x-pru-support-dev/usr/include/pruss
> am335x-pru-support-dev/usr/include/pruss/prussdrv.h
> am335x-pru-support-dev/usr/include/pruss/pruss_intc_mapping.h
> am335x-pru-support-dev/usr/lib
> am335x-pru-support-dev/usr/lib/libprussdrv.so
>
> These files get staged correctly to pru-examples recipe-specific-sysroot
> and I can build and link against them, using DEPENDS="am335x-pru-support".
> The problem is that when my build (target recipe) uses
>$(CC) my_target_program.c $(LDFLAGS) -lprussdrv
> it gets satisfied by /usr/lib/libprussdrv.so and not /usr/lib/libprussdrv.so.1
> This in turn appears to keep the pru-examples package from having
> a runtime dependency against the am335x-pru-support package and the
> necessary library file does not end up on my target.
>
> I've tried to work through this, following many recipes as examples,
> e.g. meta/recipes-multimedia/libogg (pattern for am335x-pru-support)
> and meta/recipes-multimedia/flac (pattern for pru-examples). The
> libogg/flac combo works correctly, mine does not :-(
>
> Any pointers on what I might be doing wrong? I'm so close to getting
> this stuff going, it's just the packaging that's going to claim the
> last hairs from my head...
When linking a shared object file you have to pass the linker a soname which
adds compatible version
information into the share object file.
Have a look here:
http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/commit/recipes-bsp?id=7ff327a4e3e8e19d1e3f848
865b6b27ba9f6250b
http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html
Alternatively you can drop the libprussdrv.so.1 and libprussdrv.so.1.0, and
force with FILES... the
libprussdrv.so into the not -dev package.
Probably you would also want to INSANE_SKIP_${PN} = "dev-so".
Max
>
> Thanks
>
> n.b. I'm happy to share any of the recipes, I just left them out for brevity.
>
> --
>
> Gary Thomas | Consulting for the
> MLB Associates |Embedded world
>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-rockchip][PATCH v4] classes: rockchip-gpt-img: add
Hi Trevor
2017-02-28 3:20 GMT+08:00 Trevor Woerner :
> This bbclass was taken from the Rockchip team's work at
> https://github.com/rockchip-linux/meta-rockchip/commit/
> 53d2e2e474a3014e3013d0059fd1da773fb0e2b7
> It was mostly written by Jacob Chen . I've made
> some
> small modifications and added it.
>
> Older images used (what Rockchip calls) the "legacy parameter" format.
> Newer
> images use u-boot and a GPT partitioning scheme. This class allows the
> build
> to generate a gpt-img file that can either be flashed to eMMC or written
> to an
> SDcard (the same image is used for both).
>
> This is the new image format used for rk3288 SoCs (e.g. the Firefly board).
>
> Reviewd-by: Eddie Cai
> Signed-off-by: Jacob Chen
> Signed-off-by: Trevor Woerner
> ---
> classes/rockchip-gpt-img.bbclass | 133 ++
> +
> 1 file changed, 133 insertions(+)
> create mode 100644 classes/rockchip-gpt-img.bbclass
>
> diff --git a/classes/rockchip-gpt-img.bbclass b/classes/rockchip-gpt-img.
> bbclass
> new file mode 100644
> index 000..ba83c8a
> --- /dev/null
> +++ b/classes/rockchip-gpt-img.bbclass
> @@ -0,0 +1,133 @@
> +# Copyright (C) 2017 Fuzhou Rockchip Electronics Co., Ltd
> +# Copyright (C) 2017 Trevor Woerner
> +# Released under the MIT license (see COPYING.MIT for the terms)
> +
> +inherit image_types
> +
> +# Use an uncompressed ext4 by default as rootfs
> +IMG_ROOTFS_TYPE = "ext4"
> +IMG_ROOTFS = "${IMGDEPLOYDIR}/${IMAGE_NAME}.rootfs.${IMG_ROOTFS_TYPE}"
> +
> +# This image depends on the rootfs image
> +IMAGE_TYPEDEP_rockchip-gpt-img = "${IMG_ROOTFS_TYPE}"
> +
> +GPTIMG_SUFFIX = "gpt-img"
> +GPTIMG = "${IMAGE_NAME}.${GPTIMG_SUFFIX}"
> +GPTIMG_SYMLK = "${IMAGE_BASENAME}-${MACHINE}.${GPTIMG_SUFFIX}"
> +GPTIMG_SIZE ?= "4096"
> +BOOT_IMG = "boot.img"
> +MINILOADER = "loader.bin"
> +UBOOT = "u-boot.out"
> +TRUST = "trust.out"
> +GPTIMG_APPEND ?= "console=tty1 console=ttyS2,115200n8 rw
> root=/dev/mmcblk2p7 rootfstype=ext4 init=/sbin/init"
> +
> +# default partitions [in Sectors]
> +# More info at http://rockchip.wikidot.com/partitions
> +LOADER1_SIZE = "8000"
> +RESERVED1_SIZE = "128"
> +RESERVED2_SIZE = "8192"
> +LOADER2_SIZE = "8192"
> +ATF_SIZE = "8192"
> +BOOT_SIZE = "229376"
> +
> +IMAGE_DEPENDS_rockchip-gpt-img = "parted-native \
> + u-boot-mkimage-native \
> + mtools-native \
> + dosfstools-native \
> + virtual/kernel:do_deploy \
> + virtual/bootloader:do_deploy"
> +
> +PER_CHIP_IMG_GENERATION_COMMAND_rk3288 = "generate_rk3288_loader1_image"
> +
> +IMAGE_CMD_rockchip-gpt-img () {
> + # Change to image directory
> + cd ${DEPLOY_DIR_IMAGE}
> +
> + # Remove the existing image symlink
> + rm -f "${GPTIMG_SYMLK}"
> +
> + create_rk_image
> +
> + ${PER_CHIP_IMG_GENERATION_COMMAND}
> +
> + cd ${DEPLOY_DIR_IMAGE}
> + ln -s ${GPTIMG} "${IMAGE_BASENAME}-${MACHINE}.${GPTIMG_SUFFIX}"
> +}
> +
> +create_rk_image () {
> +
> + # Initialize sdcard image file
> + dd if=/dev/zero of=${GPTIMG} bs=1M count=0 seek=${GPTIMG_SIZE}
> +
> + # Create partition table
> + parted -s ${GPTIMG} mklabel gpt
> +
> + # Create vendor defined partitions
> + LOADER1_START=64
> + RESERVED1_START=`expr ${LOADER1_START} + ${LOADER1_SIZE}`
> + RESERVED2_START=`expr ${RESERVED1_START} + ${RESERVED1_SIZE}`
> + LOADER2_START=`expr ${RESERVED2_START} + ${RESERVED2_SIZE}`
> + ATF_START=`expr ${LOADER2_START} + ${LOADER2_SIZE}`
> + BOOT_START=`expr ${ATF_START} + ${ATF_SIZE}`
> + ROOTFS_START=`expr ${BOOT_START} + ${BOOT_SIZE}`
> +
> + parted -s ${GPTIMG} unit s mkpart loader1 ${LOADER1_START} `expr
> ${RESERVED1_START} - 1`
> + parted -s ${GPTIMG} unit s mkpart reserved1 ${RESERVED1_START}
> `expr ${RESERVED2_START} - 1`
> + parted -s ${GPTIMG} unit s mkpart reserved2 ${RESERVED2_START}
> `expr ${LOADER2_START} - 1`
> + parted -s ${GPTIMG} unit s mkpart loader2 ${LOADER2_START} `expr
> ${ATF_START} - 1`
> + parted -s ${GPTIMG} unit s mkpart atf ${ATF_START} `expr
> ${BOOT_START} - 1`
> +
> + # Create boot partition and mark it as bootable
> + parted -s ${GPTIMG} unit s mkpart boot ${BOOT_START} `expr
> ${ROOTFS_START} - 1`
> + parted -s ${GPTIMG} set 6 boot on
> +
> + # Create rootfs partition
> + parted -s ${GPTIMG} unit s mkpart root ${ROOTFS_START} 100%
> +
> + parted ${GPTIMG} print
> +
> + # Delete the boot image to avoid trouble with the build cache
> + rm -f ${WORKDIR}/${BOOT_IMG}
> +
> + # Create boot partition image
> + BOOT_BLOCKS=$(LC_ALL=C parted -s ${GPTIMG} unit b print | awk '/ 6
> / { print substr($4, 1, length($4 -1)) / 512 /2 }')
> + BOOT_BLOCKS=`expr $BOOT_BLOCKS / 63 \* 63`
> +
> + mkfs.vfat -n "boot" -S 512 -C ${WORKDIR}/${BOOT_IMG} $BOOT_BLOCKS
> + mcopy -i ${WORKDIR}/${BOOT_IMG} -s
> ${DEPL
[yocto] [patchwork][PATCH 0/3] Series: Add multiple select/change controls
Patches displayed at Series view must be individually opened to allow change status or add them to a bundle, increasing needed time and providing a poor user experience. These changes add to Series view multiple select controls and the required functionality for status change, bundle addition and new bundle creation. [YOCTO #10822] Jose Lamego (3): series.py: add patch and bundle edition actions to view series.html: add patch and bundle edition forms and checkboxes series.js: add patch-selection-checkbox control functions htdocs/js/series.js | 145 + patchwork/templates/patchwork/series.html | 172 ++ patchwork/views/series.py | 88 --- 3 files changed, 307 insertions(+), 98 deletions(-) -- 2.7.4 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [patchwork][PATCH 1/3] series.py: add patch and bundle edition actions to view
This change adds patch and bundle edition actions to the series
view.
[YOCTO # 10822]
Signed-off-by: Jose Lamego
---
patchwork/views/series.py | 88 ---
1 file changed, 52 insertions(+), 36 deletions(-)
diff --git a/patchwork/views/series.py b/patchwork/views/series.py
index 7645596..cb3b721 100644
--- a/patchwork/views/series.py
+++ b/patchwork/views/series.py
@@ -17,6 +17,7 @@
# along with Patchwork; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+from django.http import HttpResponseForbidden
from django.conf import settings
from django.shortcuts import render, render_to_response
from django.shortcuts import get_object_or_404, get_list_or_404
@@ -25,6 +26,7 @@ from patchwork.models import Patch, Project, Bundle
from patchwork.models import Series, SeriesRevision, TestResult
from patchwork.requestcontext import PatchworkRequestContext
from patchwork.forms import PatchForm, CreateBundleForm
+import json
class SeriesListView(View):
@@ -44,6 +46,9 @@ class SeriesView(View):
def get(self, request, *args, **kwargs):
series = get_object_or_404(Series, pk=kwargs['series'])
revisions = get_list_or_404(SeriesRevision, series=series)
+patchform = PatchForm(project=series.project)
+createbundleform = CreateBundleForm()
+bundles = Bundle.objects.filter(owner=request.user)
for revision in revisions:
revision.patch_list = revision.ordered_patches().\
select_related('state', 'submitter')
@@ -56,19 +61,20 @@ class SeriesView(View):
'project': series.project,
'cover_letter': revision.cover_letter,
'revisions': revisions,
+'patchform': patchform,
+'createbundleform': createbundleform,
+'bundles': bundles,
})
def post(self, request, *args, **kwargs):
init_data = request.POST
-pa_id = init_data.get('patch', None)
-curr_rev = init_data.get('rev', None)
-patch = get_object_or_404(Patch, id=pa_id)
+patches = json.loads(init_data.get('patches'))
series = get_object_or_404(Series, pk=kwargs['series'])
-context = PatchworkRequestContext(request)
-context.project = patch.project
-editable = patch.is_editable(request.user)
-
revisions = get_list_or_404(SeriesRevision, series=series)
+context = PatchworkRequestContext(request)
+context.project = series.project
+form = None
+createbundleform = None
for revision in revisions:
revision.patch_list = revision.ordered_patches().\
select_related('state', 'submitter')
@@ -76,11 +82,6 @@ class SeriesView(View):
.filter(revision=revision, patch=None) \
.order_by('test__name').select_related('test')
-form = None
-createbundleform = None
-
-if editable:
-form = PatchForm(instance=patch)
if request.user.is_authenticated():
createbundleform = CreateBundleForm()
@@ -90,42 +91,57 @@ class SeriesView(View):
action = action.lower()
if action == 'createbundle':
-bundle = Bundle(owner=request.user, project=patch.project)
+bundle = Bundle(owner=request.user, project=series.project)
createbundleform = CreateBundleForm(instance=bundle,
data=request.POST)
if createbundleform.is_valid():
createbundleform.save()
-bundle.append_patch(patch)
-bundle.save()
-createbundleform = CreateBundleForm()
-context.add_message('Bundle %s created' % bundle.name)
elif action == 'addtobundle':
bundle = get_object_or_404(
Bundle, id=request.POST.get('bundle_id'))
-try:
-bundle.append_patch(patch)
-bundle.save()
-context.add_message('Patch added to bundle "%s"' %
-bundle.name)
-except Exception as ex:
-context.add_message("Couldn't add patch '%s' to bundle %s:\
- %s" % (patch.name, bundle.name, ex.message))
-
-# all other actions require edit privs
-elif not editable:
-return HttpResponseForbidden()
-
-elif action is None:
-form = PatchForm(data=request.POST, instance=patch)
-if form.is_valid():
-form.save()
-context.add_message('Patch ID: %s updated' % patch.pk)
+
+for pa_id in patches:
+patch = get_object_or_404(Patch, id=pa_id)
+editable = patch.is_editable(re
[yocto] [patchwork][PATCH 3/3] series.js: add patch-selection-checkbox control functions
This change adds control functions for individual and multiple
selection checkboxes.
[YOCTO #10822]
Signed-off-by: Jose Lamego
---
htdocs/js/series.js | 145
1 file changed, 125 insertions(+), 20 deletions(-)
diff --git a/htdocs/js/series.js b/htdocs/js/series.js
index bd75790..c4bbb0e 100644
--- a/htdocs/js/series.js
+++ b/htdocs/js/series.js
@@ -1,27 +1,47 @@
$(document).ready(function(){
$('[data-toggle="tooltip"]').tooltip()
revTab=document.getElementById('revs-list')
-coverView=document.getElementById('cover-letter-view'),
-patchView=document.getElementById('patch-view'),
+coverView=document.getElementById('cover-letter-view')
+patchView=document.getElementById('patch-view')
patchList=document.getElementById('patches-list')
-
+patchesInput=$( "input[name^='patches']" )
+seriesForms=document.getElementById('seriesForm')
+var patches = new Array()
+if ($( patchesInput[0] ).value){
+patches=json_decode($( patchesInput[0] ).value, true)
+}
+else{
+patches=[]
+}
revTab.style.border='none'
revTab.style.background='transparent'
revTab.style.padding='15px'
coverView.style.display='block'
patchView.style.display='none'
patchList.style.display='none'
+seriesForms.style.display='none'
document.getElementById('cover-letter-tab').onclick=function(){
coverView.style.display='block'
patchView.style.display='none'
patchList.style.display='none'
+patches=[]
+for (i=0; i')
+})
+})
+
+$( "input[name^='patch_id']" ).change(function(){
+patchView.style.display="none"
+uncheck_allSel()
+var p_id=$(this).attr('name').replace('patch_id:', '')
+if ($(this).prop('checked')){
+insert_patchId(p_id)
+for (i=0; ihttps://lists.yoctoproject.org/listinfo/yocto
[yocto] [patchwork][PATCH 2/3] series.html: add patch and bundle edition forms and checkboxes
This change adds patch and bundle edition forms, and patch selection
checkboxes.
[YOCTO #10822]
Signed-off-by: Jose Lamego
---
patchwork/templates/patchwork/series.html | 172 ++
1 file changed, 130 insertions(+), 42 deletions(-)
diff --git a/patchwork/templates/patchwork/series.html
b/patchwork/templates/patchwork/series.html
index 0ba1f14..3c2cad9 100644
--- a/patchwork/templates/patchwork/series.html
+++ b/patchwork/templates/patchwork/series.html
@@ -2,6 +2,9 @@
{% load person %}
{% load static %}
+{% load patch %}
+{% load listurl %}
+
{% block title %}{{project.name}}{% endblock %}
{% block headers %}
@@ -78,67 +81,152 @@ function toggle_headers(link_id, headers_id)
-{% if cover_letter %}
- Cover Letter
-
-
- {{ cover_letter }}
-
-
-{% else %}
- No cover letter was found for this series.
-{% endif %}
+{% if cover_letter %}
+ Cover Letter
+
+
+ {{ cover_letter }}
+
+
+{% else %}
+ No cover letter was found for this series.
+{% endif %}
-{% for revision in revisions %}
-
-
-Patches download mbox
-
-
-
+{% for revision in revisions %}
+
+Patches download mbox
+
+
- #
+ {% if user.is_authenticated %}
+
+
+
+ {% endif %}
Name
Submitter
State
-
-{% for patch in revision.patch_list %}
-
-
- {{ patch.name|default:"[no
subject]"|truncatechars:100 }}
- {{ patch.submitter|personify:project }}
- {{ patch.state }}
-
-{% endfor %}
-
+ {% for patch in revision.patch_list %}
+
+
+{% if user.is_authenticated %}
+
+
+
+{% endif %}
+{{ patch.name|default:"[no subject]"|truncatechars:100
}}
+{{ patch.submitter|personify:project }}
+{{ patch.state }}
+
+
+ {% endfor %}
+
-
-{% if revision.test_results %}
-Tests
-
-
-
-{% for test_result in revision.test_results %}
-{% include "patchwork/test-result.html" %}
-{% endfor %}
-
+{% endfor %}
+
+
+{% if user.is_authenticated %}
+
+ {% if patchform %}
+
+ Series patches edit
+
+{% csrf_token %}
+
+
+
+Change state:
+
+ {{ patchform.state }}
+ {{ patchform.state.errors }}
+
+
+
+Delegate to:
+
+{{ patchform.delegate }}
+{{ patchform.delegate.errors }}
+
+
+
+Archive:
+
+ {{ patchform.archived }}
+ {{ patchform.archived.errors }}
+
+
+
+
+
+ Update
+
+
+
+
+
+ {% endif %}
{% endif %}
+{% if createbundleform %}
+
+Bundling
+
+
+Create bundle:
+
+ {% if createbundleform.non_field_errors %}
+{{createbundleform.non_field_errors}}
+ {% endif %}
+
+{% csrf_token %}
+
+
+{% if createbundleform.name.errors %}
+ {{createbundleform.name.errors}}
+{% endif %}
+{{ createbundleform.name }}
+
+
+
+
+ {% if bundles %}
+
+ Add to bundle:
+
+
+{% csrf_token %}
+
+
+
+ {% for bundle in bundles %}
+{{bundle.name}}
+ {% endfor %}
+
+
+
+
+
+ {% endif %}
+
+
+{% endif %}
-{% endfor %}
-
-
{% endblock %}
--
2.7.4
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [OE-core] Yocto Project Status WW09’17
On 02/27/2017 08:59 AM, Jolley, Stephen K wrote: Current Dev Position: YP 2.3 M3 Next Deadline: YP 2.3 M3 by Feb. 27, 2017 *** FEATURE FREEZE for 2.3 is now in effect. *** SWAT team rotation: Anibal -> Todor on Feb. 24, 2017. SWAT team rotation: Todor -> Tracy on Mar. 4, 2017. https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team Key Status/Updates: ·We’re now into feature freeze for 2.3. ·We need to decide which recently submitted items should be merged. Some major items In particular: orpm v4/dnf to replace rpm v5/smart? IMHO, we should include dnf in 2.3 so folks can start playing with it and remove smart in 2.4. oMerging go into OE-Core? oSeparate out elderly GPLv2 into a separate layer? yes, but maybe not for 2.3 if its a large effort. oGraphics stack vulkan changes? The "Go" changes hit before the vulkan. Both should have the same rules applied which ever way the decision goes. oLarge queue of wic changes? I am leaning towards trying to take these even if they do delay the M3 release slightly as we do have some time left in M4 to stabilize. ·Unfortunately we continue to have stability issues in testing. There appear to be some intermittent failures which have crept into master and M3 merging will likely be delayed until those issues have been tracked down. They seem to affect sdk image size, breaking the 4GB limit and eSDKs stopping containing libxml2 under unknown circumstances, possibly amongst other issues. ·YP 2.2.1 has been released thanks to all that help. Proposed upcoming dot releases: YP 2.1.3 Cut off May 15, 2017 YP 2.1.3 Release by May 26, 2017 YP 2.2.2 Cut off May 29, 2017 YP 2.2.2 Release by June 9, 2017 I like the dot release schedule. Helps me focus. kind regards, Armin Key YP 2.3 Dates: YP 2.3 M3 Cutoff is Feb 27, 2017 YP 2.3 M3 Release is Mar. 10, 2017 YP 2.3 M4 Cutoff is April 10, 2017 YP 2.3 M4 Release is May 5, 2017 Tracking Metrics: WDD 2747 (last week 2682) (https://wiki.yoctoproject.org/charts/combo.html) Key Status Links for YP: https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.3_Status https://wiki.yoctoproject.org/wiki/Yocto_2.3_Schedule https://wiki.yoctoproject.org/wiki/Yocto_2.3_Features [If anyone has suggestions for other information you’d like to see on this weekly status update, let us know!] Thanks, */Stephen K. Jolley/**//* *Yocto Project Program Manager* *INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124 * (*Work Telephone*: (503) 712-0534 (*Cell*: (208) 244-4460 * *Email*:_stephen.k.jolley@intel.com_ -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-rockchip][PATCH v4] classes: rockchip-gpt-img: add
Hi Eddie,
On Tue 2017-02-28 @ 08:48:16 AM, Eddie Cai wrote:
> Could you also copy ${BOOT_IMG} to ${DEPLOY_DIR_IMAGE} . That is much
> earier for people find boot image. In case they want to flash boot
> partition alone.
All of this work is always done in DEPLOY_DIR_IMAGE.
$ bitbake core-image-minimal -e | grep "^DEPLOY_DIR_IMAGE="
DEPLOY_DIR_IMAGE="/z/rockchip/master/build/tmp-glibc/deploy/images/firefly-rk3288"
$ bitbake core-image-minimal -e | grep "^BOOT_IMG="
BOOT_IMG="boot.img"
With this class file as submitted in v4, if I build my first image I get:
$ ls -lh tmp-glibc/deploy/images/firefly-rk3288/
-rw-r--r-- 1 trevor users 137M Feb 27 14:05
core-image-minimal-firefly-rk3288-20170227190504.gpt-img
lrwxrwxrwx 1 trevor users 56 Feb 27 14:06
core-image-minimal-firefly-rk3288.gpt-img ->
core-image-minimal-firefly-rk3288-20170227190504.gpt-img
If I adjust the image then build it again I get:
$ ls -lh tmp-glibc/deploy/images/firefly-rk3288/
-rw-r--r-- 1 trevor users 137M Feb 27 14:05
core-image-minimal-firefly-rk3288-20170227190504.gpt-img
-rw-r--r-- 1 trevor users 137M Feb 27 14:06
core-image-minimal-firefly-rk3288-20170227190628.gpt-img
lrwxrwxrwx 1 trevor users 56 Feb 27 14:06
core-image-minimal-firefly-rk3288.gpt-img ->
core-image-minimal-firefly-rk3288-20170227190628.gpt-img
As you can see:
- the images appear in DEPLOY_DIR_IMAGE
- the first gpt-img is still there
- after each build the "core-image-minimal-firefly-rk3288.gpt-img" symlink
always points to the latest gpt-img file
Is this what you were hoping for?
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-rockchip][PATCH v4] classes: rockchip-gpt-img: add
Hi Trevor
2017-02-28 11:08 GMT+08:00 Trevor Woerner :
> Hi Eddie,
>
> On Tue 2017-02-28 @ 08:48:16 AM, Eddie Cai wrote:
> > Could you also copy ${BOOT_IMG} to ${DEPLOY_DIR_IMAGE} . That is much
> > earier for people find boot image. In case they want to flash boot
> > partition alone.
>
> All of this work is always done in DEPLOY_DIR_IMAGE.
>
> $ bitbake core-image-minimal -e | grep "^DEPLOY_DIR_IMAGE="
> DEPLOY_DIR_IMAGE="/z/rockchip/master/build/tmp-glibc/deploy/
> images/firefly-rk3288"
>
> $ bitbake core-image-minimal -e | grep "^BOOT_IMG="
> BOOT_IMG="boot.img"
>
> With this class file as submitted in v4, if I build my first image I get:
> $ ls -lh tmp-glibc/deploy/images/firefly-rk3288/
> -rw-r--r-- 1 trevor users 137M Feb 27 14:05
> core-image-minimal-firefly-rk3288-20170227190504.gpt-img
> lrwxrwxrwx 1 trevor users 56 Feb 27 14:06
> core-image-minimal-firefly-rk3288.gpt-img -> core-image-minimal-firefly-
> rk3288-20170227190504.gpt-img
>
> If I adjust the image then build it again I get:
> $ ls -lh tmp-glibc/deploy/images/firefly-rk3288/
> -rw-r--r-- 1 trevor users 137M Feb 27 14:05
> core-image-minimal-firefly-rk3288-20170227190504.gpt-img
> -rw-r--r-- 1 trevor users 137M Feb 27 14:06
> core-image-minimal-firefly-rk3288-20170227190628.gpt-img
> lrwxrwxrwx 1 trevor users 56 Feb 27 14:06
> core-image-minimal-firefly-rk3288.gpt-img -> core-image-minimal-firefly-
> rk3288-20170227190628.gpt-img
>
> As you can see:
> - the images appear in DEPLOY_DIR_IMAGE
> - the first gpt-img is still there
> - after each build the "core-image-minimal-firefly-rk3288.gpt-img" symlink
> always points to the latest gpt-img file
>
> Is this what you were hoping for?
>
I am not saying gpt image. What i mean is the single boot.img which contain
kernel zimage, device tree and extlinux file. with this file, i can use
below command update kernel and device tree. There are many people prefer
this way.
upgrade_tool db RK3288UbootLoader_V2.30.06.bin
upgrade_tool wl 32768 deploy/images/firefly-rk3288/boot.img
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Shared library question
On 2017-02-27 21:11, Max Krummenacher wrote:
Hi
Am Montag, den 27.02.2017, 15:03 +0100 schrieb Gary Thomas:
I trying to create a package am335x-pru-support which creates a
shared library used by another package pru-examples. The library
files installed with am335x-pru-support are (from /image)
-rwxr-xr-x 4 gthomas gthomas 17074 Feb 27 13:40 usr/lib/libprussdrv.a
lrwxrwxrwx 1 gthomas gthomas16 Feb 27 13:40 usr/lib/libprussdrv.so ->
libprussdrv.so.1
lrwxrwxrwx 1 gthomas gthomas18 Feb 27 13:40 usr/lib/libprussdrv.so.1 ->
libprussdrv.so.1.0
-rwxr-xr-x 1 gthomas gthomas 22092 Feb 27 13:40 usr/lib/libprussdrv.so.1.0
-rw-r--r-- 4 gthomas gthomas 8074 Feb 27 13:40 usr/include/pruss/prussdrv.h
-rw-r--r-- 4 gthomas gthomas 4286 Feb 27 13:40
usr/include/pruss/pruss_intc_mapping.h
These files are split by the packager as:
gthomas@europa:packages-split$ find am335x-pru-support | sort
am335x-pru-support
am335x-pru-support/usr
am335x-pru-support/usr/lib
am335x-pru-support/usr/lib/libprussdrv.so.1
am335x-pru-support/usr/lib/libprussdrv.so.1.0
gthomas@europa:packages-split$ find am335x-pru-support-dev | sort
am335x-pru-support-dev
am335x-pru-support-dev/usr
am335x-pru-support-dev/usr/include
am335x-pru-support-dev/usr/include/pruss
am335x-pru-support-dev/usr/include/pruss/prussdrv.h
am335x-pru-support-dev/usr/include/pruss/pruss_intc_mapping.h
am335x-pru-support-dev/usr/lib
am335x-pru-support-dev/usr/lib/libprussdrv.so
These files get staged correctly to pru-examples recipe-specific-sysroot
and I can build and link against them, using DEPENDS="am335x-pru-support".
The problem is that when my build (target recipe) uses
$(CC) my_target_program.c $(LDFLAGS) -lprussdrv
it gets satisfied by /usr/lib/libprussdrv.so and not /usr/lib/libprussdrv.so.1
This in turn appears to keep the pru-examples package from having
a runtime dependency against the am335x-pru-support package and the
necessary library file does not end up on my target.
I've tried to work through this, following many recipes as examples,
e.g. meta/recipes-multimedia/libogg (pattern for am335x-pru-support)
and meta/recipes-multimedia/flac (pattern for pru-examples). The
libogg/flac combo works correctly, mine does not :-(
Any pointers on what I might be doing wrong? I'm so close to getting
this stuff going, it's just the packaging that's going to claim the
last hairs from my head...
When linking a shared object file you have to pass the linker a soname which
adds compatible version
information into the share object file.
Have a look here:
http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/commit/recipes-bsp?id=7ff327a4e3e8e19d1e3f848
865b6b27ba9f6250b
http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html
Alternatively you can drop the libprussdrv.so.1 and libprussdrv.so.1.0, and
force with FILES... the
libprussdrv.so into the not -dev package.
Probably you would also want to INSANE_SKIP_${PN} = "dev-so".
Perfect, that worked a treat!
Thanks
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] error while compiling external module in Krogoth branch
On Tue, Feb 21, 2017 at 6:31 AM praveen vattipalli
wrote:
> Hi All,
> I am using poky-krogoth source and meta-altera layer. I am building kernel
> locally using externalsrc. while building external module i am getting
> error.
>
Which branch of meta-altera are you using
>
>
>
> ERROR: Task do_make_scripts in
> /home/praveenk/source/platform/build/../meta-skeleton/recipes-kernel/hello-mod/
> hello-mod_0.1.bb depends upon non-existent task do_shared_workdir in
> /home/praveenk/source/platform/build/../meta-altera/recipes-kernel/linux/
> linux-altera-ltsi_4.1.22.bb
> ERROR: Command execution failed: 1
>
> linux.bb contains
>
> LINUX_VERSION = "4.1.22"
> LINUX_VERSION_SUFFIX = "-ltsi"
>
> include linux-altera.inc
>
> SRC_URI = "file://${EXTERNALSRC}"
>
> LIC_FILES_CHKSUM =
> "file://${S}/COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7"
>
> BUILD_DEFCONFIG = "socfpga_defconfig"
> EXTERNALSRC = "${TOPDIR}/../meta-altera/recipes-kernel/linux/files"
> EXTERNALSRC_BUILD = "${TOPDIR}/../meta-altera/recipes-kernel/linux/files"
>
> SRCREV_pn-${PN} = "${AUTOREV}"
>
> S= "${EXTERNALSRC}"
>
> hello-mod.bb contains
>
> SUMMARY = "Example of how to build an external Linux kernel module"
> LICENSE = "GPLv2"
> LIC_FILES_CHKSUM = "file://COPYING;md5=12f884d2ae1ff87c09e5b7ccc2c4ca7e"
>
> inherit module
>
> SRC_URI = "file://Makefile \
>file://hello.c \
>file://COPYING \
> "
>
>
> S = "${WORKDIR}"
>
> # The inherit of module.bbclass will automatically name module packages
> with
> # "kernel-module-" prefix as required by the oe-core build environment.
> ~
>
>
> Am I missing anything?
>
> Thanks,
> Praveen.
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
