**** BEGIN LOGGING AT Thu Jul 13 03:00:03 2017
Jul 13 03:12:12 <zmatt> whoa
Jul 13 03:13:03 <zmatt> okay now I'm more curious why the dynamically linked version *did* work... damn
Jul 13 03:32:13 <zmatt> (fixed version uploaded)
Jul 13 03:33:32 <ds2> cuz glibc can't produce proper static executables
Jul 13 03:33:58 <zmatt> no, the static version didn't work cuz I was an idiot.  the dynamic version worked probably due to pure luck
Jul 13 03:36:57 <zmatt> of course with the sort of magic I do in my "libsubarctic" I maybe deserve it :P
Jul 13 03:53:16 <t_brah> im back
Jul 13 03:53:26 <t_brah> ill try the new version
Jul 13 03:53:41 <t_brah> lcd-util.tar.gz?
Jul 13 03:53:59 <zmatt> yeah
Jul 13 03:56:38 <t_brah> woooo
Jul 13 03:56:43 <t_brah> heres the stats
Jul 13 03:58:10 <t_brah> https://pastebin.com/YZbyHytj
Jul 13 03:58:42 <zmatt> yeah that's what I said earlier, lcdc is not enabled
Jul 13 03:58:52 <t_brah> thats my problem>?
Jul 13 03:59:57 <zmatt> looks like maybe nothing is doing anything with the display
Jul 13 04:00:12 <zmatt> I'm guessing framebuffer console isn't enabled on an android kernel build
Jul 13 04:00:39 <zmatt> can you check /sys/class/graphics/fb0/mode and .../modes ?
Jul 13 04:01:07 <zmatt> and if mode is blank but modes isn't, echo the first line of modes into mode
Jul 13 04:01:50 <zmatt> of course there's still the question of why edid probe is failing
Jul 13 04:02:48 <t_brah> checked mode and modes
Jul 13 04:02:51 <t_brah> mode is empty
Jul 13 04:03:13 <t_brah> modes has a single item (U:1024x768p-0)
Jul 13 04:03:21 <t_brah> echoed that into mode
Jul 13 04:04:38 <zmatt> any effect?
Jul 13 04:04:59 <t_brah> no
Jul 13 04:05:07 <zmatt> hm
Jul 13 04:06:17 <t_brah> should i restart the device? trigger a hotplug?
Jul 13 04:06:17 <zmatt> ok let's try something different, add a kernel parameter  video=1280x720@60E
Jul 13 04:07:02 <zmatt> (I'm assuming the monitor will accept that)
Jul 13 04:08:00 <zmatt> eh, D I mean apparently
Jul 13 04:08:05 <zmatt> not e
Jul 13 04:08:06 <zmatt> WE
Jul 13 04:08:07 <zmatt> E
Jul 13 04:08:21 <t_brah> so
Jul 13 04:08:38 <t_brah> video=1280x720@60WE?
Jul 13 04:08:40 <zmatt> actually either video=1280x720@60D or video=1280x720@60e ... should do the same thing
Jul 13 04:09:09 <zmatt> no the WE was me fat-fingering the E key while correcting the typo "not e" to "not E"
Jul 13 04:09:13 <zmatt> spaghetti everywhere
Jul 13 04:09:40 <zmatt> https://www.kernel.org/doc/Documentation/fb/modedb.txt   docs of that parameter :P
Jul 13 04:11:36 <t_brah> whoop whoop
Jul 13 04:11:45 <t_brah> android logo up for 60 seconds so far
Jul 13 04:12:44 <t_brah> alright so its running
Jul 13 04:13:13 <zmatt> woo
Jul 13 04:13:24 <zmatt> so edid failure was indeed the root problem
Jul 13 08:47:58 <raviteja> hie all
Jul 13 08:48:21 <raviteja> hey anybody need webcam and beaglebone interface program
Jul 13 08:48:35 <raviteja> i can help with it as im a freelANCER
Jul 13 10:22:26 <Rahul> Hi bbb
Jul 13 10:23:53 <Guest7563> I am reading BEAGLEBONE BLACK schematic  for USB0 and USB1
Jul 13 10:27:49 <Guest7563> in schematic document page no 4: usb pc connector is connected to tpd4s012 which is four-channel Suppressor and where this supressor is connected to am355x soc
Jul 13 10:28:43 <Guest7563> same is for usb1 which is usb host on bbb.
Jul 13 10:42:39 <madhu__> Hi All
Jul 13 10:43:37 <madhu__> I want to learn how network drivers work in linux
Jul 13 10:44:00 <madhu__> so i am planning to write some drivers on network devices
Jul 13 10:44:20 <madhu__> But problem is i don't know, from where to start and all
Jul 13 10:44:47 <madhu__> if somebody has some idea, which i can put it on beaglebone black
Jul 13 10:44:52 <madhu__> please suggest me
Jul 13 10:45:01 <madhu__> it would be great help
Jul 13 10:58:06 <tbr> madhu__: what exactly do you mean by "network drivers"? What sort of thing are you trying to learn about the Linux kernel?
Jul 13 11:00:29 <madhu__> I will explain you, I have learnt the i2c and uart protocols by writing some drivers for both i2c and uart
Jul 13 11:01:20 <madhu__> what i did is, i took one temperature sensor, and i connected via i2c and i wrote a small driver to get the temperature values
Jul 13 11:01:42 <madhu__> like that, to know about networking concepts in linux, what should i do
Jul 13 11:02:15 <madhu__> is it clear now??
Jul 13 11:05:21 <cyberguy> how do i change pinmuxing with BBB? for instance , i want to change K18 to RGMII1_TCK from command line
Jul 13 11:37:58 <tbr> madhu__: I'd say you should look at the kernel source code, specifically that for the network device drivers.
Jul 13 11:38:08 <tbr> not really beaglebone specific though
Jul 13 11:38:32 <cyberguy> tbr: how do i configure the pin-muxing ? is there any command line tool for that?
Jul 13 11:40:55 <tbr> cyberguy: that would be in the device tree and its overlays, I'd say
Jul 13 11:42:15 <cyberguy> So there isn't any command line tool (for dummies like me... ) that do all the hard work for you ...?
Jul 13 12:32:46 <cyberguy> is there any way in the command line to check current pin  functionallity? (for instance K18 is used as GPIO .. ?)
Jul 13 12:35:51 <georgem> closest thing to what you want may be: /sys/kernel/debug/gpio
Jul 13 12:54:27 <zmatt> cyberguy: I have a "show-pins" utility -> https://github.com/mvduin/bbb-pin-utils
Jul 13 12:55:21 <zmatt> the pin labels in the first column are oriented towards the bbb, but you can easily change those in the data table at the end of the script
Jul 13 13:10:42 <zmatt> and do I understand correctly that you're currently running with a device tree that configures the ethernet to MII while actually an RGMII phy is attached?
Jul 13 13:13:58 <zmatt> good thing it's not the other way around, since that would have resulted in a drive conflict on the txclk pin :P
Jul 13 15:23:23 <zmatt> jkridner: you here?
Jul 13 15:23:45 <jkridner> what's up?
Jul 13 15:24:38 <zmatt> you have any idea what the hell is up with TI having removed everything about omap4 and omap5 from their website?
Jul 13 15:26:07 <zmatt> even direct links to pdfs no longer work
Jul 13 15:26:46 <zmatt> i.e. the primary source of documentation is gone, even though people are still doing development for these targets
Jul 13 16:38:35 <phinxy> zmatt tried google cache?
Jul 13 16:53:21 <zmatt> phinxy: google cache is going to explain what's going on here?
Jul 13 16:53:49 <zmatt> (also, it doesn't cache or even index most of TI's documentation for some reason)
Jul 13 17:04:08 <zmatt> like, they even still published an update to the omap5 trm less than a year ago
Jul 13 17:13:30 <MathOnNapkins> zmatt: possible it's just a mixup / error. If it were me I'd email someone at TI b/c maybe they don't know they're missing
Jul 13 17:18:16 <zmatt> that sounds rather implausible
Jul 13 17:26:45 <MathOnNapkins> well perhaps not plausible to you, but I have run into cases with major companies where certain files and documents were conspicuously missing for no apparent reason
Jul 13 17:30:47 <zmatt> not just documents, their entire product pages
Jul 13 17:31:00 <zmatt> (and associated documents)
Jul 13 17:32:54 <zmatt> but anyway, yes maybe there's some explanation, which is why I had poked jkridner in case he might know if they were intentionally removed or not
Jul 13 17:33:20 <jkridner> what's missing from where?
Jul 13 17:33:36 <jkridner> omap4 omap5 docs?
Jul 13 17:33:53 <jkridner> do you have a ti literature number/
Jul 13 17:33:54 <jkridner> ?
Jul 13 17:34:07 <zmatt> jkridner: http://www.ti.com/product/omap5432
Jul 13 17:35:07 <jkridner> well, product pages might come down if TI isn't trying to sell the device anymore.
Jul 13 17:35:47 <jkridner> http://www.ti.com/tool/omap5432-evm?keyMatch=omap5432&tisearch=Search-EN-Everything
Jul 13 17:35:50 <zmatt> no, then you just mark it NRND... devices are still out there and in fact being developed
Jul 13 17:36:03 <zmatt> which means devs expect to find docs
Jul 13 17:36:18 <zmatt> and like I said, they still updated the TRM less than a year ago
Jul 13 17:37:01 <jkridner> hmmm... swps051k seems to be missing
Jul 13 17:37:09 <zmatt> yes
Jul 13 17:37:37 <jkridner> yeah, taking that down sounds like a mistake. I'll ask around.
Jul 13 17:37:49 <jkridner> probably an overzealous prune job.
Jul 13 17:37:49 <zmatt> ok, so I see some direct doc links still work
Jul 13 17:38:10 <zmatt> thanks
Jul 13 17:38:11 <jkridner> but I'd expect at least swps051 to be available.
Jul 13 17:39:22 <zmatt> swpz037 and swpu249 seem to be up
Jul 13 17:39:46 <zmatt> having to dig through lit numbers to reconstruct plausible urls to try isn't exactly the greatest way to browse documentation
Jul 13 17:40:55 <zmatt> same goes for omap4 btw... I don't personally care about it really, but I still see plenty of omap4 commits going on the linux-omap mailing list, so clearly there are people out there who care
Jul 13 17:43:40 <zmatt> looks like the motorola droid 4 has a fan club
Jul 13 17:57:59 <cyberguy> is there any quick way from command line to mux pins (not in the P8/9 headers) in BBB ? for instance change the MII_CLK to GPIO
Jul 13 18:15:37 <zmatt> cyberguy: you're bringing up a board that differs in relevant ways from the bbb... you're not going to escape having to learn how to adjust the Device Tree to match your hardware
Jul 13 18:18:17 <zmatt> https://github.com/RobertCNelson/dtb-rebuilder/blob/4.9-ti/src/arm/am335x-bone-common.dtsi#L375
Jul 13 18:18:28 <zmatt> that's where the phy interface is set
Jul 13 18:18:41 <zmatt> and lines 101-120 is the pinmux for ethernet
Jul 13 18:18:57 <zmatt> 101-157 actually
Jul 13 18:55:47 <cyberguy> zmatt : thanks, i already done that... i'm already tweaked my BBB a bit , removed the 100 PHY and connected it to Gbit Ethernet Port...
Jul 13 18:56:03 <cyberguy> zmatt: and ofcourse changed the device tree, compiled the kernel... everything..
Jul 13 18:56:31 <cyberguy> zmatt: the problem is, that it doesn't work... :) , i'm trying to make sure the muxing work properly, so i'm trying to mux the GPIO and flag in...
Jul 13 19:03:26 <cyberguy> zmatt: how do i use this dtb-rebuilder?
Jul 13 19:41:18 <zmatt> did you read the readme?
Jul 13 19:43:21 <zmatt> also, did you try my script for checking the pinmux?
Jul 13 19:43:51 <zmatt> you do need to pass the -v flag to show ethernet pins, I hide those by default since they're not normally of interest to users
Jul 13 20:02:06 <zmatt> lol wtf, I hadn't even noticed this yet...
Jul 13 20:02:09 <zmatt>     qblt    myLabel, r2.w0, 5  // Branch if 5 < r2.w0
Jul 13 20:02:10 <zmatt>     qblt    myLabel, r3, r4    // Branch if r4 < r3
Jul 13 20:02:18 <zmatt> nicely done
Jul 13 20:02:40 <zmatt> (pru assembly)
Jul 13 21:11:25 <phinxy> Is the Linux OS:s for BBB real time?
Jul 13 21:39:06 <zmatt> the usual kernels for bbb (robert nelson's -ti and -bone kernels) come in both normal and -rt flavors
Jul 13 21:40:16 <zmatt> however it often makes more sense to use PRUSS for real-time stuff
Jul 13 21:56:11 <kremlin> TI's method of delivering PCB design files is absolutely ridiculous
Jul 13 21:56:34 <kremlin> they give you a per-chip database file that plugs into their proprietary literal windows 95 software
Jul 13 21:56:47 <kremlin> that loads it, generates a couple of scripts and a text file
Jul 13 21:57:01 <kremlin> you run those scripts in your design program, and that generates a single-component library file
Jul 13 21:57:04 <kremlin> it's so weird
Jul 13 23:21:48 <zmatt> hmm?
Jul 13 23:24:13 <zmatt> I thought they used that "ultralibrarian" thing?
Jul 14 01:06:49 <kremlin> zmatt: that's what im talking about
Jul 14 01:17:06 <zmatt> that doesn't look like it's TI's proprietary thing... https://www.ultralibrarian.com/
Jul 14 01:26:51 <kremlin> o
**** ENDING LOGGING AT Fri Jul 14 03:00:02 2017