**** BEGIN LOGGING AT Wed Jul 28 02:59:56 2010
Jul 28 03:00:50 <swalker> has anyone been contacted about any openwrt issues wrt comcast's 6rd trial?
Jul 28 03:02:24 <builder> build #69 of adm5120 is complete: Failure [failed compile_6]  Build details are at http://tksite.gotdns.org:8010/builders/adm5120/builds/69
Jul 28 03:03:00 <thepeople> swalker: no, but I should try it someday
Jul 28 03:09:44 <swalker> thepeople: same here
Jul 28 03:10:09 <swalker> supposedly some known backfire wireless issue on the WRT160NL's and possibly one or two luci issues
Jul 28 03:10:29 <thepeople> well wireless is much improved since backfire was released
Jul 28 03:25:27 <builder> build #11 of at91 is complete: Failure [failed compile_6]  Build details are at http://tksite.gotdns.org:8010/builders/at91/builds/11
Jul 28 03:32:02 <builder> build #65 of pxcab is complete: Failure [failed compile]  Build details are at http://tksite.gotdns.org:8010/builders/pxcab/builds/65
Jul 28 03:48:45 <builder> build #74 of mpc52xx is complete: Failure [failed compile_6]  Build details are at http://tksite.gotdns.org:8010/builders/mpc52xx/builds/74
Jul 28 03:56:38 <builder> build #68 of ixp4xx is complete: Failure [failed compile_6]  Build details are at http://tksite.gotdns.org:8010/builders/ixp4xx/builds/68
Jul 28 07:04:13 <acoul> hello
Jul 28 08:34:06 <CIA-43> acoul * r22407 /trunk/target/linux/generic/patches-2.6.34/015-devtmpfs_ramfs.patch:
Jul 28 08:34:06 <CIA-43> generic/patches-2.6.34: Make devtmpfs available on (embedded) configurations without SHMEM/TMPFS,
Jul 28 08:34:06 <CIA-43> using ramfs instead. (gone mainline in kernel 2.6.35-r3)
Jul 28 09:23:45 <KanjiMonster> [florian]: ping
Jul 28 09:49:07 <[florian]> KanjiMonster: pog
Jul 28 11:40:41 <CIA-43> nbd * r22408 /trunk/package/mac80211/patches/ (5 files): ath9k: fix various calibration related bugs and clean up the code
Jul 28 11:48:13 <RealOpty> nbd, you still up coding?
Jul 28 11:48:45 <nbd> nah, i got myself some sleep and i just finished what i started yesterday
Jul 28 11:49:09 <RealOpty> for sure.
Jul 28 11:49:18 <RealOpty> morning :)
Jul 28 11:49:51 <nbd> morning ;)
Jul 28 11:51:37 <RealOpty> nbd, you have a minute to point me to the file that owrt uses (to create) for the rootfs_data?
Jul 28 11:51:57 <nbd> the mtd layer does that automatically
Jul 28 11:52:04 <nbd> you shouldn't mess with that part of the code
Jul 28 11:52:12 <RealOpty> I dont wanna mess with it :)
Jul 28 11:52:27 <nbd> if you want to avoid touching the board data, the kernel needs to create a partition for it
Jul 28 11:52:39 <RealOpty> I wanna read it and get a head start on helping Hauke :)
Jul 28 11:54:23 <RealOpty> Hauke mad me a patch to try out but after receiving more info from the dd-wrt developers i know that the patch will brick the devices cause not all the info is there.
Jul 28 11:55:02 <RealOpty> there is a part of the jffs offset that needs to be excluded too.
Jul 28 11:56:28 <nbd> ?
Jul 28 11:56:59 <RealOpty> hmm after looking at some dmesg for my owrt device, it seems as if rootfs_data is created with mtd (automatically) as you said
Jul 28 12:10:32 <RealOpty> nbd, is it possible to make a flash image that wont make a jffs and run off of /rom and /tmpfs ?
Jul 28 13:02:07 <RealOpty> nbd, so can ya point me to where the jffs partition making code is?
Jul 28 13:03:10 <jow_laptop> rgrep -in jffs2 build_dir/linux-*/linux-2.*
Jul 28 13:03:12 <jow_laptop> ;)
Jul 28 13:04:17 <RealOpty> jow_laptop, thanks ;p
Jul 28 14:33:06 <RealOpty> nbd, there is even source code to the CFE for this router :O
Jul 28 14:35:26 <mb__> RealOpty: Do you have a link to the sources for me?
Jul 28 14:35:39 <RealOpty> yes
Jul 28 14:36:10 <RealOpty> mb__, for this specific router? theres a whole page of routers with the sources.
Jul 28 14:36:30 <eltaco> Good Morning/Afternoon/Evening
Jul 28 14:36:46 <RealOpty> eltaco, mornin
Jul 28 14:36:49 <mb__> RealOpty: Well I was interested in the CFE sources.
Jul 28 14:36:50 <KanjiMonster> the cfe sources for bcm47xx are often available, but afaik never for bcm63xx
Jul 28 14:37:09 <eltaco> Anybody with a quick link how to set a dev jail to compile something else for backfire 10.03-rc2?
Jul 28 14:37:29 <RealOpty> mb__, http://kb.netgear.com/app/answers/detail/a_id/2649
Jul 28 14:37:29 <mb__> KanjiMonster: Yeah but they are often incomplete
Jul 28 14:37:40 <RealOpty> thats the page for all the routers.
Jul 28 14:37:41 <eltaco> I have been using http://downloads.openwrt.org/backfire/10.03-rc2/atheros/packages/
Jul 28 14:38:06 <RealOpty> heres the link for the source that contains the cfe for my router
Jul 28 14:38:10 <RealOpty> ftp://downloads.netgear.com/files/GPL/WNR834Bv2-V2.1.13_2.1.13_src.tar.zip
Jul 28 14:39:12 <eltaco> well.. I'm changing to the final version
Jul 28 14:39:24 <KanjiMonster> mb__: dunno, never tried to compile it (just browsed through the cfe for the asus wl500gp v1)
Jul 28 14:39:26 <eltaco> I'm new in the linksys world
Jul 28 14:41:27 <eltaco> I think I found t
Jul 28 14:41:29 <eltaco> it
Jul 28 14:41:31 <eltaco> :D
Jul 28 14:41:34 <eltaco> Bye guys, whch
Jul 28 14:41:37 <eltaco> whic
Jul 28 14:41:41 <eltaco> wish me luck
Jul 28 14:41:44 <eltaco> damn keyboard
Jul 28 14:42:12 <mb__> KanjiMonster: I have a more or less complete copy of the CFE which works and compiles up to 4354. It's put together from many different incomplete tarballs :)
Jul 28 15:06:23 <AndyI> Hi! All!
Jul 28 15:07:31 <AndyI> ping [florian]
Jul 28 15:10:23 <CIA-43> acoul * r22409 /trunk/package/compcache/files/compcache.init: package/compcache: clean unneeded swap initialization
Jul 28 15:21:04 <RealOpty> nbd, turns out that there is a way to recover the board_data partition if it does get erased... looks like i might need a jtag cable here soon :P
Jul 28 15:23:06 * RealOpty needs 5) 100 ohm resistors
Jul 28 15:24:19 <[florian]> AndyI: pong
Jul 28 15:24:37 <AndyI> <[florian]> hi!
Jul 28 15:25:19 <AndyI> <[florian]> have question about SPI driver for BCM6338
Jul 28 15:25:35 <[florian]> sure
Jul 28 15:27:00 <[florian]> AndyI: what is your question?
Jul 28 15:29:57 <AndyI> <[florian]> driver m25p80 Causes spi 2 times
Jul 28 15:30:14 <[florian]> AndyI: what do you mean?
Jul 28 15:30:52 <AndyI> first time send 1 byte  9f (rdid)
Jul 28 15:31:03 <AndyI> second read 5 byte answer
Jul 28 15:31:07 <[florian]> ah ok
Jul 28 15:31:48 <AndyI> in bcm63xx_spi this calls not separated
Jul 28 15:33:27 <AndyI> first call write answer in rx buffer
Jul 28 15:33:52 <AndyI> second call ?
Jul 28 15:37:38 <AndyI> The buffer already contains answer FLASH.
Jul 28 15:37:38 <AndyI> But all the same there is a call
Jul 28 15:37:38 <AndyI> bcm63xx_txrx_bufs
Jul 28 15:38:14 <AndyI> prepared CMD & MSG command
Jul 28 15:38:26 <[florian]> did you modify bcm63xx_spi.c?
Jul 28 15:38:44 <AndyI> yes
Jul 28 15:38:57 <[florian]> can you show it?
Jul 28 15:39:30 <AndyI> its draft only read ID from flash
Jul 28 15:40:27 <[florian]> no problem
Jul 28 15:41:13 <AndyI> send patch ?
Jul 28 15:42:23 <[florian]> openwrt.pastebin.com
Jul 28 15:44:24 <AndyI> ok wait please
Jul 28 15:44:46 <[florian]> no problem
Jul 28 15:56:57 <AndyI> http://openwrt.pastebin.com/b5xiaQS6
Jul 28 15:57:09 <AndyI> <[florian]> please looking
Jul 28 16:03:40 <AndyI> <[florian]> ping
Jul 28 16:03:49 <AndyI> http://openwrt.pastebin.com/QrRs46iu
Jul 28 16:07:40 <[florian]> AndyI: ok, and these are the only changes?
Jul 28 16:08:51 <AndyI> yes
Jul 28 16:09:07 <[florian]> other changes to bcm63xx_spi.c?
Jul 28 16:10:11 <AndyI> While is not present
Jul 28 16:12:33 <AndyI> in bcm63xx_spi_interrupt add hardcode rx data view
Jul 28 16:13:49 <AndyI> In bcm63xx_spi_interrupt anything it is not necessary to change yet
Jul 28 16:39:06 <CIA-43> jow * r22410 /packages/net/samba3/ (Makefile files/smb.conf.template): [packages] samba3: make security=share the default, user security is unsuitable due to missing user management capabilities on OpenWrt
Jul 28 17:08:32 <AndyI> <[florian]> ping
Jul 28 17:09:16 <[florian]> AndyI: pong
Jul 28 17:09:41 <AndyI> <[florian]> There are remarks?
Jul 28 17:09:57 <[florian]> AndyI: this looks fine
Jul 28 17:10:02 <[florian]> AndyI: does it work after the changes?
Jul 28 17:11:41 <realopty> damn
Jul 28 17:11:42 <AndyI> answer from flash present in RX data buff
Jul 28 17:11:49 <realopty> cant even brick my router if i wanted too :p
Jul 28 17:12:02 <[florian]> AndyI: ok, good
Jul 28 17:35:40 <AndyI> <[florian]> How the read data should be transferred by the second call?
Jul 28 17:39:35 <AndyI> And still I not absolutely understand as works completion.
Jul 28 17:39:35 <AndyI> In what distinction between INIT_COMPLETION and init_completion
Jul 28 17:55:52 <realopty> Hauke, hey bro.
Jul 28 17:56:38 <realopty> so i tried to flash it and it didnt accept firmware image so i believe that it needs a special kind of header.
Jul 28 17:57:23 <realopty> but i did find the source code of the factory firmware.
Jul 28 17:58:09 <Hauke> realopty: hi
Jul 28 17:59:07 <realopty> Hauke, did u receive my email that gave the link to the dmesg that dd-wrt spat out?
Jul 28 18:06:40 <Hauke> realopty: yes I got it
Jul 28 18:08:16 <realopty> okay well dont worry about this anymore. i dont want to waste your time, im sure there is better things that you can be working on for openwrt.
Jul 28 18:14:04 <realopty> Hauke, have you seen any devices with nvram and nvram_copy (a backup of the nvram on flash) ?
Jul 28 18:14:46 <xMff> does the CFE contains any references to the nvram_copy? If not its a OEM firmware thing you can ignore I think
Jul 28 18:16:05 <realopty> xMff, yes. every time i reboot it 'restores' the nvram says the CFE
Jul 28 18:16:13 <realopty> i have a log somewhere.
Jul 28 18:16:54 <realopty> xMff, would you like to see it?
Jul 28 18:18:23 <xMff> not really :)
Jul 28 18:18:32 <realopty> lol i didnt think so :P
Jul 28 18:21:26 <realopty> so here is the msg
Jul 28 18:21:29 <realopty> Restoring NVRAM...done
Jul 28 18:21:29 <realopty> CFE version 1.2.14 for BCM94780 (32bit,SP,LE)
Jul 28 18:21:46 <realopty> after the restore the CFE reboots
Jul 28 18:21:49 <xMff> you should find out when and why it restores the nvram
Jul 28 18:22:07 <xMff> there's probably some checksum or an embedded variable marking the priamry one dirty
Jul 28 18:23:08 <xMff> otherwise the nvram_copy stuff would be pointless if primary nvram is _always_ overwritten
Jul 28 18:23:17 <xMff> or "restored"
Jul 28 18:24:06 <realopty> only happens with openwrt. the factory firmware dosnt overwrite the nvram, it actually makes it a partition
Jul 28 18:24:31 <xMff> so it restores the _copy from the original one?
Jul 28 18:27:21 <realopty> xMff, i believe that it restores 'nvram' from the backup 'nvram_copy'
Jul 28 18:27:44 <realopty> in openwrt im not get nvram changes to be saved after reboot
Jul 28 18:27:54 <realopty> i can commit them and then read them
Jul 28 18:27:55 <xMff> well either way, it messes with both blocks so you need to exclude them I guess
Jul 28 18:28:03 <realopty> but once i reboot its gone
Jul 28 18:28:04 <realopty> yeah
Jul 28 18:28:21 <realopty> heres what the origional firmware said for mtd partions
Jul 28 18:28:24 <realopty> 0x000000420000-0x0000007f0000 : "rootfs_data"
Jul 28 18:28:24 <realopty> 0x0000007f0000-0x000000800000 : "nvram"
Jul 28 18:28:29 <realopty> hmm wait
Jul 28 18:28:53 <realopty> thats openwrt
Jul 28 18:32:41 <realopty> 0x007e0000-0x007f0000 : "nvramcopy"
Jul 28 18:32:41 <realopty> 0x007f0000-0x00800000 : "nvram"
Jul 28 18:34:11 <xMff> oh, they're next to each other
Jul 28 18:34:47 <xMff> can't you just try to shift down the nvram partition start offset by 0x10000 bytes?
Jul 28 18:36:07 <realopty> hmm looking at the info from the openwrt log that i pasted above... it would seem as if the nvramcopy is getting errased insted of the actual nvram ?
Jul 28 18:36:16 <xMff> yes
Jul 28 18:36:33 <xMff> it seems to covery the last block of the jffs2 fs
Jul 28 18:36:37 <xMff> *cover
Jul 28 18:36:46 <xMff> why the hell do I write covery every time
Jul 28 18:36:58 <realopty> LOL
Jul 28 18:37:50 <realopty> so rootfs_data is created auto? then how would i go about telling it to skip the last 0X10000 bytes?
Jul 28 18:38:08 <xMff> by making the nvram partition start 0x10000 bytes earlier I believe
Jul 28 18:39:32 <realopty> hmm but then wouldnt nvram show doubles cause they would conflict right?
Jul 28 18:39:52 <xMff> no, it would only process the copy one
Jul 28 18:43:33 <xMff> quick hack: http://openwrt.pastebin.com/FX1zeCZt
Jul 28 18:44:13 <realopty> xMff, lol i was just reading that SAME section of code
Jul 28 18:44:36 <xMff> a real solution would require some detection logic. e.g. read the second last erase block and look for a FLSH magic at offset 0x8000 within it
Jul 28 18:46:38 <realopty> xMff, thanks for the patch. ive been waiting for a good reason to reflash this device heheh
Jul 28 18:47:10 <xMff> if the change above works, you should end up with an mtd partition covering 0x20000 bytes beginning at 0x7e0000 on the mtd device
Jul 28 18:47:35 <xMff> it will contain two nvram structures
Jul 28 18:48:01 <realopty> sweet.
Jul 28 18:48:37 <xMff> one at 0x7e8000 (0x8000) and one at 0x7f8000 (0x18000)
Jul 28 18:48:39 <realopty> ok you patch says svn r 22379 . the svn im at is 22388
Jul 28 18:48:45 <xMff> doesn't matter
Jul 28 18:48:45 <realopty> patch should be ok?
Jul 28 18:48:47 <realopty> kk
Jul 28 18:49:16 <xMff> keep in mind that its a hack
Jul 28 18:49:24 <realopty> indeed.
Jul 28 18:49:29 <xMff> don't expect nvram writes to work reliably
Jul 28 18:49:43 <xMff> but it should work well enough to read nvram which is all thats needed to detect the board
Jul 28 18:50:09 <realopty> yeah im ok with that. i just dont want the cfe taking twice as long too boot up :)
Jul 28 18:51:04 <realopty> i have a svn folder that i did a make clean / and maybe a kernel_clean or something, should i have to do make target/clean ??
Jul 28 18:51:09 <realopty> there is no build_dir
Jul 28 18:51:36 <xMff> no
Jul 28 18:51:53 <xMff> btw, is usually enough to run  make target/linux/clean world  to just rebuild the kernel
Jul 28 18:54:19 <Memphiz> anybody here who has experience with max3232 ttl shifter which only works in one direction? (this thing fucks me up ... can read the boot messages, but when i try to hit any keys it only sends crap ... good old times where rs232 interfaces delivered +-12V and not the punky little voltages the current mainboards deliver)
Jul 28 18:56:47 <roh> Memphiz yes. they work fine if used correctly.
Jul 28 18:57:00 <roh> your problem sounds more like 'somebody fogot to add or enable a pullup
Jul 28 18:58:36 <Memphiz> mhh its working normal on all other boxes i have ... only with the 1043nd it doesn't
Jul 28 19:00:06 <Memphiz> the circuit isn't a self development ... its a bought kit ... there are pullups on the pcb as i can see
Jul 28 19:00:52 <Memphiz> mhh maybe its a matter of cable length ...
Jul 28 19:01:40 <Memphiz> btw ... the ttl shifter is working fine if i shorten rx and tx on the ttl side ... it echos back at all baud rates ...
Jul 28 19:01:59 <roh> on the ttl-side yes. keep it short. its cmos levels there. the max doesnt change that. short means 'as short as possible', stay below a meter or less. if you need 20cm, use 25, not 35.
Jul 28 19:02:11 <realopty> xMff, just wanna confirm. in your patch all you added was " * 2 " correct?
Jul 28 19:02:21 <xMff> yes
Jul 28 19:02:29 <realopty> kk.
Jul 28 19:02:31 <Memphiz> roh: mhh good point
Jul 28 19:02:43 <Memphiz> its 35 cm ... but i can try shortening this part ...
Jul 28 19:02:57 <realopty> patch was for 2.6.32 but im running kernel 2.6.35
Jul 28 19:02:59 <roh> in case of doubt: use a scope.
Jul 28 19:04:10 <Memphiz> yes that would be the best debugger ... but i don't have one in range :(
Jul 28 19:05:01 <Memphiz> for now i build a kernel which has a lower baud rate on the console ... maybe this could also be an indicator for to long cables if it runs with lower speed
Jul 28 19:05:49 <xMff> realopty: well, it should be trivial to rebase ;)
Jul 28 19:05:56 <roh> i usually would not do that. if the kernel cant print fast enough, funny things happen
Jul 28 19:06:32 <Memphiz> roh: mhh how funny ... bricking funny?
Jul 28 19:07:07 <roh> depends on the hw i guess. usually worst case: crash
Jul 28 19:07:32 <Memphiz> mhh ok ... note to myself ... don't touch cmdline of kernel ... :D
Jul 28 19:07:36 <roh> best case: it drops the buffer and only reports that it dropped it.
Jul 28 19:08:25 <roh> good hw isnt brickable anyhow.
Jul 28 19:09:06 <Memphiz> yes i know ... but as long as the serial isn't working for me, it is brickable (though the 1043nd 's jtag interface doesn't allow me to write the flash ... its readonly *sigh*)
Jul 28 19:09:48 <roh> jtag access means access to ram on the cpu. load a binary that can handle the flashing and the serial.
Jul 28 19:10:30 <roh> flashing via jtag and no helper-executable on the target cpu is usually highly timing critically and more complex
Jul 28 19:11:41 <Memphiz> but loading a binary means to know how to init the flash right? its alot reverse engineering ... of course it is theoretically unpossible to brick such SOCs ... but for now i think i shorten the cables and try to get bootloader access working ;)
Jul 28 19:12:55 <roh> helper executables can be either simple self-hacked stuff intended for that. also possibilities are things like for example a fitting uboot or other bootloader capable of flashing. or even a full linux kernel and ramdisk. but the last one takes ages to upload via jtag, so usually i see people using uboot or similar stuff.
Jul 28 19:13:10 <roh> flash unlocking is documented by jedec.
Jul 28 19:13:40 <roh> its the nand or nor controller you need to know how to work. but thats the case regardless of what you use for flashing.
Jul 28 19:13:47 <roh> aslong as you dont unsolder it
Jul 28 19:14:49 <Memphiz> mhh your right ... i remember doing flashing with helper agent some years ago (using a PEEDI linux - base programmer) ... there where some initialisations for some registers and then it worked very well and fast ...
Jul 28 19:15:14 <roh> its a henn/egg problem. if you can brick something, you seem to have code to write to flash somehow already.
Jul 28 19:15:17 <Memphiz> but that was an pcb which was developed by us ... not by strangers ... that did make the things easier ;)
Jul 28 19:16:01 <Memphiz> except bricking it by using an battle ax ;)
Jul 28 19:16:56 <roh> true. but i guess nobody would ask for a sw-fix then ;)
Jul 28 19:17:20 <Memphiz> i'm not sure about that *hrhr*
Jul 28 21:43:28 <realopty> cshore_, ping
Jul 28 21:43:40 <cshore_> pong realopty
Jul 28 21:43:53 <realopty> cshore_, on the page http://nuwiki.openwrt.org/doc/uci/dropbear
Jul 28 21:43:56 <realopty> for the options
Jul 28 21:44:15 <cshore_> realopty: yes?
Jul 28 21:44:21 <realopty> is the PasswordAuth option 'on' or '1'?
Jul 28 21:44:30 <cshore_> either is acceptable to uci
Jul 28 21:44:35 <realopty> okies
Jul 28 21:44:38 <cshore_> both mean true
Jul 28 21:45:04 <realopty> cshore_, what you working on?
Jul 28 21:45:14 <cshore_> currently my bills
Jul 28 21:45:35 <realopty> thats always good to work on them hehe
Jul 28 21:50:54 <realopty> xMff, !
Jul 28 21:51:09 <realopty> i mean ping :P
Jul 28 21:51:25 <realopty> xMff, you wrote this page right? http://nuwiki.openwrt.org/toh/netgear/wnr854t_glod
Jul 28 21:53:59 <realopty> anyways to the point... the router ive been trying to get openwrt to run on looks exactly like that one. at least the case is the same :P
Jul 28 23:59:34 <builder> build #67 of kirkwood is complete: Success [build successful]  Build details are at http://tksite.gotdns.org:8010/builders/kirkwood/builds/67
Jul 29 00:39:50 <builder> build #66 of rb532 is complete: Success [build successful]  Build details are at http://tksite.gotdns.org:8010/builders/rb532/builds/66
**** ENDING LOGGING AT Thu Jul 29 02:59:57 2010