[00:10] <crazy_imp> its on a wl-hdd2.5 with a toshiba drive (40gb). also my usbstick doesn't appear in /dev , but lsusb does found it
[00:52] <milan_h> crazy_imp: I use an usb-stick with kamikaze on an wl500gd, and I don't have /dev/sda*, but I do have /dev/discs/disc0/*
[00:55] <milan_h> crazy_imp: also make sure you have scsi disc (and scsi) support and usb mass storage support modules loaded or compiled in, otherwise it won't work
[01:01] <crazy_imp> milan_h: thx, scsi_mod, usb-ohci, usbcore and vfat (& fat) loaded, something other that i need?
[01:01] <nbd> hmm... if only i knew more about mips assembler...
[01:38] <nbd> [mbm]: i fixed it :D
[01:38] <nbd> Kaloz/[mbm]: the problem was that the loader killed the argument registers, so the kernel couldn't find the pointer to the boot loader environment
[01:39] <nbd> i solved it by storing the arguments in the temporary registers t4..t7 and restoring it in the 'entry' function in decompress.c
[01:41] <db90h> boom, glad u mentioned mips asm ndb ;p.. i finally found an ida license /w mips processor support ;)
[01:41] <nbd> yeah, i have one as well
[01:42] <db90h> i had given up the search previously.. i just happened to come across in on some chnese site tho
[01:42] <db90h> if i ever have the cash i'll pay for a valid license, its so damn expensive tho
[01:45] <CIA-16> nbd * r3908 /branches/buildroot-ng/openwrt/target/linux/image/generic/lzma-loader/ (6 files in 2 dirs): generic lzma loader: add support for memory copying, preserve prom arguments
[01:46] <CIA-16> nbd * r3909 /branches/buildroot-ng/openwrt/target/linux/ (4 files in 4 dirs): move mips boot patch to generic-2.6
[01:47] <CIA-16> nbd * r3910 /branches/buildroot-ng/openwrt/target/linux/Config.in: disable all other filesystems in menuconfig when initramfs is selected
[01:59] <CIA-16> nbd * r3911 /branches/buildroot-ng/openwrt/ (12 files in 8 dirs): make ramdisk support generic, some cleanups
[02:39] <CIA-16> nbd * r3912 /branches/buildroot-ng/openwrt/Makefile: clean scripts/config on distclean
[04:11] <[mbm]> nbd: fyi, it's not a "mips boot patch" exactly .. apart from being in the arch/mips directory there's nothing mips about it
[04:11] <[mbm]> it's just a jump from the base address to the proper entry point
[04:12] <[mbm]> (if I really wanted to, I could modify lzma to read elf headers and get the proper entry address, but that's much more work)
[04:30] <common> [mbm]: another thing
[04:30] <common> i need to pack the kernel with wrv-bin, which makefile to edit?
[04:30] <common> s/kernel/image
[04:30] <[mbm]> that'd be a target/linux/image
[04:38] <common> and howto call the make process so i just create the image?
[04:41] <[mbm]> that's a rather open ended question .. either ask something more specific or go look at how the existing platforms work
[04:46] <common> make target/linux-install looks good
[04:57] <common> hrm
[05:51] <common> [mbm]:
[05:51] <common> i get
[05:52] <common> http://phpfi.com/122544
[05:52] <common> any idea?
[05:52] <common> i bet i screw'd something, but no idea what
[05:52] Action: [mbm] doesn't understand german error messages and has no idea what you put in the makefiles
[05:54] <common> i dont know which makefile causes this
[05:54] <common> thats the ticket
[05:54] <common> whats your best guess?
[05:57] <common> cp: Aufruf von stat für ,,/opt/kamikaze/openwrt/build_armeb/root" nicht möglich: Datei oder Verzeichnis nicht gefunden means
[05:57] <common> could not fing ,,/opt/kamikaze/openwrt/build_armeb/root"
[05:59] <common> whats expected in ,,/opt/kamikaze/openwrt/build_armeb/root"
[07:47] <common> [mbm]: "target/linux/Config.in:48:warning: config symbol defined without type"
[07:47] <common> i added a new menu item, and seems i missed something
[07:47] <common> can you tell me what?
[07:47] <[mbm]> sounds like it
[07:47] <[mbm]> I don't even know what you added
[07:47] <[mbm]> but it sounds like whatever you added is line 48
[07:48] <common> config BR2_PACKAGE_KMOD_IXP400
[07:49] <[mbm]> you're using trunk?
[07:49] <common> yes
[07:50] <[mbm]> jsut pastebin the file
[07:50] <common> seems like i have to define BR2_PACKAGE_KMOD_IXP400 somewhere to me
[07:50] <[mbm]> no, I'm guessing you forgot the bool in the next line
[07:50] <common> http://phpfi.com/122547
[07:52] <[mbm]> hmm .. yep .. you didn't specify the variable type
[07:54] <[mbm]> for most of those you'll want:
[07:54] <common> tristate?
[07:54] <[mbm]> prompt "description"
[07:54] <[mbm]> tristate
[07:55] <[mbm]> tristate is y/n/m
[07:55] <[mbm]> bool is y/n
[07:55] <common> http://phpfi.com/122548
[07:55] <common> does not work too
[07:57] <[mbm]> if you're not going to write a help don't put the help line
[07:58] <[mbm]> 'lo
[07:59] <common> http://phpfi.com/122549
[07:59] <common> still the items dont show up
[07:59] <common> the ones in "FOX MODULES"
[08:00] <[mbm]> it depends on BR2_LINUX_2_6_IXP, if that isn't set then you won't see the BR2_PACKAGE_KMOD_IXP400_ETH
[08:00] <[mbm]> did you add a BR2_LINUX_2_6_IXP to target/Config.in ?
[08:01] <common> no, thanks, its done
[08:01] <common> the vars name is BR2_LINUX_2_6_XSCALE
[08:02] <common> missed that
[08:33] <common> [mbm]: another one
[08:34] <common> i included http://openixp.phj.hu/cgi-bin/trac.cgi/browser/target/linux/linux-2.6/wrv54g/ixp4xx.mk to my Makefile in openwrt, the source from intel gets downloaded, and compiled, the modules are in the build_arm* dir, but it does not create *any* packages for the modules, idea why?
[08:43] <Kaloz> common: that one is an old release, under a crappy license
[08:43] <Kaloz> common: the new libraries are under bsd
[08:44] <Kaloz> common: i'm already working on it, and to be honest, some of that code is fishy
[08:58] <common> it already boots
[08:58] <common> i just need to include the ixp drivers
[08:58] <common> then i'm done
[08:59] <common> and the drivers already compile
[08:59] <common> they just dont get packaged as ipkg
[09:00] <common> which really sucks
[09:00] <Kaloz> "it already boots" - not surprising, i've added the support for xscale, and it worked for quite some time now
[09:01] <common> i did not use your tree
[09:01] <Kaloz> enabling the wrv in menuconfig isn't really surprising
[09:01] <common> i merged the 2.6.15 tree from openixp
[09:01] <Kaloz> well, if you used trunk, you used my stuff anyways
[09:01] <common> the patches did not apply to 2.6.16.4 and i felt more like getting it working before fixing the diffs
[09:02] <Kaloz> lol
[09:08] <common> will you accept my diffs?
[09:08] <Kaloz> probably if they apply to our tree
[09:08] <common> its svn from yesterday
[09:09] <Kaloz> as you've said you are not using my tree :P
[09:09] <common> may 'im not using your kernel' would have been better
[09:10] <Kaloz> i see. make sure your patch will be for .16
[09:11] <common> im no kernel hacker
[09:20] <common> how can i enforce that the ixp module gets into the image?
[09:20] <common> kmod-ixp400_2.6.15-xscale-1_armeb.ipk kmod-ixp400-eth_2.6.15-xscale-1_armeb.ipk
[09:20] <common> but they are not in the image
[09:25] <[mbm]> ..
[09:27] <common> [mbm] the drivers are module only
[09:30] <common> hrmkay
[09:30] <common> got it
[09:31] <[mbm]> now probably isn't a good time to mention that trunk will soon be replaced by buildroot-ng
[09:36] <common> thats why i hurried with it
[09:36] <[mbm]> so you'd be experienced for doing the buildroot-ng port?
[09:43] <common> nbd told me he'd delay the buildroot-ng merge if i was about to merge the openixp diffs
[09:43] <common> so i hurried
[09:43] <common> and now, the drivers load, but i got no interfaces ...
[09:45] <common> k, i miss one of the 3
[10:16] <Kaloz> back
[10:23] <common> Kaloz: the ixp devices work
[10:24] <Kaloz> worked here as well for a hackish test, the question is how legal and nic eis the way you've added it :)
[10:25] <common> 1:1 taken from openixp
[10:25] <Kaloz> well :p that has some problems regarding the intel licensing if you read it
[10:26] <common> from what i saw, one is allowed to download and compile the driver, as well as ship the compiled driver?
[10:27] <Kaloz> not that simple
[10:27] <common> what to edit so more than /dev/root gets mounted on boot?
[10:27] <[mbm]> *sigh*
[10:28] <Kaloz> o.O
[10:28] <common> seems this is not really backwards compatible from openixp
[10:28] <[mbm]> porting to a new platform without understanding the architecture, the system or the license
[10:29] <[mbm]> and doing it to a branch that's going to be obsolete soon
[10:29] <[mbm]> .. why do I get the feeling this isn't going to go well?
[10:29] <wigyori> :)
[10:30] <common> why do i get the feeling you don't appreciate it?
[10:30] <[mbm]> common: I'm saying don't expect to get it right on the first try
[10:30] <wigyori> common: there is no problem with appreciation, the problem is with your common misunderstanding how an arch port should be done
[10:31] <common> you saw no line of changes, and tell me i made it wrong?
[10:31] <Kaloz> the arch is already supported, common just copes the osal and the wrv54g support from openixp
[10:32] <common> whats the problem with that?
[10:32] <[mbm]> wigyori's got it right - this is really about making as few changes as possible to go from what's already in openwrt to something that will boot on your platform
[10:32] <[mbm]> and you've off to a bad start just blindly copying the kernel from openixp
[10:33] <[mbm]> cue the "but I'm not a kernel hacker"
[10:33] <wigyori> :)
[10:34] <common> the openixp kernel worked for me, and i'd say thats better than nothing
[10:34] <[mbm]> sorry, wrong attitude
[10:34] <wigyori> if openwrt was up to 'thats better than nothing', than it wouldn't be where it is now
[10:35] <common> ladies
[10:35] <common> a little respect
[10:35] <[mbm]> common: if you turn in something that's basically a "jsut download openixp and extract it ontop of openwrt" (in other words you just massively cut and paste) then we're clearly going to reject it
[10:36] <common> _you_ got no docs where i could see that Kaloz was working on wrv54g, i added the entry to the wiki myself, i asked nbd about it, and he said this would be no problem, if you had a opublic devel ml, i'd have pinged it before, the users ml seems empty, and now *you* complain?
[10:37] <[mbm]> we're just telling you what's going to happen; you're the one complaining about it
[10:37] <wigyori> Kaloz isn't working on wrv54g - you could see it in the initial xscale patch -, but working on a nice and clean xscale support
[10:37] <wigyori> s/wrv54g/only on wrv54g/
[10:37] <Kaloz> common: i have no wrv54g, i don't work on it. I've mad the xscale port, and it supports onlt the gateway7001 only now, but that's a different question
[10:43] <common> i got lan & wifi working, if you start critics before you saw a line of the diff, there is no diff
[10:44] Action: [mbm] thought it was pretty obvious based on the stuff that was already pasted to irc
[10:45] <[mbm]> thought it better to warn you now than later
[14:54] <common> Kaloz: where did you see bsd drivers?
[14:54] <common> bsd licensed drivers?
[15:01] <common> http://developer.intel.com/design/network/products/npfamily/tolly_204132.pdf
[15:02] <common> would be great to patch ssh openssl and freeswan to use the hw crypto engine
[15:05] <florian__> openssl already supports hw crypto engines
[15:17] <florian__> I don't know if it directly manages a crypto api the kernel exports to openssl, or if openssl has per device crypto management
[15:17] <nbd> there are patches for that
[15:17] <Kaloz> *sigh* :p
[15:18] <Kaloz> bbl
[15:18] <florian__> Kaloz: no DSL driver to test :) ?
[15:22] <florian__> nbd: can you send me the presentation you made at CCC21 ?
[15:28] <nbd> it wasn't that good. better use the one from whatthehack
[15:29] <nbd> i don't know if i still have the source code
[15:29] <nbd> i'll let you know when i find it
[15:29] <CIA-16> kaloz * r3913 /branches/buildroot-ng/openwrt/target/linux/image/generic/lzma-loader/src/ (LzmaDecode.c LzmaDecode.h): get rid of CRLFs
[15:31] <florian__> nbd: thanks
[15:31] <florian__> I have to reply quite quickly in order to make a presentation, just find out a title :)
[15:31] <florian__> Kaloz: why not upgrade lzma ?
[15:38] <CIA-16> kaloz * r3914 /branches/buildroot-ng/openwrt/toolchain/gcc/ (4.1.0/110-arm-eabi.patch 4.1.1/110-arm-eabi.patch): add arm eabi patches
[18:07] <cyt0plas> Do you guys have any wrt54gx2s for testing on?
[18:35] <CIA-16> nbd * r3915 / (2 files in 2 dirs): disable madwifi rfkill support by default (broken on some hardware)
[20:24] <pjf> I need to download two distinct tarballs and I'd like to see an example how to do it
[20:31] <nbd> pjf: have a look at package/rules.mk
[20:31] <nbd> pjf: there's the default download target
[20:31] <nbd> pjf: duplicate it in your package makefile
[20:31] <nbd> pjf: and add it to the .prepared dependencies
[20:32] <pjf> nbd: thanks!
[21:23] <pjf> does anybody of you have any experiences in cross-compiling software with cmake powered build systems?
[21:24] <pjf> of course i'm asking regarding cross-compiling for openwrt target
[21:34] <[mbm]> you don't need cmake for openwrt
[21:40] <pjf> [mbm]: sure :), but I want to build a package for openwrt
[21:40] <pjf> which uses cmake as it's build system
[21:40] <[mbm]> so you write a package/whatever/Makefile
[21:41] <[mbm]> openwrt uses gnu make
[21:41] <pjf> well, but cmake is a tool which replaces autotools
[21:41] <pjf> and generates makefiles
[21:41] <pjf> it's just another way of configuring sources for building
[21:42] <pjf> the problem is that cmake officaly doesn't support cross-compiling
[21:43] <[mbm]> so just generate a makefile, fix it, then place a patch that creates the makefile in the patches directory
[21:44] <pjf> yeah, but I was searching for cleaner way - I would need to fix these patches each time original (cmake) build system is modified
[21:45] <pjf> however probably that will be the workaround if I don't find any better way...
[21:45] <[mbm]> sounds like the only other choice is to patch cmake for cross compilation
[21:45] <pjf> :)
[21:46] <[mbm]> you might be able to trick cmake by doing something like: CC=mipsel-linux-gcc cmake ...
[21:46] <pjf> if I only had two weeks I could spend on improving open source software of my choice... :)
[21:46] <pjf> that's what I'm going to try later - sadly cmake lacks any good docs
[21:47] <pjf> ...I could use to determine which env vars it uses
[21:50] <pjf> mbm, as I got your attention for a moment, do you (OpenWrt team) have any plans for date of first Kamikaze release candidates / betas?
[21:50] <pjf> or time when you'll start feature-freezing?
[21:51] <[mbm]> feature freeze on whiterussian is over, we'll be backporting large parts of kamikaze into whiterussian and updating both kamikaze and whiterussian to use the buildroot-ng system
[21:51] <pjf> ah, I see...
[21:52] <pjf> thanks, got to go now, bye
[00:00] --- Fri Jun 9 2006
[00:52] <milan_h> crazy_imp: I use an usb-stick with kamikaze on an wl500gd, and I don't have /dev/sda*, but I do have /dev/discs/disc0/*
[00:55] <milan_h> crazy_imp: also make sure you have scsi disc (and scsi) support and usb mass storage support modules loaded or compiled in, otherwise it won't work
[01:01] <crazy_imp> milan_h: thx, scsi_mod, usb-ohci, usbcore and vfat (& fat) loaded, something other that i need?
[01:01] <nbd> hmm... if only i knew more about mips assembler...
[01:38] <nbd> [mbm]: i fixed it :D
[01:38] <nbd> Kaloz/[mbm]: the problem was that the loader killed the argument registers, so the kernel couldn't find the pointer to the boot loader environment
[01:39] <nbd> i solved it by storing the arguments in the temporary registers t4..t7 and restoring it in the 'entry' function in decompress.c
[01:41] <db90h> boom, glad u mentioned mips asm ndb ;p.. i finally found an ida license /w mips processor support ;)
[01:41] <nbd> yeah, i have one as well
[01:42] <db90h> i had given up the search previously.. i just happened to come across in on some chnese site tho
[01:42] <db90h> if i ever have the cash i'll pay for a valid license, its so damn expensive tho
[01:45] <CIA-16> nbd * r3908 /branches/buildroot-ng/openwrt/target/linux/image/generic/lzma-loader/ (6 files in 2 dirs): generic lzma loader: add support for memory copying, preserve prom arguments
[01:46] <CIA-16> nbd * r3909 /branches/buildroot-ng/openwrt/target/linux/ (4 files in 4 dirs): move mips boot patch to generic-2.6
[01:47] <CIA-16> nbd * r3910 /branches/buildroot-ng/openwrt/target/linux/Config.in: disable all other filesystems in menuconfig when initramfs is selected
[01:59] <CIA-16> nbd * r3911 /branches/buildroot-ng/openwrt/ (12 files in 8 dirs): make ramdisk support generic, some cleanups
[02:39] <CIA-16> nbd * r3912 /branches/buildroot-ng/openwrt/Makefile: clean scripts/config on distclean
[04:11] <[mbm]> nbd: fyi, it's not a "mips boot patch" exactly .. apart from being in the arch/mips directory there's nothing mips about it
[04:11] <[mbm]> it's just a jump from the base address to the proper entry point
[04:12] <[mbm]> (if I really wanted to, I could modify lzma to read elf headers and get the proper entry address, but that's much more work)
[04:30] <common> [mbm]: another thing
[04:30] <common> i need to pack the kernel with wrv-bin, which makefile to edit?
[04:30] <common> s/kernel/image
[04:30] <[mbm]> that'd be a target/linux/image
[04:38] <common> and howto call the make process so i just create the image?
[04:41] <[mbm]> that's a rather open ended question .. either ask something more specific or go look at how the existing platforms work
[04:46] <common> make target/linux-install looks good
[04:57] <common> hrm
[05:51] <common> [mbm]:
[05:51] <common> i get
[05:52] <common> http://phpfi.com/122544
[05:52] <common> any idea?
[05:52] <common> i bet i screw'd something, but no idea what
[05:52] Action: [mbm] doesn't understand german error messages and has no idea what you put in the makefiles
[05:54] <common> i dont know which makefile causes this
[05:54] <common> thats the ticket
[05:54] <common> whats your best guess?
[05:57] <common> cp: Aufruf von stat für ,,/opt/kamikaze/openwrt/build_armeb/root" nicht möglich: Datei oder Verzeichnis nicht gefunden means
[05:57] <common> could not fing ,,/opt/kamikaze/openwrt/build_armeb/root"
[05:59] <common> whats expected in ,,/opt/kamikaze/openwrt/build_armeb/root"
[07:47] <common> [mbm]: "target/linux/Config.in:48:warning: config symbol defined without type"
[07:47] <common> i added a new menu item, and seems i missed something
[07:47] <common> can you tell me what?
[07:47] <[mbm]> sounds like it
[07:47] <[mbm]> I don't even know what you added
[07:47] <[mbm]> but it sounds like whatever you added is line 48
[07:48] <common> config BR2_PACKAGE_KMOD_IXP400
[07:49] <[mbm]> you're using trunk?
[07:49] <common> yes
[07:50] <[mbm]> jsut pastebin the file
[07:50] <common> seems like i have to define BR2_PACKAGE_KMOD_IXP400 somewhere to me
[07:50] <[mbm]> no, I'm guessing you forgot the bool in the next line
[07:50] <common> http://phpfi.com/122547
[07:52] <[mbm]> hmm .. yep .. you didn't specify the variable type
[07:54] <[mbm]> for most of those you'll want:
[07:54] <common> tristate?
[07:54] <[mbm]> prompt "description"
[07:54] <[mbm]> tristate
[07:55] <[mbm]> tristate is y/n/m
[07:55] <[mbm]> bool is y/n
[07:55] <common> http://phpfi.com/122548
[07:55] <common> does not work too
[07:57] <[mbm]> if you're not going to write a help don't put the help line
[07:58] <[mbm]> 'lo
[07:59] <common> http://phpfi.com/122549
[07:59] <common> still the items dont show up
[07:59] <common> the ones in "FOX MODULES"
[08:00] <[mbm]> it depends on BR2_LINUX_2_6_IXP, if that isn't set then you won't see the BR2_PACKAGE_KMOD_IXP400_ETH
[08:00] <[mbm]> did you add a BR2_LINUX_2_6_IXP to target/Config.in ?
[08:01] <common> no, thanks, its done
[08:01] <common> the vars name is BR2_LINUX_2_6_XSCALE
[08:02] <common> missed that
[08:33] <common> [mbm]: another one
[08:34] <common> i included http://openixp.phj.hu/cgi-bin/trac.cgi/browser/target/linux/linux-2.6/wrv54g/ixp4xx.mk to my Makefile in openwrt, the source from intel gets downloaded, and compiled, the modules are in the build_arm* dir, but it does not create *any* packages for the modules, idea why?
[08:43] <Kaloz> common: that one is an old release, under a crappy license
[08:43] <Kaloz> common: the new libraries are under bsd
[08:44] <Kaloz> common: i'm already working on it, and to be honest, some of that code is fishy
[08:58] <common> it already boots
[08:58] <common> i just need to include the ixp drivers
[08:58] <common> then i'm done
[08:59] <common> and the drivers already compile
[08:59] <common> they just dont get packaged as ipkg
[09:00] <common> which really sucks
[09:00] <Kaloz> "it already boots" - not surprising, i've added the support for xscale, and it worked for quite some time now
[09:01] <common> i did not use your tree
[09:01] <Kaloz> enabling the wrv in menuconfig isn't really surprising
[09:01] <common> i merged the 2.6.15 tree from openixp
[09:01] <Kaloz> well, if you used trunk, you used my stuff anyways
[09:01] <common> the patches did not apply to 2.6.16.4 and i felt more like getting it working before fixing the diffs
[09:02] <Kaloz> lol
[09:08] <common> will you accept my diffs?
[09:08] <Kaloz> probably if they apply to our tree
[09:08] <common> its svn from yesterday
[09:09] <Kaloz> as you've said you are not using my tree :P
[09:09] <common> may 'im not using your kernel' would have been better
[09:10] <Kaloz> i see. make sure your patch will be for .16
[09:11] <common> im no kernel hacker
[09:20] <common> how can i enforce that the ixp module gets into the image?
[09:20] <common> kmod-ixp400_2.6.15-xscale-1_armeb.ipk kmod-ixp400-eth_2.6.15-xscale-1_armeb.ipk
[09:20] <common> but they are not in the image
[09:25] <[mbm]> ..
[09:27] <common> [mbm] the drivers are module only
[09:30] <common> hrmkay
[09:30] <common> got it
[09:31] <[mbm]> now probably isn't a good time to mention that trunk will soon be replaced by buildroot-ng
[09:36] <common> thats why i hurried with it
[09:36] <[mbm]> so you'd be experienced for doing the buildroot-ng port?
[09:43] <common> nbd told me he'd delay the buildroot-ng merge if i was about to merge the openixp diffs
[09:43] <common> so i hurried
[09:43] <common> and now, the drivers load, but i got no interfaces ...
[09:45] <common> k, i miss one of the 3
[10:16] <Kaloz> back
[10:23] <common> Kaloz: the ixp devices work
[10:24] <Kaloz> worked here as well for a hackish test, the question is how legal and nic eis the way you've added it :)
[10:25] <common> 1:1 taken from openixp
[10:25] <Kaloz> well :p that has some problems regarding the intel licensing if you read it
[10:26] <common> from what i saw, one is allowed to download and compile the driver, as well as ship the compiled driver?
[10:27] <Kaloz> not that simple
[10:27] <common> what to edit so more than /dev/root gets mounted on boot?
[10:27] <[mbm]> *sigh*
[10:28] <Kaloz> o.O
[10:28] <common> seems this is not really backwards compatible from openixp
[10:28] <[mbm]> porting to a new platform without understanding the architecture, the system or the license
[10:29] <[mbm]> and doing it to a branch that's going to be obsolete soon
[10:29] <[mbm]> .. why do I get the feeling this isn't going to go well?
[10:29] <wigyori> :)
[10:30] <common> why do i get the feeling you don't appreciate it?
[10:30] <[mbm]> common: I'm saying don't expect to get it right on the first try
[10:30] <wigyori> common: there is no problem with appreciation, the problem is with your common misunderstanding how an arch port should be done
[10:31] <common> you saw no line of changes, and tell me i made it wrong?
[10:31] <Kaloz> the arch is already supported, common just copes the osal and the wrv54g support from openixp
[10:32] <common> whats the problem with that?
[10:32] <[mbm]> wigyori's got it right - this is really about making as few changes as possible to go from what's already in openwrt to something that will boot on your platform
[10:32] <[mbm]> and you've off to a bad start just blindly copying the kernel from openixp
[10:33] <[mbm]> cue the "but I'm not a kernel hacker"
[10:33] <wigyori> :)
[10:34] <common> the openixp kernel worked for me, and i'd say thats better than nothing
[10:34] <[mbm]> sorry, wrong attitude
[10:34] <wigyori> if openwrt was up to 'thats better than nothing', than it wouldn't be where it is now
[10:35] <common> ladies
[10:35] <common> a little respect
[10:35] <[mbm]> common: if you turn in something that's basically a "jsut download openixp and extract it ontop of openwrt" (in other words you just massively cut and paste) then we're clearly going to reject it
[10:36] <common> _you_ got no docs where i could see that Kaloz was working on wrv54g, i added the entry to the wiki myself, i asked nbd about it, and he said this would be no problem, if you had a opublic devel ml, i'd have pinged it before, the users ml seems empty, and now *you* complain?
[10:37] <[mbm]> we're just telling you what's going to happen; you're the one complaining about it
[10:37] <wigyori> Kaloz isn't working on wrv54g - you could see it in the initial xscale patch -, but working on a nice and clean xscale support
[10:37] <wigyori> s/wrv54g/only on wrv54g/
[10:37] <Kaloz> common: i have no wrv54g, i don't work on it. I've mad the xscale port, and it supports onlt the gateway7001 only now, but that's a different question
[10:43] <common> i got lan & wifi working, if you start critics before you saw a line of the diff, there is no diff
[10:44] Action: [mbm] thought it was pretty obvious based on the stuff that was already pasted to irc
[10:45] <[mbm]> thought it better to warn you now than later
[14:54] <common> Kaloz: where did you see bsd drivers?
[14:54] <common> bsd licensed drivers?
[15:01] <common> http://developer.intel.com/design/network/products/npfamily/tolly_204132.pdf
[15:02] <common> would be great to patch ssh openssl and freeswan to use the hw crypto engine
[15:05] <florian__> openssl already supports hw crypto engines
[15:17] <florian__> I don't know if it directly manages a crypto api the kernel exports to openssl, or if openssl has per device crypto management
[15:17] <nbd> there are patches for that
[15:17] <Kaloz> *sigh* :p
[15:18] <Kaloz> bbl
[15:18] <florian__> Kaloz: no DSL driver to test :) ?
[15:22] <florian__> nbd: can you send me the presentation you made at CCC21 ?
[15:28] <nbd> it wasn't that good. better use the one from whatthehack
[15:29] <nbd> i don't know if i still have the source code
[15:29] <nbd> i'll let you know when i find it
[15:29] <CIA-16> kaloz * r3913 /branches/buildroot-ng/openwrt/target/linux/image/generic/lzma-loader/src/ (LzmaDecode.c LzmaDecode.h): get rid of CRLFs
[15:31] <florian__> nbd: thanks
[15:31] <florian__> I have to reply quite quickly in order to make a presentation, just find out a title :)
[15:31] <florian__> Kaloz: why not upgrade lzma ?
[15:38] <CIA-16> kaloz * r3914 /branches/buildroot-ng/openwrt/toolchain/gcc/ (4.1.0/110-arm-eabi.patch 4.1.1/110-arm-eabi.patch): add arm eabi patches
[18:07] <cyt0plas> Do you guys have any wrt54gx2s for testing on?
[18:35] <CIA-16> nbd * r3915 / (2 files in 2 dirs): disable madwifi rfkill support by default (broken on some hardware)
[20:24] <pjf> I need to download two distinct tarballs and I'd like to see an example how to do it
[20:31] <nbd> pjf: have a look at package/rules.mk
[20:31] <nbd> pjf: there's the default download target
[20:31] <nbd> pjf: duplicate it in your package makefile
[20:31] <nbd> pjf: and add it to the .prepared dependencies
[20:32] <pjf> nbd: thanks!
[21:23] <pjf> does anybody of you have any experiences in cross-compiling software with cmake powered build systems?
[21:24] <pjf> of course i'm asking regarding cross-compiling for openwrt target
[21:34] <[mbm]> you don't need cmake for openwrt
[21:40] <pjf> [mbm]: sure :), but I want to build a package for openwrt
[21:40] <pjf> which uses cmake as it's build system
[21:40] <[mbm]> so you write a package/whatever/Makefile
[21:41] <[mbm]> openwrt uses gnu make
[21:41] <pjf> well, but cmake is a tool which replaces autotools
[21:41] <pjf> and generates makefiles
[21:41] <pjf> it's just another way of configuring sources for building
[21:42] <pjf> the problem is that cmake officaly doesn't support cross-compiling
[21:43] <[mbm]> so just generate a makefile, fix it, then place a patch that creates the makefile in the patches directory
[21:44] <pjf> yeah, but I was searching for cleaner way - I would need to fix these patches each time original (cmake) build system is modified
[21:45] <pjf> however probably that will be the workaround if I don't find any better way...
[21:45] <[mbm]> sounds like the only other choice is to patch cmake for cross compilation
[21:45] <pjf> :)
[21:46] <[mbm]> you might be able to trick cmake by doing something like: CC=mipsel-linux-gcc cmake ...
[21:46] <pjf> if I only had two weeks I could spend on improving open source software of my choice... :)
[21:46] <pjf> that's what I'm going to try later - sadly cmake lacks any good docs
[21:47] <pjf> ...I could use to determine which env vars it uses
[21:50] <pjf> mbm, as I got your attention for a moment, do you (OpenWrt team) have any plans for date of first Kamikaze release candidates / betas?
[21:50] <pjf> or time when you'll start feature-freezing?
[21:51] <[mbm]> feature freeze on whiterussian is over, we'll be backporting large parts of kamikaze into whiterussian and updating both kamikaze and whiterussian to use the buildroot-ng system
[21:51] <pjf> ah, I see...
[21:52] <pjf> thanks, got to go now, bye
[00:00] --- Fri Jun 9 2006