**** BEGIN LOGGING AT Mon Mar 16 02:59:58 2015 Mar 16 03:16:42 but yay for now being able to use my baremetal headers unchanged... \o/ Mar 16 03:18:45 and yay for the performance of direct peripheral access obviously... e.g. being able to set the level of any subset of a single GPIO bank high or low with a single write (i.e. 1 cycle unless the cpu's write buffer is clogged) is nice Mar 16 06:55:00 I'm trying to read the SRM but I've found several obvious typos with respect to table references. My inability to recognize more technical typos (read: lack of knowledge) makes me leery of the rest of the document. Is there a better reference I should be using? Mar 16 06:55:14 This is for the BBB Rev C. Mar 16 06:55:43 for what kind of info? Mar 16 06:56:36 header pin availability, max current on various pins, boot conflicts on pins, etc. Mar 16 06:56:50 try the TRM Mar 16 06:57:01 TRM? Mar 16 06:57:05 not that it would be /that/ error free Mar 16 06:57:19 technical reference manual, but that's of limited use for the things you mentioned Mar 16 06:57:49 it's still a useful thing to have in your documentation collection obviously (together with the datasheet) Mar 16 06:58:03 (of the AM335x processor that is) Mar 16 06:58:45 ahhh. i've been using that as a supplement, but at ~4700 pages, it's slow going. :-) Mar 16 06:58:49 I also have a spreadsheet which you may or may not find useful -> https://docs.google.com/spreadsheets/d/1CK5c-Cs8G1RtzGo-J3VJsD9m5K-fp06AncgeYWsdjSU/view Mar 16 06:59:02 no promises of correctness of course, but I did my best Mar 16 06:59:37 the main tabs of relevance are the ones starting with a B ;) Mar 16 07:00:12 that looks great. does "Z" in the reset state column man it's tristated? Mar 16 07:00:12 the BBB tab also has a filter view (Data -> Filter views -> CAPE) that shows pins on the expansion headers Mar 16 07:00:19 yes Mar 16 07:00:28 BBB tab? Mar 16 07:00:35 i'm new to this platform. Mar 16 07:00:36 look at the bottom Mar 16 07:01:24 Pinmux is generic to the am335x, Boot is info on boot modes, BBB is Pinmux but specialized for the beaglebone black, BBB2 is some of the same info but laid out graphically Mar 16 07:01:33 the remaining tabs can be safely ignored Mar 16 07:01:44 sweet. thanks! Mar 16 07:02:23 one more question about offsets, if you have a moment. I was reading this: http://derekmolloy.ie/gpios-on-the-beaglebone-black-using-device-tree-overlays/ Mar 16 07:02:56 one minor point: the TRM uses 1-based indexing for a few things (e.g. mii and clkout) and 0-based indexing for the rest; I consistently use 0-based indexing Mar 16 07:03:45 and got to the section under "setting up the circuit" where he lists the offset for GPIO1_28 as 0x078, but the BBB SRM lists an offset of 160(decimal) = 0x0A0. Am I misunderstanding the offset in the SRM? Mar 16 07:03:52 That's from Table 18 in the SRM. Mar 16 07:04:30 those offsets should be 4 * the number in the "Pin" column in my spreadsheet Mar 16 07:04:39 The table title is "EEPROM Pin Usage", so I think I'm just in the wrong spot to find offsets, but couldn't find them elsewhere. Mar 16 07:04:51 nice. i'll use the spreadsheet instead then. Mar 16 07:05:01 thanks. Mar 16 07:05:02 assuming you mean pinmux offsets Mar 16 07:05:26 yes. at least i think so; lots of information coming in fast today. Mar 16 07:06:36 hmm, I should try to cobble together a releaseworthy version of the code I use to directly control GPIOs from userspace (bypassing the kernel entirely) Mar 16 07:08:14 with syntax-sugar heavy C++ ;) Mar 16 07:09:10 can you point me in the direction of a good keyword to find out more about that? so far i've only encountered sysfs and kernel interfaces for GPIO control. Mar 16 07:10:28 you can open /dev/mem and mmap() any region of physical memory Mar 16 07:10:34 ewwwww Mar 16 07:11:16 you can see it in action e.g. in this gross little hack -> https://github.com/dutchanddutch/jbang but I just now did some major revision of the mechanism I use Mar 16 07:12:06 with the new version (not yet committed) you just include the headers (the same ones I use for baremetal code) and link to a magical library that will ensure the peripherals are mapped before main() is executed Mar 16 07:12:17 *the peripherals you use Mar 16 07:12:54 and with the gpio sugar syntax (yay vor C++ user-defined literals) you can do e.g. 1.28_io.set() Mar 16 07:13:40 * zmatt has a slight syntax sugar addiction Mar 16 07:14:44 the performance difference between using sysfs versus directly accessing a peripheral is rather substantial obviously Mar 16 07:15:32 yep. fortunately this project has very loose speed requirements. Mar 16 07:16:00 there's also the annoying part where sysfs won't let you set the desired output level in advance of changing the pin direction to output Mar 16 07:16:03 switching reed relays for the output, so the system can run around and do all sorts of things while those are flopping around. Mar 16 07:18:41 hmz, ok so it must be (1.12_io).set() apparently... pfff Mar 16 07:19:41 (though good to know a user-defined literal suffix can even contains dots apparently) Mar 16 07:22:18 at least g++ is doing its job optimizing all the sugar away :) all that's left are 2 instructions to load the gpio peripheral address into register, and two instructions to actually set the output Mar 16 07:31:08 zmatt: please google why you should _NOT_ use /dev/mem to access registers Mar 16 07:32:53 KotH: I'd rather indeed have a nice generic uio driver that just lets you map a peripheral's range, but /dev/mem works okay too Mar 16 07:33:55 aka "the car's motor does not have the performance i need, thus i attach a rocket launcher to my car" Mar 16 07:34:34 KotH: can you be more specific w.r.t. your objections than a vague reference to google (which does not immediately yield anything obvious) Mar 16 07:36:33 *sigh* Mar 16 07:36:39 that has been discussed sooooooo many times Mar 16 07:36:50 every noob who comes here and does GPIO does the same mistake Mar 16 07:36:55 1) access rights Mar 16 07:37:03 2) changing register addresses Mar 16 07:37:14 3) pinmux Mar 16 07:37:27 etc pp Mar 16 07:37:27 1) I map the parts I care about, close the fd, drop privs Mar 16 07:37:30 2) they don't Mar 16 07:37:50 3) taken care of by device tree, or I do that from userspace too :P Mar 16 07:38:08 * KotH shakes head and walks away Mar 16 07:39:12 KotH: being able to set or clear up to 32 gpios in 1 cpu cycle instead of up to 64 system calls seems kind of an okay reason to map gpio :P Mar 16 07:39:29 especially since the gpio peripheral is already designed to safely allow concurrent access from multiple places Mar 16 07:39:38 (by having atomic-set and atomic-clear regs) Mar 16 07:39:59 I'm guessing you also think nobody should program the PRU? given that it also directly accesses device registers Mar 16 07:41:25 there are some genuine things to watch out for when directly working with peripherals from userspace, but you haven't actually named a single one yet :P Mar 16 07:44:19 the overhead of going through the kernel is substantial, driver often only support a subset of peripheral functionality, and that's assuming there's a driver at all Mar 16 07:49:38 w/e, if you can't be bothered to defend your position or even give a reference to one those many discussions... Mar 16 07:54:37 KotH: I'm guessing you also object to the fact I configured EDMA from userspace to automatically transfer ADC samples to a buffer in OCMC ram? ;) Mar 16 07:55:03 (I did bother to reserve the OCMC ram range using device tree) Mar 16 08:01:38 (I can report btw that the theoretical ADC max of 1.6Msps, while no problem for EDMA of course, in practice doesn't leave enough sample time when driving the inputs with moderate impedance) Mar 16 08:44:01 1Msps works fine though (at least for the ~2.4 kOhm impedance used for ain7 ) Mar 16 13:47:59 though the adc noise profile at 24 MHz is... odd... https://docs.google.com/spreadsheets/d/1fBXQfxx3R9nqIiLQWu6HTmPrW6iTHDo4h7hSgAotB6Q/view Mar 16 13:56:42 not really Mar 16 13:57:11 does the datasheet mention "no missing codes"? Mar 16 13:57:22 or a DNL of less than 1LSB? Mar 16 13:57:35 doesn't explain why it's dependent on the ADC clock freq Mar 16 13:58:50 anyone, operating at 24 MHz and enabling averaging still outperforms operating at 12 MHz (except in power consumption probably) Mar 16 13:59:59 you should probably read something on ADC construction. i can recommend the lecture notes of boris murmann Mar 16 14:07:46 you just enjoy acting smug don't you? :P (I do know a few things about ADCs, and although I know there's undoubtedly plenty more I could learn about them, your reference is -- again -- too vague to be useful) Mar 16 14:09:45 yes, i enjoy that very much Mar 16 14:13:40 anyhow, I figured some example histograms of the adc at various settings might be worth sharing. (all of them are measurements of ain7 alternated with a measurement of zero (vref-), so the ones that continue excessively to the lower end simply had insufficient time) Mar 16 14:45:36 Hello, please, I have a doubt about how would I connect a USB barcode reader to a BBB, using the J1 connector. This reader needs to be powered from the BBB with 5 volts. Many thanks Mar 16 14:47:10 j1? Mar 16 14:47:17 why not use the USB port? Mar 16 14:47:52 hello, because it is been used, I'm afraid Mar 16 14:49:17 so use an usb hub? you can't magically connect usb devices to J1 Mar 16 14:49:40 use a hub Mar 16 14:50:55 Ok. Then, the BBB will recognice both usb device using a hub? Mar 16 14:51:28 it should Mar 16 14:52:08 it supports hubs yes Mar 16 14:52:25 but, this hub has to be powered? Mar 16 14:52:55 depends on the combined power draw of the barcode reader, the other device, and the hub Mar 16 14:53:30 the beaglebone can't source a huge amount of power Mar 16 14:54:04 Ok. I see it. I'll try it. Many thanks for your answer, @av500 and zmatt Mar 16 16:52:29 hey all Mar 16 16:53:23 anyone alive in here? Mar 16 17:13:09 is there alternative to updating angstrom? Mar 16 17:13:20 their servers are down Mar 16 17:14:04 vmayoral... i'm looking into your work Mar 16 17:14:21 I'm trying to set up ROS on top of angstrom Mar 16 17:14:48 it says somewhere not to install angstrom in the Beaglebone Mar 16 17:14:53 what does that mean? Mar 16 17:18:57 JPM__: the beagleboneblack now ships with debian by default, fwiw Mar 16 17:21:50 Yeah i have seen that.... but i am not sure what i want to do can be done on Debian Mar 16 17:22:26 I only see tutorials about ubuntu and Angstrom... I'm pretty clueless on linux... but i have worked a little bit with angstrom before Mar 16 17:22:59 So that's why i tried angstsrom first Mar 16 17:23:07 angstrom* Mar 16 17:30:21 Truth is.. i did see some people compile it for debian somewhere. it was probably well documented too. but i don't really trust any information that doesn't come from the ROS website Mar 16 17:30:52 Not because i doubt that the person did it, but because their technical level on the matter is much higher then mine Mar 16 17:33:53 I'd try asking around.... but in my imediate area i'm the expert (even though i know so little) Mar 16 17:36:23 reading the how to ask smart questions section :p Mar 16 17:40:05 JPM__: I believe you've misread something. What i pointed out is that the cross-compiling for ROS using Angstrom should be done in your Linux development box and not in the BeagleBone Black running Angstrom. Mar 16 17:40:30 BeagleROS should give detailed instructions on how to set up everything Mar 16 17:41:40 I'm not sure i understand... Mar 16 17:42:31 OH.... you mean programs written using ROS...? i thought you meant the set up.... Mar 16 20:56:55 hello, i am trying to boot my bbb rev c from sd card with the machinekit image. as described i press the boot button before applying power but nothing happens. i am wodnering if it is enough to just add the image to the sd card as it is described in the tutorials don't i need some kind of bootloader on the sd card Mar 16 20:58:04 dosas, did you use "dd" or "win32 imager" to write the *.img file directly to the microSD card? Mar 16 20:58:13 i used dd yes Mar 16 20:58:27 on a fat 16 partition Mar 16 20:58:38 "on a partition" ? please show us your "dd call"... Mar 16 20:59:05 sudo dd bs=1024 if=bone-debian-7.8-machinekit-armhf-2015-03-08-4gb.img of=/dev/sdi1 Mar 16 20:59:30 your need to use the full drive: "of=/dev/sdi" as the *.img contains the partition... Mar 16 20:59:40 then it'll work just fine.. Mar 16 20:59:45 ah okay Mar 16 20:59:58 so does the sd card need a specific filesystem Mar 16 21:01:53 dosas, nope... all the formatting is contained in the *.img file... It'll overright the media outright... Mar 16 21:02:14 oaky thanks i will try Mar 16 21:06:00 so once it is written i should see the partitions written by the image with gparted, right? Mar 16 21:08:54 correct Mar 16 21:17:14 rcn-ee: I am the guy who was having a fun time with you trying to debug freezing BBBs...I made the fix in the DTB you told me about (changed "OTG" to "peripheral"), and I just had one lock up on the bench anyway. Mar 16 21:18:17 I had a serial connection opened on the debug port, but it showed nothing when it froze up. Mar 16 21:18:40 I'm wondering if there's any way to prod at the board in its current state to try and figure out what it's doing. Mar 16 21:20:00 At this point, I'm considering rebuilding our image up on a different kernel build--which one do you guys suppose is the most stable? Mar 16 21:23:51 thisisbrians, right now, either 3.8.13-bone70 or 3.14.35-ti-r55 but 3.14.x hasn't had the long term testing like 3.8.x.. Mar 16 21:24:49 rcn-ee: thanks. any reason why I might pick one of those over the other? Mar 16 21:25:48 oh...i see your note about long term testing. Mar 16 21:25:50 capes/pwm/pru use 3.8.x otherwise 3.14.x Mar 16 21:26:36 gotcha. so if i'm just changing DTB, stick with 3.14.x? Mar 16 21:26:37 well i should define long term: it's old and people have been running it for months/years for bb.org whereas 3.14.x is just newer.. Mar 16 21:26:49 correct Mar 16 21:29:24 perfect. thank you! Mar 16 21:32:03 hi Mar 16 21:32:49 I did an apt-get update some minutes ago and have this: Mar 16 21:33:07 GPG error: http://repos.rcn-ee.net wheezy Release: The following signatures were invalid: KEYEXPIRED ..... Mar 16 21:33:19 along with someother repository Mar 16 21:34:10 Haran_Banjo, set your clock.. ;) Mar 16 21:34:19 sudo ntpdate pool.ntp.org Mar 16 21:34:26 aaah damn! :D thank you! Mar 16 21:35:03 of course it was that! :D Mar 16 21:35:20 with jessie it get's easier, as we have systemd doing the clock maintance.. Mar 16 21:37:31 well, at least it saves some early headhaches :D Mar 16 21:37:52 timestamps from the future!! Mar 16 21:38:05 * nerdboy runs in circles screaming Mar 16 21:38:45 rcn-ee: btw, I was looking at the -bone kernel config and have some questions/comments.... but first I need to catch a train, will you still be around later? Mar 16 21:38:54 I'm testing cryptodev, I wonder if you already went that path in order to improve crypto speed and if you're going to provide it in your repo Mar 16 21:41:28 Haran_Banjo: if you want to improve performance of the crypto accelerators, map them into userspace :P though I'm not sure whether they'll actually ever provide speed-up (versus just code reduction for ROM code), given that they're clocked really slow Mar 16 21:41:47 (from main osc) Mar 16 21:42:39 zmatt, yeap i shoudl be on.. Mar 16 21:43:40 ok :) bbl Mar 16 21:44:27 zmatt: ah, I see.. I've read someone reached transfer speeds of 38Mbit over vpn past year, while my latest test on linux 3.19 only gave me 17 Mar 16 22:40:36 hi Mar 16 23:16:00 Is there anybody who had sucess with compiling QT 5 for beaglebone? Mar 16 23:17:29 Is there anybody who had sucess with compiling QT 5 for beaglebone? Mar 16 23:24:42 Alex___ .. Yocto: http://gpupowered.org/node/20 - debian: http://www.beagleboard.org/Community/Forums?place=msg%2Fbeagleboard%2Fvw_ZQoq1QNM%2FvghebLf1-ysJ Mar 16 23:25:04 good evening friends and beighbors. Mar 16 23:25:37 *neighbors Mar 16 23:41:35 Haran_Banjo: neon-optimized aes-128 in software is known to take only 22 cycles/byte for 1536-byte messages, at 1 GHz that's 43 mega_byte_ per second Mar 16 23:41:48 Haran_Banjo: the crypto isn't the bottleneck Mar 16 23:45:13 rcn-ee: to get my assumptions right... based on its name, the -bone kernel is targeting just the am335x right? Mar 16 23:47:01 zmatt, correct.. it's tuned for the am335x, a few things we can enable/disable that don't (boot/work) on the older beagleboard omap34/dm37xx.. here's my current delta againsta generic all config: https://github.com/RobertCNelson/linux-dev/blob/master/tools/bone-config-checker.sh#L50 Mar 16 23:47:40 with the recent musb changes mainline, i can nuke a few of those things past v4.0.x.. Mar 16 23:47:43 since I saw CONFIG_ARCH_OMAP3 still set, and a lot of associated crap Mar 16 23:48:01 and pile of cpu options/features that are not applicable Mar 16 23:48:12 i could probally disable that. ;) Mar 16 23:48:55 one of the main things, is to disable config_reset_controller then the evil blob works. ;) Mar 16 23:49:02 the evil blob? Mar 16 23:49:05 sgx... Mar 16 23:49:34 but a lot of things on mainline are starting to depend on that config.. Mar 16 23:49:43 oh I'm not using any graphics, I'm actually planning to try to compile a kernel without any framebuffer support Mar 16 23:50:11 ah, then you can nuke the whole drm stack. ;) Mar 16 23:50:23 save some memory from the cma 24MB carve out too.. Mar 16 23:50:44 @veremit ... thanks Mar 16 23:51:07 What's the DRM stuff for? in case you want to use the DSP for video? Mar 16 23:51:25 GenTooMan, https://en.wikipedia.org/wiki/Direct_Rendering_Manager Mar 16 23:51:57 Doh :D I thought you ment digital rights management ... sorry :D Mar 16 23:52:28 I always heard it called DRI so I'm a bit behind the times I guess. Mar 16 23:53:37 Well DRI did come first, drm allows you to properly utilze mem/etc.. today dri2/etc is run on top of drm.. Mar 16 23:54:08 more importantly though, can I request CONFIG_UIO_PDRV_GENIRQ=m ? also in stable branches? it's just a module that won't affect anyone unless they explicitly load it, but then in the future I can hopefully share examples that use it with people Mar 16 23:54:24 zmatt, does it exist? Mar 16 23:54:59 found it.. Mar 16 23:54:59 it does in recent branches at least, now that you mention it I didn't check how far back it goes Mar 16 23:55:27 (the module has probably been around for a while, but dunno about its support for DT) Mar 16 23:57:09 zmatt enabled. ;) Mar 16 23:57:11 it became useful with 05c3e0bb562, dated Jun 18 2013 Mar 16 23:57:15 w00t Mar 16 23:58:45 zmatt, i try to keep the delta close to debian, so sometimes i mis a few.. ;) it's enable now . ;) Mar 17 00:02:32 I'll see if I can gather a list of options that are just a pointless waste of space on the am335x (after testing it'll still boot without them :P ) Mar 17 00:05:18 but ARCH_OMAP3 comes to mind, anything related to iommu (unless sgx uses it?), options related to the arm cache controller, arm architected timer, the various arm errata options, none of those apply to the cortex-a8 r3p2 Mar 17 00:06:55 and is dma for musb disabled purposely? (i.e. due to bugs, which would not terribly surprise me) Mar 17 00:08:05 talked to ti last week, iommu will become important for remoteproc/pru... Mar 17 00:08:27 i usually lave dma off on musb for mainline, till ti figures out all the side bugs... Mar 17 00:08:38 it's enabled in my v3.14.x. branch, but i really want to disable it.. Mar 17 00:08:41 hehe check Mar 17 00:09:00 musb is really sunshine isn't it? Mar 17 00:09:19 but eh, iommu for pru? but there's... no iommu Mar 17 00:09:36 wait a minute, musb was goofy in 2.6... Mar 17 00:09:41 what would the iommu do for the PRU? Mar 17 00:09:50 still not stable? Mar 17 00:10:05 ds2: a non-existent iommu doesn't do much for anything Mar 17 00:10:33 why are people so insistant on treating the PRU as a processor? Mar 17 00:10:36 well, it'll never be stable on the beaglebone white (am335x es1..) the dma controller on that sucks.. Mar 17 00:10:42 afaik the only MMUs present on the am335x are the one integrated in the cortex-a8 and the one afaik integrated in sgx Mar 17 00:11:30 ds2/zmatt, maybe it was the dsp on the omap3/am57xx, for the iommu... we talked alot about patchsets needed for the x15 and get the dsp on the omap3 usable on mainline.. Mar 17 00:11:32 there's no system mmu like on dm81xx or omaps Mar 17 00:12:37 you mean omap5/am57xx I assume? Mar 17 00:13:32 zmatt, no omap3.. ;) we talked about what it would take to just get "linux" on it, since all the old dsplink/dspbridge/etc is not maintained anywho.. So we might use it for "something".. Mar 17 00:13:52 Long live DSPgateway! Mar 17 00:14:26 omap3 at least still have a fine c64x+ dsp Mar 17 00:14:44 compared to that weird Tesla in omap4 Mar 17 00:15:35 but yeah, there's an MMU in omap3 iva, and in general they are in most TI SoCs Mar 17 00:15:43 two in DM81xx chips Mar 17 00:16:04 at least one of which deadlocks if it actually tries to do a table walk, which makes it a bit less useful ;) Mar 17 00:16:18 but there's none in the AM335x Mar 17 00:17:57 DM814x has a funny iommu-related bug also.... they added the option to route two of the EDMA TCs through the MMU to allow DMA to use virtual addresses Mar 17 00:18:22 except they messed it up: if enabled, writes use virtual addressing, but reads still use physical addressing Mar 17 00:19:05 (fortunately that would be the same MMU that deadlocks, so you weren't gonna use it anyway) Mar 17 00:22:10 rcn-ee: c64x+ / c674x (same thing except without vs with floating point) is actually quite an interesting architecture Mar 17 00:22:37 well-optimized loops (e.g. suitable linear algebra) can sustain 8 instructions / cycle Mar 17 00:23:33 zmatt, exactly! It's very nice, so disapointed we can't actually use it outside "2.6.32/etc.." and since we can't port it to syslink3, we might as well try to get it supported on mainline (running linux over remoteproc) then users could actually use it! Mar 17 00:24:16 rcn-ee: of course you can also just upload code there and run it, linux doesn't need to be particularly involved in any way Mar 17 00:24:35 is enough information out on the DSP on the O3 for folks to use it PRU/3.2 kernel style? Mar 17 00:24:35 well.. your "average" users. ;) Mar 17 00:25:05 ds2: dunno what PRU/3.2 kernel style is, but it's fully documented Mar 17 00:25:26 zmatt: a crude UIO support + userland library to download code onto the DSP Mar 17 00:25:40 zmatt: really? last I checked there certain details not available Mar 17 00:25:48 ds2: mmap its memory, upload code there, release it from reset Mar 17 00:26:13 zmatt: have you tried it and confirmed its completeness? Mar 17 00:26:18 I don't have any omap3 Mar 17 00:26:24 get a BBC Mar 17 00:26:50 but it's routine for me on a dm814x Mar 17 00:27:43 maybe iva2.2 has some specific points of attention, but iirc when I browsed its chapter it looked pretty comprehensive Mar 17 00:28:19 at one point reset/releasing the reset for the DSP was not well documented Mar 17 00:32:36 ds2: PRCM.RM_RSTCTRL_IVA2 bit 1 (RST2_IVA2) is cleared to power up the subsystem and release it from reset, once acknowledged you can upload code, then clear bit 0 (RST1_IVA2) to release the DSP from reset Mar 17 00:32:46 ta-da Mar 17 00:35:10 boot address comes from a register in the control module Mar 17 00:36:12 so, this is actually exactly the same steps as I need to do on the dm814x, just with different names Mar 17 00:39:07 compiler can be freely downloaded here -> http://software-dl.ti.com/codegen/non-esd/downloads/download.htm (for windows, linux x86, and linux armv7) Mar 17 00:42:58 of course there's more in IVA than just the DSP Mar 17 00:44:09 though even the hw accelerators seem to be documented (in contrast to those of IVA-HD) Mar 17 00:58:18 ds2: bbc? beagleboard classic? the -xM looks like a more sensible choice, though I'm not feeling particularly strong attraction to either of them Mar 17 01:16:51 zmatt: those details were not published at one point. it took a mail from someone on l-o to get that out Mar 17 01:17:34 BBC - BeagleBoard Classic, BBX - BeagleBoard xM, BBB - BeagleBone Black, BBW - BeagleBone White Mar 17 01:18:54 ds2: well, those details are even in the oldest omap34xx TRM I have (marked "PRELIMINARY"), swpu114i (2008-06) Mar 17 01:20:11 zmatt: where is that from? Mar 17 01:20:21 the internet? Mar 17 01:20:29 TI's site or? Mar 17 01:20:42 http://focus.ti.com/pdfs/wtbu/SWPU114I_PrelimFinalEPDF_06_10_2008.pdf Mar 17 01:20:47 google Mar 17 01:21:06 I see. Mar 17 01:22:37 good to see it is published. Mar 17 01:23:35 I kind of collect TI docs, since "gaps" in the documentation of one device can often be filled/clarified with info found in docs of other chips Mar 17 01:25:42 e.g. the crypto accelerators (except the PKA unfortunately) aren't documented in the TRM of any recent TI SoC... but they *are* in the docs of Snowflake (Tiva TM4C129x) Mar 17 01:26:44 am335x interconnect chapter is pathetic, but it's closely related to the dm814x which has a quite comprehensive chapter on it Mar 17 01:27:10 but getting back to the DSP Mar 17 01:27:14 both lack a serious debug chapter, but the dm816x TRM has one which, still woefully inadequate, at least gives a good overview Mar 17 01:27:18 if there is complete docs, a barebones interface might be useful Mar 17 01:27:33 /dev/mem is all you need Mar 17 01:27:51 I don't trust a single program to be screwing with /dev/mem Mar 17 01:28:04 uio provides some (alas, small) level of isolation Mar 17 01:29:52 hmm, I already had the desire for that but hadn't looked into it... can you just declare the relevant range in DT and have a device that behaves like a "/dev/mem partition" show up Mar 17 01:29:56 ? Mar 17 01:30:06 don't think so Mar 17 01:30:26 but then if you feel like playing with DT-code dejour... Mar 17 01:31:43 well it should technically not be hard to do that, preferably along with irqs and dma (the driver rcn-ee just built as a module allows irqs, but still in a quite inefficient way) Mar 17 01:31:57 but I'm no kernel programmer :P Mar 17 01:32:17 it would be nice to have simple DSP platform to learn on Mar 17 01:32:28 GSoC project ;) hehehe Mar 17 01:33:15 I read uio's explanation of still needing a kernel part, but that seemed heavily biased to PCI and shared interrupts... on SoCs that's really a non-issue Mar 17 01:33:33 look at the uio stuff for the PRU Mar 17 01:33:56 there's no reason why uio-stuff would require any peripehral-specific code Mar 17 01:34:09 link? (yes I'm lazy) Mar 17 01:34:19 drivers/uio Mar 17 01:34:26 oh right I saw something there Mar 17 01:34:40 uio-pruss or something like that Mar 17 01:36:26 right, so it's absolutely silly for that thing to be pruss-specific rather than getting its parameters from DT Mar 17 01:36:50 DT is an abomination Mar 17 01:37:21 board files were an abomination Mar 17 01:37:59 boardfiles were sane Mar 17 01:38:27 I have yet to see ways of implementing a callback for a driver specific to a board. Mar 17 01:38:38 * zmatt shrugs Mar 17 01:40:18 something like pruss-uio is where DT would shine Mar 17 01:42:22 replace its hardcode constants by DT properties and it would work just as well for other aux cores Mar 17 01:45:58 some resources can already be allocated via DT, e.g. gen_alloc is done by making child of the relevant sram node Mar 17 01:47:30 (I use that for my userspace ADC code to reserve the DMA buffer) **** ENDING LOGGING AT Tue Mar 17 02:59:58 2015