<cde> hi there
<wolfspraul> cde: hi!
<wolfspraul> so..
<wolfspraul> so basically say nothing works, right?
<wolfspraul> your jtag-serial board doesn't show up at all over usb, your m1 doesn't boot
<wolfspraul> at least we start from a place where things can only improve :-)
<cde> well leds blink, so that's at least something ;)
<wolfspraul> but what now? I don't know
<wolfspraul> the unit was 100% tested before shipping out, very extensively actually
<wolfspraul> but now, hmm, don't know
<cde> yes, I believe you
<wolfspraul> leds blink is not enough
<wolfspraul> why does the jtag-serial not register over usb?
<wolfspraul> totally nothing coming in over usb?
<wolfspraul> how is that possible
<cde> I dont think it was damaged in transit
<wolfspraul> we never had that, ever
<cde> nope, nothing :(
<wolfspraul> the USB power works I guess (led on jtag-serial comes on?), but the ftdi chip doesn't start sending stuff over usb?
<GitHub163> [scripts] xiangfu pushed 1 new commit to master: http://git.io/K633PA
<GitHub163> [scripts/master] scripts: ignore build when no new commit - Xiangfu Liu
<cde> well Linux detects no device at all
<wolfspraul> _anything_ in dmesg?
<cde> nothing
<wolfspraul> I'm at a loss
<wolfspraul> we never had a case like this
<wolfspraul> since the first prototype of the jtag-serial boards
<cde> I'm thinking ESD
<wolfspraul> well
<wolfspraul> your m1 seems also dead?
<cde> possibly, but I really have no tools to diagnose it
<xiangfu> cde, 1. replug the jtag-serial to your pc. 2. check 'dmesg'
<wolfspraul> something pretty drastic must have happened somewhere
<wolfspraul> xiangfu: nah, he checked a lot already
<xiangfu> oh.
<cde> xiangfu: I did that countless times
<wolfspraul> when you power-on your m1, which LED of the three leds on m1 comes on?
<wolfspraul> I mean when you plug in the power supply
<cde> the one on the most left iirc
<wolfspraul> watch out to only plug the 5V supply into m1 :-)
<wolfspraul> is it possible that you plugged in the 12V supply at some point?
<xiangfu> cde, left?
<wolfspraul> there is protection against that, but just curious/asking
<wolfspraul> cde: ok, and then when you press the middle button, what happens?
<wolfspraul> xiangfu: after m1 boots, what is the ethernet IP of m1 ?
<cde> nope, was vey careful to use the M1 brick
<wolfspraul> no worries it has protection against accidentally plugging in 12V, though you shouldn't try that just for fun...
<cde> hmm, iirc middle led turns on
<wolfspraul> and then after 30-40 seconds the third one comes on?
<cde> then after awhile right led
<xiangfu> wolfspraul, it try to get from DHCP
<wolfspraul> ok
<wolfspraul> cde: but nothing on vga?
<cde> nope
<wolfspraul> what do you connect the vga to?
<cde> unless the tv somehow didn't see the signal
<wolfspraul> tv?
<wolfspraul> the tv has a vga in?
<wolfspraul> yes that is (remotely) possible
<wolfspraul> I've heard a story before (from kristianpaul) who said he plugged m1 into something (vga) but it didn't work (on that particular projector or whatever it was)
<cde> yep my brother uses it to plug in an media center
<wolfspraul> xiangfu: if dhcp fails, what's the fallback IP?
<wolfspraul> cde: and that worked?
<xiangfu> wolfspraul, then no IP address
<wolfspraul> that was in France?
<wolfspraul> xiangfu: it should fall back to a fixed ip
<wolfspraul> for diagnostics
<wolfspraul> otherwise for example cde cannot just connect it to his hotebook now to try to log on. or can he?
<cde> well to be franck I didn't test my m! until today
<cde> (my brother lives in NY)
<wolfspraul> I can tell
<wolfspraul> but last minute is most fun :-)
<wolfspraul> no?
<wolfspraul> last minute is when we get all the important things done, and make the important realizations (like no static IP fallback, he he :-))
<cde> well it must be disappointing for lekernel
<wolfspraul> cde: so you saw the vga output working?
<wolfspraul> why disappointing?
<wolfspraul> and what?
<cde> no
<wolfspraul> you just wrote 'my brother uses it to plug in an media center' - I don't understand
<cde> well since I had to do a working demo :)
<wolfspraul> if the TV doesn't pickup the signal, first we should try one other monitor or projector
<cde> however let me just try the M! on another screen
<wolfspraul> did you have the demo already?
<wolfspraul> or you say the demo failed because m1 didn't work?
<cde> it's happening tomorrow at the OHS
<wolfspraul> ok do you have another screen to test vga now?
<wolfspraul> I guess you cannot log in over Ethernet unless you find something that responds to DHCP
<wolfspraul> xiangfu: ?
<wolfspraul> how can he do that?
<wolfspraul> from the LED action, it looks like m1 is booting
<cde> sure 10mn
<wolfspraul> at least that :-)
<wolfspraul> so:
<wolfspraul> 1) jtag-serial seems 'dead', quite strange
<xiangfu> wolfspraul, (DHCP) that is true.
<wolfspraul> 2) Ethernet is inaccessible because no static IP fallback and no DHCP partner available right now
<wolfspraul> 3) vga-out does not work with the TV, looking for another screen
<xiangfu> cde, we can try to reflash your jtag-serial, only if you make sure it is dead for now
<cde> hmm wait this network has dhcp
<wolfspraul> but then how do you know the address?
<cde> oh I can nmap the range
<xiangfu> cde, even m1 have success get ip address, you have to setup the Username and Password under Flickernoise.
<wolfspraul> :-)
<cde> brb
<xiangfu> which mean the VGA have  to works.
<wolfspraul> xiangfu: please think about a way to get access over ethernet without vga or keyboard
<xiangfu> cde, there are FTP and Telnet service in m1.
<wolfspraul> there should be a static IP fallback, that's easy
<wolfspraul> and there should be some way to setup username/password over ethernet? we need to think about it
<wolfspraul> xiangfu: reflash jtag-serial is a good idea, but how? is it easy for cde now?
<wolfspraul> I doubt this will help though, something bad must have happened
<wolfspraul> reflash will only touch the eeprom with some config data, but his jtag-serial seems totally dead, like the ftdi chip not doing anything
<xiangfu> cde, which release you using?
<xiangfu> cde, have you ever reflash your m1 ?
<xiangfu> cde, the old image have static ip address. 192.168.0.42
<cde> so vga just worked!
<cde> it was indeed the tv, I think the M!
<cde> 1 is fine
<wolfspraul> xiangfu: he just received a brand new rc3
<wolfspraul> ok, m1 works. that's good.
<wolfspraul> jtag-serial, hmm
<cde> about the ftdi, it's not a big deal I has a couple at home that I don't use
<wolfspraul> well
<xiangfu> cde, m1 is stable :-)
<wolfspraul> cde: I will mail you a replacement, free of course
<wolfspraul> but that's not in time for the ohs
<wolfspraul> as for returning the one you have, it's probably not worth it
<cde> np, at least the demo is showing
<wolfspraul> you can do a bit more investigation yourself if you like, that would tremendously help our project
<wolfspraul> you are at least as good or better than the people and resources we have, expect no magic on my end :-)
<cde> hmm with my 10mhz scope I might not be of much help ;)
<wolfspraul> it's up to you of course. most likely if you return it though, it will just be discarded because I don't have enough resources to do a deep analysis.
<wolfspraul> it is a strange finding though, totally no response
<wolfspraul> let's see what others say later
<wolfspraul> xiangfu: I cannot imagine that reflashing the eeprom on jtag-serial helps at all
<wolfspraul> the ftdi chip is not doing anything it seems
<wolfspraul> cde can try to short the eeprom to rule it out as a source of the problem
<cde> sure, i'll return it just in case so you can have a look
<wolfspraul> no need
<wolfspraul> I have no resources
<wolfspraul> so you just waste time and money returning it
<xiangfu> wolfspraul, seems ftdi chip totally dead.
<wolfspraul> cde could try to short the eeprom
<cde> ok I'll try flashing the eeprom
<wolfspraul> sure you can try :-)
<wolfspraul> thanks!
<wolfspraul> shorting the eeprom also, I just forgot how to do it
<wolfspraul> searching backlog...
<wolfspraul> you just have to short something on the little thing
<wolfspraul> please keep it disconnected from m1 for now
<xiangfu> put the pin 1 of the eeprom to the ground
<wolfspraul> ah
<wolfspraul> xiangfu: thanks!
<wolfspraul> cde: so you can try that. pin 1 of eeprom to ground, then connect usb
<wolfspraul> but please DISCONNECTED from m1
<cde> yeah got it :)
<wolfspraul> maybe someone at ohs has a usb protocol analyzer
<wolfspraul> you could see whether anything goes over the wire
<wolfspraul> at some point there is nothing but the ftdi chip in the way. if you indeed have the same one and can rework it - go ahead just for fun to see whether you can fix it :-)
<wolfspraul> but it's a qfn I think, right? a bit hard to rework
<wolfspraul> I'll send you a new daughterboard for sure (unless it somehow comes back to life now)
<cde> yeah I'll ask around at ohs! thanks very much guys for the help
<wolfspraul> wait, try short eeprom
<wolfspraul> I'm curious
<wolfspraul> we never had a case like this, want to understand
<wolfspraul> it's a simple board
<wolfspraul> power comes on - why is the ftdi chip unresponsive?
<wolfspraul> and what happened after shipping it out? total mystery to me...
<cde> ah don't have the equipment here :) will try it when back in france
<wolfspraul> esd? looks like an easy excuse
<wolfspraul> can you short the eeprom now to try?
<wolfspraul> for the m1 demo, you can iterate over the patches by pressing the right button I think (or the left one)
<wolfspraul> that will switch to the next patch
<wolfspraul> some patches use the camera, so you may want to connect the camera as well
<cde> ah good to know thanks :)
<xiangfu> left -- for previous patch, right -- for next patch
<cde> I need to go to sleep now (have to wake up early) I'll let you know how it goes!
<wolfspraul> yes, you absolutely need a line-in music input
<wolfspraul> otherwise no point in m1
<wolfspraul> that's the #1
<wolfspraul> then the second one is the camera, real-time video synthesis
<wolfspraul> sure, go sleep
<wolfspraul> let us know how it went
<wolfspraul> we'll fix the jtag-serial issue too, no worries...
<wolfspraul> cde: thanks for the feedback!
<xiangfu> cde, good night
<wolfspraul> oh
<wolfspraul> and of course, we should also find out one day why the TV didn't pick up the signal
<wolfspraul> there is probably something that can still be improved on m1, if the tv accepts a vga input that should work...
<wolfspraul> cde: which tv model is this? just the brand...
<roh> wolfspraul: there is no too hard in rework. only too bad yield ;)
<qi-bot> The Firmware build was successfull, see images here: http://fidelio.qi-hardware.com/~xiangfu/build-milkymist/milkymist-firmware-09152011-0336/
<kristianpaul> for the tv i had problem with my theory was that some resolution may no be supported, also at that time my laptop dint worked either :/
<wpwrak> kristianpaul: never abandon a good theory just because it's wrong ;-)
<kristianpaul> :)
<kristianpaul> also at that time my m1 want able to do higher resolution for gui
<kristianpaul> and i dont bother in take tc specs as it came froma  local company that asseble tv's and other home appliaces
<kristianpaul> s/tc/tv
<wpwrak> ah yes, that brand name inflation game. as if there weren't enough brands already in china ...
<kristianpaul> s/want/wasnt
<kristianpaul> and after i upgrade the firmware for that date, i again have problems when coming from gui to render with a vide proyector.. oh well..
<kristianpaul> but was a baracamp so again i had no time to take specs .. and i also have to run for  a workshop
<qi-bot> The Firmware build was successfull, see images here: http://fidelio.qi-hardware.com/~xiangfu/build-milkymist/milkymist-firmware-09152011-0706/
<wpwrak> joy ! finally got a standby corruption. took only some 32-34 hours. and they seem to come in clusters.
<wpwrak> xiangfu: does the CRC check in the test software start at the first word (0xffff ...) or at some offset ?
<xiangfu> no offset.
<xiangfu> start at 0x00000000 in nor flash.
<wpwrak> grmbl. so NOR corruptions do indeed come in clusters. i see a lot in the first few words, plus always one deeper inside
<xiangfu> wpwrak, what is that mean of  'come in clusters' ?
<wpwrak> btw, where is the source of the test software ? (that boot.4e53273.bin)  i don't see it in git://github.com/milkymist/milkymist
<xiangfu> git://github.com/milkymist/autotest-m1
<wpwrak> (clusters) seems that more than one NOR corruption happens within a short time span. maybe even within the same cycle.
<wpwrak> thanks !
<xiangfu> the https://github.com/milkymist is a group. all milkymist stuff is under 'https://github.com/milkymist'
<xiangfu> wpwrak, (clusters) ok. got it thanks.
<wpwrak> (group) oh, nice. thanks !
<wpwrak> let's see if these clusters may be related to temperature. i seem to get a bit more corruption in the middle of the night.
<wpwrak> or maybe it's the effect of moonlight ...
<xiangfu> wolfbug :)
<wpwrak> ;-))
<wpwrak> werebug :)
<xiangfu> oh. yes
<xiangfu> wpwrak, if it related to temperature. we will have big problem in winter, just the next few month
<wpwrak> indeed :) and i have to hurry, because i only have a few weeks left to reproduce the bug. well, unless i relocate my m1 to the fridge :)
<lekernel> re. those screen detection problems, perhaps I should use the exact 25.175MHz pixel clock instead of 25MHz
<lekernel> I thought all screens were able to tolerate this (and read the same in many places), but apparently not
<wpwrak> i would expect at lest that much tolerance too
<wpwrak> maybe it's something else ? e.g., sync polarity or such ?
<lekernel> I had a similar issue on another beamer - detecting some very high resolution like 2048x1024 and displaying only a distorted portion of the 640x480 picture
<lekernel> it rather looks like a video timing problem
<lekernel> did cde try with another USB cable btw?
<wpwrak> maybe the sync pulses have the wrong timing ? and yes, vga timing is interesting. changes quite a lot between resolutions. and polarities do, too
<lekernel> it's only using negative polarity
<wolfspraul> he said he tried several cables yes
<wolfspraul> for the tv problem, it could also simply be that the vga-in of that tv is broken, or that a certain channel had to be selected manually
<wolfspraul> but of course, if we can improve something on the m1 side, even better.
<wolfspraul> I hope his demo goes fine, a little strange with the dead jtag-serial board.
<wpwrak> ((tag board) yeah, the kernel should say something
<wpwrak> for 640x480, negative hsync/vsync would indeed be correct
<wolfspraul> but the kernel says nothing, and since the board appears powered (led on), it can only be a plain failure of the ftdi chip
<wolfspraul> eeprom shorting still to be done
<wolfspraul> i'm wondering what triggered this, since it definitely worked just a few days ago before shipping
<wolfspraul> oh well
<wolfspraul> hardware is hard
<wpwrak> i kinda wonder ... i would expect the kernel to at least announce that it found a low/full-speed device
<wolfspraul> nothing
<wolfspraul> not a single line in dmesg
<wpwrak> maybe the usb connector came a little loose
<wolfspraul> well, let's see
<wolfspraul> we have to wait
<wolfspraul> good idea [push down usb connector]
<wpwrak> (which could also be on the pc side. particularly those ether-double-usb combos are more than fragile)
<wpwrak> (dmesg) a good test would be to connect a known to be good device, paste the dmesh. then remove the device and connect the jtag on that very same port. paste dmesg again.
<GitHub168> [scripts] xiangfu force-pushed master from 2b3a2d9 to 282c36d: http://git.io/DOsw5Q
<GitHub168> [scripts/master] scripts: ignore build when no new commit - Xiangfu Liu
<lekernel> if there's a open or short circuit on one of the USB data lines (which can come from a fault cable or connector), it will produce this symptom
<wolfspraul> sounds exotic
<wolfspraul> he will test some more when he's back in france, I hope
<qi-bot> The Firmware build was successfull, see images here: http://fidelio.qi-hardware.com/~xiangfu/build-milkymist/milkymist-firmware-09152011-1036/
<wpwrak> hmmm ... i think it should be fun to profile this compiler
<kristianpaul> what this?
<wpwrak> compiler.c may spend quite some time doing string operations. that may explain some of the slowness. the things it calls look better at a first glance, though. profiling should show if the inefficiency of compiler.c really has a significant impact on overall performance or not.
<larsc> compiler.c?
<kristianpaul> flickernoise i guess
<kristianpaul> at least wpwrak mean llhdl perhaps?
<kristianpaul> :)
<wpwrak> flikcernoise/src/compiler.c
<wpwrak> things like pfv_from_name
<wpwrak> milkymist/software/libfpvm/ uses re2c and lemon. i don't know them, but they're probably reasonably efficient (i mean, why else depart from lex and yacc)
<wpwrak> well, maybe ... i still see a lot of copying
<lekernel> wpwrak, because parsers generated by lex and yacc only work on GNU systems ...
<lekernel> wpwrak, C programming is about copying :)
<lekernel> (if I understand "copying" as "code duplication and reinventing the wheel" ...)
<larsc> damm! and i always though it was about reuse
<wpwrak> you must mean flex and bison. lex and yacc must have been considered old before rms was even born ;)
<wpwrak> (duplicate) you must have spent too much time in china ;-)
<wpwrak> of course, unix-style reuse is often in the form of  new_interface | old_engine   ;-)
<larsc> "and every year we decided to add a new layer to hide the crap we've down the year before"
<wpwrak> until the day comes when the archeologists roll up their sleeves and go spelunking :)
<qi-bot> The Firmware build was successfull, see images here: http://fidelio.qi-hardware.com/~xiangfu/build-milkymist/milkymist-firmware-09152011-1312/
<mwalle> wpwrak: have you tried cooler spray and a hot air gun?
<GitHub169> [scripts] sbourdeauducq pushed 3 new commits to master: http://git.io/_Zt8Kg
<GitHub169> [scripts/master] Update makefile to use rtems cvs repository instead of deleted milkymist git clone. - JP Bonn
<GitHub169> [scripts/master] Updated for latest build script and rtems cvs tree. - JP Bonn
<GitHub169> [scripts/master] Merge pull request #2 from jpbonn/master - Sébastien Bourdeauducq
<mwalle> lekernel: what is tmu early ack?
<lekernel> an experiment that lets the SDRAM controller acknowledge the transfer a fixed number of cycles before the data gets actually transferred, to allow for more request pipelining efficiency
<lekernel> it doesn't make any difference from the LM32 point of view
<lekernel> it's just a tad bit faster
<mwalle> mh qemu head is broken (at least for lm32?)
<mwalle> lekernel: i guess that experiment is just for fun? or do you want to squeeze the last bit performance out of the soc already? :)
<mwalle> lekernel: are u still using tiling windowmanages?
<wpwrak> (early ack) i guess that's for trying to get things to work at higher resolutions
<wpwrak> (cold/hot air) hmm, so far, i'm not desperate enough for that :)