**** BEGIN LOGGING AT Tue Oct 09 02:59:59 2012 Oct 09 10:00:18 hi, i've obtained a nice board and want to port openwork to it. I'm having problems trying to find out how the ethernet switch is wired to the SoC. Is there a way to obtain this information from the original firmware sources? Oct 09 10:00:30 *openwrt Oct 09 10:01:46 sometimes yes, sometimes no Oct 09 10:01:56 there is no generic way to do it Oct 09 10:02:03 you have to look at the ethernet drivers and the kernel config Oct 09 10:05:06 the original kernel sources link to a rgmii.ko binary blob Oct 09 10:05:51 i wasn't clear enough Oct 09 10:06:42 the switch is initialized correctly, but he soc is unable to read the status, I understand that is done through a few gpio pins or something Oct 09 10:07:10 TERROR_: what device/SoC are you talking about anyway? Oct 09 10:07:29 SMC SMCE21011v2/Ralink RT3662 Oct 09 10:08:24 it's quite similar to an ASUS RT-N56U, except with half the RAM and a different switch model Oct 09 10:08:30 (also sometimes looking at the original firmware bootlog can give good information; e.g. the realtek drivers usually print the gpios used for the ugh... I2C? connection) Oct 09 10:09:09 I'll flash the original FW and see if i can identify something there Oct 09 10:09:15 give me 5' Oct 09 10:17:02 This is the bootleg: http://pastebin.com/L9jqDD2W Oct 09 10:17:21 switch init starts @209 Oct 09 10:18:27 This bootlog is for the original firmware Oct 09 10:18:45 even the errors Oct 09 10:20:55 Wow, google is fast, my paste bin is already indexed Oct 09 10:22:49 ;) Oct 09 10:24:31 pastebin is pinging google engine on every update, that's why ;) Oct 09 10:25:41 That's cheating :-P, thanks for the info barteq Oct 09 10:27:10 that's how the world works, not cheating ;P Oct 09 10:27:53 very popular in seo-related circles. You can ping also your site for example via http://pingates.com/ Oct 09 10:28:20 I learn something new every day. Oct 09 10:28:27 or automatically using xml-rpc. maaany examples over the web Oct 09 10:28:40 yup Oct 09 10:31:35 I'm not so much into web or SEO, and it shows Oct 09 10:37:35 KanjiMonster, do that bootlog rings any bells for you? Oct 09 10:38:45 hm, not really; haven't seen any specifying the appropriate gpios Oct 09 10:42:46 I'll keep digging, thanks KanjiMonster Oct 09 10:43:27 U-boot also initializes the switch, I might find something in U-boot sources Oct 09 10:44:11 TERROR_: oh, quite likely then. check also include/configs, where the device config should be somewhere Oct 09 10:45:00 YES! Oct 09 10:45:12 I got it in the first try, that was luck Oct 09 10:46:42 /GPIO[21:17] + GPIO[14:7] + GPIO [6:3] , see Ralink RT3662 datasheet page 41 Oct 09 10:49:41 Lets try those 3 pairs Oct 09 10:51:37 more likely they are 14 and 7 Oct 09 10:54:08 usually [a:b] means range a to b (inclusive) Oct 09 10:55:22 yep, but I think in this case it identifies the 2 lines (data and clk) used to talk to the switch silicon Oct 09 10:55:45 it's easy to try anyways, I'm compiling with 14 and 7 and see what happens Oct 09 11:18:54 Hello, any x86 devs here working on Xorg with Displaylink support here? Oct 09 12:22:34 [Mon 2012-10-08 12:36:18 AM PDT] <[florian]> DonkeyHotei: the mdio bus is shared between the two cpmac ethernet interfaces Oct 09 12:22:35 [Mon 2012-10-08 12:36:48 AM PDT] <[florian]> on some tnetd7300 devices, there is an internal phy connected to one of the two cpmacs Oct 09 12:22:35 [Mon 2012-10-08 07:41:45 AM PDT] the linksys WAG54GP2v1 has an ADM6996L on cpmac low Oct 09 12:22:35 [Mon 2012-10-08 07:42:00 AM PDT] mdio sees nothing Oct 09 12:23:28 <[florian]> adm6996 switches on ar7 devices are most of the time, but not always connected to mdio/mdc Oct 09 12:23:32 <[florian]> so they are not detected Oct 09 12:23:43 hmm Oct 09 12:23:49 <[florian]> this is because these switches use some kind of spi-like communication bus Oct 09 12:23:52 <[florian]> using ar7 gpios Oct 09 12:23:57 oh Oct 09 12:24:49 <[florian]> so basically, there are several situations for cpmac to handle properly: Oct 09 12:25:07 <[florian]> - switch is detected through MDIO, it can be probed using an existing switch driver Oct 09 12:25:30 <[florian]> - there is an internal phy connected, and the generic PHY device driver is picked up Oct 09 12:25:40 <[florian]> (or a specific internal phy driver, whatever) Oct 09 12:26:01 <[florian]> - there is nothing on the MDIO bus, and we must register a fixed phy driver, for the cpmac interface to always see the link as up Oct 09 12:26:12 <[florian]> - eventually, we manage to control the switch through ar7 gpios Oct 09 12:27:24 there is no existing code to manage the switch through gpio's Oct 09 12:30:04 [florian]: or is there? Oct 09 12:30:31 <[florian]> there is, kmod-switch does this on broadcom devices Oct 09 12:30:44 <[florian]> you "just" need the proper ar7 gpio mapping Oct 09 12:30:59 wouldn't that be device-specific? Oct 09 12:34:47 [florian]: ^ Oct 09 12:43:22 <[florian]> it is, most likely Oct 09 12:43:32 <[florian]> so either we come up with device tree for ar7, which would be a good thing anyway Oct 09 12:43:39 <[florian]> or we find something else Oct 09 13:35:24 [florian]: i don't think a device tree for ar7 is a great idea at this point. maybe reintroduce the fixed phy? Oct 09 13:35:57 <[florian]> DonkeyHotei: it is a good idea, because it will allow proper description of each and every ar7 device out there Oct 09 13:36:04 <[florian]> without cluttering the code with ugly stuff Oct 09 13:36:31 <[florian]> I have some patches locally re-introducing fixed phy until everything is properly sorted out Oct 09 13:36:59 that's a lot of diverse devices, which IS ugly, especially since ar7 is long-eol'ed Oct 09 13:38:12 [florian]: i am working on a bunch of local patches myself which fix vlynq, wifi, and mvswitch Oct 09 13:38:27 i for sure hope a eol notice of some vendor does less impact on openwrt than real device propagation Oct 09 13:39:21 i know that e.g. originial wrt54 are still in use a lot.. same goes for ugly stuff like brcm47xx and ath23xx Oct 09 13:39:28 [florian]: right now, there are two hiccups in my local patches as pertaining to the devices on which i have tested Oct 09 13:39:59 1) ethernet inaccessible AT ALL on the linksys Oct 09 13:40:47 2) the nas0 interface on a bridged circuit defaults to the same mac address as the lan. this is not good Oct 09 13:50:11 [florian]: do you think you can merge your local patches with mine? Oct 09 13:55:58 <[florian]> DonkeyHotei: please post your patches so I can review them, and I will post mine Oct 09 13:57:06 [florian]: i was going to post into patchwork after they were done, but if you have ones that need to be merged, maybe i should send privately for now. dcc? Oct 09 13:57:26 <[florian]> no dcc, email plase Oct 09 13:58:17 florian@openwrt.org? Oct 09 14:04:49 <[florian]> DonkeyHotei: yes sir Oct 09 14:08:55 [florian]: sent Oct 09 14:08:59 <[florian]> thanks Oct 09 14:34:45 [florian]: how does it look so far? Oct 09 15:54:31 nbd, ping pls, i just read a ticket stating dlink dir 615 h1 wifi should work? Oct 09 15:54:50 somebody reported it to work in that ticket Oct 09 15:55:45 it was a useless many-issues-in-one ticket, so i decided to close it Oct 09 15:55:51 maybe i should have used 'duplicate' instead Oct 09 15:56:10 13 days ago.. i doubt it, i tested trunk last week Oct 09 15:56:44 i'm gonna compile trunk tomorrow and test again, the router is at work unfortunately but if wifi works.. that would be awesome Oct 09 15:58:36 nope, doesnt work until r33618 Oct 09 15:59:42 package/mac80211/patches/620-rt2x00-support-rt3352.patch and package/mac80211/patches/621-rt2x00-fix-rt3352-lnagain.patch updated since then, maybe it will work Oct 09 17:10:18 https://dev.openwrt.org/changeset/33655/trunk/tools/firmware-utils/src/bcm_tag.h Oct 09 17:10:36 this is breaking svn 1.7 horribly Oct 10 00:29:56 Is there any SVN admin here who can help to fix my account? Oct 10 01:09:59 mazilo: Kaloz Oct 10 01:14:21 SmugLeaf: Thanks. Oct 10 02:38:14 ping Kaloz **** ENDING LOGGING AT Wed Oct 10 02:59:58 2012