**** BEGIN LOGGING AT Sun Sep 20 02:59:58 2015 Sep 20 03:00:06 with rgmii it actually works zero-maintenance once you set it up Sep 20 03:00:11 does the driver work with that? Sep 20 03:00:13 no Sep 20 03:00:18 the driver is shit Sep 20 03:00:37 the driver also reinitializes everything when it loads Sep 20 03:00:47 so link down, link up, switch table flushed Sep 20 03:02:20 (note that even without reset isolation, if you don't reset the PHYs then you can reset without anyone ever really noticing... just a few dropped packets in the short time before you can reenable the switch) Sep 20 03:03:23 at work I usually connected my laptop to our dm814x board which connected to the office network, rather than connecting it directly Sep 20 03:03:27 always worked perfectly Sep 20 03:04:10 ditto at home actually... my laptop's chipset has an auto-negotiation problem with my ADSL router so I actually inserted our board inbetween to fix that Sep 20 03:05:44 note that switch initialization does not have to have anything to do with the host ethernet driver Sep 20 03:05:54 the host can "plug in" at any later time Sep 20 03:06:17 in the current cpsw driver however the switch code and host ethernet code are completely interwoven Sep 20 03:08:01 I'm checking my own init code now... Sep 20 03:08:51 config rgmii in control module, enable module in prcm, setup pinmux Sep 20 03:10:48 config both rgmii ports ("maccontrol" and rx maxlen) Sep 20 03:12:24 chat with both PHYs via MDIO to check their status, only reset them if it looks really wonky, reconfigure their led behaviour to be more aesthetically pleasing Sep 20 03:12:34 the reset is fine Sep 20 03:12:46 don't expect to reboot the system that often for that to matter Sep 20 03:13:34 how often do you plan to reset the processor for a littl eblip to matter Sep 20 03:14:05 well I was doing baremetal development in an untyped language in an environment without memory protection Sep 20 03:14:53 ;) Sep 20 03:18:14 ds2: so, the stuff above is basically just the setup of the individual RGMII ports Sep 20 03:18:42 after that I clear the stats and initialize the switch and address lookup engine Sep 20 03:19:57 the former is about 5 lines of code, the latter about one page (in part because I already set up some filter rules for more convenient testing) Sep 20 03:24:00 I no actual switch driver code apart from init... I should at least have set up a timer to trigger the ALE's age-out functionality once in a while... then again on a typical network it'll take a while before you've seen 1024 distinct MAC addresses Sep 20 03:24:06 *I have no Sep 20 03:28:07 the switch is transparent to spanning-tree, which you can get away with since you have only two external ports Sep 20 03:31:36 even if you'd make a loop of one or more of these devices you wouldn't get packets circulating indefinitely since I lock the device's own MAC address to the host port, so if a packet goes full circle it would then be dropped Sep 20 03:32:41 so in practice the switch worked fine with no driver looking after it whatsoever Sep 20 03:35:49 this is also thanks to rgmii's embedded link status info.. those unfortunates using rmii would need to use the phy irq lines to get notified of link status changes, query them via mdio, and reconfigure the rmii port Sep 20 04:18:32 ds2 .. what did you do to it? pics/schems? Sep 20 04:24:44 * zmatt is kinda curious too Sep 20 04:26:01 I think there'y only a couple of missing signals on the proc... to the phy Sep 20 04:26:19 none afaik Sep 20 04:26:26 rgmii uses fewer signals, not more Sep 20 04:26:46 sure? I thought when .. hrm .. perhaps misread the datasheet or assumed the full rmi .. or some nonsense :) Sep 20 04:26:57 other+ nonsense Sep 20 04:27:04 am335x doesn't support gmii Sep 20 04:27:22 I remember there being about 3 'modes' for that interface .. Sep 20 04:27:39 yes, mii, rmii, rgmii Sep 20 04:27:39 and you needed one to get gigabit Sep 20 04:28:11 true, I thought trace lengths were likely to be more critical to get matchingright Sep 20 04:28:19 absolutely Sep 20 04:28:55 trace length is suprisingly not that critical Sep 20 04:29:18 well, definitely more critical with rgmii than with mii obviously Sep 20 04:29:34 gotten it to work with loose 30G wires Sep 20 04:29:42 o.o Sep 20 04:29:58 had to do that due to an errata Sep 20 04:30:00 I was about to ask whether you'd managed to find a phy with compatible footprint Sep 20 04:30:18 internal delay doesn't work reliably Sep 20 04:30:32 internal delay isn't supported Sep 20 04:30:34 he he he Sep 20 04:31:00 and the drivers don't enable delay on the PHY by default Sep 20 04:31:23 extending the clock line gave enough delay to verify things Sep 20 04:33:03 about 2 ns is needed iirc Sep 20 04:34:14 this still sounds like a pic-worthy hack Sep 20 04:41:39 thinking of it... 2 ns is actually quite some time Sep 20 04:42:59 loose wire has a much higher velocity factor than a pcb trace running closely over some ground/power plane right? Sep 20 04:44:22 it might have been Sep 20 04:44:40 was banging heads for hours before trying this Sep 20 04:45:10 getting gigE isn't that hard Sep 20 04:45:28 I'm seeing number suggesting ~50%, so for 1-2ns required that would be about 15-30 cm of wire o.O Sep 20 04:45:31 it was running enough to get either an arp or a ping through Sep 20 04:45:40 a foot is about what we used Sep 20 04:46:00 yep that gets you your 2 ns, lol Sep 20 04:46:07 nicely within spec Sep 20 04:46:24 not so much specs as much as it is physics Sep 20 04:46:36 it came down to following the sherlock axiom Sep 20 04:47:06 well the 2 ns is the spec (typ) for rgmii internal delay Sep 20 04:48:04 IIRC, the reasoning we had was something to shift it enough so it would look at it after the signal was stable Sep 20 04:50:12 BeagleBone black supports camera interface? Sep 20 04:51:15 Naveen: none natively, although you could hook one up via usb or sdio Sep 20 04:52:09 thanks, i need to do image processing application and i do have camera with USB 3.0 Sep 20 04:52:24 no usb 3 on the BBB, usb 2 Sep 20 04:53:01 ok, where ethernet can access the camera Sep 20 04:53:48 one last doubt, where open cv can be installed in the beagle Sep 20 04:58:37 or PRU Sep 20 04:58:57 blah... opencv blows Sep 20 05:00:54 what is PRU Sep 20 05:01:11 Programmable Realtime unit Sep 20 05:01:24 a microcontroller on the same die designed to be very deterministic Sep 20 05:04:38 what you mean by opencv blows, it is not possible Sep 20 05:25:56 so ds2 .. enquiring minds want to know .. how did you lash a gige phy to the beagle??! :) Sep 20 05:26:06 and which one did you go for/ Sep 20 05:26:23 the gig equivalent of the one on the beagle is pricey Sep 20 05:31:13 opencv has a crappy interface Sep 20 05:31:17 there are easier to use libraries Sep 20 05:31:46 veremit: it was not my personal project. I was the brains for it. Sep 20 05:32:06 bom specifics are not mine to disclose :( Sep 20 05:32:15 go on... Sep 20 05:32:46 find a documented PHY first Sep 20 05:32:49 that is the hardest part Sep 20 05:33:17 well .. as I said .. the gige equivalent of the part on the beagle is around .. I did look at its datasheet briefly .. Sep 20 05:33:37 who makes a documented gigE PHY? Sep 20 05:33:53 full datasheets are hard to get Sep 20 05:33:58 ours is documented just fine... under nda Sep 20 05:34:08 zmatt: yes that is the "issue" Sep 20 05:34:22 eh .. hell I'm under 3 nda's .. I think .. Sep 20 05:34:23 let me rephase what I said... a fully and openly documented one Sep 20 05:34:33 do I care .. nope :D Sep 20 05:34:53 can't talk about stuff under NDA Sep 20 05:34:59 :D Sep 20 05:35:01 its the OSA one I have to be more careful about Sep 20 05:35:23 I definitely get landed in prison if I breach that Sep 20 05:35:29 OSA? Sep 20 05:35:37 Official Secrets Act Sep 20 05:35:44 ah that Sep 20 05:35:46 nda .. sign it blah blah blah Sep 20 05:35:55 you work for her majesty? Sep 20 05:36:09 I bet 2/3 mean nothing .. and are unenforceable Sep 20 05:36:15 I used to for a few months Sep 20 05:36:44 ds2: btw, I added some clock settings dump to my baremetal code... http://pastebin.com/BQPycmBk Sep 20 05:37:00 ds2: that's without touching the PLLs myself Sep 20 05:37:12 i.e. setup done only by ROM Sep 20 05:37:21 zmatt: started via a 'go' in U-boot? Sep 20 05:37:25 ds2: no u-boot Sep 20 05:37:34 ok Sep 20 05:37:35 directly ROM -> my code Sep 20 05:37:46 did you find which PLL is needed for the GigE stuff? Sep 20 05:38:14 no I decided to dump the core PLL out of randomness :P Sep 20 05:38:34 it took a while to chase down which PLL is needed Sep 20 05:39:01 it's specified explicitly in the ethernet chapter, almost right at the beginning Sep 20 05:39:09 and a picture drawn in the PRCM chapter Sep 20 05:39:29 in my case, I needed to correlate that to existing code Sep 20 05:39:43 much easier if you are chasing it from bare metal Sep 20 05:40:55 the only way you can fuck up rgmii support without breaking ethernet entirely is by using the opp50 configuration Sep 20 05:41:37 there was some funny business on this particular board (2 different GigE projects that I am jumping between) Sep 20 05:41:53 the PMIC is odd. can't say more then that. Sep 20 05:42:26 lol pmics are odd .. Sep 20 05:42:34 (i.e. configure core-m5 to 100 MHz and set the "eth 50M" divider to /2) Sep 20 05:42:45 how did the pmic suddenly get into the picture here? Sep 20 05:43:01 lmao.. knew zmatt would perk at that lol Sep 20 05:43:10 zmatt: it doesn't support all the OPP's Sep 20 05:43:12 I mean, "the PMIC is odd" isn't something I'm going to disagree with Sep 20 05:43:32 i can't clarify that any more. Sep 20 05:43:42 the PMIC does just fine, ROM however didn't in revision 1.0 (TI claims they fixed it) Sep 20 05:44:01 but you can't use opp50 anyway if you want gigE Sep 20 05:44:32 (or ddr3, or a ton of other things) Sep 20 06:07:25 ds2: if you still have any doubts about ROM setting up clocks right for gigE, try having ROM boot something via ethernet... I can provide a little test prog to boot and example dnsmasq config if you want :P Sep 20 12:14:42 Greetings! I'm having a hard time getting my BBB to take a static IP. It seems upon boot, it still makes a DHCP request even though I've updated /etc/network/interfaces Sep 20 12:15:24 I can get it to take if I restart the network with a systemctl restart network... Sep 20 12:21:39 It seems it's connection manager related...I found a fix Sep 20 12:26:02 ah, connman, constant font of joy Sep 20 14:21:33 systemd-networkd ftw Sep 20 14:22:01 is it just me or is TI E2E login broken *again* Sep 20 15:53:13 Just got a Beaglebone Black and powered up via USB. What is proper way to power down and disconnect USB? Thanks Sep 20 15:54:54 sfw77: if you have ssh access you can run the "poweroff" command Sep 20 15:58:24 Thanks for your response, but I'm a new user and I probably don't have ssh access yet Sep 20 15:59:05 sfw77: you can also run that command in a bash shell on the cloud9 ide (http://beaglebone.local:3000) Sep 20 17:09:38 Hi, I want to make a dashcam/reverse camera with a Beaglebone, any camera sugestions? I would like to run the cable from the camera to the BeagleBone about 10 feet if possible. Sep 20 18:50:41 Apache is still in the base image here https://rcn-ee.com/rootfs/2015-09-11/flasher/BBB-eMMC-flasher-debian-8.2-console-armhf-2015-09-11-2gb.img.xz Sep 20 18:50:57 Is there a flasher image I can load that doesn't contain apache? Sep 20 18:51:08 I'm just looking for a headless Debian image. **** ENDING LOGGING AT Mon Sep 21 02:59:59 2015