**** BEGIN LOGGING AT Fri Oct 21 02:59:57 2011 Oct 21 07:29:52 good morning Oct 21 07:38:18 hi mckoan, all Oct 21 08:46:30 mornin Oct 21 09:08:22 ji zecke Oct 21 09:08:25 hi jineld Oct 21 09:08:31 hi woglinde Oct 21 10:13:29 03Paul Menzel  07master * rf2d53aa074 10openembedded.git/recipes/binutils/ (binutils-canadian-sdk_2.18.bb binutils-cross-sdk_2.18.bb): (log message trimmed) Oct 21 10:13:29 binutils-{canadian,cross}-sdk_2.18: Remove checksums and implicitly update them Oct 21 10:13:29 Due to a GPL violation corrected Binutils archives were uploaded with the suffix »a« and the faulty archives were removed [1]. The URLs redirect to the new archives and therefore the checksums are now incorrect. Oct 21 10:13:29 In the following commit Oct 21 10:13:30 commit bc8ddbf7944f82383936d88379619aa46c3954a2 Oct 21 10:13:30 Author: Steffen Sledz Oct 21 10:13:31 Date: Mon Sep 5 17:39:57 2011 +0200 Oct 21 12:43:18 morning dudes Oct 21 12:43:31 hi XorA Oct 21 12:45:37 hi xora Oct 21 12:46:08 party preperations going well for people? Oct 21 12:51:09 heh Oct 21 12:52:05 party? Oct 21 13:16:19 Prague party Oct 21 13:16:31 I heard you guys planned to eat and drink the town dry next week Oct 21 13:17:39 hell no! I need to eat and dring here also week after that :) Oct 21 13:18:08 JaMa|zzz: you better lead them astray then :D Oct 21 13:19:17 * JaMa|zzz is going to warn all pubs that OE crew is comming.. :) Oct 21 13:19:48 I'll try more Oct 21 13:20:25 but WOW Oct 21 13:20:37 sd_max_clk to the minimum makes suspend/resume work Oct 21 13:21:00 thanks a lot!!! Oct 21 13:21:20 what value did you use? Oct 21 13:21:43 let me find it Oct 21 13:21:56 and please reply to that ticket.. as my advice to set sd_max_clk wasn't used it seems.. Oct 21 13:22:38 /sys/module/glamo_mci/parameters/sd_post_power_clock Oct 21 13:22:43 I used that value Oct 21 13:22:51 that should be the minimum Oct 21 13:23:00 1000000 Oct 21 13:23:14 should be 1Mhz Oct 21 13:30:16 I'll do after going out Oct 21 13:40:21 can anyone help me how to compile hwinfo in Openembedded ................ I want to extract hardware info from my board.... Oct 21 13:40:38 snkt, cat /proc/cpuinfo etc...? Oct 21 13:44:37 hi, all! Oct 21 13:45:03 is it possible to access things like DEPLOY_DIR_IMAGE from python functions? Oct 21 13:45:39 I need to split my rootfs into chunks for easier downloading into board, and I think it is easier with python Oct 21 13:46:57 but plain bb.data.getVar("DEPLOY_DIR_IMAGE") prevents bitbake from parsing my .bb Oct 21 13:47:01 any ideas? Oct 21 13:48:29 http://pastebin.com/9QgaXrsL Oct 21 13:48:41 that's my code Oct 21 14:20:52 hi Oct 21 14:21:16 I'm looking into building a really small EC2 image Oct 21 14:21:24 did anyone had a go at it already ? Oct 21 14:22:11 I guess I would have to add a xen guest kernel, some dhcp and ssh auto-configuration and kernel tweaks Oct 21 14:25:40 is there some documentation on getVar usage? Oct 21 14:27:34 just the code, really. but there isn't much to document. bb.data.getVar(, , and d.getVar(, ) Oct 21 14:39:36 kergoth: how can I use it from python functions in .bb for e.g. MACHINE_POSTPROCESS_COMMAND? Oct 21 14:40:11 this one fails because getVar used improperly http://pastebin.com/9QgaXrsL Oct 21 14:40:54 that's wrong, yes. the datastore isn't being passed in Oct 21 14:41:02 the 'd' variable Oct 21 14:41:43 kergoth: thanks a lot! Oct 21 14:42:09 does anyone have experience in working/booting cuImage type kernels? (i.e. with included dts for old bootloaders that are not dts aware)? Oct 21 14:43:49 I know it's not directly OE related :> I am still trying to get that storcenter thing running with a newer kernel (it once was openprotium in OE but does not seem to be maintained anymore) Oct 21 14:43:49 Jin^eLD: u-boot works properly with these, without any problems Oct 21 14:44:06 slapin: does building a cuImage automatically mdify the laod address and entry point? Oct 21 14:44:35 slapin: when I build a normal uImage I can set entry point and load address to what I need; but when the cuImage is generated that settings are ignored Oct 21 14:44:53 I figured that happens because the image is generated by do_compile and not by the mkimage script Oct 21 14:45:27 I tried some settings in the kernel config but that still produced weirdo addresses and I am not sure where it is taking them from, when creating a cuImage Oct 21 14:45:47 Jin^eLD: I load cUimage at address, which it was built for, IIRC OE is broken re cuImage and I just use kernel build result without mkimage being run. Oct 21 14:45:57 *cuImage Oct 21 14:46:17 slapin: but where do you specify the addresses? in the defconfig? Oct 21 14:46:27 because OE's variables are ignored in that case (since mkimage is not being run) Oct 21 14:47:09 Jin^eLD: I patch kernel directly, but i think this can be passed via config too Oct 21 14:47:52 do you have a link for me, where do you patch it? Oct 21 14:48:20 I'm far from repository at the moment, but let me see Oct 21 14:54:10 slapin: from what I read on the web, the cuimage picks a different entry address itself, but I am not yet sure if that can be set or if that is OK or what exactly is happening there Oct 21 14:58:19 Jin^eLD: no idea, I put image where it belongs and it works (qe1/cpm1 have theirs bugs though), my board is old and kernel is 2.6.32.x. There is some mathematics with calculation of address, I had no time to do it properly and disabled it forcing proper address, but can't remember details and can't get there to look now. Oct 21 14:59:37 I am not even sure if that is my problem, coul very well be that its just the serial that is getting messed up for some reason Oct 21 14:59:55 http://pastebin.mozilla.org/1360580 Oct 21 15:00:34 the older non-dts kernel that works, a regular uImge, has a load addr and entry point of 0 Oct 21 15:02:23 Jin^eLD: I'd check clocks first. Have you tried various baud rates? what is your console= setting? Oct 21 15:02:58 I have tried other baudrates, yes; the supposedly correct setting is 115200n8 Oct 21 15:03:06 this works with the older kernel and it also works with uboot Oct 21 15:03:44 a question of course is, what this device tree blob is doing when it gets loaded Oct 21 15:04:19 Jin^eLD: then this might be clocks. u-boot arranges blob adddress with kernel properly, so it might be either dts itself messed up or you forgot to configure something Oct 21 15:04:52 to configure in the kernel config you mean? Oct 21 15:05:03 Jin^eLD: do you have oscilloscope Oct 21 15:05:07 no :) Oct 21 15:05:12 Jin^eLD: I mean dts Oct 21 15:05:39 and if I had one I would not know how to use it :) I am a loser when it comes to hardware... the only hardware I know well is UAZ mechanics :) Oct 21 15:05:45 Jin^eLD: I'd idvice to get oscilloscope and check what you get on serial port first Oct 21 15:06:07 slapin: as in "dts reconfires the serial to something else"? Oct 21 15:06:45 Jin^eLD: cool, does UAZ have some smart electrnics in engine control these days? Oct 21 15:07:10 slapin: these days yes, but I have 1976 version with a minimum of electronics :) Oct 21 15:07:20 Jin^eLD: I mean dts file for your board might configure something in a wrong way and needs checking Oct 21 15:07:42 ok, thanks, I got your idea, I will try to figure out what the storcenter dts file is doing... Oct 21 15:09:10 Jin^eLD: I think $100 oscilloscope from sparkfun will do for your work, and well worth money :) Oct 21 15:09:53 slapin: I fear electrical stuff because I have absolutely no clue how that stuff works :) Oct 21 15:09:58 but I will consider it Oct 21 15:10:57 Jin^eLD: by the way, what CPU is on your board? 133MHz looks familiar Oct 21 15:11:31 slapin: its MPC8241 Oct 21 15:12:01 Jin^eLD: ah, bad luck, I have mpc885 with some other troubles Oct 21 15:12:02 and the device is an Iomega StorCenter, as far as I recall the kurobox hg should have something similar Oct 21 15:12:13 I see... Oct 21 15:12:40 Jin^eLD: but I think bus clock is weird on your config Oct 21 15:13:33 how so? I think 133MHz should be fine there? that's what uboot says at the start Oct 21 15:14:01 unlike the kurobox hg people I do not have a usable uboot configuration to update uboot, that's the reason for trying the cuImage approach Oct 21 15:14:32 133MHz is CPU clock Oct 21 15:15:08 timebase-frequency Oct 21 15:15:21 Jin^eLD: I think it is from dts Oct 21 15:15:25 or something Oct 21 15:15:40 I have normal values ion my config at least Oct 21 15:16:04 0x7080 is not normal Oct 21 15:16:33 28800 = ? Oct 21 15:16:39 http://pastebin.mozilla.org/1361341 Oct 21 15:16:49 like, this part should have something 133-ish in there? Oct 21 15:17:04 or /2 or something Oct 21 15:17:11 bigger number Oct 21 15:17:49 I meant the paste Oct 21 15:17:54 its a paste from the storcenter dts Oct 21 15:19:00 I can't see where it got 133MHz from Oct 21 15:19:17 it should either get all the rest values from the same place or something Oct 21 15:19:32 slapin: I was wrong, sorry, it should be 266mhz Oct 21 15:19:34 CPU: MPC8241 Revision 1.4 at 266.666 MHz Oct 21 15:19:38 that's what uboot says Oct 21 15:19:39 check u-boot code if it patches device tree blob Oct 21 15:19:52 133 was wrong, I made a mistake Oct 21 15:20:14 then CPU clock-frequency <- 0x7f28154 (133MHz) is wrong too Oct 21 15:20:15 my uboot is from 2005, it is not dts aware... Oct 21 15:20:31 device tree is old as hills Oct 21 15:20:51 I think u-boot new about this stuff before then Oct 21 15:20:56 indeed, I see... 133 is wrong then Oct 21 15:21:13 slapin: I belive that uboot sets everything up correctly, and expects a non-dts kernel Oct 21 15:21:28 but I could not find a way to disable dts in the 3.x kernel Oct 21 15:21:51 check all values, probably something patches-up things, what is bootwrap? Oct 21 15:22:30 bootwrap is this thing that embeds the dts tree in the kernel for non-dts aware bootloaders Oct 21 15:22:36 without that the kernel did not even load Oct 21 15:22:59 check what it does, it probably have some logic for these numbers Oct 21 15:23:14 I get the idea I think, thanks.. let me search for it Oct 21 15:26:33 it seems that some fixup is done here cuboot-824x.c Oct 21 15:48:30 hmm, is there a good intro to devicetree stuff? Oct 21 15:48:31 not up to speed Oct 21 15:54:29 executive summary - its like ACPI only not dumb Oct 21 15:55:08 rofl Oct 21 15:56:32 l8r guys Oct 21 16:02:20 haha Oct 21 16:02:23 thanks! Oct 21 16:02:25 :P Oct 21 16:06:03 ah, http://devicetree.org/Device_Tree_Usage Oct 21 18:09:50 Crofton|work, pingu? Oct 21 18:11:17 yeah Oct 21 18:11:31 khem had a dns reuest Oct 21 18:22:25 Crofton|work, yes, thats what I'm calling about. Oct 21 18:23:02 downloas is a cname to the nas-admin machine? Oct 21 18:59:12 what provides which and tempfile in oe-core (aka debianutils)? Oct 21 19:10:37 probably busybox for which. oe had debianutils, maybe it just needs to be pulled into meta-oe Oct 21 19:10:50 Crofton|work, yes Oct 21 19:11:05 kergoth: i suspect it would be busybox Oct 21 19:13:29 if its just those two from busybox and rest from coreutils that would be waste I think Oct 21 19:14:07 would be good to have debianutils around for the proper-tools setup Oct 21 19:14:14 agree Oct 21 19:14:38 but if one does not use coreutils then busybox is the king Oct 21 19:15:07 * kergoth nods Oct 21 19:15:21 I worry about it at times, the proliferation of applets i mean Oct 21 19:15:29 they need someone to say no on occasion Oct 21 19:15:30 heh Oct 21 19:15:53 landley had his toybox thing for a while that looked interesting, but its unmaintained Oct 21 19:52:41 Can someone help me to look why sstage is not staging lib64? **** ENDING LOGGING AT Sat Oct 22 02:59:56 2011