[00:00] <blux> has sombody see my question?
[00:00] <[mbm]> blux: the cfe source has been provided a few times in the various gpl releases
[00:01] <blux> thx
[00:02] <blux> but it differ for WRT/WRTgs/. . ?
[00:02] <[mbm]> probably
[00:02] <blux> ok, thank you
[00:04] <blux> i it in openwrt source?
[00:04] <[mbm]> no
[00:04] <blux> ok, seems to bee no neet, CFE never changed normaly
[00:04] <[mbm]> huh?
[00:05] <blux> if upgrading to openwrt upgrading/changing CFE is not needed
[00:05] <[mbm]> right
[00:09] <blux> and "partiton table" (i know it does not exist) is in CFE? I mean the Hardcoded adress ranges that de dev know where to find NVRAM and so on.
[00:10] <[mbm]> there is no partition table
[00:10] <blux> I know
[00:10] <[mbm]> the offsets are basically hardcoded
[00:10] <blux> but somwere the hardcoded offsets
[00:11] <blux> where are they?
[00:11] <[mbm]> there's a post on the forum that explains it all
[00:11] <blux> CFE must know where to put KERNEL if flashed with tft
[00:11] <[mbm]> actually there's about 6 times where I've explained it on the forum, usually taking up 3 pages each time
[00:11] <blux> ok
[00:11] <blux> do you know the headline?
[00:12] <[mbm]> no
[00:12] <tziOm> [mbm] - where should I post patches to the entire init/filesystem system?
[00:12] <blux> How will i find the thread? (i did'n yet, an i use googel and so on)
[00:13] <[mbm]> tziOm: post them as a ticket .. and preferably separated out into specific features and not one massive patch
[00:16] <[mbm]> blux: http://forum.openwrt.org/viewtopic.php?pid=3123#p3123
[00:17] <[mbm]> http://forum.openwrt.org/viewtopic.php?pid=24157#p24157
[00:18] <blux> thank you!
[00:20] <[mbm]> cfe really doesn't know anything about the partitoning
[00:20] <[mbm]> only where the firmware starts and where nvram starts
[00:20] <blux> i see
[00:21] <blux> does it kno which flashchip is used to know the size?
[00:21] <[mbm]> yes, it knows the size of the flash chip
[00:22] <blux> by reading the flash vend ID's ?
[00:22] <[mbm]> (it needs to know that to figure out where nvram is)
[00:22] <blux> yes
[00:22] <[mbm]> hmm forgot exactly how .. mostly irrelevent
[00:22] <blux> not if you replache the flash ;-)
[00:23] <[mbm]> why bother?
[00:23] <blux> and it need to know how to wirte to the flash, the command set differ
[00:23] <blux> I Replaced the chip
[00:23] <blux> CFE boots, but I can not flash
[00:24] <[mbm]> I mean why did you replace the flash chip?
[00:24] <blux> because it doesent know how to writ to it.
[00:24] <blux> it was to small, and I like to "play" :-D
[00:25] <[mbm]> was it 2M?
[00:25] <blux> 4MB now i have 8
[00:26] <[mbm]> you could piggyback two 8M chips and put a gpio on the chip select/enable pin
[00:26] <[mbm]> or you could do the sd card mod
[00:27] <blux> if you can get intel chips TE28F640 it will work without changes, but I cant get them
[00:27] <[mbm]> there's a few chips you can use
[00:27] <[mbm]> amd chips also work
[00:28] <blux> I used SST
[00:29] <[mbm]> why don't you load the firmware the same way you loaded cfe?
[00:29] <blux> but the have a diffent command set, with i did not notice before soldering :-)
[00:29] <blux> er. . . . good question!
[00:30] <blux> but the idear wit 2 chips is nice. :-) but lot of coding work
[00:31] <[mbm]> the sd card trick has already been done and will get you a few hundred meg easily
[00:31] <blux> if I flash everything with JTAG i only have to see if the kernel supports SST wirte commands
[00:32] <[mbm]> think we disabled sst support in the kernel but it's pretty easy to enable it again
[00:32] <blux> ok, cool
[00:34] <blux> I will have a loock at the code
[00:37] <blux> is the adress where the broadcom chip points at und load cfe always same (00000) ?
[00:38] <blux> at power on
[00:42] <Kaloz> common: they told us they sync with kamikaze and clean up their work, but it never happened
[00:43] <Kaloz> common: so i did the xscale port myself (for now only the gateway 7001 is supported, but things will change soon)
[00:46] <blux> mbm: did you know if the thing with size4MB with the SST Flashs in ligthbulb's debrick is a misstake?
[00:46] <[mbm]> no idea
[00:47] <blux> ok
[00:47] <blux> did you see it?
[00:47] <[mbm]> nope, I don't use jtag
[00:47] <blux> a ok
[01:27] <florian__> nbd: do you know how, in awk, I can print colums a to end ? for instance : print '{ print $12,<end>}' ?
[01:28] <nbd> use a for loop from 12 to NF and do print $n (where n is your iteration variable)
[01:32] <florian__> ok in fact I want to save the arguments a program was called with, to a string for instance
[01:47] <florian__> ok, forgot it
[02:39] <[mbm]> .
[02:56] <florian__> would anyone help me rewriting the documentation after june 16th ?
[03:26] <florian__> Kaloz: can you remind me of the ppc linux maintainer who made power management patches ?
[05:01] <CIA-16> nbd * r3906 /branches/buildroot-ng/openwrt/target/linux/image/aruba/Makefile: fix typo
[08:30] <[mbm]> "OMG PONIES!"
[09:23] <frop> re
[09:27] <[mbm]> 'lo
[09:35] <frop> ...mmmh, making ng with target "ramdisk" doesn't build any image...
[09:37] <[mbm]> we haven't written that part yet
[09:37] <frop> ...and also, adding kmod-ipt-ipopt_2.6.16.7-brcm-1_mipsel.ipk and iptables-mod-ipopt_1.3.5-1_mipsel.ipk (example)...seem to not include modules in /lib/modules/2.6.ETC/
[09:38] <[mbm]> "2.6.ETC" ?
[09:39] <frop> eheh
[09:39] <frop> shit...you are right
[09:40] <frop> iptables modules are elsewhere
[09:40] <frop> ./lib/modules/2.6.16.7/switch-core.ko
[09:41] <frop> ./usr/lib/iptables/libipt_state.so
[09:41] <frop> btw, i can't see USB module
[09:41] <frop> kmod-usb-core_2.6.16.7-brcm-1_mipsel.ipk
[09:42] <frop> with this, shouldn't i have some modules in ./lib/modules/2.6.16.7/ ?
[09:44] <[mbm]> you're confusing the various parts of iptables
[09:44] <[mbm]> the .so's are shared objects -- plugins which allow iptables to use extra functionality
[09:44] <[mbm]> the actual kernel modules are in a separate package starting with kmod-*
[09:45] <frop> so...are kmod miss?
[09:45] <[mbm]> user didn't install them :P
[09:45] <frop> user == me?
[09:49] <nbd> [mbm]: rb532 boots until it tries to mount the rootfs now - with my local buildroot-ng tree
[09:49] <[mbm]> cool
[09:50] <frop> <*> kmod-ip6tables.................... Kernel modules for ip6tables
[09:50] <nbd> but i'm currently patching it to 2.6.17-rc5, so i'll wait for 2.6.17 before i commit it
[09:50] <frop> shouldn't this add a module in ./lib/modules/2.6.16.7/ ?
[09:50] <nbd> because i heard that there are lots of fixes for that kind of hardware in 2.6.17
[09:51] <[mbm]> there was a ticket earlier today complaing of slow network speeds on the wgt634u saying that we should upgrade the kernel
[09:52] <nbd> someone else noticed that it's because of CONFIG_SLOB
[09:52] <[mbm]> saw that too
[09:52] <[mbm]> but I'm curious if that means that the new kernel fixed slob
[09:53] <nbd> yeah
[09:53] <nbd> well, 2.6.17 shouldn't be that far away...
[09:54] <[mbm]> any more complaints from tzi0m?
[09:54] <nbd> i don't think so
[09:54] <[mbm]> shame .. was starting to think we had a wbx replacement
[09:55] <nbd> hehe
[10:18] <NDL> "but I'm curious if that means that the new kernel fixed slob" - hm, I would be surprised in that case, the code I saw for SLOB in 2.6.16.7 when investigating this problem seemd to be too plain to work fast enough ...
[10:28] <[mbm]> well, ticket 584 seems to claim otherwise
[10:43] <NDL> Hm, that's strange - the file mm/slob.c almost haven't changed from the initial commit, and there are no changes from 2.6.16.7 to 2.6.16.9 ... Probably, the problem was somewhere else then, or in the case of 584 during upgrade to 2.6.16.9 the config was changed also somehow ...
[10:44] <[mbm]> so does that 2.6.16.19 patch fix the problems you were seeing?
[10:45] <NDL> I haven't tried that yet (and will not able to try until evening, I think)
[10:48] <NDL> So far, it seems unlikely for me, because it I interpret history correctly, there were only two changes between 2.6.16.7 and 2.6.16.9, and none of them seems to be serious enough to influence this.
[10:48] <[mbm]> 2.6.16.19 .. that's the second time you've made that mistake
[10:49] <NDL> Oops, soory, I was looking to the wrong history then :-(
[11:03] <NDL> Well, I still do not see commits between 2.6.16.7 and 2.6.16.19 that could influence SLOB behavior, but I'm not that familiar with kernel to be sure, so anyway I will try to upgrade to 2.6.16.19 and see if it works OK with SLOB.
[13:23] <tziOm> [mbm], Your docs in ppl.. are they correct with regards to nvram vars anymore? do you use nvram at all? .. and.. what about the mini_fo?
[13:43] <tziOm> how can I force toolchain to beeing rebuilt?.. changed to gcc-4.1.0, but make doesnt seem to know that even after make clean
[13:43] <florian__> make distclean does the thing
[13:43] <tziOm> but it wipes my config also?
[13:43] <florian__> right
[13:44] <florian__> so just rm -rf staging_dir_*
[13:44] <florian__> and also toolchain_build_*
[13:46] <Kaloz> florian__: benh
[13:49] <florian__> Kaloz: thanks !
[13:49] <Kaloz> florian__: penguinppc.org
[13:52] <florian__> Kaloz: found it thanks, only for 2.4 kernels ?
[13:54] <Kaloz> florian__: there is a 2.6 tree as well afaik
[13:54] <Kaloz> florian__: but you can grab the ubuntu patchset, it has all of those :P
[13:54] <florian__> Kaloz: ah I did not found it ?
[13:57] <blux> read through linksys GPL and found sth. with the flash addresses, #define SB_FLASH2 0x1c000000
[13:59] <blux> it's the second bigger, flash address space and "region 1 shadowed here" means, the first flash region will be also readable here?
[13:59] <blux> and writable
[13:59] <blux> it's in WRT54G_4_20_6_0526_US/release/src/include/sbconfig.h
[14:01] <blux> my main questin is: will 1fc00000 (address of the first flash region) point to the same data then 1c00000 (adress of the second one)
[14:01] <blux> question
[21:59] <[mbm]> nbd: http://pastebin.com/760541
[22:04] <nbd> [mbm]: i don't think only doing the verbose stuff based on depth is enough
[22:05] <[mbm]> well, gets much more complicated otherwise
[22:06] <nbd> but also more useful
[22:06] <[mbm]> if you say so .. but I have yet to see a working example of your idea
[22:06] <[mbm]> btw any idea why people are complaining the gpios don't work in rc5 for the sd mod?
[22:07] <[mbm]> we didn't change any of that code
[22:07] <nbd> about the working example thing: i also don't have seen a working example of your idea
[22:07] Action: [mbm] points to the above makefile .. depth based
[22:08] <nbd> it's a makefile all right
[22:08] <nbd> but it's not integrated into the build system
[22:08] <[mbm]> it could be, but I'm not going to waste time if you're just going to rip it out again
[22:08] <nbd> the most important part (i think) is how to handle the output of submakes outside of the build system
[22:08] <nbd> i didn't say it wouldn't work
[22:09] <nbd> i just said it probably wouldn't be enough
[22:09] <nbd> so maybe you could write the code
[22:09] <nbd> and then i'll think about how to extend it
[22:11] <[mbm]> and about the gpio stuff?
[22:12] <nbd> there were no changes to the gpio code, i'm pretty sure
[22:13] <[mbm]> right, but there is the switchcore and b44
[22:13] <nbd> neither of them uses gpio
[22:13] <nbd> only switch-adm does
[22:13] <nbd> and only if there's an admtek switch
[22:13] <[mbm]> hmm
[22:13] <[mbm]> threads says that gpio 4 is stuck high
[22:14] <nbd> switch-adm checks the boardflags before doing anything to the gpio
[22:14] <framer99> i built a image with switch-adm and switch-core removed.. didnt' help
[22:14] <nbd> framer99: you have the same problem?
[22:14] <framer99> yeah
[22:15] Action: nbd checks to see if there's any weird stuff changing the gpios in the system code...
[22:15] <[mbm]> none of the kernel gpio was touched, unless there's some weird interaction
[22:15] <framer99> also tried to roll diag_led.c to rc4 revsion and rebuilt
[22:16] <[mbm]> diag is harmless
[22:16] <[mbm]> it doesn't change anything unless you explicitly write to /proc/sys
[22:16] <framer99> ok, my hardware seems to be a slight modidfication from the stnadard stuff
[22:16] <nbd> where's the source code for the sd hack module
[22:16] <nbd> ?
[22:17] <[mbm]> think it's on the customizing wiki page
[22:17] <[mbm]> I should take a look and make sure that they're setting all the gpio registers
[22:17] <framer99> http://kiel.kool.dk/mmc.c
[22:17] <framer99> i keep meaning to fix those links on wiki
[22:18] <framer99> wiki links point to port 27 (which used to be correct) instead of 80
[22:19] <nbd> hmz... this driver uses hardcoded addresses instead of the gpio functions from the system code
[22:20] <framer99> ok, it does work fine on rc4 for me.. if that helps you
[22:25] <[mbm]> doesn't set gpio control
[22:25] <[mbm]> btw .. anyone ever heard of an adaptec raid card not showing up as a raid device under linux?
[22:28] <nbd> no
[22:28] <[mbm]> got a call saying that one of the servers is showing a raid configuration as multiple drives
[22:37] <dragorn> heard of it with other cards
[22:40] <[mbm]> yeah, cheap promise ide cards do a crappy software raid
[22:40] <wigyori> this card isn't one of this junk hostraid cards?
[22:41] <[mbm]> wigyori: no, it's a nice dual xeon server with an adaptec card
[22:41] <[mbm]> hmm looks like aacraid might be involved
[23:22] <nbd> i think we should include stty in rc6
[23:22] <nbd> it's small and very useful for the serial ports
[23:23] <[mbm]> slowly creeping bigger and bigger ..
[23:24] <nbd> nah, we also remove stuff once in a while
[23:24] <[mbm]> yeah stty is helpful
[23:26] <[mbm]> hmm
[23:26] <[mbm]> could try to generate dependancies with gcc -M
[23:26] <nbd> if it wasn't so much work, i'd have modified the busybox build system already so that you can select applets as <M> instead of <*>
[23:27] <[mbm]> I remember asking andersee and mjn3 about that over a year ago
[23:27] <[mbm]> would basically be a dlsym call
[23:28] <nbd> i meant creating standalone binaries instead of linking them into the multicall binary
[23:28] <nbd> which is a lot easier to do
[23:29] <[mbm]> but the advantage of busybox is that you're sharing common code and avoiding the overhead of elf headers on small files
[23:29] <nbd> right
[23:30] <nbd> i just wanted to have something where i can move optional stuff into a package
[23:30] <[mbm]> if you create standalone programs then you won't get that advantage
[23:30] <[mbm]> the best tradeoff is probably a plugin system
[23:30] <nbd> i think a plugin system is overkill in this case
[23:31] <nbd> most applets are still small as external programs
[23:31] <[mbm]> dlsym is easy stuff
[23:31] <nbd> and most of the time you only need maybe a single extra program to do some stuff that's not in the code
[23:31] <nbd> core
[23:32] <nbd> but actually, you're right, there is a case where the dlsym would be really useful
[23:32] <nbd> ipkg
[23:32] <[mbm]> could probably manage a quick plugin system in less than a day
[23:32] <nbd> maybe we should do that after 0.9 and before 1.0
[23:32] <db90h> if JFFS2 compresses the file system on a per-file basis, then you'll loose a lot of space to less efficient compression if you seperate the tools into individual binaries
[23:32] <nbd> so that we can still have a micro firmware
[23:33] <nbd> db90h: we're not talking about separating everything
[23:33] <nbd> db90h: i meant having the core as it is now and packaging some extra stuff that's currently disabled
[23:33] <[mbm]> should be possible to do a plugin that supports mutiple applets
[23:34] <[mbm]> I mean it's basically dlopen(wildcard); app = dlsym(<applet>_main); app();
[23:34] <nbd> you only need to make sure that a list of extra applets is stored in a hash or a linked list or something like that
[23:35] <nbd> because currently it's all static
[23:36] <[mbm]> well, you only need to patch run_applet_by_name
[23:36] <nbd> hmm
[23:37] <[mbm]> seriously, this could be done very quickly if you want it
[23:37] <nbd> i don't need it right now
[23:38] <nbd> but we should do it before 1.0
[23:38] <[mbm]> yes or no, is this something useful?
[23:38] <nbd> yes
[23:39] <[mbm]> ok.. gimme an hour or so
[23:39] <nbd> why not do the buildroot-ng stuff first
[23:39] <nbd> ?
[23:39] <{Nico}> .
[23:39] <[mbm]> I'm easily distr .. ooh! shiney objects ..
[23:39] <nbd> :)
[23:40] <[mbm]> seriously though, I can get this done very quickly
[23:40] <[mbm]> I haven't got a clue how to tackle the buildroot-ng stuff
[23:40] <nbd> ok
[23:42] <nbd> when you're done, i'll move ipkg out of busybox
[23:43] <{Nico}> [mbm]: will you export functions from libbb?
[23:44] <nbd> {Nico}: no. busybox will load plugins with additional applets
[23:44] <[mbm]> I plan on doing a 5 line hack to busybox and having it suddenly load shared libaries
[23:44] <nbd> {Nico}: so the stuff doesn't have to be exported
[23:45] <{Nico}> nbd: then you'd better revert to standalone ipkg
[23:45] Action: [mbm] thinks nico missed it
[23:46] <nbd> {Nico}: the point is to have ipkg not duplicate the busybox stuff, but still be separate
[23:48] <{Nico}> well, i don't see how
[23:49] <nbd> ...
[23:49] <nbd> you'll see when it's done :)
[23:49] <[mbm]> {Nico}: it works like this .. before busybox prints out "applet not found" it tries to load a shared libary (dynamically) and then execute the applet from there .. so .. dlopen("/lib/busybox/ipkg.so"); main = dlsym("ipkg_main"); main(argc,argv);
[23:50] <nbd> [mbm]: but there is one problem with using this method for many different applets:
[23:51] <nbd> [mbm]: a plugin might need some stuff from libbb.a, which is not in the core
[23:51] <{Nico}> [mbm]: ok, but how did you link ipkg.so against static libb
[23:51] <[mbm]> you wouldn't have to link it static
[23:51] <[mbm]> could be linked dynamic
[23:53] Action: wigyori is going to kick asus's head a few times, some files are missing from their tarball
[23:53] <nbd> wigyori: which files, which tarball?
[23:53] <wigyori> (they might release another airgo source with it :D )
[23:53] <wigyori> nbd: wl566gm-1.1.0.1, drivers/net/re865x/rtl865x/*.c
[23:54] <nbd> ah
[23:56] <{Nico}> nbd: i saw you started moving packages from ./target/linux/package to package
[23:56] <nbd> if you're going to kick asus' head, kick them for not releasing a wl-700gE tarball as well
[23:56] <nbd> {Nico}: yes
[23:56] <{Nico}> i can continue moving the rest
[23:57] <nbd> great
[23:57] <nbd> yeah right, asus... "All future firmware updates will also be accompanied
[23:57] <nbd> with their respective source code on our web site. "
[23:57] <nbd> in the description for the 1.0.1.1 firmware
[23:58] <nbd> and directly above that is the 1.0.1.3 firmware
[23:58] <nbd> without any gpl code
[23:59] <nbd> asus really needs some asskicking by laf0rge
[23:59] <nbd> or any other copyright holder
[23:59] <wigyori> yep, i saw that :)
[00:00] --- Tue Jun 6 2006
[00:00] <[mbm]> blux: the cfe source has been provided a few times in the various gpl releases
[00:01] <blux> thx
[00:02] <blux> but it differ for WRT/WRTgs/. . ?
[00:02] <[mbm]> probably
[00:02] <blux> ok, thank you
[00:04] <blux> i it in openwrt source?
[00:04] <[mbm]> no
[00:04] <blux> ok, seems to bee no neet, CFE never changed normaly
[00:04] <[mbm]> huh?
[00:05] <blux> if upgrading to openwrt upgrading/changing CFE is not needed
[00:05] <[mbm]> right
[00:09] <blux> and "partiton table" (i know it does not exist) is in CFE? I mean the Hardcoded adress ranges that de dev know where to find NVRAM and so on.
[00:10] <[mbm]> there is no partition table
[00:10] <blux> I know
[00:10] <[mbm]> the offsets are basically hardcoded
[00:10] <blux> but somwere the hardcoded offsets
[00:11] <blux> where are they?
[00:11] <[mbm]> there's a post on the forum that explains it all
[00:11] <blux> CFE must know where to put KERNEL if flashed with tft
[00:11] <[mbm]> actually there's about 6 times where I've explained it on the forum, usually taking up 3 pages each time
[00:11] <blux> ok
[00:11] <blux> do you know the headline?
[00:12] <[mbm]> no
[00:12] <tziOm> [mbm] - where should I post patches to the entire init/filesystem system?
[00:12] <blux> How will i find the thread? (i did'n yet, an i use googel and so on)
[00:13] <[mbm]> tziOm: post them as a ticket .. and preferably separated out into specific features and not one massive patch
[00:16] <[mbm]> blux: http://forum.openwrt.org/viewtopic.php?pid=3123#p3123
[00:17] <[mbm]> http://forum.openwrt.org/viewtopic.php?pid=24157#p24157
[00:18] <blux> thank you!
[00:20] <[mbm]> cfe really doesn't know anything about the partitoning
[00:20] <[mbm]> only where the firmware starts and where nvram starts
[00:20] <blux> i see
[00:21] <blux> does it kno which flashchip is used to know the size?
[00:21] <[mbm]> yes, it knows the size of the flash chip
[00:22] <blux> by reading the flash vend ID's ?
[00:22] <[mbm]> (it needs to know that to figure out where nvram is)
[00:22] <blux> yes
[00:22] <[mbm]> hmm forgot exactly how .. mostly irrelevent
[00:22] <blux> not if you replache the flash ;-)
[00:23] <[mbm]> why bother?
[00:23] <blux> and it need to know how to wirte to the flash, the command set differ
[00:23] <blux> I Replaced the chip
[00:23] <blux> CFE boots, but I can not flash
[00:24] <[mbm]> I mean why did you replace the flash chip?
[00:24] <blux> because it doesent know how to writ to it.
[00:24] <blux> it was to small, and I like to "play" :-D
[00:25] <[mbm]> was it 2M?
[00:25] <blux> 4MB now i have 8
[00:26] <[mbm]> you could piggyback two 8M chips and put a gpio on the chip select/enable pin
[00:26] <[mbm]> or you could do the sd card mod
[00:27] <blux> if you can get intel chips TE28F640 it will work without changes, but I cant get them
[00:27] <[mbm]> there's a few chips you can use
[00:27] <[mbm]> amd chips also work
[00:28] <blux> I used SST
[00:29] <[mbm]> why don't you load the firmware the same way you loaded cfe?
[00:29] <blux> but the have a diffent command set, with i did not notice before soldering :-)
[00:29] <blux> er. . . . good question!
[00:30] <blux> but the idear wit 2 chips is nice. :-) but lot of coding work
[00:31] <[mbm]> the sd card trick has already been done and will get you a few hundred meg easily
[00:31] <blux> if I flash everything with JTAG i only have to see if the kernel supports SST wirte commands
[00:32] <[mbm]> think we disabled sst support in the kernel but it's pretty easy to enable it again
[00:32] <blux> ok, cool
[00:34] <blux> I will have a loock at the code
[00:37] <blux> is the adress where the broadcom chip points at und load cfe always same (00000) ?
[00:38] <blux> at power on
[00:42] <Kaloz> common: they told us they sync with kamikaze and clean up their work, but it never happened
[00:43] <Kaloz> common: so i did the xscale port myself (for now only the gateway 7001 is supported, but things will change soon)
[00:46] <blux> mbm: did you know if the thing with size4MB with the SST Flashs in ligthbulb's debrick is a misstake?
[00:46] <[mbm]> no idea
[00:47] <blux> ok
[00:47] <blux> did you see it?
[00:47] <[mbm]> nope, I don't use jtag
[00:47] <blux> a ok
[01:27] <florian__> nbd: do you know how, in awk, I can print colums a to end ? for instance : print '{ print $12,<end>}' ?
[01:28] <nbd> use a for loop from 12 to NF and do print $n (where n is your iteration variable)
[01:32] <florian__> ok in fact I want to save the arguments a program was called with, to a string for instance
[01:47] <florian__> ok, forgot it
[02:39] <[mbm]> .
[02:56] <florian__> would anyone help me rewriting the documentation after june 16th ?
[03:26] <florian__> Kaloz: can you remind me of the ppc linux maintainer who made power management patches ?
[05:01] <CIA-16> nbd * r3906 /branches/buildroot-ng/openwrt/target/linux/image/aruba/Makefile: fix typo
[08:30] <[mbm]> "OMG PONIES!"
[09:23] <frop> re
[09:27] <[mbm]> 'lo
[09:35] <frop> ...mmmh, making ng with target "ramdisk" doesn't build any image...
[09:37] <[mbm]> we haven't written that part yet
[09:37] <frop> ...and also, adding kmod-ipt-ipopt_2.6.16.7-brcm-1_mipsel.ipk and iptables-mod-ipopt_1.3.5-1_mipsel.ipk (example)...seem to not include modules in /lib/modules/2.6.ETC/
[09:38] <[mbm]> "2.6.ETC" ?
[09:39] <frop> eheh
[09:39] <frop> shit...you are right
[09:40] <frop> iptables modules are elsewhere
[09:40] <frop> ./lib/modules/2.6.16.7/switch-core.ko
[09:41] <frop> ./usr/lib/iptables/libipt_state.so
[09:41] <frop> btw, i can't see USB module
[09:41] <frop> kmod-usb-core_2.6.16.7-brcm-1_mipsel.ipk
[09:42] <frop> with this, shouldn't i have some modules in ./lib/modules/2.6.16.7/ ?
[09:44] <[mbm]> you're confusing the various parts of iptables
[09:44] <[mbm]> the .so's are shared objects -- plugins which allow iptables to use extra functionality
[09:44] <[mbm]> the actual kernel modules are in a separate package starting with kmod-*
[09:45] <frop> so...are kmod miss?
[09:45] <[mbm]> user didn't install them :P
[09:45] <frop> user == me?
[09:49] <nbd> [mbm]: rb532 boots until it tries to mount the rootfs now - with my local buildroot-ng tree
[09:49] <[mbm]> cool
[09:50] <frop> <*> kmod-ip6tables.................... Kernel modules for ip6tables
[09:50] <nbd> but i'm currently patching it to 2.6.17-rc5, so i'll wait for 2.6.17 before i commit it
[09:50] <frop> shouldn't this add a module in ./lib/modules/2.6.16.7/ ?
[09:50] <nbd> because i heard that there are lots of fixes for that kind of hardware in 2.6.17
[09:51] <[mbm]> there was a ticket earlier today complaing of slow network speeds on the wgt634u saying that we should upgrade the kernel
[09:52] <nbd> someone else noticed that it's because of CONFIG_SLOB
[09:52] <[mbm]> saw that too
[09:52] <[mbm]> but I'm curious if that means that the new kernel fixed slob
[09:53] <nbd> yeah
[09:53] <nbd> well, 2.6.17 shouldn't be that far away...
[09:54] <[mbm]> any more complaints from tzi0m?
[09:54] <nbd> i don't think so
[09:54] <[mbm]> shame .. was starting to think we had a wbx replacement
[09:55] <nbd> hehe
[10:18] <NDL> "but I'm curious if that means that the new kernel fixed slob" - hm, I would be surprised in that case, the code I saw for SLOB in 2.6.16.7 when investigating this problem seemd to be too plain to work fast enough ...
[10:28] <[mbm]> well, ticket 584 seems to claim otherwise
[10:43] <NDL> Hm, that's strange - the file mm/slob.c almost haven't changed from the initial commit, and there are no changes from 2.6.16.7 to 2.6.16.9 ... Probably, the problem was somewhere else then, or in the case of 584 during upgrade to 2.6.16.9 the config was changed also somehow ...
[10:44] <[mbm]> so does that 2.6.16.19 patch fix the problems you were seeing?
[10:45] <NDL> I haven't tried that yet (and will not able to try until evening, I think)
[10:48] <NDL> So far, it seems unlikely for me, because it I interpret history correctly, there were only two changes between 2.6.16.7 and 2.6.16.9, and none of them seems to be serious enough to influence this.
[10:48] <[mbm]> 2.6.16.19 .. that's the second time you've made that mistake
[10:49] <NDL> Oops, soory, I was looking to the wrong history then :-(
[11:03] <NDL> Well, I still do not see commits between 2.6.16.7 and 2.6.16.19 that could influence SLOB behavior, but I'm not that familiar with kernel to be sure, so anyway I will try to upgrade to 2.6.16.19 and see if it works OK with SLOB.
[13:23] <tziOm> [mbm], Your docs in ppl.. are they correct with regards to nvram vars anymore? do you use nvram at all? .. and.. what about the mini_fo?
[13:43] <tziOm> how can I force toolchain to beeing rebuilt?.. changed to gcc-4.1.0, but make doesnt seem to know that even after make clean
[13:43] <florian__> make distclean does the thing
[13:43] <tziOm> but it wipes my config also?
[13:43] <florian__> right
[13:44] <florian__> so just rm -rf staging_dir_*
[13:44] <florian__> and also toolchain_build_*
[13:46] <Kaloz> florian__: benh
[13:49] <florian__> Kaloz: thanks !
[13:49] <Kaloz> florian__: penguinppc.org
[13:52] <florian__> Kaloz: found it thanks, only for 2.4 kernels ?
[13:54] <Kaloz> florian__: there is a 2.6 tree as well afaik
[13:54] <Kaloz> florian__: but you can grab the ubuntu patchset, it has all of those :P
[13:54] <florian__> Kaloz: ah I did not found it ?
[13:57] <blux> read through linksys GPL and found sth. with the flash addresses, #define SB_FLASH2 0x1c000000
[13:59] <blux> it's the second bigger, flash address space and "region 1 shadowed here" means, the first flash region will be also readable here?
[13:59] <blux> and writable
[13:59] <blux> it's in WRT54G_4_20_6_0526_US/release/src/include/sbconfig.h
[14:01] <blux> my main questin is: will 1fc00000 (address of the first flash region) point to the same data then 1c00000 (adress of the second one)
[14:01] <blux> question
[21:59] <[mbm]> nbd: http://pastebin.com/760541
[22:04] <nbd> [mbm]: i don't think only doing the verbose stuff based on depth is enough
[22:05] <[mbm]> well, gets much more complicated otherwise
[22:06] <nbd> but also more useful
[22:06] <[mbm]> if you say so .. but I have yet to see a working example of your idea
[22:06] <[mbm]> btw any idea why people are complaining the gpios don't work in rc5 for the sd mod?
[22:07] <[mbm]> we didn't change any of that code
[22:07] <nbd> about the working example thing: i also don't have seen a working example of your idea
[22:07] Action: [mbm] points to the above makefile .. depth based
[22:08] <nbd> it's a makefile all right
[22:08] <nbd> but it's not integrated into the build system
[22:08] <[mbm]> it could be, but I'm not going to waste time if you're just going to rip it out again
[22:08] <nbd> the most important part (i think) is how to handle the output of submakes outside of the build system
[22:08] <nbd> i didn't say it wouldn't work
[22:09] <nbd> i just said it probably wouldn't be enough
[22:09] <nbd> so maybe you could write the code
[22:09] <nbd> and then i'll think about how to extend it
[22:11] <[mbm]> and about the gpio stuff?
[22:12] <nbd> there were no changes to the gpio code, i'm pretty sure
[22:13] <[mbm]> right, but there is the switchcore and b44
[22:13] <nbd> neither of them uses gpio
[22:13] <nbd> only switch-adm does
[22:13] <nbd> and only if there's an admtek switch
[22:13] <[mbm]> hmm
[22:13] <[mbm]> threads says that gpio 4 is stuck high
[22:14] <nbd> switch-adm checks the boardflags before doing anything to the gpio
[22:14] <framer99> i built a image with switch-adm and switch-core removed.. didnt' help
[22:14] <nbd> framer99: you have the same problem?
[22:14] <framer99> yeah
[22:15] Action: nbd checks to see if there's any weird stuff changing the gpios in the system code...
[22:15] <[mbm]> none of the kernel gpio was touched, unless there's some weird interaction
[22:15] <framer99> also tried to roll diag_led.c to rc4 revsion and rebuilt
[22:16] <[mbm]> diag is harmless
[22:16] <[mbm]> it doesn't change anything unless you explicitly write to /proc/sys
[22:16] <framer99> ok, my hardware seems to be a slight modidfication from the stnadard stuff
[22:16] <nbd> where's the source code for the sd hack module
[22:16] <nbd> ?
[22:17] <[mbm]> think it's on the customizing wiki page
[22:17] <[mbm]> I should take a look and make sure that they're setting all the gpio registers
[22:17] <framer99> http://kiel.kool.dk/mmc.c
[22:17] <framer99> i keep meaning to fix those links on wiki
[22:18] <framer99> wiki links point to port 27 (which used to be correct) instead of 80
[22:19] <nbd> hmz... this driver uses hardcoded addresses instead of the gpio functions from the system code
[22:20] <framer99> ok, it does work fine on rc4 for me.. if that helps you
[22:25] <[mbm]> doesn't set gpio control
[22:25] <[mbm]> btw .. anyone ever heard of an adaptec raid card not showing up as a raid device under linux?
[22:28] <nbd> no
[22:28] <[mbm]> got a call saying that one of the servers is showing a raid configuration as multiple drives
[22:37] <dragorn> heard of it with other cards
[22:40] <[mbm]> yeah, cheap promise ide cards do a crappy software raid
[22:40] <wigyori> this card isn't one of this junk hostraid cards?
[22:41] <[mbm]> wigyori: no, it's a nice dual xeon server with an adaptec card
[22:41] <[mbm]> hmm looks like aacraid might be involved
[23:22] <nbd> i think we should include stty in rc6
[23:22] <nbd> it's small and very useful for the serial ports
[23:23] <[mbm]> slowly creeping bigger and bigger ..
[23:24] <nbd> nah, we also remove stuff once in a while
[23:24] <[mbm]> yeah stty is helpful
[23:26] <[mbm]> hmm
[23:26] <[mbm]> could try to generate dependancies with gcc -M
[23:26] <nbd> if it wasn't so much work, i'd have modified the busybox build system already so that you can select applets as <M> instead of <*>
[23:27] <[mbm]> I remember asking andersee and mjn3 about that over a year ago
[23:27] <[mbm]> would basically be a dlsym call
[23:28] <nbd> i meant creating standalone binaries instead of linking them into the multicall binary
[23:28] <nbd> which is a lot easier to do
[23:29] <[mbm]> but the advantage of busybox is that you're sharing common code and avoiding the overhead of elf headers on small files
[23:29] <nbd> right
[23:30] <nbd> i just wanted to have something where i can move optional stuff into a package
[23:30] <[mbm]> if you create standalone programs then you won't get that advantage
[23:30] <[mbm]> the best tradeoff is probably a plugin system
[23:30] <nbd> i think a plugin system is overkill in this case
[23:31] <nbd> most applets are still small as external programs
[23:31] <[mbm]> dlsym is easy stuff
[23:31] <nbd> and most of the time you only need maybe a single extra program to do some stuff that's not in the code
[23:31] <nbd> core
[23:32] <nbd> but actually, you're right, there is a case where the dlsym would be really useful
[23:32] <nbd> ipkg
[23:32] <[mbm]> could probably manage a quick plugin system in less than a day
[23:32] <nbd> maybe we should do that after 0.9 and before 1.0
[23:32] <db90h> if JFFS2 compresses the file system on a per-file basis, then you'll loose a lot of space to less efficient compression if you seperate the tools into individual binaries
[23:32] <nbd> so that we can still have a micro firmware
[23:33] <nbd> db90h: we're not talking about separating everything
[23:33] <nbd> db90h: i meant having the core as it is now and packaging some extra stuff that's currently disabled
[23:33] <[mbm]> should be possible to do a plugin that supports mutiple applets
[23:34] <[mbm]> I mean it's basically dlopen(wildcard); app = dlsym(<applet>_main); app();
[23:34] <nbd> you only need to make sure that a list of extra applets is stored in a hash or a linked list or something like that
[23:35] <nbd> because currently it's all static
[23:36] <[mbm]> well, you only need to patch run_applet_by_name
[23:36] <nbd> hmm
[23:37] <[mbm]> seriously, this could be done very quickly if you want it
[23:37] <nbd> i don't need it right now
[23:38] <nbd> but we should do it before 1.0
[23:38] <[mbm]> yes or no, is this something useful?
[23:38] <nbd> yes
[23:39] <[mbm]> ok.. gimme an hour or so
[23:39] <nbd> why not do the buildroot-ng stuff first
[23:39] <nbd> ?
[23:39] <{Nico}> .
[23:39] <[mbm]> I'm easily distr .. ooh! shiney objects ..
[23:39] <nbd> :)
[23:40] <[mbm]> seriously though, I can get this done very quickly
[23:40] <[mbm]> I haven't got a clue how to tackle the buildroot-ng stuff
[23:40] <nbd> ok
[23:42] <nbd> when you're done, i'll move ipkg out of busybox
[23:43] <{Nico}> [mbm]: will you export functions from libbb?
[23:44] <nbd> {Nico}: no. busybox will load plugins with additional applets
[23:44] <[mbm]> I plan on doing a 5 line hack to busybox and having it suddenly load shared libaries
[23:44] <nbd> {Nico}: so the stuff doesn't have to be exported
[23:45] <{Nico}> nbd: then you'd better revert to standalone ipkg
[23:45] Action: [mbm] thinks nico missed it
[23:46] <nbd> {Nico}: the point is to have ipkg not duplicate the busybox stuff, but still be separate
[23:48] <{Nico}> well, i don't see how
[23:49] <nbd> ...
[23:49] <nbd> you'll see when it's done :)
[23:49] <[mbm]> {Nico}: it works like this .. before busybox prints out "applet not found" it tries to load a shared libary (dynamically) and then execute the applet from there .. so .. dlopen("/lib/busybox/ipkg.so"); main = dlsym("ipkg_main"); main(argc,argv);
[23:50] <nbd> [mbm]: but there is one problem with using this method for many different applets:
[23:51] <nbd> [mbm]: a plugin might need some stuff from libbb.a, which is not in the core
[23:51] <{Nico}> [mbm]: ok, but how did you link ipkg.so against static libb
[23:51] <[mbm]> you wouldn't have to link it static
[23:51] <[mbm]> could be linked dynamic
[23:53] Action: wigyori is going to kick asus's head a few times, some files are missing from their tarball
[23:53] <nbd> wigyori: which files, which tarball?
[23:53] <wigyori> (they might release another airgo source with it :D )
[23:53] <wigyori> nbd: wl566gm-1.1.0.1, drivers/net/re865x/rtl865x/*.c
[23:54] <nbd> ah
[23:56] <{Nico}> nbd: i saw you started moving packages from ./target/linux/package to package
[23:56] <nbd> if you're going to kick asus' head, kick them for not releasing a wl-700gE tarball as well
[23:56] <nbd> {Nico}: yes
[23:56] <{Nico}> i can continue moving the rest
[23:57] <nbd> great
[23:57] <nbd> yeah right, asus... "All future firmware updates will also be accompanied
[23:57] <nbd> with their respective source code on our web site. "
[23:57] <nbd> in the description for the 1.0.1.1 firmware
[23:58] <nbd> and directly above that is the 1.0.1.3 firmware
[23:58] <nbd> without any gpl code
[23:59] <nbd> asus really needs some asskicking by laf0rge
[23:59] <nbd> or any other copyright holder
[23:59] <wigyori> yep, i saw that :)
[00:00] --- Tue Jun 6 2006