06:19.01 | *** join/#oe ibot (~ibot@rikers.org) |
06:19.01 | *** topic/#oe is OpenEmbedded Developer Lounge | Web: http://openembedded.org | Bugtracker: http://bugs.openembedded.org and http://tinderbox.openembedded.org for compile issues | Repository: git.openembedded.org/openembedded and repo.or.cz/r/openembedded.git as ro mirror | This is not a distro or machine support channel |
06:54.02 | *** join/#oe tasslehoff (~Tasslehof@147.84-49-231.nextgentel.com) |
06:59.17 | *** join/#oe ant_work (~andrea@host6-80-static.42-85-b.business.telecomitalia.it) |
07:04.05 | *** join/#oe sH|Mnemonic (~cyberdeck@iss66.vlsi.informatik.tu-darmstadt.de) |
07:28.47 | *** join/#oe 18VAAH7YR (~t@83.151.21.119) |
07:30.39 | *** join/#oe tasslehoff (~Tasslehof@147.84-49-231.nextgentel.com) |
07:31.38 | *** join/#oe _abhishek (~abhishek@115.108.3.237) |
07:31.47 | *** part/#oe _abhishek (~abhishek@115.108.3.237) |
07:41.12 | *** join/#oe likewise (~likewise@095-097-098-131.static.chello.nl) |
07:43.46 | *** join/#oe ao2 (~ao2@2001:1418:117::1) |
08:14.35 | *** join/#oe amarsman (~marsman@90-145-17-249.wxdsl.nl) |
08:33.13 | *** join/#oe bluelightning (~paul@83.217.123.106) |
08:33.13 | *** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning) |
08:36.52 | bluelightning | morning all |
08:42.36 | tasslehoff | what's the compresslevel of the tar.bz2 images created by OE? |
08:44.52 | tasslehoff | nevermind, I'll use tar instead. unpacking a tar.bz2 on a beagleboard takes quite some time :) |
08:50.50 | pb_ | hi bluelightning |
08:53.29 | *** join/#oe HeinervdmOff (~zimmerman@hsaggate.physik.uni-bonn.de) |
09:05.07 | *** join/#oe florian (~fuchs@port-217-146-132-69.static.qsc.de) |
09:05.07 | *** join/#oe florian (~fuchs@Maemo/community/contributor/florian) |
09:07.44 | *** join/#oe sanket (~sanket@114.143.163.33) |
09:08.44 | sanket | Does HDX ICAClient work on mini6410? can anyone help me.... does anyone had done that.... |
09:09.36 | sanket | I had install on mini6410.... It get connected too.... but getting weird display screen.... |
09:10.16 | *** join/#oe kristoffer_ (~kristoffe@c-f3dfe555.010-30-6c6b7012.cust.bredbandsbolaget.se) |
09:19.07 | bluelightning | sanket: isn't that proprietary? if so this is not the place for support for that, talk to Citrix |
09:34.39 | *** join/#oe obi (~obi@unaffiliated/obi) |
09:34.49 | *** join/#oe mickey|office (~Mickey@business-092-079-168-007.static.arcor-ip.net) |
09:42.17 | *** join/#oe phdeswer (~philippe@a83-245-252-47.elisa-laajakaista.fi) |
09:54.53 | *** join/#oe pepermint (~pepermint@host100-11-dynamic.58-82-r.retail.telecomitalia.it) |
09:56.55 | pb_ | hi mickey|office |
09:57.03 | mickey|office | good morning pb_ |
09:59.52 | *** join/#oe likewise (~likewise@42-81-ftth.onsneteindhoven.nl) |
10:06.19 | *** join/#oe pepermint (~pepermint@host100-11-dynamic.58-82-r.retail.telecomitalia.it) |
10:13.25 | *** join/#oe ALoGeNo (~alogeno@7.Red-79-154-211.dynamicIP.rima-tde.net) |
10:13.25 | *** join/#oe ALoGeNo (~alogeno@unaffiliated/alogeno) |
10:35.51 | *** join/#oe pepermint (~pepermint@host100-11-dynamic.58-82-r.retail.telecomitalia.it) |
10:43.12 | lumag | hi all! |
10:43.27 | *** join/#oe ao2 (~ao2@2001:1418:117::1) |
10:47.04 | bluelightning | hi lumag |
10:47.35 | lumag | bluelightning, hi, any news regarding meta-hh or meta-opie? |
10:47.53 | bluelightning | lumag: some progress, no release yet |
10:48.03 | bluelightning | in the mean time I fixed some more build issues last night |
10:48.34 | pb_ | whereabouts is meta-handhelds hosted, by the way? |
10:48.44 | bluelightning | pb_: it's not, that's the issue |
10:48.50 | pb_ | ah, I see |
10:48.54 | pb_ | do you want to have it on oe.org? |
10:49.25 | bluelightning | that would be great... previously I was told to put it on github |
10:50.03 | pb_ | oh, right. who told you that? |
10:50.59 | *** join/#oe mickey|office (~Mickey@business-092-079-168-007.static.arcor-ip.net) |
10:51.08 | pb_ | I don't know of any reason why we couldn't host it at oe.org. if you want to send me the url to a temporary repo that I can pull from, I'll try to set it up later. |
10:51.21 | bluelightning | koen and graeme |
10:51.41 | bluelightning | pb_: ok, great... when I'm in a position to release it I'll give you a shout, thanks |
10:51.45 | pb_ | ok, cool |
10:52.13 | *** join/#oe gnutoo (~gnutoo@host239-153-dynamic.51-79-r.retail.telecomitalia.it) |
10:55.02 | lumag | colleagues, pxa270 boards (armv5te + iwmmxt) seems broken now due to big TUNE patches. Would it be suitable to add iwmmxt tune to oe-core, or it should live in meta-zaurus? |
10:55.52 | pb_ | I think it would be ok to add to oe-core. |
10:55.57 | lumag | Asking about meta-zaurus, as I'm concerned about spitz. |
10:56.02 | lumag | pb_, ok |
10:56.29 | pb_ | obviously I'm not the person who actually decides, but if I were you I would at least try submitting a patch and see what happens |
11:05.21 | lumag | ant_work, do you have any recent reports regarding collie? (especially reg. CF cards)? I've tried running several kernels in qemu, but card was not fully detected. Do you have any info? |
11:12.18 | CIA-15 | 03Josua Mayer <josua.mayer97@googlemail.com> 07master * r1a91fc4b70 10openembedded.git/recipes/mplayer/mplayer_git.bb: (log message trimmed) |
11:12.18 | CIA-15 | mplayer_git: Add patch to fix linker error on x86 machines |
11:12.18 | CIA-15 | For x86 machines the option `--enable-runtime-cpudetection` is passed to the configure script. |
11:12.18 | CIA-15 | EXTRA_OECONF_append = " ${@base_contains('MACHINE_FEATURES', 'x86', '--enable-runtime-cpudetection', '',d)} " |
11:12.18 | CIA-15 | This causes a linker error like |
11:12.19 | CIA-15 | fix undefined references in loader/module.o: |
11:12.20 | CIA-15 | module.c:(.text+0xd60): undefined reference to `report_entry' |
11:13.56 | lumag | btw: do we have mplayer recipe somewhere for oe-core builds? |
11:14.57 | ant_work | lumag: hi |
11:18.24 | ant_work | I sent you te pending patch fixing iwmmxt |
11:20.50 | ant_work | about cf, here a log http://pastebin.com/se3BMrmU |
11:20.56 | Crofton|work | http://pastebin.com/Cfa1VpLe |
11:21.03 | Crofton|work | this is in the release branch |
11:21.10 | Crofton|work | I think I've seen it before |
11:22.58 | lumag | ant_work, strange. I'll have to dig qemu then |
11:23.12 | ant_work | wait, read this too: http://lists.linuxtogo.org/pipermail/angstrom-distro-users/2011-August/003739.html |
11:25.35 | lumag | ant_work, I'm using standard microdrive emulation which works with pxa-based zaurii. StrongARM PCMCIA unit is exactly the same as in PXA. So it's either some generic hw emulation problem (like caches or other stuff) or I don't know. |
11:25.59 | ant_work | ah, I see |
11:27.05 | lumag | ant_work, regarding iwmmxt: this is a bit strange. We already have a tune-iwmmxt.inc, but it IIUC will default for all packages to be built into iwwmxt feed. |
11:29.16 | lumag | Most probably we don't want that. I'd instead use armv5te feed/xscale optimization by default and only use iwmmxt for several packages (like mplayer) |
11:31.30 | ant_work | yes, if we want to share the same feeds |
11:31.53 | ensc|w | are iwmmxt binaries working with recent kernels? |
11:33.22 | ant_work | lumag: I asked RP but he ws very busy. Maye pb_ will tell us about http://paste.debian.net/124948/ |
11:37.06 | ensc|w | no.... iwmmmxt is still broken with 3.0 |
11:38.28 | *** join/#oe mlip (~mlip@unaffiliated/mlip) |
11:39.07 | lumag | ensc|w, any points for bugreport? |
11:39.32 | ensc|w | http://comments.gmane.org/gmane.linux.ports.arm.general/11795 |
11:40.54 | ensc|w | it's probably a bug in the kernel which does not restore iwmmxt registers on task switches |
11:41.12 | ensc|w | (extremly tricky and optimized code) |
11:42.57 | lumag | ant_work, pb_ I'd suggest something like this: http://pastebin.de/18080 |
11:45.49 | ant_work | lumag: seems right if we want to split pxa25x and pxa27x |
11:46.00 | lumag | ensc|w, hmmm. |
11:46.39 | lumag | ant_work, patch is completely untested |
11:49.11 | *** join/#oe ao2 (~ao2@2001:1418:117::1) |
11:52.14 | *** join/#oe methril_work (~Rafael@189.114.111.135) |
11:55.53 | ensc|w | lumag: I can reproduced it on a pxa168 in 2 minutes; download https://www.cvg.de/people/ensc/iwmmxt-ld.tar.gz, extract it on tmpfs, chroot into it and execute ./x |
11:56.14 | lumag | ensc|w, have you tried pinging Eric Miao directly or via LAKML |
11:58.04 | ensc|w | afair, posting was cc'ed to them |
12:01.49 | lumag | ensc|w, also you might be interested in debugging which paths the kernel chooses in kernel/iwmmxt.S, kernel/xscale-cp0.c, etc. |
12:02.04 | ant_work | lumag: as far as it concerns Zaurus, maybe only mplayer and ffmpeg are concerned |
12:02.21 | ant_work | stanislav did a bit of work http://www.penguin.cz/~utx/zaurus/software |
12:02.23 | lumag | ensc|w, I don't have pxa270 at hand, might have a chance to check on qemu |
12:02.57 | ant_work | lumag: last year only mplayer http://www.penguin.cz/~utx/zaurus/feed/ipk/iwmmxt/ |
12:06.41 | *** join/#oe ldnunes (~ldnunes@189.114.111.55) |
12:07.11 | *** join/#oe _abhishek (~abhishek@115.108.3.237) |
12:07.21 | *** part/#oe _abhishek (~abhishek@115.108.3.237) |
12:09.53 | lumag | ant_work, I expected that |
12:14.41 | *** join/#oe likewise (~likewise@42-81-ftth.onsneteindhoven.nl) |
12:18.35 | *** join/#oe axiom (d4935302@gateway/web/freenode/ip.212.147.83.2) |
12:38.46 | *** join/#oe Artox (~Artox@pD957CCD0.dip.t-dialin.net) |
13:08.18 | lumag | ant_work, goot collie to boot under qemu |
13:08.52 | *** join/#oe kevinsc (~a0214685@nat/ti/x-mbousbwudxlexdgo) |
13:11.33 | lumag | Strangely enough the qemu is booting (with lot's of permission denied errors) with default init, but panics right at system prompt with init=/bin/sh |
13:13.44 | *** join/#oe mhnoyes (~mhnoyes@sourceforge/sitedocs/mhnoyes) |
13:18.19 | *** join/#oe cminyard (~cminyard@pool-173-57-155-71.dllstx.fios.verizon.net) |
13:21.30 | *** join/#oe tom_say (~william@cpe-68-203-248-184.stx.res.rr.com) |
13:21.52 | *** join/#oe hbeck (~hbeck@69.41.94.155) |
13:22.20 | pb_ | ant_work: yeah, that sucks. the issue is that PACKAGE_EXTRA_ARCHS_tune-xx is not (despite what it looks like) an override. |
13:22.36 | pb_ | see the definition of PACKAGES_EXTRA_ARCHS in bitbake.conf for why setting that variable directly doesn't do what you might expect. |
13:24.43 | lumag | btw: what is ??= ? |
13:27.10 | pb_ | basically like a delayed version of ?=. see the manual. |
13:30.59 | *** join/#oe mhnoyes (~mhnoyes@sourceforge/sitedocs/mhnoyes) |
13:42.26 | bluelightning | anyone in the OE community going to the desktop summit? |
13:42.35 | *** join/#oe galak (~galak@192.88.168.34) |
13:53.12 | *** join/#oe pespin (~pespin@90.163.77.194) |
14:01.02 | pb_ | not me |
14:01.07 | pb_ | not allowed out very often |
14:03.22 | *** join/#oe mrmoku (~mrmoku@ppp-93-104-161-142.dynamic.mnet-online.de) |
14:04.41 | *** join/#oe nslu2-log_ (~nslu2-log@limax.nslu2-linux.org) |
14:05.31 | pb_ | ah, here we go. https://www.desktopsummit.org/program/sessions/degrees-playing-nice-large-companies-open-source |
14:05.39 | pb_ | I think he is a member of the oe eV at least :-} |
14:05.48 | Crofton|work | dirk? |
14:05.58 | Crofton|work | I think he mentioend he was going on google+ |
14:06.10 | *** join/#oe devzero_ (devzero@xdsl-89-0-68-72.netcologne.de) |
14:12.03 | lumag | ant_work, here? |
14:12.49 | ant_work | yes, back now |
14:15.22 | lumag | Regarding collie: I see strange problems when using zImage compiled via OE, but no problems with 2.6.39 compiled with codesourcery gcc. |
14:15.39 | *** join/#oe CosmicPenguin (~nobody@soa.codeaurora.org) |
14:22.26 | ant_work | ah |
14:23.04 | ant_work | I did compile the working 2.6.38 with TC of oe-dev |
14:24.07 | lumag | With 2.6.39 compiled with OE I get kernel panic if I set init=/bin/sh right after command prompt |
14:26.57 | ant_work | iirc we had one bad linaro patch breaking things for arm <7 but that was oe-dev |
14:29.38 | ant_work | lumag: did yoy test on c7x0 too? |
14:29.53 | lumag | ant_work, no. |
14:30.23 | ant_work | ok, I'll do |
14:30.46 | lumag | ant_work, checked tosa via qemu, basic things seem to work. |
14:30.56 | lumag | no graphics test ATM. |
14:30.56 | ant_work | atm oe-core-built kernel boots on poodle/c7x0 |
14:31.36 | hrw | ant_work: which linaro patch? someone checked? |
14:32.13 | ant_work | oh, hrw, that was long ago and maybe khem did it. Should be in the logs |
14:32.21 | hrw | ok |
14:32.38 | ant_work | effect was broken kernel. reported by JaMa iirc |
14:36.24 | *** join/#oe kergoth (~kergoth@ip24-251-173-232.ph.ph.cox.net) |
14:36.39 | *** join/#oe NightMonkey (~NightMonk@pdpc/supporter/professional/nightmonkey) |
14:50.26 | *** join/#oe likewise (~likewise@42-81-ftth.onsneteindhoven.nl) |
15:03.03 | *** join/#oe likewise (~likewise@42-81-ftth.onsneteindhoven.nl) |
15:10.04 | *** join/#oe likewise (~likewise@42-81-ftth.onsneteindhoven.nl) |
15:19.10 | *** join/#oe mickey|office (~Mickey@business-092-079-168-007.static.arcor-ip.net) |
15:21.37 | *** join/#oe jayabharath (~jayabhara@nat/ti/x-ogobzjhqwlopafoo) |
15:34.18 | *** join/#oe risca (~risca@m90-129-168-9.cust.tele2.se) |
15:34.20 | khem | luman ?? is weaker than ?= |
15:34.29 | khem | err that was for lumag |
15:34.51 | lumag | khem, yeah, got it already. |
15:34.57 | khem | good |
15:36.29 | *** join/#oe brolin (~brolin@nat216.udea.edu.co) |
15:39.19 | lumag | ant_work, I still get very strange behaviour with collie-qemu & self-compiled kernel. |
15:39.42 | ant_work | wich gcc? |
15:40.00 | lumag | codesourcery. I'll retry with emdebian |
15:43.08 | lumag | ant_work, e.g. I can boot console-image with init=/bin/sh, but then I can create files only in /tmp (not in /, e.g.) |
15:43.19 | lumag | I get permission denied |
15:45.03 | ant_work | a few days ago console-image did not get to the prompt in my tests, missing modutils.sh iirc |
15:45.35 | ant_work | now I've seen koen updated console-image to systemd |
15:45.43 | lumag | ant_work, that's with "rw init=/bin/sh" |
15:46.13 | *** join/#oe hollisb (~hollisb@c-24-20-193-174.hsd1.or.comcast.net) |
15:46.36 | ant_work | I'll do that soon: I have to check if really devtmpfs let you boot /bin/sh with empty /dev |
15:46.40 | *** join/#oe incandescant (~joshual@c-24-21-159-20.hsd1.or.comcast.net) |
15:47.09 | lumag | ant_work, yes, it does. |
15:47.33 | lumag | ant_work, but then (as it seems to me) you are left w/o ptys: there is no /dev/pts :( |
15:47.44 | ant_work | ah, I guess console is needed |
15:49.19 | lumag | console is working. that's not a problem |
15:50.15 | *** join/#oe msm (~msm@192.88.168.34) |
15:50.23 | pb_ | oh, I had that permission thing fairly recently |
15:50.38 | pb_ | stupid busybox seemed to be dropping root privs in a situation where it oughtn't have done |
15:55.18 | lumag | pb_, seems like it |
15:55.48 | lumag | at least I can create files with redirection. |
15:56.14 | lumag | via output redirection I mean |
16:01.41 | ant_work | so seems not kernel issue |
16:02.06 | lumag | There seems to be at least one kernel issue, I must recheck it. |
16:02.28 | ant_work | ok, going now, bbl |
16:06.16 | *** join/#oe nitink (~nitink@nat/intel/x-rrqcielrftgvbxkq) |
16:21.07 | *** join/#oe toto90 (~kakashi@41.143.7.151) |
16:21.26 | *** join/#oe rob_w (~bob@ppp-188-174-38-156.dynamic.mnet-online.de) |
16:30.43 | *** join/#oe NvrBst (~NvrBst@gateway/tor-sasl/nvrbst) |
16:34.14 | msm | whats the best way to debug how bitbake is deciding to use a specific package? |
16:42.11 | *** join/#oe tasslehoff (~tasslehof@145.79-161-31.customer.lyse.net) |
16:44.46 | lumag | pb_, do you know any way to disable that spurious root privs drop? Or it's fixed now? |
16:49.37 | *** join/#oe B_Lizzard (~havoc@athedsl-418087.home.otenet.gr) |
16:52.16 | CIA-15 | 03Joshua Lock <josh@linux.intel.com> 07master * rd1f1ebbe50 10bitbake.git/lib/bb/ui/hob.py: |
16:52.16 | CIA-15 | bb/ui/hob: save changes to bblayers.conf when using Add Layer menu item |
16:52.16 | CIA-15 | Fixes [YOCTO #1283] |
16:52.16 | CIA-15 | Signed-off-by: Joshua Lock <josh@linux.intel.com> |
16:52.26 | CIA-15 | 03Joshua Lock <josh@linux.intel.com> 07master * rb16663e191 10bitbake.git/lib/bb/ui/crumbs/runningbuild.py: (log message trimmed) |
16:52.26 | CIA-15 | bb/ui/crumbs/runningbuild: optionally create list entries sequentially |
16:52.26 | CIA-15 | In b947e7aa405966262c0614cae02e7978ec637095 Bob changed the behaviour of |
16:52.26 | CIA-15 | the RunningBuildModel such that the items are added to the model in a |
16:52.27 | CIA-15 | non-sequential order. |
16:52.27 | CIA-15 | The messages in the view being listed out of order from how they are |
16:52.28 | CIA-15 | received is undesirable for users of the hob UI, therefore this patch adds |
16:52.28 | CIA-15 | 03Joshua Lock <josh@linux.intel.com> 07master * rd1d6bfab17 10bitbake.git/lib/bb/ui/crumbs/runningbuild.py: (log message trimmed) |
16:52.29 | CIA-15 | ui/crumbs/runningbuild: add optional readonly mode, default off |
16:52.29 | CIA-15 | In b947e7aa405966262c0614cae02e7978ec637095 Bob started to introduce code |
16:52.30 | CIA-15 | for a right-click menu, whilst most of the code is non-invasive it does |
16:52.30 | CIA-15 | enable the editable property of the gtk.TreeView which can be confusing. |
16:52.31 | CIA-15 | This change adds a readonly parameter, defaulting to False, to the |
16:52.31 | CIA-15 | RunningBuildTreeView which if True will prevent the editable property from |
16:53.11 | CIA-15 | 03Joshua Lock <josh@linux.intel.com> 07master * r972769e636 10bitbake.git/lib/bb/ui/hob.py: |
16:53.11 | CIA-15 | bb/ui/hob: show build messages are displayed in the order they're received |
16:53.11 | CIA-15 | Use the new sequential option of RunningBuild to ensure this. |
16:53.11 | CIA-15 | Fixes the first part of [YOCTO #1311] |
16:53.12 | CIA-15 | Signed-off-by: Joshua Lock <josh@linux.intel.com> |
16:53.12 | CIA-15 | 03Joshua Lock <josh@linux.intel.com> 07master * rd790386112 10bitbake.git/lib/bb/ui/hob.py: |
16:53.13 | CIA-15 | bb/ui/hob: disable editing in the build messages tree view |
16:53.13 | CIA-15 | Addresses the second part of [YOCTO #1311] |
16:53.14 | CIA-15 | Signed-off-by: Joshua Lock <josh@linux.intel.com> |
16:53.14 | CIA-15 | 03Joshua Lock <josh@linux.intel.com> 07master * r25ec130758 10bitbake.git/lib/bb/ui/crumbs/runningbuild.py: |
16:53.15 | CIA-15 | bb/ui/crumbs/runningbuild: emit signal when command fails with exit signal |
16:53.15 | CIA-15 | Emit the generic build-complete signal when a command fails with an exit |
16:53.45 | *** join/#oe risca (~risca@h241n2-n-a31.ias.bredband.telia.com) |
16:54.11 | CIA-15 | signal enabling the UI to update itself accordingly. |
16:54.11 | CIA-15 | Addresses [YOCTO #1265] |
16:54.11 | CIA-15 | Signed-off-by: Joshua Lock <josh@linux.intel.com> |
17:05.36 | *** join/#oe veganadian (~andrew@CPE0013f7b6cfd2-CM0013f7b6cfce.cpe.net.cable.rogers.com) |
17:05.47 | *** join/#oe morphis (~morphis@dslb-088-070-145-002.pools.arcor-ip.net) |
17:16.57 | *** join/#oe tdebrouw (~tdebrouw@91.182.174.243) |
17:26.36 | Jay7 | lumag: ping |
17:26.45 | Jay7 | lumag: about CF on Collie |
17:27.10 | Jay7 | lumag: there was letter in angstrom-devel ML that have similar issues |
17:27.42 | lumag | Jay7, I got my collie-qemu to boot from CF. But now I got another problem. Now with busybox, which looks like it drops root privileges incorrectly. |
17:28.18 | lumag | Strangely enough it affected only collie build. |
17:28.20 | *** join/#oe likewise (~likewise@095-097-098-131.static.chello.nl) |
17:29.14 | Jay7 | lumag: http://lists.linuxtogo.org/pipermail/angstrom-distro-users/2011-July/003737.html |
17:29.26 | Jay7 | and http://lists.linuxtogo.org/pipermail/angstrom-distro-users/2011-August/003739.html |
17:29.51 | Jay7 | lumag: is login does not working? |
17:30.11 | lumag | no. It's stuck before that |
17:30.20 | Jay7 | iirc, this was most known issue with bb :) |
17:30.50 | lumag | is not a bb fan. |
17:32.40 | lumag | Currently I'm rebuilding collie image. If that won't help, I'll try rebuilding busybox. |
17:32.50 | lumag | But currently the image is unusable :( |
17:33.45 | lumag | Got to go now. |
17:33.47 | lumag | Bye! |
17:33.51 | Jay7 | bb |
17:37.56 | *** join/#oe stefan_schmidt (~stefan@p4FC77394.dip.t-dialin.net) |
17:40.49 | *** join/#oe pepermint (~pepermint@host72-76-dynamic.4-87-r.retail.telecomitalia.it) |
18:13.56 | *** join/#oe florian (~fuchs@sign-4db6ae08.pool.mediaWays.net) |
18:13.56 | *** join/#oe florian (~fuchs@Maemo/community/contributor/florian) |
18:16.40 | *** join/#oe GNUtoo|htcdream (~GNUtoo@90.84.146.232) |
18:26.22 | *** join/#oe pepermint (~pepermint@host217-13-dynamic.58-82-r.retail.telecomitalia.it) |
18:29.24 | *** join/#oe Heinervdm (~thomas@pD9E11DCE.dip.t-dialin.net) |
18:35.21 | *** join/#oe msm (~msm@192.88.168.34) |
18:36.02 | *** join/#oe dijenerate (~dijenerat@204.212.240.159) |
19:01.49 | *** join/#oe woglinde (~heinold@g230117228.adsl.alicedsl.de) |
19:01.59 | *** join/#oe hlzr (~hlzr@adsl-76-212-172-71.dsl.sndg02.sbcglobal.net) |
19:03.44 | *** join/#oe rsalveti (~rsalveti@201.82.65.93) |
19:03.44 | *** join/#oe rsalveti (~rsalveti@linaro/rsalveti) |
19:04.07 | *** join/#oe mwester-laptop (~mwester@nslu2-linux/mwester) |
19:09.42 | khem | msm: bitbake -g will emit the dep graph |
19:09.57 | khem | msm: then you can look around in the .dot files |
19:10.41 | msm | khem: im only getting one proivider for virtual/kernel for my machine |
19:10.50 | kergoth | you can also use the depexp ui |
19:10.54 | msm | i can't seem to find why it's not including linux-yocto |
19:11.03 | khem | yeah depexp ui |
19:11.17 | khem | msm: which machine is it |
19:11.22 | msm | my own |
19:11.27 | msm | so i need to find out what im missing |
19:11.53 | khem | msm: hmmm linux-yocto recipes should know about your machine first |
19:11.55 | msm | i've made a linux-yocto_3.0.bbappend |
19:12.22 | msm | and my preferred providor is linux-yocto |
19:12.47 | khem | what does it show as provider |
19:13.14 | msm | just linux dummy |
19:13.16 | khem | if its not in COMPATIBLE_MACHINE for linux-yocto then it wont show up |
19:13.31 | msm | let me look |
19:13.36 | khem | or something equivalent of COMPATIBLE_MACHINE |
19:13.38 | msm | that was in the bbappend file at one point |
19:13.57 | msm | i had the line commented out⦠but i had it at one point |
19:13.59 | khem | msm: its a regexp |
19:14.15 | khem | so you might have to append to it |
19:14.51 | msm | COMPATIBLE_MACHINE += "(p2020ds)" |
19:14.59 | msm | has that format changed any? |
19:15.31 | khem | no |
19:15.35 | khem | COMPATIBLE_MACHINE = "(qemuarm|qemux86|qemuppc|qemumips|qemux86-64)" |
19:15.48 | khem | is what I see in original .bb |
19:16.05 | msm | right, some older linux-yocto.bbappend has the += format i pasted |
19:16.41 | msm | depexp⦠nice =) |
19:17.33 | khem | just COMPATIBLE_MACHINE_<yourmachine> = "yourmachine |
19:17.34 | khem | " |
19:17.46 | khem | in your .append file |
19:17.49 | msm | i see that notation as well |
19:17.50 | msm | ok |
19:18.48 | khem | you might also need KMACHINE for your machine |
19:18.50 | msm | still just picked up |
19:18.53 | msm | linux-dummy |
19:19.06 | msm | i have KMACHINE_p2020ds= "yocto/standard/fsl-p2020ds" |
19:19.09 | khem | ok |
19:19.14 | msm | not sure what that yocto/standard rferrs too though |
19:19.21 | khem | what does linux-dummy look like |
19:19.49 | msm | its just the most basic recipe |
19:20.01 | msm | provides virtual/kernel - but does nothing |
19:22.03 | khem | PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto" |
19:22.20 | khem | is that somewhere in your conf metadata |
19:22.23 | msm | i have an '=' |
19:22.29 | khem | yes |
19:22.33 | msm | PREFERRED_PROVIDER_virtual/kernel = "linux-yocto" |
19:22.34 | msm | PREFERRED_VERSION_virtual/kernel = "3.0" |
19:23.01 | khem | where do u have it ? |
19:23.04 | khem | in local.conf |
19:23.12 | msm | in machine.conf |
19:23.21 | khem | ok |
19:23.37 | msm | what is this path refer too: yocto/standard/fsl-mpc8315e-rdb |
19:23.45 | msm | in KMACHINE |
19:23.54 | khem | I dont have much idea |
19:24.08 | khem | but its kind of machine specific metadata |
19:24.12 | khem | for that kernel |
19:24.22 | khem | may be .config and patches if any I believe |
19:24.46 | msm | where does this live in the tree? |
19:26.34 | msm | i just can't see where else to provide an override for my new machine |
19:26.44 | msm | grepping through the source for mpc8315 for comparisoon |
19:27.17 | khem | its in kernel sources I think |
19:27.31 | khem | but it should first select the right kernel |
19:27.39 | khem | can you do this |
19:27.50 | khem | bitbake -e virtual/kernel > /tmp/xx |
19:27.55 | khem | and paste xx somewhere |
19:28.14 | msm | yep |
19:34.04 | msm | http://pastebin.com/8Vubys1t |
19:34.09 | msm | still looking at this myslf |
19:37.47 | *** join/#oe captainigloo (~Nico@lan31-4-82-227-130-131.fbx.proxad.net) |
19:41.21 | *** join/#oe gnutoo (~gnutoo@host239-153-dynamic.51-79-r.retail.telecomitalia.it) |
19:45.00 | khem | msm: COMPATIBLE_MACHINE=None |
19:45.03 | khem | this is the problem I think |
19:45.19 | msm | hmm |
19:45.37 | msm | i added my machine to COMPATIBLE_MACHINE in linux-yocto too and it worked |
19:46.28 | khem | msm: ok that means your .bbappend was not really being parsed in |
19:46.55 | msm | i have an idea |
19:46.58 | khem | how does your bbappend look like |
19:47.15 | msm | which makes me look silly if it works |
19:47.18 | khem | do bitbake -DDDD virtual/kernel and paste the output |
19:48.04 | msm | i have to add bbppaned files to BBFILES? |
19:48.23 | msm | bbappend* |
19:48.38 | khem | well yes |
19:48.44 | khem | atleast the search path |
19:49.02 | *** join/#oe galak (~galak@192.88.168.34) |
19:49.07 | msm | and⦠it seems to be working |
19:49.26 | khem | BBFILES += ${LAYERDIR}/recipes-*/*.bbappend" |
19:49.28 | msm | khem: thanks for the assistance |
19:49.30 | khem | np |
19:49.58 | msm | is virtual/kernel selected by most images as well? |
19:50.08 | msm | i dont need to add that as a package somewhere to build it for this machine? |
19:50.22 | khem | msm: usually virtual/kernel is decided by machine |
19:50.34 | *** join/#oe otavio (~otavio@debian/developer/otavio) |
19:51.14 | gnutoo | yes, by machine config or some inc required by machine config |
19:54.58 | galak | fray: around? |
20:00.20 | *** join/#oe sgw (~sgw@c-71-193-189-117.hsd1.wa.comcast.net) |
20:03.29 | *** join/#oe Jefro (~josiermi@nat/intel/x-ipqygpqehzhfbyxu) |
20:14.13 | *** join/#oe rcf (~rcf@227.63-243-81.adsl-dyn.isp.belgacom.be) |
20:16.30 | *** join/#oe mrmoku (~mrmoku@ppp-188-174-19-28.dynamic.mnet-online.de) |
20:24.25 | *** join/#oe jconnolly (~jconnolly@66.43.64.66) |
20:30.29 | *** join/#oe RCFout (~rcf@227.63-243-81.adsl-dyn.isp.belgacom.be) |
20:33.47 | *** join/#oe woglinde_ (~heinold@f052237127.adsl.alicedsl.de) |
20:34.18 | *** join/#oe jconnolly (~jconnolly@66.43.64.66) |
20:35.34 | *** join/#oe dijenerate (~dijenerat@204.212.240.159) |
20:49.55 | *** join/#oe NvrBst (~NvrBst@gateway/tor-sasl/nvrbst) |
20:51.15 | gnutoo | hi Jay7 |
20:51.24 | Jay7 | gnutoo: hi |
20:51.33 | *** join/#oe toto90 (~kakashi@41.141.136.80) |
20:51.48 | gnutoo | Jay7: you were involved in kexecboot right? |
20:51.56 | Jay7 | gnutoo: yes, sure |
20:52.12 | gnutoo | my question is: can you pass atags to a kexeced kenrel |
20:52.20 | gnutoo | for instance from /proc/atags |
20:52.57 | Jay7 | hm.. shouldn't atags be in /proc/cmdline in the end? |
20:53.11 | gnutoo | no it's a different thing |
20:53.35 | Jay7 | can you show contents of /proc/atags? |
20:53.44 | gnutoo | ok |
20:54.39 | gnutoo | I guess it contains not only the cmdline |
20:54.44 | gnutoo | but also other stuff |
20:54.45 | gnutoo | right? |
20:55.11 | Jay7 | seems I don't know.. |
20:55.38 | Jay7 | afaik, it was just other way to pass options to kernel |
20:55.41 | gnutoo | from bug20: |
20:55.45 | gnutoo | http://www.pastie.org/2316308 |
20:56.27 | Jay7 | last part looks like just kernel cmdline options |
20:56.41 | Jay7 | not sure about first part (AT....) |
20:57.02 | gnutoo | let me find other atags |
20:57.06 | Jay7 | better to ask some kernel guys :) |
20:57.11 | gnutoo | (other device) |
21:00.16 | gnutoo | I start to remember |
21:00.29 | gnutoo | I think there is also the board arch number |
21:00.50 | gnutoo | all that I know is that it's the interface between the bootloader and the linux kenrel |
21:01.24 | gnutoo | web is very slow here |
21:01.31 | gnutoo | (far wifi AP + VPN) |
21:02.20 | gnutoo | uboot documentation also say: |
21:02.54 | gnutoo | The maximum clock rate allowed depends on the silicon populated on the EVM.[...]This information is |
21:02.57 | gnutoo | passed to the Linux kernel using the ATAG_REVISION atag. |
21:03.39 | gnutoo | arm/Booting seem to have something too in the linux kenrel documentation |
21:05.06 | gnutoo | so it seem a lot more |
21:05.08 | *** join/#oe hlzr (~hlzr@adsl-76-212-172-71.dsl.sndg02.sbcglobal.net) |
21:05.34 | gnutoo | so who knows how atag works with kexecboot? |
21:05.41 | gnutoo | or rather who could know htat |
21:05.43 | gnutoo | *that |
21:06.10 | Jay7 | gnutoo: s/kexecboot/kernel/ :) |
21:06.46 | Jay7 | kexecboot does not pass atags to next kernel |
21:07.01 | gnutoo | for the kenrel I know |
21:07.02 | Jay7 | but you may create boot.cfg with that options in APPEND |
21:07.21 | Jay7 | as quick workaround |
21:07.28 | *** join/#oe mewyn (~mewyn@arkanoid.coinopcoop.org) |
21:07.32 | gnutoo | I know more or less(less than more) how it works at first boot |
21:07.32 | *** join/#oe svolpe (~Gerrath@unaffiliated/gerrath) |
21:07.50 | gnutoo | but I've no idea why there is no atag options in kexec |
21:07.58 | gnutoo | (the kexec program) |
21:08.21 | Jay7 | gnutoo: if atags just other way to specify kernel cmdline, it have no sense |
21:08.33 | Jay7 | just add options to kexec --command-line or --append |
21:08.36 | gnutoo | as I just said it's more than that |
21:08.45 | gnutoo | it also specify machine number |
21:08.49 | gnutoo | and a lot of stuff |
21:09.05 | gnutoo | my real problem is that since I made kexecboot work with n900 |
21:09.09 | Jay7 | well.. then it's out of my knowledge.. |
21:09.17 | gnutoo | an user complained that many stuff didn't work anymore in maemo |
21:09.34 | gnutoo | + the fact that there is one minute delay between kexec -e and the kernel starting |
21:09.42 | Jay7 | I don't know how to pass atags to kexec'ed kernel.. |
21:09.50 | gnutoo | so I wanted to try passing atags |
21:09.53 | gnutoo | to see..... |
21:09.59 | gnutoo | ok |
21:10.09 | gnutoo | ant should know? right? |
21:10.14 | gnutoo | but he's not here right now |
21:10.46 | Jay7 | gnutoo: he may know more but I'm unsure about details :) |
21:10.51 | gnutoo | ok |
21:11.04 | Jay7 | may be larsc on #qi-hw may say something |
21:11.15 | Jay7 | but he is mips hacker, not arm |
21:11.24 | Jay7 | and iirc atags are arm-specific |
21:11.24 | gnutoo | he's an arm hacker too |
21:11.35 | gnutoo | he does the freerunner kernel too |
21:11.39 | Jay7 | try to bother him then :) |
21:11.41 | *** join/#oe tom_say (~william@cpe-68-203-248-184.stx.res.rr.com) |
21:11.45 | gnutoo | there is a preserve context option |
21:11.48 | gnutoo | what does it do? |
21:12.14 | Jay7 | what do you mean? |
21:12.26 | gnutoo | kexec has: |
21:12.44 | gnutoo | --load-preserve-context |
21:13.15 | gnutoo | the help says: Load the new kernel and preserve context of current kernel during kexec |
21:15.04 | Jay7 | ah |
21:15.08 | Jay7 | seems I understand |
21:15.22 | Jay7 | it does not free'd previous kernel memory e.g. |
21:15.31 | Jay7 | so you may reuse/dump it |
21:15.40 | Jay7 | https://lists.linux-foundation.org/pipermail/linux-pm/2008-March/016953.html |
21:20.03 | gnutoo | ok |
21:20.06 | gnutoo | thanks |
21:28.10 | *** join/#oe ant__ (~andrea@host64-250-dynamic.2-87-r.retail.telecomitalia.it) |
22:33.53 | msm | khem: that yocto/standard/xyz var is actually a branch on the linux tree i believe |
22:34.34 | msm | KMACHINE_p2020ds = "linux-yocto-branch-goes-here" |
22:34.47 | *** join/#oe dijenerate (~dijenerat@173.225.251.175) |
22:39.33 | *** join/#oe tlab (~tlab@c-98-223-20-100.hsd1.in.comcast.net) |
23:05.52 | *** join/#oe bluelightning (~paul@cpc9-lewi14-2-0-cust183.2-4.cable.virginmedia.com) |
23:05.52 | *** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning) |
23:41.23 | *** part/#oe incandescant (~joshual@c-24-21-159-20.hsd1.or.comcast.net) |
23:41.29 | *** join/#oe incandescant (~joshual@c-24-21-159-20.hsd1.or.comcast.net) |
23:42.25 | *** join/#oe incandescant (~joshual@c-24-21-159-20.hsd1.or.comcast.net) |
23:42.50 | *** join/#oe cminyard (~cminyard@pool-173-57-155-71.dllstx.fios.verizon.net) |
23:48.09 | *** join/#oe julianpid (~julianpid@firewall.ctxuk.citrix.com) |