**** BEGIN LOGGING AT Fri Jan 15 02:59:59 2016 Jan 15 03:23:07 zmatt: that's what our hardware guy was thinking too, but the package says c Jan 15 03:23:36 thanks for the "read" clarification. Jan 15 03:24:11 the funny thing is, it was initially at 1.1V, then a few days later it went to 3.3V. Jan 15 03:24:18 for some reason... Jan 15 07:12:05 HAHA cat `find / -name am33xx.dtso` | grep adc FROZE my BBB Jan 15 07:12:26 haha i mean dtsi Jan 15 07:16:18 ope it came back Jan 15 07:32:27 okay so if something is listed as "status = disabled" in the OCP node of the DT you wont be able to mmap it through /dev/mem is what I'm guessing Jan 15 08:12:00 hey, someone already got a openCL application running on the x15? does is support the full profile or only the embedded profile? Jan 15 10:03:11 ayjay: more specifically: every peripheral/module is disabled unless some DT node is associated with it via a ti,hwmods node in DT, it is not set status = "disabled", a driver successfully loads for it, and the driver enables the device (pm_runtime_get{,_sync}) Jan 15 10:04:04 you can however just manually enable a clock behind the kernel's back if you want to (but it would be wise to avoid doing this for clocks that are being actively managed by the kernel) Jan 15 10:04:21 its a hardware disable? Jan 15 10:04:45 yeah, for most modules just one setting in PRCM Jan 15 10:05:05 each module has a CLKCTRL register there, with a MODULEMODE field Jan 15 10:05:25 reokay eah Jan 15 10:05:35 i thought you were talking about the control module register but i wasn't sure Jan 15 10:05:44 no, prcm Jan 15 10:06:01 lah clock manager Jan 15 10:06:04 not control module Jan 15 10:06:13 power, reset, and clock manager to be specific ;) Jan 15 10:07:09 has anyone experience with using swupdate or similar on bbb: Iwonder how to implement the possibility of having something like atctive/stanby bank and performing a safe software upgrade. all using a minimal footprint (<100Mb) distro like buildroot Jan 15 10:07:43 all with eMMC only (i.e without uSD) Jan 15 10:09:55 zmatt: it seems like using UIO is probably my best bet again. I'm worried enabling a driver like ti_am33xx_adc and then manually editing the TSC_ADC registers controlly those functions is too hairy. I was hoping just status=okay would be enough to mmap the registers with mem/. I'm trying to write a gui to give students lots of unhealthy control over the registers from userspace to teach them Jan 15 10:11:05 but to access the registers I need to enable the OCP as you described above so I should probably use UIO Jan 15 10:17:13 BUT... also to teach myself Jan 15 10:23:40 uio is absolutely cleaner; on the other hand, enabling the module manually is also instructive since it shows a bit about how PRCM works Jan 15 10:25:09 that's the problem with making things easier for people... they learn less Jan 15 10:26:37 btw, I have a little example that meddles directly with PRCM, control module, and GPIO... https://github.com/dutchanddutch/jbang written in my fairly eccentric style of C++ which I also use for baremetal code (in face this code is pretty close to baremetal, even though it runs under linux :P ) Jan 15 10:26:58 e.g. headers for prcm and the control module are in https://github.com/dutchanddutch/jbang/tree/master/include/ti/subarctic Jan 15 10:28:09 libsubarctic is some magic that will mmap() the right chunks of /dev/mem for you before main() is called (something I made to allow code portability between baremetal and linux userspace) Jan 15 10:28:21 it's kinda gross Jan 15 10:28:57 also, the readme says gcc 4.9 is required... I think that might be gcc 5 nowadays, but I'm not sure (I never test with old compilers) Jan 15 10:31:04 oooh ill check it out Jan 15 10:31:09 i'm getting started on a gui Jan 15 10:33:35 the app itself also does something gross, but potentially quite useful: requiring only that the jtag input signals are pulled up (or driven high), it flips the bit (accessible via JTAG only) to assert DBGEN to the cpu, which allows hw breakpoints and watchpoints to be used Jan 15 10:35:31 unfortunately linux doesn't support hw breakpoints/watchpoints on the cortex-a8 (yet), but someone nevertheless managed to debug a hard-to-catch memory corruption (on an omap3, by porting this trick) with a very neat workaround: Jan 15 10:36:05 he just configured a watchpoint anyway (from userspace) -- when it triggered, the confused kernel started flailing and dumped a traceback, which was exactly what he needed :D Jan 15 10:39:17 i actually see a flailing kernel Jan 15 10:39:20 in my head Jan 15 10:48:08 I'm actually currently working on improving uio to support allocating and mapping normal-uncached memory for dma operations, and will try to change the mapping of peripherals from Strongly-Ordered to Device Jan 15 10:48:10 I don't understand why it's S-O, all kernel drivers use Device-type afaik Jan 15 10:48:10 (or well, looks like Historical Reasons, plus lack of documentation what semantics certain memory types are supposed to have) Jan 15 14:24:09 Hello Jan 15 14:25:09 I have an issue when trying to use the debian 8.1 image (2015-11-12) on a beaglebone : it doesn't boot Jan 15 14:25:25 it boot perfectly well on beaglebone black Jan 15 14:25:51 did I miss something ? I think I understood the image supports both hardwares Jan 15 14:27:22 the images should work with all variants of the beagle name .. the same image/uSD card works on a bbb, yes? Jan 15 14:28:00 correct. Jan 15 14:28:24 I don't recognise that date though .. are you getting official images from http://elinux.org/Beagleboard:BeagleBoneBlack_Debian ? Jan 15 14:28:47 or .. I think there are links from latest-images now on the beagle site .. >,< Jan 15 14:28:47 I only used dd to flash the image on a µSD card, and it boots perfectly on BBB, but not on standard beaglebone Jan 15 14:29:30 you checked the md5sum, just in case? Jan 15 14:29:47 I got it from http://builds.beagleboard.org/images/master/08132bf0d0cb284d1148c5d329fe3c8e1aaee44d/bone-debian-8.2-tester-2gb-armhf-2015-11-12-2gb.img.xz Jan 15 14:30:05 I tried re-downloading it, to no avail Jan 15 14:30:40 righto .. yes from latest-images .. hmm Jan 15 14:32:44 I can't imagine why that would bea a problem .. but you could try a 2016-01 image from http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#2016-01-10 ... Jan 15 14:32:57 there should be a stand-alone one there which will work with both Jan 15 14:35:05 I can try that, but I'd like to fix the current image, since I have worked on this image on a BBB, and I am now trying to make it work on our older equipments :-p Jan 15 14:35:12 d'oh righto Jan 15 14:35:53 I think the guy that builds those images shoul dbe in later .. Jan 15 14:37:30 Maybe I should make a forum post ? Jan 15 14:37:59 I'll try to make some progress on the 2016-01-10 image in the meantime Jan 15 14:38:12 try it in parallel, maybe Jan 15 14:38:19 by all means post too ^^ Jan 15 14:38:49 and feel free to lurk here .. someone might mention something .. and/or you can review the channel logs too Jan 15 14:39:32 there shouldn't be much difference .. but I can appreciate not wanting to duplicate effort :) Jan 15 14:42:01 thanks, I'll do that :-) Jan 15 15:11:14 Is the BBB OMAP2+? I'm working on a custom kernel and there is a TI OMAP2+ option in Frequency scaling, do I need to select that one for optimal performance? Jan 15 15:25:30 abferm: personally I thought it was omap3 .. but I think there are some left-over settings with omap2 labels .. Jan 15 16:13:43 veremit: it isn't omap3 either, closer to omap4 (yet different) Jan 15 16:14:01 and I'm also not sure exactly which drier is doing the frequency scaling, since multiple are enabled Jan 15 16:14:06 *driver Jan 15 16:14:52 many "omap" options are in fact pointless on the am335x, including the "omap pinmux", interconnect driver, emif driver, and a bunch more Jan 15 16:16:35 zmatt.. so its a mess .. as usual .. lol Jan 15 16:16:59 though it's possible ti put the emif driver to use in the 4.1-ti branch to save/restore config in suspend modes... not sure, might also be handled by the m3 Jan 15 16:17:07 no wait, it can't be handled by the m3 Jan 15 16:17:27 zmatt.. do you know anything about using the ti adc driver in touchscreen mode? Jan 15 16:18:44 might still be custom code... the emif driver mostly deals with lpddr2 stuff (not supported on am335x) and on-the-fly frequency changes (not supported on am335x, officially at least, could still be done relatively easily) Jan 15 16:18:51 veremit: zip, nada, nothing :D Jan 15 16:18:57 mm ok. Jan 15 16:19:09 ti adc is one of the drivers I dropped very early on Jan 15 16:19:28 well .. any ti driver is ..yeah .. Jan 15 16:28:12 bbl shopping Jan 15 16:28:38 hmm to go to grocery store .. Jan 15 16:49:50 * Xabaras76 Hello to everyone Jan 15 16:50:58 * Xabaras76 Please I need a little help about installing SDL2 on a beagleboard black Jan 15 16:56:37 sudo apt-get install libsdl2 Jan 15 16:57:59 * Xabaras76 Thanks a lot for your answer veremit Jan 15 16:58:25 or libsdl2-dev if you're developing Jan 15 16:58:31 ie. need headers etc Jan 15 16:58:49 I already tried that command but it say to me :Unable to locate package libsdl2 Jan 15 16:59:10 yes I mangled the command I think . needs some extra bits .. checking .. Jan 15 16:59:43 * Xabaras76 ok I will try thanks a lot...! Jan 15 17:00:08 sudo apt-get install libsdl2-2.0 Jan 15 17:00:15 you need the extra -2.0 Jan 15 17:00:24 stupid debian package naming .. lol Jan 15 17:00:25 * Xabaras76 In any case....I already dounload the source and compiled it..... Jan 15 17:00:35 well that's always an option Jan 15 17:01:11 * Xabaras76 I get no errors also when I made mke install..... Jan 15 17:01:34 but when I do dpkg...I can't find the lib...... Jan 15 17:01:37 perfect :) Jan 15 17:01:49 no .. dpkg won't know about things you manually install :P~ Jan 15 17:02:36 you'll probably find it in /usr/local/lib and /usr/local/bin and /usr/local/share etc Jan 15 17:03:03 whereas the debian installers will put it in the standard places Jan 15 17:03:32 * Xabaras76 sorry....I'm a total noob trying to get my way in Linux sorry if I make sometimes easy questions for you... Jan 15 17:04:15 * Xabaras76 I appreciate a lot your help Jan 15 17:05:38 * Xabaras76 I tryied the other command...but I get this: Jan 15 17:05:42 E: Unable to locate package libsdl2-2.0 E: Couldn't find any package by regex 'libsdl2-2.0' Jan 15 17:06:02 are you running the ... uhoh.. hold up Jan 15 17:06:17 you need debian jessie Jan 15 17:06:27 doesnt' exist in wheezy which is he default image Jan 15 17:07:15 * Xabaras76 again thanks a lot..... Jan 15 17:07:35 unless you have work you need to save, I'd recommend grabbing a new image from http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#2016-01-10 Jan 15 17:08:07 * Xabaras76 I check in usr/local/lib and I have got the libSDL2..! Jan 15 17:08:27 * Xabaras76 OOHHH a new image.....:) Jan 15 17:08:51 * Xabaras76 thanks again :) Jan 15 17:10:04 have a play with that little lot .. I gotta afk a bit .. bbl :) Jan 15 17:12:03 * Xabaras76 Thanks a lot again........:) Jan 15 17:38:46 I've been working on my custom kernel, and have noticed that these errors have been showing up in dmesg. Any ideas on how to fix them? http://pastebin.com/aUQTDW0K Jan 15 17:48:49 abferm: first one: interrupt-affinity is (contrary to the docs) not an optional property Jan 15 17:50:16 point it to <&{/cpus/cpu@0}> (or add a label to the cpu for more convenient reference) Jan 15 17:52:03 (note that although the pmu irq is known to be unreliable, the polling workaround has not been implemented apparently so the irq is still necessary; without it you lose a lot of useful profiling ability) Jan 15 17:54:04 next two lines are linux being a fascist and complaining that the device ought to reference the voltage regulator supplying it Jan 15 17:54:49 "there's no regulator you need to concern yourself about, stfu" is not an option, to make the message go away you probably have to instantiate a fixed-regulator Jan 15 17:55:01 (or remove the message) Jan 15 17:55:11 omap-sham is a buggy piece of shit, turn it off Jan 15 17:57:24 omap_voltage_late_init: not sure, there seem to be multiple voltage regulation mechanisms compiled into the kernel even though only one will be appropriate for the am335x... I suspect this message is one of the other mechanisms complaining it has no business here Jan 15 17:59:40 the last entries suggest you either have an old kernel and DT that still manually lists the operating performance points, and you neglected to include 1 GHz as a supported frequency. modern kernels take care of this themselves using some code (dunno which config options) and an appropriate firmware blob "am335x-bone-scale-data.bin" (CONFIG_EXTRA_FIRMWARE) Jan 15 17:59:52 afk again, next round of shopping Jan 15 18:44:05 I disabled /dev/ttyO0 in inittab and sysctl but I'm still not seeing echos to my computer. What else could be holding it up? Jan 15 19:08:32 foreverska_: which port are you talking about? Jan 15 19:09:37 BBB with debian. Jan 15 19:10:54 If you want kernel and u-boot messages during boot, you should use the UART broken out with the pin header. Jan 15 19:13:07 Yea, I'm not super worried about that. I have a serial cable for the ttyO0 header and I was hoping to quickly use that. Jan 15 19:22:43 The cable works... I just jumped RX and TX and I get a loopback. But when I echo to it, it doesn't show on putty on the other end. Jan 15 19:50:48 zmatt: sorry I went to lunch right after asking, where exactly is the interrupt-affinity set? Jan 15 20:06:04 foreverska_: is ttyO0 set as your console in your uEnv.txt file? Jan 15 20:07:20 hi. does anyone know when the x15 is coming out? Jan 15 20:20:07 abferm: device tree node /pmu Jan 15 20:20:52 foreverska_: port settings are probably wrong Jan 15 20:23:24 try stty -F /dev/ttyO0 sane raw 115200 pass8 -crtscts -cdtrdsr clocal Jan 15 20:23:34 (replace 115200 by other bitrate if desired) Jan 15 20:25:57 foreverska_: note that unless you have some really ancient system, inittab is not being used Jan 15 20:27:32 also, do you see things like startup messages correctly? Jan 15 20:27:41 since if you don't, then your putty is misconfigured Jan 15 20:27:58 zmatt: so I need a &pmu { interrupt-affinity = <&{/cpus/cpu@0}> }; in my dts? Jan 15 20:29:17 abferm: that's a quick fix yes. of course it really ought to be fixed upstream, either by adding it to the main dtsi or by fixing the driver to keep the promise made by the documentation that interrupt-affinity is optional if there's only one cpu Jan 15 20:31:39 zmatt: I also have the firmware for the frequency scaling. Any guesses as to which options need changed? I found the DT frequency list, it is in am33xx.dsi, but they are listed alongside voltages, and I don't know what the appropriate voltage for 1GHz would be. Jan 15 20:32:02 There it is. zmatt, you're a savior Jan 15 20:35:15 abferm: the DT frequency list is overridden by some boneblack dtsi Jan 15 20:36:52 zmatt: I see a bone-common.dtsi, but no boneblack dtsi files. Jan 15 20:37:42 abferm: what kernel are you using? Jan 15 20:40:27 (since I can't even check for you which file it might be, since no kernel version I use or have used in recent times still uses a DT-specified list of frequencies and voltages Jan 15 20:40:30 ) Jan 15 20:45:05 I pulled linux-stable (4.1.15) https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/log/?id=refs/tags/v4.1.15 as my upstream Jan 15 20:45:42 It is the newest long term support linux kernel Jan 15 20:45:58 zmatt ^ Jan 15 20:51:49 not the -ti branch thereof? Jan 15 20:52:49 (either TI's SDK kernel or rcn-ee's derivative thereof for bbb) Jan 15 20:53:32 abferm, cpufreq values are in hwmod's.. Jan 15 20:53:55 rcn-ee: he's using mainline 4.1, it apparently still has a table Jan 15 20:54:38 there's a table for the "am335x es1" aka beaglebone white.. Jan 15 20:55:31 abferm, here's the quick and dirty 1Ghz table hack: https://github.com/RobertCNelson/linux-dev/blob/master/patches/beaglebone/dts/0001-am335x-boneblack-add-cpu0-opp-points.patch Jan 15 20:57:05 zmatt: I just asked my co-worker, and he pulled main-line, not ti... we may have to fix that. Jan 15 20:57:43 abferm, the ti branch has a better cpufreq-vs-volt driver, it's not mainline yet, but it's only < 20 patches i keep thme in the bone patchset.. Jan 15 20:58:11 https://github.com/RobertCNelson/linux-dev/tree/master/patches/ti/cpu_freq Jan 15 20:58:12 rcn-ee: plus the tilcdc clock divider fix, and probably a ton of other stuff Jan 15 20:58:29 rcn-ee, just curious, where did you get the uV values for that patch? Jan 15 20:58:48 rcn-ee: btw, I got a small patch that makes 4.1-ti compile in thumb mode again, you want it? (this means TI still compiles in ARM mode? why oh why?) Jan 15 20:58:53 our 3.8.13 kernel.. Jan 15 20:59:20 I know they got bumped at some point based on a measurement that had been done or so Jan 15 20:59:24 zmatt, you fixed the "wkup3" compile? you should ping that on linux-omap and get it mainlne ;) Jan 15 20:59:42 (the wkupm3 is going in this rc) Jan 15 20:59:45 rcn-ee: it was really trivial to fix, just look at the assembler complaint and fix it Jan 15 21:02:41 it would be very nice to have thumb2 again.. on the am335x it helps.. Jan 15 21:04:41 http://pastebin.com/3S3sy8U4 Jan 15 21:05:23 note that I paid no attention to the actual code, I just grabbed the register that would be clobbered by the next statement and used it as temporary Jan 15 21:06:01 zmatt, it looks safe. ;) Jan 15 21:06:06 it is Jan 15 21:06:44 the code is probably fairly asinine, as even in this snippet it already shows storing a value and then loading it immediately afterward again Jan 15 21:07:50 after making the patch I realized that for all our applications latency is important and power saving is absolutely not, so I disabled everything to do with the wakeup-m3 Jan 15 21:09:48 ah wait the problem was that even then sleep33xx gets compiled Jan 15 21:10:07 that has some assembly too.. Jan 15 21:10:22 ? Jan 15 21:10:50 nm... ;) Jan 15 21:12:44 time to become illuminated again! Jan 15 21:12:52 (finally got replacement bulbs) Jan 15 21:13:30 * zmatt likes light Jan 15 21:14:15 I don't understand people who illuminate their living room like some dark cave and call it "cosy" Jan 15 21:25:49 zmatt: Who am I to judge... but maybe some people don't like the way the other people in their living rooms look? And would rather be in the dark? Jan 15 21:28:13 hehe Jan 15 21:30:17 I don't judge, it just fascinates me a bit how a lot of people somehow consider decreased illumination to improve a room Jan 15 21:30:55 otoh, with the horrible light sources some people use I understand it a bit better >< Jan 15 22:11:18 zmatt: Thanks for suggesting I drop omap-sham, I've been working on slimming our kernel package to be deploy-able over cell, and that bought me about another 100k. Jan 15 22:15:01 lol seriously? Jan 15 22:17:11 disabling pretty much all kernel mode crypto possible is also one of the things I did to slim things down... we have no plans to use IPSec, network filesystems, encrypted filesystems, etc Jan 15 22:36:20 rcn-ee: on your wiki for building up a full distro for the BeagleBone Black here, https://eewiki.net/display/linuxonarm/BeagleBone+Black Jan 15 22:36:41 are you supposed to choose either Mainline _or_ TI BSP for the kernel? Jan 15 22:37:02 zmatt: We've been trying to keep as much crypto in place as possible. Most of my slimming was removing graphics support, wifi, wimax, datacenter stuff, etc. Jan 15 22:38:13 yates, it's up to you ;) mainline has uio_pruss, ti bsp has remoteproc_pruss, otherwise they are the same.. Jan 15 22:39:22 zmatt, one turned to 3. ;) i cheated and used the ARM/THUMB macros so wouldn't break anything: https://github.com/RobertCNelson/ti-linux-kernel-dev/commit/8d4797085e913eebde1c98ca1ddcd14c854539e9 Jan 15 22:39:55 https://github.com/RobertCNelson/ti-linux-kernel-dev/commit/146abbb94a13ec0e6c8acc94f50f34ca9f3c0374 Jan 15 22:40:28 rcn-ee: got it. thanks. Jan 15 23:05:52 rcn-ee: heh, and I just noticed a second silliness visible in the tiny bit of context of the patch: apart from the "ldr r2, wfi_flags" being redundant (at least if we pick a different temp register), the last two instructions visible in context could have been ldr pc, ti_emif_restore_context Jan 15 23:06:04 (unless r1 is needed again later, but I doubt that) Jan 15 23:06:16 ah wait no Jan 15 23:06:17 blx Jan 15 23:06:21 pft Jan 15 23:06:28 * zmatt misread as bx Jan 15 23:08:04 rcn-ee: running the ./build_kernel.sh invokes the kernel configuration utility (that ncurses thing). are we supposed to customize anything there or just exit it (for a standard BeagleBone Black buidl) using am33x-v4.4 # Long-term 4.4.x) of bb-kernel? Jan 15 23:08:29 yates: you can uncomment a flag in system.sh to prevent the menuconfig Jan 15 23:08:39 AUTO_BUILD or something iirc Jan 15 23:08:58 aha. Jan 15 23:09:01 that would be good. Jan 15 23:13:46 zmatt: the "Voltage driver support not added." message is coming from arch/arm/mach-omap2/voltage.c looks like the voltdm_list is empty. Jan 15 23:40:39 my guess would be the whole omap2 voltage driver is not applicable to the am335x Jan 15 23:46:24 power management on omaps is much much more elobrate than on most other TI SoCs Jan 15 23:46:41 (or all other TI SoCs probably) **** ENDING LOGGING AT Sat Jan 16 02:59:58 2016