[00:25] <blux> someone here who does kernel programming? (or know sth about flash access)?
[00:25] <nbd> what do you want to know?
[00:26] <blux> hmm I thnk you'll know me
[00:26] <blux> I am the guy with the flash mod
[00:26] <nbd> which one?
[00:26] <[mbm]> umm, there have been several flash mods
[00:27] <blux> did i miss sth?
[00:28] <[mbm]> maybe you should just explain what you've done and what you need
[00:28] <blux> replaching the flash Chip with an bigger one
[00:30] <[mbm]> (... and ?)
[00:30] <blux> and i whant to know if the addresse 0x1FC00000 and 0x1C000000 are "the same"
[00:30] <blux> shadowed ore sth
[00:31] <[mbm]> yes
[00:32] <blux> but the adressroom of 0x1FC00000 is smaller
[00:33] <nbd> blux: they should behave in the same way
[00:34] <blux> ok
[00:35] <blux> hmm. kann 8MB adressed with 0x1FC00000 ?
[00:35] <nbd> yes, the openwrt flash map driver uses this mapping
[00:35] <[mbm]> why don't you just create a pastebin with the dmesg instead of these terse summaries<7>Physically mapped flash: Found an alias at 0x400000 for the chip at 0x0
[00:35] <[mbm]> <7>Physically mapped flash: Found an alias at 0x800000 for the chip at 0x0
[00:35] <[mbm]> <7>Physically mapped flash: Found an alias at 0xc00000 for the chip at 0x0
[00:35] <[mbm]> <7>Physically mapped flash: Found an alias at 0x1000000 for the chip at 0x0
[00:35] <[mbm]> <7>Physically mapped flash: Found an alias at 0x1400000 for the chip at 0x0
[00:35] <[mbm]> <7>Physically mapped flash: Found an alias at 0x1800000 for the chip at 0x0
[00:35] <[mbm]> <7>Physically mapped flash: Found an alias at 0x1c00000 for the chip at 0x0
[00:35] <[mbm]> ack.. damn machine
[00:36] <[mbm]> lost contorl of the mouse
[00:36] <blux> :-)
[00:37] <blux> I only have access via JTAG. . .
[00:37] <[mbm]> you'll want to connect serial
[00:37] <blux> and in debrick only the two addreses are in
[00:38] <[mbm]> all you need to do is write cfe
[00:38] <blux> I have. . . but "Flash mod" -> the chip is emty and cfe not bboting :-)
[00:38] <[mbm]> you don't need access to the entire flash to debrick
[00:38] <[mbm]> cfe boots, doesn't find a firmware and starts waiting on tftp
[00:39] <[mbm]> you don't even need nvram for that
[00:39] <blux> nvram have to be written to se end, won't it?
[00:39] <blux> ok
[00:39] <blux> you anwsert to fast
[00:40] <blux> does CFE support SST write instructions? it will not be able to write
[00:41] <[mbm]> no idea - I would have used the same brand of flash chip as it came with to avoid that issue
[00:41] <blux> bu you talk of "many" flash mods it there sth to read about them?
[00:41] <[mbm]> go read the forum
[00:41] <blux> ok
[00:55] <blux> hmm If I flash the CFE to wrt and read it again the file is corrupted. . . Ive done it twitche, with nearly the same corruptions . . .
[00:55] <nbd> maybe your jtag cable is too long
[00:55] <nbd> is it a buffered one?
[01:07] <blux> no it isn't
[01:10] <blux> and it is not to long i think
[01:26] <[mbm]> check your pins
[01:26] <[mbm]> sounds like you might have a short
[02:55] <blux> I thougth of it myself. . .
[02:55] <blux> and i was afk
[03:01] <blux> what do you think will happen if one wire is sligthly longer than all others?
[03:10] <[mbm]> Unless we're talking about an order of magnitude longer (several feet) it's unlikely to matter
[03:22] <blux> ok
[03:23] <blux> resistance doesd metter to i think, it thin, but not thinner then the wires on the board
[03:23] <blux> to -> too
[03:24] <blux> I'll try again, I've loocked for shorts and refit some wires
[03:25] <blux> some I'e soldert to fit the differnt pinout
[03:58] <blux> what does an Linksys tries to tell if he's blinking fast? I know the slow blink blink
[04:16] <blux> N8
[09:21] <CIA-17> florian * r4695 /branches/buildroot-ng/openwrt/target/linux/brcm63xx-2.6/patches/001-bcm963xx.patch: Restore boot loader detection by parsing the command line, fixes issue with Inventel liveboxes
[10:14] <CIA-17> florian * r4696 /packages/net/aircrack-ng/Makefile: Upgrade aircrack-ng to 0.6.1
[11:05] <CIA-17> florian * r4697 /branches/buildroot-ng/openwrt/target/linux/brcm63xx-2.6/patches/001-bcm963xx.patch: Fixup PCI compilation
[11:11] <CIA-17> florian * r4698 /branches/buildroot-ng/openwrt/target/linux/brcm63xx-2.6/config: Enable PCI in kernel config, and compile wireless drivers
[11:24] <db90h> i also just updated the wireless-tools patch for v29 pre10, if you guys want it
[11:24] <nbd> is the new version any good?
[11:26] <db90h> testing now, had to do one more minor edit of makefile (hard coded 28 ver number in dir and lib name)
[11:26] <db90h> as far as if it's any good...
[11:26] <db90h> i dunno
[11:26] <db90h> ;)
[11:27] <db90h> i think since the version you guys had in kamikaze, v28, there is a new option to not include stuff that's not commonly used, for smaller binaries
[11:27] <db90h> ok, it works fine now.. just built ok
[11:28] <db90h> anyway, as of now it's in my svn, so you should be able to check out and slap into the kamikaze (old) trunk and white russian trunks if you want to update it in either
[11:28] <db90h> save someone 5 minutes someday
[11:29] <db90h> the only reason i was playing with it is cuz i had updated it for the the wl530-g images i'm building, hoping it would address a lack of proper interpretation of survey (iwlist scan) results
[11:30] <Kaloz> that's more like a driver problem
[11:30] <db90h> yea, i think so
[11:30] <db90h> i was desperate and wished for the impossible ;)
[11:30] <Kaloz> hehe :)
[11:31] <db90h> most of the wireless-tools stuff works fine, but iwlist scan returns some "unknown wireless token 0x####" where a found AP should be
[11:33] <florian__> ah ah !
[11:34] <nbd> :)
[11:36] <Kaloz> yo
[11:36] <florian__> nbd: I have tried to load a bit the other binary modules, some are just inserted well out of the box
[11:36] <nbd> interesting
[11:37] <nbd> have you tried running adsl stuff?
[11:37] <florian__> atmapi and bcmprocfs are inserted well just out of the box, I think blaadd should we well inserted too with the kmod-atm I forgot to install in my initramfs
[11:38] <nbd> what does blaadd do?
[11:38] <florian__> this is precisely what I want to know
[11:38] <florian__> there are several modules related to dsl : atmapi (self-explanatory), adsldd, blaad
[11:39] <nbd> isn't there also adslapi?
[11:40] <florian__> adsldd comes with an adsl_phy.bin which is probably the phy to upper layer
[11:40] <florian__> I found no adslapi
[11:41] <nbd> hmm, probably a different sdk then
[11:41] <florian__> or another implementation index
[11:42] <florian__> have you figured out why there are different binaries for different profiles ? 6348GW, 6348R ... ?
[11:43] <nbd> no idea
[11:45] <nbd> florian__: i'll give you a snapshot of bcmdrivers from the 3.03 sdk for testing
[11:45] <florian__> ok, I won't be able to do more testing before saturday
[11:45] <nbd> uh, not 3.03, but 3.05
[11:45] <florian__> actually, I will get back a huawei hg550
[11:46] <florian__> which is CFE based, so that I could also test if it works
[11:46] <nbd> florian__: http://downloads.openwrt.org/people/nbd/tmp/bcmdrivers_3.05.tar.gz
[12:00] <florian__> nbd: can you have a test at this tarball ? http://downloads.openwrt.org/people/florian/broadcom-brcm63xx-0.1.tar.bz2
[12:01] <nbd> are the makefiles included?
[12:01] <florian__> which ones ?
[12:01] <nbd> buildroot
[12:01] <nbd> and driver makefiles
[12:01] <florian__> driver makefiles, yes
[12:03] <florian__> for the buildroot-ng makefile, see this pastebin : http://pastebin.ca/152994
[12:03] <nbd> k
[12:11] <CIA-17> nbd * r4699 /branches/buildroot-ng/openwrt/package/madwifi/Makefile: skip a lot of useless junk in madwifi on linux 2.4
[15:16] <[florian]> re
[15:16] <[florian]> nbd: have you tested my tarball ?
[15:16] <nbd> not yet
[15:17] <[florian]> ok, no problem
[15:29] <florian> ticket #737 is not really a problem, right ?
[15:31] <nbd> probably just a matter of changing the chillispot init script
[15:50] <florian> I mean, giving 127.0.0.1 as nameserver shoud not be a problem if dnsmasq resolves
[15:51] <nbd> no, the problem is that 127.0.0.1 is handed out as dns server via dhcp
[15:51] <nbd> which of course won't work
[15:52] <florian> ah ok
[15:54] <CIA-17> florian * r4700 /packages/lang/sablevm-classpath/Makefile: Add missing preriquisites to sablevm-classpath
[15:55] <florian> [mbm]: you had problems compiling ipcad right ?
[15:55] <florian> [mbm]: tickets #733 reporst the same problem, can you have a try at the packages with your fresh ubuntu ?
[17:24] <[mbm]> florian: hmm squid shouldn't require openssl on the host, only that the openssl package is installed
[18:20] <CIA-17> nbd * r4701 /branches/buildroot-ng/openwrt/package/madwifi/ (8 files in 2 dirs): update madwifi to 0.9.2
[18:41] <florian> [mbm]: actually only openssl headers
[18:43] <florian> anyone already tried to x-compile isakmpd ?
[18:44] <[mbm]> florian: what I mean is that the openssl package should install those in staging_dir .. there's no point in having the system put them in /usr/include
[18:49] <florian> ok, so we could use the headers in staging_dir instead of requiring host side libs ?
[18:49] <[mbm]> right
[18:51] <florian> ok, I will fix this later
[18:51] <florian> any other package mentionned compiles fine ?
[18:53] <[mbm]> think ipcad changes depending on which gcc version is used
[18:54] <florian> preciselty
[18:54] <[mbm]> I really didn't have any trouble compiling most of the packages listed as buggy
[18:56] <florian> ok
[18:56] <florian> feel free to close the ticket if you think it is invalid
[18:57] <[mbm]> haven't closed it yet because I'm not sure why that person is getting those errors
[18:58] <florian> I think [olli]
[18:59] <florian> he asked me of taking care of them
[19:23] <florian> I am getting less and less fond of package maintaining
[19:24] <[mbm]> heh, kernel hacking is more fun?
[19:24] <florian> though it is more complicated and I learn step by step, definitively yes
[19:24] <[mbm]> well, at least packages on ng take far less time than whiterussian
[19:25] <florian> yes that's really what I appreciate
[19:26] <florian> and it now takes far less time adding this or that software
[19:34] <Bartman007> [mbm]: so what the deal with the wpa_supplicant error I ran into yesterday, you knew of it, but disappeared. I couldn't find any references to it anywhere on the forums or the dev site. I don't care if it won't be fixed for a while, I was just wondering what the status it.
[19:37] <[mbm]> bug I had stumbled across a few weeks back but haven't had time to fix yet
[19:38] <Bartman007> ok, thanks.
[19:38] <mtoledo> what's going on with http://wiki.openwrt.org/TableOfHardware?
[19:38] <Bartman007> so should I submit a bug report so it is recorded somewhere?
[19:39] <Bartman007> mtoledo: what do you mean?
[19:40] <Bartman007> ah. I see what you mean. it was working fine no more than a half hour ago
[19:40] <mtoledo> marcelo@marcelo:~/projetos/vbox_dynamic_route/trunk$ lynx -source http://wiki.openwrt.org/TableOfHardware | wc -l
[19:40] <mtoledo> 3774
[19:40] <mtoledo>
[19:40] <mtoledo> weird, in firefox it's not appearing.
[19:41] <thepeople_work> working for me in fireforx
[19:41] <Bartman007> this website glitch pops up every so after.
[19:41] <thepeople_work> firefox*
[19:41] <Bartman007> s/after/often/
[19:41] <Bartman007> first time it has actually happened to me though.
[20:00] <florian> I am sick of stupid people "why do you need to make your own linux kernel for bcm963xx"
[20:00] <florian> the question is obviously to make coffee
[20:01] <florian> the answer sorry
[20:01] <groz> #define COFFEE linux-bcm-963xx
[20:01] <groz> now shut up and go make coffee
[20:02] <groz> proper wording for an answer
[20:02] <groz> :)
[20:02] <blux> has someone the datasheet of an BCM4712 or so?
[20:02] <murb> blux: make groz some coffee.
[20:02] <groz> lol
[20:02] <groz> good morning strangers, i'm back in the world
[20:03] <groz> and working on a coffee right now
[20:03] <blux> Ok, comt to me, and i will serve you one
[20:04] <florian> blux: you can find quite easily the reference guide
[20:04] <Bartman007> heh, prereq detection of jikes has been modified/improved, it now bitches about a broken java compiler :-)
[20:04] <florian> datasheet will likely be available by signing the proper NDA
[20:05] <florian> this mostly exclude people that are not working for a company which has orderd 1000 < units from brcm
[20:06] <florian> and probably people more or less explicitely people working in oss projects
[20:07] <Bartman007> florian: you could always try to convince mbm's company to order the required units :-P
[20:07] <groz> that still wouldn't free up the information
[20:08] <groz> it would just mean somebody is caught between a rock and a hard place with access to nda material
[20:08] <groz> and the inability to 'let it out'
[20:08] <florian> precisely
[20:08] <Bartman007> yeah.
[20:08] <Bartman007> could always try the IBM BIOS reverse enginnering method :-)
[20:09] <groz> this is precisely the reason why with one of my clients, i am offsite, with no access to 'company internal' documentation
[20:09] <Bartman007> though the NDA probably bars discussing it at all
[20:10] <groz> bartman, years ago, i wasn involved in a 'clean room' reverse engineering project for the ibm vga bios
[20:10] <groz> it was a lot of work, not trivia
[20:10] <groz> and the corporate lawyers were breathing down our necks on a weekly basis
[20:10] <Bartman007> that's what it's called, couldn't remember the term clean room
[20:11] <groz> We literally worked in a separate office (next door to the main office)
[20:11] <groz> with no network connections into main office, and no phone connections to main office
[20:11] <groz> and no access to the library over there
[20:11] <groz> our door cards would not let us into main office
[20:12] <Bartman007> sounds rather cool except for the auditing. :-)
[20:12] <groz> It was a huge pain
[20:13] <groz> by the time we were done, I think we knew more about that vga bios than the folks that originally wrote it
[20:14] <Bartman007> I wouldn't doubt it.
[20:18] <Bartman007> Closest I've run into but on a smaller scale, was on my high school robotics team. The lead programmer became upset over a few things and hadn't check the control code back into the repository for a few weeks, so a few of us had to figure out what the code did based on the compiled code, the reaction of the robot, and a few clues about his general programming style.
[20:19] <Bartman007> after a while we said fsck it and rewrote most of the control routines because his coding style was crap.
[20:19] <florian> lol
[20:20] <Bartman007> florian: yeah, a lot simpler :-)
[20:20] <florian> Bartman007: not sure, I have been helping a friend in programming a robot quite hard actually
[20:21] <blux> hmm but BCM could sell more if thy put the information free
[20:21] <groz> depends on your perspetive blux
[20:22] <murb> blux: what happens if they don't actually own it to give it all away?
[20:22] <Bartman007> this was a PITA because he had written a fair amount of code that introduced a level of abstraction between the operator and the robot. the drivers had already had quite a bit of practice with this new code, then the bastard got upset because other people wanted to him to at least commit what he had so other people might be able to help speed it along.
[20:22] <groz> the competition could also figure it all out, and make cheaper / better devices with access to that
[20:22] <blux> I think a couple of people will build things with an BCm chip
[20:22] <Bartman007> blux: trade secrets are a very sensitive subject
[20:22] <groz> and when it comes to the software radio stuff, they cannot let it out, FCC rules
[20:23] <blux> I would do it, an small board with an BCM
[20:23] <florian> blux: probably
[20:23] <blux> hmm
[20:24] <Bartman007> blux: the number of boards they would sell to enthusiasts is a drop in the bucket compared to the sales they are achieving from the major players in the business
[20:28] <groz> pretty small drop, in a pretty big bucket
[20:41] <groz> anybody here worked with uclinux at all ?
[20:42] <wigyori> just played around with that, for that brecis core
[20:42] <groz> i'm wondering, is it possible to build with an x86 target, but nommu options, to work with uclinux on x86 while I wait for the real hardware to arrive ?
[20:42] <wigyori> well, not that much
[20:42] <wigyori> ;p
[20:42] <groz> all of the target hardware i have here right now has an mmu
[20:43] <groz> but, i got some coming soon that doesn't, just wondering if there is an easy way to 'be ready' before it actually arrives
[20:43] <murb> i was once tempted to try it on an old c2503
[20:43] <murb> but never got arround to it.
[20:43] <groz> and the ideal would be to build for x86 but actually build uclinux for it, not linux
[21:07] <blux> is thair an dev which gives 1111 ? the contrary of /dev/zero
[21:10] <blux> ?
[21:10] <blux> perhaps /dev/full ?
[21:12] <blux> I need to build an file full of FF with dd ore so
[21:15] <nbd> dd if=/dev/zero bs=1k count=1 | sed -e 's,\x00,\xff,g'
[21:16] <blux> ok
[21:16] <blux> thx
[21:30] <CIA-17> nbd * r4702 /branches/buildroot-ng/openwrt/toolchain/gcc/Makefile: fix gcc symlink install
[22:04] <florian> groz: I have tried to play a bit for the wrt54gp2, without success yet
[22:04] <florian> and also for the wrt54gx2 (which could run under normal linux though)
[22:10] <florian> sound quite painful
[22:11] <florian> there are lot of platform specific drivers
[22:41] <florian> nbd: can you try with pci enabled for bcm63xx ?
[22:44] <nbd> not right now
[22:45] <florian> ok no pb
[22:50] <blux> is someone interested in an ne debrick version?
[22:50] <blux> new
[22:52] <florian> did you made some changes ?
[22:52] <florian> nbd: looks like pci is not crashing the device
[22:52] <blux> yes
[22:52] <florian> nbd: how can I make a simple workaround for things like that :
[22:52] <florian> wl: Unknown symbol pci_register_driver
[22:52] <florian> wl: Unknown symbol sys_read
[22:52] <florian> wl: Unknown symbol sys_open
[22:52] <florian> wl: Unknown symbol alloc_skb
[22:53] <blux> new optins /slow it depends on thes patch which added a sleep during write operations
[22:53] <florian> ah good thing
[22:54] <blux> and not yes switchable an oly for SST flash an direkt veryfinging of the written Data
[22:55] <blux> every written byte get readed again and compaired against the orginal
[22:55] <florian> in case there was errors or ?
[22:55] <blux> I someone will have this as feature, i will do is as an option /veryfy ore so
[22:56] <blux> yes, to detect wrte errors
[22:56] <blux> write
[22:56] <florian> good idea
[22:56] <blux> writing then reading and compairing
[22:56] <florian> did you submit the patch to the original author ?
[22:57] <blux> no, I can't find him anywhere
[22:57] <blux> its ligthbulb but I did not find his e-mail address
[22:57] <florian> ok
[22:57] <florian> what about ranvik.net ?
[23:00] <blux> is this ligthbulb ?
[23:00] <blux> aka HairyDairyMaid ?
[23:00] <florian> yep this is his site I think
[23:02] <blux> ok
[23:03] <blux> he is russian ore so?
[23:03] <nbd> no
[23:04] <blux> what else?
[23:04] <blux> hes a nert http://ranvik.net/prosjekter-privat/wlan-bilder/100_1607.JPG
[23:04] <blux> hanging aut the bare board and soldering such an wire to it ;-)
[23:04] <blux> out
[23:06] <florian> nbd: you have not answered to my question ;)
[23:07] <florian> if you have just general tips and tricks
[23:11] <blux> If you go to address 0x1c000000 you will have 0000000000000. . on the flash chip address pins, orge will it be som kind of multiplexed?
[23:12] <blux> I mean if you are at 0x1c000000 all adress lines will be at logical 0
[23:28] <blux> ohh, I found an E-maqil address of Hairydairy. . .
[23:28] <blux> I was so blind!
[23:31] <db90h> groz: you would like a nommu uclinux target for openwrt?
[23:32] <groz> what would that be db90 ?
[23:33] <groz> my interest is actually in bringing up uclinux in advance of getting the target hardware, so i can validate a bunch of packages
[23:33] <groz> cuz i know there are issues in areas like fork
[23:33] <db90h> i am also working with uclinux right now
[23:33] <groz> what target are you using ?
[23:34] <db90h> not openwrt though.. for the wl530-g
[23:34] <db90h> if it's reasonable to build openwrt for such a system, using the uclinux patches, then i'd love to see it done
[23:36] <groz> well, that's kind of my plan, end up with a uclinux target within the -ng build environment
[23:36] <db90h> i think probably what it work take is apply the uclinux patches to the linux kernel in openwrt, redo any openwrt kernel patches that then need adjusting (if any), then start debugging and fixing up packages that don't work because of things like fork
[23:37] <groz> well, that's my real goal, to work with a couple things on the difference in fork
[23:37] <groz> so, to do that, i need a target that has no mmu
[23:37] <db90h> then you'd have to build flat binaries as well.. i really don't know everything necessary to achieve this. I'd like to better learn the reasons for its feasibility or infeasibility
[23:38] <groz> and was wondering if anybody has tried building uclinux for x86, with mmu disabled
[23:38] <groz> by disabling the mmu, you end up with the appropriate environment on the target
[23:38] <groz> to get into the issues of fork differences
[23:38] <db90h> is your eventual plan to get openwrt working with nommu, or are you just messing with uclinux?
[23:39] <groz> I have a hardware device arriving soon, that's got no mmu
[23:39] <groz> and currently runs uclinux based on a very hacked buildroot
[23:39] <groz> so, i'd like to just merge it into -ng
[23:40] <db90h> i'd love to see that done. from what nbd told me, it sounded it was a bit unrealistic.. but i am still very hazy in many areas
[23:40] <groz> well, that's just it, i'm not sure of what all the issues are, so, starting to look into it
[23:43] <groz> doesn't help that www.uclinux.org is dead
[23:45] <db90h> brb
[00:00] --- Wed Aug 30 2006
[00:25] <nbd> what do you want to know?
[00:26] <blux> hmm I thnk you'll know me
[00:26] <blux> I am the guy with the flash mod
[00:26] <nbd> which one?
[00:26] <[mbm]> umm, there have been several flash mods
[00:27] <blux> did i miss sth?
[00:28] <[mbm]> maybe you should just explain what you've done and what you need
[00:28] <blux> replaching the flash Chip with an bigger one
[00:30] <[mbm]> (... and ?)
[00:30] <blux> and i whant to know if the addresse 0x1FC00000 and 0x1C000000 are "the same"
[00:30] <blux> shadowed ore sth
[00:31] <[mbm]> yes
[00:32] <blux> but the adressroom of 0x1FC00000 is smaller
[00:33] <nbd> blux: they should behave in the same way
[00:34] <blux> ok
[00:35] <blux> hmm. kann 8MB adressed with 0x1FC00000 ?
[00:35] <nbd> yes, the openwrt flash map driver uses this mapping
[00:35] <[mbm]> why don't you just create a pastebin with the dmesg instead of these terse summaries<7>Physically mapped flash: Found an alias at 0x400000 for the chip at 0x0
[00:35] <[mbm]> <7>Physically mapped flash: Found an alias at 0x800000 for the chip at 0x0
[00:35] <[mbm]> <7>Physically mapped flash: Found an alias at 0xc00000 for the chip at 0x0
[00:35] <[mbm]> <7>Physically mapped flash: Found an alias at 0x1000000 for the chip at 0x0
[00:35] <[mbm]> <7>Physically mapped flash: Found an alias at 0x1400000 for the chip at 0x0
[00:35] <[mbm]> <7>Physically mapped flash: Found an alias at 0x1800000 for the chip at 0x0
[00:35] <[mbm]> <7>Physically mapped flash: Found an alias at 0x1c00000 for the chip at 0x0
[00:35] <[mbm]> ack.. damn machine
[00:36] <[mbm]> lost contorl of the mouse
[00:36] <blux> :-)
[00:37] <blux> I only have access via JTAG. . .
[00:37] <[mbm]> you'll want to connect serial
[00:37] <blux> and in debrick only the two addreses are in
[00:38] <[mbm]> all you need to do is write cfe
[00:38] <blux> I have. . . but "Flash mod" -> the chip is emty and cfe not bboting :-)
[00:38] <[mbm]> you don't need access to the entire flash to debrick
[00:38] <[mbm]> cfe boots, doesn't find a firmware and starts waiting on tftp
[00:39] <[mbm]> you don't even need nvram for that
[00:39] <blux> nvram have to be written to se end, won't it?
[00:39] <blux> ok
[00:39] <blux> you anwsert to fast
[00:40] <blux> does CFE support SST write instructions? it will not be able to write
[00:41] <[mbm]> no idea - I would have used the same brand of flash chip as it came with to avoid that issue
[00:41] <blux> bu you talk of "many" flash mods it there sth to read about them?
[00:41] <[mbm]> go read the forum
[00:41] <blux> ok
[00:55] <blux> hmm If I flash the CFE to wrt and read it again the file is corrupted. . . Ive done it twitche, with nearly the same corruptions . . .
[00:55] <nbd> maybe your jtag cable is too long
[00:55] <nbd> is it a buffered one?
[01:07] <blux> no it isn't
[01:10] <blux> and it is not to long i think
[01:26] <[mbm]> check your pins
[01:26] <[mbm]> sounds like you might have a short
[02:55] <blux> I thougth of it myself. . .
[02:55] <blux> and i was afk
[03:01] <blux> what do you think will happen if one wire is sligthly longer than all others?
[03:10] <[mbm]> Unless we're talking about an order of magnitude longer (several feet) it's unlikely to matter
[03:22] <blux> ok
[03:23] <blux> resistance doesd metter to i think, it thin, but not thinner then the wires on the board
[03:23] <blux> to -> too
[03:24] <blux> I'll try again, I've loocked for shorts and refit some wires
[03:25] <blux> some I'e soldert to fit the differnt pinout
[03:58] <blux> what does an Linksys tries to tell if he's blinking fast? I know the slow blink blink
[04:16] <blux> N8
[09:21] <CIA-17> florian * r4695 /branches/buildroot-ng/openwrt/target/linux/brcm63xx-2.6/patches/001-bcm963xx.patch: Restore boot loader detection by parsing the command line, fixes issue with Inventel liveboxes
[10:14] <CIA-17> florian * r4696 /packages/net/aircrack-ng/Makefile: Upgrade aircrack-ng to 0.6.1
[11:05] <CIA-17> florian * r4697 /branches/buildroot-ng/openwrt/target/linux/brcm63xx-2.6/patches/001-bcm963xx.patch: Fixup PCI compilation
[11:11] <CIA-17> florian * r4698 /branches/buildroot-ng/openwrt/target/linux/brcm63xx-2.6/config: Enable PCI in kernel config, and compile wireless drivers
[11:24] <db90h> i also just updated the wireless-tools patch for v29 pre10, if you guys want it
[11:24] <nbd> is the new version any good?
[11:26] <db90h> testing now, had to do one more minor edit of makefile (hard coded 28 ver number in dir and lib name)
[11:26] <db90h> as far as if it's any good...
[11:26] <db90h> i dunno
[11:26] <db90h> ;)
[11:27] <db90h> i think since the version you guys had in kamikaze, v28, there is a new option to not include stuff that's not commonly used, for smaller binaries
[11:27] <db90h> ok, it works fine now.. just built ok
[11:28] <db90h> anyway, as of now it's in my svn, so you should be able to check out and slap into the kamikaze (old) trunk and white russian trunks if you want to update it in either
[11:28] <db90h> save someone 5 minutes someday
[11:29] <db90h> the only reason i was playing with it is cuz i had updated it for the the wl530-g images i'm building, hoping it would address a lack of proper interpretation of survey (iwlist scan) results
[11:30] <Kaloz> that's more like a driver problem
[11:30] <db90h> yea, i think so
[11:30] <db90h> i was desperate and wished for the impossible ;)
[11:30] <Kaloz> hehe :)
[11:31] <db90h> most of the wireless-tools stuff works fine, but iwlist scan returns some "unknown wireless token 0x####" where a found AP should be
[11:33] <florian__> ah ah !
[11:34] <nbd> :)
[11:36] <Kaloz> yo
[11:36] <florian__> nbd: I have tried to load a bit the other binary modules, some are just inserted well out of the box
[11:36] <nbd> interesting
[11:37] <nbd> have you tried running adsl stuff?
[11:37] <florian__> atmapi and bcmprocfs are inserted well just out of the box, I think blaadd should we well inserted too with the kmod-atm I forgot to install in my initramfs
[11:38] <nbd> what does blaadd do?
[11:38] <florian__> this is precisely what I want to know
[11:38] <florian__> there are several modules related to dsl : atmapi (self-explanatory), adsldd, blaad
[11:39] <nbd> isn't there also adslapi?
[11:40] <florian__> adsldd comes with an adsl_phy.bin which is probably the phy to upper layer
[11:40] <florian__> I found no adslapi
[11:41] <nbd> hmm, probably a different sdk then
[11:41] <florian__> or another implementation index
[11:42] <florian__> have you figured out why there are different binaries for different profiles ? 6348GW, 6348R ... ?
[11:43] <nbd> no idea
[11:45] <nbd> florian__: i'll give you a snapshot of bcmdrivers from the 3.03 sdk for testing
[11:45] <florian__> ok, I won't be able to do more testing before saturday
[11:45] <nbd> uh, not 3.03, but 3.05
[11:45] <florian__> actually, I will get back a huawei hg550
[11:46] <florian__> which is CFE based, so that I could also test if it works
[11:46] <nbd> florian__: http://downloads.openwrt.org/people/nbd/tmp/bcmdrivers_3.05.tar.gz
[12:00] <florian__> nbd: can you have a test at this tarball ? http://downloads.openwrt.org/people/florian/broadcom-brcm63xx-0.1.tar.bz2
[12:01] <nbd> are the makefiles included?
[12:01] <florian__> which ones ?
[12:01] <nbd> buildroot
[12:01] <nbd> and driver makefiles
[12:01] <florian__> driver makefiles, yes
[12:03] <florian__> for the buildroot-ng makefile, see this pastebin : http://pastebin.ca/152994
[12:03] <nbd> k
[12:11] <CIA-17> nbd * r4699 /branches/buildroot-ng/openwrt/package/madwifi/Makefile: skip a lot of useless junk in madwifi on linux 2.4
[15:16] <[florian]> re
[15:16] <[florian]> nbd: have you tested my tarball ?
[15:16] <nbd> not yet
[15:17] <[florian]> ok, no problem
[15:29] <florian> ticket #737 is not really a problem, right ?
[15:31] <nbd> probably just a matter of changing the chillispot init script
[15:50] <florian> I mean, giving 127.0.0.1 as nameserver shoud not be a problem if dnsmasq resolves
[15:51] <nbd> no, the problem is that 127.0.0.1 is handed out as dns server via dhcp
[15:51] <nbd> which of course won't work
[15:52] <florian> ah ok
[15:54] <CIA-17> florian * r4700 /packages/lang/sablevm-classpath/Makefile: Add missing preriquisites to sablevm-classpath
[15:55] <florian> [mbm]: you had problems compiling ipcad right ?
[15:55] <florian> [mbm]: tickets #733 reporst the same problem, can you have a try at the packages with your fresh ubuntu ?
[17:24] <[mbm]> florian: hmm squid shouldn't require openssl on the host, only that the openssl package is installed
[18:20] <CIA-17> nbd * r4701 /branches/buildroot-ng/openwrt/package/madwifi/ (8 files in 2 dirs): update madwifi to 0.9.2
[18:41] <florian> [mbm]: actually only openssl headers
[18:43] <florian> anyone already tried to x-compile isakmpd ?
[18:44] <[mbm]> florian: what I mean is that the openssl package should install those in staging_dir .. there's no point in having the system put them in /usr/include
[18:49] <florian> ok, so we could use the headers in staging_dir instead of requiring host side libs ?
[18:49] <[mbm]> right
[18:51] <florian> ok, I will fix this later
[18:51] <florian> any other package mentionned compiles fine ?
[18:53] <[mbm]> think ipcad changes depending on which gcc version is used
[18:54] <florian> preciselty
[18:54] <[mbm]> I really didn't have any trouble compiling most of the packages listed as buggy
[18:56] <florian> ok
[18:56] <florian> feel free to close the ticket if you think it is invalid
[18:57] <[mbm]> haven't closed it yet because I'm not sure why that person is getting those errors
[18:58] <florian> I think [olli]
[18:59] <florian> he asked me of taking care of them
[19:23] <florian> I am getting less and less fond of package maintaining
[19:24] <[mbm]> heh, kernel hacking is more fun?
[19:24] <florian> though it is more complicated and I learn step by step, definitively yes
[19:24] <[mbm]> well, at least packages on ng take far less time than whiterussian
[19:25] <florian> yes that's really what I appreciate
[19:26] <florian> and it now takes far less time adding this or that software
[19:34] <Bartman007> [mbm]: so what the deal with the wpa_supplicant error I ran into yesterday, you knew of it, but disappeared. I couldn't find any references to it anywhere on the forums or the dev site. I don't care if it won't be fixed for a while, I was just wondering what the status it.
[19:37] <[mbm]> bug I had stumbled across a few weeks back but haven't had time to fix yet
[19:38] <Bartman007> ok, thanks.
[19:38] <mtoledo> what's going on with http://wiki.openwrt.org/TableOfHardware?
[19:38] <Bartman007> so should I submit a bug report so it is recorded somewhere?
[19:39] <Bartman007> mtoledo: what do you mean?
[19:40] <Bartman007> ah. I see what you mean. it was working fine no more than a half hour ago
[19:40] <mtoledo> marcelo@marcelo:~/projetos/vbox_dynamic_route/trunk$ lynx -source http://wiki.openwrt.org/TableOfHardware | wc -l
[19:40] <mtoledo> 3774
[19:40] <mtoledo>
[19:40] <mtoledo> weird, in firefox it's not appearing.
[19:41] <thepeople_work> working for me in fireforx
[19:41] <Bartman007> this website glitch pops up every so after.
[19:41] <thepeople_work> firefox*
[19:41] <Bartman007> s/after/often/
[19:41] <Bartman007> first time it has actually happened to me though.
[20:00] <florian> I am sick of stupid people "why do you need to make your own linux kernel for bcm963xx"
[20:00] <florian> the question is obviously to make coffee
[20:01] <florian> the answer sorry
[20:01] <groz> #define COFFEE linux-bcm-963xx
[20:01] <groz> now shut up and go make coffee
[20:02] <groz> proper wording for an answer
[20:02] <groz> :)
[20:02] <blux> has someone the datasheet of an BCM4712 or so?
[20:02] <murb> blux: make groz some coffee.
[20:02] <groz> lol
[20:02] <groz> good morning strangers, i'm back in the world
[20:03] <groz> and working on a coffee right now
[20:03] <blux> Ok, comt to me, and i will serve you one
[20:04] <florian> blux: you can find quite easily the reference guide
[20:04] <Bartman007> heh, prereq detection of jikes has been modified/improved, it now bitches about a broken java compiler :-)
[20:04] <florian> datasheet will likely be available by signing the proper NDA
[20:05] <florian> this mostly exclude people that are not working for a company which has orderd 1000 < units from brcm
[20:06] <florian> and probably people more or less explicitely people working in oss projects
[20:07] <Bartman007> florian: you could always try to convince mbm's company to order the required units :-P
[20:07] <groz> that still wouldn't free up the information
[20:08] <groz> it would just mean somebody is caught between a rock and a hard place with access to nda material
[20:08] <groz> and the inability to 'let it out'
[20:08] <florian> precisely
[20:08] <Bartman007> yeah.
[20:08] <Bartman007> could always try the IBM BIOS reverse enginnering method :-)
[20:09] <groz> this is precisely the reason why with one of my clients, i am offsite, with no access to 'company internal' documentation
[20:09] <Bartman007> though the NDA probably bars discussing it at all
[20:10] <groz> bartman, years ago, i wasn involved in a 'clean room' reverse engineering project for the ibm vga bios
[20:10] <groz> it was a lot of work, not trivia
[20:10] <groz> and the corporate lawyers were breathing down our necks on a weekly basis
[20:10] <Bartman007> that's what it's called, couldn't remember the term clean room
[20:11] <groz> We literally worked in a separate office (next door to the main office)
[20:11] <groz> with no network connections into main office, and no phone connections to main office
[20:11] <groz> and no access to the library over there
[20:11] <groz> our door cards would not let us into main office
[20:12] <Bartman007> sounds rather cool except for the auditing. :-)
[20:12] <groz> It was a huge pain
[20:13] <groz> by the time we were done, I think we knew more about that vga bios than the folks that originally wrote it
[20:14] <Bartman007> I wouldn't doubt it.
[20:18] <Bartman007> Closest I've run into but on a smaller scale, was on my high school robotics team. The lead programmer became upset over a few things and hadn't check the control code back into the repository for a few weeks, so a few of us had to figure out what the code did based on the compiled code, the reaction of the robot, and a few clues about his general programming style.
[20:19] <Bartman007> after a while we said fsck it and rewrote most of the control routines because his coding style was crap.
[20:19] <florian> lol
[20:20] <Bartman007> florian: yeah, a lot simpler :-)
[20:20] <florian> Bartman007: not sure, I have been helping a friend in programming a robot quite hard actually
[20:21] <blux> hmm but BCM could sell more if thy put the information free
[20:21] <groz> depends on your perspetive blux
[20:22] <murb> blux: what happens if they don't actually own it to give it all away?
[20:22] <Bartman007> this was a PITA because he had written a fair amount of code that introduced a level of abstraction between the operator and the robot. the drivers had already had quite a bit of practice with this new code, then the bastard got upset because other people wanted to him to at least commit what he had so other people might be able to help speed it along.
[20:22] <groz> the competition could also figure it all out, and make cheaper / better devices with access to that
[20:22] <blux> I think a couple of people will build things with an BCm chip
[20:22] <Bartman007> blux: trade secrets are a very sensitive subject
[20:22] <groz> and when it comes to the software radio stuff, they cannot let it out, FCC rules
[20:23] <blux> I would do it, an small board with an BCM
[20:23] <florian> blux: probably
[20:23] <blux> hmm
[20:24] <Bartman007> blux: the number of boards they would sell to enthusiasts is a drop in the bucket compared to the sales they are achieving from the major players in the business
[20:28] <groz> pretty small drop, in a pretty big bucket
[20:41] <groz> anybody here worked with uclinux at all ?
[20:42] <wigyori> just played around with that, for that brecis core
[20:42] <groz> i'm wondering, is it possible to build with an x86 target, but nommu options, to work with uclinux on x86 while I wait for the real hardware to arrive ?
[20:42] <wigyori> well, not that much
[20:42] <wigyori> ;p
[20:42] <groz> all of the target hardware i have here right now has an mmu
[20:43] <groz> but, i got some coming soon that doesn't, just wondering if there is an easy way to 'be ready' before it actually arrives
[20:43] <murb> i was once tempted to try it on an old c2503
[20:43] <murb> but never got arround to it.
[20:43] <groz> and the ideal would be to build for x86 but actually build uclinux for it, not linux
[21:07] <blux> is thair an dev which gives 1111 ? the contrary of /dev/zero
[21:10] <blux> ?
[21:10] <blux> perhaps /dev/full ?
[21:12] <blux> I need to build an file full of FF with dd ore so
[21:15] <nbd> dd if=/dev/zero bs=1k count=1 | sed -e 's,\x00,\xff,g'
[21:16] <blux> ok
[21:16] <blux> thx
[21:30] <CIA-17> nbd * r4702 /branches/buildroot-ng/openwrt/toolchain/gcc/Makefile: fix gcc symlink install
[22:04] <florian> groz: I have tried to play a bit for the wrt54gp2, without success yet
[22:04] <florian> and also for the wrt54gx2 (which could run under normal linux though)
[22:10] <florian> sound quite painful
[22:11] <florian> there are lot of platform specific drivers
[22:41] <florian> nbd: can you try with pci enabled for bcm63xx ?
[22:44] <nbd> not right now
[22:45] <florian> ok no pb
[22:50] <blux> is someone interested in an ne debrick version?
[22:50] <blux> new
[22:52] <florian> did you made some changes ?
[22:52] <florian> nbd: looks like pci is not crashing the device
[22:52] <blux> yes
[22:52] <florian> nbd: how can I make a simple workaround for things like that :
[22:52] <florian> wl: Unknown symbol pci_register_driver
[22:52] <florian> wl: Unknown symbol sys_read
[22:52] <florian> wl: Unknown symbol sys_open
[22:52] <florian> wl: Unknown symbol alloc_skb
[22:53] <blux> new optins /slow it depends on thes patch which added a sleep during write operations
[22:53] <florian> ah good thing
[22:54] <blux> and not yes switchable an oly for SST flash an direkt veryfinging of the written Data
[22:55] <blux> every written byte get readed again and compaired against the orginal
[22:55] <florian> in case there was errors or ?
[22:55] <blux> I someone will have this as feature, i will do is as an option /veryfy ore so
[22:56] <blux> yes, to detect wrte errors
[22:56] <blux> write
[22:56] <florian> good idea
[22:56] <blux> writing then reading and compairing
[22:56] <florian> did you submit the patch to the original author ?
[22:57] <blux> no, I can't find him anywhere
[22:57] <blux> its ligthbulb but I did not find his e-mail address
[22:57] <florian> ok
[22:57] <florian> what about ranvik.net ?
[23:00] <blux> is this ligthbulb ?
[23:00] <blux> aka HairyDairyMaid ?
[23:00] <florian> yep this is his site I think
[23:02] <blux> ok
[23:03] <blux> he is russian ore so?
[23:03] <nbd> no
[23:04] <blux> what else?
[23:04] <blux> hes a nert http://ranvik.net/prosjekter-privat/wlan-bilder/100_1607.JPG
[23:04] <blux> hanging aut the bare board and soldering such an wire to it ;-)
[23:04] <blux> out
[23:06] <florian> nbd: you have not answered to my question ;)
[23:07] <florian> if you have just general tips and tricks
[23:11] <blux> If you go to address 0x1c000000 you will have 0000000000000. . on the flash chip address pins, orge will it be som kind of multiplexed?
[23:12] <blux> I mean if you are at 0x1c000000 all adress lines will be at logical 0
[23:28] <blux> ohh, I found an E-maqil address of Hairydairy. . .
[23:28] <blux> I was so blind!
[23:31] <db90h> groz: you would like a nommu uclinux target for openwrt?
[23:32] <groz> what would that be db90 ?
[23:33] <groz> my interest is actually in bringing up uclinux in advance of getting the target hardware, so i can validate a bunch of packages
[23:33] <groz> cuz i know there are issues in areas like fork
[23:33] <db90h> i am also working with uclinux right now
[23:33] <groz> what target are you using ?
[23:34] <db90h> not openwrt though.. for the wl530-g
[23:34] <db90h> if it's reasonable to build openwrt for such a system, using the uclinux patches, then i'd love to see it done
[23:36] <groz> well, that's kind of my plan, end up with a uclinux target within the -ng build environment
[23:36] <db90h> i think probably what it work take is apply the uclinux patches to the linux kernel in openwrt, redo any openwrt kernel patches that then need adjusting (if any), then start debugging and fixing up packages that don't work because of things like fork
[23:37] <groz> well, that's my real goal, to work with a couple things on the difference in fork
[23:37] <groz> so, to do that, i need a target that has no mmu
[23:37] <db90h> then you'd have to build flat binaries as well.. i really don't know everything necessary to achieve this. I'd like to better learn the reasons for its feasibility or infeasibility
[23:38] <groz> and was wondering if anybody has tried building uclinux for x86, with mmu disabled
[23:38] <groz> by disabling the mmu, you end up with the appropriate environment on the target
[23:38] <groz> to get into the issues of fork differences
[23:38] <db90h> is your eventual plan to get openwrt working with nommu, or are you just messing with uclinux?
[23:39] <groz> I have a hardware device arriving soon, that's got no mmu
[23:39] <groz> and currently runs uclinux based on a very hacked buildroot
[23:39] <groz> so, i'd like to just merge it into -ng
[23:40] <db90h> i'd love to see that done. from what nbd told me, it sounded it was a bit unrealistic.. but i am still very hazy in many areas
[23:40] <groz> well, that's just it, i'm not sure of what all the issues are, so, starting to look into it
[23:43] <groz> doesn't help that www.uclinux.org is dead
[23:45] <db90h> brb
[00:00] --- Wed Aug 30 2006