**** BEGIN LOGGING AT Wed Nov 14 03:00:00 2012
Nov 14 09:22:26 <Wipster> Morning, you remember quite a while ago we talked about reworking the TI atm stuff, would this still be worth attempting?
Nov 14 09:23:54 <[florian]> Wipster: probably not
Nov 14 09:24:10 <[florian]> Wipster: it would be a fun project for sure, but testing for regression would be too long imho
Nov 14 09:27:03 <[florian]> Wipster: fortunately the big complicated stuff (atm) is already using linux-atm so that facilitates stuff
Nov 14 11:05:33 <russell--> Hauke: the wgt634u flash situation is somewhat more confusing than i laid out in the email
Nov 14 11:08:23 <Hauke> russell--: I applied a patch by b.sander from ticket #11420: http://nbd.name/gitweb.cgi?p=openwrt.git;a=commitdiff;h=0cddb5e96a70c9d1449da52ecbb9d99f8d13974d
Nov 14 11:08:29 <Hauke> could this cause your problems?
Nov 14 11:09:26 <russell--> maybe, see, openwrt has been reporting 0xa0000 forever (i grepped my rather large console log), but as far as i can tell, cfe and a "config" space should only occupy 0x80000.
Nov 14 11:10:13 <russell--> however, when i flash the current images and see the cfe partition up to 0x80000 and then flash from that, i get a nonbooting device
Nov 14 11:11:08 <Hauke> russell--: do you have a boot log of the original vendor firmware
Nov 14 11:11:18 <russell--> cfe is unhappy (can't find elf or something) and it bails out at a CFE> prompt
Nov 14 11:11:42 <russell--> i do, actually, in fact i have them for about 30 different devices
Nov 14 11:12:19 <russell--> interestingly the first 3 128k blocks (the CFE) are always identical
Nov 14 11:12:38 <russell--> but the next block ("config") has some variability.
Nov 14 11:13:23 <russell--> i was kinda paranoid in the early days and made a habit of storing dumps of flash on every one
Nov 14 11:13:56 * russell-- goes to find an example bootlog to paste somewhere
Nov 14 11:14:12 <Hauke> the linux mainline kernel contains a flash map for this devices and it says that cfe is 0x60000 in size and then is a config partition of 0x20000  and after that comes the linux kernel arch/mips/bcm47xx/wgt634u.c
Nov 14 11:14:37 <russell--> that looks consistent with the stock firmware, yes.
Nov 14 11:14:47 * russell-- has no idea what's in "config"
Nov 14 11:15:08 <russell--> it isn't nvram stuff, that's stashed near the top
Nov 14 11:15:51 <Hauke> the wgt634u does not use nvram but it uses some other way to store data
Nov 14 11:16:08 <Hauke> the wgt634u is a strange device, it is different from all the others ;-)
Nov 14 11:16:16 <russell--> http://sprunge.us/QcCV
Nov 14 11:16:50 <russell--> yes it is ;-)
Nov 14 11:20:29 <russell--> when i flash (using sysupgrade or mtd -r write) from a device showing the linux partition starting at 0x80000, the reboot stalls in CFE with the message:
Nov 14 11:20:33 <russell--> Loading: Failed.
Nov 14 11:20:35 <russell--> Could not load : Not an ELF-format executable
Nov 14 11:24:54 <Hauke> russell--: do you know where cfe places the image when you flash from cfe?
Nov 14 11:25:53 <russell--> i recover by flashing from CFE, so it should be easy to find out ;-)
Nov 14 11:26:27 <russell--> is mtd just writing a raw image?
Nov 14 11:26:54 <russell--> so i can look for the pattern of the start of the image file on flash?
Nov 14 11:27:34 <russell--> "flash -noheader"
Nov 14 11:27:38 <Hauke> yes it should just write a raw image
Nov 14 11:32:12 <russell--> ah yeah, there is an ELF at 0x80000, but HDR0 is at 0xa0000
Nov 14 11:34:12 <russell--> aha
Nov 14 11:34:37 <russell--> from CFE, i flash a .bin (which starts with the ELF)
Nov 14 11:35:05 <russell--> sysupgrade uses a trx which starts with HDR0
Nov 14 11:35:38 <russell--> (i think sysupgrade is ultimately calling "mtd -r write foo.trx linux")
Nov 14 11:36:28 <Hauke> russell--: ah so if you would use the .bin file for sysupgrade it would work?
Nov 14 11:36:41 <russell--> maybe so
Nov 14 11:36:56 * russell-- tries
Nov 14 11:37:33 <russell--> hmm
Nov 14 11:38:00 <russell--> i'm not sure that's a good solution though
Nov 14 11:38:15 <russell--> since it'll be tricky for people to transition
Nov 14 11:38:19 <Hauke> so I will revent this commit http://nbd.name/gitweb.cgi?p=openwrt.git;a=commitdiff;h=0cddb5e96a70c9d1449da52ecbb9d99f8d13974d and then one should use the .trc image for sysupgrade
Nov 14 11:38:30 <Hauke> s/revent/revert
Nov 14 11:38:50 <russell--> they'll have to look at the offset of the "linux" partition to know what to flash
Nov 14 11:43:04 <Hauke> as this change was just introduced 2 weeks ago I do not think there are many users on this device
Nov 14 11:44:10 <russell--> the change to .bin doesn't really save ay thing, HDR0 ends up in the same place
Nov 14 11:44:53 <russell--> i think reverting is probably the right thing
Nov 14 11:45:20 <russell--> with the trx flash, i guess we never touch the ELF header
Nov 14 11:47:34 <russell--> i'm going to try sysupgrading with the .bin
Nov 14 11:48:10 <russell--> just flashing the first one (with 0x80000 linux partition) now, then will flash the .bin
Nov 14 11:49:06 <strasidlo> hello guys, do you know where or why is package libipq missing in openwrt?
Nov 14 11:49:32 <strasidlo> where is package or ..*
Nov 14 11:52:40 <russell--> Hauke: yeah, sysupgrade doesn't like the image type
Nov 14 11:52:55 <russell--> "Invalid image type. Please use only .trx files"
Nov 14 11:53:20 <russell--> mtd looks for the trx header
Nov 14 11:53:29 <russell--> so, i guess reverting is the right solution
Nov 14 13:02:17 <apocn> is it possible to trigger a script when the interface link is detected?
Nov 14 13:02:33 <apocn> like with ethtool
Nov 14 13:19:39 <dangole> ping dape
Nov 14 13:25:05 <jwendell> apocn, look at /etc/hotplug.d/iface
Nov 14 13:40:29 <apocn> jwendell, yes but I only see ifup and ifdown
Nov 14 13:41:01 <apocn> interface can be up without being connected, so it wont be triggered on link detection.
Nov 14 13:41:42 <apocn> my real problem is that I launch wpa_supplicant on startup and if the cable is not connected it stops retrying after 60 seconds
Nov 14 13:42:09 <apocn> if I connect the cable after 60 seconds it won't send the EAPOL-Start frame in order to start the Authentication handshake
Nov 14 13:47:12 <jwendell> somehow netifd does that
Nov 14 13:47:25 <jwendell> so, take a look at how netifd handles this
Nov 14 13:59:23 <apocn> ok, I did some tests with ifup and ifdown and it doesnt work
Nov 14 14:19:02 <OpenWrt-Commits> juhosg r34200 trunk/ scripts/om-fwupgradecfg-gen.sh target/linux/ar71xx/image/Makefile scripts/om2p-fwupgradecfg-gen.sh * scripts: rename om2p-fwupgradecfg-gen.sh to more generic om-fwupgradecfg-gen.sh
Nov 14 14:35:33 <tonikasch> bye
Nov 14 14:46:58 <Wipster> when iteratly making a patch and checking compile will clean, cleanout any source changes or just the compiled bits?
Nov 14 15:31:05 <DonkeyHotei> [Wed 2012-11-14 01:22:28 AM PST] <Wipster> Morning, you remember quite a while ago we talked about reworking the TI atm stuff, would this still be worth attempting? <------ what did you have in mind?
Nov 14 15:33:37 <Wipster> DonkeyHotei, a clean up and sort out to start with. working through checkpatch.pl stuff atm
Nov 14 15:34:27 <DonkeyHotei> that sounds like a massive undertaking for little gain
Nov 14 15:35:09 <DonkeyHotei> i'd rather there be a way to update it for the later ar7 chips that allowed larger dsp firmware
Nov 14 15:35:29 <DonkeyHotei> and the holy grail would be a driver for the 1350A wifi
Nov 14 15:35:57 <DonkeyHotei> actiontec made a device called the pk5000
Nov 14 15:36:09 <DonkeyHotei> 32MiB flash, 64MiB ram
Nov 14 15:36:16 <DonkeyHotei> ar7
Nov 14 15:36:20 <Wipster> DonkeyHotei, true but I dont know enough about the stack atm to undertake a rewrite, hopefully this will give me some insight
Nov 14 15:36:43 <DonkeyHotei> but using 8.x of the dsp firmware, which is too big to fit on older chips
Nov 14 15:37:13 <DonkeyHotei> it would be an awesome device for openwrt if only the 1350A wifi could work
Nov 14 15:38:02 <DonkeyHotei> i have seen fcc documents that show actiontec will soon also have a PK5001A device
Nov 14 15:38:19 <Wipster> DonkeyHotei, see I have been onto them about that, their source only has the 0.1 sangam atm code, but the bin in the base directory is the same as that of a reported version 8 from a ticket
Nov 14 15:38:20 <DonkeyHotei> that one will be amazon or newer
Nov 14 15:38:51 <DonkeyHotei> i was the one who reported version 8 and attached the binary to the ticket
Nov 14 15:39:47 <DonkeyHotei> i tried that binary on an older device, and it rejected the firmware as exceeding the max size
Nov 14 15:40:32 <Wipster> DonkeyHotei, ahhh good to know. Well I shall get back onto them, see if there is an updates sangam code to go with, I dont believe it would be used with one ment for dsp v4
Nov 14 15:40:50 <DonkeyHotei> maybe it could be a 7200/7300 difference, but i never verified that
Nov 14 15:41:23 <DonkeyHotei> "them" ?
Nov 14 15:44:34 <DonkeyHotei> Wipster: "them" ?
Nov 14 15:46:14 <Wipster> DonkeyHotei, I emailed Actiontec about the latest GPL source and if it was really the latest, they got back to me. So I will be a bit more specific about the versions now.
Nov 14 15:49:23 <DonkeyHotei> Wipster: their gpl-releasing people really don't know what they're doing. their tarballs don't compile
Nov 14 15:50:14 <DonkeyHotei> and generally, they're not obligated to release the ti atm/dsp stuff because they received it under nda, not gpl
Nov 14 15:51:21 <DonkeyHotei> we have what we have because netgear and/or linksys forgot to remove it from a tarball or two
Nov 14 15:52:28 <Wipster> DonkeyHotei, yeh thats fair enough. Does it hurt to try though?
Nov 14 15:53:19 <DonkeyHotei> it's a waste of time trying to get more ar7 stuff from actiontec. if anyone could provide it, it would be lantiq afaik
Nov 14 15:54:01 <DonkeyHotei> the 7200 chip in the pk5000 has the infineon logo, not the TI logo
Nov 14 15:54:34 <Wipster> DonkeyHotei, ah a chip post buyout, dont have one of them
Nov 14 15:54:44 <DonkeyHotei> blogic: you kinda disappeared last night
Nov 14 15:55:20 <DonkeyHotei> Wipster: as i said, the actiontec pk5000, where i got the 8.x dsp fw
Nov 14 16:19:55 <DonkeyHotei> Wipster: do you have any ar7 devices that have the adm6996L switch chip? what about the adm6996M?
Nov 14 16:20:49 <DonkeyHotei> [florian]: i was talking to someone in #ar7 recently that has an ar7 device with a broadcom robo-switch
Nov 14 16:20:58 <Wipster> DonkeyHotei, not sure off hand I can check later
Nov 14 16:22:13 <DonkeyHotei> [florian]: actually a pretty common device i've physically seen installed all over the place as it's the one handed out by Megapath Networks, one of the major dedicated-line adsl isp's here
Nov 14 16:23:23 <[florian]> DonkeyHotei: did he try kmod-switch/robo on this?
Nov 14 16:25:15 <DonkeyHotei> [florian]: we didn't get that far so far. it does not run linux stock, and the bootloader is a mystery
Nov 14 16:25:25 <[florian]> oh ok
Nov 14 16:26:58 <DonkeyHotei> he was going to get a jtag dump of the stock rom to me, but he hasn't been on in a while
Nov 14 16:30:27 <written_tabletpc> dev.openwrt.org <-- 502 error :-(
Nov 14 16:42:59 <DonkeyHotei> [florian]: that person is in .ch, btw
Nov 14 16:45:40 <[florian]> more in my TZ :)
Nov 14 16:47:40 <DonkeyHotei> [florian]: btw, based on the gpio mapping failure on the linksys, it seems the voip hardware in it is connected by gpio rather than by vlynq as i previously assumed
Nov 14 16:50:10 <[florian]> ok
Nov 14 16:52:51 <DonkeyHotei> and where is blogic?
Nov 14 16:53:19 <DonkeyHotei> other than geographically, that is
Nov 14 18:19:03 <dwmw2_gone> do we support making the Japanese images for Buffalo WZR-HP-G301NH and friends?
Nov 14 18:19:11 <dwmw2_gone> it won't load the normal non-JP firmware
Nov 14 18:24:33 <rundfreifunk> via tftp? problem with flashing? may the same problems/ hints as written at http://wiki.openwrt.org/toh/buffalo/wzr-hp-g300nh2#flash.procedure
Nov 14 18:27:39 <written_tabletpc> https://gist.github.com/4073861 - anyone can fix this build error?
Nov 14 18:31:14 <rundfreifunk> please install xkbcomp (your logfile says:checking for xkbcomp... not_found)
Nov 14 18:31:47 <written_tabletpc> yeah, i know this
Nov 14 18:32:37 <written_tabletpc> it's the default xkbdata/Makefile from openwrt
Nov 14 18:36:22 <written_tabletpc> maybe blogic ?
Nov 14 18:37:24 <rundfreifunk> i think thats the xkbcomp at your linux system, which is missing.. so apt-get install it
Nov 14 18:37:48 <written_tabletpc> no, it's a build-system problem
Nov 14 18:39:18 <rundfreifunk> hm but yes, your "linux system" IS the "build-system"
Nov 14 18:39:45 <written_tabletpc> no, openwrt build-system
Nov 14 18:40:08 <written_tabletpc> and xkbcomp is compiled fine in the openwrt build-system
Nov 14 18:41:07 <written_tabletpc> so xkbcomp is there
Nov 14 18:41:25 <written_tabletpc> but somehow xkbdata does not now about it :-(
Nov 14 18:42:56 <rundfreifunk> oh
Nov 14 18:45:52 <DonkeyHotei> blogic hasn't been responding in this channel for 21 hours
Nov 14 19:12:37 <written_tabletpc> bad :-(
Nov 14 19:43:01 <apocn> is it possible to trigger a script when the interface link is detected? (not when the interface goes up, but when you actually connect the cable and there is link)
Nov 14 20:32:35 <apocn> also, is it possible to control the LEDs of the device?
**** ENDING LOGGING AT Thu Nov 15 02:59:58 2012