**** BEGIN LOGGING AT Sat Dec 12 02:59:59 2015 Dec 12 09:18:18 wheeeeeeeeeeeeeeeeeeeeeeeeeeeeeee my first OpenGLES program running on the BBB! Dec 12 09:19:13 w00t Dec 12 09:19:19 ES1 or 2 ? Dec 12 09:19:51 ES2 Dec 12 09:20:08 next step is to figure out texture stuff Dec 12 09:20:20 then I have my very own micro super computer at my disposal :D Dec 12 09:20:29 hehe Dec 12 09:21:24 people keep adding funny stuff to the kernel Dec 12 09:22:09 like userfaultfd ... allowing you to handle pagefaults in userspace :D Dec 12 09:22:20 I have come to the conclusion that userland folks speak a multitude of incomprehensible jibberish Dec 12 09:22:41 wonder what would happen if the userfaultfd handler is swapped out ;) Dec 12 09:22:58 nothing remarkable Dec 12 09:23:34 note that you register the handler for a specific memory region Dec 12 09:23:39 it's not global or something Dec 12 09:23:53 first and biggest use case is live-migration Dec 12 09:24:55 you can start processes at the new location already and transfer their data as needed to handle the pagefaults Dec 12 09:25:06 or emulation Dec 12 09:25:47 or shared memory via the network.. that one might have some performance drawbacks though ;) Dec 12 09:26:07 HiPPi Dec 12 09:26:17 ? Dec 12 09:26:37 it is some fast networking protocol used by the supercomputer folks... might be obsolete by now Dec 12 09:26:55 ah Dec 12 09:27:10 btw, have you ever tried: unshare -u -r Dec 12 09:27:16 nope Dec 12 09:27:23 try it for fun (it's safe) Dec 12 09:27:30 as normal user Dec 12 09:27:35 HE HE HE Dec 12 09:27:47 shared memory via network might not be as bad Dec 12 09:28:01 MPP using a RGMII interface Dec 12 09:28:07 or plain GMII Dec 12 09:29:56 well the bad part is that it would only have page granularity Dec 12 09:30:23 why's that bad? Dec 12 09:30:37 on x86, IIRC - you can have pages as small as 16bytes Dec 12 09:30:41 can easily lead to thrashing Dec 12 09:30:41 no Dec 12 09:30:48 4 KB Dec 12 09:31:23 so, multicore cpu caches often do this sort of thing too, but with cacheline granularity Dec 12 09:32:26 you mean what Linux uses or the hw can do? Dec 12 09:33:53 a net-shmem would have its pages readonly by default, on write you'd need to negotiate an exclusive lock which involves making the page read/write for that node and unreadable for all others. an access by someone else would then grab the updated version from the current page owner (which would revert to read-only or no-access depending on whether the other node wants to read or write) Dec 12 09:33:59 both Dec 12 09:34:02 I think Dec 12 09:34:29 in any case what linux uses is ultimately the relevant limit Dec 12 09:34:40 the hw can change it Dec 12 09:34:45 there are large pages Dec 12 09:34:58 IIRC - there are bits in the page entries to specify different shift or something like that Dec 12 09:35:21 there are usually a few page sizes Dec 12 09:35:59 though on ARM some of them just require 16 consecutive identical page table entries (but having the benefit of taking up only 1 TLB entry, thus reducing TLB pressure) Dec 12 09:36:50 some ancient ARM cores supported "tiny pages": 1 KB Dec 12 09:37:03 but other than that I've never seen smaller than 4 KB Dec 12 09:37:47 did you try the unshare btw ? it really is funny to see a user namespace in action Dec 12 09:38:38 creating only a new user namespace is so much weirder than a full container Dec 12 11:21:42 hiya Dec 12 11:22:34 moo Dec 12 11:22:41 quick question: is there a document (or firm knowledge) about the location of J1 relative to P9 Dec 12 11:22:57 ...other than Altium-files which I can't open as I use eagle (on mac) Dec 12 11:26:00 it seems the pitch between P9 pins and J1 is not 2.54mm but something else, can't find that info Dec 12 11:31:31 have you checked the SRM? Dec 12 11:32:05 yes Dec 12 11:32:11 it has pics, but no measurements Dec 12 11:33:04 cape dimensions are there and P9 and P8 locations Dec 12 11:35:20 mh, J1 is the debug uart. it's not really intended for cape use Dec 12 11:36:46 I know, I just want to bring it through Dec 12 11:36:55 indeed for debugging Dec 12 11:37:12 because we need to debug with the cape :) Dec 12 11:48:56 :) Dec 12 11:51:31 <_av500_> Jartza: I think its .05" off Dec 12 11:51:35 <_av500_> so half a .1 step Dec 12 11:51:55 <_av500_> Jartza: I remember drilling between the holes one a .1 proto board Dec 12 11:52:07 <_av500_> snd I cursed a lot :) Dec 12 11:52:27 I can imagine Dec 12 11:52:44 that would be 3.81mm Dec 12 11:53:22 measuring with caliper it looks closer to 3.2mm though Dec 12 12:09:13 so, nobody knows? Dec 12 12:12:55 have you tried opening the gerbers? Dec 12 12:15:44 seems 125 mil spacing between there Dec 12 12:15:46 3.175 mm Dec 12 12:19:04 heh, nice I can even open it using http://www.gerber-viewer.com/default.aspx Dec 12 12:21:12 and yeah, seems to be 3.175 Dec 12 12:44:37 yeah Dec 12 13:21:07 hahaha wtf Dec 12 13:21:19 ok no wonder the phy doesn't reset on reboot Dec 12 13:21:55 this is the "reset pulse" supposedly asserted by the am335x on the reset line on warm reset -> http://gerbil.xs4all.nl/bbb-warm-reset.png Dec 12 13:32:03 ah nm Dec 12 13:39:54 new image at same url, proper capture of a "reset" when I manually configure the warm reset output pulse time to its max value Dec 12 13:40:16 capacitor vs output driver: 1-0 Dec 12 14:16:04 HALLO Dec 12 14:17:00 i have one question and i dont find anything to that issue Dec 12 14:17:33 i have a beaglebone black and i want to change the spee/frequency of the i2c1 Dec 12 14:19:03 i understand how it works with i2c0, but when i search in .dts i cant find the the clock-frequency of i2c1 Dec 12 14:19:14 anybody an idea? Dec 12 14:19:24 DUDA: which dts did you search? Dec 12 14:20:35 am335x-boneblack.dts Dec 12 14:20:48 DUDA: you see the includes at the top? Dec 12 14:22:39 what do you mean with that Dec 12 14:22:52 DUDA: the dts is split into multiple files Dec 12 14:23:10 ok no that is new for me Dec 12 14:23:36 at least on the kernel I have checked out Dec 12 14:24:34 quick and dirty search yields results: grep -20 i2c1 *.dts|grep clock-frequency Dec 12 14:26:05 ok i try it Dec 12 14:34:35 find not exactly i2c1, but i2c@4819c000 there is an entry with clock-frequency Dec 12 14:34:50 is that i2c1 Dec 12 14:44:40 on line 564 of am335x-evm.dts on my board: &i2c1 { Dec 12 14:44:47 ymmv Dec 12 14:49:48 ok i try it again Dec 12 17:45:00 ok this is interesting... this bbb exhibits the dreaded Power Led Blip of Doom when attempting to power it via usb Dec 12 17:45:14 but powers up just fine when using an AC adapter Dec 12 18:49:48 i just accidentally short-circuit'ed a bbb by pulling GND to 5V. should just throw it away? any chance to fix it by hand? Dec 12 18:51:45 nevermind, it seems alive. after a cold reset waiting a couple minutes with the PSU unplugged from the mains it booted again Dec 12 20:24:19 You may have temporarily hit it in the head and it took some time for charge to "bleed" out of unknown areas. Dec 12 21:28:09 samael: the big question would have been "which gnd, which 5v?" **** ENDING LOGGING AT Sun Dec 13 02:59:58 2015