**** BEGIN LOGGING AT Wed Dec 09 03:00:26 2015 Dec 09 04:00:40 Anyone there? Dec 09 04:38:48 hi every one. Dec 09 04:38:49 I am using beaglebone green with latest debain image and 4d systems LCD cape on it. Eqep0 is not working. I have loaded the bone_eqep0.dts. When i cat the perion , I am getting 0. It would be great if someone could help me out. Dec 09 04:46:00 When i cat the position i get 0 Dec 09 09:04:36 abhilash: I did some quick tests with QEO a while ago, seemed to work fine... haven't tied useing the kernel driver though Dec 09 09:07:44 thanks zmatt Dec 09 09:08:24 actually the thing is in 4d CAPE, they are using GPIO3_19 Dec 09 09:08:31 i did a dmesg | tail Dec 09 09:08:41 there was conflict Dec 09 10:51:00 So appearently my BBB just died when connecting my 5V power supply to it. It was already connected and powered via USB only, when I plugged in the DC, all LEDs just went off immedeately. Dec 09 10:51:53 I checked the power supply using a voltmeter: 5.09V - all perfectly fine. Any guesses on what went wrong? Dec 09 10:52:50 Now the BBB seems dead, nothing's happening when I connect to it via USB only. Dec 09 10:57:59 hello Dec 09 11:04:07 irc_user: did you measure potential between USB and the power supply? Dec 09 11:05:27 tbr: No. Dec 09 11:09:30 you should check that. sometimes things can get surprisingly bad Dec 09 11:10:04 but yeah, sounds like you need to buy a new board. (unless you are into reworking SMD and replacing the PMIC) Dec 09 17:54:40 Hi, is there a way to remove UU entries from i2c-1, devices 55-57 Dec 09 17:55:07 MaBe: yes but why? Dec 09 17:56:18 tried dtc and deleted lines, rebooted and now i have a brick :-( Dec 09 17:57:43 because i do not need them Dec 09 17:58:49 how do I remove them Dec 09 18:00:02 I guess you better don't, there is usually a reason for a kernel driver for that device Dec 09 18:00:21 what board, what bus and what address? Dec 09 18:09:08 any help how to remove 54-57 from i2c-1 ? Dec 09 18:19:00 @Defiant: can you please explain howto ? Dec 09 19:23:09 Hello Dec 09 20:50:18 Hello Dec 09 21:34:14 I deleted can0 by mistake Dec 09 21:34:28 using sudo ip link delete can0 Dec 09 21:34:36 do you know how to get it back? Dec 09 22:08:36 Hello! I deleted the can0 device by mistake by using sudo ip link delete can0 Dec 09 22:08:43 is there any way to get it back? Dec 09 22:09:17 reboot? Dec 09 22:10:09 i tried but it did not work Dec 09 22:10:21 still i get "cannot find can0" Dec 09 22:10:42 I am trying to update the software Dec 09 22:10:51 not sure what to do other than that Dec 09 22:31:19 someone? please? :( Dec 09 22:31:40 oops Dec 09 22:33:41 hard reset .. power down, power up .. if your configuration for the interface is correct, it should pop back up Dec 09 22:34:09 Hello! I deleted the can0 device by mistake by using sudo ip link delete can0. How can i fix that? Dec 09 22:43:41 of all the published images, are the TI kernel ones the only ones that have a working SGX driver? Dec 09 22:48:20 ds2 .. I think those are the only ones with the relevant code in... Dec 09 22:50:00 I presume rightly or wrongly that the SGX code support in OpenGL et al is proprietary and requires NDA and funky stuff too? Dec 09 22:50:27 IE too look at source or integrate it into anything. Dec 09 22:55:15 'k Dec 09 23:05:10 RN was talking about a project which should alleviate -some- of the proprietary stuff iirc .. Dec 09 23:49:47 it is no big deal Dec 09 23:54:43 unless you need to use the SGX for anything. Are there any drivers for OpenGL et al besides the TI stuff? Dec 09 23:58:47 ds2: I had sgx working on a not-very-recent console image that still used a -bone kernel Dec 09 23:59:37 with kernel and sgx stuff built using rcn's scripts Dec 10 00:00:21 dunno if things are easier now, they certainly could have been easier than they were when I tried it :P Dec 10 00:01:38 in conversation with rcn-ee it turned out the redistribution license is much more permissive than he thought Dec 10 00:02:37 so the crap with downloading an sdk from TI, unpacking, compiling, etc really isn't necessary (anymore, may have been more restrictive in the past) Dec 10 00:10:16 compiling the demo included with the sdk also was "fun" :P Dec 10 00:10:25 due to paths Dec 10 00:13:37 zmatt .. that's interesting to know Dec 10 00:14:00 it could now just be apt-get install Dec 10 00:14:36 if someone's created the deb :p Dec 10 00:27:28 well not sure I was interested in to 7 years ago LOL. Dec 10 00:33:18 zmatt: does he have the sgx kernel side merged into his trees? Dec 10 00:33:47 no, separate repo Dec 10 00:33:54 oh blah Dec 10 00:34:04 yeah, well, I don't blame him Dec 10 00:34:13 browse the tree to understand why Dec 10 00:34:14 trying to find the path of least resistance to use all the known cores on the am33 Dec 10 00:34:34 I know what tree looks like. I have done a merge before. just trying to avoid doing it again ;) Dec 10 00:34:53 why merge instead of building it as a module? Dec 10 00:35:17 no modules. not going to module hell. Dec 10 00:36:17 i wonder if there is a trivial way to synchronize the PRU with the lcd driver Dec 10 00:38:16 yes Dec 10 00:38:44 there's a clock mux that allows PRUSS to be clocked by the Display PLL Dec 10 00:39:15 is the display PLL that generates the PCLK? Dec 10 00:40:12 display PLL is usually the selected source for the LCDC functional clock, which is then usually divided by 2 to result in the final pixel clock Dec 10 00:40:35 Hmmm Dec 10 00:40:56 can the final PCLK be divided by more then 2? Dec 10 00:41:22 in case you are curious - I am looking for a easy way to generate NTSC color Dec 10 00:42:25 2-255 iirc Dec 10 00:42:39 if the DisplayPLL can something like 56X the PCLK, then PCLK can be color burst and color is pretty trivial Dec 10 00:42:44 oooh Dec 10 00:43:33 this is worth pursuing Dec 10 00:44:09 SGX for image process; LCDC to generate color burst; PRU to generate video out and capture camera in... A8 just has to coordinate it all Dec 10 00:44:54 just need to take a deep breath and dive into the clock framework code to get the mux reconfigured Dec 10 00:44:57 lcdc to generate color burst? Dec 10 00:45:20 there's nothing lcdc can do that pru can't Dec 10 00:45:29 except maybe widely parallel output Dec 10 00:45:31 yeah... setup PCLK to generate the 3.57MHz Dec 10 00:46:11 I doubt if the LCDC can generate proper composite VSYNC w/o a lot of HW Dec 10 00:46:27 right now, the PRU drives a mux for gray level/sync Dec 10 00:46:29 it can't even generate proper separate sync Dec 10 00:47:07 on the bbb they configure the hdmi framer to regenerate the hsync Dec 10 00:47:18 with *correct* timing Dec 10 00:47:19 the problem is LCDC would generate a sync vsync pulse; composite wants funky business with a long 0v signal Dec 10 00:47:29 *nod* Dec 10 00:47:49 to fix that requires a NTSC framer which is more complex then PRU SW Dec 10 00:48:09 but you're saying "PRU for video out", then where's lcdc involved anymore at all? Dec 10 00:48:14 only trickly part is generating 3.57MHz on the PRU when it is clocked by 200MHz Dec 10 00:48:26 the LCDC is setup solely to generate a 3.57MHz squarewave on the PCLK line Dec 10 00:48:52 as long as the PRU can be synchronous to a multiple of that, I can do color (color is done by different phases relative to 3.57MHz) Dec 10 00:48:55 if you don't need lcdc, you have the display PLL freely available to clock PRUSS Dec 10 00:49:00 you can run PRU at any rate you want Dec 10 00:49:16 I want the divider block to simplify things Dec 10 00:49:30 plus using PCLK gets me an extra pin to the outside world Dec 10 00:49:59 just got ot make sure I can get reasonable close to 56*3.57MHz on that PLL Dec 10 00:50:02 I doubt it'll simplify things, since you gain the problem of synchronizing to the lcdc frame timing Dec 10 00:50:21 zmatt: why? last I checked, PCLK runs continously Dec 10 00:50:28 oh right Dec 10 00:50:35 you're gating it externally? Dec 10 00:50:54 yeah... it needs to drive a transistor as it is like a 0.3V "ripple" signal I need Dec 10 00:51:07 also need to low pass it as NTSC wants a sine wave not a square wave Dec 10 00:51:18 so you lose a PRU pin anyway? Dec 10 00:51:21 all that is just a few passives Dec 10 00:51:39 PCLK is on a pin mux with the PRU? thought it was only LCD_DATA pins that are shared Dec 10 00:51:57 no I mean, if you use lcdc you need a pin to gate it Dec 10 00:52:19 if you don't use lcdc you need a pin to generate the signal, but probably wouldn't need a separate rate Dec 10 00:53:19 Oh like that... the PRU is already controlling a mux; it would use the mux for the gating Dec 10 00:53:32 I see Dec 10 00:53:33 things are working for the monochrome case already Dec 10 00:54:02 how much tolerance is there on the 3.57 MHz ? Dec 10 00:54:26 according to the old articles - maybe +/-0.02MHz Dec 10 00:54:34 ohhhhhh Dec 10 00:54:39 but it depends on the screen Dec 10 00:54:40 200 MHz / 56 = 3.57142857143 Dec 10 00:54:49 :D Dec 10 00:55:16 w/o the synchronization, I can potentially be slip relative to color burst in the PRU which translates to shifting colors Dec 10 00:55:17 you could use the pruss ecap also Dec 10 00:55:21 as a pwm Dec 10 00:55:59 anyway, plenty of options Dec 10 00:56:01 is the ecap guaranteed to be synchronous wrt to the rest of the PRU? Dec 10 00:56:40 there's a bit you need to toggle iirc, it's in the TRM.. it has two possible clock sources Dec 10 00:57:07 wonder if any of them is a input from a pin? Dec 10 00:57:22 btw, for clocks... https://github.com/dutchanddutch/jbang/blob/master/include/ti/subarctic/prcm.h Dec 10 00:57:28 search for "muxes" Dec 10 00:57:35 next step up is to synchronize with an external 3.57MHz color burst to do overlays in color Dec 10 00:57:37 (there are two sections) Dec 10 00:59:16 there might also be an interesting option to get a low-jitter clock if that's of any value, but that requires a bit more scenic route in the clock tree Dec 10 01:00:31 that's the HW. diving into the clock framework code on Linux will be an adventure in itself Dec 10 01:01:01 delete the DT nodes, problem solved :P Dec 10 01:01:08 ;) Dec 10 01:01:24 last I looked, that code isn't complete and relies on crap in U-boot Dec 10 01:01:34 keep in mind only pll-per is the only low-jitter pll Dec 10 01:02:29 ds2: be sure to keep the prcm.h I linked to handy, it's probably a more useful overview than the TRM Dec 10 01:02:44 ctrl.h is in the same dir for the control module (which also affects some muxing) Dec 10 01:03:01 if jitter is an issue, keep in mind pll-per is the only low-jitter PLL Dec 10 01:03:35 (that's why RMII requires an external clock, the internally generates one derives from pll-core which had too much jitter) Dec 10 01:04:32 probally going to have to map it from the Linux end; that .h should be a good check Dec 10 01:05:16 you can route pll-per as alternative bypass clock to the auxiliary PLLs such as pll-disp Dec 10 01:05:59 one thing at a time Dec 10 01:06:14 I assume the SGX has its own PLL, right? Dec 10 01:06:20 it is also used for the PRU uart and iep, though you can switch that over to PRU's main/ocp clock Dec 10 01:06:23 no Dec 10 01:06:27 not afaik Dec 10 01:06:30 oh sigh Dec 10 01:06:49 but it's pointless to run SGX synchronous anyway Dec 10 01:07:02 since it runs variable-time code Dec 10 01:07:06 ls Dec 10 01:07:10 hmm? Dec 10 01:07:10 oops Dec 10 01:07:12 veremit: I'm here! Dec 10 01:07:24 if it doesnt have its own PLL... that would make it synchronous Dec 10 01:07:48 ds2: I mean, "own pll" suggests you care about frequency locking or such Dec 10 01:08:09 I care being able to run the SGX at its max clock rate Dec 10 01:08:22 getting the right outputs may require running other clocks slightly slower Dec 10 01:08:47 not with pruss running on pll-disp Dec 10 01:08:50 (sgx runs on core Dec 10 01:08:51 ) Dec 10 01:08:53 AFAICT, the SGX should make a nice batch processing system Dec 10 01:09:49 running SGX at an odd speed would mean it needs asynchronous bridges on all its interconnect ports Dec 10 01:10:15 that's a good point Dec 10 01:10:52 so I'd say use pll-disp (or more advanced, pll-per) for your oddball clocking needs Dec 10 01:11:13 pll-per has lower jitter, but changing it from its default means losing USB Dec 10 01:11:43 need USB Dec 10 01:12:56 then pll-disp it is Dec 10 01:13:48 see clksel_pruss_ocp in prcm.h Dec 10 01:13:51 it is too bad there are no exposed clock inputs to synchronize the PRU with an external clock Dec 10 01:14:11 zmatt: how woudl clksel_pruss_ocp help? I'd think Ineed to figure out hte magic clk_get/put stuff Dec 10 01:14:57 by looking at the hex offset I added as a comment at the start of the line Dec 10 01:15:08 and looking it up in the clocks dtsi Dec 10 01:15:32 it's also possible the mux isn't even declared in DT yet because noone needed it Dec 10 01:16:24 in which case you can either declare it Dec 10 01:16:40 in that case, I might as well hack it into U-boot ;) Dec 10 01:16:52 or have the bootloader set the mux bit, and change the DT to claim pruss is clocked by disp-m2 Dec 10 01:16:57 exactly Dec 10 01:17:51 note that per-m2 (192 MHz) also goes to pruss for some of its peripherals, like the uart Dec 10 01:18:10 but there was some bit you can toggle to switch it over to the normal/ocp pru clock Dec 10 01:18:37 it is undocumented what the deal is with the clocking of ecap, just try it Dec 10 01:19:02 hmmm Dec 10 01:19:52 (interestingly aforementioned bit may never be cleared once set -- this suggests it also causes async bridges to be bypassed) Dec 10 01:20:17 this is a lot of adventure Dec 10 01:20:25 not really Dec 10 01:20:33 I mean Dec 10 01:20:38 yes, great adventure! Dec 10 01:20:42 prehaps the excursion into gpgpu land Dec 10 01:20:55 that *is* an adventure Dec 10 01:21:28 well, but I haven't been down that road whereas the clock tree is a known adventure Dec 10 01:21:52 the clock tree is trivial Dec 10 01:22:46 you need to flip two bits and all of PRU suddenly runs on disp-m2 Dec 10 01:23:25 configure the PLL as desired (keeping the official max of 200 MHz in mind... well, or not, your call of course) Dec 10 01:23:27 assuming things work as expected Dec 10 01:23:51 I've never had much fights with clocking really Dec 10 01:23:57 been down the road chasing clocks for the RGMII Dec 10 01:24:01 you work in bare metal land Dec 10 01:24:06 yes Dec 10 01:24:14 everything is so wonderfully easy there Dec 10 01:24:19 my adventure involves chasing through layers of code Dec 10 01:24:53 I know that part, which is exactly why I don't even try to fix all the broken linux drivers I encounter, I just bypass them Dec 10 01:24:57 was wondering why I don't see code to setup the clocks in Linux... the reason is quite sherlock holmes-esque Dec 10 01:25:20 there is NO code to setup the clocks in Linux :D it relies on U-boot Dec 10 01:25:22 just setup your desired clocks in u-boot and tell linux how it is in DT Dec 10 01:25:28 that's not true afaik Dec 10 01:25:36 that's not true, period. Dec 10 01:25:43 display PLL is dynamically changed Dec 10 01:25:46 no code for the particular clock I needed Dec 10 01:25:59 not speaking in general Dec 10 01:27:01 iirc dividers and muxes usually don't really have specific code... just a generic driver, and register + bit offset declared in DT Dec 10 01:27:28 or, just setup in u-boot and tell linux via DT how you set things up :) Dec 10 01:27:50 that's actually the saner solution if you don't need changes at runtime Dec 10 01:29:05 still an adventure sorting that out Dec 10 01:29:42 prcm.h contains pretty much the whole clock tree (and a few comments on where other mux bits are) Dec 10 01:29:58 well ok not the actual tree Dec 10 01:30:04 but the registers making it up Dec 10 01:30:42 and at least the AM335x TRM puts an "integration" section near the start of each chapter Dec 10 01:31:03 plenty of older TRMs don't Dec 10 01:31:49 fun with SGX first Dec 10 01:31:57 where is that link again .. curious .. Dec 10 01:32:06 SGX integration debug registers are documented in the DM814x TRM Dec 10 01:32:23 (some subsection of chapter 1) Dec 10 01:32:39 dunno if they're useful, but just in case Dec 10 01:32:51 not on that layer Dec 10 01:32:53 veremit: hmm? Dec 10 01:33:19 veremit: https://github.com/dutchanddutch/jbang/tree/master/include/ti/subarctic <-- that one? Dec 10 01:33:20 get the SGX to do some simple stuff like convolutions and measuring the texture transfer rates Dec 10 01:34:08 ds2: apparently OpenCL would be possible but it's "up to the vendor" to include support for that in the driver package or not Dec 10 01:34:28 yes, hence not going down that road Dec 10 01:35:05 AFAICT, OpenCL provides better datatypes and nicer transfer rates but shades and textures should be doable using pure GLES2 Dec 10 01:35:38 the unknown is texture transfer rates; lots of reports of them being slow Dec 10 01:35:39 ds2: I have a different mountain ahead of me for SGX... for testing purposes I would like it to generate some bus transactions on request Dec 10 01:36:00 zmatt: couldn't you just shove textures around to do that? Dec 10 01:36:19 that's the other little detail: from baremetal. Dec 10 01:36:27 preferably while EMIF is disabled Dec 10 01:36:47 for interconnect testing purposes Dec 10 01:37:22 that seems to be a lot harder Dec 10 01:37:42 and I assume you want bus transactions for data and not just register accesses Dec 10 01:38:01 I want it to generate L3 transactions Dec 10 01:38:12 to map its view of the L3 Dec 10 01:38:31 on other cores I'd just write a tiny test program Dec 10 01:38:53 but the core on which the sgx microkernel runs is undocumented Dec 10 01:39:51 it seems to me however there's a good chance that sgx can generate 2D block bursts, in which case it's the only initiator on the am335x capable of doing so hence a very valuable test case Dec 10 01:41:04 I think I'll just post on the powervr list, who knows I might get lucky Dec 10 01:41:49 or a C&D letter ;) Dec 10 01:41:53 especially since I don't need to know anything whatsoever about anything to do with its graphics pipeline Dec 10 01:42:04 where all the IP is presumably Dec 10 01:43:17 plus, a slightly better prog could be used for interconnect performance analysis Dec 10 01:44:23 which help squeezing more 3d performance out of their chip Dec 10 01:44:32 always good from a PR pov Dec 10 01:45:06 as you say, probably all I need is already there Dec 10 01:45:31 I just need a really really really tiny subset Dec 10 01:45:53 oh well Dec 10 01:46:01 simpler initiators first :P Dec 10 01:50:52 I think rcn was trying to get bitcoin mining on the x15 gpu going .. Dec 10 01:50:52 and thanks zmatt .. yes, that's the one Dec 10 02:46:23 Hi everyone, I have a question. Dec 10 02:47:45 I have a beaglebone black with debian wheezy, can I upgrade it via changing the /etc/apt/sources.list to jessie? **** ENDING LOGGING AT Thu Dec 10 02:59:59 2015