00:04.20 | *** join/#oe NvrBst (~NvrBst@gateway/tor-sasl/nvrbst) |
00:24.22 | bluelightning | Crofton|work: er... there's a meta-zynq on yoctoproject.org as well. .. ??? |
00:25.37 | wmat | bluelightning: lack docs for what? oe-core? |
00:25.44 | bluelightning | wmat: yeah |
00:25.54 | wmat | ah |
00:29.40 | bluelightning | -> sleep |
00:33.06 | *** join/#oe jevin (~jevin@napalm.jevinskie.com) |
01:02.23 | *** join/#oe kgilmer (~kgilmer@cpe-74-73-229-28.nyc.res.rr.com) |
01:07.46 | *** join/#oe slonsiki (~slonsiki@69-12-177-67.dsl.static.sonic.net) |
01:24.21 | *** join/#oe ibot (~ibot@rikers.org) |
01:24.21 | *** topic/#oe is OpenEmbedded Developer Lounge | Web: http://openembedded.org | Repositories: http://git.openembedded.org/ | Primary Repo Mirrors: https://github.com/openembedded | This is not a distro or machine support channel |
01:29.28 | *** join/#oe liuyq (~liuyq0307@221.123.128.226) |
01:32.09 | *** join/#oe liuyq (~liuyq0307@221.123.128.226) |
01:37.29 | *** join/#oe Openfree` (~Openfreer@116.228.88.131) |
01:38.19 | *** join/#oe liuyq (~liuyq0307@221.123.128.226) |
01:42.17 | dlan | hi, I'm running OE with Gentoo Linux as HOST, and have problem setup with qemu-network |
01:42.42 | dlan | my host is 192.168.90.x, and seems qemu client setup with 192.168.7.x |
01:43.23 | dlan | running "ifconfig" in qemu client, show no ip, also udhcpc service fail |
01:44.09 | *** join/#oe liuyq (~liuyq0307@221.123.128.226) |
02:02.43 | *** join/#oe kgilmer (~kgilmer@cpe-74-73-229-28.nyc.res.rr.com) |
02:33.06 | *** join/#oe nerdboy (~sarnold@dsl-66-59-252-223.static.linkline.com) |
02:37.29 | *** join/#oe nerdboy (~sarnold@dsl-66-59-252-223.static.linkline.com) |
02:37.37 | *** join/#oe nerdboy (~sarnold@gentoo/developer/nerdboy) |
03:05.51 | *** join/#oe blupp (~blupp@188.99.239.33) |
03:19.55 | *** join/#oe slonsiki (~slonsiki@69-12-177-67.dsl.static.sonic.net) |
03:34.10 | *** join/#oe rob_w__ (~bob@ppp-188-174-45-100.dynamic.mnet-online.de) |
03:42.39 | *** join/#oe kgilmer (~kgilmer@cpe-74-73-229-28.nyc.res.rr.com) |
03:56.52 | *** join/#oe nitink (nitink@nat/intel/x-elmsnnnxcwgbvwsk) |
03:58.53 | *** join/#oe joshin (~josh@ip72-201-94-139.ph.ph.cox.net) |
03:58.53 | *** join/#oe joshin (~josh@unaffiliated/joshin) |
04:02.27 | *** join/#oe cheng (~cheng@175.139.221.223) |
04:16.45 | *** part/#oe cminyard (~cminyard@pool-173-57-151-210.dllstx.fios.verizon.net) |
05:44.41 | *** join/#oe clio (~andrej@85.159.109.222) |
06:39.34 | *** join/#oe rsalveti` (~rsalveti@177.133.172.122) |
06:48.35 | *** join/#oe rsalveti (~rsalveti@linaro/rsalveti) |
06:55.15 | *** join/#oe eballetbo (~eballetbo@249.Red-80-33-164.staticIP.rima-tde.net) |
07:04.54 | *** join/#oe Guest10839 (~quassel@151.65.162.110) |
07:08.33 | *** join/#oe rob_w (~bob@93.104.205.194) |
07:08.33 | *** join/#oe rob_w (~bob@unaffiliated/rob-w/x-1112029) |
07:08.57 | *** join/#oe kristoffer (~kristoffe@c-95dbe555.010-30-6c6b7012.cust.bredbandsbolaget.se) |
07:10.56 | *** join/#oe risca (~risca@h87-96-186-215.dynamic.se.alltele.net) |
07:14.12 | *** join/#oe apelete (~apelete@91.224.149.44) |
07:21.27 | *** join/#oe florian (~fuchs@port-217-146-132-69.static.qsc.de) |
07:21.27 | *** join/#oe florian (~fuchs@Maemo/community/contributor/florian) |
07:22.33 | *** join/#oe Dodji (~musashi@vpn-konference.ms.mff.cuni.cz) |
07:25.04 | *** join/#oe rob_w__ (~bob@93.104.205.194) |
07:26.04 | *** join/#oe morphis (~morphis@dslb-088-071-185-196.pools.arcor-ip.net) |
07:28.54 | *** join/#oe rschus (~rschus@31.32.193.216) |
07:29.34 | *** join/#oe risca (~risca@h240n6-n-a31.ias.bredband.telia.com) |
07:30.17 | *** join/#oe morphis_ (~morphis@dslb-088-071-185-196.pools.arcor-ip.net) |
07:37.44 | *** join/#oe fog (~fog@debian/developer/fog) |
07:43.37 | *** join/#oe ao2 (~ao2@2001:1418:117::1) |
07:54.46 | *** join/#oe ant_work (~ant@host6-80-static.42-85-b.business.telecomitalia.it) |
08:22.22 | *** join/#oe bluelightning (~paul@83.217.123.106) |
08:22.22 | *** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning) |
08:30.04 | *** join/#oe eballetbo (~eballetbo@249.Red-80-33-164.staticIP.rima-tde.net) |
08:31.20 | *** join/#oe 18WABFRYI (~jason@pdpc/supporter/active/jkridner) |
08:32.53 | *** join/#oe woglinde (~henning@f052066138.adsl.alicedsl.de) |
08:41.28 | *** join/#oe nitink (~nitink@134.134.137.73) |
08:45.27 | bluelightning | morning all |
08:48.00 | dlan | bluelightning: afternoon here |
08:49.16 | bluelightning | dlan: aha, but http://www.total-knowledge.com/~ilya/mips/ugt.html |
08:49.21 | bluelightning | ;) |
08:51.25 | dlan | bluelightning: oh, so, morning~ |
08:53.50 | dlan | bluelightning: do you know who responsible for mips related patch? I'd like to get mipsel support in, but seems no one interest, or care?! |
08:54.25 | dlan | the patch titled with "runqemu/mips: adjust runqemu script to support mipsel machine", which sent to the OE-core |
08:54.57 | dlan | it's actually tivial, but I'd like get in, also if reject, I could carry it myself |
08:55.04 | bluelightning | dlan: things are a bit tricky atm, we went through a period of very nasty breakage so RP_ is only taking obvious patches atm |
08:55.16 | bluelightning | dlan: you could reply to your own patch with a ping |
08:56.10 | dlan | bluelightning: actually I replied, but I don't who I should ping to.. |
08:56.33 | dlan | yeah, bug fix only? no feature added, probably.. |
09:03.01 | *** join/#oe florian (~fuchs@Maemo/community/contributor/florian) |
09:33.22 | *** join/#oe silvio__ (~silvio@fireone.i3p.it) |
09:33.30 | silvio__ | hi all |
09:40.12 | *** join/#oe ensc|w (~ensc@www.sigma-chemnitz.de) |
09:46.34 | bluelightning | dlan: I just had a look at your patch and replied |
09:47.45 | dlan | bluelightning: yeah, I got your reply |
09:48.38 | dlan | previously, i'm using "case ..esac" and then thought substitution maybe simplier |
09:51.26 | *** join/#oe florian (~fuchs@port-217-146-132-69.static.qsc.de) |
09:51.26 | *** join/#oe florian (~fuchs@Maemo/community/contributor/florian) |
09:52.32 | *** join/#oe rob_w (~bob@unaffiliated/rob-w/x-1112029) |
09:53.46 | dlan | bluelightning: how about this, if you're ok, I will re-send, http://pastebin.ca/2169918 |
09:55.27 | bluelightning | dlan: yep, looks good to me |
09:55.46 | dlan | bluelightning: ok, thanks |
09:56.42 | *** join/#oe gcoville (~ghc@c-67-172-180-95.hsd1.ca.comcast.net) |
10:05.14 | *** join/#oe vitus (~vitus@145.253.169.210) |
10:09.34 | *** join/#oe dos1 (~dos@unaffiliated/dos1) |
10:17.46 | *** join/#oe nitink1 (~nitink@134.134.137.73) |
10:33.01 | *** join/#oe apelete (~apelete@91.224.149.44) |
10:35.34 | *** join/#oe snkt (~snkt@122.170.104.85) |
10:46.25 | *** join/#oe mickey_office (~mickey@e182221015.adsl.alicedsl.de) |
10:48.20 | *** join/#oe nitink (~nitink@134.134.137.73) |
10:50.21 | pb_ | morning all |
10:50.23 | pb_ | stabs directfb |
10:51.00 | pb_ | their commit aaebf60b86acc666e4c680e39d0f72676b8298d5 is the most misguided fix for a "compiler warning" that I have seen for a long time. |
10:51.35 | *** join/#oe nitink (nitink@nat/intel/x-abcoylhogvkzwnyn) |
10:53.01 | *** join/#oe khem (~khem@99-57-140-209.lightspeed.sntcca.sbcglobal.net) |
10:54.29 | Crofton|work | pb_, which repo? |
10:54.57 | pb_ | the main git.directfb.org one |
10:55.06 | pb_ | http://git.directfb.org/?p=core/DirectFB.git;a=commitdiff;h=aaebf60b86acc666e4c680e39d0f72676b8298d5 |
11:08.21 | *** join/#oe einball (einball@gateway/shell/c-base/x-hhqlmyysfdwbadhk) |
11:08.42 | einball | OE fails to build pseudo-native using the angstrom oebb.sh script. |
11:08.45 | einball | http://paste.frubar.net/15022 This is the log - Where could I start? |
11:08.54 | einball | *start to solve this problem. |
11:09.06 | Crofton|work | it likes like your machine is missing some headers |
11:10.48 | Crofton|work | /usr/include/gnu/stubs-64.h do you have this file? |
11:11.20 | einball | Is is MY machine or did OE miss to download them? as fas as I understand, OE should not use the local installed libs for crosscompilation? |
11:11.34 | Crofton|work | this is a native package |
11:11.43 | Crofton|work | so I believe it is using the host compiler |
11:11.56 | Crofton|work | your machine |
11:12.12 | Crofton|work | OE tries hard not to dpeend to much on your machine, but some things it needs |
11:12.55 | einball | ah, okay. The file is missing. So, I'll search for its dependencies. |
11:13.20 | Crofton|work | glibc-devel on Fedora |
11:13.23 | *** join/#oe likewise (~likewise@203-158-ftth.onsneteindhoven.nl) |
11:13.37 | likewise | gm |
11:13.40 | Crofton|work | OE should have checked before starting :) |
11:13.41 | Crofton|work | gm |
11:14.22 | einball | hmm, Debian did move to the eglibc some time ago afair ... I'll check |
11:14.36 | einball | ah yup |
11:14.44 | likewise | florian: You seem to have worked with i.MX a lot. Aware of any issues with the i.MX28 FEC behaving erratically during init? |
11:15.53 | einball | okay, lets try again |
11:22.46 | einball | It was not the clib |
11:22.48 | *** join/#oe Crofton (~balister@pool-96-240-162-243.ronkva.east.verizon.net) |
11:26.31 | einball | Hold on ... Shame on me |
11:26.37 | Crofton|work | heh |
11:26.43 | Crofton|work | you had me worried |
11:27.23 | einball | Debian moved to the eglibc, so I installed the eglibc dev package |
11:27.37 | einball | but this was obviously not the package it wanted |
11:28.21 | einball | /usr/bin/ld: i386 architecture of input file `/home/einball/oe/setup-scripts/build/tmp-angstrom_v2012_05-eglibc/sysroots/x86_64-linux/usr/lib/libsqlite3.a(sqlite3.o)' is incompatible with i386:x86-64 output |
11:28.42 | einball | I really ... hate this :) |
11:29.04 | einball | first it depends on the 64bit then it complains about not being able to link. |
11:36.04 | florian | likewise: hmm... not yet, but maybe i.MX28 is somewhat different and this is the one I have not done that much with personally |
11:43.14 | *** join/#oe stuk_gen (~quassel@151.65.162.110) |
11:45.21 | likewise | florian: ok thanks |
11:45.50 | *** join/#oe housel (~user@mccarthy.opendylan.org) |
11:46.02 | *** join/#oe snkt (~snkt@122.170.104.85) |
11:46.29 | *** join/#oe thaytan (~thaytan@113.94.233.220.static.exetel.com.au) |
11:46.29 | *** join/#oe scoutcamper (scoutcampe@nasadmin/webteam/scoutcamper) |
11:56.22 | *** join/#oe mickey_office (~mickey@e182221015.adsl.alicedsl.de) |
12:00.21 | *** join/#oe roric (~roric@194-237-7-146.customer.telia.com) |
12:07.46 | *** join/#oe eFfeM_work (~frans@D4B268BA.static.ziggozakelijk.nl) |
12:15.18 | *** join/#oe likewise (~likewise@203-158-ftth.onsneteindhoven.nl) |
12:17.25 | ensc|w | einball: imx28 + recent oe (core + meta) + fedora 17 (x86_64) works like a charm here... |
12:18.15 | ensc|w | however, fec init is tricky because reset must be applied manually by keeping modX pins high |
12:20.21 | likewise | ensc|w: thanks for chiming in. what are the modX pins? |
12:21.53 | ensc|w | 3 pins to the external ethernet phy (afair, rx0/1 + rx_en for the reference lan87xx phy) |
12:26.34 | *** join/#oe CMoH (~cipi@78.96.83.205) |
12:26.34 | *** join/#oe CMoH (~cipi@unaffiliated/c-moh) |
12:35.13 | *** join/#oe mhnoyes (~mhnoyes@173-86-187-103.dr01.myck.or.frontiernet.net) |
12:35.13 | *** join/#oe mhnoyes (~mhnoyes@sourceforge/sitedocs/mhnoyes) |
12:45.43 | *** part/#oe azi` (azi@95.87.160.17) |
12:59.22 | *** join/#oe mickey_office (~mickey@e182221015.adsl.alicedsl.de) |
13:03.23 | *** join/#oe rob_w (~bob@ppp-188-174-45-100.dynamic.mnet-online.de) |
13:03.23 | *** join/#oe rob_w (~bob@unaffiliated/rob-w/x-1112029) |
13:03.25 | *** join/#oe udovdh (~udovdh@pindarots.xs4all.nl) |
13:24.05 | *** join/#oe Leatherface- (~leatherfa@gw2.pite.biz) |
13:34.20 | *** join/#oe nitink (~nitink@134.134.137.73) |
13:45.47 | likewise | ensc|w : tnx, need to check that. |
13:47.51 | bluelightning | ah, i see i.mx28 support is in meta-fsl-arm now... I know at least one person who will be pleased by that |
13:48.00 | bluelightning | :) |
13:51.01 | likewise | bluelightning: referring to self? :) |
13:51.42 | bluelightning | no, I don't have one of those devices, but I spoke to one person who was keen to move to OE-core but couldn't due to the lack of a bsp for that device |
13:52.21 | likewise | There is tons of BSP's for the i.MX28 for OE over the last five years. (That might be the exact problem) |
13:53.41 | *** join/#oe cminyard (~cminyard@pool-173-57-151-210.dllstx.fios.verizon.net) |
13:56.06 | *** join/#oe kgilmer (~kgilmer@rrcs-108-176-50-210.nyc.biz.rr.com) |
13:59.39 | *** join/#oe kgilmer (~kgilmer@rrcs-108-176-50-210.nyc.biz.rr.com) |
14:01.20 | slapin | likewise: any examples of such BSPs? |
14:01.21 | hrw | Crofton|work: but please check by compiling hello.c instead of stat(${inludedir}/gnu/stubs.h) :D |
14:02.25 | *** join/#oe fcooper (~a0273011@nat/ti/x-aofulxffugrqvldp) |
14:05.37 | likewise | slapin: http://www.gitorious.org/schnitzeltony-oe-meta/meta-freescale |
14:06.13 | likewise | slapin: and there were some OE classic "BSP";s floating around. |
14:06.39 | likewise | slapin: different boards, different kernels, etc etc. |
14:07.59 | einball | ensc|w: I really don't understand, where the problem is and why nothing works on my machine :P |
14:09.35 | einball | I compiled PHP on my beagleboard .. because I needed it. But that took like forever :D |
14:10.43 | *** join/#oe ericben (~ebenard@pac33-2-82-240-38-71.fbx.proxad.net) |
14:12.12 | slapin | any at91 BSPs, by the way? |
14:14.23 | *** join/#oe eephillip (~eephillip@pdpc/supporter/student/eephillip) |
14:17.24 | *** join/#oe ChrisD1 (~ChrisD@merak.alcor.co.uk) |
14:22.16 | likewise | slapin: well, yes for OE Classic all popular embedded devices (until 2011) are covered AFAIK. Have you looked at OpenEmbedded Classic? |
14:22.32 | *** join/#oe nitink (nitink@nat/intel/x-fznaymvmtbktgzzt) |
14:22.33 | likewise | slapin: I have used at91 /9200 and G45 series. |
14:23.34 | likewise | ensc|w: can you show a kernel that pull those pins high explicitly from software (I assume temporarily config'ing these pins as GPO's? |
14:34.05 | *** join/#oe sgw (~sgw@c-71-193-189-117.hsd1.wa.comcast.net) |
14:35.10 | *** join/#oe roric (~roric@194-237-7-146.customer.telia.com) |
14:36.10 | *** join/#oe mickey_office (~mickey@e182221015.adsl.alicedsl.de) |
14:41.36 | slapin | likewise: I try to migrate from OE-classic and too lazy to make my own layer hoping somebody already made that (even Atmel themselves) |
14:42.32 | slapin | likewise: I'm mostly interested in 9260 and 9g20 |
14:43.47 | slapin | and I beleive, that since interest in at91s is so low these days, an architecture is almost dead |
14:43.48 | likewise | slapin: google: http://gitorious.org/oe-atmel/meta-atmel |
14:44.05 | likewise | slapin: no, don't assume it to be dead. |
14:44.40 | silvio__ | when i try to compile qt-embedded-gless i obtain error like this, some suggest? |
14:44.40 | likewise | slapin: assuming it *is* dead, what SoC has taken it's place? |
14:44.54 | silvio__ | ../../include/QtCore/../../src/corelib/kernel/qcoreevent.h:75:9: error: expected identifier before numeric constant |
14:44.54 | silvio__ | | ../../include/QtCore/../../src/corelib/kernel/qcoreevent.h:75:9: error: expected '}' before numeric constant |
14:44.54 | silvio__ | | ../../include/QtCore/../../src/corelib/kernel/qcoreevent.h:75:9: error: expected unqualified-id before numeric constant |
14:44.54 | silvio__ | | ../../include/QtCore/../../src/corelib/kernel/qcoreevent.h:298:17: error: expected ')' before 'type' |
14:45.20 | slapin | likewise: last commit is from 2011 in that repository |
14:45.36 | silvio__ | its seams i need some includes, but it's not clear for me |
14:46.25 | slapin | likewise: where I live, people replace at91s with low-end Samsung s3c24xx and i.MX23 |
14:46.37 | likewise | slapin: yeah well, did the chips change afterwards? Maybe it's super stable :) |
14:46.49 | likewise | slapin: where do you live? |
14:46.51 | einball | and ARM :o |
14:47.07 | slapin | likewise: Russia |
14:47.14 | likewise | einball: arm what? |
14:47.36 | likewise | einball: we are only talking about ARM chips in this discussion, AFAIK |
14:48.22 | slapin | likewise: but I don't see new projects with at91 outsourced to me anymore, which also means something. |
14:48.38 | likewise | slapin: there is a trend to just pick the cheapest parts, there is a lot of choice when you do not need features like SATA, H.264. |
14:49.11 | likewise | slapin: what is the current trend than? i.MX? |
14:49.43 | einball | likewise: Cortex-A* CPU's |
14:49.50 | slapin | likewise: but people tend to stick to the same things, why people change from at91 to mxs without any particular reason? that's costs money after all. |
14:50.17 | einball | at91 is ARM? |
14:50.38 | slapin | einball: at91 contains ARM core |
14:50.44 | einball | oh, didn't know that |
14:51.01 | einball | Many people here in germany tend to use Cortex µC |
14:51.03 | slapin | einball: most of these are arm926ej-s |
14:51.19 | slapin | einball: at91s that is |
14:51.30 | likewise | einball: with Linux or without? |
14:51.37 | einball | not or .. and! |
14:51.42 | einball | They use both |
14:51.45 | slapin | einball: 'Cotrex' is too generic term |
14:52.20 | einball | I personally like to use cortex-A* |
14:52.39 | einball | A friend of mine says he plays better with the M series |
14:53.14 | einball | But I don't have enought knowledge to program them. |
14:53.15 | slapin | einball: m series are very small mcus, a series are application processors or cpus. |
14:53.35 | einball | I know |
14:53.45 | slapin | einball: read manuals at arm.com, they are quite open these days, and vendor's datasheet |
14:54.27 | *** join/#oe darknighte (~mgc@pdpc/supporter/professional/darknighte) |
14:54.32 | einball | Depends on your application, but they develop gas stations |
14:54.33 | slapin | einball: if you have proper dev board, it is usually no more than 2 weeks to start with new processor |
14:54.37 | einball | so they might go with both |
14:54.54 | slapin | einball: depends on your applications, actually |
14:55.36 | *** join/#oe florian (~fuchs@sign-4db6bc00.pool.mediaWays.net) |
14:55.36 | *** join/#oe florian (~fuchs@Maemo/community/contributor/florian) |
14:55.46 | einball | My knowledge stops at Arduino and Atmega's |
14:57.02 | einball | Iam more the hardware and signaling guy |
14:57.20 | einball | *signal |
14:57.57 | *** join/#oe hollisb (~hollisb@192.94.38.34) |
14:59.33 | *** join/#oe ensc (~irc-ensc@fedora/ensc) |
15:01.58 | *** join/#oe xmlich02 (~imlich@2001:67c:1220:80c:0:eb4d:725f:a14b) |
15:02.13 | slapin | einball: the knowledge on how to bring up these arm beasts won't harm even if you want to specialize, because finding bad soldering might be a huge task (last time it took a week and 3 broken boards for me). |
15:03.20 | einball | slapin: that's the problem. I study electrical engineering and basically learn nothing about manufacturing. |
15:04.05 | einball | So I'll have to learn on my own - very hard and frustrating if you have almost no time to do so because you will fall behind with your studies |
15:04.52 | slapin | einball: buy parts and solder something simple yourself, that's great experience, very cheap, lots of fun and doesn't take too much time |
15:05.29 | slapin | einball: some led blinker is a good start |
15:05.56 | einball | Currently I build a 2000 parts HF transceiver, so I know how to solder and I like it. But it's the rough "surface" of that bare metal that worries me |
15:06.21 | einball | *I currently |
15:06.38 | einball | (Programming part) |
15:07.57 | slapin | likewise: as for at91, 'super-stable' approach is good for supporting legacy stuff, and is very bad for developing new product, so Atmel approach shows well, that they relly consider their architecture as legacy. |
15:08.33 | slapin | likewise: while hardware doesn't change, software is continuousely evolving. |
15:11.06 | *** join/#oe mickey_office (~mickey@e182221015.adsl.alicedsl.de) |
15:11.11 | slapin | einball: processor/mcu-based devices can be far simple than that, so you can take some cortex-m0, some power supplies, capacitors, crystal, ft2232 for jtag and uart, and have device under 100 parts which can do lots of things, and you learn new processor. |
15:12.20 | slapin | einball: that's fun. because you solder it for 1-2 hours and have something working. |
15:14.04 | einball | I'll maybe start in half a year. Before I may do another µC I'll have to learn programming the 8051 in assembler :-/ |
15:14.30 | Crofton | bluelightning, the proto=file and path to local git repo does the trick, at least in classic |
15:14.34 | einball | (university stuff .. ) |
15:15.06 | *** join/#oe udovdh (~udovdh@pindarots.xs4all.nl) |
15:15.08 | bluelightning | Crofton: ah right, that should also work in core |
15:16.26 | slapin | einball: 8051 is really legacy. AVR and ARM are much much simpler, and less brain damaged... |
15:16.36 | silvio__ | someone use gles with nvidia tegra? |
15:16.48 | silvio__ | qt-embedded-gles |
15:16.50 | einball | I know ... And I hate my professor for using this old stuff. |
15:17.39 | *** join/#oe woglinde (~heinold@g225075060.adsl.alicedsl.de) |
15:27.16 | likewise | silvio__: curiosity: which tegra chip and board are you using? |
15:28.13 | woglinde | hehe tegra |
15:29.58 | bluelightning | woglinde: don't you have a tegra-based netbook? |
15:30.40 | woglinde | bluelightning yes I have tegra2 |
15:34.15 | silvio__ | toradex t20 |
15:34.29 | slapin | woglinde: could you please tell the model of tegra2 netbook? |
15:34.29 | woglinde | *g* |
15:34.30 | *** join/#oe nitink (nitink@nat/intel/x-yqbqqinjistaqknq) |
15:34.34 | silvio__ | likewise: toradex t20 |
15:34.37 | woglinde | slpain ac100 |
15:34.42 | woglinde | args slapin |
15:34.50 | woglinde | and I bought the tablet too |
15:34.55 | slapin | woglinde: is it tegra2? |
15:34.59 | woglinde | yes |
15:35.01 | woglinde | both |
15:35.24 | woglinde | tablet is folio100 |
15:35.30 | woglinde | still running android |
15:35.32 | slapin | wow, than I have tegra2 too, I thought it was tegra1 |
15:35.39 | woglinde | no |
15:35.58 | woglinde | there wasnt any real customer tegra1 device so far |
15:36.29 | slapin | woglinde: I run ubuntu 11 on ac100, it somewhat works, no drivers, though. |
15:36.45 | slapin | woglinde: that's cool to know |
15:36.51 | woglinde | upgrade to 12.04 and kernel 3.1 |
15:37.17 | woglinde | btw. because of tegra I have one commit in linux ;) |
15:37.25 | likewise | toradex t20 was the red cross sponsoring action at EW2012 |
15:37.41 | slapin | woglinde: I think it won't help with graphics much. |
15:37.41 | likewise | almost bought one, but it would end up on the pile here |
15:38.02 | woglinde | I didnt finish the tegra-layer so far |
15:38.53 | slapin | I'd prefer to install OE on that netbook, to reduce memory footprint and make it somewhat faster. |
15:39.02 | woglinde | uhm |
15:39.16 | woglinde | install blackbox or some else wm |
15:39.23 | woglinde | you dont get much ram with oe |
15:39.28 | tzanger | I have a recipe question... Currently I have a recipe which takes a pristine source and applies a patch to it. When I update the patch, I have to update the PR to ensure that the system picks up the changed patch when building the recipe. |
15:39.55 | *** join/#oe morphis_ (~morphis@dslb-088-071-185-196.pools.arcor-ip.net) |
15:40.02 | woglinde | you have to update the PR so your package repos know there is an update |
15:40.30 | tzanger | I'd like to generate the patch every time the recipe is run. I can use svn diff to do this, but I'm not sure how to force OE to *always* rebuild the package since I dont' think I want to update the PR every single time the build is done |
15:40.41 | slapin | woglinde: I'd prefer to cross-compile stuff for it, et al. |
15:40.56 | woglinde | slapin do what you want ;) |
15:41.01 | woglinde | its opensource |
15:42.52 | silvio__ | likewise: so what u use? |
15:43.00 | tzanger | woglinde: does the PR have to be ever-increasing, or does it just have to be different from the last build? |
15:43.12 | woglinde | tzanger o.O |
15:43.37 | woglinde | when you update you either increase the pr or put it pack to 0 if it is a major update |
15:43.45 | woglinde | ups back |
15:43.52 | *** join/#oe kgilmer (~kgilmer@rrcs-108-176-50-210.nyc.biz.rr.com) |
15:43.57 | woglinde | hi kgilmer |
15:44.07 | likewise | silvio__: Currently I have AVR32, PowerPC 2020, i.MX53 projects |
15:44.45 | tzanger | woglinde: can I make hte PR the md5sum of the patchfile? that way the PR will be different if the patch changed from last time, and remain the same if not |
15:44.46 | likewise | silvio__: and i.MX28 |
15:44.56 | tzanger | er.. wait. PR is checked before it decides to build. that won't work at all |
15:45.59 | woglinde | tzanger what is your problem? |
15:46.10 | woglinde | new version -> PR change |
15:47.32 | tzanger | woglinde: the patch is generated upon package build. I don't want to manually create the patch and manually update PR when the patch changed |
15:47.53 | woglinde | o.O |
15:48.01 | tzanger | basically if I ask bitbake to build the package, I want to generate the patch and build only if the patch is different from last time |
15:48.03 | tzanger | (or there was no last time) |
15:48.32 | woglinde | tzanger I dont think bitbake support this |
15:48.43 | woglinde | and I dont know whats so hard on PR change |
15:48.48 | tzanger | I'm trying to determine how bitbake decides whether to build something |
15:49.10 | tzanger | woglinde: automated daily builds with a development team that is changing the branch I'm generating a patch from |
15:49.22 | tzanger | I guess I can script it to automatically mangle the recipe but that sounds messy |
15:49.37 | tzanger | PR change isn't hard... unless you have to generate the patch and bump PR every night |
15:50.06 | woglinde | choose another development process |
15:51.12 | tzanger | what I can do is set up a subversion commit hook that generates the patch and updates the PR, It hink |
15:51.12 | tzanger | er think |
16:04.22 | tzanger | woglinde: Do I have to update PR if my URI_SRC is a repository? Will OE always pull from the repo and detect changes when asked to build? |
16:04.43 | khem | tzanger: use OE-Core |
16:04.46 | tzanger | i.e. the recipe does not change, but the patch file in the SRC_URI svn:// repo changed |
16:04.51 | khem | and you will get what you want |
16:04.59 | tzanger | I've never heard of OE-Core, googling |
16:05.10 | khem | its OE nextgen |
16:05.12 | tzanger | ah |
16:05.27 | khem | woglinde: howdy |
16:05.28 | tzanger | there are plans to move to that but I can't move everything over from Angstrom for this |
16:05.41 | khem | woglinde: did systemd/uclibc work for you ? |
16:06.03 | khem | tzanger: angstrom as of today uses OE-Core too |
16:06.17 | khem | so if you use latest angstrom you should get it as well |
16:07.16 | woglinde | hi khem |
16:07.23 | tzanger | yes but that's the same issue... updating the entire repo and fixing whateve breakage is found |
16:07.43 | tzanger | we'll update in time but updating *today* or for this software cycle isn't possible |
16:07.59 | woglinde | khem sorry didnot test latest state |
16:08.00 | khem | then live with what you have is only option for you |
16:08.08 | khem | woglinde: please try it out |
16:08.18 | khem | woglinde: I didnt have enought cycles |
16:08.25 | tzanger | khem: I am, I'm asking questions about what OE does |
16:08.32 | woglinde | khem uclibc-git? |
16:08.36 | khem | woglinde: yes |
16:08.42 | woglinde | okay |
16:08.50 | woglinde | hm baby is angry |
16:08.59 | khem | woglinde: I want angstrom to work with uclibc |
16:09.05 | khem | woglinde: you got a second one ? |
16:09.10 | tzanger | if I have a svn:// URI in SRC_URI and bitbake is asked to build the recipe, does it check ot see if the svn repo changed from the last time the recipe was built? |
16:09.15 | woglinde | khem yes |
16:09.48 | khem | tzanger: if you use AUTOREV for SRCREV then it will |
16:10.10 | khem | woglinde: both boys ? or mix or girls |
16:10.37 | tzanger | khem: aha... let me look those up, thank you |
16:10.56 | woglinde | yes both boys |
16:11.20 | tzanger | woglinde: how old is the baby? I just had a son on the 3rd |
16:11.31 | *** join/#oe JDuke128 (~kadirbaso@188.3.61.14) |
16:11.43 | khem | woglinde: 3rd July, ? |
16:13.44 | *** join/#oe mr_science (~sarnold@net-cf9a4e91.cst.impulse.net) |
16:13.44 | *** join/#oe mr_science (~sarnold@gentoo/developer/nerdboy) |
16:19.05 | silvio__ | bb |
16:19.18 | silvio__ | quit |
16:23.30 | tzanger | khem: hm, ok, if I'm reading this correctly then in my local.conf I would add "SRCREV_my-recipe-here ?= ${AUTOREV}" to local.conf. That would instruct OE to always pull from the repo for that package, is that correct? |
16:24.13 | khem | you would do it in recipe |
16:24.18 | tzanger | my local.conf has no lines relating to packages right now, which is why I'm unsure that I understand the OE user manual |
16:25.28 | tzanger | hm ok, the documentation has a bug then. |
16:25.29 | tzanger | it states "If you really absolutely have to follow the latest commits, you can do that by adding ’SRCREV_pn-linux-davinci ?= ${AUTOREV}’ to your local.conf, for example. In this case, you’d build against the most recent and unstable source for the pn-linux-davinci package." |
16:25.52 | woglinde | khem 16.5 |
16:28.16 | *** join/#oe kgilmer (~kgilmer@rrcs-108-176-50-210.nyc.biz.rr.com) |
16:38.47 | khem | woglinde: congrats |
16:39.00 | khem | woglinde: my kids are 4 and 6 |
16:39.11 | khem | little bigger troubles than you |
16:39.16 | khem | but still troubles :) |
16:47.31 | tzanger | khem: wait until they hit their teens, or in the case of daughters, about 8 :-) |
16:50.45 | tzanger | I've got them from 17 down to two weeks. little ones are easier and fun, but around 7-12 for boys is really nice |
16:54.06 | *** join/#oe HokieTux (~HokieTux@157.22.28.10) |
16:59.05 | *** join/#oe NightMonkey (~NightrMon@pdpc/supporter/professional/nightmonkey) |
17:05.35 | *** join/#oe fcooper (~a0273011@nat/ti/x-jcyouaqffcsxhugv) |
17:12.21 | *** join/#oe challinan (~challinan@173-10-226-189-BusName-WestFlorida.hfc.comcastbusiness.net) |
17:13.19 | *** join/#oe challinan (~challinan@173-10-226-189-BusName-WestFlorida.hfc.comcastbusiness.net) |
17:14.29 | hrw | hi |
17:14.46 | hrw | meta-kirkwood is the only kirkwood support OE has nowadays? |
17:16.58 | *** join/#oe strnx (strnx@204.12.223.119) |
17:18.42 | *** join/#oe onoffon (~khem@m890536d0.tmodns.net) |
17:20.38 | *** join/#oe playya (~playya@unaffiliated/playya) |
17:22.17 | *** join/#oe apelete (~apelete@109.190.26.176) |
17:25.36 | *** join/#oe Desert (~quassel@192.100.196.159) |
17:27.37 | likewise | hrw: AFAIK yes. |
17:27.53 | likewise | hrw: and it's probably not (much) newer than classic. |
17:28.05 | woglinde | khem what do I need in local.conf for master of meta-angstroem? |
17:28.13 | likewise | hrw: haven't touched it though for long |
17:28.31 | woglinde | all I tried so far it did not find the right version |
17:28.32 | hrw | likewise: I unbricked my sheevaplug and it runs fine with HEAD uboot/kernel |
17:28.34 | likewise | hrw: I will open that can of worms, when Marvell gives me Armada XP |
17:28.39 | hrw | likewise: :D |
17:28.52 | hrw | armadaxp... I played a little with their devboard |
17:28.55 | likewise | hrw: so far, they cannot push Reply on their email :) |
17:29.04 | likewise | hrw: drool, I need the PCIe on it |
17:29.16 | likewise | hrw: 2x PCIe x4 right |
17:29.39 | likewise | hrw: How can I get one? Should I apply at Canonical? |
17:30.16 | hrw | likewise: I do not know who at Canonical has them even |
17:30.27 | hrw | likewise: I spend time at Linaro rather then at Canonical |
17:30.38 | hrw | and the one I played with was not Canonical either |
17:31.15 | likewise | hrw: Marvell is hard to approach, even their dist is not happy about small customers |
17:33.24 | *** join/#oe pidge (pidge@nat/intel/x-hrvtlfjqnwurfqsm) |
17:33.57 | woglinde | hm okay found it |
17:38.12 | *** join/#oe strnx (strnx@204.12.223.119) |
17:42.19 | Desert | Crofton: no i compiled that version |
17:44.26 | *** join/#oe NvrBst (~NvrBst@gateway/tor-sasl/nvrbst) |
17:44.36 | woglinde | hm or not |
17:44.38 | woglinde | damn |
17:45.38 | woglinde | arsg typo |
17:46.54 | hrw | lovely ;) |
17:47.33 | hrw | I flashed fresh uboot, booted 5MB kernel (with busybox initramfs) and have network and angstrom repositories available so can setup ubifs etc |
17:48.41 | onoffon | hrw cool |
17:49.20 | onoffon | hrw how is oe being used in linaro now i wonder |
17:51.03 | hrw | onoffon: toolchain WG uses oe for some gcc testing |
17:51.09 | ka6sox-away | cbrake are you here? |
17:51.21 | onoffon | likewise howdy |
17:51.44 | onoffon | you mentioned some armv8 using it |
17:52.12 | onoffon | is khem on phone btw |
17:53.01 | hrw | onoffon: we (I) will add armv8 support to get something bootable quickly so we can start bootstrapping ubuntu and test fastmodels |
17:53.35 | onoffon | nice |
17:54.11 | onoffon | i would wait for your patches |
17:54.12 | likewise | onoffon: howdy to you too :) |
17:54.36 | likewise | (Re: [19:51]onoffonlikewise howdy) |
17:55.08 | onoffon | likewise do u use avr32 |
17:56.52 | likewise | onoffon: yes w/o linux in a current project, with linux in a VERY OLD project |
17:58.04 | onoffon | ok |
17:58.15 | onoffon | what libc |
18:00.41 | onoffon | hrw it will be 64 bit right |
18:00.50 | hrw | onoffon: yes, 64bit |
18:01.02 | hrw | onoffon: 32bit support is optional on aarch64 |
18:01.58 | onoffon | cool |
18:02.05 | onoffon | also qemu |
18:03.51 | hrw | no, qemu is not planned yet |
18:04.24 | hrw | there is armv8 fastmodel but I do not remember when it will be publically available (if at all) |
18:04.27 | onoffon | hmm |
18:05.06 | onoffon | so what will u use for target |
18:05.18 | hrw | vexpress-v8 |
18:05.28 | hrw | or how it will be named |
18:05.37 | onoffon | k |
18:05.47 | hrw | at beginning probably linux-dummy only from OE side |
18:05.53 | hrw | no details yet |
18:06.14 | onoffon | arm wont send free to devs :) |
18:06.43 | hrw | onoffon: you know that 'legal' part of ARM is >50% of company? |
18:07.17 | onoffon | yeah linux dummy is a breather when doing new arch port |
18:07.36 | woglinde | where the heck preferred version 0.9.32+0.9.33% comes from |
18:07.45 | onoffon | so iys a lawyer company |
18:08.13 | onoffon | i used it for mips 64 |
18:08.52 | woglinde | args found it |
18:10.19 | onoffon | woglinde angstrom? |
18:12.15 | woglinde | yeah I had it in site.conf |
18:13.58 | hrw | leds on sheeva are fun... kernel tells: "there is red and green" when I see green and blue. At the end there is no red one and green(kernel) is blue(device) |
18:18.13 | onoffon | your kernel is color blind |
18:21.56 | *** join/#oe hollisb (~hollisb@nat-wv.mentorg.com) |
18:26.12 | Desert | i compiled using bitbake, how do i get the toolchain? |
18:26.19 | Desert | to cross compile |
18:26.32 | hrw | bye all |
18:26.35 | Desert | when i downloaded a narcissus image o got the toolchain for free, how to build it myself ? |
18:26.44 | hrw | Desert: bitbake meta-toolchain(-sdk) |
18:26.58 | Desert | hrw cool! |
18:26.59 | Desert | thanks |
18:28.00 | *** join/#oe ao2 (~ao2@2001:1418:117::1) |
18:30.54 | *** join/#oe DesertZarzamora (~quassel@192.100.196.159) |
18:31.29 | DesertZarzamora | whats the difference between meta-toolchain and meta-toolchain-sdk ? |
18:33.52 | Desert | how do i install aditional packages to a toolchain ? |
18:33.57 | Desert | i need opencv |
18:34.50 | Desert | or maybe im asking the wrong question, im developing in my (x86) laptop, but i cross compile, so i need opencv for ARM installed along my dev system |
18:34.56 | Desert | how can i achieve this ? |
18:39.06 | gmc | Desert: in that case, you should build it for your target |
18:39.26 | gmc | and thenenter it as dependency to those recipes where you need opencv |
18:44.34 | Desert | so, i can modify meta-toolchain and enter opencv requirements? |
18:44.48 | Desert | and it will create a toolchain with opencv baked in ? |
18:51.45 | gmc | not sure what you mean with baked in ..? |
18:51.51 | gmc | opencv is just a bunch of libraries, right? |
18:54.30 | Desert | uhm, yes, i was thinking about a tar.gz with everything packed, to distribute to colleagues with everything set up |
19:12.18 | *** join/#oe darknighte (~mgc@pdpc/supporter/professional/darknighte) |
19:15.46 | woglinde | Desert yes than you need to extend to opencv recipe for sdk stuff |
19:16.25 | Desert | woglinde: can you point to a tutorial on how to do this, im a newbie |
19:18.28 | woglinde | you could try to add BBCLASSEXTEND = "native nativesdk" |
19:18.33 | woglinde | in the recipe |
19:18.41 | woglinde | or nativesdk only |
19:18.57 | woglinde | but maybee all requirements of openvc need thats too |
19:19.05 | woglinde | but it depends on the recipe too |
19:32.50 | *** join/#oe GNUtoo-netbook (~gnutoo@host76-91-dynamic.21-79-r.retail.telecomitalia.it) |
19:45.43 | *** join/#oe playya (~playya@unaffiliated/playya) |
20:02.53 | *** join/#oe GNUtoo-desktop (~GNUtoo@host76-91-dynamic.21-79-r.retail.telecomitalia.it) |
20:03.44 | *** join/#oe bluelightning (~paul@cpc13-lewi17-2-0-cust74.2-4.cable.virginmedia.com) |
20:03.44 | *** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning) |
20:05.47 | *** join/#oe NightMonkey (~NightrMon@pdpc/supporter/professional/nightmonkey) |
20:06.49 | woglinde | hm coreutils complains about LIC_FILES_CHKSUM |
20:15.07 | *** join/#oe denisATeukrea (~GNUtoo@host76-91-dynamic.21-79-r.retail.telecomitalia.it) |
20:31.24 | *** join/#oe jkridner (~jason@pdpc/supporter/active/jkridner) |
20:33.50 | *** join/#oe jkroon_ (~jkroon@89-253-118-72.customers.ownit.se) |
20:38.25 | khem | Desert: there are two variables you need to add to when it comes to SDKs TOOLCHAIN_TARGET_TASK for any target packages and TOOLCHAIN_HOST_TASK for natisdk packages |
20:38.33 | khem | just do TOOLCHAIN_TARGET_TASK += " |
20:38.49 | khem | TOOLCHAIN_TARGET_TASK += "opencv-dev" and you must be set |
20:39.15 | woglinde | khem hm ah |
20:39.44 | GNUtoo-desktop | hi khem |
20:39.56 | GNUtoo-desktop | hi woglinde |
20:40.07 | woglinde | hi gnutoo |
20:40.15 | khem | GNUtoo-desktop: hello |
20:40.43 | GNUtoo-desktop | khem, firefox is still broken, I wonder if I update the recipe, would it have a chance to be magically fixed? |
20:41.32 | GNUtoo-desktop | (chromium is also broken but I care less about it) |
20:51.37 | khem | GNUtoo-desktop: I doubt |
20:51.54 | GNUtoo-desktop | ok |
20:51.58 | khem | GNUtoo-desktop: I think we have to try with binutils bleeding edge |
20:52.05 | GNUtoo-desktop | ok |
20:52.10 | khem | I think its fixed in top of tree |
20:52.18 | GNUtoo-desktop | ok nice |
20:53.19 | GNUtoo-desktop | how do I try bleeding edge binutils? |
20:53.36 | khem | good question. |
20:53.45 | khem | I guess I will create recipes and let you know |
20:53.52 | khem | wont happen today |
20:53.56 | khem | but I made a note |
20:54.14 | GNUtoo-desktop | ok |
20:54.17 | GNUtoo-desktop | thanks a lot!!!! |
21:32.31 | *** join/#oe ant____ (~andrea@host176-223-dynamic.7-79-r.retail.telecomitalia.it) |
21:40.53 | *** join/#oe pwgen (~ew@2.108.92.38) |
21:44.53 | ant____ | hi pwgen |
21:45.07 | pwgen | hi .. |
21:45.45 | pwgen | installing debian with debian installer on an external usb disk (:-) |
21:45.59 | woglinde | and? |
21:46.10 | woglinde | where is oe in that? |
21:46.12 | pwgen | it seems i do nat have a problem with ext4dev in the kexecboot, its more lvm related .. |
21:46.47 | pwgen | ... FG.. that is the image from where i started the debian installer .. |
21:49.03 | pwgen | i have build serveral oe images , systemd-image is booting very fast ... |
21:50.11 | msm | anyone ever see: https://gist.github.com/3101315 |
21:51.33 | msm | I can run the task standalone and it works |
21:51.53 | msm | just under bitbake does it fail |
21:52.10 | woglinde | msm could be qemu which segfaults |
21:52.16 | woglinde | check your dmesg output |
21:53.00 | msm | rm[24817]: segfault at 0000000000000000 rip 0000003eb26784a0 rsp 00007fff4b7dec68 error 4 |
21:53.06 | msm | im not in qemu though? |
21:53.18 | woglinde | I never saw rm segfaulting |
21:53.55 | msm | i wonder if i need to reboot |
21:54.01 | msm | i did upgrade a lot of packages on this machine |
21:54.28 | woglinde | o.O |
21:54.29 | msm | centos 5.6 -> 5.8 |
21:54.48 | woglinde | maybee |
21:55.01 | ant____ | woglinde: pwgan said it was a pain to kexecboot linux on that tegra3 Android tablets ;) |
21:55.13 | woglinde | uhm |
21:55.23 | woglinde | I wonder that kexecboot works at all |
21:55.38 | ant____ | kexec needs sort of hardboot patch |
21:56.14 | *** join/#oe NightMonkey (~NightrMon@pdpc/supporter/professional/nightmonkey) |
21:56.19 | pwgen | there is a strange KEXEC_HARDBOOT option for a 3.1.10 kernel that allows to use a patched kexec |
21:56.29 | ant____ | then they still use ext4dev so this doesn't match with fs-detection |
21:56.54 | ant____ | anymore |
21:57.00 | pwgen | and with this any linux (arm based )can run on the tf201 |
21:57.02 | woglinde | pwgen the 3.1.10 kernel from nvidia git? |
21:58.02 | pwgen | woglinde: http://eric-weiss.de/oe/oe-core/meta-erics/recipes-kernel/linux/linux-tf201-stock_git.bb |
21:58.52 | pwgen | but still fighting with varoius kernel configurations . |
22:00.25 | woglinde | ah yes they are pulling over the nvidia git tree |
22:00.27 | pwgen | but i could manage to get the Angstrom-Gnome image build and run. but not touchpad and touchscreen |
22:00.36 | pwgen | yupp |
22:01.13 | woglinde | hm |
22:01.21 | woglinde | xorg problem? |
22:01.56 | pwgen | xorg-driver-input-mtouch missing . thats what they are using on ubuntu, and i could get it work under debian |
22:02.33 | pwgen | but ubuntu did a lot of patchwork to detect the atmel-maxtouch touchscreen proper |
22:02.54 | GNUtoo-desktop | pwgen, we have a multitouch driver.... |
22:02.57 | GNUtoo-desktop | let me look |
22:03.02 | GNUtoo-desktop | it's used at least for crespo |
22:03.11 | GNUtoo-desktop | (nexus S) |
22:03.21 | woglinde | hm I wonder if that hard kexec works on tegra2 too |
22:04.04 | woglinde | ah |
22:04.06 | woglinde | +#elif defined(CONFIG_ARCH_TEGRA_2x_SOC) || defined(CONFIG_ARCH_TEGRA_3x_SOC) |
22:04.09 | woglinde | looks like |
22:04.10 | GNUtoo-desktop | xf86-input-mtev_git.bb |
22:04.22 | GNUtoo-desktop | it's not mtouch tough |
22:04.23 | pwgen | after i can now kexecboot i will try to get as most stuff ass possible run under debian , and then add it to my oe-core images . |
22:05.53 | pwgen | woglinde: ask RayMan in the asus-transformer channel. i think he knows also a lot about tegra2 ( your AC100 ) |
22:06.57 | woglinde | pwgen can you give me a short breefing how do you call kexec stuff? |
22:08.39 | pwgen | woglinde: there are 2 small patches for the kexec-tools-2.0.2 required. and the patches for KEXEC_HARDBOOT |
22:09.21 | *** join/#oe eephillip (~eephillip@pdpc/supporter/student/eephillip) |
22:10.19 | pwgen | then you can call kexec -l --load-hardboot --mem-min=0x98000000 --mem-max=0xc0000000 --append=init=/dev/zero(:) --initrd=something /boot/zImage |
22:10.44 | woglinde | init dev/zero |
22:10.45 | woglinde | lol |
22:10.54 | pwgen | *FG* |
22:11.06 | pwgen | or init=/bin/emacs ... |
22:11.21 | woglinde | okay kexec than put all stuff into ram |
22:11.32 | woglinde | makes a reset and calls the kernel from there |
22:12.55 | pwgen | the kexec -e will coldstart the system, it will load the asus loader, and then start the defined kernel, but the target kernel needs to be somehow ( assume KEXEC_HARDBOOT enabled ) patched , for this zou cannot boot the origianl andoid image |
22:13.58 | pwgen | and the bootloader must be "rooted", they have something with bootloader encryption |
22:17.21 | pwgen | q |
22:18.30 | pwgen | http://pastebin.com/Xc0NdXJz |
22:20.40 | pwgen | and http://pastebin.com/P7vsyqQy are required to patch kexectools-2.0.2 |
22:21.14 | woglinde | good nite |
22:21.24 | pwgen | CU |
22:33.41 | Desert | khem: i guess i have to add that TOOLCHAIN_TARGET_TASK += "opencv-dev" to some .bb, my guess is meta-toolchain_****.bb |
22:33.52 | Desert | but where is that -bb file, im targeting beagleboard |
22:34.31 | Desert | i did a locate, but i found several meta-toolchain.bb |
22:34.46 | Desert | opie, qte, efl, gnuradio |
22:34.49 | Desert | and a bare |
22:34.59 | Desert | setup-scripts/sources/openembedded-core/meta/recipes-core/meta/meta-toolchain.bb |
22:36.04 | Desert | which is mostly empty |
22:36.07 | Desert | how to know which one? |
22:36.20 | Desert | http://pastebin.com/jEgiYB8G |
22:46.27 | *** join/#oe dos1 (~dos@unaffiliated/dos1) |
23:12.23 | *** join/#oe esbenh (~esben@hugin.dotsrc.org) |
23:47.03 | *** join/#oe jevin (~jevin@napalm.jevinskie.com) |