**** BEGIN LOGGING AT Mon Jan 23 03:00:00 2017 Jan 23 03:21:40 zmatt hmm I'll take a gander, maybe a look too. Jan 23 06:23:26 hey, this is kinda neat... if an i2c peripheral uses the very common { write offset byte; read/write data bytes } protocol, you can just declare it as EEPROM in DT and then use pread()/pwrite() on the resulting nvmem attribute in sysfs to perform register reads/writes Jan 23 06:24:07 obvious in retrospect, but easily overlooked :) Jan 23 08:34:52 zmatt: :) Jan 23 10:03:38 Which code compiler I should choose for Beagle board X-15 Jan 23 10:04:15 Beagleboard X15 uses AM5x series processor and I would like to implement openCV codes on it Jan 23 10:25:35 your favorite compiler that supports armv7a Jan 23 10:38:49 zeekhuge: Hi Zeek! Jan 23 10:50:21 Hey lore4 ! Jan 23 10:51:35 How are you ? Jan 23 10:52:13 I am fine, thanks. How are you? Jan 23 10:58:09 I am okay. Sorry, I updated my BBB but didnt try the code. Jan 23 10:58:33 actually the new kernel i updated to didnt have remoteproc drivers Jan 23 11:00:31 don't worry Zeek ;) I spent this morning some time to figure out what i am missing... for now, I decided to create a repository so you can access the code. Once, I finished, I'll provide you the link Jan 23 11:33:03 zeekhuge: https://github.com/lore4/TSCADCss Jan 23 11:38:59 omw to lunch Jan 23 12:28:00 https://hastebin.com/xiqocipazo.cc <-- that's what my header for the adc looks like :) Jan 23 12:30:08 https://github.com/lore4/TSCADCss/blob/master/Example/PRU/PRU_RPMsg_Echo_Interrupt1/AM335x_PRU.cmd#L63 this is wrong, cregister 27 does not point to the ADC, in fact none of the cregisters do Jan 23 12:35:18 zmatt, I looked into the PRU compiler and assembler manuals, but there was not description about the CREGISTER tag that is used in the .cmd file. Jan 23 12:35:31 infact this is what the doc says: Jan 23 12:35:37 name 1 [( attr )] : origin = expression , length = expression [, fill = constant] Jan 23 12:36:04 I though the CREGISTER thing is just optional and is to make the the code more understandable Jan 23 12:38:16 *thought Jan 23 12:43:14 zmatt: subarctic? aegis? Jan 23 12:43:25 zmatt: sounds like names of secret projects in an anime series Jan 23 12:43:47 zmatt: although "götterfunken" is missing Jan 23 13:08:17 zmatt, zeekhuge: I am back :) Jan 23 13:09:40 zmatt: ty for pasting your header! Jan 23 13:10:22 zmatt: that is my last test. Usually, I use "#define TSCADCSS (*((volatile sysTscadcss*)0x44E0D000))" to define the ADC access... is it also wrong? Jan 23 13:11:08 zeekhuge: there are also examples that do not specify any CREGISTER, but stillI have not any clue about that :( Jan 23 13:14:10 zmatt: what do you read by default into ADCSTAT of ADC, please? Jan 23 13:14:57 lore4: examples ? like ? link ..? Jan 23 13:15:59 zeekhuge: it works!!!! Jan 23 13:16:15 push it ! Jan 23 13:16:24 ship it! Jan 23 13:16:47 lol... everyone here was waiting for that? Jan 23 13:17:26 finish some test and then I'll commit Jan 23 13:17:41 what did you change ? Jan 23 13:17:53 lore4: ^^ Jan 23 13:18:31 I feel really dumb to say that... but the most of was due to a missing "echo 'BB-ADC' > /sys/devices/platform/bone_capemgr/slots" Jan 23 13:18:51 zeekhuge: which i do not know why it has such a big influence as we are reading from mem Jan 23 13:19:12 adc clocks I would suspect Jan 23 13:19:23 what do you mean? Jan 23 13:19:36 not every module is enabled by default in the chip Jan 23 13:19:47 there's muxes and clocks to set up for each submodule Jan 23 13:20:13 when you load a cape .. all sorts of magic happens :) Jan 23 13:20:17 uhm... and the module does it? Jan 23 13:20:32 cape is BBB mojo Jan 23 13:20:35 which is why the board has been a bit dead without the cape_mgr for a while Jan 23 13:20:44 nothing cape-specific about it Jan 23 13:20:49 unless you know how to set things up with the DT .. Jan 23 13:20:55 capemgr is just one or two ways to load overlays Jan 23 13:21:02 and overlays are a way to edit the DT at runtime Jan 23 13:21:07 zmatt: will explain it better .. :D Jan 23 13:21:15 what matters is the DT, regardless of how it got there :P Jan 23 13:21:26 right :D Jan 23 13:21:32 lore4: so "TSCADCSS (R) : org = 0x44E0D000 len = 0x00000300 CREGISTER=27 // 31" works to access the ADC ? Jan 23 13:21:57 the cregister is plain wrong Jan 23 13:22:17 zeekhuge: no, now it is not using that define Jan 23 13:22:27 finalizing to clean up a bit the code then I'll commit Jan 23 13:23:03 and if you want to verify you can read from the adc, read the ident register (offset 0) and compare against the value I mentioned in comments in my header Jan 23 13:24:35 zmatt: ok! committing, then going into it! :D Jan 23 13:27:13 and prcm troubles can be avoided when accessing stuff from the cortex-a8 by using uio instead of /dev/mem to let the kernel still do the necessary power management dance... that doesn't help directly of course for PRU access to a device (although it may be an option to let a process on the a8 keep the device open on PRU's behalf) Jan 23 13:28:03 zmatt: uhm... now I got lost, sorry T.T Jan 23 13:28:29 so, normally the kernel will perform necessary power management stuff for devices Jan 23 13:28:37 ok Jan 23 13:28:57 (btw, committed! ) Jan 23 13:29:03 \o/ Jan 23 13:29:09 it knows how to do this thanks to the "ti,hwmods" property in device tree entries, which reference hardware data that's currently still hardcoded in the kernel Jan 23 13:29:39 ok Jan 23 13:31:27 this works basically regardless of the driver, so you can e.g. use the generic uio driver (uio_pdrv_genirq) instead of TI's tscadc driver Jan 23 13:31:56 then if you open the resulting uio device, the kernel will ensure the adc has its clock(s) enabled Jan 23 13:34:04 loading the "BB-ADC" overlay will of course also enable its clocks, because the tscadc driver wants to be able to use the adc obviously, but this driver conflicts with manually accessing the adc (other than introspecting its status) Jan 23 13:35:14 ahh.. so you mean that the most important thing it is not to provide a module in DT but to enable "peripherals" by setting "ti, hwmods"? Jan 23 13:35:41 ti,hwmods is a property that needs to be set on a DT node representing the device Jan 23 13:35:46 sorry, I am dumb :P Jan 23 13:36:07 lore4: there's a lot to get your head around Jan 23 13:36:11 and zmatt is a pro :p Jan 23 13:36:20 (or, well, technically just *a* device... but for sanity's sake I'll assume it's the appropriate one :P ) Jan 23 13:37:40 ver|laptop: really ! when zmatt says something, I really try to concentrate and understand each word he is saying ! Man !! Jan 23 13:37:48 lore4: so, the sequence is: kernel counters a DT node, tries to locate the right driver Jan 23 13:38:22 before it lets the driver probe the device described by the DT node, it also makes sure the device is accessible Jan 23 13:38:49 for this it references the ti,hwmods property so it knows e.g. which clocks to enable Jan 23 13:39:12 zeekhuge: I'll let zmatt contradict that .. but he sure knows a lot.. and works intimately with the TI procs :D Jan 23 13:39:29 zmatt: ^ hope thats fair!? ;) Jan 23 13:39:40 ver|laptop: phew... now i am a bit more relaxed, ty ;) Jan 23 13:40:22 lore4: and he can explain it heaps better than the little bits I understand haha :D Jan 23 13:40:51 if kernel can't find a driver, or the driver indicates it doesn't need access to the device anymore for a while, the kernel will disable the device again until further notice Jan 23 13:41:25 (and if there's a status="disabled" property the kernel isn't even going to try to look for a driver) Jan 23 13:42:54 zmatt: uhm.. so if i get it right, then how driver indicates that it doesn't need access to the device anymore? Jan 23 13:44:12 I mean, could it happen that I loaded *a* driver and then I find out that my app is not working as somehow the driver indicated that it doesn't need access anyomore? Jan 23 13:45:04 that would suggest the driver is broken Jan 23 13:45:25 ver|laptop: lol... that's good, I am a bit worried to ask too much as here all are just sharing for free Jan 23 13:46:03 zmatt: uhm... do you mean hw broken or software broken? Jan 23 13:46:04 it's the driver's responsibility to not lie to the kernel's power management framework :P Jan 23 13:46:21 about whether the device is in active use or not Jan 23 13:48:37 this is an extremely simple example: http://lxr.free-electrons.com/source/drivers/bus/simple-pm-bus.c during probe it simply indicates the device is in use (pm_runtime_enable) and it stays that way until removal Jan 23 13:48:48 ok, hence the driver is the one that manage the peripheral, but it is the kernel the one that manages peripheral's power. Am I right? Jan 23 13:49:30 wait, my description of what's going on there is wrong Jan 23 13:50:17 simple-pm-bus actually enables power management there, i.e. it allows the kernel to disable whenever it sees no reason to keep the device enabled Jan 23 13:51:11 kernel is like whole collection of other device drivers and management algorithms. so kernel uses other device drivers to maintain power i think. Jan 23 13:51:18 this driver itself actually has no reason to keep it enabled, as you can see there's absolutely nothing going on on it Jan 23 13:51:35 uhm .. okay . I'll keep quite. Jan 23 13:51:41 however, it may have children Jan 23 13:51:56 if any of those are kept active, then so will this bus driver Jan 23 13:52:58 why should a driver has childer? Do you mean by fork? Jan 23 13:53:05 no Jan 23 13:53:08 *children Jan 23 13:53:18 simple-pm-bus is a driver that can be used e.g. for interconnects Jan 23 13:53:32 the child devices would be peripherals connected to that interconnect Jan 23 13:53:51 each one for each peripheral, right? Jan 23 13:54:02 *one for each Jan 23 13:54:07 a nice example is a PWMSS instance with its children eHRPWM, eCAP, and eQEP Jan 23 13:56:11 there's nothing really going on in PWMSS itself, but it does need to be enabled to be able to access one of the three modules inside it Jan 23 13:57:07 so, the kernel keeps track of these relationships and the power management framework will automatically wake up parent devices if necessary Jan 23 13:58:04 zmatt: http://processors.wiki.ti.com/index.php/Linux_Core_PWM_User's_Guide ? Jan 23 13:58:05 anyway, this is a bit of a side-track Jan 23 13:58:26 what about it? Jan 23 14:00:07 if I got it right: to power peripherals, the kernel must load their driver. To power certain peripherals, kernel may load driver that are not directly linked to those peripherals Jan 23 14:00:18 eh, no Jan 23 14:00:23 (first of all, thanks zmatt for the explanation!) Jan 23 14:00:27 T.T Jan 23 14:00:30 this has nothing to do with driver loading Jan 23 14:00:50 the kernel doesn't need to load anything to power peripherals, it knows perfectly well how to do that Jan 23 14:01:06 and it knows that bia DT, right? Jan 23 14:01:12 *via Jan 23 14:02:01 (and it performs this power management semi-automagically on behalf of device drivers, which merely need to indicate whether they need the device to be active or not) Jan 23 14:02:37 yes, the ti,hwmods property is how the kernel knows which of its built-in knowledge applies to some device Jan 23 14:05:53 then, the built-in knowledge are drivers or modules? first of all, drivers are modules? Jan 23 14:06:36 or, this built-in knowledge is something different from kernel and modules Jan 23 14:09:52 meanwhile, I am looking at you code for ADC, nice ordering and commenting ;) Jan 23 14:17:41 zmatt: ident is the same ;) Jan 23 14:18:51 a module is just a runtime-loadable chunk of kernel, typically (but not necessarily) containing a driver Jan 23 14:19:28 the built-in knowledge is a big pile of tables Jan 23 14:20:06 e.g. http://lxr.free-electrons.com/source/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c Jan 23 14:20:33 ah, there's the built-in knowledge for the adc: http://lxr.free-electrons.com/source/arch/arm/mach-omap2/omap_hwmod_33xx_data.c#L91 Jan 23 14:21:25 that name on line 110 is what ti,hwmods is matched against Jan 23 14:24:29 so ".name = "adc_tsc"," is matched to "ti,hwmods" in DT? Jan 23 14:25:31 yeah, on line 856: http://lxr.free-electrons.com/source/arch/arm/boot/dts/am33xx.dtsi#L851 Jan 23 14:26:33 ahhhhhh.... Jan 23 14:27:29 this is really cool! Jan 23 14:29:41 and in that DTSI it is not specified any driver name, right? only that the status is disable... Hence, If it changes to status "okay" then the peripheral is enabled Jan 23 14:29:53 am I right? Jan 23 14:30:15 there's most certainly a driver indicated, line 852 Jan 23 14:30:38 btw, I notices that your ADC0_data is in a different address than 44E0D200/44E0D100... am I missing anything? Jan 23 14:31:22 if no compatible-string were given (or no driver were found for the compatible-string(s) specified) then effectively it would be like status="disabled" Jan 23 14:31:55 the adc has a separate data port directly on the L3 interconnect Jan 23 14:32:14 ouch! : \ Jan 23 14:32:19 why ouch? Jan 23 14:32:53 you can use either of the two, but the data port on the L3 interconnect is a better choice for transferring large amounts of data Jan 23 14:32:59 I didn't know that "compatible = "ti,am3359-tscadc";" meant the compatible driver Jan 23 14:33:10 now you do :) Jan 23 14:33:14 thanks :D Jan 23 14:33:38 I really have a lot to learn! ^_^" Jan 23 14:33:45 (still) Jan 23 14:34:56 so, what I do is change the compatible-string to match against the uio_pdrv_genirq driver instead, this allows the device registers to be mmap()ed after opening the device similar to using /dev/mem, except now the kernel knows you need access to the device hence the pm framework will kick in to enable the adc clocks Jan 23 14:35:16 as a bonus, uio_pdrv_genirq allows irqs to be delivered to userspace Jan 23 14:44:37 zmatt: uhm... wait, please... Jan 23 14:44:55 sure, I'll go make tea while I wait though ;) Jan 23 14:45:08 zmatt: sure, no stress ;) Jan 23 14:56:01 zmatt: I have some issue in understanding wjat dp you mean by "compatible-string to match with uio_pdrv_genirq" Jan 23 15:02:53 actually, I have several issues... but I would start with that xD Jan 23 15:12:32 that driver is a little bit eccentric since it has no compatible-strings by default to match against. you can specify one with a module parameter however, though I just realized you can probably actually just put the literal driver name ("uio_pdrv_genirq") in the compatible-string Jan 23 15:14:50 zmatt: ty. So you mean that in your DT you specified the uio_pdrv_genirq instead in order to access adc via mmap? Jan 23 15:15:18 *So, do you mean that ... Jan 23 15:16:41 yes, the uio_pdrv_genirq driver is usable for most peripherals Jan 23 15:17:37 ah ha!... first question with a "yes" as response :D Jan 23 15:19:49 hehe Jan 23 15:21:24 zmatt: I understand that from line 96 to 165, it is "the same" as I did in sysTscadcss struct, however I do not understand struct StepBase, Fifo, and Step. Are these structs fro your application? Jan 23 15:21:30 *for Jan 23 15:23:23 no, they're structs for ADC registers Jan 23 15:23:33 I use them a bit lower Jan 23 15:29:13 line? Jan 23 15:32:11 eh, 156-160 Jan 23 15:51:41 ahhh... yes Jan 23 15:51:53 they are register bit fields! Jan 23 15:52:10 thank you Jan 23 15:54:38 zmatt: do you know which config-pin mode it is needed to change a pin to ADC mode? Jan 23 15:57:28 I also understood that the l3 data port that you were referring to, it is the ADC DMA in global memory Jan 23 15:58:47 adc has dedicated pins Jan 23 15:59:08 yeah the data port is also called the dma port, although there's not really anything dma-specific to it Jan 23 16:03:06 zmatt: cool, so no need to se any config-pin, right? Jan 23 16:03:38 correct Jan 23 16:04:14 zmatt: roger that! Second positive answer, wu-uh! Jan 23 16:04:43 :D Jan 23 16:04:53 I double check the assembly example to understand now what should I do in order to configure the adc to read from 1 pin Jan 23 16:04:57 :D Jan 23 16:05:18 I mean to read some values from a pin Jan 23 16:05:26 thank you, zmatt! Jan 23 16:22:21 Hello everyone, I am having a small issue and was hoping someone could help me. I am running a beaglebone black with Debian 8.6 and after having some trouble with the preinstalled version of the cloud9 IDE(namely no autocomplete, which seems to be a common issue after google) I attempted to install a newer version of it. I put it into the path "/opt/cloud9_new/" and ran the automated install scripts which all worked fine. Jan 23 16:22:25 After that I just had to edit the systemd startup script to use the new instance during bootup. I do so by changing the WorkingDirectory value in /lib/systemd/system/cloud9.service to the new path. Now, everytime I boot up the startup script fails as it seems it has already been started, at the least the log showing an "Error: listen EADDRINUSE". If I manually shut it down (through systemctl stop ...) and then start it again (again t Jan 23 16:22:36 I know this is just a small problem but I was hoping someone could help me or at least has an idea what I might have done wrong? Jan 23 18:32:26 anybody have experience tuning/tweaking BBBW wireless? I seem to get maximum 9 MBits/sec using BBBW onboard wireless chipset, but 29 MBits/sec using a $5 mt7601u-based usb dongle. The former strikes me as quite slow Jan 23 18:32:43 (benchmarks based on iperf) Jan 23 18:45:08 latest firmware? Jan 23 18:45:31 yep, ive done full-upgrade Jan 23 18:46:20 if you mean using APT, probably will not have installed a newer kernel Jan 23 18:47:18 i'm running the 4.4.30 kernel, which is what comes on the November 6 stable image, I believe Jan 23 18:48:49 latest kernels from the 4.4 series are 4.4.43-ti-r84 and 4.4.44-bone16 Jan 23 18:49:19 I'm not sure whether the kernel is a factor though, but it might be Jan 23 18:49:40 I know they fixed some performance issue some time ago, but I don't know if it was in kernel, firmware package, or even a config file Jan 23 18:52:32 hrm, ok, I'll give the latest (stable) kernal a go. Jan 23 18:54:31 ok, apparently that fix was in the bb-wl18xx-firmware package, which presumably got updated if you installed updates Jan 23 18:55:26 thanks @zmatt Jan 23 18:55:38 apparently the important bit is a wl18xx.conf file (I'm guessing in /etc/modprobe.d/ ?) with the line: options wl18xx ht_mode=default Jan 23 18:56:53 with ht_mode=defulat being the desired mode? Jan 23 18:58:22 https://github.com/rcn-ee/repos/blob/master/bb-wl18xx-firmware/suite/jessie/debian/wl18xx.conf Jan 23 18:58:56 I see this in an irc log from november: Jan 23 18:59:02 deva_, with iperf i'm getting: (4.4.27-ti-r62) [SUM] 0.0-10.5 sec 42.8 MBytes 34.2 Mbits/sec (4.9.0-rc3-ti-r2) [SUM] 0.0-10.1 sec 49.1 MBytes 41.0 Mbits/sec Jan 23 19:02:31 hrm, ok, i'll investigate other things then (I'm only 10 ft from router, so dunno what else could be the issue). Thank for your time zmatt, i appreciate it. Jan 23 19:13:29 zmatt - You using a TI wifi? What kernel ver? Jan 23 19:15:24 path would be more like /lib/firmware/ti-connectivity/wl18xx-conf.bin Jan 23 19:18:54 zmatt - if you’re aware of a specific performance fix for the TI wilink, I’d be interested in hearing specifics. Jan 23 19:20:15 I had to deal with the ti backports repo when I implemented drivers for board integrating their chip because their devs weren’t pushing their drivers into the mainline kernel at the time. Jan 23 21:16:40 splud: I gave specifics above for a specific fix (namely to enable MIMO), but that is already a while ago and integrated in the latest stable images for a while already. I do not have any beaglebone with a wl18xx chipset myself Jan 23 21:17:41 while getting stuff into mainline is good, it has little impact for most beaglebone users since the (current) default kernel is based on the TI kernel series anyway Jan 23 21:18:31 (and the path I guessed was correct) Jan 23 21:27:20 Sadly, TI insists on “maintaining” their own kernel and driver tree. Makes using TI products for prodution a PITA because you can’t necessarily just use the mainline kernel. BB is a nifty SBC device, but it’s basically a pitch for using TI products. Jan 23 21:28:04 I see continuous progress made with upstream integration, but it's a process that takes time Jan 23 21:30:02 it doesn't surprise me that TI also just wants stuff to work without waiting for mainline integration Jan 23 21:30:35 given the effort is takes to maintain out-of-kernel patches, I'm pretty sure they would very much like to see stuff upstream Jan 23 21:31:20 They maintain their own kernel repo. Jan 23 21:31:23 however getting stuff in mainline can also be a serious PITA, and some maintainers are simply obnoxious Jan 23 21:31:26 yes, of course Jan 23 21:31:34 so does the beaglebone project (more than one even) Jan 23 21:31:43 and probably every distro Jan 23 21:32:01 and I have my own linux repo with custom patches Jan 23 21:32:47 (most of which have however at least been merged by my "upstream", rcn-ee) Jan 23 21:33:06 But for some development customer having to use the TI repo and their build environment (they’ve got scripts that actually check for a specific Ubuntu release for the build host), it’s a serious pain. Jan 23 21:33:47 It’s an effort to reverse engineer the stuff to sort out what is really needed or not to integrate it into ones own build environment. Jan 23 21:33:58 you mean the sdk? there's really no need to use that, and last time I wanted to check something in their SDK the check could simply by ignored Jan 23 21:34:17 yes, fortunately rcn-ee does most of that work :) Jan 23 21:38:53 and to illustrate the pain it can be to get stuff upstream: I recently came across the blog of the guy who got hired by broadcom to work on an open source vc4 driver, and who ended up becoming the rpi kernel maintainer... about this process he said "Every step of the way is misery to get the code merged, and I would give up a lot to never work on the Linux kernel again." Jan 23 21:40:08 I personally likewise have patches that I should probably try to upstream, but I just don't have the energy to deal with the hassle right now Jan 23 21:43:36 Seems to me that driver maintainers for one manufacturer or another should have an easier time developing a relationship which enabled them to upstream in a timely fashion. Jan 23 21:45:30 I don't closely follow the linux-omap mailing list, but there seem to be patches submitted by people @ti.com nearly every day Jan 23 21:46:24 and indeed today's BBB kernels are much closer to mainline than they used to be Jan 23 21:46:49 I think even am335x suspend/remove is getting close to being mainline Jan 23 21:47:51 *suspend/resume Jan 23 21:58:53 Have you ever used the mmc util to set write reliability on the BB ? Jan 23 22:00:20 The onboard eMMC flash part is apparently pretty much factory default, and I’d like to set it for reliable write (single block operations) to lessen potential devastation from loss of power. **** ENDING LOGGING AT Tue Jan 24 03:00:01 2017