2011-06-23 00:50 stefan_schmidt: it's a mystery ;) 2011-06-23 00:51 wpwrak: heh 2011-06-23 00:52 wpwrak: I bet its some function that contains random() and hours modulo 2011-06-23 00:52 wpwrak: anyway, hacking on the atusb driver now 2011-06-23 00:52 added correct printout for 231 (id 3) and ignoring interface 1 so far 2011-06-23 00:53 without ignoring the interface or driver gets probed two times. One for each interface. And if I get it correctly 1 is only for DFU? 2011-06-23 00:53 at least ignoring it does no harm as I can still talk to the chip 2011-06-23 00:54 stefan_schmidt: heh, cool. how do you structure it ? 2011-06-23 00:54 wpwrak: well, strcuture...., well the branch is called atusb-bastard :) 2011-06-23 00:54 ;-)) 2011-06-23 00:54 but maybe I should not do it to dirty 2011-06-23 00:55 is it an spi host, a fork of at86rf230.c, ... ? 2011-06-23 00:55 I wonder how much my work will clash with the work from Richard 2011-06-23 00:55 wpwrak: I was thinking about getting all usefull logic/function from at86rf230.c and gluing usb logic to it 2011-06-23 00:56 yeah, if you get anything to work, you should sync with him 2011-06-23 00:56 but on the other hand I want to use it long term 2011-06-23 00:56 he is in charge for the usb part and you for the transport split? 2011-06-23 00:57 well, i changed my plan a little: no big transport split but just make it an SPI host 2011-06-23 00:57 hmm 2011-06-23 00:57 a very specialized one ;-) 2011-06-23 00:57 wpwrak: --verbose? 2011-06-23 00:57 it can figure out what to do by looking at the structure of the requests 2011-06-23 00:58 did yuo see that i added three new requests, ATUSB_SPI_WRITE, ATUSB_SPI_READ1, and ATUSB_SPI_READ1 ? 2011-06-23 00:58 wpwrak: ive seen your commits but could not make out much of it 2011-06-23 00:58 they map to register read/write, frame buffer read/write, and - in case we use it - SRAM read/write 2011-06-23 00:59 it seemed the interrupt work is done 2011-06-23 00:59 ok, mapping calls sounds easy 2011-06-23 00:59 the interrupt work is a bit trouble 2011-06-23 00:59 so we just have some functions abstracting real spi and usb-spi? 2011-06-23 00:59 i haven't figured out how to efficiently synchronize control transfers and interrupts 2011-06-23 01:00 atusb could just be an SPI driver that knows a few magic tricks 2011-06-23 01:00 if you send it requests it doesn't understand, it would just complain 2011-06-23 01:01 hmm 2011-06-23 01:01 thinks about it 2011-06-23 01:01 what worries me is the interrupt synchronization 2011-06-23 01:01 it shuffles the work away from the transport split to writing a spi driver 2011-06-23 01:02 how are interrupts handled over USB anyway in the kernel? 2011-06-23 01:02 if the interrupt synchronization can't be hidden cleanly and reasonably efficiently in the SPI driver layer, the whole SPI host idea may not fly after all 2011-06-23 01:03 i think you just enqueue an URB and get it when it has been served. but i don't think there are sequence guaranteed 2011-06-23 01:03 s/guaranteed/guarantees/ 2011-06-23 01:04 but .. i'm not an expert of the USB subsystem 2011-06-23 01:04 I haven't seen much that we could use for int from the spi framework 2011-06-23 01:05 there may also be a problem with the firmware using edge-triggered interrupts. not sure if the avt re-arms them when entering or when leaving the ISR. in the latter case, we may lose interrupts. but that can be fixed. 2011-06-23 01:05 (int) you have to create a "fake" interrupt, then pass its number to at86rf230.c 2011-06-23 01:06 wpwrak: but the drivers gets the interrupt from the platform data and not from spi?! 2011-06-23 01:07 the spi driver picks it up from the platform data and then passes it on. so you can fake all that :) 2011-06-23 01:07 what I like about the transport split is that it is straight forward to implement (int aside) 2011-06-23 01:08 what I like about the spi way is that it abstracts it nicely and we don't have to touch the main driver 2011-06-23 01:08 (spi) ah, thats possible to hook in there then 2011-06-23 01:09 yeah, and we want the spi split for atben, too. spi_gpio must be pretty slow. 2011-06-23 01:09 also, the transport split is easy at the top (the transfer functions) but gets messy at the bottom (driver registration, removal, etc.) 2011-06-23 01:10 I actually would expect some more bottlenecks on the way from the chip to the flash :) 2011-06-23 01:10 wpwrak: so how would we best work together on this? (Also including Richard of course) 2011-06-23 01:11 (chip to flash) flash ? 2011-06-23 01:12 you should let richard know that you're hacking on it, so that he can sync with you when he has time (or if he's done anything already, update you) 2011-06-23 01:12 (bottleneck) I meant the whole system performance from getting data from atben to the actual nand flash for storage. Nor sure if spi_gpio is the bottleneck there 2011-06-23 01:13 regarding the overall architecture, i'm not quite sure yet what to do about the interrupt problem. several approaches come to mind. all of them suck in one way or another: 2011-06-23 01:13 letting him know as in sending patches to the ml? 2011-06-23 01:14 1) stop handling control transfers while there's a pending interrupt. that would require the user of atusb to have an asynchronous bulk/interrupt read pending all the time, or it'll hang. okay the kernel, messy for user space. 2011-06-23 01:15 (letting know) more polite to warn him before sending patches :) 2011-06-23 01:15 I will put the politeness in the cover letter :P I'm fine with the patches getting thrown away if he has somehting better already 2011-06-23 01:16 Just want to get started with it 2011-06-23 01:16 2) keep the current approach but make some means to explicitly sync after register accesses where we actually care about the interrupt situation. that would be the ones that need the interrupt/worker synchronization ritual. 2011-06-23 01:16 3) convert everything to use bulk transfers, so that all the data flows in the same stream. 2011-06-23 01:18 suckiness of 1): would either complicate user space or require a sync/async mode switch. also, not sure if blocking control transfers is such a nice idea. 2011-06-23 01:18 suckiness of 2): at86rf230.c needs to know about this 2011-06-23 01:18 I would avoid making user space more complicated. Its the kernel job to make it easy (INHO) 2011-06-23 01:19 suckiness of 3): parsing of messages in a stream is harder than just getting handed a nice message in the form of a control transfer. 2011-06-23 01:20 (user space) i mean the user space only tools. they don't use the kernel code. 2011-06-23 01:20 ah, the tools/ section 2011-06-23 01:20 yup 2011-06-23 01:21 not much of an opinion here. They all have benefits... 2011-06-23 01:24 right now i use a bulk EP, not an interrupt EP, but it seems they're very similar 2011-06-23 01:24 I have some more days working on this. So it would make sense to pput our effort together instead of me going off in one direction due to time pressure 2011-06-23 01:24 will be easier to change once i've split the firmware build into boot and app usb stack 2011-06-23 01:27 given that you know hardware, firmware and drivers the architecture decision should be in your hands 2011-06-23 01:27 I'm happy to help coding it though 2011-06-23 01:28 yeah. i need to read a bit more about usb. see if there are any useful hints about the interrupt model 2011-06-23 01:29 3:30 am here. I think I call it a day. 2011-06-23 01:29 Will send my small mini patches to the list and Richard to let him know what I'm doing 2011-06-23 01:29 the at86rf230/1 is a bit nasty when it comes to interrupt synchronization, due to the shared interrupt bit and the shared buffer, but it's still not *that* outlandish 2011-06-23 01:29 So he can decide what to do with it 2011-06-23 01:29 oh, its one frame buffer for both tx and rx? 2011-06-23 01:29 alright. i think for now, i don't have any clear recommendation about what to do. 2011-06-23 01:29 yup 2011-06-23 01:30 oh, the cc2420 has one for each direction 2011-06-23 01:30 must have saved a lot of precious gates :-( 2011-06-23 01:30 i know ... 2011-06-23 01:30 but no re-submit in hardware 2011-06-23 01:30 seems that someone at atmel really liked the old 3c501 2011-06-23 01:30 heh 2011-06-23 01:31 (recommendation) seems so :P 2011-06-23 01:31 I will be back here tomorrow to discuss this further. Or ml both fine with me. 2011-06-23 01:32 alright. meanwhile, i'll ponder the interrupt situation a bit more. 2011-06-23 01:33 great 2011-06-23 01:35 hmm. one aproach may be to not read the interrupt status and just send a zero byte instead of the status. that may get rid of some trouble. 2011-06-23 01:36 the interrupt may still be late/weird, but at least IRQ_STATUS would be correct 2011-06-23 01:44 wpwrak: mails are out. Hopefully polite enough. :) 2011-06-23 01:44 time to move my body into the bed 2011-06-23 01:44 night all 2011-06-23 02:12 A question... stupid question..Â Â Is the USB port on the NN fully functional? 2011-06-23 02:13 Nanonote USB is a device port, not host 2011-06-23 02:15 What does that mean? 2011-06-23 02:15 "Devices" as in like flash drives... or..? 2011-06-23 02:17 good analogy. Nanonote can NOT attach to e.g. USB drives, or a USB WiFi stick, ora USB Flash drive. it has the same type of connection as those other devices 2011-06-23 02:18 So, what could the USB port be used for? 2011-06-23 02:18 I don't claim to be an expert. 2011-06-23 02:19 it can be used with Linux Ethergadter s/w to provide a connection to a Linux PC, and thence to the internet 2011-06-23 02:20 Ok. I knew that.. but wasn't sure if it could actually do more. 2011-06-23 02:21 Thanks. 2011-06-23 02:22 oh, cool, deaddrops.com for the offline lovers :-) 2011-06-23 02:26 wpwrak: about sige, i think i was confuse because i forgot this chipÂ Â (SE4162) have complex output, not real ! as before ones and others IC's like the one from maxin 2011-06-23 03:01 he, i was doubing but namuru core implement tracking for I and Q already ;-) 2011-06-23 03:02 so.. from a sample at least i should implement two correlators 2011-06-23 07:35 what is that? http://en.qi-hardware.com/wiki/Buddhamachine 2011-06-23 07:43 http://www.fm3buddhamachine.com/ 2011-06-23 07:47 mh, yes 2011-06-23 08:13 (buddha) nice plastic. how do you make vertical walls with bumps ? 2011-06-23 08:23 ah, the bumbs are wheels. no bumps in the plastic then. 2011-06-23 08:28 pity that the battery cover isn't shown fully. i'm rather curious whether is has any parts that fold back on itself. that's a problem i'be been trying to solve for about a year or so - how to make a battery cover if all you have is a mill with 3 degrees of freedom (for making the part or a mold) 2011-06-23 09:35 hmm, cannot push after xiangfu's renaming of the branch 2011-06-23 09:35 git push origin master 2011-06-23 09:35 -> To prevent you from losing history, non-fast-forward updates were rejected 2011-06-23 09:35 git pull --rebase origin master 2011-06-23 09:35 -> Current branch trunk is up to date. 2011-06-23 09:36 any ideas? 2011-06-23 09:37 ouch, and xiangfu is MIA today... 2011-06-23 09:37 dvdk: we just rebased yesterday 2011-06-23 09:37 i could just try a 'git pull' but that's going to mess with the logs? 2011-06-23 09:38 how can i retrieve a diff for the stuff already committed? 2011-06-23 09:38 so you need to git reset --hard origin/master (save your commits first) 2011-06-23 09:38 sve cmomits how? 2011-06-23 09:38 save commits via git format-patch 2011-06-23 09:38 save uncommited via git stash 2011-06-23 09:38 shows empty 2011-06-23 09:38 do you have commits to save? 2011-06-23 09:38 i already committed, just didn't push 2011-06-23 09:38 yup 2011-06-23 09:39 just a diff against remote head.Â Â 2011-06-23 09:39 how? 2011-06-23 09:41 i just checked, git format-patch -n should work 2011-06-23 09:42 doesn't do anything 2011-06-23 09:42 git log --branches shows my commit 2011-06-23 09:42 now i just need to extract it 2011-06-23 09:43 how do you do it? (format-patch) 2011-06-23 09:43 format-patch -n 2011-06-23 09:43 huh? 2011-06-23 09:43 you should at leasst supply a range 2011-06-23 09:44 you mean two revs 2011-06-23 09:44 yes 2011-06-23 09:46 you could also use a log with -p 2011-06-23 09:46 and reapply your patches after reset 2011-06-23 09:47 git log -p --branches does the job 2011-06-23 09:47 great 2011-06-23 09:48 extremely large file (>50MB) going to cut out my changes 2011-06-23 09:50 something is wrong 2011-06-23 09:50 the patch should be small, only contain your changes 2011-06-23 09:51 git log -p --branches is a full log of not only my changes 2011-06-23 09:51 btw i still cannot push 2011-06-23 09:51 error: failed to push some refs to 'git@projects.qi-hardware.com:openwrt-xburst.git' 2011-06-23 09:51 do i need to run 'git pull' ? 2011-06-23 09:52 you need to: 1) save your changes, this way or another 2011-06-23 09:52 2) git reset --hard origin/master 2011-06-23 09:52 did both 2011-06-23 09:52 3) reaplply your changes 2011-06-23 09:52 did that too 2011-06-23 09:52 and don't forget to git fetch -a 2011-06-23 09:52 as a first step 2011-06-23 09:52 fetch as 1,2,3,4? 2011-06-23 09:53 fetch as 1) 2011-06-23 09:54 it's not going to work :)Â Â so again: 2011-06-23 09:54 git fetch -a 2011-06-23 09:54 git reset --hard origin/master 2011-06-23 09:54 patch -p1 < ./mypatch 2011-06-23 09:54 yea 2011-06-23 09:55 this shoudl work 2011-06-23 09:55 git commit toolchain/gcc/ 2011-06-23 09:55 -> ...Â Â 2 files changed, 14 insertions(+), 0 deletions(-) 2011-06-23 09:55 git push origin master 2011-06-23 09:55 -> rror: failed to push some refs to 'git@projects.qi-hardware.com:openwrt-xburst.git' 2011-06-23 09:56 hates git 2011-06-23 09:56 show the 'git status' after 'git reset --hard origin/master' 2011-06-23 09:56 git reset --hard origin/master 2011-06-23 09:56 HEAD is now at a2997e2 uboot-xburst: update to 2010.06 2011-06-23 09:57 git status 2011-06-23 09:57 # On branch trunk 2011-06-23 09:57 # Untracked files: 2011-06-23 09:57 [..] 2011-06-23 09:57 ha 2011-06-23 09:57 nothing added to commit but untracked files present (use "git add" to track) 2011-06-23 09:57 you are on trunk 2011-06-23 09:57 but how?Â Â that's not my fault 2011-06-23 09:57 git checkout master 2011-06-23 09:57 aha 2011-06-23 09:57 why are you on trunk? yo ushouldn't be 2011-06-23 09:57 hmm. 2011-06-23 09:57 if you followed xiangfu's isntructions 2011-06-23 09:57 something about the rename? whon knows 2011-06-23 09:58 or maybe i did a wrong pull? 2011-06-23 09:58 you should've checkouted to master and removed (pruned) the trunk 2011-06-23 09:58 i did all the stuff that xiangfu wrote in his mail yesterday 2011-06-23 09:58 [commit] David KÃ¼hling: toolchain/gcc: add option SJLJ_EXCEPTIONS to select gcc's exception handling http://qi-hw.com/p/openwrt-xburst/2c58e58 2011-06-23 09:59 maybe now it worked 2011-06-23 09:59 "git branch -D trunk" - if you've done that, why it shows "# On branch trunk" ? :) 2011-06-23 09:59 yeah, now it's all right 2011-06-23 09:59 but i'm sure that there wasn't a trunk branch earlier today 2011-06-23 09:59 :) 2011-06-23 10:00 i once typed in 'git push origin trunk' out of habit, but that won't create a branch, would it? 2011-06-23 10:00 hm.. dunno 2011-06-23 10:00 my command from yesterday was 2011-06-23 10:00 git fetch -a && git checkout -b temp && git branch -D master && git checkout -b master && git remote prune origin && git branch -D trunk 2011-06-23 10:00 maybe i should use ; instead of && next time :) 2011-06-23 10:00 (just to be sure) 2011-06-23 10:01 btw aseprite works with my toolchain fixes 2011-06-23 10:01 should i enable config_SJLJ_EXCEPTIONS in config.full_system? 2011-06-23 10:01 your changes look great 2011-06-23 10:01 we need to push it upstream ): 2011-06-23 10:01 yeah, the right fix would be to repair the default exception handling code 2011-06-23 10:01 sure, enable it 2011-06-23 10:01 but using SJLJ_EXCEPTIONS as workaround for now so we can build/test c++ code 2011-06-23 10:03 next time interacting with git i'll use use 'script' for proof (and understanding :) 2011-06-23 10:05 heh :) 2011-06-23 10:07 dvdk: would you create a ticket in openwrt? I think it's not so good when i created a ticket for cmake's "fix bogus values" 2011-06-23 10:07 on behalf of you :_ 2011-06-23 10:08 you mean for the cmake issue?Â Â yeah will do that later 2011-06-23 10:09 wpwrak: got my 5.5 hours sleep (damn postman) 2011-06-23 10:09 wpwrak: Will reply to Richards mails now. qi-hw git is fine with me. 2011-06-23 10:10 dvdk: this one here, is already upstream: https://dev.openwrt.org/ticket/9573 2011-06-23 10:11 so this is already fixed.Â Â what else should i open a ticket for?Â Â the c++ issue? 2011-06-23 10:12 yea, i meant the c++ issue 2011-06-23 10:12 ok, maybe add our info to the already existing ticket 2011-06-23 10:12 (see my mail) 2011-06-23 10:13 ah yeah, that's a good point 2011-06-23 10:30 [commit] David KÃ¼hling: config.full_system: enable SJLJ_EXCEPTIONS to workaround toolchain bugs http://qi-hw.com/p/openwrt-packages/b8736d6 2011-06-23 11:58 kyak, dvdk: I added gfortran and the sjlj option 2011-06-23 11:58 stefan_schmidt: (postman) you should be ahppy you heard him ;-) 2011-06-23 11:59 jow_laptop: hey, cool! seems we can drop at least two of our patches 2011-06-23 11:59 thanks! 2011-06-23 12:00 wpwrak: only packages for my gf :) 2011-06-23 12:00 wpwrak: I'm moving my patches over to qi-kernel now and should have a new set with maybe some mor epatches later today 2011-06-23 12:01 larsc: okay to give stefan commit access for qi-kernel, so that he can work on the ben-wpan branch ? 2011-06-23 12:03 wpwrak: the IRQ race is tough when we are just trying to pass it from spi to usb I fear 2011-06-23 12:04 jow_laptop: btw, i've managed to make Ctrl+r (reverse-search) work somehow in busybox's ash, here is the first draft: http://downloads.qi-hardware.com/people/kyak/tmp/busybox.patch . I'll try to polish it and make it configurable. Let's see if it get's accepted then by busybox upstream :) 2011-06-23 12:04 but emulating two irqs and two frame buffer is problematic as well. To much logic in the firmware 2011-06-23 12:19 jow_laptop: cool 2011-06-23 12:20 stefan_schmidt: yeah, i wouldn't go as far a trying to emulate something wildly different 2011-06-23 12:20 wpwrak: ok, firmware is your part :D 2011-06-23 12:21 about the mtd-utils problem (missing ubiattach) 2011-06-23 12:21 just did feeds/install mtd-utils 2011-06-23 12:21 but looking at the makefiles i don't find any utilities that were split out 2011-06-23 12:21 wpwrak: I'm going to plug in the driver into the ieee802154 driver layer 2011-06-23 12:23 is the build-server using a different feeds.conf?Â Â because the one that is in nanonote-files does source an old version of mtd-utils without the splitting of tools 2011-06-23 12:24 stefan_schmidt: alright. that gives you the maximum flexibility 2011-06-23 12:24 dvdk: grep mtd-utils .config 2011-06-23 12:24 dvdk: and you'll see all of them :) 2011-06-23 12:24 not here 2011-06-23 12:24 CONFIG_PACKAGE_mtd-utils=m 2011-06-23 12:25 ah 2011-06-23 12:25 of course, you need to enable it 2011-06-23 12:25 enabled it no more options here 2011-06-23 12:25 to see the submenu items 2011-06-23 12:25 my feeds.conf: src-svn packages svn://svn.openwrt.org/openwrt/packages@25513 2011-06-23 12:25 @25513 is the problem? 2011-06-23 12:25 probably 2011-06-23 12:25 wpwrak: and it keeps the userspace API over sockets my other code bases on :) 2011-06-23 12:25 but where does the build server take his feeds.conf?Â Â im using the one from nanonote-files 2011-06-23 12:26 dvdk: why are you even pinning the revision, if you are playing with trunk? 2011-06-23 12:26 because i want reproducable builds :) 2011-06-23 12:26 the build server has it's own 2011-06-23 12:26 you can see it there 2011-06-23 12:26 where?Â Â can i get it? 2011-06-23 12:26 http://fidelio.qi-hardware.com/~xiangfu/compile-log/openwrt-xburst.full_system-06212011-1026/feeds.conf 2011-06-23 12:26 but i'm not on trunk, i'm on master :) 2011-06-23 12:27 we are all on master now, there is no trunk 2011-06-23 12:27 ah, well 2011-06-23 12:27 backfire is done :) 2011-06-23 12:27 but there must still be a deterministic, pinned feeds.conf, no? 2011-06-23 12:27 in nanonote-files? 2011-06-23 12:27 yes 2011-06-23 12:27 so yes 2011-06-23 12:27 used by the build server, so that build results do not change over time 2011-06-23 12:28 (without _us_ hacking anything) 2011-06-23 12:28 huh? 2011-06-23 12:28 this is the purpose of build server 2011-06-23 12:28 to build the latest 2011-06-23 12:28 not to build the same 2011-06-23 12:28 i mean, if we don't change our git repos, then build shouldn't have different results 2011-06-23 12:29 i thought the latest of _our_ stuff, not uncontrollable (and not easily patchable) openwrt upstream 2011-06-23 12:29 there is always latest feeds on build server. After the images is built, which is considered to be a release, then feeds can be pinned to reproduce it 2011-06-23 12:29 you can always see which feeds we base on 2011-06-23 12:29 http://fidelio.qi-hardware.com/~xiangfu/compile-log/openwrt-xburst.full_system-06212011-1026/VERSIONS 2011-06-23 12:29 here 2011-06-23 12:30 ok 2011-06-23 12:30 packages svn 27245 2011-06-23 12:30 the next build will be probably some other (next) svn revision 2011-06-23 12:31 it's been pretty stable for the last several build 2011-06-23 12:31 you can read the failed_packages.txt 2011-06-23 12:31 no too many of them 2011-06-23 12:31 at least nothing that's coming from qi-packages :) 2011-06-23 12:33 stefan_schmidt: oh, the socket API wouldn't change in any case :) 2011-06-23 12:34 wpwrak: sure, but right now the driver does know nothing about ieee802154 2011-06-23 12:34 wpwrak: I'm just teaching it the ops 2011-06-23 12:35 stefan_schmidt: aaah, yes. of course not. no meat on the skeleton :) 2011-06-23 12:36 wpwrak: need .... to .... be .... fixed 2011-06-23 12:39 hmm, interesting. for once, i now have a system there the interrupt handling doesn't deadlock even in simple tests. 2011-06-23 12:39 s/there/where/ 2011-06-23 12:39 morning 2011-06-23 12:41 (of course, it's not the approach that i plan to use in the end. that would be too easy :) 2011-06-23 12:43 kyak: if you have all the latest upstream packages in your feeds, can you enable the ubiattach tool and copy the config to config.full_sysytem? 2011-06-23 12:43 doesn't want to wait for 'make world ' after changing the feeds 2011-06-23 12:44 dvdk: yup. In fact, maybe i should enable all mtd-utils*? 2011-06-23 12:44 kyak: good idea 2011-06-23 12:44 [commit] Werner Almesberger: atusb/fw/: aggregate interrupts while waiting http://qi-hw.com/p/ben-wpan/27fc0a0 2011-06-23 12:44 dvdk: http://dpaste.com/557864/ 2011-06-23 12:45 kyak: you mean i should commit? 2011-06-23 12:45 all right then 2011-06-23 12:45 and now, let's try something completely different ... ;-) 2011-06-23 12:45 no, i can do that 2011-06-23 12:45 ok thx, so i just have to wait 2-3 days for the nextÂ Â "nightly" build :) 2011-06-23 12:45 why? 2011-06-23 12:46 it's already there 2011-06-23 12:46 because i'm lazy 2011-06-23 12:46 there, where? in the nightly build? 2011-06-23 12:46 yeah 2011-06-23 12:46 ok, time to upgrade (yet again).Â Â you're moving faster than i can follow :) 2011-06-23 12:46 http://fidelio.qi-hardware.com/~xiangfu/compile-log/openwrt-xburst.full_system-06212011-1026/packages/ 2011-06-23 12:46 (didn't see any commit related to ubiattach) 2011-06-23 12:46 nighly build builds all packages 2011-06-23 12:46 therefore they are there 2011-06-23 12:46 built as =m 2011-06-23 12:47 i understand, the package.Â Â but 'opkg search' didn't find it. 2011-06-23 12:47 opkg search '*mtd*' 2011-06-23 12:47 base-files - 71-r27114 2011-06-23 12:47 mtd - 15 2011-06-23 12:47 nanonote-script-files - 1.2 2011-06-23 12:48 opkg install mtd-utils-ubiattach 2011-06-23 12:48 Unknown package 'mtd-utils-ubiattach'. 2011-06-23 12:48 this VERSION=2011-06-18 2011-06-23 12:48 do you have your opkg.conf pointed to the right build? 2011-06-23 12:48 did you run opkg update? 2011-06-23 12:49 ah, points to: 2011-06-23 12:49 src/gz snapshots http://downloads.qi-hardware.com/software/packages/NanoNote/Ben/latest 2011-06-23 12:49 wrong? 2011-06-23 12:49 but this is how the image shipped 2011-06-23 12:50 [commit] kyak: config.full_system: enable mtd-utils-* http://qi-hw.com/p/openwrt-packages/6cf325e 2011-06-23 12:50 no, this is not right 2011-06-23 12:50 it should point to fidelio* 2011-06-23 12:50 yeah, need to fix Makefile of nanonote-files? 2011-06-23 12:50 in the //downloads.qi-hardware.com/software/packages/NanoNote/Ben/latest, there is the latest RELEASE image 2011-06-23 12:50 change it depending on build? 2011-06-23 12:50 if only yo uthink it is worth it :) 2011-06-23 12:51 definitely :) 2011-06-23 12:51 needs more coffe 2011-06-23 12:51 it is easir for me do it manually after reflash.. 2011-06-23 12:51 hmm, reflashing so often, already have a directory with 'make install' here to configure my nanonote after reflash 2011-06-23 12:52 i have a ben.sh for that 2011-06-23 12:52 but guessing the right value for opkg.conf too difficult? 2011-06-23 12:52 that i scp to Ben and just run it after reflash 2011-06-23 12:52 dvdk: perhaps it would make sense to modify the opkg.conf while running the build (via shell script) 2011-06-23 12:52 it's more complex here: it uploads a whole bunch of files, than runs a script (installing ubiattahc/mount scripts + ssh, emacs config and more) 2011-06-23 12:53 kyak: nmaybe that's easiest, just hack into the trunk build script 2011-06-23 12:53 yup 2011-06-23 12:53 again, if it is worth it :) 2011-06-23 12:53 which i doubt 2011-06-23 12:53 is searching for the right directory on fidelio 2011-06-23 12:54 it's in xiangfu's ~/bin 2011-06-23 12:54 :) 2011-06-23 12:56 huh? 2011-06-23 12:56 opkg install mtd-utils-ubiattach 2011-06-23 12:56 Installing mtd-utils-ubiattach (20090227-1) to root... 2011-06-23 12:56 Downloading http://fidelio.qi-hardware.com/~xiangfu/compile-log/openwrt-xburst.trunk-full_system-06202011-0123/packages/mtd-utils-ubiattach_20090227-1_xburst.ipk. 2011-06-23 12:56 Collected errors: 2011-06-23 12:56 * satisfy_dependencies_for: Cannot satisfy the following dependencies for mtd-utils-ubiattach: 2011-06-23 12:56 * mtd-utils * 2011-06-23 12:56 opkg install mtd-utils 2011-06-23 12:56 Unknown package 'mtd-utils'. 2011-06-23 12:57 package dependencies broken? 2011-06-23 12:57 hum 2011-06-23 12:57 opkg --force-depends install mtd-utils-ubiattach 2011-06-23 12:58 finally i have my data back 2011-06-23 12:58 mtd-utils is a submenu in which mtd-utils-* reside, not the real package. During build it is set to =y (even if mtd-utils-* are =m), so such dependency doesn't appear 2011-06-23 12:59 this is a completely legal case to use --force-depends :) 2011-06-23 12:59 doesn't want to know any more details :) 2011-06-23 13:16 meh, there's a dependecy on a not existing mtd-utils ? 2011-06-23 13:20 jow_laptop: looks like it, don't like it, too 2011-06-23 13:21 well its wrong 2011-06-23 13:21 plain wrong 2011-06-23 14:04 [commit] David KÃ¼hling: gmenu2x: update to use latest revision from git http://qi-hw.com/p/openwrt-packages/238cd35 2011-06-23 14:42 [commit] David KÃ¼hling: ase: use libjpeg,libz,libpng,libfreetype from openwrt instead of included ones http://qi-hw.com/p/openwrt-packages/cbb09a5 2011-06-23 14:42 kyak: btw our libfreetype seems to do subpixel aliasing, ASE fonts look a little nicer now 2011-06-23 15:20 6: wpan0: mtu 127 qdisc noop state DOWN qlen 10 2011-06-23 15:20 Â Â Â Â link/ieee802.15.4 de:ad:be:af:ca:fe:ba:be brd ff:ff:ff:ff:ff:ff:ff:ff 2011-06-23 15:20 wpwrak: ^^ ieee802154 registration is working 2011-06-23 15:20 only stub functions so far 2011-06-23 15:22 hail the caffeebabe ;) 2011-06-23 15:22 wpwrak: Next is a small xmit function following the atrf-rxtx style 2011-06-23 15:23 stefan_schmidt: nice ! :) 2011-06-23 15:24 xMff: bee2 bee2 ! ;-) 2011-06-23 15:25 can one get these atusb things with a case on? 2011-06-23 15:28