<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
<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
<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 ;)
<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
<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 :)
<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 :)