**** BEGIN LOGGING AT Sun Sep 15 02:59:59 2013 Sep 15 03:23:34 build #341 of avr32 is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/avr32/builds/341 Sep 15 03:30:49 build #368 of ppc40x is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/ppc40x/builds/368 Sep 15 04:53:24 build #353 of x86 is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/x86/builds/353 Sep 15 06:14:33 build #349 of ar7 is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/ar7/builds/349 Sep 15 06:18:52 build #288 of iop32x is complete: Failure [failed shell_12] Build details are at http://buildbot.openwrt.org:8010/builders/iop32x/builds/288 Sep 15 07:19:48 build #331 of xburst is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/xburst/builds/331 Sep 15 08:20:01 build #289 of ep93xx is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/ep93xx/builds/289 Sep 15 08:21:07 build #326 of ixp4xx is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/ixp4xx/builds/326 Sep 15 08:34:16 build #323 of kirkwood is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/kirkwood/builds/323 Sep 15 09:12:35 Hauke I still have a few questions about diag and switch, but no rush, ping me whenever you have time :) Sep 15 09:12:44 hauke r37991 packages/libs/orbit2/patches/020-build-fix.patch * orbit2: fix build with recent glib version Sep 15 09:18:58 hauke r37992 packages/ (12 files in 8 dirs) * packages: remove empty files and directories. Sep 15 09:40:09 hauke r37993 trunk/target/linux/brcm47xx/patches-3.10/710-bgmac_fix_internal_switch_initialization.patch * brcm47xx: bgmac: fix internal switch initialization Sep 15 09:40:46 zajec: thank you for the patch Sep 15 09:41:06 zajec: is ethernet now working on your device? Sep 15 09:42:03 Hauke, this patch fix issues that you cannot connect to your device? Sep 15 09:43:08 FreeArtMan: yes it fixes the problem that ethernet did not work on BCM4749, BCM5357, BCM53572 with internal switch Sep 15 09:43:41 the internal switch is mostly used by devices only supporting 100MBit/s Sep 15 09:44:43 yesterday i was trying to compile openwrt for brcm47xx and wasnt able to connect to device Sep 15 09:44:48 can it be the issue? Sep 15 09:46:08 yes it could be Sep 15 09:48:02 ok i will try now Sep 15 10:29:04 FreeArtMan: too early Sep 15 10:29:08 Hauke: ethernet is working Sep 15 10:29:12 Hauke: BCM5325 isn't Sep 15 10:29:28 zajec: ok Sep 15 10:29:32 Hauke: i don't get any packets because of Sep 15 10:29:33 vc5 |= VC5_DROP_VTABLE_MISS; Sep 15 10:29:46 if I remove that line, packets are transmitted, but switch doesn't work Sep 15 10:29:55 i mean it ignores VLAN tags Sep 15 10:30:18 I send ping from the CPU (router) to the VLAN id 1 (LAN network) and packets arrive to my notebook with VLAN tag Sep 15 10:30:26 zajec: have you asked KanjiMonster if he knows anything about it Sep 15 10:30:31 so switch doesn't analyze VLAN tag and doesn't router them to the correct ports Sep 15 10:30:43 Hauke: he didn't point anything Sep 15 10:30:48 he knows about this issue Sep 15 10:30:59 we agree that this VC5_DROP_VTABLE_MISS is correct Sep 15 10:31:05 there must be some different issue Sep 15 10:31:08 at least the BCM5356 has a BCM5325 with core rev 3, it could be that more things are changed Sep 15 10:31:09 will debug it Sep 15 10:31:20 zajec: the problem might be that the bcm5325 variant in bcm5357/58 uses a slightly different vlan register format Sep 15 10:32:12 I don't know if this is already fixed in b53 but likely not. So if the vlans don't get setup correctly, and you tell the switch to drop anything that isn't allowed by the vlans set up, then logically nothing will go through. Sep 15 10:35:13 zajec: could you log all calls of chipphywr() and chipphyrd() in etcgmac.c Sep 15 10:35:32 then we see what the working switch driver by broadcom does Sep 15 10:38:35 zajec: http://pastebin.com/MgCVvgRU is what I'm talking about Sep 15 10:39:05 KanjiMonster: I implemented that and nothing changed Sep 15 10:39:13 oh, okay Sep 15 10:39:24 this should just effect BCM5356, but zajec has a different SoC Sep 15 10:39:27 i'll take a look at all of that :) Sep 15 10:39:56 Hauke: not necessarily, look at the si_corerev() call above that, that might also return >= 3 Sep 15 10:39:56 KanjiMonster: but b53 sets some more bit than the robo driver does in other parts Sep 15 10:40:07 btw. it's a Sep 15 10:40:09 [ 3.932000] b53_common: found switch: BCM5325, rev 0 Sep 15 10:40:27 KanjiMonster: but that is just done when we have a robo core, which I haven't seen Sep 15 10:40:42 zajec: bcm5325 has neither a chip id nor revision id register, so rev will always be 0 for that one. Sep 15 10:41:13 broadcom does this: mii_rreg(robo, PAGE_STATUS, REG_STATUS_REV, &robo->corerev, 1); Sep 15 10:41:48 PAGE_STATUS 0x01, REG_STATUS_REV 0x50 Sep 15 10:41:52 Hauke: yes, but it returns 0 (as all attempts to read non existent registers) Sep 15 10:42:38 KanjiMonster: you are reading a different register Sep 15 10:42:46 in b53_read8(dev, B53_MGMT_PAGE, B53_REV_ID, &dev->core_rev); Sep 15 10:43:12 B53_MGMT_PAGE 0x02, B53_REV_ID 0x40 Sep 15 10:43:50 let me read 0x1 and 0x50 Sep 15 10:44:50 KanjiMonster: in the code you posted, isn't ((vid >> 4) << 12)); always 0 ? Sep 15 10:44:51 i have this dump E900 can't just boot from elf using tftp Sep 15 10:44:56 not enough memry :/ Sep 15 10:46:14 Hauke: bcm5325 allows you to setup a "prefix" for the vlan ids Sep 15 10:46:18 this is it Sep 15 10:46:27 ok Sep 15 10:46:34 so you could in theory decide to use vlans 16-31, or 32-48 etc pp Sep 15 10:47:15 GUYS Sep 15 10:47:23 [ 3.912000] b53_common: switch rev?: 4 Sep 15 10:47:35 b53_read8(dev, 0x1, 0x50, &dev->core_rev); Sep 15 10:47:37 pr_info("switch rev?: %i\n", dev->core_rev); Sep 15 10:49:35 zajec: ah Sep 15 10:49:40 zajec: this must be a bcm5325 specific register, because for 5395 it isn't defined, and for bcm53115 it's the "PBPTRFIFO Status Register 0" Sep 15 10:49:49 that bcmrobo.c isfunny Sep 15 10:50:10 they read core rev only if there isn't robo_reset nvram entry Sep 15 10:50:13 weird logic Sep 15 10:50:21 this register is only read for internal switches in brcmrobo.c Sep 15 10:50:42 yeah Sep 15 10:50:51 so they should check if this is external or internal Sep 15 10:50:54 using some bit status Sep 15 10:50:56 not the nvram entry ;) Sep 15 10:51:17 makes more sense for me Sep 15 10:51:17 yeh, but this also works mostly ;-) Sep 15 10:51:34 KanjiMonster: bcmrobo.c prefers ssb/bcma core revision over that register status Sep 15 10:51:40 yes Sep 15 10:51:43 KanjiMonster: robo->corerev = si_corerev(sih); Sep 15 10:52:00 KanjiMonster: do 5395 and 53125 have a ROBO_CORE_ID core? Sep 15 10:52:25 5395 and 53125 are external switch chips Sep 15 10:52:46 oh, we can't really access ssb/bcma on b53_switch_detect Sep 15 10:52:48 they don't have "cores" Sep 15 10:52:48 In think this robo core rev way only used on very old SoCs Sep 15 10:52:50 not in a clena way at least Sep 15 10:53:17 also for all modern cores 0x2, 0x40 is the "Chip Revision ID Register" Sep 15 10:53:27 s/cores/chips/ Sep 15 10:53:33 ok Sep 15 10:54:43 Hauke: is your code for rev 4 already in the OpenWrt source? Sep 15 10:54:55 (commited?) Sep 15 10:54:58 no Sep 15 10:55:04 can you send me patch? Sep 15 10:55:19 you have it, right? Sep 15 10:55:48 zajec: http://pastebin.com/Ysexi54i Sep 15 11:05:00 KanjiMonster: do you know if all bcm5325 switches have the rev at this different place or just these internal switches? Sep 15 11:05:20 no idea Sep 15 11:05:38 bcm5325 belongs to the few switch chips where I don't have a full register set available Sep 15 11:05:46 ok Sep 15 11:18:11 Hauke: KanjiMonster: did you get my message? Sep 15 11:18:13 success :) Sep 15 11:18:45 zajec_: The last I received was (12:55:19 PM) zajec: you have it, right? Sep 15 11:21:29 well, it's working :) Sep 15 11:21:31 the switch Sep 15 11:22:31 zajec_: nice, what have you changed? Sep 15 11:22:36 Hauke: btw, something like this should work without introducing platform specific code into b53 (which I'd like to avoid as much as possible ;) for the 5356 case: http://pastebin.com/m1QrY4pX Sep 15 11:25:46 just your changes Sep 15 11:25:51 + rev detection Sep 15 11:25:56 * zajec_ leaving for a shopping Sep 15 11:26:03 will provide patch after 15 minutes Sep 15 11:26:07 *int 15 mintues? Sep 15 11:26:36 build #38 of imx23 is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/imx23/builds/38 Sep 15 11:41:59 build #313 of ar71xx is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/ar71xx/builds/313 Sep 15 12:10:21 Hauke: what is that BCM5365? Sep 15 12:10:36 is that SoC? Sep 15 12:10:42 with what switch? Sep 15 12:11:57 i meant BCM5356 Sep 15 12:16:56 the BCM5356 is a low cost SoC with an integrated switch Sep 15 12:17:51 zajec_: http://pastebin.com/Yj6YPDqe Sep 15 12:19:57 the BCM5365 is a switch ;-) Sep 15 12:19:58 all BCM535x/BCM536x are low cost socs with integrated switches Sep 15 12:20:27 bcm5365 is also a SoC with integrated switch ;) Sep 15 12:30:15 Hauke: that look slike a BCM53572 with a BCM5325 Sep 15 12:30:20 Hauke: that dmesg from pastebin Sep 15 12:30:36 Hauke: where is there any BCM5356/65? Sep 15 12:32:34 oh, is the http://git.mirror.nanl.de/openwrt/trunk.git down? Sep 15 12:33:38 zajec_: Yes now I also see that, BCM5356 is written on the chip Sep 15 12:34:02 the chip id 0x5356 probably does not exists, google has no results for "Found chip with id 0x5356" Sep 15 12:34:08 so, it's a matter of package i guess Sep 15 12:34:32 "package 0x0B" Sep 15 12:35:36 #define BCM5356C0_PKG_ID 0xb /* 5356c0 package id */ Sep 15 12:36:03 hmm this is strange there are some references to this chipid in the broadcom source code Sep 15 12:37:03 do you mean #define BCM5356_CHIP_ID 0x5356 ? Sep 15 12:37:08 probably some never released stuff Sep 15 12:37:24 could be that no device with this chipd was ever released Sep 15 12:41:08 KanjiMonster: how should we do the switch rev reading? Sep 15 12:41:32 do you think it is save to read the rev from these other regs when we have a BCM5325? Sep 15 12:41:53 * zajec_ did it that way Sep 15 12:44:00 Hauke: should be harmless. Sep 15 12:44:13 the revision is used only for that vlan register layout in the original code Sep 15 12:48:36 ah yes, now ethernet also works for me Sep 15 12:50:24 Hauke: give me 5 minutes, i'm testing b53 right now Sep 15 13:00:34 ohh, what the hell Sep 15 13:00:36 http://pastebin.com/a020edpd Sep 15 13:00:40 can you help me with that? Sep 15 13:02:19 build #314 of au1000 is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/au1000/builds/314 Sep 15 13:03:13 i tried rm -fR build_dir/toolchain-mipsel_gcc-4.6-linaro_uClibc-0.9.33.2/ ... Sep 15 13:04:45 same problem Sep 15 13:05:13 damn, I knew doing "git pull" is a bad idea... Sep 15 13:05:20 it was working fine untile that Sep 15 13:06:00 why OpenWrt has to cause such problem all the time :/ Sep 15 13:06:37 the gcc version was changed a week ago Sep 15 13:07:24 sure, but why it can't just recompile whatever is needed :/ Sep 15 13:08:34 normally that works, but when the compiler was changed it sometimes does not ;-) Sep 15 13:08:58 oh great Sep 15 13:09:01 what about that: Sep 15 13:09:02 > make menuconfig Sep 15 13:09:03 /bin/sh: /home/zajec/openwrt/openwrt-new.git/staging_dir/host/bin/find: No such file or directory Sep 15 13:09:05 /bin/sh: /home/zajec/openwrt/openwrt-new.git/staging_dir/host/bin/find: No such file or directory Sep 15 13:09:20 was removing a build_dir and staging_dif (both) a bad idea? Sep 15 13:09:42 then it should rebuild everything Sep 15 13:09:48 i hoped for Sep 15 13:09:58 try removing tmp Sep 15 13:10:00 but now me whole configuration got broken Sep 15 13:10:14 oh, not it regenerates sth Sep 15 13:10:18 ok Sep 15 13:10:20 have it Sep 15 13:10:21 thx Sep 15 13:11:05 zajec_: KanjiMonster: these are the patches I have: http://pastebin.com/ufj49aXN and http://pastebin.com/M0FfBbVx Sep 15 13:12:01 Hauke: i like this "b53: fix vlan write for BCM5325" Sep 15 13:12:10 Hauke: i like this: "entry = (untag << VA_UNTAG_S) | members;" Sep 15 13:12:15 not duplication :) Sep 15 13:12:33 Hauke: i think you could just remove braces around "entry |= VA_VALID_25_R4 | vid << VA_VID_HIGH_S;" and the second one Sep 15 13:12:44 Hauke: in case one crazy day we decide to push b53 mainstream ;) Sep 15 13:12:49 to Linus's tree Sep 15 13:12:52 build #398 of at91 is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/at91/builds/398 Sep 15 13:13:19 I like braces around if blocks when an else is used Sep 15 13:13:59 well, it's just against kernel coding style :/ Sep 15 13:15:23 Hauke: i'm not sure about "b53: detect rev of BCM5325" Sep 15 13:15:53 Hauke: what about putting that "return b53_read8(dev, B53_STAT_PAGE, B53_REV_ID_25, &dev->core_rev);" near to the Sep 15 13:15:55 + if (is5356(dev)) { Sep 15 13:15:56 + dev->core_rev = 3; Sep 15 13:16:09 maybe we could have that core_rev hacks at one place? :) Sep 15 13:16:45 Hauke: and there is one thing about your earlier patch I would like to change Sep 15 13:16:58 Hauke: i'm not sure if the "is5356" is a good name Sep 15 13:17:08 Hauke: could you replace it with for example "is_soc_5356"? Sep 15 13:17:14 I removed the 5356 stuff Sep 15 13:17:19 ah, ok Sep 15 13:17:28 when we see such an SoC we can add it again Sep 15 13:17:38 I assume we will never see such an SoC Sep 15 13:17:44 so your BCM5325 works fine without that "dev->core_rev = 3;"? Sep 15 13:17:48 is core_rev detected fine? Sep 15 13:17:52 using B53_REV_ID_25? Sep 15 13:18:36 it is a BCM5356C0 Sep 15 13:19:02 and my devices also detects a BCM5325 rev 4 Sep 15 13:19:07 Hauke: yes, please remove the braces ;p (also maybe call it BCM5325 revison 3+ or so). And for the second patch the comment style is above, with length info (also call it "Revision ID register for BCM5325" or "BCM5325 Revision ID register") Sep 15 13:19:11 great! Sep 15 13:20:38 KanjiMonster: what do you mean by "calling it"? Do you mean commit message ("b53: fix vlan write for BCM5325")? Sep 15 13:20:49 yes Sep 15 13:20:58 ok Sep 15 13:21:07 to be specific that not all bcm5325's are affected Sep 15 13:21:12 Hauke: if you have a moment, please apply KanjiMonster's changes and push it Sep 15 13:21:13 but only a subset of it Sep 15 13:21:23 Hauke: i can't wait for testing it :) Sep 15 13:21:27 yeah Sep 15 13:21:29 that's right Sep 15 13:22:23 Hauke: that gcc change you were talking about... does it mean Linaro gcc used for cross-compiling was updated? like in my request https://lists.openwrt.org/pipermail/openwrt-devel/2013-August/020958.html ? Sep 15 13:22:39 yes Sep 15 13:22:53 hooray, that's great! :) Sep 15 13:22:53 (but not for AA) Sep 15 13:22:58 sure Sep 15 13:23:08 sane :) Sep 15 13:27:31 Hauke: can you ping me here after pushing changes? Sep 15 13:27:36 going to eat a dinner :) Sep 15 13:30:04 hauke r37994 trunk/target/linux/generic/files/drivers/net/phy/b53/b53_common.c * kernel: b53: fix vlan write for BCM5325 revison 3+ Sep 15 13:31:18 ah, we have a got Sep 15 13:31:20 *bot Sep 15 13:31:23 forgot :D Sep 15 13:31:40 hauke r37995 trunk/target/linux/ generic/files/drivers/net/phy/b53/b53_regs.h generic/files/drivers/net/phy/b53/b53_common.c * kernel: b53: detect revision of BCM5325 Sep 15 13:31:50 zajec_: both are in now Sep 15 13:32:36 Hauke: thx Sep 15 13:32:41 waiting for git sync Sep 15 13:33:02 does trac support git? Sep 15 13:33:06 could we switch to git? Sep 15 13:33:10 zajec_: thanks also from my side for the bgmac problem Sep 15 13:33:34 Hauke: no problem :) Sep 15 13:33:39 Hauke: glad we have it working now Sep 15 13:33:51 lets close some tickets ;-) Sep 15 13:33:56 are there any other bcm47xx issues left? Sep 15 13:33:59 apart from wifi? Sep 15 13:34:05 Hauke: yeah! Sep 15 13:34:09 * zajec_ leaving for a dinner Sep 15 13:34:10 * zajec_ afk Sep 15 13:38:14 build #285 of mcs814x is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/mcs814x/builds/285 Sep 15 13:38:16 build #279 of gemini is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/gemini/builds/279 Sep 15 13:39:02 zajec_: more than 128MB of ram is not supported Sep 15 13:40:35 zajec_: BCM4706 with two BCM4331 is getting very hot Sep 15 13:47:01 zajec_: led handling is somehow wrong in b43, I think the api between driver and ucode changed with ucode 5.X Sep 15 13:47:11 zajec_: brcmsmac does it in a different way Sep 15 13:49:09 build #371 of ramips is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/ramips/builds/371 Sep 15 13:50:35 zajec_: for the bcm4331 heat problem temperature management probably needs to be implemented (i.e. reading out core temp, and if its too hot reducing the number of tx chains until it cooled down enough) Sep 15 13:53:00 Hauke: i'm not sure if Broadcom let firmware/hardware handle LEDs anymore Sep 15 13:53:12 Hauke: it looks like they handle it in wl.ko only Sep 15 13:54:18 github mirror is slooow :/ Sep 15 13:54:23 zajec_: I do not know how it is done now, but b43 does it the wrong way, we often had it that the firmware took control over wrong gpio like the switch reset gpio ;-) Sep 15 13:54:33 yeah Sep 15 13:54:46 zajec_: http://git.openwrt.org/ is fast 10 minutes Sep 15 13:55:11 and the github mirror is a mirror of the http://git.openwrt.org/ git Sep 15 13:56:10 i didn't know ahout that one Sep 15 13:56:21 nice! Sep 15 14:01:09 hm Sep 15 14:01:12 not sure where i fialed Sep 15 14:01:16 but network doesn't work for me ;) Sep 15 14:03:10 zajec_: are you sure a kernel with b53 including the patches was build? Sep 15 14:03:48 zajec_: don't use the github mirror Sep 15 14:03:52 no Sep 15 14:03:59 build system didn't refresh sources Sep 15 14:04:00 damn Sep 15 14:06:50 really... why OpenWrt doesn't notice that target/linux/generic/files/drivers/net/phy/b53/b53_common.c was modified Sep 15 14:07:00 why it can't simple re-compile b53 correctly Sep 15 14:07:27 should I "rm -fR build_dir/target-mipsel_uClibc-0.9.33.2/linux-brcm47xx/linux-3.10.10/" ? Sep 15 14:08:51 yes Sep 15 14:09:07 or "make target/linux/clean" Sep 15 14:09:28 is this not something that should be done automatically? Sep 15 14:10:26 KanjiMonster: will this patch or a similar one be added to OpenWrt soon: http://patchwork.openwrt.org/patch/2554/ ? Sep 15 14:12:20 Hauke: not yet, as there are several things in it I'm not sure about yet Sep 15 14:18:17 build #370 of cobalt is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/cobalt/builds/370 Sep 15 14:20:15 Hauke: it works as expected :) Sep 15 14:20:18 Hauke: that's great :) Sep 15 14:26:07 build #101 of mpc85xx is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/mpc85xx/builds/101 Sep 15 14:27:31 zajec_: b43 does not find any results when scanning the first time Sep 15 14:27:40 build #254 of octeon is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/octeon/builds/254 Sep 15 14:27:50 the second call to iw wlan0 scan results an expected result Sep 15 14:34:46 i know, i know... Sep 15 14:35:12 http://lists.infradead.org/pipermail/b43-dev/2013-August/003183.html Sep 15 14:35:12 + my response Sep 15 14:35:39 ok Sep 15 14:57:45 Hauke: https://dev.openwrt.org/ticket/12931 Sep 15 14:57:51 close as invalid? Sep 15 14:59:22 yes Sep 15 14:59:54 but we probably need a script which migrates old configurations into new ones Sep 15 15:05:20 KanjiMonster: do you have a switch configuration migration script for brcm63xx from switch-robo to swconfig? Sep 15 15:06:17 build #371 of lantiq is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/lantiq/builds/371 Sep 15 15:06:40 Hauke: no, as bcm63xx did not come with pre configured switches pre b53 Sep 15 15:09:20 hauke r37996 trunk/target/linux/brcm47xx/patches-3.10/260-MIPS-BCM47XX-add-board-detection.patch * brcm47xx: update board detection patch Sep 15 15:11:07 thanks Hauke ! tomorrow morning i will rebuild and test on my zte h218n Sep 15 15:13:06 dape: no problem Sep 15 15:13:48 it is interesting how the telephony stuff was done Sep 15 15:17:07 juhosg r37997 trunk/target/linux/generic/patches-3.10/400-mtd-add-rootfs-split-support.patch * kernel/3.10: move OpenWrt MTD options into a submenu Sep 15 15:21:20 Hauke: i hope we dont get any false detections Sep 15 15:26:21 zajec_: what about this patch: http://pastebin.com/hTMTkKEV on the zte device we get bgmac bcma0:1: Failed to parse et_swtype () Sep 15 15:28:12 sec, opera just crashed Sep 15 15:28:14 .what a day.. Sep 15 15:28:44 Hauke: buf[10] is probably not needed Sep 15 15:28:51 value is anded with 0xF Sep 15 15:29:04 so this can be 15 as maximum Sep 15 15:29:13 buf[3] should be enough Sep 15 15:29:17 ok then we go with 3 Sep 15 15:29:18 '1' '5' '\0' Sep 15 15:29:48 or 4 for 0xf Sep 15 15:29:55 oh Sep 15 15:29:56 it's the same in memoty Sep 15 15:29:57 ok Sep 15 15:30:00 memory Sep 15 15:30:06 4 makes sense Sep 15 15:48:36 hauke r37998 trunk/target/linux/brcm47xx/patches-3.10/029-mtd-bcm47xxpart_detect_block_aligned_Squashfs_partition.patch * brcm47xx: mtd: bcm47xxpart: detect block aligned Squashfs partition Sep 15 15:51:32 hauke r37999 trunk/target/linux/brcm47xx/patches-3.10/711-bgmac_fix_parsing_of_et_swtype.patch * brcm47xx: bgmac: allow bigger et_swtype nvram variable Sep 15 15:52:06 https://pastee.org/gsjm ramdisk boot log on zte h218n before the two patches above Sep 15 16:01:20 dape: with r37999 ethernet should work Sep 15 16:01:32 juhosg r38000 trunk/ (39 files in 25 dirs) * kernel: update 3.10 to 3.10.12 Sep 15 16:01:51 awesome, recompiling right now Sep 15 16:06:59 works! Hauke zajec_ https://pastee.org/5gmxk Sep 15 16:09:12 dape: hooray ;) Sep 15 16:10:11 dape: nice Sep 15 16:12:13 with chinese default nonpublic firmware i got like 30 Mbit/sec with a wget file download test to dev null, if wget under openwrt sticks to 100 Mbit/s then everything its clear.. Sep 15 16:13:41 dape: that's the first report that lan on brcm47xx is faster in OpenWrt than with the vendor firmware Sep 15 16:14:25 recompiling right now with wget-nossl and r38000 , by the way congrats Sep 15 16:18:44 by the way, this zte just seems to rebooted - long log of this "bgmac bcma0:1: Hardware reported transmission for empty TX ring slot 12! End of ring: 0" error here - https://pastee.org/2qy7s Sep 15 16:26:06 zajec_: are you aware of this problem "Hardware reported transmission for empty TX ring slot 31! End of ring: 0" Sep 15 16:28:22 yeah Sep 15 16:28:26 i've fix for that Sep 15 16:28:36 quick hack is that size = min(size, 0x2000) i sent you Sep 15 16:28:41 but i have a real fix WIP too Sep 15 16:29:01 we didn't have a working ethernet for so long... Sep 15 16:29:09 i think you can wait with that for a day or two :) Sep 15 16:29:15 i'll probably finish the patch tomorrow Sep 15 16:30:11 if you guys need me to test stuff just ping me if im online and i'll compile and boot in a jiffie Sep 15 16:39:04 Hauke, zajec_ this is awesome! via pppoe-wan (ipv4 only) wgetting a 100MB file at 8 MB/s - https://pastee.org/t8gsh Sep 15 17:01:36 hauke r38001 trunk/ target/linux/brcm47xx/patches-3.10/260-MIPS-BCM47XX-add-board-detection.patch package/kernel/broadcom-diag/src/diag.c * brcm47xx: add detection code for Huawei E970 Sep 15 17:04:20 juhosg r38002 trunk/target/linux/ (9 files in 8 dirs) * kernel/3.10: add new Kconfig option for firmware partition split Sep 15 17:19:00 updated openwrt/upstream, https://home.comcast.net/~sdwalker/uscan/index.html Sep 15 17:31:32 so for diag.c, I just need to add WRT310N1 to the list and create a [WRT310N1] with the gpios?! Sep 15 17:33:40 nevermind, seems that diag.c is patched by 260-MIPS-BCM47XX-add-board-detection.patch, so I should add gpios on the patch, correct? Sep 15 17:36:05 Devastator: you directly edit package/kernel/broadcom-diag/src/diag.c Sep 15 17:37:17 Hauke ok, another question, does openwrt uses the same logic of dd-wrt about lan, wan and wireless mac addresses? lan = sticker mac, wan = lan + 1 and wireless = lan + 2? Sep 15 17:37:46 Devastator: no Sep 15 17:38:11 it uses the same mac addresses used by the vendor firmware Sep 15 17:39:02 Hauke can you point me where I can find this code? I will explain why Sep 15 17:40:18 Devastator: in arch/mips/bcm47xx/sprom.c bcm47xx_fill_sprom_ethernet() the mac addresses are read from the nvram Sep 15 17:40:30 Hauke I've replaced WRT310N's flashchip to 8MB, a friend edited the CFE to make it work, but it had dummy mac addresses, I'm going to edit the cfe again with my macs Sep 15 17:40:42 and then the drivers are taking them from there Sep 15 17:40:59 back then we were only trying to make it work hehe Sep 15 17:41:03 thanks Sep 15 17:41:14 Devastator: CFE's nvram is used only to fill "the big" nvram if you want to restore iit Sep 15 17:41:24 Devastator: so you can just write own mac in "the big" nvram Sep 15 17:41:34 I'm assuming /dev/mtd0 is the cfe? Sep 15 17:41:38 Devastator: that CFE's won't overwrite it until restoring it again Sep 15 17:41:44 Devastator: should be Sep 15 17:41:56 zajec_ yep, but won't survive resets, unfortunately Sep 15 17:42:14 reboot yes, nvram restore - not Sep 15 17:42:22 do you restore nvram every day? :P Sep 15 17:42:54 heheh no, I like to make things more complicated than they actually are Sep 15 17:44:15 Hauke possible last question, my switch is 100Mbit WAN and gigabit lan, do I have to configure any file to define eth0 eth1 correctly? Sep 15 17:55:25 Devastator: no the switch should use auto detection by default to use the best speed available Sep 15 17:55:41 ok Sep 15 17:55:48 thanks! Sep 15 18:03:16 Hauke: is that really possible that WAN it 100Mb/s and LANs are 1000Mb/s/ Sep 15 18:06:28 do I need to define lan leds somewhere? like green for 100 and blue for 1000? Sep 15 18:08:56 and wireless led.. Sep 15 18:19:24 the lan leds are directly connected to the switch, the wlan leds are controlled by the wireless driver Sep 15 18:19:35 ok Sep 15 18:28:48 hum.. from what I see in sprom.c, wan and lan have the same mac unless there is et1macaddr Sep 15 18:29:00 ok, so I should be good to go... Sep 15 18:40:42 meh, I must have done something wrong.. power led still blinks.. Sep 15 18:52:49 Hauke does this make sense? http://codepad.org/IAkVgB3G Sep 15 18:55:10 Devastator: yes Sep 15 18:55:32 thank god.. rebuilding Sep 15 18:59:49 Hauke: could you send 180-bcm47xx-nvram-gpio.patch for mainline inclusion? Sep 15 19:01:47 Hauke: when I sent you 026-mtd-bcm47xxpart-find-boot-partition-by-CFE-magic.patch I asked you to test this on your device... Sep 15 19:01:59 Hauke: so... does this patch work for you? :) Sep 15 19:15:06 is the ses led not used at all? Sep 15 19:19:09 zajec_: I will send 180-bcm47xx-nvram-gpio.patch for mainline inclusion, I am just waiting till the merge window closed Sep 15 19:19:47 zajec_: I have tested 026-mtd-bcm47xxpart-find-boot-partition-by-CFE-magic.patch on all of my devices which are working Sep 15 19:23:31 zajec_: it could be possible to make wan 100MBit/s max, and LAN 1000MBit/s, but I do not think that this is used on normal home routers where all ports are behind one switch Sep 15 19:24:35 Hauke he was curious because my device has 100MBit wan and 1000MBit lan, don't know why.. Sep 15 19:27:43 hum, I don't think driver is handling wireless led, it's too dimm and doesn't matter if wifi is up or down, led doesn't change Sep 15 19:41:29 hum.. wireless led is a known issue, thank god! Sep 15 19:45:29 build #287 of adm5120 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/adm5120/builds/287 Sep 15 19:46:51 ses led will do for now.. hum, I wonder if I can use ses button to wifi on/off and failsafe.. Sep 15 19:53:34 Devastator: failsafe should be activated by any button Sep 15 19:53:54 hum, just hold while powering on? Sep 15 19:54:49 press it when you see "Press the [f] key and hit [enter] to enter failsafe mode" in the boot log Sep 15 19:55:01 ok Sep 15 19:56:12 and if you need me to debug the wireless led, let me know, but this is cosmetic and if it's in proprietary driver, unlikely to be fixed.. Sep 15 19:56:45 tomorrow I will send you my draft for the bcm47xx add new device wiki entry Sep 15 19:57:36 Devastator: this wifi leds have problems on all brcm47xx devices Sep 15 19:59:24 many many thanks for you and Kanji to fix the switch, after I fix the cfe I will close it and put as my main router for test Sep 15 19:59:45 almost 4 years waiting :D Sep 15 20:02:02 is it normal for wifi not come up after wifi down/wifi up? Sep 15 20:02:29 no Sep 15 20:03:00 depends on the /etc/config/wireless ;) Sep 15 20:03:05 hope you removied "disabled 1" Sep 15 20:03:51 yes Sep 15 20:04:20 if I do wifi down, I have to reboot to put it back on hehe Sep 15 20:06:17 funny.. http://codepad.org/KN58mXiQ Sep 15 20:26:29 Hauke: sent your patch Sep 15 20:26:34 hope you don't mind Sep 15 20:26:56