<qi-bot> [commit] Ayla: Read config file(s) present on both system and user-specific directories. (master) http://qi-hw.com/p/gmenu2x/3d3e0fa
<qi-bot> [commit] Ayla: Set card root to /media by default for the Dingux port. (master) http://qi-hw.com/p/gmenu2x/4fd4b23
<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 ?
<kristianpaul> arghh
<aw> 0x66 test histories: 1. usb – A without reply, replaced a new U16 then pass(with CRC check) 2. tested CRC failed after replaced u7/u19/u20. 3. reflashed again successfully, http://downloads.qi-hardware.com/hardware/milkymist_one/production/rc3/test_results/66-reflash-results-1 4. tested successfully
<aw> interesting on 0x66. ;-)
<aw> the image CRC has failed in 'Checking : flickernoise.fbi(rescue)(CRC)CRC failed (expected aa12a56a, got 92968609)'
<wpwrak> aw: (0x66) did you reflash after replacing u7/u19/u20 ? or was that the same flash content that worked before (and then failed) ?
<aw> wpwrak, after replacing u7/u19/u20, i tested then got CRC failed. so I then reflashed it again and show without CRC err.
<aw> wpwrak, before replacing u7/u19/u20, I still used test image with CRC checking, and no err; at that time I tested a new U16 usb transceiver.
<aw> wpwrak, good now I just got 0x64 with CRC err. at 'Checking : standby.fpgCRC failed (expected c58e8905, got ac858cbf)'
<wolfspraul> aw: hey :-) how is the testing going?
<aw> new condition on CRC err I met on 0x66, you can see the logs
<aw> now I just got 0x64 with standby CRC failed....;-)
<aw> this log was done by last first round by shorter cable
<wolfspraul> did you upload the latest testing results?
<wolfspraul> I am most interested in one category of boards: those that performed rendering fine, but then after X power cycles, stopped rendering
<wolfspraul> do we have such cases?
<aw> now I was going to test it after replacing u/7u/19/u20, then got CRC err with new test image
<aw> wolfspraul, not yet updated this 0x64 test log
<aw> now going to reflash it again.
<wolfspraul> aw: 31 boards 'available' now
<wolfspraul> hmm
<wolfspraul> I mean cases like 0x6B
<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'
<wpwrak> http://en.qi-hardware.com/wiki/Milkymist_One_Power_On_Off_Sequence#cite_note-5   (the link to the NOR data sheet) doesn't work :-(
<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> aw, I can reproduce your bug: -0000a80 0000 26cc 0000 0000 0000 0000 440c 6000
<xiangfu> +0000a80 1000 26cc 0000 0000 0000 0000 440c 6000
<xiangfu> I tried 7 times then it can not boot up. then I use jtag read the standby back.
<xiangfu> diff with origin one. I got one diff:
<xiangfu> -0000a80 0000 26cc 0000 0000 0000 0000 440c 6000
<xiangfu> +0000a80 1000 26cc 0000 0000 0000 0000 440c 6000
<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
<qi-bot> [commit] Werner Almesberger: schhist/README: fixed typo (by Holger Freyther) (master) http://qi-hw.com/p/eda-tools/487e0e6
<bartbes> so this 'new' mediatomb, does it play back from upnp too?
<bartbes> is there a reason guile is at version 1.8.x, instead of 2.0.x?
<xiangfu> bartbes, no. just no one upgrade the makefile and test
<bartbes> which is why I'm redownloading the sdk and stuff
<bartbes> here's hoping libffi has already been ported
<bartbes> (I checked, it does run on MIPS)
<bartbes> xiangfu: also, do you know who have access to the repo management, I kind of forgot my login details
<xiangfu> bartbes, (libffi) just checked:Search results in feed 'packages':
<xiangfu> libffi                   Foreign Function Interface (FFI) library
<xiangfu> libffi-sable             Foreign Function Interface library (for sablevm)
<bartbes> or well, it is not accepting the password in my password manager
<bartbes> ah, cool, thanks
<xiangfu> bartbes, what is your name?
<bartbes> real name or account name?
<xiangfu> account name.
<bartbes> bartbes, afaik
<xiangfu> ok. I will try to reset your password on projects.qi-hardware.com
<bartbes> thanks
<bartbes> (again)
<bartbes> any interest in a minimal config around
<bartbes> (I disabled everything)
<wolfspraul> definitely
<wolfspraul> there is one btw, we can compare with yours
<wolfspraul> there should be a config.minimal somewhere
<bartbes> it's just there to provide me with an sdk for the time being, next I will enable guile, build it and start working on updating it
<bartbes> here's hoping I can get guile 2.0.2 on
<wolfspraul> yes, that's great!
<bartbes> ffi ftw
<bartbes> I heard libffi is already on there, so it can't be too hard
<bartbes> but I can't count on it being easy :P
<bartbes> wolfspraul: so why is that old 'btr' script not in the image?
<bartbes> (the battery checking one)
<wolfspraul> no reason
<wolfspraul> which package was it in before? if it fell through the cracks, we need to add it back
<bartbes> that's one hell of a reason
<bartbes> it never was in one, it was on the wiki
<wolfspraul> oh you mean it should have been packaged
<wolfspraul> nobody got to it yet
<wpwrak> DocScrutinizer2: how do you like the N9 global release plan ? seems like a random pick of countries ;-)
<kodein> I thought the MO was to fail hard enough at launching it that they can pull it off the shelves at the earliest possible convenience.
<wpwrak> yes, it does look a bit as if this was part of their plan ;-)
<kristianpaul> N9 is on my country, but too expensive 350usd for a  25usd internet plan
<kristianpaul> stay with his oldfashioned phone
<kodein> I have a newfashioned phone that isn't too old, so I won't get the N9 either.
<kodein> I might've considered it if it isn't an orphaned project even before launch :/
<bartbes> how are the patch files created again?
<bartbes> I can't remember what the diff arguments were..
<bartbes> hmm, -ruN looks sane
<bartbes> except it doesn't work
<bartbes> pokes wolfspraul
<Dubbles> hey
<Dubbles> anyone here?
<bartbes> yes
<Dubbles> can you help me with this laptop
<Dubbles> woops
<bartbes> wrong channel
<Dubbles> what is the right channel lol
<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)
<wpwrak> test bold normal
<wpwrak> kewl :) thanks !
<steve|m> 12,14nice
<wpwrak> what was that ? :)
<steve|m> "MIRC" colors
<wpwrak> ah, xchat only gets ^B through. ^- and ^V do other things
<steve|m> does ^_ or ^7 work?
<wpwrak> not with xchat
<wpwrak> they do nothing. ^_ produces the right code in an xterm, so it's not a keyboard/etc. problem
<bartbes> steve|m: there's underline and stuff when you right click on the input box
<bartbes> see
<bartbes> %UI am told this works too?%U
<bartbes> not really
<bartbes> :P
<bartbes> you probably have to set them somewhere
<steve|m> bartbes: I'm using irssi, so there's no right-click whatsoever :)
<bartbes> oh right, in irssi it's just ^7 yeah
<bartbes> it was meant for wpwrak, of course ;)
<wpwrak> bartbes: eeey, 12coolness ! thanks !
<bartbes> :)
<bartbes> so either of you know about the diff format the toolchain wants?
<wpwrak> bartbes: i think you need to set a trap for kyak :)
<bartbes> I expect xiangfu to know as well
<bartbes> since he made the previous patch
<bartbes> even better
<bartbes> I made one before..
<wpwrak> ah yes, xiangfu may show up even sooner
<wpwrak> ;-)
<bartbes> oh
<bartbes> I did it
<bartbes> wow
<bartbes> miracles came true
<bartbes> so it's not the format it choked on
<bartbes> but the filename
<bartbes> of course..
<wpwrak> it must be something after all :)
<bartbes> oh... boy
<bartbes> ehm, libunistring
<bartbes> let me guess, unported?
<bartbes> it takes hours to compile too (natively)
<bartbes> fun fun fun
<wpwrak> C++ ? :)
<bartbes> like the friday it's just become
<bartbes> a unicode library, that basically says it, doesn't it?
<LunaVorax_win> Evening everyone
<wpwrak> luddites like me shun unicode and C++, so yes, what would be an indication. (luddite(C++) == luddite(unicode)) ergo (unicode => C++)
<bartbes> no, it's c code
<mth> bartbes: maybe -p0 is the problem, for example buildroot assumes patches are made for -p1
<bartbes> mth: yeah, that was the problem
<bartbes> oh.. no..
<bartbes> not another libiconv problem!
<bartbes> how do I select the full iconv again?
<bartbes> tries libiconv-full
<bartbes> seems to be working
<bartbes> more compiling, yaaay
<LunaVorax_win> wpwrak: which software does QI use to make schematics ?
<bartbes> I have a feeling I needed to do something extra with libiconv-full..
<wpwrak> LunaVorax_win: we try to converge on kicad. i use kicad. m1 still used altium.
<LunaVorax_win> Ok, thanks :)
<LunaVorax_win> wpwrak: Altium via wine ?
<wpwrak> LunaVorax_win: no idea. i just read the PDF ;-)
<LunaVorax_win> ok :)