2011-08-10 02:32 <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? 
2011-08-10 02:33 <ignatius-> And, yes, I have UBI compiled in the kernel.
2011-08-10 02:52 <ignatius-> It'll boot to a prompt, the partition size just doesn't use the entire NAND.
2011-08-10 03:24 <xiangfu> ignatius-, you have to flash the correct UBI rootfs to your big partition.
2011-08-10 03:33 <xiangfu> ignatius-, or you can run 'mtd.nn moust data /data' for mount the 1.5GB data partition to /data
2011-08-10 03:33 <xiangfu> ignatius-, http://en.qi-hardware.com/wiki/Format_Data_Partition
2011-08-10 03:36 <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.
2011-08-10 03:36 <ignatius-> What would the "proper" UBI rootfs be based on?
2011-08-10 03:41 <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.
2011-08-10 03:42 <ignatius-> And I followed the Debain instructions. That's the route I took.
2011-08-10 03:42 <ignatius-> There are some precompiled kernels that _DO_ work with my system. Most others don't. I don't get it.
2011-08-10 03:43 <ignatius-> Like the "JLime" kernels, for example.
2011-08-10 03:55 <xiangfu> ignatius-,  different GCC/uClibc may make kernel can not boot to rootfs. something wrong with load 'init'.
2011-08-10 03:55 <ignatius-> Ah. I see.
2011-08-10 03:56 <ignatius-> Yes. VFS error. Unable to load init.
2011-08-10 03:56 <ignatius-> I remember seeing that before. Didn't make the connection.
2011-08-10 03:58 <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?
2011-08-10 03:58 <ignatius-> Er. s/compile/access
2011-08-10 04:01 <xiangfu> xiangfu, sorry the UBI rootfs is same. 
2011-08-10 04:06 <xiangfu> since your rootfs already used in a 512MB partitons then it will not working if you just modify the partition size.
2011-08-10 04:06 <xiangfu> you have to reflash it again.
2011-08-10 04:09 <wolfspraul> it's amazing how long a change in partition size is haunting us
2011-08-10 04:22 <wpwrak> yeah, such things need to be pushed, not offered for "pickup at your convenience"
2011-08-10 04:22 <wpwrak> there's also the problem of coordinating the distributions
2011-08-10 04:45 <wolfspraul> wpwrak: looking at the latest m1 rc3 test result http://en.qi-hardware.com/wiki/Milkymist_One_run_3_schedule#Test_Results
2011-08-10 04:46 <wolfspraul> there'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 cycle
2011-08-10 04:47 <wolfspraul> I 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.
2011-08-10 04:48 <wolfspraul> for example 0x34, 0x39
2011-08-10 04:48 <wpwrak> and what brings them back ?
2011-08-10 04:48 <wolfspraul> 0x3C
2011-08-10 04:48 <wolfspraul> right now when there's a problem Adam will mostly just stop with the board 'failed'
2011-08-10 04:49 <wolfspraul> later when we have data for all 90 we zoom in on any cluster of problems we can see
2011-08-10 04:49 <wolfspraul> but I think I can see that one already :-)
2011-08-10 04:49 <wolfspraul> a board that renders just fine, some once, twice, some 6 times, 9 times, and then suddenly cannot reconfigure anymore
2011-08-10 04:49 <wolfspraul> 'renders' means a full boot and render for 30 seconds without any noticable issues
2011-08-10 04:49 <wpwrak> "reconfigure" is just the boot, no reflashing, correct ? (i.e., only 34 of these three also has the reflashing problem, correct ?)
2011-08-10 04:49 <wolfspraul> some of them then stay in this condition, others may come back the next day or several days late
2011-08-10 04:50 <wolfspraul> later
2011-08-10 04:50 <wpwrak> odd indeed :)
2011-08-10 04:50 <wolfspraul> read the notes
2011-08-10 04:50 <wolfspraul> then you see the sequence of steps on each board
2011-08-10 04:50 <wolfspraul> yes it could be related to flash
2011-08-10 04:50 <wolfspraul> it could be related to fix2
2011-08-10 04:50 <wolfspraul> it could be related to tolerances of the diode or capacitors we added
2011-08-10 04:51 <wolfspraul> it could be related to something we could fix in software (bitstream), depending on where exactly in the 'reconfigure fails' it stops
2011-08-10 04:51 <wpwrak> how hard is it to read back the flash via jtag ?
2011-08-10 04:51 <wolfspraul> should be easy, we can try
2011-08-10 04:51 <wpwrak> i've heard that it is possible but slow. how slow ? :)
2011-08-10 04:51 <wolfspraul> I don't know though, just guessing
2011-08-10 04:52 <wpwrak> reading back the flash would eliminate mere flash corruption as an issue
2011-08-10 04:52 <wpwrak> well, unless it _is_ flash corruption ;-)
2011-08-10 04:52 <wpwrak> in which case you'd have identified the disease :)
2011-08-10 04:53 <wolfspraul> you mean the initial flashing is faulty?
2011-08-10 04:53 <wolfspraul> that is impossible now since we do crc checks, and also those are all boards that first rendered fine
2011-08-10 04:54 <wolfspraul> and then after X power cycles, they stop reconfiguring
2011-08-10 04:54 <wpwrak> you could still get later flash corruption for some reason
2011-08-10 04:54 <wolfspraul> oh yes, we should definitely read back and compare
2011-08-10 04:55 <wolfspraul> if the data has changed, what could be the cause?
2011-08-10 04:55 <wpwrak> now you're asking the tricky questions ;-)
2011-08-10 04:55 <wpwrak> could be some more unexpected behaviour of the reset circuit
2011-08-10 04:56 <wpwrak> or maybe it's something else. for all we know, it could be the FPGA sending some junk
2011-08-10 04:57 <wolfspraul> let's see what lekernel says later. I feel somewhat uneasy about those failure cases.
2011-08-10 04:57 <wpwrak> as 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 boot
2011-08-10 04:57 <wolfspraul> because 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...
2011-08-10 04:58 <wpwrak> yeah, 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 ;-)
2011-08-10 04:58 <wolfspraul> ah no, I don't see it that way
2011-08-10 04:58 <wolfspraul> rc1 had a whole number of major issues, expectedly
2011-08-10 04:59 <wpwrak> okay. if an rc1 is flawless, you're cheating ;-)
2011-08-10 04:59 <wolfspraul> rc2 was 40 boards, and I helped Adam testing for several days, so I know white well what I saw
2011-08-10 04:59 <wolfspraul> and we were nowhere near this kind of testing quality as we are with rc3
2011-08-10 04:59 <wolfspraul> if we had done that, we would have never shipped or sold a single rc2
2011-08-10 05:00 <wolfspraul> every single rc2 board has trouble booting
2011-08-10 05:00 <wpwrak> *grin*
2011-08-10 05:00 <wolfspraul> as 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.
2011-08-10 05:00 <wolfspraul> but that won't scale
2011-08-10 05:00 <wolfspraul> so we do need to get to the real root cause sooner or later
2011-08-10 05:01 <wolfspraul> the later the more expensive
2011-08-10 05:01 <wpwrak> are 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 ?
2011-08-10 05:01 <wolfspraul> the latter right now
2011-08-10 05:01 <wolfspraul> but soon we will dig in there
2011-08-10 05:02 <wpwrak> so it could be that just 1/N tests fail
2011-08-10 05:02 <wolfspraul> I doubt that
2011-08-10 05:02 <wolfspraul> there is firm evidence of 'memory'
2011-08-10 05:02 <wolfspraul> read the notes
2011-08-10 05:02 <wpwrak> it would be good to automate all those things. such that you can do, say, 100 or 1000 boot tests without adam actually pushing buttons
2011-08-10 05:02 <wolfspraul> 0x34 0x39 0x3c
2011-08-10 05:02 <wolfspraul> well
2011-08-10 05:03 <wolfspraul> Adam 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.
2011-08-10 05:03 <wolfspraul> so 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 more
2011-08-10 05:03 <wolfspraul> in which case I would rather do more testing before start selling
2011-08-10 05:03 <wolfspraul> for example increase to 20 cycles and do all boards again
2011-08-10 05:03 <wolfspraul> see whether more 'drop out'
2011-08-10 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 history
2011-08-10 05:04 <wolfspraul> I mean all boards that are 'available' right now
2011-08-10 05:04 <wolfspraul> notes column
2011-08-10 05:05 <wolfspraul> 0x34 is interesting
2011-08-10 05:05 <wolfspraul> if I understand the notes correctly it did flash, boot and render after replacing diode + c238
2011-08-10 05:05 <wpwrak> i don't see a "memory" anywhere. in the sense of a persistent state change of the system 
2011-08-10 05:05 <wolfspraul> and then it went back to failure mode again
2011-08-10 05:05 <wolfspraul> well
2011-08-10 05:05 <wolfspraul> with 0x34 you see it very clear
2011-08-10 05:05 <wolfspraul> that's why Adam had to resort to trying diode/c238 replacements
2011-08-10 05:05 <wolfspraul> because there was no other way to kick it back alive
2011-08-10 05:06 <wolfspraul> let me look at 0x39 and 0x3C
2011-08-10 05:06 <wpwrak> 0x34 also has the reflashing issue. is this also with the short cable ?
2011-08-10 05:06 <wolfspraul> yes those two no memory yet, just testing stop for now
2011-08-10 05:06 <wolfspraul> I am sure Adam is 100% on the short cable now
2011-08-10 05:06 <wolfspraul> no need to add more uncertainty
2011-08-10 05:07 <wolfspraul> as soon as we have identified _any_ improvement, we'll go for that
2011-08-10 05:07 <wpwrak> in other words, the short cable doens't always make the problem go away
2011-08-10 05:07 <wolfspraul> there may be multiple problems
2011-08-10 05:07 <wolfspraul> and the analysis of that short vs. long theory was also lacking
2011-08-10 05:07 <wpwrak> can you downgrade to full-speed usb ?
2011-08-10 05:07 <wolfspraul> it was an empirical decision
2011-08-10 05:07 <wolfspraul> I don't think it's a flashing issue, because once the crc test passes, we can assume everything was written correctly.
2011-08-10 05:07 <wolfspraul> so why doubt that?
2011-08-10 05:08 <wpwrak> you probably have impedance issues in the USB signals. high-speed is hairy
2011-08-10 05:08 <wpwrak> no, board 34 ends with: 10. stopped at 'Bitstream length: 1484404' while reflashing
2011-08-10 05:08 <wolfspraul> when 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 then
2011-08-10 05:08 <wolfspraul> yes now it does
2011-08-10 05:09 <wpwrak> so this is with the short cable ?
2011-08-10 05:09 <wolfspraul> but under 7. it rendered
2011-08-10 05:09 <wolfspraul> that's my point
2011-08-10 05:09 <wolfspraul> how can I board that boots and renders fall back (!) to an unreconfigurable state
2011-08-10 05:09 <wpwrak> no no ... different issue :)
2011-08-10 05:09 <wolfspraul> and yes, now it cannot be reflashed anymore
2011-08-10 05:09 <wolfspraul> but before it could be flashed
2011-08-10 05:09 <wpwrak> the "10. stopped at 'Bitstream length: 1484404' while reflashing" is also what you got when the cable was too long, correct ?
2011-08-10 05:10 <wolfspraul> don't know
2011-08-10 05:10 <wolfspraul> there are several boards in this state, but I believe all/most of them rendered before
2011-08-10 05:10 <wolfspraul> checking
2011-08-10 05:12 <wolfspraul> long cable issue was "d2/d3 dimly lit after flashing"
2011-08-10 05:13 <wpwrak> i 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 step
2011-08-10 05:13 <wolfspraul> my concern now is on boards that rendered just fine, and then without any hw action, REGRESSED to unreconfigurable state
2011-08-10 05:13 <wpwrak> this 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.
2011-08-10 05:14 <wolfspraul> 'download' you mean write the flash or read the flash?
2011-08-10 05:14 <wolfspraul> read multiple times? or write multiple times?
2011-08-10 05:15 <wpwrak> now, 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 else
2011-08-10 05:16 <wpwrak> download = read from NOR to USB/PC via JTAG
2011-08-10 05:17 <wolfspraul> yes sounds good, we'll prepare that
2011-08-10 05:17 <wolfspraul> for now Adam will go through the entire lot with another whole round of testing
2011-08-10 05:17 <wpwrak> oh, 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.
2011-08-10 05:17 <wolfspraul> I highly doubt we are looking at usb issues here
2011-08-10 05:17 <wolfspraul> if 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 study
2011-08-10 05:18 <wolfspraul> the issue is a running board (renders fine), that suddenly regresses to a nonconfigurable board
2011-08-10 05:18 <wpwrak> ph 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 predictable
2011-08-10 05:18 <wolfspraul> how can that be related to any usb issue?
2011-08-10 05:18 <wpwrak> s/ph/oh/
2011-08-10 05:19 <wolfspraul> I agree, but that's a completely different problem, and doesn't block much right now.
2011-08-10 05:19 <wolfspraul> what blocks a lot is boards that render fine and then fall back.
2011-08-10 05:19 <wpwrak> the problem with the usb issue is taht it may cause jtag-download to be corrupted. errors CAN get past the USB CRC.
2011-08-10 05:19 <wolfspraul> that may mean none of the boards that pass can be sold, until we find the root cause
2011-08-10 05:19 <wolfspraul> how can that lead to a board first rendering fine, and then failing on the xth power cycle
2011-08-10 05:20 <wpwrak> no no. that's not what i'm saying
2011-08-10 05:20 <wpwrak> what 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.
2011-08-10 05:20 <wolfspraul> even 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 back
2011-08-10 05:21 <wolfspraul> anyway I agree on your download multiple times and md5sum etc.
2011-08-10 05:21 <wolfspraul> that will give us some visibility into the lower levels
2011-08-10 05:22 <wolfspraul> but the really interesting thing happens somewhere between 2 power cycles
2011-08-10 05:22 <wpwrak> and 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)
2011-08-10 05:22 <wolfspraul> where the first one ends in a board that renders, and the next one ends in a board that won't reconfigure
2011-08-10 05:22 <wolfspraul> what happens in between?
2011-08-10 05:22 <wpwrak> well, does anything happen in between ? :) we don't know this yet
2011-08-10 05:22 <wpwrak> it could be a memory-less effect
2011-08-10 05:23 <wpwrak> 20% chance of failure on boards X, Y, and Z
2011-08-10 05:23 <wolfspraul> hah, there is Adam :-)
2011-08-10 05:23 <wolfspraul> aw: how's testing going?
2011-08-10 05:24 <wolfspraul> wpwrak: 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.
2011-08-10 05:24 <wpwrak> something 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 seeing
2011-08-10 05:25 <wpwrak> a "switch" would be nice. easier to debug :)
2011-08-10 05:25 <wolfspraul> my most pressing problem is to decide whether the boards labeled 'available' currently can be sold or not
2011-08-10 05:25 <wolfspraul> aw: I am wondering about 0x39 and 0x3C...
2011-08-10 05:26 <aw> don't know yet why 
2011-08-10 05:27 <aw> continuing to finish previous vga/midi/usb failures firstly..;-) my hands is not pipeline. :)
2011-08-10 05:28 <aw> will beck to see. :)
2011-08-10 05:28 <wpwrak> aw: you need more caffeine pills ;-)
2011-08-10 05:30 <wpwrak> wolfspraul: it's a pity that only adam can do testing. there's the risk of tunnel vision and other systematic errors in this. 
2011-08-10 05:30 <wpwrak> wolfspraul: (besides the sheer workload, of course)
2011-08-10 05:30 <wolfspraul> true but unfixable
2011-08-10 05:30 <wolfspraul> there's a lot of risks
2011-08-10 05:30 <wolfspraul> we should already run rc4 with 160 units in parallel
2011-08-10 05:31 <wolfspraul> throw a lot more resources at it, take a lot more risks
2011-08-10 05:31 <wolfspraul> develop Milkymist Two in parallel
2011-08-10 05:31 <wolfspraul> an so on
2011-08-10 05:31 <wolfspraul> a lot of 'should'
2011-08-10 05:31 <wpwrak> (unfixable) yeah, possibly. lekernel didn't want to do a little trip to taipei ? :)
2011-08-10 05:31 <wolfspraul> Sebastien would need a few helping hands on the IC design as well, ahh. not 'would', but 'should'
2011-08-10 05:31 <wolfspraul> good idea, never thought about it
2011-08-10 05:32 <wolfspraul> Sebastien could surely learn some manufacturing patience, if he would be able to handle it :-)
2011-08-10 05:32 <wolfspraul> you are fatalistic enough that no matter what happens, you stay calm
2011-08-10 05:32 <wolfspraul> he he
2011-08-10 05: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.
2011-08-10 05:33 <wolfspraul> such 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 it
2011-08-10 05:33 <wolfspraul> rc3 is already far better than rc2, as a product. the downside is that as we raise the testing level, more unpleasant surprises are made.
2011-08-10 05:33 <wolfspraul> what at least for my part, I want that
2011-08-10 05:34 <wolfspraul> I have no illusions about my ability to sell boards one by one to people that shelf them, and so will never report back problems.
2011-08-10 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)
2011-08-10 05:34 <wolfspraul> incompetence or not, it's a very demanding mental challenge
2011-08-10 05:34 <wolfspraul> most software and 'design' people would run away
2011-08-10 05:34 <wpwrak> hehe :)
2011-08-10 05:35 <wolfspraul> it's frustrating to have to accept the randomess and seemingly unending stream of rare/unexpected/strange/should-not-be cases
2011-08-10 05:35 <wolfspraul> makes you feel a small little nobody in the big wide universe
2011-08-10 05:35 <wolfspraul> so much better to hack on software, right?
2011-08-10 05:35 <wolfspraul> :-)
2011-08-10 05:35 <wolfspraul> anyway, good idea with the trip, but nobody had the idea before
2011-08-10 05:36 <wolfspraul> I'm not even sure it would have helped much, I think progress is just fine
2011-08-10 05: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"
2011-08-10 05:36 <wolfspraul> neither the acrylic cases nor the boxes/eva, labels and other print material has arrived in Taipei as of today
2011-08-10 05:37 <wpwrak> customs having a slow week ?
2011-08-10 05:37 <wolfspraul> no, all fine. moving.
2011-08-10 05:37 <wolfspraul> it's hardware
2011-08-10 05:37 <wolfspraul> doesn't travel at the speed of light
2011-08-10 05:37 <wpwrak> but i thought they're already at customs ?
2011-08-10 05:37 <wpwrak> and have been so for at least a day. maybe more ?
2011-08-10 05:37 <wolfspraul> yes, I don't know exactly which gps coordinate they are at at any given minute :-)
2011-08-10 05:37 <wolfspraul> A DAY!
2011-08-10 05:37 <wolfspraul> wow
2011-08-10 05:37 <wolfspraul> so many things can happen in a day, right?
2011-08-10 05:37 <wolfspraul> :-)
2011-08-10 05:38 <wolfspraul> Steve Jobs makes the entire iPhone in one single day.
2011-08-10 05:38 <wolfspraul> he gets up in the morning, and in the evening he shows his friends
2011-08-10 05:38 <wpwrak> well, i'm used to BUE customs sitting on stuff for a day and i hate every minute of it
2011-08-10 05:38 <wolfspraul> so let's see. Adam is making a full round of testing now.
2011-08-10 05:38 <wolfspraul> then we see new numbers
2011-08-10 05:39 <wpwrak> i thought he'd shit the next iMarvel right after breakfast. didn't realize it took him a whole day ;-)
2011-08-10 05:39 <wolfspraul> but I already have this suspicion there is more valuable stuff to discover
2011-08-10 05:39 <wolfspraul> if there were one board one time that went from rendering to unconfigurable, ok, i'd ignore it
2011-08-10 05:39 <wolfspraul> but it's several boards, and growing. too many.
2011-08-10 05:40 <wpwrak> can 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 analysis
2011-08-10 05:40 <wpwrak> (jtag dongle) well, at least the one adam will use for this
2011-08-10 05:40 <wolfspraul> I think we can short or otherwise disable the eeprom on the daughterboard
2011-08-10 05:40 <wolfspraul> that way it will fall back to full-speed
2011-08-10 05:40 <wolfspraul> something like that
2011-08-10 05:41 <wolfspraul> it's a bit difficult to enforce on the Linux side, afaik
2011-08-10 05:41 <wolfspraul> missing feature
2011-08-10 05:41 <wolfspraul> can't just echo '0' into some sys file, afaik
2011-08-10 05:41 <wpwrak> you had them do only full-speed in the past (by accident), was that an eeprom issue ?
2011-08-10 05:41 <wolfspraul> no
2011-08-10 05:41 <wolfspraul> but now that that bug is fixed, I believe shorting the eeprom will cause it to fall to full
2011-08-10 05:42 <wolfspraul> I don't know how to force it on the Linux side, you tell me
2011-08-10 05:42 <wolfspraul> I looked once, couldn't find anything
2011-08-10 05:42 <wpwrak> okay. may be worth trying then
2011-08-10 05:42 <wpwrak> (linux side) dunno either. use a old full-speed-only hub ? ;-)
2011-08-10 05:52 <wpwrak> linux 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-speed
2011-08-10 05:52 <wpwrak> now, let's see how this works ...
2011-08-10 05:55 <wpwrak> hmm. you need to know the PCI ID of you EHCI. how convenient. let's see if there's a link somewhere deeper in sysfs ...
2011-08-10 06:17 <larsc> well you could go by the driver node
2011-08-10 06:23 <wpwrak> larsc: the only path that seems to lead anywhere is via class/usbmon/. a little odd.
2011-08-10 06:26 <wpwrak> ah, there's the usb bus also in the pci hierarchy. let's see if this helps
2011-08-10 06:26 <larsc> wpwrak: /sys/bus/usb/devices/usbX
2011-08-10 06:27 <larsc> hmpf! were did my coffe go?
2011-08-10 06:29 <wpwrak> yes ... okay, with .. i can get to proper the PCI hierarchy. how, where's the companion file again ...
2011-08-10 06:30 <wpwrak> hehe, bus/usb/drivers/usb/usb1/../companion
2011-08-10 06:30 <wpwrak> well, maybe. that only works for two EHCIs. the others have weirder paths.
2011-08-10 06:34 <wpwrak> yes ! :)
2011-08-10 06:34 <wpwrak> okay, here is how it works:
2011-08-10 06:35 <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"
2011-08-10 06:36 <wpwrak> - that's usb-$BUS-$PORT. you remember these values
2011-08-10 06:36 <wpwrak> - then, echo $PORT >/sys/bus/usb/drivers/usb/usb$BUS/../companion
2011-08-10 06:37 <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"
2011-08-10 06:38 <wpwrak> in the example above, the command would have been: echo 1 >/sys/bus/usb/drivers/usb/usb2/../companion
2011-08-10 06:38 <wpwrak> as usual, mind the space between 1 and > ;-)
2011-08-10 06:40 <wpwrak> this 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)
2011-08-10 06:41 <wpwrak> to return the port to high-speed,
2011-08-10 06:42 <wpwrak> echo -$PORT >/sys/bus/usb/drivers/usb/usb$BUS/../companion
2011-08-10 06:42 <wpwrak> e.g., echo -1 >/sys/bus/usb/drivers/usb/usb2/../companion
2011-08-10 07:16 <blackrose> M}KM0†openmokoK:ˆœ"FåS‚U-p÷î‚Uý-p
2011-08-10 07:18 <blackrose> ÷îý…V„
2011-08-10 07:20 <kyak> heh, good to know my irc client/terminal is fine displaying Chinese or whatever that is :)
2011-08-10 07:21 <larsc> i only see lots of blocks with numbers
2011-08-10 07:22 <blackrose> @kyak,i want buy a openmoko
2011-08-10 07:22 <blackrose> where i can buy it ?
2011-08-10 07:23 <xiangfu> blackrose, taobao.com search freerunner or Ben nanonote :)
2011-08-10 07:23 <xiangfu> blackrose, (I assume you are in China)
2011-08-10 07:24 <blackrose> xiangfu,thank you.yes ,i come from china.
2011-08-10 07:24 <xiangfu> blackrose, checkout this: http://item.taobao.com/item.htm?id=9697106676
2011-08-10 07:26 <blackrose> thanks, i saw "Qi-Hardware" on other website
2011-08-10 07:26 <xiangfu> blackrose, cool. welcome to join #qi-hardware
2011-08-10 07:27 <blackrose> thanks!
2011-08-10 07:28 <xiangfu> blackrose, I recommend you buy ben nanonote instead freerunner .
2011-08-10 07:28 <blackrose> why ?
2011-08-10 07:29 <xiangfu> blackrose, because we (45 people here) support Ben nanonote. answer All nanonote questions.
2011-08-10 07:29 <xiangfu> why you want buy freerunner?
2011-08-10 07:29 <blackrose> can you give me a website?
2011-08-10 07:30 <blackrose> Now, i learn embedded system programming, so i want to buy it play.
2011-08-10 07:32 <xiangfu> blackrose, wow then nanonote is the right device
2011-08-10 07:32 <xiangfu> blackrose, http://en.qi-hardware.com/wiki/Applications
2011-08-10 07:33 <xiangfu> blackrose, http://en.qi-hardware.com and http://en.qi-hardware.com/wiki/Ben_NanoNote, 
2011-08-10 07:33 <xiangfu> blackrose, you can find the device in taobao.com also.
2011-08-10 07:34 <xiangfu> blackrose, all source code here: http://projects.qi-hardware.com/
2011-08-10 07:35 <blackrose> thanks. all source? Is include bootloader and kernel?
2011-08-10 07:35 <xiangfu> blackrose, yes. include them
2011-08-10 07:35 <blackrose> i can read it later
2011-08-10 07:35 <xiangfu> blackrose, most is under : http://projects.qi-hardware.com/index.php/p/openwrt-xburst/
2011-08-10 07:38 <blackrose> where is hardware's info of Ben nanonote?
2011-08-10 07:39 <xiangfu> blackrose, http://en.qi-hardware.com/wiki/Ben_NanoNote ,there is "Hardware / Flashing " at bottom
2011-08-10 07:40 <blackrose> see it.
2011-08-10 10:09 <`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 zigbee
2011-08-10 10:09 <`antonio`> http://pastebin.com/7tYJGRJ6
2011-08-10 12: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)
2011-08-10 13:30 <`antonio`> wpwrak, do you have any image I can flash with the dirtpan modifications? 
2011-08-10 13:32 <wpwrak> i don't have a full system image. but i can make and upload kernel and tools binaries. lemme check what i have ...
2011-08-10 13:34 <`antonio`> wpwrak, that would be great 
2011-08-10 13:39 <wpwrak> but 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 ...
2011-08-10 13:47 <wpwrak> `antonio`: http://downloads.qi-hardware.com/people/werner/wpan/bintmp/
2011-08-10 13:47 <wpwrak> extract wpan-binaries.tar.gz into / then run /sbin/ldconfig
2011-08-10 13:48 <wpwrak> for the kernel, bunzip it, scp the uImage to the ben, then
2011-08-10 13:48 <wpwrak> flash_eraseall /dev/mtd1 && nandwrite -p /dev/mtd1 uImage
2011-08-10 13:49 <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 ;-)
2011-08-10 14:00 <`antonio`> wpwrak, thanks i'll let you know how that goes
2011-08-10 14:01 <wpwrak> `antonio`: do you have 2 atbens or atben to atusb ?
2011-08-10 14:02 <`antonio`> wpwrak, yes i have 2 atbens
2011-08-10 14:03 <wpwrak> great. then you don't have to worry about the PC kernel :)
2011-08-10 14:45 <`antonio`> wpwrak, thank you ! we got it working !
2011-08-10 14:56 <wpwrak> `antonio`: whee ! welcome "on the air" ! ;-)
2011-08-10 15:23 <wpwrak> hmm, 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 ?
2011-08-10 16:52 <kristianpaul> wolfspraul: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?
2011-08-10 16:57 <wolfspraul> ah no worries, we'll all work in parallel
2011-08-10 16:57 <wolfspraul> everybody cranking here ;-)
2011-08-10 18:03 <kristianpaul> hum, afaik stillmissing vga feedback for remote operation :(
2011-08-10 18:04 <kristianpaul> wpwrak:(Fnord) a good excuse to go to cccamp? :)
2011-08-10 18:15 <kristianpaul> http://events.ccc.de/camp/2011/Fahrplan/events/4575.en.html
2011-08-10 18:15 <kristianpaul> thats a nice excuse to go :)
2011-08-10 18:44 <wpwrak> wolfspraul: be quick if you want to use "libre". they're starting to erode that as well: http://www.alibre.com/
2011-08-10 18:50 <kristianpaul> oh, the bitsfrombytes guys, really nice printers.. afaik no so libre latelly :(
2011-08-10 21:42 <qi-bot> The build has FAILED, see log here: http://fidelio.qi-hardware.com/~xiangfu/compile-log/openwrt-xburst.full_system-08092011-1953/