Re: [linux-yocto] Having issues while building linux kernel using poky-dora-10.0.0
On 12/18/2013, 6:16 PM, Ravi Rao wrote: Hi Bruce, Thanks a lot for a very quick response. Please keep me in loop if you find any thing about this issue. Also I was wondering if there is a work around that I can use to get past this issue. Doing a manual clone, putting it in a local directory and then changing the SRC_URI to point to it, versus the git.yoctoproject.org variant should get you up and running. Bruce Regards, Ravi.. On 12/17/13 19:32, Bruce Ashfield wrote: On 12/17/2013, 8:18 PM, Ravi Rao wrote: Hi All, I am using Ubuntu 12.04 Host and downloaded poky-dora-10.0.0 and trying to build 3.10.x kernel for mpc8315e-rdb and I keep getting the fetch failure error. Any idea what may be causing this. This is the second report of this issue in a few days. I've checked the repos with manual clones and the commits/and branches all look fine. I've added Michael to the cc', since he may be looking into the infrastructure on this one already. Bruce rrao@svtauto001:~/poky-dora-build$ git --version git version 1.7.9.5 rrao@svtauto001:~/poky-dora-build$ uname -a Linux svtauto001 3.8.0-34-generic #49~precise1-Ubuntu SMP Wed Nov 13 18:05:00 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux Any help in resolving this is greatly appreciated... rrao@svtauto001:~/poky-dora-build$ bitbake virtual/kernel Parsing recipes: 100% |###| Time: 00:00:24 Parsing of 855 .bb files complete (0 cached, 855 parsed). 1186 targets, 53 skipped, 0 masked, 0 errors. NOTE: Resolving any missing task queue dependencies Build Configuration: BB_VERSION= "1.20.0" BUILD_SYS = "x86_64-linux" NATIVELSBSTRING = "Ubuntu-12.04" TARGET_SYS= "powerpc-poky-linux" MACHINE = "mpc8315e-rdb" DISTRO= "poky" DISTRO_VERSION= "1.5" TUNE_FEATURES = "m32 fpu-soft ppce300c3" TARGET_FPU= "soft" meta meta-yocto meta-yocto-bsp= ":" NOTE: Preparing runqueue NOTE: Executing SetScene Tasks NOTE: Executing RunQueue Tasks WARNING: Failed to fetch URL http://download.savannah.gnu.org/releases/quilt/quilt-0.60.tar.gz, attempting MIRRORS if available WARNING: Failed to fetch URL git://git.yoctoproject.org/linux-yocto-3.10.git;bareclone=1;branch=standard/fsl-mpc8315e-rdb,meta;name=machine,meta, attempting MIRRORS if available ERROR: Fetcher failure: Fetch command failed with exit code 128, output: fatal: unable to connect to git.yoctoproject.org: git.yoctoproject.org[0: 140.211.169.56]: errno=Connection timed out ERROR: Function failed: Fetcher failure for URL: 'git://git.yoctoproject.org/linux-yocto-3.10.git;bareclone=1;branch=standard/fsl-mpc8315e-rdb,meta;name=machine,meta'. Unable to fetch URL from any source. ERROR: Logfile of failure stored in: /home/rrao/poky-dora-build/tmp/work/mpc8315e_rdb-poky-linux/linux-yocto/3.10.11+gitAUTOINC+363bd856c8_12dc46ba4e-r0/temp/log.do_fetch.3704 ERROR: Task 6 (/sdn/hpass/poky-dora-10.0.0/meta/recipes-kernel/linux/linux-yocto_3.10.bb, do_fetch) failed with exit code '1' WARNING: Failed to fetch URL git://git.yoctoproject.org/yocto-kernel-tools.git, attempting MIRRORS if available ERROR: Fetcher failure: Fetch command failed with exit code 128, output: fatal: unable to connect to git.yoctoproject.org: git.yoctoproject.org[0: 140.211.169.56]: errno=Connection timed out ERROR: Function failed: Fetcher failure for URL: 'git://git.yoctoproject.org/yocto-kernel-tools.git'. Unable to fetch URL from any source. ERROR: Logfile of failure stored in: /home/rrao/poky-dora-build/tmp/work/x86_64-linux/kern-tools-native/0.2+gitAUTOINC+a42509b01c-r12/temp/log.do_fetch.8559 ERROR: Task 27 (/sdn/hpass/poky-dora-10.0.0/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb, do_fetch) failed with exit code '1' NOTE: Tasks Summary: Attempted 233 tasks of which 3 didn't need to be rerun and 2 failed. Waiting for 0 running tasks to finish: Summary: 2 tasks failed: /sdn/hpass/poky-dora-10.0.0/meta/recipes-kernel/linux/linux-yocto_3.10.bb, do_fetch /sdn/hpass/poky-dora-10.0.0/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb, do_fetch Summary: There were 3 WARNING messages shown. Summary: There were 4 ERROR messages shown, returning a non-zero exit code. rrao@svtauto001:~/poky-dora-build$ ___ linux-yocto mailing list linux-yo...@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto ___ linux-yocto mailing list linux-yo...@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
[yocto] deploy/images
Hello all, I have a few questions about the files in deploy/images. When working with beagleboard I would see MLO u-boot and uImage. I would copy these to DOS partition. Now Working with ZedBoard I have been using the BOOT.bin, devicetree.dtb and zImage. The BOOT.bin was created with xilinx FSBL and system.bit using the Xilinx tools. The zImage and devicetree.dtb were created with a kernel that was modified from linux-digilent . https://github.com/Digilent/linux-digilent.git. Yocto item that I have been using is custom-image-zedboard-20131214212545.rootfs.ext2. What tools do I need to use The files in deploy/images custom-image-zedboard-20131214212545.rootfs.cpio custom-image-zedboard-20131214212545.rootfs.ext2 custom-image-zedboard-20131214212545.rootfs.ext2.gz custom-image-zedboard-20131214212545.rootfs.ext2.gz.u-boot custom-image-zedboard.cpio custom-image-zedboard.ext2 custom-image-zedboard.ext2.gz custom-image-zedboard.ext2.gz.u-boot modules--3.8-xilinx+git0+6a0bedad60e2bca8d9b50bf81b9895e29e31a6d7-r1-zedboard-20131214164131.tgz README_-_DO_NOT_DELETE_FILES_IN_THIS_DIRECTORY.txt uImage uImage--3.8-xilinx+git0+6a0bedad60e2bca8d9b50bf81b9895e29e31a6d7-r1-zedboard-20131214164131.bin uImage--3.8-xilinx+git0+6a0bedad60e2bca8d9b50bf81b9895e29e31a6d7-r1-zynq-zed-20131214164131.dtb uImage-zedboard.bin uImage-zynq-zed.dtb Is uImage-zedboard.bin a u-boot type file? Which manual should I read about transferring these files to the mmc. Any and all help will be appreciated. Thanks ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Fwd: Kontron CONFIG_I2C_KEMPLD support in Fish River Island 2? Or Crownbay?
Hit the send too early. My questions are: What kernel versions and what BSPs of Yocto support the CONFIG_I2C_KEMPLD? We are using Linux Kernel 3.8.4 but we found a link saying KEMPLD is supported in a Linux kernel version as high as 3.1.2. Anyone out there know about this? (see below for first part) -- Forwarded message -- From: Bill Martin Date: Wed, Dec 18, 2013 at 3:54 PM Subject: Kontron CONFIG_I2C_KEMPLD support in Fish River Island 2? Or Crownbay? To: yocto@yoctoproject.org We are in need of enabling the CONFIG_I2C_KEMPLD for a build for our Kontron (architecture is x86). We have been using the Crownbay BSP. But of course I did a google search and found patches in the Linux kernel for allowing i2c_kempld. Also these patches were associated with Fish River Island II. I was under the impression that these names "Crownbay," "Fish River Island II" and such were all part of Yocto. The patches I encountered were dated earlier this year and I was assuming the Fish River Island II BSP for our Dylan (9.0.2) build would support I2C ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Kontron CONFIG_I2C_KEMPLD support in Fish River Island 2? Or Crownbay?
We are in need of enabling the CONFIG_I2C_KEMPLD for a build for our Kontron (architecture is x86). We have been using the Crownbay BSP. But of course I did a google search and found patches in the Linux kernel for allowing i2c_kempld. Also these patches were associated with Fish River Island II. I was under the impression that these names "Crownbay," "Fish River Island II" and such were all part of Yocto. The patches I encountered were dated earlier this year and I was assuming the Fish River Island II BSP for our Dylan (9.0.2) build would support I2C ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [DOCS][PATCH] profile-manual-usage: remove meta-toolchain-sdk references
[YOCTO #5676] Signed-off-by: Saul Wold --- documentation/profile-manual/profile-manual-usage.xml | 1 - 1 file changed, 1 deletion(-) diff --git a/documentation/profile-manual/profile-manual-usage.xml b/documentation/profile-manual/profile-manual-usage.xml index 5279730..e1b4250 100644 --- a/documentation/profile-manual/profile-manual-usage.xml +++ b/documentation/profile-manual/profile-manual-usage.xml @@ -2175,7 +2175,6 @@ core-image-minimal core-image-sato meta-toolchain -meta-toolchain-sdk adt-installer meta-ide-support -- 1.8.3.1 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] poky-tiny, boot and filesystems
Rudi, >From a first view, my problem is that my embedded Yocto-Linux device takes too long from the application of power to the time that it is first able to a) signal the user that the device is waking up and b) respond to events from I/O (Ethernet and CAN). (40+ seconds prior to shifting to poky-tiny, not counting BIOS delays) >From another view, my problem is a lack of understanding about the processes involved during that time, and how the poky-tiny distro is intended to be applied to resolve the 'first view' problem. Yes, poky-tiny produces an image that is both smaller and starts fewer services. It also uses tiny-init which I believe is neither SysV init nor systemd. Outside of the scope of poky-tiny, I need some way to boot my hardware, and the poky-tiny guides seem to stop once they're able to boot qemu. If I simply create an ext2 boot partition on my sdcard and copy the poky-tiny.ext2 image to it, nothing boots. If I also install grub to that partition and provide a grub.cfg, I can boot. (The selection of grub as my boot loader may be my first mistake ?) In that grub.cfg are two critical lines: 1) linux /boot/bzImage root=/dev/mmcblk0p1 and 2) initrd /boot/core-image-minimal-crownbay.cpio.gz If I just do 1), I can boot quickly, but I can't do much else because the file system is mounted read-only. I _want_ most of the file system to be read-only, but need to be able to start the network and do some other 'normal' tasks that require write access to some areas of the file system. Once my user space application is running, my app will use another (USB) device for persistent data storage. If I also do 2), more works and I can start the network, but of course the system takes a bit longer while it's loading the ramdisk. If this is the expected and optimal mode of operation, then I'm done. But am I wrong in thinking that the contents of the .cpio.gz file replaces all of what is in the .ext2 image once it is loaded? I'm confused by the fact that files I added to the tiny-init recipe end up in both the .ext2 file image (just stage 1) and the resulting file system after both 1) & 2). It's not that the recipe doesn't work, or that the system is not functional in the end, but a question of whether there's a duplication of effort involved or if there's just a better way to do it for my specific requirements. I understand that these questions stray well beyond the scope of this mailing list, but at the same time, any references to the poky-tiny distro probably won't be understood outside it. Thanks, John On Wed, Dec 18, 2013 at 12:18 PM, Rudolf Streif wrote: > John, > > What is your actual problem? You appended the tiny-init recipe and your > changes do or do not get put into the rootfs? If you could post your recipe > then folks can look at it. > > As far as boot time is concerned, you need to distinguish boot loader and > kernel boot from user space. It looks as if you are trying to optimize your > user space boot time by using an image that starts less services. What > services you need of course depends on your application. To optimize user > space boot process you may also want to investigate systemd instead of SysV > init. > > Rudi > > > On Wed, Dec 18, 2013 at 8:26 AM, r10kindsofpeople < > r10kindsofpeo...@gmail.com> wrote: > >> I've been beating my head for a few days now, and would love a little >> guidance. Acknowledging that there are multiple ways to skin the cat, my >> immediate goal is to reduce the boot time, presumably using poky-tiny. >> >> I have poky-tiny building for my hardware under dora. >> I have it booting on crownbay hardware by copying the .ext2 image onto >> the sdcard, installing grub, copying the .cpio.gz file on to the card, and >> using grub to load the kernel image and initrd the filesystem. >> >> I'm wondering if that last bit about initrd is the 'best' option, or if I >> should be overlaying a write-able filesystem on top of the original .ext2 >> file system? How? >> >> And I'm pretty sure I've not got something right...I figured out how to >> .bbappend the tiny-init recipe and get my own edits into 'init' and >> 'rc.local', but it appears those files and changes made it into both the >> ext2 file system and the .cpio.gz initrd file system. On one hand, I'm >> grateful since it works, but 'both' seems to point at me getting something >> wrong. >> >> Any links to clear tutorials would be greatly appreciated. There's a >> wealth of information available on this topic, but none that seems >> comprehensive (that I've found), and as I've said, each seems to take a >> different approach, leaving out a step or two along the way. >> >> John >> >> >> >> ___ >> yocto mailing list >> yocto@yoctoproject.org >> https://lists.yoctoproject.org/listinfo/yocto >> >> > > ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] poky-tiny, boot and filesystems
John, What is your actual problem? You appended the tiny-init recipe and your changes do or do not get put into the rootfs? If you could post your recipe then folks can look at it. As far as boot time is concerned, you need to distinguish boot loader and kernel boot from user space. It looks as if you are trying to optimize your user space boot time by using an image that starts less services. What services you need of course depends on your application. To optimize user space boot process you may also want to investigate systemd instead of SysV init. Rudi On Wed, Dec 18, 2013 at 8:26 AM, r10kindsofpeople < r10kindsofpeo...@gmail.com> wrote: > I've been beating my head for a few days now, and would love a little > guidance. Acknowledging that there are multiple ways to skin the cat, my > immediate goal is to reduce the boot time, presumably using poky-tiny. > > I have poky-tiny building for my hardware under dora. > I have it booting on crownbay hardware by copying the .ext2 image onto the > sdcard, installing grub, copying the .cpio.gz file on to the card, and > using grub to load the kernel image and initrd the filesystem. > > I'm wondering if that last bit about initrd is the 'best' option, or if I > should be overlaying a write-able filesystem on top of the original .ext2 > file system? How? > > And I'm pretty sure I've not got something right...I figured out how to > .bbappend the tiny-init recipe and get my own edits into 'init' and > 'rc.local', but it appears those files and changes made it into both the > ext2 file system and the .cpio.gz initrd file system. On one hand, I'm > grateful since it works, but 'both' seems to point at me getting something > wrong. > > Any links to clear tutorials would be greatly appreciated. There's a > wealth of information available on this topic, but none that seems > comprehensive (that I've found), and as I've said, each seems to take a > different approach, leaving out a step or two along the way. > > John > > > > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto > > ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] poky-tiny, boot and filesystems
I've been beating my head for a few days now, and would love a little guidance. Acknowledging that there are multiple ways to skin the cat, my immediate goal is to reduce the boot time, presumably using poky-tiny. I have poky-tiny building for my hardware under dora. I have it booting on crownbay hardware by copying the .ext2 image onto the sdcard, installing grub, copying the .cpio.gz file on to the card, and using grub to load the kernel image and initrd the filesystem. I'm wondering if that last bit about initrd is the 'best' option, or if I should be overlaying a write-able filesystem on top of the original .ext2 file system? How? And I'm pretty sure I've not got something right...I figured out how to .bbappend the tiny-init recipe and get my own edits into 'init' and 'rc.local', but it appears those files and changes made it into both the ext2 file system and the .cpio.gz initrd file system. On one hand, I'm grateful since it works, but 'both' seems to point at me getting something wrong. Any links to clear tutorials would be greatly appreciated. There's a wealth of information available on this topic, but none that seems comprehensive (that I've found), and as I've said, each seems to take a different approach, leaving out a step or two along the way. John ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] libxml2 error
Please don't take conversations off the list, so that others can help/learn.
On 18 December 2013 14:22, wuteng wu wrote:
> I'm newbie to Yocto, could u tell me more details?
> I found some info under the dir:
> /home/teng/poky/meta/recipes-core/libxml/libxml2.inc as below:
>
> EXTRA_OECONF = "--without-python --without-debug --without-legacy
> --without-catalog --without-docbook --with-c14n --without-lzma
> --with-fexceptions"
> EXTRA_OECONF_class-native = "--with-python=${STAGING_BINDIR}/python
> --without-legacy --with-catalog --without-docbook --with-c14n
> --without-lzma"
> EXTRA_OECONF_class-nativesdk = "--with-python=${STAGING_BINDIR}/python
> --without-legacy --with-catalog --without-docbook --with-c14n
> --without-lzma"
> EXTRA_OECONF_linuxstdbase = "--without-python --with-debug --with-legacy
> --with-catalog --with-docbook --with-c14n --without-lzma"
>
> Is the --without-python option that i need to modify?
Yes, apologies I got the option name wrong when writing the mail.
Ross
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] libxml2 error
On 18 December 2013 07:50, wuteng wu wrote: > I built the Yocto 1.5 project for my SAMA5D34-EK board, i add the libxml2 by > IMAGE_INSTALL_append = " libxml2", i got the image and programmed it into > NAND Flash of the board, but when i type python -c "import libxml2" from the > hyper Terminal , it gave out the message: "Traceback (most recent call > last): File "", line 1, in ImportError: No module named libxml2" > > I can find libxml2.so.2.9 under the usr/lib dir, i'm wondering where does > the error comes from, could anyone help me to solve the problem ? Thx. Our libxml2 is built without Python, you'll need to remove the --disable-python options from the recipe. Ross ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Setting PV dynamically in a recipe
On Wed, Dec 18, 2013 at 01:29:25AM +, Brad Litterell wrote:
> Hi Paul,
>
> Thanks for that tip. For my private packages I don't build directly from
> git, but from a tarball (in turn created from my working directory) because I
> want to be able to build the source I'm working on without committing it to
> git.
>
> In an ideal world, I'd like to to be able to build in two modes: dev &
> release. Release mode would use the git-based solution (and enforce building
> from git), and in the dev mode, build from something like externalsrc. (The
> reason I don't use externalsrc directly is because it didn't detect changes
> in the underlying external source, so I created a script that does and
> updates the tarball.)
>
> What is the best way to switch recipes between dev & test modes like that.
> It appears debug-tweaks is only used in image recipes, so I don't know
> whether I should (or could) use something like this in a package recipe:
>
> SRC_URI += '${@base_contains("EXTRA_IMAGE_FEATURES", "debug-tweaks",
> "...tarball...", "...git..."}'
>
> or whether something like that is asking for trouble. My current solution is
> manual - edit the recipe, but that feels kinda lame.
>
> It seems like most of the yocto build tools assume building directly from git
> (or with external-src but without dependency checking).
>
> Any suggestions?
Don't use *IMAGE_FEATURES* to in recipe conditionals.
When you're building some package you don't know in which image it will
be included so you cannot know with which *IMAGE_FEATURES* it should be
built.
It's true that EXTRA_IMAGE_FEATURES are often set in DISTRO config, but
still it's unsafe to assume they are "global". With improved
base_contains and sstate interaction, using some flag in DISTRO_FEATURES
shouldn't cause so many packages to rebuild, so it could be usable for
"debug-build" flag.
>
> From: Paul Eggleton [paul.eggle...@linux.intel.com]
> Sent: Tuesday, December 17, 2013 12:24 PM
> To: Brad Litterell
> Cc: zhenhua@freescale.com; yocto@yoctoproject.org
> Subject: Re: [yocto] Setting PV dynamically in a recipe
>
> Hi Brad,
>
> On Tuesday 17 December 2013 19:46:11 Brad Litterell wrote:
> > Thank you for the reply. However, That's not what I'm looking for. I
> > already get the latest version of the source code.
> >
> > What I'm really after is the ability to generate output packages that have
> > increasing version numbers so I can use the package manager to update them.
> >
> > I think Martin's subsequent reply is the secret to use PKGV. I didn't know
> > about that variable.
>
> You don't need to use any special classes to get this behaviour. Put this in
> your recipe (replacing 1.2.3 with the appropriate base version you are
> building):
>
> PV = "1.2.3+git${SRCPV}"
>
> and enable the PR service, which will ensure SRCREV changes always increment
> the version properly:
>
> http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#working-with-a-pr-service
>
> Cheers,
> Paul
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
--
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
signature.asc
Description: Digital signature
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
