[00:05] <florian> nbd: does your kernel also crashes but can continue loading ?
[00:08] <nbd> user space seems stable
[00:09] <florian> but it crashes before getting you to user-space right ?
[00:11] <nbd> not without mtd
[00:12] <florian> ah, I am using initramfs and it crashes just before getting me to user-space
[00:12] <nbd> can you show me a kernel log?
[00:12] <florian> sure
[00:13] <florian> http://pastebin.ca/150420
[00:15] <nbd> can you show me a full one, from the beginning?
[00:15] <florian> ok
[00:16] <florian> http://pastebin.ca/150423
[00:20] <florian> do you have any about that ?
[00:20] <florian> any idea :)
[00:21] <nbd> no
[00:21] <nbd> does it happen randomly
[00:21] <nbd> ?
[00:21] <florian> no, it is always at the same place, right after "Algorithmics/MIPS FPU Emulator v1.5"
[00:22] <nbd> what kind of board is this?
[00:23] <nbd> i mean 6348 or 6345?
[00:24] <florian> 6348
[00:24] <florian> ah, I think it is a 6348GW
[00:24] <nbd> mine too
[00:24] <florian> the livebox is very particular, it has bluetooth, VoIP DSP ...
[00:24] <nbd> is the oops always the same?
[00:25] <florian> actually, yes
[00:26] <florian> once I managed to gain access to user-space
[00:29] <florian> nbd: do you think it could be hardware specific ?
[00:29] <nbd> maybe, since it does not happen on my hardware
[00:30] <florian> not really could
[00:31] <florian> and the only sources I have for that particular hardware is a 2.4 kernel from inventl
[00:36] <florian> nbd: have you changed the prom.c code and so on ?
[00:36] <nbd> yeah, i changed a few things
[00:37] <nbd> btw. is your cpu speed detected correctly?
[00:37] <nbd> oh, wait
[00:37] <florian> I don't remember if the speed was 256Mhz
[00:37] <nbd> noticed something
[00:37] <nbd> #
[00:37] <nbd> Memory: 4788k/7808k available
[00:37] <nbd> does your device only have 8 mb ram ??
[00:39] <florian> it has more if I well remember
[00:39] <florian> I need to find back a 2.4 dmesg
[00:41] <nbd> the 8 mb ram thing definitely explains the crash
[00:42] <florian> I think it is either 8mb or 16Mb ram
[00:43] <florian> I can find it via redboot actually
[00:44] <nbd> redboot should show it, normally
[00:44] <nbd> can you paste the redboot output?
[00:44] <florian> 16Mb
[00:45] <nbd> sounds like the problem might not have been caused by my changes
[00:45] <florian> http://pastebin.ca/150447
[00:45] <nbd> but instead it was triggered by using initramfs
[00:45] <florian> ah probably
[00:46] <nbd> you should compare the memory detection part in prom.c with the 2.4 stuff
[00:46] <florian> yes
[00:46] <florian> I will do it later, have to sleeping now, see you
[00:47] <nbd> see you tomorrow
[10:08] <florian> nbd: ping ?
[11:46] <nbd> florian: pong
[11:46] <florian> nbd: I found some code which can be memory detection related
[11:47] <florian> unfortunately, the box still detects 8Mb ram
[11:47] <nbd> i'll take a look at it later
[11:54] <florian> I saw that there was also several fixes in arch/mips/kerne/head.S
[12:00] <florian> the link to the inventel sources is here : http://www.inventel.com/gateway/gpl_software/OPENSOURCE-5G-2006-07-18.tgz
[12:00] <nbd> yeah, i have that one
[12:01] <florian> ok
[12:01] <florian> still no bcm_enet sources :(
[12:06] <CIA-17> nbd * r4682 /branches/buildroot-ng/openwrt/package/base-files/default/lib/network/config.sh: fix find_config() in the network scripts
[13:22] <CIA-17> nbd * r4684 /branches/buildroot-ng/openwrt/package/broadcom-wl/files/lib/wifi/broadcom.sh: broadcom-wl: set vlan_mode for every enabled interface
[13:22] <CIA-17> mbm * r4685 /branches/buildroot-ng/openwrt/package/base-files/default/etc/init.d/S10boot: change hotplug trigger to a simpler awk command
[14:03] <florian> nbd: thing that is strange is that 16Mb is hardcoded in the current prom.c we have
[14:03] <florian> I think I should force the bootloader to redboot since there is no detection yet
[14:07] <florian> I also noticed that r4k_interval is set to CPU_CLOCK / HZ / 2;
[14:07] <nbd> yes
[14:08] <florian> did you restore it in the current code, I did not look though
[14:08] <nbd> i removed the ifdefs and made it always check the cpu speed at run time
[14:08] <nbd> and set the r4k_interval in a similar way
[14:08] <florian> ok
[14:08] <nbd> the timer stuff is definitely working
[14:08] <florian> yes looks like it is
[14:09] <florian> ah ah, setting up the right boot_loader_type works !
[14:09] <nbd> does it detect the memory properly now?
[14:10] <florian> yes
[14:10] <florian> I also added few other fixes that should not be that much relevant
[14:10] <nbd> can you send me a diff between svn tree and your tree?
[14:11] <nbd> i will then commit it together with my binary compatibility hacks
[14:11] <florian> I did not patched yet, I will update it
[14:11] <nbd> ok
[14:11] <florian> I think we should also focus a bit on bootloader detection
[14:11] <florian> because this would dramatically ease further fixes
[14:11] <nbd> do you know if the flash is always mapped into the same memory location?
[14:12] <florian> how can I check ? I reboot and compare kmsg's ?
[14:13] <florian> I am currently using initramfs
[14:13] <nbd> hmm... i will look into it
[14:14] <florian> how could the memory location change by the way ?
[14:31] <nbd> it's hardware specific
[14:32] <florian> ok
[14:54] <florian> nbd: you can commit your fixes, I will commit mine later, have to go doing my homework :(
[14:54] <nbd> ok
[14:56] <florian> fscking exams
[14:56] <nbd> yeah
[15:08] <CIA-17> kaloz * r4686 /branches/buildroot-ng/openwrt/target/linux/magicbox-2.6/config: tune the Magicbox kernel config
[15:08] <CIA-17> nbd * r4687 /branches/buildroot-ng/openwrt/ (include/kernel.mk package/kernel/Makefile): fix LINUX_RELEASE and use it for the kmod-* build
[15:12] <CIA-17> nbd * r4688 /branches/buildroot-ng/openwrt/target/linux/imagebuilder/: remove old image builder directory - will be rewritten
[15:16] <mbm> btw there's a minor bug with the kernel module installation
[15:16] <mbm> for example if you build without uhci and later enable uhci
[15:17] <mbm> the module won't get built or installed
[15:17] <Kaloz> hmz
[15:17] <Kaloz> as we have select PCI_SUPPORT
[15:17] <mbm> haven't looked to see why
[15:17] <Kaloz> what about USB_SUUPORT, SOUND_SUPPORT, etc?
[15:17] <nbd> mbm: i think it's a stampfile problem
[15:17] <nbd> Kaloz: yeah, let's add those
[15:18] <nbd> well, not SOUND_SUPPORT
[15:18] <nbd> but USB_SUPPORT
[15:18] <mbm> nbd: yeah I figured as much but it really shouldn't need stamp files
[15:18] <nbd> mbm: i'll look into it
[15:19] <mbm> the ipk serves as a stamp
[15:19] <Kaloz> nbd: and package/alsa/Makefile:DEPENDS:=@PCI_SUPPORT should be @PCI_SUPPORT||USB_SUPPORT, right?
[15:19] <nbd> mbm: found the problem
[15:20] <nbd> Kaloz: yes
[15:20] <nbd> Kaloz: well, actually... do you think there can be USB without PCI_SUPPORT?
[15:20] <Kaloz> good catch.. theoritically yes, but didn't see such stuff yet
[15:20] <Kaloz> anyways, i leave it that way for now
[15:22] <CIA-17> nbd * r4689 /branches/buildroot-ng/openwrt/include/kernel-build.mk: move $(MAKE) packages from .linux-compile: to compile:
[15:22] <nbd> mbm: fixed
[15:22] <Kaloz> nbd: any idea why x86 doesn't have pci_support?
[15:22] <nbd> no
[15:23] <nbd> probably someone forgot it
[15:23] <Kaloz> k, i fix that as well
[15:24] <Kaloz> uml?
[15:24] <Kaloz> pci/usb? :)
[15:24] <nbd> i don't think so
[15:24] Action: Kaloz has no idea how uml handles those
[15:24] <Kaloz> k
[15:26] <Kaloz> and
[15:26] <Kaloz> menu "PCMCIA/CardBus support" depends LINUX_2_4_X86 || LINUX_2_6_X86 || LINUX_2_4_BRCM || LINUX_2_6_BRCM
[15:26] <Kaloz> can be changed to simply depõend on PCMCI_SUUPORT, right?
[15:26] <nbd> yes
[15:32] <CIA-17> kaloz * r4690 /branches/buildroot-ng/openwrt/target/ (Config.in linux/Config.in): introduce USB_SUPPORT, clean up some dependencies
[15:32] <Kaloz> that should be okay i guess
[16:15] <florian> we are still having a meeting tonight right ?
[16:15] <VinceLe> I'm trying various updated version of kernel, binutils on br-ng for ar7
[16:15] <VinceLe> and get a lot of compil problems
[16:16] <VinceLe> is there some extended documentation on such experimentations ?
[16:17] <VinceLe> like what to change for trying a new binutils / gcc or what has been already tested, etc...
[16:19] <nbd> VinceLe: you won't be able to use a newer gcc on linux 2.4
[16:19] <VinceLe> OK that was a shot in the dark :-)
[16:20] <VinceLe> but for binutils that is surprising me a bit...
[16:23] <VinceLe> I've seen somewhere (don't remember) that work has begun on 2.6-ar7 where can I find that ?
[19:09] <nbd> {Nico}: ping
[19:10] <nbd> VinceLe: do you have any kernel hacking experience?
[19:10] <VinceLe> not so much hacking but a lot of usage
[19:10] <VinceLe> a lot of reading lkml too
[19:10] <nbd> because we don't need testing for the ar7 2.6 port
[19:11] <nbd> we need people to complete it
[19:11] <VinceLe> One #define patch included upstream :P
[19:11] <nbd> the 2.6 port boots with initramfs, has no working flash map yet and no ethernet, dsl or wifi driver
[19:11] <VinceLe> but I'm willing to chage from user to developer status...
[19:12] <nbd> i've started a new ethernet driver, but it's less than 1/3 complete, can't do anything useful yet and needs lots of work
[19:12] <nbd> and i don't have the time to finish it
[19:12] <VinceLe> I'm just trying to do compilation test now because I'm waiting for my max232 to get there...
[19:12] <nbd> i have a patch that represents the state of my work, which is based on 2.6.15
[19:12] <nbd> that would need to be forward-ported as well
[19:12] <nbd> so compilation tests are entirely useless
[19:12] <VinceLe> and I won't try to flash without serial console
[19:13] <VinceLe> Is your work hosted somewhere ?
[19:13] <nbd> not at the moment
[19:13] <nbd> wait
[19:13] <nbd> the patch is
[19:13] <nbd> http://downloads.openwrt.org/people/nbd/tmp/ar7.patch
[19:13] <VinceLe> I may be able to try forward port too...
[19:13] <nbd> not without a serial console :)
[19:13] <VinceLe> thank you, I'll have a look
[19:14] <VinceLe> and read that code
[19:14] <VinceLe> I'm experiencing with git, so that will be good material to put in that beast
[19:15] <VinceLe> got it, starting to read
[19:15] <nbd> if you really want to start with kernel hacking, i can give you some detailed info on what we have, when you get your serial console
[19:16] <VinceLe> OK
[19:17] <VinceLe> I already have a question :)
[19:17] <nbd> ok :)
[19:17] <VinceLe> Does some models have yamon as bootloader ?
[19:17] <nbd> i've never seen one that uses yamon
[19:17] <nbd> mostly adam2, which emulates part of the yamon api
[19:18] <VinceLe> the first lines of the patch are for yamon-passed boot params
[19:18] <VinceLe> Ah OK
[19:18] <VinceLe> good to know
[19:18] <nbd> some devices also use pspboot
[19:18] <nbd> if i recall correctly, it's also partially compatible
[19:18] <VinceLe> Yes I think I have one of them
[19:18] <nbd> adam2 is easier, because it can netboot the kernels
[19:19] <nbd> having to reflash for every test is annoying
[19:19] <VinceLe> I have a DG834G which I'll hack, and a WAG354G that I'll keep functional until the DG+openwrt work
[19:19] <nbd> on 2.4 the wag354g had some extra problems
[19:20] <nbd> so yes, it's better to start off with the dg834g
[19:20] <nbd> you should flash it with the linux 2.4 port once, though
[19:20] <nbd> since the boot loader has a crc check
[19:20] <nbd> and our ar7 port changes a few bytes in the loader to disable that check
[19:20] <nbd> (automatically)
[19:20] <VinceLe> yes, I already prepared the updated adam2
[19:20] <nbd> ah, ok
[19:20] <nbd> great
[19:21] <nbd> the most important task after forward-porting the kernel is to finish the ethernet driver
[19:21] <nbd> i've just added some basic hw init and i wrote some code to set up the dma descriptor rings
[19:21] <VinceLe> You mean to flash the entire MTD overwriting adam2 partition in one go ?
[19:21] <nbd> huh?
[19:22] <VinceLe> I have just modified the copy of mtd2
[19:22] <nbd> flash an openwrt image over the web interface instead
[19:22] <VinceLe> and would flash that alone
[19:22] <nbd> because it doesn't overwrite the boot loader
[19:22] <nbd> it just patches 4 bytes
[19:22] <nbd> that has less risk attached
[19:23] <VinceLe> Yes, I have done that manually on the backup copy I made
[19:23] <VinceLe> and checked the resulting md5sum
[19:23] <nbd> so you have changed the boot loader on the flash already?
[19:23] <VinceLe> but if the built image already has that, ~i'll use it
[19:24] <VinceLe> no, just prepared the mtd2 image to be flashed when I got the serial
[19:24] <nbd> the image just provides a safer way of doing it (and it does so automatically)
[19:25] <VinceLe> OK, but You only flash adam2 once, after that you only flash kernel+fs, right ?
[19:25] <nbd> well, normally it should work like this:
[19:25] <nbd> you flash a complete image with openwrt over the web interface
[19:25] <nbd> the device writes the kernel and fs to the flash
[19:26] <nbd> when openwrt boots up, it checks the md5sum of the boot loader
[19:26] <nbd> if it matches the original one, it patches 4 bytes and then goes on booting
[19:27] <VinceLe> OK, but I thought that an unpatched adam2 would not boot the new image because it does not have the required magic thing somewhere...
[19:28] <VinceLe> or did you reveng that magic thing ?
[19:28] <VinceLe> and add it to dg834 images ?
[19:30] <nbd> the image that openwrt generates has a valid crc
[19:30] <nbd> that's why it boots
[19:30] <VinceLe> OK that explains all
[19:40] <{Nico}> nbd: pong
[19:41] <nbd> {Nico}: do you remember which ipkg version the busybox patch is based on?
[19:41] <{Nico}> nbd: wait a min.
[19:42] <{Nico}> 0.99.162
[19:43] <nbd> thanks
[19:43] <nbd> i think it's annoying that versioned depends are still broken
[19:46] <{Nico}> trying to understand ipkg source code is a real pain
[19:47] <{Nico}> maybe we should talk about that ipkg-ng again
[19:48] <{Nico}> bbl
[19:52] <florian> re
[20:08] <florian> nbd: can you post your latest bcm963xx fixes ?
[20:59] <nbd> florian_: i'll make a patch for you
[21:08] <nbd> florian_: ok. all my stuff is in svn now
[21:15] <florian_> thank you !
[22:15] <florian_> re
[22:19] <florian_91_44> looks like we are going to start the meeting ?
[22:20] <mbm> sure
[22:22] <nbd> mbm: topics for today?
[22:23] <mbm> no real agenda this time, I just wanted to catch up
[22:23] <mbm> ng is looking pretty good on the broadcom after the patches made earlier
[22:24] <mbm> but it still lacks a few basic things like diag (which is preventing failsafe) and minifo
[22:24] <florian_91_44> ok, so I might add something
[22:24] <groz> i'm only partially here for about 15 more minutes, then i'll be 'here' for a bit
[22:24] <florian_91_44> I have starting compiling the wiki into what we could later call an openwrt book
[22:25] <florian_91_44> what I would like to cover is : porting a new arch, porting packages, adding new packages, configuring and using whiterussian and buildroot-ng, debugging with openwrt (just general concerns)
[22:26] <mbm> ok, I do have a few publishing connections
[22:26] <Kaloz> buildroot-ng as a name will be gones soon probably :)
[22:26] <florian_91_44> well, this could be good to publish this kind of book in order to clarify things
[22:26] <nbd> yeah
[22:26] <mbm> Kaloz: right that's what I was getting at
[22:26] <nbd> the main missing thing is the image builder
[22:27] <florian_91_44> also, I think that a brief openwrt history : sveasoft ... would be good
[22:27] <nbd> but i think we should do the move even before that one's ready
[22:27] <florian_91_44> we can discuss this thing later
[22:27] <nbd> since current trunk/ is pretty much useless now
[22:27] <florian_91_44> well, the main task that remains is converting kernel modules to the new layout
[22:27] <nbd> we should probably svn mv trunk tags/kamikaze-oldl svn mv branches/buildroot-ng trunk;
[22:27] <nbd> s/oldl/old;/
[22:28] <florian_91_44> sounds good
[22:29] <florian_91_44> Kaloz, nbd, mbm what do you think about an official book ?
[22:30] <Kaloz> no reason imho
[22:30] <Kaloz> i mena, no reason to keep a useless copy of the old trunk
[22:30] <mbm> somewhat concerned about how up to date the book could be given that we're constantly changing things
[22:31] <nbd> Kaloz: svn mv is better than svn rm
[22:31] <Kaloz> nbd: i mean overwrite the trunk stuff and svn commit it :p
[22:32] <nbd> overwriting is more work, i've had some trouble with it before
[22:32] <nbd> svn is weird there
[22:32] <mbm> just do a mv
[22:32] <florian_91_44> mbm: that's true, that's also why we need at least not to change many things as we have done during the past few months, at least concerning package developpment (that mostly interests new users), and the way to add a new target I think
[22:33] <{Nico}> we should keep old trunk somewhere until all ports to -ng are done
[22:33] <nbd> florian_91_44: it's our development version. promising not to change things is a bad idea at this point
[22:33] <florian_91_44> nbd: this also interests people
[22:33] <nbd> florian_91_44: i don't expect that many changes
[22:34] <florian_91_44> nbd: you have seen like me that during the past weeks many people spoke about -ng in #openwrt
[22:34] <nbd> florian_91_44: and i do believe that the format will stay compatible with our changes
[22:34] <florian_91_44> nbd: then it's ok
[22:34] <nbd> florian_91_44: but we shouldn't freeze the format yet
[22:34] <florian_91_44> sure, this would refrain us from evolving
[22:34] <nbd> exactly
[22:35] <Kaloz> well, when br-ng hits whiterussian, you can document that
[22:35] <nbd> that's one of the main advantages of the new format, it's so easy to extend without breaking compatibility
[22:35] <{Nico}> florian_91_44: the book should focus on embedded development and wireless and present openwrt with buildroot-ng as the tool of choice
[22:35] <Kaloz> Kamikaze will keep changing for some time
[22:35] <nbd> i don't think we're ready to do a book just yet
[22:35] <florian_91_44> {Nico}: that's good
[22:35] <nbd> maybe for 1.0
[22:35] <florian_91_44> ok
[22:36] <florian_91_44> we can still start writing parts that are not config format dependent or something like that
[22:37] <nbd> so... rc6?
[22:38] <florian_91_44> :)
[22:38] <mbm> as usual nothing has been done on whiterussian lately
[22:38] <nbd> a few things have been done
[22:38] <nbd> and i'm almost done with umts support
[22:38] <florian_91_44> yes there was some
[22:39] <malbon> should I setup an autobuilder for whiterussian?
[22:39] <mbm> ah, yep .. must have missed the commit messages
[22:40] <nbd> let's talk about webif plans
[22:40] <mbm> speaking of which, where's db90h
[22:40] <nbd> db90h: ping
[22:40] <nbd> :)
[22:41] <db90h> ;)
[22:41] <db90h> i hope to complete much more work on the webif, and i hope that much of it will be directly usable in RC6, if you guys so choose
[22:41] <mbm> as I said at the last meeting, my main concern was removing the broken bits of webif like the very confusing firewall page, and adding the various nvram values
[22:42] <nbd> the firewall stuff should be rewritten using buildroot-ng style config files
[22:42] <mbm> would be nice if the firewall page was replaced by something that works but that isn't high on my todo list
[22:42] <groz> i have a suggestion if folks are re-writing webif or parts thereof
[22:42] <nbd> and db90h merged some dhcp config stuff in his tree, which i believe should also be converted to a buildroot-ng style config
[22:42] <db90h> yes,.. the firewall, dnsmasq, and qos pages..
[22:42] <groz> if it's 'write it out' functions are encapsulated, then, they can be overridden with new ones, that spew forth the new config formats used in -ng
[22:42] <db90h> any others you can think of off hand?
[22:43] <groz> then all of the if code can be re-used
[22:43] <mbm> db90h: there's also a number of nvram settings which right now can only be set manually at the commandline, tons of them for wl .. even the ones we do show aren't grouped in any useful way
[22:43] <db90h> i'd like to have pages for all common packages, until ng where all packages supplying a compatible config file will be supported by the new system
[22:43] <nbd> mbm: i also gave db90h a snapshot of some update code for buildroot-ng config files: http://downloads.openwrt.org/people/nbd/tmp/config-stuff.tar.gz
[22:43] <mbm> :)
[22:43] <nbd> mbm: the parser is already included in /etc/functions.sh
[22:44] <db90h> i like the ideal of not mandating any new nvram variables, unless absolutely necessary (which seems unlikely)
[22:45] <nbd> we did add a few variables occasionally, but only where it made sense
[22:45] <mbm> has anyone given any thought to webif on ng? are we still going to use ash and awk or do we write it in c and have shared object plugins?
[22:46] <nbd> i was thinking about a mix of both, when we're actually rewriting it:
[22:46] <nbd> have a template engine in c that transforms an abstract syntax for defining forms into html
[22:46] <nbd> and defining shell functions in the same file for interacting with the config stuff
[22:46] <nbd> so we don't have to code everything in c
[22:47] <{Nico}> nbd: you mean extend haserl or drop it?
[22:47] <db90h> yes, that sounds good for the NG webif
[22:47] <nbd> drop it, the haserl code is ugly
[22:47] <db90h> speaking of which... the life of the current webif system.. is planned to extend to what? release 0.9?
[22:48] <nbd> when i did the translation wrapper, i first wanted to build it into haserl
[22:48] <nbd> but i found that the code was so messy that i gave it up shortly after
[22:48] <mbm> db90h: oh, if you're looking for new features for webif, something I had planned on doing was a vlan config page .. would just be a very simple table like http://downloads.openwrt.org/people/mbm/vlan.html showing a matrix of the ports and the vlans they're assigned to
[22:50] <Exiles> hmmm
[22:50] <db90h> it seems one of the unfortunate things is that all the work on the current webif system will be deprecated and incompatible with the new system, however i do not think that this should prevent work on the current webif system, because as you guys know, people use releases even after they've been deprecated for years
[22:50] <nbd> we will keep the old one around for a while, i think. i don't know when we're actually going to start hacking on a new one
[22:50] <mbm> ... let's not start another flamewar ?
[22:51] <mbm> apart from available time, nothing is stopping anyone from working on webif
[22:52] <db90h> i was considering rollover help.. is this something that you guys are opposed to for any reason?
[22:52] <nbd> no
[22:52] <mbm> if you can think of a good way to share code between whiterussian and ng I'd love to hear it
[22:53] <nbd> mbm: if we make use of the -ng config format for the more complex pages, then we can keep most of the code when we port it over to -ng
[22:53] <nbd> mbm: e.g. firewall, dhcp, etc.
[22:53] <mbm> sounds good
[22:53] <nbd> wifi config, network config will have to be redone anyway
[22:57] <florian_91_44> what about pending ticjets ?
[22:57] <florian_91_44> tickets sorry
[22:57] Action: nbd looks
[22:58] <nbd> is anybody actually interested in the gdb stuff?
[22:58] <nbd> or can we leave that for 1.0/-ng
[22:58] <Exiles> gdb?
[22:58] <db90h> mbm: ah, i like the vlan page..
[22:58] <nbd> Exiles: debugger
[22:59] <florian_91_44> gdb sounds doable for 1.0
[22:59] <mbm> db90h: any port which lists multiple vlans should be considered a tagged port
[22:59] <nbd> but you can have a port untagged in one vlan and tagged in another, right?
[23:00] <mbm> right, the tagging is just triggered when there are multiple vlans associated with a single port -- tagging is automatically turned on for that port
[23:02] <florian_91_44> there is a lof of kernel and motorola related bugs, how do we proceed ? do we ask a user to do intensive tests ?
[23:02] <db90h> ok, i will start on the vlan page soon
[23:02] <nbd> mbm: but how do you control where the port is untagged and where it's tagged if it can be both at the same time?
[23:02] <nbd> florian_91_44: yeah, we definitely need someone with access to the hardware
[23:03] <mbm> nbd: a vlan can be untaged on one port and tagged on another
[23:03] <db90h> mbm: is there any work you've already done, or did I understand correctly that this is just a 'look and feel' template?
[23:03] <mbm> db90h: just a mockup; I started playing around with ideas for a generic network interface page alsp
[23:04] <nbd> mbm: yeah, that's what i said, but how do you integrate that in the web interface?
[23:05] <mbm> nbd: I really don't see what's so complicated, the example shows vlan0ports="1 2 3 4 5t" vlan1ports=0 5t" .. 5 is listed in both vlans so it automatically gets the "t"
[23:05] <florian_91_44> shall we stick to awk ?
[23:06] <florian_91_44> and should we open webif developpment to users ?
[23:07] <nbd> mbm: but you could have something like this: vlan0ports="1 2 3 4 5t" vlan2ports="1t 2t 3t 4t 5t"
[23:07] <db90h> a three way checkbox could be used, but that seems more confusing than anything
[23:07] <nbd> mbm: ports 1-4 untagged in vlan0, tagged in vlan2
[23:07] <mbm> nbd: it really wouldn't make sense to do that though
[23:08] <nbd> mbm: it would, if you leave out a few ports and run a different subnet on the same cable
[23:08] <nbd> mbm: which not all ports have access to
[23:08] <mbm> I mean either the equipment connected to teh ports uses vlans or it doesn't
[23:09] <Exiles> more and more equpiment is able to though
[23:09] <nbd> mbm: it might be connected to a switch with a few nodes that can't do vlan and with a few more that can
[23:09] <Exiles> I have a 24 port switch that does vlans
[23:09] <mbm> nbd: if you have any equipment that doesn't do vlan tagging it should be connected through an untagged port, you shouldn't mix tagging on a port
[23:10] <nbd> i still think that it could be useful for some people
[23:10] <nbd> but maybe we can just force them to not use webif for that
[23:11] <db90h> yes, if it's a small minority that would use it, then i think it would save confusion for the majority to leave it off..
[23:12] <mbm> well, along the same lines, it's also possible for me to buy a dumb switched hub, connect my lan and my cable modem through it and then run interface aliasing on one of my lan computers to make it actually use the cable modem .. works? yes. good ide? not really
[23:13] <db90h> i'll write up a basic vlan page and if a need to allow untag/tagged port over-rides arises and someone has an idea to do it gracefully, then we can add it
[23:13] <nbd> makes sense
[23:14] <mbm> the problem with missing tagged and untagged on a single port is that if the device doesn't support vlans it still sees the vlan tag and may even blindly forward the vlan tagged packet
[23:14] <mbm> er mixing
[23:16] <florian_91_44> do you think webif is that much important for a 1.0 release ? I ask this question really naively
[23:17] <nbd> i think lots of people would complain if it was missing
[23:17] <{Nico}> florian_91_44: we already have it, it just needs some fixing / enhancements
[23:17] <mbm> right, which is why I didn't just rip it out and mark a release
[23:17] <Exiles> I feel if done right, it will make openwrt end user capable, instead of being moreso for people with highend needs
[23:18] <florian_91_44> I don't think about suppressing it, but do we need full-featured webif that would ease a lof of tasks or still let the user configure most things by shell
[23:18] <db90h> btw, i extended the numbering gap between webif pages to allow for WR packages to install their own pages and be able to insert beween page X and page Y.. it's not perfect by any means.. is there a better solution anyone can think of?
[23:19] <Exiles> I could do so in perl, but not sure with webif
[23:19] <db90h> also, by extending the gap, any third-party pages that already have low numbers will be advanced to the beginning.. but I thought of if I find a page number <10 I'll make it go to the end
[23:19] <{Nico}> db90h: do you already have support for all wl variables?
[23:20] <db90h> no, not yet.. i added gmode, txpwr, ap_isolate
[23:20] <db90h> i plan to support them all before its over
[23:21] <mbm> don't think the order that the pages appear on the menu is important
[23:22] <groz> it's important if you get to the stage of being worried about cosmetics
[23:22] <groz> helps control logical flows
[23:23] <mbm> as longas it's consistant enough that the new page always shows up in the amse location, it really doesn't matter what that location is
[23:23] <db90h> yea, it's not mission critical by any means.. so i suppose i'll just stick with this inperfect solution of leaving a gap between default pages for now, it will be good enough
[23:23] <mbm> if it starts moving around randomly every time I change pages I might get annoyed
[23:23] <db90h> hehe
[23:24] <florian_91_44> so webif seems to be the most significant module to improve before a 1.0 release ?
[23:26] <nbd> yes
[23:26] <nbd> and we also need to fix up some stuff for the wl-500g premium
[23:26] <mbm> yes, that's what's holding back the 0.9 release (1.0 is ng)
[23:26] <florian_91_44> ok,could not we make a rc6 including only hardware bugfixes
[23:27] <florian_91_44> then a 0.9 with the new webif ?
[23:27] <mbm> we should probably go through and update all the whiterussian packages to their latest version so the next whiterussian release doesn't use obsolete versions
[23:27] <mbm> florian_91_44: well, not new as in rewritten, but new as in fixed (if it gets rewritten, great)
[23:27] <nbd> mbm: why not remove lots of packages like asterisk and build them with the sdk from the -ng package sources instead?
[23:28] <florian_91_44> I think it's a good idea, most update fixes problems for packages
[23:28] <db90h> what about the old squashfs in WR (and other old things)? you guys gonna update it/them in RC6?
[23:28] <mbm> db90h: thats what I mean, all of that really should be updated
[23:29] <db90h> sounds good.. btw, squashfs 3.1 was released last week for anyone who didn't notice.. i imagine the lzma patches might need some adjustment, but that should be no big deal
[23:30] <florian_91_44> lzma itself could be upgraded as well
[23:30] <nbd> i think we should keep the old version where updating doesn't give us any real benefits
[23:30] <nbd> iirc with the lzma stuff it got bigger after updating
[23:31] <florian_91_44> possibly
[23:31] <Kaloz> db90h: no reason to upgrade as far as i saw
[23:32] <db90h> i agree, no huge reason to upgrade..
[23:32] <Kaloz> :P
[23:32] <db90h> ;)
[23:32] <florian_91_44> what about devices ? do we stick to bcm947xx/53xx ?
[23:32] <nbd> sure
[23:32] <Kaloz> basically backward compatibility stuff were added, what we rip out anyways
[23:32] <Kaloz> :)
[23:32] <Kaloz> florian_91_44: whiterussian won't support other platforms. that's kamikaze's privilege
[23:33] <db90h> you guys might consider turning off SIZE mode for JFFS2 at runtime.. as this compresses each block some 5 times (or so) to try and find the best.. and I'd say 98% or more of the time it ends up using ZLIB anyway
[23:33] <nbd> db90h: iirc at some point i already reduced the number of algorithms
[23:33] <db90h> oh, ok
[23:33] <nbd> db90h: and sometimes it gets distributed quite even between lzo and zlib
[23:34] <nbd> don't know if it was lzo
[23:34] <nbd> but something with lz* for sure :)
[23:34] <db90h> oh, i didn't know that.. I always meant to check and see the distribution of the algorithms used
[23:34] <nbd> and i don't think filesystem performance is that important
[23:34] <nbd> size reduction however is
[23:35] <db90h> if I ever get around to doing a survey on the algorithms, I'll let you know if there are any that remain which never get used
[23:35] <nbd> ok
[23:35] <florian_91_44> who does what ?
[23:36] <nbd> ?
[23:36] <florian_91_44> I mean to complete 0.9 how do we proceed ?
[23:37] <nbd> everybody does what he wants to do? :)
[23:37] <groz> i'll be back shortly foks, gotta step away for a few minutes
[23:37] <florian_91_44> I will be very busy this week, but after it will be ok to do massive testing and so on
[23:38] <florian_91_44> I also insist on having a proper documentation, even for 0.9
[23:39] <florian_91_44> if it does not cover developpment it should cover configuration/usage
[23:39] <florian_91_44> the wiki is a real mess we already mentioned it
[23:39] <nbd> yeah, we really could use some decent documentation
[23:40] <florian_91_44> the job is not that hard, compile, update the infos, write some examples ...
[23:40] <florian_91_44> this is a thing I would like to do
[23:40] <nbd> great
[23:42] <{Nico}> if we can agree on some toc, writing will come along
[23:44] <florian_91_44> let's agree ;) ?
[23:45] <nbd> agreed :)
[23:45] <mbm> damn, wireless network crashed 10 min ago
[23:45] <mbm> (re)
[23:45] <florian_91_44> mbm: fscking openwrt box ?
[23:45] <florian_91_44> you should seriously think about running dd-wrt instead
[23:46] <mbm> florian_91_44: no, fscking ubuntu box, now it won't even let me select that it's a wpa network
[23:46] <mbm> got sick of it and just plugged in a wire
[23:47] <florian_91_44> my ibook sometimes unload bcm43xx when it wants
[23:47] Action: Kaloz configures tha stuff by hand - no problems at all :)
[23:47] <Kaloz> brb
[23:48] <mbm> yeah, it kicked my bcm43xx card offline a few times
[23:48] <mbm> grabbed a different card and couldn't get it to connect via wpa
[23:48] Action: mbm really needs to buy a ew network card
[23:50] <Bartman007> mbm: does Ubuntu allow WPA configuration out of the box?
[23:50] <mbm> nope, requires some very annoying gnome applet
[23:51] <mbm> after that it usually just works
[23:51] <mbm> except for some drivers
[23:51] <mbm> the bcm43xx in ubuntu is pretty bad
[23:52] <mbm> the gnome app refuses to find my network most of the time since it's ssid hidden
[23:52] <mbm> so I run an iwconfig command to force the connection
[23:52] <mbm> it gets connected, authed and about 10 packets go through
[23:52] <mbm> then I need to run iwconfig again and force the connection
[23:53] <Bartman007> yeah, I haven't figured out a way to make linux autodetect hidden networks (with wpa_supplicant at least)
[23:53] <mbm> after that it stays up for hours at a time
[23:53] <mbm> something weird though when it gets authed and sends a few packets and then suddenly stopps until forced to reconnect
[23:54] <Bartman007> at first I had a similar problem, it would connect, and auth, but dhcp would timeout.
[23:54] <Bartman007> (gentoo here)
[23:54] <florian_91_44> we need to find someone with a motorola device
[23:55] <Bartman007> florian_91_44: a motorola bcrm?
[23:55] <nbd> yep
[23:55] <nbd> actually preferably several motorolas
[23:55] <Bartman007> iirc, TheCompWiz has one
[23:55] <nbd> because there are several different ones
[23:55] <Bartman007> I think he has a WR850G
[23:56] <florian_91_44> ok,that would be great, there are lot of pending bugs related to motorola devices
[23:56] <Bartman007> damnit, firefox lost sound agin.
[23:57] <{Nico}> florian_91_44, nbd, Kaloz: anyone of you knows where we can find one in EU?
[23:57] <nbd> no
[23:57] <florian_91_44> {Nico}: I never saw one
[23:58] <florian_91_44> {Nico}: etienne will have its ar525w soon
[00:00] --- Mon Aug 28 2006
[00:08] <nbd> user space seems stable
[00:09] <florian> but it crashes before getting you to user-space right ?
[00:11] <nbd> not without mtd
[00:12] <florian> ah, I am using initramfs and it crashes just before getting me to user-space
[00:12] <nbd> can you show me a kernel log?
[00:12] <florian> sure
[00:13] <florian> http://pastebin.ca/150420
[00:15] <nbd> can you show me a full one, from the beginning?
[00:15] <florian> ok
[00:16] <florian> http://pastebin.ca/150423
[00:20] <florian> do you have any about that ?
[00:20] <florian> any idea :)
[00:21] <nbd> no
[00:21] <nbd> does it happen randomly
[00:21] <nbd> ?
[00:21] <florian> no, it is always at the same place, right after "Algorithmics/MIPS FPU Emulator v1.5"
[00:22] <nbd> what kind of board is this?
[00:23] <nbd> i mean 6348 or 6345?
[00:24] <florian> 6348
[00:24] <florian> ah, I think it is a 6348GW
[00:24] <nbd> mine too
[00:24] <florian> the livebox is very particular, it has bluetooth, VoIP DSP ...
[00:24] <nbd> is the oops always the same?
[00:25] <florian> actually, yes
[00:26] <florian> once I managed to gain access to user-space
[00:29] <florian> nbd: do you think it could be hardware specific ?
[00:29] <nbd> maybe, since it does not happen on my hardware
[00:30] <florian> not really could
[00:31] <florian> and the only sources I have for that particular hardware is a 2.4 kernel from inventl
[00:36] <florian> nbd: have you changed the prom.c code and so on ?
[00:36] <nbd> yeah, i changed a few things
[00:37] <nbd> btw. is your cpu speed detected correctly?
[00:37] <nbd> oh, wait
[00:37] <florian> I don't remember if the speed was 256Mhz
[00:37] <nbd> noticed something
[00:37] <nbd> #
[00:37] <nbd> Memory: 4788k/7808k available
[00:37] <nbd> does your device only have 8 mb ram ??
[00:39] <florian> it has more if I well remember
[00:39] <florian> I need to find back a 2.4 dmesg
[00:41] <nbd> the 8 mb ram thing definitely explains the crash
[00:42] <florian> I think it is either 8mb or 16Mb ram
[00:43] <florian> I can find it via redboot actually
[00:44] <nbd> redboot should show it, normally
[00:44] <nbd> can you paste the redboot output?
[00:44] <florian> 16Mb
[00:45] <nbd> sounds like the problem might not have been caused by my changes
[00:45] <florian> http://pastebin.ca/150447
[00:45] <nbd> but instead it was triggered by using initramfs
[00:45] <florian> ah probably
[00:46] <nbd> you should compare the memory detection part in prom.c with the 2.4 stuff
[00:46] <florian> yes
[00:46] <florian> I will do it later, have to sleeping now, see you
[00:47] <nbd> see you tomorrow
[10:08] <florian> nbd: ping ?
[11:46] <nbd> florian: pong
[11:46] <florian> nbd: I found some code which can be memory detection related
[11:47] <florian> unfortunately, the box still detects 8Mb ram
[11:47] <nbd> i'll take a look at it later
[11:54] <florian> I saw that there was also several fixes in arch/mips/kerne/head.S
[12:00] <florian> the link to the inventel sources is here : http://www.inventel.com/gateway/gpl_software/OPENSOURCE-5G-2006-07-18.tgz
[12:00] <nbd> yeah, i have that one
[12:01] <florian> ok
[12:01] <florian> still no bcm_enet sources :(
[12:06] <CIA-17> nbd * r4682 /branches/buildroot-ng/openwrt/package/base-files/default/lib/network/config.sh: fix find_config() in the network scripts
[13:22] <CIA-17> nbd * r4684 /branches/buildroot-ng/openwrt/package/broadcom-wl/files/lib/wifi/broadcom.sh: broadcom-wl: set vlan_mode for every enabled interface
[13:22] <CIA-17> mbm * r4685 /branches/buildroot-ng/openwrt/package/base-files/default/etc/init.d/S10boot: change hotplug trigger to a simpler awk command
[14:03] <florian> nbd: thing that is strange is that 16Mb is hardcoded in the current prom.c we have
[14:03] <florian> I think I should force the bootloader to redboot since there is no detection yet
[14:07] <florian> I also noticed that r4k_interval is set to CPU_CLOCK / HZ / 2;
[14:07] <nbd> yes
[14:08] <florian> did you restore it in the current code, I did not look though
[14:08] <nbd> i removed the ifdefs and made it always check the cpu speed at run time
[14:08] <nbd> and set the r4k_interval in a similar way
[14:08] <florian> ok
[14:08] <nbd> the timer stuff is definitely working
[14:08] <florian> yes looks like it is
[14:09] <florian> ah ah, setting up the right boot_loader_type works !
[14:09] <nbd> does it detect the memory properly now?
[14:10] <florian> yes
[14:10] <florian> I also added few other fixes that should not be that much relevant
[14:10] <nbd> can you send me a diff between svn tree and your tree?
[14:11] <nbd> i will then commit it together with my binary compatibility hacks
[14:11] <florian> I did not patched yet, I will update it
[14:11] <nbd> ok
[14:11] <florian> I think we should also focus a bit on bootloader detection
[14:11] <florian> because this would dramatically ease further fixes
[14:11] <nbd> do you know if the flash is always mapped into the same memory location?
[14:12] <florian> how can I check ? I reboot and compare kmsg's ?
[14:13] <florian> I am currently using initramfs
[14:13] <nbd> hmm... i will look into it
[14:14] <florian> how could the memory location change by the way ?
[14:31] <nbd> it's hardware specific
[14:32] <florian> ok
[14:54] <florian> nbd: you can commit your fixes, I will commit mine later, have to go doing my homework :(
[14:54] <nbd> ok
[14:56] <florian> fscking exams
[14:56] <nbd> yeah
[15:08] <CIA-17> kaloz * r4686 /branches/buildroot-ng/openwrt/target/linux/magicbox-2.6/config: tune the Magicbox kernel config
[15:08] <CIA-17> nbd * r4687 /branches/buildroot-ng/openwrt/ (include/kernel.mk package/kernel/Makefile): fix LINUX_RELEASE and use it for the kmod-* build
[15:12] <CIA-17> nbd * r4688 /branches/buildroot-ng/openwrt/target/linux/imagebuilder/: remove old image builder directory - will be rewritten
[15:16] <mbm> btw there's a minor bug with the kernel module installation
[15:16] <mbm> for example if you build without uhci and later enable uhci
[15:17] <mbm> the module won't get built or installed
[15:17] <Kaloz> hmz
[15:17] <Kaloz> as we have select PCI_SUPPORT
[15:17] <mbm> haven't looked to see why
[15:17] <Kaloz> what about USB_SUUPORT, SOUND_SUPPORT, etc?
[15:17] <nbd> mbm: i think it's a stampfile problem
[15:17] <nbd> Kaloz: yeah, let's add those
[15:18] <nbd> well, not SOUND_SUPPORT
[15:18] <nbd> but USB_SUPPORT
[15:18] <mbm> nbd: yeah I figured as much but it really shouldn't need stamp files
[15:18] <nbd> mbm: i'll look into it
[15:19] <mbm> the ipk serves as a stamp
[15:19] <Kaloz> nbd: and package/alsa/Makefile:DEPENDS:=@PCI_SUPPORT should be @PCI_SUPPORT||USB_SUPPORT, right?
[15:19] <nbd> mbm: found the problem
[15:20] <nbd> Kaloz: yes
[15:20] <nbd> Kaloz: well, actually... do you think there can be USB without PCI_SUPPORT?
[15:20] <Kaloz> good catch.. theoritically yes, but didn't see such stuff yet
[15:20] <Kaloz> anyways, i leave it that way for now
[15:22] <CIA-17> nbd * r4689 /branches/buildroot-ng/openwrt/include/kernel-build.mk: move $(MAKE) packages from .linux-compile: to compile:
[15:22] <nbd> mbm: fixed
[15:22] <Kaloz> nbd: any idea why x86 doesn't have pci_support?
[15:22] <nbd> no
[15:23] <nbd> probably someone forgot it
[15:23] <Kaloz> k, i fix that as well
[15:24] <Kaloz> uml?
[15:24] <Kaloz> pci/usb? :)
[15:24] <nbd> i don't think so
[15:24] Action: Kaloz has no idea how uml handles those
[15:24] <Kaloz> k
[15:26] <Kaloz> and
[15:26] <Kaloz> menu "PCMCIA/CardBus support" depends LINUX_2_4_X86 || LINUX_2_6_X86 || LINUX_2_4_BRCM || LINUX_2_6_BRCM
[15:26] <Kaloz> can be changed to simply depõend on PCMCI_SUUPORT, right?
[15:26] <nbd> yes
[15:32] <CIA-17> kaloz * r4690 /branches/buildroot-ng/openwrt/target/ (Config.in linux/Config.in): introduce USB_SUPPORT, clean up some dependencies
[15:32] <Kaloz> that should be okay i guess
[16:15] <florian> we are still having a meeting tonight right ?
[16:15] <VinceLe> I'm trying various updated version of kernel, binutils on br-ng for ar7
[16:15] <VinceLe> and get a lot of compil problems
[16:16] <VinceLe> is there some extended documentation on such experimentations ?
[16:17] <VinceLe> like what to change for trying a new binutils / gcc or what has been already tested, etc...
[16:19] <nbd> VinceLe: you won't be able to use a newer gcc on linux 2.4
[16:19] <VinceLe> OK that was a shot in the dark :-)
[16:20] <VinceLe> but for binutils that is surprising me a bit...
[16:23] <VinceLe> I've seen somewhere (don't remember) that work has begun on 2.6-ar7 where can I find that ?
[19:09] <nbd> {Nico}: ping
[19:10] <nbd> VinceLe: do you have any kernel hacking experience?
[19:10] <VinceLe> not so much hacking but a lot of usage
[19:10] <VinceLe> a lot of reading lkml too
[19:10] <nbd> because we don't need testing for the ar7 2.6 port
[19:11] <nbd> we need people to complete it
[19:11] <VinceLe> One #define patch included upstream :P
[19:11] <nbd> the 2.6 port boots with initramfs, has no working flash map yet and no ethernet, dsl or wifi driver
[19:11] <VinceLe> but I'm willing to chage from user to developer status...
[19:12] <nbd> i've started a new ethernet driver, but it's less than 1/3 complete, can't do anything useful yet and needs lots of work
[19:12] <nbd> and i don't have the time to finish it
[19:12] <VinceLe> I'm just trying to do compilation test now because I'm waiting for my max232 to get there...
[19:12] <nbd> i have a patch that represents the state of my work, which is based on 2.6.15
[19:12] <nbd> that would need to be forward-ported as well
[19:12] <nbd> so compilation tests are entirely useless
[19:12] <VinceLe> and I won't try to flash without serial console
[19:13] <VinceLe> Is your work hosted somewhere ?
[19:13] <nbd> not at the moment
[19:13] <nbd> wait
[19:13] <nbd> the patch is
[19:13] <nbd> http://downloads.openwrt.org/people/nbd/tmp/ar7.patch
[19:13] <VinceLe> I may be able to try forward port too...
[19:13] <nbd> not without a serial console :)
[19:13] <VinceLe> thank you, I'll have a look
[19:14] <VinceLe> and read that code
[19:14] <VinceLe> I'm experiencing with git, so that will be good material to put in that beast
[19:15] <VinceLe> got it, starting to read
[19:15] <nbd> if you really want to start with kernel hacking, i can give you some detailed info on what we have, when you get your serial console
[19:16] <VinceLe> OK
[19:17] <VinceLe> I already have a question :)
[19:17] <nbd> ok :)
[19:17] <VinceLe> Does some models have yamon as bootloader ?
[19:17] <nbd> i've never seen one that uses yamon
[19:17] <nbd> mostly adam2, which emulates part of the yamon api
[19:18] <VinceLe> the first lines of the patch are for yamon-passed boot params
[19:18] <VinceLe> Ah OK
[19:18] <VinceLe> good to know
[19:18] <nbd> some devices also use pspboot
[19:18] <nbd> if i recall correctly, it's also partially compatible
[19:18] <VinceLe> Yes I think I have one of them
[19:18] <nbd> adam2 is easier, because it can netboot the kernels
[19:19] <nbd> having to reflash for every test is annoying
[19:19] <VinceLe> I have a DG834G which I'll hack, and a WAG354G that I'll keep functional until the DG+openwrt work
[19:19] <nbd> on 2.4 the wag354g had some extra problems
[19:20] <nbd> so yes, it's better to start off with the dg834g
[19:20] <nbd> you should flash it with the linux 2.4 port once, though
[19:20] <nbd> since the boot loader has a crc check
[19:20] <nbd> and our ar7 port changes a few bytes in the loader to disable that check
[19:20] <nbd> (automatically)
[19:20] <VinceLe> yes, I already prepared the updated adam2
[19:20] <nbd> ah, ok
[19:20] <nbd> great
[19:21] <nbd> the most important task after forward-porting the kernel is to finish the ethernet driver
[19:21] <nbd> i've just added some basic hw init and i wrote some code to set up the dma descriptor rings
[19:21] <VinceLe> You mean to flash the entire MTD overwriting adam2 partition in one go ?
[19:21] <nbd> huh?
[19:22] <VinceLe> I have just modified the copy of mtd2
[19:22] <nbd> flash an openwrt image over the web interface instead
[19:22] <VinceLe> and would flash that alone
[19:22] <nbd> because it doesn't overwrite the boot loader
[19:22] <nbd> it just patches 4 bytes
[19:22] <nbd> that has less risk attached
[19:23] <VinceLe> Yes, I have done that manually on the backup copy I made
[19:23] <VinceLe> and checked the resulting md5sum
[19:23] <nbd> so you have changed the boot loader on the flash already?
[19:23] <VinceLe> but if the built image already has that, ~i'll use it
[19:24] <VinceLe> no, just prepared the mtd2 image to be flashed when I got the serial
[19:24] <nbd> the image just provides a safer way of doing it (and it does so automatically)
[19:25] <VinceLe> OK, but You only flash adam2 once, after that you only flash kernel+fs, right ?
[19:25] <nbd> well, normally it should work like this:
[19:25] <nbd> you flash a complete image with openwrt over the web interface
[19:25] <nbd> the device writes the kernel and fs to the flash
[19:26] <nbd> when openwrt boots up, it checks the md5sum of the boot loader
[19:26] <nbd> if it matches the original one, it patches 4 bytes and then goes on booting
[19:27] <VinceLe> OK, but I thought that an unpatched adam2 would not boot the new image because it does not have the required magic thing somewhere...
[19:28] <VinceLe> or did you reveng that magic thing ?
[19:28] <VinceLe> and add it to dg834 images ?
[19:30] <nbd> the image that openwrt generates has a valid crc
[19:30] <nbd> that's why it boots
[19:30] <VinceLe> OK that explains all
[19:40] <{Nico}> nbd: pong
[19:41] <nbd> {Nico}: do you remember which ipkg version the busybox patch is based on?
[19:41] <{Nico}> nbd: wait a min.
[19:42] <{Nico}> 0.99.162
[19:43] <nbd> thanks
[19:43] <nbd> i think it's annoying that versioned depends are still broken
[19:46] <{Nico}> trying to understand ipkg source code is a real pain
[19:47] <{Nico}> maybe we should talk about that ipkg-ng again
[19:48] <{Nico}> bbl
[19:52] <florian> re
[20:08] <florian> nbd: can you post your latest bcm963xx fixes ?
[20:59] <nbd> florian_: i'll make a patch for you
[21:08] <nbd> florian_: ok. all my stuff is in svn now
[21:15] <florian_> thank you !
[22:15] <florian_> re
[22:19] <florian_91_44> looks like we are going to start the meeting ?
[22:20] <mbm> sure
[22:22] <nbd> mbm: topics for today?
[22:23] <mbm> no real agenda this time, I just wanted to catch up
[22:23] <mbm> ng is looking pretty good on the broadcom after the patches made earlier
[22:24] <mbm> but it still lacks a few basic things like diag (which is preventing failsafe) and minifo
[22:24] <florian_91_44> ok, so I might add something
[22:24] <groz> i'm only partially here for about 15 more minutes, then i'll be 'here' for a bit
[22:24] <florian_91_44> I have starting compiling the wiki into what we could later call an openwrt book
[22:25] <florian_91_44> what I would like to cover is : porting a new arch, porting packages, adding new packages, configuring and using whiterussian and buildroot-ng, debugging with openwrt (just general concerns)
[22:26] <mbm> ok, I do have a few publishing connections
[22:26] <Kaloz> buildroot-ng as a name will be gones soon probably :)
[22:26] <florian_91_44> well, this could be good to publish this kind of book in order to clarify things
[22:26] <nbd> yeah
[22:26] <mbm> Kaloz: right that's what I was getting at
[22:26] <nbd> the main missing thing is the image builder
[22:27] <florian_91_44> also, I think that a brief openwrt history : sveasoft ... would be good
[22:27] <nbd> but i think we should do the move even before that one's ready
[22:27] <florian_91_44> we can discuss this thing later
[22:27] <nbd> since current trunk/ is pretty much useless now
[22:27] <florian_91_44> well, the main task that remains is converting kernel modules to the new layout
[22:27] <nbd> we should probably svn mv trunk tags/kamikaze-oldl svn mv branches/buildroot-ng trunk;
[22:27] <nbd> s/oldl/old;/
[22:28] <florian_91_44> sounds good
[22:29] <florian_91_44> Kaloz, nbd, mbm what do you think about an official book ?
[22:30] <Kaloz> no reason imho
[22:30] <Kaloz> i mena, no reason to keep a useless copy of the old trunk
[22:30] <mbm> somewhat concerned about how up to date the book could be given that we're constantly changing things
[22:31] <nbd> Kaloz: svn mv is better than svn rm
[22:31] <Kaloz> nbd: i mean overwrite the trunk stuff and svn commit it :p
[22:32] <nbd> overwriting is more work, i've had some trouble with it before
[22:32] <nbd> svn is weird there
[22:32] <mbm> just do a mv
[22:32] <florian_91_44> mbm: that's true, that's also why we need at least not to change many things as we have done during the past few months, at least concerning package developpment (that mostly interests new users), and the way to add a new target I think
[22:33] <{Nico}> we should keep old trunk somewhere until all ports to -ng are done
[22:33] <nbd> florian_91_44: it's our development version. promising not to change things is a bad idea at this point
[22:33] <florian_91_44> nbd: this also interests people
[22:33] <nbd> florian_91_44: i don't expect that many changes
[22:34] <florian_91_44> nbd: you have seen like me that during the past weeks many people spoke about -ng in #openwrt
[22:34] <nbd> florian_91_44: and i do believe that the format will stay compatible with our changes
[22:34] <florian_91_44> nbd: then it's ok
[22:34] <nbd> florian_91_44: but we shouldn't freeze the format yet
[22:34] <florian_91_44> sure, this would refrain us from evolving
[22:34] <nbd> exactly
[22:35] <Kaloz> well, when br-ng hits whiterussian, you can document that
[22:35] <nbd> that's one of the main advantages of the new format, it's so easy to extend without breaking compatibility
[22:35] <{Nico}> florian_91_44: the book should focus on embedded development and wireless and present openwrt with buildroot-ng as the tool of choice
[22:35] <Kaloz> Kamikaze will keep changing for some time
[22:35] <nbd> i don't think we're ready to do a book just yet
[22:35] <florian_91_44> {Nico}: that's good
[22:35] <nbd> maybe for 1.0
[22:35] <florian_91_44> ok
[22:36] <florian_91_44> we can still start writing parts that are not config format dependent or something like that
[22:37] <nbd> so... rc6?
[22:38] <florian_91_44> :)
[22:38] <mbm> as usual nothing has been done on whiterussian lately
[22:38] <nbd> a few things have been done
[22:38] <nbd> and i'm almost done with umts support
[22:38] <florian_91_44> yes there was some
[22:39] <malbon> should I setup an autobuilder for whiterussian?
[22:39] <mbm> ah, yep .. must have missed the commit messages
[22:40] <nbd> let's talk about webif plans
[22:40] <mbm> speaking of which, where's db90h
[22:40] <nbd> db90h: ping
[22:40] <nbd> :)
[22:41] <db90h> ;)
[22:41] <db90h> i hope to complete much more work on the webif, and i hope that much of it will be directly usable in RC6, if you guys so choose
[22:41] <mbm> as I said at the last meeting, my main concern was removing the broken bits of webif like the very confusing firewall page, and adding the various nvram values
[22:42] <nbd> the firewall stuff should be rewritten using buildroot-ng style config files
[22:42] <mbm> would be nice if the firewall page was replaced by something that works but that isn't high on my todo list
[22:42] <groz> i have a suggestion if folks are re-writing webif or parts thereof
[22:42] <nbd> and db90h merged some dhcp config stuff in his tree, which i believe should also be converted to a buildroot-ng style config
[22:42] <db90h> yes,.. the firewall, dnsmasq, and qos pages..
[22:42] <groz> if it's 'write it out' functions are encapsulated, then, they can be overridden with new ones, that spew forth the new config formats used in -ng
[22:42] <db90h> any others you can think of off hand?
[22:43] <groz> then all of the if code can be re-used
[22:43] <mbm> db90h: there's also a number of nvram settings which right now can only be set manually at the commandline, tons of them for wl .. even the ones we do show aren't grouped in any useful way
[22:43] <db90h> i'd like to have pages for all common packages, until ng where all packages supplying a compatible config file will be supported by the new system
[22:43] <nbd> mbm: i also gave db90h a snapshot of some update code for buildroot-ng config files: http://downloads.openwrt.org/people/nbd/tmp/config-stuff.tar.gz
[22:43] <mbm> :)
[22:43] <nbd> mbm: the parser is already included in /etc/functions.sh
[22:44] <db90h> i like the ideal of not mandating any new nvram variables, unless absolutely necessary (which seems unlikely)
[22:45] <nbd> we did add a few variables occasionally, but only where it made sense
[22:45] <mbm> has anyone given any thought to webif on ng? are we still going to use ash and awk or do we write it in c and have shared object plugins?
[22:46] <nbd> i was thinking about a mix of both, when we're actually rewriting it:
[22:46] <nbd> have a template engine in c that transforms an abstract syntax for defining forms into html
[22:46] <nbd> and defining shell functions in the same file for interacting with the config stuff
[22:46] <nbd> so we don't have to code everything in c
[22:47] <{Nico}> nbd: you mean extend haserl or drop it?
[22:47] <db90h> yes, that sounds good for the NG webif
[22:47] <nbd> drop it, the haserl code is ugly
[22:47] <db90h> speaking of which... the life of the current webif system.. is planned to extend to what? release 0.9?
[22:48] <nbd> when i did the translation wrapper, i first wanted to build it into haserl
[22:48] <nbd> but i found that the code was so messy that i gave it up shortly after
[22:48] <mbm> db90h: oh, if you're looking for new features for webif, something I had planned on doing was a vlan config page .. would just be a very simple table like http://downloads.openwrt.org/people/mbm/vlan.html showing a matrix of the ports and the vlans they're assigned to
[22:50] <Exiles> hmmm
[22:50] <db90h> it seems one of the unfortunate things is that all the work on the current webif system will be deprecated and incompatible with the new system, however i do not think that this should prevent work on the current webif system, because as you guys know, people use releases even after they've been deprecated for years
[22:50] <nbd> we will keep the old one around for a while, i think. i don't know when we're actually going to start hacking on a new one
[22:50] <mbm> ... let's not start another flamewar ?
[22:51] <mbm> apart from available time, nothing is stopping anyone from working on webif
[22:52] <db90h> i was considering rollover help.. is this something that you guys are opposed to for any reason?
[22:52] <nbd> no
[22:52] <mbm> if you can think of a good way to share code between whiterussian and ng I'd love to hear it
[22:53] <nbd> mbm: if we make use of the -ng config format for the more complex pages, then we can keep most of the code when we port it over to -ng
[22:53] <nbd> mbm: e.g. firewall, dhcp, etc.
[22:53] <mbm> sounds good
[22:53] <nbd> wifi config, network config will have to be redone anyway
[22:57] <florian_91_44> what about pending ticjets ?
[22:57] <florian_91_44> tickets sorry
[22:57] Action: nbd looks
[22:58] <nbd> is anybody actually interested in the gdb stuff?
[22:58] <nbd> or can we leave that for 1.0/-ng
[22:58] <Exiles> gdb?
[22:58] <db90h> mbm: ah, i like the vlan page..
[22:58] <nbd> Exiles: debugger
[22:59] <florian_91_44> gdb sounds doable for 1.0
[22:59] <mbm> db90h: any port which lists multiple vlans should be considered a tagged port
[22:59] <nbd> but you can have a port untagged in one vlan and tagged in another, right?
[23:00] <mbm> right, the tagging is just triggered when there are multiple vlans associated with a single port -- tagging is automatically turned on for that port
[23:02] <florian_91_44> there is a lof of kernel and motorola related bugs, how do we proceed ? do we ask a user to do intensive tests ?
[23:02] <db90h> ok, i will start on the vlan page soon
[23:02] <nbd> mbm: but how do you control where the port is untagged and where it's tagged if it can be both at the same time?
[23:02] <nbd> florian_91_44: yeah, we definitely need someone with access to the hardware
[23:03] <mbm> nbd: a vlan can be untaged on one port and tagged on another
[23:03] <db90h> mbm: is there any work you've already done, or did I understand correctly that this is just a 'look and feel' template?
[23:03] <mbm> db90h: just a mockup; I started playing around with ideas for a generic network interface page alsp
[23:04] <nbd> mbm: yeah, that's what i said, but how do you integrate that in the web interface?
[23:05] <mbm> nbd: I really don't see what's so complicated, the example shows vlan0ports="1 2 3 4 5t" vlan1ports=0 5t" .. 5 is listed in both vlans so it automatically gets the "t"
[23:05] <florian_91_44> shall we stick to awk ?
[23:06] <florian_91_44> and should we open webif developpment to users ?
[23:07] <nbd> mbm: but you could have something like this: vlan0ports="1 2 3 4 5t" vlan2ports="1t 2t 3t 4t 5t"
[23:07] <db90h> a three way checkbox could be used, but that seems more confusing than anything
[23:07] <nbd> mbm: ports 1-4 untagged in vlan0, tagged in vlan2
[23:07] <mbm> nbd: it really wouldn't make sense to do that though
[23:08] <nbd> mbm: it would, if you leave out a few ports and run a different subnet on the same cable
[23:08] <nbd> mbm: which not all ports have access to
[23:08] <mbm> I mean either the equipment connected to teh ports uses vlans or it doesn't
[23:09] <Exiles> more and more equpiment is able to though
[23:09] <nbd> mbm: it might be connected to a switch with a few nodes that can't do vlan and with a few more that can
[23:09] <Exiles> I have a 24 port switch that does vlans
[23:09] <mbm> nbd: if you have any equipment that doesn't do vlan tagging it should be connected through an untagged port, you shouldn't mix tagging on a port
[23:10] <nbd> i still think that it could be useful for some people
[23:10] <nbd> but maybe we can just force them to not use webif for that
[23:11] <db90h> yes, if it's a small minority that would use it, then i think it would save confusion for the majority to leave it off..
[23:12] <mbm> well, along the same lines, it's also possible for me to buy a dumb switched hub, connect my lan and my cable modem through it and then run interface aliasing on one of my lan computers to make it actually use the cable modem .. works? yes. good ide? not really
[23:13] <db90h> i'll write up a basic vlan page and if a need to allow untag/tagged port over-rides arises and someone has an idea to do it gracefully, then we can add it
[23:13] <nbd> makes sense
[23:14] <mbm> the problem with missing tagged and untagged on a single port is that if the device doesn't support vlans it still sees the vlan tag and may even blindly forward the vlan tagged packet
[23:14] <mbm> er mixing
[23:16] <florian_91_44> do you think webif is that much important for a 1.0 release ? I ask this question really naively
[23:17] <nbd> i think lots of people would complain if it was missing
[23:17] <{Nico}> florian_91_44: we already have it, it just needs some fixing / enhancements
[23:17] <mbm> right, which is why I didn't just rip it out and mark a release
[23:17] <Exiles> I feel if done right, it will make openwrt end user capable, instead of being moreso for people with highend needs
[23:18] <florian_91_44> I don't think about suppressing it, but do we need full-featured webif that would ease a lof of tasks or still let the user configure most things by shell
[23:18] <db90h> btw, i extended the numbering gap between webif pages to allow for WR packages to install their own pages and be able to insert beween page X and page Y.. it's not perfect by any means.. is there a better solution anyone can think of?
[23:19] <Exiles> I could do so in perl, but not sure with webif
[23:19] <db90h> also, by extending the gap, any third-party pages that already have low numbers will be advanced to the beginning.. but I thought of if I find a page number <10 I'll make it go to the end
[23:19] <{Nico}> db90h: do you already have support for all wl variables?
[23:20] <db90h> no, not yet.. i added gmode, txpwr, ap_isolate
[23:20] <db90h> i plan to support them all before its over
[23:21] <mbm> don't think the order that the pages appear on the menu is important
[23:22] <groz> it's important if you get to the stage of being worried about cosmetics
[23:22] <groz> helps control logical flows
[23:23] <mbm> as longas it's consistant enough that the new page always shows up in the amse location, it really doesn't matter what that location is
[23:23] <db90h> yea, it's not mission critical by any means.. so i suppose i'll just stick with this inperfect solution of leaving a gap between default pages for now, it will be good enough
[23:23] <mbm> if it starts moving around randomly every time I change pages I might get annoyed
[23:23] <db90h> hehe
[23:24] <florian_91_44> so webif seems to be the most significant module to improve before a 1.0 release ?
[23:26] <nbd> yes
[23:26] <nbd> and we also need to fix up some stuff for the wl-500g premium
[23:26] <mbm> yes, that's what's holding back the 0.9 release (1.0 is ng)
[23:26] <florian_91_44> ok,could not we make a rc6 including only hardware bugfixes
[23:27] <florian_91_44> then a 0.9 with the new webif ?
[23:27] <mbm> we should probably go through and update all the whiterussian packages to their latest version so the next whiterussian release doesn't use obsolete versions
[23:27] <mbm> florian_91_44: well, not new as in rewritten, but new as in fixed (if it gets rewritten, great)
[23:27] <nbd> mbm: why not remove lots of packages like asterisk and build them with the sdk from the -ng package sources instead?
[23:28] <florian_91_44> I think it's a good idea, most update fixes problems for packages
[23:28] <db90h> what about the old squashfs in WR (and other old things)? you guys gonna update it/them in RC6?
[23:28] <mbm> db90h: thats what I mean, all of that really should be updated
[23:29] <db90h> sounds good.. btw, squashfs 3.1 was released last week for anyone who didn't notice.. i imagine the lzma patches might need some adjustment, but that should be no big deal
[23:30] <florian_91_44> lzma itself could be upgraded as well
[23:30] <nbd> i think we should keep the old version where updating doesn't give us any real benefits
[23:30] <nbd> iirc with the lzma stuff it got bigger after updating
[23:31] <florian_91_44> possibly
[23:31] <Kaloz> db90h: no reason to upgrade as far as i saw
[23:32] <db90h> i agree, no huge reason to upgrade..
[23:32] <Kaloz> :P
[23:32] <db90h> ;)
[23:32] <florian_91_44> what about devices ? do we stick to bcm947xx/53xx ?
[23:32] <nbd> sure
[23:32] <Kaloz> basically backward compatibility stuff were added, what we rip out anyways
[23:32] <Kaloz> :)
[23:32] <Kaloz> florian_91_44: whiterussian won't support other platforms. that's kamikaze's privilege
[23:33] <db90h> you guys might consider turning off SIZE mode for JFFS2 at runtime.. as this compresses each block some 5 times (or so) to try and find the best.. and I'd say 98% or more of the time it ends up using ZLIB anyway
[23:33] <nbd> db90h: iirc at some point i already reduced the number of algorithms
[23:33] <db90h> oh, ok
[23:33] <nbd> db90h: and sometimes it gets distributed quite even between lzo and zlib
[23:34] <nbd> don't know if it was lzo
[23:34] <nbd> but something with lz* for sure :)
[23:34] <db90h> oh, i didn't know that.. I always meant to check and see the distribution of the algorithms used
[23:34] <nbd> and i don't think filesystem performance is that important
[23:34] <nbd> size reduction however is
[23:35] <db90h> if I ever get around to doing a survey on the algorithms, I'll let you know if there are any that remain which never get used
[23:35] <nbd> ok
[23:35] <florian_91_44> who does what ?
[23:36] <nbd> ?
[23:36] <florian_91_44> I mean to complete 0.9 how do we proceed ?
[23:37] <nbd> everybody does what he wants to do? :)
[23:37] <groz> i'll be back shortly foks, gotta step away for a few minutes
[23:37] <florian_91_44> I will be very busy this week, but after it will be ok to do massive testing and so on
[23:38] <florian_91_44> I also insist on having a proper documentation, even for 0.9
[23:39] <florian_91_44> if it does not cover developpment it should cover configuration/usage
[23:39] <florian_91_44> the wiki is a real mess we already mentioned it
[23:39] <nbd> yeah, we really could use some decent documentation
[23:40] <florian_91_44> the job is not that hard, compile, update the infos, write some examples ...
[23:40] <florian_91_44> this is a thing I would like to do
[23:40] <nbd> great
[23:42] <{Nico}> if we can agree on some toc, writing will come along
[23:44] <florian_91_44> let's agree ;) ?
[23:45] <nbd> agreed :)
[23:45] <mbm> damn, wireless network crashed 10 min ago
[23:45] <mbm> (re)
[23:45] <florian_91_44> mbm: fscking openwrt box ?
[23:45] <florian_91_44> you should seriously think about running dd-wrt instead
[23:46] <mbm> florian_91_44: no, fscking ubuntu box, now it won't even let me select that it's a wpa network
[23:46] <mbm> got sick of it and just plugged in a wire
[23:47] <florian_91_44> my ibook sometimes unload bcm43xx when it wants
[23:47] Action: Kaloz configures tha stuff by hand - no problems at all :)
[23:47] <Kaloz> brb
[23:48] <mbm> yeah, it kicked my bcm43xx card offline a few times
[23:48] <mbm> grabbed a different card and couldn't get it to connect via wpa
[23:48] Action: mbm really needs to buy a ew network card
[23:50] <Bartman007> mbm: does Ubuntu allow WPA configuration out of the box?
[23:50] <mbm> nope, requires some very annoying gnome applet
[23:51] <mbm> after that it usually just works
[23:51] <mbm> except for some drivers
[23:51] <mbm> the bcm43xx in ubuntu is pretty bad
[23:52] <mbm> the gnome app refuses to find my network most of the time since it's ssid hidden
[23:52] <mbm> so I run an iwconfig command to force the connection
[23:52] <mbm> it gets connected, authed and about 10 packets go through
[23:52] <mbm> then I need to run iwconfig again and force the connection
[23:53] <Bartman007> yeah, I haven't figured out a way to make linux autodetect hidden networks (with wpa_supplicant at least)
[23:53] <mbm> after that it stays up for hours at a time
[23:53] <mbm> something weird though when it gets authed and sends a few packets and then suddenly stopps until forced to reconnect
[23:54] <Bartman007> at first I had a similar problem, it would connect, and auth, but dhcp would timeout.
[23:54] <Bartman007> (gentoo here)
[23:54] <florian_91_44> we need to find someone with a motorola device
[23:55] <Bartman007> florian_91_44: a motorola bcrm?
[23:55] <nbd> yep
[23:55] <nbd> actually preferably several motorolas
[23:55] <Bartman007> iirc, TheCompWiz has one
[23:55] <nbd> because there are several different ones
[23:55] <Bartman007> I think he has a WR850G
[23:56] <florian_91_44> ok,that would be great, there are lot of pending bugs related to motorola devices
[23:56] <Bartman007> damnit, firefox lost sound agin.
[23:57] <{Nico}> florian_91_44, nbd, Kaloz: anyone of you knows where we can find one in EU?
[23:57] <nbd> no
[23:57] <florian_91_44> {Nico}: I never saw one
[23:58] <florian_91_44> {Nico}: etienne will have its ar525w soon
[00:00] --- Mon Aug 28 2006