<wpwrak> (vga) yeah. it's still work in progress (right now strugging with dma), but i think it still qualifies as an unexpected capability ;-)
<mth> larsc: this patch might be useful for upstream inclusion, please review: https://github.com/mthuurne/opendingux-kernel/commit/8893e953e685864855f6fc612808315787fbcf3a
<wpwrak> mth: so it basically figures out what ram size the boot loader configured, reports it, and also makes the kernel use it ?
<wpwrak> mth: what happens if the boot loader picked an incorrect size, e.g., too conservative ? (since it doesn't need all of it anyway)
<rjeffries> kodein agree but one hope Meego can be at least a nuche mobile OS.
<mth> wpwrak: yes, it takes exactly what the boot loader configured
<mth> if the boot loader configured too little, then the kernel won't be able to use all of it anyway since there is no code in the (current) kernel to reconfigure the SDRAM interface
<wpwrak> rjeffries: (cost calculation) yes, 3x is a low multiplier. however, there are a few special factors here: for some things, the entire R&D cost is "outsourced". second, we're competing price-wise with high-volume production. this means reduced margins or the product would seem excessively priced.
<mth> if you want to use less memory than the boot loader configured though, you can use the "mem=" parameter
<wpwrak> mth: hmm, good point about the kernel not being able to use more
<wpwrak> mth: the mem= parameter is admittedly something i never liked.
<mth> it can be useful to simulate a system that has less memory, but until now it was required to be able to boot at all
<mth> this autodetect feature reduces the number of kernels we have to ship for the Dingoo, since the A320 model has 32MB RAM and the A330 model has 64MB RAM
<wpwrak> rjeffries: there's not much room for niche operating systems :) well, unless you're willing to pour large amounts of money into them.
<rjeffries> maybe LB in protecting their flank. android has some exposure to M$ patents it seems
<wpwrak> mth: (mem=) ah, i meant its role on the ben. not in general.
<MrX> new topic: we are looking for something to replace uboot
<MrX> and a minimal boot loader to load a kexecboot kernel could probably be identical for Dingoo and NanoNote
<wpwrak> a round of applause for MrX, please !
<wpwrak> MrX: i've heard Jay7 is working on the kexec side of this
<MrX> ok
<wpwrak> MrX: larsc has made some simple boot loader for the ben some time ago, but i don't know what happened with it
<MrX> if I understood correctly, the loader would just need to initialize the SDRAM and NAND controllers, load the kexecboot kernel and jump to it
<wpwrak> MrX: well, however boot loader and kernel decide to divide up the work. but yes, i'd say, the less the boot loader does, the better
<wpwrak> MrX: however, you may also want to consider SD boot
<MrX> not really; that would be handled by kexecboot
<MrX> kexecboot is a bootloader based on the linux kernel
<MrX> the simple loader just init some hardware and load kexecboot from the NAND
<wpwrak> if you want a "fast path" that doesn't involve loading two kernels, you may need other boot sources
<MrX> then, with kexecboot you can decide on which peripheral you want to boot: NAND, SD, network...
<wpwrak> (kexecboot) i haven't forgotten ;-) see section 5 of http://www.almesberger.net/cv/papers/ols2k-9.pdf
<MrX> I *think* that it would be possible to modify our OpenDingux kernel so that it initializes differently depending on a key press
<mth> worst case the boot loader could read the key status and pass different command line arguments to the kernel
<mth> but then the boot loader becomes more device specific
<wpwrak> mmh, better leave those keypress decisions to the boot loader. you're already paying the price of bringing up a linux system, so you may as well initialize the screen
<mth> perhaps better to read key status from user space from the initrd
<MrX> is it a problem to load two linux kernels anyway?
<mth> it takes some time, other than that no problem
<wpwrak> mth: i don't see a problem with having a few device-specific strings in the boot loader
<MrX> not if the kernel is tiny
<MrX> we don't need sound drivers for a bootloader ;)
<wpwrak> MrX: it still takes time ;-) the question is simply if it's little enough to not matter
<MrX> we don't even need the screen
<mth> MrX: didn't you try a minimal kernel earlier today?
<MrX> it didn't boot \o/
<mth> oh
<MrX> I did it to check the size, mainly
<MrX> as you said, if we put the kernel on a UBI located on a small partition of the NAND, the loading will be quite fast
<wpwrak> MrX: kexecboot kernel or final kernel ?
<MrX> for that bootloader we don't need the drivers for the screen, the sound, the watchdog, etc.
<MrX> wpwrak: the final one
<mth> I think the screen would be nice though, so you could select different kernels off an SD card, for example
<MrX> as the thing that takes most of the time when loading the kernel is the mounting of UBIFS
<wpwrak> why ubi then ?
<MrX> mth, yes, but it's device-specific then
<mth> MrX: screen support in the kexecboot kernel, not the boot loader
<wpwrak> yes, mounting NAND file systems sucks. about the only one that looked promising was logfs, but i don't know what happened with it
<wpwrak> mth: you definitely need screen support. e.g., for your boot menu
<mth> wpwrak: because it can work around bad blocks and it can do replacements that one take effect once fully complete
<MrX> mth: for kexecboot, indeed
<mth> we could develop all of that ourselves, but it already exists
<mth> we could use a small UBI device so it is quick to scan on attach
<MrX> the SPL and kexecboot could be outside UBI, but the final kernel should be on UBI
<mth> and have a static volume on that containing the kernel image, no file system
<mth> wpwrak: logfs is included in the mainline kernel, I don't know if it's usable in practice though
<MrX> do logfs have volumes?
<mth> it does not run on top of UBI, in any case
<MrX> volumes are interesting on UBI, as they allow us to update the system while running it
<mth> logfs might be a candidate for the home partition
<wpwrak> mth: (ubi, atomic updates) okay, that's a benefit
<mth> since that is by far largest and must be read/write
<wpwrak> mth: logfs may also have short mount time
<MrX> yes that could be done
<wpwrak> what scares me of ubi is its sheer complexity
<MrX> so four NAND partitions: the SPL, kexecboot, a UBI volume with the kernel and two rootfs, and a logfs partition with the user data
<wpwrak> but then, i'd rather have no "naked nand" at all anyway ;-)
<mth> UBI at least divides the problem into two layers: one handling all the flash issues and another with the file system
<wpwrak> mth: naw, both struggle with those flash issues ;-) otherwise, you could just mount, say, ext3 on top of a ubi volume, and be happy
<mth> maybe that will be possible one day
<mth> with SSDs and the trim command, block devices become more like UBI volumes ;)
<wpwrak> heh ;) i see nand become more like ATA disks, which i like :)
<mth> I heard the other day from someone running virtualized servers that they also like the trim command
<mth> it keeps the disk images small
<wpwrak> ph, trim in general makes a lot of sense. gives your lower layers a better idea of what your upper layers really need.
<mth> the problems solved by an SSD controller doing ATA + trim and UBI are more or less the same
<mth> anyway, it's 3am here and I need to get some sleep
<mth> I'll talk to you later
<MrX> I'll do the same
<MrX> tomorrow I have a 9-hour train trip
<MrX> see you
<kristianpaul> hi room  :-)
<dvdk> wolfspraul: wrt to community news:
<dvdk> wolfspraul: did the news ever cover NanoNixOS?
<wolfspraul> dvdk: no, good point!
<dvdk> wolfspraul: didn't try myself, but it looks pretty much working
<wolfspraul> actually good that you are here :-) how would you describe the mplayer news in 1-2 lines?
<dvdk> wolfspraul: could lie any say it is 100% stable now :)
<dvdk> wolfspraul: (url) yes looks like it.
<dvdk> wolfspraul: NanoNixOS does everything right where openwrt fails :)
<dvdk> (wrt recipies)
<dvdk> wolfspraul: wrt mplayer: what about writing "tuning and fixing efforts continued.  now plays up to qvga material of most patent-free video files, especially Ogg/Theora and Google's WebM, at full screen"
<wolfspraul> so anything up to 320x240 will be displayed full-screen (scaled up if necessary)
<wolfspraul> even with high bitrates/quality settings?
<wolfspraul> and how about audio - all types of audio, or just certain formats or certain downconverted bitrates/samplerates?
<dvdk> wolfspraul: haven't tested really all possibilities.  16:9 material at 30 FPS, high quality seems to play well.  320x240@25 FPS plays too, but this was black/withe, color might increase cpu load still.  we made quite a lot of advances in the last days
<wolfspraul> that was pretty clear :-) thanks a lot btw, I think you are by far out the most advanced mplayer guy we have...
<dvdk> wolfspraul: audio makes problems when more than 2 channels (i.e. surround) (although we might be able to fix that).  sample rates != 44100 will suffer some quality degratation when resampling, but vworbis at 2 channels should play, independend sample rate/quality
<dvdk> of course there's a flash/mmc bandwidth limit when bitrate goes too high :)
<wolfspraul> 16:9 you mean 320x180?
<dvdk> wolfspraul: tested at 320x176 (did i mention that we have a slight visialization bug with material not w/h divideble by 16? :)
<wolfspraul> well that's what I'm trying to get at - I try to distill the bottom line for the unsuspecting end user :-)
<wolfspraul> for example - they may take the .AVI from their videocamera, run ffmpeg2theora without any additional options, and then think it should work
<dvdk> wolfspraul: yes, it converges, but like charging a capacitor.  gets harder and harder to get it full.
<wolfspraul> but at 640x480, or 60fps, it will not (I guess)
<dvdk> wolfspraul: 640x480, 60fps: no-go.  if the yo 30 fps, QVGA all should be ok.  hmm, the not-dividable-by 16 bug could still hit (upstream mplayer bug), 'll try to fix that.
<dvdk> s/yo/go
<wolfspraul> so let's see "can now play most files in Ogg Theora and WebM formats up to 320x240 and 30fps, and most audio except for surround-sound"
<dvdk> mplayer lags the theora standard development by a few years.
<dvdk> wolfspraul: yeah, sounds reasonable.
<wolfspraul> I want to be as real as possible. Not over-hype, but also not make it too long with too many exceptions most people will not understand anyway.
<dvdk> wolfspraul: understand that too well.  frustrating users too early is a bad idea.  let them get addicted to nanonote first.
<dvdk> wolfspraul: everything work-in-progress.  as I said it's converging :)
<dvdk> and no real show-stoppers in sight
<wolfspraul> I want to add a url to an actual .ipk file - what's the best url?
<dvdk> wolfspraul: need to .ipks.  mplayer + the acceleration driver
<dvdk> best use my last builds?
<wolfspraul> up to you
<wolfspraul> I don't think many people will install it, but it needs to be included for professional reasons.
<dvdk> wolfspraul: it's just on dyndns.  getting upload to qi-hardware/files won't hurt
<wolfspraul> the most important thing is to include it in the next image...
<wolfspraul> yes I think xiangfu already copied something to the qi server, but I don't know whether that was the latest version since there is so much happening
<dvdk> wolfspraul: everything configured for automatic inclusion in next firmware already
<dvdk> (need both)
<dvdk> wolfspraul: xiangfu only copied the sources for building, no actual ipk
<dvdk> starts mass-filing mplayer (upstream) bug reports :)
<kyak> mirko: ping
<qi-bot> [commit] David Kühling: mplayer: fix playback of Theora files width width/height not multiple of 16 http://qi-hw.com/p/openwrt-packages/9b60e67
<qi-bot> [commit] David Kühling: mplayer_jz47xx: upgrade to 0.1.4 which fixes various bugs http://qi-hw.com/p/openwrt-packages/e43f37c
<qi-bot> [commit] David Kühling: mplayer: correct last patch for size-non-multiple-of-16 theora files http://qi-hw.com/p/openwrt-packages/1217996
<Fusin> .
<wpwrak> kewl. dma does something a again. i don't have the faintest clue how my changes could have affected what happens, but somehow, they do :)
<wpwrak> now .. how to make all this a little less horribly noisy
<wpwrak> aha. there's a hint. i turned off the dma channel before setting it up, as the manual instructs me to do, and afterwards, i switched it on again. the interesting effect is that this made it fail to start. the even more interesting effect is that is also keeps on failing to start it i revert to the previous version of the code. a hardware reset bring things back to sanity. hmm.
<wpwrak> hmm. and it's rather finicky about the front porch timing. make it 1 us longer or 0.5 us shorter, and it locks up again
<viric> wpwrak: the wlan module I told you is 'open' on the protocol
<viric> wpwrak: did you see?
<viric> openlink
<viric> openlink.org
<viric> wpwrak: and it has linux drivers
<viric> isn't it looking nice?
<viric> and it comes with sdio interface alreadyt
<wpwrak> viric: (openlink.org) okay, that looks good indeed
<wpwrak> viric: the module is also easily soldered, with contacts on the side, not just below (although that makes it a bit large)
<viric> well, I hope the drivers don't require an omap chip ;)
<wpwrak> heh ;-)
<wpwrak> so, why don't you give it a try ? connect it via UBB and see what it does
<viric> So having that on a board means only connecting the pins to SDIO?
<wpwrak> the data sheet isn't quite clear on what you really need. but maybe there's more documentation to be found
<wpwrak> you probably can't do things like BT audio over SDIO.
<viric> the next chip has even GPS :)
<viric> wl1281
<wpwrak> one more and it'll have LTE as well ;-)
<viric> hm what is lte?
<viric> power-over-wireless? :)
<wpwrak> the successor of UMTS :)
<viric> ahh ok
<wpwrak> you should try to get one and make it work. you can probably just solder a ribbon cable to it for experiments. later, maybe make a proper board
<wpwrak> for the antenna, you can use standard parts
<viric> Hardware-Based Encryption/Decryption Using 64-, 128-, and 256-Bit WEP, TKIP or AES Keys
<viric> that's more powerful than the wlan module in my PC, I think :)
<viric> wpwrak: if I had to do any board, I would do a board starting from your UBB.
<viric> it could even be used in a PC, through a micro-SD/SD adapter, if the PC has a SDIO card port
<viric> wpwrak: the sdio port is providing 3.3V?
<wpwrak> (board) you could make one that has just the connections, then connect with a ribbon cable to UBB. later, maybe make one that has the 8:10 card connector so that you can plug it into the ben like the atben. you could probably reuse the PCB antenna
<wpwrak> yes
<viric> what about the notebook antennas? They are not that bi
<viric> g
<wpwrak> yes, they probably work too. you just need to make sure they have the right impedance.
<wpwrak> for testing, you can also use the sort of antenna that connects to wireless routers, and connect it with an adapter cable to the U.FL connector
<viric> clear
<viric> I've some routers that have the small connectors...
<viric> their antennas have those small connetors. inside.
<wpwrak> viric: have you been able to find the wl1271 data sheet as well ?
<roh> viric: is that a hardmac module?
<viric> wpwrak: well, I have seen the same datasheet you have seen, I imagine
<viric> roh: no idea
<wpwrak> viric: i only found one describing the module's pinout and the electrical characteristics, but nothing describing the chip itself
<roh> i think there is nothing at all 'new' on this module
<roh> its just another one with no news at all
<roh> i dont see anything special.
<roh> The drivers for the WL1271 are not built into the open-source release. They were bolted onto the released Kernel and must be downloaded from the ARM Processor Wireless Connectivity Downloads Wiki page.
<roh> i short 'broken binary drivers'
<wpwrak> the driver itself should be open. the firmware isn't, though.
<roh> wpwrak: so its not more open than the atheros crap
<wpwrak> now the question is how much the firmware does ...
<wpwrak> yes, could be just as bad
<roh> wpwrak: its a mobile device. it should be hardmac to be useable.
<roh> i will continue to use softmac hw will that problem is fixed. ;) and ignore low-end mobile chipsets like this one (and atheros ar6k)
<wpwrak> "should" be hardmac ? i'm also more than happy with softmac :)
<roh> viric: sorry, but after so much dissapoiintment by the manufacturers of such 'solutions' one learns how to view through all their marketing bs and search for the important issues.
<roh> wpwrak: in softmac one can never archieve proper standby times. much too much traffic on the air if
<wpwrak> without chip documentation, one would also depend on the module maker. more sourcing risk.
<viric> so this chip represents nothing new in the field?
<wpwrak> roh: duh, use a "shallow sleep" kind of standby. not the mess we did at openmoko.
<roh> if you ask me: i hope that realtek or ralink get their asses down and do a mobile solution chipset.
<viric> I'm simply not aware of other chips around. I saw this on lwn.
<roh> wpwrak: eh.. have you checed what 'normal' wifi chipsets eat at power?
<roh> thats more than a moko in full use
<wpwrak> viric: it seems to be a small improvement over the status quo. e.g., if there's a mainline driver, that would make it better than, say, ar6k.
<roh> wpwrak: wifi card on a notebook 'on' usually eats atleast one watt.
<viric> I don't think the driver is in mainline
<wpwrak> roh: yes, but you get that power burn with soft- and hardmac
<roh> wpwrak: you get that power with softmac and all the traffic and thus wakeups on your big cpu
<wpwrak> viric: no mainline driver would be bad. been there, hated every minute of it :)
<viric> ok
<roh> wpwrak: i dont believe in softmac for mobile use for a simple reason: my device needs to be fully on not to fall out of the network. with hardmac it can 'wake up' the main cpu as son as the wireless gets 'packets addressed to me'
<wpwrak> roh: what mode of operation are you talking about ? taking a nap while the user is reading what the browser shows ? or suspend while being carried in your pocket ?
<roh> wpwrak: no. voip via wifi for example
<roh> SIMPLE usecases from reality.
<wpwrak> and why would it be so expensive for your cpu to run for a few cycles ?
<roh> also it sucks big time if your instant messaging breaks off everytime you lock the screen.
<roh> wpwrak: because its 'off'
<wpwrak> that again sounds like the problem design we had at openmoko
<roh> check the amount of work which needs to be done on that fat arm cores with multiple plls and shit.
<roh> wpwrak: these were not uncommon. welcome to reality. its not simpler anywhere.
<roh> there IS a reason why hardmac is a good idea.
<roh> there is just none why we dont get the source for it.
<wpwrak> naw, the openmoko design was an evil all-or-nothing process. also with very long wakeup times. not nice for anything.
<roh> wpwrak: we had additional issues. true.
<roh> wpwrak: yet waking up often involves waking up lots of shit we do not need at all to exchange packets. especially if its only 'still there, dont delete me from you auth list'
<wpwrak> sure, you can't get the minimum power levels if your cpu needs to wake up for every packet, that's clear. but i still doubt that this has to mean a disastrous power drain in real life
<roh> i mean.. go ahead.. show me a single mobile wifi chipset which is softmac. i havent seen one.
<roh> wpwrak: it IS desastrous. even on notebooks.
<wpwrak> atheros have been talking about offering softmac on the ar6002 ;-)
<roh> wpwrak: it even makes a huge difference how the thing is connected.
<roh> atheros is on my 'never again' list. from even before ar6k times
<wpwrak> ;-)
<roh> i have some accesspoints with their differenc chipsets.. and no. i dont know any chipset i'd prefer atm.
<roh> i got a fonera with a atheros ar2310 soc. (2.4ghz ap) some ar5k minipci for 5ghz ap (currently 2.4g client) and intel iwl3945... they all suck big time. i use ethernet cables basically all the time.
<roh> ar2310 gets incredibly hot and garbles packets from time to time (and the rf is so bad that it differs >3db over the range of channel 1-14
<roh> ar5k.. well.. its 2011 and in ap mode mac80211 still sometimes lets hostapd crash weirdly...
<wpwrak> 3 dB doesn't sound too evil
<roh> and iwl3945.. its drivers are broken weird and differently every kernelrelease since 2.6.2x
<roh> wpwrak: its enozgh to get from 'good' to 'no' link
<roh> maybe its 6db... i got nothing to measure true db at that freq.
<roh> thats what these lying drivers tell me ;)
<qi-bot> [commit] Werner Almesberger: ubb-vga.c: cleaned up setup process and prepared for DMA http://qi-hw.com/p/ben-blinkenlights/64f3047
<qi-bot> [commit] Werner Almesberger: ubb-vga.c: added (fragile) DMA support (locks up on anything but 800x600) http://qi-hw.com/p/ben-blinkenlights/a8a0cfa
<wpwrak> (no link) well yes, if you're at the limit, a difference of 0.00001 dB will do ;-))
<roh> wpwrak: so in the end i can say 'i tried'  (when it comes to wifi).. i cannot say i really succeeded
<roh> it works somehow. and if hostapd crashes rebooting the ap is the fastest solution
<wpwrak> suckish
<roh> exactly. but i am happy to run a wire everwhere i place my dock for a few month.
<wpwrak> now .. why does that bloody dma controller lock up ? and how do i get it to work again, without a full cpu reset ?
<roh> docking stations for thinkpads rule
<roh> wpwrak: btw.. we never spoke about 'running ap' or even 'multi-ap, same essid' networks ;)
<roh> thats a field where open divers fail completely atm.
<roh> +r
<roh> well.. not really the drivers. the 'app' supporting it in that case (and handling the auth/deauth foo)
<wpwrak> sounds fixable. maybe turn your anger into patches ? ;-)
<roh> wpwrak: its not really fixable without redesigning a lot.
<wpwrak> roh: more glory for the one who does it ;-)
<roh> all solutions i know which do proper roaming have central control nodes and only 'trunk out traffic' at the ap, do all management decicions on a central node (or its backup)
<roh> nah. wifi is boring  and slow anyhow
<roh> also its no fun without a single fullfeatured vendor giving specs/documentation
<wpwrak> true. let's wait ten years and then do it with sdr :)
<roh> surely not.
<roh> sdr will never be power-efficient
<wpwrak> by the, sdr will be small and efficient :)
<roh> simply because it needs to move much too much data for no reason
<roh> hw mod/demods are great
<wpwrak> so what ? as long as you don't move it far, that's cheap again. i didn't say you had to drag it all the way to the main cpu
<roh> wpwrak: wifi is something in the 10-40mhz wide bandwith area
<roh> in ofdm.
<wpwrak> i know :)
<roh> you'd need oversampling and thus a insane amount of clock and data speed.
<wpwrak> so, integrate you synth, mixer, dac, adc, and a bit of fpga, and you have pretty much all on one chip.
<roh> still a waste of power
<roh> work with somebody who has the right demod already
<wpwrak> perhaps. but if the waste is small enough, who cares ?
<roh> it will not be small. not at that numbers.
<wpwrak> and you'd be able to run a lot of things with the same chip.
<roh> you need to do all athat in less than 1/10th of a watt
<wpwrak> ten years :)
<roh> in ten years wifi is completely unimportant i guess.
<roh> replaced by something much faster and easier to implement. not that much stupidity in design.
<roh> e.g. you cant properly roam a client as an ap.
<wpwrak> 802.11y ;-)
<roh> you can only deauth it and hope it tries another ap
<roh> you cannot tell it 'connect there please'
<wpwrak> why not ?
<roh> bad design
<roh> in the protocol.
<wpwrak> if you know exactly where you want to connect, you can do this even with the existing protocol. no problem.
<roh> wpwrak: wifi cannot handle situations where you got a lot of nodes on only a small space
<roh> e.g. 3000 nodes in one building
<roh> we have that every year at the ccc congress
<roh> 2.4 ghz is dead. mostly unusable on big parts of the day.
<roh> 5ghz works barely (much more channels to be used at the same time, 2.4 has only 3 channels
<wpwrak> well, if your spectrum is saturated, you lose. that much is clear. and yes, the design for lots of bandwidth doesn't help.
<roh> its not only the spectrum. the effect multiplies when you got bad design in the protocol and bad implementations of it.
<wpwrak> it's fun to let 802.11 and 802.15.4 fight it out between each other. powerful 802.11 can mess up 802.15.4 quite badly, as expected. but 802.15.4 is also a pretty efficient 802.11 killer if you (ab)use it (im)properly ;-)
<roh> e.g. some specific versions of firmware or driver on apple computers made the most stupid roaming decisions.. to connect to the strongest ap they could recieve.. with no temporal dampening.. which made them 'flap' a lot
<roh> huh? what have 802.11  and 802.15.4 to do with each other?
<roh> their spectrum shouldnt even overlap
<wpwrak> bad news for all the apple fanboys :)
<wpwrak> of course the spectrum overlaps
<roh> wasnt 802.15.4 using the same as bt (only channel 13 and 14 of wifi) ?
<wpwrak> no, it has 16 channels from 2405 - 2480 MHz.
<roh> irgh
<wpwrak> and they're narrow
<roh> ah. so theyre nonoverlapping themselves, yes?
<wpwrak> yup
<roh> sometimes i really wonder how things could get THAT messed up. who has such bad ideas like channels overlapping itself?
<wpwrak> marketing ? ;-)
<roh> nah. i think they just never expected to be their own opponent.
<roh> means 'the whole bad used by wifi'
<DocScrutinizer> having fun?
<wpwrak> DocScrutinizer: battling with DMA ...
<roh> hey doc
<DocScrutinizer> ok, skimming backscroll I have to say I'm all with roh
<DocScrutinizer> hardmac has a reason
<DocScrutinizer> TI SmartReflex and zero-clock has a reason too
<DocScrutinizer> the suspend-to-ram idea of openmoko been idiotic from beginning
<roh> DocScrutinizer: its actually not that bad if you got decent amounts of ram and higher clocks. remember how much power ddr eats. and you cant just let it run lower
<roh> and 'using less ram if needed and disabling big parts of it' i havent seen implemented outside of big numa supercomputers yet ;)
<DocScrutinizer> hehe
<roh> dont get me wrong. would be really cool to have such mechanisms in notebooks, smartphones and notepads
<DocScrutinizer> idle power consumption of N900 - with CPU instant on (zero clock) and WLAN: ~7mA
<roh> n900 is a bad example of runtime ;)
<DocScrutinizer> how's that?
<roh> its one of the power-eating smartphones recently sold. i know some people using it. and recharing once a day is not a good result
<roh> +g
<DocScrutinizer> that's their own fault, installing apps that aren't designed well
<DocScrutinizer> I mean, a battery monitor that updates its own graphix at 10Hz, even when screen is blanked and app in background - WTF?!
<DocScrutinizer> without GSM I easily get stanby times of >3days here
<roh> having even only tcp conn running kills their schemes quite well... think.. jabber client ;)
<DocScrutinizer> with WLAN!
<DocScrutinizer> with IRC with like 10 chan I still get always on idle of >24h
<DocScrutinizer> with one chan probably more like 48h
<DocScrutinizer> without IRC or any other constat traffic causing app the standby time with WLAN on is more like >1week than <1day
<DocScrutinizer> the battery is 1340mAh, the measured average current on a single ssh over WLAN running bq27000 script is <10mA
<DocScrutinizer> do your math
<DocScrutinizer> even if it rises to 20mA it's still decent (depending on sleeps in that script, and config of AP)
<roh> DocScrutinizer: to be fair.. i still tend to think a week of battery runtime would be nice
<DocScrutinizer> roh: on N900 the major battery hog is 3G data (GPRS). For each even unsolicited inbound packet your TX ramps up for like 10s
<DocScrutinizer> of course for outbound packets as well
<DocScrutinizer> so depending on your carrier's NAT/FW setup they can suck your battery empty in a few hours, on a completely idle device
<DocScrutinizer> it's all up to confic of carrier's network
<roh> hihi
<DocScrutinizer> some fools are happy if they get a real public IP by their 3G DHCP
<qi-bot> [commit] Werner Almesberger: ubb-vga.c: DMA was set to transfer twice the amount needed, oops http://qi-hw.com/p/ben-blinkenlights/b273f27
<roh> DocScrutinizer: if you ask me.. nat is no solution to any problem.
<roh> if you want a packet filter.. use one.
<DocScrutinizer> I'm a great fan of user configurable stateful packet inspection on UMTS provider side FW
<DocScrutinizer> probably one of the very few valid usecases of uPnP
<qwebirc55913> kill Fusin
<qwebirc55913> ;)
<Fusin> no more killing me plz ;)
<rjeffries> wpwrak: there are a dozen or more mobile phones which support wifi yet have decent battery life.
<rjeffries> IMO if wifi was even an option for ben, it would significantly increase useability, and therefor broaden the maret
<wpwrak> rjeffries: see above :) take the module, connect it, see how bad or good the driver situation is
<rjeffries> if a user is at a public location such as a library, or a coffee shop, or a waiting room, there will likely be wifi
<rjeffries> wpwrak that is as you know way WAY above my pay grade
<rjeffries> but somebody in the community will.
<wpwrak> rjeffries: no matter how far you have to go, the journey always starts with the first step ;-)
<urandom__> omg nanonote flashing success on first try, yeah!
<rjeffries> is this the board? it is the $27 wifi module plus support circuitry  https://boardzoo.com/product_info.php?products_id=1
<lekernel> ~#{~!! we need PRs for f**k's sake
<wpwrak> lekernel: PRs ?
<lekernel> openmoko got that one right, but apparently only the geeks stayed here :-P
<lekernel> press releases
<lekernel> (and other forms of advertisement)
<wpwrak> lekernel: ah yes. a bit more publicity would be very good to have
<wpwrak> rjeffries: that's the module plus some stuff you seem to need to interface to the beagleboard, yes
<lekernel> maybe we can set a rule that every second week (or even once in a week), someone in our core community (not always the same) has to release an article to a high profile news site (slashdot, engadget, ...)
<wpwrak> rjeffries: keep on going ;-) btw, the module without beaglestuff is here: http://www.mouser.com/ProductDetail/LS-Research/450-0037/?qs=sGAEpiMZZMuz9EkqwWgEDcRrleT5ZvLr
<rjeffries> I saw that don't understand how it could be connected to the Ben 8:10 connector
<wpwrak> lekernel: hmm, i wouldn't even know how you "release an article" to them ...
<lekernel> really, this has to move forward.
<lekernel> wpwrak: depends on the site. slashdot has user submissions and then people vote the article (unfortunately, I can notice a tendency to vote down milkymist related articles)
<lekernel> for others, I guess you pick a journalists and bother them until the article is out
<wpwrak> rjeffries: it has an SD interface. so you can use UBB plus a ribbon cable to connect. here's the data sheet: http://www.lsr.com/downloads/tiwi_r2/tiwi_r2_datasheet.pdf
<wpwrak> rjeffries: unfortunately, not very detailed
<rjeffries> lekernel something we need to understand is why so many Nanonotes are what one might call "Drawer computers" or "shelf computers" i.e. NOT BEING USED AT ALL
<wpwrak> lekernel: maybe we should just call everything we do "iPad killer" and such ;-)
<lekernel> rjeffries: is that significantly higher than with other tech products?
<rjeffries> wolfspraul 's most recntlt released sales indicate maybe 1100-1200 Bens in the world. there may be at most 5o active users
<lekernel> wpwrak: do whatever you can that has a good attracted attention vs. attracted problems ratio :-)
<rjeffries> lekernel fora product such as ben that should appeal most to geeks and techno nerds, the silence is deafening. Ben has not struck a nerve. in fact, one could argue it is on life support
<wpwrak> lekernel: i just imagine the expression on the faces of the apple lawyers - what, it's an "iPad killer" yet we don't have a single patent we can use against them ? ;-)
<rjeffries> iit may well be that the future is more in the directing of your FPGA work. clearly that ius where wolfspraul is focusing
<lekernel> wpwrak: I don't care about the apple lawyers. they are boring and dull people. but I do care about selling Milkymist (and other stuff) to cool people.
<wpwrak> rjeffries: imho, what the ben needs badly is a successor. alas, the successor needs financing. not a lot, as far as such things go, but still more than you probably carry around in your wallet
<rjeffries> wpwrak I agree re urgent need for Ben NN sucessor
<wpwrak> lekernel: yes, i understand your sense of urgency all too well
<lekernel> anyway, I believe we do need to make the news. more people could only improve those things.
<lekernel> the arduino, for example, is successful because there are lots of tutorials available
<lekernel> there is no such things for Ben
<lekernel> having more people could only mean more tutorials written
<lekernel> for milkymist, it's more about looking for core developers. geeks aren't the primary audience.
<wpwrak> lekernel: the way you phrase it, it sounds like a bit of a chicken and egg problem
<wpwrak> lekernel: (core dev) in which areas ?
<lekernel> anything. software, fpga, whatever :-)
<lekernel> we already have the technical resources to make it a end user product, so there aren't really constraints or pressure on what should be done
<lekernel> but it's very cool to see stuff like that GDB in system debugger or QEMU emulation that mwalle contributed
<wpwrak> lekernel: you say you already have the technical resources ... so you're looking more for people who help with community-building, in the sense of adding stuff to/around the base system ?
<lekernel> atm one big task I'm thinking about is video streaming support (vp8 or theora)
<lekernel> yeah
<wpwrak> one thing that's useful for generating news articles are product announcements
<lekernel> yeah, but we're not going to announce a new product every second week
<lekernel> really I want to set the pace of news release to something quite aggressive :-)
<lekernel> even if they're not big news. way to build momentum ...
<lekernel> so we can fill it with e.g. new software features
<wpwrak> it still has to be interesting enough to make it past whatever relevance criteria are in place
<lekernel> please do not talk to me about relevance when such crap http://hardware.slashdot.org/story/11/04/30/172214/Help-Build-the-Worlds-First-Community-Funded-CPU-ASIC makes it to slashdot
<wpwrak> there are countless projects that make release after release without making the news
<lekernel> yes. we should not be one of those anymore.
<lekernel> even the average milkymist commit is more relevant than that retarded opencores project
<wpwrak> (crap) well, we could do the same. ask for donations for making mm1 or a ya
<lekernel> why donations? contrary to opencores we have stuff to sell
<wpwrak> the opencore people probably have a slightly different opinion ;-)
<wpwrak> (about relevance)
<wpwrak> well, release announcements then
<lekernel> yes
<wpwrak> milkymist software version 2.0 with these features: <insert list>
<wpwrak> ben nanonote distribution 2011Q2 with <...list...>
<lekernel> yeah, this kind of thing... but with a slight touch of sensationalism :)
<wpwrak> of course :)
<lekernel> and get that posted to the fucking big news sites
<lekernel> slashdot, engadget, heise, ....
<wpwrak> "kills the iPad so dead that even your iPhone and iPod will die" ;-)
<lekernel> I said "slight touch"
<wpwrak> hey, i didn't say that it'll also do steve jobs ;-)
<wpwrak> i wonder what went wrong with heise. qi-hw never made it to the newsticker there. that's a bit odd.
<lekernel> it made it once
<wpwrak> not only to heise open ?
<lekernel> maybe that's just because they get no news from us
<lekernel> and do not go looking for them...
<wpwrak> wolfgang says he has a contact there
<lekernel> which is exactly the problem I'm talking about solving now
<lekernel> that doesn't mean he mails them regularly
<wpwrak> of course. but then, if he spams them every week, they may just ignore him
<lekernel> that's why I'm talking about 1) several people to write to the journalists (also because it's a daunting task, so it's better if we share that burden) 2) several news outlets to contact
<wpwrak> let's look at the steps ...
<wpwrak> 1) produce something newsworthy
<wpwrak> 2) brag about it to the right people
<wpwrak> 3) get those people to pass it on
<wpwrak> miss one of these steps, and it doesn't fly. now, do we know where the problems are ?
<lekernel> ok, even if it's not perfect, it's still going to be A LOT better than the current "no PR" policy, no?
<wpwrak> regarding 1), the ben and the first mm1 release would certainly count.
<wpwrak> i'm not sure there's a "no pr" policy. all i see is that very little makes it to the end.
<lekernel> lack of policy is a policy :-)
<wpwrak> tuxbrain got two hits (i think) with ubb+arduino. not sure if this resulted in much, though.
<wpwrak> but at least he got the word out
<lekernel> tbh I think that we definitely have newsworthy stuff to post every month, at least.
<lekernel> he got the word out? where? on his blog?
<wpwrak> naw, on some gadget sites
<lekernel> no one reads it. i'm not saying that to bash David, it's the same with milkymist.org, the milkymist blog, and qi-hardware.com
<wpwrak> i forgot which - i usually don't read much but heise newsticker :)
<wpwrak> so, what of the stuff we currently have or are already doing would you consider suitable for a news item ?
<lekernel> hmm... it's on arduino.cc and adafruit.com. not too bad indeed.
<lekernel> but we need more of this stuff
<wpwrak> agreed :)
<jirkab>
<wpwrak> thinking of it, even openmoko didn't get too many items at major sites. an announcement for each product, and i think one article when it shut down, but that was all
<lekernel> wpwrak: your VGA board is worthy to be posted to adafruit.com and hackaday. get it there.
<wpwrak> so i'm not sure how the word got around. maybe via places i don't look at, maybe via "2nd class" news channels, maybe purely viral
<lekernel> milkymist is _really_ difficult to post to such sites btw. they just don't get what it's about. but it should be better on bigger sites.
<jirkab> rjeffries: I'm an active NanoNote user, too (jirkasnotes.wordpress.com). I use my NanoNote on daily basis ;-)
<wpwrak> yeah, VGA will be good for those. need to get it to be slightly more predictable, though.
<lekernel> oh, don't bother... even in its current state it's already a lot better than the average hackaday project
<lekernel> and they actually like half-working stuff
<lekernel> funny the other day someone from makezine asked me for pictures of "half built" M1s because he felt the studio pictures we put online recently were too 'slick'
<lekernel> hahaha
<wpwrak> VGA could also be an element for an experimentation kit. maybe 10 simple circuits or so. that would even be a "product". would need a few more small circuits, though. i'm a bit disappointed that nobody seems to have done anything with UBB yet.
<wpwrak> lekernel: (mm1) yeah, it's already too many things in one ;-)
<lekernel> wpwrak: I'd guess UBB would need tutorials ...
<wpwrak> lekernel: yes
<lekernel> it's typically the type of thing that would fit on instructables and all the arduino-friendly blogs
<wpwrak> this kind of things makes me green with envy: http://ucontroller.com/Propeller Protoboard Designs for the Beginner.pdf
<lekernel> the propeller is a piece of crap, but that's the kind of tutorials that would already be a good step for UBB/NN
<wpwrak> tuxbrain once had the idea of bundling UBB with a breadboard. not sure what became of the idea. (other than that it didn't result in a product)
<wpwrak> exactly
<wpwrak> in fact, i did the vga thingy because rjeffries was getting on my nerves with suggestions to use a prop for video output ;-)
<lekernel> ok. anyway. what do you think of my idea of the "news round" ?
<wpwrak> i wouldn't give it a fixed schedule. maybe rather ask if there are people who can help with that and which channels they can address. then push news in that direction.
<lekernel> we need to do our promotion homework somehow. otherwise we're going to be stuck in that "little fringe and obscure projects no one cares about" state.
<jirkab> wpwrak: your VGA output work is a great thing (I will be very happy if this will be a way for presentations from NN - even for tatis images)
<lekernel> fixed schedule ensures that homework gets done
<wpwrak> jirkab: thanks :) what's "tatis images" ?
<jirkab> wpwrak: oops - static images :-(
<wpwrak> lekernel: homework doesn't get done if people are not motivated. perhaps there are some who would be motivated ?
<wpwrak> jirkab: aah, yes. at least for now, static seems to be the way of things.
<wpwrak> lekernel: so maybe as a first step, float the idea of putting more effort into PR on the list. state the current weaknesses. invite people to help. see what happens.
<wpwrak> lekernel: if everybody agrees that this would be a great thing for someone else to do, then try to tighten things
<wpwrak> lekernel: if volunteers step forward, let them figure out their modus operandi
<wpwrak> lekernel: call it a "pr task force" if you want :)
<lekernel> hahaha
<viric> some people here use 'netsurf' in the nanonote?
<qi-bot> [commit] Werner Almesberger: ubb-vga.c: moved some DMA settings from per-line to per-session setup http://qi-hw.com/p/ben-blinkenlights/9fb5c6f
<qi-bot> [commit] Werner Almesberger: tstimg.c: completed the alphabet http://qi-hw.com/p/ben-blinkenlights/7d16a06
<qi-bot> [commit] Werner Almesberger: ubb-vga.c (struct mode, mode_db): removed no longer used field "line_words" http://qi-hw.com/p/ben-blinkenlights/90b087c
<qi-bot> [commit] Werner Almesberger: ubb-vga: gently prepare the code for sharing mode information http://qi-hw.com/p/ben-blinkenlights/f7eb220
<qi-bot> [commit] Werner Almesberger: ubb-vga: make mode information global http://qi-hw.com/p/ben-blinkenlights/eabd0b5
<qi-bot> [commit] Werner Almesberger: tstimg.c (tstimg): display timing parameters http://qi-hw.com/p/ben-blinkenlights/3007939
<qi-bot> [commit] Werner Almesberger: ubb-vga: added quick and dirty run-until-keypress mode http://qi-hw.com/p/ben-blinkenlights/934a89b
<lekernel> wpwrak: openpandora: 4000 units sold, 100 users in #openpandora right now
<lekernel> (and rjeffries :p )
<lekernel> btw they posted it on engadget http://www.engadget.com/2008/09/30/pandora-pre-orders-go-live/
<lekernel> so the drawerware ratio seems quite consistent to me
<wpwrak> we're above average then ;-)
<rjeffries> lekernel thanks for suggesting I buy a Pandora gizmo. ;) I have not paid attention since the early days when they struggled do get a few built
<mth> they're still struggling to get them built, although they do produce at a steady pace now
<mth> I'm still waiting for mine though
<lekernel> we should do their production while they do our advertisement :p
<wpwrak> ;-))