<xiangfu> eharrington: let me test again in my nanonote.
<eharrington> Just ssh'd  in to check files again. I had to mount mmcblk0p1 /sd - then ls -l on /sd/boot shows uImage is there.
<xiangfu> eharrington: I got a "ext2fs_devread()" error in another 8GB sdcard. I will try to format the sdcard to 2 partitions and try again.
<xiangfu> eharrington: maybe something wrong with the mmc driver. you can try some sd card < 8GB, I will work on this recently.
<eharrington> OK, thank-you. I do recall reading somewhere that there might be a > 4gb, not sure if it is related, sorry don't remember where I saw it. I will try some things also.
<pitanga> Hello folks! In http://en.qi-hardware.com/wiki/Updating_Ben_NanoNote_software#Alternative_to_using_the_reflash_ben.sh_script -> Notes it is stated "Usbboot is not very robust. Neither on the side of the code that is running on the NanoNote, nor how it implements the USB protocol, nor on how it handles NAND. It's much better to let the Linux kernel do this. Unless there is a real new feature in u-boot, leave u-boot unchanged on your NanoNote now".
<kyak> pitanga: so?
<eharrington> I find it stable, albeit slow, just scp'd 135 mb to nano via usb, took 8 min's.
<eharrington> or is that my sd card that is slow? hmmm, will have to experiment
<kyak> usbboot as far as i know is using other driver than usb gadget
<eharrington> Tried re-partition 8 gb sd to only 1 3 gb part, still not able to boot debian at /boot/uImage. Will find some 2 or 4 gb sd's tomorrow to test.
<eharrington> Anyone used: downloads.qi-hardware.com/people/xiangfu/tmp/openwrt-xburst-qi_lb60-u-boot.bin with smaller sd?
<eharrington> pitanga: Are you having errors with:  "nprog 2048 openwrt-xburst-qi_lb60-root.ubi 0 0 -n" ? If so, you should try "nprog 2048 openwrt-xburst-qi_lb60-root.ubi 0 0  -n"  (extra space between last 0 & -n)
<pitanga> eharrington: do I need to "nerase" before "nprog"?
<eharrington> I did that step the first attempt, but skipped it on later tries (because all steps other than #11 appeared to work fine)
<xiangfu> pitanga: yes. to refresh rootfs. we need "nerase"
<pitanga> xiangfu: what if I don't want to erase u-boot, as recommended on the note I mentioned above? Or should I just forget about that note and reflash everything?
<xiangfu> pitanga: [nerase 16 512 0 0] this command will only erase the rootfs partition
<pitanga> xiangfu: thanks!
<xiangfu> pitanga: for more info about usbboot you can search in en.qi-hardware.com :-)
<pitanga> xiangfu: thks!
<nllpntr> i have a minor problem with the nanonote i just received, if anyone cares to pipe up...
<nllpntr> tried to flash debian, something failed, although without any errors, and it won't boot at all.
<jluis> nllpntr: Have you tried to press alt+f2? did yow see any message when powering up?
<nllpntr> no message on power up, nothing at all. i assume alt+f2 would be after power up?
<jluis> debian don't present info on tty1 so you have to change to tty2 to loggin but the flasshing process sometimes fail without error
<nllpntr> ah
<nllpntr> so assuming flashing failed, how might I resurrect this thing?
<nllpntr> oh, followed instructions from here: http://pyneo.org/howto/debian/nano.html
<jluis> to make you use the carbonized ruber ;P
<nllpntr> I have a feeling I missed some major detail and should not have used said instructions...
<jluis> the instructions worked for me but  just to be sure connect your neo to usb anb see if it is recognized as a ethernet
<nllpntr> nope
<nllpntr> it's behaving as a brick.
<freespace> if you short the usb boot pin, and then plug it in, does a new usb device show up?
<nllpntr> no, can't usb boot
<freespace> that doesn't sound good
<nllpntr> whoah, wait a tic. it just booted.
<nllpntr> well, connected via usb
<nllpntr> magic!
<freespace> i am that fear some :P
<nllpntr> heh
<jluis> or low battery
<freespace> you would need to take the battry out for short the usb boot pads
<nllpntr> should I reinsert the batter while it flashes?
<nllpntr> does that matter?
<nllpntr> perhaps it died last time during the flash? doesn't seem likely with usb power...
<freespace> when i reflash
<freespace> i only short it until the flash script finds it
<freespace> then i leave it alone
<freespace> w/o battery until it finishes
<freespace> then i unplug
<freespace> put battery in
<freespace> and it boots
<freespace> i noticed some strange behaviour if i put the battery in while still plugged in
<nllpntr> well, that's no different from my first attempt. it's still flashing now, we shall see
<jluis> ben recives suficient power from usb, is not needed to reinsert the battery
<nllpntr> thought so
<freespace> nod, the important thing is it isn't bricked :D
<nllpntr> indeed
<nllpntr> I guess i'm just finding it difficult to short those pins reliably
<nllpntr> don't have proper tools using <ahem> steel wool
<nllpntr> heh
<freespace> did you get the little rubber dome thingy?
<nllpntr> no, is that supposed to be included?
<freespace> oh i got one
<freespace> check carefully
<nllpntr> hey, the wiki does say "_WHATEVER TECHNIQUE YOU CAN COME UP WITH_"
<freespace> i almost threw it out
<freespace> mine came in a small palstic bag
<freespace> it is wha you find if you take a kb apart
<freespace> the carbonised rubber in it is what i use
<freespace> i position it over the switch, then press down
<freespace> it should be with in the instructions
<freespace> and the screen cleaning cloth
<nllpntr> odd. I was careful. didn't see a smaller bag.
<freespace> ok, maybe it is a new thing
<freespace> i ordered last week
<nllpntr> I'll figure something out
<freespace> nod
<freespace> lick it
<freespace> :P
<nllpntr> hah
<nllpntr> almost did try that actually
<freespace> haha
<nllpntr> ok, flash is done. I unplugged, inserted the battery... waiting for something to happen
<freespace> which firmware?
<nllpntr> hmm. embarassingly, I don't know...
<freespace> flash the latest offical from qi
<freespace> and once you know that works, go from there?
<nllpntr> got a quick link? I'm finding their pages a bit spaghettified
<freespace> those were the instructions
<freespace> and then just use reflash_ben.sh
<freespace> it will automagic download
<freespace> the latest images
<nllpntr> ah right
<freespace> so just download the .deb or whathave you
<freespace> then reflash_ben
<freespace> that page should be restrucutred
<freespace> once i can pass the captcha i will edit it
<nllpntr> sweet. working. perhaps I will do some more homework before operating on this thing.
<freespace> nod
<freespace> it is quite addictive
<nllpntr> seriously. this is all i've been playing with since I got home from work.
<nllpntr> yay! all is right with the world
<nllpntr> thanks for all the help folks
<nllpntr> I need to sleep before I get assimilated
<rafa> larsc: or any one knows if there is a git for the current kernel in the official openwrt distro QI uses?
<rafa> (2.6.32)
<rafa> xiangfu: you know perhaps right?
<rafa> xiangfu: I mean, without to use the whole openwrt building process.
<xiangfu> rafa: no. the current git not sync with openwrt. so it's old
<rafa> xiangfu: but I would like to build just the 2.6.32 kernel, should I use the  git://projects.qi-hardware.com/openwrt-xburst.git ?
<rafa> I only want to work a bit with kernel, no with the whole openwrt. Perhaps I do not understand well that git, but it looks like it manages the whole official distro
<xiangfu> rafa: yes. the openwrt-xburst.git manages the whole official distro.
<xiangfu> rafa: and there is another kernel.git in projects.qi-hardware.com
<mth> do you need 2.6.32 specifically? otherwise you could compile the 2.6.34 kernel from the qi-kernel git
<xiangfu> rafa: which only have kernel source code.
<rafa> mth: yes, we use 2.6.34 kernel in jlime. But we need 2.6.32 to test zimage initramfs and kexec.
<rafa> xiangfu: the kernel.git in projects.qi-hardware.com is just for 2.6.34 it seems. Well, thanks anyway, I will try to take 2.6.32 from openwrt-xburst.git ;)
<xiangfu> rafa: the master bransh is 2.6.32. but it's old. I will try to update it now
<xiangfu> rafa: I want make a automatic sync with openwrt-xburst.git but always have problem with patch the openwrt-xburst.git's kernel patches.
<rafa> xiangfu: I can imagine.. a sync between two tools-repositories should be hard to keep :(
<xiangfu> Hi rafa,  here the network is not good. so I will go home then upload the 2.6.32.10 kernel to qi-kernel.git. will be three hours later.
<rafa> xiangfu: thanks a lot !!!! I will be too happy if you can do that .. Again thanks
<mth> larsc, zear: in the gmenu2x git, there is the autotools build but also src/Makefile-zear
<mth> it would be easier to maintain only one build system
<mth> I'm not a fan of autotools, so I actually wouldn't mind building with a hand-coded Makefile, but I don't know how the other maintainers feel about that
<zear> mth, Makefile-zear is what you guys renamed the Makefile when you adopted my nanonote port to owrt
<zear> oh right, you weren't maintaining it, well, it's what them guys did ;)
<mth> I only got commit rigths yesterday
<zear> yeah, my bad ;)
<zear> mth, for some reason i confuse you with qi-guys when you talk in this channel :D
<mth> :)
<mth> another question is how to do support for different devices
<zear> mth, well, once it's adopted to owrt i don't touch it, because owrt is black magic for me :D
<larsc> virtual Device class and an implementation for each device
<larsc> with setBacklight, getPower and such ops
<mth> sounds good
<zear> that's a good idea
<mth> select device at compile time or run time? (since you said 'virtual')
<zear> also, it needs setKeymapping
<zear> because i hate how we use virtual GP2X buttons now
<larsc> both would be poissble
<mth> I think compile time would be better, to keep the footprint low in case more devices are added later
<mth> also it would allow a particular device implementation to use libraries that are not present on other devices
<mth> zear: it's not only in the openwrt build, but also in the gmenu2x git tree
<mth> I'm building it from git for the Dingoo
<zear> mth, if you want to build it for the dingoo, you need to revert the root path and battery status device back to dingux settings
<mth> switching from sparsehash 1.7 installed in the toolchain to sparsehash 1.6 in the gmenu2x source tree fixed a crash, although I have no idea why
<mth> zear: that's why I was asking how to handle different devices :)
<zear> so download joyrider port's code and compare it with the one from the git
<mth> battery path is the same between NN and OpenDingux, but backlight probably not
<zear> mth, well, this git build is based on a very very dirty hack of mine
<larsc> well, backlight is /sys/class/backlight/*/
<mth> ok, so you won't be offended if I remove it then and add the needed flags to the autotools build?
<mth> larsc: but "*" is not the same, right?
<larsc> correct
<larsc> mth: as a starting point http://metafoo.de/gmenu2x-device.patch
<mth> thanks, I'll use that
<rafa> mth: do you maintain the gmenu2x git code?
<mth> well, I can commit to it, but I don't want to be the sole maintainer
<rafa> so who is the main maintainer? or it is just who has commit rights will do whatever he wants?
<mth> I don't know if there is a maintainer
<mth> if I am in doubt, I check with larsc
<mth> (whether or not to commit something)
<rafa> mth:  cool
<rafa> zear: we know now where to send our gmenu2x complains :D
<zear> rafa, i made it clear a couple of times that the flickering of the nn's screen is my fault because i left the jz4740 overclocking code in gmenu2x and it messes with LCD timings ;)
<mth> I don't like GUI programming, I prefer looking at the system parts and the build
<mth> the overclocking code should be moved out of the menu and into the kernel
<mth> well, the menu should ask the kernel for a certain frequency and the kernel should set that freq
<rafa> mth: is not the menu a sdl application? why it should ask something to the kernel?
<rafa> zear: is it your fault that gmenu2x has that problem? coool! :) at least you will be famous between openwrt nn users
<rafa> :D
<zear> rafa, :D
<zear> more like infamous :D
<rafa> a virus1
<rafa> !
<mth> rafa: because that's better than mmap-ing /dev/mem and accessing the SoC registers directly
<zear> ;P
<rafa> mth: well, for sdl I would say that the application just should do the proper sdl calls, and IIRC sdl does not have nothing to do with kernel if you use just the sdl API. But things could change from time to time
<rafa> some day Vi will ask openoffice to ask kernel to let Vi to use the keyboard :P
<kristoffer> *shudder*
<kristoffer> dont say that
<kristoffer> I would be lost without vim and mutt
<mth> rafa: there is no SDL API for changing the CPU freq
<rafa> kristoffer: haha.. me too
<rafa> mth: that is why gmenu2x should not ask kernel nothing
<mth> huh?
<mth> you want to remove the feature then?
<rafa> mth: of course, if that application is a GUI application written using sdl I do not understand how it would like to do kernel questions. But I am not so interested in gmenu2x anyway. If we use gmenu2x someday then it should be just a GUI app I think.
<rafa> zear: it is your fault I know
<zear> ;D
<rafa> ;)
<mth> things like battery status also communicate with the kernel, through the /sys pseudo filesystem
<rafa> surely because there is not a multi platform middle ware to use
<rafa> or just a simple lib
<mth> we want to introduce a Device class in gmenu2x, which has one implementation per device
<mth> so not a separate lib, but a separate unit within gmenu2x
<rafa> mth: anyway, cool if you are worning on gmenu2x. I will be happy if it improves ;)
<rafa> working*
<calamarz> rafa: is there a way to enable acpi support in the kernel? (sorry if newbie question)
<mth> isn't ACPI x86 specific?
<calamarz> oh, I had no idea of that :/
<mth> I'm not sure, it's an actual question, not a rhetoric one :)
<rafa> calamarz: no idea, I have set Power Management support in 2.6.34. If something under that works either it is APM or ACPI. I would think that APM could be possible, but no sure.
<rafa> calamarz: larsc could know
<rafa> or krisstofer, who is not here :P
<calamarz> mmm looking at the debian package for acpi-modules, I only see it for x86 and amd64, if that means something
<rafa> calamarz: do you acpid (daemon)
<rafa> ?
<rafa> do you see*
<calamarz> mmm yes, acpid is for mipsel too
<qi-commits> Xiangfu Liu: add-config-file. SYNC AT: Fri Jun 18 21:01:10 CST 2010 http://qi-hw.com/p/qi-kernel/df6af7e
<qi-commits> Lars-Peter Clausen: From 9a4567a733b689d5dc803cd27dfaa01bc03dc374 Mon Sep 17 00:00:00 2001 http://qi-hw.com/p/qi-kernel/05256e0
<qi-commits> Lars-Peter Clausen: From 806ead1e454a8a5876b777b22ca67187c4749f32 Mon Sep 17 00:00:00 2001 http://qi-hw.com/p/qi-kernel/80d9e42
<qi-commits> Xiangfu Liu: From 4939c63a61175f87d93ac0164c7adb40e8410a47 Mon Sep 17 00:00:00 2001 http://qi-hw.com/p/qi-kernel/7c47ff2
<qi-commits> Lars-Peter Clausen: From d76e6b85f28891eecded962793fb8a02cdf26f39 Mon Sep 17 00:00:00 2001 http://qi-hw.com/p/qi-kernel/6373d8b
<qi-commits> Lars-Peter Clausen: From 2d00c901d3a438c6f750f8b13b329845775ec3b5 Mon Sep 17 00:00:00 2001 http://qi-hw.com/p/qi-kernel/03e316d
<qi-commits> Lars-Peter Clausen: From df07ed6a52d9f6027ff1753c00b3128fa18dde31 Mon Sep 17 00:00:00 2001 http://qi-hw.com/p/qi-kernel/8110220
<qi-commits> Lars-Peter Clausen: From d3699249d687dc0b4d8d4e0e5ac3f9405d31b1ac Mon Sep 17 00:00:00 2001 http://qi-hw.com/p/qi-kernel/3cbbb13
<qi-commits> Lars-Peter Clausen: From f6bc2
<calamarz> nice date on the qi-commits :p
<nebajob> supppppp
<rafa> wejp: hey man, could you tell me a link for the gmu source code?
<eharrington_> greetings, anyone know what default un & pw are for debian in sd card image (it's working!!!) Success with 2 gb sd card with exact same procedur/files which failed on 8 gb card & 8gb with 3 gb part. Progress.
<eharrington_> xiangfu: got it booted on 2 gb card, unable to login yet
<eharrington_> am stuck at (none) login: prompt, doesn't like my openwrt un/pw
<eharrington_> so, dual booting is now running
<eharrington_> never mind, editted passwd from openwrt, I'm in!
<calamarz> rafa: http://wejp.k.vu/wp-content/uploads/2010/03/gmu-0.7.0.tar.gz ? or you were asking for a git or st?
<wejp> i have no idea what he is asking about, i mean the source is on my website of course
<calamarz> eharrington_: that's good news, yeah
<rafa> calamarz: thanks
<rafa> wejp: I did not know that you had a web site.. then, google gave me it, so I was guessing that wejp.k.vu would be the proper site to look.
<wejp> oh ok
<rafa> wejp: perhaps the website is very famous, just that it is the first time that I visit it :)
<wejp> i thought this would be well known as the site is even mentioned in gmu itself ;)
<rafa> wejp: I have not used gmu yet ;)
<wejp> ok, i see :)
<calamarz> wejp: i'm trying to finish the debian package this weekend... cannot tell about its quality, it'll be my first debian package :p
<wejp> nice :)
<wejp> oh, btw, there will be a new gmu release in the near future, only few things left to do :)
<zear> :3
<tuxbrain> rafa: I want gmu in Jlime :P
<rafa> tuxbrain: yeah, we will have it soon, zear already convinced us  ;)
<kyak> ok, i really think to have to write to mailing list about this, but..
<kyak> i'm doing some tests with SDIO WiFi card, and it's not working very well
<kyak> now i've lowered the configuration to a simple ad-hoc between my laptop and Ben
<kyak> and there is a 50 % packet loss
<kyak> not 49 and not 51
<kyak> can be seen so clear with ping
<kyak> and a weird messages about sparse IRQs and sdop interrupts in dmesg
<kyak> sdio
<kyak> so i just posted
<tuxbrain> kiak, you think is the card or the sdio of BNN?
<kyak> i suppose it's the ks7010 driver
<kyak> but i can't be sure
<kyak> but the only reason why i think so is because the message coming from ks7010 driver
<kyak> i thought at first it might be a conflict with mmc card driver, so i tryed to disable it in various ways
<kyak> but ks7010 seems to rely on some functions of mcc
<kyak> driver, so it doesn't work at all without mmc driver
<kyak> tuxbrain: when you have some free time, would you mind to test it with the latest software?
<kyak> ad-hoc or OPEN configuration.. to see if this problem is existing for you
<kyak> i'm praying for it not to be a hardware issue
<kyak> because i must admit that the Wi-Fi card is not fitting so well as regular sd memory card
<kyak> fitting in the slot i mean
<kyak> it's not ejected
<kyak> ot not always ejected
<kyak> *or
<tuxbrain> cross your fingers to I found the sd... I have not see it arround for long time, I will do some archoelogical research later on this weekend
<kyak> lol, ok :)
<kyak> it's easy to loose, yes
<kyak> that's why i try to keep it in a case
<calamarz> tuxbrain: did you get any progress with the keymouse configs?
<tuxbrain> sorry calamarz, too many fronts, I still having to recompile the kernel due input-core has to be a module as well,... and the worst of all,  the gps module arrives, the elphel cam is working like a charm, so body is calling for some hot tin, wires , video tutorial and true metal. so I think keymouse will wait until I get a gps fix :P , pics on the preliminars http://www.tuxbrain.org/downloads/nanonote/gps/
<kyak> i see this problem hasn't been solved since then
<calamarz> yeah that gps looks promising ! :)
<Textmode> morning all
<tuxbrain> oh is a pitty I can't stream outside on line the video  on nanonote with the elphel at 1920x1088 at 25fps  is streaming to my PC,  , once I install the new image on BNN I will do a quick tour with this...., man I can see my every line of my fingerprints, I'm still amazed by the definition on the close ups.
<tuxbrain> well let's stop playing with the toys and let rest until moring, good night Textmode :)
<Textmode> rest well, tuxxy
<mth> larsc: which branch is this commit attached to? jz4740: fb: Small cleanups http://qi-hw.com/p/qi-kernel/f6cda2a
<mth> ah never mind
<mth> I was confused because the commit is 17 days old, but was not pushed until yesterday
<larsc> yeah, i forgot to push some cleanups
<larsc> preparing v2 of the jz4740 patches right now, which will probably go into ralfs queue
<mth> -   mmc_suspend_host(host->mmc, PMSG_SUSPEND);
<mth> + mmc_suspend_host(host->mmc, 0);
<mth> this change breaks compilation in my tree
<mth> Ralf being the MIPS maintainer?
<larsc> yes
<larsc> how can that break compilation?
<mth> drivers/mmc/host/jz4740_mmc.c:946: error: incompatible type for argument 2 of 'mmc_suspend_host'
<larsc> hm, k
<mth> pm_message_t is a struct, so 0 seems to be invalid indeed
<larsc> hm
<larsc> i think it happend because the second parameter is gone in .35 and i backported a change from there
<larsc> will fix it later
<mth> with that change reverted, it compiles fine and boots on the A320
<larsc> good
<urandom_> someone already flashed the latest openwrt image?
<qi-commits> Maarten ter Huurne: Fixed most warnings. http://qi-hw.com/p/gmenu2x/9f05aaf
<qi-commits> Maarten ter Huurne: Remove manually created Makefile, since the autotools build is now usable. http://qi-hw.com/p/gmenu2x/d8dd090
<qi-commits> Maarten ter Huurne: Enabled code specific for embedded devices and enable more warnings. http://qi-hw.com/p/gmenu2x/29b8277
<qi-commits> Xiangfu Liu: add jz4760 support to stage2, make it can reflash jz4760 device http://qi-hw.com/p/xburst-tools/4cdac88
<qi-commits> Xiangfu Liu: add jz4760 support to xburst_stage1 http://qi-hw.com/p/xburst-tools/bcc23ae
<qi-commits> Xiangfu Liu: make the usbboot detect the target cpu type by usb id http://qi-hw.com/p/xburst-tools/046a7e7
<qi-commits> Xiangfu Liu: cleanup head files http://qi-hw.com/p/xburst-tools/d0db327
<qi-commits> Xiangfu Liu: add jz4760 support to stage2 http://qi-hw.com/p/xburst-tools/7a5a090
<qi-commits> Maarten ter Huurne: Fixed order of includes in "cpu.cpp". http://qi-hw.com/p/gmenu2x/7a5d099
<qi-commits> Maarten ter Huurne: Removed ListView and ListViewItem class, since they were not used anywhere. http://qi-hw.com/p/gmenu2x/1d6ad03
<emeb> hey - 6-15-2010 image. That's new.
<qi-commits> Maarten ter Huurne: Do not run the main loop inside the GMenu2X constructor, but in a method. http://qi-hw.com/p/gmenu2x/3efa602
<Textmode> ew...was it really doing that?
<mth> yep
<mth> sometimes I'm amazed it runs at all
<urandom_> ahh no! i bricked my ben once again :(
<urandom_> so nobody tryed the latest image yet? just want to know if it works at all
<qi-commits> Maarten ter Huurne: Cleaned up BrowseDialog class: removed unused methods and fields, restricted access where possible. http://qi-hw.com/p/gmenu2x/ad22a90
<urandom_> yeah!!! sucess!
<qi-commits> Maarten ter Huurne: Removed SDL_ttf and FreeType from the libraries to link with, since there is no code that uses these libs. http://qi-hw.com/p/gmenu2x/6ec6155
<qi-commits> Maarten ter Huurne: Add explicit destructor to BrowseDialog. http://qi-hw.com/p/gmenu2x/9c5799c
<qi-commits> Maarten ter Huurne: In "utilities.h", only include those headers that are needed by the definitions in "utilities.h". http://qi-hw.com/p/gmenu2x/660b4f0
<qi-commits> Maarten ter Huurne: Fixed intendation. http://qi-hw.com/p/gmenu2x/c52b239
<qi-commits> Maarten ter Huurne: Removed SelectorDetector class, since it is not used. http://qi-hw.com/p/gmenu2x/5db8ac8