Re: [yocto] Migrate, or not Migrate, that's the question!!!
On 2 February 2016 at 08:40, Diego Sueiro wrote: > Khem, > > On 1 February 2016 at 18:34, Khem Raj wrote: > >> >> I think you have to think about what you are getting into. You are trying >> to mix quite two different things are create third one. If I were you, I >> would just >> keep myself synced with upstream as much as I could, Don’t look one way, >> you have to look into time and effort you will spend on maintaining this new >> jargon for years to come. >> > > Thanks for your opinion. > > I agree with you, but this decision is out of my responsibility. > > We already had problems on backporting device drivers and packages. > I believe that for the next generation of the product we'll try to keep > synced with upstream, but until then I want to try to use a recent version > of Yocto/OE > And just to keep it clear. We are talking about a project with 272 packages and 1.5 MLOC (proprietary embedded code) which took 4 years to be developed. Regards, -- *dS Diego Sueiro Administrador do Embarcados www.embarcados.com.br <http://www.embarcados.com.br/?utm_source=assinatura_diego&utm_medium=e-mail&utm_campaign=Assinatura%20Email%20Diego> /*long live rock 'n roll*/ -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Migrate, or not Migrate, that's the question!!!
Khem, On 1 February 2016 at 18:34, Khem Raj wrote: > > I think you have to think about what you are getting into. You are trying > to mix quite two different things are create third one. If I were you, I > would just > keep myself synced with upstream as much as I could, Don’t look one way, > you have to look into time and effort you will spend on maintaining this new > jargon for years to come. > Thanks for your opinion. I agree with you, but this decision is out of my responsibility. We already had problems on backporting device drivers and packages. I believe that for the next generation of the product we'll try to keep synced with upstream, but until then I want to try to use a recent version of Yocto/OE. Regards, -- *dS Diego Sueiro Administrador do Embarcados www.embarcados.com.br <http://www.embarcados.com.br/?utm_source=assinatura_diego&utm_medium=e-mail&utm_campaign=Assinatura%20Email%20Diego> /*long live rock 'n roll*/ -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Migrate, or not Migrate, that's the question!!!
Bryan, On 28 January 2016 at 13:49, Bryan Evenson wrote: > In my opinion, I think in the long term it would be easier to make a clean > break. Start with a recent branch, like Jethro, get a minimal image to > build for your hardware and then add your own layer with your proprietary > recipes. I think that will be a lot easier than trying to get oe-core > working with 5+ year old versions of gcc and eglibc. Yes, that would mean > additional testing, but it may be less testing/integration than you are > currently doing just trying to keep your current image maintained. > > > Thanks for your opinion. But unfortunately, updating the packages is out of scope in this moment since the product is certificated and doing this will require a new process. Maybe I can use the Arago External Pre-built Binary Toolchain (2011-09)[1] in which is supported by TI until daisy branch[2]. [1] - http://software-dl.ti.com/sdoemb/sdoemb_public_sw/arago_toolchain/2011_09/index_FDS.html [2] - http://arago-project.org/git/?p=meta-arago.git;a=tree;f=meta-arago-extras/conf/distro/include;h=23e7bcba85ab80e4bf813fd43f64c61a12ba3f0a;hb=refs/heads/daisy Regards, -- *dS Diego Sueiro Administrador do Embarcados www.embarcados.com.br <http://www.embarcados.com.br/?utm_source=assinatura_diego&utm_medium=e-mail&utm_campaign=Assinatura%20Email%20Diego> /*long live rock 'n roll*/ -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Migrate, or not Migrate, that's the question!!!
Hello folks, I'm in a project that uses openembedded-classic and Arago stuff to build the product's image. A lot of problems have been raised in relation to build time, dependencies handling, integrating new recipes, recipes tweaks etc. We are evaluating the possibility to migrate to Yocto Project (Openembedded Core). But some requirements MUST be met: - eglibc (2.12), gcc (4.5.3), u-boot, kernel and other packages versions must have be maintained. We cannot update it versions since this product is in the field for a couple of years and it was heavily tested and certified. I read some guidelines[1][2], but my main concern is if I'm going into a "can of worms", as most packages dating from 2011 and I do not know how much the OpenEmbedded-core is "coupled" to glibc and gcc versions, for example. I think the ideal scenario is to use the most recent Yocto version and have all nice features available. Perhaps to achieve this I have to migrate first to "2011-1" branch of openembedded-core and have all packages versions and custom modifications ported to the new openembedded platform and then migrate to the a newer version. I really appreciate if you guys have some thoughts, tips or some kind of information that can help me to take this decision and move forward. [1] http://www.yoctoproject.org/docs/2.0/mega-manual/mega-manual.html#migration [2] http://www.openembedded.org/wiki/Migrating_metadata_to_OE-Core Regards, -- *dS Diego Sueiro Administrator of Embarcados www.embarcados.com.br <http://www.embarcados.com.br/?utm_source=assinatura_diego&utm_medium=e-mail&utm_campaign=Assinatura%20Email%20Diego> -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Build optimization question
Take a look at poky-tiny distro: http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta-yocto/conf/distro/poky-tiny.conf As you are using BBB you can optimize u-boot code and remove some board detection steps. I noticed that MLO generated by u-boot 2014.07 mainline is too much faster than the old ones. Regards, -- *dS Diego Sueiro sent from mobile. Em 08/11/2014 12:54, "Burton, Ross" escreveu: > > On 8 November 2014 14:23, Brian Hutchinson wrote: > >> I'm planning to just start excluding some of the packages in it ... I >> don't need sound, wireless, Bluetooth etc. >> >> > If you don't need sound, wifi, and bluetooth then remove the relevant > flags from DISTRO_FEATURES and they'll never be built. > > Ross > > -- > ___ > 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] Yocto Daisy - Beaglebone Black - core-image-minimal - Error: do_compile
Hi prashanthg, On Fri, Oct 24, 2014 at 8:24 AM, prashanthg wrote: > I have been facing issues with 'bitbake core-image-minimal' with Qt5 > library added for BBB. > > Error Log: http://pastebin.com/ADdyJnz8 > > Build Configuration: > BB_VERSION= "1.22.0" > BUILD_SYS = "i686-linux" > NATIVELSBSTRING = "Ubuntu-13.10" > TARGET_SYS= "arm-poky-linux-gnueabi" > MACHINE = "beaglebone" > DISTRO= "poky" > DISTRO_VERSION= "1.6.1" > TUNE_FEATURES = "armv7a vfp neon callconvention-hard cortexa8" > TARGET_FPU= "vfp-neon" > meta > meta-yocto > meta-yocto-bsp= "daisy:bda51ee7821de9120f6f536fcabe592f2a0c8a37" > meta-oe = "daisy:518cd119a8724dbd485a5d5c5047de59e8fbd652" > meta-ti = "daisy:80924d3bba59d6920217216c73af43fdd40d0152" > meta-qt5 = "daisy:c29c317e0f22202bfaa85329a580564bbc179089" > > It would be great if you can help me solve this issue. > > Thanks and Regards, > Prashanth I have Qt5.3.2 (meta-qt5 on master branch) with accelerated graphics built and running on BBB. I did not have seen this error. Note that you need to remove meta-yocto-bsp from your bblayers.conf to get the BSP support from meta-ti. Regards, -- *dS Diego Sueiro Administrador do Embarcados www.embarcados.com.br <http://www.embarcados.com.br/?utm_source=assinatura_diego&utm_medium=e-mail&utm_campaign=Assinatura%20Email%20Diego> /*long live rock 'n roll*/ -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Rootfs with F2FS.
Any thoughts or advice? Regards, -- *dS Diego Sueiro Administrador do Embarcados www.embarcados.com.br <http://www.embarcados.com.br/?utm_source=assinatura_diego&utm_medium=e-mail&utm_campaign=Assinatura%20Email%20Diego> /*long live rock 'n roll*/ On Thu, Sep 25, 2014 at 12:28 PM, Diego Sueiro wrote: > Folks, > > As I could inspect on openembedded/yocto source code I didn't found > anything related with images created with F2FS. Just found f2fs-tools > recipe. > > What needs to be done to get a rootfs with F2FS? > Just need to make it's entries at image_types.bbclass? > > What about u-boot? > I think it cannot read F2FS partitions, correct? > If true, I have to put zImage and dtb in a fat or extX partition to get it > loaded from u-boot. > > > Regards, > > -- > *dS > Diego Sueiro > > Administrador do Embarcados > www.embarcados.com.br > <http://www.embarcados.com.br/?utm_source=assinatura_diego&utm_medium=e-mail&utm_campaign=Assinatura%20Email%20Diego> > > /*long live rock 'n roll*/ > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Rootfs with F2FS.
Folks, As I could inspect on openembedded/yocto source code I didn't found anything related with images created with F2FS. Just found f2fs-tools recipe. What needs to be done to get a rootfs with F2FS? Just need to make it's entries at image_types.bbclass? What about u-boot? I think it cannot read F2FS partitions, correct? If true, I have to put zImage and dtb in a fat or extX partition to get it loaded from u-boot. Regards, -- *dS Diego Sueiro Administrador do Embarcados www.embarcados.com.br <http://www.embarcados.com.br/?utm_source=assinatura_diego&utm_medium=e-mail&utm_campaign=Assinatura%20Email%20Diego> /*long live rock 'n roll*/ -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] yocto 1.6 - beaglebone black - cape manager
Takk, On Wed, Sep 24, 2014 at 5:20 PM, TakkTakk wrote: > ok, i changed "bootz" to "bootm" and i kept S2 swith pressed. > Yocto not booting, two leds D2, D3 is shining. > > Serial console output: > > U-Boot SPL 2013.04-dirty (Sep 09 2014 - 21:38:22) > musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, > SoftConn) > musb-hdrc: MHDRC RTL version 2.0 > musb-hdrc: setup fifo_mode 4 > musb-hdrc: 28/31 max ep, 16384/16384 memory > USB Peripheral mode controller at 47401000 using PIO, IRQ 0 > musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, > SoftConn) > musb-hdrc: MHDRC RTL version 2.0 > musb-hdrc: setup fifo_mode 4 > musb-hdrc: 28/31 max ep, 16384/16384 memory > USB Host mode controller at 47401800 using PIO, IRQ 0 > OMAP SD/MMC: 0 > reading u-boot.img > reading u-boot.img > > > U-Boot 2013.04-dirty (Sep 09 2014 - 21:38:22) > > I2C: ready > DRAM: 512 MiB > WARNING: Caches not enabled > NAND: No NAND device found!!! > 0 MiB > MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 > *** Warning - readenv() failed, using default environment > > musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, > SoftConn) > musb-hdrc: MHDRC RTL version 2.0 > musb-hdrc: setup fifo_mode 4 > musb-hdrc: 28/31 max ep, 16384/16384 memory > USB Peripheral mode controller at 47401000 using PIO, IRQ 0 > musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, > SoftConn) > musb-hdrc: MHDRC RTL version 2.0 > musb-hdrc: setup fifo_mode 4 > musb-hdrc: 28/31 max ep, 16384/16384 memory > USB Host mode controller at 47401800 using PIO, IRQ 0 > Net:not set. Validating first E-fuse MAC > cpsw, usb_ether > Hit any key to stop autoboot: 0 > gpio: pin 53 (gpio 53) value is 1 > mmc0 is current device > micro SD card found > mmc0 is current device > gpio: pin 54 (gpio 54) value is 1 > SD/MMC found on device 0 > reading uEnv.txt > 527 bytes read in 4 ms (127.9 KiB/s) > Loaded environment from uEnv.txt > Importing environment from mmc ... > Running uenvcmd ... > reading uImage > 4368264 bytes read in 499 ms (8.3 MiB/s) > reading /dtbs/am335x-boneblack.dtb > 29192 bytes read in 10 ms (2.8 MiB/s) > ## Booting kernel from Legacy Image at 8020 ... >Image Name: Linux-3.8.13 >Image Type: ARM Linux Kernel Image (uncompressed) >Data Size:4368200 Bytes = 4.2 MiB >Load Address: 80008000 >Entry Point: 80008000 >Verifying Checksum ... OK > ## Flattened Device Tree blob at 80f8 >Booting using the fdt blob at 0x80f8 >Loading Kernel Image ... OK > OK >Using Device Tree in place at 80f8, end 80f8a207 > > Starting kernel ... > > Uncompressing Linux... done, booting the kernel. > Hummm. That's strange. I don't know if kernel 3.8.13 populate the serial debug interface as ttyO0 or ttyS0. I think you can remove your uEnv.txt file from FAT partition and powerup the board by pressing the boot switch, The u-boot from meta-beagleboard doesn't need any extra configuration. Regards, -- *dS Diego Sueiro Administrador do Embarcados www.embarcados.com.br <http://www.embarcados.com.br/?utm_source=assinatura_diego&utm_medium=e-mail&utm_campaign=Assinatura%20Email%20Diego> /*long live rock 'n roll*/ -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Poky/Yocto drivers for cellular modem
Take a look at meta-eca: http://git.yoctoproject.org/cgit/cgit.cgi/meta-eca/tree/ Regards, -- *dS Diego Sueiro sent from mobile. Em 19/09/2014 18:34, "Burton, Ross" escreveu: > On 18 September 2014 17:39, Simon Andrieu wrote: > > Using some Linux distribution, it exists drivers that help recognizing a > > cellular modem USB stick and to raise a corresponding network interface. > > > > Would you know please if such a generic cellular modem driver exists in > > Poky/Yocto distribution please? > > Would connman + ofono be suitable? > > Ross > -- > ___ > 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] yocto 1.6 - beaglebone black - cape manager
On Fri, Sep 12, 2014 at 6:59 PM, TakkTakk wrote:
> i build core-image-base
> My uEnv.txt content :
>
> kernel_file=uImage
> console=ttyO0,115200n8
> mmcroot=/dev/mmcblk0p2 rw
> mmcrootfstype=ext4 rootwait
>
> loaduimage=load mmc ${mmcdev}:${mmcpart} ${loadaddr} ${kernel_file}
> loadfdt=load mmc ${mmcdev}:${mmcpart} ${fdtaddr} /dtbs/${fdtfile}
>
> mmcargs=setenv bootargs console=${console} root=${mmcroot}
> rootfstype=${mmcrootfstype} ${optargs}
> uenvcmd=run loaduimage; run loadfdt; run mmcargs; bootz ${loadaddr} -
> ${fdtaddr}
>
I think that the problem is the "bootz" command. This command is used to
boot zImage kernel. Change it to "bootm" and don't forget to keep the S2
switch pressed.
But again. With a console serial cable is easier to find what is going
wrong.
>
> optargs=quiet drm.debug=7 capemgr.enable_partno=BB-UART4
> --
>
> files inside the FAT partition:
> uEnv.txt
> uImage
> u-boot.img
> MLO
> dtbs/am335x-boneblack.dtb
>
Regards,
--
*dS
Diego Sueiro
Administrador do Embarcados
www.embarcados.com.br
<http://www.embarcados.com.br/?utm_source=assinatura_diego&utm_medium=e-mail&utm_campaign=Assinatura%20Email%20Diego>
/*long live rock 'n roll*/
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] yocto 1.6 - beaglebone black - cape manager
On Thu, Sep 11, 2014 at 10:24 AM, TakkTakk wrote: > Yes I have ubuntu on eMMC, when i don't press S2 ubuntu will be boot. > When i press switch S2 yocto don't boot and LED USR0 , USR1, USR2, > USR3 stay lit steadily. > I boot yocto 1.6 (but without layer meta-beagleboard) on sdcard and > everything was ok. > Without the console serial cable (on UART0) is hard to guess what's going wrong. What is your o uEnv.txt content and the files inside the FAT partition? Regards, -- *dS Diego Sueiro Administrador do Embarcados www.embarcados.com.br <http://www.embarcados.com.br/?utm_source=assinatura_diego&utm_medium=e-mail&utm_campaign=Assinatura%20Email%20Diego> /*long live rock 'n roll*/ -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] yocto 1.6 - beaglebone black - cape manager
TakTak,
On Wed, Sep 10, 2014 at 1:39 PM, TakkTakk wrote:
> yocto buit with INSANE_SKIP_${PN} += "installed-vs-shipped" with no error.
> then i copied:
> cp MLO /media/boot/MLO
> cp u-boot-beaglebone.img /media/boot/u-boot.img
> sudo tar -xvf core-image-base-beaglebone.tar.gz -C /media/root/
>
> then, inserted microSD card to Beaglebone Black and bbb not boot. 4
> led lit steadily and nothing happens. I have cable hdmi connected to
> monitor.
>
> then i did
> $ cp uImage /media/boot
> $ mkdir /media/boot/dtbs
> $ cp uImage-am335x-boneblack.dtb /media/boot/dtbs/am335x-boneblack.dtb
>
> $ cp uEnv.txt /media/boot
>
> uEnv.txt from here
> http://www.embarcados.com.br/beaglebone-black-yocto/ but i changed
> zImage to uImage and still I can not boot the SD Card on the Beagle.
> All four LEDs stay lit steadily.
> What am i doing wrong?
>
Do you have another image installed on eMMC? If yes try to power up the
board with sdcard inserted and the switch S2 pressed (near sdcard slot).
Regards,
--
*dS
Diego Sueiro
Administrador do Embarcados
www.embarcados.com.br
<http://www.embarcados.com.br/?utm_source=assinatura_diego&utm_medium=e-mail&utm_campaign=Assinatura%20Email%20Diego>
/*long live rock 'n roll*/
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] yocto 1.6 - beaglebone black - cape manager
On Tue, Sep 9, 2014 at 12:53 PM, tomek82221 Gazeta.pl
wrote:
> ok, but where i can add INSANE_SKIP_${PN} += "installed-vs-shipped"
> in meta-beagleboard/common-bsp/recipes-kernel/linux/linux-mainline_3.8.bb
> ?
> or create
> meta-beagleboard/common-bsp/recipes-kernel/linux/linux-mainline_3.8.bbappend
> ?
>
> thanks for your help
>
Both will work.
Regards,
--
*dS
Diego Sueiro
Administrador do Embarcados
www.embarcados.com.br
<http://www.embarcados.com.br/?utm_source=assinatura_diego&utm_medium=e-mail&utm_campaign=Assinatura%20Email%20Diego>
/*long live rock 'n roll*/
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] yocto 1.6 - beaglebone black - cape manager
Hi Chris,
On Mon, Sep 8, 2014 at 2:28 PM, tomek82221 Gazeta.pl
wrote:
> Can I use kernel version 3.8, meta-beagleboard as BSP layer in Yocto 1.6 ?
>
Yes you can.
Here - https://www.yoctoproject.org/downloads/core/daisy16 is "Linux
> kernel 3.14 and 3.10 LTSI "
>
> I build yocto with
> BBLAYERS ?= " \
> /home/fil/Pulpit/yocto/poky/meta \
> /home/fil/Pulpit/yocto/poky/meta-yocto \
> /home/fil/Pulpit/yocto/poky/meta-beagleboard/common-bsp \
> /home/fil/Pulpit/yocto/poky/meta-openembedded/meta-oe \
> "
>
> have some errors:
>
> ERROR: QA Issue: linux-mainline: Files/directories were installed but
> not shipped
> /lib/firmware/sb16
> /lib/firmware/korg
> /lib/firmware/sb16/mulaw_main.csp
> /lib/firmware/sb16/alaw_main.csp
> /lib/firmware/sb16/ima_adpcm_init.csp
> /lib/firmware/sb16/ima_adpcm_capture.csp
> /lib/firmware/sb16/ima_adpcm_playback.csp
> /lib/firmware/korg/k1212.dsp
> ERROR: QA run found fatal errors. Please consider fixing them.
> ERROR: Function failed: do_package_qa
> ERROR: Logfile of failure stored in:
>
> /home/fil/Pulpit/yocto/poky/build/tmp/work/beaglebone-poky-linux-gnueabi/linux-mainline/3.8.13-r23a/temp/log.do_package.6509
> NOTE: recipe linux-mainline-3.8.13-r23a: task do_package: Failed
> ERROR: Task 88
> (/home/fil/Pulpit/yocto/poky/meta-beagleboard/common-bsp/recipes-kernel/linux/
> linux-mainline_3.8.bb,
> do_package) failed with exit code '1'
>
To solve this you can use a bbappend setting:
INSANE_SKIP_${PN} += "installed-vs-shipped"
Regards,
--
*dS
Diego Sueiro
Administrador do Embarcados
www.embarcados.com.br
<http://www.embarcados.com.br/?utm_source=assinatura_diego&utm_medium=e-mail&utm_campaign=Assinatura%20Email%20Diego>
/*long live rock 'n roll*/
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] systemd crashes above emergency runlevel
Ilya, On Sat, Sep 6, 2014 at 7:12 AM, Ilya Dmitrichenko wrote: > I am suspecting this could be simply something to do with the rootfs > being read-only when he tries to start, but I'll dig into it and see > what's up exactly. > Take a look at this layer to have a read only fs with systemd: https://github.com/MentorEmbedded/meta-ro-rootfs Regards, -- *dS Diego Sueiro Administrador do Embarcados www.embarcados.com.br <http://www.embarcados.com.br/?utm_source=assinatura_diego&utm_medium=e-mail&utm_campaign=Assinatura%20Email%20Diego> /*long live rock 'n roll*/ -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] systemd crashes above emergency runlevel
Ilya, On Fri, Sep 5, 2014 at 8:45 AM, Ilya Dmitrichenko wrote: > I have built an image form Beaglebone (white) with systemd instead of > sysvinit and it crashes after loading a few services. I'm suspecting > it's to do with getty taking over the console tty, but not quite sure. > > What I see that the serial port terminal (tried screen and > miniterm.py) gets disconnected and something occurs to the FTDI serial > port so OS X kernel doesn't see it again. > > I was able to boot with init=/bin/sh and set default.target to > emergency.target and from there calling `/sbin/init 1` started more > systemd units and then crashed the same way. > > Any ideas? > What systemd version you are using? I have two different problems with systemd (208 - did not tested on newer versions yet). 1 - The boot was reaching Emergency Mode giving me this kind of message: systemd-fsck[136]: Config: Superblock last mount time (Mon Jan 6 17:54:44 2014, systemd-fsck[136]: now = Wed Jan 1 07:14:39 2014) is in the future. systemd-fsck[136]: Config: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY. systemd-fsck[136]: (i.e., without -a or -p options) This was solved by having the /etc/e2fsck.conf file with this content: [options] broken_system_clock = true 2 - The other issue is related with journal log files rotation. It did not respect the restrictions configured at journal.conf. If you have consecutive power cycles (without issuing linux shutdown process) the "currupted" logs is not going to be rotated and it time it boots a new log file is created. After some time the memory is full and some process cannot start because of this. Can you send your boot log? Regards, -- *dS Diego Sueiro Administrador do Embarcados www.embarcados.com.br <http://www.embarcados.com.br/?utm_source=assinatura_diego&utm_medium=e-mail&utm_campaign=Assinatura%20Email%20Diego> /*long live rock 'n roll*/ -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] yocto 1.6 - beaglebone black - cape manager
Hi Gazeta, On Thu, Sep 4, 2014 at 5:48 PM, tomek82221 Gazeta.pl wrote: > Hi > I'm build yocto 1.6, My hardware is beaglebone black I successfull > build system image. But I can't see cape manager. > I need them to use SPI - enable spidev - > http://elinux.org/BeagleBone_Black_Enable_SPIDEV . > What do i do to build yocto with a cape manager? > As far as I know, you have to use meta-beagleboard <https://github.com/beagleboard/meta-beagleboard> (almost 1 year without any new commit) as your BSP layer to get capemanager support with Yocto. Take a look here <https://github.com/beagleboard/meta-beagleboard/blob/dylan/common-bsp/recipes-kernel/linux/linux-mainline_3.8.bb>. The kernel version is 3.8. Here we have good news of having capemanager support on mainline: http://beagleboard.org/blog/2014-08-27-device-tree-overlay-support-lands-upstream/ Here you have a beaglebord.org linux repo with capemanager support: https://github.com/beagleboard I don't know if there is any WIP to get this kernel compiled by Yocto/OE. Regards, -- *dS Diego Sueiro Administrador do Embarcados www.embarcados.com.br <http://www.embarcados.com.br/?utm_source=assinatura_diego&utm_medium=e-mail&utm_campaign=Assinatura%20Email%20Diego> /*long live rock 'n roll*/ -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Image that depends on another image
On Thu, Aug 28, 2014 at 4:27 AM, Khem Raj wrote: > On 14-08-27 06:43:09, Seth Bollinger wrote: > > On Thu, Aug 21, 2014 at 7:25 PM, Christopher Larson > > > wrote: > > > > > > > > On Thu, Aug 21, 2014 at 5:08 PM, Seth Bollinger > > > wrote: > > > > > >> Our device requires two images to be built. Is there any way to have > the > > >> first image depend on the second image? > > > > > > > > > do_rootfs[depends] += "some-other-image:do_rootfs" would probably do. > > > > > > > I hate to resurrect this thread, but after testing this out and using it > we > > ran into a small hiccup. Since we're using the second image to generate > a > > second partition, a lot of the dependencies actually need to be injected > > into the first image (users, utilities, etc.). Is there a way to do > this? > > First image is a normal image too, so keep adding to RDEPENDS or > IMAGE_INSTALL inside that image recipe, there could be rootfs port > processing functions to tweak the content even Or he can create a packagegroup in which can be used for both image recipes? Regards, -- *dS Diego Sueiro Administrador do Embarcados www.embarcados.com.br <http://www.embarcados.com.br/?utm_source=assinatura_diego&utm_medium=e-mail&utm_campaign=Assinatura%20Email%20Diego> /*long live rock 'n roll*/ -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Build dts alone
Anooj, On Wed, Aug 27, 2014 at 11:15 AM, Maciej Borzecki < maciej.borze...@open-rnd.pl> wrote: > On Wednesday 27 of August 2014 16:12:58 Anooj Gopi wrote: > > Thank you very much... devshell is really cool. > > > > It would be nice if we could mention this info some where in > > http://www.yoctoproject.org/docs/current/kernel-dev/kernel-dev.html > > It is mentioned in developer's manual: > > https://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#platdev-appdev-devshell The dtb compilation is performed on do_install task. So you can regenerate the dtb by issuing: "bitbake virtual/kernel -f -c install". Regards, -- *dS Diego Sueiro Administrador do Embarcados www.embarcados.com.br <http://www.embarcados.com.br/?utm_source=assinatura_diego&utm_medium=e-mail&utm_campaign=Assinatura%20Email%20Diego> /*long live rock 'n roll*/ -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] should systemd be considered harmful ?
Paul, On Fri, Aug 22, 2014 at 8:00 AM, Paul Eggleton < paul.eggle...@linux.intel.com> wrote: > Hi Alex, > > On Wednesday 20 August 2014 18:53:10 Alex Damian wrote: > > In release 216, systemd includes a caching nameserver, and full TTY > stream > > parsing. See details > > > > > http://lists.freedesktop.org/archives/systemd-devel/2014-August/022295.html > > > > I think the ever growing number of components in systemd will create > > conflicts with the normal tools, like libresolv, used in traditional UNIX > > systems. > > > > I think the number of components shipped with and required by systemd is > > pretty outside the scope for an init system. > > > > I would argue that the monolithic systemd is not in line with the UNIX > > philosophy of small tools that do one thing and do it well, and that it > is > > actually contra-productive to use it in embedded systems due to the large > > number of dependencies needed to get it to run, as well as the difficulty > > to debug when something goes amiss. > > > > Can I get your opinions in the respect that systemd is a useful tool to > > have in the Yocto Project ? > > One of the things that OpenEmbedded (and by extension, the Yocto Project) > emphasises is flexibility. We support three packaging backends for > example. It > has to be this way - the systems we are targeting vary greatly in size, > scope, > and application. The OS produced by our build system may not always > necessarily resemble a traditional Linux or even Unix system. > > As far as init goes, for some devices, you can get by with sysvinit. Others > can do with much less - e.g. a single sequential script for initialising > the > device and starting services. Others still need something more dynamic and > robust, and those are the things systemd is designed to handle better. We > need > to cater for all of these, so we have little choice but to support systemd > and > do so properly. That does mean that the build system has to understand what > functions systemd provides and where other software that might otherwise > provide that functionality is not needed and thus should not be installed > when > systemd is being used. > > I know a lot of people hold the view that systemd is rolling in too many > functions that are already handled elsewhere, and it has seemed that way > to me > at times. It may be worth taking a look over this blog post if you haven't > already though: > > http://0pointer.de/blog/projects/the-biggest-myths > Thanks for the link. It's really helpful. Regards, -- *dS Diego Sueiro Administrador do Embarcados www.embarcados.com.br <http://www.embarcados.com.br/?utm_source=assinatura_diego&utm_medium=e-mail&utm_campaign=Assinatura%20Email%20Diego> /*long live rock 'n roll*/ -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] should systemd be considered harmful ?
Alex, On Wed, Aug 20, 2014 at 2:53 PM, Alex Damian wrote: > Hello, > > In release 216, systemd includes a caching nameserver, and full TTY stream > parsing. See details > > http://lists.freedesktop.org/archives/systemd-devel/2014-August/022295.html > > I think the ever growing number of components in systemd will create > conflicts with the normal tools, like libresolv, used in traditional UNIX > systems. > > I think the number of components shipped with and required by systemd is > pretty outside the scope for an init system. > > I would argue that the monolithic systemd is not in line with the UNIX > philosophy of small tools that do one thing and do it well, and that it is > actually contra-productive to use it in embedded systems due to the large > number of dependencies needed to get it to run, as well as the difficulty > to debug when something goes amiss. > > Can I get your opinions in the respect that systemd is a useful tool to > have in the Yocto Project ? I like systemd for embedded systems. The boot process is faster then sysVinit and it's easy to create/manage services. It should me nice if we can install "systemd-ecosystem" with some granularity like we do with python, for example. But I don't know if it's possible or not. Regards, -- *dS Diego Sueiro Administrador do Embarcados www.embarcados.com.br <http://www.embarcados.com.br/?utm_source=assinatura_diego&utm_medium=e-mail&utm_campaign=Assinatura%20Email%20Diego> /*long live rock 'n roll*/ -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Boot Logo support
Paul, On Wed, Aug 20, 2014 at 3:48 AM, Mengeringhausen, Paul < paul.mengeringhau...@andron.de> wrote: > Hello! > > > > I have a custom board with imx233 Freescale Processor running linux from a > Yocto Denzil distribution. I want to display a custom bootlogo at system > boot, everything was fine until I disabled "framebuffer console support" in > the kernel options. > > I had to disable this because I don't need the console in my application, > I am writing directly to the framebuffer when my userspace application has > loaded and the blinking cursor of the console is bothering. Additionally > the console welcome message is overwriting the bootlogo, that's also not > nice. > > Is there an easy way to display the kernel bootlogo without having to > enable the console on my fb device? > > > > Thanks, > > Greetings, > > Paul > > If you are using sysVinit take a look at your /etc/inittab and comment the line of getty for tty1. You can use a bbappend to deploy your custom /etc/inittab file. Regards, -- *dS Diego Sueiro Administrador do Embarcados www.embarcados.com.br <http://www.embarcados.com.br/?utm_source=assinatura_diego&utm_medium=e-mail&utm_campaign=Assinatura%20Email%20Diego> /*long live rock 'n roll*/ -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [OE-core] Announcing meta-musl OE/Yocto layer supporting musl C library
Wow This is a really great job. Nice work. I'm gonna test it. Regards, -- *dS Diego Sueiro Administrador do Embarcados www.embarcados.com.br <http://www.embarcados.com.br/?utm_source=assinatura_diego&utm_medium=e-mail&utm_campaign=Assinatura%20Email%20Diego> /*long live rock 'n roll*/ On Sat, Aug 16, 2014 at 9:50 PM, Khem Raj wrote: > Hello All > > musl <http://www.musl-libc.org/> is a newer implementation licensed > under MIT licence > A layer to support musl to supply your system C library as an > alternative to uclibc and eglibc/glibc is now available at > > https://github.com/kraj/meta-musl > > README describes way to get going with it. > > Few things to note > > * Supports gcc 4.9 in OE not 4.8 > * Current musl recipe is 1.1.4 based > * You need latest master of OE-Core > (106305227003761c3fc562c21bb859a5256f2b36) or newer and > bitbake > * Its only able to build core-image-minimal > * core-image-minimal boots on qemuarm, qemuppc, qemumips, qemux86, > qemux86-64 > > I will send a request to add it to layerindex soon and then you should > be able to find it using > layerindex.opernembedded.org as well > > If you try it out on your hardware and/or have feedback I am > interested. Fork it from github, file bugs > send patches > > Happy hacking > > -Khem > -- > ___ > Openembedded-core mailing list > openembedded-c...@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] how many variations to build for a beaglebone black (BBB)?
Gary, On Mon, Jul 7, 2014 at 11:02 AM, Gary Thomas wrote: > The big thing missing from this version(*) is no cape support, > so if you need an LCD display or CAN driver or ..., you're not > going to find it. The meta-ti version does support those AFAIK > > (*) unless this changed in the last three weeks while I was on holiday :-) > meta-ti does not have support for cape manager. Just meta-beagleboard included it for kernel 3.8. Regards, -- *dS Diego Sueiro Administrador do Embarcados www.embarcados.com.br <http://www.embarcados.com.br/?utm_source=assinatura_diego&utm_medium=e-mail&utm_campaign=Assinatura%20Email%20Diego> /*long live rock 'n roll*/ -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Changing SysVinit default runlevel
Hi Robert, On Fri, Jul 4, 2014 at 7:21 AM, Robert Yang wrote: > On 07/04/2014 06:12 PM, Diego Sueiro wrote: > >> Folks, >> >> Despite of using ROOTFS_POSTPROCESS_COMMAND to change /etc/inittab, is >> there >> another method provided by build system to set the default runlevel. >> > > Yes, I think so, you can edit: > > meta/recipes-core/sysvinit/sysvinit-inittab/inittab > > Or maybe a better way is add sysvinit-inittab_2.88dsf.bbappend to your > local layer, and add another inittab to the layer, too. > > // Robert > > Thanks for the suggestion. I think this method (bbappend) is better than ROOTFS_POSTPROCESS_COMMAND. Regards, -- *dS Diego Sueiro Administrador do Embarcados www.embarcados.com.br <http://www.embarcados.com.br/?utm_source=assinatura_diego&utm_medium=e-mail&utm_campaign=Assinatura%20Email%20Diego> /*long live rock 'n roll*/ -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Changing SysVinit default runlevel
Folks, Despite of using ROOTFS_POSTPROCESS_COMMAND to change /etc/inittab, is there another method provided by build system to set the default runlevel. Regards, -- *dS Diego Sueiro Administrador do Embarcados www.embarcados.com.br <http://www.embarcados.com.br/?utm_source=assinatura_diego&utm_medium=e-mail&utm_campaign=Assinatura%20Email%20Diego> /*long live rock 'n roll*/ -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Encrypted root filesystem
Folks, I did some search on Google but I could'n found any instructions on how to achieve this with YP/OE build system. How can I get a rootfs encrypted with YP? The image will be installed in a NAND memory. If some could point some directions it will help me a lot. Regards, -- *dS Diego Sueiro Administrador do Embarcados www.embarcados.com.br <http://www.embarcados.com.br/?utm_source=assinatura_diego&utm_medium=e-mail&utm_campaign=Assinatura%20Email%20Diego> /*long live rock 'n roll*/ -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Python3-distribute-native build fails in daisy
Andreas, On Sun, Jun 8, 2014 at 3:05 AM, Andreas Galauner wrote: > Hi all, > > I'm currently trying to add a few python packages to my image for which > I need Python 3.3 because a few of them depend on asyncio. These > packages (asyncio itself, websockets and django) are installed with the > usual distribute setup.py scripts either using setuptools or distribute. > > Now when trying to build python3-distribute-native as a build dependency > for any of these packages, bitbake fails with the following message: > > > snip < > > | copying DEVGUIDE.txt -> build/src > > | copying CHANGES.txt -> build/src > > | copying README.txt -> build/src > > | copying MANIFEST.in -> build/src > > | copying launcher.c -> build/src > > | Traceback (most recent call last): > > | File "setup.py", line 34, in > > | util.run_2to3(outfiles_2to3) > > | File > "/media/andy/Data/Zedboard/openembedded/build_poky/tmp-eglibc/sysroots/x86_64-linux/usr/lib/python3.3/distutils/util.py", > line 507, in run_2to3 > > | from lib2to3.refactor import RefactoringTool, > get_fixers_from_package > > | File > "/media/andy/Data/Zedboard/openembedded/build_poky/tmp-eglibc/sysroots/x86_64-linux/usr/lib/python3.3/lib2to3/refactor.py", > line 19, in > > | import logging > > | File > "/media/andy/Data/Zedboard/openembedded/build_poky/tmp-eglibc/sysroots/x86_64-linux/usr/lib/python3.3/logging/__init__.py", > line 26, in > > | import sys, os, time, io, traceback, warnings, weakref > > | ImportError: No module named 'time' > > | ERROR: python3 setup.py build_ext execution failed. > > | WARNING: > /media/andy/Data/Zedboard/openembedded/build_poky/tmp-eglibc/work/x86_64-linux/python3-distribute-native/0.6.32-ml5/temp/run.do_compile.1363:1 > exit 1 from > > | exit 1 > > | ERROR: Function failed: do_compile (log file is located at > /media/andy/Data/Zedboard/openembedded/build_poky/tmp-eglibc/work/x86_64-linux/python3-distribute-native/0.6.32-ml5/temp/log.do_compile.1363) > > snip < > (Note: even if the path says openembedded, it's yocto) > > When using the devshell to launch python3 and trying to import time, it > fails in the same way. > I'm using an up-to-date checkout of the daisy branch. > > Any ideas what the cause for this could be and how to solve this? > > - Andy > I'm getting the same problem for python3-distribute. Take a look bug #6373 <https://bugzilla.yoctoproject.org/show_bug.cgi?id=6373>. Try to do a "bitbake python3-native -fccompile ; bitbake python3-native -f" and see if you can go further than me. Regards, -- *dS Diego Sueiro Administrador do Embarcados www.embarcados.com.br <http://www.embarcados.com.br/?utm_source=assinatura_diego&utm_medium=e-mail&utm_campaign=Assinatura%20Email%20Diego> /*long live rock 'n roll*/ -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Setting default system python version
Jegan, On Mon, May 26, 2014 at 3:06 AM, Jegan Chandru wrote: > There is variable called PREFERRED_VERSION_pkgname ?= "version" where you > can set the desired version of any packages available.(if thats what you > are looking for) Try adding it in your image recipe or conf file. Also once > added, you can check by executing 'bitbake -s' and see preferred version > tab. Actually I don't think that it's going to work for python3, since python(2.7) and python3 are separate recipes that does not provide the same package (python). They provide two different packages: python and python3, respectively. And I believe that PREFERRED_VERSION just have effects on local.conf, machine.conf and distro.conf, not on image recipes. Maybe using update-alternatives class can help me to achieve this: http://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#ref-classes-update-alternatives<http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/update-alternatives.bbclass> Regards, -- *dS Diego Sueiro Administrador do Embarcados www.embarcados.com.br<http://www.embarcados.com.br/?utm_source=assinatura_diego&utm_medium=e-mail&utm_campaign=Assinatura%20Email%20Diego> /*long live rock 'n roll*/ -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Setting default system python version
Now python3-distutils returns the following on do_compile: Log data follows: | DEBUG: Executing shell function do_compile | Traceback (most recent call last): | File "setup.py", line 45, in | exec(init_file.read(), d) | File "", line 8, in | File "//tmp/work/cortexa7hf-vfp-vfpv4-neon-poky-linux-gnueabi/python3-distribute/0.6.32-ml5/distribute-0.6.32/build/src/setuptools/__init__.py", line 2, in | from setuptools.extension import Extension, Library | File "//tmp/work/cortexa7hf-vfp-vfpv4-neon-poky-linux-gnueabi/python3-distribute/0.6.32-ml5/distribute-0.6.32/build/src/setuptools/extension.py", line 5, in | from setuptools.dist import _get_unpatched | File "//tmp/work/cortexa7hf-vfp-vfpv4-neon-poky-linux-gnueabi/python3-distribute/0.6.32-ml5/distribute-0.6.32/build/src/setuptools/dist.py", line 103 | except ValueError, e: | ^ | SyntaxError: invalid syntax | ERROR: python3 setup.py build_ext execution failed. | WARNING: exit code 1 from a shell command. Change the python3-distutils recipe to "inherit distutils" instead "inherit distutils3" did the trick. But now my python3-mypackage, in which inherits setuptools3 is getting the following error: | DEBUG: Executing shell function do_compile | Traceback (most recent call last): | File "setup.py", line 6, in | from setuptools import setup, find_packages | ImportError: No module named 'setuptools' | ERROR: python3 setup.py build_ext execution failed. | WARNING: exit code 1 from a shell command. It seems that setuptools is not installer on native. Abraços, -- *dS Diego Sueiro Administrador do Embarcados www.embarcados.com.br<http://www.embarcados.com.br/?utm_source=assinatura_diego&utm_medium=e-mail&utm_campaign=Assinatura%20Email%20Diego> /*long live rock 'n roll*/ On Fri, May 23, 2014 at 11:45 AM, Diego Sueiro wrote: > Folks, > > I'm having issues on python3-distribute compile (daisy branch): > > Traceback (most recent call last): > | File "setup.py", line 34, in > | util.run_2to3(outfiles_2to3) > | File > "//tmp/sysroots/x86_64-linux/usr/lib/python3.3/distutils/util.py", > line 507, in run_2to3 > | from lib2to3.refactor import RefactoringTool, get_fixers_from_package > | File > "/tmp/sysroots/x86_64-linux/usr/lib/python3.3/lib2to3/refactor.py", > line 19, in > | import logging > | File > "//tmp/sysroots/x86_64-linux/usr/lib/python3.3/logging/__init__.py", > line 26, in > | import sys, os, time, io, traceback, warnings, weakref > | ImportError: No module named 'time' > | ERROR: python3 setup.py build_ext execution failed. > | WARNING: exit code 1 from a shell command. > > Any thoughts? > > > > Abraços, > > -- > *dS > Diego Sueiro > > Administrador do Embarcados > www.embarcados.com.br<http://www.embarcados.com.br/?utm_source=assinatura_diego&utm_medium=e-mail&utm_campaign=Assinatura%20Email%20Diego> > > /*long live rock 'n roll*/ > > > On Fri, May 23, 2014 at 11:29 AM, Diego Sueiro wrote: > >> Folks, >> >> I did not fount it on manuals. >> How can I set the default system python version for an image? >> >> >> Regards, >> >> -- >> *dS >> Diego Sueiro >> >> Administrador do Embarcados >> www.embarcados.com.br<http://www.embarcados.com.br/?utm_source=assinatura_diego&utm_medium=e-mail&utm_campaign=Assinatura%20Email%20Diego> >> >> /*long live rock 'n roll*/ >> > > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Setting default system python version
Folks, I'm having issues on python3-distribute compile (daisy branch): Traceback (most recent call last): | File "setup.py", line 34, in | util.run_2to3(outfiles_2to3) | File "//tmp/sysroots/x86_64-linux/usr/lib/python3.3/distutils/util.py", line 507, in run_2to3 | from lib2to3.refactor import RefactoringTool, get_fixers_from_package | File "/tmp/sysroots/x86_64-linux/usr/lib/python3.3/lib2to3/refactor.py", line 19, in | import logging | File "//tmp/sysroots/x86_64-linux/usr/lib/python3.3/logging/__init__.py", line 26, in | import sys, os, time, io, traceback, warnings, weakref | ImportError: No module named 'time' | ERROR: python3 setup.py build_ext execution failed. | WARNING: exit code 1 from a shell command. Any thoughts? Abraços, -- *dS Diego Sueiro Administrador do Embarcados www.embarcados.com.br<http://www.embarcados.com.br/?utm_source=assinatura_diego&utm_medium=e-mail&utm_campaign=Assinatura%20Email%20Diego> /*long live rock 'n roll*/ On Fri, May 23, 2014 at 11:29 AM, Diego Sueiro wrote: > Folks, > > I did not fount it on manuals. > How can I set the default system python version for an image? > > > Regards, > > -- > *dS > Diego Sueiro > > Administrador do Embarcados > www.embarcados.com.br<http://www.embarcados.com.br/?utm_source=assinatura_diego&utm_medium=e-mail&utm_campaign=Assinatura%20Email%20Diego> > > /*long live rock 'n roll*/ > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Setting default system python version
Folks, I did not fount it on manuals. How can I set the default system python version for an image? Regards, -- *dS Diego Sueiro Administrador do Embarcados www.embarcados.com.br<http://www.embarcados.com.br/?utm_source=assinatura_diego&utm_medium=e-mail&utm_campaign=Assinatura%20Email%20Diego> /*long live rock 'n roll*/ -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] QT5 for gernericX86
Bastian, On Thu, May 22, 2014 at 12:32 PM, Bastian Weißbach wrote: > Hey Guys, > > I'm trying to build a Linux for a generic X86 system with QT5. > > I've tried to go the simple way. I cloned the nessesary layers (meta-intel > and meta-qt5). Then I selected "intel-corei7-64" as MACHINE and > added cinematicexperience to my image. Then I build core-image-minimal. > > But when I try to start Qt5_CinematicExperience (on the target) it failed > because of the missing xcb plugin. > > Is there anything I missed? > > Thanks for your help! > If you want to use qt5 with X11 you need to add DISTRO_FEATURES_append onto your local.conf But if tou want to use opengl or famebuffer take a look at PACKAGECONFIG options on: meta-qt5/recipes-qt/qt5/qtbase.inc I would recommend you to you core-image-x11 or core-image-base. Regards, -- *dS Diego Sueiro Administrador do Embarcados www.embarcados.com.br<http://www.embarcados.com.br/?utm_source=assinatura_diego&utm_medium=e-mail&utm_campaign=Assinatura%20Email%20Diego> /*long live rock 'n roll*/ -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Help with building app recipe
Folks, I'm trying to accomplish this in a 64bits host machine. But I'm getting errors the following error on compile task: | In file included from //tmp/sysroots/x86_64-linux/usr/include/python3.3m/Python.h:50:0, | from ../../git/src/qpython_priv.h:22, | from moc_qpython_priv.cpp:9: | //sysroots/x86_64-linux/usr/include/python3.3m/pyport.h:820:2: error: #error "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)." | #error "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)." | ^ Searching on Google it says that this is a known bug when trying to cross-compile Python stuff for 32bits machines on 64bits hosts. It seems that the guys from Buildroot could get this solved: http://lists.busybox.net/pipermail/buildroot/2011-August/045257.html I'm trying to find the "magical" patch to how to get this fixed. Also found this link too: http://blog.devork.be/2009/02/compiling-32-bit-python-on-amd64.html But I'm not quite sure how to get this fixed on Yocto. Should it need to be fixed on the pyotherside, or python3, or python3-native recipe? Any directions are appreciated. Regards, -- *dS Diego Sueiro Administrador do Embarcados www.embarcados.com.br<http://www.embarcados.com.br/?utm_source=assinatura_diego&utm_medium=e-mail&utm_campaign=Assinatura%20Email%20Diego> /*long live rock 'n roll*/ On Sat, May 17, 2014 at 2:18 AM, Khem Raj wrote: > On Fri, May 16, 2014 at 5:33 AM, Neuer User wrote: > > If I change the sed line to "#!/usr/bin/env python3", that would > > probably work then. But would it break something else? > > would be fine. > -- > ___ > 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] RPM to Verify Installed Packages
Mark, On Mon, May 12, 2014 at 12:37 PM, Mark Hatle wrote: > On 5/9/14, 12:14 PM, Mark Hatle wrote: > >> On 5/7/14, 7:46 AM, Diego Sueiro wrote: >> >>> Folks, >>> >> >> I'm looking at this issue. I'd suggest you open a bug in the Yocto >> Project >> bugzilla. Feel free to assign it to me. (I'll end up with it anyway...) >> > > I opened a bug, 6309. I've sent a fix for master, and we can work it back > into previous versions once approved by oe-core. Thanks for your effort. Regards, -- *dS Diego Sueiro Administrador do Embarcados www.embarcados.com.br<http://www.embarcados.com.br/?utm_source=assinatura_diego&utm_medium=e-mail&utm_campaign=Assinatura%20Email%20Diego> /*long live rock 'n roll*/ -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] RPM to Verify Installed Packages
Folks, After 1 day of debugging I found what was causing the issue. Commenting out the to lines (590-591) below on lib/verify.c (showVerifyPackage function) solved the issue: /* If not verifying %ghost, skip ghost files. */ /* XXX the broken!!! logic disables %ghost queries always. */ if (!(FF_ISSET(qva->qva_fflags, GHOST) && FF_ISSET(fflags, GHOST))) continue; I've tested "rpm -V" on qemuarm and qemux86 and it's reporting errors for missing files and MD5 error at least. I really don't know what is the side effect of this change and any help on trying to understand what's going on with this bug is very welcome. Regards, -- *dS Diego Sueiro Administrador do Embarcados www.embarcados.com.br<http://www.embarcados.com.br/?utm_source=assinatura_diego&utm_medium=e-mail&utm_campaign=Assinatura%20Email%20Diego> /*long live rock 'n roll*/ On Wed, May 7, 2014 at 9:46 AM, Diego Sueiro wrote: > Folks, > > On Tue, May 6, 2014 at 3:48 PM, Diego Sueiro wrote: > >> On Tue, May 6, 2014 at 3:39 PM, Khem Raj wrote: >> >>> On Tue, May 6, 2014 at 11:34 AM, Diego Sueiro >>> wrote: >>> > >>> > It's hard to say. But when I try to execute it I receive: "cannot >>> execute >>> > binary file". >>> > And the output of "file" command is: "data". >>> > >>> > My bet is that the system was powered down during the update process. >>> >>> what happens if you reinstall it ? >> >> >> It works. >> But the problem is that --verify option is not working. >> Even if I remove a file from the installed package it did not point for a >> missing file. >> > > Any thoughts? > > > > Regards, > > -- > *dS > Diego Sueiro > > Administrador do Embarcados > www.embarcados.com.br<http://www.embarcados.com.br/?utm_source=assinatura_diego&utm_medium=e-mail&utm_campaign=Assinatura%20Email%20Diego> > > /*long live rock 'n roll*/ > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] couple simple questions on building for intel galileo
Robert, Here is some instructions with some workarounds: http://www.malinov.com/Home/sergey-s-blog/intelgalileo-buildinglinuximage And I think that you already saw meta-intel-iot-devkit: http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel-iot-devkit/ As soon as I get my Galileo I'll try to put Yocto on it. Please, share your results with us. Regards, -- *dS Diego Sueiro Administrador do Embarcados www.embarcados.com.br<http://www.embarcados.com.br/?utm_source=assinatura_diego&utm_medium=e-mail&utm_campaign=Assinatura%20Email%20Diego> /*long live rock 'n roll*/ On Thu, May 8, 2014 at 4:21 AM, Robert P. J. Day wrote: > > just got an intel galileo board, and want to whip together a > yocto-built image for it on my fedora rawhide system. before even > starting, a quick google showed me that people seemed to be having > trouble: > > https://communities.intel.com/thread/51115 > > where are the canonical instructions for building a basic image for > the galileo with yocto? i found this: > > http://wiki.ros.org/IntelGalileo/HydroGalileoInitialInstall > > but i'd like to make sure i'm using the most current instructions to > avoid problems. thanks. > > 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 mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] RPM to Verify Installed Packages
Folks, On Tue, May 6, 2014 at 3:48 PM, Diego Sueiro wrote: > On Tue, May 6, 2014 at 3:39 PM, Khem Raj wrote: > >> On Tue, May 6, 2014 at 11:34 AM, Diego Sueiro >> wrote: >> > >> > It's hard to say. But when I try to execute it I receive: "cannot >> execute >> > binary file". >> > And the output of "file" command is: "data". >> > >> > My bet is that the system was powered down during the update process. >> >> what happens if you reinstall it ? > > > It works. > But the problem is that --verify option is not working. > Even if I remove a file from the installed package it did not point for a > missing file. > Any thoughts? Regards, -- *dS Diego Sueiro Administrador do Embarcados www.embarcados.com.br<http://www.embarcados.com.br/?utm_source=assinatura_diego&utm_medium=e-mail&utm_campaign=Assinatura%20Email%20Diego> /*long live rock 'n roll*/ -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] RPM to Verify Installed Packages
On Tue, May 6, 2014 at 3:39 PM, Khem Raj wrote: > On Tue, May 6, 2014 at 11:34 AM, Diego Sueiro > wrote: > > > > It's hard to say. But when I try to execute it I receive: "cannot execute > > binary file". > > And the output of "file" command is: "data". > > > > My bet is that the system was powered down during the update process. > > what happens if you reinstall it ? It works. But the problem is that --verify option is not working. Even if I remove a file from the installed package it did not point for a missing file. Regards, -- *dS Diego Sueiro Administrador do Embarcados www.embarcados.com.br<http://www.embarcados.com.br/?utm_source=assinatura_diego&utm_medium=e-mail&utm_campaign=Assinatura%20Email%20Diego> /*long live rock 'n roll*/ -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] RPM to Verify Installed Packages
Hi Khem, On Tue, May 6, 2014 at 3:29 PM, Khem Raj wrote: > what kind of corruption ? It's hard to say. But when I try to execute it I receive: "cannot execute binary file". And the output of "file" command is: "data". My bet is that the system was powered down during the update process. Regards, -- *dS Diego Sueiro Administrador do Embarcados www.embarcados.com.br<http://www.embarcados.com.br/?utm_source=assinatura_diego&utm_medium=e-mail&utm_campaign=Assinatura%20Email%20Diego> /*long live rock 'n roll*/ -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] RPM to Verify Installed Packages
Folks, I'm using Yocto on dora branch. We got a binary corrupted after a package update using rpm. But "rpm -V" [1][2] command doesn't show any errors. Is there any limitation for rpm (5.4.9) built from Yocto? The rpm database is not corrupted. I took a look on rpm recipe and didn't found anything related to a specific PACKAGECONFIG. Any help is welcome. [1] - http://www.rpm.org/max-rpm/ch-rpm-verify.html [2] - http://www.rpm.org/max-rpm/s1-rpm-verify-output.html Regards, -- *dS Diego Sueiro Administrador do Embarcados www.embarcados.com.br<http://www.embarcados.com.br/?utm_source=assinatura_diego&utm_medium=e-mail&utm_campaign=Assinatura%20Email%20Diego> /*long live rock 'n roll*/ -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Beaglebone Black with core-image-weston
Folks, I'm trying to get wayland support on BBB with yocto daisy, but weston is not starting up. Here is the output: Date: 2014-04-30 UTC [15:39:30.029] weston 1.4.0 http://wayland.freedesktop.org/ Bug reports to: https://bugs.freedesktop.org/enter_bug.cgi?product=Wayland&component=weston&version=1.4.0 Build: 1.4.0-dirty configure.ac: Bump version to 1.4.0 (2014-01-23 20:51:40 -0800) [15:39:30.030] OS: Linux, 3.14.0-yocto-standard, #1 PREEMPT Tue Apr 29 17:00:14 BRT 2014, armv7l [15:39:30.031] Starting with no config file. [15:39:30.032] Loading module '/usr/lib/weston/drm-backend.so' [15:39:30.048] initializing drm backend [15:39:30.053] using /dev/dri/card0 [15:39:30.054] Loading module '/usr/lib/weston/gl-renderer.so' gbm: malformed or no PCI IDfailed to load module: /usr/lib/gbm/gbm_gallium_drm.so: cannot open shared object file: No such file or directory [15:39:30.074] failed to initialize egl [15:39:30.105] fatal: failed to create compositor Looking at the yocto manual [1] it says that wayland is only supported on Mesa 3D and DRI targets. I've already tried to add PACKAGECONFIG_pn-mesa="gallium-gbm" but it complains that "Nothing RPROVIDES 'libgles2". Should I have to build libgles-opma3 to get it supported? Before trying this I would like to have some clarification about wayland support on BBB. Is it possible? If not, why am I able to build an unsupported image for it? [1] - http://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#wayland Regards, -- *dS Diego Sueiro Administrador do Embarcados www.embarcados.com.br<http://www.embarcados.com.br/?utm_source=assinatura_diego&utm_medium=e-mail&utm_campaign=Assinatura%20Email%20Diego> /*long live rock 'n roll*/ -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Missing kernel, modules and dtb for beaglebone on core-image-minimal
Stefan, On Tue, Apr 29, 2014 at 11:32 AM, Stefan Stanacar wrote: > That's not a bug :), it's intended. The README.hardware clearly states > that for deploying a core-image-minimal you need to unpack the modules and > copy the dtbs over. > > http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/README.hardware#n244 > > There is a reason for that, mainly beacause the way core-image-minimal > recipe works. > A BSP usually adds kernel-modules and other stuff to > MACHINE_EXTRA_RDEPENDS but not all images respect that (they need to > inherit core-image.bbclass and not overwrite IMAGE_INSTALL). Thanks. Got it. Why I never RTFM or at least the README file? Regards, -- *dS Diego Sueiro Administrador do Embarcados www.embarcados.com.br<http://www.embarcados.com.br/?utm_source=assinatura_diego&utm_medium=e-mail&utm_campaign=Assinatura%20Email%20Diego> /*long live rock 'n roll*/ -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Missing kernel, modules and dtb for beaglebone on core-image-minimal
Folks, I'm using daisy branch of yocto and I realized that kernel and dtb files were not present on /boot and there were no modules installed on /lib/modules/3.14.0-yocto-standard. Regards, -- *dS Diego Sueiro Administrador do Embarcados www.embarcados.com.br<http://www.embarcados.com.br/?utm_source=assinatura_diego&utm_medium=e-mail&utm_campaign=Assinatura%20Email%20Diego> /*long live rock 'n roll*/ -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] CGL compliance layer initiative
Vali, I'm excited to see CGL support for Yocto. I'm going to test this layer as soon as possible. One question, which branch of Yocto is it based on? Regards, -- *dS Diego Sueiro sent from mobile. On Apr 9, 2014 11:05 AM, "Vali Cobelea" wrote: > OK Paul, that indeed makes sense, I really did not knew that preliminary > versions of layers are accepted. > I will discuss around here and if everything goes OK we will start the > move in the "public" layer index. > I also do agree with an all-together strategy, no matter for the layer > state. > > > Much appreciated, > Vali > > > On 04/09/2014 02:01 PM, Paul Eggleton wrote: > >> On Wednesday 09 April 2014 13:55:47 Vali Cobelea wrote: >> >>> On 04/09/2014 01:51 PM, Paul Eggleton wrote: >>> >>>> On Tuesday 08 April 2014 18:34:08 Vali Cobelea wrote: >>>> >>>>> Here at ENEA we decided to take the initiative regarding the CGL >>>>> compliance when it comes to the Yocto Project. >>>>> For this we started the work on a dedicated layer called 'meta-cgl' >>>>> >>>>> which can be accessed / cloned from here: >>>>> http://git.enea.com/git/?p=linux/meta-cgl.git >>>>> git clone g...@git.enea.com:linux/meta-cgl >>>>> >>>>> Have a look of the things we got there so far, please remember that >>>>> there is still plenty of work to be done (layer architecture, CGL >>>>> requirements coverage mode and so on). >>>>> It is a little bit more than a stub layer, consider it a starting point >>>>> for the direction we would like to have with this layer. >>>>> >>>>> Any input is much appreciated, lets keep the discussion by this email >>>>> thread and see where it goes. >>>>> >>>> I don't have anything to offer on the layer contents, but I would say in >>>> order to make it easy for people to find this layer I would strongly >>>> encourage you to> >>>> submit it to the OpenEmbedded layer index: >>>> http://layers.openembedded.org/layerindex/submit/ >>>> >>> Thank you for the input. >>> We will keep the layer for a short period of time at the current >>> location while getting other ideas regarding the content / architecture. >>> The layer initiative will also be raised up in the board advisory >>> meeting, in order to get even more input. >>> After which we will make it easier to find, access and use for anyone, >>> exactly as you suggested. >>> >> OK, as the maintainer it's totally up to you. >> >> I would say though generally that I'd like to see more people adding their >> work-in-progress layers to the layer index, even if at some time later >> they >> will be moved elsewhere or absorbed into another layer - it just makes it >> easier to point people to the layer index so they can find recipes that >> have >> already been written, rather than having to re-write them from scratch. >> >> Cheers, >> Paul >> >> > -- > ___ > 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] Get rid of opkg install error
Paul, On Wed, Mar 26, 2014 at 8:54 AM, Paul Barker wrote: > On 26 March 2014 11:29, Diego Sueiro wrote: > > > > On Wed, Mar 26, 2014 at 8:16 AM, Paul Barker > wrote: > >> > >> On 26 March 2014 09:47, Diego Sueiro wrote: > >> > Folks, > >> > > >> > I have a image recipe which installs some custom files on rootfs. > >> > Instead of having a bbappend for each package that provides those > files > >> > I > >> > want to concentrate it on image recipe. > >> > >> Why do you want to merge all your custom files into one recipe? With > >> them separated into the packages they affect you can add/remove > >> packages a lot easier in the future. > > > > > > Because I want to have different image recipes for different proposes. > > For example: One image with eth0 on dhcp and another one with static ip. > Or > > some different images for product variations. > > > > Ok, I understand you now. I need to work out a way of handling this > for future systems I'll be working on but it's not something I've > needed to do so far. > > I would probably lean in the direction of using bbappends and > generating all config packages during a build (because a package of > custom config files shouldn't have a long build time). So you'd have > init-ifupdown-image1config, init-ifupdown-image2config, etc. Then in > each image recipe I'd select which package is installed. > > That does leave it spread between bbappend files as it's grouped by > functionality rather than by target image. I'm not sure how to > efficiently group it the other way around. > Thanks for the suggestion. > > >> > >> > >> > > >> > The problem is that I'm receiving the following error: > >> > > >> > "But that file is already provided by package" > >> > > >> > > >> > Is there a way to get rid of this error? > >> > >> The only thing I can think of is to use bbappends to prevent the > >> original files from installing but not to add the replacement files. > >> Then have a single recipe which packages all the replacement files. > >> That way only one package provides each file. > > > > > > This is a possible solution. But if I build an image without these custom > > files (core-image-minimal for example) the original ones will not be > > shipped. Am I correct? > > Or maybe I can check for a custom variable defined at local.conf and > check > > for it on bbappend to know if I have to remove or not the original files. > > > > Yes, that would be the issue there. Not sure how well a local.conf > check would work. Well, I'll git it a try. Regards, -- *dS Diego Sueiro Administrador do Embarcados www.embarcados.com.br<http://www.embarcados.com.br/?utm_source=assinatura_diego&utm_medium=e-mail&utm_campaign=Assinatura%20Email%20Diego> /*long live rock 'n roll*/ -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Get rid of opkg install error
On Wed, Mar 26, 2014 at 8:16 AM, Paul Barker wrote: > On 26 March 2014 09:47, Diego Sueiro wrote: > > Folks, > > > > I have a image recipe which installs some custom files on rootfs. > > Instead of having a bbappend for each package that provides those files I > > want to concentrate it on image recipe. > > Why do you want to merge all your custom files into one recipe? With > them separated into the packages they affect you can add/remove > packages a lot easier in the future. > Because I want to have different image recipes for different proposes. For example: One image with eth0 on dhcp and another one with static ip. Or some different images for product variations. > > > > > The problem is that I'm receiving the following error: > > > > "But that file is already provided by package" > > > > > > Is there a way to get rid of this error? > > The only thing I can think of is to use bbappends to prevent the > original files from installing but not to add the replacement files. > Then have a single recipe which packages all the replacement files. > That way only one package provides each file. This is a possible solution. But if I build an image without these custom files (core-image-minimal for example) the original ones will not be shipped. Am I correct? Or maybe I can check for a custom variable defined at local.conf and check for it on bbappend to know if I have to remove or not the original files. Regards, -- *dS Diego Sueiro Administrador do Embarcados www.embarcados.com.br<http://www.embarcados.com.br/?utm_source=assinatura_diego&utm_medium=e-mail&utm_campaign=Assinatura%20Email%20Diego> /*long live rock 'n roll*/ -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Get rid of opkg install error
Folks, I have a image recipe which installs some custom files on rootfs. Instead of having a bbappend for each package that provides those files I want to concentrate it on image recipe. The problem is that I'm receiving the following error: "But that file is already provided by package" Is there a way to get rid of this error? Regards, -- *dS Diego Sueiro Administrador do Embarcados www.embarcados.com.br<http://www.embarcados.com.br/?utm_source=assinatura_diego&utm_medium=e-mail&utm_campaign=Assinatura%20Email%20Diego> /*long live rock 'n roll*/ -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Remote management of embedded devices
Hi Mark, On Fri, Mar 7, 2014 at 2:42 PM, Mark O'Donovan wrote: > > We're experimenting with software called yalertunnel (yaler.net). Is it open-source? Is there any cost to use it? Regards, -- *dS Diego Sueiro Administrador do Embarcados www.embarcados.com.br /*long live rock 'n roll*/ ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Python package recipe
Hi Paul,
On Tue, Feb 4, 2014 at 10:52 AM, Paul Barker wrote:
> This looks like the best you're going to get without fixing the
> upstream source. Just looked at
>
> https://github.com/adafruit/adafruit-beaglebone-io-python/blob/master/overlays/builder.py
> ,
> it contains hard-coded install paths. You could report a bug or submit
> a patch to make these respect the install prefix.
>
I'll take a look on this.
>
> >>
> >> FILES_${PN} = " ${nonarch_base_libdir}/firmware/* \
> >> ${exec_prefix} \
>
> What files do you need under ${exec_prefix}? Do you definitely want
> all this in one package and not separate packages for the firmware and
> such?
>
As soon as the python module needs the dtbos it must be installed together.
Now it looks like this:
FILES_${PN} += " ${nonarch_base_libdir}/firmware/* "
> A lot of recipes have to customise the install function and add extra
> directories to FILES_*, don't worry about that.
>
Thanks for your attention.
Regards,
--
*dS
Diego Sueiro
Administrador do Embarcados
www.embarcados.com.br
/*long live rock 'n roll*/H
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Python package recipe
Folks,
Any suggestions?
Regards,
--
*dS
Diego Sueiro
Administrador do Embarcados
www.embarcados.com.br
/*long live rock 'n roll*/
On Thu, Jan 30, 2014 at 2:30 PM, Diego Sueiro wrote:
> Folks,
>
> I'm trying to create a recipe for Adafruit's BeagleBone IO Python Library:
> https://github.com/adafruit/adafruit-beaglebone-io-python
>
> The problem is that this python package generates some dtbos and install
> them on /lib/firmware but these files were not presented on generated
> package.
>
> Here is my python-pybbio.bb:
>
> DESCRIPTION = "Adafruit's BeagleBone IO Python Library"
> SECTION = "devel/python"
> LICENSE = "MIT"
> LIC_FILES_CHKSUM = "file://README.rst;md5=6c89ebda10e2f2efefe5e681a9a0c1f1"
> SRCNAME = "pybbio"
>
>
> COMPATIBLE_MACHINE = "(beaglebone)"
>
> SRC_URI = "git://
> github.com/adafruit/adafruit-beaglebone-io-python;branch=master"
> SRCREV_pn-${PN} = "ff6f11abe7864e8db735b359365a85323bff2a06"
>
> S = "${WORKDIR}/git"
>
> inherit setuptools
>
> PACKAGE_ARCH = "${MACHINE_ARCH}"
>
>
> To get dtbos and all python files on the package I need to add these lines
> in my recipe:
>
> do_install_append() {
> install -d ${D}/${nonarch_base_libdir}/firmware
> install -m 0644 ${S}/overlays/*dt*
> ${D}${nonarch_base_libdir}/firmware/
> }
>
> FILES_${PN} = " ${nonarch_base_libdir}/firmware/* \
> ${exec_prefix} \
>
>
> It seems not good to me and I thought that there is a better solution.
> Should I have to inherit another class to achieve this?
>
> Note: I can easly install this on target using pip install
>
>
> Regards,
>
> --
> *dS
> Diego Sueiro
>
> Administrador do Embarcados
> www.embarcados.com.br
>
> /*long live rock 'n roll*/
>
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Python package recipe
Folks,
I'm trying to create a recipe for Adafruit's BeagleBone IO Python Library:
https://github.com/adafruit/adafruit-beaglebone-io-python
The problem is that this python package generates some dtbos and install
them on /lib/firmware but these files were not presented on generated
package.
Here is my python-pybbio.bb:
DESCRIPTION = "Adafruit's BeagleBone IO Python Library"
SECTION = "devel/python"
LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://README.rst;md5=6c89ebda10e2f2efefe5e681a9a0c1f1"
SRCNAME = "pybbio"
COMPATIBLE_MACHINE = "(beaglebone)"
SRC_URI = "git://
github.com/adafruit/adafruit-beaglebone-io-python;branch=master"
SRCREV_pn-${PN} = "ff6f11abe7864e8db735b359365a85323bff2a06"
S = "${WORKDIR}/git"
inherit setuptools
PACKAGE_ARCH = "${MACHINE_ARCH}"
To get dtbos and all python files on the package I need to add these lines
in my recipe:
do_install_append() {
install -d ${D}/${nonarch_base_libdir}/firmware
install -m 0644 ${S}/overlays/*dt* ${D}${nonarch_base_libdir}/firmware/
}
FILES_${PN} = " ${nonarch_base_libdir}/firmware/* \
${exec_prefix} \
It seems not good to me and I thought that there is a better solution.
Should I have to inherit another class to achieve this?
Note: I can easly install this on target using pip install
Regards,
--
*dS
Diego Sueiro
Administrador do Embarcados
www.embarcados.com.br
/*long live rock 'n roll*/
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] busybox 1.21 ash bug?
On Tue, Dec 10, 2013 at 3:25 PM, Paul Eggleton < paul.eggle...@linux.intel.com> wrote: > Assuming that wasn't a deliberate change, it's likely that something that > depended on bash was bringing it in before and either that something is no > longer in the image, or it no longer depends on bash. (You can of course > explicitly add bash to the image if that's what you want.) > Thanks Paul, I added bash on my image. Rgs, -- *dS Diego Sueiro /*long live rock 'n roll*/ ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] busybox 1.21 ash bug?
On Tue, Dec 10, 2013 at 1:46 PM, Olof Johansson wrote:
> That type of for loop is a bashism; as far as I know and can
> tell, busybox ash does not support it (even with ASH_BASH_COMPAT=y).
>
> The code that is executed when the parser finds a "for" token:
>
> ash.c: parse_command(void)
> ...
> switch (readtoken()) {
> ...
> case TFOR:
> if (readtoken() != TWORD || quoteflag || !goodname(wordtext))
> raise_error_syntax("bad for loop variable");
>
> Are you sure it's using busybox ash when it actually works? I can
> reproduce the error message your are seeing in both busybox 1.20
> and 1.21.
>
>
> RANDOM is also an extension, but one that is supported by busybox
> (or rather, can be). The default defconfig in oe-core does not
> enable it, see ASH_RANDOM_SUPPORT.
>
I have a bbappend to enable it.
What a shame. I'm really sorry about the buzz.
I'm working based on Angstrom distribution setup-scripts, and for dylan
version it is using bash as the default shell and for dora version it is
using the ash from busybox.
Regards,
--
*dS
Diego Sueiro
/*long live rock 'n roll*/
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] busybox 1.21 ash bug?
Folks, Recently I switched to dora branch which builds busybox 1.21. I was using dylan branch with busybox 1.20 and the some shell scripts stopped working. There is a problem related with "for" statements. For example, on script below, it runs nice on busybox 1.20 but on 1.21 fails with the output:"./script.sh: line 3: syntax error: bad for loop variable". #!/bin/sh for (( i=1; i <= 5; i++ )) do echo "Random number $i: $RANDOM" done I've searched on busybox bug tracking but did not found nothing related with this. Maybe I'm missing something, I really don't know. I appreciate any help with this, and I'm sorry if this is not the appropriate list to discuss this kind of subject. Regards, -- *dS Diego Sueiro /*long live rock 'n roll*/ ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Custom defconfig is not used
On Thu, Nov 28, 2013 at 1:49 PM, Bruce Ashfield < bruce.ashfi...@windriver.com> wrote: > And the patch I attached for the kern-tools to use the dedicated > release branch for dylan fixed the other patching issue you were > seeing. > This patch was applied in some repo? Regards, -- *dS Diego Sueiro /*long live rock 'n roll*/ ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Custom defconfig is not used
Bruce,
Any updates on this?
Regards,
--
*dS
Diego Sueiro
/*long live rock 'n roll*/
On Mon, Nov 4, 2013 at 1:14 AM, Bruce Ashfield wrote:
> On 13-10-29 11:31 AM, Diego Sueiro wrote:
>
>> Bruce,
>>
>> I've created new build setup with this configuration:
>>
>> BB_VERSION= "1.18.0"
>> BUILD_SYS = "x86_64-linux"
>> NATIVELSBSTRING = "Ubuntu-12.10"
>> TARGET_SYS= "arm-poky-linux-gnueabi"
>> MACHINE = "beaglebone"
>> DISTRO= "poky"
>> DISTRO_VERSION= "1.4.2"
>> TUNE_FEATURES = "armv7a vfp neon"
>> TARGET_FPU= "vfp-neon"
>> meta
>> meta-yocto
>> meta-yocto-bsp= "dylan:4e399f08d596197859214fdb3b06403b87bf8789"
>> meta-oe = "dylan:a108b2203a997634f87ac687e81712badaf3c546"
>> common-bsp= "dylan:7fdf9c670a10c5031a2dc15c45e453de8c21"
>> meta-mine = "dylan:4e399f08d596197859214fdb3b06403b87bf8789"
>>
>> common-bsp comes from meta-beagleboard.
>> meta-oe needed to be added because of machine_kernel_pr.bbclass.
>>
>> bblayers.conf:
>>
>> LCONF_VERSION = "6"
>> BBPATH = "${TOPDIR}"
>> BBFILES ?= ""
>> BBLAYERS ?= " \
>>${TOPDIR}/meta \
>>${TOPDIR}/meta-yocto \
>>${TOPDIR}/meta-yocto-bsp \
>>${TOPDIR}/meta-openembedded/meta-oe \
>>${TOPDIR}/meta-beagleboard/common-bsp \
>>${TOPDIR}/meta-mine \
>>"
>>
>> meta-mine:
>>
>> conf/layer.conf:
>>
>> BBPATH .= ":${LAYERDIR}"
>> BBFILES += "${LAYERDIR}/recipes*/*/*.bb
>> ${LAYERDIR}/recipes*/*/*.bbappend"
>> BBFILE_COLLECTIONS += "my-layer"
>> BBFILE_PATTERN_my-layer := "^${LAYERDIR}/"
>> BBFILE_PRIORITY_my-layer = "10"
>>
>> recipes-kernel/linux/linux-mainline_3.8.bbappend (scenario 1):
>>
>> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-3.8:"
>> COMPATIBLE_MACHINE_beaglebone = "(beaglebone)"
>> SRC_URI += " file://defconfig \
>> "
>>
>> recipes-kernel/linux/linux-mainline-3.8/defconfig (scenario 1):
>>
>> http://pastebin.com/qd8B3C5K
>>
>>
>> recipes-kernel/linux/linux-mainline_3.8.bbappend (scenario 2):
>>
>> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-3.8:"
>> inherit kernel
>> require recipes-kernel/linux/linux-yocto.inc
>> COMPATIBLE_MACHINE_beaglebone = "(beaglebone)"
>> SRC_URI += " file://config-addons.cfg \
>> "
>>
>> recipes-kernel/linux/linux-mainline-3.8/config-addons.cfg (scenario
>> 2):
>>
>> CONFIG_WATCHDOG_NOWAYOUT=y
>>
>> CONFIG_NTFS_FS=y
>> CONFIG_NTFS_RW=y
>>
>>
>>
>> Results:
>>
>> * Scenario 1: Full defconfig replacement
>>
>>
>> ${WORKDIR}/defconfig comes from meta-beagleboard instead of meta-mine
>>
>> ${S}/.config comes from meta-beagleboard instead of meta-mine
>>
>
> FYI: I went silent on this, since I was running a few experiments in the
> background. Mainly on scenario 2, but I can say that I see the same
> behaviour
> with scenario #1 as you do. Whether or not I use the yocto kernel tooling,
> or the core kernel processing, I see exactly the same defconfig used.
>
> The issue you are seeing is distinct from the kernel processing, since
> the defconfig isn't treated any differently than anything else on the
> SRC_URI from the fetcher point of view ... and it is the fetcher which
> is matching file://defconfig from the meta-beagleboard layer before the
> one you have in meta-mine, since FILESEXTRAPATHS are searched after the
> FILESPATH for the elements in the SRC_URI. But I'm not a fetcher expert,
> that's my understanding and empirical evidence.
>
> As a debug, I called src_patches() in patches.bbclass explicitly, and
> it is obvious that the source of the defconfig is from meta-beagleboard.
> Renaming the file in meta-beagleboard, allows the one in meta-mine to
> be found, since the search continues.
>
> So for this question, your issue is with the ordering of the elements
> on the SRC_URI, and you can have your la
Re: [yocto] Deploying Yocto build images
Stefano, This is a really great tool. I'm always developing a new software update tool for each new project, since there are different requirements. As I can see you are dealing with different scenarios, and this is really amazing. I'm already cloning meta-swupdate to test it. Looking at recipes I realized that swupdate is initialized in an sysVinit environment. Did you plan to use systemd too? Maybe I can contribute to this. Thanks for sharing. Regards, -- *dS Diego Sueiro /*long live rock 'n roll*/ 2013/11/21 Stefano Babic > Hi everybody, > > in the last ELCE, David point out in his presentation that we should > improve how to deploy Yocto images on the target. > > I did some work this year to provide a reliable way for some customers > of us to install Yocto's images in field, and I have published last week > the sources. Here the link of the announcement: > > http://comments.gmane.org/gmane.comp.embedded.eldk/2397 > > Mainly, it is a tool that can be stored in the rootfs or will be put in > a separate initrd image and whose goal is only to update the system. I > have tried to describe pros and cons of several different solutions > (updating via bootloader ? single copy against dual copy ?) - you can > find details in the doc directory in the swupdate repository. > > Maybe someone of you can find this helpful, and I will be happy if I > could get some feedback. > > Best regards, > Stefano Babic > > -- > = > DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de > = > ___ > 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] Toaster Alpha Release for dora-10.0.0
2013/11/6 Flanagan, Elizabeth > Please see the wiki on how to start the system. > > https://wiki.yoctoproject.org/wiki/Toaster#To_get_it_up_and_running: > The sequence of commands mentions to stop toaster and then opens http://localhost:8000/, but if I do that the service is not available. So, I believe that the sequence must be: - to see the web interface: xdg-open http://localhost:8000/ - to stop Toaster: source toaster stop Regards, -- *dS Diego Sueiro /*long live rock 'n roll*/ ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] adding a udev entry for a camera
Edward,
Is uvcvideo module loaded?
What is lsmod and dmesg output when webcam is connected?
Regards,
--
*dS
Diego Sueiro
/*long live rock 'n roll*/
2013/10/31 Edward Vidal
> Hello,
> I had just recently built angstrom a few days ago. I tried the kernel
> that was built with 3.2.28 with the same results still not getting a
> /dev/video0.
> I did the following steps since angstrom uses meta-beagleboard, in hopes
> of getting a kernel 3.8 version.
>
> git commit -a
> git checkout -b wkg-angstrom-v2013.06-yocto1.4
> origin/angstrom-v2013.06-yocto1.4
> ./oebb.sh config beagleboard
> ./oebb.sh update
>
> . .oe/environment-angstrom-v2013.06
> MACHINE=beagleboard bitbake console-image
> rm -rf build/tmp-angstrom_v2012_12-eglibc/
>
> Even with meta-beagleboard at
> commit cdaa65dba20da97be7793404bcc90c498771fb04
> Author: Koen Kooi
> Date: Wed Oct 30 18:31:21 2013 +0100
>
> contrib: bone-flash-tool: use --numeric-owner with tar to keep file
> ownershi
>
> Signed-off-by: Koen Kooi
> Which is a dylan branch it still was building a 3.2.28 kernel
>
> git checkout -b 3.8 feb3ea180018d0f
> commit feb3ea180018d0f64f406f208827413b91122b07
> Author: Koen Kooi
> Date: Sun Oct 27 17:17:06 2013 +0100
>
> linux-mainline 3.8: ADC and MIDI cape patches
>
> Signed-off-by: Koen Kooi
> It still tries to build a 3.2.28 kernel.
> What should I do to force it to build the 3.8 kernel?
>
> Any and all help will be appreciated.
> Thanks to all
>
>
> On Thu, Oct 31, 2013 at 11:08 AM, Khem Raj wrote:
>
>> On Thu, Oct 31, 2013 at 9:54 AM, Edward Vidal
>> wrote:
>> > hello,
>> > I removed the bus
>> > udevadm test --action=add /usr/src/kernel/sysfs
>> >
>> > run_command: calling: test
>> > adm_test: version 182
>> > This program is for debugging only, it does not run any program,
>> > specified by a RUN key. It may show incorrect results, because
>> > some values may be different, or not available at a simulation run.
>> >
>> > builtin_kmod_init: load module index
>> > add_matching_files: unable to open '/var/run/udev/rules.d': No such
>> file or
>> > directory
>> > parse_file: reading '/etc/udev/rules.d/10-c920.rules' as rules file
>> > still no /dev/video0
>> >
>> > cat /etc/udev/rules.d/10-c920.rules
>> > SUBSYSTEM=="video4linux", ATTRS{idvendor}=="0x046d",
>> > ATTRS{idProduct}=="0x082d", NAME="video0", MODE:="0660", RUN="/bin/mknod
>> > /dev/video0 c 81 0"
>> > still no /dev/video0
>> > The camera is working correctly on my fedora 18 x86_64.
>>
>> OK so atleast your rules file is correct syntax wise. Why not try the
>> 3.8 kernel from meta-beagleboard ?
>>
>> >
>> > Note:
>> > * Before camera connected
>> > ** After camera connected
>> > Linux sim4.swbell.net 3.9.2-200.fc18.x86_64 #1 SMP Mon May 13 13:59:47
>> UTC
>> > 2013 x86_64 x86_64 x86_64 GNU/Linux
>> >
>> > Module Size Used by
>> > **snd_usb_audio 145223 1
>> > **snd_usbmidi_lib24713 1 snd_usb_audio
>> > **snd_rawmidi29531 1 snd_usbmidi_lib
>> >
>> > *snd_hwdep 17650 1 snd_hda_codec
>> > **snd_hwdep 17650 2 snd_usb_audio,snd_hda_codec
>> >
>> > *snd_seq_device 14136 1 snd_seq
>> > **snd_seq_device 14136 2 snd_seq,snd_rawmidi
>> >
>> > *snd79379 19
>> >
>> snd_hda_codec_realtek,snd_hwdep,snd_timer,snd_hda_codec_hdmi,snd_pcm,snd_seq,snd_hda_codec,snd_hda_intel,snd_seq_device
>> > **snd79379 24
>> >
>> snd_hda_codec_realtek,snd_usb_audio,snd_hwdep,snd_timer,snd_hda_codec_hdmi,snd_pcm,snd_seq,snd_rawmidi,snd_usbmidi_lib,snd_hda_codec,snd_hda_intel,snd_seq_device
>> >
>> > *video 18991 0
>> > **video 18991 0
>> >
>> > This is the beagleboard
>> > lsmod
>> > Module Size Used by
>> > nls_iso8859_1 3673 1
>> > nls_cp437 5339 1
>> > I am going to be checking the video is a module or built into the
>> kernel of
>> > the
>> > uname -a
>> > Linux beagleboard 3.4.36-yocto-standard #1 Mon Oct 28 21:58:22 MDT 2013
>> > armv7l GNU/Linux
>> >
>> > Thanks
>> >
>> >
>> > On Thu, Oct 31, 2013 at 10:23 AM, Khem Raj wrote:
>> >>
>> >> On Thu, Oct 31, 2013 at 8:45 AM, Edward Vidal <
>> vidal.devel...@gmail.com>
>> >> wrote:
>> >> >
>> >> > Do I add RUN+="/bin/mknod /dev/video0 c 81 0" see below new version
>> of
>> >> > 1--c920.rules
>> >> > cat 10-c920.rules
>> >> > SUBSYSTEM=="video4linux", BUS=="usb", ATTRS{idvendor}=="0x046d",
>> >> > ATTRS{idProduct}=="0x082d", NAME="video0", MODE:="0660",
>> >> > RUN+="/bin/mknod
>> >> > /dev/video0 c 81 0"
>> >>
>> >> get rid of BUS construct there
>> >
>> >
>>
>
>
> ___
> 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] adding a udev entry for a camera
Is it enabled on kernel config? Some references: http://linuxtv.org/wiki/index.php/Webcam_Devices http://tldp.org/HOWTO/Webcam-HOWTO/hardware.html Regards, -- *dS Diego Sueiro /*long live rock 'n roll*/ 2013/10/31 Gary Thomas > On 2013-10-30 19:12, Edward Vidal wrote: > >> Hello, >> This is when I connect the camera >> udevadm monitor test >> monitor will print the received events for: >> UDEV - the event which udev sends out after rule processing >> KERNEL - the kernel uevent >> >> KERNEL[803.263336] add /devices/platform/usbhs_omap/** >> ehci-omap.0/usb1/1-2/1-2.3/1-**2.3.4 (usb) >> KERNEL[803.267456] add /devices/platform/usbhs_omap/** >> ehci-omap.0/usb1/1-2/1-2.3/1-**2.3.4/1-2.3.4:1.0 (usb) >> KERNEL[803.269287] add /devices/platform/usbhs_omap/** >> ehci-omap.0/usb1/1-2/1-2.3/1-**2.3.4/1-2.3.4:1.1 (usb) >> KERNEL[803.269958] add /devices/platform/usbhs_omap/** >> ehci-omap.0/usb1/1-2/1-2.3/1-**2.3.4/1-2.3.4:1.2 (usb) >> KERNEL[803.270721] add /devices/platform/usbhs_omap/** >> ehci-omap.0/usb1/1-2/1-2.3/1-**2.3.4/1-2.3.4:1.3 (usb) >> KERNEL[803.276214] add /devices/platform/usbhs_omap/** >> ehci-omap.0/usb1/1-2/1-2.3/1-**2.3.4/usb_device/usbdev1.15 >> (usb_device)** >> UDEV [803.277191] add /devices/platform/usbhs_omap/** >> ehci-omap.0/usb1/1-2/1-2.3/1-**2.3.4 (usb) >> UDEV [803.306091] add /devices/platform/usbhs_omap/** >> ehci-omap.0/usb1/1-2/1-2.3/1-**2.3.4/usb_device/usbdev1.15 (usb_device) >> UDEV [803.318603] add /devices/platform/usbhs_omap/** >> ehci-omap.0/usb1/1-2/1-2.3/1-**2.3.4/1-2.3.4:1.2 (usb) >> UDEV [803.324249] add /devices/platform/usbhs_omap/** >> ehci-omap.0/usb1/1-2/1-2.3/1-**2.3.4/1-2.3.4:1.1 (usb) >> UDEV [803.329712] add /devices/platform/usbhs_omap/** >> ehci-omap.0/usb1/1-2/1-2.3/1-**2.3.4/1-2.3.4:1.0 (usb) >> UDEV [803.333160] add /devices/platform/usbhs_omap/** >> ehci-omap.0/usb1/1-2/1-2.3/1-**2.3.4/1-2.3.4:1.3 (usb) >> >> still no /dev/video0 >> ls -la /dev/v* >> crw-rw 1 root tty 7, 0 Jan 1 2000 /dev/vcs >> crw-rw 1 root tty 7, 1 Jan 1 2000 /dev/vcs1 >> crw-rw 1 root tty 7, 2 Jan 1 2000 /dev/vcs2 >> crw-rw 1 root tty 7, 3 Oct 29 13:51 /dev/vcs3 >> crw-rw 1 root tty 7, 128 Jan 1 2000 /dev/vcsa >> crw-rw 1 root tty 7, 129 Jan 1 2000 /dev/vcsa1 >> crw-rw 1 root tty 7, 130 Jan 1 2000 /dev/vcsa2 >> crw-rw 1 root tty 7, 131 Oct 29 13:51 /dev/vcsa3 >> root@beagleboard:~# lsusb >> Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp. >> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub >> Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub >> Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. >> Bus 001 Device 004: ID 0409:0059 NEC Corp. HighSpeed Hub >> Bus 001 Device 005: ID 413c:2005 Dell Computer Corp. RT7D50 Keyboard >> Bus 001 Device 006: ID 046d:c001 Logitech, Inc. N48/M-BB48 [FirstMouse >> Plus] >> Bus 001 Device 015: ID 046d:082d Logitech, Inc. >> >> *** >> >> >> udevadm monitor --udev >> monitor will print the received events for: >> UDEV - the event which udev sends out after rule processing >> camera removed*** >> UDEV [1325.916811] remove /devices/platform/usbhs_omap/** >> ehci-omap.0/usb1/1-2/1-2.3/1-**2.3.4/1-2.3.4:1.1 (usb) >> UDEV [1325.918489] remove /devices/platform/usbhs_omap/** >> ehci-omap.0/usb1/1-2/1-2.3/1-**2.3.4/1-2.3.4:1.0 (usb) >> UDEV [1325.919282] remove /devices/platform/usbhs_omap/** >> ehci-omap.0/usb1/1-2/1-2.3/1-**2.3.4/1-2.3.4:1.2 (usb) >> UDEV [1325.923005] remove /devices/platform/usbhs_omap/** >> ehci-omap.0/usb1/1-2/1-2.3/1-**2.3.4/1-2.3.4:1.3 (usb) >> UDEV [1325.928437] remove /devices/platform/usbhs_omap/** >> ehci-omap.0/usb1/1-2/1-2.3/1-**2.3.4/usb_device/usbdev1.15 (usb_device) >> UDEV [1325.932709] remove /devices/platform/usbhs_omap/** >> ehci-omap.0/usb1/1-2/1-2.3/1-**2.3.4 (usb) >> camera added >> *** >> UDEV [1329.344727] add /devices/platform/usbhs_omap/** >> ehci-omap.0/usb1/1-2/1-2.3/1-**2.3.4 (usb) >> UDEV [1329.376313] add /devices/platform/usbhs_omap/** >> ehci-omap.0/usb1/1-2/1-2.3/1-**2.3.4/usb_device/usbdev1.16 (usb_device) >> UDEV [1329.389008] add /devices/platform/usbhs_omap/** >> ehci-omap.0/usb1/1-2/1-2.3/1
Re: [yocto] Custom defconfig is not used
2013/10/30 Bruce Ashfield > I've confirmed this behaviour on dylan when I exactly reproduced > your configuration. The more interesting one is scenario 2, so I'm > trying it out, before looking at #1 in more detail. > Phew, now I'm not feeling crazy. Looking at linux.inc from meta-beagleboard I can see that there are a lot of tweaks applied onto kernel config. Maybe it is bricking something. https://github.com/beagleboard/meta-beagleboard/blob/dylan/common-bsp/recipes-kernel/linux/linux.inc Regards, -- *dS Diego Sueiro /*long live rock 'n roll*/ ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Custom defconfig is not used
Bruce,
I've created new build setup with this configuration:
BB_VERSION= "1.18.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING = "Ubuntu-12.10"
TARGET_SYS= "arm-poky-linux-gnueabi"
MACHINE = "beaglebone"
DISTRO= "poky"
DISTRO_VERSION= "1.4.2"
TUNE_FEATURES = "armv7a vfp neon"
TARGET_FPU= "vfp-neon"
meta
meta-yocto
meta-yocto-bsp= "dylan:4e399f08d596197859214fdb3b06403b87bf8789"
meta-oe = "dylan:a108b2203a997634f87ac687e81712badaf3c546"
common-bsp= "dylan:7fdf9c670a10c5031a2dc15c45e453de8c21"
meta-mine = "dylan:4e399f08d596197859214fdb3b06403b87bf8789"
common-bsp comes from meta-beagleboard.
meta-oe needed to be added because of machine_kernel_pr.bbclass.
bblayers.conf:
LCONF_VERSION = "6"
BBPATH = "${TOPDIR}"
BBFILES ?= ""
BBLAYERS ?= " \
${TOPDIR}/meta \
${TOPDIR}/meta-yocto \
${TOPDIR}/meta-yocto-bsp \
${TOPDIR}/meta-openembedded/meta-oe \
${TOPDIR}/meta-beagleboard/common-bsp \
${TOPDIR}/meta-mine \
"
meta-mine:
conf/layer.conf:
BBPATH .= ":${LAYERDIR}"
BBFILES += "${LAYERDIR}/recipes*/*/*.bb ${LAYERDIR}/recipes*/*/*.bbappend"
BBFILE_COLLECTIONS += "my-layer"
BBFILE_PATTERN_my-layer := "^${LAYERDIR}/"
BBFILE_PRIORITY_my-layer = "10"
recipes-kernel/linux/linux-mainline_3.8.bbappend (scenario 1):
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-3.8:"
COMPATIBLE_MACHINE_beaglebone = "(beaglebone)"
SRC_URI += " file://defconfig \
"
recipes-kernel/linux/linux-mainline-3.8/defconfig (scenario 1):
http://pastebin.com/qd8B3C5K
recipes-kernel/linux/linux-mainline_3.8.bbappend (scenario 2):
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-3.8:"
inherit kernel
require recipes-kernel/linux/linux-yocto.inc
COMPATIBLE_MACHINE_beaglebone = "(beaglebone)"
SRC_URI += " file://config-addons.cfg \
"
recipes-kernel/linux/linux-mainline-3.8/config-addons.cfg (scenario 2):
CONFIG_WATCHDOG_NOWAYOUT=y
CONFIG_NTFS_FS=y
CONFIG_NTFS_RW=y
Results:
- Scenario 1: Full defconfig replacement
${WORKDIR}/defconfig comes from meta-beagleboard instead of meta-mine
${S}/.config comes from meta-beagleboard instead of meta-mine
- Scenario 2: Config fragments
"bitbake linux-mainline" got stuck on do_patch
log.do_patch:
DEBUG: Executing shell function do_patch
WARNING: no meta data branch found ...
Switched to branch 'linux-3.8.y'
[INFO] validating against known patches (beaglebone-standard-meta)
Regards,
--
*dS
Diego Sueiro
/*long live rock 'n roll*/
2013/10/29 Diego Sueiro
> 2013/10/29 Andrea Adami
>
>> I'll jump in one more time...
>>
>> Have you tried putting defconfig and patch under subdir?
>>
>> recipes-kernel/linux/linux-yocto-3.2/
>> defconfig
>> my-own.patch
>>
>> I've recently added two similar entries for 3.10 and it works.
>> Afaik it was impossible to put a common patch under /linux-yocto-.3.2
>> at the time.
>>
>
> Andrea,
>
> I did it before and not worked.
> I'll do it again just to make sure.
>
>
> Regards,
>
> --
> *dS
> Diego Sueiro
>
> /*long live rock 'n roll*/
>
>
> 2013/10/29 Andrea Adami
>
>> On Tue, Oct 29, 2013 at 11:33 AM, Diego Sueiro
>> wrote:
>> >
>> > 2013/10/28 Bruce Ashfield
>> >>
>> >> I'm using dylan for my yocto checkout (not oe-core standalone, since
>> >> this is a yocto list/question),
>> >
>> > I thought that opemenbedded-core and poky were sharing the same core
>> > components, classes and functions.
>> >
>> >>
>> >> My build shows:
>> >>
>> >> meta
>> >> meta-yocto
>> >> meta-yocto-bsp= "dylan:3dc4505f0e744177ae4ddff1e1ce8b31b95dfaa6"
>> >> meta-ti = "master:c14c386946e1ea341faeea292580e37d538d645d"
>> >> meta-alphalem = "master:a5c0e8ff51297a4090cd47d669b4fc9c94696908"
>> >> meta-alphalem-bsp = "master:56086e4dc618e975c9a46491793041f0d18e47a2"
>> >>
>> >> Mike indicated that he was using dylan for meta-ti, but that doesn't
>> >> make a difference either, since for our purposed. It's kernel.bbclass
>> >> and the yocto kernel processing that matters.
>> >
>> > I'll build a setup with yocto (dylan), meta-beagleboard (dylan) and
>> > meta-mine to check if I can reproduce the issues.
>> >
>> >
Re: [yocto] Custom defconfig is not used
2013/10/29 Andrea Adami
> I'll jump in one more time...
>
> Have you tried putting defconfig and patch under subdir?
>
> recipes-kernel/linux/linux-yocto-3.2/
> defconfig
> my-own.patch
>
> I've recently added two similar entries for 3.10 and it works.
> Afaik it was impossible to put a common patch under /linux-yocto-.3.2
> at the time.
>
Andrea,
I did it before and not worked.
I'll do it again just to make sure.
Regards,
--
*dS
Diego Sueiro
/*long live rock 'n roll*/
2013/10/29 Andrea Adami
> On Tue, Oct 29, 2013 at 11:33 AM, Diego Sueiro
> wrote:
> >
> > 2013/10/28 Bruce Ashfield
> >>
> >> I'm using dylan for my yocto checkout (not oe-core standalone, since
> >> this is a yocto list/question),
> >
> > I thought that opemenbedded-core and poky were sharing the same core
> > components, classes and functions.
> >
> >>
> >> My build shows:
> >>
> >> meta
> >> meta-yocto
> >> meta-yocto-bsp= "dylan:3dc4505f0e744177ae4ddff1e1ce8b31b95dfaa6"
> >> meta-ti = "master:c14c386946e1ea341faeea292580e37d538d645d"
> >> meta-alphalem = "master:a5c0e8ff51297a4090cd47d669b4fc9c94696908"
> >> meta-alphalem-bsp = "master:56086e4dc618e975c9a46491793041f0d18e47a2"
> >>
> >> Mike indicated that he was using dylan for meta-ti, but that doesn't
> >> make a difference either, since for our purposed. It's kernel.bbclass
> >> and the yocto kernel processing that matters.
> >
> > I'll build a setup with yocto (dylan), meta-beagleboard (dylan) and
> > meta-mine to check if I can reproduce the issues.
> >
> >>
> >> In meta-alphalem-bsp, I have linux-mainline_3.2.bbappend, with the
> >> following content:
> >>
> >> > cat linux-mainline_3.2.bbappend
> >> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-3.2:"
> >>
> >> inherit kernel
> >> require recipes-kernel/linux/linux-yocto.inc
> >>
> >> COMPATIBLE_MACHINE = "(beagleboard)"
> >>
> >> SRC_URI_append = " file://defconfig"
> >> SRC_URI_append = " file://my_frag.cfg"
> >>
> >> And I added a fragment which has:
> >>
> >> > cat my_frag.cfg
> >> CONFIG_WATCHDOG_NOWAYOUT=y
> >> CONFIG_NTFS_FS=y
> >> CONFIG_NTFS_RW=y
> >>
> >> When both are applied to the kernel build, we should see CONFIG_NTFS_FS
> >> transition from =m to =y:
> >>
> >> > grep CONFIG_NTFS_FS *
> >> defconfig:CONFIG_NTFS_FS=m
> >> my_frag.cfg:CONFIG_NTFS_FS=y
> >>
> >> After invoking linux-mainline's configure task, I see the following:
> >>
> >> > grep CONFIG_NTFS_FS linux-beagleboard-standard-build/.config
> >> CONFIG_NTFS_FS=y
> >>
> >> And other elements of the defconfig and fragment are properly applied
> >> to the configuration phase.
> >>
> >> I'm also seeing good results on master, which means that I'm at a
> >> standstill to reproduce any problems.
> >>
> >> Diego: can you confirm for me what triggers you are seeing that shows
> >> the defconfig and fragment are not used. I assume the config options
> >> are not present, but I just want to be sure.
> >
> > For the full defconfig replacement after doing a do_configure I've
> checked
> > .config on ${S} and it did not included my CONFIGS.
> > For config fragment it got stuck on do_patch task.
> >
> >
> >
> > Regards,
> >
> > --
> > *dS
> > Diego Sueiro
> >
> > /*long live rock 'n roll*/
> >
> > ___
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
> >
>
> I'll jump in one more time...
>
> Have you tried putting defconfig and patch under subdir?
>
> recipes-kernel/linux/linux-yocto-3.2/
> defconfig
> my-own.patch
>
> I've recently added two similar entries for 3.10 and it works.
> Afaik it was impossible to put a common patch under /linux-yocto-.3.2
> at the time.
>
> Regards
>
> Andrea
>
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Custom defconfig is not used
2013/10/28 Bruce Ashfield
> I'm using dylan for my yocto checkout (not oe-core standalone, since
> this is a yocto list/question),
>
I thought that opemenbedded-core and poky were sharing the same core
components, classes and functions.
> My build shows:
>
> meta
> meta-yocto
> meta-yocto-bsp= "dylan:**3dc4505f0e744177ae4ddff1e1ce8b**31b95dfaa6"
> meta-ti = "master:**c14c386946e1ea341faeea292580e3**7d538d645d"
> meta-alphalem = "master:**a5c0e8ff51297a4090cd47d669b4fc**9c94696908"
> meta-alphalem-bsp = "master:**56086e4dc618e975c9a46491793041**f0d18e47a2"
>
> Mike indicated that he was using dylan for meta-ti, but that doesn't
> make a difference either, since for our purposed. It's kernel.bbclass
> and the yocto kernel processing that matters.
>
I'll build a setup with yocto (dylan), meta-beagleboard (dylan) and
meta-mine to check if I can reproduce the issues.
> In meta-alphalem-bsp, I have linux-mainline_3.2.bbappend, with the
> following content:
>
> > cat linux-mainline_3.2.bbappend
> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-3.2:"
>
> inherit kernel
> require recipes-kernel/linux/linux-**yocto.inc
>
> COMPATIBLE_MACHINE = "(beagleboard)"
>
> SRC_URI_append = " file://defconfig"
> SRC_URI_append = " file://my_frag.cfg"
>
> And I added a fragment which has:
>
> > cat my_frag.cfg
> CONFIG_WATCHDOG_NOWAYOUT=y
> CONFIG_NTFS_FS=y
> CONFIG_NTFS_RW=y
>
> When both are applied to the kernel build, we should see CONFIG_NTFS_FS
> transition from =m to =y:
>
> > grep CONFIG_NTFS_FS *
> defconfig:CONFIG_NTFS_FS=m
> my_frag.cfg:CONFIG_NTFS_FS=y
>
> After invoking linux-mainline's configure task, I see the following:
>
> > grep CONFIG_NTFS_FS linux-beagleboard-standard-**build/.config
> CONFIG_NTFS_FS=y
>
> And other elements of the defconfig and fragment are properly applied
> to the configuration phase.
>
> I'm also seeing good results on master, which means that I'm at a
> standstill to reproduce any problems.
>
> Diego: can you confirm for me what triggers you are seeing that shows
> the defconfig and fragment are not used. I assume the config options
> are not present, but I just want to be sure.
>
For the full defconfig replacement after doing a do_configure I've checked
.config on ${S} and it did not included my CONFIGS.
For config fragment it got stuck on do_patch task.
Regards,
--
*dS
Diego Sueiro
/*long live rock 'n roll*/
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Custom defconfig is not used
Bruce,
We have two scenarios here:
1. bbapend with full defconfig replacement
2. bbapend with config fragments
The first scenario just worked when using FILESPATH_prepend. For me it does
not make sense, since on YP manual says that FILESEXTRAPATHS_prepend must
be use [1].
The second scenario did not worked even changing to FILESPATH_prepend.
[1] -
http://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#var-FILESEXTRAPATHS
Regards,
--
*dS
Diego Sueiro
/*long live rock 'n roll*/
2013/10/25 Mike Lewis
> Bruce: yep, fixed my issue. Sorry for the bother!
>
> Diego: thanks for the solution!
>
> - Mike
>
>
> On 10/25/2013 11:44 AM, Bruce Ashfield wrote:
>
>> On Fri, Oct 25, 2013 at 7:43 AM, Diego Sueiro
>> wrote:
>>
>>> Bruce,
>>>
>>> Regarding the defconfig not used, I've found this thread on Angstrom
>>> devel
>>> ML:
>>> http://www.mail-archive.com/**angstrom-distro-devel@**
>>> linuxtogo.org/msg06721.html<http://www.mail-archive.com/angstrom-distro-devel@linuxtogo.org/msg06721.html>
>>>
>>> I've replaced "FILESEXTRAPATHS_prepend" with "FILESPATH_prepend" and
>>> removed
>>> the custom "do_configure_prepend" function and bitbake is now using my
>>> defconfig.
>>> So, it seems that there is an issue with FILESEXTRAPATHS variable.
>>>
>>> Aha. That does make sense.
>>
>> Mike: does that same change fix your issues ?
>>
>> Bruce
>>
>> Regards,
>>>
>>> --
>>> *dS
>>> Diego Sueiro
>>>
>>> /*long live rock 'n roll*/
>>>
>>>
>>> 2013/10/23 Bruce Ashfield
>>>
>>>> On 13-10-22 12:23 PM, Mike Lewis wrote:
>>>>
>>>>> Hi Bruce,
>>>>>
>>>>> I'm trying to accomplish the nearly the same thing (i.e. adding config
>>>>> fragment) and I'm having the same issue at the do_patch step. Were you
>>>>> able to reproduce this on your end?
>>>>>
>>>>
>>>> Mike,
>>>>
>>>> Is you config/layer somewhere than I can have a look at it ? I was
>>>> trying
>>>> some builds here, and my tests are working. But I'd like to try it
>>>> with your config as well.
>>>>
>>>> Bruce
>>>>
>>>>
>>>> Thanks,
>>>>> Mike
>>>>>
>>>>> On 10/18/2013 01:17 PM, Bruce Ashfield wrote:
>>>>>
>>>>>> On 13-10-18 05:17 AM, Diego Sueiro wrote:
>>>>>>
>>>>>>>
>>>>>>> 2013/10/18 Bruce Ashfield >>>>>> <mailto:bruce.ashfield@**windriver.com
>>>>>>> >>
>>>>>>>
>>>>>>> I fell behind today .. i had 2300 unread email to start this
>>>>>>> morning :)
>>>>>>> Is there a way that I can get a copy of your recipes and layers
>>>>>>> ?
>>>>>>> If
>>>>>>> I can do a build myself, I can easily debug and fix this ..
>>>>>>> otherwise, we'll
>>>>>>> go back and forth many times debugging.
>>>>>>>
>>>>>>> Cheers,
>>>>>>>
>>>>>>> Bruce
>>>>>>>
>>>>>>>
>>>>>>> I'm using the environment provided by Angstrom from it's github setup
>>>>>>> scripts.
>>>>>>> If you want to exactly reproduce it you need to:
>>>>>>>
>>>>>>> git clone
>>>>>>> https://github.com/Angstrom-**distribution/setup-scripts.git<https://github.com/Angstrom-distribution/setup-scripts.git>
>>>>>>> cd setup-scripts
>>>>>>> git checkout angstrom-v2013.06-yocto1.4
>>>>>>> MACHINE=beaglebone ./oebb.sh config beaglebone
>>>>>>>
>>>>>>> Here is the setup and files for meta-mine:
>>>>>>>
>>>>>>> bblayers.conf:
>>>>>>>
>>>>>>> BBLAYERS = \"
>>>>>>>
>>>>>>> ...
>>>>>>> ${TOPDIR}/sources/meta-mine \
>>>>>>> "
>>>>>>>
>>>>>>> meta-mi
Re: [yocto] BAD_RECOMMENDATIONS / BAD_RECOMMENDS not working
2013/10/25 Martin Jansa > BAD_RECOMMENDATIONS work only for packages which are installed because > something has them in RRECOMMENDS, if your custom image has qt-demo-init in > IMAGE_INSTALL or pulled by RDEPENDS in some variable, than it won't be > removed (and shouldn't be). > Thanks Martin, qt-demo-init is listed as RDEPENDS on packagegroup-core-qt4e. As soon as my image recipe have a IMAGE_INSTALL = "packagegroup-core-qt4e", I'll have to remove the init script with ROOTFS_POSTPROCESS_COMMAND. That is it? The renaming question is: packagegroup-core-qt4e should include qt-demo-init with RRECOMENDS instead of RDEPENDS? Regards, -- *dS Diego Sueiro /*long live rock 'n roll*/ ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] BAD_RECOMMENDATIONS / BAD_RECOMMENDS not working
Folks, I'm using dylan branch and package management is ipk. I'm trying to remove qt-demo-init package from my custom image with both BAD_RECOMMENDATIONS and BAD_RECOMMENDS variables but it is still being installed on rootfs. I've already did a cleansstate on my image recipe but no success. I can use the ROOTFS_POSTPROCESS_COMMAND to remove the initscript from /etc/init.d but it seems to be an workaround to get this working. Regards, -- *dS Diego Sueiro /*long live rock 'n roll*/ ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Custom defconfig is not used
Bruce,
Regarding the defconfig not used, I've found this thread on Angstrom devel
ML:
http://www.mail-archive.com/angstrom-distro-devel@linuxtogo.org/msg06721.html
I've replaced "FILESEXTRAPATHS_prepend" with "FILESPATH_prepend" and
removed the custom "do_configure_prepend" function and bitbake is now using
my defconfig.
So, it seems that there is an issue with FILESEXTRAPATHS variable.
Regards,
--
*dS
Diego Sueiro
/*long live rock 'n roll*/
2013/10/23 Bruce Ashfield
> On 13-10-22 12:23 PM, Mike Lewis wrote:
>
>> Hi Bruce,
>>
>> I'm trying to accomplish the nearly the same thing (i.e. adding config
>> fragment) and I'm having the same issue at the do_patch step. Were you
>> able to reproduce this on your end?
>>
>
> Mike,
>
> Is you config/layer somewhere than I can have a look at it ? I was trying
> some builds here, and my tests are working. But I'd like to try it
> with your config as well.
>
> Bruce
>
>
>
>> Thanks,
>> Mike
>>
>> On 10/18/2013 01:17 PM, Bruce Ashfield wrote:
>>
>>> On 13-10-18 05:17 AM, Diego Sueiro wrote:
>>>
>>>>
>>>> 2013/10/18 Bruce Ashfield >>> <mailto:bruce.ashfield@**windriver.com >>
>>>>
>>>> I fell behind today .. i had 2300 unread email to start this
>>>> morning :)
>>>> Is there a way that I can get a copy of your recipes and layers ? If
>>>> I can do a build myself, I can easily debug and fix this ..
>>>> otherwise, we'll
>>>> go back and forth many times debugging.
>>>>
>>>> Cheers,
>>>>
>>>> Bruce
>>>>
>>>>
>>>> I'm using the environment provided by Angstrom from it's github setup
>>>> scripts.
>>>> If you want to exactly reproduce it you need to:
>>>>
>>>> git clone https://github.com/Angstrom-**
>>>> distribution/setup-scripts.git<https://github.com/Angstrom-distribution/setup-scripts.git>
>>>> cd setup-scripts
>>>> git checkout angstrom-v2013.06-yocto1.4
>>>> MACHINE=beaglebone ./oebb.sh config beaglebone
>>>>
>>>> Here is the setup and files for meta-mine:
>>>>
>>>> bblayers.conf:
>>>>
>>>> BBLAYERS = \"
>>>>
>>>> ...
>>>> ${TOPDIR}/sources/meta-mine \
>>>> "
>>>>
>>>> meta-mine/conf/layer.conf:
>>>>
>>>> # We have a conf and classes directory, append to BBPATH
>>>> BBPATH .= ":${LAYERDIR}"
>>>> # We have a recipes directory, add to BBFILES
>>>> BBFILES += "${LAYERDIR}/recipes*/*/*.bb
>>>> ${LAYERDIR}/recipes*/*/*.**bbappend"
>>>> BBFILE_COLLECTIONS += "mine-layer"
>>>> BBFILE_PATTERN_mine-layer := "^${LAYERDIR}/"
>>>> BBFILE_PRIORITY_mine-layer = "10"
>>>> LAYERDEPENDS_mine-layer = "angstrom-layer"
>>>>
>>>> meta-mine/recipes-kernel/**linux/linux-mainline_3.8.**bbappend:
>>>>
>>>> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-3.8:"
>>>> inherit kernel
>>>> require recipes-kernel/linux/linux-**yocto.inc
>>>> COMPATIBLE_MACHINE_beaglebone = "(beaglebone)"
>>>> SRC_URI += " file://config-addons.cfg "
>>>>
>>>> meta-mine/recipes-kernel/**linux/linux-mainline-3.8/**
>>>> config-addons.cfg:
>>>>
>>>> CONFIG_WATCHDOG_NOWAYOUT=y
>>>> CONFIG_NTFS_FS=y
>>>> CONFIG_NTFS_RW=y
>>>>
>>>>
>>>>
>>>> But I think that instead of using the whole Angstrom you can just use
>>>> poky and meta-beagleboard/common-bsp on dylan branch.
>>>>
>>>
>>> Great. I'll launch some test builds and see what breaks (or works) :)
>>>
>>> Bruce
>>>
>>>
>>>>
>>>> Regards,
>>>>
>>>> --
>>>> *dS
>>>> Diego Sueiro
>>>>
>>>> /*long live rock 'n roll*/
>>>>
>>>
>>> __**_
>>> yocto mailing list
>>> yocto@yoctoproject.org
>>> https://lists.yoctoproject.**org/listinfo/yocto<https://lists.yoctoproject.org/listinfo/yocto>
>>>
>>
>>
> __**_
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.**org/listinfo/yocto<https://lists.yoctoproject.org/listinfo/yocto>
>
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Custom defconfig is not used
2013/10/18 Bruce Ashfield
> I fell behind today .. i had 2300 unread email to start this morning :)
> Is there a way that I can get a copy of your recipes and layers ? If
> I can do a build myself, I can easily debug and fix this .. otherwise,
> we'll
> go back and forth many times debugging.
>
> Cheers,
>
> Bruce
>
I'm using the environment provided by Angstrom from it's github setup
scripts.
If you want to exactly reproduce it you need to:
git clone https://github.com/Angstrom-distribution/setup-scripts.git
cd setup-scripts
git checkout angstrom-v2013.06-yocto1.4
MACHINE=beaglebone ./oebb.sh config beaglebone
Here is the setup and files for meta-mine:
bblayers.conf:
BBLAYERS = \"
...
${TOPDIR}/sources/meta-mine \
"
meta-mine/conf/layer.conf:
# We have a conf and classes directory, append to BBPATH
BBPATH .= ":${LAYERDIR}"
# We have a recipes directory, add to BBFILES
BBFILES += "${LAYERDIR}/recipes*/*/*.bb ${LAYERDIR}/recipes*/*/*.bbappend"
BBFILE_COLLECTIONS += "mine-layer"
BBFILE_PATTERN_mine-layer := "^${LAYERDIR}/"
BBFILE_PRIORITY_mine-layer = "10"
LAYERDEPENDS_mine-layer = "angstrom-layer"
meta-mine/recipes-kernel/linux/linux-mainline_3.8.bbappend:
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-3.8:"
inherit kernel
require recipes-kernel/linux/linux-yocto.inc
COMPATIBLE_MACHINE_beaglebone = "(beaglebone)"
SRC_URI += " file://config-addons.cfg "
meta-mine/recipes-kernel/linux/linux-mainline-3.8/config-addons.cfg:
CONFIG_WATCHDOG_NOWAYOUT=y
CONFIG_NTFS_FS=y
CONFIG_NTFS_RW=y
But I think that instead of using the whole Angstrom you can just use poky
and meta-beagleboard/common-bsp on dylan branch.
Regards,
--
*dS
Diego Sueiro
/*long live rock 'n roll*/
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Custom defconfig is not used
2013/10/17 Bruce Ashfield
> Look at oe-core/meta-skeleton for the custom kernel recipe example.
> It has the inherit/include combinations that you need to follow.
>
>
> My concern is: if doing this to just have the config fragment feature,
>> I'll possibly mess up the kernel build.
>>
>
> It shouldn't. It only adds to existing phases, and doesn't make
> any changes. I've tested it in many combinations and it should
> work fine.
>
> If something breaks, I'd like to know, so we can fix it.
>
Bruce,
I didn't change linux-mainline_3.8.bb.
My linux-mainline_3.8.bbappend is:
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-3.8:"
inherit kernel
require recipes-kernel/linux/linux-yocto.inc
COMPATIBLE_MACHINE_beaglebone = "(beaglebone)"
SRC_URI += " file://mine.patch \
file://config-addons.cfg \
"
My config-addons.cfg:
CONFIG_WATCHDOG_NOWAYOUT=y
CONFIG_NTFS_FS=y
CONFIG_NTFS_RW=y
After a cleansstate the build got stucked on do_patch task.
Here is the content of log.do_patch:
DEBUG: Executing shell function do_patch
WARNING: no meta data branch found ...
Switched to branch 'linux-3.8.y'
Running with bitbake -v I got the following:
...
+ configme --reconfig --output
<...>/build/tmp-angstrom_v2013_06-eglibc/work/beaglebone-angstrom-linux-gnueabi/linux-mainline/3.8.13-r23a/linux-beaglebone-standard-build
standard beaglebone
[INFO] Configuring target/machine combo: "standard/beaglebone"
[INFO] Configuring target/machine combo: "standard/beaglebone"
[INFO] collecting configs in ./meta/meta-series
[INFO] collecting configs in ./meta/meta-series
cat: meta/cfg/standard/beaglebone/config_frag.txt: No such file or directory
cat: meta/cfg/standard/beaglebone/config_frag.txt: No such file or directory
cat: meta/cfg/standard/beaglebone/config_frag.txt: No such file or directory
cat: meta/cfg/standard/beaglebone/config_frag.txt: No such file or directory
mv: target `3.8.13' is not a directory
mv: target `3.8.13' is not a directory
creation of pre-processed config data failed
config of "standard/beaglebone" failed
creation of pre-processed config data failed
config of "standard/beaglebone" failed
ERROR: Function failed: do_kernel_configme (see
<...>/build/tmp-angstrom_v2013_06-eglibc/work/beaglebone-angstrom-linux-gnueabi/linux-mainline/3.8.13-r23a/temp/log.do_kernel_configme15450.
for further information)
ERROR: Task 7
(<...>/setup-scripts/sources/meta-beagleboard/common-bsp/recipes-kernel/linux/
linux-mainline_3.8.bb, do_kernel_configme) failed with exit code '1'
Regards,
--
*dS
Diego Sueiro
/*long live rock 'n roll*/
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] default root password
2013/10/17 Bryan Evenson > I know there is the EXTRA_USER_PARAMS feature for adding users and > modifying a user's password, but I couldn't get it to work for root. I > tried adding: > > INHERIT += "extrausers" > EXTRA_USERS_PARAMS = "\ > usermod -p '' root; \ > " > > and I would get errors when building the image. I can't remember the > errors I got, but I couldn't get the build to complete when I tried to > modify the root password in this manner. The other way worked so I went > with that. > Bryan, I've tried that too.The issue raised for me was related to INHERIT += "extrausers", as soon as, it is not present on dylan branch. So, I solved that with ROOTFS_POSTPROCESS_COMMAND strategy. Regards, -- *dS Diego Sueiro /*long live rock 'n roll*/ ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Custom defconfig is not used
2013/10/17 Bruce Ashfield > > > I expected to get this working "out-of-box". >> > > Did you do a "bitbake -e " ? and then look at > the SRC_URI ? That will tell us if for some reason the beagle layer's > defconfig is on there twice. I'll do it after my current build gets finished. > > > Why config fragments did not worked too? >> > > recipes must inherit linux-yocto to get that support, since it is > optional and not something we force on all kernel recipes. So if you > want fragment support, creating your own kernel recipe, based on the > one in the layers you are using, which inherits linux-yocto is one > route to take. Can I do it on bbappend, or do I need to copy the entirely linux-mainline_3.8.bb from meta-bleagleboard to my layer and add "inherit linux-yocto"? Do I need to "inherit linux-yocto", "require recipes-kernel/linux/linux-yocto.inc" or "inherit kernel-yocto"? My concern is: if doing this to just have the config fragment feature, I'll possibly mess up the kernel build. Regards, -- *dS Diego Sueiro /*long live rock 'n roll*/ ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] default root password
2013/10/16 David Andrey > Hi, > > There are lot of threads floating around, and a FAQ without answer. > https://wiki.yoctoproject.org/wiki/FAQ:How_do_I_set_or_change_the_root_p > assword > > So what is the official way to set a default root password ? > Using a sed command on /etc/passwd through ROOTFS_POSTPROCESS_COMMAND or > is there any other built-in solution ? > > regards > David > David, Did you find another way to achieve this? -- *dS Diego Sueiro /*long live rock 'n roll*/ > ___ > 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] Custom defconfig is not used
2013/10/17 Bruce Ashfield
> On Wed, Oct 16, 2013 at 2:19 PM, Diego Sueiro
> wrote:
> > Folks,
> >
> > Looking at log.do_unpack it shows:
> >
> > ...
> > NOTE: Unpacking
> >
> <...>/meta-beagleboard/common-bsp/recipes-kernel/linux/linux-mainline-3.8/beaglebone/defconfig
> > to
> >
> <...>/build/tmp-angstrom_v2013_06-eglibc/work/beaglebone-angstrom-linux-gnueabi/linux-mainline/3.8.13-r23a/
> > ...
> >
> > NOTE: Unpacking
> > <...>/meta-mine/recipes-kernel/linux/linux-mainline-3.8/mine.patch to
> >
> <...>/build/tmp-angstrom_v2013_06-eglibc/work/beaglebone-angstrom-linux-gnueabi/linux-mainline/3.8.13-r23a/
> > NOTE: Unpacking
> >
> <...>/meta-beagleboard/common-bsp/recipes-kernel/linux/linux-mainline-3.8/beaglebone/defconfig
> > to
> >
> <...>/build/tmp-angstrom_v2013_06-eglibc/work/beaglebone-angstrom-linux-gnueabi/linux-mainline/3.8.13-r23a/
> >
> >
> > Note that it copies defconfig from meta-beagleboard and in the end,
> instead
> > copying mine, it is copying from meta-beagleboard again.
> >
> > My layer has the priority higher than meta-beagleboard.
>
> I can't get at my machines to test this myself (technically I'm still
> on vacation), but when you
> dump the bitbake environment, how many defconfig's show up in the
> SRC_URI ? It would be
> easy enough in your bbapend to simply call your defconfig something
> else (i.e. defconfig-mine)
> and override/append to kernel_do_configure() to simply copy yours over
> top of the .config,
> regardless of what the fetcher is doing with the SRC_URI.
>
> Bruce
>
>
Bruce,
Putting the following in my recipe did the trick:
do_configure_prepend() {
cp ${WORKDIR}/defconfig-mine ${WORKDIR}/defconfig
}
Now the .config is the same as my custom defconfig.
But, this is a workaround, right?
I expected to get this working "out-of-box".
Why config fragments did not worked too?
--
*dS
Diego Sueiro
/*long live rock 'n roll*/
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Custom defconfig is not used
Folks,
Looking at log.do_unpack it shows:
...
NOTE:
Unpacking
<...>/meta-beagleboard/common-bsp/recipes-kernel/linux/linux-mainline-3.8/beaglebone/defconfig
to
<...>/build/tmp-angstrom_v2013_06-eglibc/work/beaglebone-angstrom-linux-gnueabi/linux-mainline/3.8.13-r23a/
...
NOTE: Unpacking
<...>/meta-mine/recipes-kernel/linux/linux-mainline-3.8/mine.patch to
<...>/build/tmp-angstrom_v2013_06-eglibc/work/beaglebone-angstrom-linux-gnueabi/linux-mainline/3.8.13-r23a/
NOTE:
Unpacking
<...>/meta-beagleboard/common-bsp/recipes-kernel/linux/linux-mainline-3.8/beaglebone/defconfig
to
<...>/build/tmp-angstrom_v2013_06-eglibc/work/beaglebone-angstrom-linux-gnueabi/linux-mainline/3.8.13-r23a/
Note that it copies defconfig from meta-beagleboard and in the end, instead
copying mine, it is copying from meta-beagleboard again.
My layer has the priority higher than meta-beagleboard.
Abraços,
--
*dS
Diego Sueiro
Administrador do Embarcados
www.embarcados.com.br
Engenheiro de Controle e Automação
UNIVERSIDADE FEDERAL DE ITAJUBÀ
/*long live rock 'n roll*/
2013/10/16 Diego Sueiro
> Guys,
>
> As I told before, I already tried the config fragment strategy and it did
> not worked too.
>
> Looking at linux-mailine-3.8.bb from meta-beagleboard[1] it just inherits
> kernel and not inherits linux-yocto or requires linux-yocto.inc. So I
> believe that the config fragment will not work. But I can be wrong.
>
> On directory "meta-mine/recipes-kernel/linux/" I have this:
>
> .
> ├── files
> │ ├── mine.patch
> │ └── defconfig
> └── linux-mainline_3.8.bbappend
>
>
> And my linux-mainline_3.8.bbappend recipe:
>
> FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
> SRC_URI += " file://mine.patch \
> file://defconfig \
> "
>
> The mine.patch is applied but defconfig not.
>
> I've already tried to use another FILESEXTRAPATHS layout like[2],but no
> success too.
>
> How can I have the "bb" command listed on the following link?
> http://www.crashcourse.ca/wiki/index.php/OE_FILESEXTRAPATHS
>
>
> [1] -
>
> https://github.com/beagleboard/meta-beagleboard/blob/dylan/common-bsp/recipes-kernel/linux/linux-mainline_3.8.bb<https://github.com/beagleboard/meta-beagleboard/blob/dylan/common-bsp/recipes-kernel/linux/linux-mainline_3.8.bb>
> [2] -
> http://cgit.openembedded.org/meta-handheld/tree/recipes-kernel/linux/linux-yocto_3.10.bbappend
>
> Regards,
>
> --
> *dS
> Diego Sueiro
>
> /*long live rock 'n roll*/
>
>
> 2013/10/15 Andrea Adami
>
>> Hi,
>>
>> I guess you're setting a wrong FILESEXTRAPATHS_prepend :=
>> "${THISDIR}/files:"
>>
>> See this example, using simple defconfig for some devices and an
>> experimental configuration (WIP ;) fo others using fragments.
>>
>>
>> http://cgit.openembedded.org/meta-handheld/tree/recipes-kernel/linux/linux-yocto_3.10.bbappend
>>
>> Cheers
>>
>> Andrea
>>
>>
>> On Tue, Oct 15, 2013 at 11:49 PM, Rudolf Streif
>> wrote:
>> > Diego,
>> >
>> > You are appending a kernel recipe that uses the Linux Yocto tooling. The
>> > defconfig is essentially comprised of many different pieces from the
>> meta
>> > branch of the Yocto kernel repository and optional configuration
>> fragments
>> > that you provide. This tooling will not recognize a defconfig file you
>> > provide but it does recognize configuration fragments to be added to
>> > .config.
>> >
>> > You need to put
>> >
>> > CONFIG_WATCHDOG_NOWAYOUT=y
>> >
>> > into a file that ends with .cfg eg. watchdog.cfg and then modify your
>> > bbappend to
>> >
>> > FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
>> > SRC_URI += " file://0019-mine.patch \
>> > file://watchdog.cfg \
>> > "
>> >
>> > Rudi
>> >
>> >
>> >
>> > On Tue, Oct 15, 2013 at 2:07 PM, Diego Sueiro
>> > wrote:
>> >>
>> >> Folks,
>> >>
>> >> I created the following bbapend recipe for linux-mainline_3.8.bb (from
>> >> meta-beagleboard on dylan branch) for beaglebone.
>> >> meta-mine/recipes-kernel/linux/linux-mainline_3.8.bbappend:
>> >>
>> >> FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
>> >> SRC_URI += " file://0019-mine.patch \
>> >> file://defconfig \
>> >> "
>> >>
>> >> But t
Re: [yocto] populate_sdk for custom image failed
Folks, Any thoughts? Abraços, -- *dS Diego Sueiro Administrador do Embarcados www.embarcados.com.br Engenheiro de Controle e Automação UNIVERSIDADE FEDERAL DE ITAJUBÀ /*long live rock 'n roll*/ 2013/10/14 Diego Sueiro > Folks, > > I have a custom image in which installs mplayer with IMAGE_INSTALL += > "mplayer". > When I try to generate it's sdk (bitbake mycustom-image -c populate_sdk) > I'm getting the following error: > > | Collected errors: > | * satisfy_dependencies_for: Cannot satisfy the following dependencies > for mplayer2-dev: > | * xpext (= 1.0-5-r0.0) * > | * opkg_install_cmd: Cannot install package mplayer2-dev. > | DEBUG: Python function do_populate_sdk finished > > I've already did a cleansstate on both mplayer and xpext, but the issue > remains. > I'm using dylan branch. > > Any hints? > > Regards, > > -- > *dS > Diego Sueiro > > Administrador do Embarcados > www.embarcados.com.br > > Engenheiro de Controle e Automação > UNIVERSIDADE FEDERAL DE ITAJUBÀ > > /*long live rock 'n roll*/ > ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Custom defconfig is not used
Guys,
As I told before, I already tried the config fragment strategy and it did
not worked too.
Looking at linux-mailine-3.8.bb from meta-beagleboard[1] it just inherits
kernel and not inherits linux-yocto or requires linux-yocto.inc. So I
believe that the config fragment will not work. But I can be wrong.
On directory "meta-mine/recipes-kernel/linux/" I have this:
.
├── files
│ ├── mine.patch
│ └── defconfig
└── linux-mainline_3.8.bbappend
And my linux-mainline_3.8.bbappend recipe:
FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
SRC_URI += " file://mine.patch \
file://defconfig \
"
The mine.patch is applied but defconfig not.
I've already tried to use another FILESEXTRAPATHS layout like[2],but no
success too.
How can I have the "bb" command listed on the following link?
http://www.crashcourse.ca/wiki/index.php/OE_FILESEXTRAPATHS
[1] -
https://github.com/beagleboard/meta-beagleboard/blob/dylan/common-bsp/recipes-kernel/linux/linux-mainline_3.8.bb
[2] -
http://cgit.openembedded.org/meta-handheld/tree/recipes-kernel/linux/linux-yocto_3.10.bbappend
Regards,
--
*dS
Diego Sueiro
/*long live rock 'n roll*/
2013/10/15 Andrea Adami
> Hi,
>
> I guess you're setting a wrong FILESEXTRAPATHS_prepend :=
> "${THISDIR}/files:"
>
> See this example, using simple defconfig for some devices and an
> experimental configuration (WIP ;) fo others using fragments.
>
>
> http://cgit.openembedded.org/meta-handheld/tree/recipes-kernel/linux/linux-yocto_3.10.bbappend
>
> Cheers
>
> Andrea
>
>
> On Tue, Oct 15, 2013 at 11:49 PM, Rudolf Streif
> wrote:
> > Diego,
> >
> > You are appending a kernel recipe that uses the Linux Yocto tooling. The
> > defconfig is essentially comprised of many different pieces from the meta
> > branch of the Yocto kernel repository and optional configuration
> fragments
> > that you provide. This tooling will not recognize a defconfig file you
> > provide but it does recognize configuration fragments to be added to
> > .config.
> >
> > You need to put
> >
> > CONFIG_WATCHDOG_NOWAYOUT=y
> >
> > into a file that ends with .cfg eg. watchdog.cfg and then modify your
> > bbappend to
> >
> > FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
> > SRC_URI += " file://0019-mine.patch \
> > file://watchdog.cfg \
> > "
> >
> > Rudi
> >
> >
> >
> > On Tue, Oct 15, 2013 at 2:07 PM, Diego Sueiro
> > wrote:
> >>
> >> Folks,
> >>
> >> I created the following bbapend recipe for linux-mainline_3.8.bb (from
> >> meta-beagleboard on dylan branch) for beaglebone.
> >> meta-mine/recipes-kernel/linux/linux-mainline_3.8.bbappend:
> >>
> >> FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
> >> SRC_URI += " file://0019-mine.patch \
> >> file://defconfig \
> >> "
> >>
> >> But the defconfig and .config files on ${S} and ${WORKDIR} used are from
> >> meta-beagleboad, not from my bbappend.
> >>
> >> I tried to follow the instructions to add config fragments on the page
> >> below but it did not worked too.
> >>
> >>
> http://www.yoctoproject.org/docs/current/kernel-dev/kernel-dev.html#changing-the-configuration
> >>
> >> The strange thing is: My patch is applied but my defconfig, or config
> >> fragment is not used.
> >> I just want to add CONFIG_WATCHDOG_NOWAYOUT=y.
> >>
> >> I already did a cleasstate but no success.
> >>
> >> Any hints?
> >>
> >>
> >> Regards,
> >>
> >> --
> >> *dS
> >> Diego Sueiro
> >>
> >> /*long live rock 'n roll*/
> >>
> >> ___
> >> 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 mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Custom defconfig is not used
Folks,
I created the following bbapend recipe for linux-mainline_3.8.bb (from
meta-beagleboard on dylan branch) for beaglebone.
meta-mine/recipes-kernel/linux/linux-mainline_3.8.bbappend:
FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
SRC_URI += " file://0019-mine.patch \
file://defconfig \
"
But the defconfig and .config files on ${S} and ${WORKDIR} used are from
meta-beagleboad, not from my bbappend.
I tried to follow the instructions to add config fragments on the page
below but it did not worked too.
http://www.yoctoproject.org/docs/current/kernel-dev/kernel-dev.html#changing-the-configuration
The strange thing is: My patch is applied but my defconfig, or config
fragment is not used.
I just want to add CONFIG_WATCHDOG_NOWAYOUT=y.
I already did a cleasstate but no success.
Any hints?
Regards,
--
*dS
Diego Sueiro
/*long live rock 'n roll*/
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] populate_sdk for custom image failed
Folks, I have a custom image in which installs mplayer with IMAGE_INSTALL += "mplayer". When I try to generate it's sdk (bitbake mycustom-image -c populate_sdk) I'm getting the following error: | Collected errors: | * satisfy_dependencies_for: Cannot satisfy the following dependencies for mplayer2-dev: | * xpext (= 1.0-5-r0.0) * | * opkg_install_cmd: Cannot install package mplayer2-dev. | DEBUG: Python function do_populate_sdk finished I've already did a cleansstate on both mplayer and xpext, but the issue remains. I'm using dylan branch. Any hints? Regards, -- *dS Diego Sueiro Administrador do Embarcados www.embarcados.com.br Engenheiro de Controle e Automação UNIVERSIDADE FEDERAL DE ITAJUBÀ /*long live rock 'n roll*/ ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Kernel module
Dilip, You can take a look at this example : http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta-skeleton/recipes-kernel/hello-mod -- *dS Diego Sueiro sent from my droid tablet. On Oct 11, 2013 11:17 PM, "Dilip Kumar" <008di...@gmail.com> wrote: > Hi, > What all the modifications has to be done and steps to follow for adding > external kernel module into the linux-yocto and checking that in qemulator. > > regards > dilip > > ___ > 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] meta-toolchain-qt with Qt Creator
2013/10/7 Laurentiu Palcu > Hi Diego, > It's a little more complicated than that. After building the toolchain, > all binaries have the default absolute path to the dynamic loader > (/opt/poky/...) hardcoded in the elf INTERP section. This is easy to > change. However, other binaries may or may not have other hardcoded > paths to search for different things (like configs, etc.). Most of these > could be easily fixed by providing the binary with an option or setting > an environment variable to instruct it where to find what it needs. Take > for example the gcc --sysroot option. By default gcc will search for the > sysroot in the default location (starting with /opt/poky), but providing > a --sysroot option, we override this default path. > > So, even though, for relocation, changing the INTERP section may suffice > for most of the binaries, some may need more tweaking. > > A quick search on google brought me to this page: > http://qt-project.org/doc/qt-4.8/qmake-environment-reference.html > > It turns out that QMAKESPEC environment variable is what QT creator > looks at to be able to locate qmake.conf. So, perhaps, we need to add > this to the environment file and the problem should be fixed... > > Can you please test this? > > Thanks, > Laurentiu > > Laurentiu, Thanks for the explanation. I took a look at environment-setup-armv7a-vfp-neon-poky-linux-gnueabi file and it is already exporting the QMAKESPEC variable to the right path. Maybe this variable is overridden by another one or by Qt Creator based on some INTERP. I did a "grep -r \/poky\/1\.4\.2 ./*" on the toolchain (installed outside default path) and this is the results: http://pastebin.com/us9p5vVp Unfortunately I don't have enough knowledge to track this. Regards, -- *dS Diego Sueiro ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] meta-toolchain-qt with Qt Creator
Folks, I've found the issue. I was installing the poky toolchain outside the default path (/opt/opky/1.4.2). After installing on default path, Qt creator was enable to find the right QT version. I compiled an example and loaded it on board without any issues. I discovered it before seeing an warning message from Qt creator saying that it could not find the qmake.conf on /opt/opky/1.4.2/<...>/usr/mkspec/default/qmake.conf. Lesson learned: don't change the default toolchain insatallation path, otherwise something will not work properly. Can someone explain this behavior? Since you can choose a path to install the toolchain it must have to work out of the box. Abraços, -- *dS Diego Sueiro Administrador do Embarcados www.embarcados.com.br Engenheiro de Controle e Automação UNIVERSIDADE FEDERAL DE ITAJUBÀ /*long live rock 'n roll*/ 2013/10/4 Diego Sueiro > Hello >> Yocto dylan+ meta-toolchain-qt as Joerg's document says. >> Best regards > > > Jose, > > I'm a little bit confused. > Did you compiled qt-everywhere-opensource-src-4.8.4 for your host machine > and added it's qmake to Qt creator? > Then add yocto sysroot, gdb and gcc to Qt creator? > Could you please pont me step-by-step how did you get it working? > > If add Yocto's qmake toolchain on Qt Creator I get the version error. > > DIego Sueiro > > 2013/10/4 Jose Mª Ferreiro > >> >> El 04/10/2013 16:30, Diego Sueiro escribió: >> >> 2013/10/4 Jose Mª Ferreiro >> >>> Hello Diego >>> >>> We have had success doing a mix from these documents: >>> - install host qt libraries: >>> http://qt-project.org/doc/qt-4.8/install-x11.html >>> - install host qt creator: >>> http://labs.isee.biz/index.php/How_to_install_Qt_Creator#Configure_Yocto_SDK >>> - yocto steps: https://community.freescale.com/thread/309578 , >>> >>> on a imx6Q Sabe Lite board being the host an Ubuntu 12.04. >>> >>> Good luck >>> >> >> Jose, >> >> Thanks for the info. >> >> Which poky branch/version are you using? >> Did you use the meta-toolchain from poky or the arm gcc from Ubuntu? >> >> >> Hello >> >> Yocto dylan+ meta-toolchain-qt as Joerg's document says. >> >> Best regards >> >> Regards, >> >> -- >> *dS >> Diego Sueiro >> >> >> >>> >>> >>> El 04/10/2013 14:45, Diego Sueiro escribió: >>> >>> Folks, >>> >>> After a lots of internet search, including this ML threads, i did not >>> find any solution for this. >>> >>> I'm having issues to integrate meta-toolchain-qt >>> and meta-toolchain-qte with Qt Creator 2.8.1. >>> I'm using this environment: >>> >>> Build Configuration: >>> BB_VERSION= "1.18.0" >>> BUILD_SYS = "x86_64-linux" >>> NATIVELSBSTRING = "Ubuntu-12.10" >>> TARGET_SYS= "arm-poky-linux-gnueabi" >>> MACHINE = "beaglebone" >>> DISTRO= "poky" >>> DISTRO_VERSION= "1.4.2" >>> TUNE_FEATURES = "armv7a vfp neon" >>> TARGET_FPU= "vfp-neon" >>> meta >>> meta-yocto >>> meta-yocto-bsp= "dylan:560fa9ad8dd46f23cff7a2e88a3492c363314b29" >>> meta-ti = "dylan:24edd661d5e8fce3689bdd2c89e0105af8080152" >>> >>> >>> When I configure the qmake path on Qt Creator I get the following >>> message: >>> >>> "Qt version is not properly installed please run make install" >>> >>> >>> I've tried on dylan branch too, but no success. >>> >>> So, I tried to use Angstrom's setup-scripts >>> on angstrom-v2013.06-yocto1.4 branch. And it came with the issue related >>> with "error while loading shared libraries: __vdso_time: invalid mode >>> for dlopen(): Invalid argument". So, I switched to Fedora 19 and it has >>> gone, but the invalid Qt version problem remains. >>> >>> I tried, without success, to compile by myself the >>> qt-everywhere-opensource-src-4.8 >>> these toolchains: >>> >>> angstrom-eglibc-x86_64-cortexa8hf-vfp-neon-toolchain-qte-v2013.06 >>> poky-eglibc-x86_64-arm-toolchain-qte-1.4.2 >>> >>> >>> If someone could successfully use meta-toolchain-qte with Qt Creator, >>> please point me the right directions to achieve this. >>> >>> I really need some help to get a qt4-embedded toolchain working. >>> >>> Kind Regards, >>> >>> -- >>> *dS >>> Diego Sueiro >>> >>> /*long live rock 'n roll*/ >>> >>> >>> ___ >>> yocto mailing >>> listyocto@yoctoproject.orghttps://lists.yoctoproject.org/listinfo/yocto >>> >>> >>> >>> ___ >>> 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 mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] meta-toolchain-qt with Qt Creator
> > Hello > Yocto dylan+ meta-toolchain-qt as Joerg's document says. > Best regards Jose, I'm a little bit confused. Did you compiled qt-everywhere-opensource-src-4.8.4 for your host machine and added it's qmake to Qt creator? Then add yocto sysroot, gdb and gcc to Qt creator? Could you please pont me step-by-step how did you get it working? If add Yocto's qmake toolchain on Qt Creator I get the version error. DIego Sueiro 2013/10/4 Jose Mª Ferreiro > > El 04/10/2013 16:30, Diego Sueiro escribió: > > 2013/10/4 Jose Mª Ferreiro > >> Hello Diego >> >> We have had success doing a mix from these documents: >> - install host qt libraries: >> http://qt-project.org/doc/qt-4.8/install-x11.html >> - install host qt creator: >> http://labs.isee.biz/index.php/How_to_install_Qt_Creator#Configure_Yocto_SDK >> - yocto steps: https://community.freescale.com/thread/309578 , >> >> on a imx6Q Sabe Lite board being the host an Ubuntu 12.04. >> >> Good luck >> > > Jose, > > Thanks for the info. > > Which poky branch/version are you using? > Did you use the meta-toolchain from poky or the arm gcc from Ubuntu? > > > Hello > > Yocto dylan+ meta-toolchain-qt as Joerg's document says. > > Best regards > > Regards, > > -- > *dS > Diego Sueiro > > > >> >> >> El 04/10/2013 14:45, Diego Sueiro escribió: >> >> Folks, >> >> After a lots of internet search, including this ML threads, i did not >> find any solution for this. >> >> I'm having issues to integrate meta-toolchain-qt and meta-toolchain-qte >> with Qt Creator 2.8.1. >> I'm using this environment: >> >> Build Configuration: >> BB_VERSION= "1.18.0" >> BUILD_SYS = "x86_64-linux" >> NATIVELSBSTRING = "Ubuntu-12.10" >> TARGET_SYS= "arm-poky-linux-gnueabi" >> MACHINE = "beaglebone" >> DISTRO= "poky" >> DISTRO_VERSION= "1.4.2" >> TUNE_FEATURES = "armv7a vfp neon" >> TARGET_FPU= "vfp-neon" >> meta >> meta-yocto >> meta-yocto-bsp= "dylan:560fa9ad8dd46f23cff7a2e88a3492c363314b29" >> meta-ti = "dylan:24edd661d5e8fce3689bdd2c89e0105af8080152" >> >> >> When I configure the qmake path on Qt Creator I get the following >> message: >> >> "Qt version is not properly installed please run make install" >> >> >> I've tried on dylan branch too, but no success. >> >> So, I tried to use Angstrom's setup-scripts >> on angstrom-v2013.06-yocto1.4 branch. And it came with the issue related >> with "error while loading shared libraries: __vdso_time: invalid mode >> for dlopen(): Invalid argument". So, I switched to Fedora 19 and it has >> gone, but the invalid Qt version problem remains. >> >> I tried, without success, to compile by myself the >> qt-everywhere-opensource-src-4.8 >> these toolchains: >> >> angstrom-eglibc-x86_64-cortexa8hf-vfp-neon-toolchain-qte-v2013.06 >> poky-eglibc-x86_64-arm-toolchain-qte-1.4.2 >> >> >> If someone could successfully use meta-toolchain-qte with Qt Creator, >> please point me the right directions to achieve this. >> >> I really need some help to get a qt4-embedded toolchain working. >> >> Kind Regards, >> >> -- >> *dS >> Diego Sueiro >> >> /*long live rock 'n roll*/ >> >> >> ___ >> yocto mailing >> listyocto@yoctoproject.orghttps://lists.yoctoproject.org/listinfo/yocto >> >> >> >> ___ >> 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 mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] meta-toolchain-qt with Qt Creator
2013/10/4 Jose Mª Ferreiro > Hello Diego > > We have had success doing a mix from these documents: > - install host qt libraries: > http://qt-project.org/doc/qt-4.8/install-x11.html > - install host qt creator: > http://labs.isee.biz/index.php/How_to_install_Qt_Creator#Configure_Yocto_SDK > - yocto steps: https://community.freescale.com/thread/309578 , > > on a imx6Q Sabe Lite board being the host an Ubuntu 12.04. > > Good luck > Jose, Thanks for the info. Which poky branch/version are you using? Did you use the meta-toolchain from poky or the arm gcc from Ubuntu? Regards, -- *dS Diego Sueiro > > > El 04/10/2013 14:45, Diego Sueiro escribió: > > Folks, > > After a lots of internet search, including this ML threads, i did not > find any solution for this. > > I'm having issues to integrate meta-toolchain-qt and meta-toolchain-qte > with Qt Creator 2.8.1. > I'm using this environment: > > Build Configuration: > BB_VERSION= "1.18.0" > BUILD_SYS = "x86_64-linux" > NATIVELSBSTRING = "Ubuntu-12.10" > TARGET_SYS= "arm-poky-linux-gnueabi" > MACHINE = "beaglebone" > DISTRO= "poky" > DISTRO_VERSION= "1.4.2" > TUNE_FEATURES = "armv7a vfp neon" > TARGET_FPU= "vfp-neon" > meta > meta-yocto > meta-yocto-bsp= "dylan:560fa9ad8dd46f23cff7a2e88a3492c363314b29" > meta-ti = "dylan:24edd661d5e8fce3689bdd2c89e0105af8080152" > > > When I configure the qmake path on Qt Creator I get the following > message: > > "Qt version is not properly installed please run make install" > > > I've tried on dylan branch too, but no success. > > So, I tried to use Angstrom's setup-scripts > on angstrom-v2013.06-yocto1.4 branch. And it came with the issue related > with "error while loading shared libraries: __vdso_time: invalid mode for > dlopen(): Invalid argument". So, I switched to Fedora 19 and it has gone, > but the invalid Qt version problem remains. > > I tried, without success, to compile by myself the > qt-everywhere-opensource-src-4.8 > these toolchains: > > angstrom-eglibc-x86_64-cortexa8hf-vfp-neon-toolchain-qte-v2013.06 > poky-eglibc-x86_64-arm-toolchain-qte-1.4.2 > > > If someone could successfully use meta-toolchain-qte with Qt Creator, > please point me the right directions to achieve this. > > I really need some help to get a qt4-embedded toolchain working. > > Kind Regards, > > -- > *dS > Diego Sueiro > > /*long live rock 'n roll*/ > > > ___ > yocto mailing > listyocto@yoctoproject.orghttps://lists.yoctoproject.org/listinfo/yocto > > > > ___ > 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] meta-toolchain-qt with Qt Creator
Folks, After a lots of internet search, including this ML threads, i did not find any solution for this. I'm having issues to integrate meta-toolchain-qt and meta-toolchain-qte with Qt Creator 2.8.1. I'm using this environment: Build Configuration: BB_VERSION= "1.18.0" BUILD_SYS = "x86_64-linux" NATIVELSBSTRING = "Ubuntu-12.10" TARGET_SYS= "arm-poky-linux-gnueabi" MACHINE = "beaglebone" DISTRO= "poky" DISTRO_VERSION= "1.4.2" TUNE_FEATURES = "armv7a vfp neon" TARGET_FPU= "vfp-neon" meta meta-yocto meta-yocto-bsp= "dylan:560fa9ad8dd46f23cff7a2e88a3492c363314b29" meta-ti = "dylan:24edd661d5e8fce3689bdd2c89e0105af8080152" When I configure the qmake path on Qt Creator I get the following message: "Qt version is not properly installed please run make install" I've tried on dylan branch too, but no success. So, I tried to use Angstrom's setup-scripts on angstrom-v2013.06-yocto1.4 branch. And it came with the issue related with "error while loading shared libraries: __vdso_time: invalid mode for dlopen(): Invalid argument". So, I switched to Fedora 19 and it has gone, but the invalid Qt version problem remains. I tried, without success, to compile by myself the qt-everywhere-opensource-src-4.8 these toolchains: angstrom-eglibc-x86_64-cortexa8hf-vfp-neon-toolchain-qte-v2013.06 poky-eglibc-x86_64-arm-toolchain-qte-1.4.2 If someone could successfully use meta-toolchain-qte with Qt Creator, please point me the right directions to achieve this. I really need some help to get a qt4-embedded toolchain working. Kind Regards, -- *dS Diego Sueiro /*long live rock 'n roll*/ ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Issues on booting cedartrail image
2013/9/29 Diego Sueiro > > Folks, > > Serial console issue solved. On this board the DB9 connector is mapped on > ttyS1. > > But I can't still get logged on system with images generated with > meta-cedartrail on danny branch. > > Any hint about udev reported error? > > Folks, I'm really sorry about the buzz. The solution for udev issue was in this thread: https://lists.yoctoproject.org/pipermail/yocto/2012-December/013262.html Now the system is booting. Regards, -- *dS Diego Sueiro Administrador do Embarcados www.embarcados.com.br Engenheiro de Controle e Automação UNIVERSIDADE FEDERAL DE ITAJUBÀ /*long live rock 'n roll*/ ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Issues on booting cedartrail image
2013/9/29 Diego Sueiro
> 2013/9/28 Sean Liming
>
>> Do you have a serial connections between the D2550 system and your host
>> PC?
>>
>> ** **
>>
>> There is an install for USB to HDD installation. The serial connection is
>> needed to see the console output selection. Modify either the grub.cfg or
>> syslinux.cfg and change the default to “install”
>>
>> ** **
>>
>> Regards,
>>
>> ** **
>>
>> Sean Liming
>>
>> Owner
>>
>> [image: ablogo color - 500] <http://www.annabooks.com/>
>>
>> Tel: 714-970-7523 / Cell: 858-774-3176
>>
>> **
>>
> Just a correction I'm using D2500 processor with NM10 Express Chip and
> this motherboard:
>
> http://www.intel.com/content/www/us/en/motherboards/desktop-motherboards/desktop-board-d2500hn.html
>
> I'm sorry about the wrong info sent before.
>
> Sean,
>
> Yes, the serial cable is connected between motherboard and the host PC. I
> can get syslinux output from serial console.
>
> Changing "boot" to "install" doesn't resolved the issue. I believe that is
> something wrong with rootfs since init claims about "udevd: not found".
> Here is my syslinux.cfg:
>
> # Automatically created by OE
> serial 0 115200
> ALLOWOPTIONS 1
> DEFAULT install
> TIMEOUT 10
> PROMPT 1
> LABEL boot
> KERNEL /vmlinuz
> APPEND initrd=/initrd LABEL=boot root=/dev/ram0 console=ttyS0,115200
> console=tty0 video=LVDS-1:d video=VGA-1:e
> LABEL install
> KERNEL /vmlinuz
> APPEND initrd=/initrd LABEL=install root=/dev/ram0 console=ttyS0,115200
> console=tty0 video=LVDS-1:d video=VGA-1:e
>
>
> Here is my grub.cfg:
>
> # Automatically created by OE
> serial --unit=0 --speed=115200 --word=8 --parity=no --stop=1
> default=install
> timeout=10
>
> menuentry 'boot'{
> linux /vmlinuz LABEL=boot root=/dev/ram0 console=ttyS0,115200
> console=tty0 video=LVDS-1:d video=VGA-1:e
> initrd /initrd
> }
>
> menuentry 'install'{
> linux /vmlinuz LABEL=install-efi root=/dev/ram0 console=ttyS0,115200
> console=tty0 video=LVDS-1:d video=VGA-1:e
> initrd /initrd
> }
>
>
>
> Using poky dylan branch and meta-ti-contrib with cdt-vesa machine I can
> boot a core-image-minimal and get logged in just on display. There is
> nothing on serial console after syslinux.
>
>
>
>
Folks,
Serial console issue solved. On this board the DB9 connector is mapped on
ttyS1.
But I can't still get logged on system with images generated with
meta-cedartrail on danny branch.
Any hint about udev reported error?
Regards,
--
*dS
Diego Sueiro
Administrador do Embarcados
www.embarcados.com.br
Engenheiro de Controle e Automação
UNIVERSIDADE FEDERAL DE ITAJUBÀ
/*long live rock 'n roll*/
>
>
>> **
>>
>> *From:* yocto-boun...@yoctoproject.org [mailto:
>> yocto-boun...@yoctoproject.org] *On Behalf Of *Diego Sueiro
>> *Sent:* Saturday, September 28, 2013 4:40 PM
>> *To:* yocto@yoctoproject.org
>> *Subject:* [yocto] Issues on booting cedartrail image
>>
>> ** **
>>
>> Folks,
>>
>> ** **
>>
>> I'm having troubles to boot a cedartrail image. I tried both
>> core-image-minimal and core-image-cdv-media-cedartrail. I tried to boot
>> from USB drive and hard disk.
>>
>> I'm using this hardware:
>> http://www.intel.com/content/www/us/en/motherboards/desktop-motherboards/desktop-board-d2550mud2.html
>>
>>
>> ** **
>>
>> I've followed the instructions from:
>>
>>
>> http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel/tree/meta-cedartrail/README?h=danny
>>
>>
>>
>> https://wiki.yoctoproject.org/wiki/How_do_I#Q:_How_do_I_put_Yocto_on_a_hard_drive.3F
>>
>>
>> ** **
>>
>> For core-image-minimal
>>
>> Syslinux console output:
>>
>> SYSLINUX 4.03 2010-10-22 Copyright (C) 1994-2010 H. Peter Anvin et al***
>> *
>>
>> boot:
>>
>> Loading /vmlinuz...
>>
>> Loading /initrd.ready.
>>
>> ** **
>>
>> Syslinux display outuput (VGA):
>>
>> SYSLINUX 4.03 2010-10-22 Copyright (C) 1994-2010 H. Peter Anvin et al***
>> *
>>
>> boot:
>>
>> Loading /vmlinuz...
>>
>> Loading /initrd.ready.
>>
>> ** **
>>
>> Decompressing Linux... Parsing ELF... done.
>>
>> Booting the kernel.
>>
>> ** **
>>
>> B
Re: [yocto] Issues on booting cedartrail image
2013/9/28 Sean Liming
> Do you have a serial connections between the D2550 system and your host PC?
>
>
> ** **
>
> There is an install for USB to HDD installation. The serial connection is
> needed to see the console output selection. Modify either the grub.cfg or
> syslinux.cfg and change the default to “install”
>
> ** **
>
> Regards,
>
> ** **
>
> Sean Liming
>
> Owner
>
> [image: ablogo color - 500] <http://www.annabooks.com/>
>
> Tel: 714-970-7523 / Cell: 858-774-3176
>
> **
>
Just a correction I'm using D2500 processor with NM10 Express Chip and this
motherboard:
http://www.intel.com/content/www/us/en/motherboards/desktop-motherboards/desktop-board-d2500hn.html
I'm sorry about the wrong info sent before.
Sean,
Yes, the serial cable is connected between motherboard and the host PC. I
can get syslinux output from serial console.
Changing "boot" to "install" doesn't resolved the issue. I believe that is
something wrong with rootfs since init claims about "udevd: not found".
Here is my syslinux.cfg:
# Automatically created by OE
serial 0 115200
ALLOWOPTIONS 1
DEFAULT install
TIMEOUT 10
PROMPT 1
LABEL boot
KERNEL /vmlinuz
APPEND initrd=/initrd LABEL=boot root=/dev/ram0 console=ttyS0,115200
console=tty0 video=LVDS-1:d video=VGA-1:e
LABEL install
KERNEL /vmlinuz
APPEND initrd=/initrd LABEL=install root=/dev/ram0 console=ttyS0,115200
console=tty0 video=LVDS-1:d video=VGA-1:e
Here is my grub.cfg:
# Automatically created by OE
serial --unit=0 --speed=115200 --word=8 --parity=no --stop=1
default=install
timeout=10
menuentry 'boot'{
linux /vmlinuz LABEL=boot root=/dev/ram0 console=ttyS0,115200
console=tty0 video=LVDS-1:d video=VGA-1:e
initrd /initrd
}
menuentry 'install'{
linux /vmlinuz LABEL=install-efi root=/dev/ram0 console=ttyS0,115200
console=tty0 video=LVDS-1:d video=VGA-1:e
initrd /initrd
}
Using poky dylan branch and meta-ti-contrib with cdt-vesa machine I can
boot a core-image-minimal and get logged in just on display. There is
nothing on serial console after syslinux.
Regards,
--
*dS
Diego Sueiro
Administrador do Embarcados
www.embarcados.com.br
Engenheiro de Controle e Automação
UNIVERSIDADE FEDERAL DE ITAJUBÀ
/*long live rock 'n roll*/
> **
>
> *From:* yocto-boun...@yoctoproject.org [mailto:
> yocto-boun...@yoctoproject.org] *On Behalf Of *Diego Sueiro
> *Sent:* Saturday, September 28, 2013 4:40 PM
> *To:* yocto@yoctoproject.org
> *Subject:* [yocto] Issues on booting cedartrail image
>
> ** **
>
> Folks,
>
> ** **
>
> I'm having troubles to boot a cedartrail image. I tried both
> core-image-minimal and core-image-cdv-media-cedartrail. I tried to boot
> from USB drive and hard disk.
>
> I'm using this hardware:
> http://www.intel.com/content/www/us/en/motherboards/desktop-motherboards/desktop-board-d2550mud2.html
>
>
> ** **
>
> I've followed the instructions from:
>
>
> http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel/tree/meta-cedartrail/README?h=danny
>
>
>
> https://wiki.yoctoproject.org/wiki/How_do_I#Q:_How_do_I_put_Yocto_on_a_hard_drive.3F
>
>
> ** **
>
> For core-image-minimal
>
> Syslinux console output:
>
> SYSLINUX 4.03 2010-10-22 Copyright (C) 1994-2010 H. Peter Anvin et al
>
> boot:
>
> Loading /vmlinuz...
>
> Loading /initrd.ready.
>
> ** **
>
> Syslinux display outuput (VGA):
>
> SYSLINUX 4.03 2010-10-22 Copyright (C) 1994-2010 H. Peter Anvin et al
>
> boot:
>
> Loading /vmlinuz...
>
> Loading /initrd.ready.
>
> ** **
>
> Decompressing Linux... Parsing ELF... done.
>
> Booting the kernel.
>
> ** **
>
> But I cannot see any kernel or system prints after that.
>
> ** **
>
> For core-image-cdv-media
>
> Syslinux console output:
>
> SYSLINUX 4.03 2010-10-22 Copyright (C9 1994-2010 H. Peter Anvin et al
>
> boot:
>
> Loading /vmlinuz...
>
> Load�ng /initrd.ready.
>
> ** **
>
> For syslinux display outuput (VGA) it prints kernel boot end the last 3
> lines are:
>
> Freeing unusued kernel memory: 500k freed
>
> /init: line 69: udevd: not found
>
> Waiting for removable media
>
> ** **
>
> ** **
>
> With GRUB method (second link above) nothing appears on console and
> display for both images.
>
> ** **
>
> Here is my build environment:
>
> Build Configuration:
>
> BB_VERSION= "1.16.0"
>
> TARGET_ARCH = "i586"
>
&
[yocto] Issues on booting cedartrail image
Folks, I'm having troubles to boot a cedartrail image. I tried both core-image-minimal and core-image-cdv-media-cedartrail. I tried to boot from USB drive and hard disk. I'm using this hardware: http://www.intel.com/content/www/us/en/motherboards/desktop-motherboards/desktop-board-d2550mud2.html I've followed the instructions from: http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel/tree/meta-cedartrail/README?h=danny https://wiki.yoctoproject.org/wiki/How_do_I#Q:_How_do_I_put_Yocto_on_a_hard_drive.3F For core-image-minimal Syslinux console output: SYSLINUX 4.03 2010-10-22 Copyright (C) 1994-2010 H. Peter Anvin et al boot: Loading /vmlinuz... Loading /initrd.ready. Syslinux display outuput (VGA): SYSLINUX 4.03 2010-10-22 Copyright (C) 1994-2010 H. Peter Anvin et al boot: Loading /vmlinuz... Loading /initrd.ready. Decompressing Linux... Parsing ELF... done. Booting the kernel. But I cannot see any kernel or system prints after that. For core-image-cdv-media Syslinux console output: SYSLINUX 4.03 2010-10-22 Copyright (C9 1994-2010 H. Peter Anvin et al boot: Loading /vmlinuz... Load�ng /initrd.ready. For syslinux display outuput (VGA) it prints kernel boot end the last 3 lines are: Freeing unusued kernel memory: 500k freed /init: line 69: udevd: not found Waiting for removable media With GRUB method (second link above) nothing appears on console and display for both images. Here is my build environment: Build Configuration: BB_VERSION= "1.16.0" TARGET_ARCH = "i586" TARGET_OS = "linux" MACHINE = "cedartrail" DISTRO= "poky" DISTRO_VERSION= "1.3.2" TUNE_FEATURES = "m32 core2" TARGET_FPU= "" meta meta-yocto meta-yocto-bsp= "danny:70ca9ff6422a03c26cfa78e76f6334bcf3fe47ec" meta-intel meta-cedartrail = "danny:cc42fb6ec5900ad9f034014c3ddce04223908608" meta-oe = "danny:f00028caf257e386c0f3ae46bd4b3ba53dd0729d" meta-videofone= "danny:70ca9ff6422a03c26cfa78e76f6334bcf3fe47ec" Someone has some tips? Kind regards, -- *dS Diego Sueiro Administrador do Embarcados www.embarcados.com.br Engenheiro de Controle e Automação UNIVERSIDADE FEDERAL DE ITAJUBÀ /*long live rock 'n roll*/ ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Adding machine for linux-yocto-stable
Bruce, linux-libc-headers-yocto issue solved after yocto update. Now, I'm waiting for linux-yocto-stable. Regards, -- *dS Diego Sueiro /*long live rock 'n roll*/ On Tue, Feb 8, 2011 at 4:04 PM, Diego Sueiro wrote: > Bruce, > > I'm getting this error for linux-libc-headers-yocto too. > > > ERROR: Function 'opkg-build execution failed' failed > ERROR: Logfile of failure stored in: > /home/dev-2/yocto/build/tmp/work/armv7a-poky-linux-gnueabi/linux-libc-headers-yocto-2.6.37+git-4+343c06b25b221aa7f7019aee83b2d976041fddce_2+yocto/standard/base-r2/temp/log.do_package_write_ipk.16387 > Log data follows: > | ar: > /home/dev-2/yocto/build/tmp/work/armv7a-poky-linux-gnueabi/linux-libc-headers-yocto-2.6.37+git-4+343c06b25b221aa7f7019aee83b2d976041fddce_2+yocto/standard/base-r2/deploy-ipks/armv7a/linux-libc-headers-yocto-dbg_2.6.37+git-4+343c06b25b221aa7f7019aee83b2d976041fddce_2+yocto/standard/base-r2_armv7a.ipk: > No such file or directory > | ERROR: Function 'opkg-build execution failed' failed > NOTE: package > linux-libc-headers-yocto-2.6.37+git-4+343c06b25b221aa7f7019aee83b2d976041fddce_2+yocto/standard/base-r2: > task opkg-build execution failed: Failed > ERROR: Task 547 > (/home/dev-2/yocto/poky/meta/recipes-kernel/linux-libc-headers/ > linux-libc-headers-yocto_git.bb, do_package_write_ipk) failed with exit > code '1' > > > Regards, > > -- > *dS > Diego Sueiro > > /*long live rock 'n roll*/ > > > On Tue, Feb 8, 2011 at 3:38 PM, Bruce Ashfield < > bruce.ashfi...@windriver.com> wrote: > >> On 11-02-08 12:31 PM, Diego Sueiro wrote: >> >>> Bruce, >>> >>> I've updated my yocto tree but I'm still getting this error: >>> >>> ERROR: Function 'do_kernel_checkout' failed (see >>> >>> /home/dev-2/yocto/build/tmp/work/bw-b600-poky-linux-gnueabi/linux-yocto-stable-2.6.34+git1+e1f85a470934a0cf6abde5d95533e74501822c6b_6+72ca49ab08b8eb475cec82a10049503602325791-r1/temp/log.do_kernel_checkout.26330 >>> for further information) >>> ERROR: Logfile of failure stored in: >>> >>> /home/dev-2/yocto/build/tmp/work/bw-b600-poky-linux-gnueabi/linux-yocto-stable-2.6.34+git1+e1f85a470934a0cf6abde5d95533e74501822c6b_6+72ca49ab08b8eb475cec82a10049503602325791-r1/temp/log.do_kernel_checkout.26330 >>> Log data follows: >>> | Fixing up git directory for standard/devkit8000 >>> | error: pathspec 'devkit8000-standard' did not match any file(s) known >>> to git. >>> | ERROR: Function 'do_kernel_checkout' failed (see >>> >>> /home/dev-2/yocto/build/tmp/work/bw-b600-poky-linux-gnueabi/linux-yocto-stable-2.6.34+git1+e1f85a470934a0cf6abde5d95533e74501822c6b_6+72ca49ab08b8eb475cec82a10049503602325791-r1/temp/log.do_kernel_checkout.26330 >>> for further information) >>> NOTE: package >>> >>> linux-yocto-stable-2.6.34+git1+e1f85a470934a0cf6abde5d95533e74501822c6b_6+72ca49ab08b8eb475cec82a10049503602325791-r1: >>> task do_kernel_checkout: Failed >>> ERROR: Task 1 >>> (/home/dev-2/yocto/poky/meta-boardware/recipes-kernel/linux/ >>> linux-yocto-stable_git.bb >>> <http://linux-yocto-stable_git.bb>, do_kernel_checkout) failed with exit >>> code '1' >>> >> >> This is the typical BSP bootstrap 'problem'. Hold on for >> just a little while longer, with the new fetcher changes >> in master, I'm updating the recipes (literally now) to >> fix this and am testing the workflow for adding a new board >> as part of these changes. >> >> Cheers, >> >> Bruce >> >> >>> I've tried this two options on >>> SRCREV_machine_pn-linux-yocto-stable_devkit8000: >>> >>>"ef7f944e773950d4016b7643f9ecf052bbe250cd" = beagleboard-standard >>> branch >>>"2b1caf6ed7b888c95a1909d343799672731651a5" = master branch >>>"72ca49ab08b8eb475cec82a10049503602325791" = standard branch >>> >>> >>> There isn't an specific devki8000 branch. >>> >>> Regards, >>> >>> -- >>> *dS >>> Diego Sueiro >>> >>> /*long live rock 'n roll*/ >>> >>> >>> On Tue, Feb 8, 2011 at 12:11 PM, Bruce Ashfield >>> mailto:bruce.ashfi...@windriver.com>> >>> wrote: >>> >>>On 11-02-08 08:46 AM, Diego Sueiro wrote: >>> >>>Folks, >>> >>>I'm trying to get devkit8000 kernel compiled with >>>l
Re: [yocto] Adding machine for linux-yocto-stable
Bruce, I'm getting this error for linux-libc-headers-yocto too. ERROR: Function 'opkg-build execution failed' failed ERROR: Logfile of failure stored in: /home/dev-2/yocto/build/tmp/work/armv7a-poky-linux-gnueabi/linux-libc-headers-yocto-2.6.37+git-4+343c06b25b221aa7f7019aee83b2d976041fddce_2+yocto/standard/base-r2/temp/log.do_package_write_ipk.16387 Log data follows: | ar: /home/dev-2/yocto/build/tmp/work/armv7a-poky-linux-gnueabi/linux-libc-headers-yocto-2.6.37+git-4+343c06b25b221aa7f7019aee83b2d976041fddce_2+yocto/standard/base-r2/deploy-ipks/armv7a/linux-libc-headers-yocto-dbg_2.6.37+git-4+343c06b25b221aa7f7019aee83b2d976041fddce_2+yocto/standard/base-r2_armv7a.ipk: No such file or directory | ERROR: Function 'opkg-build execution failed' failed NOTE: package linux-libc-headers-yocto-2.6.37+git-4+343c06b25b221aa7f7019aee83b2d976041fddce_2+yocto/standard/base-r2: task opkg-build execution failed: Failed ERROR: Task 547 (/home/dev-2/yocto/poky/meta/recipes-kernel/linux-libc-headers/ linux-libc-headers-yocto_git.bb, do_package_write_ipk) failed with exit code '1' Regards, -- *dS Diego Sueiro /*long live rock 'n roll*/ On Tue, Feb 8, 2011 at 3:38 PM, Bruce Ashfield wrote: > On 11-02-08 12:31 PM, Diego Sueiro wrote: > >> Bruce, >> >> I've updated my yocto tree but I'm still getting this error: >> >> ERROR: Function 'do_kernel_checkout' failed (see >> >> /home/dev-2/yocto/build/tmp/work/bw-b600-poky-linux-gnueabi/linux-yocto-stable-2.6.34+git1+e1f85a470934a0cf6abde5d95533e74501822c6b_6+72ca49ab08b8eb475cec82a10049503602325791-r1/temp/log.do_kernel_checkout.26330 >> for further information) >> ERROR: Logfile of failure stored in: >> >> /home/dev-2/yocto/build/tmp/work/bw-b600-poky-linux-gnueabi/linux-yocto-stable-2.6.34+git1+e1f85a470934a0cf6abde5d95533e74501822c6b_6+72ca49ab08b8eb475cec82a10049503602325791-r1/temp/log.do_kernel_checkout.26330 >> Log data follows: >> | Fixing up git directory for standard/devkit8000 >> | error: pathspec 'devkit8000-standard' did not match any file(s) known >> to git. >> | ERROR: Function 'do_kernel_checkout' failed (see >> >> /home/dev-2/yocto/build/tmp/work/bw-b600-poky-linux-gnueabi/linux-yocto-stable-2.6.34+git1+e1f85a470934a0cf6abde5d95533e74501822c6b_6+72ca49ab08b8eb475cec82a10049503602325791-r1/temp/log.do_kernel_checkout.26330 >> for further information) >> NOTE: package >> >> linux-yocto-stable-2.6.34+git1+e1f85a470934a0cf6abde5d95533e74501822c6b_6+72ca49ab08b8eb475cec82a10049503602325791-r1: >> task do_kernel_checkout: Failed >> ERROR: Task 1 >> (/home/dev-2/yocto/poky/meta-boardware/recipes-kernel/linux/ >> linux-yocto-stable_git.bb >> <http://linux-yocto-stable_git.bb>, do_kernel_checkout) failed with exit >> code '1' >> > > This is the typical BSP bootstrap 'problem'. Hold on for > just a little while longer, with the new fetcher changes > in master, I'm updating the recipes (literally now) to > fix this and am testing the workflow for adding a new board > as part of these changes. > > Cheers, > > Bruce > > >> I've tried this two options on >> SRCREV_machine_pn-linux-yocto-stable_devkit8000: >> >>"ef7f944e773950d4016b7643f9ecf052bbe250cd" = beagleboard-standard >> branch >>"2b1caf6ed7b888c95a1909d343799672731651a5" = master branch >>"72ca49ab08b8eb475cec82a10049503602325791" = standard branch >> >> >> There isn't an specific devki8000 branch. >> >> Regards, >> >> -- >> *dS >> Diego Sueiro >> >> /*long live rock 'n roll*/ >> >> >> On Tue, Feb 8, 2011 at 12:11 PM, Bruce Ashfield >> mailto:bruce.ashfi...@windriver.com>> >> wrote: >> >>On 11-02-08 08:46 AM, Diego Sueiro wrote: >> >>Folks, >> >>I'm trying to get devkit8000 kernel compiled with >>linux-yocto-stable recipe. >>I've added devkit8000 on COMPATIBLE_MACHINE and on >>KMACHINE_dekvkit800. >> >>But I don't know what pokylinux branch to use to make the kernel >>build >>works. >> >>I believe that I have to config these variables: >> >> LINUX_KERNEL_TYPE >> >> >>This one defaults to something sane, so you don't need >>to set this line. >> >> >>SRCREV_machine_pn-linux-yocto-stable_devkit8000 >> >> >>You would need to set this, to a SRCREV of the branch you'll >>end up building. >>
Re: [yocto] Adding machine for linux-yocto-stable
Bruce, I've updated my yocto tree but I'm still getting this error: ERROR: Function 'do_kernel_checkout' failed (see /home/dev-2/yocto/build/tmp/work/bw-b600-poky-linux-gnueabi/linux-yocto-stable-2.6.34+git1+e1f85a470934a0cf6abde5d95533e74501822c6b_6+72ca49ab08b8eb475cec82a10049503602325791-r1/temp/log.do_kernel_checkout.26330 for further information) ERROR: Logfile of failure stored in: /home/dev-2/yocto/build/tmp/work/bw-b600-poky-linux-gnueabi/linux-yocto-stable-2.6.34+git1+e1f85a470934a0cf6abde5d95533e74501822c6b_6+72ca49ab08b8eb475cec82a10049503602325791-r1/temp/log.do_kernel_checkout.26330 Log data follows: | Fixing up git directory for standard/devkit8000 | error: pathspec 'devkit8000-standard' did not match any file(s) known to git. | ERROR: Function 'do_kernel_checkout' failed (see /home/dev-2/yocto/build/tmp/work/bw-b600-poky-linux-gnueabi/linux-yocto-stable-2.6.34+git1+e1f85a470934a0cf6abde5d95533e74501822c6b_6+72ca49ab08b8eb475cec82a10049503602325791-r1/temp/log.do_kernel_checkout.26330 for further information) NOTE: package linux-yocto-stable-2.6.34+git1+e1f85a470934a0cf6abde5d95533e74501822c6b_6+72ca49ab08b8eb475cec82a10049503602325791-r1: task do_kernel_checkout: Failed ERROR: Task 1 (/home/dev-2/yocto/poky/meta-boardware/recipes-kernel/linux/ linux-yocto-stable_git.bb, do_kernel_checkout) failed with exit code '1' I've tried this two options on SRCREV_machine_pn-linux-yocto-stable_devkit8000: "ef7f944e773950d4016b7643f9ecf052bbe250cd" = beagleboard-standard branch "2b1caf6ed7b888c95a1909d343799672731651a5" = master branch "72ca49ab08b8eb475cec82a10049503602325791" = standard branch There isn't an specific devki8000 branch. Regards, -- *dS Diego Sueiro /*long live rock 'n roll*/ On Tue, Feb 8, 2011 at 12:11 PM, Bruce Ashfield < bruce.ashfi...@windriver.com> wrote: > On 11-02-08 08:46 AM, Diego Sueiro wrote: > >> Folks, >> >> I'm trying to get devkit8000 kernel compiled with linux-yocto-stable >> recipe. >> I've added devkit8000 on COMPATIBLE_MACHINE and on KMACHINE_dekvkit800. >> >> But I don't know what pokylinux branch to use to make the kernel build >> works. >> >> I believe that I have to config these variables: >> >>LINUX_KERNEL_TYPE >> > > This one defaults to something sane, so you don't need > to set this line. > > > SRCREV_machine_pn-linux-yocto-stable_devkit8000 >> > > You would need to set this, to a SRCREV of the branch you'll > end up building. > > >> >> Any suggestions? >> > > Are you working out of an up to date master ? I've made some > changes recently that allow BSPs to bootstrap/reuse existing > branches. If you aren't on the latest master the procedure > is different. > > Cheers, > > Bruce > > >> Regards, >> >> -- >> *dS >> Diego Sueiro >> >> /*long live rock 'n roll*/ >> >> >> >> ___ >> 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] Adding machine for linux-yocto-stable
Folks, I'm trying to get devkit8000 kernel compiled with linux-yocto-stable recipe. I've added devkit8000 on COMPATIBLE_MACHINE and on KMACHINE_dekvkit800. But I don't know what pokylinux branch to use to make the kernel build works. I believe that I have to config these variables: LINUX_KERNEL_TYPE SRCREV_machine_pn-linux-yocto-stable_devkit8000 Any suggestions? Regards, -- *dS Diego Sueiro /*long live rock 'n roll*/ ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Kernel Panics on armv4t with gcc.4.5.1
Gary, I suggest you to remove all gcc entries on sstate-cache and stamp directories. After that try to build it again. Regards, -- *dS Diego Sueiro /*long live rock 'n roll*/ On Thu, Feb 3, 2011 at 3:06 PM, Gary Thomas wrote: > On 02/03/2011 10:03 AM, Kamble, Nitin A wrote: > >> Hi Gary, >> I would look into the 4.5.2 branch and will try to get it to work. >> BTW there is some workaround Diego Sueiro came up with in his email yday >> for 4.5.2 gcc. >> > > I already applied his changes. The errors I'm getting > are completely different than what he was seeing. > > > -Original Message- >>> From: yocto-boun...@yoctoproject.org [mailto:yocto- >>> boun...@yoctoproject.org] On Behalf Of Gary Thomas >>> Sent: Wednesday, February 02, 2011 7:29 AM >>> To: yocto@yoctoproject.org >>> Subject: Re: [yocto] Kernel Panics on armv4t with gcc.4.5.1 >>> >>> On 02/02/2011 06:45 AM, Gary Thomas wrote: >>> >>>> On 01/31/2011 05:41 PM, Kamble, Nitin A wrote: >>>> >>>>> Diego, >>>>> >>>>> Can you try with 4.5.2 gcc from this branch: >>>>> >>>> http://git.pokylinux.org/cgit/cgit.cgi/poky- >>> contrib/log/?h=nitin/khem_gcc_nitin >>> >>>> >>>> I too am having trouble (OMAP-L138 == armv5te/arm926ejs) >>>> >>>> Nitin, I tried using your branch, but it failed to build: >>>> >>>> NOTE: package gcc-cross-intermediate-4.5.2-r3: task >>>> >>> do_populate_sysroot: Started >>> >>>> ERROR: Error executing a python function in /home/local/poky- >>>> >>> contrib/meta/recipes-devtools/gcc/gcc-cross-intermediate_4.5.2.bb: >>> >>>> OSError: [Errno 2] No such file or directory: >>>> '/home/local/efacec_omap_4.5.2/tmp/work/armv5te-poky-linux- >>>> >>> gnueabi/gcc-cross-intermediate-4.5.2-r3/sysroot- >>> destdir///home/local/efacec_omap_4.5.2/tmp/sysroots/cobra- >>> omapl138p78//lib' >>> >>>> >>>> ERROR: The stack trace of python calls that resulted in this >>>> >>> exception/failure was: >>> >>>> ERROR: File "sstate_task_postfunc", line 10, in >>>> ERROR: >>>> ERROR: File "sstate_task_postfunc", line 4, in sstate_task_postfunc >>>> ERROR: >>>> ERROR: File "sstate.bbclass", line 17, in sstate_install >>>> ERROR: >>>> ERROR: File "/home/local/poky-contrib/meta/lib/oe/path.py", line 56, >>>> >>> in copytree >>> >>>> ERROR: names = os.listdir(src) >>>> ERROR: >>>> ERROR: The code that was being executed was: >>>> ERROR: 0006: bb.build.exec_func(intercept, d) >>>> ERROR: 0007: sstate_package(shared_state, d) >>>> ERROR: 0008: >>>> ERROR: 0009: >>>> ERROR: *** 0010:sstate_task_postfunc(d) >>>> ERROR: 0011: >>>> ERROR: (file: 'sstate_task_postfunc', lineno: 10, function:) >>>> ERROR: 0001: >>>> ERROR: 0002:def sstate_task_postfunc(d): >>>> ERROR: 0003: shared_state = sstate_state_fromvars(d) >>>> ERROR: *** 0004: sstate_install(shared_state, d) >>>> ERROR: 0005: for intercept in shared_state['interceptfuncs']: >>>> ERROR: 0006: bb.build.exec_func(intercept, d) >>>> ERROR: 0007: sstate_package(shared_state, d) >>>> ERROR: 0008: >>>> ERROR: (file: 'sstate_task_postfunc', lineno: 4, function: >>>> >>> sstate_task_postfunc) >>> >>>> ERROR: Function 'sstate_task_postfunc' failed >>>> >>>> >>>> Any ideas how to fix this? >>>> >>> >>> Just to check, I applied the patches from Nitin's contrib tree >>> to poky/master and rebuilt - same results. I used the sequence >>>5b7e96d852778f1164198040cbd165241ea51e40..HEAD >>> >>> >>>> *From:*yocto-boun...@yoctoproject.org [mailto:yocto- >>>>> >>>> boun...@yoctoproject.org] *On Behalf Of *Diego Sueiro >>> >>>> *Sent:* Monday, January 31, 2011 10:53 AM >>>>> *To:* yocto@yoctoproject.org >>>>> *Subject:* [yocto] Kernel Panics on armv4t with gcc.4.5.1 >>>>> >>>>> Folks, >>>>> >>>>> I'm not a kernel and neither a gcc exper
[yocto] Binutils compiling workaround
Folks, I was trying to get binutils (2.10.1 an 2.21) compiled but always getting this error: cc1: warnings being treated as errors /home/dev/yocto-repo/build/tmp/work/armv4t-poky-linux-gnueabi/binutils-2.21-r0/binutils-2.21/gas/config/tc-arm.c: In function 'parse_operands': /home/dev/yocto-repo/build/tmp/work/armv4t-poky-linux-gnueabi/binutils-2.21-r0/binutils-2.21/gas/config/tc-arm.c:1895:27: error: 'firsttype$defined' may be used uninitialized in this function /home/dev/yocto-repo/build/tmp/work/armv4t-poky-linux-gnueabi/binutils-2.21-r0/binutils-2.21/gas/config/tc-arm.c:1895:27: error: 'firsttype$index' may be used uninitialized in this function make[4]: *** [tc-arm.o] Error 1 make[4]: Leaving directory `/home/dev/yocto-repo/build/tmp/work/armv4t-poky-linux-gnueabi/binutils-2.21-r0/binutils-2.21/build.arm-poky-linux-gnueabi.arm-poky-linux-gnueabi/gas' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/home/dev/yocto-repo/build/tmp/work/armv4t-poky-linux-gnueabi/binutils-2.21-r0/binutils-2.21/build.arm-poky-linux-gnueabi.arm-poky-linux-gnueabi/gas' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/dev/yocto-repo/build/tmp/work/armv4t-poky-linux-gnueabi/binutils-2.21-r0/binutils-2.21/build.arm-poky-linux-gnueabi.arm-poky-linux-gnueabi/gas' make[1]: *** [all-gas] Error 2 make[1]: Leaving directory `/home/dev/yocto-repo/build/tmp/work/armv4t-poky-linux-gnueabi/binutils-2.21-r0/binutils-2.21/build.arm-poky-linux-gnueabi.arm-poky-linux-gnueabi' make: *** [all] Error 2 FATAL: oe_runmake failed Function 'do_compile' failed (see /home/dev/yocto-repo/build/tmp/work/armv4t-poky-linux-gnueabi/binutils-2.21-r0/temp/log.do_compile.26524 for further information) ERROR: Function 'do_compile' failed (see /home/dev/yocto-repo/build/tmp/work/armv4t-poky-linux-gnueabi/binutils-2.21-r0/temp/log.do_compile.26524 for further information) As the compiler was treating warnings as errors I put "--disabe-werror" on EXTRA_OECONF inside the binutils.inc file. I don't know if this is the best solution. What is the root cause of this warning? Regards, -- *dS Diego Sueiro /*long live rock 'n roll*/ ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Kernel Panics on armv4t with gcc.4.5.1
Nitin,
After removing:
echo "/* GNU ld script
Use the shared library, but some functions are only in
the static library. */
GROUP ( libgcc_s.so.1 libgcc.a )" > ${D}${libdir}/libgcc_s.so
from gcc-package-target.inc and gcc-package-cross.inc, the gcc 4.5.2 was
successfully compiled.
And no kernel panic anymore. :-D
I just want to understand what is wrong with gcc 4.5.1.
Regards,
--
*dS
Diego Sueiro
Administrador do Portal Embarcados
www.embarcados.com.br
/*long live rock 'n roll*/
On Tue, Feb 1, 2011 at 8:40 AM, Diego Sueiro wrote:
> Nitin,
>
>
> I got this error:
>
> /home/dev/yocto-repo/build/tmp/sysroots/i686-linux/usr/bin/armv4t-poky-linux-gnueabi/arm-poky-linux-gnueabi-ld:
> /usr/lib/crti.o: Relocations in generic ELF (EM: 3)
> /home/dev/yocto-repo/build/tmp/sysroots/i686-linux/usr/bin/armv4t-poky-linux-gnueabi/arm-poky-linux-gnueabi-ld:
> /usr/lib/crti.o: Relocations in generic ELF (EM: 3)
> /usr/lib/crti.o: could not read symbols: File in wrong format
> collect2: ld returned 1 exit status
> make[2]: *** [libgcc_s.so] Error 1
> make[2]: *** Waiting for unfinished jobs
> arm-poky-linux-gnueabi-ranlib libgcc_eh.a
> arm-poky-linux-gnueabi-ranlib libgcc.a
> make[2]: Leaving directory
> `/home/dev/yocto-repo/build/tmp/work/armv4t-poky-linux-gnueabi/gcc-cross-intermediate-4.5.2-r3/gcc-4.5.2/build.i686-linux.arm-poky-linux-gnueabi/arm-poky-linux-gnueabi/libgcc'
> make[1]: *** [all-target-libgcc] Error 2
> make[1]: Leaving directory
> `/home/dev/yocto-repo/build/tmp/work/armv4t-poky-linux-gnueabi/gcc-cross-intermediate-4.5.2-r3/gcc-4.5.2/build.i686-linux.arm-poky-linux-gnueabi'
> make: *** [all] Error 2
> FATAL: oe_runmake failed
> Function 'do_compile' failed (see
> /home/dev/yocto-repo/build/tmp/work/armv4t-poky-linux-gnueabi/gcc-cross-intermediate-4.5.2-r3/temp/log.do_compile.646
> for further information)
> ERROR: Function 'do_compile' failed (see
> /home/dev/yocto-repo/build/tmp/work/armv4t-poky-linux-gnueabi/gcc-cross-intermediate-4.5.2-r3/temp/log.do_compile.646
> for further information)
>
>
>
> Regards,
>
> --
> *dS
> Diego Sueiro
>
> /*long live rock 'n roll*/
>
>
> On Mon, Jan 31, 2011 at 10:41 PM, Kamble, Nitin A <
> nitin.a.kam...@intel.com> wrote:
>
>> Diego,
>>
>> Can you try with 4.5.2 gcc from this branch:
>> http://git.pokylinux.org/cgit/cgit.cgi/poky-contrib/log/?h=nitin/khem_gcc_nitin
>>
>>
>>
>> Thanks,
>>
>> Nitin
>>
>>
>>
>>
>>
>> *From:* yocto-boun...@yoctoproject.org [mailto:
>> yocto-boun...@yoctoproject.org] *On Behalf Of *Diego Sueiro
>> *Sent:* Monday, January 31, 2011 10:53 AM
>> *To:* yocto@yoctoproject.org
>> *Subject:* [yocto] Kernel Panics on armv4t with gcc.4.5.1
>>
>>
>>
>> Folks,
>>
>>
>>
>> I'm not a kernel and neither a gcc expert developer, and after searching
>> for a solution for the last 2 weeks I've decided to appeal to the list.
>>
>>
>>
>> I'm trying to build a kernel image (2.6.32 and 2.6.30) for mini2440
>> (armv4t) with Yocto Project (poky master branch) and I'm facing a strange
>> issue.
>>
>>
>>
>> If I compile the kernel with Yocto gcc recipes (gcc 4.5.1) the kernel will
>> panic on init (console printed message is attached for kernel 2.6.30 and
>> 2.6.32).
>>
>> But, if I compile the kernel with meta-oe gcc recipes (gcc 4.5) everything
>> will be ok.
>>
>> Just for your reference these is the gcc recipes which I'm using:
>>
>>
>> http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-devtools/gcc
>>
>>
>> http://git.openembedded.org/cgit.cgi/meta-openembedded/tree/recipes-devtools/gcc
>>
>>
>>
>>
>>
>> I've compiled with and without thumb instructions, but the issue remains.
>>
>> I've tried to apply the patches gcc-armv4-pass-fix-v4bx-to-ld.patch
>> and gcc-arm-volatile-bitfield-fix.patch, but no success.
>>
>>
>>
>>
>>
>>
>>
>> Kind Regards,
>>
>>
>>
>> --
>>
>> *dS
>> Diego Sueiro
>>
>> /*long live rock 'n roll*/
>>
>
>
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Kernel Panics on armv4t with gcc.4.5.1
Nitin, I got this error: /home/dev/yocto-repo/build/tmp/sysroots/i686-linux/usr/bin/armv4t-poky-linux-gnueabi/arm-poky-linux-gnueabi-ld: /usr/lib/crti.o: Relocations in generic ELF (EM: 3) /home/dev/yocto-repo/build/tmp/sysroots/i686-linux/usr/bin/armv4t-poky-linux-gnueabi/arm-poky-linux-gnueabi-ld: /usr/lib/crti.o: Relocations in generic ELF (EM: 3) /usr/lib/crti.o: could not read symbols: File in wrong format collect2: ld returned 1 exit status make[2]: *** [libgcc_s.so] Error 1 make[2]: *** Waiting for unfinished jobs arm-poky-linux-gnueabi-ranlib libgcc_eh.a arm-poky-linux-gnueabi-ranlib libgcc.a make[2]: Leaving directory `/home/dev/yocto-repo/build/tmp/work/armv4t-poky-linux-gnueabi/gcc-cross-intermediate-4.5.2-r3/gcc-4.5.2/build.i686-linux.arm-poky-linux-gnueabi/arm-poky-linux-gnueabi/libgcc' make[1]: *** [all-target-libgcc] Error 2 make[1]: Leaving directory `/home/dev/yocto-repo/build/tmp/work/armv4t-poky-linux-gnueabi/gcc-cross-intermediate-4.5.2-r3/gcc-4.5.2/build.i686-linux.arm-poky-linux-gnueabi' make: *** [all] Error 2 FATAL: oe_runmake failed Function 'do_compile' failed (see /home/dev/yocto-repo/build/tmp/work/armv4t-poky-linux-gnueabi/gcc-cross-intermediate-4.5.2-r3/temp/log.do_compile.646 for further information) ERROR: Function 'do_compile' failed (see /home/dev/yocto-repo/build/tmp/work/armv4t-poky-linux-gnueabi/gcc-cross-intermediate-4.5.2-r3/temp/log.do_compile.646 for further information) Regards, -- *dS Diego Sueiro /*long live rock 'n roll*/ On Mon, Jan 31, 2011 at 10:41 PM, Kamble, Nitin A wrote: > Diego, > > Can you try with 4.5.2 gcc from this branch: > http://git.pokylinux.org/cgit/cgit.cgi/poky-contrib/log/?h=nitin/khem_gcc_nitin > > > > Thanks, > > Nitin > > > > > > *From:* yocto-boun...@yoctoproject.org [mailto: > yocto-boun...@yoctoproject.org] *On Behalf Of *Diego Sueiro > *Sent:* Monday, January 31, 2011 10:53 AM > *To:* yocto@yoctoproject.org > *Subject:* [yocto] Kernel Panics on armv4t with gcc.4.5.1 > > > > Folks, > > > > I'm not a kernel and neither a gcc expert developer, and after searching > for a solution for the last 2 weeks I've decided to appeal to the list. > > > > I'm trying to build a kernel image (2.6.32 and 2.6.30) for mini2440 > (armv4t) with Yocto Project (poky master branch) and I'm facing a strange > issue. > > > > If I compile the kernel with Yocto gcc recipes (gcc 4.5.1) the kernel will > panic on init (console printed message is attached for kernel 2.6.30 and > 2.6.32). > > But, if I compile the kernel with meta-oe gcc recipes (gcc 4.5) everything > will be ok. > > Just for your reference these is the gcc recipes which I'm using: > > > http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-devtools/gcc > > > http://git.openembedded.org/cgit.cgi/meta-openembedded/tree/recipes-devtools/gcc > > > > > > I've compiled with and without thumb instructions, but the issue remains. > > I've tried to apply the patches gcc-armv4-pass-fix-v4bx-to-ld.patch > and gcc-arm-volatile-bitfield-fix.patch, but no success. > > > > > > > > Kind Regards, > > > > -- > > *dS > Diego Sueiro > > /*long live rock 'n roll*/ > ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Kernel Panics on armv4t with gcc.4.5.1
Folks, I'm not a kernel and neither a gcc expert developer, and after searching for a solution for the last 2 weeks I've decided to appeal to the list. I'm trying to build a kernel image (2.6.32 and 2.6.30) for mini2440 (armv4t) with Yocto Project (poky master branch) and I'm facing a strange issue. If I compile the kernel with Yocto gcc recipes (gcc 4.5.1) the kernel will panic on init (console printed message is attached for kernel 2.6.30 and 2.6.32). But, if I compile the kernel with meta-oe gcc recipes (gcc 4.5) everything will be ok. Just for your reference these is the gcc recipes which I'm using: http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-devtools/gcc http://git.openembedded.org/cgit.cgi/meta-openembedded/tree/recipes-devtools/gcc I've compiled with and without thumb instructions, but the issue remains. I've tried to apply the patches gcc-armv4-pass-fix-v4bx-to-ld.patch and gcc-arm-volatile-bitfield-fix.patch, but no success. Kind Regards, -- *dS Diego Sueiro /*long live rock 'n roll*/ VFS: Mounted root (jffs2 filesystem) on device 31:2. Freeing init memory: 104K Failed to execute /linuxrc. Attempting defaults... Unable to handle kernel paging request at virtual address 00100104 pgd = c398 [00100104] *pgd=3398c031, *pte=, *ppte= Internal error: Oops: 817 [#1] Modules linked in: CPU: 0Not tainted (2.6.30.4-boardcon #1) PC is at get_page_from_freelist+0x1cc/0x418 LR is at get_page_from_freelist+0xf8/0x418 pc : []lr : []psr: 6093 sp : c381db10 ip : fp : c381db6c r10: c041e660 r9 : c03c0cb8 r8 : 6013 r7 : 0001 r6 : c03e0974 r5 : c03e0994 r4 : r3 : 00100100 r2 : r1 : 00200200 r0 : 0001 Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user Control: c000717f Table: 3398 DAC: 0015 Process init (pid: 1, stack limit = 0xc381c268) Stack: (0xc381db10 to 0xc381e000) db00: 0044 f77682ec db20: c03e0f00 000284d0 c03e0974 c03e0974 db40: c002f3a0 c381a000 84d0 c381c000 c03e0efc db60: c381dbdc c381db70 c00621c8 c0061d18 0044 c0403248 000284d0 db80: 0001 c381c000 c381db88 0400 c381dbb4 c040230c dba0: 0010 c04022e0 c040230c c381dbfc c3981000 c3935000 c3a05160 dbc0: c381c000 c3981000 c398 0200 c381dbfc c381dbe0 c006ee50 c0062130 dbe0: 40025000 c381a000 c3a05160 c381c000 c381dc64 c381dc00 c0071404 c006ee38 dc00: c381dc2c c381dc10 c0022048 c0038bdc 0800 f400 4000 dc20: c3935000 c381dc30 c00229e4 c0022010 c041e560 0080 c3935000 dc40: 4002587c c381ddf0 c381a000 c3a05160 0805 c3935034 c381dd1c c381dc68 dc60: c0028194 c0070ba0 40025000 0800 c393d780 0034 c3408a80 dc80: c381dd3c c381dc90 c005e3bc c00922c8 0001 c381c000 c381dcbc c381dca8 dca0: 0001dd5c 00c0 c381dd98 dcc0: 0001 c381dd14 c381dce0 c0151f5c c0151c90 dce0: c3a05184 c3a05184 c381dd14 c3a05160 c3a05184 0805 4002587c c381ddf0 dd00: 0005 c03ba664 2013 4000 c381dd3c c381dd20 c002835c c0028004 dd20: 0005 0805 4002587c c381ddf0 c381ddec c381dd40 c00221bc c00282f8 dd40: 40024000 c3935000 c381ddc4 c381dd58 c007481c c00737d4 c3a05120 dd60: c393d780 001c c3a05160 c3a05000 c03c0ddc c34089e8 0812 dd80: c393d780 c381c000 c393d780 c3a05120 c3a05124 c3a05108 c381ddc4 0007 dda0: c381c000 c393d780 2000 c3935000 0812 0002 c381de0c c381ddc8 ddc0: c0074cf8 c007467c 08100877 c381de24 c381df50 c381c000 dde0: c381de4c c381ddf0 c00229a0 c0022198 4002587c 077c 81025fff de00: c393d700 c3838e00 c381df50 c381c000 c393d780 4000 c381de4c de20: c381de38 c00b3b70 c014c7c8 2013 0784 c00b3b70 de40: c381dedc c381de50 c00b4a48 c00b3b2c 0812 000b 00016c14 de60: 0001 0001653c 8000 4002587c 40025960 e53c 8000 c393d700 de80: 000169fc c3984480 c3986fc0 c393d734 0006 c3838f00 dea0: c3838e00 c035c6c0 bed4 c03e1440 c03c15bc c03c1208 c3838e00 dec0: fff8 c381df50 c381c000 c381df14 c381dee0 c0084c64 c00b3f4c dee0: befff000 0002 c03ba228 c3838e00 c381df50 c381c000 df00: c03ba228 c03ba1a0 c381df4c c381df18 c0085db8 c0084bc0 c381df9c df20: c03ba1a0 c381df50 c035c6c0 c03ba228 df40: c381dfb4 c381df50 c0025b70 c0085bb4 df60: df80: c03e1380 c001d1f8 dfa0: c381dfc4 c381dfb8 c002225c c0025b40 c381dfdc c381dfc8 dfc0: c00222ec c002
