**** BEGIN LOGGING AT Fri Oct 23 02:59:58 2015 Oct 23 03:01:08 maybe I'm doing something silly so I'll start here if there's something immediately obvious: I have an lcd cape that's blank. I went through the instructions posted in the beagleboard/bb.org-overlays github repo and I'm getting nowhere. Here is where I am now: http://pastebin.com/tm2Bcgd0 Oct 23 03:02:11 I wanted to keep my kernel at 4.1 but in a last-ditch effort I moved to 4.2 in hopes that maybe there was a fix I was overlooking. still the same problem Oct 23 03:04:29 I'd guess there's a problem with your overlay Oct 23 03:06:01 also, one thing to mind is that apparently the dtbo format of 3.8 kernels and 4.x kernels are not quite the same, hence there are also different dtcs in circulation Oct 23 03:07:01 but I don't really know much details about that, I normally never use overlays (but they do work for me on 4.x Oct 23 03:07:04 ) Oct 23 03:10:26 ah the github repo already makes sure you have the right dtc Oct 23 03:10:45 then I would say a problem with the overlay itself is most likely Oct 23 03:11:54 the dmesg logs makes me think it's not even trying to load the overlay? Oct 23 03:12:13 dunno, "failed to load" Oct 23 03:12:45 [ 5.093377] bone_capemgr bone_capemgr: initialized OK. [ 5.173939] bone_capemgr bone_capemgr: slot #0: dtbo 'BB-BONE-LCD4-01-00A1.dtbo' loaded; overlay id #0 Oct 23 03:12:59 that's good trace that I would expect to see Oct 23 03:13:12 what slot is your cape actually using? Oct 23 03:13:19 (eeprom #) Oct 23 03:13:42 A0 Oct 23 03:13:56 I tried all the pin configurations already Oct 23 03:14:17 the slot changes when I move the pins around Oct 23 03:14:25 note that forcibly loading a cape using "capemgr.enable_partno=" is afaik duplicative with the auto-detection mechanism Oct 23 03:14:37 and might therefore possible even cause an error Oct 23 03:14:59 *possibly Oct 23 03:15:32 I'm not really sure, I never use the capemgr so I'd have to check the sources to see what it's doing and i'm too lazy for that right now :P Oct 23 03:16:02 I tried that permutation as well :) Oct 23 03:16:28 I tried all the pin settings with/without enable_partno Oct 23 03:16:49 if you have doubt about whether it even tried to load it, try loading it via the new configfs mechanism... it's more tolerant about stuff like metadata (read: it ignores all of it), and who knows maybe it even has more informative error messages Oct 23 03:16:56 I also tried different overlays Oct 23 03:17:16 have a link to the overlay source code? Oct 23 03:17:52 btw what's all that crap doing in your uEnv.txt ? Oct 23 03:18:06 those addresses and such Oct 23 03:18:19 euh Oct 23 03:18:20 huh Oct 23 03:18:38 /boot/uboot/uEnv.txt ? what weirdass image is this based on? Oct 23 03:19:58 * zmatt has never seen any file residing in /boot/uboot/ Oct 23 03:20:18 * zmatt pokes rcn-ee Oct 23 03:21:34 I have no idea, that's what was already there Oct 23 03:22:16 what distro version is it? Oct 23 03:22:18 I got the board from sparkfun and didn't do anything exotic with it? Oct 23 03:22:32 deb Oct 23 03:22:46 cat /etc/dogtag Oct 23 03:22:47 matthewaveryusa, looks like you are dealing the ancient 2014-may release (cat /etc/dogtab) Oct 23 03:22:56 our saviour is here! Oct 23 03:23:25 does not exist Oct 23 03:23:33 matthewaveryusa, then ancient.. ;) Oct 23 03:23:49 grab jessie: http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#2015-10-18 Oct 23 03:24:11 sorry, ssh was out, root@beaglebone:~# cat /etc/dogtag BeagleBoard.org BeagleBone Debian Image 2014-04-23 Oct 23 03:24:14 still ancient Oct 23 03:24:15 got it Oct 23 03:24:51 matthewaveryusa, one of the big problems with that one, it won't load a v3.14.x dtb, as it falls on top of the kernel image in ram.. Oct 23 03:25:00 then i never tried v4.1.x overlays on it either. ;) Oct 23 03:27:12 https://groups.google.com/forum/#!topic/beagleboard/AHCiZPcCQ3s this discusses 4.1 Oct 23 03:28:13 should work on jessie Oct 23 03:28:32 thanks, I'll try tomorrow after work! Oct 23 03:28:58 rcn-ee: gawd vayu's control module really is a mess... I mean, even more than the control module normally already is Oct 23 03:29:20 zmatt, must be disabled stuff stuck in it.. Oct 23 03:30:09 that doesn't explain why you'd put the DCAN ram init controls in the same byte as the DSS deshdcp_clock_enable bit Oct 23 03:30:31 in fact, what on earth is that last one even doing in the control module instead of PRCM Oct 23 03:32:10 rcn-ee: with a mess I don't mean all the gaps and such Oct 23 03:32:15 I mean the "sort -R" aspect Oct 23 03:33:15 zmatt, register "auto-router" with no rules... Oct 23 03:33:43 and using yet another way of storing a MAC address (different from the two used in the ethernet subsystem, different from previous control modules) Oct 23 03:34:00 no, not *that* random Oct 23 03:34:05 that's subarctic PRCM Oct 23 03:34:13 this isn't quite *that* bad yet Oct 23 03:34:36 but especially since it's an automotive chip I would have expected a bit more attention to detail Oct 23 03:35:21 but it seems centaurus was the last chip where designers bothered to pay a bit of attention to consistency and organisation :/ Oct 23 03:36:06 using different pin numbering for padconf, the wakeup-event array, and iodelay is particularly asinine Oct 23 03:36:18 zmatt, isn't am4x's mac also differnet then the am3x's.. Oct 23 03:36:48 dunno, I thought aegis' control module was still virtually the same as subarctic's Oct 23 03:37:02 (btw, don't say "am3x", that would also cover the am35xx :P ) Oct 23 03:37:53 nope, same format Oct 23 03:38:00 yeah, geting sucked into ti's terms'... anything "am3" on git.ti.com is am335x.. (sgx/etc) Oct 23 03:38:19 { b1, b0, -, -, b5, b4, b3, b2 } Oct 23 03:38:28 yeah, am33xx/am3517/dm816 mac in all differnt offsets... Oct 23 03:38:32 same as centaurus, subarctic, and also the format actually used in MII Oct 23 03:38:35 nope Oct 23 03:38:41 same offset in control module Oct 23 03:39:03 0x630 Oct 23 03:39:15 dunno am35xx Oct 23 03:39:16 i'm looking at: https://patchwork.ozlabs.org/patch/520232/ Oct 23 03:39:18 that's a whole different thing Oct 23 03:39:26 0x630, 0x110, 0x30 ;) Oct 23 03:39:55 but they are in the same order... Oct 23 03:40:03 dra7xx changed the memory order... Oct 23 03:40:06 oh wait, netra didn't have a cpsw Oct 23 03:40:06 yes Oct 23 03:41:53 wait, hum Oct 23 03:42:15 no nm, the docs are just being idiotic, I hope Oct 23 03:43:10 aegis describes 10--5432 Oct 23 03:43:30 it probably means 45--0123 same as centaurus and subarctic Oct 23 03:44:09 10--5432 *is* however the format used by the ALE, with the -- containing other data of the switch table entry Oct 23 03:44:45 vayu introduced 543-210- just to be different Oct 23 03:45:08 nobody apparently considered the actual order 012345 as stored in the packet to be a convenient one :P Oct 23 03:46:32 but this sort of crap is exactly what I mean with "gawd what a mess" Oct 23 03:46:43 vayu has many of the same registers seen previously in control modules Oct 23 03:47:19 but everything is arranged differently, often bitpacked together with completely unrelated stuff in a single register Oct 23 03:47:42 except not quite bitpacked, so a human was in fact involved Oct 23 03:47:45 just not one that cared Oct 23 03:48:26 or cared enough to mess with us.. Oct 23 03:48:42 "had one task".. ;) Oct 23 03:48:47 "never attribute to malice that what can be adequately explained by incompetence" Oct 23 03:48:55 :P Oct 23 03:49:07 that's a good quote tooo Oct 23 03:51:52 hmm Oct 23 03:52:15 Description: Register to configure some IP level signals Oct 23 03:52:19 good description too Oct 23 05:20:34 rcn-ee: argh, there's no gcc 5 yet in jessie, not even as a separate package? -.- Oct 23 05:22:25 I guess I can compile locally and then copy to the x15 Oct 23 06:37:47 that's new... the control module has locations that fault on read Oct 23 07:13:26 (also, you're kidding me? an "imprecise external abort" resulting from reading strongly ordered memory? wtf) Oct 23 07:15:10 rcn-ee: I think it's definitely a good idea to disable the omap_l3 driver... that thing spams the kernel log like hell, and it's not even remotely useful spam Oct 23 10:27:38 guide me to start beagleboneblack running debian Oct 23 10:32:53 http://beagleboard.org/getting-started Oct 23 10:53:13 it has #exactsteps Oct 23 13:35:19 Hey ther Oct 23 13:35:57 can anyone help me by providing documentation on how to build zigbee drivers on a beaglebone using ubuntu? Oct 23 13:37:54 I'm not aware of an open source zigbee stack for linux Oct 23 13:38:03 There is a 6LoWPAN stack Oct 23 13:39:46 for windows? Oct 23 14:24:54 hi Oct 23 14:25:31 I have a question to ask someone? Oct 23 14:26:39 Is it possible to install Android on the BeagleBoard? Oct 23 14:27:17 probably. look at rowboat or such. Oct 23 14:28:45 Android's anybody here in this range is installed and does not have the same problem? Oct 23 14:29:21 the same problem as what? Oct 23 14:30:39 I just want to know the relationship between hardware and more on Android with no problem on this board? Oct 23 14:31:27 people in here usually don't run android on their BBB Oct 23 14:54:58 Hello ... I have a (i hope) little problem with my first systemd service: Oct 23 14:56:41 I have written a python script which runs a pwm. Python script works. I have written a systemd service and service works (start/stop), but after reboot service is running but there is no pwm signal. I have tried different WantedBy, After, Require, etc. I am using Adafruit for the PWM. Oct 23 15:02:04 Cupro: sorry, most of us here hate systemd passionately Oct 23 15:02:25 those who dont hate systemd mostly left because of us haters Oct 23 15:03:35 oh great :) Oct 23 15:04:33 I am not really friend with systemd, because it doesn't work for me *g* Oct 23 15:06:04 KotH: so it's cool to hate systemd again? Oct 23 15:06:12 * bradfa is always behind the times Oct 23 15:06:45 bradfa: it was never uncool Oct 23 15:06:48 at least not here :) Oct 23 15:06:54 KotH: on #beagle? Oct 23 15:06:59 or the interwebs Oct 23 15:07:10 depends on your definition of "here" Oct 23 15:07:20 * bradfa feels at home again on #bealge Oct 23 15:09:31 I have found there is a seperat systemd channel here :) Oct 23 15:35:18 my company has a love/hate relationship with systemd. Oct 23 16:13:16 bradfa, we hate what we don't understand Oct 23 16:43:58 hellow Oct 23 16:44:43 Good afternoon I have a problem with the BBB at times when it starts 4dcape70-t screen goes black, and then when I reset it, it becomes all right again and the screen starts normally. Although it is rare it happens to the screen does not go up and turn black, what can it be? Problem with power supply? we've tested even with a power supply of 2 Ampers 5Volts, and it continues to present the same problem. I would appreciate your help, I' Oct 23 17:01:53 Anyone know of a good filler to put in the barrel jack to keep people from plugging stuff in? I know someone has to make it, but I can't come up with a name for it that nets google results. Oct 23 17:05:31 KotH: "most of us" ? when was that poll taken exactly? :P Oct 23 17:05:48 abferm: hot glue? Oct 23 17:05:58 abferm: polycaprolactone? Oct 23 17:06:03 abferm: just desolder the thing? Oct 23 17:08:25 Industrial product, so no hotglue/handmolded plastic where people see it. We already have a cut-out for it on our case, and it may come in handy internally. I just want a deterant for other people once it goes out the door. Oct 23 17:09:31 plastic plug? Oct 23 17:09:59 take the dimensions, find a plug of roughly the size Oct 23 17:10:20 might even exist as an actual part for those barrel connectors Oct 23 17:11:01 Yeah, searches aren't getting anything. I think it is an issue with coming up with the right name for said plastic plug. Oct 23 17:13:00 although finding a suitable plug is infinitely more convenient, polycaprolactone can actually look very nice if you don't hand-mold it (which causes fingerprint-texture) but use a smooth surface. also it's really easy to dye, made some glossy-black myself Oct 23 17:13:40 it's just too much effort unless the number of units s very small Oct 23 17:16:05 or make a rubber mold and cast plugs yourself out of some suitable material Oct 23 17:23:03 pick your poison: http://www.componentforce.co.uk/category/73/barrel-plugs Oct 23 18:33:04 abferm: talk with CCO about custom ordering the borads with the jack desoldered, they do customizations like that Oct 23 18:33:18 * bradfa has ordered a few 100s of BBW with no barrel jack previously Oct 23 18:47:25 wtf, the cortex-a15 turns a fault occurring while *reading* from *device* memory into an *async* abort?!? did that processor get dropped on the head as a baby or something? Oct 23 18:48:38 even surrounding the read with dsb instructions, and out of sheer desperation appending an isb and a bunch of nops still doesn't seem to result in timely delivery of the exception Oct 23 18:48:52 zmatt: are you complaining that first round silicon isn't perfect? :) Oct 23 18:49:14 the a15 isn't first round, it's r2p2 Oct 23 18:49:30 also, I'm really afraid this isn't an erratum but Working As Designed™ Oct 23 18:49:51 zmatt: I'm sure it can be fixed in software Oct 23 18:51:10 first gonna check if it's not the compiler's fault somehow Oct 23 18:55:25 * zmatt strangles gcc Oct 23 18:55:44 well, *and* the processor Oct 23 18:56:42 zmatt, give clang-3.6/clang-3.7 a try... (as gcc-5 isn't in jessie).. Oct 23 18:57:17 rcn-ee: haha, right. clang is good for optimizing your code to death, not for sane behaviour Oct 23 18:57:38 anything that smells like it could be undefined behaviour in some interpretation of the C standard and it'll happily optimize your code by deleting it Oct 23 18:57:56 also, it doesn't actually implement -fnon-call-exceptions Oct 23 18:59:16 gcc does, but because little-retarded-cortex-a15 decided to turn this into an async abort, it doesn't actually occur on the load instruction, which is where gcc is made to anticipate them with -fnon-call-exceptions Oct 23 18:59:34 an asm("dsb"); forces the cpu to deliver the exception _now_ thank you Oct 23 18:59:51 but gcc helpfully marked the dsb instruction as "cantunwind" Oct 23 19:00:13 since surely a dsb couldn't result in an exception, right? .. right? Oct 23 19:00:35 * zmatt hits gcc around the head with a bunch of cortex-a15's Oct 23 19:01:12 rcn-ee: at least I succesfully disabled the omap_l3 driver Oct 23 19:01:30 so now you don't get a big traceback of some unrelated kernel code whenever a fault occurs Oct 23 19:02:09 but I need to update the kernel it seems... this one doesn't include uio_genirq_pdrv yet Oct 23 19:02:27 I wanted to make a userspace daemon that does the job of omap_l3, but *properly* Oct 23 19:02:50 in the sense of actually providing useful information, like the address that faulted :P Oct 23 19:03:15 can I safely update, or will scary things happen? Oct 23 19:03:40 zmatt, should be fine. ;) Oct 23 19:04:58 it seems people already complained about this gcc behaviour in 2003 Oct 23 19:05:07 (on x86) Oct 23 19:06:13 and the linaro guys haven't fixed it! ;) Oct 23 19:07:38 <_av500_> they are too busy making 96 boards Oct 23 19:08:57 that's right they need to "fix" things as none of the boards followed the "spec" . ;) Oct 23 19:08:58 *has an idea* Oct 23 19:09:25 <_av500_> specs are for the weak Oct 23 19:10:04 and usually written by people who don't know the hardware.. ;) Oct 23 19:11:37 hah, this worked! Oct 23 19:11:49 forced gcc to emit the memory barrier itself Oct 23 19:11:54 __atomic_load_n( &src[i], __ATOMIC_ACQUIRE ) Oct 23 19:12:55 now it covered the load *and* barrier with proper unwinding info, et voila, catch( BusError ) worked Oct 23 19:16:18 (either that or the barrier it emitted is insufficient to force experience delivery of the exception and it gets coincidentally caught by an innocent later iteration) Oct 23 19:16:24 *expedient Oct 23 19:16:43 I still can't believe the a15 makes this an async abort Oct 23 19:17:21 it's not some fire-and-forget write or something, it's a device read! Oct 23 19:17:45 (don't worry, I'll eventually stop ranting about it) Oct 23 19:31:11 a dsb doesn't even do the trick, an isb is needed :( Oct 23 19:37:34 *finally* Oct 23 19:38:00 ok and now the data suddenly also looks a lot more plausible Oct 24 00:43:32 Anyone working with Beaglebone on OS X El Capitan? Oct 24 00:45:07 anyone boot up openwrt on bbb? Oct 24 01:01:25 openwrt? why? Oct 24 01:02:18 bbb has many, many times the amount of memory and dynamic storage any router/embedded routing device has .. Oct 24 01:28:04 but if that's all you wanna do .. you can find all the equivalent packages in debian or angstrom :p Oct 24 01:31:28 but but BBB doesn't run MIPS Oct 24 01:31:43 d'oh! Oct 24 02:42:35 hey guys whats up Oct 24 02:50:02 ds2: openwrt is not just MIPS. it support ARM and x86 Oct 24 02:52:19 and openwrt has a pretty nice setup, especially for consumer devices. with its RO base and writeable overlay. ubuntu-core (snappy) goes in that direction now **** ENDING LOGGING AT Sat Oct 24 02:59:59 2015