**** BEGIN LOGGING AT Thu Sep 30 02:59:57 2010 Sep 30 03:57:23 where does the gpio mknod stuff happen on most platforms? Sep 30 03:59:51 philipp64: I think that's hotplug that creates the actual device nodes....there's no explicit creation Sep 30 04:09:45 so I need to add rules then. Sep 30 04:27:50 cshore_: still there? Sep 30 04:28:16 sorry, looking at other windows Sep 30 04:28:27 what's up? Sep 30 04:28:32 no worries. wasn't sure what timezone you're in. Sep 30 04:29:21 so, regarding the patch I sent on saturday or sunday for Geos, it's been suggested that I redo parts of it. Sep 30 04:29:36 in particular, let's see... Sep 30 04:30:57 here... /etc/init.d/leds-geos Sep 30 04:31:55 regarding the gpio mknod stuff I think the kernel module populates /sys, and does whatever it is that causes hotplug events, and hotplug automagically creates the device nodes...at least I'm not aware of any specific gpio node creation Sep 30 04:37:42 ok, let's back up a bit. how do platforms create LED entries, and then associate them with Ethernet transmission, disk activity, etc? Sep 30 04:47:45 I'm looking, for example, at target/linux/ar71xx/base-files/etc/uci-defaults/rb750 for instance trying to understand how it works. Sep 30 04:56:27 cshore_: any idea where this is documented, or how I can munge my leds-geos script into this format? Sep 30 05:29:00 sorry I keep losing this window Sep 30 05:30:17 the LED entries are created in the platform driver in the kernel...the scripts just use defined leds. I don't think it's documented anywhere and I don't know much about it, unfortunately Sep 30 05:35:38 ok. is uci documented anywhere? how one manipulates /etc/modules.d/ for instance? Sep 30 06:13:49 uci is documented on the wiki, but modules.d isn't part of wiki (and I'm not sure what you mean by manipulate modules.d) Sep 30 06:16:22 the issue is that I need to add modules args to /etc/modules.d/50-gpio-cs5535 ... Sep 30 07:41:18 hello Sep 30 08:09:33 cshore_: ping Sep 30 09:05:41 hi to all. What does it happens when after make menuconfig for a specific target in the next make V=99 call the system warn that some variables in .config.target are not set? Sep 30 09:06:03 The message is something like this: Sep 30 09:06:03 echo "# CONFIG_KALLSYMS is not set" >> /home/enrico/workspace/Backfire/build_dir/linux-lpc313x/linux-2.6.32/.config.target Sep 30 09:11:54 glp: pong Sep 30 09:12:03 glp: received the routers Sep 30 09:50:51 mb * r23157 /trunk/target/linux/omap24xx/Makefile: omap24xx: Update to 2.6.36-rc6 Sep 30 09:52:14 acoul: ping Sep 30 09:55:03 After investigating, I see that this happens only if I set the target build destination as "ram disk" This option is different between kamikaze and backfire. Sep 30 10:18:49 mb * r23158 /packages/ (6 files in 6 dirs): Add me as maintainer for certain packages. Sep 30 10:49:27 jow * r23159 /trunk/package/ (8 files in 8 dirs): [package] add maintainer information Sep 30 10:51:20 build #1 of brcm63xx is complete: Failure [failed compile_4] Build details are at http://tksite.gotdns.org:8010/builders/brcm63xx/builds/1 Sep 30 10:51:37 mb * r23160 /trunk/target/linux/omap24xx/Makefile: omap24xx: Add maintainer information Sep 30 11:01:47 mb * r23161 /trunk/include/package-dumpinfo.mk: Add maintainer information to menuconfig description dialog Sep 30 11:39:13 build #0 of ps3 is complete: Failure [failed compile_6] Build details are at http://tksite.gotdns.org:8010/builders/ps3/builds/0 Sep 30 13:48:37 build #0 of orion is complete: Exception [exception failed slave lost shell_10 compile_12] Build details are at http://tksite.gotdns.org:8010/builders/orion/builds/0 Sep 30 13:48:37 build #0 of rb532 is complete: Exception [exception failed slave lost shell_10 compile_12] Build details are at http://tksite.gotdns.org:8010/builders/rb532/builds/0 Sep 30 13:48:39 build #0 of pxcab is complete: Exception [exception failed slave lost shell_10 compile_12] Build details are at http://tksite.gotdns.org:8010/builders/pxcab/builds/0 Sep 30 13:48:41 build #0 of rdc is complete: Exception [exception failed slave lost shell_10 compile_12] Build details are at http://tksite.gotdns.org:8010/builders/rdc/builds/0 Sep 30 13:48:43 build #0 of au1000 is complete: Exception [exception failed slave lost shell_10 compile_12] Build details are at http://tksite.gotdns.org:8010/builders/au1000/builds/0 Sep 30 13:50:37 build #1 of atheros is complete: Failure [failed shell_3] Build details are at http://tksite.gotdns.org:8010/builders/atheros/builds/1 Sep 30 13:59:57 Any hints about the cause of this error: i486-openwrt-linux-uclibc-gcc -DHAVE_CONFIG_H -I../../include -I../../include -I. -I/home/rriggio/src/kamikaze/staging_dir/target-i386_uClibc-0.9.30.1/usr/include -I/home/rriggio/src/kamikaze/staging_dir/target-i386_uClibc-0.9.30.1/include -I/home/rriggio/src/kamikaze/staging_dir/toolchain-i386_gcc-4.1.2_uClibc-0.9.30.1/usr/include -I/home/rriggio/src/kamikaze/staging_dir/toolchain-i386_gcc-4.1.2_uClibc-0.9.30. Sep 30 13:59:59 1/include -DCLICK_TOOL -O2 -pipe -march=i486 -funit-at-a-time -fhonour-copts -c ../../lib/clp.c -o clp.o Sep 30 14:00:01 make[5]: [clp.o] Error 1 (ignored) Sep 30 14:14:01 \help Sep 30 14:28:35 build #1 of cobalt is complete: Failure [failed compile] Build details are at http://tksite.gotdns.org:8010/builders/cobalt/builds/1 Sep 30 14:28:39 build #1 of ep93xx is complete: Failure [failed compile] Build details are at http://tksite.gotdns.org:8010/builders/ep93xx/builds/1 Sep 30 14:32:45 build #1 of mpc52xx is complete: Failure [failed compile] Build details are at http://tksite.gotdns.org:8010/builders/mpc52xx/builds/1 Sep 30 14:35:14 build #1 of gemini is complete: Failure [failed compile] Build details are at http://tksite.gotdns.org:8010/builders/gemini/builds/1 Sep 30 14:39:22 build #1 of etrax is complete: Failure [failed compile] Build details are at http://tksite.gotdns.org:8010/builders/etrax/builds/1 Sep 30 14:49:38 acoul * r23162 /trunk/package/grub/Makefile: package/grub: fix build issues under 64bit FreeBSD Sep 30 15:00:55 nbd * r23163 /trunk/package/mac80211/ (Makefile patches/017-remove_ath9k_rc.patch): ath9k: compile out the ath9k rate control Sep 30 15:15:35 build #1 of ixp4xx is complete: Failure [failed compile] Build details are at http://tksite.gotdns.org:8010/builders/ixp4xx/builds/1 Sep 30 15:27:17 build #1 of rb532 is complete: Failure [failed compile] Build details are at http://tksite.gotdns.org:8010/builders/rb532/builds/1 Sep 30 15:32:05 build #1 of orion is complete: Failure [failed compile] Build details are at http://tksite.gotdns.org:8010/builders/orion/builds/1 Sep 30 15:57:44 build #1 of pxcab is complete: Failure [failed compile] Build details are at http://tksite.gotdns.org:8010/builders/pxcab/builds/1 Sep 30 16:05:28 build #1 of au1000 is complete: Failure [failed compile] Build details are at http://tksite.gotdns.org:8010/builders/au1000/builds/1 Sep 30 16:36:46 cshore_: I hope they work :-) Sep 30 16:37:52 I think they can be beaten into shap Sep 30 16:38:07 I haven't booted them yet, but I'll let you know soon Sep 30 16:39:13 I've been busy working on my sister's computer before I head down to my visit my mom and my sister for a few days starting tomorrow Sep 30 16:49:44 chore_: don't you sleep? :-) Sep 30 19:09:32 heh Sep 30 19:10:40 usually, just sometimes I have time pressures....like tomorrow I'll be heading down to my mom's to visit my mom and my sister and I'm working on a computer for her and want to have my laptop ready so I can work down there. Sep 30 19:11:32 besides the day before last I slept the whole day away Sep 30 19:11:48 got to make up for such of an unheard of thing ;-) Sep 30 21:54:14 how do i make an ISO?? Sep 30 21:54:38 looking in the image makefile i see that the stuff is there that makes the iso Sep 30 21:54:53 but whats the config need to look like? Sep 30 22:02:04 RealOpty: searching for ISO in menuconfig tells me: "Depends on: TARGET_ROOTFS_INITRAMFS && TARGET_x86" Sep 30 22:06:14 mb * r23164 /packages/Xorg/app/pwrtray/Makefile: pwrtray: Improve screen and device locking Sep 30 22:08:19 KanjiMonster, ah i should of thought of that, ty Sep 30 22:08:30 i didnt have INITRAMFS selected Sep 30 22:37:15 nbd: tried to draw a larger conversation about the merits of using uci-defaults for customizing an image... it would be nice to do as much as possible at build time without interfering with your goal of minimizing build time. Sep 30 22:37:27 (i.e. not building kernel modules more than once were possible) Sep 30 22:38:06 maybe I'm just not understanding all the constraints. Sep 30 22:38:22 too bad that xMff isn't around to add to the conversation. Sep 30 22:40:04 philipp64|laptop: ah, you are on irc, too. Sorry for not replying yet (I'm Jonas, btw), haven't really have the time yet to look into it Sep 30 22:41:38 ok. had been hoping to get my commits in sync with the release of the platform to the public... but I don't think that's going to happen. rather get it right than do it over anyway. Sep 30 22:41:57 and no, I don't work for Traverse. I just use a few of their boxes and really like them. Sep 30 22:43:50 tbh, I don't know much about the x86 targets Sep 30 22:46:23 that's ok. it's a generic enough problem, I think. Sep 30 22:46:27 but as an insight on how its done on mips (or how its supposed to be done): there's boot time detection of the board, which in turn is responsible for registering platform devices, which get their board tailored configuration provided (especially for root fs device and network interfaces) Sep 30 22:47:30 of course, this mostly comes from the fact that many devices on socs can't be really detected, but you have to "know" they are there Sep 30 22:50:43 this is helped by the fact that most bootloaders for embedded have special linux support that supplies a commandline with the board name, or provide a data structure for linux with the information Sep 30 22:51:32 which target are we talking about? Sep 30 22:52:13 I was looking at /proc/cpuinfo and there wasn't anything distinguishing there. and there's no "dmidecode"... Sep 30 22:52:38 so I can't count on that. You're right that you might have to count on a kernel ... argument like "platform=geos" or whatever. Sep 30 22:54:30 ar71xx directly uses this; bcm47xx and bcm63xx uses some other ways of identying at boot time what they are booting from Sep 30 22:55:14 bcm47xx has pretty good hardware support for probing the devices. Most platforms don't have that. Sep 30 22:55:50 On bcm47xx there are almost no so called "platform devices", which are statically created devices. Sep 30 22:56:06 only the ssb bus itself Sep 30 22:56:21 Yeah (though it's not a platform device, technically) Sep 30 22:56:57 well, it's integrated in the soc, isn't it? ;) Sep 30 22:57:18 No I mean it's not implemented as a struct platform_device Sep 30 22:57:24 ah, okay, yeah Sep 30 22:57:26 so how does a platform (target or subtarget) customize it's kernel-params line? Sep 30 22:58:20 The bootloader usually provides it. Sep 30 23:05:01 not happening in my case. they're using coreboot. Sep 30 23:05:14 (it's a skinny open BIOS...) Sep 30 23:05:26 or rather, OSS BIOS. Sep 30 23:16:09 Well, there are only three ways to do it: 1) Provide a special kernel for the platform, 2) provide kernel parameters from bootloader, 3) All devices are safe to autoprobe. Sep 30 23:24:21 stintel: ping Sep 30 23:46:39 (3) is rarely the case in my experience. a lot of embedded devices assume that because the user won't be peeking inside them, that you can sweep a lot of ugliness under the carpet. Sep 30 23:47:19 philipp64|laptop: sorry, haven't had time to review your stuff yet Sep 30 23:47:34 still busy with other stuff Sep 30 23:50:04 KanjiMonster: on another topic, how does a platform specify which LEDs need to be created and what GPIO lines they correspond with? oh, and I have a "soft reset" button that corresponds to a GPIO line as well. Sep 30 23:56:29 philipp64|laptop: I can't really do better than doing educated guesses, but you can either register them at boot time, assuming the gpio controller is a platform device, or probably later on the first boot through uci-defaults (assuming you can id the board at this stage) Sep 30 23:57:40 I noticed that the ath9k driver registers some LED's. not sure how this works. Oct 01 00:03:36 philipp64|laptop: look at the ath9k code ;) Oct 01 00:04:09 that's what's weird. I thought all of that was implemented in the LED-class stuff. Oct 01 01:30:01 why would genext2fs says this Oct 01 01:30:03 ./genext2fs: couldn't allocate a block (no free space) Oct 01 01:30:08 when its all lies! Oct 01 01:30:47 too few inodes or block limit too low Oct 01 01:34:12 ah my FS was larger than what i expected, ty xMff Oct 01 01:36:22 trying to make a debian root_fs that can be built from openwrt code. not having much luck tho, got the kernel to boot but then it mounts rootfs then hangs Oct 01 02:34:41 xMff: so if I wanted to introduce into the build process, some target-specific scripts that could be run to customize the image in place before the .iso or .ext2 or whatever got created... where does that happen? **** ENDING LOGGING AT Fri Oct 01 02:59:57 2010