| roh | brrr... | 00:01 |
|---|---|---|
| roh | 'make it stop! - burn it with fire!! - nuke it from space - ...' | 00:02 |
| Fallenou | :) | 00:05 |
| kristianpaul | Fallenou: low troughtput no matter if you still able to transfer the whole thing | 01:21 |
| kristianpaul | adamw_: hola :-) | 01:59 |
| kristianpaul | How did you tests last time? (jtag-serial pod) | 01:59 |
| adamw_ | http://en.qi-hardware.com/wiki/JTAG/Serial_Cable_run_1_for_Milkymist_One#Tests_and_Results | 02:00 |
| adamw_ | some things wrong? | 02:00 |
| kristianpaul | no no, well let me check first :-) | 02:01 |
| adamw_ | ok...i didn't use it to flash NOR via high speed though.:-) | 02:02 |
| kristianpaul | looks good in any case :-) | 02:03 |
| adamw_ | must tell me if we missed important tests.:) | 02:04 |
| kristianpaul | hmm flash need a script, wiki is ok but you may need something faster to type, but for one board is okay | 02:05 |
| adamw_ | u know me that I quite don't know the s/w details. | 02:05 |
| adamw_ | but just for those automatics program used so i can know the 'h/w connection' is ok on jtag/serial pod. | 02:06 |
| adamw_ | hmm ..yes but last time i did really know the high speed bug. man! | 02:06 |
| adamw_ | didn't know. | 02:07 |
| kristianpaul | what? 8.2Mb flickernoise binary, i hope can still boot... | 02:12 |
| kristianpaul | adamw_: will be nice compare high speed jta-serial pod with xilinx cable | 02:15 |
| adamw_ | hmm...surely | 02:16 |
| adamw_ | but i would focus on fixing boot bug first.:-) | 02:17 |
| kristianpaul | yes yes | 02:17 |
| kristianpaul | ok, no i cant belive from 1.4Mb with pdf support to get pdf suppport i got now a 8.2Mb bin !! | 02:21 |
| kristianpaul | lekernel: ^ | 02:21 |
| kristianpaul | E: Invalid flash boot image length | 02:22 |
| kristianpaul | hmm | 02:22 |
| kristianpaul | dammit, i cant boot... | 02:30 |
| kristianpaul | ah weird, is just flicernoise??.. the httpd network demo is oka.. | 02:36 |
| kristianpaul | Fallenou: Where are you using MAXIMUM_FRAME_SIZE?? and how are you _handling_ frames larger than that in order to reject those | 02:51 |
| kristianpaul | Fallenou: i'm just reading page 48 of netwotking.pdf about Stress Tests | 02:53 |
| kristianpaul | ETHERNET_FRAME_LENGTH = MAXIMUM_FRAME_SIZE? | 02:55 |
| kristianpaul | // TODO: Use a softc or global variables, but not both!!!... | 02:58 |
| kristianpaul | are you using softc right now? | 02:58 |
| kristianpaul | ah yes | 02:59 |
| kristianpaul | now i ask my self how well this driver follow rtems guidelines... | 03:08 |
| 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? | 05:21 |
| 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? | 07:30 |
| Fallenou | kristianpaul: this driver surely is not a model , it is by several aspects wrong | 09:53 |
| Fallenou | anyway we should not receive any frame larger than the usual MTU | 09:54 |
| Fallenou | I guess no network card would send bogus packets in normal configuration | 09:55 |
| lekernel | kristianpaul: yeah, the binary is now 8MB with fonts etc., and yes, it still works | 10:44 |
| lekernel | we have 128MB RAM anyway... | 10:44 |
| lekernel | adamw_: the FPGA does not reset the flash when it is reset | 10:44 |
| lekernel | i.e. pulsing PROGRAM_B low does not make it assert RP# low | 10:45 |
| lekernel | but normally people don't access PROGRAM_B, so I don't think we should add circuitry to handle this case | 10:46 |
| adamw_ | so I'd like the time FPGA asserts in reset(configuration started) syncronized with flash in parallel. | 11:07 |
| lekernel | well yeah, you could simply add a diode between PROGRAM_B and RP# and put a reset IC on PROGRAM_B | 11:08 |
| adamw_ | yes, but seems that needed to add two diodes: | 11:10 |
| adamw_ | one is located between PROGRAM_B and reset ic's out | 11:11 |
| adamw_ | um...no | 11:11 |
| adamw_ | i described wrong. sorry | 11:11 |
| adamw_ | should be: | 11:11 |
| adamw_ | i nyour last email replied me on list , you mentioned two diodes? | 11:14 |
| adamw_ | but now it seems that we can only just add 1 diode. seems it's enough. | 11:15 |
| adamw_ | right? | 11:15 |
| lekernel | yeah, it's enough | 11:26 |
| lekernel | the one diode solution is better | 11:27 |
| adamw_ | yeah~seems it's ok. | 11:33 |
| lekernel | http://www.stanford.edu/class/ee183/handouts_win2003/VerilogQuickRef.pdf what a mess :) | 11:34 |
| adamw_ | btw, i checked the p.36 of http://www.numonyx.com/Documents/Datasheets/319942_J3-65nm_256-Mbit_MLC%20DS.pdf | 11:35 |
| adamw_ | the P3 needs 300us MIN. | 11:36 |
| adamw_ | this seems that my reset ic's delay time at least 300us is a must? | 11:37 |
| lekernel | yeah, but I read that the FPGA needed 5ms, so it's a bit surprising we ran into this issue | 11:37 |
| lekernel | anyway | 11:38 |
| lekernel | yeah, your reset IC should pulse low for at least 300usec | 11:38 |
| lekernel | but i'd put more (like 10ms) to be sure | 11:38 |
| adamw_ | yeah...i think so | 11:39 |
| lekernel | or maybe 50ms | 11:39 |
| lekernel | so everything comes out of reset when the power supply is well stabilized | 11:39 |
| adamw_ | right. currently i used 20us delay time only. It's not enough. | 11:39 |
| adamw_ | right.. | 11:39 |
| lekernel | you could even put 1s delay there :) it's only for the first power up... | 11:39 |
| lekernel | no need to optimize this one | 11:40 |
| lekernel | so let's take very large margins and be safe | 11:40 |
| adamw_ | correct. end user won't feel it's a long time. | 11:40 |
| adamw_ | but should solve our boot tiny period (power cycling) problem. | 11:41 |
| adamw_ | ok...so I'll order a sample with more than 300us and try later. | 11:41 |
| wolfspraul | lekernel: I told you we did pretty thorough/extreme testing. | 11:41 |
| lekernel | adamw_: take a few dozen milliseconds | 11:41 |
| adamw_ | hope we are all right on analizing at the beginning. | 11:41 |
| wolfspraul | but now that we see this and find a way to make it more robust - great. | 11:42 |
| adamw_ | lekernel, I'll..tks. | 11:42 |
| lekernel | aeris: http://golang.org/doc/gccgo_install.html | 12:36 |
| lekernel | try that :) | 12:36 |
| lekernel | http://www.rtems.com/wiki/index.php/GCCGoRTEMS | 12:37 |
| aeris | Autant faire du Java... | 12:39 |
| cocoadaemon | bwerk | 12:40 |
| cocoadaemon | ;) | 12:40 |
| cocoadaemon | ola lekernel aeris | 12:41 |
| cocoadaemon | dis donc, ça se peuple ici ;) | 12:41 |
| cocoadaemon | good job lekernel | 12:41 |
| lekernel | c'est quoi le problème avec google go? | 12:41 |
| lekernel | y0 cocoadaemon | 12:41 |
| cocoadaemon | j'ai rien contre go, je disais bwerk pour "autant faire du java" ;) | 12:42 |
| 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 | 12:42 |
| cocoadaemon | mais, aeris, c'est un Projet® Google© ! | 12:43 |
| cocoadaemon | </troll> | 12:43 |
| lekernel | java c'est lent + besoin de JVM | 12:43 |
| lekernel | go c'est compilé nativement et moins lent que java | 12:44 |
| aeris | ça se compile le Java | 12:44 |
| lekernel | c'est pas fait pour... | 12:44 |
| lekernel | go works nicely with RTEMS too... java does not | 12:48 |
| aeris | Je pense que ce n'est pas une bonne idée de partir sur des techno inconue... | 12:49 |
| lekernel | moi je pense que si :) | 12:50 |
| lekernel | go semble bien plus propre que c++ | 12:50 |
| lekernel | et il n'y a pas de raison qu'on n'arrive pas à le faire fonctionner sur milkymist | 12:51 |
| aeris | Mais personne ne pourras bosser dessus | 12:51 |
| lekernel | http://en.wikipedia.org/wiki/Google_Go#Examples | 12:51 |
| lekernel | ça semble assez clair comme syntaxe | 12:51 |
| Fallenou | ruby seems really nice and is really becoming a good language | 12:53 |
| Fallenou | with a lot of usefull and well done librairies (gem) | 12:54 |
| lekernel | ruby is totally slow | 12:54 |
| 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 | 12:55 |
| lekernel | go seems a good compromise | 12:56 |
| lekernel | fast, high level, and shouldn't be too much hassle to get it to work | 12:56 |
| Fallenou | ok :) | 12:56 |
| lekernel | http://www.engineyard.com/blog/2009/ready-set-go/ | 13:01 |
| kristianpaul | go go.. | 16:08 |
| kristianpaul | go + mtk ;-) | 16:08 |
| lekernel | funny: xst does not use carry chains for adders with operands of strictly less than 6 bits | 18:16 |
| lekernel | http://lwn.net/SubscriberLink/428100/9d3311d20cd0ea12/ | 21:02 |
| lekernel | hrm | 21:02 |
| Fallenou | hum sounds like a strange technical choice | 21:10 |
| sh4rm4 | why was rtems chosen over linux ? | 21:19 |
| sh4rm4 | btw: congrats to MTK, lekernel. i've never seen such skillful code removal before | 21:21 |
| sh4rm4 | it looks as if you ripped 50% of the code off | 21:21 |
| 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 | 21:22 |
| sh4rm4 | hmm...so RTEMS is POSIX compliant ? i wonder how hard it would be to port stuff there if it wasnt | 21:23 |
| lekernel | yes it is | 21:24 |
| sh4rm4 | oic, nice | 21:24 |
| lekernel | maybe we'll switch to linux, when/if it does not introduce regressions compared to rtems | 21:25 |
| sh4rm4 | i heard some rumours about openwrt a while ago | 21:25 |
| sh4rm4 | (here) | 21:25 |
| lekernel | the initial plan was to make it run linux and openwrt | 21:25 |
| lekernel | but it turned out to be a bloodbath | 21:26 |
| lekernel | getting that mess to work far exceeded my limited patience | 21:26 |
| sh4rm4 | hehe | 21:27 |
| lekernel | (and time) | 21:27 |
| sh4rm4 | well, if rtems runs nice, why would you considering switching back to linux ? | 21:27 |
| lekernel | more features | 21:27 |
| lekernel | like bluetooth, wifi, etc. | 21:27 |
| sh4rm4 | i c | 21:27 |
| lekernel | and geeks like it better | 21:28 |
| sh4rm4 | how much work would it be to adopt MTK for linux usage ? (i.e. on fbdev) | 21:28 |
| lekernel | it's trivial | 21:28 |
| lekernel | all the mtk code is platform independent | 21:29 |
| lekernel | it writes to a framebuffer, and takes events in | 21:29 |
| lekernel | and calls application callback functions | 21:29 |
| lekernel | that's it | 21:29 |
| sh4rm4 | nice | 21:29 |
| mwalle | is {git,www}.qemu.org working for anyone? | 21:48 |
| sh4rm4 | http://www.downforeveryoneorjustme.com/git.qemu.org | 21:49 |
| larsc | well, i can't reach it either | 21:50 |
| lekernel | works for me | 21:53 |
| 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 | 21:54 |
| lekernel | ah, maybe they use that for IPC with PlanAhead | 21:54 |
| lekernel | but it's still a silly use of RPC | 21:54 |
| mwalle | lekernel: could you check if the the HEAD is at e14da0af640e4255b15d81907a93a2637e14e478 (Fix vmport segfault (v2)) ? | 21:56 |
| lekernel | yup, it is | 21:57 |
| mwalle | thx | 21:57 |
| --- Fri Feb 18 2011 | 00:00 | |
Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!