<vladkorotnev> hello everyone :P is there any program to listen to XM, IT, MOD and other module files for the Ben NanoNote?
<qi-bot> [commit] Xiangfu Liu: [nanonote-files] reflash_ben.sh: fix -d using correct path http://qi-hw.com/p/openwrt-packages/cb0fb36
<qi-bot> [commit] kyak: gcc-mips: prepare for trunk http://qi-hw.com/p/openwrt-packages/e12038a
<qi-bot> [commit] kyak: alsa-lib: no need for this patch in trunk http://qi-hw.com/p/openwrt-packages/5d9fb4f
<qi-bot> [commit] kyak: ncursesw is perfectly fine in openwrt trunk, no need to override http://qi-hw.com/p/openwrt-packages/2a9d88c
<qi-bot> [commit] kyak: triggersad is now happy again! http://qi-hw.com/p/openwrt-packages/a587847
<qi-bot> [commit] kyak: guile: fix compilation in trunk http://qi-hw.com/p/openwrt-packages/bd0dd2e
<qi-bot> [commit] kyak: gnuplot-gfx: fix compilation issue in trunk http://qi-hw.com/p/openwrt-packages/db5ca76
<qi-bot> [commit] kyak: ben-cyrillic: fix keymap for VolUp/VolDown http://qi-hw.com/p/openwrt-packages/94156cd
<qi-bot> [commit] kyak: keymouse: fix keymap for VolUp/VolDown http://qi-hw.com/p/openwrt-packages/6c1f1bd
<qi-bot> [commit] kyak: ks7010: support kernel > 2.6.35 http://qi-hw.com/p/openwrt-packages/da6e346
<qi-bot> [commit] kyak: busybox in trunk has changed some unicode options http://qi-hw.com/p/openwrt-packages/11d4435
<qi-bot> [commit] kyak: libpurple: initial port http://qi-hw.com/p/openwrt-packages/57d4eb8
<qi-bot> [commit] kyak: centerim5: initial port http://qi-hw.com/p/openwrt-packages/e4daa38
<xiangfu> kyak, Hi
<xiangfu> kyak, will send you an email about the commit on openwrt-package trunk.
<qi-bot> [commit] Xiangfu Liu: [nanonote-files] reflash_ben.sh: update version to 2011-05-22 http://qi-hw.com/p/openwrt-packages/cdd70d2
<xiangfu> OpenWrt Release: for stable 2011-05-22
<larsc> whitequark: not on the jz47xx branch
<qi-bot> [commit] kyak: alsa-lib: no need for this patch in trunk http://qi-hw.com/p/openwrt-packages/09d5d02
<qi-bot> [commit] kyak: ncursesw is perfectly fine in openwrt trunk, no need to override http://qi-hw.com/p/openwrt-packages/1d17965
<qi-bot> [commit] kyak: triggersad is now happy again! http://qi-hw.com/p/openwrt-packages/ed48679
<qi-bot> [commit] kyak: guile: fix compilation in trunk http://qi-hw.com/p/openwrt-packages/ec6b1e7
<qi-bot> [commit] kyak: gnuplot-gfx: fix compilation issue in trunk http://qi-hw.com/p/openwrt-packages/17d05bb
<qi-bot> [commit] David Kühling: mplayer_jz47xx: upgrade to 0.1.5 version that supports /proc/<pid>/pagemap http://qi-hw.com/p/openwrt-packages/36bcb9e
<qi-bot> [commit] David Kühling: mplayer_jz47xx: fix md5-sum for updated version http://qi-hw.com/p/openwrt-packages/f342c3b
<qi-bot> [commit] kyak: update ffmpeg to a working git revision http://qi-hw.com/p/openwrt-packages/71d83e9
<qi-bot> [commit] kyak: ben-cyrillic: fix keymap for VolUp/VolDown http://qi-hw.com/p/openwrt-packages/38ada8f
<qi-bot> [commit] kyak: keymouse: fix keymap for VolUp/VolDown http://qi-hw.com/p/openwrt-packages/3c53b09
<qi-bot> [commit] kyak: ks7010: support kernel > 2.6.35 http://qi-hw.com/p/openwrt-packages/822e1e0
<qi-bot> [commit] David Kühling: emacs: make programming language comments colored by default http://qi-hw.com/p/openwrt-packages/32e4ab8
<qi-bot> [commit] kyak: config.full_system: disable busybox's strings, enable binutils and http://qi-hw.com/p/openwrt-packages/05e9503
<qi-bot> [commit] Xiangfu Liu: nanonote-files: config.full_system: disable libxfce4util http://qi-hw.com/p/openwrt-packages/cd2b5dc
<qi-bot> [commit] Xiangfu Liu: nanonote-files: feeds.conf: disable useless feeds http://qi-hw.com/p/openwrt-packages/2a5cc31
<qi-bot> [commit] kyak: busybox in trunk has changed some unicode options http://qi-hw.com/p/openwrt-packages/ef1173e
<qi-bot> [commit] kyak: libpurple: initial port http://qi-hw.com/p/openwrt-packages/0cde876
<qi-bot> [commit] kyak: centerim5: initial port http://qi-hw.com/p/openwrt-packages/d04c529
<qi-bot> [commit] kyak: Merge branch 'master' into trunk http://qi-hw.com/p/openwrt-packages/ad8ac99
<qi-bot> [commit] kyak: Merge branch 'trunk' of projects.qi-hardware.com:openwrt-packages into trunk http://qi-hw.com/p/openwrt-packages/1e52ad6
<kyak> xiangfu: hm, i don't understand.. after i did git pull, i got 21 commits ahead of trunk?...
<xiangfu> kyak, I rebase the trunk branch, for get some last commit from 'master'
<xiangfu> I guess there is a 'git merge master' in your local git
<kyak> xiangfu: what's the difference between rebasing and merging? I think the history is lost during rebase.. So we should merge
<kyak> xiangfu: btw, i answered you e-mail
<xiangfu> rebaseing: is try to apply the pathes on top of another branch. if there are same commits like "nanonote-files: feeds.conf: disable useless", will only have one after rebase.
<xiangfu> merge will just mix them together for simple :)
<kyak> damn.. why it has to be so hard :)
<kyak> anyway, i wonder why i do 'git co master' and see centerim5 package there
<xiangfu> kyak, maybe you run 'git merge trunk' under 'mater' branch
<kyak> also i wonder why the history is lost every time.. ]
<kyak> xiangfu: no-no, it says "on branch master"
<kyak> and no commits pending
<xiangfu> the history is changed after rebase.
<kyak> i think we should always avoid push -f
<kyak> this is what causing history lost.. am i right?
<xiangfu> yes.
<xiangfu> but sometime we have to do that. :(, like rebase openwrt-xburst on top of last upstream backfire
<xiangfu> the only thing is after rebase we have to run 'git reset --hard origin/trunk' at local
<kyak> why do we have to do that?
<xiangfu> kyak, or we will never find our commit again.
<kyak> hm
<xiangfu> like our commit will insterted to 100 openwrt upstream commit.
<kyak> ah ok..
<kyak> something similar i did recently :))
<kyak> resolved manually the conflict in sound.mk
<xiangfu> kyak, sorry, I have to rebase the 'trunk' branch again. there are some mess. :)
<kyak> and the commit got inside another commit
<kyak> xiangfu: yeah, please do what you have to do :)
<xiangfu> kyak, but after this time, I think we will never rebase 'trunk' again. :)
<kyak> why not?
<kyak> trunk is still not the same as master
<xiangfu> all master commits have included by trunk
<kyak> yeah
<xiangfu> and since we decide switch to 'trunk' we will never try to commit new thing to 'master' only fix last release bug I think
<kyak> but not all trunk commits are included in master
<kyak> ah, ok
<kyak> i thought we are going to "overwrite" master with trunk
<xiangfu> 'trunk' will became 'master' in next few days :)
<xiangfu> rename them
<kyak> ok
<xiangfu> 'master' --> 'backfire'
<xiangfu> 'trunk' --> 'master'
<kyak> this makes sense
<xiangfu> same with openwrt-xburst.git I think.
<kyak> xiangfu: centerim5/libpurple commits must not get inside the master (i.e. backfire)
<xiangfu> yes.
<xiangfu> so we only rebase on top 'master', never merge 'trunk' back to 'master'
<qi-bot> [commit] Xiangfu Liu: [nanonote-files] reflash_ben.sh: update version to 2011-05-22 http://qi-hw.com/p/openwrt-packages/cdd70d2
<qi-bot> [commit] kyak: gcc-mips: prepare for trunk http://qi-hw.com/p/openwrt-packages/83e109c
<qi-bot> [commit] kyak: alsa-lib: no need for this patch in trunk http://qi-hw.com/p/openwrt-packages/d9c3322
<qi-bot> [commit] kyak: ncursesw is perfectly fine in openwrt trunk, no need to override http://qi-hw.com/p/openwrt-packages/60ae3de
<qi-bot> [commit] kyak: triggersad is now happy again! http://qi-hw.com/p/openwrt-packages/0f74ee4
<qi-bot> [commit] kyak: guile: fix compilation in trunk http://qi-hw.com/p/openwrt-packages/e0bb18d
<qi-bot> [commit] kyak: gnuplot-gfx: fix compilation issue in trunk http://qi-hw.com/p/openwrt-packages/a8ac0c6
<qi-bot> [commit] kyak: ben-cyrillic: fix keymap for VolUp/VolDown http://qi-hw.com/p/openwrt-packages/f54d4ad
<qi-bot> [commit] kyak: keymouse: fix keymap for VolUp/VolDown http://qi-hw.com/p/openwrt-packages/5395297
<qi-bot> [commit] kyak: ks7010: support kernel > 2.6.35 http://qi-hw.com/p/openwrt-packages/82df0af
<qi-bot> [commit] kyak: busybox in trunk has changed some unicode options http://qi-hw.com/p/openwrt-packages/839aab9
<qi-bot> [commit] kyak: libpurple: initial port http://qi-hw.com/p/openwrt-packages/4fd96bb
<qi-bot> [commit] kyak: centerim5: initial port http://qi-hw.com/p/openwrt-packages/00d5146
<xiangfu> kyak, last rebase done. you can 'git fetch -a && git reset --hard origin/trunk' under local trunk branch
<xiangfu> then run 'gitk' you will see all commits is on top of master
<kyak> ok, never merge, always rebase :)
<xiangfu> the merge is used like: there are three branch 'master' 'ben-naonote' 'ya-naonote', then we can merge 'ben-nanonote' under 'master', merge 'ya-nanonote' under 'master'
<xiangfu> but our case is we have to rebase on top of openwrt upstream, also this rebase help us find the different with upstrem
<xiangfu> just fyi, :)
<kyak> yep, i got it.
<kyak> just i still don't understand why some files in web interface don't have history
<kyak> see ben_ru_uni.map
<kyak> this was changed recently
<kyak> and it's date and history is empty
<xiangfu> the projects.qi-hardware.com using 'indefero' cache a lot, so we better check that again tomorrow :)
<xiangfu> hmm.. there is no 'age' and 'message' on ben_ru_uni.map
<kyak> yes
<kyak> and the same for some other files
<kyak> i'd say that all commits to trunk don't have such history
<xiangfu> seems it's 'indefero' cache problem. let's give 'indefero' 24 hours for caching :)
<kyak> it's not caching, most commits are much more than 24 hrs old
<kyak> like that gcc-mips commit
<xiangfu> but we just rebased.
<kyak> hmm
<kyak> this is tricky.. i thought the commit identifier is kept
<kyak> ok, let's see in some time :)
<xiangfu> kyak, if the last openwrt release don't have big bug/problem, we can switch to 'trunk' after that.
<xiangfu> kyak, also we can think about Jlime/Openwrt dual boot,
<xiangfu> think about nand partition, since we have fast mount time,
<xiangfu> add atben support
<kyak> i'm using trunk for quite some time now, without apparent problems. Btw, plplot fails to build for some reason, i guess we could ask dvdk to have a look..
<xiangfu> yes.
<kyak> xiangfu: dual boot - i think it's working already by holding a button during power on. What more can we wish?
<kyak> some menu.. i'm not sure, it only waste precious seconds during bootup
<xiangfu> yes. then the Jlime/Openwrt have to install in two partition.
<kyak> 2 Gb is not much at all :)
<xiangfu> I don't have clear idea on dual boot. :(
<kyak> taking into account the growing number of uSD slot hacks
<kyak> not everyone would have spare uSD slot for jlime :)
<kyak> i'm happy with the current partition layout
<kyak> more than 512 Mb for rootfs is good if you need to pre-install all the software. but in real life, one person doesn't need that much
<kyak> 512 Mb rootfs with around 150 Mb free space for installation of additional pacakges is good
<kyak> having 2 Gb rootfs would make me hesitate to reflash
<kyak> because i'm lazy to backup and then restor my user files after reflash
<xiangfu> back/restore is bad. me either
<xiangfu> I mean I also don't want to do backup/restore.
<kyak> having some space that can survive between reflashes is good.
<kyak> frankly, i wouldn't give another 512 Mb of NAND for the second OS.. 1.5 Gb of datafs is not that much at all
<kyak> also, i don't know who will be using both OSs actively at the same time
<kyak> i.e. constantly switching between each other
<kyak> another OS that would be just a waste of space
<kyak> for someone using jlime, 512 Mb of openwrt (that he doesn't use or uses very rare) is a waste of NAND
<kyak> and vice versa
<kyak> and, having two OS's means doubling of support efforts
<xiangfu> yes.
<xiangfu> that's true
<lunavorax_frizzl> Hi all!
<xiangfu> lunavorax_frizzl, Hi
<kyak> xiangfu: do i need to be root to run reflash_ben.sh?
<kyak> i saw this requirement had been removed
<kyak> i'm almost used to flashing Ben as root :) is it required?
<xiangfu> since the xburst-tools have changed, as long as you have write access to ingenic usb device like:
<xiangfu> /etc/udev/rules.d$ more 80-ben-nanonote.rules
<xiangfu> SUBSYSTEM=="usb", ATTRS{idVendor}=="601a", ATTRS{idProduct}=="4740", MODE="0666"
<xiangfu> kyak, at before, we check 'root' under 'reflash_ben.sh' and 'usbboot',
<xiangfu> but using udev is better then just 'root'
<kyak> i see that checking for root has been removed
<xiangfu> kyak, me too, before setup the udev :)
<kyak> i'll setup udev :)
<kyak> it was buggin me to run that as root, but not as much as to take measures :)
<kyak> xiangfu: couple of days ago, i merged openwrt-trunk into qi-openwrt-trunk. Should i now rebase instead?
<xiangfu> which repos? openwrt-xburst.git?
<kyak> there was only one conflict at that time.. i think it lead to creation of "double" merge
<kyak> yeah, openwrt-xburst.git
<kyak> i.e. our local change in sound.mk got merged with upstream change in another (third) commit
<kyak> instead of rebasing on top of that upstream change
<xiangfu> yes. rebase is better for maintain our commits.
<xiangfu> you can use 'git rebase -i OPENWRT_TRUNK_BRANCH_NAME'
<xiangfu> then it will bring a text for you to edit. decide which commit you want.
<kyak> yep, it brings the text
<kyak> i want all of them :)
<kyak> not sure if this one "pick a85f9e8 trunk: build sound modules in kernel"
<kyak> will rebase without conflicts
<xiangfu> just save and exit. see if there is conflicts?
<xiangfu> if no. then everything is find. if there is we have to manually fix the conflict.
<kyak> Could not apply a85f9e8... trunk: build sound modules in kernel
<kyak> just like i said
<kyak> after i fix the conflict. How should i proceed?
<kyak> add/rm this file, or git rebase --continue ?
<xiangfu> 'git rebase --continue'
<xiangfu> you can run 'git mergetools'
<xiangfu> sorry, 'git mergetool'
<kyak> one minute..
<kyak> Could not apply 21fdcfd... package/kernel: Remove all 2.4 definitions
<kyak> but files require merging.. wtf?
<kyak> *no files
<xiangfu> this commit is from upstream?
<xiangfu> sorry. should be from ours.
<xiangfu> where is this commit from ? are you sure you have correct branch? current branch and which branch you are rebase on?
<kyak> that commit is from upstream
<kyak> i know how it got there..
<kyak> that' because of merging..
<kyak> fixing it now..
<qi-bot> [commit] jow: [package] iw: fix calculation of fractional multicast rates like 5.5Mbps due to wrong operator precedence http://qi-hw.com/p/openwrt-xburst/030f9c1
<qi-bot> [commit] jow: [package] ncurses: enable C++ bindings (#9442) http://qi-hw.com/p/openwrt-xburst/bfa121a
<qi-bot> [commit] jow: [netfilter] package u32 match and TEE target, patches by Maxim Uvarov http://qi-hw.com/p/openwrt-xburst/36715e6
<qi-bot> [commit] Xiangfu Liu: optimize for ben nanonote http://qi-hw.com/p/openwrt-xburst/402a517
<qi-bot> [commit] Xiangfu Liu: [xburst] Improve mounttime http://qi-hw.com/p/openwrt-xburst/807cc4b
<qi-bot> [commit] Xiangfu Liu: nanonote optimize http://qi-hw.com/p/openwrt-xburst/5f63507
<qi-bot> [commit] Xiangfu Liu:  Add-gfortran-compiler-support-to-the-toolchain http://qi-hw.com/p/openwrt-xburst/eaaf0bd
<qi-bot> [commit] kyak: add kernel patch for setfont2 http://qi-hw.com/p/openwrt-xburst/2703fe0
<qi-bot> [commit] Xiangfu Liu: optimize for ben nanonote http://qi-hw.com/p/openwrt-xburst/ed08699
<qi-bot> [commit] kyak: config-2.6.37: enable battery, disable RNDIS http://qi-hw.com/p/openwrt-xburst/8d85716
<qi-bot> [commit] kyak: patches-2.6.37: support for Ben NAND partitioning http://qi-hw.com/p/openwrt-xburst/21c6371
<qi-bot> [commit] David Kühling: linux kernel: add CONFIG_PROC_PAGE_MONITOR=y to allow for clean user-space DMA http://qi-hw.com/p/openwrt-xburst/1502cdd
<qi-bot> [commit] kyak: config-2.6.37: enable options needed for keymouse http://qi-hw.com/p/openwrt-xburst/89bf2df
<qi-bot> [commit] kyak: trunk: fix kernel keymap for VolUp/Down and Del http://qi-hw.com/p/openwrt-xburst/c27e043
<qi-bot> [commit] kyak: trunk: build sound modules in kernel http://qi-hw.com/p/openwrt-xburst/c1d7c81
<qi-bot> [commit] kyak: trunk: add ks7010 support patch http://qi-hw.com/p/openwrt-xburst/328d74a
<qi-bot> [commit] Xiangfu Liu: base-files, move it to openwrt-package/nanonote-files http://qi-hw.com/p/openwrt-xburst/0432ba5
<qi-bot> [commit] Xiangfu Liu: optimize for ben nanonote http://qi-hw.com/p/openwrt-xburst/80fdec5
<qi-bot> [commit] Xiangfu Liu: base-files, move it to openwrt-package/nanonote-files http://qi-hw.com/p/openwrt-xburst/920e585
<kyak> xiangfu: now everything should be as expected.. Could you double check?
<kyak> our commits to trunk nice and clean on top of the latest trunk
<xiangfu> great. one small things is you can just remove the top three commits.
<xiangfu> since it'a add and delete the same file.
<xiangfu> kyak, sorry. the top two commits. not three.
<kyak> heh, right :)
<kyak> hooks/post-update: line 24: echo: write error: Broken pipe
<kyak> hmm
<kyak> but anyway, git reset --hard HEAD~2; git push -f origin trunk is done
<xiangfu> kyak, great you have merged 'fix typo from the previous commit' to the correct commits :)
<kyak> yeah, that i did, too :)
<kyak> that was embarassing typo :) now noone knows it has ever been
<xiangfu> :D
<xiangfu> hmm.. I can not 'git fetch -a', it show there is no update in git server.
<xiangfu> can you push again
<kyak> one sec
<kyak> $ git push origin trunk
<kyak> Everything up-to-date
<xiangfu> wait, it's working now.
<kyak> git show-branch openwrt trunk (openwrt is the name of remote openwrt branch) shows 15 commits in trunk
<xiangfu> kyak, works just fine.
<kyak> good!
<kyak> git log -p ^openwrt trunk <- create cumulative patch from openwrt-trunk to qi-openwrt-trunk :)
<kyak> such a beast...
<xiangfu> you want git diff openwrt ?
<kyak> heh, another way to do it :)
<kyak> git has too much to offer
<xiangfu> one big patch :)
<xiangfu> git format-patch -15 :) is better
<kyak> different commands can be used to achieve the same goal,, perhaps it's not very good
<lunavorax_frizzl> Anyone here knows a good DOS disassembler ?
<qi-bot> [commit] Werner Almesberger: bin/fk: little helper script to flash the kernel via SSH or usbboot http://qi-hw.com/p/wernermisc/387e6dd
<qi-bot> [commit] Werner Almesberger: bin/ben, bin/jlime: helper scripts for network setup and SSH login http://qi-hw.com/p/wernermisc/6aace95
<lunavorax_frizzl> Oh I never realized how much space Xorg was using in RAM
<lunavorax_frizzl> ~580MB
<DocScrutinizer> nt exactly xorg but probably all the apps allocating rather large canvas aka webpages aka oversized scrollable windows
<DocScrutinizer> which are usually larger than the framebuffer for the screen's real resolution
<vladkorotnev> hello everyone :D
<vladkorotnev> I know it's a noob question, but how do I insert a microSD card into the ben nanonote?
<wpwrak> vladkorotnev: so it arrived ? congratulations !
<wpwrak> vladkorotnev: you insert the card with the contacts facing upward
<vladkorotnev> wpwrak: thanks!
<vladkorotnev> wpwrak: it tries to get back out :P
<wpwrak> push it in a little more. then it should lock (you can still pry it out, but it resists a little)
<vladkorotnev> oh thanks, I got it
<vladkorotnev> but where's its mount point?
<wpwrak> puuh. not sure if there's any kind of automount. maybe you have to mount manually.
<ron_> thinking about possible futre nanonote derivative, a question: changing toi a different LCD display module implies (??) a new lcm controller?  
<ron_> from something I read here months ago, apparently the lcd controller was especially tough to crack (open up code). is that correct
<wpwrak> ron_: you mean the chip on the lcd module ? yes, there's a number of such chips and you can never quite tell which one they use
<wpwrak> ron_: this happened before i got involved, byt lcd controllers are generally a mess, so i wouldn't be surprised if it was a pain
<wpwrak> s/byt/but/
<ron_> wpwrak my real question is it practical to go to a new and larger display with higher resolution
<ron_> i understrand that having more bits to move around is a challenge
<wpwrak> roh: well, i wouldn't change the form factor of the nanonote much. but a slightly wider display should be possible
<ron_> on the other hand 4760 will run about 2x faster
<ron_> on the other hand the main attraction of Ben is it is very open. on a spec basis, it is very weak compared to many other portable devices that can be used with Linux. e.g. Palm Pre run a nice linux.
<wpwrak> yeah, a new design would have a lot more memory bandwidth. maybe faster clock, sdr->ddr or even ddr2, a wider bus. you could drive a very large screen.
<wpwrak> it specs are weak, but the price is low :) i think that's an interesting niche.
<kyak> vladkorotnev: it arrived at the right time to give it a try to new testing image from xiangfu :)
<wpwrak> ron_: i would also hope that more opened design would be easier to adapt. e.g., you could make a laptop-sized variant with a moderate investment. still a few kbucks, but far less than what it would cost today.
<kristianpaul> valhalla: great it arrives indeed
<kristianpaul> oops
<kristianpaul> is gone..
<kristianpaul> sorry valhalla
<wpwrak> ron_: all we'd need to make this happen is a pot of gold. anyone stumbled upon one by chance ? :)
<wpwrak> kristianpaul: the curse of auto-completion :)
<kristianpaul> yeah.. :S
<Jay7> wpwrak. ron_: I'll prefer case and keyboard like HP Jornada ;)
<Jay7> interesting, is Pandora case schematics awailable?
<Jay7> I mean OpenPandora
<qwebirc145> hello how is the development going?
<valhalla> kristianpaul: np, the conversation looks interesting anyway :D
<valhalla> Jay7: no, the openpandora is not open as far as hardware is concerned
<Jay7> valhalla: I mean case
<valhalla> Jay7: yes, case included
<Jay7> bad OpenPandora, bad!
<valhalla> they are dead scared of clones appearing before they have managed to finish builiding the preorders
<Jay7> they are failed almost anything
<Jay7> but they was one of pioneers
<valhalla> exactly, when they started they were sort of "open enough for now"
<wpwrak> we have to keep raising the bar :) there's still a lot to do.
<valhalla> well, the nanonote is also "open enough for now", since the SoC is still proprietary, only the "now" of the nanonote is later than  the "now" of pandora
<wpwrak> the nanonote also lacks open schematics that were used for production (the "real" schematics are in a proprietary format), an open layout, and an open case designs.
<wpwrak> schematics and layout should be easy enough to "do right" in a future device. the case is harder.
<Jay7> case design is very special thing..
<wpwrak> wolfspraul: btw, someone asked for the ben layout a few days ago. have you ever released the gerbers ?
<wpwrak> Jay7: it's different from electronics. but hey, it should certainly be doable for a few lads with sharp wits and some CNC system (mill, printer, whatever) :-)
<wolfspraul> wpwrak: the avt2 gerbers are published in both kicad and pads, I believe.
<wolfspraul> the other gerbers are irretrievable due to the process back then with multiple companies involved
<wpwrak> (avt) cool. (others) :-(
<wolfspraul> but for all practical purposes the lb60 and avt2 gerbers are the same, it's only a technical problem
<wolfspraul> The ben gerbers are released as avt2, in both pads and kicad format.
<wolfspraul> that's the bottom line
<wolfspraul> the pads version is even production tested (the kicad version is not)
<wolfspraul> the naming of lb60 and avt2 was unfortunate
<wolfspraul> naming pcb revisions in open projects is a pain
<wpwrak> hmm, where are they ? http://downloads.qi-hardware.com/hardware/qi_avt2/RC2/ only has schematics (as PDF)
<wpwrak> ah, v1.0 ! :)
<wpwrak> design files for orcad and pads: http://downloads.qi-hardware.com/hardware/qi_avt2/v1.0/
<wolfspraul> yes
<wpwrak> wolfspraul: (naming pcb revisions) hmm, what do you mean ?
<wolfspraul> the kicad run never made it though, so the kicad files are untested
<wolfspraul> those random numbers lb60 and avt2 are a bad idea
<wolfspraul> it just doesn't work
<wpwrak> ah. well, they look "professional" :)
<wolfspraul> the best is to only have one file format (say kicad), to start in that file format from day 1, always stay in that file format
<wolfspraul> any derivatives or generated files should be generated in a clean and reproducible process, from a known revision of the original open kicad files
<wolfspraul> and all boards should be named after the product they are being part of, and then just a date code, or revision number
<wolfspraul> that's the theory
<wpwrak> hmm yes, including the git revision would be an interesting idea
<wolfspraul> in practice it's sometimes not like that :-)
<wpwrak> well, ben-wpan is pretty close. i still maintain my version number (basically a date code) manually, but besides that, everything originates from the kicad design files
<wpwrak> (plus some auxiliary material for BOM, CNC, etc. but that's kinda unavoidable)
<DocScrutinizer> PADS \o/ :-S
<Jay7> is looking at google analytics for kexecboot.org site
<Jay7> wpwrak: seems you made lot of traffic ;)
<Jay7> I see interesting sources like acessa.me, google.com.pe
<Jay7> location chart is interesting too.. Brazil, Pery, Colombia, Mexico, Argentina
<Jay7> s/Pery/Peru/
<wpwrak> Jay7: (traffic) hm no, i just mentioned it on a forum in germany. don't think it spread far from there
<wpwrak> Jay7: maybe someone else discovered it independently ;-)
<Jay7> well, may be :)
<Jay7> btw, now USA visitors count is greater than Russia visitors count :)
<Jay7> good sign
<Jay7> USA is at 1st place now :)
<wpwrak> whee ! :)
<wpwrak> if you translate the page to chinese, maybe even more people will come ;-)
<Jay7> I don't speak chinese :(
<Jay7> btw, some people from South Korea was here too
<Jay7> and Japan
<wpwrak> now you've earned global fame :)
<Jay7> and India
<Jay7> hehe
<Jay7> well.. I should commit something then :)
<kristianpaul> btw what happend with kexecboot and nanonote?
<Jay7> almost nothing :)
<kristianpaul> ah :-)
<Jay7> I have no time to find and fix kexec problem on NN
<Jay7> and kexecboot is unusable w/o working kexec at this moment
<Jay7> so work is kinda stalled
<kristianpaul> i hope your followers are not here
<Jay7> I'll add support for switch_root and switch_root + losetup soon :)
<Jay7> then kexecboot may be usable even w/o kexec :)
<kristianpaul> may be i'm blind, but any body case a link to source code here http://gnss-sdr.ru/index.php?blogid=2 ?
<kristianpaul> s/case/can see
<Jay7> hehe.. glonass..
<kristianpaul> Jay7: over your sky ;)
<Jay7> scilab source code
<kristianpaul> rar..
<Jay7> yeah.. windows users very like it here
<Jay7> but migrating to 7zip slowly
<Jay7> kicad sources
<kristianpaul> phew how do i missed..
<Jay7> kristianpaul: just click on every header and check articles
<Jay7> there are some more links inside
<kristianpaul> dammit i tought was a single page..
<kristianpaul> feel about it
<kristianpaul> thanks Jay7  :-)
<Jay7> kristianpaul: np :)
<kristianpaul> great there is code for the cpld.. :D
<Jay7> kristianpaul: btw, have you tried gpredict?
<kristianpaul> Jay7: of course i used once a week, at least to try just "see" some sats for now :-)
<Jay7> kristianpaul: is it working? I mean that OE port
<kristianpaul> ahh OE, not tried
<kristianpaul> that go after werner ubb-vga..
<Jay7> still have lingot unpushed..
<kristianpaul> urgh, the're using the cypress chip..
<kristianpaul> or usrp legacy ;)
<methril_work> nice GPS site
<methril_work> "GPS"
<kristianpaul> GNSS!
<methril_work> ok kristianpaul, sorry for the mistake ;)
<grunthus> hi, looking for some help with software USB-boot, for new Ben
<grunthus> ah, no, looks like I got 601a:4740 from lsusb now
<grunthus> ls /dev/bus/usb
<kristianpaul> methril_work: nha, just kidding, actuatully the blog is focus on glonass it seems, thats is gnss too
<grunthus> Hmmm. OK, reflash_ben.sh reported success, however the Ben will still not switch on for normal use? Any ideas anyone?
<grunthus> Erm, disregard. I got it via the reset switch!!
<kristianpaul> :-)
<DocScrutinizer> roh: do you have a needlebed tester? (maybe a special tool for your CNC mill)
<DocScrutinizer> ponders to revamp an old 24pin impact printer, then feed the results to kicad to RE the schematics
<DocScrutinizer> of the DUT
<DocScrutinizer> HAH, (C): use a electroluminescent transparent layer of twice the PCB length and width, with the needle with RF in the center
<DocScrutinizer> use a second EL layer for PCB backside
<DocScrutinizer> 2 cameras
<DocScrutinizer> where's the next patent lawyer?!
<DocScrutinizer> NB I'm talking about blank PCB, not PCBA