<whitequa1k>
xiangfu: what about jzboot integration? I've sent you a reply
<xiangfu>
whitequa1k: sorry. I put too much time on milkymist one recently. sorry.
<xiangfu>
whitequa1k: I was thinking. we can add support nanonote to jzboot. then we can just delete the usbboot in future. and keep the xbboot.
<xiangfu>
whitequa1k: do you think we should merge to source code repo?
<xiangfu>
s/to/two
<kyak>
what's the difference between jzboot and usbboot?
<whitequa1k>
xiangfu: no problem, I just wanted to be sure that my letter wan't eaten by spam-filter or something like that
<xiangfu>
usbboot source code is very very bad. the target source code are copy  from ingenic.cn
<xiangfu>
kyak: only the target image source code is bad :)
<kyak>
so you mean that jzboot is much cleaner?
<kyak>
what about the functionality?
<xiangfu>
kyak: I think so.
<whitequa1k>
I don't think that merging repositories is a good idea, jzboot is completely different from usbboot
<kyak>
xiangfu: i'm thinking about that bug in latest usbboot, that corrupted the bootloader. Maybe it'll work good in jzboot?
<whitequa1k>
I think you can set up a repo for 'qi-jzboot' and then we'll add all relevant changes to it
<xiangfu>
whitequa1k: where is the source code of firmware in jzboot
<whitequa1k>
also, it uses target images from usbboot/ingenic. the main difference is in host functionality
<xiangfu>
whitequa1k: so you don't have touch the firmware source code. only the host app?
<whitequa1k>
yeah
<whitequa1k>
the host app was rewrittten from scratch, through
<xiangfu>
whitequa1k:maybe the first step is include the 'jzboot' in debian package xburst-tools. :)
<xiangfu>
whitequa1k: ok. understand now.
<whitequa1k>
then it makes sense to include jzboot in your repo, yeah
<xiangfu>
whitequa1k: hmm.. then the sync will be a problem. I will ask debian people if the package can build base on two repo :)
<xiangfu>
kyak: if they using the firmware from ingenic.cn.  then jzboot will be the same as lastest usbboot.
<kyak>
xiangfu: does it mean that older usbboot wasn't using the firmware from ingenic?
<whitequa1k>
xiangfu: I mean that we can just include it in a subdirectory, not merging anything (in this context word merge can have different meanings), and then it won't be a problem to build the package
<whitequa1k>
I think it's OK to make repository on qi-hardware the main one for jzboot
<xiangfu>
whitequa1k: oh. yes. a subdirectory will not a problem
<kyak>
xiangfu: this is strange, i'm using the same firmware with both older and latest usbboot, but only latest usbboot has this problem
<whitequa1k>
kyak: the firmware has some glitches , which have workarounds in jzb[D[D[D[D[D[D[D[D[D[D[D[D[Doot
<whitequa1k>
oop
<kyak>
--)
<whitequa1k>
okay, I'll find a better internet connection then
<whitequa1k>
I'll return in ~2 hours
<xiangfu>
whitequa1k: (main one for jzboot) . ok talk to you when you back :)
<xiangfu>
kyak: which commit of the older usbboot?
<xiangfu>
kyak: can you test reflash twice u-boot on your nanonote. ?
<kyak>
xiangfu: i reflashed in several million times :)
<kyak>
it doesn't help
<kyak>
xiangfu: which commit - i don't know. I tested the old release (mentioned in my e-mail back then) and the latest one from git
<whitequa1k>
xiangfu: I'm here
<xiangfu>
whitequa1k: Hi  (main one for jzboot)  so we make a sub-folder under xburst-tools?
<whitequa1k>
yeah
<xiangfu>
whitequa1k: ok. great. I remember I saw some document that we can import all git history to another git sub-folder.
<whitequa1k>
that is called 'git submodules'
<tuxbrain>
wpwrak aw_ parcel with atben atusb and jtag had just arrived :)
<xiangfu>
whitequa1k: oh. do you have an account in projects.qi-hardware.com?
<whitequa1k>
no
<whitequa1k>
I'll register now then
<aw_>
tuxbrain, pls just send to list then we can view it. :-)
<tuxbrain>
I have a lot of other work to do but I will try to follow the wpwrak howto asap and do some post about it, also sugru is on its way so I will also make some lamer test on if it cause any perceptible effect
<aw_>
tuxbrain, sorry that I was thought it's the panelized gerber. :-)
<tuxbrain>
aw_:  no was your pà rcel :P the pcb maker is not so quick :P
<aw_>
tuxbrain, yup...;-)
<whitequa1k>
xiangfu: done, username is whitequark
<xiangfu>
whitequark: I made a small patch for jzboot.
<whitequark>
xiangfu: have you pushed it?
<xiangfu>
whitequark: not yet. I still not very clear how submodules works. needs add one Makefile.am to the jzboot.
<whitequark>
the submodule is basically a link to a particular commit in other repository
<whitequark>
so when you fetch a commit X from main repository, and run 'git submodule update', it will always fetch commit Y (recorded in .gitmodules) from the submodule repo
<whitequark>
the submodule itself is a perfectly normal git repository
<whitequark>
so, after you update the submodule (i.e. checkout other commit in the subdirectory), you need to commit the parent repo as well
<xiangfu>
whitequark: so for add a new file Makefile.am . I have to push it to jzboot.git?
<whitequark>
yes
<whitequark>
will qi-bot announce commits in jzboot?
<wolfspra1l>
not yet :-)
<xiangfu>
whitequark: I will add me as the jzboot.git member. then add the new file Makefile.am
<xiangfu>
whitequark: what is the error of your 'autogen.sh' ?
<whitequark>
that was caused by nonexistent Makefile.am because jzboot has not updated
<whitequark>
it's fine now
<tuxbrain>
roh wpwrak aw_ wolfspra1l sugru also arrives... sigh why by the love of $DEITY fun stuff arrives when your plenty of boooring stuff to take care off
<whitequark>
xiangfu: jzboot has readline support, but currently it's enabled by compiling make READLINE=1
<whitequark>
I wonder how that should be hooked into autoconf
<xiangfu>
needs add one option to './configure.ac' and the 'jzboot/makefile.am' check the ./configure.ac line 12.
<xiangfu>
there is a '--enalbe-firmware' '--disable-firmware' in configure now. for enable/disable firmware under usbboot
<whitequark>
okay, I'll do that
<xiangfu>
usbboot/src/Makefile.am line 15
<xiangfu>
whitequark: thanks
<whitequark>
why there is a .mailmap file in xburst-tools root?
<tuxbrain>
btw guys another topic question... what people do you think about RFID technology? Is a pantent trap? I think a rfid-6lowpan device can be cool by itself but also a good complement for nanonote as datalogger.
<xiangfu>
whitequark: it's commit by Jonathan Nieder, for 'git shorlog'
<whitequark>
sure, but what purpose it has? I've never seen that before
<wpwrak>
tuxbrain: (parcel arrived) wonderful ! and great timing ! ;-)
<wpwrak>
tuxbrain: (atusb) hmm, both of them ?
<tuxbrain>
wpwrak: (atusb) no, the atusb6 is the crazy one, the 7 gives me [192239.352519] usb 2-1: new full speed USB device using uhci_hcd and address 90
<tuxbrain>
[192239.480312] usb 2-1: device descriptor read/64, error -71
<tuxbrain>
[192239.965081] usb 2-1: configuration #1 chosen from 1 choice
<tuxbrain>
and a pretty lsusb
<tuxbrain>
Bus 002 Device 091: ID 20b7:1540
<xiangfu>
whitequark: I guess it's for "debian/changelog.upstream.awk"
<whitequark>
xiangfu: ah right, thanks
<whitequark>
I'm currently converting the entire jzboot to automake
<xiangfu>
whitequark: we need cleanup the debian build code. since we don't using the git commit any more. instead we start to release the source tar ball.
<wpwrak>
tuxbrain: (atusb6) hmm. maybe the USB reset problem has a time component. or some hardware issue re-appeared. do you have something that can measure frequency up to > 1 MHz ? (ideally, 8 MHz, but anything above 1 MHz should do)
<tuxbrain>
wpwrak: nop
<tuxbrain>
I doubt my old faithfull digital voltmeter can do what you said, or maybe yes but my eyes  can't pericive the fluctuations  >0,01MHz
<whitequark>
tuxbrain: ahem... do you want to say you can catch 10kHz with your eyes?
<whitequark>
that's pretty impressive
<jlamothe>
Clearly you're superman.  :)
<tuxbrain>
nah! just trained with codificated porn films during my adolescense
<tuxbrain>
In spain there is a full male generation able to do that :)
<tuxbrain>
hehehe zumbi is another one of those :P
<wpwrak>
tuxbrain: (no instruments) hmm, could also be that it just doesn't have the correct firmware. i expected that we'd have to reflash for some updates anyway, so i didn't particularly check. you can change the firmware with the process described here: http://lists.en.qi-hardware.com/pipermail/discussion/2011-March/007641.html
<wpwrak>
tuxbrain: programming would be the  make prog-app  step
<wpwrak>
tuxbrain: there are basically four things that can cause problems with USB: 1) a problem in the USB-ATmega32U2 side connection. that should be very unlikely (could happen in production, though, e.g., if they produce a short across one of the TVS)
<wpwrak>
tuxbrain: 2) the yet unresolved USB reset/enumeration problem on its own. that is just a guess. 3) having both DFU and application in the flash. that would cause them to cycle endlessly through reset, due to the USB reset problem. the solution is to just flash the application, without flashing the DFU boot loader.
<tuxbrain>
wpwrak: roger, I will try to reflash it today night or tomorrow, now I must leave
<wpwrak>
tuxbrain: 4) if the ATmega32U2 fails to switch the clock speed. the transceiver produced a 1 MHz clock after reset. the MCU needs 8 MHz, so it tells the transceiver to switch. if this goes wrong, the system will run at an incorrect speed.
<tuxbrain>
wpwrak: btw pretty impresive piece of artesany both atben/atusb.... do you think about dedicate to jewelry?
<wpwrak>
(jewelry) thanks ! maybe we should start a fashion trend that uses electronic as jewelry ;-)
<tuxbrain>
ad 6lowpan biometrics to this and you have a win product :)
<tuxbrain>
btw wpwrak what do you think about RFID tech?
<whitequark>
xiangfu: I've ported that to autotools. even with fancy --with-readline switch
<wpwrak>
tuxbrain: (rfid) no idea. i don't know the use cases too well. okay, except as fancy bar codes.
<xiangfu>
whitequark: cool.
<whitequark>
i'll try to hook up debian packaging for jzboot then
<tuxbrain>
wpwrak: animal control on farms, logistics, personal identification for security... but yes all uses cases can be sumarized on fancy bar codes :)
<tuxbrain>
what I mean is to have an auntonomouse device with 6lowpan and rdif reader to integrate in a 6lowpan network, but I don't know is rfid is pantent tainted technology or how dificult is to implement
<tuxbrain>
dificult=costs
<wpwrak>
tuxbrain: don't know about RFID IPR issues either
<tuxbrain>
IPR (Intellectual property reclaim?)
<C-Keen>
rights I guess
<wpwrak>
tuxbrain: if you have some RFID thingy that tasks plain SPI, there should be no problem connecting it to a 6LoWPAN device. there are a lot of MCU+IEEE 802.15.4 chips, and many of then are supported by contiki
<wpwrak>
tuxbrain: for an autonomous wireless system, you could use, say, the freescale mc13224v
<wpwrak>
tuxbrain: that's an arm7 (plus RF). even has the balun integrated. a bit difficult to solder, though - sort of a hybrid between QFN and BGA
<whitequa1k>
it's also cheap for such a good soc
<whitequa1k>
$9 here
<whitequa1k>
btw, can anyone suggest an easy-to-use 2.4GHz transciever with no external components?
<wpwrak>
whitequa1k: you mean a chip (which probably doesn't exist) or a module ?
<wpwrak>
whitequa1k: also, what do you do with the rf signal ? antenna or connector would be "external components", right ? so it has to be a module then
<tuxbrain>
wpwrak: I think can have access to someone able to solder it.... so in theory connecting this freescale to the avobe rfidreader, some source of power and we are done?
<whitequa1k>
wpwrak: a chip. I've found TI's CC2500, but a few people that worked with it complain to unstabilites
<whitequa1k>
it technically requires only several caps and a PCB antenna
<wpwrak>
whitequa1k: and a crystal, plus for anything but a dipole, a balun. that's just like the at86rf231
<wpwrak>
tuxbrain: could work, yes
<wpwrak>
whitequa1k: the crystal is almost unavoidable - you need 40 ppm stability
<whitequa1k>
wpwrak: oh sure, a crystal too, and load capacitors
<wpwrak>
whitequa1k: someone could design a "parasitic" oscillator that takes another station as its reference, but afaik, nobody has done such a thing yet
<wpwrak>
whitequa1k: i think the mc1322x may be your best best for low component count. no external xtal load caps, integrated balun. unfortunately, the chip itself is a bit large. but still smaller than a module
<whitequa1k>
wpwrak: it's not only large, it has pads underneath it. I won't be able to do pcb for it by myself
<whitequa1k>
so unfortunately I don't think that is an option
<whitequa1k>
atrfs are nice, but I wasn't able to find any in russia (you can buy a thousand, but not one)
<wpwrak>
whitequa1k: if you can buy a thousand, someone must have spares :)
<wpwrak>
whitequa1k: maybe ask atmel ? otherwise, the cc2500 may be a suitable alternative. oddly enough, that one has us export restrictions while the at86rf231 doesn't ;-)
<whitequa1k>
wpwrak: do you mean, ask them for samples?
<whitequa1k>
ah well, terraelectronica has some cc2500 in stock. the problem is solved then
<whitequa1k>
also, are those 'chip antennas' as good as they're described on vendor site?:)
<wpwrak>
curses blackouts
<wpwrak>
whitequa1k: (atmel) samples or names of distributors
<wpwrak>
whitequa1k: (chip antenna) dunno. it's said that their performance varies a lot with their surroundings, so they may need careful tuning