**** BEGIN LOGGING AT Fri Dec 04 03:00:42 2015 Dec 04 03:01:40 I'd expect the channel will also begin to leak in off-state if you bias things too far? Dec 04 03:02:13 dunno, I'm not *that* deeply into CMOS Dec 04 03:02:42 I just read a bit about back-bias to have some idea of what on earth they were talking about when I encountered its config registers Dec 04 03:03:12 talk about the use of 'magic' LOL Dec 04 03:04:41 but yeah, lol digital my ass... there are only analog circuits, and a big division between people trying to make them as linear as possible and people trying to make them as non-linear as possible ;) Dec 04 03:05:35 although the latter also isn't quite true anymore for high-speed external interfaces (see e.g. slew rate control) Dec 04 03:08:17 well considering all the parasitic circuits in modern IC's it is good that there is some 'stuff' being worked on in that regard. Slew rate control is one way to extend I2C bus. Instead of the RC circuit of the capacitance of the line you have a constant current source as the pullup. It cleans up long lines nicely. I suspect one would do the same thing for high speed circuits. At least until you hit the 'capacitance' Dec 04 03:08:17 charging wall anyhow. Dec 04 03:08:51 I think slew rate control is mostly done for EMI reduction Dec 04 03:11:09 (I was delighted to see the diagram in this section btw -> https://en.wikipedia.org/wiki/USB#Signaling ... I wish signal diagrams were drawn like that more often) Dec 04 03:12:44 I wonder how it was made, since there's even a little dimple on the D- line when the D+ line makes its final transition Dec 04 03:30:03 It appears to be an SVG so likely they used an open source tool to make it. I am dubious about using liberoffice draw. However if you export data from calc into draw after getting a set of sampled points that would work. then use draw to add other useful information. Dec 04 03:30:54 Sleep time... maybe I'll get something done tomorrow. I work too much dang it. Dec 04 03:31:00 yeah I meant more like whether it was captured or simulated Dec 04 03:31:36 Good question... I think the author is attached to the diagram Dec 04 03:32:10 well it has a name and a link :D Dec 04 03:33:00 I was wondering how exactly the author him/herself would be attached to a diagram Dec 04 03:33:03 ;) Dec 04 03:34:09 (sigh) well this reminds me of jokes in KiCAD about "atomic" value ... that actually got a lot of mileage :D **** BEGIN LOGGING AT Fri Dec 04 12:26:18 2015 Dec 04 12:39:49 vermit: and what is official chanel now? Dec 04 13:02:18 gonda .. this is as close as it gets, excepting the TI E2E forums for the chip Dec 04 13:03:18 That said, we got jkridner sat up there .. :) Dec 04 13:05:23 guess it could be better staffed than just me. :-) Dec 04 13:05:41 jkridner: what, the E2E forum? Dec 04 13:06:06 I mean here.... this *is* the "official" support channel, backed up by the mailing list. Dec 04 13:06:37 Always hard to get support organisations up properly. Dec 04 13:06:50 E2E is for escalating silicon-related issues. if they don't get answered there, then ping me personally. Dec 04 13:07:08 I'm trying to test a kernel I recompiled with some additional modules for a BBW running Debian Squeeze. When I dpkg -i the .deb, I get an error about "trying to overwrite '/boot/uImage'" (pastebin.com/5LFcvcre). Any idea what I'm doing wrong? It's likely something simple as I'm new at this... Dec 04 13:07:16 I usually view it the other way around. Hard technical questions are better answered on the mailing list, which is searchable. Plus, nobody expects an anser immediately on the mailing list. Dec 04 13:09:13 so, support path goes: http://beagleboard.org/chat (here) --> http://beagleboard.org/discuss --> e2e or RMA, depending.... or to the particular open source project. Dec 04 13:09:58 wmat: I expect people to come here to try to figure out how to ask a better question on the mailing list. Dec 04 13:10:06 true enough Dec 04 13:10:28 jkridner .. the clarification is most helpful :) Dec 04 13:11:03 Those here that are able, are mostly willing, I think ... lol Dec 04 13:11:38 I confess that I've never done the mailing list thing .. that's a bit "old tech" for me .. Dec 04 13:11:55 (even though I grew up through the age of BBS's and 2400 baud modems!) Dec 04 13:12:17 i hear that same argument about IRC all the time Dec 04 13:17:15 clearly we need a phorum Dec 04 13:17:39 then we could sell ads on it and get $$$ Dec 04 13:26:32 av500: pipe down Dec 04 13:27:15 ? Dec 04 14:22:00 av500: I'm not a fan of forums Dec 04 14:24:55 wmat: not surprised :) Dec 04 14:41:06 av500, there are forums. Although I hate the google platform Dec 04 14:41:14 personal thing :) Dec 04 14:43:00 stt_michael: google has phorums? Dec 04 14:43:04 you mean groups? Dec 04 14:44:19 groups.. its a mangling of the term, yes Dec 04 14:44:36 luckily groups has a mailing list interface Dec 04 14:44:56 tbr, .. oh you antiquated lot :P lol Dec 04 14:45:25 why is so much code-related stuff still mailing-list oriented Dec 04 14:45:53 because it just works and doesn't need to be reinvented Dec 04 14:46:11 its a really crap interface unless there's a crawler which posts it to the web Dec 04 14:46:37 not that I can name any better .. but I've long lamented the very patchy documentation for the beagles Dec 04 14:47:17 stt_michael: groups is not a phorum Dec 04 14:47:26 since it can send/receive mail Dec 04 14:47:30 stt_michael: there are many very good books on the beagle platform, mostly BBB Dec 04 14:47:37 phorums explicitly dont want email interaction Dec 04 14:49:28 av500, of this I'm aware Dec 04 14:49:54 and yes, books are great .. but people digest information in very different ways in the 21st century. Dec 04 14:50:04 the younger generations particularly are very 'immediate' Dec 04 14:50:37 well, good documentation is a difficult thing to produce Dec 04 14:50:45 wmat, agreed Dec 04 14:51:03 and with the pace of updates to kernel and beagle codes/disto's its an onerous job too Dec 04 14:51:15 we need good Tools. Dec 04 14:51:37 elinux should work better ... Wiki's are quite good Dec 04 14:52:02 maybe a Beagleboard wiki ? or .. updating/opening up the existing one *goes to refresh himself* Dec 04 14:52:22 uh, the BeagleBoard wiki is elinux Dec 04 14:52:53 wmat: no, no, needs to be from scratch and will be _better_ *nod* *nod* trust me! Dec 04 14:53:09 heh Dec 04 14:53:14 .. oo this is cool .. http://beagleboard.org/project/3dhubsbeagleboard/ Dec 04 14:53:34 wmat, I see .. thought it covered ARM in more general .. or did it .. Dec 04 14:53:56 teh funny thing is, I have several vendors asking me to write documentation on elinux, but nobody wants to pay me to do it Dec 04 14:55:12 too many ppl think that since it's open source, it should be free ... Dec 04 14:55:45 yep Dec 04 14:56:29 there is an easy confusion over open source being free Dec 04 14:56:38 it is .. but its not Dec 04 14:56:56 like firmware blobs .. bein "open" .. they are available .. but some poor bugger had to write them once Dec 04 14:57:03 usually broadcom or realtek / etc. Dec 04 14:57:13 i wish i could rent/buy an open source house :p Dec 04 14:57:14 amd / ati and others Dec 04 14:57:22 nobe, wouldn't it be awesome? Dec 04 14:57:41 you can nearly do 'open source' electric Dec 04 14:58:03 open source wood fire works :D lol Dec 04 14:58:13 there's heat and cooking ! Dec 04 14:58:54 well i meant that's why i reply to those guys to make them understand even developpers need to earn some money Dec 04 14:59:40 Quick question, anyone know how to extract ram load address from the MLO? (using angstrom if it makes a difference) Dec 04 15:11:02 MipMip: hexdump? Dec 04 15:17:46 what's the format of the MLO file? is it documented anywhere? Dec 04 15:20:53 it's a binary file Dec 04 15:21:05 a bin Dec 04 15:21:26 it's basically x-loader Dec 04 15:22:35 it's a stripped down u-boot Dec 04 15:24:32 sometimes Dec 04 15:25:03 hmm, at what offset is the ram load address for the u-boot SBL? Dec 04 15:25:23 (in the MLO file) Dec 04 15:26:54 i'm having some trouble getting the BBB to break at my breakpoints while JTAGing Dec 04 18:20:50 hrm. u-boot upstream fails to build for beagle-x15 ... Dec 04 18:27:38 Hello, I have a particular temperature/humidity sensor that uses I2C, I know it is working just fine because it is working in some other devices i use it with. When I plug it into the BBB, within 6 seconds, I get a bunch of errors about "mmcblk0: error -110 sending status command, retrying", "end_request: I/O error, dev mmcblk0, sector 1720745", etc. In some cases, it locks up the BBB completely. My other I2C devices Dec 04 18:27:38 work on the BBB - it's just this particular device. How can I go about finding out the cause of this problem. Dec 04 18:29:22 <[Butch]> Quick question: Anybody know where I can get python > 2.7.9? Dec 04 18:32:19 Butch - http://www.python.org/ Dec 04 18:32:41 <[Butch]> clockman: I was hoping to not have to compile from source. Dec 04 18:33:09 what distro are you using? Dec 04 18:33:34 <[Butch]> clockman: Debian Dec 04 18:33:59 <[Butch]> clockman: Jessie Dec 04 18:34:03 [Butch]: install python3? Dec 04 18:34:37 <[Butch]> vagrantc: I’m actually trying to get powerline to work, and I think it wants 2.7.10+ Dec 04 18:34:52 <[Butch]> But perhaps I’m full of horse hockey. Dec 04 18:35:19 it doesn't look like python 2.x versions are getting updated in debian, as there's a push to migrate to python 3.x Dec 04 18:36:00 <[Butch]> Installing pyton3. Dec 04 18:36:02 <[Butch]> python3 Dec 04 18:36:05 <[Butch]> Typing is hard Dec 04 18:36:05 so it's pretty much use python 3, or compile python 2 from source Dec 04 18:37:35 debian stretch might have 2.7.10 Dec 04 18:37:45 <[Butch]> This is what happens when you try to turn your BBB into an actual development environment. :-) Dec 04 18:38:17 ah, no it doesn't Dec 04 18:39:18 <[Butch]> tbr: Thanks for checking! Dec 04 18:39:47 * tbr was misled by his laptop showing: ii libpython2.7:amd64 2.7.10-3 Dec 04 18:39:57 python itself is 2.7.9 Dec 04 18:40:36 that's what i meant when i said it wasn't getting updated :) Dec 04 18:41:12 <[Butch]> :-) Dec 04 18:41:21 <[Butch]> Gotta keep those windows straight. :-) Dec 04 18:41:42 <[Butch]> python3 did not fix the problem. Dec 04 18:42:01 <[Butch]> Well, I haven’t found the right incantation to make python3 solve the problem. Let’s put it that way. Dec 04 18:46:01 vagrantc, mainline u-boot also needs the memory changes from ti's branch.. Dec 04 18:46:19 (memtest will fail on someboards..) Dec 04 18:47:22 vagrantc, here's the current working tree: http://git.ti.com/gitweb/?p=ti-u-boot/ti-u-boot.git;a=shortlog;h=refs/heads/ti-u-boot-2015.07 Dec 04 18:48:33 hrm. forward-porting that might be fun... Dec 04 18:57:53 <[Butch]> Success! It had nothing to do with python directly. Apparently the version of vim installed in Jessie is not compiled with python support. If one installs vim-nox (or one of the other actual packages that backs vim-python), one gets python support and things start working. Dec 04 19:11:12 vagrantc, just concentrate on the iostate/pinmux and memory related stuff.. Dec 04 19:20:41 [Butch], i never use vim, can you sumarize the problem/solution for, then i'll push it as default.. Dec 04 19:21:44 rcn-ee: if you're shipping with vim-tiny, then that's the same as default debian does. it's a bit "special" and most sane people immediately install vim proper and maybe also exuberant-ctags. Dec 04 19:22:02 <[Butch]> Vim has a status line that shows what’s going on when you’re editiing. There are a bunch of ways to format the status line. One of those ways is using a module called “powerline,” which allows you to use “fancy” characters (unicode) in your status line, and colors, and other stuff. Dec 04 19:22:30 in the jessie/lxqt image i just have "vim"... Dec 04 19:22:33 <[Butch]> The powerline module requires python support to be built in to vim at compile time. The stock vim that came with Jessie didn’t have it. Dec 04 19:23:14 [Butch]: I'd expect the same on a vanilla debian install anywhere else, jftr. Dec 04 19:23:22 <[Butch]> However, if you try to install vim-python (which has python support), you find that it’s a virtual package that links to four other ones, one of which is vim-nox. vim-nox has scripting support (Tcl), which I don’t care about, but I do care about the vim executable having python support built in. Dec 04 19:23:28 <[Butch]> Once I installed it, much happiness. Dec 04 19:23:56 so we need vim-python & vim-nox added by default.; ) Dec 04 19:24:05 <[Butch]> tbr: I’m not sure about that — the Intertubez seemed to lead me to believe that some debians had it. Dec 04 19:24:21 <[Butch]> rcn-ee: vim-python isn’t a real package, so you can just skip it. Dec 04 19:25:03 my laptop has both: ii vim-tiny 2:7.4.826-1 and ii vim 2:7.4.826-1 Dec 04 19:25:14 because I installed vim right away Dec 04 19:25:39 <[Butch]> tbr: if you type vim —version, does it have python support (+python or +python3) Dec 04 19:27:58 [Butch]: /usr/bin/vim has +python -python3; while /usr/bin/vim.tiny has -python -python3 Dec 04 19:28:29 <[Butch]> tbr: So there’s a case where the stock vim has python 2.7 support. I assume that’s a debian distro. Dec 04 19:28:32 I find it reasonable to ship with a minimalistic vim (in earlier releases it was actual vi or something close to it) Dec 04 19:29:05 [Butch]: we're talking about jessie, all the time Dec 04 19:29:14 <[Butch]> tbr: Just making sure. Dec 04 19:29:52 <[Butch]> So, to reiterate, the Jessie distro that tbr is looking at on his laptop has a stock vim with python 2.7 support, while the vim on the BBB Jessie has a stock vim without it. Dec 04 19:30:04 <[Butch]> Now my head hurts even more than it did before. :-) Dec 04 19:30:39 and vim-nox enables: +python (but not -python3) (on my bbb with jessie) Dec 04 19:30:48 [Butch]: to reiterate, I installed the package "vim" manually. A default debian install will only ship with the "vim-tiny" package. Dec 04 19:31:10 so: nothing to see here, move along, everything is fine Dec 04 19:32:19 <[Butch]> tbr: Well, except that your vim package that you installed had support, and the vim package that came on the BBB (or that I installed, I don’t remember) didn't. Dec 04 19:32:24 vim-nox is probably the same as vim but without gvim Dec 04 19:32:58 well, vim-nox Provides: vim-python, and vim doesn't. Dec 04 19:33:08 <[Butch]> But installing vim-nox (or vim-gtk or vim-gnome or vim-athena) gets you python support. Dec 04 19:33:42 <[Butch]> There is a bit of a disparity here between what’s on the BBB and what tbr is looking at on his laptop. Dec 04 19:33:51 no there isn't Dec 04 19:35:04 if I log onto my BBB vim will also have +python, because the first thing that I did was to install "vim exuberant-ctags rsync mc" (and probably one or two other packages), just like on any debian installation that I do. Dec 04 19:36:15 <[Butch]> But the vim package on BBB doesn’t have python support. Dec 04 19:36:32 <[Butch]> You have to get it from one of the other ones above. Dec 04 19:37:08 ok, now we're getting somewhere Dec 04 19:37:14 that's a debian bug Dec 04 19:37:41 file a bug against debian that the arm package of vim doesn't have +python like on x86_64 Dec 04 19:38:14 (I'd recommend to check for previous bugs and or comments before doing so) Dec 04 19:38:51 <[Butch]> OK, so I sorted this out. The default vim on BBB is vim.basic, which does not have python support. Dec 04 19:39:01 <[Butch]> There is also vim.tiny, which you saw. Dec 04 19:39:23 <[Butch]> Then, once you install some other vim package, like vim.nox, it changes the vim link to point to that, giving you python support. Dec 04 19:40:16 <[Butch]> This is a pretty deep rabbit hole. Are we sure we want to continue down it? :-) Dec 04 19:41:51 fix pushed... for the next weekend image: https://github.com/RobertCNelson/omap-image-builder/commit/f349a6a408a4815cc5efd0c38f9683e42170bdd4 Dec 04 19:43:02 <[Butch]> rcn-ee: :-) Dec 04 19:43:37 <[Butch]> I’m sure that there will be some gotcha hiding that including that package will uncover. Dec 04 19:44:07 <[Butch]> Thank you for adding it! Dec 04 19:44:19 nah it'll be fine, it's with all the other python packages that make things a pain for debootstrap. ;) Dec 04 19:44:53 <[Butch]> Now when I have to rebuld this thing in a year, I won’t run into the old “Damn, I forgot how I solved this problem.” problem. :-) Dec 04 19:45:31 Just add it to your new install "prep script". ;) Dec 04 19:48:30 <[Butch]> If only I had one of those . . . Dec 04 19:52:59 i do... it's a little crazy.. but on a fresh debian install, mount flash drive, run script... everything is "default" ssh/etc.. Dec 04 19:53:36 <[Butch]> rcn-ee: No, it’s a great idea. I just haven’t gotten around to it. Dec 04 19:54:44 Hi guys where can I find these Kernel headers -> 3.8.13-bone78 Dec 04 19:54:46 ? Dec 04 19:54:46 it makes things nice when hardware fails, as everything i have is in git/nfs/etc.. Dec 04 19:55:15 cart_man, sudo apt-get install linux-headers-3.8.13-bone78 Dec 04 19:56:38 rcn-ee: Unable to locate pakcage linux-headers-3.8.13-bone78 : ( Dec 04 19:56:59 cart_man, cat /etc/dogtag ? Dec 04 19:57:22 BeagleBoard.org BeagleBone Debian Image 2014-04-23 Dec 04 19:57:26 rcn-ee: ^^ Dec 04 19:58:31 cart_man, feel free to upgrade at any time: http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#2015-11-03 Dec 04 19:58:52 (like now if you want the headers. ;) ) Dec 04 20:04:28 rcn-ee: Ok but how do I go about not upgrading just getting the headers.. I have a system that is hanging by a thread that I got working a couple of hours ago.. if I mess something up now I have to start over and I would rather quit my job Dec 04 20:05:26 cart_man, http://repos.rcn-ee.com/debian/pool/main/l/linux-upstream/ Dec 04 20:10:26 rcn-ee: Ok and I install this package with dkpg right? Dec 04 20:10:33 what is the flag I use again? Dec 04 20:13:32 rcn-ee: Got it :) Dec 04 20:14:33 how to find which files are being shared by samba Dec 04 20:15:31 rcn-ee: You do not happen to know if there is a prebuilt driver for my OS and the rtl8192cu WiFi chip? Dec 04 20:17:12 well if you aren't using hdmi, disable that asap, then the crappy rtl8192cu will magicly work.. Dec 04 20:17:18 or use v4.1.x Dec 04 21:09:23 hi Dec 04 21:10:49 how can I apply a digitalread pin value to a variable Dec 04 21:13:09 hello? Dec 04 21:13:16 can anyone helpme? Dec 04 21:17:41 rcn-ee: Thanks allot :)! Dec 04 21:18:19 cart_man, did you disable hdmi? isn't that weird. ;) Dec 04 21:18:54 rcn-ee: Hmm no I did not.. I know that there is some noise issues but I think I will be ok...or is it very bad? Dec 04 21:19:43 Hey I have a question. I'm trying to read a pin status on the beaglebone black and assign the value to a variable. Do anyone know how can this be done using node.js? Dec 04 21:19:51 yeah, when the hdmi is enabled, that connector messes up every wifi device... Dec 04 21:20:22 helpme14, there's bonescript examples (based on nodejs) taht do that already Dec 04 21:22:10 I tried using the digitalRead example and it shows me my value which is great but when I try to assign that value to a variable I get the error message "TypeError: Cannot read property 'toString' of undefined" Dec 04 21:22:39 I'm not sure what I am doing wrong. Dec 04 21:27:51 rcn-ee: Well that is not cool though... how do I disabled it? Dec 04 21:30:10 cart_man, add "capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN" to your bootargs.. Dec 04 22:05:08 rcn-ee: Hey do you know if there is a way to TAR/ZIP a file so that it keeps all of its symbolic links and all other custom properties it might have? Dec 04 22:06:19 --dereference ? Dec 04 22:07:13 rcn-ee: Well I am not sure what it is called Dec 04 22:07:59 man tar shows that... Dec 04 22:30:18 for reference http://linux.die.net/man/1/tar Dec 04 22:30:26 Greetings people. Dec 04 22:35:53 rsync -a Dec 04 22:36:02 but check the man page Dec 04 22:36:14 oh wait lol Dec 04 22:36:52 what I was roughly aiming for was 'archive mode' Dec 04 22:37:13 which usually includes a few things inc. dereference .. but you don't want it to 'traverse' links Dec 05 00:18:19 ah to those zmatt, jkridner with Mime-type issues .. this was the one I've seen for many binary files .. application/octet-stream Dec 05 01:27:52 does the bbb dram interface have to be initialized (e.g., by some part of the uboot or linux kernel startup) before accessing it? Dec 05 01:28:08 yes Dec 05 01:28:19 it's normally done by u-boot Dec 05 01:29:06 zmatt: have you ever done it in assembly? I want to extend the led tester to run a few simples DRAM tests. Dec 05 01:29:19 s/simples/simple/ Dec 05 01:30:03 it basically just involves writing the right config constants to some registers Dec 05 01:31:31 ok, i guess the easiest path is to check that area of uboot source ? Dec 05 01:31:51 or i could just read the trm. Dec 05 01:32:03 not sure if I'd call that easy since it's kind of annoying to track down the ingredients scattered across multiple files, but yeah Dec 05 01:32:50 yeah, that's a good caveat... Dec 05 01:33:01 the TRM is of limited use, especially since the timing values you need to configure are actually board-dependent (although ddr3-800 is slow enough that you still have significant Dec 05 01:33:06 margin for error) Dec 05 01:33:21 is ddr-800 what's on the bbb? Dec 05 01:33:25 ddr3-800? Dec 05 01:33:36 it's the max it officially supports yes Dec 05 01:33:46 the ram chip itself is capable of much higher speeds Dec 05 01:34:12 basically you can't actually buy "ddr3-800" ram anymore, it's always a higher speedbin Dec 05 01:34:50 (it's also the lowest speedbin definded by JEDEC) Dec 05 01:34:57 *defined Dec 05 01:35:51 zmatt: is the emif used for dram? Dec 05 01:35:56 correct Dec 05 01:36:22 i've used that block of ip on the ti 64x, so somewhat familair Dec 05 01:36:31 hmmm probably not Dec 05 01:36:38 that was EMIFA I think Dec 05 01:36:39 not EMIF4D Dec 05 01:37:04 actually it was emif4d-revc-3.229-21-oct-2008 Dec 05 01:37:07 I still need to finish my own ddr init code in my baremetal codebase Dec 05 01:37:07 :) Dec 05 01:37:09 oh ok Dec 05 01:37:16 no, just joking. Dec 05 01:37:21 aha. Dec 05 01:37:26 I was already wtfing Dec 05 01:37:29 :P Dec 05 01:37:58 basically in baremetal code I normally never need the external ram since there's no much internal sram already Dec 05 01:38:05 still, i BET there are some residual similarities. Dec 05 01:39:12 veremit: btw, for future reference, tar by default seems to preserve most things, though you still need to pass --xattrs to preserve those also Dec 05 01:39:28 I think 'rsync -a' also needs an additional flag for those Dec 05 01:40:08 zmatt.. yes I recall tar being quite tolerant Dec 05 01:40:29 actually scrap that, even with --xattrs tar doesn't work right Dec 05 01:40:33 rsync -aX does seem to Dec 05 01:40:50 I do rsync OS images frequently with good success .. as long as you miss out /dev /sys /proc Dec 05 01:41:09 a good test target is /bin/ping which on modern debian uses file caps instead of setuid Dec 05 01:41:10 usually -avz out of habit Dec 05 01:41:22 oo Dec 05 01:41:38 # getcap /bin/ping Dec 05 01:41:38 /bin/ping = cap_net_raw+ep Dec 05 01:41:42 zmatt: is it necessary to perform the h/w leveling (not even sure what that entails, but i see it in the trm) before accessing dram? that is, aren't the default parameters "gracious" enough to allow the timing to work out-of-the-box? Dec 05 01:41:55 yates: h/w level is broken and not supported :) Dec 05 01:41:58 leveling Dec 05 01:42:30 ah, i see tha tnow. so same question for s/w leveling. Dec 05 01:43:06 in my experience you can get away with wildly wrong leveling in practice Dec 05 01:43:26 at these low speeds Dec 05 01:43:49 good to know, thanks. we also took a good amount of care to keep the ram close to the cpu and ensure all lines are teh same length. Dec 05 01:44:06 I'm looking at my ram init code from a previous board (dm814x-based) Dec 05 01:44:20 it's really negligble amount of code really Dec 05 01:44:39 and this actually had two EMIFs under the umbrella of a DMM that needed to be initialized Dec 05 01:47:57 i see Dec 05 01:48:55 still some 70+ pages to the emif in the trm... whew! Dec 05 01:49:10 probably don't need to read everything, though. Dec 05 01:49:41 is spruh73l the latest version of the trm? Dec 05 01:49:53 SPRUH73L Dec 05 01:50:08 or the version you're using, zmatt Dec 05 01:50:09 ? Dec 05 01:50:26 yates: http://pastebin.com/UU2RpLkV <- this is what I had scraped together from u-boot a while ago Dec 05 01:50:53 that's the latest version yes Dec 05 01:51:51 ack Dec 05 01:53:34 so it's: config PLL, write leveling data to phy, configure phy io drivers (via control module), release CKE control, after that things get a bit vague since I haven't checked yet what the last three calls do exactly in which order Dec 05 01:53:51 they still need to enable and calibrate the VTP macros somewhere, probably in config_ddr_phy Dec 05 01:54:41 then write config values to a few relevant EMIF regs, but make sure sdram_config is written last (that's probably done by config_sdram() then) Dec 05 01:54:56 *VTP macro, sorry Dec 05 01:55:34 voltage, temperature, and process Dec 05 01:56:06 yeah that, thingy that uses the external precision resistor to calibrate driver current Dec 05 01:56:15 does the vtp store settings non-volatilely? Dec 05 01:56:19 no Dec 05 01:56:36 oh, you just have to initialize from the code? Dec 05 01:56:56 you just enable it wait for it to say "OK, calibration done" Dec 05 01:57:28 it periodically auto-recalibrates when needed to compensate for temperature changes Dec 05 01:57:30 are the leveling parameters stored non-volatily on-chip? Dec 05 01:57:34 noe Dec 05 01:57:35 nope Dec 05 01:57:51 i was under the impression there were some ddram parameters that were stored in on-chip flash. not true? Dec 05 01:58:06 there's no on-chip flash Dec 05 01:58:08 none Dec 05 01:58:29 well, some sort of non-volatile memory. Dec 05 01:58:38 earom, eeprom, etc. Dec 05 01:59:01 there is nothing like that/ Dec 05 01:59:03 ? Dec 05 01:59:05 the only on-chip non-volatile memory is eFUSE, and it's only factory-programmed Dec 05 01:59:15 i see. Dec 05 01:59:45 (it does have a "customer eFUSE" feature, but you'd need to be a really big customer to get those... it's disabled in off-the-shelf AM335x parts) Dec 05 02:00:03 no, i meant something associated with the dram controller(s) Dec 05 02:00:14 nothing non-volatile Dec 05 02:00:24 right. i was confyoosed. Dec 05 02:00:36 eschew obfuscation. Dec 05 02:00:43 the RAM config parameters are also volatile, and automatically programmed by EMIF when you write to the sdram_config register Dec 05 02:01:50 note btw that the phy registers have accidently been made write-only on the am335x (erratum), so you can't read them back to check what you've written Dec 05 02:02:34 you mean registers associated with the ethernet i/f? Dec 05 02:02:44 no, ddr phy Dec 05 02:02:54 0x44e12000 Dec 05 02:03:19 leveling data Dec 05 02:03:20 and such Dec 05 02:03:32 oh, well that's nice... Dec 05 02:03:39 is the sram write-only too? Dec 05 02:03:41 :) Dec 05 02:03:49 hehe Dec 05 02:04:19 some vendors used to jokingly include "write-only memory" in their catalog Dec 05 02:05:17 National had some "UFART" chips in the catalogues back in the 80s: "Universal Fully Asynchronous Receiver/Transmitter" Dec 05 02:05:28 but seriously, the am335x looks like it was done by an intern or something Dec 05 02:05:43 ouch. Dec 05 02:06:00 are you using a debugger? which one and what software? Dec 05 02:06:03 ccs? Dec 05 02:06:34 i had suggested the segger j-link Dec 05 02:06:41 but we haven't purchased one yet. Dec 05 02:07:03 note that ccs isn't free unless you use it with the xds100v2 Dec 05 02:07:19 that may be a thing to keep into mind Dec 05 02:08:28 i bought a version of it (5.1?) about 2-3 years back. i don't know how the licensing works anymore, i thought it was perpetual, and even if it is, i don't remember if it includes the Cortex A8 Dec 05 02:08:34 and yeah I use ccs... though it sucksm, so I use only it if I can't debug an issue by trial&error and some debug prints, lol Dec 05 02:08:51 i'm with you there, re: debug prints. Dec 05 02:08:51 ah if you bought it already then nm Dec 05 02:09:07 openocd sucks also, but different Dec 05 02:09:20 oh really? i heard a lot of good about that, indirectly Dec 05 02:09:29 openocd/eclipse? Dec 05 02:09:54 dunno about the eclipse part, that's another monstrosity I usually prefer to avoid (note that CCS is also eclipse-based) Dec 05 02:09:55 segger jlink has gdbserver. i think that's good lol. Dec 05 02:11:19 i'm with you on eclipse - i didn't buy into it. but emacs+gnumake doesn't get you debugging... gotta use something. Dec 05 02:11:37 otherwise i'd totally toss all the ide bs Dec 05 02:12:03 but openocd can't really handle ARMv7 targets well, especially not during init / early boot or suspend/resume situations (probably the most common times to need JTAG) since it doesn't properly handle WAIT responses which you inevitable get if some PLL is still (or again) unlocked and part of the chip becomes slow to respond Dec 05 02:12:33 so then you're forced to configure some insanely slow interface speed like 1 kHz to hope to avoid WAIT responses Dec 05 02:13:04 maybe we shoudl keep our fingers crossed stuff will work without having to require a debugger... Dec 05 02:14:21 so, you guys did a custom board design... how'd you deal with the ddr3 part? did you have prior experience with something like that, or copied that part of the pcb layout unmodified from the bbb? Dec 05 02:15:08 copied from bbb verbatime Dec 05 02:15:17 that part Dec 05 02:15:29 hehe, ok Dec 05 02:15:47 since, well, ever read the ddr3 design rules in the am335x datasheet? Dec 05 02:16:11 verbatim is probably overstated. we didn't use the exact same traces. Dec 05 02:16:20 no... Dec 05 02:16:35 i didn't do the hw design, though Dec 05 02:19:05 you didn't use the exact same traces... then we're back with, have you guys ever done something with ddr3 before? Dec 05 02:19:26 I hope whoeever did the hw design *did* read the part of the datasheet :P Dec 05 02:20:09 (section 7.7.2.3 of sprs717g) Dec 05 02:20:11 i think the layout guys that we used have. not positive, though Dec 05 02:21:27 they spend 20 pages on explanining how to do the pcb layout for it Dec 05 02:22:30 good points. i'll ask our hw guys / layout guy. Dec 05 02:26:00 well, let's just hope they have, presumably one does not undertake something this ambitious without some serious reading up Dec 05 02:26:09 anyhow Dec 05 02:26:41 it also just occurred to me: CCS typically includes some GEL files containing scripts that initialize the memory controller Dec 05 02:27:05 even without jtag you can use those since GEL is more or less C-ish Dec 05 02:27:24 it'll probably have leveling values for the am335x-evm, but care Dec 05 02:29:01 is the cost of my time writing this test less than the ~$600 for the debugger?!? Dec 05 02:29:33 https://www.digikey.com/product-detail/en/TMDSEMU100V2U-20T/296-31067-ND/2261950 Dec 05 02:29:57 with that and the gel file, it would be something like "fill 0x20000000 0x10000000 /verify" Dec 05 02:30:20 the base address of ram is 0x80000000 Dec 05 02:30:31 that's why i said "something like" Dec 05 02:30:34 hehe Dec 05 02:30:53 I'd personally use a little test program instead Dec 05 02:31:01 it'll be a _lot_ faster than doing the writes via JTAG Dec 05 02:31:18 and you can use a simple PRNG as test pattern instead of filling a fixed pattern Dec 05 02:31:26 a fixed pattern can miss many memory problems Dec 05 02:32:05 true. Dec 05 02:32:19 e.g. writing a value and then reading it back will even work if the RAM is entirely non-operational since the value will be held capacitively on the data lines Dec 05 02:32:23 *may work Dec 05 02:32:42 that's a stretch.. Dec 05 02:32:48 nope, happened to me Dec 05 02:33:00 no shit? Dec 05 02:33:22 you mean if you write a fixed pattern? Dec 05 02:33:22 it was the first little test of external RAM, and it seemed encouraging Dec 05 02:33:30 haha . Dec 05 02:33:34 foolish you. Dec 05 02:33:35 I just wrote some value and read it back again Dec 05 02:33:42 different values too Dec 05 02:34:05 but just write followed by read Dec 05 02:34:06 wait, different values? so how does a PRNG fix that? Dec 05 02:34:16 because you first fill all of ram Dec 05 02:34:20 then reinit the prng Dec 05 02:34:25 right right. Dec 05 02:34:25 then verify all of ram Dec 05 02:34:32 the prng is like a memory, in a sense. Dec 05 02:34:41 yeah, it's a really big test pattern Dec 05 02:35:10 note btw that the board I just mentioned turned out to have "RAS" and "CAS" swapped in the schematic by accident Dec 05 02:35:19 i used a simple one for sending test data on ericsson's first gsm/edge board on the ti 55x Dec 05 02:35:20 so rest assured, the memory really didn't work Dec 05 02:35:45 prng, that is. Dec 05 02:36:25 that is a very informative experience, thanks for sharing it. this is all goign in my files. Dec 05 02:37:57 in your opinion, would a week be a reasonable amount of time to get this ddr3 test code running? Dec 05 02:38:48 by the way, did i tell you the led test is working? Dec 05 02:38:53 thanks for that, man Dec 05 02:38:59 if you can init DDR from CCS then the memory test loop itself is like 10 lines of code, why'd you need a week for that? :P Dec 05 02:39:02 np Dec 05 02:39:06 and good to hear Dec 05 02:39:31 did you click the digikey link btw? Dec 05 02:39:34 yes Dec 05 02:39:43 $82.30 Dec 05 02:39:48 that. :) Dec 05 02:40:02 and it would even have included a free CCS license if you didn't already have one Dec 05 02:40:26 re: led test: it's not the code itself, but all the details on where to locate things, the ld script syntax, etc. Dec 05 02:40:38 excellent example Dec 05 02:40:40 don't get me started about linker scripts Dec 05 02:40:45 * zmatt strangles GNU ld Dec 05 02:41:20 i've written a bunch for TI's code generation tools over the decades (whew, i'm getting old).. Dec 05 02:41:21 * zmatt sets GNU ld on fire Dec 05 02:41:30 not gnu ld, though Dec 05 02:41:46 nice syntax, eh? Dec 05 02:41:46 * zmatt pees over GNU ld to extinguish it again so he can safely hack into a for a while with a machete Dec 05 02:42:04 what do you use for doc? just the ld manual? Dec 05 02:42:47 that and many delightful experiences involving "WTF did it do THIS TIME" Dec 05 02:45:09 just 10 loc, right? Dec 05 02:45:10 :) Dec 05 02:45:28 THAT'S why 10 loc takes a week (among others..) Dec 05 02:45:34 hehehehe Dec 05 02:45:46 i finally got that FREAKIN .img file formatted correctly Dec 05 02:45:53 it took a DAY Dec 05 02:46:04 yates: did you see my README on raw mmc boot mode? Dec 05 02:46:19 no, where? Dec 05 02:46:22 github Dec 05 02:46:29 the led test project? Dec 05 02:46:31 yep Dec 05 02:46:36 i'll look Dec 05 02:47:29 http://paste.fedoraproject.org/297603/49283607 Dec 05 02:47:54 about ld, for example I first declared memory to start at 0x402f0400 (in the MEMORY {} section of the linker script) Dec 05 02:48:07 it'll happily ignore that and put your image at 0x402f0000 anyway Dec 05 02:48:19 why?!? Dec 05 02:49:12 btw, what do the double : ("::") mean in a gnu make file? is it .PHONY? Dec 05 02:49:16 because surely memory starts on a page boundary? so obviously the right thing to do is to just silently ignore the lower 12 bits Dec 05 02:49:45 unless you pass the right linker option of course Dec 05 02:49:57 intuitively named -Wl,--omagic Dec 05 02:50:07 why DID memory start at 0400? Dec 05 02:50:15 because secrom Dec 05 02:50:34 the first 1 KB of sram is reserved by secure rom for... well, nothing really, it doesn't use it Dec 05 02:50:53 probably their firewall doesn't support configuring a 0 KB boundary Dec 05 02:51:03 whta? Dec 05 02:51:09 firewall?!? Dec 05 02:51:37 eh, yes? Dec 05 02:52:30 the cortex-a8 has an elaborate one for secure-world stuff only, but there are also freely programmable firewalls for all L3 targets Dec 05 02:52:43 the L4 interconnects also support per-peripheral configurable permissions Dec 05 02:52:45 "firewall" is usually used to refer to blocking ports on a network interface. why are you using this term for a linker script? Dec 05 02:52:58 blocking access to RAM Dec 05 02:53:08 which is why I need to avoid that part in my linker script Dec 05 02:53:33 if you try to access the first 1 KB of the cortex-a8 local SRAM you get a bus error Dec 05 02:53:42 due to firewall violation Dec 05 02:53:54 that's why the program image is loaded at 0x402f0400 Dec 05 02:59:23 that was probably easier for TI than fixing the firewall to allow 0 KB of sram to be allocated to secure world :P **** ENDING LOGGING AT Sat Dec 05 02:59:58 2015