**** BEGIN LOGGING AT Sun May 27 02:59:59 2012 May 27 03:49:05 mranostay HELLO :P May 27 03:49:06 lol May 27 03:49:59 Should be making videos on my home security system soon. May 27 03:50:03 Once I get my custom PCB in. May 27 04:14:47 Is it safe for me to connect a BeagleBone to a 5V, 40A power supply? (This is a rather basic question; I just want to make sure.) May 27 04:16:32 tlevine yes it should be fine. May 27 04:16:49 but it is highly dependent on the quality of the power supply. May 27 04:17:10 So saying it "should" be fine is questionable. May 27 04:17:18 sounds a little hot May 27 10:02:20 Does anyone have any leads regarding what's causing the missing /dev/sd* issue in newer kernels? May 27 10:17:57 Qbert: yes, TI broke USB again in their kernels May 27 11:04:47 Hi Guys I have some questions regarding the BB xM software. I tried to experiment and load new firmware. I got the kernel rootfs, MLO and uboot.img from http://downloads.angstrom-distribution.org/demo/beagleboard/ May 27 11:05:45 I've connected the LCd to the DVI port of the BB. but I see nothing. The OS is booting hoewever and I see the linux prompt thru the serial console May 27 11:07:14 But I don't have the video working. What should I have in uEnv.txt ? May 27 11:07:59 koen: Ok, thanks for the info. Damn TI, how hard can it be to actually TEST it fist. :| May 27 13:04:56 jkridner: ping May 27 13:35:04 jkridner: I was using bonescript to set the PWMs, but I can't find a method to read back the dutycycle May 27 13:35:14 how to send files over xmodem using screen to my beaglebone, minicom is terrible May 27 13:35:29 have you googled for that? May 27 13:35:34 or looked in the screen docs? May 27 13:35:39 jkridner: https://github.com/koenkooi/bonescript/tree/bebopr May 27 13:39:44 ok figured out something from http://etherhack.wordpress.com/2010/04/14/uploading-files-with-xmodem/ but getting the same message: May 27 13:39:57 "Give your local XMODEM receive command now." May 27 13:40:03 what should be that for Bone? May 27 13:43:52 ok, figured out - reset works! - transfered the bootloader, but unable to send a custom app which is 655K in size May 27 14:59:11 jkridner: I feel I need to learn how to use client.js :) May 27 15:18:23 koen: no no, don't go over to the dark side! May 27 16:42:07 How's everyone doing? May 27 16:45:28 <_av500__> gm May 27 17:43:42 hi av500 May 27 17:49:28 <_av500__> ho May 27 17:49:33 no May 27 18:03:16 <_av500__> ko May 27 18:06:13 av500 how was linuxtag? May 27 19:32:33 jkridner: did you break digitalRead? May 27 23:33:16 What is the proper way to start up Gate One by default in the Cloud9 image? May 27 23:34:19 I'm busy adding some new functionality to Gate One to make it so that you can programmatically get it to start up a specific application if your app successfully passes API authentication May 27 23:34:42 So in theory I could add a menu entry to Cloud9 that, say, brings up an IPython or bpython console May 27 23:35:27 ...while still retaining the base SSH functionality if you visit Gate One directly May 28 00:06:10 This is very strange, after booting Angstrom-Cloud9-IDE-GNOME-eglibc-ipk-v2012.05-beaglebone-2012.05.24.img.xz I don't have an /etc/network directory. Also, no /etc/network/interfaces May 28 00:06:28 ...yet if I do an "opkg files netbase" it shows those should be present May 28 00:20:18 * fiola chuckles May 28 00:21:55 I only just got my BeagleBone (and love it). But yeah, the state of Amgstrom config/startup is bizzare. Maybe needs a few people to sort it out committee-style. May 28 00:22:56 Or throw the whole thing out and put in OpenRC. May 28 00:29:51 fiola: OMG, you did not just say committee-style May 28 00:30:04 * prp_afk makes that quote of the year May 28 00:33:26 prp_afk: I did, with heart in mouth :DDDDDDD May 28 00:34:56 I know it's usually a recipe for square wheels. But sometimes individuals doing things just get it all wrong, because "it works for them". A distro affects a lot of people, and more than one cook may be beneficial. May 28 00:36:14 koen's motto is generally "patches welcome"... if you think something's broken offer a solution May 28 00:38:36 prp_afk: it is only May May 28 00:41:38 It's going to be a great year for open source in UK. Reason is that anyone moderately sane will stay out of the public frenzy of the Olympics, and actually get some work done. :P May 28 00:58:15 "Patches welcome" isn't a replacement for people talking to each other. Unless the patch contains a huge documentation spiel about what's intended, it's prolly not going to help, as people will be pulling in opposite directions. It may even get rejected because people not on same wavelength. Talking is good. May 28 01:00:57 My biggest problem with Angstrom at the moment is just how long it takes to compile everything May 28 01:01:34 Even after I've compiled cloud9-image I can make a tiny modification to a single package and it will still take an hour and a half to re-compile it when all it really needs to do is repackage the ipk in question and make a new tarball May 28 01:02:31 When I was working on OpenWRT years ago I could make a new ROM in minutes. Then again, those were only a few megabytes in size. Not 400+ May 28 01:04:52 ARM isn't really a native dev environment currently, unless you're OK with going back 10 years, as CPUs are too slow. Sure it works ... but it's only acceptable under limited circumstances. There isn't really a solution to that at present. May 28 01:04:59 ...but if I'm building, say, a custom Ubuntu bootable disk image that only takes a few minutes. The same is true if I'm building a CentOS image. I don't know what the hell takes it so long. It just sits there eating up 5-20% of my CPU and very little RAM for over an hour and the end result is a 400+MB image. Thats much smaller than some CentOS images I've made in the past May 28 01:05:48 Even if I modify an ipk that requires absolutely no compilation it takes over an hour on a quad core box with 4GB of RAM that is otherwise doing nothing May 28 01:06:05 That is after I've already compiled the entire image May 28 01:06:27 Oh, that sounds worse than just slow. That sounds faulty. May 28 01:07:01 It isn't like it has to go through "task 2000 of 3488" all over again. All it should have to do is make the new ipk, copy it to the rootfs, and re-tarball everything up. Why does that take over an hour? Makes no sense to me May 28 01:09:04 I guess the only way forward there, other than waiting 5 years, is to join the gcc ARM group and help sort out the issues. May 28 01:09:32 fiola: I don't think the problem has anything at all to do with gcc or compiling May 28 01:09:40 Oh? May 28 01:09:41 I think it has to do with bitbake May 28 01:09:47 Hmmm May 28 01:10:30 Like I said, even if I modify a single ipk that only copies a few files (no compiling) it still takes an hour and a half to create a rootfs tarball May 28 01:10:42 Well if so, that's a lot better than if it had to do with compilers. May 28 01:11:28 The compiling process takes a long time, sure, but you only have to do that once per package. The thing you have to do CONSTANTLY is make new images (if you want to test things properly anyway) May 28 01:13:24 I'm also curious why we're messing around with opkg on a device that ships by default with a 4GB storage device May 28 01:14:03 The point of opkg is to save space at the expense of features. If you have plenty of space there's no reason not to use dpkg May 28 01:14:19 (in conjunction with apt) May 28 01:14:22 Well making new images is just linking, once you know what you need to link. Are you saying that bitbake's finding out "what you need to link" is totally screwed, or that the linking has a problem? May 28 01:14:41 fiola: Why would it need to link anything at all? May 28 01:15:06 That's what making images is, linking. May 28 01:15:09 If all I'm doing is updating a single ipk it shouldn't have to re-link anything May 28 01:15:26 The entire rootfs is in the build dir May 28 01:15:37 Just make the ipk, unpack it to the rootfs dir, and make the new tarball/squasfs/whatever May 28 01:16:07 No need to link anything unless you're re-compiling something and even then you should only have to re-link just that package May 28 01:17:23 So what's taking the time? May 28 01:18:16 It seems to start with an opkg- command and then pseudo runs the longest May 28 01:18:29 Why it is messing around with pseudo I have no idea May 28 01:18:37 I didn't change anything that would require that May 28 01:18:41 strace is your friend May 28 01:20:52 There should be a standard FOSS flag "--WTFyoudoin" that engages an "strace STUFF | grep open" on an operation :P May 28 01:23:14 I think I'm going to walk my way backwards in the dependency chain of images to see which one is invoking psuedo at all May 28 01:26:14 This takes so long I think I'm just going to make opkg files and skip all the image stuff May 28 01:28:09 I come from the Gentoo school of thought, so images are kind of academic. Kind of sad though that ARM is so slow currently. May 28 01:28:53 I think it's just a matter of cache. ARM never really got into the cache game, probably because of power consumption. May 28 01:29:40 <_troll_> uh? May 28 01:31:27 Gentoo is a big part of my past as well. More of an Ubuntu guy these days but I could certainly see how using Gentoo would be superior for making packaged distributions for embedded use May 28 01:33:41 _troll: effective CPU caches consume a lot of power. When you run at many times the speed of external memory, you generally consume many time more current too. May 28 01:35:16 riskable: Yeah, but only in theory. In practice Gentoo uses a "look at everything" approach which doesn't scale well, so updates take ages even on powerful x86 equipment. On ARM ... ouch. May 28 01:35:44 fiola: what do you mean by "look at everything" approach? May 28 01:36:04 * javaJake happens to be a Gentoo user on both ARM and amd64, fwiw May 28 01:38:02 javaJake: updates look at the entire dependency graph. Gentoo has no ability to install upgrades without breaking previous dependents, except in the few cases where packages are slotted. May 28 01:38:05 It has been a long time since I've done anything with Gentoo. Last time I did anything with it at all was "Gentoo in a chroot" on a different distro just so I could get a customized version of apache running with a newer version of openssl on some ancient RHEL install May 28 01:39:20 A scalable "Gentoo-NG" would slot everything automatically, so when you emerge an update, you NEVER break anything. Revdep-rebuild would only be an optimization. Gentoo is nowhere near to that currently. May 28 01:39:53 fiola: Is that even in the works?!? May 28 01:39:55 fiola: this bug aims to fix the "breaking previous dependents" issue :) https://bugs.gentoo.org/327809 May 28 01:40:13 what you're talking about is in the works May 28 01:40:21 Wow! May 28 01:40:29 The old way of getting around that problem was to compile everything statically :) May 28 01:41:09 fiola: There's also currently preserved-rebuild which is a workaround that keeps old libraries around until they're no longer needed May 28 01:41:54 Lastly, those breaks happen a *lot* less than they used to because --as-needed (sp?) is now turned on by default in CFLAGS. May 28 01:42:01 javaJake: thanks for that link. Would be awesome if Gentoo became scalable that way. May 28 01:43:11 fiola: agreed May 28 01:43:17 Basically any upgrade that makes something else break is a total fail. We've lived with it for years, but .... it's a fail./ May 28 01:46:04 fiola: it's the price you pay for rolling updates. If you use a distro with a release cycle like Ubuntu, you solve that linking issue by doing a total OS upgrade. May 28 01:50:30 javaJake: Yeah, but ignoring the Ubuntu-type "big bang" approach which we reject anyway because it's tantamount to "We know what you want and don't argue with us", we can have Gentoo-type flexibility as long as we don't pull the carpet out from other packages that are our dependents. Ok it requires more disk space to hold old versions around, and filestore organization to allow it, but disks are cheap. It can be done :-)))) May 28 01:50:37 Speaking of Ubuntu... I just loaded the 12.04 arm image on my Beaglebone and it booted up OK but it seems to have hung when I tried to login as root May 28 01:53:59 javaJake: and once it's done, Gentoo will be just as usable on ARM as on fast x86, because you won't ever need to upgrade anything unless you absolutely demand the new functionality. May 28 02:19:32 <_troll_> fiola: I know what caches are, just don't understand your comment about arm not being "in the game" May 28 02:19:53 <_troll_> omap4 has 1MB L2 May 28 02:33:23 fiola: well currently Gentoo portage does keep old libraries around in @preserved-rebuild such as libpng May 28 02:41:57 _troll: A modern 1.5GHz ARM wouldn't *on pure clock speed* be an order of magnitude slower than x86 if everything else were equal (indeed, Thumb2 may be even more efficient than x86 on instruction density). So I assume cache memory speed plays a large role in keeping ARM slower by far. And it seems a reasonable guess because faster memory certainly consumes more power. May 28 02:42:55 And ARM Holdings aren't happy with using a lot of power. It would make their niche disappear. May 28 02:47:17 <_troll_> fiola: cache is not the big difference here May 28 02:47:33 <_troll_> sure, an i7 has a few more MB of cache May 28 02:47:46 <_troll_> but the huge difference is external memory bandwidth May 28 02:48:21 <_troll_> a typical intel system has 2-4 channels ddr3 May 28 02:49:30 Any DDR3 ARM systems we can compare with? May 28 02:50:06 <_troll_> and on the microarchitecture side, an i7 has more execution units and more aggressive out of order execution than current arm chips May 28 02:50:23 <_troll_> cortex-a15 goes some way towards narrowing that gap May 28 02:51:07 In any case, I think you're wrong there. Cache is everything, not external memory. CPUs run much faster than external memory would allow, using cache locality which is very successful for most common problems. May 28 02:51:59 Is it a combination of both? May 28 02:52:01 It's even a big thing in computational libs to exploit cache locality to the full. The Julia sets lib comes to mind, good writeup there. May 28 02:52:03 <_troll_> ever heard of cache misses? May 28 02:52:20 It's a comination, sure, but the cache rules. It's a multiplier. May 28 02:52:21 <_troll_> what good will a cache do you if you are unable to fill it? May 28 02:52:25 _troll_: it's hard to take you seriously with that nick btw :) May 28 02:53:07 _troll: That's the whole idea of caching. You minimize your cache misses so that your cache rules the day. If you have a hotshot cache, but a lot of cache misses, you fail. May 28 02:53:16 <_troll_> I know how caches work May 28 02:53:21 <_troll_> no need to lecture me May 28 02:53:36 Well if you know, why dwell on cache not being important? May 28 02:53:50 <_troll_> and yes, caches matter, but it's only one part of the system May 28 02:53:51 Unless you're doing it to justify your nick May 28 02:54:20 <_troll_> the working set is frequently much larger than any practical cache May 28 02:54:36 <_troll_> and in those cases memory bandwidth becomes very important May 28 02:54:50 When the working set is large than what fits in the cache, you fail. Bad program or library design. May 28 02:54:57 l;arger* May 28 02:55:06 <_troll_> you have a very narrowminded view May 28 02:55:23 That's how caching works, sorry if you don;t like it. May 28 02:55:30 <_troll_> suppose you want to encode 1h of video May 28 02:55:40 <_troll_> do you know how much raw data that is? May 28 02:55:46 <_troll_> many, many gigabytes May 28 02:56:17 <_troll_> even a single frame of HD video is several MB May 28 02:56:18 Streaming doesn't work with a data cache unless the algorithm reuses what is in the current cached window repeatedly. May 28 02:56:27 <_troll_> and your working set is at least 3 frames May 28 02:56:50 <_troll_> no matter what you do, you *will* have cache misses May 28 02:57:30 Of course you have cache misses. Cache works does its job when they are infrequent, and fails when they are frequent. It's simple. May 28 02:58:20 <_troll_> and when you need to process data orders of magnitude larger than the cache, you will have misses May 28 02:58:48 <_troll_> of course you should do whatever possible to use the caches as well as possible May 28 02:58:49 Which is where cache locality comes in. Most algorithms have high locality, reusing a datum repeatedly. If your algorithm doesn't, then it will run at external memory speed, and will be slow as heck. May 28 02:59:54 * _troll_ gives up **** ENDING LOGGING AT Mon May 28 02:59:58 2012