OpenWrt

[00:13] <groz> dumb question mbm, make sure i got this order figured right, first the patches in generic-2.x get applied, then the ones in the specific x86-2.x directory correct ?
[00:14] <groz> when patching the kernel up
[00:16] <[mbm]> [ -d ../generic-$(KERNEL)/patches ] && $(PATCH) $(LINUX_DIR) ../generic-$(KERNEL)/patches $(MAKE_TRACE)
[00:16] <[mbm]> [ -d ./patches ] && $(PATCH) $(LINUX_DIR) ./patches $(MAKE_TRACE)
[00:16] <[mbm]> (target/linux/*/Makefile)
[00:16] <[mbm]> .. in short, yes.
[00:16] <groz> rite, ok, i think i've found where the 2.4 modules are getting bashed
[00:16] <groz> i'll know in a couple minutes, but it's one of the patches in generic
[00:17] <groz> changing the makefile
[00:18] <groz> question becomes, should i generate a reversion and put it in the x86-2.4 or remove the culprit from generic ?
[00:19] <groz> then it'll likely have to go into a few of the arch specific ones
[00:20] <[mbm]> what's the problem with the patch in generic?
[00:20] <groz> 209-build_fixes
[00:20] <[mbm]> specifically?
[00:20] <groz> replaces a cp with an objcopy
[00:21] <groz> and it trashes the x86 modules
[00:21] <groz> hang on, i've just verified it
[00:21] <groz> i pulled that patch out
[00:21] <groz> make clean, make
[00:21] <groz> and i've got valid modules now
[00:21] <groz> file says they are elf files now, before it was calling them all sorts of things
[00:21] <groz> even called ip_ip.o a db3 database file
[00:23] <[mbm]> doesn't matter
[00:23] <[mbm]> important thing is what it said when you tried to load the modules
[00:23] <groz> when i tried to load them, it said not an elf file
[00:23] <groz> and puked up an error
[00:23] <[mbm]> hmm
[00:23] <groz> I'm just setting up to boot this one now, and confirm they work ok
[00:24] <groz> but it's the block at line 37 of that patch
[00:24] <groz> that does it
[00:25] <[mbm]> just looking at that now
[00:25] <[mbm]> there's nothing wrong with that
[00:26] <[mbm]> my guess is that somehow the wrong version of objcopy got called
[00:26] <[mbm]> you might want to log the compile and verify that
[00:27] <groz> first, i'm going to finish building a netboot image with this result
[00:27] <groz> and make sure it does actually work on the target
[00:27] <[mbm]> that blog is a pretty minor optimization
[00:27] <[mbm]> er block
[00:28] <[mbm]> my guess is that my changes to $(TARGET_CC) last week screwed up some of that
[00:29] <groz> it could be, but, i'll validate firs that this is useable
[00:29] <groz> just fixing up my 'create a netboot image' to use 2.4 with an initrd
[00:29] <[mbm]> k; I'm still playing catch22 with the kernel.mk
[00:29] <groz> and i gotta recompile the kernel, and actually compile in a file system for my initrd
[00:29] <groz> oops
[00:30] <groz> i'm just making an initrd outa the ext2 image
[00:30] <groz> but ext2 isnot compiled in
[00:33] <groz> ok, bingo, the 2.4 boot worked this time, and, modules loaded
[00:50] <groz> are you ending up fissuing at all with image.mk in that process ?
[00:51] <groz> if so, just a small heads up, i have a change coming shortly that makes a small change in there
[00:51] <groz> i moved the ext block outside the if ramfs
[00:51] <groz> so you can create a ramfs kernel, and an ext2 file system
[00:51] <groz> then use the ext2 as the basis of a bootable image
[00:51] <groz> which contains the kernel+initramfs
[01:15] <groz> ok, partial success
[01:15] <groz> via board just bootted 2.4 from the usb stick, it's up, and fully functional
[01:16] <groz> i have not yet pivoted back onto the stick
[01:17] Action: [mbm] is playing with kernel.mk and kernel-build.mk
[01:17] <groz> root@OpenWrt:/# mount
[01:17] <groz> none on /old/dev type devfs (rw)
[01:17] <groz> none on /old/proc type proc (rw)
[01:17] <groz> none on /old/tmp type tmpfs (rw,nosuid,nodev)
[01:17] <groz> none on /old/dev/pts type devpts (rw)
[01:17] <groz> none on /old/proc/bus/usb type usbfs (rw)
[01:17] <groz> none on /proc type proc (rw)
[01:17] <groz> root@OpenWrt:/#
[01:17] <[mbm]> :)
[01:17] <groz> woohoo
[01:17] <groz> success, with a 2.4 kernel
[01:17] <[mbm]> now use the firstboot pivot function
[01:18] <groz> just plain pivot from the command line for that one
[01:18] <groz> to see if it works
[01:18] <groz> i'm not sure i've even got firstboot on it
[01:18] <[mbm]> *&^*&^@# .. this is annoying
[01:18] <groz> i dont think that comes along in an x86 build, but, i can fix that trivially
[01:18] <groz> ok, now we know it all works, back to that patch problem
[01:18] <groz> what you want me to do, is put the patch back in
[01:19] <groz> then log the build
[01:19] <[mbm]> look at the target/linux/*/Makefiles
[01:19] <[mbm]> the two relevent lines go like this -
[01:19] <[mbm]> LINUX_VERSION:=2.4.32
[01:19] <[mbm]> include $(INCLUDE_DIR)/kernel.mk
[01:20] <[mbm]> now, picture $(INCLUDE_DIR)/kernel.mk including a .kernel.mk with $(LINUX_VERSION)
[01:20] <groz> yep
[01:20] <[mbm]> it ends up clobbering the makefile to the point that I can't write a valid LINUX_VERSION even if I wanted to
[01:21] <[mbm]> I'll always end up with the one in .kernel.mk
[01:21] <groz> ok
[01:21] <groz> now
[01:21] <groz> in the initial one
[01:21] <groz> THIS_VERSION=$LINUX_VERSION
[01:21] <groz> now in the included on
[01:22] <groz> if $THIS_VERSION != $LINUX_VERSION puke
[01:22] <[mbm]> yeah, I'm playing with all that stuff now
[01:22] <[mbm]> but it's just nasty
[01:22] <groz> well here's a thought
[01:22] <groz> for now
[01:22] <groz> if you change from one kernel to another
[01:22] <groz> personally, i dont think it's out of line
[01:22] <groz> to enforce some cleaning at that point
[01:23] <[mbm]> doesn't suit my rapid coding style ;)
[01:23] <groz> do it quick, then do it again, and again
[01:23] <groz> take your time, do it right, it's done :)
[01:28] <groz> ok, make clean, put the patch back, building and grabbing a copy of the spew on the way
[01:28] <groz> weill go see why that obj copy breaks
[02:31] <groz> mbm, you still here ?
[02:35] <CIA-17> mbm * r4570 /branches/buildroot-ng/openwrt/include/ (kernel-build.mk kernel.mk): fix issues if kernel config is changed after the compile has started
[02:35] <[mbm]> yep.
[02:35] Action: [mbm] scrolls up
[02:35] <groz> i386-linux-uclibc-objcopy -O binary -R .note -R .comment -S -R __ksymtab -R .comment -R .note -x \
[02:35] <groz> `i386-linux-uclibc-nm $f | cut -f3- -d' ' | sed -n \
[02:35] <groz> -e 's/__module_parm_\(.*\)/-K \1/p' \
[02:35] <groz> -e 's/__ks..tab_\(.*\)/-K \1/p'` \
[02:36] <groz> it's that translation, now, to find where the -S is actually coming from
[02:36] <groz> i believe it's the -S that's doing it
[02:36] <[mbm]> right
[02:36] <groz> and it's NOT from the initial patch i pointed out
[02:36] <groz> and i am on the hunt for just where its coming from
[02:37] <[mbm]> heh
[02:39] <groz> basically somewhere in all this stuff, the objcopy stuff is being stuffed with everything up to the -S
[02:39] <[mbm]> right
[02:39] <groz> prior to reaching the spot in question
[02:40] <[mbm]> which will nuke a few extra sections and cause some grief
[02:40] <groz> uh huh
[02:41] <[mbm]> the places it could have come from - rules.mk, include/kernel-build.mk or the actual kernel makefile
[02:42] <groz> Rules.mk in the kernel dir too
[02:42] <groz> but it's not there
[02:42] <groz> i checked that already
[02:42] <[mbm]> right, my guess is that it came from the kernel
[02:42] <groz> actually, Rules.make
[02:42] <[mbm]> foud it?
[02:42] <groz> not yet
[02:43] <groz> hmmm it's in a bunch of the arches
[02:43] <groz> but not the arch i'm building
[02:43] <groz> but it is in x86-64
[02:43] <groz> oh wait
[02:43] <groz> there it is
[02:43] <groz> in arch/i386/Makefile
[02:44] <[mbm]> can you pastebin that part?
[02:44] <groz> hang on
[02:44] <[mbm]> guessing that you should be able to handle things by just setting $(OBJCOPY) on the make commandline in kernel-build.mk
[02:44] <[mbm]> saves you from having to patch the kernel
[02:45] <groz> pastebin awful slow
[02:45] <groz> http://pastebin.ca/133627
[02:46] <[mbm]> there's a few pastebins .. one of them will work ;)
[02:47] <groz> this one worked
[02:47] <groz> I know the -S is bad
[02:47] <groz> but
[02:47] <groz> what about the -O binary ?
[02:48] <[mbm]> that's what caused the 'this is not an elf file' error
[02:48] <groz> i thought that was the -S caused that
[02:48] <[mbm]> whoever wrote that line in the makefile assumed that objcopy would only be used for generating the vmlinuz
[02:48] <[mbm]> no, the -S is for removing massive amounts of elf sections
[02:49] <[mbm]> which will (likely) also cause problems
[02:51] <groz> well, the generic mips patch already changes the arch in the makefile to mips
[02:51] <groz> which is pain if you are playing with params a lot,a nd keep forgetting ARCH=i386
[02:51] <groz> i think i'll just put a small patch in that changes those 2 things
[02:54] <[mbm]> huh? there's a spot in kernel-build.mk where it changes the ARCH but I don't remember any of the generic patches changing it
[02:54] <groz> 000-linux_mips.patch is in the generic patches
[02:55] <groz> and that patches the makefile in the kernel dir
[02:55] <groz> reember i said a few days ago, didn't think that one belongs in generic/patches
[02:55] <[mbm]> *mumble* that patch shouldn't be there
[02:55] <groz> and you said it wouldn't hurt
[02:56] <[mbm]> well, I mean the ARCH= part
[02:56] <groz> which is why i was suggesting the 'generic' then 'arch' then 'board'
[02:56] <[mbm]> the rest of it is contained to arch/mips
[02:56] <groz> right
[02:56] <groz> no biggie
[02:56] <groz> we patch in so many things already
[02:56] <groz> one more little one is trivial
[02:56] <groz> and it's better to add one in the x86 than to go hacking in the ones already there
[02:56] <groz> unless we just remove that set of lines from the 000 patch
[02:57] <[mbm]> I'm just thinking of removing lines from 000
[02:57] <[mbm]> just tracking down who added them and why
[02:57] <groz> and actually, i'm guessing that's the one that adds it, haven't verified yet, doing that now
[02:59] <groz> yes it is
[02:59] <groz> at line 27940
[03:01] <[mbm]> that patch touches a ton of files
[03:02] <groz> yes
[03:02] <groz> so, rather than mess with that one
[03:02] <groz> cuz it's huge
[03:02] <groz> i'll put in a tiny one that puts the arch line back in the x86 trees
[03:02] <[mbm]> nope
[03:02] <groz> or, since this is being hardwired
[03:02] <[mbm]> I'll fix the 000 patch
[03:02] <groz> ok
[03:03] <[mbm]> the 00 patch touches 90 files outsides the mips stuff
[03:03] <[mbm]> looking for other sources of conflicts
[03:04] <[mbm]> looks like tons of bugfixes
[03:05] <[mbm]> my guess is that someone generated that patch by diffing the linux-mips tree with the linux tree
[03:05] <[mbm]> which imho is a bad idea because it leaves you with a huge patch that mangles everything without telling you why
[03:06] <groz> likely then it actually removes a lot of fixes that were in the mainline tree
[03:07] <CIA-17> mbm * r4571 /branches/buildroot-ng/openwrt/target/linux/generic-2.4/patches/000-linux_mips.patch: a "generic" patch shouldn't be setting the ARCH to mips
[03:07] <[mbm]> certainly changes tons of things
[03:07] <[mbm]> not sure which is the more accurage code
[03:07] <[mbm]> er .. accurate
[03:12] <[mbm]> http://paste.uni.cc/9447 .. there's a list of files which have been modified outside the arch directories
[03:15] <groz> heh, so on some of those
[03:15] <groz> the question becomes
[03:15] <groz> who's right ?
[03:15] <[mbm]> yep
[03:15] <[mbm]> I prefer to stick to the stock kernel and only patch as needed
[03:16] <groz> well, i'm building a 2.4 right now
[03:16] <groz> with that patch removed
[03:16] <groz> and see where it ends up
[03:16] <[mbm]> but there's so many examples of non-x86 stuff being broken in the kernel
[03:16] <groz> exactly
[03:16] <[mbm]> bbiab
[03:16] <groz> but my thoughts are, i'm compiling for x86 for now
[03:16] <groz> so
[03:16] <groz> go with the flow
[03:16] <groz> ok, i'm gonna go get some dinner soon too
[07:38] <db90h> you guys are planning to use the old 43xx wireless driver in WR RC6, right?
[07:41] <db90h> always so responsive to my queries, the love i feel is without bounds
[07:41] <groz> possibly because nobody that knows the answer is anywhere near a computer right now
[07:42] <db90h> thank you
[07:44] <db90h> since the new driver has continued problems, i expect unless these issues are resolved by broadcom, the old one will be used
[07:44] <db90h> i'm considering building an end user firmware around openwrt, as someone needs to.. the new config system you guys are using makes it very easy and someone should begin this task
[07:44] <groz> I dont know what th eplans are, but, i'd guess the newer drivers wont go into the mainline stuff till they atually work correctly
[07:45] <db90h> (by config system i mean package config)
[07:45] <db90h> i'd like to develop an ncurses based configurator for the new package configuration format, then extend it to a web UI
[07:46] <groz> what kind of configurator do you mean ?
[07:46] <db90h> a tool to set the config options available for each installed package
[07:46] <db90h> the new format at least tries to standardize all package configuration..
[07:47] <db90h> of course, many more packages will need to start using the new config format, but I assume this will happen as time passes
[07:50] <db90h> i'm trying to find documentation on this config format, but perhaps it hasn't been written yet.. nbd has showed me samples. The complete-ness of the system I'm not sure of, but I have no problem working to complete it
[07:57] <db90h> one problem though is why build root to work with.. at the moment, what is preventing the total switch to buildroot-ng? the number of packages ported to it?
[07:57] <db90h> err what
[07:58] <groz> well the packages moved over is growing by leaps and bounds, but the system as a whole is not really 'soup' yet
[07:58] <groz> there are plenty of issues
[07:59] <db90h> ah, ic.. so then at the moment, were i to build an end user firmware, would you suggest working with the 'old' buildroot?
[07:59] <common> no
[07:59] <common> freewrt does that already
[08:00] <common> and i honestly doubt freewrt will make it
[08:00] <db90h> why no? besides the fact that someone else is..
[08:00] <common> porting to the new branch will take time
[08:00] <db90h> so will waiting for the new branch to come to fruition
[08:01] <common> and another point is, the more ppl work with br-ng, the faster it will work stable
[08:01] <groz> there's going to be some radical changes as ng catches on
[08:01] <groz> it's multi platform, and it's a great system for deploying limited run stuff out of
[08:01] <common> db90h: apart from some minor? issues (ipkg is broken= br-ng works really fine for me on xscale, i ported all the crap required myself
[08:01] <groz> i'm already close to having some of my stuff moved to x86 on top of ng
[08:02] <groz> and it's great
[08:02] <common> what really sucks is the communication here
[08:02] <groz> and once i've worked out a few more details, going onto other new hardware should be borderline trivial
[08:02] <common> *really*
[08:03] <common> if you are looking for packet maintainers, open a damn mailing list
[08:03] <db90h> hmm.. i'll have to think about it.. although an end user firmware obviously benefits from advancing the openwrt code, it side-tracks me to work on both tasks..
[08:04] <db90h> on other words, fixing ng issues as i see them prevents me from making rapid progress to my intended goal
[08:05] <db90h> i appreciate the info, it clarifies much to me
[08:06] <db90h> oh, and as far as freewrt, I'd like to think they would be an end user firmware, but the developers seem to not be particularly focused on such... it seems largely an operwrt twin with a build system that's been tweaked to suit the preferences of others (BSD people?)
[08:06] <common> no
[08:07] <common> according to their statement they want to support less devices but offer a better 'eXPerience'
[08:07] <db90h> i have been following their project fairly closely
[08:07] <db90h> yes, i read that in their statement.. in contrasts to their attitudes
[08:07] <db90h> in my opinion
[08:07] <common> i'd say nobody needs they crap they've done yet
[08:08] <groz> I would say this
[08:08] <groz> if indeed the goal is 'end user' experience
[08:08] <groz> then the 'right' way to go about it
[08:08] <groz> use image builder, to put the required packages into an image
[08:09] <common> compiling on bsd is nothing i'd ever ask for
[08:09] <groz> then start one more package, a configuration setup with an emphasis on 'look and feel'
[08:09] <groz> then commit it back too
[08:09] <groz> everybody benefits, and, you get the 'end user dist' you are looking for
[08:09] <db90h> yea groz, that is somewhat what i envisioned..
[08:09] <db90h> system configurators (as i call them) as packages
[08:09] <groz> end users only really see the user interface
[08:10] <groz> but it's the developers doing the package work, that are doing most of the heavy lifting
[08:10] <db90h> i have to say that i find web UI stuff quite tedious, coming from the perspective of a low-levle developer.. so while I like to say that those working on end user things are of less quality, i have to admit they do as much heavy lifting when it comes down to real world use
[08:11] <db90h> the attitude that those who work on making a system more easy for end users to use are of inferior skill and importance I held for many years, but now I am changing my opinion
[08:12] <db90h> it's simply two different areas to me, and each is equally important
[08:13] <common> would you say compiling on mirabelisbsd is important to you?
[08:13] <db90h> oh, that's my #1 requirement <sarcasm>
[08:14] <db90h> i don't think it's productive to demean the freewrt changes tho, they haven't had time to really get focused yet.. we'll see what they come up with
[08:14] <groz> i agree db, didn't mean it's not 'work', meant the heavy lifting of making the thing actually work as a router
[08:14] <groz> is done under the covers
[08:14] <groz> then a ui makes it 'easy'
[08:15] <groz> but until the 'under the covers' all works, ui not needed
[08:15] <db90h> true that
[08:15] <groz> the problem is, the folks that get it to that point
[08:15] <groz> find an ssh sessdion the preferred 'user interface'
[08:15] <groz> so, they never go beyond that
[08:16] <groz> and many cant comprehend why you would want to
[08:16] <db90h> yea.. also its annoying for the UI people to get all the credit from end users ;p.. i have almost had breakdowns in my past when i see some vb coder get the credit for invoking calls to a library i wrote to do all the actual work ;)
[08:16] <groz> been there, done that
[08:19] <db90h> my current rationale behind this endeavor is that I'm tried of all these end user firmwares being so grossly inadequate in comparison to openwrt.. i want to change this. I want to bring the stability, structure, cleanliness, and extensible attributes of openwrt to the masses..
[08:19] <groz> no good db
[08:19] <groz> the masses want 'closed and simple'
[08:19] <groz> give them to many options
[08:20] <groz> and they just get confused
[08:20] <groz> honestly, for most, the ideal router has one option
[08:20] <groz> on/off
[08:20] <db90h> true
[08:20] <groz> that's a philosophy on which a lot of my projects start
[08:20] <groz> any options other than on/off are to many for most uers
[08:20] <common> db90h: port imon from fli4l to openwrt
[08:21] <common> it got on/off
[08:21] <db90h> there are a large class of users in between the non-technical end users and the hard-core technical users tho.. perhaps this is who I'm really thinking of
[08:22] <common> important thing is proper docs, explain them what a netmask is if they want to know
[08:22] <common> wikipedia is a great source to link to
[08:28] <db90h> i'm still trying to find a place in all this.. i don't know where i stand even. I have done a lot of work trying to make DD-WRT more appealing to the technical crowd (i.e. Firmware Modification Kit), yet am totally dissastisfied with it's chaotic guts and can't stand to use it myself after running openwrt
[08:28] <db90h> i mean dis-satisified with dd-wrt
[08:29] <db90h> i discovered immediately it's QoS hasn't worked in months (u'd think someone might have noticed).. and any change to anything causes several redundant nvram commits (change to qos page == 5)
[08:30] <common> but the enduser sees "QoS" -> cool
[08:31] <db90h> and the build system is like a pile of spaghetti, some of the warnings on added code are nothing short of scary i.e. several "unknown escape sequence" in httpd I haven't looked at yet (ever a proper reason for an unknown escape sequence in C.. i.e. \4?) ... is it too much to ask for a web UI and reasonable clean guts?
[08:31] <db90h> i could spend years trying to clean up dd-wrt, but easier to start from scratch
[08:31] <db90h> common: yea, exactly.. how many poeple have been using it this whole time and never knew it didn't work?
[08:32] <db90h> there are clear iptable errors emitted in the serial output
[08:32] <common> what i miss on openwrt is a (personal) structure
[08:32] <common> you'll know yourself
[08:33] <common> you can write deadend monolgues in this channel
[08:33] <common> nobody cares
[08:33] <db90h> you mean a lack of social structure?
[08:33] <db90h> yea, it isn't a particularly welcoming feeling.. i know
[08:34] <groz> well, not all of us spend all day sitting at a puter waiting for somebody to yak on irc
[08:34] <groz> some of us only get here occaisionally
[08:34] <common> thats not the point
[08:34] <db90h> you should spend all day on irc groz, it makes for a very healthy psyche ;)
[08:35] <groz> i have 2 businesses to run db
[08:35] <db90h> i am being sarcastic
[08:35] <common> groz: where to ask for the broken ipkg on br-ng?
[08:35] <db90h> i need to find something better to do with my time ;p
[08:35] <groz> i just merged in the old one for now in my own thing, so i can work on the stuff that needs working
[08:35] <common> groz: whom to ask for the xscale patches i offer?
[08:36] <db90h> what would help is a signle person who was such an irc addict to go yak'ing away to anyone..
[08:36] <db90h> this would make people feel more welcomed and less rejected
[08:36] <common> db90h: mailing lists
[08:37] <common> post, and get a reply, maybe in 2 days, but get a damn reply
[08:37] <db90h> hehe
[08:38] <db90h> you seem somewhat upset about this common.. i personally have felt rejected from this community several times, perhaps justly
[08:38] <common> this DROP & REJECT attitude is nothing they can really affort
[08:38] <db90h> it helps to have someone acknowledge your work with some sense of urgency and excitement
[08:39] <common> as they waste potential ressources
[08:40] <db90h> yea, i totally agree.. i've spoken to numerous people who have been demotivated due to beratement, negativity, or lack of care or concern here and the forums
[08:41] <db90h> when i started on my v5 flashing technology, there wasn't an openwrt developer who was mildly supportive.. but now all v5 users can do something more with their routers than they could before, and i don't think of this as a bad thing
[08:41] <common> i remember
[08:42] <db90h> the GS v5 series has 16MB RAM enabled now, so it's particularly useful.. despite its small ROM size
[08:42] <groz> i dont view it as a bad thing, but, i dont have any v5. not intending to get any, so to me, it's interesting
[08:42] <groz> but, not something i'll have any chance to actually see in operation, or use
[08:43] <common> groz: you miss his point
[08:43] <db90h> it wasn't a lack of interest, they did respond to it.. all negatively and saying what a waste of time it was, etc..
[08:43] <db90h> tho i should note i have a large number of character defects, so i am not so politically correct or socially apt
[08:43] <groz> different perspectives i guess
[08:44] <common> no
[08:44] <db90h> i have attributed my social problems with openwrt community to my own failings
[08:44] <common> demotivating somebody to contribute is no different perspective
[08:44] <common> thats annoying
[08:45] <db90h> but groz is nice, maybe he will restore balance ;)
[08:45] <groz> well, some folks are focussed on other things, and to them, trying to squeeze down onto a v5 is a waste of time
[08:45] <groz> i look at it this way, it has no relavence to me, but, if it's another platform that can be useful
[08:45] <groz> it's useful
[08:45] <groz> for me, the v5 is not useful
[08:45] <groz> my application set wont fit on it
[08:46] <common> for me the whole broadcom based crap is not usefull, but thats not that point
[08:47] <groz> well, i can squeeze onto a 4/16 platform, and, per unit cost does matter to me
[08:47] <groz> so, the wrt54gl is a useful platform
[08:47] <groz> and i've got lots of them out there
[08:47] <db90h> when someone comes in and says, "I'm going to install a mechanical arm on my WRT and have it paint a picture for me", you can respond one of two ways: 1.) tell them its useless and a waste of time and they are stupid or 2.) say, good for you, have at it or 3.) not respond
[08:47] <groz> and now im startinga a new project, that'll be hosted on x86
[08:48] <common> db90h: mbm is the 1/3 person
[08:48] <groz> yah, and take a hundred folks, some will go each route
[08:48] <groz> i happen to be one of the folks that goes down road 2
[08:48] <groz> but that's probably because after running my own business for 25 years
[08:48] <groz> my people skills are a little different than most folsk that spend ther time developing software
[08:49] <db90h> yea, it takes some maturity to reach that level of zen ;).. i can't claim that i haven't been demotivating to people myself
[08:49] <common> groz: i have patches for br-ng xscale, i want to commit them, talk to a dev about them, whom do you recommend?
[08:49] <groz> i dunno common, the bit issue, who has the hardware to work with em
[08:49] <groz> i know i dont
[08:49] <groz> what hardware did you do it on ?
[08:50] <db90h> is there a donation fund for buying new hardware?
[08:50] <common> wrv54g
[08:50] <db90h> xscale is very important port i think
[08:50] <common> xscale is that damn powerfull
[08:51] <common> its like a horse
[08:51] <db90h> yea, i'd like to learn more about the platform.. some day perhaps i will have an xscale based device
[08:51] <common> compared to a bunch of mice
[08:52] <common> arm big endian
[08:52] <groz> well, until i see xscale in high volume production devices, it wont really be a big one for me
[08:52] <db90h> was the code base for the most part endian neutral / big endian ready?
[08:52] <groz> unless i get a client specifically asking for it
[08:53] <common> groz: freecom fsg?
[08:54] <groz> that's not a sub 75 dollar device
[08:54] <groz> my main focus is devices we can source sub 75 dollars
[08:54] <groz> or, devices that have specific requirements for a client
[08:54] <common> db90h: problem is the accesslibrary the network driver needs for is not gpl, the firmware is not gpl, you have to patch everything 'in time', but apart from that and ipkg is broken, it works really fine
[08:55] <common> not sure if the ipkg thing is an endian issue
[08:55] <common> far too less debug info
[08:56] <groz> well in the ng branch, the busybox ipkg got merged in very recently
[08:56] <groz> and it's broken
[08:56] <groz> i'm aware of that
[08:56] <groz> but, i haven't had time to even think about looking at it
[08:57] <common> Kaloz wants to use a free accesslibrary for xscale, but from what i know, there is _none_
[09:27] <db90h> yea, it seems almost all these platforms have proprietary closed-source drivers
[10:36] <groz> nbd ping ?
[10:41] <db90h> hmm.. http://lazutkin.com/blog/2006/feb/15/openwrt-gui-new-release/
[10:43] <db90h> i haven't even tried it out, i just stumbled upon it by accident in an unrelated search
[10:44] <db90h> never heard of it before
[10:44] <groz> http://www.flickr.com/photos/uhop/sets/1135170/
[10:45] <db90h> thanks
[10:45] <groz> i just clicked on links
[10:45] <groz> till i stumbled on that
[10:45] <db90h> ;p
[10:45] <db90h> awesome looking
[10:45] <db90h> in comparison to current webif anyway
[10:45] <db90h> i am surprised i had not heard of this
[10:45] <groz> reserve commentary till you see it's function
[10:46] <groz> paint jobs can be quite decieving
[10:46] <db90h> indeed ;)
[10:47] <db90h> groz, i know u have been using these routers for a long time.. u ever had any router whose nvram area on the flash ROM gave out?
[10:47] <groz> I have successfully reached my goal today
[10:47] <groz> i have the via board, booting openwrt from a usb stick
[10:47] <groz> and i can create the image for the usb stick
[10:47] <db90h> very cool
[10:47] <groz> directly within buildroot ng
[10:47] <groz> it's almost ready for commit
[10:47] <groz> just a few cleanups
[10:48] <groz> yes, i've seen a few where nvram gave out
[10:48] <groz> but
[10:48] <groz> that's not a good example
[10:48] <groz> my current stuff out there does not use nvram
[10:48] <groz> period
[10:48] <db90h> sooner or later i think almost every router will have a usb port, and although i am unsure if this aids generally in booting off usb drives as I suspect it does, it is a big thing for everyone
[10:48] <groz> so, if we have an nvram failure, it's not from overuse
[10:48] <groz> it's just a quality thing
[10:48] <groz> well, this is very x86 specific
[10:48] <groz> i'm actually using lilo to prep the image for the stick
[10:49] <groz> it creates an 8mb image that you can dd onto the stick
[10:49] <db90h> i am a supporter of using nvram because basically its a tuple based variable storage system that can be emulated easily on any platform which it doesn't exist.. and for platforms it does exist, it provides writable and proper config storage without necessitating a writable FS
[10:49] <groz> then boot from it
[10:49] <groz> and resize2fs to fill the stick
[10:49] <groz> well, i disagree, here's why
[10:49] <groz> nvram does no wear levelling
[10:49] <groz> same secotre over and over
[10:49] <groz> so it's now the life limit on your router
[10:50] <groz> every time you write nvram
[10:50] <db90h> i totally agree with that, which is why my question.. seeing dd-wrt commit my nvram 4000 times has scared me
[10:50] <groz> you earase the block and rewrite it
[10:50] <groz> well, i did actually do a real test on this once
[10:50] <groz> we set a router going with a destructive test program
[10:50] <db90h> yea, i tell people who worry about upgrading firmware too often to not worry about any such thing, cuz their nvram area will give out long before the other regions ;)
[10:50] <groz> it was a wrt54g version 3
[10:50] <groz> if i remember correctly
[10:51] <groz> erase failure ocurred after about 145,000 cycles
[10:51] <groz> cycling the same sector over and over
[10:51] <db90h> that's not that many really..
[10:51] <db90h> fyi, did u know the common upnp package for these routers commits nvram everytime a port is mapped or unmapped?
[10:51] <groz> linksys firmware commits it a LOT
[10:52] <groz> they want routers to die after 2 or 3 years
[10:52] <groz> sell you a replacement
[10:52] <groz> if a 70 dollar router dies after 2 years
[10:52] <groz> everybody goes 'oh well', and buys a replacement
[10:52] <db90h> i was shocked when i saw the commit messages every upnp mapping.. u could write a program to exploit that and kill the router
[10:52] <db90h> yep
[10:52] <groz> upnp is not for killing routers
[10:53] <db90h> of course, after 2 years, with technology it may be time for an upgrade anyway
[10:53] <groz> it's for compromising networks
[10:53] <db90h> hehehe
[10:53] <groz> I have done demonstrations to a client
[10:53] <groz> on how dangerous upnp can be
[10:54] <db90h> thanks for the 145K info.. i would like to publish that on the openwrt wiki somewhere, for people's info, if u don't mind me mentioning you
[10:54] <groz> well, i'd prefer to go find my notes on that first, and validate the number
[10:55] <groz> but in that case, there was another factor
[10:55] <groz> i chose that router to try the experiment on
[10:55] <groz> because it was not reliable
[10:55] <groz> we did have semi regular failures reflashing it
[10:55] <db90h> the flash writing is supposed to slow with the number of cycles, right?
[10:55] <groz> well, it's actually the erase cycle that's life limiting
[10:56] <db90h> therefore wouldn't it be possible to gauge fROM health through timing an nvram commit on a system with low CPU load?
[10:56] <groz> and the flash can only be erased in 'eraseblock' chunks
[10:56] <groz> nvram happens to be one eraseblock
[10:56] <db90h> ah, ok, well same difference since write mandates erase
[10:56] <groz> no, it wouldn't be a valid measurement
[10:56] <groz> no, write does not
[10:56] <groz> if you are writing part of a block
[10:57] <groz> then next write, another part of it
[10:57] <groz> no erase required
[10:57] <db90h> ah
[10:57] <db90h> i didn't know that
[10:57] <groz> that's what jffs is all about
[10:57] <db90h> i thought the entire block had to be erased and rewritten for any change to that block
[10:57] <groz> no, erase turns all bits to 1
[10:57] <groz> write will change some to 0
[10:57] <groz> a portion of the eraseblock that's not been written to yet
[10:57] <groz> is available to write
[10:57] <db90h> gotcha, i am glad you told me this
[10:58] <groz> that's why jffs, a file system that's aware of this property
[10:58] <groz> is so commonly used on flash
[10:58] <groz> it tracks such stuff, and 'deals with it'
[10:58] <groz> but lets say you update a small file 10 times
[10:58] <groz> all 10 copies likely end up in the same block
[10:59] <groz> just only one of them is 'valid'
[10:59] <db90h> makes sense
[10:59] <groz> when the entire block is used up
[10:59] <groz> it is available to cycle into the 'to be erased' pile
[10:59] <groz> and once erased, it rejoins 'free space'
[10:59] <db90h> yes, very appropriate..
[11:00] <groz> the very worst thing you can do on flash
[11:00] <groz> is fat
[11:00] <groz> which re-writes the fat on every file change
[11:00] <db90h> i bet
[11:00] <groz> but, things like usb sticks
[11:00] <groz> actually have wear levelling logic in the stick
[11:00] <groz> so it's transparent
[11:00] <groz> the mapping is done on the stick, to do the wear levelling
[11:01] <db90h> cool
[11:01] <groz> which is why i'm not adverse to using ext3 on a usb stick
[11:01] <groz> and why i set mine up this way
[11:01] <db90h> this is very educational to me ;)
[11:01] <groz> so what i do is this
[11:01] <groz> i create an 8mb ext file system within buildroot ng
[11:02] <groz> then i lilo it
[11:02] <groz> now i can stick it into a machine and boot it
[11:02] <groz> i do NOT parition it
[11:02] <groz> so the whole stick is now available
[11:02] <groz> but it's only an 8 meg fs
[11:02] <groz> resize2fs
[11:02] <groz> and voila
[11:02] <groz> full stick
[11:02] <db90h> cool
[11:02] <groz> so the 8mb file can be dd onto a stick of any size
[11:03] <groz> i've got a via epia board beside me here, and i've got a couple 128 mb sticks
[11:03] <groz> i've also got a little thing that you can stick sd cards in
[11:03] <groz> and plug it into usb
[11:03] <groz> cute little thing i got at a tradeshow, hp giveaway
[11:03] <groz> i've got a 16 mb sd in that one
[11:04] <groz> they are all working fine
[11:04] <groz> thenm for develpment
[11:04] <db90h> yea, i'd like to ahve a usb sdcard reader
[11:04] <groz> i've got 2 boot setups in lilo
[11:04] <groz> one a 'known good' kernel + initrd
[11:04] <groz> another 'what i just wrote'
[11:04] <groz> and i've got lilo talking on the serial port
[11:04] <groz> voila, cute little router to work with
[11:04] <groz> headless
[11:05] <groz> via epia board, dual ethernet, 4 serial ports, no fans
[11:05] <groz> 700 mhz processor
[11:05] <db90h> is that a sub-75 device?
[11:05] <db90h> $ i mean
[11:05] <groz> no, not this one
[11:06] <groz> this one is a development system, which mirrors what i have in th efiled at one client location
[11:06] <groz> highly custom system
[11:06] <groz> does this
[11:06] <groz> serial 1 = gps
[11:06] <groz> serial 2 = input from a solid state gyro set
[11:06] <groz> serial 3 = output to a set of motors
[11:07] <db90h> u know, given my clear obsession with this type stuff of late, i've thought about starting to do service work setting up wireless networks.. i am going to take a wild guess and say you do this on a higher level, mostly for large clients?
[11:07] <groz> serial 4 input from nmea on a boat
[11:07] <groz> final result
[11:07] <groz> it takes all the data from nmea, gps, and gyros
[11:07] <groz> figures out state in 3 dimensions
[11:07] <groz> then using the motors
[11:07] <groz> aims a satellite dish at a geostationary
[11:07] <groz> while the boat is in moti9on
[11:07] <db90h> wow
[11:07] <db90h> that's fucking awesome
[11:07] <groz> oh, wireless networks
[11:07] <groz> hehe, i have a few clients doing that
[11:08] <groz> put it in perspective
[11:08] <groz> 1800 wrts in the field, and growing at a hundred or two a month
[11:08] <db90h> that's a lot of wrts ;)
[11:08] <groz> all of them centrally managed from one central management server setup
[11:08] <groz> lots of them have vpn connects running
[11:09] <groz> about 1/4 of them are on the far siode of satellite links
[11:10] <db90h> that is a much larger network than i have ever messed with, to say the least.. i am not really a network guru at all, i'm just tyring to figure out how i can make money doing what i like.. up until now, all my technical interests i've been able to profit from in some way or another
[11:10] <groz> http://www.nautilusexplorer.com/main/index.php?ship
[11:10] <groz> there are 5 on that boat
[11:10] <groz> one, on top of the mast
[11:10] <groz> it's a 'client'
[11:10] <groz> it's hunting for open netowrks
[11:10] <groz> every time it finds an open network, it connects
[11:10] <db90h> all openwrt?
[11:10] <groz> brings up a vpn home
[11:10] <groz> no, none are openwrt now
[11:11] <groz> they will change, i'm planning on migrating all of my stuff onto openwrt
[11:11] <db90h> linksys fw?
[11:11] <groz> they are all 'invented here' now
[11:11] <groz> no, all custom, my own setup
[11:11] <db90h> ah, custom job
[11:11] <db90h> i figured the default firmware wasn't capable of such things ;)
[11:11] <groz> so the one that's 'war sailing' on top of the mast
[11:11] <groz> when it brings up a vpn
[11:11] <groz> then there are a couple more on there as access points
[11:11] <db90h> war sailing, hehe
[11:11] <groz> one connecte3d tothe war sailer
[11:12] <groz> then another farther down the boat, wds connection
[11:12] <groz> only 50 feet apart, but, it's a steel boat
[11:12] <groz> very poor penetration
[11:12] <groz> thenanotherr down in the engine room
[11:12] <db90h> do you think these cellular data networks will ever replace localized wifi?
[11:12] <groz> in the engine room, it's connected to some cameras
[11:12] <groz> which send thier video back to the wheelhouse
[11:12] <groz> over 3 wds hops
[11:12] <groz> see, the thing is this
[11:13] <groz> to run cables, we have to punch holes in watertight bulkheads
[11:13] <groz> that's a no no
[11:13] <groz> so i've 'wired' the boat without wires
[11:13] <groz> wrt54 with wds connects
[11:13] <db90h> how is performance on a multi-wds hop?
[11:13] <groz> then the skipper, he walks around with a nokia 770
[11:14] <groz> and can monitor all sorts of things on board using the browser on the nokia
[11:14] <db90h> cool ;)
[11:14] <groz> then for important stuff
[11:14] <db90h> i'd find setting something like up quite fun in its challenges
[11:14] <groz> i route email over the wifi link if it's available and if not
[11:14] <groz> it routes out over irridium sat phone
[11:14] <groz> we have 2 classes of email on board
[11:15] <groz> everybody has 2 accounts on the mail server
[11:15] <groz> one is bulk, waits for a wifi connect to go
[11:15] <db90h> ah, so a distress email should be always able to be sent
[11:15] <groz> one is 'high priority' and goes over satellite
[11:15] <groz> nahh, we have more reliable systems for distress
[11:15] <groz> inmarsat
[11:15] <groz> but text messages on inmarsat
[11:15] <groz> 1.25 cents per character
[11:15] <db90h> wow
[11:15] <db90h> i guess that keeps it down to emergency use ;p
[11:16] <groz> and for that
[11:16] <groz> we have developed a 'codebook'
[11:16] <groz> so, skipper writes a text note for the office
[11:16] <groz> then it gets fed into a program i wrote
[11:16] <groz> breaks it down into 5 letter groupings
[11:16] <groz> and it can go over inmarsat that way
[11:16] <db90h> neat
[11:17] <groz> so ya, some of the systems are very very customized
[11:17] <groz> and i have a real time status screen here
[11:17] <groz> when the boat finds a wifi connection (most marinas have wifi today)
[11:17] <groz> it brings up a vpn to the office, and everybody in the office gets an email
[11:17] <groz> advising them 'boat is online now'
[11:18] <groz> then, we get real tricky
[11:18] <groz> we route the boat pbx system thru an asterisk setup, over the wifi
[11:18] <groz> into an asterisk in the office
[11:18] <groz> and suddenly, all the phones on the boat
[11:18] <groz> can make calls on shore
[11:18] <groz> without incurring satellite charges
[11:18] <db90h> that's pretty cool.. isn't it choppy tho?
[11:19] <groz> depends, when they are in mexico, it can be at times
[11:19] <groz> but when they are on the west coast here, rarely
[11:19] <groz> and when you are comparing it to $1.25 a minute
[11:19] <groz> who cares if it's a bit choppy
[11:19] <groz> it's normally as good as cellular
[11:19] <db90h> hehe, yea
[11:20] <groz> so ya, we do really push the limits on this stuff
[11:21] <groz> but the boat is my proving ground for a lot of things
[11:21] <groz> a very good old friend owns/operates it
[11:21] <groz> and it's a floating wireless mesh
[11:21] <groz> that runs all over the world
[11:21] <groz> from southern mexico to northern alaska
[11:21] <db90h> well, let me reel you back into this nvram thing for a minute.. i'm working on building CFEs compatible with these boards from the publicly available source (primarily to create compressed CFEs to extend available ROM space at least 128KB).. do u think it'd be a waste of time to implement a compressed NVRAM system so that the NVRAM is stored in compressed blocks and the NVRAM area is only erased when tehre is no more room to wr
[11:22] <db90h> .. a new valid nvram block (compressed)
[11:22] <groz> well, you want my honest opinion ?
[11:22] <db90h> yea
[11:22] <groz> boils down to this
[11:22] <groz> writing is on the wall
[11:22] <groz> the broadcom hardware in the wrt line will not be around that much longer
[11:22] <groz> not really worth a lot of effort anymore
[11:23] <groz> cuz, it's going to be an end of life product within a short time
[11:23] <db90h> ah, I never considered that
[11:23] <groz> for what i do, example
[11:23] <groz> i need a linux kernel, vpn, and a few more things, on all boxes, as a minimum
[11:23] <groz> there's no way i can make it all fit, with wpa tools
[11:23] <groz> on the v5
[11:24] <db90h> yea
[11:24] <groz> so squeezing a bit more space on there is fine
[11:24] <groz> it may have value to you, but, it has no value to _me_
[11:25] <groz> and very soon, im going to have to find a replacement platform
[11:25] <groz> to do what we currently do with wrt54gl
[11:25] <db90h> but the reason I was working with the CFE is different than my question I suppose.. the nvram compression would be done not to save space, but to limit erase cycles on the nvram block by allowing storage of multiple copies of nvram (only one valid) in the block since many more copies can fit when compressed
[11:26] <groz> well, currently i believe it has 2 copies in there
[11:26] <groz> i may be wrong on that
[11:26] <groz> but to put it in perspective for ya
[11:26] <groz> one utility i have NOT been carrying in my 'standard' stuff up to now
[11:26] <db90h> i haven't seen such indications on the wrt54g(s) i've played with.. the default nvram is storred in CFE, and the last 64KB is dedicated to the single copy of active NVRAM
[11:26] <groz> is nvram
[11:27] <groz> we dont use it, at all
[11:27] <groz> just whatever the defaults are at boot
[11:27] <groz> to init the hardware
[11:28] <db90h> by compressing it and allowing multiple copies stored, i mean so when you recommit, you can just store a new copy after the last copy and make it the new valid one.. then when the block is full of copies, erase
[11:28] <db90h> to extend nvram area life
[11:28] <db90h> but i'm thinking it's a waste of time
[11:29] <groz> it's a good concept
[11:29] <groz> but
[11:29] <groz> cost/.benefit
[11:29] <groz> is it worth the effort
[11:29] <groz> ??
[11:29] <db90h> yea, i think not
[11:29] <groz> keeping in mind
[11:29] <groz> the defaults have to be 'normal format'
[11:29] <groz> for the boot loader to actually init things right
[11:29] <db90h> well i'd be recompiling the CFE to implement this, so I would change that.. the changes would ahve to be in both hte CFE and Linux
[11:30] <db90h> but still, saving the poor nvram from erase cycles is something that isn't going to matter very often, if at all
[11:30] <groz> well, as long as you dont have apps committing constantly
[11:30] <groz> it's not a big deal
[11:31] <db90h> yea, i think it's an unnatural obsession i've developed with keeping my nvram area healthy the last couple hours
[11:31] <db90h> i will put an end to this obsession now ;p
[11:31] <groz> when i first started doing software
[11:31] <groz> we used to measure ram in bits
[11:32] <groz> and i carved a real good niche for myself in the early 80's
[11:32] <groz> by being able to implement stuff that would fit in a 16K eprom, and use very few bytes of ram
[11:32] <groz> today
[11:32] <groz> 512 meg is the smallest / cheapest memory stick you can buy 'off the shelf'
[11:33] <groz> so i work on the assumption, if using a meg of ram saves a few hours development
[11:33] <groz> no big deal
[11:33] <groz> the wrt being a noteable exception
[11:33] <db90h> yea, i think that's kinda why I like embedded stuff
[11:33] <db90h> reminds me of the good ole days.. I started coding on a 286, so not quite as old as you, but I do have concepts of keeping it small still stuck in my brain ;)
[11:34] <groz> yah, the z-80 was fun, 8088/86 even more fun
[11:34] <groz> i can remember when we would buy an ibm pc
[11:34] <groz> then replace the bios
[11:34] <groz> with our application
[11:34] <db90h> lol
[11:34] <groz> and turn it into a dedicated controller
[11:35] <groz> you would be amazed at how much equipment we could run
[11:35] <groz> twiddling bits on a parallel port
[11:36] <db90h> despite the lesser capabilities and resources, people seem to generally have figured out ways to make even the first PCs do about anything
[11:36] <groz> we had our own asm code that would init all the hardware etc
[11:37] <groz> and that left us with varying amounts of space free in the bios roms
[11:37] <groz> another trick we used many times
[11:37] <groz> video card has room for a 32K rom
[11:37] <groz> so
[11:37] <groz> cut a few traces to disable the video itself
[11:37] <groz> then stick our application into it's socket
[11:37] <db90h> that's where i got my start, x86 asm.. used it almost exclusively until about 5 years ago
[11:37] <groz> as a rom
[11:37] <groz> used video card as a 'cheap rom carrier'
[11:38] <groz> was cheaper to buy a video card off the shelf, than to make our own board
[11:38] <db90h> hehe, cool
[11:38] <db90h> ethernet cards maybe u could have done the same with
[11:38] <groz> they were not as good tho, only mapped 8K
[11:38] <groz> video mapped 32K
[11:39] <db90h> it's been a long time since 32K was useful ;p
[11:39] <groz> ya, well
[11:39] <groz> it's been a LONG time since i've done hand tuned assembly too
[11:39] <groz> but back in the day
[11:39] <groz> i used to be able to regurgitate from memory
[11:39] <db90h> hehe
[11:39] <groz> the clock cycles for every instruction in the 8088 set
[11:40] <groz> and write code tuned to operate at a specific frequency
[11:40] <db90h> yea, i used to try to keep track of them myself, but as the processors got more complex, the task of out-optimizing (for speed) a good C compiler got harder and harder
[11:40] <groz> hehe, welllllll
[11:40] <db90h> i never wrote code to operate at a specific frequency tho ;p
[11:40] <groz> i can still remember the first time i actually did a project in c
[11:41] <groz> here was another trick we used
[11:41] <groz> example, on one project
[11:41] <groz> i needed a very precise 120hz interrupt
[11:41] <groz> the device had to operate in phase with ac power
[11:41] <groz> sooooo
[11:41] <groz> we programmed up com1 to be 1200 baud
[11:41] <groz> then started sending chars out
[11:41] <groz> and at precisely 120hz
[11:42] <groz> we would get 'tx empty' interrupts
[11:42] <groz> stuff another in the que
[11:42] <groz> lather rinse repeat
[11:42] <groz> forever
[11:42] <db90h> lol, that's a good idea
[11:42] <groz> that controller is still running today
[11:42] <groz> its an ibm pc
[11:42] <groz> with it's program in rom
[11:43] <groz> i couldn't re-create it if i wanted to
[11:43] <groz> dont have the tools to burn eproms anymore
[11:43] <groz> and probly couldn't find blanks if i tried
[11:43] <db90h> i used to code TSRs, EXE and COM parastic, complete with my own polymorphic engines .. that was my thing.. I'll not say the word ;)
[11:44] <groz> been there, done that
[11:44] <db90h> now whenever i mention the V word, people look at me like some damn email worm author
[11:44] <groz> tsr's that did the 'indos' flag dance
[11:44] <db90h> hehe, yea
[11:44] <groz> try this one on for size
[11:44] <groz> this was about 92
[11:45] <groz> i was working with a company that had a video controller
[11:45] <groz> it was the very first lcd panel display controller
[11:45] <db90h> of course above i speak of viruses, in the day it was very fun to code them.. trace interrupts to make sure they aren't hooked by AV software for implementation of stealth techniques, etc.. so fun
[11:45] <groz> panels back then were actually 640x240 16 grey shades
[11:45] <groz> so, they stuck 2 panels together to create a 640x480 display
[11:45] <groz> we had a vga chipset with 2 crtc in it
[11:45] <groz> one for each panel
[11:46] <groz> we had a prototype chip
[11:46] <groz> that was getting them mixed up at times
[11:46] <groz> but we were able to identify the issue, and it could be detected during vertical retrace blanking
[11:46] <groz> by looking at some test registers
[11:46] <groz> sooooo
[11:46] <groz> i writes a bit of code as a tsr to test the concept
[11:47] <groz> hook vertical retrace interuupt
[11:47] <groz> put chip in 'test mode' during vertical blanking
[11:47] <groz> chekc for the problem
[11:47] <groz> if its there, fix before vertical period is over
[11:47] <groz> lather rinse repeat on every vertical retrace
[11:47] <groz> it asllowed us to demo a broken chip
[11:47] <groz> and actually sealed the deal to take that prototype to production
[11:47] <db90h> hehe, lotsa such kludges all over the place back then (and now) I think
[11:48] <groz> oh, look in the driver code in linux
[11:48] <groz> it's just as bad, even worse today
[11:48] <groz> drivers gettin in under the covers and 'fixing' buggy hardware
[11:48] <groz> i mean shit, look at serial code alone
[11:48] <groz> how much code goes in a good serial driver
[11:48] <groz> to work around 16550 'issues'
[11:49] <db90h> in Windows there have even been user-mode kernel (win32 API) fixes for specific application bugs
[11:49] <groz> run windows debug kernel
[11:49] <db90h> fixing hardware issues with kludges is one thing, fixing company X's word processor bug in the win32 API is inappropriate
[11:49] <groz> and watch the spew out the debug console back in the early days
[11:49] <groz> i'll never forget the first time we saw the 'Excel hack enabled' message pop out of that one
[11:50] <groz> when i worked for the video chipset company
[11:50] <db90h> i'll try that sometime ;)
[11:50] <groz> here's another one we did
[11:50] <groz> i put this code in the video bios
[11:50] <groz> it would watch for, and detect 2 specific 'video performanc test' programs
[11:51] <groz> when they were running
[11:51] <groz> i would intercept a few calls
[11:51] <groz> and route them thru highly optimized hand tuned assembler
[11:51] <groz> tht would do only what that particular test program did
[11:51] <db90h> lol, that's common today as well
[11:52] <db90h> i bet that made your hardware look pretty good ;)
[11:52] <groz> here's another i did
[11:52] <groz> we were doing one chip on a gate array, when the feature set was complete
[11:53] <groz> the hardware guys said they had about a thousand gates free on the array
[11:53] <groz> i had them put in some hardware brezenham counters for me
[11:53] <groz> then used that in the line draw code in the autocad drivers
[11:53] <db90h> remember the DOS disk compressor that just was a TSR that doubled the free space returned?
[11:53] <groz> oh ya, frig what was it's name
[11:53] <db90h> i can't remember
[11:53] <groz> there was another one
[11:54] <groz> it dis something similar with memory
[11:54] <groz> it just reported to windows more memory than the machine actually had
[11:54] <groz> did nothing else
[11:54] <groz> back in the win 3.1 days
[11:54] <groz> and it sold like hot cakes for 29.95 a pop
[11:54] <db90h> i bet it did
[11:54] <db90h> and i bet a lot of people thought their computers ran faster
[11:55] <db90h> these damn 'RAM optimizers' today are only slightly less fraudulent
[11:55] <db90h> but people swear by them
[11:55] <groz> well, i like to put it in perspective for folks
[11:55] <groz> consider this
[11:55] <groz> when i left 'big company' to go do my own thing
[11:56] <groz> i bought the biggest/baddest development system money could buy
[11:56] <groz> sooo
[11:56] <groz> i had a 486-dx2 with 16 meg of ram, and a 300 meg hd
[11:56] <groz> 10 mbit ethernet cable to another box
[11:56] <groz> 386-33
[11:57] <groz> the 486 box cost me (without monitor) around 3000
[11:57] <groz> i wrote a full blown commercial shrink wrap on that over 18 months
[11:57] <groz> solo effort
[11:57] <groz> today, workign with wrt
[11:57] <groz> 16 meg of ram, 200mhz processor
[11:57] <groz> for 75 bucks
[11:57] <groz> retail
[11:57] <db90h> hehehe
[11:57] <groz> how is that for perspective ?
[11:58] <db90h> makes you wonder for how long such growth is sustainable
[11:58] <groz> well, the shift to multi core tells you
[11:58] <groz> they hae run into problems making the core processors faster/better
[11:58] <db90h> yea, i think with current chip technologies they have reached a speed limit
[11:59] <groz> and that problem is basically coming from speed of light issues
[11:59] <groz> and on the die size
[11:59] <groz> it's reaching atomic issues
[11:59] <groz> so now the only way to continue going faster, is to go parallel
[11:59] <db90h> it perhaps means its time for software developers to once again care something about optimization.. I dont know if u've played with .NET, but .NET apps barely run ok on today's hardware
[12:00] <groz> never installed it, dont want to
[12:00] <groz> but as an example
[12:00] <groz> i'm moving a lot of things here to virtual machines now
[12:00] <db90h> Microsoft wrote a new console u know, msh (PowerShell).. it is *nix like.. it's .NET based. You run it and it uses 40MB of RAM for a basic shell prompt
[12:01] <db90h> yea, virtualization is the next huge change i think
[12:01] <groz> here's what i did
[12:01] <groz> i bought a box, not bad, box
[12:01] <db90h> virtualiztaion will be everywhere.. no need to worry about platform independence, just distribute the OS with the app.. as one of many examples of its uses
[12:01] <groz> it's an asus motherboard with an amd dual core on it
[12:01] <groz> it's got 3 sata drives, raid 5
[12:01] <groz> and as an example, sitting on that
[12:02] <groz> is my dhcp server
[12:02] <groz> but
[12:02] <groz> it's wrapped in a little uml
[12:02] <groz> dedicated function, just a uml running only dhcp
[12:02] <groz> oh, distribute the os
[12:02] <groz> ok, you will LOVE this
[12:02] <groz> i have one client, the actual app is a web based thing, done in php
[12:02] <groz> so, here's how it deploys on customer sites
[12:03] <groz> we set up a colinux session on a windows box, to run headless, with a 32 meg root file system, basic apache/php
[12:03] <groz> it gets set up as a service on the box
[12:03] <groz> and it's set to auto start
[12:03] <groz> another one they do the same way
[12:03] <groz> for an authenticaion server
[12:03] <groz> we just run a colinux with freeradius in it
[12:04] <groz> customers think they are getting a ;windows service'
[12:04] <groz> which they are
[12:04] <groz> we just dont tell them, its linux on windows
[12:04] <db90h> hehehe, yea wide spread virtualization and free VM players brings linux new value.. developers can develop for it and not care what OS the user is running
[12:04] <groz> but this new box i put together
[12:05] <groz> it's a bare bones install, nothing but what's needed to host umls
[12:05] <groz> then all the services are grouped into functional groups
[12:05] <groz> so, my version control
[12:05] <groz> all encapsulated in one uml, dedicated to nothing else
[12:05] <groz> email, same thing
[12:06] <groz> now, there's no longer that nagging issue
[12:06] <groz> ok, i got a 'server' with all those services
[12:06] <groz> whats gonna break when it gets updated
[12:06] <groz> cuz each service is in it's own functional group
[12:06] <groz> and all can be managed independantly
[12:06] <db90h> cool
[12:06] <groz> now, carry it a step further
[12:06] <groz> i've got openwrt in a uml
[12:06] <groz> pretty much all of my testing /development moving forward
[12:07] <groz> witll be first on uml
[12:07] <groz> then deploy to real hardware
[12:07] <groz> what i do is /etc/init.d/uml start openwrt
[12:07] <groz> and up it comes
[12:08] <groz> that's an ideal way to test a lot of the packages without having to fuss with hardware
[12:08] <groz> i've been meaning to get the colinux one don
[12:08] <groz> but it's not done yet
[12:08] <groz> but consider this setup when i'm travelling
[12:08] <groz> on my windows notebook
[12:08] <groz> wifi attached to bridge, no ip params on bridge, just bridge
[12:09] <groz> windows not talking to it other than hosting the driver
[12:09] <groz> a tap on that bridge, goes to openwrt running in colinux
[12:09] <groz> with a second tap out of that, providing ip to windows
[12:09] <groz> now, i'm in a hotel, with jsut a notebook
[12:09] <groz> and i've got windows behind my openwrt firewall setup
[12:09] <groz> yet using the windows wifi drivers
[12:09] <db90h> cool idea
[12:10] <groz> and, dealing with my clients, for a lot of their things
[12:10] <groz> we are married to windows for administrative stuff
[12:10] <groz> i need to have it
[12:10] <groz> now, remember that version control uml on my server
[12:10] <groz> time to hit the road
[12:10] <groz> i shut it down
[12:10] <groz> transfer it's image file over to notebook
[12:10] <groz> and voila, up comes a colinux, and, svn to go
[12:11] <groz> i've got track and svn in a single uml, per customer
[12:11] <groz> going to visit a customer
[12:11] <groz> i can take the whole thing along, on the notebook
[12:12] <db90h> nice ;)
[12:12] <groz> i' pragmatic about all this stuff
[12:12] <groz> i will use what's needed to get the job done
[12:13] <groz> and virtualization lets me do it all
[12:13] <groz> but i do love colinux, it solves the problem of deploying linux on a site where they are scared of linux
[12:13] <groz> dont tell em it's linux, just tell em it's a windows service
[12:13] <db90h> i need to try colinux out
[12:14] <groz> that requires it's own ip
[12:14] <groz> colinux = uml for windows
[12:15] <db90h> i have been bothering to make some my recent linux tools compatible with cygwin, but i may just start recommending colinux and endeavoring compatibility with it
[12:15] <db90h> if colinux is as complete as you suggest, cygwin is a thing of the past
[12:15] <groz> colinux is a kernel
[12:15] <groz> add a root fs
[12:15] <murb> add some swap
[12:15] <db90h> well, cygwin different but same use often
[12:15] <groz> i have debian, ubuntu, and openwrt variants
[12:16] <groz> my debian on the notebook works like this
[12:16] <murb> groz: that do you need to (re)build the colinux kernel?
[12:16] <groz> it fires up, as a windows service, but, inside it
[12:16] <groz> it has vnc set up as x display 0
[12:16] <murb> I've only ever used the prepackaged ones.
[12:16] <groz> i've buit it once before murb
[12:16] <groz> it was pretty strait forward
[12:16] <murb> groz: I hope you are running updated the vnc packages.
[12:16] <db90h> ah, i had thought it was tied to a specific linux distro.. like i said, i haven't tried it
[12:16] <groz> i'm planning on adding it to openwrt
[12:16] <groz> as a target
[12:17] <murb> (nasty authentication negociation flaw, you suggest auth that isn't supported by the server and it lets you in)
[12:17] <groz> then on notebook, vncviewer full screen
[12:17] <groz> and voila
[12:17] <groz> alt-esc
[12:17] <groz> switch between linux and windows desktops
[12:17] <db90h> how hard to get ubuntu running with colinux?
[12:17] <groz> no worries murb, firewalls fix tht
[12:18] <groz> i've written some scripts that create uml root file systems for debian and ubuntu
[12:18] <db90h> i currently have a VMWare machine /w Ubuntu running constantly
[12:18] <groz> i have to make tiny mods to them to make them work with colinux
[12:18] <groz> a few more mknods
[12:18] <db90h> i'll definitely try colinux out
[12:18] <groz> then the root fs it produces will work with uml or colinux
[12:19] <groz> when it's soup, the gameplan is to 'let it out' just not sure the route
[12:19] <groz> i need to get the colinux kernel build merged into openwrt first
[12:19] <groz> then there is a kernel to go with it
[12:20] <groz> that kernel will lload the openwrt rootfs, but, could also be used to start a debian or ubuntu rootfs
[18:00] <[mbm]> .
[18:08] <murb> --
[20:29] <[mbm]> nbd: ping?
[20:29] <nbd> pong
[20:30] <[mbm]> going to pull the hotplug lines out of S10boot and move them to S40network
[20:30] <nbd> ok
[20:30] <[mbm]> also going to remove that ifconfig lo, and actually move lo to /etc/config/network
[20:31] <[mbm]> don't think we need that promisc either
[20:32] <[mbm]> how about some documentation on the new config format?
[20:33] <nbd> didn't have time for it yet
[20:33] <nbd> but it want to do it very soon
[20:33] <[mbm]> ok
[20:34] <[mbm]> there's absolutely no examples of pppoe anywhere
[20:34] <nbd> i know
[20:34] <[mbm]> and I can't even figure out some of these scripts to make an example
[20:34] <nbd> maybe i'll find the time for it today
[20:37] <[mbm]> so how's the camp?
[20:38] <nbd> fun
[20:38] <nbd> we finally have some better internet connectivity now
[20:38] <nbd> the last few days we only had umts or no internet
[20:39] <nbd> we have wifi links to a few dsl lines in the area and one of the important nodes was killed by rain :)
[20:40] <[mbm]> heh
[20:41] <nbd> the main network here is a mesh network with ad-hoc and olsr
[20:41] <nbd> but that part is working reasonably well
[20:41] <[mbm]> interesting
[20:41] <[mbm]> never actually had a mesh setup
[20:42] <dragorn> I wanted to set one up but where I live is very anti-mesh, physically
[20:44] <[mbm]> setting one up for inside my apartment would be overkill ;)
[20:44] <[mbm]> (wds works just fine for that ...)
[20:44] <nbd> freifunk hamburg doesn't really have a working mesh
[20:44] <nbd> they just have the people that build technology for freifunk berlin, which has a 300 node network :)
[20:44] <[mbm]> huh? I thought that was their major claim to fame
[20:45] <[mbm]> ah
[20:50] <[mbm]> hmm I should benchmark my new system to see if my dual amd64 can beat my dual xeon
[21:12] <rugolini> what bootloader do guys are planing to use in x86 version ?
[21:13] <rugolini> im trying to work on update system using initramfs
[21:13] <[mbm]> think groz was playing around with lilo
[21:15] <rugolini> hmmm, cause http://wiki.openwrt.org/SoekrisPort uses grub and i saw you guys yesterday talking about lilo...
[21:15] <rugolini> i will do my work with lilo then...
[21:15] <rugolini> thanks
[21:16] <CIA-17> mbm * r4572 /branches/buildroot-ng/openwrt/package/spca5xx/ (Makefile patches/02-seq_bug.patch): fix minor compile issues with spca5xx
[21:17] <[mbm]> rugolini: what are you working on that actually deals with the boot loader?
[21:17] <rugolini> here, i have another system running linux 2.6 in many places....
[21:17] <rugolini> and i have a version of kamikize working pretty well as a router
[21:18] <rugolini> then i need to upgrade both systems with a new version....
[21:18] <rugolini> i was thinking in making an image using initramfs to update everything
[21:18] <rugolini> maybe it could work
[21:19] <[mbm]> you never actually have to touch grub, once the menu.lst is in place grub will just read from it
[21:19] <rugolini> and if im doing this work, maybe i can help openwrt project with something later
[21:19] <[mbm]> for lilo you run it every time you move the vmlinux files around
[21:20] <[mbm]> either way, it's not like it makes a major impact on the upgrade system
[21:21] <rugolini> i need to set in the bootloader to load an initramfs image, right ?
[21:21] <[mbm]> no
[21:21] <[mbm]> such things can be compiled directly into the kernel image
[21:22] <rugolini> hmmm
[21:24] <rugolini> i will do some research then :P
[21:32] <groz> i have lilo working
[21:32] <groz> and i have it making bootable images
[21:32] <groz> it's _almost_ ready to commit back
[21:32] <rugolini> hmmm, cool
[21:33] <[mbm]> hmm .. bcm-2.4 didn't boot
[21:33] <[mbm]> I'll have to check that with serial later
[21:33] <groz> x86-2.4 is what is working best right now, there are some issues yet to solve in 2.6
[21:34] <groz> i' m on the phone, but when i'm off, i wanna talk to you guys about a couple things in that stuff
[22:31] <groz> ok, i'm back
[22:32] <groz> rugolini, you were talking about some of th eissues of grub/lilo etc booting an x86 system
[22:33] <groz> The real issue, it's very dependant on how you have the boot set up, disk partitions, etc
[22:33] <groz> what i'm working with is running it from a usb stick that is not partitioned at all
[22:33] <groz> it's just a big disk, mounted, with lilo on it
[22:35] <[mbm]> spiffy, xeon system takes 5 minutes to compile; amd64 takes 3
[22:36] <groz> whats the amd system ?
[22:36] <Kaloz> :P
[22:36] <groz> single, dual, ???? specs ????
[22:37] <[mbm]> amd64x2 4200+
[22:37] <Kaloz> and the xeon?
[22:37] <groz> 2 processors, or a dual core ? or 2 dual cores ?
[22:37] <Kaloz> [22:37:11] <@[mbm]> amd64x2 4200+
[22:37] <[mbm]> the amd64 is dual core
[22:37] <Kaloz> so single cpu, dualcore
[22:37] <[mbm]> the xeon is two processors, 3Ghz
[22:38] <groz> ok, i'm looking to replace one old box here this week, i've got one with an amd64 3800 which is pretty nice
[22:38] <groz> been debating just make another like that, or, go for a more spendy processor
[22:39] <groz> then 3 sata as a raid 5 on it
[22:39] <groz> the dual core really does make the raid a lot more transparent
[22:40] <groz> nbd, you here still ?
[22:41] <[mbm]> specs: amd64x2 4200+ in an asus M2NPV-VM board; 2G of DDR2 8000 (which due to some crappy stability is cirrently running at 666)
[22:41] <Kaloz> groz: i'm debating on getting an xscale iop based nas or just drop an amd64 downclocked to 800mhz with a large passive heatsink
[22:41] <[mbm]> running off sata drives .. bought a new sata dvd burner to go with it
[22:41] <groz> ok, i've got an av8n with the 3800+ in it, works nice
[22:41] <common> Kaloz: which free accesslibrary do you want to use for xscale?
[22:41] <[mbm]> it's an AM2 socket so I'll be able to upgrade it
[22:41] <groz> 3 250g sata
[22:42] <Kaloz> no access library. just a free ethernet driver
[22:42] <common> which?
[22:42] <Kaloz> i doubt there is a lot of :P
[22:42] <common> there is none?
[22:42] <Kaloz> there is one
[22:42] <common> link?
[22:42] <Kaloz> no link for it yet
[22:43] <common> work in progress?
[22:43] <groz> http://pastebin.ca/135243
[22:43] <Kaloz> well, mostly working on the gateway :) let's say 100% working, with some annoying debug messages i can ignore
[22:43] <groz> mbm, that's the script i was talking about yesterday
[22:44] <groz> that needs privs to mount the image
[22:44] <groz> and make it bootable
[22:44] <groz> with lilo
[22:44] <groz> my debate now, should i incorp it just as yet another package in the mainline build
[22:44] <groz> or set it as a script on the side
[22:44] <Kaloz> common: it will be integrated soon imho.. but anyways, first i want nbd to add support for that crappy rgloader
[22:44] <groz> because it's gonna generate pw prompts
[22:44] <[mbm]> groz: you shouldn't need losetup .. just mount -o loop file /dir
[22:44] <groz> and stop a build
[22:44] <groz> no that doesn' twork mbm
[22:44] <common> Kaloz: are you intrested in the kernel tweaks for wrv54g?
[22:44] <groz> not for lilo
[22:44] <[mbm]> hmm shame
[22:44] <groz> it wants to query geometry of the mount
[22:45] <groz> extlinux doesn't
[22:45] <groz> but, extlinux also doesn't work
[22:45] <groz> i fought with it for hours and hours
[22:45] <Kaloz> common: well, addign the kernel patches isn't a big deal, but afaik nbd is working on those as well
[22:45] <groz> it never gets the geometry right
[22:45] <groz> while this setup with lilo, never seems to get it wrong
[22:45] <common> the gtwx part in 2.6.17 is broken, won't even compile
[22:46] <Kaloz> groz: uboot?
[22:46] <[mbm]> hrm .. did someone much with basefiles or libgcc recently?
[22:46] <groz> i've never looked at uboot kaloz
[22:46] <groz> will uboot boot an x86 ?
[22:47] <rugolini> back...
[22:47] <groz> kaloz, whats nice about the way i'm doing it
[22:47] <groz> it's just an ext file system that can be dd onto a usb stick
[22:47] <rugolini> groz, i was thinking something diferent from you, but i don't know if it will work...
[22:47] <groz> then after its on, you can resize2fs to fill the stick
[22:47] <common> why do you use a own config/interfaces instead of using busybox ifup?
[22:49] <rugolini> groz, im thinking to compile some tools (static), make the partitions, copy the files and dd an image (i know this will be bigger), but maybe it's for my problems
[22:50] <groz> why would you want parititioins ?
[22:50] <rugolini> hmmmm
[22:50] <groz> with the setup i'm using, it's also pretty trivial
[22:51] <groz> to add a second kernel/initrd to lilo
[22:51] <groz> and have a 'boot old good' option
[22:51] <rugolini> cause i prefer to have like 2 partitions.... in case i need to change something remotely
[22:51] <groz> or, an option to boot 'ramdisk only'
[22:51] <rugolini> groz, yeah....
[22:52] <groz> the way i'm setting mine up
[22:52] <groz> i have a known good kernel, with known good initrd
[22:52] <rugolini> i just compile lilo, and i will start to make some tests tomorow
[22:52] <groz> then when i rebuild stuff, i can just copy a kernel/initrd in, lilo, and reboot
[22:53] <rugolini> i need to go to the university in 15min
[22:53] <rugolini> today i want be able to start this :(
[22:55] <rugolini> groz, if make any progress i tell you...
[23:19] <groz> mbm, remember the question yesterday regarding 000 patch, does it help, or does it hurt ?
[23:19] <groz> i have the answer now
[23:19] <[mbm]> probably hurts
[23:19] <groz> build without that one, and netboot using gzip initrd fails
[23:19] <groz> build with it, it work
[23:19] <[mbm]> ah, interesting
[23:19] <groz> i've done a before and after verification now
[23:19] <groz> so, it stays
[23:20] <groz> without that patch , initrd that's not compressed works fine, netboot nbi or elf
[23:20] <[mbm]> :) I just would have liked a broken out set of patches rather than one huge patch file
[23:20] <groz> but gzip the initrd, and it fails with a crc error
[23:20] <[mbm]> but the 2.4 stuff really doesn't concern me
[23:20] <groz> interesting enough, the same gzipped initrd, coming off the local disk
[23:20] <groz> works fine
[23:20] <[mbm]> and the 2.6 stuff is nicely broken up
[23:21] <groz> well, in some cases, i'll want to use 2.4, so an x86 box is in sync with a wrt
[23:21] <groz> deploying the exact same stuff on it, expect same behaviours
[23:21] <Kaloz> then add the missing bits to the system code of brcm-2.6
[23:21] <Kaloz> :P
[23:21] <groz> with the exception of wifi
[23:21] <Kaloz> so it won't be 4712 only
[23:22] <[mbm]> I really prefer to keep ontop of the bleeding edge stuff so there's less work later
[23:22] <[mbm]> in other words keeping up with the incremental changes rather than being abandoned when the 2.4.x tree goes end of life
[23:24] <groz> well i have valid situations for both sides, 2.4 and 2.6
[23:24] <groz> so, i'm gonna get to the point i got em both clean on x86
[23:24] <[mbm]> cool
[23:25] <[mbm]> what was what issue you were telling me about yesterday with the modules?
[23:25] <groz> hang on phone
[23:25] <[mbm]> (now that I've fixed that pesky kernel issue)
[23:25] <groz> but the objcopy was trashing them
[23:25] <[mbm]> no, there was something else
[23:25] <groz> from 209-build???? patch
[23:25] <[mbm]> you were saying that the wrong modules were being put into the filesystem
[23:25] <groz> oh, make .modules-done depedant on config
[23:26] <groz> so if i reconfig, it'll rebuild the modules packages
[23:26] <[mbm]> ah
[00:00] --- Thu Aug 17 2006