**** BEGIN LOGGING AT Wed Feb 15 02:59:57 2012 Feb 15 03:11:01 why might opkg say "Unknown package: ...", even though the package is listed in the Angstrom repos and i've done "opkg update"? the package isn't available for the architecture? Feb 15 03:14:09 although the repo says it is... Feb 15 03:20:10 peterwoo: can you search for it? Feb 15 03:20:13 I seem to have a similar issue Feb 15 03:22:09 no Feb 15 03:22:17 searching around i find http://comments.gmane.org/gmane.comp.hardware.beagleboard.general/22873 Feb 15 03:22:39 seems that the packages aren't all compatible with the latest Angstrom releases Feb 15 03:27:02 ah what a pain Feb 15 03:40:11 guess i'll just have to roll ubuntu Feb 15 06:59:26 * etheretic1 finds the upload bit of http://www.speedtest.net/ a bit suggestive. Feb 15 08:56:31 hello Feb 15 08:59:14 i'm trying to use OWFS on beagleboard. Somebody know it? Feb 15 09:01:50 I've used it in the past Feb 15 09:02:01 although I think in the end I decided to use a different progra, Feb 15 09:02:06 ie one that wasn't based on fusefs Feb 15 09:02:19 but that was mainly because I was using FreeBSD and fusefs is not 100% on that platform Feb 15 09:02:37 I have a running owhttpd -u -p 81 Feb 15 09:02:52 but how can i see a temperature value? Feb 15 09:03:36 visit http://beagleboardip:81 ? Feb 15 09:03:39 I didn't use the web serber Feb 15 09:03:41 server Feb 15 09:03:50 i tried use owfs -u , but i dont know the mount point Feb 15 09:03:50 is the file system mounted? Feb 15 09:04:03 how can i mount ? Feb 15 09:04:09 i have a RJ11 stuff Feb 15 09:04:15 mkdir /owfs ; owfs -u /owfs ? Feb 15 09:04:21 DS18S20 Feb 15 09:04:25 yes Feb 15 09:04:31 I have a bunch of those Feb 15 09:04:39 (for monitoring beer fermentation :) Feb 15 09:05:41 if I make a directory it is enought to add as a mount point for owfs ? Feb 15 09:05:53 ahh that's it, I neded up using http://www.digitemp.com/ Feb 15 09:05:59 yes Feb 15 09:06:03 there's nothing special about it Feb 15 09:06:10 it can go where you like Feb 15 09:06:49 owfs -u /mnt/owfs/ Feb 15 09:06:55 I used digitemp because I didn't need fuse Feb 15 09:07:03 DEFAULT: ow_usb_msg.c:(276) Opened USB DS9490 bus master at 1:3. Feb 15 09:07:09 DEFAULT: ow_usb_cycle.c:(182) Set DS9490 1:3 unique id 0x00 (no devices at all) Feb 15 09:07:23 these two message were throwed Feb 15 09:08:14 what does ls -la /mnt/owfs say? Feb 15 09:08:29 total 2 drwxr-xr-x 2 root root 1024 Feb 14 16:16 . drwxr-xr-x 3 root root 1024 Feb 14 16:16 .. Feb 15 09:08:59 not good.. Feb 15 09:09:07 so do you have a temperature sensor plugged in? Feb 15 09:09:36 there is a RJ11 to USB stuff Feb 15 09:09:52 hmm Feb 15 09:09:53 and there is a wire in it Feb 15 09:09:58 I haven't used the DS9490 myself Feb 15 09:10:00 with a DS18S20 sensor Feb 15 09:10:18 where did you get it from? Feb 15 09:10:56 I get it from a friend who use it, but not with beaglebone Feb 15 09:11:12 he see the usb device on /dev/tty.... Feb 15 09:11:41 i cannot see this dir Feb 15 09:11:50 let me check the data sheet Feb 15 09:11:56 thank you Feb 15 09:12:30 http://datasheets.maxim-ic.com/en/ds/DS18S20.pdf Feb 15 09:12:32 and Feb 15 09:12:33 http://pdfserv.maxim-ic.com/en/ds/DS9490-DS9490R.pdf Feb 15 09:14:34 yeah it doesn't seem much use Feb 15 09:14:39 the DS9490 one I mean Feb 15 09:14:48 doesn't say what sort of protocol it uses over USB Feb 15 09:15:09 have you tried this device on a "real" linux box? Feb 15 09:15:24 no Feb 15 09:15:45 I would try that Feb 15 09:15:49 i think it should works on a real linux Feb 15 09:16:09 http://forums.cabling-design.com/homeautomation/1-wire-and-linux-18183-.htm implies there is a kernel module for it now Feb 15 09:16:18 that may interfere with owfs Feb 15 09:16:49 eagle_: well there's only one way to find out Feb 15 09:17:02 of course finding a linux box with the sam version as your BB might be hard Feb 15 09:18:17 digitemp should be an easier way ? Feb 15 09:20:16 I dunno, not sure it supports the DS2490 cip Feb 15 09:22:37 thank you for your help Feb 15 09:23:28 np Feb 15 09:23:32 hmm some googling says it does Feb 15 09:25:27 yes it should work Feb 15 09:25:36 I think it builds a separate binary Feb 15 09:26:21 wow Feb 15 09:26:33 ls -la /mnt/owfs/ Feb 15 09:26:40 [ 1074.060410] usb_process_rx_queue 1466: Invalid PD popped from Rx completion queue Feb 15 09:26:43 total 1 Feb 15 09:26:48 drwxr-xr-x 1 root root 8 Feb 14 16:19 . drwxr-xr-x 3 root root 1024 Feb 14 16:16 .. drwxr-xr-x 1 root root 8 Feb 14 16:19 bus.0 drwxr-xr-x 1 root root 8 Feb 14 16:19 settings drwxr-xr-x 1 root root 8 Feb 14 16:19 statistics drwxr-xr-x 1 root root 32 Feb 14 16:19 structure drwxr-xr-x 1 root root 8 Feb 14 16:19 system drwxr-xr-x 1 root root 8 Feb 14 16:19 uncached Feb 15 09:27:11 i already have these dirs Feb 15 09:32:57 you know, it's really hard to read it all smushed into one line Feb 15 09:33:25 of course Feb 15 09:33:53 so the directories created in the mount point Feb 15 09:34:41 but still (no devices at all) message was throwed Feb 15 09:34:43 they're made by owfs Feb 15 09:34:54 look in them you'll probably see your devs Feb 15 09:38:05 it is the same dir structure what i can see on owhttpd in the browser Feb 15 09:41:46 where could I get the latest patches for the linux kernel for a craneboard? The latest kernel I found was 2.6.37 Feb 15 09:45:54 how can i get a php5mysql lib on my angstrom demo? I don't see any lib when i try opkg list | grep 'php' or searching on the http://www.angstrom-distribution.org/repo/ website Feb 15 09:46:29 kate123: build it? ;) Feb 15 10:15:47 Darlus: Yes i try :) i onley found a deb package and not the source code can i build it in angstrom with the deb package? Feb 15 11:33:10 I don't have a multimeter at my current location but I'm wondering if any body knew off hand if the pins labeled as "VDD_3v3EXP" in the BeagleBone SRM means that it is 3.3v? also why the EXP? Feb 15 11:34:41 at a guess, expansion Feb 15 11:47:16 so unimportant then? Feb 15 11:49:20 well.. Feb 15 11:49:27 important if you want to power your subboard I suppose.. Feb 15 11:55:22 Nope, just powering a GPS module Feb 15 11:57:24 Anyone happen to know why when I run: http://pastebin.com/raw.php?i=4bnshaNr to install pyserial but then attempting to run my script I get this error?: http://pastebin.com/raw.php?i=X5vFicV0 Feb 15 11:59:51 import pyserial ? Feb 15 12:02:40 that didn't work either, but I'm almost certain its just serial Feb 15 12:03:10 i tried opkg update; opkg upgrade; too that didn't work either Feb 15 12:15:12 hmm it is import serial Feb 15 12:27:03 Sometimes when I unplug my network cable dmesg starts yelling: smsc95xx 1-2.1:1.0: eth0: kevent 4 may have been dropped Feb 15 12:27:17 and it won't stop until I pull the plug Feb 15 15:42:42 the reason it never stops yelling is that it never stops yelling. Feb 15 15:43:15 it keeps dropping the kevent that is meant to reset the link, because it is busy printing messages about how it can't :) Feb 15 16:58:14 http://pastebin.com/EfQbsLGB If anyone gets a chance, I'm getting some errors when trying to boot the kernel and I need some help. Feb 15 17:00:56 * mranostay yawns Feb 15 17:25:32 mark____: try making your rootfs ext2fs? Feb 15 17:27:08 http://blog.ngas.ch/archives/2011/12/13/the_destructive_desktop__mdash_linux_in_trouble/index.html Feb 15 17:27:30 the destructive desktop will soon or latter make embedded linux hard to use Feb 15 17:27:56 can't agree with the author more Feb 15 17:29:03 dbus sucks Feb 15 17:29:15 gobject sucks too Feb 15 17:30:54 networkmanager sucks Feb 15 17:31:24 glad I don't have to work with that stuff anymore :) Feb 15 17:32:41 good article… reminds me too much of a past life working on ubuntu desktop stuff Feb 15 18:37:58 hmmmm Feb 15 18:41:19 ds2: ? Feb 15 18:43:17 mranostay: u in redwood cty? Feb 15 18:43:55 yes Feb 15 18:44:06 what room? Feb 15 18:45:03 Bordeaux Feb 15 18:49:22 ds2: you? Feb 15 18:56:43 champaign Feb 15 18:57:22 * mranostay waves through the wall Feb 15 18:57:42 :) Feb 15 19:08:11 Well Feb 15 19:08:17 koen: can you add synergy to the Angstrom feeds for beagleboard/beaglebone? Feb 15 19:08:19 I asked ANOTHER question on the sitara forum that I'm sure nobody will !&*#%!&*(% answer Feb 15 19:08:20 >:( Feb 15 19:08:24 it seems like it is built: http://www.angstrom-distribution.org/repo/?pkgname=synergy Feb 15 19:09:07 SilicaGel: is it a good question? if so, it might not hurt to post a link to the question here as well as on the mailing list if you don't get an answer here. Feb 15 19:09:58 http://e2e.ti.com/support/dsp/sitara_arm174_microprocessors/f/416/t/165307.aspx#602224 Feb 15 19:10:04 I'm not sure if it's a good question or not hehe Feb 15 19:10:33 http://e2e.ti.com/support/dsp/sitara_arm174_microprocessors/f/416/t/165045.aspx is another one Feb 15 19:10:37 you'll probably get the typical answer when no one knows the answer… "why would you want to do that?" Feb 15 19:10:44 http://e2e.ti.com/support/dsp/sitara_arm174_microprocessors/f/416/t/165035.aspx is another one Feb 15 19:10:49 the thing is Feb 15 19:10:53 or the lovely insulting variant… "you'd have to be crazy to want to do that!" Feb 15 19:10:54 Ti support sends me to the forums Feb 15 19:10:59 they're basically sending me to a black hole. Feb 15 19:11:04 only an idiot would do it THAT way! Feb 15 19:11:41 Amazon AWS sends me to the forums for support, too, but they have their own people monitoring things and answering questions. Feb 15 19:11:48 With T.I. I get the feeling I'm just getting the shoveoff Feb 15 19:11:54 jkridner: I'll have a look Feb 15 19:12:22 hmmmmm blackholes on the planet Feb 15 19:12:35 and when I start getting into deep things like the transfer size of EDMA transfers in SAM/DAM fifo modes ... all I really get are blank stares. Feb 15 19:13:56 so PRU memory isn't local to the PRU? Feb 15 19:14:11 PRU memory is mapped to global memory through L4/L4 interconnets yeah. Feb 15 19:14:22 unelss I grossly misunderstand something Feb 15 19:15:41 SilicaGel: I believe the first question is of the read-the-TRM variety. yes, the EDMA is designed to handle buffering data rx/tx the serial ports, including the McSPI. The specifics of doing so is an engineering exercise. I think you'd get more response if you uncovered an issue. Feb 15 19:15:57 huh Feb 15 19:16:38 yeah. maybe you're right. I'm reading the TRM, there are just pieces of it I can't connect in my head yet. Feb 15 19:17:06 those usually come together when you start doing it Feb 15 19:17:43 SilicaGel: I just responded on the forum, but I am a bit concerned my response isn't all that useful. Feb 15 19:18:02 I know the EDMA is designed to do what you suggest. Feb 15 19:18:12 so you're thinking Feb 15 19:18:17 I haven't tried the exact configuration you mention, but it should work, yes. Feb 15 19:18:29 use a timer to trigger one dma channel to make the McSPI start transferring bytes Feb 15 19:18:47 then what, use a second DMA to pull the data back OUT of the spi fifo to put into dram? Feb 15 19:18:50 yeah, since you need to send bytes on SPI to receive them. Feb 15 19:19:07 at least that's what I'd assume if you are in a master configuration. Feb 15 19:19:12 yeah. The McSPI actually has a 'receive only' mdoe where you can somehow tell it to start without having toa ctually transfer bytes into it Feb 15 19:19:37 ... but that is yet another thing I haven't quite figured out yet hehe Feb 15 19:19:42 that's cool. Feb 15 19:19:57 Sorry if I sound like a dumbass. I'm just overwhelmed. The TRM is 4500 pages Feb 15 19:20:00 I'm curious as to what the SPI Linux driver looks like and if it uses DMA. I'd guess not. Feb 15 19:20:17 you don't sound like a dumbass… just alone on a project :) Feb 15 19:20:23 it can use dma, iirc Feb 15 19:20:56 ds2: cool. can you get it to do transfers at timed intervals? Feb 15 19:21:03 it is only 4500 pages... Feb 15 19:21:32 that i donno.. the mcbsp seemmore suited for that Feb 15 19:21:47 * jkridner reads http://www.kernel.org/doc/Documentation/spi/spi-summary Feb 15 19:22:00 <-- slow elc link Feb 15 19:23:24 … and http://www.kernel.org/doc/Documentation/spi/spidev Feb 15 19:23:37 * jkridner paid for the "express" service at the hotel. Feb 15 19:23:42 helps a bit. Feb 15 19:23:47 why not use the mcbsp instead? Feb 15 19:24:01 Do I have a McBSP? Feb 15 19:24:06 This is on an AM3359 Feb 15 19:24:12 oh Feb 15 19:24:21 mcasp might do it Feb 15 19:24:38 am33x is mcasp, iirc Feb 15 19:25:41 it has the audio serial port yeah, and an mcspi Feb 15 19:28:36 SilicaGel: my reading of the am335x trm says that the bus between the PRU cores and the PRU shared memory is internal to PRUSS Feb 15 19:28:56 looks like PRU core mem is inside each PRU and the shared mem is across the PRUSS "SCR" bus Feb 15 19:29:18 the other thing i was thinking i could do is to just go back to my original plan of using the PRU to start conversion, wait for end of conversion pin, fetch the data, and trigger a 2D dma transfer of said data Feb 15 19:29:20 oh really hmm Feb 15 19:29:39 that same PRUSS "SCR" is also on the L4 Feb 15 19:29:47 and each PRU core has a port on the L3 Feb 15 19:30:05 "Figure 4-2 PRUSS Integration" Feb 15 19:30:39 hmmm Feb 15 19:31:21 SilicaGel: can you desc briefly what u are doing? link access is not convenient atm. Feb 15 19:31:25 so that prot on the l3 is what allows the PRU to access the global memory map (both memory and special function registers for I/O, etc.) correct? Feb 15 19:31:30 s/prot/port/ Feb 15 19:31:41 i'd assume yes, but haven't got that far Feb 15 19:32:07 ds2 it's four, high speed A/D converters, 16 bits. I want the arm mpu to only have to deal with a whole 1 second worth of data at a time Feb 15 19:32:48 that sounds more like an audio thing the a spi thing Feb 15 19:33:12 hm well it's not audio exactly, but sort of. It's vibration data on diesel engines Feb 15 19:34:25 yes but periodic sampling is what you have incomon Feb 15 19:34:35 jay6981: it's interesting too that even though each PRU has "its own" data memory, they can still see each others memories but at a different offset Feb 15 19:35:08 ds2: hm so can the McASP be used just like an SPI port that kind of does its thing over and over autonomously? Feb 15 19:35:28 yeah, those memories are external to the PRU cores across a dedicated bus inside the PRUSS Feb 15 19:35:44 ok then that's what they call the "32 bit interconnect" Feb 15 19:35:56 more less, yes Feb 15 19:36:10 yeah, or "SCR" switched central resource Feb 15 19:36:17 managing the cs line needscreativity Feb 15 19:36:58 ds2, so no elc for you? bummer Feb 15 19:37:11 i am @ elc Feb 15 19:37:11 mmm.. so there might be improvements in the McSPI kernel driver... Feb 15 19:37:26 ah, screen or something Feb 15 19:37:48 jay6981: let me show you one other thing though, look here: http://processors.wiki.ti.com/index.php/PRU_Linux-based_Example_Code#PRU_memAccessL3andDDR Feb 15 19:37:58 yes Feb 15 19:38:07 That is part of the thing that left me with the impression that the PRU could read and write DRAM Feb 15 19:38:10 SilicaGel: looks like you load the PRU isn memory via the host CPU over L3 while the PRU core is stopped Feb 15 19:38:24 jay6981: yeah, that's definitely how you load the pru PROGRAM memory Feb 15 19:38:26 russ: what room? Feb 15 19:38:30 the PRU is a harvard architecture machine Feb 15 19:38:42 so i think PRU can read/write DRAM… they have a local memory mapped interface to the SoC memory map Feb 15 19:38:54 ok Feb 15 19:39:01 blobs attack! Feb 15 19:39:05 but the MPU can't read/write the "share data memory" wthin the PRU, that's what you're saying? Feb 15 19:39:26 upfront? Feb 15 19:39:30 it seems to say you can't access the PRU isn memory while the PRU is running Feb 15 19:39:35 ds2: what room are you in now? Feb 15 19:39:37 but data memory is different i think Feb 15 19:39:46 FWIW spidev has a small bug to be aware on more recent kernels. if you set up only a receive transaction it will lock up the kernel but if you set up a bidirectional transaction (sending random noise) it seems to work - at least on my gumstix OE build Feb 15 19:39:59 mranostay, same Feb 15 19:40:10 SilicaGel: "The PRU accesses the external Host memory map through the Interface/OCP Master port (System OCP_HP0/1) starting at address 0x0008_0000." Feb 15 19:40:54 ok it took me a while to find this but in the section 2.1 ARM Cortex A8 Memory map it says PRUSS is in the global memory map at 0x4A300000 ... and its description is "PRU Subsystem 1 Instruction?Data/Control space" Feb 15 19:41:01 it looks like a straight mapping, in that you have to do some tricks if you want to access external SoC memory between 0x0-0x7FFFF Feb 15 19:41:20 upfront Feb 15 19:41:35 oh Feb 15 19:41:39 so how i interpret this - tell me if I'm wrong - is that you take 0x4A300000 and add it to an offset address in Table 4-6 Feb 15 19:41:43 ]in the back Feb 15 19:42:02 SilicaGel: which A/D converter are you using? Feb 15 19:42:03 and then you can access DATA 12KB RAM (2) at 0x4A300000 + 0x00010000 = 0x4a310000 Feb 15 19:42:07 SilicaGel: checking Feb 15 19:42:22 dwery: it's an LTC1609ISW Feb 15 19:42:43 with a programmable digital filter in front of it, LTC1564 Feb 15 19:42:48 SilicaGel: you get that the PRU has it's own seperate local address space? Feb 15 19:43:04 its Feb 15 19:43:05 SilicaGel: pretty nice stuff. hobby or work? Feb 15 19:43:08 yeah, so PRU programs themselves dont' use this global memory map Feb 15 19:43:23 dwery: it's for work, but it's kind of fun too Feb 15 19:43:29 well, anything above pru address 0x7FFFF is external soc map Feb 15 19:43:36 best of both worlds Feb 15 19:44:29 I'd love to offload some SPI stuff to the PRU Feb 15 19:44:49 so if the PRU is running, you're sayign you don't have access to IRAM ... interesting. I didn't know if that was required by interconnets, or if they're just saying it's not a good idea to change IRAM while the PRU is using it to execute Feb 15 19:45:03 I interpreted that as "You shouldn't" rather than "you can't" but I could be wrong Feb 15 19:46:10 \ Feb 15 19:46:22 btw.. does TI have some ready-made IPs for the PRU? Feb 15 19:46:28 SilicaGel: yeah, you probably have to just try it. Feb 15 19:46:34 There's a number of examples Feb 15 19:46:47 they're all on http://processors.wiki.ti.com/index.php/PRU_Linux-based_Example_Code as far as I know Feb 15 19:46:55 SilicaGel: your address calculation looks good btw Feb 15 19:47:09 ds2: Russ: ok i'm in the room now Feb 15 19:47:22 I found a couple of examples where people did very serious things on the PRU and I was wondering if it was all internal development Feb 15 19:47:23 so I have a more general dma question then Feb 15 19:47:49 When the DMA controller has to transfer memory from the PRU to DRAM, it still has to do it via the L3 interconnect right Feb 15 19:47:52 like a CAN bus controller Feb 15 19:48:13 yeah I friggin can't BELIEVE they released source code for a CAN controller. I thought bosch would be totally all over them in court if they did something like that. Feb 15 19:48:17 hmmmm Feb 15 19:48:35 SilicaGel: well, someone did it from scratch then Feb 15 19:48:44 SilicaGel: appears DMA will have to talk to PRUSS Data RAM over L4 Feb 15 19:48:51 L4 Feb 15 19:49:02 heh Feb 15 19:49:11 jay6981: so then, why don't I just say screw the DMA, and have the PRU stuff data into DRAM over L3/L4 ? Feb 15 19:49:21 mranostay, still at one with amazing animated slides Feb 15 19:49:23 ? Feb 15 19:49:34 SilicaGel: seems feasible Feb 15 19:49:46 mdp: no Binary Blobs Feb 15 19:49:50 jay6981: and the expense that I'd pay for not using the DMA is what ... anything? Feb 15 19:50:06 oh, cool. me too Feb 15 19:50:22 SilicaGel: just tying up the PRU cores doing data transfers Feb 15 19:50:29 well geeze Feb 15 19:50:32 that's cool Feb 15 19:50:35 because it has nothing else to do Feb 15 19:50:35 haha Feb 15 19:50:50 watch everyone walk pass each other Feb 15 19:51:04 it looks like you could actually make the PRU cores access their own data rams over the L3->L4 interconnect as well as over the local SCR bus Feb 15 19:51:09 not that you would want to Feb 15 19:51:11 just neat Feb 15 19:51:18 it's job is very straight forward. Strobe START CONVERSION pin, nop nop nop, wait for CONVERSION FINISHED pin to go active, suck data out of SPI, stick data into DRAM Feb 15 19:51:27 haha Feb 15 19:51:41 that's good, there's a slow way to do it, and an even SLOWEr way to do it Feb 15 19:51:54 silcagel: gates + mcasp Feb 15 19:52:02 Maybe if you do it fast enough you could cause a black hole Feb 15 19:52:09 I missed the amazing animated slides Feb 15 19:52:26 SilicaGel: looks like a fun project btw, neat little system to play with Feb 15 19:52:44 yeah I think it will be. I hope I'm not sticking my neck out by telling people I can do this, when I'm only "pretty" sure I can Feb 15 19:52:52 Russ, best part of the session..i had to leave so i didn't miss zach's rich character in action Feb 15 19:53:19 silicagel: should be doablein someform Feb 15 19:53:22 I actually have three thigns to do with the PRU, but only 2 of them at once Feb 15 19:53:29 I have to implement a J1708 receiver in one PRU Feb 15 19:53:38 this vibration A/D converter thing in another PRU Feb 15 19:53:57 then when it's time to go to sleep / low power mode, I'm going to load a wakeup program into one of those two PRUs and put the main processor to sleep Feb 15 19:54:19 You know it's funny to me that if you look at the TRM in the chapt 2 memory map they actually list a Cortex M3 memory map. WTF Feb 15 19:54:36 is that a copy and paste error? As far as I know there were no AM33XX chips with an M3 inside Feb 15 19:55:03 SilicaGel: it's feasible… the only issue is you might run into some bug in the pru silicon or something and not be able to get help Feb 15 19:55:09 or come up with some other work around Feb 15 19:55:09 SilicaGel: http://www.kanecomputing.co.uk/pdfs/Mistral_can_expansion_module.pdf the funny thing is that there's no reference to this module on Mistral's web site Feb 15 19:55:46 SilicaGel: was wondering same, wrt M3 Feb 15 19:56:07 dwery: they may pay royalties to bosch for that. I know bosch DOES have IP cores and soft implementations you can license Feb 15 19:56:08 isn't the power controller thing an M3? Feb 15 19:56:13 but I found a FREE one somewhere Feb 15 19:56:25 There's no M3 inside the AM335x that I know of ! Feb 15 19:56:33 maybe Bosch sued and they obliterated the module Feb 15 19:56:40 m3 for pm Feb 15 19:56:51 keep reading Feb 15 19:56:57 ok Feb 15 19:57:17 it doesn't say much about it. Feb 15 19:57:22 "This product has been removed from our webstore for more " Feb 15 19:57:23 :D Feb 15 19:57:37 Figure 8-6 shows a Cortex M3 though Feb 15 19:58:39 it's not available for your use is why :) Feb 15 19:58:47 yeah ok i get it now Feb 15 19:59:12 but it is smart enough to be able to watch gpio0, dmtimer1, usb2phy, tsc, adc, uart0, i2c0 to make it wake up Feb 15 19:59:16 we are all disappointed, trust me Feb 15 20:00:01 huh it doesn't say it has rom though. So does something on boot load the M3's "program" into him? Feb 15 20:00:18 335x could have been a couple orders of magnitude more useful with s/PRU/gen pur M3/ Feb 15 20:00:22 I don't know why I put quotes around "program," sorry Feb 15 20:00:35 maybe. The PRU is actually pretty damned nifty though.; Feb 15 20:00:48 It's just far less accessible (technology wise) than an m3 or even m0 would have been Feb 15 20:00:58 yup Feb 15 20:01:17 My apprehension about using the PRU is mostly that anything I do is totally TI specific, and even at that, there's no guarantee T.I. might not just give up on it one day Feb 15 20:01:22 i'd take even a msp430! Feb 15 20:01:34 that would be interesting too Feb 15 20:01:42 pru's failure is the core and lack of being able to leverage common tool…fail Feb 15 20:02:07 m0 is pretty low power though, well competitive to msp430, which is kind of funny to me as msp430's main advantage IMO was the crazy low power and clock modes they historically have had Feb 15 20:02:29 *cough* 430 *cough* Feb 15 20:03:58 �� Feb 15 20:04:35 blah Feb 15 20:04:46 so l3 is kind of like a packet bus Feb 15 20:04:54 where you stuff in commands saying "I want you to write this to there" Feb 15 20:04:57 I think I have an msp430 dev kit lying around somewhere... Feb 15 20:05:06 and something on the other end reads that command, does it, and sends back an ack Feb 15 20:05:11 correct? Feb 15 20:05:11 L3 is the fastest bus on the SoC Feb 15 20:05:16 ok Feb 15 20:05:17 used for talking with the SDRAM mostly Feb 15 20:05:19 I have a launchpad too, never played with it ;) Feb 15 20:05:48 and the L4 can communicate between the L3 (and, therefore, anything on L3) and slower peripherals that live ONLY on L4, right? Feb 15 20:06:02 the MPU connects to L3 only Feb 15 20:06:08 MPU talks to L4 via the L3->L4 bridge Feb 15 20:06:25 L4 runs at L3_CLK/2 i think Feb 15 20:06:38 probably configuarable Feb 15 20:06:40 Is that the L3F, the L3S, or the whoel L3 ? Feb 15 20:07:19 The PRUSS has two 32-bit "initiator" ports, I wonder if that's specifically one per PRU (dedicated) or if they're sorta pooled Feb 15 20:07:21 it's probably one per PRU Feb 15 20:08:05 but like for instance the DCAN is only on the L4 ... so for the PRU to talk to DCAN, it has to send a message to L3 which relays it to L4 for you ... right? Feb 15 20:08:41 oh no. I bet that's wrrong, beacuse PRUSS1 is also on L4. It's on both. :( Feb 15 20:09:36 oh but there are two types of ports, "initiator" and "target" Feb 15 20:10:16 so the PRUSS is an "initiator" on L3. And on L4 there doesn't seem to be the initiator/target concept. Feb 15 20:11:22 so the PRU can read/write DRAM over L3, because it can initiate. But no initiators can use L3 to access memory resources of the PRU itself? hrm. that must go through L4? Feb 15 20:11:27 * SilicaGel checks the memory map chapter again Feb 15 20:13:07 ok. Feb 15 20:13:43 So based on that, it seems like having the PRU read/write DRAM would be fairly fast, but having the MPU read/write the PRU's memory would be slower (L4) Feb 15 20:27:40 yeah, you'd probably stall out the MPU Feb 15 20:46:04 koen: I have the range finder working. Feb 15 20:47:11 light, sound or laser? Feb 15 20:47:43 sound Feb 15 20:48:03 lv-maxsonar-ez1 Feb 15 20:49:00 ah, those nifty things Feb 15 20:50:26 annoying cats ;) Feb 15 20:55:20 i wonder how fast the pru can write a 32 bit word into SDRAM over L3 Feb 15 20:55:31 nanoseconds probably right? Feb 15 20:56:18 if i had to guess i'd say around 100ns Feb 15 20:58:46 hmm that's nto really so good hehe Feb 15 20:58:54 what? Feb 15 20:59:06 memory access always seem slow to me on the omap stuff Feb 15 20:59:43 hi woglinde_ Feb 15 21:03:07 if PRU has a cycle counter would be easy enough to test Feb 15 21:03:22 you know, i'm reading the API for the PRU userspace driver infrastructure and it's pretty cool but it is scaring the shit out of me Feb 15 21:03:56 it lets you do things like have your userspace allocate memory, then get the physical address of said memory and pass it to the PRU Feb 15 21:04:00 so then what happens if you hit ctrl-c Feb 15 21:04:14 and that memory is returned to the kernel Feb 15 21:04:20 but the PRU is still off and running, writing to it Feb 15 21:06:29 maybe kernel stops the PRU when you kill the process Feb 15 21:06:45 yeah like maybe it sees a close() Feb 15 21:08:02 where are these api docs? Feb 15 21:08:11 http://processors.wiki.ti.com/index.php/PRU_Linux_Application_Loader_API_Guide Feb 15 21:08:27 cool Feb 15 21:09:23 it says to do it you have to patch and recompile the kernel, in addition to the kernel module that this api needs to be loaded Feb 15 21:09:32 but I'm looking at the patch, and it's for mach-davinci Feb 15 21:09:36 so I'm not sure waht that means Feb 15 21:09:47 I can't be the first person stupid enough to try to amke PRU work on a beaglebone can I? Feb 15 21:09:57 there was some other guy talking about it in here a few weeks ago Feb 15 21:10:04 silicagel you are Feb 15 21:10:04 maybe it was me :) Feb 15 21:10:10 maybe! :) Feb 15 21:10:13 woglinde_: What! you didn't say ", ha ha" Feb 15 21:10:39 mach-davinci is the machine type in the arch/arm tree Feb 15 21:10:42 beagle --> toy Feb 15 21:11:12 oh so sitara is also built using that machine type? Feb 15 21:11:40 unsure Feb 15 21:11:53 you might have to do some porting :) Feb 15 21:12:16 Maybe I should ask the T.I. forum Feb 15 21:12:18 the naming convention isn't very good Feb 15 21:12:22 ... which is the same as asking nobody!!!!!!!!!!!!!!!!! Feb 15 21:12:31 you probably need to look through the arch/arm code to figure out what's what Feb 15 21:13:12 ask about SIGKILL, not SIGINT, just to be sure you won't get unecessary answers Feb 15 21:13:42 i'm fetching their source Feb 15 21:18:54