#qi-hardware IRC log for Wednesday, 2011-08-10

ignatius-Ok. I've dowloaded kernel source that supports the bigger NAND partition (openwrt-xburst-release_2010-11-17), compiled it. Booted it up, and I get this message, after a bunch of UBIFS debugging messages (which none of them help me): "ubimkvol: error!: bad volume type "ubifs" -- Anyone know what I could possibly doing wrong? 02:32
ignatius-And, yes, I have UBI compiled in the kernel.02:33
ignatius-It'll boot to a prompt, the partition size just doesn't use the entire NAND.02:52
xiangfuignatius-, you have to flash the correct UBI rootfs to your big partition.03:24
xiangfuignatius-, or you can run 'mtd.nn moust data /data' for mount the 1.5GB data partition to /data03:33
xiangfuignatius-, http://en.qi-hardware.com/wiki/Format_Data_Partition03:33
ignatius-Ah. That's what I was trying to avoid. Having to reinstall the rootfs. I have a lot of stuf that i'll have to download over again.03:36
ignatius-What would the "proper" UBI rootfs be based on?03:36
ignatius-I just don't understand why, when I compiled kernel sources a year or so ago. Everything worked right. I could compile (working) kernels on my desktop. I was able to configure the kernel sources to meet my needs. Problem way, for some reason (by my own doing?) I messed everything up, and can no longer (no which source tree i've tried) recompile a working kernel.03:41
ignatius-And I followed the Debain instructions. That's the route I took.03:42
ignatius-There are some precompiled kernels that _DO_ work with my system. Most others don't. I don't get it.03:42
ignatius-Like the "JLime" kernels, for example.03:43
xiangfuignatius-,  different GCC/uClibc may make kernel can not boot to rootfs. something wrong with load 'init'.03:55
ignatius-Ah. I see.03:55
ignatius-Yes. VFS error. Unable to load init.03:56
ignatius-I remember seeing that before. Didn't make the connection.03:56
ignatius-What did you mean by "flashing the correct UBI rootfs to the big partition"??? Is there a targetted way to compile the UMID/MTD partitions?03:58
ignatius-Er. s/compile/access03:58
xiangfuxiangfu, sorry the UBI rootfs is same. 04:01
xiangfusince your rootfs already used in a 512MB partitons then it will not working if you just modify the partition size.04:06
xiangfuyou have to reflash it again.04:06
wolfspraulit's amazing how long a change in partition size is haunting us04:09
wpwrakyeah, such things need to be pushed, not offered for "pickup at your convenience"04:22
wpwrakthere's also the problem of coordinating the distributions04:22
wolfspraulwpwrak: looking at the latest m1 rc3 test result http://en.qi-hardware.com/wiki/Milkymist_One_run_3_schedule#Test_Results04:45
wolfspraulthere's a worrying pattern I see in boards that work fine (called 'rendering cycle', meaning boot to render, let it render 30 seconds), but then fail to reconfigure the fpga after a power cycle04:46
wolfspraulI will wait for Adam to go through the entire lot first and let the dust settle, but I think it's already clear there's some valuable something to be discovered there.04:47
wolfspraulfor example 0x34, 0x3904:48
wpwrakand what brings them back ?04:48
wolfspraul0x3C04:48
wolfspraulright now when there's a problem Adam will mostly just stop with the board 'failed'04:48
wolfspraullater when we have data for all 90 we zoom in on any cluster of problems we can see04:49
wolfspraulbut I think I can see that one already :-)04:49
wolfspraula board that renders just fine, some once, twice, some 6 times, 9 times, and then suddenly cannot reconfigure anymore04:49
wolfspraul'renders' means a full boot and render for 30 seconds without any noticable issues04:49
wpwrak"reconfigure" is just the boot, no reflashing, correct ? (i.e., only 34 of these three also has the reflashing problem, correct ?)04:49
wolfspraulsome of them then stay in this condition, others may come back the next day or several days late04:49
wolfspraullater04:50
wpwrakodd indeed :)04:50
wolfspraulread the notes04:50
wolfspraulthen you see the sequence of steps on each board04:50
wolfspraulyes it could be related to flash04:50
wolfspraulit could be related to fix204:50
wolfspraulit could be related to tolerances of the diode or capacitors we added04:50
wolfspraulit could be related to something we could fix in software (bitstream), depending on where exactly in the 'reconfigure fails' it stops04:51
wpwrakhow hard is it to read back the flash via jtag ?04:51
wolfspraulshould be easy, we can try04:51
wpwraki've heard that it is possible but slow. how slow ? :)04:51
wolfspraulI don't know though, just guessing04:51
wpwrakreading back the flash would eliminate mere flash corruption as an issue04:52
wpwrakwell, unless it _is_ flash corruption ;-)04:52
wpwrakin which case you'd have identified the disease :)04:52
wolfspraulyou mean the initial flashing is faulty?04:53
wolfspraulthat is impossible now since we do crc checks, and also those are all boards that first rendered fine04:53
wolfsprauland then after X power cycles, they stop reconfiguring04:54
wpwrakyou could still get later flash corruption for some reason04:54
wolfsprauloh yes, we should definitely read back and compare04:54
wolfspraulif the data has changed, what could be the cause?04:55
wpwraknow you're asking the tricky questions ;-)04:55
wpwrakcould be some more unexpected behaviour of the reset circuit04:55
wpwrakor maybe it's something else. for all we know, it could be the FPGA sending some junk04:56
wolfspraullet's see what lekernel says later. I feel somewhat uneasy about those failure cases.04:57
wpwrakas i understand if, the flash is only accessed when booting (and when updating). so if it gets corrupted later on, then you wouldn't notice until the next boot04:57
wolfspraulbecause if a board fails on the 9th rendering cycle (out of 10), that's only one tiny test away from selling it. and what would guarantee that it won't fail on the 13th cycle, i.e. 3 cycles into the user's hands...04:57
wpwrakyeah, rc3 has quite a few troubles. a bit frustrating after things have gone so well before. but hey, that's how you earn the official endorsement from murphy ;-)04:58
wolfspraulah no, I don't see it that way04:58
wolfspraulrc1 had a whole number of major issues, expectedly04:58
wpwrakokay. if an rc1 is flawless, you're cheating ;-)04:59
wolfspraulrc2 was 40 boards, and I helped Adam testing for several days, so I know white well what I saw04:59
wolfsprauland we were nowhere near this kind of testing quality as we are with rc304:59
wolfspraulif we had done that, we would have never shipped or sold a single rc204:59
wolfspraulevery single rc2 board has trouble booting05:00
wpwrak*grin*05:00
wolfspraulas we've discussed before. we were just pretty good in selling boards to people that never did much with them, or that were smart enough to use workarounds, or simply got used to having to cycle several times etc.05:00
wolfspraulbut that won't scale05:00
wolfspraulso we do need to get to the real root cause sooner or later05:00
wolfspraulthe later the more expensive05:01
wpwrakare you sure the rc3 reconf cluster has a "memory" ? i.e., is it good-good-good-good-bad-bad-bad-bad ? or is it good-good-good-good-bad-ring the alarm and stop testing ?05:01
wolfspraulthe latter right now05:01
wolfspraulbut soon we will dig in there05:01
wpwrakso it could be that just 1/N tests fail05:02
wolfspraulI doubt that05:02
wolfspraulthere is firm evidence of 'memory'05:02
wolfspraulread the notes05:02
wpwrakit would be good to automate all those things. such that you can do, say, 100 or 1000 boot tests without adam actually pushing buttons05:02
wolfspraul0x34 0x39 0x3c05:02
wolfspraulwell05:02
wolfspraulAdam requested that already but it's hard to implement, and we want to do a real physical disconnect of the power cable as well, at least that's the test now.05:03
wolfspraulso we have 0x34 0x39 0x3C now, and I'm sure by the time Adam went all the way through after the schmitt-trigger fix, there'll be more05:03
wolfspraulin which case I would rather do more testing before start selling05:03
wolfspraulfor example increase to 20 cycles and do all boards again05:03
wolfspraulsee whether more 'drop out'05:03
wpwrak(notes) you mean the "notes" column ? or the .results link ? the "notes" column doesn't suggest any memory. and for 34, i see mainly a troubled history05:03
wolfspraulI mean all boards that are 'available' right now05:04
wolfspraulnotes column05:04
wolfspraul0x34 is interesting05:05
wolfspraulif I understand the notes correctly it did flash, boot and render after replacing diode + c23805:05
wpwraki don't see a "memory" anywhere. in the sense of a persistent state change of the system 05:05
wolfsprauland then it went back to failure mode again05:05
wolfspraulwell05:05
wolfspraulwith 0x34 you see it very clear05:05
wolfspraulthat's why Adam had to resort to trying diode/c238 replacements05:05
wolfspraulbecause there was no other way to kick it back alive05:05
wolfspraullet me look at 0x39 and 0x3C05:06
wpwrak0x34 also has the reflashing issue. is this also with the short cable ?05:06
wolfspraulyes those two no memory yet, just testing stop for now05:06
wolfspraulI am sure Adam is 100% on the short cable now05:06
wolfspraulno need to add more uncertainty05:06
wolfspraulas soon as we have identified _any_ improvement, we'll go for that05:07
wpwrakin other words, the short cable doens't always make the problem go away05:07
wolfspraulthere may be multiple problems05:07
wolfsprauland the analysis of that short vs. long theory was also lacking05:07
wpwrakcan you downgrade to full-speed usb ?05:07
wolfspraulit was an empirical decision05:07
wolfspraulI don't think it's a flashing issue, because once the crc test passes, we can assume everything was written correctly.05:07
wolfspraulso why doubt that?05:07
wpwrakyou probably have impedance issues in the USB signals. high-speed is hairy05:08
wpwrakno, board 34 ends with: 10. stopped at 'Bitstream length: 1484404' while reflashing05:08
wolfspraulwhen Adam is back from lunch break, we can ask him to try to boot 0x39 and 0x3C, I would think we will see the 'memory' effect then05:08
wolfspraulyes now it does05:08
wpwrakso this is with the short cable ?05:09
wolfspraulbut under 7. it rendered05:09
wolfspraulthat's my point05:09
wolfspraulhow can I board that boots and renders fall back (!) to an unreconfigurable state05:09
wpwrakno no ... different issue :)05:09
wolfsprauland yes, now it cannot be reflashed anymore05:09
wolfspraulbut before it could be flashed05:09
wpwrakthe "10. stopped at 'Bitstream length: 1484404' while reflashing" is also what you got when the cable was too long, correct ?05:09
wolfsprauldon't know05:10
wolfspraulthere are several boards in this state, but I believe all/most of them rendered before05:10
wolfspraulchecking05:10
wolfspraullong cable issue was "d2/d3 dimly lit after flashing"05:12
wpwraki would propose the following test: take a board that boots okay, verify that it boots okay. download the flash via jtag 3-5 times, verify that all the copies are identical (cmp, maybe also md5sum so that we have a reference), then boot again. if it boots okay, reconfig and everything, proceed. else, bring it back to life or pick a different board and repeat from the first step05:13
wolfspraulmy concern now is on boards that rendered just fine, and then without any hw action, REGRESSED to unreconfigurable state05:13
wpwrakthis will give you a known to be good downloaded flash content. this may or may not be identical to what you upload. if it is, even better. if not, that may just be something the flash process does, that's why i'd treat it as a black box for now.05:13
wolfspraul'download' you mean write the flash or read the flash?05:14
wolfspraulread multiple times? or write multiple times?05:14
wpwraknow, equipped with a reference downloaded content, take one of the boards that have regressed and jtag-download its flash. then compare with the reference. if there're different, something may have disturbed the flash, flash access may be unreliable, or it has a jtag/usb issue. if they're the same, it's something else05:15
wpwrakdownload = read from NOR to USB/PC via JTAG05:16
wolfspraulyes sounds good, we'll prepare that05:17
wolfspraulfor now Adam will go through the entire lot with another whole round of testing05:17
wpwrakoh, and of the 3-5 images from the "good" board differ among each other, that wuold also be interesting. if the board then still boots okay, then it means that USB is bad. otherwise, the flash may have become compromised.05:17
wolfspraulI highly doubt we are looking at usb issues here05:17
wolfspraulif anything your test may lead us in the wrong direction because it exposes usb issues that are unrelated to the regression on the running boards we are trying to study05:17
wolfspraulthe issue is a running board (renders fine), that suddenly regresses to a nonconfigurable board05:18
wpwrakph i'm absolutely sure you have an usb issue ;-) but i don't think it causes the reconfig problem. but it may hit you on other occasions, making tests less predictable05:18
wolfspraulhow can that be related to any usb issue?05:18
wpwraks/ph/oh/05:18
wolfspraulI agree, but that's a completely different problem, and doesn't block much right now.05:19
wolfspraulwhat blocks a lot is boards that render fine and then fall back.05:19
wpwrakthe problem with the usb issue is taht it may cause jtag-download to be corrupted. errors CAN get past the USB CRC.05:19
wolfspraulthat may mean none of the boards that pass can be sold, until we find the root cause05:19
wolfspraulhow can that lead to a board first rendering fine, and then failing on the xth power cycle05:19
wpwrakno no. that's not what i'm saying05:20
wpwrakwhat i'm saying is that you need jtag-download as a tool to analyze this problem. but that tool itself may be compromised, due to the usb issue. so you need to factor in tests for data integrity over usb as well.05:20
wolfsprauleven if it takes several reflash cycles, why bother about that unreliability right now? the interesting part is that after a proven successful flash (proven by a crc in the test image, and then proven by successful rendering), the board falls back05:20
wolfspraulanyway I agree on your download multiple times and md5sum etc.05:21
wolfspraulthat will give us some visibility into the lower levels05:21
wolfspraulbut the really interesting thing happens somewhere between 2 power cycles05:22
wpwrakand again, the failure to reflash is also a regression. although possibly in a different domain. (we don't know for sure that the "usb problem" is really usb. could also be, say, the flash occasionally just not wanting to talk to the world)05:22
wolfspraulwhere the first one ends in a board that renders, and the next one ends in a board that won't reconfigure05:22
wolfspraulwhat happens in between?05:22
wpwrakwell, does anything happen in between ? :) we don't know this yet05:22
wpwrakit could be a memory-less effect05:22
wpwrak20% chance of failure on boards X, Y, and Z05:23
wolfspraulhah, there is Adam :-)05:23
wolfspraulaw: how's testing going?05:23
wolfspraulwpwrak: that is not what i gather from closely following the testing so far, this issue seems more sticky, like a switch, and then it stays.05:24
wpwraksomething like that. you need automated tests (or a patient operator ;-) to analyze such things. remember those capacitor issues we had in gta02, where i did hundreds of automated runs. it's this kind of thing. if you have a stochastic problem, you need to collect enough data before you can be sure what it is that you're seeing05:24
wpwraka "switch" would be nice. easier to debug :)05:25
wolfspraulmy most pressing problem is to decide whether the boards labeled 'available' currently can be sold or not05:25
wolfspraulaw: I am wondering about 0x39 and 0x3C...05:25
awdon't know yet why 05:26
awcontinuing to finish previous vga/midi/usb failures firstly..;-) my hands is not pipeline. :)05:27
awwill beck to see. :)05:28
wpwrakaw: you need more caffeine pills ;-)05:28
wpwrakwolfspraul: it's a pity that only adam can do testing. there's the risk of tunnel vision and other systematic errors in this. 05:30
wpwrakwolfspraul: (besides the sheer workload, of course)05:30
wolfspraultrue but unfixable05:30
wolfspraulthere's a lot of risks05:30
wolfspraulwe should already run rc4 with 160 units in parallel05:30
wolfspraulthrow a lot more resources at it, take a lot more risks05:31
wolfsprauldevelop Milkymist Two in parallel05:31
wolfspraulan so on05:31
wolfspraula lot of 'should'05:31
wpwrak(unfixable) yeah, possibly. lekernel didn't want to do a little trip to taipei ? :)05:31
wolfspraulSebastien would need a few helping hands on the IC design as well, ahh. not 'would', but 'should'05:31
wolfspraulgood idea, never thought about it05:31
wolfspraulSebastien could surely learn some manufacturing patience, if he would be able to handle it :-)05:32
wolfspraulyou are fatalistic enough that no matter what happens, you stay calm05:32
wolfspraulhe he05:32
wpwrak(rc4) naw, i think it would be too early for this. there are still a number of things that seem a bit to vague and that can probably be debugged in rc3.05:32
wolfspraulsuch a trip would have been quite costly in time and money though, not sure even if we would have had the proposal before whether everybody would have liked it05:33
wolfspraulrc3 is already far better than rc2, as a product. the downside is that as we raise the testing level, more unpleasant surprises are made.05:33
wolfspraulwhat at least for my part, I want that05:33
wolfspraulI have no illusions about my ability to sell boards one by one to people that shelf them, and so will never report back problems.05:34
wpwrak(if he would be able to handle it) yeah, that's what may be a concern. i remember harald freaking out ;-) (okay, that was mostly about FIC incompetence)05:34
wolfspraulincompetence or not, it's a very demanding mental challenge05:34
wolfspraulmost software and 'design' people would run away05:34
wpwrakhehe :)05:34
wolfspraulit's frustrating to have to accept the randomess and seemingly unending stream of rare/unexpected/strange/should-not-be cases05:35
wolfspraulmakes you feel a small little nobody in the big wide universe05:35
wolfspraulso much better to hack on software, right?05:35
wolfspraul:-)05:35
wolfspraulanyway, good idea with the trip, but nobody had the idea before05:35
wolfspraulI'm not even sure it would have helped much, I think progress is just fine05:36
wpwrak(trip) before actually seeing all the little rc3 problems, it would indeed have sounded unnecessary. the problem is that, with those widely spread out issues and the large amount of rework, you really have to be "there"05:36
wolfspraulneither the acrylic cases nor the boxes/eva, labels and other print material has arrived in Taipei as of today05:36
wpwrakcustoms having a slow week ?05:37
wolfspraulno, all fine. moving.05:37
wolfspraulit's hardware05:37
wolfsprauldoesn't travel at the speed of light05:37
wpwrakbut i thought they're already at customs ?05:37
wpwrakand have been so for at least a day. maybe more ?05:37
wolfspraulyes, I don't know exactly which gps coordinate they are at at any given minute :-)05:37
wolfspraulA DAY!05:37
wolfspraulwow05:37
wolfspraulso many things can happen in a day, right?05:37
wolfspraul:-)05:37
wolfspraulSteve Jobs makes the entire iPhone in one single day.05:38
wolfspraulhe gets up in the morning, and in the evening he shows his friends05:38
wpwrakwell, i'm used to BUE customs sitting on stuff for a day and i hate every minute of it05:38
wolfspraulso let's see. Adam is making a full round of testing now.05:38
wolfspraulthen we see new numbers05:38
wpwraki thought he'd shit the next iMarvel right after breakfast. didn't realize it took him a whole day ;-)05:39
wolfspraulbut I already have this suspicion there is more valuable stuff to discover05:39
wolfspraulif there were one board one time that went from rendering to unconfigurable, ok, i'd ignore it05:39
wolfspraulbut it's several boards, and growing. too many.05:39
wpwrakcan you downgrade the jtag dongle to full-speed ? and if yes, is it difficult to do ? if it's easy, i would recommend doing this before starting the flash corruption analysis05:40
wpwrak(jtag dongle) well, at least the one adam will use for this05:40
wolfspraulI think we can short or otherwise disable the eeprom on the daughterboard05:40
wolfspraulthat way it will fall back to full-speed05:40
wolfspraulsomething like that05:40
wolfspraulit's a bit difficult to enforce on the Linux side, afaik05:41
wolfspraulmissing feature05:41
wolfspraulcan't just echo '0' into some sys file, afaik05:41
wpwrakyou had them do only full-speed in the past (by accident), was that an eeprom issue ?05:41
wolfspraulno05:41
wolfspraulbut now that that bug is fixed, I believe shorting the eeprom will cause it to fall to full05:41
wolfspraulI don't know how to force it on the Linux side, you tell me05:42
wolfspraulI looked once, couldn't find anything05:42
wpwrakokay. may be worth trying then05:42
wpwrak(linux side) dunno either. use a old full-speed-only hub ? ;-)05:42
wpwraklinux seems to have a mechanism, not for forcing full-speed per se, but for assigning the port to the companion UHCI/OHCI, which also has the effect of not using high-speed05:52
wpwraknow, let's see how this works ...05:52
wpwrakhmm. you need to know the PCI ID of you EHCI. how convenient. let's see if there's a link somewhere deeper in sysfs ...05:55
larscwell you could go by the driver node06:17
wpwraklarsc: the only path that seems to lead anywhere is via class/usbmon/. a little odd.06:23
wpwrakah, there's the usb bus also in the pci hierarchy. let's see if this helps06:26
larscwpwrak: /sys/bus/usb/devices/usbX06:26
larschmpf! were did my coffe go?06:27
wpwrakyes ... okay, with .. i can get to proper the PCI hierarchy. how, where's the companion file again ...06:29
wpwrakhehe, bus/usb/drivers/usb/usb1/../companion06:30
wpwrakwell, maybe. that only works for two EHCIs. the others have weirder paths.06:30
wpwrakyes ! :)06:34
wpwrakokay, here is how it works:06:34
wpwrak- plug in the critter and let it enumerate at high-speed. check the demsg output. should say something like "usb 2-1: new high speed USB device"06:35
wpwrak- that's usb-$BUS-$PORT. you remember these values06:36
wpwrak- then, echo $PORT >/sys/bus/usb/drivers/usb/usb$BUS/../companion06:36
wpwrak- the device should now reset and re-enumerate as full-speed. dmesg should then show something like "usb 6-1: new full speed USB device"06:37
wpwrakin the example above, the command would have been: echo 1 >/sys/bus/usb/drivers/usb/usb2/../companion06:38
wpwrakas usual, mind the space between 1 and > ;-)06:38
wpwrakthis only works with EHCIs that do things the old way, of having an UHCI/OHCI on their side. if they are themselves capable of lower speeds, this mechanism isn't available (and, it seems, there's no alternative means in this case)06:40
wpwrakto return the port to high-speed,06:41
wpwrakecho -$PORT >/sys/bus/usb/drivers/usb/usb$BUS/../companion06:42
wpwrake.g., echo -1 >/sys/bus/usb/drivers/usb/usb2/../companion06:42
blackroseM}KM0†openmokoK:ˆœ"FåS‚U-p÷î‚Uý-p07:16
blackrose÷îý…V„07:18
kyakheh, good to know my irc client/terminal is fine displaying Chinese or whatever that is :)07:20
larsci only see lots of blocks with numbers07:21
blackrose@kyak,i want buy a openmoko07:22
blackrosewhere i can buy it ?07:22
xiangfublackrose, taobao.com search freerunner or Ben nanonote :)07:23
xiangfublackrose, (I assume you are in China)07:23
blackrosexiangfu,thank you.yes ,i come from china.07:24
xiangfublackrose, checkout this: http://item.taobao.com/item.htm?id=969710667607:24
blackrosethanks, i saw "Qi-Hardware" on other website07:26
xiangfublackrose, cool. welcome to join #qi-hardware07:26
blackrosethanks!07:27
xiangfublackrose, I recommend you buy ben nanonote instead freerunner .07:28
blackrosewhy ?07:28
xiangfublackrose, because we (45 people here) support Ben nanonote. answer All nanonote questions.07:29
xiangfuwhy you want buy freerunner?07:29
blackrosecan you give me a website?07:29
blackroseNow, i learn embedded system programming, so i want to buy it play.07:30
xiangfublackrose, wow then nanonote is the right device07:32
xiangfublackrose, http://en.qi-hardware.com/wiki/Applications07:32
xiangfublackrose, http://en.qi-hardware.com and http://en.qi-hardware.com/wiki/Ben_NanoNote, 07:33
xiangfublackrose, you can find the device in taobao.com also.07:33
xiangfublackrose, all source code here: http://projects.qi-hardware.com/07:34
blackrosethanks. all source? Is include bootloader and kernel?07:35
xiangfublackrose, yes. include them07:35
blackrosei can read it later07:35
xiangfublackrose, most is under : http://projects.qi-hardware.com/index.php/p/openwrt-xburst/07:35
blackrosewhere is hardware's info of Ben nanonote?07:38
xiangfublackrose, http://en.qi-hardware.com/wiki/Ben_NanoNote ,there is "Hardware / Flashing " at bottom07:39
blackrosesee it.07:40
`antonio`good morning, wpwrak: I am following the instructions on http://projects.qi-hardware.com/index.php/p/ben-wpan/source/tree/master/install/INSTALL-Ben    but I am having some problems with zigbee10:09
`antonio`http://pastebin.com/7tYJGRJ610:09
wpwrak`antonio`: oh, interesting. seems that you didn't cross-compile the programs. if you run "file iz" on the /usr/sbin/iz, what does it say ? (you may have to copy it back to the Linux PC first, as your ben may not have "file" installed)12:09
`antonio`wpwrak, do you have any image I can flash with the dirtpan modifications? 13:30
wpwraki don't have a full system image. but i can make and upload kernel and tools binaries. lemme check what i have ...13:32
`antonio`wpwrak, that would be great 13:34
wpwrakbut fist, i have to fix my build environment ... the last experiments with try to teach openwrt to cross-build SDL didn't go so well ...13:39
wpwrak`antonio`: http://downloads.qi-hardware.com/people/werner/wpan/bintmp/13:47
wpwrakextract wpan-binaries.tar.gz into / then run /sbin/ldconfig13:47
wpwrakfor the kernel, bunzip it, scp the uImage to the ben, then13:48
wpwrakflash_eraseall /dev/mtd1 && nandwrite -p /dev/mtd1 uImage13:48
wpwrak(and make sure you don't reset/power down/etc. between starting the flash_eraseall and the end of the nandwrite. otherwise, it's usbboot time ;-)13:49
`antonio`wpwrak, thanks i'll let you know how that goes14:00
wpwrak`antonio`: do you have 2 atbens or atben to atusb ?14:01
`antonio`wpwrak, yes i have 2 atbens14:02
wpwrakgreat. then you don't have to worry about the PC kernel :)14:03
`antonio`wpwrak, thank you ! we got it working !14:45
wpwrak`antonio`: whee ! welcome "on the air" ! ;-)14:56
wpwrakhmm, that CCCamp is in a place called "Finowfurt". is it just coincidence that this name almost contains the letters of "Fnord", and in the right sequence ?15:23
kristianpaulwolfspraul:if too expensive too travel may be give him acess by ssh/vpn to a laptop connected to a M1 so some test can remotelly done?16:52
wolfspraulah no worries, we'll all work in parallel16:57
wolfsprauleverybody cranking here ;-)16:57
kristianpaulhum, afaik stillmissing vga feedback for remote operation :(18:03
kristianpaulwpwrak:(Fnord) a good excuse to go to cccamp? :)18:04
kristianpaulhttp://events.ccc.de/camp/2011/Fahrplan/events/4575.en.html18:15
kristianpaulthats a nice excuse to go :)18:15
wpwrakwolfspraul: be quick if you want to use "libre". they're starting to erode that as well: http://www.alibre.com/18:44
kristianpauloh, the bitsfrombytes guys, really nice printers.. afaik no so libre latelly :(18:50
qi-botThe build has FAILED, see log here: http://fidelio.qi-hardware.com/~xiangfu/compile-log/openwrt-xburst.full_system-08092011-1953/21:42
--- Thu Aug 11 201100:00

Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!