**** BEGIN LOGGING AT Fri Aug 02 02:59:59 2013
Aug 02 03:24:30 <builder> build #325 of ppc40x is complete: Failure [failed compile_5]  Build details are at http://buildbot.openwrt.org:8010/builders/ppc40x/builds/325
Aug 02 03:27:39 <builder> build #306 of rb532 is complete: Failure [failed shell_12]  Build details are at http://buildbot.openwrt.org:8010/builders/rb532/builds/306
Aug 02 03:31:19 <builder> build #306 of ppc44x is complete: Failure [failed shell_12]  Build details are at http://buildbot.openwrt.org:8010/builders/ppc44x/builds/306
Aug 02 04:20:09 <builder> build #320 of uml is complete: Failure [failed compile_5]  Build details are at http://buildbot.openwrt.org:8010/builders/uml/builds/320
Aug 02 04:42:18 <MartijnVdS> g
Aug 02 05:04:54 <builder> build #327 of cobalt is complete: Failure [failed compile_5]  Build details are at http://buildbot.openwrt.org:8010/builders/cobalt/builds/327
Aug 02 05:09:20 <builder> build #290 of sibyte is complete: Failure [failed shell_12]  Build details are at http://buildbot.openwrt.org:8010/builders/sibyte/builds/290
Aug 02 05:09:58 <builder> build #328 of lantiq is complete: Failure [failed compile_5]  Build details are at http://buildbot.openwrt.org:8010/builders/lantiq/builds/328
Aug 02 08:09:57 <middey> good morning
Aug 02 08:10:19 <middey> are there any way's to the a uboot before flashing it to the device ?
Aug 02 08:11:32 <MartijnVdS> to do what with uboot?
Aug 02 08:15:58 <middey> i builded the uboot for the easybox 904 from gpl sources and i get an .elf file, Can i run that on the device when it already started ?
Aug 02 08:18:01 <middey> I think i should start explain my plan from the first idea.
Aug 02 08:18:50 <middey> I have the easybox 904 with a uboot that require a password if you enter the menu
Aug 02 08:19:11 <middey> i have the sources of it too and i found that check
Aug 02 08:20:50 <middey> i change it from password_check_function != 0 to password_check_function == 0
Aug 02 08:20:58 <middey> and builded the u-boot
Aug 02 08:21:23 <middey> and now my question is if i can test that in any way before i flash that to my device
Aug 02 08:21:43 <middey> because my device has no jtag and so i don't want to brick it
Aug 02 08:22:17 <middey> I hope i have it explained good enough what do you think MartijnVdS
Aug 02 08:22:46 <MartijnVdS> you could dump the current uboot, and compare
Aug 02 08:23:08 <MartijnVdS> (copy from flash to somewhere else)
Aug 02 08:33:53 <middey> ok but what of the generated files i should compare the u-boot.bin the u-boot.bin.phy the u-boot.elf the u-boot.lq the u-boot.lq.pad.128k or the u-boot.lq.pad.256k ?
Aug 02 08:34:51 <MartijnVdS> I'd check which one is most like the one already in flash
Aug 02 09:11:48 <middey> u-boot.lq.pad.128k and  the u-boot.lq.pad.256k have exactly the same size as th dumped uboot on flash.
Aug 02 09:12:12 <middey> the uboot from flash and the two above are filled with zero bytes in the end
Aug 02 09:16:33 <middey> i think the uboot.bin and the dumped are the similarest becaused they have a few zero byte's in the end and after that is in the dumpe uboot a loot of FF bytes
Aug 02 09:23:15 <middey> hm wait i was wrong it seems like the dumped u-boot have a header that is only in the u-boot.lq.pad.128k and  the u-boot.lq.pad.256k. So the question is what should i use of these two files
Aug 02 09:24:23 <middey> ok the both files are the same just renamed :)
Aug 02 09:25:50 <middey> ok and the uboot.lq is identical with the  u-boot.lq.pad.128k and  the u-boot.lq.pad.256k. But it is smaller it is not filled with zerobytes at the end
Aug 02 10:02:43 <OpenWrt-Commits> nbd r37653 trunk/package/kernel/mac80211/patches/ 523-mac80211_configure_antenna_gain.patch 300-pending_work.patch * mac80211: backport a few upstream fixes
Aug 02 10:12:21 <builder> build #339 of orion is complete: Failure [failed compile_8]  Build details are at http://buildbot.openwrt.org:8010/builders/orion/builds/339
Aug 02 11:41:07 <russell--> r35704 explains the vlan numbering change (from, like, a long time ago!)
Aug 02 11:41:46 <russell--> doesn't explain the wgt634u switch not working on 3.10.4 though
Aug 02 11:42:41 <KanjiMonster> wgt634 was bcm5365?
Aug 02 11:42:49 <russell--> yes, i think so
Aug 02 11:43:39 <KanjiMonster> is it identified as 5365?
Aug 02 11:44:17 <russell--> [    6.960000] roboswitch: found a 5325! It's a BCM5365. at eth0
Aug 02 11:44:55 <KanjiMonster> huh, roboswitch? wasn't that supposed to be 3.8- and 3.10 was supposed to be b53/swconfig?
Aug 02 11:45:20 <russell--> that message is from 3.8.13
Aug 02 11:45:47 <KanjiMonster> and I was talking about 3.10, because you were talking about 3.10 ;)
Aug 02 11:46:03 <russell--> i didn't see a message emitted in 3.10
Aug 02 11:46:11 <russell--> 3.8 at least told me what it found
Aug 02 11:46:33 * russell-- has console logs, goes back to look closer
Aug 02 11:46:54 <KanjiMonster> anything from b53?
Aug 02 11:47:10 <KanjiMonster> it should have at least tried to probe
Aug 02 11:47:16 <russell--> i can say that only eth0 can be configured with dhcp, udhcpc -i eth0.N doesn't result in any responses
Aug 02 11:48:42 <KanjiMonster> that wasn't my question ;p
Aug 02 11:49:06 <russell--> for 3.10, all i see is b44 messages
Aug 02 11:49:11 <russell--> nothing b53
Aug 02 11:49:30 <russell--> it does create vlan interfaces, but they don't do anything
Aug 02 11:50:16 <KanjiMonster> yes, if the switch isn't detected then the vlans can't get enabled in the switch
Aug 02 11:51:54 <KanjiMonster> do you see anything about probing the mii bus?
Aug 02 11:51:59 <KanjiMonster> in the kernel log
Aug 02 11:52:08 <KanjiMonster> or can you paste the bootlog somewhere?
Aug 02 11:52:43 <russell--> https://personaltelco.net/~russell/wgt634u-3.10.4-boot.log
Aug 02 11:53:33 <russell--> [    5.180000] libphy: b44_eth_mii: probed
Aug 02 11:55:33 <KanjiMonster> [    5.184000] b44 ssb0:0 (unregistered net_device): attached PHY driver [Generic PHY] (mii_bus:phy_addr=1:1e)
Aug 02 11:56:02 <KanjiMonster> I think I have an idea what's broken
Aug 02 11:56:25 <russell--> awesome
Aug 02 11:56:32 <russell--> (because i don't ;-)
Aug 02 11:57:04 <KanjiMonster> likely the bcm5365 uses a phyid that the b53 driver doesn't recognise
Aug 02 12:05:19 <russell--> b53_priv.h:     BCM5365_DEVICE_ID = 0x65,
Aug 02 12:09:41 <KanjiMonster> phyid, not device id
Aug 02 12:15:36 <russell--> there are two listed in b53_mdio.c
Aug 02 12:16:53 <KanjiMonster> try that one: http://inuyasha.ath.cx/~jonas/b53_add_0040_phyid.patch
Aug 02 12:17:08 <russell--> okay
Aug 02 12:23:44 <russell--> oops, build errors
Aug 02 12:25:21 <KanjiMonster> wouldn't wonder :p
Aug 02 12:25:34 <KanjiMonster> can you fix it yourself?
Aug 02 12:25:43 <KanjiMonster> or should I take a look at it
Aug 02 12:26:05 <KanjiMonster> currently lack a tree to build test
Aug 02 12:28:27 <russell--> minor typo, trying again
Aug 02 12:29:45 <KanjiMonster> great (minor typos are my specialty ;)
Aug 02 12:30:32 <russell--> s/id2/id3/ in one spot
Aug 02 12:33:43 <russell--> oh, and this:
Aug 02 12:33:45 <russell--> drivers/net/phy/b53/b53_mdio.c: In function 'b53_phy_driver_register':
Aug 02 12:33:45 <russell--> drivers/net/phy/b53/b53_mdio.c:411:1: error: label 'out' defined but not used [-Werror=unused-label]
Aug 02 12:33:48 <russell--> cc1: all warnings being treated as errors
Aug 02 12:33:59 <KanjiMonster> just delete the out label
Aug 02 12:34:03 <russell--> right
Aug 02 12:38:59 <russell--> built, flashing now
Aug 02 12:43:11 <russell--> oops ... literally ;-)
Aug 02 12:43:36 <KanjiMonster> where?
Aug 02 12:44:01 <russell--> https://personaltelco.net/~russell/wgt634u-3.10.4-boot2.log
Aug 02 12:45:04 <Devastator> now that I have some experience with device porting on openwrt I will try to port my modified WRT310N, it's a "good" router
Aug 02 12:45:31 <KanjiMonster> russell--: but it looks like we are getting somewhere: [    5.188000] b53_common: found switch: BCM5365, rev 0
Aug 02 12:46:32 <russell--> indeed
Aug 02 12:46:51 <KanjiMonster> ah, I think I see a potential issue
Aug 02 12:48:29 <KanjiMonster> yes, that's likely the issue
Aug 02 12:49:32 <KanjiMonster> hm, wait, no
Aug 02 12:49:48 <KanjiMonster> that was an old source tree, it's already fixed
Aug 02 12:50:34 <russell--> ah
Aug 02 12:59:16 * russell-- has to sleep now, back in about 6hrs
Aug 02 12:59:40 <MartijnVdS> nn
Aug 02 14:21:02 <Pteridium>  
Aug 02 14:21:19 <blogic>  
Aug 02 14:22:09 <stintel>   
Aug 02 14:22:15 <DonkeyHotei>  
Aug 02 14:22:18 <Pteridium> KanjiMonster: have you took a look to the mail i sent about bcm6368 and FPU emulation?
Aug 02 14:23:22 <KanjiMonster> Pteridium: I haven't looked too cloesely
Aug 02 14:24:24 <Pteridium> ok.
Aug 02 14:25:33 <Pteridium> Now i'm generating an image with latest trunk in Debian 6.0.7 x86-64.
Aug 02 14:26:57 <Pteridium> hope the problem is the PC/linux distro instead bcm6368
Aug 02 14:39:58 <Pteridium> KanjiMonster: in the VR-3025un (bcm6368 based) the lan leds are controlled by gpio instead switch. There is any way to associate they with the switch?
Aug 02 14:40:34 <Pteridium> is there*
Aug 02 14:41:17 <KanjiMonster> depends
Aug 02 14:41:32 <Pteridium> ?
Aug 02 14:42:45 <KanjiMonster> depends on if this is the internal switch, and which gpios these are
Aug 02 14:43:23 <Pteridium> internal switch; gpios 5 to 8
Aug 02 14:43:48 <KanjiMonster> 5 to 8? not 6 to 9?
Aug 02 14:45:23 <Pteridium> i think that are 5 to 8 but i could be wrong
Aug 02 14:45:32 <Pteridium> one moment..
Aug 02 14:46:40 <Pteridium> you are right, 6 to 9
Aug 02 14:47:06 <KanjiMonster> I am working on a pinmux driver that should make that easy
Aug 02 14:48:05 <Pteridium> ok, i'll wait. Thanks for the advice.
Aug 02 14:48:38 <Pteridium> if you need to test something tell me it
Aug 02 15:06:23 <OpenWrt-Commits> hauke r37654 trunk/package/kernel/broadcom-diag/Makefile * broadcom-diag: increase version number
Aug 02 15:11:16 <builder> build #291 of xburst is complete: Failure [failed compile_9]  Build details are at http://buildbot.openwrt.org:8010/builders/xburst/builds/291
Aug 02 15:11:20 <builder> build #244 of mpc52xx is complete: Failure [failed compile_5]  Build details are at http://buildbot.openwrt.org:8010/builders/mpc52xx/builds/244
Aug 02 15:18:23 <builder> build #229 of octeon is complete: Failure [failed shell_12]  Build details are at http://buildbot.openwrt.org:8010/builders/octeon/builds/229
Aug 02 15:44:12 <OpenWrt-Commits> hauke r37655 trunk/package/kernel/broadcom-diag/src/diag.c * broadcom-diag: add support for the ASUS RT-N12
Aug 02 15:47:25 <strasidlo> blogic: any hits to solve ash: job control issue? where should I look for to fix it?
Aug 02 16:10:49 <builder> build #9 of imx23 is complete: Failure [failed compile_4]  Build details are at http://buildbot.openwrt.org:8010/builders/imx23/builds/9
Aug 02 16:16:32 <OpenWrt-Commits> hauke r37656 trunk/target/linux/ generic/config-3.8 generic/config-3.9 generic/config-3.6 generic/config-3.10 * kernel: add missing config option
Aug 02 16:51:55 <OpenWrt-Commits> hauke r37657 trunk/target/linux/generic/config-3.10 * kernel: add missing config option
Aug 02 17:06:26 <zinx> oh finally
Aug 02 17:06:42 <zinx> KanjiMonster: you were right, wrong gpio mode.  pcimux isn't actually parsed by the current pinmux.c :/
Aug 02 17:07:21 <zinx> adding it fixed my problem
Aug 02 17:25:18 <zinx> i supposed i shouldn't have assumed it worked properly :/
Aug 02 17:25:23 <zinx> erh, suppose
Aug 02 18:33:16 <blogic> zinx: this is on ramips
Aug 02 18:49:46 <builder> build #354 of at91 is complete: Failure [failed compile_5]  Build details are at http://buildbot.openwrt.org:8010/builders/at91/builds/354
Aug 02 18:58:56 <zinx> blogic: yes
Aug 02 18:59:32 <zinx> blogic: pcimux is simply not in the pinmux.c patch, i added it in the same manner gpiomux is there and it works fine
Aug 02 19:14:51 <blogic> ok
Aug 02 19:14:55 <blogic> mail me the patch please
Aug 02 19:15:18 <blogic> on which soc is this ?
Aug 02 19:28:31 <zinx> blogic: RT3883
Aug 02 19:29:18 <middey> blogic i unbricked my easybox 904 now and have telnet acces. i already dumped the flash and edited the bootlog in the wiki. What should i do next ?
Aug 02 19:29:22 <zinx> blogic: locally i just updated the patch using quilt refresh, i doubt it's in the format you want :/
Aug 02 19:32:36 <blogic> zinx: well
Aug 02 19:32:40 <blogic> give it to me anyhow
Aug 02 19:32:47 <blogic> zinx: better than nothing
Aug 02 19:37:55 <zinx> blogic: heh ok
Aug 02 19:38:34 <zinx> blogic: zenthought.org/tmp/0002-MIPS-ralink-add-pinmux-driver.patch
Aug 02 19:39:08 <zinx> (i would not normally distribute a changed patch in that form, for hopefully obvious reasons)
Aug 02 19:39:52 <zinx> it defaults to making the pci pins be gpio
Aug 02 19:43:37 <zinx> oh i left debug code in that, beware
Aug 02 20:07:20 <OpenWrt-Commits> hauke r37658 trunk/package/kernel/linux/modules/usb.mk * kernel: fix usb-chipidea compilation with kernel <= 3.9
Aug 02 20:08:28 <OpenWrt-Commits> hauke r37659 trunk/package/kernel/linux/modules/video.mk * kernel: add missing module to video-core for kernel < 3.6
Aug 02 20:08:53 <russell--> KanjiMonster: /me is back again
Aug 02 20:14:02 <OpenWrt-Commits> hauke r37660 trunk/target/linux/ generic/config-3.6 generic/config-3.3 * kernel: add missing config options
Aug 02 20:17:44 <builder> build #328 of cobalt is complete: Failure [failed compile_5]  Build details are at http://buildbot.openwrt.org:8010/builders/cobalt/builds/328
Aug 02 21:40:51 <builder> build #340 of orion is complete: Failure [failed compile_5]  Build details are at http://buildbot.openwrt.org:8010/builders/orion/builds/340
Aug 02 21:42:45 <builder> build #307 of rb532 is complete: Failure [failed shell_12]  Build details are at http://buildbot.openwrt.org:8010/builders/rb532/builds/307
Aug 02 21:44:33 <builder> build #307 of ppc44x is complete: Failure [failed shell_12]  Build details are at http://buildbot.openwrt.org:8010/builders/ppc44x/builds/307
Aug 02 22:58:29 <builder> build #321 of uml is complete: Failure [failed compile_5]  Build details are at http://buildbot.openwrt.org:8010/builders/uml/builds/321
Aug 03 00:26:05 <russell--> KanjiMonster: is there an imbalance in b53_phy_driver_register ... it seems like only one (the first successfully found) is registered, but all three are unregistered unconditionally in the b53_phy_driver_unregister function ... is that going to be a problem?
Aug 03 00:40:55 <builder> build #300 of avr32 is complete: Failure [failed compile_9]  Build details are at http://buildbot.openwrt.org:8010/builders/avr32/builds/300
Aug 03 01:53:33 <builder> build #291 of sibyte is complete: Failure [failed shell_12]  Build details are at http://buildbot.openwrt.org:8010/builders/sibyte/builds/291
**** ENDING LOGGING AT Sat Aug 03 03:00:00 2013