| DocScrutinizer05 | and I still think OE was the birth defect in OM | 02:13 |
|---|---|---|
| DocScrutinizer05 | afaik SHR has no proper non-root user accounts (or even any accounts) til this very day | 02:14 |
| DocScrutinizer05 | I still like to think of OE as "linux for fridges" | 02:15 |
| DocScrutinizer05 | while you could define a usual phone as an embedded device (= only custom UI with limited clearly defined functionality), a smartphone already boldly fails on that definition. Even more a pocket computer with attached modem, like Freerunner | 02:18 |
| wpwrak | well, i don't exactly like OE. but with jlime, we had a pretty much hassle-free variant of OE for the ben. not only by technical merits but by having the proper division between development and distribution we never had at openmoko. | 02:21 |
| wpwrak | also with openwrt, we have that. only that openwrt is a weaker basis, so the work of the distribution maintainers is harder. | 02:22 |
| DocScrutinizer05 | I'm more a fan of the downsizing approach, rather than nuking everything to a bare fridge controller level and then re-adding ~90% of mainline stuff again | 02:23 |
| wpwrak | at OM, for most of the time, you basically had nobody who would take care of OE for you. so each developer somehow had to get involved. | 02:25 |
| wpwrak | well, that burn-to-the-ground-then-rebuild is kinda what we're doing with owrt ;-) | 02:25 |
| wpwrak | OE is a lot better i this regard | 02:25 |
| DocScrutinizer05 | I'd probably not need anybody to take care of debian for me | 02:25 |
| wpwrak | DocScrutinizer05: are you sure ? :) | 02:25 |
| wpwrak | how often do you compile debian packages from source ? | 02:26 |
| wpwrak | when i do, it's from sources that are themselves upstream to debian | 02:26 |
| DocScrutinizer05 | actually not that often, but I did a few years ago, for maemo | 02:26 |
| wpwrak | all i want from debian/ubunto are packages. and my work is not debian-specific but gets packaged by someone (in our case often xiangfu) into debian. that someone knows the rules/rituals, chain of command, etc., of debian. so "debianizing" code is more or less transparent to me. | 02:28 |
| DocScrutinizer05 | sure. What more do I need? | 02:29 |
| wpwrak | same for fedora and whatever. they do their work, i do mine. i keep my makefiles clean, so they won't have too much of a headache, and i never even hear from them. and that's just as it should be :) | 02:29 |
| wpwrak | DocScrutinizer05: precisely. get the process right and things all of a sudden get very simple | 02:30 |
| DocScrutinizer05 | well, porting pkgs from debian/other-mainline to an "embedded" system is a oneway thing in my book anyway | 02:30 |
| DocScrutinizer05 | I for sure wouldn't bother to upstream maemo-specific patches | 02:31 |
| DocScrutinizer05 | after all that's why maemo exists, and it's not just an OMAP build of devian | 02:32 |
| DocScrutinizer05 | debian even | 02:32 |
| DocScrutinizer05 | I've seen epic fail of mer etc, which tried to stay on main too much | 02:33 |
| wpwrak | i think upstreaming is good. but you don't need to be in a great hurry to do it. | 02:34 |
| DocScrutinizer05 | oooh sensor-fw not IRQ event driven, rather polling? Don't worry we'll deal with powersaving later, for now we need something that *works* X-P | 02:34 |
| wpwrak | such is life :) | 02:35 |
| wpwrak | everybody knows battery life sucks anyway ;-) | 02:35 |
| DocScrutinizer05 | exactly, and that will never change for mer | 02:35 |
| DocScrutinizer05 | since for them, if it's not upstream, it doesn't exist | 02:36 |
| DocScrutinizer05 | and, like it or not, main is not exactly built for "embedded", they every now and then took design decisions that are fine for servers or even laptops | 02:37 |
| wpwrak | yes, that's the main challenge for making an embedded version of a major distro | 02:38 |
| wpwrak | tjat | 02:38 |
| wpwrak | grr | 02:38 |
| wpwrak | that's also why i didn't consider debian embeddable for a long time. it seems they now worked / are working on that. but i don't know the status | 02:38 |
| wpwrak | it's basically a question of having more flexible dependencies, and the config options that allow such flexibility | 02:39 |
| wpwrak | e.g., bad: installing a package for "/bin/true" pulls in the gnome desktop because the package also contains /bin/ls and someone added a --beep option for whatever, which in turn needs some audio subsystem and the gnome desktop has the volume control utility. | 02:41 |
| wpwrak | good: /bin/true will come alone. and if some genius invented a --beep option for it too, then you'll be able to install without it | 02:41 |
| DocScrutinizer05 | ack | 02:44 |
| DocScrutinizer05 | on maemo we got friggin PITA called metapackages | 02:44 |
| DocScrutinizer05 | actually ONe metapackage | 02:44 |
| DocScrutinizer05 | that contains virtually all | 02:44 |
| wpwrak | nice ;-) | 02:44 |
| DocScrutinizer05 | indeed >:-( | 02:45 |
| wpwrak | apt-get install maemo # nice and simple :) | 02:45 |
| DocScrutinizer05 | exactly | 02:46 |
| wpwrak | well, it's not a bad idea if a lot of people actually want the "standard system". depends on whether such a standard system really exists | 02:46 |
| DocScrutinizer05 | even apt-get install mp-fremantle-community-pr | 02:47 |
| DocScrutinizer05 | *blush* | 02:47 |
| wpwrak | whatever that is :) | 02:47 |
| DocScrutinizer05 | I'm fighting since 2 years against it | 02:47 |
| DocScrutinizer05 | it's the continuation of the original metapackage from nokia, by community (incl me) | 02:48 |
| DocScrutinizer05 | http://wiki.maemo.org/Community_SSU | 02:48 |
| DocScrutinizer05 | wpwrak: the torture starts when you want to get rid of, or replace, one of the "standard" components - like camera | 03:01 |
| DocScrutinizer05 | apt-get will suggest to remove the mp and roundabout 400 other pkgs ;-P | 03:03 |
| DocScrutinizer05 | same happens when you get pissed by messybox and simply want to install procps | 03:04 |
| DocScrutinizer05 | to finally get an idea of what your processes do and look like | 03:04 |
| DocScrutinizer05 | procps conflicts with busybox, busybox tears down the fremantle-mp, the mp uninstalls ~80% of your system | 03:06 |
| wpwrak | interesting .. urjtag has a configure that ignores cross-compilation. how sweet is that ? | 03:06 |
| DocScrutinizer05 | well, the latter not instantly, actually I failed to understand when *that* happens | 03:06 |
| wpwrak | sounds as if someone has implemented some creative new thoughts about the metaphysical reality of dependencies ;-) | 03:08 |
| DocScrutinizer05 | yep, the one been Nokia | 03:08 |
| DocScrutinizer05 | and my maintainer freaks explain to me we can't get rid of this abomination | 03:08 |
| wpwrak | lab diary notice: the lobotomy was successful beyond our wildest expectations | 03:10 |
| DocScrutinizer05 | http://maemo.org/packages/view/mp-fremantle-community-pr/ | 03:10 |
| DocScrutinizer05 | http://maemo.org/packages/package_instance/view/fremantle_extras-devel_free_armel/mp-fremantle-community-pr/20.2010.36-2maemo16/ | 03:12 |
| DocScrutinizer05 | "Depends:" :-o | 03:12 |
| wpwrak | there ain't no "depends" on that page | 03:15 |
| wpwrak | (ujtag) naw, my mistake - it seems to support cross-compilation just fine. now, dumbing it down for ben compatibility ... | 03:31 |
| wpwrak | xiangfu: hmm, is there a quick way to build just the kernel in openwrt ? kinda like "make kernel_menuconfig" | 05:48 |
| wpwrak | (i already tried "make kernel" but there's no such target. would have been too easy :) | 05:49 |
| Action: wpwrak praises XTerm.*.colorMode: false | 05:56 | |
| xiangfu | wpwrak: make target/linux/{clean,compile} V=s | 06:01 |
| Last message repeated 2 time(s). | 06:03 | |
| xiangfu | it will delete the linux folder. compile it again. | 06:03 |
| xiangfu | or just make target/linux/compile V=s | 06:03 |
| xiangfu | (network problem...) | 06:03 |
| wpwrak | kewl. thanks a lot ! | 06:03 |
| hellekin | sometimes, I just feel stupid not knowing stuff like that: http://bookos.org/Computers-%26-Internet-Hardware-cat84 | 06:23 |
| wpwrak | hellekin: what's special about a page full of errors ? | 06:29 |
| xiangfu | wpwrak: have you receive my message? | 06:39 |
| xiangfu | make target/linux/{clean,compile} V=s or make target/linux/compile V=s | 06:39 |
| wpwrak | yes, thanks ! | 06:47 |
| wpwrak | seems that it doesn't quite work, though. first, i had to build "install" to get it to actually compile, and then then it failed because it had not made uImage | 06:48 |
| wpwrak | now running that regular build ... | 06:48 |
| wpwrak | now .. let's see if it still boots | 06:51 |
| wpwrak | yay. victory ! | 06:51 |
| wpwrak | now, why didn't it accept my config change ... | 06:52 |
| wpwrak | ah no, it did. good :) | 06:52 |
| kyak | wpwrak: yeah, make target/linux/install V=s will actually build the uImage | 06:52 |
| wpwrak | kewl. configure silently defaults to the build host architecture in case the specified cross-toolchain isn't around. autocrap indeed. | 07:25 |
| qi-bot | [commit] kyak: w3m: fix build (master) http://qi-hw.com/p/openwrt-packages/a6504b8 | 07:42 |
| hellekin | wpwrak: oh, crap. It's a repository of 1.5 million books for download. That one was supposed to link to the Hardware category | 08:33 |
| wpwrak | the amazon of bookwarez ? ;-) | 08:42 |
| sagex | thats funny. I've been trying to get ethernet over usb0 and I am able to ssh into the device but I cannot ping google | 08:46 |
| wpwrak | sagex: perhaps your PC isn't forwarding and NAT'ing ? | 08:47 |
| sagex | wpwrak, ok I'd like to know how to forward and nat'ing | 08:48 |
| wpwrak | http://lmgtfy.com/?q=nanonote+forward+nat | 08:51 |
| Action: wpwrak loves those lmgtfy moments (-:C | 08:52 | |
| sagex | hehe | 08:52 |
| wpwrak | yeah. ubb-jtag works ;-) | 09:05 |
| wpwrak | just identified one of my milkymists | 09:05 |
| wpwrak | whoopsie ! pld load "fjmem.bit" ... then it (urjtag) happily identifes the 6slx45fgg484 followed by getting OOM-killed | 09:09 |
| wpwrak | let's see what strace has to say about that ... | 09:11 |
| wpwrak | hmm. tries to allocate 11 MB. weird | 09:13 |
| wpwrak | bah. no ltrace on openwrt. that's cheap. | 09:26 |
| wpwrak | urjtag certainly likes its malloc ... | 09:30 |
| wpwrak | now, if we had a 2nd 8:10 card slot, i could add swap. grrr ... | 09:31 |
| viric | you can use slip + nbd ;) | 09:36 |
| wpwrak | aha ! it tries to allocate a "data register" for the eight times the size of the bitstream. 1484404*8 = 11875232. that explains something. | 09:41 |
| viric | one-bit-per-byte storage? | 09:41 |
| wpwrak | yeah, apparently | 09:42 |
| wpwrak | dr_data[8*u+0] = (bs->data[u] & 0x80) ? 1 : 0; and so on | 09:42 |
| viric | oh, even without redundancy. it should be ? 0xff:0 | 09:43 |
| wpwrak | at least it doesn't malloc little buffers for "0", "1", ... | 09:47 |
| viric | hehe | 09:47 |
| kyak | wpwrak: and so i came upon timer_create()... | 11:06 |
| kyak | this is getting ridiculous | 11:06 |
| kyak | setitimer is good, but it doesn't allow me to keep track of overruns | 11:10 |
| kyak | if my function (called from the timer handler) didn't return before the next timer period has elapsed, the next timer signal would just get lost | 11:12 |
| larsc | I wouldn't recommend setitimer anyway, it's kind of legecy stuff | 11:16 |
| kyak | hm, ok! | 11:18 |
| kyak | from the other hand, timer_create() requires -lrt -lpthread -ldl :) | 11:19 |
| kyak | not that it really matters, but still.. | 11:19 |
| kyak | heh.. timer_create is described in both man 2 and man 3p | 11:23 |
| kyak | yeah, i'm sticking to timer_create() and timer_getoverrun(). It works just as i needed | 11:53 |
| whitequark | wpwrak: Paul Wilson has some wise things to say about GC's: ftp://ftp.cs.utexas.edu/pub/garbage/gcsurvey.ps, section 1.1 | 12:04 |
| wpwrak | kyak: happy ending ? :-) | 13:23 |
| kyak | wpwrak: i hope so. If anyone knows a better way, please don't tell me, i don't want to rewrite the same algorithm in yet another way :) | 13:25 |
| wpwrak | kyak: look at the bright side - you're now done comprehensive research on the topic and can post a comparison :) | 13:28 |
| wpwrak | hmm, didn't someone once implement in-memory page compression ? that might solve my urjtag problem ... | 13:30 |
| wpwrak | (the things we do - or think of doing - to accommodate bothersome user space ...) | 13:30 |
| larsc | wpwrak: zram | 13:34 |
| wpwrak | whitequark: i'm so glad my code doesn't have to worry about GC ;-) take all the headache of explicit memory management, move it somewhere else, then square it :) | 13:35 |
| xiangfu | wpwrak: or you can try another jtag program: https://github.com/Wolfgang-Spraul/fpgatools/tree/master/mini-jtag :) | 13:36 |
| xiangfu | the urjtag try to put the bit in byte size, then revert to byte again when write to device.(like pld load) | 13:38 |
| whitequark | wpwrak: you clearly never wrote much GC-managed code ;) | 13:40 |
| wpwrak | whitequark: i stopped after seeing it collect its garbage ;-) | 13:40 |
| xiangfu | :) | 13:41 |
| wpwrak | xiangfu: (urjtag) yeah. i'm impressed by their efficiency ;-) | 13:41 |
| larsc | doesn't the kernel do gc for you? once the process exits the memory is free again ;) | 13:43 |
| wpwrak | xiangfu: hmm, some of the code in mini-jtag looks very familiar :) nice and compact, though. pity it's very FTDI-specific | 13:46 |
| wpwrak | larsc: the kernel is expected to do magic. that's why it's written by wizards with long white beards :) | 13:48 |
| wpwrak | kyak: thanks ! that was what i was looking for. pity they have a static division. let's see how good it is ... | 13:52 |
| kyak | wpwrak: what is static division? | 13:53 |
| wpwrak | kyak: that you have to allocate the amount of memory that goes into that swap | 13:54 |
| wpwrak | or .. actually, that may just be their nominal size | 13:54 |
| kyak | hm, i'm confused :) | 13:54 |
| wpwrak | chaos and confusion, my work here is done. bwahaha :) | 13:55 |
| larsc | kyak: he's talking about zram | 14:00 |
| kyak | larsc: let me forward his thanks to you then :) | 14:06 |
| wpwrak | xiangfu: how big is wolfgang's blinking leds bitstream for the lx9 ? | 14:12 |
| xiangfu | wpwrak: 340704 | 14:13 |
| wpwrak | great. 1/4.3 the size of fjmem.bit | 14:14 |
| xiangfu | the .bit file is fix size for each chip. | 14:14 |
| wpwrak | bah, not even RLE ? that's cheap | 14:16 |
| wpwrak | i.e., there are a lot of very compressible zeroes in there | 14:16 |
| wpwrak | zmem must be a bit disgusted. first, the 1-to-8 spreading by urtag, and then the actual data is mostly zeroes, too. | 14:17 |
| wpwrak | in any case, fjmem just informed me that it found "32 MiB" of flash :) | 14:18 |
| wpwrak | 262 seconds for fjmem.bit. so an lx9 bitstream would take about one minute. probably less, given that it should fit into the ben without compression (zram) | 14:26 |
| wpwrak | frequency 6000000 -> new real frequency 46570.9, delay 0 operating without delay :) | 14:29 |
| wpwrak | now .. let's take pictures ... | 14:33 |
| qi-bot | [commit] Werner Almesberger: README: there's much more than the blinkenlights here (master) http://qi-hw.com/p/ben-blinkenlights/d33da70 | 18:11 |
| qi-bot | [commit] Werner Almesberger: ubbctl/: UBB pin status decoder (master) http://qi-hw.com/p/ben-blinkenlights/f0c6e87 | 18:11 |
| qi-bot | [commit] Werner Almesberger: ubb-jtag/: instructions for building a JTAG interface with UBB (master) http://qi-hw.com/p/ben-blinkenlights/1024f48 | 18:11 |
| qi-bot | [commit] Werner Almesberger: ubb-jtag/ubb-jtag-m1.sch: schematics for UBB-VGA-M1 cable (master) http://qi-hw.com/p/ben-blinkenlights/d16af2a | 18:11 |
| wpwrak | xiangfu: would you happen to have a smaller bitstream (e.g., from your lx9 experiements) somewhere ? | 18:24 |
| wpwrak | wolfspra1l: or you ? | 18:25 |
| wpwrak | (i'm trying to see how much zram slows down things, and maybe urjtag will let me load a smaller bitstream) | 18:26 |
| kristianpaul | i wonder if a bitstream could get smaller, anyway you need initialice to a safe state even the un-used CLBs | 18:42 |
| wpwrak | well, i don't plan to actually run it for very long :) | 18:46 |
| qi-bot | [commit] Werner Almesberger: ubb-jtag/README: ideas for increasing the speed (master) http://qi-hw.com/p/ben-blinkenlights/b6a9e23 | 18:57 |
| qi-bot | [commit] Werner Almesberger: ubb-jtag/ubb-jtag-m1.sch: connect VREF to 2.5 V; explain that R3 is untested (master) http://qi-hw.com/p/ben-blinkenlights/a58e789 | 18:57 |
| --- Sat Jan 5 2013 | 00:00 | |
Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!