<aw>
rc3: regards to power-cycling of rendering failure, I am going to use 'replug the dc adapter male plug' not to switch power cord to see if secrets behind. ;-)
<xiangfu>
aw, :)
<aw>
rc3: just have that a little times of feeling on this without firm data, but worthy to see if difference existed.
<aw>
regards to great email from Werner about Full speed on usb host, I'll try that after my this round( get all vga/midi/usb done firstly). ;-)
<aw>
the method of input of power-cycling is dependent to rendering fail since just got @7th on 0x6b, before this board, I tested successfully 0x56, 0x5e.
<aw>
sorry that corrected last sentences is 'independent'
<rjeffries>
.
<rjeffries>
quote: "
<rjeffries>
A smartphone might involve as many as 250,000 (largely questionable) patent claims,"
<larsc>
so what do we learn from this? never try to build and distribute a smartphone
<rjeffries>
larsc i don't know the number of potential patents is mind-boggling
<kristianpaul>
larsc: not sell it with android i would think :)
<larsc>
kristianpaul: so you think those patents only apply to android?
<kristianpaul>
larsc: sure not, but i dont started the patent troll
<kristianpaul>
i'm new on this field, but i'm sure is not the first time apple/microft  acude to litigation when they feels their IP spectrum is not enought to control a "market"
<kristianpaul>
also if we want to ignore other not so know lawsuits related to smartphone (not that i know of, but i guess there are)
<kristianpaul>
so if we as a copyleft dont call that atention that lot well.. there is some safety
<kristianpaul>
like promoting milkmist is a gpu that can beat nvidia.. and such..
<kristianpaul>
imho
<kristianpaul>
fighting against wpa2/wifi and hostapd and posible ath5k driver issues :S ?
<aw>
I've not finished 2nd round tests about vga/midi/usb reworks, the 'available' qty should be a little more later.
<wolfspraul>
ok
<wolfspraul>
but I think there are boards that first rendered, and then stop reconfiguring
<aw>
for me, no idea to care cases about 0x6B while 2nd round tests. sorry..i just recorded first
<wolfspraul>
makes sense
<wolfspraul>
yes, finish the complete round first
<wolfspraul>
then we look at the numbers
<wpwrak>
aw: when you get a CRC error, do you always reflash ? or did you try a few times to see if the board will pass the CRC check without reflashing ?
<aw>
wpwrak, yes, now I just reflash it, not try few times to see if the board will pass.
<aw>
later if i found it again. i can try to do a few times to see if pass. ;-)
<wpwrak>
aw: yes, the next time you hit a CRC error, it would be good to try a few times. if the CRC error goes away (or changes), then it's a problem of the flash itself
<wpwrak>
aw: if the CRC error stays, then it's flash corruption
<aw>
wpwrak, seems understood from your analysis on either 'flash corruption' or 'flash itself', good. thanks. i missed a good chance to know a firm hard data we can get. :(
<wpwrak>
aw: it seems that the CRC error happens often enough that you'll have plenty more opportunities :)
<aw>
wpwrak, hope I meet it again, good also bad. ;-)
<wolfspraul>
looking at the results overall right now I think things are starting to look much better
<wolfspraul>
especially after Adam continues to fix the vga/midi/usb cases that are probably all fixable easily
<wpwrak>
wolfspraul: let's not praise the day before the CRC error :)
<wolfspraul>
then we are down to flash and render/reconfig issues, which may all end up with the same root cause
<wolfspraul>
oh there will be flash & render/reconfig issues, and they have to be resolved
<wolfspraul>
there are way too many boards now that start falling into non-reconfigurable mode after 2, 5, 9 etc. times rendering, which is totally unacceptable
<wolfspraul>
but Adam is right, first finish _all_ reworks around usb/midi/vga, then look at the data
<wolfspraul>
aw: did I understand your plan correctly?
<wpwrak>
i'd just oportunistically try to reproduce a CRC error when one occurs. beats finishing everything else and then having to spend days trying to reproduce the error, which will then of course hide
<aw>
wolfspraul, you did.
<wolfspraul>
aw: when you do the render cycle testing, how do you do the power cycling? do you just unplug the DC jack from the running system?
<wolfspraul>
or do you shutdown m1 with the menu in the gui?
<aw>
wolfspraul, before today, i always switched my power cord to disconnect the 110V AC, I doubted through this way this morning, so I unplugged the DC male jack instead, but still got 6B rendering failure.
<wolfspraul>
but in both cases we suddently withdraw current
<wolfspraul>
suddenly
<xiangfu>
DocScrutinizer2, I got the little usb grab device recording the video now.
<xiangfu>
wpwrak, ^
<wolfspraul>
should not be much difference from the board's perspective
<xiangfu>
the output  file format have "HIDVD" and "MPEG4" "DVD" "VCD" .... I have finish with "HIDVD" and "MPEG4"
<wolfspraul>
I am wondering whether the problem with boards going to unreconfigurable state also exists if you do the shutdown in the gui first, and only once it's powered down you unplug the cable...
<aw>
wolfspraul, i now don't think those two ways are related to rendering failure issue though. ;-)
<wpwrak>
disconnecting mains would cause a slow voltage drop. pulling DC is faster. dunno what "shutdown" does
<wolfspraul>
aw: ok, don't let my comment confuse you
<wolfspraul>
I was jsut thinking
<aw>
wpwrak, agreed you, so I just tried to use disconnecting dc jack this morning. but still got rendering err. though. ;-)
<wolfspraul>
maybe the corruption (if it is one) also happens because of how we shutdown, not because of how it starts
<aw>
wolfspraul, yes..sorry that guys I have to finish them firstly then chat if i found new different err or CRC again. :)
<wpwrak>
"no rendering" means that it reconfigures but doesn't boot into flickernoise ? or does it boot and then somehow fail later ?
<wolfspraul>
yes, finish everything first, including all usb/midi/vga fixes
<aw>
wpwrak, means 'can't reconfiguration from power-cycle' which is bad.
<wolfspraul>
I think they are all the same, one root cause
<aw>
even surely can't be boot up.
<wolfspraul>
which is good
<wolfspraul>
but needs to be fixed before we start selling :-)
<aw>
i go to test..
<wpwrak>
ah, so you're not even near rendering yet, but reconfiguration
<wpwrak>
wolfspraul: yes, sounds all like flash trouble
<xiangfu>
aw, hi  if can not boot up. if the reboot working
<xiangfu>
aw, like press the three buttons at same time?
<xiangfu>
aw, middle one is for powerup, press all three buttons is for reboot. I always use 'reboot' I found is faster and better then just 'power-up'
<aw>
xiangfu, no need do this I think....which is un-normal though. ;-)
<wpwrak>
good that i found the data sheet before and have the URL in my IRC log ;-)
<xiangfu>
aw, hmm..  maybe help for debug :)
<xiangfu>
aw, yes it's un-normal.
<wpwrak>
hmm. the NOR's Vcc(min) = 2.7 V. U24's -Vdet(min) is 2.577 V. so at least theoretically, the board could be at a voltage where the NOR is outside its range and the reset hasn't kicked in yet
<wpwrak>
a similar condition may exist for the FPGA
<wpwrak>
maybe U24 should use a higher threshold. e.g., nominally 3 V (corresponds to 2.94-3.06 V)
<wpwrak>
wolfspraul: btw, why do we have all the M1 hw discussions on #qi-hardware now ? trying not to disturb lekernel ? :)
<wolfspraul>
not on purpose, sure they can be on #milkymist as well
<xiangfu>
aw, I am try to [power cycle] --> [rending 30 seconds] --> [power cycle] in my m1. see if there is problem on my m1.
<aw>
xiangfu, yours is rc2 without reset ic and diode h/w patches which is rc3 we have now. ;-)
<xiangfu>
in that wiki page: Fig. 15 <-- when you press middle and right at same time it will boot to that screen.
<xiangfu>
the 0xa80, it should be '1' but now in my m1 it's '0'
<xiangfu>
now I reflash standby, test again.
<aw>
xiangfu, when you said 'can not boot up', please see LED 2 and LED3, are they dimly lit or fully off? we described a 'can't reconfigure' status is that LED 2(d2) and LED 3(d3) are dimly lit. if they are all fully off after powered-cycle, fpga finished reconfiguration.
<xiangfu>
aw, fully off here.
<aw>
xiangfu, different from mine rc3 here. but good that you found bug in rc2 you there.
<xiangfu>
aw, now I am try again. already three times.
<xiangfu>
aw, ok. I can not reproduce again. now I have tried 20 times.
<xiangfu>
Fig. 15, hold left and middle then press right will goto that screen. it's a test screen wait input from serial console
<bartbes>
one that is about general channel, but of which I don't know its name or location on the internet, perhaps.
<kristianpaul>
Dubbles: /j #hardware
<bartbes>
ooh, someone arrives
<bartbes>
kristianpaul: you don't happen to be able to answer my question, do you?
<kristianpaul>
bit busy right now, i'll check backlog as i get to home :)
<wpwrak>
bartbes: in what way does does  diff -ruN  fail to do what you expect of it ?
<bartbes>
in this way: can't find file to patch at input line 3
<bartbes>
it fails to apply with the toolchain ;)
<bartbes>
but when I used patch -p0 < patch it works
<bartbes>
*worked
<wpwrak>
hmm, maybe the "toolchain" (=?) assumes -p1 or such ?
<bartbes>
I just need to know how I can export compatible diffs
<bartbes>
I tried the diff --git mentioned in the diff I am replacing
<bartbes>
but.. it does not appear to be a feature of my diff
<bartbes>
(and it's no git repo)
<wpwrak>
seems to be mainly a question of what you consumer expects. so that's where you should look for the answer. i.e., the patch command, if there's one
<bartbes>
in the openwrt toolchain?
<bartbes>
last I checked my suicide wish wasn't that bad
<bartbes>
:P
<wpwrak>
nice .. how do you do bold ?
<bartbes>
^B
<bartbes>
on my client, anyway
<wpwrak>
hmm, i must say that i'm duly impressed with what Microchip have done with their USB PIGs. they seem to be about the only low-cost USB devices on the market that can handle low voltages (~2 V), e.g., for mixed USB and battery operation. oddly enough, even companies that have MCUs with very decent low-voltage performance, like Atmel, don't manage to combine that with USB (i.e., their USB devices want 2.7 V or even more)