**** BEGIN LOGGING AT Sat Aug 06 02:59:58 2016 Aug 06 03:00:57 ARGH Aug 06 03:01:04 i guess i am writing a tda19988 driver tonight too Aug 06 03:01:43 in one night? :) Aug 06 03:02:24 basically your best bet would be copying the linux driver as directly as possible Aug 06 03:02:55 assuming that doesn't get you into license conflicts Aug 06 03:02:59 by "writing" i mean "mangling the extant one to autoconfigure when the 'nxp,tda998x' fdt node is hit" Aug 06 03:03:10 it will Aug 06 03:03:29 then good luck Aug 06 03:03:34 we are very strictly no-GPL & it wouldn't work regardless (bsd driver environment is a lot different) Aug 06 03:03:36 thanks :) Aug 06 03:03:39 there's no usable public documentation for the tda Aug 06 03:03:46 ! Aug 06 03:04:16 although there's a (possibly accidently) released repo somewhere with tda stuff for some microcontroller Aug 06 03:04:20 i am really unimpressed with nxp/freescale Aug 06 03:04:30 ill google around for it Aug 06 03:04:59 https://github.com/joelagnel/beagle-nxp-hdmi Aug 06 03:05:05 ah, thanks Aug 06 03:05:18 oh that's also GPL Aug 06 03:05:20 hmz Aug 06 03:05:34 i can still figure out what's going on and re-implement it myself Aug 06 03:06:18 gplv2 stuff we can ~sorta~ get away with Aug 06 03:06:46 that includes all of linux Aug 06 03:07:03 yeah, this uh Aug 06 03:07:09 isn't really my area of expertise Aug 06 03:07:37 but, if you're not doing open source then probably you have no issue getting the datasheet from nxp under NDA Aug 06 03:07:48 i am :( Aug 06 03:07:49 openbsd Aug 06 03:08:04 then... heh you're kinda screwed Aug 06 03:08:39 im screwed if i can't work backwards from this linux driver and re-implement it myself Aug 06 03:10:17 some relatives of the tda19988 have register descriptions, like the tda9983b, but i don't know how close it is to the tda19988 Aug 06 03:10:43 let's hope "close" Aug 06 03:10:56 overall it seems like a pretty nice and versatile hdmi framer... Aug 06 03:12:06 if it weren't for the lack of full public docs Aug 06 03:12:15 at least I'm assuming that's still the case, haven't checked recently Aug 06 03:13:31 i am unimpressed with nxp/freescale Aug 06 03:13:43 https://github.com/tcort/minix-i2c/tree/master/drivers/tda19988 Aug 06 03:14:42 why? my experiences with / impressions from them has so far usually been positive Aug 06 03:16:15 bad documentation compared to TI Aug 06 03:16:25 really ass-backwards design on the SoCs Aug 06 03:16:31 specifically imx6q's IPU Aug 06 03:17:09 "bad documentation compared to TI" is more saying about the usually good documentation from TI Aug 06 03:17:18 they tend to abbandon projects like the imx6q SDK which had a bunch of example software that used values you couldn't find in the imx6q ref. manual Aug 06 03:18:05 the docs I've seen for imx and nxp (which really shouldn't be thrown on one pile obviously) seemed pretty decent relative to, ehm, some other SoC vendors Aug 06 03:18:46 I won't name any names... well except broadcom maybe Aug 06 03:19:21 they are almost-legibile, ill give them that Aug 06 03:20:07 imx5 reference manual also contains surprisingly lot of info about security and efuse stuff Aug 06 03:20:20 but they are incomplete, full of grammar/typesetting errors, overly-wordy when describing mundane things you'll never need to worry about, and too curt describing really really important things Aug 06 03:20:54 really those sound like very minor faults Aug 06 03:21:22 i have high standards Aug 06 03:21:25 and trust me, TI docs are also incomplete and full of mistakes Aug 06 03:21:28 i wouldn't write documentation like that Aug 06 03:21:32 that's true Aug 06 03:22:07 but have you ever looked at the docs available for, say, the broadcom SoCs used on the rpi series? Aug 06 03:22:24 never Aug 06 03:22:29 that doesn't even qualify to be called an SoC Aug 06 03:22:33 :P Aug 06 03:22:40 i let that dog lie Aug 06 03:22:56 a more appropriate name is undocumented ASIC :P Aug 06 03:23:09 kremlin: they're written by one dude of the rpi project *based on* the unpublished broadcom datasheet Aug 06 03:23:31 the errata are a community-maintained wiki Aug 06 03:23:55 doesn't bode well Aug 06 03:24:10 zmatt: like I said... a more accurate name is undocumented ASIC :P Aug 06 03:24:11 i hope broadcomm didn't do the rpi3's armv8 SoC Aug 06 03:24:13 it only documents a few of the peripherals Aug 06 03:24:29 i need a good cheap well-doc'd AArch64 board Aug 06 03:24:48 actually all rpi variants basically just minor variations of the same broadcom SoC Aug 06 03:25:03 i don't think i'd buy [board,qual]comm products out of principle, though. they are very anti-open source Aug 06 03:25:12 well shoot Aug 06 03:25:20 broad* Aug 06 03:25:33 also I heard the rpi3 doesn't actually work in 64-bit mode yet Aug 06 03:25:54 sad Aug 06 03:26:45 in any case, all three generations are the same bcm2708 VideoCore 4 SoC, each with a different ARM subsystem tacked onto the side Aug 06 03:27:08 (the ARM processor is not the boot cpu, it boots from the VideoCore 4 processor) Aug 06 03:27:57 geez. Aug 06 12:29:06 Hello People Aug 06 12:41:39 I keep bumping that darn cable. Aug 06 12:50:37 Greetings. Being a total newbie I have been using the oracle at google.com to find my way around. SAdly I have recently run adrift and need a flashlight. Aug 06 12:51:57 I have BeagleBone Green running 4.4-LTS, And all of the tutorials I have seen so far have you doing something like echo board_name > /sys/devices/beagle_capemgr.*/slots. Well in my partiuclar Kernel, that driver doesn't exist. Aug 06 12:53:06 there is a /sys/devices/platform/beagle_bon/beagle_capemgr/slots-4 and slots in the same place. So my question is what am I missing? Aug 06 12:53:45 I don't want the answer, just a flash light to illuminate the path. Aug 06 12:53:48 mh, not sure which 4.x kernels have the cape manager and how it works Aug 06 12:54:20 basically most "exactsteps" on "the intarwebz" will be based on the ancient 3.8.xx TI vendor kernel Aug 06 12:54:49 so some abstraction is to be expected when running a newer kernel Aug 06 12:55:31 it is very well possible, that what you found is the current home of cape-manager Aug 06 12:55:34 Ahh, okay, where can I find some new information? What I am trying to do, is configure a PRU, to count a mock Encoder signal (generated by an Arduino Uno. Aug 06 12:56:27 you could "cat /sys/devices/platform/beagle_bon/beagle_capemgr/slots-4" to see what it says in the virtual file Aug 06 12:56:40 PRU will need some extra steps, I guess Aug 06 12:57:10 tbr: Thanks for the insight, well I thought that initially, but wen I try to echo to the /slots file, I get a write error, or an invalid parameter error. Aug 06 12:57:55 I guess a good place to check for discussions of such topics is the google group/form for beagleboard Aug 06 12:58:05 tbr: I am guessing it will, Probably a bit too ambitious a project for a newbie, but the PRU's is why I am playing with the beaglebone. Aug 06 12:59:52 One more question, My understanding is that the inputs to the Beaglebone are not 5v tolerant. So I am setting up a simple voltage divider for the time being. What's the preferred way to handle a pulsing signle that is 5v? Aug 06 13:00:40 for instance a quadrature encoder. Aug 06 13:01:25 I'd probably use level converters for "signals proper" Aug 06 13:01:40 dime-a-dozen from china Aug 06 13:02:10 tbr: I'll do that. Thanks for the insight. I'll see if I Can figure out how to load my overlay. Aug 06 13:02:34 which is what I am trying to do. Aug 06 13:02:39 not only are the inputs not 5V tolerant, the SoC will also blow up if you put voltage on IO pins while it's OFF Aug 06 13:02:55 That's no good! Aug 06 13:03:05 I'll keep that inmind! Aug 06 13:03:21 Any other land minds I should avoid while workign with the BBB? Aug 06 13:04:06 there is some rare problem where the board will die if you disconnect power by yanking out the cable in operation Aug 06 13:04:19 thus it's recommended to shut it down properly Aug 06 13:15:19 cdwBeableNewbie: like tbr said, for signals (other than open-drain/open-collector) being input into the BBB it's highly recommended to use a buffer powered from the BBB's own 3.3v Aug 06 13:16:16 I'd be inclined to include a series resistor on the buffer's output also to limit current in ugly power-down scenarios Aug 06 13:19:01 btw, the beaglebone has three hardware quadrature decoders Aug 06 13:19:25 that can track position and velocity and include a motor stall watchdog Aug 06 13:19:46 *the am335x I should say Aug 06 13:31:22 zmatt: thanks for the info. I am embarking on a learning expedition (despite the availablility already) of building a 3-d printer brain. What I a want to do is add an encoder to all the axis and us that the determine if the commanded move was made. So there is a lot of things I have to learn and am planning to take it one step at a time. Aug 06 13:33:04 Firs step obviously is getting the PRU's working and using it to count the direction of an encoder (gonna fake the enoder on the arduino at least temporarily) Aug 06 13:33:49 well like I said you don't need to use PRUs for it, there's actual hw support Aug 06 13:34:30 of course using a PRU is probably a usable alternative e.g. if you need the pins to which the eQEP modules are mapped for other uses Aug 06 13:34:40 I look into that. I still need to find a way to configure that correct? Aug 06 13:35:02 yeah, although I even have an example using uio from python for that Aug 06 13:35:24 see qep-test in https://github.com/mvduin/py-uio Aug 06 13:36:35 Oh, another thing, I bought a sparkfun protocape with a blank eeprom, do you have a link about how to write it? Aug 06 13:37:41 if it's an i2c eeprom and declared in DT (already done by default for the four standard cape eeprom addresses) then it'll show up in sysfs Aug 06 13:38:24 okay, then I can just copy a binary file to it with how I want it configured? Aug 06 13:38:50 yeah it just looks like a regular file that you can read and (if not write-protected) write Aug 06 13:39:09 Great, makes that a lot easier to deal with. Aug 06 13:39:22 thanks for your patience with this newbie! Aug 06 13:39:31 ls /sys/bus/nvmem/devices/*/nvmem Aug 06 13:40:36 there'll be a 0-0050 or 0-00500 device (seems to depend a bit of kernel version) for the bbb's on-board eeprom Aug 06 13:41:30 I think cape eeproms will show up as 1-* but I don't have capemgr enabled myself so I'm not sure Aug 06 13:41:34 cool. So back to my original question, has the beagle_capemgr been removed. Aug 06 13:42:17 afaik it's still present and enabled by default in all of rcn's kernels/DTs for the beaglebone Aug 06 13:43:18 Any links that woudl show how to configure resources like PRU etc? Aug 06 13:43:33 Based on more recent Kernel versions? Aug 06 13:44:28 or is the preferred way to handle it to go to userland instead of kernel land? Aug 06 13:44:38 I've been off the "standard path" for so long I really have no idea anymore what the official way is newcomers are expected to do things Aug 06 13:44:51 like they made the horrible cape-universal enabled by default Aug 06 13:45:37 also the 4.x-ti kernels use remoteproc for PRU instead of uio_pruss (although there's still the 4.x-bone kernels that default to uio_pruss) Aug 06 13:46:33 if cape-universal is disabled in /boot/uEnv.txt and a 4.x-bone kernel is used then loading an overlay for PRU should work as it used to Aug 06 13:46:42 zmatt: that is probably what I was missing. Aug 06 13:47:28 so I need to disable the cap-universale in uEnv.txt (another lesson I learned, the hard way). Aug 06 13:47:35 I also made some utils that make the job of writing overlays less painful https://github.com/mvduin/overlay-utils Aug 06 13:47:53 I'll grab those... Aug 06 13:48:04 although I use the new configfs mechanism for loading overlays (with bin/add-overlay) rather than bone_capemgr Aug 06 13:48:27 zmatt: Any guide on setting up my dev environment? Aug 06 13:48:54 Do you work in windows, linux, macosx? OR do you use the cloud IDE? Aug 06 13:49:03 linux exclusively Aug 06 13:49:17 and like I said, I haven't followed the standard path for a long time Aug 06 13:49:21 Do you code directly on the BBB using VIM? or do you another UDE? Aug 06 13:50:37 I use debian stretch rather than jessie, custom compiled kernel, completely custom DT, uio_pdrv_genirq or /dev/mem to access quite a few peripherals (with the help of our own C++ headers for numerous peripherals) Aug 06 13:51:34 so I'm never really sure how to advise newcomers on setting things up Aug 06 13:52:10 Thank you. Understood. You are quite a ways further down the learning curve than I am. thanks for the insights. Aug 06 13:52:50 I am beginning to research the configfs so I can start to understand it. Aug 06 13:53:06 a small glimpse of the sort of stuff I do can be seen here https://github.com/dutchanddutch/jbang :) Aug 06 13:53:13 that was the flashlight I needed. Aug 06 13:53:47 (not that meddling with pinmux directly like I'm doing there should be viewed as any sort of recommendation) Aug 06 13:55:02 who has used onion omega here? Aug 06 13:55:37 bokenator2: this is the channel for beagleboards and beaglebones Aug 06 13:55:40 duh Aug 06 13:56:12 LOL, no I have no plans on doing that. Although in my collection of goodies that included the BBB I got a seed CPLD breakout, and am needing a way to program it. Considered using Arduino for it, but looks like I might find a handy way to use the BBB for it too. Aug 06 13:56:58 cdwBeableNewbie: https://github.com/mvduin/bbb-pin-utils these may be handy too Aug 06 13:57:13 in particular show-pins which shows a detailed overview of your current pinmux state Aug 06 13:57:23 (pipe through sort to get it sorted by expansion header pin) Aug 06 13:58:30 zmatt: You are a wealth of information. Thanks. Aug 06 13:59:04 oh and https://goo.gl/Jkcg0w may be of use also, especially the sheets labeled P9 and P8 Aug 06 14:01:20 and if you ever need to handle peripheral irqs in PRUSS or setup EDMA, I collected all relevant event numbers here -> https://docs.google.com/spreadsheets/d/1OipGNHITcz11S4phqUVysvS5rl_-HO--N3AalQqbtSQ/view Aug 06 14:01:31 (most of that can also be found in the TRM, but not conveniently in one place) Aug 06 14:02:22 zmatt: you hang around here often? Aug 06 14:02:54 I don't get a lot of time to wear my embedded systems hat, but it's nice to know htere is a knowledge able person around. Aug 06 14:03:25 in that last spreadsheet I occasionally also included related SoCs for comparison; it's always the "subarctic" column you need (which is the name of the die which receives the AM335x part codes among others) Aug 06 14:03:53 yeah I'm always in here, though obviously if you poke me it might take a while for me to respond Aug 06 14:04:44 no sweat thanks man. I appreciate the information... a lot more than I am ready to udnerstand, but at least you shown a flashlight so I can see where I am going now. Aug 06 14:05:18 (in technical IRC channels it's generally a good idea anyway to stay connected for a good while after asking a question since people might just peek in every now and then) Aug 06 14:06:28 yeah I do that with my day job (web application developer) So I spend a lot fo time looking for answers when I get stuck. Aug 06 14:07:20 I felt like I was banging my head against a wall, because everything I tried kept coming around the the same point. A dead end. Now I think I understand why, most likely becaue the default universal cape is enabled. Aug 06 14:08:36 so, to clarify: cape-universal enables a whole bunch of peripherals by default and includes a way to change pinmux at runtime Aug 06 14:09:01 but as a result it effectively claims all pins and is incompatible with basically every overlay Aug 06 14:09:46 (it also enables a whole bunch of peripherals while they're unused, effectively just disconnecting them from any physical pins while the peripheral remains operational) Aug 06 14:09:54 actually when I cat the slots file /sys/devices/platform/bon_capemgr/slots slot for says 4: P-O-L- 0 OVerride Board Name,00A0,OVerride Manuf,univ_emmc Aug 06 14:10:52 yeah that's cape-universal Aug 06 14:11:06 specifically the variant that doesn't claim the emmc pins (obviously) Aug 06 14:11:46 for something named "universal" there are actually lots of variants of it that occupy different subsets to avoid conflicting with this or that :P Aug 06 14:11:48 slots 0-3 show PF---- -1 so once I disable cape universal, can I use one of the other slots or are those alays set like that? Aug 06 14:12:26 generally speaking, attempting to remove an overlay is rather hazardous, especially when it's as invasive as cape-universal Aug 06 14:12:32 better to prevent it from loading in the first place Aug 06 14:12:52 Okay, I can prevent it from loading in the uEnv.txt file? Aug 06 14:13:45 yeah iirc there's a cmdline option there that enables it Aug 06 14:14:06 this one? cmdline=coherent_pool=1M quiet cape_universal=enable Aug 06 14:14:18 yep, ditch the cape_universal=enable Aug 06 14:15:08 not going to effect the eMMC boot process correct? Aug 06 14:15:47 ASking because I already had an adventure with the uEnv.txt file... Aug 06 14:17:33 hehe Aug 06 14:17:51 no it wo'nt Aug 06 14:18:32 Yeah I was following someones sed command, and it ended up overriding the entire file (maybe my own fault). so when I rebooted, I got heartbeat, and nothing else! Aug 06 14:19:22 had to get a microsd card to fix it... Lesson learned! Have a microSD flasher card ready in waiting. Aug 06 14:20:03 0-1 PF---- -1! Aug 06 14:20:07 alright! Aug 06 14:22:34 actually you can fairly easily recover a BBB via USB but I'll leave that chapter for another time Aug 06 14:23:07 do get a serial console cable if you don't already have one... it'll almost certainly save your ass one day Aug 06 14:23:29 Yes, bus pirate? Aug 06 14:23:46 Was considering that for a myraid of reasons. Aug 06 14:24:10 or even a generic CP2102 module for $1 off ebay Aug 06 14:24:11 I've only used the standard ftdi cable, but any 3.3V serial cable should work Aug 06 14:25:22 some 5V cables seem to work unreliable. while the console header on the BBB is, unusually, 5V tolerant, I guess a 5V cable may not be satisfied with the 3.3V signal coming from the BBB Aug 06 14:26:09 that would make sense, if they the VHI is too high. Aug 06 14:26:37 Got a link on using configfs to configure the pinmux? Aug 06 14:27:08 my google foo seems to be weak at the moment, finding a lot on USB not so much on other peripherals. Aug 06 14:29:21 found it. Aug 06 14:34:32 it's just a different way of loading overlays Aug 06 14:34:46 the overlays themselves are essentially the same as via bone_capemgr Aug 06 16:14:54 Hi Aug 06 16:15:18 I have a problem with analogWrite function in my beaglebone black Aug 06 16:15:49 /var/lib/cloud9/pid_first.js:36 b.analogWrite('P9_14', out_sat, 2000.0); ^ TypeError: Object 1 has no method 'analogWrite' at calc (/var/lib/cloud9/pid_first.js:36:3) at exports.readAIN.readFile (/usr/local/lib/node_modules/bonescript/src/hw_capemgr.js:346:13) at fs.readFile (fs.js:273:14) at Object.oncomplete (fs.js:108:15) Aug 06 17:55:55 YEAY I got my first overlay to load!!!!! WOOT WOOT!!!! Aug 06 18:29:18 cdwBeableNewbie: congratulations! 'Tis not the most obvious process but it's a total gateway drug! Aug 06 19:41:23 there should really just be a good UI to configure the hardware to your liking and generate a (main) DT from that Aug 06 19:41:40 that is a neat idea Aug 07 02:58:21 zmatt werent you thinking about working on that ui **** ENDING LOGGING AT Sun Aug 07 02:59:57 2016