<roh> brrr...
<roh> 'make it stop! -  burn it with fire!! - nuke it from space - ...'
<Fallenou> :)
<kristianpaul> Fallenou: low troughtput no matter if you still able to transfer the whole thing
<kristianpaul> adamw_: hola :-)
<kristianpaul> How did you tests last time? (jtag-serial pod)
<adamw_> some things wrong?
<kristianpaul> no no, well let me check first :-)
<adamw_> ok...i didn't use it to flash NOR via high speed though.:-)
<kristianpaul> looks good in any case :-)
<adamw_> must tell me if we missed important tests.:)
<kristianpaul> hmm flash need a script, wiki is ok but you may need something faster to type, but for one board is okay
<adamw_> u know me that I quite don't know the s/w details.
<adamw_> but just for those automatics program used so i can know the 'h/w connection' is ok on jtag/serial pod.
<adamw_> hmm ..yes but last time i did really know the high speed bug. man!
<adamw_> didn't know.
<kristianpaul> what? 8.2Mb flickernoise binary, i hope can still boot...
<kristianpaul> adamw_: will be nice compare high speed jta-serial pod with xilinx cable
<adamw_> hmm...surely
<adamw_> but i would focus on fixing boot bug first.:-)
<kristianpaul> yes yes
<kristianpaul> ok, no i cant belive from 1.4Mb with pdf support to get pdf suppport i got now a 8.2Mb bin !!
<kristianpaul> lekernel: ^
<kristianpaul> E: Invalid flash boot image length
<kristianpaul> hmm
<kristianpaul> dammit, i cant boot...
<kristianpaul> ah weird, is just flicernoise??.. the httpd network demo is oka..
<kristianpaul> Fallenou: Where are you using MAXIMUM_FRAME_SIZE?? and how are you _handling_ frames larger than that in order to reject those
<kristianpaul> Fallenou: i'm just reading page 48 of netwotking.pdf about Stress Tests
<kristianpaul> ETHERNET_FRAME_LENGTH  = MAXIMUM_FRAME_SIZE?
<kristianpaul> // TODO: Use a softc or global variables, but not both!!!...
<kristianpaul> are you using softc right now?
<kristianpaul> ah yes
<kristianpaul> now i ask my self how well this driver follow rtems guidelines...
<Technicus> Hello . . . perhaps a little off topic, but are there any instructions avaliable for connecting a Cannon video camera via usb to a Debian system as a video capture device?
<adamw_> lekernel, while starting a Program_B(configuration) got LOW, shall RP# be activated as LOW from fpga h/w itself or your codes too?
<Fallenou> kristianpaul: this driver surely is not a model , it is by several aspects wrong
<Fallenou> anyway we should not receive any frame larger than the usual MTU
<Fallenou> I guess no network card would send bogus packets in normal configuration
<lekernel> kristianpaul: yeah, the binary is now 8MB with fonts etc., and yes, it still works
<lekernel> we have 128MB RAM anyway...
<lekernel> adamw_: the FPGA does not reset the flash when it is reset
<lekernel> i.e. pulsing PROGRAM_B low does not make it assert RP# low
<lekernel> but normally people don't access PROGRAM_B, so I don't think we should add circuitry to handle this case
<adamw_> so I'd like the time FPGA asserts in reset(configuration started) syncronized with flash in parallel.
<lekernel> well yeah, you could simply add a diode between PROGRAM_B and RP# and put a reset IC on PROGRAM_B
<adamw_> yes, but seems that needed to add two diodes:
<adamw_> one is located between PROGRAM_B and reset ic's out
<adamw_> um...no
<adamw_> i described wrong. sorry
<adamw_> should be:
<adamw_> i nyour last email replied me on list , you mentioned two diodes?
<adamw_> but now it seems that we can only just add 1 diode. seems it's enough.
<adamw_> right?
<lekernel> yeah, it's enough
<lekernel> the one diode solution is better
<adamw_> yeah~seems it's ok.
<adamw_> the P3 needs 300us MIN.
<adamw_> this seems that my reset ic's delay time at least 300us is a must?
<lekernel> yeah, but I read that the FPGA needed 5ms, so it's a bit surprising we ran into this issue
<lekernel> anyway
<lekernel> yeah, your reset IC should pulse low for at least 300usec
<lekernel> but i'd put more (like 10ms) to be sure
<adamw_> yeah...i think so
<lekernel> or maybe 50ms
<lekernel> so everything comes out of reset when the power supply is well stabilized
<adamw_> right. currently i used 20us delay time only. It's not enough.
<adamw_> right..
<lekernel> you could even put 1s delay there :) it's only for the first power up...
<lekernel> no need to optimize this one
<lekernel> so let's take very large margins and be safe
<adamw_> correct. end user won't feel it's a long time.
<adamw_> but should solve our boot tiny period (power cycling) problem.
<adamw_> ok...so I'll order a sample with more than 300us and try later.
<wolfspraul> lekernel: I told you we did pretty thorough/extreme testing.
<lekernel> adamw_: take a few dozen milliseconds
<adamw_> hope we are all right on analizing at the beginning.
<wolfspraul> but now that we see this and find a way to make it more robust - great.
<adamw_> lekernel, I'll..tks.
<lekernel> try that :)
<aeris> Autant faire du Java...
<cocoadaemon> bwerk
<cocoadaemon> ;)
<cocoadaemon> ola lekernel aeris
<cocoadaemon> dis donc, ça se peuple ici ;)
<cocoadaemon> good job lekernel
<lekernel> c'est quoi le problème avec google go?
<lekernel> y0 cocoadaemon
<cocoadaemon> j'ai rien contre go, je disais bwerk pour "autant faire du java" ;)
<aeris> ça semble mignon, comme language, mais t'en qu'a prendre un language évoluer, autant prendre Java, il est connu et pleins de lib
<cocoadaemon> mais, aeris, c'est un Projet® Google© !
<cocoadaemon> </troll>
<lekernel> java c'est lent + besoin de JVM
<lekernel> go c'est compilé nativement et moins lent que java
<aeris> ça se compile le Java
<lekernel> c'est pas fait pour...
<lekernel> go works nicely with RTEMS too... java does not
<aeris> Je pense que ce n'est pas une bonne idée de partir sur des techno inconue...
<lekernel> moi je pense que si :)
<lekernel> go semble bien plus propre que c++
<lekernel> et il n'y a pas de raison qu'on n'arrive pas à le faire fonctionner sur milkymist
<aeris> Mais personne ne pourras bosser dessus
<lekernel> ça semble assez clair comme syntaxe
<Fallenou> ruby seems really nice and is really becoming a good language
<Fallenou> with a lot of usefull and well done librairies (gem)
<lekernel> ruby is totally slow
<lekernel> and I don't know if a sizable proportions of those libs would work at all, and if they do, without taking one second to draw one pixel
<lekernel> go seems a good compromise
<lekernel> fast, high level, and shouldn't be too much hassle to get it to work
<Fallenou> ok :)
<kristianpaul> go go..
<kristianpaul> go + mtk ;-)
<lekernel> funny: xst does not use carry chains for adders with operands of strictly less than 6 bits
<lekernel> hrm
<Fallenou> hum sounds like a strange technical choice
<sh4rm4> why was rtems chosen over linux ?
<sh4rm4> btw: congrats to MTK, lekernel. i've never seen such skillful code removal before
<sh4rm4> it looks as if you ripped 50% of the code off
<lekernel> because linux was unstable, and is slow to boot, complex and it takes 10 times more times to write a linux device driver than a rtems one
<sh4rm4> hmm...so RTEMS is POSIX compliant ? i wonder how hard it would be to port stuff there if it wasnt
<lekernel> yes it is
<sh4rm4> oic, nice
<lekernel> maybe we'll switch to linux, when/if it does not introduce regressions compared to rtems
<sh4rm4> i heard some rumours about openwrt a while ago
<sh4rm4> (here)
<lekernel> the initial plan was to make it run linux and openwrt
<lekernel> but it turned out to be a bloodbath
<lekernel> getting that mess to work far exceeded my limited patience
<sh4rm4> hehe
<lekernel> (and time)
<sh4rm4> well, if rtems runs nice, why would you considering switching back to linux ?
<lekernel> more features
<lekernel> like bluetooth, wifi, etc.
<sh4rm4> i c
<lekernel> and geeks like it better
<sh4rm4> how much work would it be to adopt MTK for linux usage ? (i.e. on fbdev)
<lekernel> it's trivial
<lekernel> all the mtk code is platform independent
<lekernel> it writes to a framebuffer, and takes events in
<lekernel> and calls application callback functions
<lekernel> that's it
<sh4rm4> nice
<mwalle> is {git,www}.qemu.org working for anyone?
<larsc> well, i can't reach it either
<lekernel> works for me
<lekernel> lol, it never ceases to amaze me that xilinx fpga editor uses sunrpc (don't know what for) and takes ages to start up with RPC set-up errors if portmap isn't running on your machine
<lekernel> ah, maybe they use that for IPC with PlanAhead
<lekernel> but it's still a silly use of RPC
<mwalle> lekernel: could you check if the the HEAD is at e14da0af640e4255b15d81907a93a2637e14e478 (Fix vmport segfault (v2)) ?
<lekernel> yup, it is
<mwalle> thx