[00:09] <[mbm]> nbd: pastebin.com/750037
[00:19] Action: [mbm] looks at changeset 3873 ..
[00:20] <[mbm]> nbd: if a directory like that mysteriously shows up it's because it somehow ran against the system (amd64) toolchain .. the solution is to fix that, not remove the directory
[00:20] <nbd> i think it's an error in the busybox makefile
[00:21] <nbd> i don't think it's serious
[00:21] <[mbm]> I'm still looking into the toolchain issue above
[00:21] <[mbm]> could have sworn it compiled 6 hours ago
[00:23] <nbd> did you remove the staging dir as well after the parallel build attempt?
[00:24] <[mbm]> well, just for fun let's do a full rebuild .. rm -rf .config .pkginfo .pkgdeps *_mipsel
[00:24] <[mbm]> .. and it's not smart enough to pop up menuconfig
[00:25] <[mbm]> .. make menuconfig, save the defaults ..
[00:25] <[mbm]> and wait 15 minutes
[00:25] <nbd> need to fix that
[00:32] <[mbm]> .. and we've crashed at exactly the same place
[00:32] <[mbm]> shown in the pastebin above
[00:36] <[mbm]> nbd: btw the point of FORCE was to replace .PHONY (which you've used again in 3872)
[00:37] <nbd> right. so we can just remove FORCE there
[00:38] <CIA-16> nbd * r3875 /branches/buildroot-ng/openwrt/target/linux/kernel.mk: remove useless FORCE depend
[00:38] Action: [mbm] thinks the FORCE stuff is easier to follow than the .PHONY
[00:39] <nbd> so what do you want to do in this case?
[00:39] <[mbm]> all the stuff in packages I replaced with FORCE
[00:39] <[mbm]> think we should try to be somewhat consistant
[00:40] <nbd> so you want to move that line:
[00:40] <nbd> @{ [ "$(INSTALL_TARGETS)" != "" ] && $(IPKG) install $(INSTALL_TARGETS) || true; }
[00:40] <nbd> to the vmlinux target?
[00:41] <[mbm]> why not pkg-install: FORCE
[00:41] <[mbm]> ?
[00:41] <nbd> ah, that's what you meant
[00:41] <[mbm]> although you're unlikely to have a pkg-install file so the force is somewhat silly
[00:42] <nbd> same for all the other targets?
[00:42] <[mbm]> right, no point in using .PHONY
[00:44] <nbd> i'll go through the other parts in target/linux as well
[00:45] <[mbm]> btw, downgraded to 3868 and it appears to actually eb building the toolchain correctly
[00:48] <nbd> ah
[00:48] <nbd> found it
[00:48] <nbd> i removed MAKE1
[00:48] <CIA-16> nbd * r3876 /branches/buildroot-ng/openwrt/toolchain/uClibc/Makefile: fix toolchain build
[00:48] <nbd> try the latest rev with parallel build again
[00:51] <[mbm]> k
[00:51] <[mbm]> well, last time even the single builds had issues
[00:52] <nbd> but i'm sure that the issue is resolved now
[00:52] <nbd> it wasn't building uclibc
[00:58] <[mbm]> seems to have fixed the single builds
[01:02] <[mbm]> parallel builds sare still screwy
[01:03] <[mbm]> crashed one by not having staging_dir/bin/sed
[01:03] <nbd> where did you add the parallel build?
[01:04] <[mbm]> I had it enabled in the menuconfig and I ran it as 'make -j6'
[01:05] <nbd> don't do that. try adding it to specific $(MAKE) invocations in toolchain/*/Makefile
[01:06] <[mbm]> ugh
[01:06] <nbd> that way we have full control over what's going to be built in parallel
[01:06] <nbd> makes it easier to exclude some screwy parts
[01:07] <[mbm]> ok, so use the menuconfig to set the number of jobs and then edit the makefiles to call make with that number?
[01:07] <nbd> yes. package uses that number already
[01:07] <[mbm]> ok
[01:08] <nbd> btw. i'm going to disable gdb by default
[01:08] <nbd> most people don't need it anyway
[01:08] <[mbm]> :)
[01:08] <[mbm]> didn't we have that asme discussion.. a year ago?
[01:08] <Kaloz> wbx wanted to keep it....
[01:08] <nbd> i don't remember it
[01:09] <[mbm]> Kaloz: yeah I remember that
[01:09] <nbd> wbx is gone for now...
[01:09] <Kaloz> he was arguing with me when i wanted to disable it
[01:09] <nbd> you can still enable it in menuconfig...
[01:12] <[mbm]> right .. disable it .. next topic ..
[01:13] <Kaloz> next topic that i should get up in 5 hours and i still have to do too much shit
[01:13] <nbd> i think i've changed all the .PHONY stuff in my tree (even the stuff that didn't explicitly add it)
[01:13] <nbd> i'll do a test compile and then i'll commit it
[01:16] <[mbm]> I suppose the main thing is that the firmware itself builds in parallel
[01:16] <[mbm]> the toolchains you really only build once
[01:18] Action: nbd took some time to write comments on the blogs and news sites that covered wbx' fork
[01:18] Action: [mbm] had no idea it was covered anywhere other than wbx's blog
[01:19] <nbd> pro-linux.de and golem.de
[01:19] <nbd> my guess is that waldemar has some contacts there
[01:19] <[mbm]> I'm sure he does
[01:29] <CIA-16> nbd * r3877 /branches/buildroot-ng/openwrt/ (29 files in 25 dirs): cleanup; replace .PHONY with FORCE; disable gdb by default
[01:30] <[mbm]> hmm google does such a lousy job of translating
[01:30] <Kaloz> babelfish
[01:31] <[mbm]> not much better
[01:31] <[mbm]> the translations are to the point that I could probably read the original german versions easier
[01:32] <[mbm]> ohwell, doesn't appear to be anything newsworthy in them
[01:32] <nbd> no. it's basically the same content that's already in his open letter
[01:33] <[mbm]> that's what I mean
[01:34] <[mbm]> nbd: you bastard - "rmdir: .../busybox/lib64: no such file or directory .. make: *** [busybox-compile] Error 2
[01:34] <[mbm]> ;)
[01:35] <nbd> oops
[01:36] <CIA-16> nbd * r3878 /branches/buildroot-ng/openwrt/package/busybox/Makefile: fix busybox build
[01:37] Action: nbd tries a parallelized toolchain build
[01:37] <[mbm]> looks like ppp dependancies are wrong
[01:37] <[mbm]> it wants pcap
[01:37] <[mbm]> (didn't nico remove that?)
[01:37] <nbd> i removed the runtime dependency
[01:37] <nbd> but the build time dependency is still there
[01:37] <[mbm]> yeah but it still needs pcap.h for compile
[01:38] <[mbm]> or it bombs make
[01:38] <nbd> it still uses parts of pcap
[01:38] <nbd> for the filter stuff
[01:38] <[mbm]> right now it can't find pcap.h
[01:38] <[mbm]> probably because it isn't selected in menuconfig
[01:38] <nbd> did you remove that dependency?
[01:38] <nbd> hmm
[01:38] <[mbm]> nope
[01:38] <nbd> then there's a bug in the InstallDev stuff
[01:39] <nbd> did it build libpcap?
[01:39] <nbd> i mean the devel stuff
[01:40] <[mbm]> think it's an issue with include paths
[01:40] <[mbm]> I just compiled pcap and it still won't compile ppp
[01:41] <[mbm]> ah .. it's not even in staging_dir
[01:42] <nbd> i found the bug
[01:42] <nbd> seems like i can't do ifdef on stuff that i have defined
[01:45] <CIA-16> nbd * r3879 /branches/buildroot-ng/openwrt/toolchain/binutils/Makefile: allow parallel build of binutils
[02:06] <CIA-16> nbd * r3880 /branches/buildroot-ng/openwrt/package/rules.mk: fix InstallDev bug
[02:06] <nbd> [mbm]: should work now
[02:18] <CIA-16> nbd * r3881 /branches/buildroot-ng/openwrt/package/ipset/Makefile: remove broken dependency
[02:19] <CIA-16> nbd * r3882 /branches/buildroot-ng/openwrt/Makefile: add clean targets, more FORCE stuff
[02:28] <CIA-16> nbd * r3883 /branches/buildroot-ng/openwrt/package/rules.mk: add TARGET_CONFIGURE_OPTS to default compile command
[02:31] <CIA-16> nbd * r3884 /branches/buildroot-ng/openwrt/package/rules.mk: remove some debugging code, include package/rules.mk in package dependency check
[02:47] <CIA-16> nbd * r3885 /branches/buildroot-ng/openwrt/target/linux/kernel.mk: fix dependency problem
[02:47] <nbd> alxhh: fixed in svn
[02:47] <nbd> alxhh: (hopefully)
[02:47] <alxhh> *g*
[03:06] <CIA-16> nbd * r3886 /branches/buildroot-ng/openwrt/package/rules.mk: some bugfixes and additions for the default compile target
[03:12] <[mbm]> :)
[03:17] <CIA-16> nbd * r3887 /branches/buildroot-ng/openwrt/package/nvram/src/ (Makefile include/): add broadcom include files, fix build
[03:22] <nbd> hmm... there's a #freewrt
[03:23] <nbd> lmao. it was registered by elektik over a year ago
[03:24] <nbd> and now wbx et al. are using it
[03:25] <[mbm]> interesting
[03:26] <nbd> it doesn't have a topic lock :)
[08:01] <[mbm]> hmm .. sb_irq isn't exported
[08:15] <wigyori> .
[12:55] <[mbm]> anyone have one of the boards with serial on a gpio line?
[13:28] <[mbm]> hmm .. that's weird .. even on a cold boot the watchdog reboot flag is set
[13:28] <[mbm]> thought that was only supposed to be set if the board got rebooted by the watchdog timers
[13:31] <[mbm]> also don't understand why the code for gpio on the serial never seems to enable the gpio interrupts
[19:11] <xrg_> :)
[19:11] <Kaloz> 'lo :)
[19:12] <xrg_> isn't the devfs obsolete?
[19:12] <Kaloz> udev is simply not a way to go
[19:12] <[mbm]> depends on who you talk to
[19:12] <Kaloz> i will look into mdev later, but devfs works flawlessly
[19:12] <[mbm]> udev imho is a hack
[19:12] <xrg_> I agree. For embedded, I would go with static..
[19:13] <[mbm]> static? bah, that would require us to ship with a fully populated /dev for anything anyone could ever possibly plug in
[19:13] <[mbm]> honestly, there's nothing wrong with devfs
[19:13] <xrg_> I can't find devfs in 2.6.17, however.. :(
[19:14] Action: Kaloz forward ported it
[19:14] <xrg_> mbm, there is one: it's inside the kernel.
[19:14] <[mbm]> xrg_: and?
[19:14] <xrg_> And it occupies kernel code segments. I prefer to have less mem allocated there..
[19:15] <[mbm]> and udev occupies user memory .. I still don't see what your point is
[19:17] <xrg_> It's a matter of taste actually. I prefer to let out of the kernel whatever can be..
[19:18] <[mbm]> go look at the size of a system with devfs and then a system with udev
[19:18] <[mbm]> and also note that udev can't be used to boot
[19:18] <xrg_> That's true
[19:19] <[mbm]> which then requires a static /dev
[19:20] <xrg_> oops:Author: Greg KH <gregkh@suse.de> 2005-06-22 01:24:19 "2c6e5a839f92591a4bc6cac4a575d42151645af3"
[19:20] <xrg_> [PATCH] devfs: remove devfs from Kconfig preventing it from being built
[19:20] <xrg_>
[19:20] <xrg_> Here's a much smaller patch to simply disable devfs from the build. If
[19:20] <xrg_> this goes well, and there are no complaints for a few weeks, I'll resend
[19:20] <xrg_> my big "devfs-die-die-die" series of patches that rip the whole thing
[19:20] <xrg_> out of the kernel tree.
[19:21] <xrg_> What next?
[19:21] <Kaloz> grab out patch
[19:21] <[mbm]> you act as though this was the first time they did something stupid
[19:22] <xrg_> Didn't anybody complain, then?
[19:22] <[mbm]> yes, there was tons of complaints
[19:24] <xrg_> Still, I ask how could we be more vanilla-compliant..
[19:24] <[mbm]> go search for Bruce Evans, and note the flame fest about him sabotaging it
[19:24] <xrg_> Do we need tons of /dev entries for embedded?
[19:24] <alxhh> xrg_: usb?
[19:24] <[mbm]> vanilla is not for embedded systems and it never will be
[19:24] <[mbm]> the vanilla kernel has always been for the pc
[19:24] <xrg_> Mine doesn't have usb, nor other hotplugs.
[19:25] <[mbm]> and very slow to merge in any otehr platforms or keep them up to date
[19:25] <[mbm]> and on a pc, udev works
[19:25] <alxhh> xrg_: lots of usb, minipci, pccard, etc
[19:25] <xrg_> IMHO, all code should be given to vanilla.
[19:25] <[mbm]> it's not best for embedded systems
[19:25] <xrg_> don't just say vanilla is different.
[19:26] <Kaloz> xrg_: it's given, but they don't take it fasz enough
[19:26] <Kaloz> fast
[19:26] <[mbm]> openwrt is a rather minimal set of patches to the vanilla kernel
[19:26] <[mbm]> we could have just as easily used a linux-mips kernel
[19:27] <xrg_> I see.
[19:27] <Kaloz> well, using that would be easy
[19:27] <Kaloz> :)
[19:27] <Kaloz> i mean easier :)
[19:27] <Kaloz> but this way it's cleaner
[19:27] <[mbm]> Kaloz: and it would be a few releases behind the vanilla kernel
[19:27] <xrg_> Couldn't there be a uCudev, say, then?
[19:28] Action: [mbm] points out that support for ramdisk was also broken
[19:28] <[mbm]> now you can't just compile a squashfs image and stuff it directly into the kernel
[19:28] <xrg_> yes, ramdisk gets rewritten.
[19:28] <[mbm]> you're expected to create a cpio archive which then gets extrated to a tmpfs
[19:29] <[mbm]> which is another really bad mistake for embedded systems
[19:29] <xrg_> I've tried that,once.
[19:29] <xrg_> mbm, why?
[19:29] <[mbm]> everyone did, and a number of them failed because the new ramdisk uses /init and not /sbin/init or anything standard
[19:30] <[mbm]> xrg_: not only does the cpio get worse compression than squashfs, waiting for it to extract the cpio archive to ram disk is noticably slower
[19:30] <xrg_> mbm, can't be. 'init' or /sbin/init is just selected from an algo.
[19:31] <[mbm]> granted it's now writable, but I'd rather not have the hardware watchdog fire off while I'm waiting for the system to boot
[19:31] <xrg_> Yes, setting it is rather tricky.
[19:31] <[mbm]> xrg_: no, trust me, the new ramdisk stuff in 2.6 uses /init and not the usually /sbin/init /linuxrc /bin/sh
[19:31] <[mbm]> there's not a damned thing tricky about the watchdog
[19:32] <[mbm]> the problem is that the bootup takes too long
[19:32] <xrg_> Oh, no, the cpio should NOT have the init (as far as I remember).
[19:32] <xrg_> the root fs should be mounted first.
[19:32] <[mbm]> so your chances of getting to userspace and refreshing the watchdog before it expires diminish as the size of the cpio increases
[19:33] <xrg_> I was referring to the ramdisk, not the watchdog.
[19:33] <[mbm]> I suggest you actually read the ramdisk code
[19:33] <xrg_> It has a different sequence, so that it mounts earlier in the boot process.
[19:33] <[mbm]> because if you don't have a /init it doesn't do anything
[19:34] <[mbm]> and yes, I wasted a whole day trying to figure that out
[19:34] <xrg_> Anyway, I won't be the one that will decide on the ramdisk issue..
[19:34] <[mbm]> and no it isn't documented anywhere
[19:36] <xrg_> I only want to keep close to vanilla, so that I can help them more. Being centralized reduces the maintenance overhead (in terms of diversity)..
[19:36] <[mbm]> there's a major difference between being close to vanilla and repeating mistakes just because they were made in vanilla
[19:37] <[mbm]> you really need to get away from the mentality that vanilla is perfect, especially for embedded systems
[19:38] <xrg_> No, it's not. But I want to help make it better.
[19:40] <xrg_> Anyway, I won't insist. let's code..
[19:41] Action: [mbm] just wants embedded systems to be as light and compact as possible, even if it means adding extra patches
[19:44] <[mbm]> ...
[19:45] <[mbm]> let's switch to openssl/openssl .. I know it's several megs larger than dropbear, but it's a standard ..
[19:55] Action: alxhh want emacs as standard editor
[19:56] <[mbm]> alxhh: we didn't have room left after installing the full x11 suite and gnome
[19:56] <[mbm]> :/
[22:31] <evilrabbi> What advice would you give someone tring to get this to work on untested devices?
[22:33] <nbd> what kind of untested device?
[22:33] <malbon> have a serial console cable handy (and working) and run from ram if possible.
[22:34] <evilrabbi> it's a tew-432brp
[22:35] <malbon> hmm will never work
[22:35] <evilrabbi> ah
[22:35] <evilrabbi> I guess this has been tested before then
[22:35] <malbon> It's a marvell device, and at present they are completely unsupported by openwrt
[22:35] <evilrabbi> =\
[22:36] <malbon> no, not tested, it's just not a supported chipset.
[22:36] <malbon> also having only 1mb of flash makes it sort of useless.
[22:36] <evilrabbi> gotcha
[22:37] <evilrabbi> i'll go grab another router then
[22:37] <evilrabbi> =)
[22:37] <nbd> preferably one with at least 4 mb flash and at least 16 mb ram
[22:37] <malbon> having said that, marvell patches for linux do exist, so you could try a port yourself, but there are many better options.
[22:39] <evilrabbi> i have a couple netgear and dlink routers laying around
[00:00] --- Fri Jun 2 2006
[00:19] Action: [mbm] looks at changeset 3873 ..
[00:20] <[mbm]> nbd: if a directory like that mysteriously shows up it's because it somehow ran against the system (amd64) toolchain .. the solution is to fix that, not remove the directory
[00:20] <nbd> i think it's an error in the busybox makefile
[00:21] <nbd> i don't think it's serious
[00:21] <[mbm]> I'm still looking into the toolchain issue above
[00:21] <[mbm]> could have sworn it compiled 6 hours ago
[00:23] <nbd> did you remove the staging dir as well after the parallel build attempt?
[00:24] <[mbm]> well, just for fun let's do a full rebuild .. rm -rf .config .pkginfo .pkgdeps *_mipsel
[00:24] <[mbm]> .. and it's not smart enough to pop up menuconfig
[00:25] <[mbm]> .. make menuconfig, save the defaults ..
[00:25] <[mbm]> and wait 15 minutes
[00:25] <nbd> need to fix that
[00:32] <[mbm]> .. and we've crashed at exactly the same place
[00:32] <[mbm]> shown in the pastebin above
[00:36] <[mbm]> nbd: btw the point of FORCE was to replace .PHONY (which you've used again in 3872)
[00:37] <nbd> right. so we can just remove FORCE there
[00:38] <CIA-16> nbd * r3875 /branches/buildroot-ng/openwrt/target/linux/kernel.mk: remove useless FORCE depend
[00:38] Action: [mbm] thinks the FORCE stuff is easier to follow than the .PHONY
[00:39] <nbd> so what do you want to do in this case?
[00:39] <[mbm]> all the stuff in packages I replaced with FORCE
[00:39] <[mbm]> think we should try to be somewhat consistant
[00:40] <nbd> so you want to move that line:
[00:40] <nbd> @{ [ "$(INSTALL_TARGETS)" != "" ] && $(IPKG) install $(INSTALL_TARGETS) || true; }
[00:40] <nbd> to the vmlinux target?
[00:41] <[mbm]> why not pkg-install: FORCE
[00:41] <[mbm]> ?
[00:41] <nbd> ah, that's what you meant
[00:41] <[mbm]> although you're unlikely to have a pkg-install file so the force is somewhat silly
[00:42] <nbd> same for all the other targets?
[00:42] <[mbm]> right, no point in using .PHONY
[00:44] <nbd> i'll go through the other parts in target/linux as well
[00:45] <[mbm]> btw, downgraded to 3868 and it appears to actually eb building the toolchain correctly
[00:48] <nbd> ah
[00:48] <nbd> found it
[00:48] <nbd> i removed MAKE1
[00:48] <CIA-16> nbd * r3876 /branches/buildroot-ng/openwrt/toolchain/uClibc/Makefile: fix toolchain build
[00:48] <nbd> try the latest rev with parallel build again
[00:51] <[mbm]> k
[00:51] <[mbm]> well, last time even the single builds had issues
[00:52] <nbd> but i'm sure that the issue is resolved now
[00:52] <nbd> it wasn't building uclibc
[00:58] <[mbm]> seems to have fixed the single builds
[01:02] <[mbm]> parallel builds sare still screwy
[01:03] <[mbm]> crashed one by not having staging_dir/bin/sed
[01:03] <nbd> where did you add the parallel build?
[01:04] <[mbm]> I had it enabled in the menuconfig and I ran it as 'make -j6'
[01:05] <nbd> don't do that. try adding it to specific $(MAKE) invocations in toolchain/*/Makefile
[01:06] <[mbm]> ugh
[01:06] <nbd> that way we have full control over what's going to be built in parallel
[01:06] <nbd> makes it easier to exclude some screwy parts
[01:07] <[mbm]> ok, so use the menuconfig to set the number of jobs and then edit the makefiles to call make with that number?
[01:07] <nbd> yes. package uses that number already
[01:07] <[mbm]> ok
[01:08] <nbd> btw. i'm going to disable gdb by default
[01:08] <nbd> most people don't need it anyway
[01:08] <[mbm]> :)
[01:08] <[mbm]> didn't we have that asme discussion.. a year ago?
[01:08] <Kaloz> wbx wanted to keep it....
[01:08] <nbd> i don't remember it
[01:09] <[mbm]> Kaloz: yeah I remember that
[01:09] <nbd> wbx is gone for now...
[01:09] <Kaloz> he was arguing with me when i wanted to disable it
[01:09] <nbd> you can still enable it in menuconfig...
[01:12] <[mbm]> right .. disable it .. next topic ..
[01:13] <Kaloz> next topic that i should get up in 5 hours and i still have to do too much shit
[01:13] <nbd> i think i've changed all the .PHONY stuff in my tree (even the stuff that didn't explicitly add it)
[01:13] <nbd> i'll do a test compile and then i'll commit it
[01:16] <[mbm]> I suppose the main thing is that the firmware itself builds in parallel
[01:16] <[mbm]> the toolchains you really only build once
[01:18] Action: nbd took some time to write comments on the blogs and news sites that covered wbx' fork
[01:18] Action: [mbm] had no idea it was covered anywhere other than wbx's blog
[01:19] <nbd> pro-linux.de and golem.de
[01:19] <nbd> my guess is that waldemar has some contacts there
[01:19] <[mbm]> I'm sure he does
[01:29] <CIA-16> nbd * r3877 /branches/buildroot-ng/openwrt/ (29 files in 25 dirs): cleanup; replace .PHONY with FORCE; disable gdb by default
[01:30] <[mbm]> hmm google does such a lousy job of translating
[01:30] <Kaloz> babelfish
[01:31] <[mbm]> not much better
[01:31] <[mbm]> the translations are to the point that I could probably read the original german versions easier
[01:32] <[mbm]> ohwell, doesn't appear to be anything newsworthy in them
[01:32] <nbd> no. it's basically the same content that's already in his open letter
[01:33] <[mbm]> that's what I mean
[01:34] <[mbm]> nbd: you bastard - "rmdir: .../busybox/lib64: no such file or directory .. make: *** [busybox-compile] Error 2
[01:34] <[mbm]> ;)
[01:35] <nbd> oops
[01:36] <CIA-16> nbd * r3878 /branches/buildroot-ng/openwrt/package/busybox/Makefile: fix busybox build
[01:37] Action: nbd tries a parallelized toolchain build
[01:37] <[mbm]> looks like ppp dependancies are wrong
[01:37] <[mbm]> it wants pcap
[01:37] <[mbm]> (didn't nico remove that?)
[01:37] <nbd> i removed the runtime dependency
[01:37] <nbd> but the build time dependency is still there
[01:37] <[mbm]> yeah but it still needs pcap.h for compile
[01:38] <[mbm]> or it bombs make
[01:38] <nbd> it still uses parts of pcap
[01:38] <nbd> for the filter stuff
[01:38] <[mbm]> right now it can't find pcap.h
[01:38] <[mbm]> probably because it isn't selected in menuconfig
[01:38] <nbd> did you remove that dependency?
[01:38] <nbd> hmm
[01:38] <[mbm]> nope
[01:38] <nbd> then there's a bug in the InstallDev stuff
[01:39] <nbd> did it build libpcap?
[01:39] <nbd> i mean the devel stuff
[01:40] <[mbm]> think it's an issue with include paths
[01:40] <[mbm]> I just compiled pcap and it still won't compile ppp
[01:41] <[mbm]> ah .. it's not even in staging_dir
[01:42] <nbd> i found the bug
[01:42] <nbd> seems like i can't do ifdef on stuff that i have defined
[01:45] <CIA-16> nbd * r3879 /branches/buildroot-ng/openwrt/toolchain/binutils/Makefile: allow parallel build of binutils
[02:06] <CIA-16> nbd * r3880 /branches/buildroot-ng/openwrt/package/rules.mk: fix InstallDev bug
[02:06] <nbd> [mbm]: should work now
[02:18] <CIA-16> nbd * r3881 /branches/buildroot-ng/openwrt/package/ipset/Makefile: remove broken dependency
[02:19] <CIA-16> nbd * r3882 /branches/buildroot-ng/openwrt/Makefile: add clean targets, more FORCE stuff
[02:28] <CIA-16> nbd * r3883 /branches/buildroot-ng/openwrt/package/rules.mk: add TARGET_CONFIGURE_OPTS to default compile command
[02:31] <CIA-16> nbd * r3884 /branches/buildroot-ng/openwrt/package/rules.mk: remove some debugging code, include package/rules.mk in package dependency check
[02:47] <CIA-16> nbd * r3885 /branches/buildroot-ng/openwrt/target/linux/kernel.mk: fix dependency problem
[02:47] <nbd> alxhh: fixed in svn
[02:47] <nbd> alxhh: (hopefully)
[02:47] <alxhh> *g*
[03:06] <CIA-16> nbd * r3886 /branches/buildroot-ng/openwrt/package/rules.mk: some bugfixes and additions for the default compile target
[03:12] <[mbm]> :)
[03:17] <CIA-16> nbd * r3887 /branches/buildroot-ng/openwrt/package/nvram/src/ (Makefile include/): add broadcom include files, fix build
[03:22] <nbd> hmm... there's a #freewrt
[03:23] <nbd> lmao. it was registered by elektik over a year ago
[03:24] <nbd> and now wbx et al. are using it
[03:25] <[mbm]> interesting
[03:26] <nbd> it doesn't have a topic lock :)
[08:01] <[mbm]> hmm .. sb_irq isn't exported
[08:15] <wigyori> .
[12:55] <[mbm]> anyone have one of the boards with serial on a gpio line?
[13:28] <[mbm]> hmm .. that's weird .. even on a cold boot the watchdog reboot flag is set
[13:28] <[mbm]> thought that was only supposed to be set if the board got rebooted by the watchdog timers
[13:31] <[mbm]> also don't understand why the code for gpio on the serial never seems to enable the gpio interrupts
[19:11] <xrg_> :)
[19:11] <Kaloz> 'lo :)
[19:12] <xrg_> isn't the devfs obsolete?
[19:12] <Kaloz> udev is simply not a way to go
[19:12] <[mbm]> depends on who you talk to
[19:12] <Kaloz> i will look into mdev later, but devfs works flawlessly
[19:12] <[mbm]> udev imho is a hack
[19:12] <xrg_> I agree. For embedded, I would go with static..
[19:13] <[mbm]> static? bah, that would require us to ship with a fully populated /dev for anything anyone could ever possibly plug in
[19:13] <[mbm]> honestly, there's nothing wrong with devfs
[19:13] <xrg_> I can't find devfs in 2.6.17, however.. :(
[19:14] Action: Kaloz forward ported it
[19:14] <xrg_> mbm, there is one: it's inside the kernel.
[19:14] <[mbm]> xrg_: and?
[19:14] <xrg_> And it occupies kernel code segments. I prefer to have less mem allocated there..
[19:15] <[mbm]> and udev occupies user memory .. I still don't see what your point is
[19:17] <xrg_> It's a matter of taste actually. I prefer to let out of the kernel whatever can be..
[19:18] <[mbm]> go look at the size of a system with devfs and then a system with udev
[19:18] <[mbm]> and also note that udev can't be used to boot
[19:18] <xrg_> That's true
[19:19] <[mbm]> which then requires a static /dev
[19:20] <xrg_> oops:Author: Greg KH <gregkh@suse.de> 2005-06-22 01:24:19 "2c6e5a839f92591a4bc6cac4a575d42151645af3"
[19:20] <xrg_> [PATCH] devfs: remove devfs from Kconfig preventing it from being built
[19:20] <xrg_>
[19:20] <xrg_> Here's a much smaller patch to simply disable devfs from the build. If
[19:20] <xrg_> this goes well, and there are no complaints for a few weeks, I'll resend
[19:20] <xrg_> my big "devfs-die-die-die" series of patches that rip the whole thing
[19:20] <xrg_> out of the kernel tree.
[19:21] <xrg_> What next?
[19:21] <Kaloz> grab out patch
[19:21] <[mbm]> you act as though this was the first time they did something stupid
[19:22] <xrg_> Didn't anybody complain, then?
[19:22] <[mbm]> yes, there was tons of complaints
[19:24] <xrg_> Still, I ask how could we be more vanilla-compliant..
[19:24] <[mbm]> go search for Bruce Evans, and note the flame fest about him sabotaging it
[19:24] <xrg_> Do we need tons of /dev entries for embedded?
[19:24] <alxhh> xrg_: usb?
[19:24] <[mbm]> vanilla is not for embedded systems and it never will be
[19:24] <[mbm]> the vanilla kernel has always been for the pc
[19:24] <xrg_> Mine doesn't have usb, nor other hotplugs.
[19:25] <[mbm]> and very slow to merge in any otehr platforms or keep them up to date
[19:25] <[mbm]> and on a pc, udev works
[19:25] <alxhh> xrg_: lots of usb, minipci, pccard, etc
[19:25] <xrg_> IMHO, all code should be given to vanilla.
[19:25] <[mbm]> it's not best for embedded systems
[19:25] <xrg_> don't just say vanilla is different.
[19:26] <Kaloz> xrg_: it's given, but they don't take it fasz enough
[19:26] <Kaloz> fast
[19:26] <[mbm]> openwrt is a rather minimal set of patches to the vanilla kernel
[19:26] <[mbm]> we could have just as easily used a linux-mips kernel
[19:27] <xrg_> I see.
[19:27] <Kaloz> well, using that would be easy
[19:27] <Kaloz> :)
[19:27] <Kaloz> i mean easier :)
[19:27] <Kaloz> but this way it's cleaner
[19:27] <[mbm]> Kaloz: and it would be a few releases behind the vanilla kernel
[19:27] <xrg_> Couldn't there be a uCudev, say, then?
[19:28] Action: [mbm] points out that support for ramdisk was also broken
[19:28] <[mbm]> now you can't just compile a squashfs image and stuff it directly into the kernel
[19:28] <xrg_> yes, ramdisk gets rewritten.
[19:28] <[mbm]> you're expected to create a cpio archive which then gets extrated to a tmpfs
[19:29] <[mbm]> which is another really bad mistake for embedded systems
[19:29] <xrg_> I've tried that,once.
[19:29] <xrg_> mbm, why?
[19:29] <[mbm]> everyone did, and a number of them failed because the new ramdisk uses /init and not /sbin/init or anything standard
[19:30] <[mbm]> xrg_: not only does the cpio get worse compression than squashfs, waiting for it to extract the cpio archive to ram disk is noticably slower
[19:30] <xrg_> mbm, can't be. 'init' or /sbin/init is just selected from an algo.
[19:31] <[mbm]> granted it's now writable, but I'd rather not have the hardware watchdog fire off while I'm waiting for the system to boot
[19:31] <xrg_> Yes, setting it is rather tricky.
[19:31] <[mbm]> xrg_: no, trust me, the new ramdisk stuff in 2.6 uses /init and not the usually /sbin/init /linuxrc /bin/sh
[19:31] <[mbm]> there's not a damned thing tricky about the watchdog
[19:32] <[mbm]> the problem is that the bootup takes too long
[19:32] <xrg_> Oh, no, the cpio should NOT have the init (as far as I remember).
[19:32] <xrg_> the root fs should be mounted first.
[19:32] <[mbm]> so your chances of getting to userspace and refreshing the watchdog before it expires diminish as the size of the cpio increases
[19:33] <xrg_> I was referring to the ramdisk, not the watchdog.
[19:33] <[mbm]> I suggest you actually read the ramdisk code
[19:33] <xrg_> It has a different sequence, so that it mounts earlier in the boot process.
[19:33] <[mbm]> because if you don't have a /init it doesn't do anything
[19:34] <[mbm]> and yes, I wasted a whole day trying to figure that out
[19:34] <xrg_> Anyway, I won't be the one that will decide on the ramdisk issue..
[19:34] <[mbm]> and no it isn't documented anywhere
[19:36] <xrg_> I only want to keep close to vanilla, so that I can help them more. Being centralized reduces the maintenance overhead (in terms of diversity)..
[19:36] <[mbm]> there's a major difference between being close to vanilla and repeating mistakes just because they were made in vanilla
[19:37] <[mbm]> you really need to get away from the mentality that vanilla is perfect, especially for embedded systems
[19:38] <xrg_> No, it's not. But I want to help make it better.
[19:40] <xrg_> Anyway, I won't insist. let's code..
[19:41] Action: [mbm] just wants embedded systems to be as light and compact as possible, even if it means adding extra patches
[19:44] <[mbm]> ...
[19:45] <[mbm]> let's switch to openssl/openssl .. I know it's several megs larger than dropbear, but it's a standard ..
[19:55] Action: alxhh want emacs as standard editor
[19:56] <[mbm]> alxhh: we didn't have room left after installing the full x11 suite and gnome
[19:56] <[mbm]> :/
[22:31] <evilrabbi> What advice would you give someone tring to get this to work on untested devices?
[22:33] <nbd> what kind of untested device?
[22:33] <malbon> have a serial console cable handy (and working) and run from ram if possible.
[22:34] <evilrabbi> it's a tew-432brp
[22:35] <malbon> hmm will never work
[22:35] <evilrabbi> ah
[22:35] <evilrabbi> I guess this has been tested before then
[22:35] <malbon> It's a marvell device, and at present they are completely unsupported by openwrt
[22:35] <evilrabbi> =\
[22:36] <malbon> no, not tested, it's just not a supported chipset.
[22:36] <malbon> also having only 1mb of flash makes it sort of useless.
[22:36] <evilrabbi> gotcha
[22:37] <evilrabbi> i'll go grab another router then
[22:37] <evilrabbi> =)
[22:37] <nbd> preferably one with at least 4 mb flash and at least 16 mb ram
[22:37] <malbon> having said that, marvell patches for linux do exist, so you could try a port yourself, but there are many better options.
[22:39] <evilrabbi> i have a couple netgear and dlink routers laying around
[00:00] --- Fri Jun 2 2006