**** BEGIN LOGGING AT Thu Sep 11 02:59:57 2008 Sep 11 06:17:11 juhosg * r12567 /trunk/target/linux/atheros/files/include/asm-mips/mach-atheros/gpio.h: [atheros] use generic cansleep wrappers for GPIO Sep 11 12:23:39 cyrus * r12568 /trunk/package/base-files/files/sbin/usb-storage: Prevent unwanted shell expansion Sep 11 13:19:40 mb___: hi Sep 11 13:20:18 mb___: are you there? Sep 11 15:31:25 mb___: are you there? Sep 11 15:40:30 sn9: what's up? Sep 11 15:41:49 i've been trying to get tg3 to work on the wrt350n v1, and near as i can figure, the ssb layer is not allowing phy access Sep 11 15:47:19 mb___: ^^^^^ Sep 11 15:56:12 sn9: It works for me. But note that the roboswitch does not work Sep 11 15:56:35 mb___: works for you on a wrt350n v1? Sep 11 15:56:51 the americal version with broadcom wireless Sep 11 15:56:58 whatever version that is Sep 11 15:57:03 american Sep 11 15:57:19 what svn rev? Sep 11 15:57:35 I don't know. Sep 11 15:57:58 i can tell you that anything recent has no ethernet Sep 11 15:58:15 you have to disable the bridge stuff in the config and bring up the device as a single device manually Sep 11 15:58:28 in nvram? Sep 11 15:58:34 via serial console Sep 11 15:58:46 tg3 won't even load Sep 11 15:58:53 the switch does not work, as I said. Sep 11 15:59:02 Did you compile ssb gige support? Sep 11 15:59:20 build fails with an error unless i do Sep 11 15:59:38 the error being? Sep 11 15:59:51 undeclared stuff Sep 11 16:00:14 So you really wonder why it doesn't work? Sep 11 16:00:44 let me get this straight -- i have to leave out ssb gige? Sep 11 16:01:10 ehm, no? Sep 11 16:01:27 First you'll have to tell me the error message. Sep 11 16:01:38 you just asked why compilation fails when i leave it out Sep 11 16:01:53 ? Sep 11 16:02:03 build fails with an error unless i do Sep 11 16:02:04 the error being? Sep 11 16:02:09 I asked if you compiled ssb-gige, because without it tg3 won't load Sep 11 16:02:29 what's the freaking error you get from tg3? Sep 11 16:02:30 build fails with an error unless i compile it in Sep 11 16:03:14 tg3 can't id the phy, and when i hard-code the phy id, it can't read the mac address Sep 11 16:03:52 guy, I want to see error messages from an unmodified build. Sep 11 16:04:01 I cannot help you by random guessing Sep 11 16:04:14 I still don't know _what_ fails Sep 11 16:04:30 on an unmodified build, there are no errors -- it simply does nothing Sep 11 16:04:54 that is, if i compile in ssb gige Sep 11 16:05:08 so, did you login via serial console and disable the bridges and bring up the ethernet interface manually? Sep 11 16:05:08 if i leave it out, the build never finishes Sep 11 16:05:36 i tried, but it didn't do anything Sep 11 16:05:49 Ok, well. Works for me. Sep 11 16:05:54 Debug it, please. Sep 11 16:06:07 I really can't help you here. Sep 11 16:06:32 well, to see if it would help, i backported the current tg3 and ssb support from 2.6.27-rc6 Sep 11 16:07:12 You'd better try an older kernel Sep 11 16:07:19 I think I used 2.6.25 Sep 11 16:07:25 using 2.6.25.16 Sep 11 16:07:42 I think that was the original kernel I developed the stuff on Sep 11 16:08:56 also look for roboswitch changes and try to revert them. Sep 11 16:09:09 you've also committed changes to later kernels in mainline. i can understand if that's not supposed to work, but i'd like to see what i can do to improve that Sep 11 16:09:27 I added basic support for the switch when I committed the stuff (but no VLAN, which openwrt depends on in its default config) Sep 11 16:09:45 I did not change ssb-gige since the commit Sep 11 16:09:59 tg3 changed, but not by me. Sep 11 16:10:16 I guess the old patch doesn't even apply anymore to recent tg3 Sep 11 16:10:38 ssb changed in mainline, and you were the main committer Sep 11 16:10:55 as long as ssb-gige didn't change, it hardly matters Sep 11 16:12:05 it did change -- i just checked again Sep 11 16:12:10 But I really think you didn't set up the networking/roboswitch correctly for it to work. In the default openwrt config it really just looks like it doesn't do anything. Sep 11 16:12:24 Does tg3 load successfully? Sep 11 16:12:37 If it does, register access (including PHY) does work Sep 11 16:12:48 It accesses and verifies a lot of accesses on init Sep 11 16:13:10 registers Sep 11 16:14:17 now using the tg3 and ssb from .27 on .25, it does not load successfully, and even if an older version does sometimes, i'd like to help fix the current one Sep 11 16:14:24 first ssb-gige needs to be loaded, then tg3 and then roboswitch. Then you need to disable any vlan stuff. Sep 11 16:14:41 roboswitch is not built Sep 11 16:14:46 !!!!!!!!!!!!!!!!!!!!! Sep 11 16:15:12 You absolutely need that, right? Sep 11 16:15:29 the roboswitch hardware is default powered completely off. Sep 11 16:16:33 building it isn't even an option in menuconfig nor kernel_menuconfig Sep 11 16:20:02 mb___: there is no separate roboswitch module for 2.6 that i can see Sep 11 16:20:42 closest thing i can find is LIBPHY Sep 11 16:21:23 28 define KernelPackage/switch/description Sep 11 16:21:24 29 This package contains switch drivers for ADM6996L and BCM53XX RoboSwitch. Sep 11 16:21:24 30 endef Sep 11 16:21:48 20 TITLE:=Switch drivers Sep 11 16:22:01 oh, that. that's in there Sep 11 16:25:32 speaking of, how are you on that? I've been poking at the adm driver, adding configurable WAN port and whatnot Sep 11 16:26:14 I really would like to get VLAN configuration going, but have gotten distracted chasing other rabbits Sep 11 16:27:04 aoz: i think LIBPHY would be really need to handle that eventually Sep 11 16:27:33 well, we have broadcom code. Just somebody has to step up and write roboswitch code based on that. Sep 11 16:28:13 mb___: why not LIBPHY? Sep 11 16:28:27 because roboswitch uses ioctl Sep 11 16:30:30 openwrt needs to handle LIBPHY hardware anyway Sep 11 16:31:53 I'm not sure how libphy would help here, but we currently use ioctl. Sep 11 16:32:18 does libphy support access of two drivers (tg3 and roboswitch) to the PHY simultaneously Sep 11 16:32:19 ? Sep 11 16:33:09 if the roboswitch code were ported to libphy, roboswitch could go away entirely, right? Sep 11 16:34:03 in .27, libphy already handles other broadcom phy's Sep 11 16:35:33 why on earth would roboswitch go away? Sep 11 16:35:47 We need a driver for that hardware. Sep 11 16:36:13 The switch has almost nothing to do with the actual PHY Sep 11 16:36:26 It is accessed through a different PHY-id, as far as I remember Sep 11 16:36:39 in contrast to other switches? Sep 11 16:37:43 sn9: I'm not sure what you are actually trying to tell me. if you want something with libphy, for whatever reason, please do a patch. Sep 11 16:37:53 I currently think it's bogus. Sep 11 16:38:58 326 /* The robo has a fixed PHY address that is different from the Sep 11 16:38:58 327 * Tigon3 PHY address. */ Sep 11 16:38:58 328 robo.phy_addr = ROBO_PHY_ADDR; Sep 11 16:39:30 The TG3 PHY is accessed through PHY-ID 0x01. The switch is accessed through 0x1E Sep 11 16:39:51 So the only thing the two devices share really is just the MMIO register for access to the HW. Sep 11 16:40:32 ok, maybe tg3 is not arbitrating that right, anymore Sep 11 16:41:16 ? Sep 11 16:41:46 maybe tg3 is hitting the robo by mistake Sep 11 16:42:11 I'm pretty sure it doesn't ever use anything else than PHY routing 0x01 Sep 11 16:42:55 they are both accessed as the same pci device on ssb? Sep 11 16:43:46 they share the mmio Sep 11 16:43:55 two regs' Sep 11 16:44:23 they are indirectly accessed, so the MMIO regs are just Address and Data Sep 11 16:44:56 the address register also takes the PHY-id Sep 11 16:45:19 ah, i see. so the code in tg3 that checks phy id based on pci id is bogus Sep 11 16:45:39 What's this assumption based on? Sep 11 16:45:51 which assumption? Sep 11 16:45:58 [18:45:18] ah, i see. so the code in tg3 that checks phy id based on pci id is bogus Sep 11 16:46:10 it's based on what you just said Sep 11 16:46:28 There is no code which checks the phy-id based on the pci-id Sep 11 16:46:38 tg3 has such Sep 11 16:47:08 uses it as a last resort, before reading regs as a last-last resort Sep 11 16:47:10 tg3 doesn't even have support for multiple PHY-ids, without my match. At least when I last looked at it. Sep 11 16:47:47 tg3 supports some twenty-odd phy id's Sep 11 16:48:03 one at a time, though Sep 11 16:48:32 roboswitch complains if the PHY-id is wrong Sep 11 16:49:20 tg3 complains if the phy id is unknown or unreadable Sep 11 16:49:38 Ok, I think you're confused because I used the wrong word Sep 11 16:49:47 possibly Sep 11 16:49:49 I was not talking about the PHY-id, but the PHY-address Sep 11 16:49:55 oh Sep 11 16:50:14 1727 /* Currently this is fixed. */ Sep 11 16:50:14 1728 #define PHY_ADDR 0x01 Sep 11 16:50:26 the TG3 PHY always is at 0x01 Sep 11 16:50:34 Robo always is at 0x1E Sep 11 16:50:48 The PHY access MMIO registers multiplex the accesses in hardware Sep 11 16:51:39 The switch really is unrelated from the tg3 PHY. it just shares the same MMIO register to indirectly access it. Sep 11 16:51:40 that brings back the question of why tg3 can no longer access regs properly Sep 11 16:51:46 That's the only reason we need the ioctl Sep 11 16:52:08 Why do you think it can't access regs properly? Sep 11 16:52:45 well, it couldn't read the phy id, and when i hard-coded that, it couldn't read the mac address Sep 11 16:53:03 You said you don't get any error messages. Sep 11 16:53:33 the MAC address is stored in nvram. Sep 11 16:53:40 no errors with the tg3 in trunk, but i'd like to help fix the current tg3 Sep 11 16:53:41 the device does not have a prom Sep 11 16:54:06 so trunk does work?? Sep 11 16:54:55 it does nothing in response to configuration without the vlans, as i recall Sep 11 16:55:45 wouldn't it be better to first fix that before porting the stuff? Sep 11 16:57:04 well, at first, i was hoping the later tg3 would have already fixed it, but in any case, what fixes it in trunk may no longer apply to the mainline tg3 Sep 11 16:57:15 anyway, there are a few things to consider when porting: The tg3 on the device has no prom and no firmware processor. Sep 11 16:57:32 There also are some write ordering things to take care of wrt IRQs. Sep 11 16:57:32 but it does have nvram, right? Sep 11 16:57:36 no Sep 11 16:57:54 everything is stored in global nvram and is accessed through the ssb-gige driver Sep 11 16:58:23 tg3 tries to get at nvram through regs, iirc Sep 11 16:58:57 see my patch. It changes tg3 to be ssb-gige aware. You really need to port that. Sep 11 16:59:03 Without it this can not work. Sep 11 16:59:29 pdev_is_ssb_gige_core(pdev) is the check if the tg3 pci dev is really a ssb-gige device. Sep 11 17:00:24 ok, where is that? Sep 11 17:00:41 in the repository Sep 11 17:01:50 ah, patch 700 Sep 11 17:15:16 lars * r12569 /trunk/include/package.mk: Add InstallDev/(Pre|Post) hooks. Sep 11 17:26:04 sn9: the tg3 works properly on latest trunk. I cannot get the switch to forward packets, however Sep 11 17:26:19 But I didn't try hard. I just flashed latest trunk image Sep 11 17:26:42 i am forward-porting patch 700 and will try again Sep 11 17:41:41 in any case, the tg3 loads and works fine. So I'm pretty sure this won't fix it. Sep 11 17:42:18 It's pretty obvious that the switch is not working. As I said, it lacks all of the VLAN config, which is required by openwrt. Sep 11 17:42:42 I'm currently not sure how I reconfigured the stuff to work in single-ethernet mode. Sep 11 17:43:18 You had to reload a few modules, assign static IP addresses to the physical device and so on... Dunno. Sep 11 17:50:45 I'd rather look for roboswitch changes Sep 11 17:50:50 see SVN history Sep 11 17:51:10 nbd: you around? Sep 11 17:51:21 SAIDias: yup Sep 11 17:51:31 can I pm? Sep 11 17:51:53 why? Sep 11 17:52:35 xM (Jo) wanted me to get in touch with you, figured our discussion might be best on outside of channel Sep 11 17:52:40 ok Sep 11 18:14:50 sn9: I just see that there don't seem to be any interrupts on the tg3 device. So ssb IRQ routing may be broken Sep 11 18:15:29 probably, but i need to verify Sep 11 18:15:34 there wasn't any change (that matters) to the switch code, so we can rule that out. Sep 11 18:15:50 There wasn't any change to the tg3 patch, so we can rule tg3 out. Sep 11 18:16:11 seems IRQ routing Sep 11 18:17:09 when developing the stuff I added a few printks to the IRQ routine to check whether it starts triggering or not. Sep 11 18:17:20 But I won't do that now. Sep 11 18:17:34 I'm basically not interested in that device. Sep 11 20:57:56 does anybody knows this error? Sep 11 20:57:57 bison: cannot open file `/home/jow/openwrt/kamikaze/staging_dir/host/share/bison/m4sugar/m4sugar.m4': No such file or directory Sep 11 21:00:47 ahh, I moved the buildroot to another directory Sep 11 21:01:00 I just symlink it for now Sep 11 21:11:35 nbd: you there? Sep 11 22:23:18 h3sp4wn: poke Sep 11 22:28:47 Kaloz: Hi - If you want to know why those work I am not sure Sep 11 22:29:01 :) Sep 11 22:29:33 ok, but it compiles a working toolchain for you, and everything works? (eg. iwconfig reports sane values and stuff for example?) Sep 11 22:31:24 Kaloz: http://paste.debian.net/17027 Sep 11 22:32:00 Those invalid nwid are from when my workstation was not rebooted but that was over a week ago Sep 11 22:35:13 There is something wrong with nf_conntrack_amanda / nf_nat_amanda but I don't use them **** ENDING LOGGING AT Fri Sep 12 02:59:57 2008