**** BEGIN LOGGING AT Mon Jan 23 02:59:57 2012 Jan 23 07:30:18 hi folks! Jan 23 07:48:04 well, there is no kernel in the jffs2 images. i built. :) Jan 23 07:53:58 good morning Jan 23 08:54:40 hii Jan 23 08:54:53 i;m trying to compile qt 4.8 Jan 23 08:55:11 in oe Jan 23 08:55:35 having some compilation issues Jan 23 08:55:51 | linking ../../../bin/moc | ld: unrecognized option '-Wl,-rpath-link,/home/localadmin/Zero/build/tmp/staging/i686-linux/usr/lib' | ld: use the --help option for usage information | make: *** [../../../bin/moc] Error 1 | FATAL: oe_runmake failed Jan 23 08:59:04 i am using the same recipes being used for qt4.7 Jan 23 08:59:21 there is no issues in compiling qt4.7 Jan 23 09:05:42 sisc: those commas, are they really in the commandline ? Jan 23 09:09:55 yes Jan 23 09:12:38 sisc: i may be wrong, but in my opinion there is one comma to much in here: -rpath-link,/home/localadmin/Zero/build/tmp/staging/i686-linux/usr/lib Jan 23 09:13:06 ipaglor: k Jan 23 09:13:13 let me try Jan 23 09:14:33 LFLAGS = -L/home/localadmin/Zero/build/tmp/staging/i686-linux/usr/lib -Wl,-rpath-link,/home/localadmin/Zero/build/tmp/staging/i686-linux/usr/lib -Wl,-rpath,/home/localadmin/Zero/build/tmp/staging/i686-linux/usr/lib -Wl,-O1 -fno-exceptions -Wl,-O1 Jan 23 09:14:51 this line is there in Makefile Jan 23 09:16:39 sisc: ok, changing that makes a difference? Jan 23 09:16:46 no Jan 23 09:16:59 still ld unrecognized option -Wl Jan 23 09:17:14 ld: unrecognized option '-Wl' Jan 23 09:17:32 LFLAGS = -L/home/localadmin/Zero/build/tmp/staging/i686-linux/usr/lib -Wl -rpath-link,/home/localadmin/Zero/build/tmp/staging/i686-linux/usr/lib -Wl -rpath,/home/localadmin/Zero/build/tmp/staging/i686-linux/usr/lib -Wl,-O1 -fno-exceptions -Wl,-O1 Jan 23 09:19:40 sisc: well, id say it must be: -L/home/localadmin/Zero/build/tmp/staging/i686-linux/usr/lib -Wl,-rpath-link=/home/localadmin/Zero/build/tmp/staging/i686-linux/usr/lib..... Jan 23 09:20:25 k Jan 23 09:20:30 does that change anything if you manually run the command with the , changed to a = Jan 23 09:22:27 ipaqlor: i tried ur way Jan 23 09:22:37 still getting same error Jan 23 09:22:39 ld: unrecognized option '-Wl,-rpath-link=/home/localadmin/Zero/build/tmp/staging/i686-linux/usr/lib' Jan 23 09:24:14 sisc: ok, sorry, no idea then. Jan 23 09:24:36 ipaqlor: ok Jan 23 09:24:40 no problem Jan 23 09:24:50 i'll wait here Jan 23 09:25:02 may be someone else could hel me Jan 23 09:25:02 *help Jan 23 09:25:22 anyways thnx Jan 23 09:25:32 sisc: pastebin your recipe would help Jan 23 09:26:53 k Jan 23 09:32:03 http://pastebin.com/BaNYvyJs Jan 23 10:02:03 morning all Jan 23 10:04:08 hi pb_, all Jan 23 10:04:49 mornin Jan 23 10:15:51 morning pb_, bluelightning, Jin^eLD Jan 23 10:16:04 hi ipaqlor Jan 23 10:16:25 bluelightning: i managed to get the jffs2 images mounted :) and, yes, no kernel there :) Jan 23 10:16:42 ipaqlor: yes I know... in my images that is fixed Jan 23 10:16:49 ipaqlor: (and that fix is now in meta-handheld) Jan 23 10:17:02 bluelightning: since i can mount the jffs2 images i can at least add the kernel manually and dump them to images afterwords Jan 23 10:17:22 bluelightning: so git update should fix that? Jan 23 10:17:50 ipaqlor: yes Jan 23 10:18:00 git pull Jan 23 10:19:13 bluelightning: ah, yes, update was with svn. as i said. im kind of at war with versioning systems :) Jan 23 10:27:51 bluelightning: what wa sthe reason for the kernel not being incopareted into the images? i cant see anything about it in the commit log Jan 23 10:29:16 linux: add 2.6.29 kernel for h3600, conf/machine/h3600: switch to linux (2.6.29),..... Jan 23 10:35:54 mhm, git diff... well, should bring me somehow somewhere i guess... Jan 23 10:38:31 ipaqlor: "conf/machine/h3600: make kernel and /boot/params essential" Jan 23 10:38:44 revision f91d7bc58d166422529cac3dcbbe509c71efcd3f Jan 23 10:43:18 +MACHINE_ESSENTIAL_EXTRA_RDEPENDS = "kernel ipaq-boot-params" ok. Jan 23 10:43:41 git diff HEAD f91d7bc58d166422529cac3dcbbe509c71efcd3f Jan 23 10:50:46 bluelightning: whats the least inavive "cleanup" i can do to get a core-image incoperating the new kernelsettings and fixes? Jan 23 10:51:12 bluelightning: else its 6-8hours building again :( Jan 23 10:51:17 ipaqlor: bitbake -c clean task-core-boot Jan 23 10:51:25 ipaqlor: then just bitbake core-image-minimal Jan 23 10:52:02 no need to wipe out everything :) Jan 23 10:52:37 bluelightning: nice, thanks. :) rebuilding the whole thingy like 10 times within a week is enough ;) Jan 23 10:57:09 bluelghtning: no, taht didnt do it :) Jan 23 10:58:33 bluelightning: means, there has no kernel been rebuilt, and the jffs2 image still does not contain a kernel. Jan 23 10:58:46 ipaqlor: did it actually rebuild task-core-boot or did it just do a setscene task for it? Jan 23 10:59:03 NOTE: Executing SetScene Tasks Jan 23 10:59:16 it always prints that Jan 23 10:59:30 could you pastebin the log please Jan 23 10:59:35 bluelightning: besides that all do's are setscene dos :) Jan 23 10:59:44 from NOTE: package task-core-boot-1.0-r9: task do_package_setscene: Started Jan 23 10:59:51 toNOTE: package task-core-boot-1.0-r9: task do_package_write_ipk_setscene: Succeeded Jan 23 10:59:55 right Jan 23 11:00:01 bitbake -c cleansstate task-core-boot Jan 23 11:00:16 then bitbake core-image-minimal Jan 23 11:01:43 pb_: about this -staticdev, I'm worried I'll have to repackage klibc as well Jan 23 11:03:32 generally I think the change implies the .la are in -dev while the .a in -staticdev Jan 23 11:05:00 well, not only that, ${SOLIBS} and ${SOLIBSDEV} have to been added Jan 23 11:05:18 bluelightning: nope, still no kernel built or added. Jan 23 11:06:05 ant_work: yeah, that seems to be the idea Jan 23 11:06:38 s/been/be/ Jan 23 11:06:46 http://pastebin.com/FYydW4CV Jan 23 11:06:48 ipaqlor: that can't be right Jan 23 11:06:59 bluelightning: just not cleaned up enough :) Jan 23 11:07:03 pb_: it's all that easy with small recipes like apmd :) Jan 23 11:09:10 bluelightning: pls note the DISTRO_VERSION in above pastebin Jan 23 11:09:20 (btw) Jan 23 11:09:43 ant_work: yes Jan 23 11:10:43 ant_work: I thought of an improvement - perhaps we could use a separate variable e.g. KEXECBOOT_MENUENTRY or something like that and then default assign that to DISTRO_VERSION... that way you could make it slightly more descriptive if you want Jan 23 11:12:04 ipaqlor: what does this report: bitbake -e task-core-boot | grep ^RDEPENDS Jan 23 11:12:55 RDEPENDS_task-core-boot="base-files base-passwd busybox initscripts modutils-initscripts netbase tinylogin sysvinit udev update-alternatives-cworth" Jan 23 11:12:55 RDEPENDS_task-core-boot-dev="task-core-boot (= 1.0-r9)" Jan 23 11:12:55 RDEPENDS_task-core-boot-staticdev="task-core-boot-dev (= 1.0-r9)" Jan 23 11:13:42 ok, how about: bitbake -e task-core-boot | grep ^MACHINE_ESSENTIAL Jan 23 11:14:11 bluelightning: nothing Jan 23 11:14:17 right Jan 23 11:14:43 MACHINE_EXTRA_RDEPENDS="ipaq-boot-params" Jan 23 11:14:46 i got Jan 23 11:14:54 so the only thing I can think of is you did not update meta-handeld... Jan 23 11:15:07 ipaqlor: please cd into the meta-handheld dir and do a git pull Jan 23 11:15:24 bluelightning: hehehe :) i did that, else i wouldnt have seen the git diff :) Jan 23 11:15:45 it has not picked up the changes to h3600.conf Jan 23 11:15:55 otherwise that MACHINE_EXTRA_RDEPENDS would not be there Jan 23 11:16:14 bluelightning: 7e17fd80927b4af06ad40dcb97bfde2dea6da6c9 is where i am :) Jan 23 11:16:23 ok Jan 23 11:16:44 you're sure you don't have more than one copy of meta-handheld and your conf/bblayers.conf is pointing to an older one? Jan 23 11:17:16 bluelightning: yes, i am shure that i absolutly and totally did only what you said me :) Jan 23 11:17:45 bluelightning: but, i have changed the h3600.conf by myself (32 instead of 16mb flash) Jan 23 11:18:10 bluelightning: but i can delete meta-handhelds and fetch it new Jan 23 11:18:29 ipaqlor: what does "git status" report in meta-handheld? Jan 23 11:19:14 Your branch is behind 'origin/master' by 5 commits, and can be fast-forwarded Jan 23 11:19:17 argl Jan 23 11:19:27 i hate those f***g versioning systems Jan 23 11:19:41 whats that all good for Jan 23 11:20:22 git reset --hard master Jan 23 11:20:23 git pull Jan 23 11:20:26 i do a pull, it pulls, i look at the log, theres the log, but it hasnt changed anything???? whats the logic there? Jan 23 11:20:45 when you did a git pull what did it say? Jan 23 11:20:59 conflict, by any chance? Jan 23 11:21:11 bluelightning: its out of my scrollbuffer but it said nothing that made me believe anything is wrong. Jan 23 11:21:20 just do one now Jan 23 11:24:01 bluelightning: i just removed it and fetched it new. Jan 23 11:24:16 ipaqlor: that wasn't really necessary, but OK Jan 23 11:24:30 bluelightning: i really do not want to go into svn that deeply. its a tool, and a bad one in my opionion. i will not waste any time on this. Jan 23 11:24:49 git is fantastic, but there is a learning curve Jan 23 11:24:52 or git or cvs or hg for that matter Jan 23 11:25:30 bluelightning: yeah, many peolple like it. i am none of them. ive seen people wasting weeks with versioning systems instead of doing their work Jan 23 11:25:37 honestly, version control is a hugely important part of my job... without it a lot of things would be impossible Jan 23 11:27:25 bluelightning: well, ever tried without? Jan 23 11:27:31 ipaqlor: years ago yes Jan 23 11:27:49 I've also had recent experiences dealing with inferior version control systems Jan 23 11:28:02 bluelightning: and whats the thingy? are you 50 people working on one and the same sourcefile? Jan 23 11:28:48 in either case the result is one day you get deep into a project and then realise you forgot to make a backup before you made a drastic change, and you've lost a significant amount of work Jan 23 11:29:39 bluelightning: ok, there is a bunch of "real" backupsolutions :) Jan 23 11:29:49 two people working on the same file doesn't happen very often... there are exceptions, but if it happens a lot it suggests you need to improve the code structure or how you manage developer tasks Jan 23 11:29:58 bluelighnting: you could use filesystem snapshots for starters :) Jan 23 11:30:32 in any case git has highly evolved conflict resolution - it has to, as it's used to manage the linux kernel itself Jan 23 11:30:33 bluelightning: well, im not confinced :) Jan 23 11:31:03 filesystem snapshots don't get the developer into a rhythm of committing individual isolated pieces of work Jan 23 11:31:37 the best thing about version control is, if you discover a bug months down the track, you can go back through the history and find out when it was introduced Jan 23 11:31:44 that's critical when you're working on a real product Jan 23 11:32:17 another useful function is being able to maintain different branches Jan 23 11:32:23 bluelightningL that si possible with daily...or whatthely backups to Jan 23 11:32:49 so you can have a bleeding edge development version of the software, and a maintenance version so you keep customers happy with stable software Jan 23 11:32:56 bluelightning: branches, yes. well, how about hardlinks :) Jan 23 11:33:02 honestly backups just don't cut it Jan 23 11:33:12 well, heh. if you have a sufficiently sophisticated snapshot/backup strategy to do that, guess what, you have just reinvented RCS. Jan 23 11:33:32 bluelightning: anyways. i know what i do not like about versioning systems. you know what you do like about them. there may be no consens possible here. :) Jan 23 11:33:59 ipaqlor: I think you just haven't had one save your bacon... once you have, you'll be a convert. :) Jan 23 11:35:15 bluelightning: well, until now, i have just wasted weeks with versioningsystems :) i dont think i get into the clean with it in the near future ;) Jan 23 11:37:52 pb_: no, i havent reinvented nothing. i see no use for such things. Jan 23 11:52:53 bluelightning: on with the show. got a "fresh" meta-handheld repodump. redid: bitbake -c cleansstate task-core-boot , and finally bitbake core-image-minimal gave me "tootoot" a filesystem image with kernel :) time to flash :) Jan 23 12:15:20 ipaqlor: great, will be good to hear if it works :) Jan 23 12:19:38 bluelightning: it "looks" good :) but i need to modify the console boot parameters for i dont have a serial cradle and the screen just gets blanked when launching the flash boot. Jan 23 12:20:43 also, there ssems to be some "piling up" of boot parameters. Jan 23 12:21:23 bluelightning: my params file in /boot contains set linuxargs "root=mtd1 noinitrd console=ttyS0,115200 console=tty0" Jan 23 12:22:31 ipaqlor: that looks OK Jan 23 12:22:46 ipaqlor: that enables console on serial and on the first tty (the display) Jan 23 12:22:49 isn't root=/dev/mtd1 ? Jan 23 12:23:27 bluelightning: ah, ok i seen to time ttyS0 ;) my bad. Jan 23 12:24:25 ipaqlor: ant_work might be right about the root= though, if it fails to find the root partition you might need to experiment with changing that Jan 23 12:24:59 bluelightning: yes, also i found the USE_VT = "0" Jan 23 12:25:14 in h3600.conf .... looks like i want to "1" that Jan 23 12:28:55 hm.. yes, maybe tty1 Jan 23 12:29:42 ipaqlor: if you change USE_VT then you'll need to bitbake -c cleansstate sysvinit-inittab Jan 23 12:30:20 ipaqlor: btw I'd really recommend you try to get hold of a serial cable/cradle Jan 23 12:30:58 how are you uploading the rootfs if you don't have serial btw? Jan 23 12:31:03 bluelightning: well. doesnt look like i will get a hold on on within the next months Jan 23 12:31:49 bluelightning: i have a CF silverslider and a 512mb kingstom cf card Jan 23 12:32:21 bluelightning: + the good old crl bootloader :) Jan 23 12:32:35 bluelightning: btw it looks like there are unused vars wrt console Jan 23 12:33:00 CONSOLE= USE_VT= SERIAL_CONSOLE Jan 23 12:33:20 I can't believe we need 3 Jan 23 12:33:54 juppi, nice pyhton errors the way i like em Jan 23 12:34:11 this thingy is a beast :) Jan 23 12:34:31 ipaqlor: ah right :) Jan 23 12:35:09 ipaqlor: not sure what it's like where you are but I just bought an h3600 serial cradle for £4 on ebay Jan 23 12:35:34 serial is invaluable for finding out what's going wrong when booting fails Jan 23 12:35:57 bluelightning: i got no paypal, no creditcard and no ebay account :) Jan 23 12:36:12 ok, then read about early_printk ;) Jan 23 12:36:26 bluelightning: there is net console to :) Jan 23 12:36:38 bluelightning: but i dont know if it will work with isbnet :) Jan 23 12:40:28 ipaqlor: one way to find out :) Jan 23 12:42:00 you know, for some reasons on Z corgi/c7x0 console =tty0 was bad, using tty1 is fine. That was long ago but we kept that seting Jan 23 12:42:13 bluelightning: yeah, shure. Jan 23 12:47:22 bluelightning: I see, sysvinit-inittab uses SERIAL_CONSOLE, SERIAL_CONSOLES and USE_VT Jan 23 12:47:32 hahahaha Jan 23 12:47:51 well, cant have enough variables these days ;) Jan 23 12:47:57 heh Jan 23 12:48:11 let'me devine: systemd will have own set ;) Jan 23 12:49:44 ant_work: yes.. I'm sure this was discussed not that long ago on the oe-core list Jan 23 12:50:31 I can't grep here, so can only guess SERIAL_CONSOLES come from the multiple CONSOLE parsing Jan 23 12:53:26 ant_wokrk: cant grep here? saved some pennys on minimal busybox ;) Jan 23 12:54:13 nah, I'm offsite and PC is off or running OSX atm Jan 23 12:54:34 :) Jan 23 12:54:41 I don't dare to deploy OE here on office server Jan 23 12:55:37 chicken chicken ;) Jan 23 12:57:44 ok, USE_VT = "1" didnt change nothing in the boot params Jan 23 12:58:40 ipaqlor: it won't, it's only used to determine whether or not to set up getty's for the VTs Jan 23 12:58:56 i.e in inittab Jan 23 12:59:11 SERIAL_CONSOLE = "115200 ttySA0 vt100" , USE_VT = "1" leads to set linuxargs "root=mtd1 noinitrd console=ttyS0,115200 console=tty0" .... Jan 23 12:59:41 bluelightning: ok Jan 23 13:01:21 ipaqlor: pls use root=/dev/mtd* Jan 23 13:01:42 ant_work: ill hapily do, as soon as i have found out where the source this gets set Jan 23 13:02:19 bluelightning: my params file in /boot contains set linuxargs "root=mtd1 noinitrd c Jan 23 13:03:17 and usually you need two more tags rootfstype=ext2 rootwait Jan 23 13:03:24 or ext3, ... Jan 23 13:03:56 ant_work: you are way ahead of me. im still trying to find out what gets overriden by what and depends on which :) Jan 23 13:03:58 ipaqlor: /boot/params comes in via the recipes-bsp/ipaq-boot-params recipe in meta-handheld Jan 23 13:04:20 I see, change there accordingly to your setup then Jan 23 13:04:41 ant_work: this is jffs2 and it's onboard flash, shouldn't need any wait I would think... Jan 23 13:05:45 a ok ../meta-handheld/recipes-bsp/ipaq-boot-params/files/params (END) Jan 23 13:07:00 ok, fixed that Jan 23 13:07:05 rebuild :) Jan 23 13:11:36 mhm, i just thought about the blank screen. there should at least be the spash image shown or am i wrong here? Jan 23 13:14:03 there should yes Jan 23 13:14:40 CONFIG_LOGO=y Jan 23 13:14:43 yes Jan 23 13:15:58 so the kernel isnt even near to accessing the rootfilesystem (mtd1) Jan 23 13:18:33 hmm Jan 23 13:18:55 well when my device arrives I'll be able to see what's going on Jan 23 13:19:17 .macro loadsp, rb, tmp Jan 23 13:19:17 .endm Jan 23 13:19:17 .macro writeb, ch, rb Jan 23 13:19:17 mcr p14, 0, \ch, c8, c0, 0 Jan 23 13:19:17 .endm Jan 23 13:19:23 :) Jan 23 13:19:31 this is where it starts ;) Jan 23 13:22:18 bluelightning: ok. well. i give the binaries from mad a chance and slush them together via manipulating jffs2. Jan 23 13:23:00 bluelightning: if that doesnt work. ill roleback to 2.6.26 Jan 23 13:23:17 ipaqlor: you mean 2.6.21-hh Jan 23 13:23:57 I think if you see nothing it's likely to be something more fundamental than the kernel Jan 23 13:24:13 ipaqlor: I don't see CONFIG_JFFS2_FS=y Jan 23 13:24:31 bluelightning: ah, yes, 2.6.21-hh you are right. Jan 23 13:25:23 and CONFIG_MTD_CMDLINE_PARTS is not set Jan 23 13:25:37 ant_work: heh... that could be a problem Jan 23 13:25:56 bluelightning: start froma Zaurus kernel config and change the specific bits... Jan 23 13:26:09 config are really minimal now Jan 23 13:26:50 mhmkay Jan 23 13:27:02 check out the mtdparts settings in kernel Jan 23 13:27:22 this is really device specific Jan 23 13:27:44 ant_work: yes. i assumed somethings that are now proven to be not true. Jan 23 13:28:04 well Jan 23 13:28:52 should i create a net machine named h3760 and build there from scratch or any suggestions Jan 23 13:29:12 because this way im not seeing this going somewhere. Jan 23 13:29:37 se, we have two defconfigs able to boot from 'any' block device: you should meet at least the same requirements Jan 23 13:32:30 ant_work: my requirement is that i get something compiled, booted and running. soon. some people did this 10 years ago so wtf. Jan 23 13:33:24 I see h4600 is sa1100 Jan 23 13:33:32 err.. h3600 Jan 23 13:33:40 yes Jan 23 13:33:54 so really anything new... Jan 23 13:34:04 but the complexity of oe seems to hinder me to getting anywhere. Jan 23 13:34:33 so ill stop here and use what works and script the rest. Jan 23 13:35:25 it's just the kernel needing minor editings to boot from mtd Jan 23 13:36:07 ant_work: its does not display linuxlogo. Jan 23 13:37:04 this is the last problem to solve;) Jan 23 13:37:04 that doesn't particularly sound like it's an oe problem, to be honest. it sounds as though you just have a busted kernel for whatever reason. Jan 23 13:38:11 90% of what oe is doing is irrelevant if your kernel doesn't even boot at all. Jan 23 13:38:17 pb_: yes, i know. Jan 23 13:39:43 it does seem that you're making life particularly hard for yourself by trying to do this without serial. I guess you could patch the kernel to output early debug to the framebuffer but it will be fairly fiddly to get that right. Jan 23 13:42:48 pb_: I see there is a trend about having separate /usr on boot (potentially) Jan 23 13:43:01 pb_: i have no cradle and i cant get none. i am more interested in getting a "compile environment that works" together for starters than to debug a kernel one person at least had ever booted an h3600 with :) Jan 23 13:43:24 pb_: this should go without a serialcradle without big problems. Jan 23 13:44:15 yeah, indeed. presumably you are going to need a working kernel in order to run your binaries though. Jan 23 13:45:00 pb_: yes, for example my next try in compiling will be the lates hh kernel. and if that does not work, then there is somthing really really messed up :) Jan 23 13:45:40 yeah, though note that the -hh kernels probably haven't been built or tested with any recent version of gcc Jan 23 13:45:59 and older kernels did tend to break with newer compilers at about the time all that stuff was happening. Jan 23 13:46:21 (this was the whole reason that oe had the KERNEL_CCSUFFIX, though I'm not sure if that mechanism still exists.) Jan 23 13:46:21 pb_: the good news keep coming ;) Jan 23 13:48:56 ipaqlor: people have booted the 2.6.29 kernel, it does work Jan 23 13:49:47 pb_: ipaqlor_: I don't know anything about h3600 but sa1100 is very well maintained arch inupstream. RMK did revert some bad commits last week breaking many machines Jan 23 13:50:01 so I'd tray 3.1 Jan 23 13:50:07 *try Jan 23 13:50:28 bluelightning: thats why i said at least one person Jan 23 13:50:57 ipaqlor: FYI, I spoke to Dmitry Artamonow about getting those patches updated for a newer kernel, he said he might be able to although apparently the screen on his h36xx is broken Jan 23 13:51:19 hehe, no wonder my screen is blank ;) Jan 23 13:51:32 yeah, that was after he did the 2.6.29 kernel patches :p Jan 23 13:51:42 the blankscreen for everyone conspiracy Jan 23 13:52:01 well, ext3 is not compiled, nor is MMC Jan 23 13:52:07 try ext2 on CF ;) Jan 23 13:52:41 i thing crl needs vfat. dont know if it handles partitions and i only got one cfcard. Jan 23 13:52:48 no, i cant buy one! :) Jan 23 13:55:51 ant_work: regarding the 3.x kernels. i really dont know if that is feasable :) thes little h3600 and similiar models have a very "special" peripheral hardware inside.... Jan 23 13:56:34 havent even looked if the hardwarecontroller is supported with newer kernels. but im about to do that right away. Jan 23 13:57:20 the atmel chip that does the light, butten, ts interrupt and what not thingys. Jan 23 14:01:36 yes! arch/arm/mach-sa1100/h3600.c Jan 23 14:01:54 it _will_ need patches though Jan 23 14:02:10 hopefully dmitry will be able to sort those out Jan 23 14:02:25 in the mean time it should be possible to get 2.6.29 working Jan 23 14:03:21 I think it should be possible to get a working screen even without a driver for the micro. iirc, nothing you need for lcd is driven from there. Jan 23 14:05:36 bluelightning: there is an awful lot of patches :/ Jan 23 14:05:43 ant_work: yes Jan 23 15:48:19 florian: hay flo Jan 23 15:48:53 ji cs_nbp Jan 23 15:48:56 florian: compiled e17 for nbp, no errors. one drawback: effed locale impeaches ecore startup Jan 23 15:48:56 hi Jan 23 15:49:23 florian: many strange things going on on nbp sys Jan 23 15:49:27 :D Jan 23 15:51:09 compiled with meta-efl? Jan 23 15:51:25 y Jan 23 15:51:40 then of course no errors :) Jan 23 15:51:51 :p;) Jan 23 15:53:02 florian: got a hint on where I should start to look? Jan 23 16:09:41 ok, just flashed the 2.6.29 recompiled with jffs2, misc mtd options...., no display init here. Jan 23 16:10:13 so i dump it now. sensless to continue. with this kernel. Jan 23 16:11:41 ipaqlor: you haven't determined it's the kernel Jan 23 16:12:08 bluelightning: well. havent i. ok. what am i missing here? Jan 23 16:12:43 it could be that bootldr doesn't recognise the jffs2 partition Jan 23 16:12:55 it could be that bootldr can't find the kernel Jan 23 16:13:29 or even hand wrong options to it Jan 23 16:14:04 yes... I just trusted that the kernel config I downloaded from dmitry's webpage was correct, I did not examine it Jan 23 16:14:28 s/correct/sufficient for our purposes/ Jan 23 16:14:33 bluelightning: well, since the crl doesnt exit wenn ther eis no kernel in the jffs2 and it exits(in my opionion bootstraps the kernel it just found) Jan 23 16:15:38 well, you're welcome to try the 2.6.21 kernel if you think it will help Jan 23 16:15:59 you'll find it increasingly hard to get beyond starting the kernel assuming it even starts Jan 23 16:16:11 hehehe Jan 23 16:16:32 2.6.21 is really old now, a lot of userspace assumes a newer kernel these days Jan 23 16:16:38 e.g. udev Jan 23 16:17:47 bluelightning: udev is one of the "features" i really dont need :) Jan 23 16:18:02 bluelightning: i can spare those few devicenodes Jan 23 16:18:05 ;) Jan 23 16:18:09 that's right, you could use something else Jan 23 16:18:22 like MAKEDEV ;) Jan 23 16:18:36 so this problem is solved. Jan 23 16:18:39 nice! Jan 23 16:18:47 maybe Jan 23 16:20:43 bluelightning: i hav no doubt that is eally hard to impossible to make a newest from the newest of software compileable for this machine. but since this is not a issue for me - i just want something i can compile - i wouldnt even be here if i found a tarball containing a buildenvironment from hh when the build worked Jan 23 16:22:29 shure, things like better powermanagement enhancements and kexec and stuff are neat. but i prefer to have something buildable and useable to having the newest unusable Jan 23 16:23:37 ipaqlor: well you are using the latest version of the build system that includes the latest libc, compiler, other libs & userspace apps etc. Jan 23 16:24:21 bluelightning: shure. and there i am going to stop, and walk backwards again until i see the ligt :) Jan 23 16:28:09 bluelightning: so next step. make a break and kick something. afterwards glue together a oe jffs with the vmlinz from the latest hh familiar builds. if kernel boots, jffs2 is ok. Jan 23 16:30:26 florian: btw i meant for locale, not for e17 Jan 23 16:34:25 cs_nbp: not yet... but I didn't manage to take a look so far Jan 23 16:34:39 but sounds like a good job for the night Jan 23 16:35:51 bbiab Jan 23 17:21:01 re Jan 23 17:30:12 I'm confusing myself over when something needs to go in DEPENDS, RDEPENDS, and IMAGE_INSTALL. Mainly why somethings seems to be found in both DEPENDS and IMAGE_INSTALL but other times a recipe only lists in under IMAGE_INSTALL. Jan 23 17:30:57 hm? Jan 23 17:31:14 IMAGE_INSTALL is only for images, first of all. thats all it does, it governs what goes into an image. it also contains package names, not recipe names Jan 23 17:31:25 IMAGE_INSTALL will only be found in image recipes Jan 23 17:31:30 right, Jan 23 17:31:30 (or config metadata, potentially) Jan 23 17:32:09 DEPENDS is a list of recipes. what it really says is, take my do_configure, and make it depend on the do_populate_sysroot task in all those recipes. Jan 23 17:33:18 so in some image recipes there will also be a DEPENDS. for instance task-base-extended might be listed under depends and image_install, but ntpdate is just under install Jan 23 17:33:28 no need Jan 23 17:33:43 bitbake tracks runtime dependencies. IMAGE_INSTALL is put into the image's RDEPENDS Jan 23 17:34:08 further, the classes instruct bitbake that building an image requires that do_package_write be run in any dependent recipes Jan 23 17:34:15 so there's no need to tell bitbake to build those things explicitly Jan 23 17:34:35 e.g. by putting the in depends ? Jan 23 17:34:39 them* Jan 23 17:35:00 yes, that would tell bitbake in normal circumstances that you want those other things to be b uilt before this. Jan 23 17:35:14 it's not necessary if it's already been told on the runtime side Jan 23 17:35:30 it keeps track of what recipes will emit what packages, and knows those need to be built to satisfy the runtime dependency Jan 23 17:35:39 RDEPENDS is a per package list of what other packages this package needs Jan 23 17:35:56 ok, that makes sense and is consistent with the behavior I've been seeing. I guess some of the recipes just have it listed unnecessarily Jan 23 17:35:58 RDEPENDS is what goes into the Depends field of the binary package that gets emitted Jan 23 17:36:33 but also keep in mind that our classes can automagically *set* rdepends for the packages based on what the contents used. (e.g. what libraries it linked against) Jan 23 17:36:55 so if something is in DEPENDS, 90% of the time it gets automatically also pulled into rdepends,a nd you therefore don't need it in both except in extremely rare circumstances Jan 23 17:37:55 hopefully I didn't make it even more confusing :) Jan 23 17:38:31 ok, you lost me there. If something is in depends, doesn't that mean it gets built and included no questions asked, provided the recipe that has the DEPENDS statement is built Jan 23 17:38:39 its *built* yes Jan 23 17:38:47 but... Jan 23 17:38:48 that doesn't mean it will also be *installed* if you install the binary package that was emitted Jan 23 17:39:08 usually it is, because again 90% of the time we can automatically generate the runtime dependencies for the package Jan 23 17:39:29 Ugh! Ok, I think I follow. Jan 23 17:39:44 remember that there are two namespaces involved here. recipes and packages. DEPENDS lists recipes, not packages. so it cannot be simply placed as is into the deps of the binary package Jan 23 17:41:23 another way of thinking about this.. one is the dependencies on other sources in order to build.. and the other is something required to run the resulting binaries Jan 23 17:41:44 right Jan 23 17:43:15 but when I'm simply trying to add preexisting packages to an image I can simply list them in the image_install and bitbake takes care of satisfying their dependencies, of both sorts! Jan 23 17:43:34 yep Jan 23 17:43:43 during package install, the system expects all potential dependencies (runtime) to be able to be satisfied Jan 23 17:46:24 On a slightly related note, any idea why adding tools-sdk to EXTRA_IMAGE_FEATURES did not cause a sdk to be in the resulting image. I've gotten around it by adding task-native-sdk to IMAGE_INSTALL in my image recipe, but still for understanding... Jan 23 18:14:35 florian: am back now, too, was tryin to get a rs232 with com and honda connectors - impossible in 'normal' electronics stores it seems (huh, whuts thst?) Jan 23 20:32:30 Has the source mirroring scheme changed since the creation of openembedded-core? I've tried to add a source mirror to my local.conf, but it appears that it is being ignored. Jan 23 20:36:33 Should I need to do something other than add these two lines to local.conf? http://pastebin.com/jauTUvRg Jan 23 20:39:41 has anyone an idea where i can find the codenmof the old crl bootloader? Jan 23 20:42:55 got it. Jan 23 21:45:39 hi, Jan 23 21:46:47 does somebody have a clue on why the following flags get into the do_compile of my kernel: Jan 23 21:46:48 -mno-thumb-interwork -marm Jan 23 21:46:56 the kernel is linux-palmpre Jan 23 21:47:06 from meta-smartphone/meta-palm Jan 23 21:49:38 oe classic or or-core? Jan 23 21:53:14 TARGET_CC_KERNEL_ARCH += "-mno-thumb-interwork -marm" Jan 23 21:53:16 oe core Jan 23 21:53:23 conf/machine/include/tune-thumb.inc Jan 23 21:53:30 I'll look in git Jan 23 21:53:36 ya, I was going to suggest looking there.. Jan 23 21:53:55 appears to me someone made the decision that the kernel can't be built w/ thumb instructions directly, thus those flags are passed Jan 23 21:54:16 ok Jan 23 21:54:34 I'm not sure but I think my kernel doesn't boot when compiled with theses instructions Jan 23 21:55:11 that would be really strange... since my understanding is that the thumb-interwork shouldn't be there.. and -marm simply means don't use thumb instructions in this case Jan 23 21:55:28 ok Jan 23 21:55:39 it's a palm pre 2.6.24 kernel Jan 23 21:56:04 basically I did that: Jan 23 21:56:11 ya.. they may have some unique patches or something.. but I honestly don't know Jan 23 21:56:15 I bitbaken the kernel -> not booting Jan 23 21:56:29 I removed theses instructions in run.do_compile Jan 23 21:56:35 I made clean the kernel Jan 23 21:56:43 I recompiled it with run.do_compile Jan 23 21:56:49 I pushed it to the device Jan 23 21:56:51 and it booted Jan 23 21:57:09 I've no serial on that device Jan 23 21:57:15 and it's indeed a big problem Jan 23 21:57:18 you should uild both ways and see if you can figure out the difference.. my guess is a bug in the palm pre kernel -- or a difference in the order of code generation Jan 23 21:57:28 ok Jan 23 21:57:34 I'll add thumb back and retry Jan 23 21:57:38 *-mnothumb Jan 23 21:57:56 ya.. start with that.. it would be odd if they're expecing interworking on something to be there in the palm pre kernel Jan 23 21:58:38 there is also the possibility that I did a manipulation error Jan 23 21:58:44 while booting or copying the kernel Jan 23 21:58:50 because I'm quite new with that platform Jan 23 21:59:05 ya, I don't have any knowledge of the pre, other then I've used one.. ;) Jan 23 21:59:08 and I don't use novacom but the reverse engineered precom(modified by me) Jan 23 21:59:35 (with my modifications I can talk to bootie) Jan 23 22:05:12 florian: perhaps it isn't the locale that's broken and another thing messes it up Jan 23 22:06:11 florian: eg after resume in terminal it's like 'enter' is stuck (5 new prompt lines every second) until I hit ctrl-c Jan 23 22:06:14 hmmm you're right it works Jan 23 22:06:22 but the uImage-palmpre.bin failed Jan 23 22:06:25 I'll retry it Jan 23 22:07:11 florian: and that thing with the 100% cpu xmodmap Jan 23 22:08:05 cs_nbp: that's rather strange indeed Jan 23 22:10:38 florian: I've got the impression something is seriously wrong weither with the kernel or the graphics driver Jan 23 22:11:12 florian: btw irq handling in suspend is broken, too "LX: require interrupt" (or similar) Jan 23 22:11:44 florian: use it for daily work now so I notice a couple of things Jan 23 22:12:57 cs_nbp: I see a reset at boot time but then after one or two more attempts it boots Jan 23 22:13:41 florian: you mean a screen flicker? I get one screen flicker and then kernel boots Jan 23 22:13:54 florian: after boost console Jan 23 22:13:57 cs_nbp: no, a complete reset Jan 23 22:14:02 oink Jan 23 22:14:09 florian: don't have that Jan 23 22:14:10 before the filesystem gets mounted Jan 23 22:14:50 one thing that makes me nervous is that the last original commandline in the bb files hardcoded the amount of ram to 32mb Jan 23 22:15:36 ram? the 128mb? Jan 23 22:15:39 as 32? Jan 23 22:15:44 yes right Jan 23 22:16:50 that doesn't sound right Jan 23 22:17:03 it's not like we want a downgrade to the 5mx Jan 23 22:17:42 might slow down some things Jan 23 22:18:38 htop shows 122MB available Jan 23 22:19:04 sure it's not the special reserved ram for the kernel? Jan 23 22:19:22 or nand? Jan 23 22:25:07 florian: which recipe is that? Jan 23 22:25:58 cs_nbp: boost-bootcode_git.bb, but it has changed some time ago. Jan 23 22:39:02 florian: there is something funny in kernel and distro config Jan 23 22:39:31 florian: distro says 'only utf8 locale', kernel default NLS option is iso8859-1 Jan 23 22:40:49 not sure that's a problem though **** ENDING LOGGING AT Tue Jan 24 02:59:57 2012