**** BEGIN LOGGING AT Fri Feb 20 02:59:59 2015 Feb 20 11:52:05 https://twitter.com/locusf Feb 20 11:52:08 thats interesting Feb 20 11:53:15 hardware runs software? Feb 20 12:28:55 who'da thunk?! Feb 20 12:31:12 stt_michael, yeah and apparently people even make chatrooms to talk about it! Feb 20 12:31:40 stt_michael, its all getting outta hand man!!! Feb 20 12:43:14 -shrug- Feb 20 13:51:38 Is there's a way to tell the kernel scripts when compiling kernel to use gxargs instead of xargs ? Feb 20 14:12:00 hah, omg it actually works... having the bbb self-jtag with no external hardware/wires other than driving nTRST high (could be done with a solder blob) and connecting TDO to EMU0 (so I can see what's going on, not needed once the procedure is stable and tested) Feb 20 14:14:28 pins are "controlled" by toggling the input-enable bit of the pinmux registers in control module, changing the cpu's perception of the pin level between its true value (1) and zero Feb 20 14:14:43 this is so gross :D Feb 20 14:15:19 :) Feb 20 14:16:24 when perfected, this means a tiny solder blob is all that's needed to be able to assert DBGEN to the processor which is required to enable a debug monitor Feb 20 14:17:22 which for example could allow single-stepping a program *including* the kernel code running in its context (i.e. "step into" would work for syscalls), while interrupts and other processes continue to run normally Feb 20 14:21:17 zmatt, if you get that working post a video of it. Feb 20 14:26:03 hehe, yeah well first things first... I still need finish and polish this code a bit and post it on github, there's someone on the linux-omap mailing list who wants to do a similar thing on the dm3730 (openpandora) Feb 20 14:28:18 and I haven't even begun looking around to see whether someone already made a suitable open source debug monitor... maybe the pandora guy knows Feb 20 14:28:38 can it be used to insert printf() calls into running programs? :) Feb 20 14:29:43 you don't need a debug monitor to insert printf() calls into running programs... you can do that just fine purely in software Feb 20 14:29:59 I dont want to SW to know :) Feb 20 14:30:05 it doesn't need to Feb 20 14:32:13 you just patch the instruction at the target address to become a branch to a block of code you inject in its process space which: 1. saves all relevant registers, 2. performs the printf, 3. restores registers 4. executes the original instruction 5. jumps back to right after the "tracepoint" you just inserted Feb 20 14:32:35 or you use ETM tracing to the ETB Feb 20 14:32:43 which is entirely non-invasive and also doesn't require DBGEN Feb 20 14:33:11 you can configure a trace event on combination of program counter and context id Feb 20 14:33:33 i know :) Feb 20 14:34:01 so this is one thing where a debug monitor actually would have nothing to offer Feb 20 14:35:50 the main advantages of a debug monitor is that it also works in kernel mode (in fact the user<->kernel transition is not really of any special significance to it), and you can use hardware breakpoints and watchpoints Feb 20 14:37:24 hardware breakpoints aren't very interesting, though they have a few advantages over software breakpoint (no need to modify the code, faster to enable/disable, also works in ROM code) Feb 20 14:37:39 watchpoints however are really useful and have no software equivalent Feb 20 14:39:18 they set a breakpoint on memory access (based on access type, address and/or value, both with optional masks applied iirc) Feb 20 14:40:33 zmatt, right but even if you want to use a JTAG wouldn't it be easier just to buy a BBW off of ebay and use openocd. Feb 20 14:41:03 where is the fun in that? Feb 20 14:41:31 georgem: that doesn't help if you want to JTAG a BBB rather than a BBW :P Feb 20 14:41:44 (I actually have a jtag header soldered onto my BBB) Feb 20 14:42:35 zmatt, right either way. Feb 20 14:43:04 in general it's stupid you need to enable DBGEN via JTAG when debug monitor functionality is also damn useful without JTAG Feb 20 14:43:15 (that's something TI did btw, not ARM's fault) Feb 20 14:44:26 useful enough that I would have recommended including a way to bitbang the jtag port in new hardware designs... but now it turns out that's not needed, with this hack you only need to pull-up the JTAG pins and software can do the rest Feb 20 14:45:12 if it weren't for that annoying pull-down on nTRST, it would work on a plain BBB without solderwork Feb 20 14:47:33 also, working locally on the processor will be *much* faster than JTAG... JTAG is iirc limited to about 10 Mbit/s according to the datasheet, you may be able to run it at 30 Mbit/s, and most of that will be lost in protocol overhead Feb 20 14:48:35 zmatt, so... if a break point is triggered isn't the CPU going to be stopped an unable to continue interfacing with the JTAG? Or am I missing something? Feb 20 14:49:49 georgem: with a debug monitor (unlike normal halting debug as typically done via JTAG) interrupts and task switches can continue normally Feb 20 14:50:26 zmatt, ah, gotcha Feb 20 14:54:27 the only thing you need to watch out for is that if you step into kernel code that grabs a lock on something that's also needed for communication with the debug monitor, you have a problem. one workaround is to grab the debug console for exclusive use by the debug monitor so it has that communication path available (lock-free) for such occasions.... if you want the frontend to run on the same processor you Feb 20 14:54:33 should probably step over rather than step ... Feb 20 14:54:36 ... into syscalls :P unless the debug monitor can be made locking-aware but that may require non-trivial effort Feb 20 14:55:39 being able to step into syscalls would rock though, for "why the hell am I getting this error?" occasions Feb 20 14:56:59 and would probably be an awesome learning tool for how the kernel works Feb 20 15:03:43 openocd only supports halting mode afaict btw, so that's rarely what you want when you have an OS like linux running Feb 20 15:04:04 (though it actually didn't seem to mind being halted for a bit) Feb 20 15:04:30 but it probably leads to a thundering herd of timeouts expiring :P Feb 20 15:05:07 its like the clock on the NMI to make the C64 slower for hard to play games :) Feb 20 15:05:10 (unless the timer used is configured to freeze during debug halt) Feb 20 15:05:19 lol Feb 20 15:05:25 that's a cute hack Feb 20 15:06:05 although not many systems would simply ignore and return from an NMI Feb 20 15:06:51 (old macs actually had an NMI button on the back of the computer, next to the reset button) Feb 20 15:07:43 dropped you into the debugger Feb 20 15:08:27 (sigh, I sometimes still miss MacsBug a bit... omg I'm now sounding like some old fart going on about the "good old days" -.- ) Feb 20 15:09:43 some apple developers apparently missed it too, they made a GDB plugin that makes it work more or less like MacsBug (it was never ported across the PowerPC -> Intel transition though) Feb 20 15:11:24 zmatt: are you familiar with ftrace? Feb 20 15:13:41 it's really useful for poking your way around a running kernel Feb 20 15:14:20 no, I had never heard of it until now, nice Feb 20 15:14:49 yeah, check it out. it's really powerful Feb 20 15:18:16 it's no substitute for being able for step into a syscall of course... (nor is single-stepping a replacement for trace obviously) Feb 20 15:19:16 I can also see different pros and cons of a software trace framework such as ftrace versus hardware trace via ETM Feb 20 15:19:53 zmatt: useful or not, its a neat hack Feb 20 15:20:09 av500: it is Feb 20 15:20:15 maybe one day nasa will need it to debug a comet probe :) Feb 20 15:20:22 attach a jtag to that :) Feb 20 15:21:30 does anyone know if the kernel at https://github.com/beagleboard/linux works? I am getting a build config error with it that says: drivers/misc/Kconfig:528: can't open file "drivers/misc/cape_bone_argus/Kconfig" make[1]: *** [bb.org_defconfig] Error 1 Feb 20 15:21:41 the idea came to me as a result of some e2e post where someone (for unknown reasons) was changing the pinconf of the nRESET pin to zero and (surprise!) getting a system reset as a result Feb 20 15:24:45 av500: so georgem also solved your "insert a printf" problem: the kernel can actually do it for you (uprobe) Feb 20 15:25:44 if configured in Feb 20 15:26:07 3.8.13-bone69 doesn't have it, but for example 3.19.0-rc5-bone2 does Feb 20 15:28:03 paul175, strange, what branch? Feb 20 15:28:33 paul175, http://builds.beagleboard.org/builders/build-kernel Feb 20 15:29:40 branch 3.14 Feb 20 15:30:04 I fixed that error and am getting another one, it doesn't look good Feb 20 15:30:38 it's odd your getting any errors... it's building both on my machine and bb.org's build bot... what system do you have? Feb 20 15:31:46 Ubuntu with the 3.13 kernel is our build machine Feb 20 15:33:23 are you using trusty's built-in gcc cross or linaro's? Feb 20 15:33:39 linaros Feb 20 15:34:42 this version: gcc-linaro-4.9-2014.11-x86_64_arm-linux-gnueabihf Feb 20 15:35:37 Since it's 3.14.x based, i still using: gcc-linaro-arm-linux-gnueabihf-4.8-2014.04 Feb 20 15:35:54 but i can test that easily..... Feb 20 15:36:11 (dl-ing.) Feb 20 15:42:22 rcn-ee but can not open file should not have to do something with the compiler toolchain Feb 20 15:42:44 i agree, it 'shouldn't'... Feb 20 15:43:10 assuming his git clone was sucessful ;) Feb 20 15:43:33 oh I think the file got messed up somehow, I just copied the file out of git with a text editor and got to a new failure Feb 20 15:43:50 now it does this: make[1]: *** No rule to make target `mm/zsmalloc.o', needed by `mm/built-in.o'. Stop. Feb 20 15:44:16 I had downloaded the repo via the zip archive method Feb 20 15:44:24 oh don't do that... Feb 20 15:44:32 paul175 you did somehting really wrong Feb 20 15:44:54 use git Feb 20 15:45:25 Just: git clone https://github.com/beagleboard/linux ; git checkout 3.14.33-ti-r50 -b tmp Feb 20 15:46:39 when I try to clone I get an HTTP code 407 fatal error Feb 20 15:46:49 that is probably an issue for a different IRC channel Feb 20 15:47:07 stupid company firewall? Feb 20 15:47:15 yeah Feb 20 15:47:27 if your getting that with clone, you might have something in the middle of your connection.. so even the *.zip probally got modified in route.. Feb 20 15:47:32 I would make an admin ticket Feb 20 15:47:42 github is a must for every developer Feb 20 15:47:52 and a secure conneciton .;) Feb 20 15:48:03 good idea, I did not think of the zip getting corrupted by the firewall Feb 20 15:48:54 ours opens it up, checks and repackages it.. if it finds something it blocks... Feb 20 15:50:55 georgem: apparently linux has ETM support too, though "... will show up under /sys/bus/coresight/devices" Feb 20 15:50:59 ls: cannot access /sys/bus/coresight: No such file or directory Feb 20 15:51:36 ah, they're missing from the am335x device tree Feb 20 15:57:53 hmm, every time i get their newsletter i wonder if av500 knows springair.de Feb 20 16:16:55 <_av500_> now I do Feb 20 16:17:24 i am still getting this on boot, which hangs indefinitely: A start job is running for LSB: Raise network interf... Feb 20 16:17:34 i have eth0 not enabled too Feb 20 16:17:46 it's a huge pain -- does anyone know how to disable entirely? it's like 2 out of every 5 boots it hangs Feb 20 16:46:54 is it normal the that 4 blue leds are blinking in some repetitive weird sequence that seems to differ every day? Feb 20 16:47:10 yesterday when i got home from work, all 4 were blinking two times quickly and then pausing for 1s... today when i got home, they blink two and two Feb 20 16:47:11 nope... Feb 20 16:47:50 figured it out. i can disable all network interfaces entirely... then swap out my interfaces file after boot, and restart network Feb 20 16:47:56 lol not the most ideal situation, but seems to be bulletproof Feb 20 16:48:28 the "A start job is running for LSB..." doesn't even show up on network restart, and it gets skipped on boot. Feb 20 16:48:37 rcn-ee, any weird process i could stop? Feb 20 16:48:50 i'm kind of wondering if there's a race condition that's causing it to hang on boot. oh well, on to the next problem. Feb 20 16:48:51 perhaps it got hacked or something Feb 20 16:49:13 well, root user is blank.. Feb 20 16:49:26 i set a password on it Feb 20 16:49:26 i'd just reflash with the latset: http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#2015-02-15 Feb 20 16:49:39 hmm, i've done tons of configuration on it by now though :( Feb 20 16:49:58 is there some system call i could strace to find out what is making it blink, or something? Feb 20 16:51:40 talin_, if it's an embest/element14 board, check for /etc/init.d/led_aging.sh and nuke it.. Feb 20 16:52:25 rcn-ee, it's element 14, but there is no such file Feb 20 16:53:43 now the leds are getting lit and unlit sequentially from left to right... Feb 20 16:54:18 are the leds accessed through some file in /dev that i could lsof? Feb 20 16:55:04 thru: /sys/class/leds/ Feb 20 16:56:24 Hi , i want to write a gpio driver , there are 4 gpio modules is there any register to select the particular gpio module , i have reffered am335x reference manual but nothings there . any idea Feb 20 17:13:25 they are located at different addresses... write a gpio driver, for another OS or a baremetal program? Feb 20 17:15:01 (if doing baremetal programming there's not really a need for a "driver" as such, you can just model the GPIO module with a struct, declare the four gpio modules as extern variables, and pass a list of assignments for their addresses to the linker) Feb 20 17:15:18 anybody here having pratice on driver development of bbb Feb 20 17:15:44 for which OS? I mean, linux obviously already has a gpio driver Feb 20 17:16:10 yup i know Feb 20 17:16:14 but if we want develop that again Feb 20 17:16:23 ahh as practice you mean? Feb 20 17:16:54 yes , sorry Feb 20 17:17:35 do u know ? zmatt Feb 20 17:18:23 someone knows why the BBB reboots by itself from time to time ? Feb 20 17:18:24 on linux, device tree is used to declare instances of hardware modules, for example there's Feb 20 17:19:05 gpio@4804c000 { Feb 20 17:19:06 ti,hwmods = "gpio2"; Feb 20 17:19:06 reg = <0x4804c000 0x1000>; Feb 20 17:19:06 compatible = "ti,omap4-gpio"; Feb 20 17:19:06 ...more stuff... Feb 20 17:19:08 }; Feb 20 17:19:53 this declares a device called "gpio@4804c000" whose register block is at 0x4804c000 with size 0x1000 Feb 20 17:20:06 the "compatible" entry says which driver is to be used Feb 20 17:20:57 the ti,hwmods thing associates it with the appropriate power/clock management data Feb 20 17:21:25 yes i have seen that but in previous boards like arm9 i used to write drivers but in bbb it has dts for hardware info. but i don't know anything about device tree, how to write a dts ,etc. Feb 20 17:21:33 catslab, which kernel? uname -r Feb 20 17:21:55 3.8.13 and 3.15.10 Feb 20 17:22:14 might be a trouble on the BBB too Feb 20 17:22:21 bunty: there's lots of info on the web, although device tree is relatively new and still changing a lot Feb 20 17:23:24 bunty: basically instead of having hardcoded descriptions for every SoC and board (which was getting a bit out of hand) you can write a textual description of the hardware, this is compiled to a binary blob of data (a "flattened device tree") Feb 20 17:23:31 catslab, see: http://bugs.elinux.org/issues/127 make sure you have: https://github.com/RobertCNelson/ti-linux-kernel-dev/blob/ti-linux-3.14.y/patches/beaglebone/dts/0004-bbb-force-usb0-to-perhiperal-mode-fixes-http-bugs.el.patch Feb 20 17:23:31 the bootloader passes this to the kernel Feb 20 17:23:40 by editing device tree can we control the hw Feb 20 17:24:19 by editing device tree you change what the kernel knows about the hardware and how to treat it Feb 20 17:24:30 for examples, for every CAPE there's a device tree overlay Feb 20 17:24:42 to assign pin functions and such Feb 20 17:25:05 rcn-ee: got to check that in the tree for the 3.15.10 Feb 20 17:25:48 if you change the compatible = "ti,omap4-gpio"; to compatible = "buntys-magnificent-gpio-driver"; then the kernel will look for that Feb 20 17:25:58 then what is the diferrence b/w device driver and a device tree Feb 20 17:26:28 device tree just tells the kernel which driver to use, and the parameters the driver needs Feb 20 17:26:34 rcn-ee: ok missing that one, I think I'll change branch to 3.14 :) Feb 20 17:27:14 catslab, if you need something specific from 3.15. we can try to back port it... otherwise it's getting updates from kernel.org and ti's workingon it to ;) Feb 20 17:27:38 k. if i write a dts and compile it to dtb how can i add it to kernel Feb 20 17:27:51 rcn-ee: yes, I think you already told me about that :) Feb 20 17:27:55 bunty, it's like firmware, it's seperate. ;) Feb 20 17:28:35 btw you can dump your current device tree using: dtc -I fs /proc/device-tree Feb 20 17:28:39 rcn-ee: btw, I managed to compile kernel on OSX, had to patch a few files Feb 20 17:28:42 but it'll be less readable than the original sources Feb 20 17:29:00 catslab, with clang? or macports? Feb 20 17:29:20 catslab: any blog post about it ? Feb 20 17:29:26 k. how can i add it permanently to my board Feb 20 17:29:32 bunty: since device tree sources often use labels to refer to other nodes, this is converted to "phandle" numbers Feb 20 17:30:15 you can either change your device tree, recompile it with dtc, put it in /boot/dtbs (don't overwrite the existing one, give it a different name) Feb 20 17:30:28 and then have u-boot load it Feb 20 17:30:29 or Feb 20 17:30:31 easier Feb 20 17:30:39 you can install an "overlay" at runtime Feb 20 17:30:42 I used linaro from Feb 20 17:30:42 and also from an application how can i talk with the device , if i devlp a driver then i can use the device file but what in case of device tree Feb 20 17:30:43 http://www.welzels.de/blog/en/arm-cross-compiling-with-mac-os-x/ Feb 20 17:30:56 bunty: nothing changes there Feb 20 17:31:15 device-tree just replaces the hardware config info that used to be hardcoded into the kernel Feb 20 17:31:36 once the driver loads, everything is the same as before Feb 20 17:32:14 and a few things from macports like findutils for gxargs, elf.h from apple witha few lines added Feb 20 17:32:18 really i need a good tutorial on dts Feb 20 17:32:52 bunty: examine the dts sources for your device, it gives a good idea of what kind of information it provides to the kernel Feb 20 17:33:11 in the kernel source tree, they're at arch/arm/boot/dts/ Feb 20 17:33:15 rcn-ee: in your tools/rebuild.sh I had to move from xargs to gxargs Feb 20 17:33:42 bunty: for example arch/arm/boot/dts/am335x-boneblack.dts Feb 20 17:33:46 and instead of make menuconfig, just make nconfig because of ncurses trouble Feb 20 17:34:22 will try to sort all that and post on blog Feb 20 17:34:26 ;) Feb 20 17:34:43 k. thanks i am looking forward to it Feb 20 17:35:17 but still we can add a new driver module to do work Feb 20 17:35:19 bunty: note that the file itself only contains definition *specific* to the beaglebone-black, and #includes general definitions for the am335x (am33xx.dtsi) and the two beaglebone editions Feb 20 17:35:29 catslab, we can probally just use uname and swap it ;) Feb 20 17:35:32 will it affect the dts or anything Feb 20 17:35:48 rcn-ee: it's out of my league :) but I can learn Feb 20 17:35:51 bunty: you use device tree to tell the kernel to use your driver Feb 20 17:36:39 bunty: see also http://events.linuxfoundation.org/sites/events/files/slides/petazzoni-device-tree-dummies.pdf Feb 20 17:36:40 catslab, you can do it.. ;) swap both those commands as a variable and if uname = MacOS use the 'other' command.. Feb 20 17:37:02 means u are saying if i add a new driver module without editing the dt it is useless Feb 20 17:37:52 i wonder if there's a college course on the dsp... all the omap3 would like to use dsp questions are coming out of the wood work again. ;) Feb 20 17:38:22 bunty: the kernel needs *some* way to know to use your driver... on buses with auto-detection such as USB there's infrastructure for that (e.g. your driver registers which USB devices it handles) Feb 20 17:38:27 Ah if you mean a if [ uname .... ] ok, but I was thinking of something like redifining xargs in the script, as I saw something like export xargs='/usr/local/bin/gxargs' but ain't working on the mac Feb 20 17:39:27 zmatt : ya for that i will register my driver as a character driver to let know the kernel about my driver Feb 20 17:39:31 bunty: when no auto-detection is possible, it needs to be explicitly told "here's a device, use that driver for it, here's the info the driver will need to know what to do with it" Feb 20 17:41:10 rcn-ee: other trouble is the SGX, the bin is not executable on osx, but I copied the ignore/SDK_BIN from debian and it compiled fine on mac Feb 20 17:41:19 bunty: ehh, you're confusing device files (the things in /dev) with devices (the actual pieces of hardware) or drivers for them... you can of course make a kernel module that creates some character device file in /dev without being loaded as a driver for some specific piece of hardware Feb 20 17:41:43 like /dev/null doesn't represent any hardware Feb 20 17:42:02 zmatt :i cant understand after registering the driver to kernel again we have to edit the dts to tell the krnel which deriver to use. Feb 20 17:42:15 catslab, yeah, i'm trying to get TI to let us distrute that.. (you notice how the modules are in the repo ;) only thing left is the lib's.. Feb 20 17:42:48 yep Feb 20 17:43:03 zmatt: i think the registation is sufficient for the kernel to know which driver to use when i will be opening the corresponding device file Feb 20 17:43:04 ok gone for lunch, bbiab Feb 20 17:43:24 but normally the sequence is: kernel learns about existence of a device (through auto-detection or device-tree), kernel loads the appropriate driver, the driver then perhaps registers a character device for it if that's an appropriate interface Feb 20 17:43:47 the kernel then notifies udev, and udev will create the /dev/whatever file Feb 20 17:43:48 does anyone have a reliable wifi chip they would recommend? i'm having a terrible time with these realtek ones Feb 20 17:44:05 i get constant reconnection issues Feb 20 17:44:08 ralink or atheros Feb 20 17:44:24 yes its true but i am saying if i do it manually Feb 20 17:44:26 Humpelstilzchen: would you mind linking one on amazon? Feb 20 17:44:47 bunty: if you do it manually (like /dev/null) then device tree is not involved in any way Feb 20 17:45:09 since, as far as the kernel is concerned, it doesn't represent any actual hardware Feb 20 17:45:19 but if you intend to write a gpio driver, that's not what you want to do Feb 20 17:45:30 because then you need to lots of stuff manually that normally the kernel handles for you Feb 20 17:45:58 manually means creating a device file manually with a known major and minor num Feb 20 17:46:11 ehh, why would you do that? Feb 20 17:46:19 blaine_: http://www.amazon.de/TP-LINK-TL-WN722N-Adapter-High-Gain-Antenne-WLAN-Empfang/dp/B002SZEOLG/ref=sr_1_1?ie=UTF8&qid=1424454316&sr=8-1&keywords=tp-link+722n Feb 20 17:46:35 modern drivers use dynamically allocated numbers anyway Feb 20 17:46:39 just asking incase Feb 20 17:46:42 and udev will create the device file automatically Feb 20 17:46:57 ok. Feb 20 17:47:06 static major/minor numbers and manual creation of device files is really something that belongs in the distant past :) Feb 20 17:47:50 Humpelstilzchen: ty. N150 or N300? Feb 20 17:47:51 so if udev creates the device file auttomatically then what is the need of dts Feb 20 17:48:14 bunty: I already explained the sequence several times Feb 20 17:48:53 bunty: read it again (" but normally the sequence is: " ... about 5 minutes ago) Feb 20 17:49:28 bunty: also, have you read the slides yet that I linked to? Feb 20 17:49:59 because it shows how DT works, also from the driver's perspective Feb 20 17:50:57 k. so you are saying that if auto detection is not happing then dt is doing it Feb 20 17:51:07 m i right Feb 20 17:51:33 the kernel needs *some* way to know about hardware, it is not omniscient Feb 20 17:52:48 and device-tree indeed deals with the "hardcoded" (non-auto-detected) parts Feb 20 17:52:51 Well, it's not till 4.1.15, that the kernel becomes self aware: http://news.softpedia.com/news/Arnold-s-T-800-Terminator-Runs-Linux-Kernel-4-1-We-re-All-Doomed-473236.shtml Feb 20 17:52:59 hmm. Feb 20 17:53:08 but tell me one thing isn't that auto detection or udev not sufficient Feb 20 17:54:11 udev is waaay later in this process, if the kernel doesn't even know a device exists, udev obviously also will not Feb 20 17:54:52 udev can help out if the kernel recognizes *some* device exists, but isn't quite sure what to do with it Feb 20 17:54:56 for example an unknown usb device Feb 20 17:55:42 rcn-ee: good to know. Feb 20 17:56:28 but there's not really any good way to detect the existence of on-chip peripherals, nor a reliable way to identify what sort of peripheral it might be even if you know the address Feb 20 17:56:29 agmlego, if v3.20 turns into 4.0, that means 4.1 should be a few months away... atleast it's a long term stable release too. ;) Feb 20 17:56:49 k. see what i will do i will devlp a driver that dynamically creates a device file at the time of inserting the module and after that can i use it Feb 20 17:56:51 ?? Feb 20 17:57:03 sure, but that has nothing to do with hardware Feb 20 17:57:07 rcn-ee: yup. Feb 20 17:57:12 (hence nothing to do with device tree) Feb 20 17:57:46 how it has nothing to do with hw Feb 20 17:58:07 in driver i will be using all the register of the hw Feb 20 17:58:16 you could do that Feb 20 17:58:24 if you like pain Feb 20 17:58:25 :P Feb 20 17:58:37 again confused Feb 20 17:59:11 say you just directly access the gpio module.... you get big problems because there's already a device driver loaded for it Feb 20 17:59:30 so you remove or disable its device tree entry Feb 20 17:59:36 then access the gpio module Feb 20 17:59:38 i will remove it Feb 20 17:59:40 yes Feb 20 17:59:54 you get a kernel oops because the module's clock signals aren't enabled Feb 20 18:00:17 because the kernel didn't know anyone wanted to use it Feb 20 18:00:33 because it doesn't know your module is a driver for that piece of hardware Feb 20 18:00:52 why i will touch the DT i will just remove the standard gpio driver module Feb 20 18:01:02 yes, but that has consequences Feb 20 18:01:47 what kind of consequences Feb 20 18:02:29 the DT entry also tells the kernel which register range the driver needs (the kernel will map it for you), which interrupt(s) the module generates (the driver can simply ask for them), which clocks are needed to make the module work (again, the driver just has to ask) Feb 20 18:03:11 so many details are handled automagically by the kernel using the info in device-tree, the driver won't need to concern itself with the details anymore Feb 20 18:03:45 look at slide 15 of http://events.linuxfoundation.org/sites/events/files/slides/petazzoni-device-tree-dummies.pdf Feb 20 18:04:05 means using DT makes driver coding easy Feb 20 18:05:01 easier, and certainly more generic Feb 20 18:06:07 like, you don't want to hardcode the address or irq number in a GPIO driver since 1. they differ per chip 2. there are typically multiple GPIO modules in a chip Feb 20 18:07:56 so previously the driver would define some data structure to contain all the info it needed, and then you had a board definition file in the kernel which instantiated the driver with the relevant info. every new piece of hardware required changing the kernel and recompiling Feb 20 18:08:25 while now that's handled in a generic way Feb 20 18:11:23 anyway, I'm off for a while... read those slides, look at actual device tree files, maybe examine some driver to see how it works... Feb 20 18:12:02 though the gpio-omap driver is probably not a good place to start, it's quite complicated because it supports many different versions of the GPIO module, and both the new device-tree and old non-device-tree way of doing things Feb 20 18:12:12 so it's kind of messy Feb 20 18:16:13 k. thanx for your information Feb 20 18:43:53 i am new to beagle board contribution .... can anyone tell me how to get stearted Feb 20 18:44:05 i am new to beagle board contribution .... can anyone tell me how to get started Feb 20 18:52:43 Utal, find a bug fix it, post it. ;) Feb 20 18:53:07 or two :) Feb 20 18:57:00 rcn-ee, can u send some documentation link Feb 20 18:58:02 Utal, docs: 1: grab coffee, 2: open email, read bb.org bug reports: 3: start on first one...... 4: hours later pull out hair (thats left) 5: ??? 6: submit 7: profit Feb 20 19:01:47 rcn-ee: would it be possible to cherry-pick 1600ef7b54e212775f0cda7138053eb83cde9c7b (add function to request timer by [DT] node) onto the official 3.8 tree? Feb 20 19:02:36 ddrown, which repo? https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=1600ef7b54e212775f0cda7138053eb83cde9c7b (bad commit) Feb 20 19:02:39 or wait, I probably have the wrong id Feb 20 19:03:04 8fc7fcb593ac3c5730c8391c2d7db5b87e2d0bf2 Feb 20 19:03:51 ddrown, i'll add it to my queue and test out.. Feb 20 19:04:11 I'm using it on my build and kernel module Feb 20 19:04:32 cool! Feb 20 19:05:06 I'm using 3.8.13-bone67 branch Feb 20 19:05:23 it's always fun, adding more stuff to 3.8.. the kernel that just won't die! (i have some backports for nimbelink's cape too.) Feb 20 19:05:42 heh yeah, there's so much invested in that branch Feb 20 19:05:48 because so many other things work there too Feb 20 19:07:14 now if everyone would stop staying "no" to panto's patches maybe we can get off 3.8. ;) He has to fight for every single detail... Feb 20 19:07:24 heh Feb 20 19:07:58 yeah, getting stuff into mainline seems to be a pain Feb 20 19:08:42 my kernel module: https://github.com/ddrown/pps-gmtimer Feb 20 19:09:28 oh, and there's a second kernel patch there too - https://github.com/ddrown/pps-gmtimer/blob/master/kernel-tclkin.patch Feb 20 19:09:31 sweet, pps client. ;) Feb 20 19:09:55 without it, TCLKIN doesn't work Feb 20 19:10:34 btw, would you like me to add your module/dtbo to the defualt build too? Feb 20 19:10:41 sure Feb 20 19:11:18 it'll just make things interesting as the *.dtbo will be built in, so if you need to make any changes you'll be forced to rename it.. Feb 20 19:11:32 heh Feb 20 19:12:04 they get put into the initramfs? Feb 20 19:12:22 They'll actually be in the zImage. ;) Feb 20 19:14:36 oh, it gets compiled into the system dtb? Feb 20 19:15:53 the *.dtbo are built as firmware, so they get coped into the zImage. Feb 20 19:16:01 Where as the *.dtb's are external Feb 20 19:16:31 ah ok Feb 20 19:17:18 i wonder, does anything else (cape) currently use P9.41 at the previous 12Mhz setting? Feb 20 19:17:46 using the tclkin_ck isn't possible without that patch Feb 20 19:18:24 if you try to use EXT_CLK as your source without it, it tries to load the timer "timer_ext_ck" which doesn't exist Feb 20 19:18:44 s/load the timer/load the clock/ Feb 20 19:19:38 okay, pushed the cherrypick. ;) Feb 20 19:19:52 it's possible that a cape could use that clock definition, but I don't see how they'd get to it Feb 20 19:20:57 I think later kernels have these clocks defined in the DT, which is much nicer Feb 20 19:21:14 and if someone is using it, they'll just have to pipe up. ;) Feb 20 19:21:49 rcn-ee: support for device tree overlays isn't enabled in the 3.19-bone kernels? Feb 20 19:22:20 not yet. ;) Feb 20 19:23:33 it kind of surprised me Feb 20 19:24:53 I was having a few build errors/issues, so i didn't push that branch out yet. ;) Feb 20 19:25:01 ok Feb 20 19:31:56 rcn-ee: on OSX when I pull the kernel from the git using the ./build_kernel.sh, at the very first time it's telling me I've got files that will be overwritten by checkout. I do a git stash in kernel, then relaunch the script it passes Feb 20 19:33:55 catslab, what version of git is in OSX ? git --version (my hackintosh is at home and i've never looked) Feb 20 19:36:34 1.9.3 on OSX 10.10.2 Feb 20 19:37:18 oh, that's not too bad.. i was thinking it was around 1.7.x (wheezy) or 1.6.x (centos)... Feb 20 19:37:47 which brings up another question, why is it complaining. ;) Feb 20 19:39:30 on the intial clone, i'm using a "shared" reference, wonder if it's a git bug with HFS? Feb 20 19:40:31 yep 1.9.3 on 10.9.5 Feb 20 19:40:51 mmm Feb 20 19:41:26 net/netfilter/xt_DSCP.c and xt_RATEEST.c Feb 20 19:41:37 are the 2 files Feb 20 19:41:50 can't copy paste, it's on another mac Feb 20 19:42:08 yeap, that looks like hfs+ case-insensitve issue. ;) Feb 20 19:42:27 from what i've read, git is suppost to hide that on hfs.. Feb 20 19:42:59 with a stash and rerun it's ok Feb 20 19:44:01 https://avtok.com/2011/08/05/i-hate-hfs.html Feb 20 19:44:13 i'll see about adding a uname lookup and hide that. ;) Feb 20 19:46:12 good writeup of what actually happens; http://polkabecky.tumblr.com/post/54471595169/creating-case-sensitive-filesystems-for-git-on Feb 20 19:46:17 ahaha yes :) anyway I could make a disk image in case sensitive, mount it and compile on it Feb 20 19:47:20 ok you got it before me :) Feb 20 19:47:45 and stick it in ram, for even faster builds ;) Feb 20 19:49:48 yep :) even if the ssd if fast... in ram I won't have time to get a coffee ! Feb 20 19:58:02 wifi will literally drive me insane. half the time, 0% packet loss. the other half, 30% packet loss. no rhyme or reason. Feb 20 19:58:52 blaine_: can be anything from microwave to another wifi, or even solar eruption :) Feb 20 19:59:07 catslab: my laptop, sitting next to me, has no issues =\ Feb 20 19:59:23 maybe that's it? maybe my laptop is interfering with this tiny nano wifi chip Feb 20 20:00:06 maybe, or even the chip can run hot and do some strange things Feb 20 20:00:32 catslab: good point too. Feb 20 20:01:07 i get a bunch of these [ 380.972949] wlan0: deauthenticating from d8:eb:97:2a:bf:92 by local choice (Reason: 3=DEAUTH_LEAVING) Feb 20 20:01:34 looks like a firware trouble to me Feb 20 20:03:43 rcn-ee: on the 3.14 branch is there a way to enable the uio_pruss module in the kernel menuconfig apart from patching ? :) Feb 20 20:05:35 i haven't tried it yet, did you get it to build/work? Feb 20 20:09:02 I had it working on 3.15 but had to patch some files , I'm trying on 3.14 Feb 20 20:10:11 but did not see it in the menuconfig :) So I'll thrown a bunch of patches Feb 20 20:12:54 catslab, ping me on that backport, specially if it works, we need to get uio_pruss working in v3.14.x ( i just haven't worked on it yet) Feb 20 20:13:36 ddrown, your getting the config: CONFIG_PPS_BB_GMTIMER, i got a little creative.. ;) Feb 20 20:14:40 ok, will test that, I have to grab my logic analyser to check if it really works and toggle the pins as it should Feb 20 20:19:31 hi guys i was wondering if you guys could point me in the right direction. I have never used joystick input in c++ and got my ps3 controller working with my beaglebone black through bluetooth. I just need to know how to use the actual input in c++ what would you guys recommend? Feb 20 20:21:23 mistawright, the xinput library should help you out there.. Feb 20 20:22:11 err... there has to be something better, that's just for configuring/testing.. Feb 20 20:23:06 evtest? Feb 20 20:24:37 mistawright, https://github.com/drewnoakes/joystick Feb 20 20:25:27 rcn-ee: heh ok Feb 20 20:28:28 rcn-ee, thanks for the help Feb 20 20:30:25 ddrown, please give head of 3.8.x a test when you have a chance.. it should all be intergrated now.. . https://github.com/RobertCNelson/bb-kernel/commit/288d13c1bb09106783aec6cb67e2fdef2af06049 Feb 20 20:33:07 here's a question -- catslab maybe you've got an idea. if i do a `ping -c 1 8.8.8.8' it returns every time very quickly. except when i'm having wifi issues. now, `ping 8.8.8.8` just skips the message, it doesn't "hang" like -c 1 does Feb 20 20:33:39 presumably because -c 1 is waiting for it to complete. now here's a mystery. I can set a "ttl" for ping. So that it doesn't hang for like 8 seconds when wifi is down. ping -c 1 8.8.8.8 -t 1 (1ms ttl) Feb 20 20:33:57 when wifi is working, this fails immediately with a timeout exceeded. but when i'm having wifi issues, it still hangs for the 5- 8seconds or so. Feb 20 20:34:16 perhaps this is implying that i'm not actually timing out the ping, i'm waiting on the wifi hardware. so maybe it is a firmware issue after all. Feb 20 20:37:28 yes looks like there's a trouble between kernel and wifi herdware Feb 20 20:37:36 and this is called firmware :) Feb 20 20:38:28 hehe. ok cool. i'm just going to order a new one. Feb 20 20:38:57 that's what I was about to tell you Feb 20 20:39:11 you're going to spend too much time on it for nothing Feb 20 20:39:12 yep. too bad, this one fits our case perfectly. but obviously realtek isn't having it. Feb 20 20:39:26 oh Feb 20 20:39:55 all good, we can print a new hole Feb 20 20:40:11 I had to much trouble with realtek wifi harware Feb 20 20:40:35 yeah it's too bad. the other nano cards may work fine, not sure Feb 20 20:40:44 but i'll order one i know has an atheros chip in it Feb 20 20:40:53 yep, more reliable Feb 20 20:41:33 I always had trouble with realtek on geode Feb 20 20:41:45 Just use atheros ;) Feb 20 20:41:48 i think there is no such thing as a nano form factor atheros Feb 20 20:41:53 rcn-ee: yep, learning that the hard way heh Feb 20 20:42:29 the only problem, they get price squezed out by ralink/realtek/etc so there chips are hard to find.. As everyone wants the cheap crap.. Feb 20 20:42:50 i've used arl9170 for a few projects, they work awesome, but you can't get them anymore!!!! Feb 20 20:43:02 =\ -- is arl atheros? Feb 20 20:43:05 https://wikidevi.com/wiki/Atheros Feb 20 20:43:24 carl9170 was the driver i used.. (the commuinty arl9170?) Feb 20 20:43:24 ty Feb 20 20:43:48 20% packet loss is OK if you're using tcp right? heh Feb 20 20:43:51 "ARxyz" is atheros.. Feb 20 20:48:42 A-LINK WNU Feb 20 20:51:29 too big Feb 20 20:52:28 catslab, are you looking for one of those really "small" chips that fit in a usb connector? Feb 20 20:52:58 nope was just wasting time to help blaine_ :) Feb 20 20:53:17 kernel is compiling and nobody at work Feb 20 20:53:18 lol Feb 20 20:53:26 it's friday. ;) Feb 20 20:54:16 yep :) just got back my analyser Feb 20 21:16:45 mmm I think I messed the pinmux :) Feb 20 21:17:13 it should be the same as 3.15.x ;) Feb 20 21:17:25 I'm on 3.15 to validate my cape Feb 20 21:17:34 before switching to 3.15 Feb 20 21:17:37 3.14 Feb 20 21:17:46 ah.. and found a bug. ;) Feb 20 21:18:33 yep and I scrapped my old dts, so I tried to rebuild one Feb 20 21:19:17 what's the best for declaring pins for pruss ? compatible="..... what ? " Feb 20 21:31:57 rcn-ee: got a trouble on 3.14 compilation net/ipv4/netfilter/ipt_ECN.c Feb 20 21:34:17 that's odd... building clean on the build bot: http://builds.beagleboard.org/builders/build-kernel/builds/4 Feb 20 21:34:37 yep I'll check that later Feb 20 21:35:01 got to find out why pins aren't toggling on the cape first :) Feb 20 21:36:31 rcn-ee : if I get an error "make drivers error 2" from your rebuild.sh script .. where is the debug output :P Feb 20 21:37:06 if you have 1+ cores, run it again, it's proballly at the top Feb 20 21:37:39 ah Feb 20 21:38:08 it's fun if you have 8 cores, it takes awhile for the 7 other threads to wind down.. Feb 20 21:38:58 hrm got it .. as I suspected .. Feb 20 21:39:13 trying to build the realtek 8192 sources against mainline kernel .. Feb 20 21:39:42 not gonna be easy Feb 20 21:52:12 ok got the pruss outputing something on 3.15.10 Feb 20 21:52:31 got to find why the int_iep is not working the way I want :) Feb 20 21:55:04 mmm ok, was the analyser.... Never let others play with the analyzer :) Feb 20 21:56:18 you need to chain that to your desk, then no one can borrow it.. Feb 20 21:57:04 definitely Feb 20 21:57:52 ahaha yes or reset the settings each time it comes back Feb 20 22:00:43 and looks like some pins on the 4Dsystem lcd cape are not wired.... Feb 20 22:00:51 I'll have to investigate Feb 20 22:01:35 catslab .. there must be sufficient wired :) Feb 20 22:02:55 ok shelving drivers for tonight .. I've bricked the board anyhow :/ Feb 20 22:03:23 back to serial kernel debuggering Feb 20 22:08:09 i need to configur mcbsp1 pins. I checked i have to use this macro OMAP3_CORE1_IOPAD(0x20d4, PIN_OUTPUT | MUX_MODE0) in dtsi file. How can i know the corresponding mcbps1 pins??? Feb 20 22:08:25 Omap documentation is really not great to understand the muxing details. Feb 20 22:08:40 anyone have any understanding of configuring the muxes? Feb 20 22:17:16 I saw a web page with pinmuxing Feb 20 22:19:59 and can not find the url.... Feb 20 22:20:09 can send you what I downloaded Feb 20 22:20:09 anyone know if there's an EDIF file for BeagleBone Black schematics floating around anywhere? Feb 20 22:26:09 ok I'm gone :) Good WE **** ENDING LOGGING AT Sat Feb 21 02:59:59 2015