**** BEGIN LOGGING AT Wed Mar 14 02:59:58 2012 Mar 14 04:31:21 Hi, I wanted to start developing a commercial application to be deployed on the beagleboard, but then I realised that its not production ready. DO you know of any SBC that is similar in design and production ready? that is supported and has a case cover? Mar 14 04:35:16 keithzz, its "production ready" but you won't be able to rely on the actual board being available in "production quantities" Mar 14 04:36:15 so a board in a metal/aluminum case is reliable in a industrial environemt? Mar 14 04:36:30 temp from -20 to 70C? Mar 14 06:08:40 blah Mar 14 06:08:49 the #beagle is a production ready _DESIGN_ Mar 14 06:09:06 prototype and have someone build it. Mar 14 06:11:39 ds2, correcgt Mar 14 06:11:53 building it is easy Mar 14 06:16:39 hmmm... Mar 14 07:02:31 do i need a uEnv.txt to automatically boot the beaglebone? Mar 14 07:09:21 how do i know what addresses to put into the file? Mar 14 07:59:14 Does anyone have any experience actually using McBSP1 or McBSP3? Mar 14 07:59:38 I feel like it shouldn't be this difficult Mar 14 08:00:01 Since they're available on the expansion header Mar 14 08:00:08 But I can't make heads or tails of it Mar 14 08:00:23 And I've been scouring the internet for the past week Mar 14 08:08:11 i got this small GPIO issue... I know I just missed something... can any tell me : If I want to do high/low on GPIO1_1 on my beaglebone.. do I need to set someting first? and what? Mar 14 08:08:51 trying a : echo "low" > /sys/class/gpio/gpio33/direction Mar 14 08:09:32 but is gpio33 = pin 24 => gpio1_1 Mar 14 08:09:36 ?? Mar 14 08:19:18 Have you set up your pin muxes correctly? I don't know directly about the Beaglebone, but the BeagleBoard not all the GPIO are set up for GPIO straight away Mar 14 08:19:37 Does gpio33 show up in your /sys/class/gpio? What errors are you getting? Mar 14 08:21:58 @harley ^^ Mar 14 08:22:14 Or are you getting any errors, or is it just not responding? Mar 14 08:22:41 How man piano tuners are there in the United States? Mar 14 08:24:12 (num_pianos * tuning_freq * tuning_time) / hours_per_workweek Mar 14 08:24:41 workday, rather Mar 14 08:24:47 Assuming tuning_freq is in tunings/day Mar 14 08:25:33 <_tasslehoff_> av500: fyi: we've been benchmarking filesystems on our sd card, and the extreme latencies we had go away with anythin !ext3 Mar 14 08:26:15 So, has no one ever actually *used* McBSP1 or 3? Mar 14 08:27:04 no one? out of all the 6 billion people? Mar 14 08:27:14 _tasslehoff_: ic Mar 14 08:27:15 That's about what it looks like from my research Mar 14 08:27:30 I lied Mar 14 08:27:32 A few claim to have Mar 14 08:27:33 publish! Mar 14 08:27:43 But leave no indications of how they got it working Mar 14 08:27:53 Or vague references Mar 14 08:27:57 solder and iron? Mar 14 08:28:16 * fiveofoh is just a bit tired of fruitless googling and mailing list reading and datasheet scouring Mar 14 08:28:21 <_tasslehoff_> harley: direction: "out" makes more sense, and then value: "low". Mar 14 08:28:41 But direction low is supported Mar 14 08:28:59 I'd fall back to "out" and then value "low" if that didn't work though Mar 14 08:29:10 <_tasslehoff_> it is? then I'll shut up :) Mar 14 08:29:25 Yep :P It's a little shortcut, slash edge case Mar 14 08:29:30 it's totally logical, isn't it? Mar 14 08:29:33 fiveofoh: using them to output sound via alsa? Mar 14 08:29:42 av500: That's the ideal situation Mar 14 08:29:51 Obviously, McBSP2 works like a peach Mar 14 08:29:55 Cause it's all built-in and things Mar 14 08:29:57 what does 'echo coffee > /dev/mem' does? Mar 14 08:30:14 fiveofoh: so you'd have to hack up the alsa driver to use another mcbsp Mar 14 08:30:30 ynezz: computer is 5% faster for 15minutes Mar 14 08:30:40 so you need a cron job Mar 14 08:31:02 fiveofoh: using the mcbsp2 support as a template Mar 14 08:31:12 That's what I've been gathering, but I haven't done any kernel hacking...I've been trying to poke around, I downloaded the Angstrom build stuff Mar 14 08:31:31 Is that the right place to start poking around? Mar 14 08:31:32 well, kernel hacking will be involved Mar 14 08:31:46 you can use angtrom to re-build your kernel as step one Mar 14 08:31:55 I got that Mar 14 08:31:58 once you can build and run kernels, hacking begins Mar 14 08:31:58 I think Mar 14 08:32:07 I haven't tried actually using the kernel Mar 14 08:32:12 which for you will involve staring at the alsa code a lot Mar 14 08:32:27 But I followed the directions and downloaded the setup-scripts and told it to build BeagleBoard Mar 14 08:32:35 It spit out a uboot.bin in an obscure directory Mar 14 08:32:40 So I think it worked :P Mar 14 08:32:47 * fiveofoh tries actually using the uboot.bin Mar 14 08:33:03 I found the mcbsp code in /sound/soc/omap Mar 14 08:33:19 Where would I look for the alsa code? Mar 14 08:33:21 I doubt it spits out a u-boot.bin Mar 14 08:33:30 it has been spitting out an u-boot.img for arges Mar 14 08:33:38 * fiveofoh checks again Mar 14 08:33:41 and uboot is the boot loader Mar 14 08:33:43 not the kernel Mar 14 08:34:56 Aha here we go Mar 14 08:34:59 In setup-scripts/build/tmp-angstrom_2010_x-eglibc/deploy/images/beagleboard Mar 14 08:35:03 I have uImage-beagleboard.bin Mar 14 08:35:12 And modules-3.0.23+-r117a-beagleboard.tgz Mar 14 08:35:31 So I lied, it's uimage.bin :P Mar 14 08:36:06 * fiveofoh takes a stab in the dark Mar 14 08:38:06 The angstrom build scripts appear to be composed entirely of patches that the scripts apply to a bunch of .tar.bz2 source files that they download Mar 14 08:38:08 Which makes sense Mar 14 08:38:17 But seems unfriendly to hacking Mar 14 08:38:18 Also Mar 14 08:38:27 patches are unfriendly to hacking? Mar 14 08:38:32 which planet are you from? Mar 14 08:38:34 Hahaha Mar 14 08:38:57 No, I understand the reasoning and it's great and makes sense and all Mar 14 08:39:30 fiveofoh: this has been debated here a lot, and both sides have the scars to prove it Mar 14 08:39:54 Which of all this has been debated? Mar 14 08:39:55 but he does not know about devshell yet... Mar 14 08:40:46 And koen, it just makes it harder to add your own patch if you don't actually have the whole sourcefiles all patched up Mar 14 08:41:25 fiveofoh: http://www.slimlogic.co.uk/2011/05/openembeddedangstrom-kernel-workflow/ Mar 14 08:41:30 Ooh Mar 14 08:41:52 (Also, my uimage-beagleboard.bin, copied to my SD as UIMAGE, appears to be working nicely Mar 14 08:42:21 fiveofoh: if you plan on working a lot on the kernel, just grab the git+patches into your own git and compile that standalone Mar 14 08:42:45 Well, I plan on working on the kernel as little as possible, but... :P Mar 14 08:42:49 all you need is the kernel source and the cross toolchain Mar 14 08:45:53 Where does the temporary working directory this fellow talks about come from? Mar 14 08:46:03 Ooh wait Mar 14 08:46:10 * fiveofoh tries running those commands Mar 14 08:48:09 Oh lordy, this will probably take a while, eh? Mar 14 08:49:01 spend it staring at alsa code :) Mar 14 08:49:16 specifically the beagle-alsa glue Mar 14 08:49:17 That's what I was thinking Mar 14 08:49:27 I just have to find the alsa code Mar 14 08:49:33 linux/sound Mar 14 08:49:46 yes, sound has its own top level folder Mar 14 08:49:47 Yeah, in the linux-3.1 tar I found? Mar 14 08:49:51 I noticed that Mar 14 08:49:53 Oddly enough Mar 14 08:50:03 thats says something about the state of sound support in linux..... Mar 14 08:50:08 It seemed a bit out of place :P Mar 14 08:50:20 own top level folder -> it can be GONE any day.... Mar 14 08:50:31 How nice Mar 14 08:50:45 Hokay Mar 14 08:59:17 * fiveofoh dawdles off to stare at some ALSA code Mar 14 09:05:27 anyone with experience with this card? http://www.amazon.com/SanDisk-Extreme-Performance-Memory-SDSDX3-008G-P31/dp/B002GEQDK4 Mar 14 09:05:40 it's extreme Mar 14 09:06:46 extreme > hardcore? Mar 14 09:07:24 yup i have used it Mar 14 09:07:38 hitlin37: was it an extreme user experience? Mar 14 09:07:54 That reminds me of a hair product I saw once Mar 14 09:08:04 this is THE card that always works on bb Mar 14 09:08:06 It was labelled "ultimate" (or some other such absolute adjective) Mar 14 09:08:12 But it was only two of three circles :/ Mar 14 09:08:17 ynezz: I would wait for the "Extreme Nexus S2" Mar 14 09:08:19 "Maximum" maybe? Mar 14 09:08:48 fiveofoh: there can alway be an ultimater product in the future.... Mar 14 09:08:53 Noooooooo Mar 14 09:08:58 until the ultimatest comes along Mar 14 09:09:24 But what then? Mar 14 09:09:32 superultimatest Mar 14 09:10:09 (Which reminds me of my astonishment that preantepenultimate is actually a word) Mar 14 09:10:24 hitlin37: so, what does that * means after that speed claim? :) "you can achieve this speed on 2nd Monday in January at 11pm" ? Mar 14 09:11:48 Here we are Mar 14 09:11:53 "Maximum hold" Mar 14 09:11:53 http://aussie.com/en_US/products/images/product_pages/aussome_volume/product_aussome_hairspray.png Mar 14 09:11:58 3/4 circles Mar 14 09:12:24 ynezz: it means you cannot sue them for the speed Mar 14 09:13:15 It's the "up to" in the product details Mar 14 09:13:16 :P Mar 14 09:13:34 lord british has already been there in the 80s/90s. ultima1, ultima2, ... Mar 14 09:13:51 so I need to make a gpio ?? if I want gpio1_1 what echo do i write Mar 14 09:14:21 harley: what does "ls /sys/class/gpio" get you? Mar 14 09:14:27 i use to boot angstrom on it,but never ran any speed test on it Mar 14 09:14:33 echo "168" > /sys/class/gpio/export Mar 14 09:15:05 ls /sys/class/gpio export gpio3 gpiochip0 gpiochip64 unexport gpio1 gpio33 gpiochip32 gpiochip96 Mar 14 09:15:30 mkay, so looks like as of now you have gpio1 and gpio33 available Mar 14 09:15:45 yes Mar 14 09:16:31 but then I look for 3.3v on pin 24.. nothing Mar 14 09:17:21 I want to set pin24 high with : echo "high" > /sys/class/gpio/gpio33/direction Mar 14 09:17:48 I think its the wrong gpio... is gpio33 = pin24 ? Mar 14 09:17:54 gpio1_1 Mar 14 09:18:14 Yeah, it should be Mar 14 09:18:30 gpio1 starts at 32 Mar 14 09:18:39 so 0=32, 1=33 Mar 14 09:18:46 goood Mar 14 09:18:51 And 1_1 looks to be at pin 24 Mar 14 09:19:02 What does cat /sys/class/gpio33/direction give you? Mar 14 09:19:15 and "cat /sys/class/gpio33/value" Mar 14 09:19:21 and gpio33 - made with the export Mar 14 09:22:44 so I can just do a echo "0" > /sys/class/gpio33/value and the pin24 will be low Mar 14 09:22:59 for me, gpio33 sets p8.28 high. Mar 14 09:23:54 oh nevermind, that's something else I have going. Mar 14 09:24:10 harley: That's the idea, but check to make sure your direction and value are set up right Mar 14 09:24:34 What do the cat commands up above give you? Mar 14 09:25:07 give 1 Mar 14 09:25:10 cats don't take commands Mar 14 09:25:47 and with a echo "0" > /sys/class/gpio/gpio33/value - the cat give me 0 Mar 14 09:25:56 its looks like its working Mar 14 09:26:06 Mkay, and direction? Mar 14 09:26:38 echo "0" > /sys/class/gpio/gpio33/direction Mar 14 09:26:43 Noo Mar 14 09:26:50 bash: echo: write error: Invalid argument Mar 14 09:26:51 cat /sys/class/gpio33/direction Mar 14 09:27:15 (Also, this is less typing if you cd to /sys/class and just do cat gpio33/direction) Mar 14 09:27:30 root@omap:/sys/class/gpio# cat /sys/class/gpio33/direction cat: /sys/class/gpio33/direction: No such file or directory Mar 14 09:27:50 cat /sys/class/gpio/gpio33/direction Mar 14 09:28:25 cat /sys/class/gpio/gpio33/direction #out Mar 14 09:28:41 so thats a output? Mar 14 09:28:46 yup Mar 14 09:28:52 Sorry for the typo there Mar 14 09:29:01 FWIW, that pin doesn't work for me either Mar 14 09:29:05 nP ;) Mar 14 09:29:10 So at this point, I'd just start testing pins and see if you find one that is on Mar 14 09:29:20 And see if it goes off when you tell it to Mar 14 09:29:20 :P Mar 14 09:29:33 But yeah, according to the docs as I read them it should be 24 Mar 14 09:29:47 yep.. we use the beaglebone as a DAQ for windmills Mar 14 09:30:16 Random fact of the day: "propreantepenultimate" is an actual word Mar 14 09:30:17 So I need to remote control the setup Mar 14 09:30:24 Thanks, 1800s Mar 14 09:32:50 gpio is on gpiochip32.. can I use that somehow ? Mar 14 09:33:00 gpio1_1 is on gpiochip32.. can I use that somehow ? Mar 14 09:34:55 harley: what do you mean? Mar 14 09:37:55 the dirs : gpiochip0 gpiochip32 gpiochip64 gpiochip96 - are they the hole chip ? there is 4 gpio? Mar 14 09:38:41 so I can use the gpiochip32 to control the gpio1_1 (thats on pin24) Mar 14 09:38:52 Those just give you an interface to chip stats Mar 14 09:38:54 No, I don't think so Mar 14 09:39:02 http://www.mjmwired.net/kernel/Documentation/gpio.txt#644 Mar 14 09:39:28 Less random source, with out nice anchor links: http://kernel.org/doc/Documentation/gpio.txt Mar 14 09:39:35 here's how to see all your GPIO info: cat /sys/kernel/debug/gpio Mar 14 09:40:03 i.e. what's exported, what's high/low Mar 14 09:40:10 Ooh handy Mar 14 09:40:14 yess!!!! Mar 14 09:40:16 direction too Mar 14 09:41:38 gpio-32 (sysfs ) in lo Mar 14 09:41:52 gpio-33 (sysfs ) out lo Mar 14 09:42:45 so you've exported those pins and gpio1_0 is in/low gpio1_1 is out/low Mar 14 09:43:32 so my gpio-32 is gpio1_0 Mar 14 09:44:18 why do I get 3.3volt on p8-25 if its is low Mar 14 09:46:07 Does flipping gpio33 back and forth change p8-25? Mar 14 09:46:35 It's not like docs have never been wrong before :P Mar 14 09:47:05 I've had some unexplainable trouble with some of the GPIO pins Mar 14 09:47:15 most be me doing something wrond.. Mar 14 09:47:21 most be me doing something wrong.. Mar 14 09:47:32 not necessarily. Mar 14 09:47:50 you are the experts ;) Mar 14 09:48:44 Haha well do this Mar 14 09:48:50 (And I'm hardly an expert) Mar 14 09:49:04 echo "0" > /sys/class/gpio/gpio33/value Mar 14 09:49:05 probe Mar 14 09:49:11 echo "1" > /sys/class/gpio/gpio33/value Mar 14 09:49:13 probe Mar 14 09:49:15 Does it change? Mar 14 09:50:13 (This is probing p8-25) Mar 14 09:50:31 p8-25 ? Mar 14 09:50:45 Yep, the one with the unexplained 3.3v Mar 14 09:50:46 thats gpio1_0 Mar 14 09:50:51 Says the docs Mar 14 09:51:41 Or try setting gpio-32 to output Mar 14 09:52:03 But I'd probe around to make sure gpio33 isn't going somewhere else Mar 14 09:52:08 set it to out ? Mar 14 09:52:38 gpio can be somewhere else ? Mar 14 09:52:44 Well does fiddling with gpio33 change p8-25? Mar 14 09:52:47 the gpio33 Mar 14 09:52:48 It shouldn't be Mar 14 09:52:49 But you never know' Mar 14 09:53:12 no .. still 3.3 volt Mar 14 09:54:04 Hmkay, well then yeah, try setting gpio32 to ouput Mar 14 09:54:41 Who knows, gpio32 might have a pull-up on it or some such (totally stabbing in the dark there) Mar 14 09:57:04 root@omap:/sys/class/gpio/gpio32# ls # active_low direction edge power subsystem uevent value Mar 14 09:57:19 so its active_low Mar 14 09:58:30 That's just for edge-stuff though Mar 14 09:58:41 oki.. Mar 14 09:58:46 just looking around Mar 14 09:58:48 It talks about that in the gpio.txt Mar 14 09:59:31 I think it's a pinmux issue Mar 14 09:59:32 I better read the http://kernel.org/doc/Documentation/gpio.txt more carefull Mar 14 10:00:06 harley: take a look at this: http://akademii.blogspot.com/2012/02/beaglebone-gpio-testing.html Mar 14 10:00:29 The docs say that it should be pinmuxed to GPIO by default Mar 14 10:00:39 But you can only trust docs so far :P Mar 14 10:01:56 Woah, there's userspace pinmuxing? Mar 14 10:01:58 Since when? Mar 14 10:02:05 yes.. that I will test... Mar 14 10:02:18 looks easy... Mar 14 10:03:01 yeah, and I've heard of some people having weird pinmux issues before Mar 14 10:04:35 Yes!!!! its working... in gpio1_0 Mar 14 10:04:50 great! Mar 14 10:05:02 I was missing the command : echo 7 > /sys/kernel/debug/omap_mux/gpmc_ad0 Mar 14 10:05:07 one click shopping ftw: http://www.amazon.de/ServicePack-Wiederherstellzeit-Machbarkeitsstudie-vorbehalten-Servicepartner/dp/B003Y3TVEG/ref=pd_sim_sbs_sg_2 Mar 14 10:22:25 thanks alot MattRichardson and fiveofoh ... Mar 14 10:22:37 No problem. Mar 14 10:24:46 the beaglebone will be in a 60Meter high windmill out at sea in the near future.....info : http://www.hornsrev.dk/index.en.html Mar 14 10:25:38 looks interesting! So it will be logging data? Mar 14 10:25:45 yes.. Mar 14 10:26:09 hmm, milled wind Mar 14 10:27:03 because we only got a data connection - I need to make a interface to control everything remote from my office Mar 14 10:27:23 and get data home Mar 14 10:27:32 that sounds pretty cool. I was just thinking about how BB is great for datalogging. using an Arduino you'd need to add so much to the arduino to do the logging. Mar 14 10:27:58 And yea, it's great for remote access Mar 14 10:28:11 You can SFTP in and get the log files. Mar 14 10:28:15 we added a AVRxxx and a Telit-modul for wireless Mar 14 10:28:24 when it needs a reboot, you have a small rowboat? Mar 14 10:28:29 av500: Hokay, found my linux kernel in setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/beagleboard-angstrom-linux-gnueabi/linux-3.0.23-r117a/git/ I think Mar 14 10:28:49 git status Mar 14 10:29:06 yeah... its a long swim to the windmill Mar 14 10:29:12 gives a million gives a whole bunch of changes, but whatever Mar 14 10:29:28 we use a Telit-board as a backup connection Mar 14 10:29:28 the changes are the applied patches I guess Mar 14 10:29:36 Ah that would make sense Mar 14 10:30:02 So at this point, the basic idea is make my changes, make them a patch, and everyone is happy? Mar 14 10:30:21 you could do that Mar 14 10:30:21 harley: sounds cool. Which telit? Mar 14 10:31:30 av500: Is there a better way? Mar 14 10:31:45 i did not say it was bad Mar 14 10:32:01 Oh I know, I just want to do it the right/best/whatever way Mar 14 10:32:05 there are many ways Mar 14 10:32:18 if your end goal is to add more patches in angstrom then yes Mar 14 10:32:18 MattRichardson: at my office I played with the RF (868) modul Mar 14 10:32:30 Heh my immediate goal is to get this thing working Mar 14 10:32:44 then just hack away Mar 14 10:32:45 So I can leave out the "make them a patch" bit at this point Mar 14 10:32:46 MattRichardson: the final version is going to the a longer range .. lige GSM or 3 Mar 14 10:32:58 just be carefull not to run some bitbakes that delete/overwrite that kernel Mar 14 10:33:31 harley: If you're able to, I'd love to see what the setup looks like in the end. Mar 14 10:35:34 sure.. If I remember .. I make apost about it to a beaglebone forum ;-) Mar 14 11:02:34 Yeah, I'm just gonna loop bitbake -c compile now Mar 14 11:02:48 Looks like there's already a driver for a cousin of the codec I'm using Mar 14 11:03:11 ak4671, I'm using ak5358b Mar 14 11:03:19 So shouldn't be toooooo painful :P Mar 14 11:17:36 My word, the three AKs that are in there are waaaaay more complicated than mine Mar 14 11:18:48 AK47 is quite simple Mar 14 11:28:43 Hi, I'm trying to open bone schematic (orcad - DSN) file and it gives me "Attempt to read a design file which is not supported by this version Mar 14 11:28:43 of database." Does anyone know any alternative ? If someone can save as to older version of orcad using save as option n share, it will be great. Mar 14 11:36:34 greetings, has anyone experienced serial port bitrate failure with 3.2.x series kernel on omap3 (BeagleBoard Rev.C4)? I've got this boar running on 2.6.32.8 kernel and there it works OK - when I set UART to 1MBit/sec it is as it should, but on 3.2.8 kernel I have 1.25MBit/sec instead of 1MBit/sec. Mar 14 11:37:30 at lower bitrates like 115200 looks like there is proper speed set up with this 3.2.8 kernel. Mar 14 11:57:10 so, 3.2.8 gives you 25% more for free Mar 14 11:57:22 and you complain..... Mar 14 11:58:36 av500: Yeah, my codec is literally just an I2S bus with four pins for config, that you just pull low/high :P Mar 14 11:58:53 None of this i2c to communicate, registers, extra features, volume control Mar 14 11:59:43 * fiveofoh realizes you were probably referring to kalashnikovs Mar 14 12:04:54 fiveofoh: my favorite I2S stereo dac is the TDA1543, 8 pins :) Mar 14 12:09:04 http://www-user.tu-chemnitz.de/~heha/Mikrocontroller/TDA1543-1.gif Mar 14 12:09:27 Oh wow Mar 14 12:09:30 That is minimalistic Mar 14 12:09:32 Nice Mar 14 12:09:32 yep Mar 14 12:09:55 Yeah, this one is 16 pins Mar 14 12:09:56 So tsice that Mar 14 12:10:03 *twice Mar 14 12:10:15 But certainly not 34 or 57 or 64 or whatever those other ones are :P Mar 14 12:10:50 Oh and this is an adc Mar 14 12:10:55 ah Mar 14 12:11:43 I'm trying to decide how best to approach the codec driver for it, I'm assuming it'll be pretty basic since it's just straight I2C Mar 14 12:12:17 I2S Mar 14 12:12:18 no? Mar 14 12:12:24 Heh yeah Mar 14 12:12:30 You think I'd have gotten that distinction down by now Mar 14 12:19:11 hmm, 10 pieces for 10€, I am tempted Mar 14 12:21:48 http://www.pavouk.org/hw/spdifdac/spdif_dacsch.png Mar 14 12:30:14 as for my uart bitrate problem - I see that in 2.6.32.8 the serial ports are not using "omap-serial.c", in 2.6.39 i can see it being used (as well as in 3.x series) Mar 14 12:42:43 why does all linux code examples for beaglebones in JavaScript, why not in C? Mar 14 12:43:36 beagle people love web technologies Mar 14 12:43:42 :S Mar 14 12:43:43 C is obsolete in 2012 Mar 14 12:44:00 use A Mar 14 12:44:09 doesn't matter, there won't be a 2013 anyway Mar 14 12:44:19 enjoy your javascript while you still can Mar 14 12:44:24 going directly to 2014? Mar 14 12:45:10 hm, how come, that there's no 2013? I've can here with beans and there's "best before: 12/2013" :P Mar 14 12:45:31 it'll be good forever! Mar 14 12:45:39 Probably some end-of-the-world prophecy expires this year Mar 14 12:45:50 eaglebone: in any case, if you look around, you'll also find examples in "C" Mar 14 12:46:11 what language is better to type codes? Mar 14 12:46:29 morse Mar 14 12:46:32 for reliability and robustness Mar 14 12:46:52 morse with fec Mar 14 12:47:04 The best language to pick is one that you have been using 10 years, have deep knowledge of and fits the use-case perfectly Mar 14 12:47:37 * av500 is looking for a developer with 10ys of android experience Mar 14 12:47:58 I'm working on a way to write instructions in plain Latin Mar 14 12:48:10 but would you take 10 android devs that have 10ys of combined experience? Mar 14 12:48:43 I woul fear they would cancel each other out Mar 14 12:49:57 mvista had job postings like that back in 2000..looking for 10 years linux experience Mar 14 12:50:14 not surprising Mar 14 12:50:28 engineering probably asked hr to get someone with linux experience Mar 14 12:50:36 then hr slapped on the standard 10y requirement Mar 14 12:50:39 someone older than 10ys Mar 14 12:51:07 * av500 sadly has 10ys of TI SoC experience... Mar 14 12:51:26 they did add a lot of corporatism with all the VC cash that year Mar 14 12:51:51 av500, wow, I'm sorry Mar 14 12:52:36 mdp: please, donate instead of flowers Mar 14 12:52:44 :) Mar 14 12:52:57 av500: donate more TI SoCs? Mar 14 12:53:05 yeah! Mar 14 12:53:13 "av500 memorial mental health foundation" Mar 14 12:53:32 does the frame buffer memory need to be physically contiguous? I think it should be virtually contiguous Mar 14 12:53:50 * mdp notes that the channel is being watched and he probably is not permitted to joke about such things Mar 14 12:54:05 just curiosity, where do you work as you are that experienced? Mar 14 12:54:10 NotTooDumb3: it depends Mar 14 12:54:23 depends on what factors? Mar 14 12:54:44 NotTooDumb3: you only need physically contiguous if your h/w requires it Mar 14 12:55:01 and the omap3 hw requires it Mar 14 12:55:21 mru, assuming you are using some on chip display hw... Mar 14 12:55:40 what determines the dma able memory of a device? is that exactly what we mention in bootargs with mem= argument? Mar 14 12:55:48 NotTooDumb3: if you are using a non-memory mapped display interface…..then YMMV Mar 14 12:56:04 mdp: what else would you use, a remote framebuffer attached over spi? Mar 14 12:56:07 even then you may want a dma-able buffer Mar 14 12:56:37 mru, certainly..but even then it may need to be contiguous since you generally want to dma there too Mar 14 12:56:47 scather, gather Mar 14 12:56:57 chanied dma Mar 14 12:57:00 chained Mar 14 12:57:01 hunter gatherers Mar 14 12:57:07 no need for contiguous Mar 14 12:57:38 omap3 has rather poor support for chained dma Mar 14 12:57:46 when i try to allocate dma able memory, i see the device's dma memory as zero though i mentioned dma=640M in bootargs..how to check where i am doing wrong? Mar 14 12:57:48 omap4 can do it Mar 14 12:57:50 extra kudos for a dma that can write cpu registers too Mar 14 12:58:06 dma can write dma control registers... Mar 14 12:58:06 av500, upstream driver may prevent "fancy" stuff like that :) Mar 14 12:58:20 mcspi is pretty dumb, fwiw Mar 14 12:58:21 mdp: upstream is where patches go to die? Mar 14 12:58:36 sometimes Mar 14 12:59:00 NotTooDumb3: kmalloc is not good enough for you? Mar 14 13:01:21 who is the admin of this room? Mar 14 13:01:50 nobody Mar 14 13:01:57 wanna file a complaint? Mar 14 13:02:08 no just wonder Mar 14 13:02:30 usually there are admins on IRC rooms Mar 14 13:02:55 jkridner is probably writing some javascript and not paying attention to the room Mar 14 13:03:27 is he the admin of all server? Mar 14 13:03:33 he is god Mar 14 13:03:37 :) Mar 14 13:03:42 The is heaven and earth Mar 14 13:03:48 Alpha and omega Mar 14 13:04:01 av500 are you from stockholm? Mar 14 13:04:04 he is also Luke's true father Mar 14 13:04:11 eaglebone: not if I can prevent it Mar 14 13:05:24 eaglebone: but that is the irc server, not where I am from Mar 14 13:05:32 yeah Mar 14 13:05:42 eaglebone: you are not from Oregon either but from malmö Mar 14 13:05:49 malmö :) Mar 14 13:05:51 sweden Mar 14 13:06:28 connection to the servers are wierd Mar 14 13:06:39 I could connect to the server in stockholm rather than OR Mar 14 13:06:49 consider the paradox, how can one person be both jkridner AND boris houndleroy at the same time? Mar 14 13:07:05 mdp: some are even 3 in 1 Mar 14 13:07:07 think about it…really tugs at your notion of the universe and spirituality, eh? Mar 14 13:07:28 av500, good…you're following along here in philosophy 101..ok. :) Mar 14 13:07:28 father, son and holy mackerel Mar 14 13:08:01 holy trout slapping Mar 14 13:08:08 amen Mar 14 13:12:09 hrm, so maybe we could do a LatinScript for beaglebone…."lux sit" can be the led API Mar 14 13:12:45 everybody wants to code in "plain english" so we'll give them something better! Mar 14 13:13:00 nucleus non tabernus! Mar 14 13:13:28 LOL Mar 14 13:15:37 look at it this way, it's a dead language, just like C :) Mar 14 13:40:17 mdp, i need to write physical address of the buffer i allocate, in the base address register of window..so kmalloc alone is not sufficient for me.. Mar 14 13:40:42 there is ways to get that address Mar 14 13:40:56 NotTooDumb3: read the DMA API docs Mar 14 13:41:07 it's all been done before…thousands of times Mar 14 13:41:15 per second Mar 14 13:41:17 thousands of examples in the kernel drivers Mar 14 13:42:50 isn't using dma_alloc_coherent better than using kmalloc along with another dma API to convert virtual to physical address? Mar 14 13:43:12 then use dma_alloc_coherent () Mar 14 13:44:42 i am trying to use dma_alloc_coherent (), but it returns NULL, and when i try to debug i found out the device's dma able memory as zero..but i gave mem=640M in bootargs.. Mar 14 13:46:25 is the device's dma able determined from mem= argument we give in boot args? Mar 14 14:31:07 is this a physical address? 1f81c000 Mar 14 14:31:27 <_av500_> I find it pretty nondescript Mar 14 14:32:53 I used this API virt_to_dma after kmalloc and that is the address returned..it might be physical addr but not sure.. Mar 14 14:33:57 and though i get a physical address now, kernel is still crashing little down the boot process..i am confused how this alloc is causing a crash some where else Mar 14 14:34:22 <_av500_> its not a phys addres Mar 14 14:34:30 <_av500_> at least it is not in sdram Mar 14 14:35:40 do i need to give phy addr only for base addr reg? or can it be any dma able address? does1f81c000 appear to be a dma able memory? Mar 14 14:36:10 are you sure you have the skills required for kernel hacking? Mar 14 14:37:07 at least a badge Mar 14 14:37:20 mru: like listening to humppa music? Mar 14 14:37:48 LetoThe2nd: if that's what it takes Mar 14 14:39:50 mru: i'm sure it helps. Mar 14 14:57:13 * mranostay yawns Mar 14 14:57:21 happy half tau day everyone Mar 14 14:59:32 happy RPi day! Mar 14 15:01:41 +1 Mar 14 15:02:23 this whole tau vs 2pi thing really goes to show people will bitch and moan about anything :) Mar 14 15:06:24 Am I correct to think that I can do anything that is in the board file in a kernel module? Mar 14 15:06:34 mranostay: most formulas make a lot more sense with tau than with pi Mar 14 15:06:59 jsabeaudry: yes, but that doesnt make it a good idea :) Mar 14 15:07:33 hmm, boot a generic kernel and then load the beagle.ko Mar 14 15:07:52 av500: trolling already? :) Mar 14 15:07:58 koen, in the case of setting up the gpmc port for a device, would you recommend doing it in the board file or in the kernel module for the device? Mar 14 15:08:10 you startau'd it Mar 14 17:32:43 hello Mar 14 17:33:05 My home computer is disassembled right now so I am on my touchpad Mar 14 17:33:47 awesome-o Mar 14 17:34:20 yeah. Ever since I put Cyanogenmod 9 on this (ice cream sandwich) I am happy as a clam with it. Mar 14 17:35:29 CM7 on it was pretty rough. that's what ... android 2.2 or something i don't even know Mar 14 17:35:47 all I know is it kinda sucked. But with this ICS even though it's still "alpha" it is stable and has all the nice new ics features. Mar 14 18:31:47 mdp: I was not paying attention... what did I miss? Mar 14 18:32:16 some discussion about the paradox of your dual identity Mar 14 18:33:00 wow, I have many identities, even god! Mar 14 18:33:28 Boris is just a role I play on the Intertubes. Mar 14 18:33:36 jkridner_: howdy boris! Mar 14 18:34:18 so far, I believe only Phillip has braved the full-body Boris skin in the physical realm. Mar 14 18:41:43 jsabeaudry: which kind of chip are you going to connect to gpmc? Mar 14 18:42:05 SilicaTouchpad: soft SPI in the pruss? congrats! Mar 14 18:43:49 dwery, Xilinx Spartan 6 Mar 14 18:45:05 uh nice! Mar 14 18:45:34 (I will probably ask another dozen of times...) Mar 14 18:45:54 yeah it looks good Mar 14 18:46:03 don't worry about it I also keep asking the same questions Mar 14 18:46:07 it's sort of a 4 bit wide spi ... four data inputs, one clock Mar 14 18:46:36 Next week I will let you know how fast we can make it go. For this specific application we're limited to the 20 MHz the A/D converters can go Mar 14 18:47:53 great. Mar 14 18:54:39 hmmmm Mar 14 18:57:16 mmmmh Mar 14 18:57:50 when we actually went through the pin list of mappable pru egpio pins and compared it to the bone srm we found out we're not in as bad shape as i thought Mar 14 18:58:01 there really are a good number of pins available. Better prospects for pru1 than pru0 Mar 14 19:00:52 what are PRU and PRUSS ? Mar 14 19:01:53 source of major frustration for lots of folks Mar 14 19:02:16 * Russ immediately thinks of ROUSs Mar 14 19:04:26 programmable register unit solid sate Mar 14 19:04:56 think Real Time Controller. Mar 14 19:04:58 embedded uc in am335x Mar 14 19:05:19 Programmable Realtime Unit. Mar 14 19:05:36 ka6sox, thank you! Mar 14 19:16:53 SilicaTouchpad: if you do a real 4xSPI I could maybe write a kernel driver for it Mar 14 19:17:28 so we can have more /dev/spidev complaints :D Mar 14 19:18:59 <_av500_> Probably Redundant Unit of Substantial Swearing Mar 14 19:20:32 Problematic Relatively Useless Solid State Mar 14 19:22:42 though from what i have followed on the topic, _av500_: has a very good description Mar 14 19:28:50 dwery: my hobby is *complaining* not *receiving* complaints!! Mar 14 19:28:57 But thanks, I'll jump on the list and complain about spidev Mar 14 19:29:32 haha Mar 14 19:29:35 :D Mar 14 19:29:40 I am amused that you guessed part of the name was "Solid State" Mar 14 20:18:48 that PRUSS is loaded with features Mar 14 20:20:26 we talked about it here nonstop for days a few weeks ago Mar 14 20:27:37 yep, i was here, just now lookinf at datasheet Mar 14 20:27:41 looking Mar 14 20:27:51 she's a nice girl Mar 14 20:27:56 but very demanding Mar 14 20:28:22 is the pruss like a fpga with a microcontroller on it or just a microcontroller with dma and lots of io switches ? Mar 14 20:28:38 it's more like a micro Mar 14 20:28:42 <_av500_> noyes Mar 14 20:28:48 k Mar 14 20:29:11 like a smaller arm to me Mar 14 20:29:24 so its like a m3 ? Mar 14 20:29:34 <_av500_> its like a strange micro they teach you at uni as an exercise Mar 14 20:29:55 _av500_: for me that was intel 8085 Mar 14 20:30:06 for me it was mostek 6502 Mar 14 20:30:34 well perhaps its not to far from a PIC16 or something in that order.. Mar 14 20:30:36 MIX! Mar 14 20:30:43 but the teacher had very limited knowledge of it for the decades he taught it Mar 14 20:31:07 unsolo_: looks far better than a PIC16 Mar 14 20:31:14 in the PRUSSv2 it also has a MAC !!! Mar 14 20:31:29 SilicaTouchpad: what type of MAC? Mar 14 20:31:39 what! no more making up mad addy's? Mar 14 20:31:45 s/mad/mac Mar 14 20:31:52 * djlewis waits Mar 14 20:32:00 the type that multiplies ... and accumulates Mar 14 20:32:19 oh, we still make up mac addy's Mar 14 20:32:19 ahh but probably not in a float and probably not in a vector style either Mar 14 20:32:27 I'm afraid if I comment on djlewis's remark it would only serve to encourage him! Mar 14 20:33:27 <_av500_> a big mac? Mar 14 20:33:59 _av500_: that would be the one in the neon Mar 14 20:34:23 I heard NEON was uselss and you shouldn't enable it Mar 14 20:34:29 <_av500_> yes Mar 14 20:34:30 provided the neon has madd *multiply and add i prefer that name over mac Mar 14 20:34:49 Crofton|work: oO Mar 14 20:34:52 <_av500_> Crofton|work: everytime you use it, you hurt a strawberry Mar 14 20:34:54 I heard the pontiac aztek was so badly rejected by the american public that the only way to make it less popular would have been to have a swastika painted on it from the factory Mar 14 20:34:58 <_av500_> or a gooseberry Mar 14 20:35:01 <_av500_> or some berry Mar 14 20:35:14 sadly, that might make it more popular :( Mar 14 20:35:31 the aztec... one of chris bangle's finest moments Mar 14 20:35:36 doesnt the ffmpeg code for the cortex-a8 use it bigtime ? Mar 14 20:35:39 todays youth would flock to it, along with a few extremists Mar 14 20:36:03 Crofton|work: i honestly would struggle to se why the neon would have a negative impact Mar 14 20:36:19 the vfp is more of a topic one could perhaps discuss Mar 14 20:36:23 idunno you know Mar 14 20:36:31 isnt mru the only person alive that can program it Mar 14 20:36:32 i watch all this "why not an m3" talk against the pru and i kind of bristle Mar 14 20:36:41 djlewis: lol Mar 14 20:37:02 The PRU is pretty nice, the learning curve is relative short at least for the simple assembly it has Mar 14 20:37:17 * djlewis was referring to the NEON Mar 14 20:37:20 hmm i should learn some.. Mar 14 20:37:33 djlewis: i dont get how programin the pru is easier than using the neon Mar 14 20:37:35 the hardest part of this whole thing has been understanding the crazy pinmux stuff (which really isn't all that crazy) and the whole SYSCONFIG problem Mar 14 20:37:40 no forget haha Mar 14 20:37:44 m3 would be easier though... wouldn't have to wait on TI for assembler Mar 14 20:37:47 wow. communications breakdown. Mar 14 20:38:05 reboot Mar 14 20:38:10 we'd know the instruction encoding Mar 14 20:38:17 It'd be easier in the sense that you could use a C compiler on it too, but I'm not sure that's really an advantage Mar 14 20:38:30 ok that's a point there about the instruction encoding. Mar 14 20:38:35 now if you could use basic . . . Mar 14 20:38:41 hmm Mar 14 20:38:45 * djlewis waits again . . . Mar 14 20:39:00 i really want to play with that pruss now but i have no idea what i would want it to do Mar 14 20:39:07 well i have some ideas.. but.. Mar 14 20:39:28 maybe add more pwms Mar 14 20:40:15 do a sound driver in it perhaps.. if there is some dacs attached to it Mar 14 20:40:59 do a pci-e interface is probably above what it can do Mar 14 20:41:21 it apears similar to the Borg queen. On top of the thinking heap. Mar 14 20:42:12 <_av500_> wasnt that the Fraggles? Mar 14 20:42:19 haha Mar 14 20:42:22 SilicaTouchpad: "every fix is just one bit, the problem is how to find that one bit" Mar 14 20:43:10 SilicaTouchpad: you're making me remember that quote from an old timer from when I was a pup Mar 14 20:43:33 haha Mar 14 20:43:41 does the pruss have like a eeprom storage or something or do you have to program it whenever you want it to do something remotely useful Mar 14 20:43:50 i'm just saying the kinds of real time tasks I want to perform on this thing I probably wouldn't write in C anyway. Mar 14 20:44:07 no it has dedicated blocks of instruction ram; you load it using mmap Mar 14 20:44:16 <_av500_> mdp: and then there's the proven practice to use random hex values instead of defines to make that extra hard Mar 14 20:44:38 as long as the PRU is not active, you can access its instruction memory via L3 Mar 14 20:44:51 we were having a discussion about the D0/D1 situation with am335x McSPI and the spi-omap2-mcspi.c driver and how the TRM figure is misleading since it's not clear that it's just showing "one application" of D0/D1 to MOSI/MISO.. Mar 14 20:44:57 i.e. it's in the global address space visible to the cortex Mar 14 20:44:58 <_av500_> writeb(0x34895349389, 33986379); Mar 14 20:45:17 made me think of how hard it is for customers to deal with that Mar 14 20:45:19 can PRU run with the rest of the SoC powered down? Mar 14 20:45:28 can it wake up the a8? Mar 14 20:45:38 _av500_, we call that, "job security" Mar 14 20:45:41 That's theoreitccally one of its uses Mar 14 20:45:46 mdp: haha Mar 14 20:45:55 yeah, a built in uc is really handy for that kind of stuff Mar 14 20:46:17 but to bea ble to talk to stuff it has to have the interconnects up Mar 14 20:46:21 I wonder how low power they can be Mar 14 20:46:27 jay6981: depends on how much it drains Mar 14 20:46:32 <_av500_> can one pru wake the other? so they can both jump on the A8 like my kids at sunday morning? Mar 14 20:46:46 I think that these 'smart power' modes are supposed to facilitate that, but my experience so far is that if you enable smart power, the interconnection just doesn't work at all. Mar 14 20:46:48 hopefully less than a PIC24 Mar 14 20:46:52 but one would asume the pru can irq wait like all the other irQ\s in the thing Mar 14 20:46:59 *sort of* Mar 14 20:47:06 irq wakeup not wait Mar 14 20:47:14 yeah. no. no interrupts. it busywaits. Mar 14 20:47:24 There's a "wait for event" instruction in PRU V2 Mar 14 20:47:26 SilicaTouchpad: i think that happened because it was idle Mar 14 20:47:30 but I think it's still a busywait. Mar 14 20:47:31 SilicaTouchpad: i was thinking of the waking up the A8 Mar 14 20:47:41 yeah. well hm Mar 14 20:47:42 SilicaTouchpad: so kernel side stuff…where is that wrt hvaibav's beaglebone tree. Mar 14 20:48:10 hrm i am not in front of my computer, it's uio_pruss.c in maybe mach-omap ? Mar 14 20:48:15 or drivers ? i can't remember sorry :( Mar 14 20:48:21 SilicaTouchpad: ok, so everything is ready to go? :) Mar 14 20:48:54 i don't think so, he said "your patch is not necessary" Mar 14 20:49:11 meaning he fixed it in his kernel "another way" Mar 14 20:49:22 so how/when that flows from his kernel into angstrom = mystery to me Mar 14 20:49:40 so the PRU runs off of CLKOUTM4 Mar 14 20:49:48 If the L4/L3 are up Mar 14 20:49:50 ahh, so pruss pinmuxing, hwmod entries, and uio_pruss.c are all in his tree I guess then Mar 14 20:49:55 couldn't the PRU just cut the Cortex's clock? Mar 14 20:50:08 oh, ok no Mar 14 20:50:25 once you configure the main cpu pinmu,x, you might have to configure the internal pinmux Mar 14 20:50:43 typically you would write a little C program that runs on the A8 that as part of its function loads the program into the PRU Mar 14 20:50:43 I just haven't seen any patches come across the list, wasn't sure if it was at that stage yet Mar 14 20:51:01 right, I've used pru on am180x Mar 14 20:51:02 then you decide to either have the PRU configure the PRUSS internal pinux, or you have your C program do it from the A8 over L3 Mar 14 20:52:00 ok, and he must have that hwmod stuff right in his tree Mar 14 20:52:02 cool Mar 14 20:52:45 he has something in there that supposedly takes it out of reset when you enable his clock Mar 14 20:53:19 i don't know Mar 14 20:53:27 let me tell you about my experience with him, its very brief. Mar 14 20:54:05 I said "when you unload the module it doesn't put the PRUSS back into reset" Mar 14 20:54:10 he said "I tested it and it works fine" Mar 14 20:54:21 I said "It doesn't seem that way to me, try rmmod uio_pruss" Mar 14 20:54:28 He said "I compile it statically" Mar 14 20:54:45 worksforme, so fuck off! Mar 14 20:54:57 I said "Then how do you know what it does in module_exit if you don't have it in there as a module that you can remove?" Mar 14 20:55:15 turned out to be a misunderstanding, he didn't really meant to assert that he tested THAT. Mar 14 20:55:41 Though I thought my question was fairly clear, but it sounds like he's a pretty busy guy, probably thought I was some kind of n00b Mar 14 20:56:22 anyway we have our angstrom patch and it works for us; we posted it to the beagle list and koen knows about it Mar 14 20:56:41 I'm working on posting my modified-and-improved pruss userspace library. Mar 14 20:56:46 well, he's pretty buried with tryin to get am335x upstream Mar 14 20:56:48 I just am without a desktop for another day thanks to this renovation Mar 14 20:57:12 yeah i know Mar 14 20:57:18 and I do have a workaround for *my* problem Mar 14 20:57:29 it does help that it's a massive change in architecture from 3430 and stuff so it's a huge effort Mar 14 20:57:32 s/does/does not/ Mar 14 20:57:59 we're lucky he volunteered to maintain an integration tree for beaglebone in the mean time Mar 14 20:58:12 yeah. Mar 14 20:58:30 also the pru shouldn't be his priority, he should worry about things MOST people care about Mar 14 20:58:34 not good when you're chasing away people who are trying to help Mar 14 20:59:00 we all chase away people sometimes :) Mar 14 20:59:08 iindeedd Mar 14 20:59:27 s/people/capable people Mar 14 21:00:13 maybe he's just following the official policy that "commoners" can't program the PRU Mar 14 21:00:16 too difficult Mar 14 21:00:22 So hvaibav's tree is the most up to date (with all patches applied) ? Mar 14 21:00:55 ah... being sold short is even better :) Mar 14 21:01:07 It's true commoners can't do it, but at some point someone has to turn from a commoner to a whatever-it-is that you become when you can do PRUs Mar 14 21:02:07 That's horse shit that it's too difficult Mar 14 21:02:13 it's the simplest assembly language I have ever used Mar 14 21:02:28 it's about 10x easier than stupid PIC10/12/14/16 Mar 14 21:03:13 jwinnebeck, Is mmaped IO possible directly from Java (without jni)? Mar 14 21:03:25 Yes and no Mar 14 21:03:39 if their excuse is 'we don't want to tell you so you buy our software" I would respect that for its honesty, but "it's too hard" is crap Mar 14 21:03:42 There is an FileChannel.map command which gets you a buffer Mar 14 21:03:44 it does call mmap Mar 14 21:03:49 However it doesn't work on /dev devices Mar 14 21:03:51 <_av500_> usign jni? Mar 14 21:04:04 jsabeaudry: it's supposed to be the canon single tree until mainline can be that tree Mar 14 21:04:15 you know, red2 tried using the gpio event interface from java using nio select and it failed miserably Mar 14 21:04:28 And it's because Java calls File.length on it first, and the Oracle JVM at least returns 0 for the length of seemingly anything that's not a normal file Mar 14 21:04:44 so Java fails the map call saying there's no valid part of the file to map and doesn't even try the mmap syscal Mar 14 21:04:48 jsabeaudry: I'm still rebasing my own driver work to it..kinda stalled due to lack of time atm :) Mar 14 21:04:58 I guessed this based on experimentation and strace outputs Mar 14 21:04:58 hm Mar 14 21:05:01 so I haven't personally verified that it works nicely for me Mar 14 21:05:09 were you mmapping the pruss to do this? or something else in /dev ? Mar 14 21:05:26 jwinnebeck, wow, so pretty much useless in practice Mar 14 21:05:38 woah Mar 14 21:05:40 you know what Mar 14 21:05:41 I don't know how OpenJDK reacts. I did for my master's project a database that uses partitions directly through /dev Mar 14 21:05:48 I think I just fgot an idea how to fix this problem Mar 14 21:05:57 And I noticed that GCJ and (at the time Sun) Oracle JVM were very different Mar 14 21:06:07 mdp, great, will transmit info to arch folks, they are still using koen's tree, the beaglebone3.2 branch Mar 14 21:06:20 So I would try this on openjdk if you are using it jsabeaudry Mar 14 21:06:25 I wonder if I could modify uio_pruss.ko to make it override the stat interface and report a correct "file" size Mar 14 21:06:26 If you do, let me know the result Mar 14 21:06:27 jsabeaudry: that was announced on the list Mar 14 21:06:46 I'm just repeating information, not the official source :) Mar 14 21:07:08 oh no, you said it, you own it. Where do we send complaints so that you receive them most efficientlyu? Mar 14 21:07:35 jsabeaudry: I know that RandomAccessFile does work Mar 14 21:07:41 So that uses fseek and fread Mar 14 21:07:50 What I don't know is why that would or would not work Mar 14 21:07:50 mdp, I honestly haven't figured out google groups, the order of things is not intuitive to me Mar 14 21:07:55 to be honest I haven't tried it Mar 14 21:08:11 do you HAVE to use mmap with the UIO driver? Mar 14 21:08:17 Maybe you do... I dunno Mar 14 21:08:17 we could make a character mode driver as well that supports seekk and read (or write) to do this Mar 14 21:08:19 bu yeah Mar 14 21:08:26 jsabeaudry: https://groups.google.com/forum/#!msg/beagleboard/gjLyY3cVCc4/UUmGKCnddgwJ Mar 14 21:08:27 you have gto use mmap to use it as it exists today Mar 14 21:08:34 But RAF works on files like /dev/sda Mar 14 21:08:48 probably would work on /dev/mem too Mar 14 21:09:06 jwinnebeck, I'll probably write a driver that will expose procfs stuff so it's easier to handle from a JVM Mar 14 21:09:17 jsabeaudry: I despise it but it's where the list is…read it in mutt and forget about google groups Mar 14 21:09:31 if you are going to do that, what I would do is just add read() write() and seek() to the current driver Mar 14 21:09:39 I'm pretty sure you can do that even within the UI framework Mar 14 21:09:52 If you can't, then I say scrap the UIO framework entirely, and just write a charactger mode driver that does it Mar 14 21:10:21 The thing is, expect it to be slower. But if you're using it mainly to load 8KB of IMEM? Who gives a crap Mar 14 21:10:41 The only thing that the UIO framework really does for you is offer standard semantics for handling events. Well geuss what. You don't need that. Mar 14 21:10:44 Well SilicaTouchpad, if my theory is right you can just add a stat Mar 14 21:10:55 uyeah. Mar 14 21:11:02 SilicaTouchpad: fwiw, people tend to make those "too complicated" comments when the support load is expected to be high Mar 14 21:11:25 so *I *think* you can add stat to a UI O drover beacuse a UIO driver is just a character mode driver with some undelrying framework Mar 14 21:11:30 some semis do this with their jtag scan chain info, fwiw..for the same reason Mar 14 21:11:30 If that's not the case, Mar 14 21:11:32 the thing is, Mar 14 21:11:52 yuou could just make a character mode driver that supports mmap() read() write() seek() stat() .. and have one driver that can do everything Mar 14 21:11:55 honestly Mar 14 21:12:04 I think having a cahracter mode driver is a better thing to do anyway! Mar 14 21:12:12 what if I made a driver that was /dev/pru/** Mar 14 21:12:30 and my driver had files like: /dev/pru/imem0 /dev/pru/imem1 /dev/pru/dmem0 /dev/pru/dmem1 /dev/pru/dmem2 Mar 14 21:12:46 then you could take your PURRU progam and say: cat mypruprogram.bin > /dev/pru/imem0 Mar 14 21:12:57 Wouldn't that be easier than having to dick around with UIO? I sure think so Mar 14 21:13:34 then you make one that's /dev/pru/event and you impelment the 4-byte-read event semantics of UIO, nothing wrong with those at all Mar 14 21:14:05 I think all this would be a lot easier. Who's with me!!! Mar 14 21:14:49 sounds nice Mar 14 21:15:28 the only thing that bothers me is how it should tie in with hwmod or whatever to figure out what resources are there and where they are located, rather than hhaving to have big switch statements etc. Mar 14 21:15:32 oh yeah that's my other complaint Mar 14 21:15:52 the uio_pruss.ko driver as is should actually look at the REVID in the PRU and complain if it is something unexpected Mar 14 21:16:17 this dog is bored out of its mind so I am going to take it for a walk then feed it, i shall return! Mar 14 21:24:49 happy doggie :) Mar 14 21:36:34 The pwm drivers are not in hvaibhav's tree? (ecap and ehrpwm) Mar 14 22:08:44 jsabeaudry: I guess not, interesting. Mar 14 22:11:27 SilicaTouchpad: I gotta say, since I once reviewed the pruss support submitted to staging for am180x, that I think the uio_pruss.c driver is the wrong approach. It should be split into a core pruss mfd driver..and then uio_pruss.c is a client to that core mfd driver. the mfd driver would basically be the resource allocation hub to handle N prus and handle kernel apis to alloc/dealloc precious PRU resource wanting to be used by the client drivers Mar 14 22:13:19 mdp, agreed. Mar 14 22:13:54 mdp, Perhaps those drivers have been removed from the patch list Mar 14 22:14:12 jsabeaudry: patch list? Mar 14 22:15:13 mdp, meta-ti/recipes-kernel/linux/... Mar 14 22:15:59 jsabeaudry: I'm pretty sure koen uses both of those drivers in his applications so they would be in the angstrom kernel recipe..he's cited them a few times to me Mar 14 22:16:41 mdp, they are in the angstrom kernel for sure as my last opkg upgrade added them Mar 14 22:16:53 ok, cool, that jives with what I hear then Mar 14 22:17:10 I'm not sure what the flow is into hvaibhav's kernel Mar 14 22:17:15 basically I'm searching for a repo with all patches applied Mar 14 22:17:25 perhaps koen needs to submit the patches to the list :) Mar 14 22:17:26 * _av500_ goes to change dsl router Mar 14 22:17:44 keeping in mind that both of them are unacceptable upstream Mar 14 22:18:01 why is that? Mar 14 22:18:27 they really wish for somebody to rewrite them into shauer's pwm subsystem that has some momentum now for replacing the silly pwm lib Mar 14 22:19:05 and bgatliff's competing pwm subsystem seems to have lost…that is what the ehrpwm driver is based on Mar 14 22:19:59 and, I think that means that ecap would need extensions proposed to shauer's pwm system to handle capture devices to be acceptable Mar 14 22:20:09 basically, these drivers could use a friend Mar 14 22:20:48 yeah ok Mar 14 22:20:55 the only thing i say though is Mar 14 22:21:04 well two things Mar 14 22:21:20 First, you can't really handle the PRUs separately Mar 14 22:21:29 well you can but I think you're asking for trouble if you do Mar 14 22:21:49 I've been thinking it could be a nightmare, yes Mar 14 22:22:00 yeah. They're too connected. Mar 14 22:22:09 They share a common SYSCONFIG for starters, a common eCAP Mar 14 22:22:26 and honestly I'm perfectly OK with having thhe kernel be completely unaware of the PRU's eCAP and UART Mar 14 22:22:45 _av500_: fed up with constantly turning wifi off and on? ;) mine 'bricked' itself during its firmware update today Mar 14 22:22:55 I kind of like the fact that I can make a timer out of the eCAP without having to allocate one from kernel space, then somehow communicate to the PRU which timer it is and where to find it Mar 14 22:23:20 especially on the am335x where you can't feed GPTIMER events (not even 12!!!!) into the PRU directly Mar 14 22:24:32 SilicaTouchpad, I'm interest in a particular use case, each one running a different application…say one implementing spi-pruss.c and one doing uio-pruss.c and doing what's being done now..for example Mar 14 22:24:51 hm Mar 14 22:24:53 but you know Mar 14 22:25:01 so I need a resource manager Mar 14 22:25:08 yeah ok Mar 14 22:25:15 I know what you mean by that. Mar 14 22:25:50 since the PRU's can run separately I can see that use case. Mar 14 22:26:05 but there are shared resources Mar 14 22:26:11 this is why MFDs exist Mar 14 22:26:14 They CAN run separately but they share a common SYSCFG area, so if you relly wanted to operate them separately you'd neeed to coordinate Mar 14 22:26:17 yeah, what he said Mar 14 22:26:20 similar to how twl4030 is managed that way Mar 14 22:26:25 and there are other problems Mar 14 22:26:29 this properly is a MFD and needs to be treated as such... Mar 14 22:26:31 like, who gets the shared DMEM? Mar 14 22:26:35 is there resistance to that/ Mar 14 22:26:37 ? Mar 14 22:26:49 or just nobody to recode it to be there? Mar 14 22:26:58 You could say just by convention that PRU0 gets DMEM1 and PRU1 gets DMEM1 (but that's not strictly necessary, just a good idea) ... Mar 14 22:27:09 but the other thing is Mar 14 22:27:19 you can't exactly have the PRU request resources from the MPU, not in any simple way Mar 14 22:27:33 so it'd still be up to your C (userspace) code to GET the resources you want, then somehow communicate that to the PRU Mar 14 22:27:40 SilicaTouchpad: well, you don't need to implement policy in the kernel…but you can be aware of those shared resources and provide a mechanism to reserve it and report allocation errors when two clients try to request the same resource Mar 14 22:28:07 The way I do this today is I create a struct { } with 32 bit alignment, then I copy that struct into the first bit of DMEM0 as a 'configuration' area prior to starting the PRU ... that works OK ... but it's up to me to do that, there's no ... conventions Mar 14 22:28:40 well, the slate is clean, TI has elected to not set the conventions here Mar 14 22:28:43 what was really awful was, when i first got to it, uio_pruss.ko would allocate a 256KB block of memory in DDR, to be used as a DMA (or fake DMA) area Mar 14 22:28:47 the community gets to do that Mar 14 22:28:50 mdp, you are talking about not just the shared memory segment but also the internal memory space and peripherals? Mar 14 22:28:52 whatever makes sense :) Mar 14 22:28:55 which is fine, i liked that Mar 14 22:29:10 and their userspace library provides you with a way to get aa pointer to that dma memory. Also good. Mar 14 22:29:24 But their userspace library did NOT provide a way for the userspace app to figure out how *big* that block is Mar 14 22:29:27 duh Mar 14 22:29:28 SilicaTouchpad: if you've followed the DSP use fiasco with omap3 then you should be thankful :) Mar 14 22:29:41 Hahahah I haven't followed that, but I love mayhem Mar 14 22:29:44 ka6sox: yes Mar 14 22:30:11 the way its done now certainly could cause overallocation and collisions. Mar 14 22:30:47 ka6sox: you can have a resource block with blobs you want to load that advertises stuff it needs to work Mar 14 22:30:54 the thing is you avoid some of this if by convention you say one userspace program, two PRU programs, and treat them as one thing instead of two separate things. Mar 14 22:30:56 I don't know. Mar 14 22:31:19 I don't have this use case (treating them separately) but I will mull this over because I can see what you are saying and why others might Mar 14 22:31:34 SilicaTouchpad, I do.... Mar 14 22:31:51 initially i kind of had these thoughts, too, of "Can't I treat the PRU as a job execution unit and just send it jobs to the first available PRU?" Mar 14 22:32:07 oh boy...scheduling PRUs :D Mar 14 22:32:14 but my "jobs" all touch hardware, and hardware is fixed, so it's not really feasible to make anything I do run on either pru. It needs to be on PRU0 or PRU1 Mar 14 22:33:06 but still, wouldn't a PRU scheduler be really fun? :) Mar 14 22:33:25 it doesn't have to be complex to start Mar 14 22:33:55 at this point it would be a resource manager on top of uio_pruss? Mar 14 22:34:05 correct Mar 14 22:34:18 I'm just looking at the fact that all the world is not a UIO driver Mar 14 22:34:33 I think we can all agree on that Mar 14 22:34:37 agreed. Mar 14 22:34:45 so fundamentally UIO and pruss have to be disconnected Mar 14 22:35:39 normally we would abstract it out to a pmem space or sysfs entries. Mar 14 22:36:01 otherwise what are we saying, people that want a PRU to bitbang spi to be a super mcspi have to write a driver that doesn't reset the PRUSS and cooperates with uio_pruss.c Mar 14 22:36:06 it's just fundamentally wrong Mar 14 22:36:26 so I think it's wise to abstract out the PRU core from a UIO client driver to start Mar 14 22:38:17 so pru-manager Mar 14 22:38:24 I don't like this UIO thing Mar 14 22:38:27 I think it's a pain in the ass Mar 14 22:38:31 hehe Mar 14 22:38:35 and I think having to open up 8 files to get 8 events is stupid Mar 14 22:38:46 yes its a PITA to use the UIO code. Mar 14 22:39:01 what I do like about it is that it's ioctl-free Mar 14 22:39:09 the more files the better! Mar 14 22:39:19 but i think a better general solution would be to have an ioctl interface that you aren't REQUIRED to use for it to work Mar 14 22:39:22 mdp: you like plan9? Mar 14 22:39:33 hehe Mar 14 22:39:54 I really think the ticket here is /dev/pruss/pru0/imem and /dev/pruss/pruu1/dmem and all, as just "files" you can mmap OR read/write/seek if you want Mar 14 22:40:08 I'm programmed to hate ioctls..like all good linux disciples Mar 14 22:40:14 and I really would like to see a much simpler event based interface where it writes you a BYTE Mar 14 22:40:24 heh Mar 14 22:40:31 a byte that says what event # it was Mar 14 22:40:44 maybe you add some bits to it to signal lost interrupts if you really give a crap about that Mar 14 22:41:20 I'd much rather see it have sysfs entries for turning it off and on and loading it up... Mar 14 22:41:25 all I'm getting at is the PRU should be usable from C, or java, or perl, or groovy, or fortran ... Mar 14 22:41:25 it's always nice if you can poll() for events Mar 14 22:41:30 right Mar 14 22:41:31 a purpose-built interface for the pruss…sounds good Mar 14 22:41:55 SilicaTouchpad: all I care is that it works from BoneScript, that's that matters Mar 14 22:41:59 oh I said /dev/pruss/pru0/xxx but Mar 14 22:42:08 but maybe /sys is the right place to do it Mar 14 22:42:13 It probably is Mar 14 22:42:30 sysfs is for control, a block of pmem is better for upload/download things. Mar 14 22:42:49 hm so Mar 14 22:43:19 if i want to load pru0 by cat myprogram.bin > ${PRU0_IMEM} Mar 14 22:43:31 you would put PRU_IMEM where, in /sys/something ? Mar 14 22:43:47 surely you just... why not use the syslink API? Mar 14 22:43:50 it would be some horrible path, right, like /sys/device/class/by-name/pruss/by-id/memory/program/imem0/ Mar 14 22:43:50 * ds2 ducks Mar 14 22:43:53 haha Mar 14 22:44:01 syslink api ... what ... is that Mar 14 22:44:02 me shoots ds2 Mar 14 22:44:05 I'm not sure what you mean by that Mar 14 22:44:17 do you mean like netlink? Mar 14 22:44:23 I want a header block on that binary so the resource manager can tell userspace "NFW" Mar 14 22:44:32 mabe we should do it like the old sparcs did and require you to write your pru loader in forth Mar 14 22:44:36 I tink that's a grand idea! Mar 14 22:44:49 lets not do that please....its already done. Mar 14 22:44:52 but but it will make it uniform with the other members of the family with an aux processor Mar 14 22:44:53 ;) Mar 14 22:45:11 okay...but this one is "dynamic" right? Mar 14 22:45:23 well so was the dsp on OMAP too... Mar 14 22:45:39 you do have to use remoteproc, of course Mar 14 22:45:47 PRUSSbios Mar 14 22:45:48 do you talk to the dsp on the omap the same way, you mmap something and get access to his internal memory? Mar 14 22:45:48 ;) Mar 14 22:46:12 dsplink? Mar 14 22:46:14 prius? Mar 14 22:46:26 plugin pruss Mar 14 22:46:50 rofl next time someone shows up here and asks what a pruss is I am going to tell them it's a kind of hybrid Mar 14 22:47:52 aha…pruss client drivers should be call pruss-plugins Mar 14 22:47:52 I could easily see each PRUSS fighting for the same L3/L4 resources. Mar 14 22:47:54 cool Mar 14 22:47:57 ok, it is my favorite time of the week, home depot time! Mar 14 22:48:15 since they are self-contained things. Mar 14 22:48:20 not "Tool Time"? Mar 14 22:48:33 what about beer time? Mar 14 22:48:41 I'll drink to that one Mar 14 22:48:52 all kidding aside... would be nice if the the PRUSS can also be tied in with the PM frame work so it can offload some of the wake up functionality Mar 14 22:48:55 its beer:30 someplace in the world. Mar 14 22:49:04 ds2: there's already an m3 for that Mar 14 22:49:20 mru: programmable by mere mortals? Mar 14 22:49:26 except it's unavailable to us Mar 14 22:49:30 thought all the other cortices are locked up? Mar 14 22:49:39 I'm sure there's some way to get at it Mar 14 22:50:12 mdp, currently each PRU programme is totally separate and doesn't have any way to know what resources it needs when its loaded. Mar 14 22:50:30 ds2, there's a PM framework?!? Mar 14 22:50:33 :) Mar 14 22:50:40 I sure hope not Mar 14 22:50:46 so the manager would have to get information brought to it as to what that "plugin" uses. Mar 14 22:50:50 frameworks are the best way to not get anything done Mar 14 22:50:59 ka6sox: right, I was suggesting to address that by convention Mar 14 22:52:39 so a framework for generating the plugins would have to bring that to the party Mar 14 22:52:54 "by convention" Mar 14 22:53:25 properly written "plugins" would tell the resource manager what they use Mar 14 22:54:01 we already do this for in kernel memory resources..and it relies on properly written code to request the resource to catch conflicts Mar 14 22:54:12 ka6sox, no no…no framework..don't use that word Mar 14 22:54:20 <_av500_> what's all the PM talk here? cant you make the thing DO something before you make it do NOTHING? Mar 14 22:54:21 okay I won't Mar 14 22:54:37 I retract that. Mar 14 22:54:52 I can bring a file that says what resources this plugin is using...thats fine. Mar 14 22:54:53 "system" Mar 14 22:55:00 thank you Mar 14 22:55:15 anyway, just a suggestion Mar 14 22:55:30 we just need to agree on what the plugin resource file looks like and we are okay. Mar 14 22:55:44 have the manager just deconflict. Mar 14 22:56:22 the only exception to that would be a plugin that uses both PRUs that can internally deconflict. Mar 14 22:56:43 it basically just a structure with typical magic value, and static/dynamic list of resources based on what stuff we need to track Mar 14 22:56:47 use both prus...you ar on your own Mar 14 22:57:32 you tack that header on the front of the bin..and that's what the kernel groks on load Mar 14 22:58:37 I wonder how often I will be swapping out PRU plugins. Mar 14 22:58:42 ka6sox, number of prus used is a resource Mar 14 22:58:53 right Mar 14 22:59:10 tilt if one is in use and you request 2 Mar 14 22:59:24 ka6sox, ok, so to put it in perspective..I have this crazy idea that once you have a several pru plugins…you start to get users trying to build on them like black boxes Mar 14 23:00:12 they may load two, you want it to scream bloody murder if the second one tries to request resources that aren't available Mar 14 23:01:00 this is beyond this point of "make it work" to "make it a useful building block" Mar 14 23:01:34 so user loadable PRU modules? Mar 14 23:01:38 ka6sox, right, so that's a perfect common use case Mar 14 23:02:15 modprobe Mar 14 23:02:27 pruprobe Mar 14 23:02:28 where a user is a typical beaglebone hobbyist Mar 14 23:03:05 but you get what I'm saying..you load a driver, it needs to load "firmware" and it could fail due to lack of resources Mar 14 23:03:13 and driver doesn't load Mar 14 23:03:24 there are 2 bits though... Mar 14 23:03:31 the user space and the pru space. Mar 14 23:03:39 analogous to many common drivers requiring firmware to init/probe Mar 14 23:03:43 right Mar 14 23:03:48 both go together as part of the plugin. Mar 14 23:04:11 could be kernel space Mar 14 23:04:38 you can implement a kernel tty driver using the pru Mar 14 23:05:05 I'd kind of like some kernel space for control registers at least. Mar 14 23:05:34 and some sysfs "control bits" Mar 14 23:05:35 so in that model it's like loading firmware for any other device Mar 14 23:05:41 right Mar 14 23:05:45 and yeah, you get some sysfs knobs for the core Mar 14 23:06:06 turn it off, turn it on, interrupt stuff etc. Mar 14 23:06:30 maybe even a "load" knob. Mar 14 23:06:58 show resource usage Mar 14 23:07:16 the core knows some good stuff in this case Mar 14 23:07:21 each pru would need its own sysfs register... Mar 14 23:07:29 stop/start/reset/load Mar 14 23:07:44 so then the other userspace side of things (just forget that UIO is the standard interface for the moment) Mar 14 23:09:47 in that core stuff, you provide a mechanism to load a pru program from userspace and bind it to UIO…one that groks the magic header Mar 14 23:10:06 and the "right way" is not to hammer stuff directly into memory Mar 14 23:10:15 just like we discourage /dev/mem use for obvious reasons Mar 14 23:10:54 because, "oh yeah" that bypasses the damn kernel resource management frame^H^H^H^H^Hsystem for memory regions Mar 14 23:11:38 just assign a pmem space equal to both PRU's and the shared bit..its tiny. Mar 14 23:11:53 and not hammer /dev/mem Mar 14 23:11:54 ka6sox, I think that's right…may file the gpio model and "export" a pru to userspace even..dunno Mar 14 23:12:00 yeah, good Mar 14 23:12:06 s/file/follow/ Mar 14 23:14:21 the pru is an internal thing whereas gpio can be internal or external... Mar 14 23:14:39 I really don't expect to be typing things @ the pru and then having it act... Mar 14 23:14:54 heh Mar 14 23:15:33 I want it to take things from here to there when this happens. Mar 14 23:16:03 yeah, I guess it's not necessarily the best analogy Mar 14 23:16:34 I was thinking about userspace versus kernel space client drivers..only in that context Mar 14 23:16:40 ah Mar 14 23:16:41 okay Mar 14 23:16:59 the userspace I see mostly in the "management" of the resources... Mar 14 23:17:08 not execution and operation. Mar 14 23:18:00 more akin to setting the IP/netmask/gateway and restarting "networking" Mar 14 23:18:16 well, I've got this use case thought where somebody loads a program that does deterministic data acquisition and uses a UIO userspace driver to pick bytes out of a buffer Mar 14 23:18:31 meanwhile he has a spi-pruss.c driver loaded on the other PRU Mar 14 23:18:57 okay so I guess we could let it do that easily enough Mar 14 23:19:13 pmem holds the programme and gets loaded Mar 14 23:19:21 people like to do that simple stuff that's non-critical timing in userspace completely Mar 14 23:19:35 then call pruss.c to use it Mar 14 23:19:43 sounds good Mar 14 23:19:58 or for faster use...use a pmem enabled driver. Mar 14 23:20:22 like the video capture stuff does on davinci Mar 14 23:22:11 I like it Mar 14 23:22:36 gives levels of service appropriate to what is needed to interface to userspace. Mar 14 23:24:28 from sysfs start/stop/reset/load/irq to full pmem Mar 14 23:26:02 and theoretically dma even if necessary. Mar 14 23:36:32 mdp: is that what you were thinking? Mar 14 23:37:35 pretty much..though I tend to think away from android-isms like pmem :) Mar 14 23:38:07 but I've heard it's supposed to be embraced now Mar 14 23:40:05 i learned pmem from working on a davinci Mar 14 23:40:10 with linux Mar 14 23:40:29 or kmem... Mar 14 23:41:09 call it what you like, just not late for the party. Mar 14 23:41:13 cmem Mar 14 23:41:44 <_av500_> +1 Mar 14 23:41:56 at least thats what one would use on the c64x+ on the dm37/omap3 Mar 14 23:42:05 thats the name Mar 14 23:42:17 cmem..its been a year or 2 since I worked on that. Mar 14 23:42:28 <_av500_> ka6sox: its been 5 here :) Mar 14 23:42:45 <_av500_> well, started 5ys ago Mar 14 23:42:51 cma should be finished real soon now (tm) Mar 14 23:42:58 <_av500_> +100 Mar 14 23:43:04 hmm whats cma ? Mar 14 23:43:15 sorry my dumness Mar 14 23:43:18 <_av500_> cmem done proper Mar 14 23:43:19 contiguous memory allocator Mar 14 23:43:28 <_av500_> in-kernel cmem Mar 14 23:43:34 ahh Mar 14 23:43:35 <_av500_> vs the outside of kernel cmem cmem Mar 14 23:43:51 aha, *whew* Mar 14 23:43:54 <_av500_> unsolo_: and cmem is only link, bridge does not need it Mar 14 23:43:58 remeber the ps3 linux kernel needed a continous memory space allocated for the framebuffer.. Mar 14 23:44:01 <_av500_> since it uses the dsp mmu Mar 14 23:44:11 _av500_: i see Mar 14 23:44:12 <_av500_> unsolo_: most framebuffers do Mar 14 23:44:25 for the PRU we need a TINY framebuffer Mar 14 23:44:32 ok, you guys implement this now, I've got to go have rhubarb pie for RPi day! Mar 14 23:44:34 just enough to move things back and forth. Mar 14 23:44:38 <_av500_> if it fit a page.... Mar 14 23:44:41 <_av500_> fits Mar 14 23:44:53 ka6sox: wouldnt a mbox system suffice Mar 14 23:45:00 <_av500_> mdp: not rhasparb pi? Mar 14 23:45:22 close…strawberry-rhubarb to be exact…and beer:30, of course Mar 14 23:45:47 unsolo_, that would make it async which I guess is fine. Mar 14 23:46:26 Is it okay to hook an lcd that draws 100mA to the 3.3v supply on the beaglebone? or is that too much current Mar 14 23:46:43 (i should say is that not enough current) Mar 14 23:47:16 I guess I like that better as I tend to like things like erlang that use that model. Mar 14 23:47:48 and properly implemented is non-blocking Mar 14 23:48:26 * mru wants blockbuster i/o Mar 14 23:52:13 then the kernel needs to be re-written to not use shared memory model. Mar 14 23:53:07 although it continues to get better. Mar 14 23:54:04 haha Mar 14 23:54:08 that will take some time Mar 14 23:54:59 I did 8-bit micros for years...single threaded things...then switched to working on FPGA/CPLD/ASIC stuff...its hard to come back to single threaded when you have seen the light. Mar 14 23:55:31 * unsolo_ saw the light in cell then it faded Mar 14 23:55:32 which is why I like playing with the PRUs Mar 14 23:56:03 isnt a c64x dsp more fun than a pru Mar 14 23:56:13 no Mar 14 23:56:23 hmm Mar 14 23:56:32 depends on what you need Mar 14 23:56:35 done a lot of DSP stuff too...still single threaded. Mar 14 23:57:14 right, for what I am doing I do care that 85 things change on a single clock cycle... Mar 14 23:57:27 oh Mar 14 23:57:41 so the pru is more like a fpga than a uc then i guess Mar 14 23:57:52 no, 2 of them are Mar 14 23:57:59 hmm Mar 14 23:58:04 the pru is a very much a uc Mar 14 23:58:18 yes it is a uc Mar 14 23:58:23 * unsolo_ still fails to se the "great" fuss Mar 14 23:58:32 but *each* one has its own thread. Mar 14 23:58:49 each one is a uc Mar 14 23:58:53 hehe Mar 14 23:58:59 right Mar 14 23:59:18 the omap4 has two m3 cores Mar 14 23:59:27 ahh i see Mar 14 23:59:51 mru: it also has two A9's Mar 15 00:00:09 but a9 isn't a uc Mar 15 00:00:20 also...its not a GP thing... *and* they have Super Cow Powers to get into almost everythign. Mar 15 00:00:49 * unsolo_ prefers dedicated uC's for actual real low power Mar 15 00:00:56 not some pretend stuff Mar 15 00:01:08 how is this pretend? Mar 15 00:01:10 give it some fram too i hear.. Mar 15 00:01:22 ka6sox: does it do < 1mW ? Mar 15 00:01:26 who knows Mar 15 00:01:31 its on die Mar 15 00:01:32 exactly Mar 15 00:01:53 go programme a MSP430 if you want that... Mar 15 00:02:06 uCs are nice for two reasons: power and predictability Mar 15 00:02:18 I want to get some real work done with a webbie interface that my son can do... Mar 15 00:02:22 execution on a cortex-a9 is too unpredictable for some applications Mar 15 00:02:43 this *is* predictable....it has a defined clock cycle and instruction time. Mar 15 00:03:00 ka6sox: thats a better reason than power ;) Mar 15 00:03:03 the pru, yes Mar 15 00:03:05 very predictable Mar 15 00:03:07 the pru Mar 15 00:03:38 its NOT a GP controller...it is dedicated to 1 task...doing things predictably. Mar 15 00:04:20 imho linux isnt predictable.. but there are some os's that are at least more predictable imho. Mar 15 00:04:38 although you will never reach the uC predictability Mar 15 00:04:44 it will *never* be Mar 15 00:04:55 uC is not predictable. Mar 15 00:05:04 it has variable instruction times. Mar 15 00:05:33 variable instruction time is fine as long as the same instruction always takes the same time Mar 15 00:05:57 or has an easily calculated upper bound, preferably not too much higher than the average Mar 15 00:06:14 with RISC possible..but CISC is not fun Mar 15 00:06:15 depends on what your requirements are Mar 15 00:06:15 mru: then you are only predictable within. Mar 15 00:06:35 for precise timing, you need perfect predictability Mar 15 00:06:36 and at least not neccesarely deterministic Mar 15 00:06:53 if all you care about is meeting a deadline, an upper bound is enough Mar 15 00:07:13 which is why I prefer the FPGA/CPLD for ultimate predictability. Mar 15 00:07:25 sure Mar 15 00:07:51 but the pru can get down to the level needed to drive a 3D printer. Mar 15 00:08:23 ka6sox: like directly drive it ? Mar 15 00:08:57 drive the stepper controllers..yes Mar 15 00:09:50 remove stepper and do it using pwm and feedback .. be a man and Fail epicly xD Mar 15 00:10:14 ka6sox: predict the outcome and achieve precision (Kallman) Mar 15 00:10:23 many ways around the absolute.. Mar 15 00:11:13 surely the whole thing generates a lot of feedback would the pru be able to handle it ? Mar 15 00:11:29 3D printers run open loop Mar 15 00:11:33 <_av500_> only positive feedback Mar 15 00:11:41 <_av500_> negative would make it cry Mar 15 00:11:52 _av500_: awsome.. Mar 15 00:12:12 ka6sox: cool project.. Mar 15 00:12:44 <_av500_> ka6sox: take a panda and use the omap4 to actually melt the plastic Mar 15 00:13:01 I *was* going to use an FPGA to solve this...and it would have done so...but it is so much cooler to have the Beagle do it by itself. Mar 15 00:13:44 ka6sox: and way cheaper. Mar 15 00:13:47 but now I'm looking into solving the general case of using the PRU's Mar 15 00:13:53 the FPGA was $7 Mar 15 00:14:01 every $ counts Mar 15 00:14:13 consider the increase in profit on 10 000 units sold Mar 15 00:14:30 every parents dream to have a lego replicator at home. Mar 15 00:14:31 um... Mar 15 00:14:55 this is a POC...not thinking about using a BBone for "production" Mar 15 00:15:10 i would .. its cheap. Mar 15 00:15:35 its not meant for production quantities...so I am not gonna do that to them. Mar 15 00:15:54 if/when I need that then I'll just layout a board. and build it Mar 15 00:16:04 cool Mar 15 00:17:29 I much prefer that the PRUSS' are treated like the MFDs they are than some UIO abstraction. Mar 15 00:19:48 MFDs make sense Mar 15 00:27:30 at least there are some examples to go by https://gstreamer.ti.com/gf/project/pru_sw/scmsvn/?action=browse&path=%2Ftrunk%2Fexample_apps%2F Mar 15 02:21:29 hello. i came back to report the result of serial communication issue. i was trying to use "Breakout Board for FT232RL USB to Serial" link: http://www.sparkfun.com/products/718 instead of general USB-to-Serial cables. But it didn't work out. I have seen somehow repetitive pattern of character dumps but cannot fix it whatever I do. It turned out that the level mismatch problem. Yesterday, I ve been told that could be a problem. So now Mar 15 02:24:08 rs232 level converter. And I can see the boot message correctly! Very nice & great. Thank you for everyone! Hope somebody can get help from my case. To learn about level converting, you can check this : http://www.sparkfun.com/tutorials/104 Mar 15 02:24:35 good night. (here is amsterdam) :) chao **** ENDING LOGGING AT Thu Mar 15 02:59:58 2012