| GitHub124 | [migen] sbourdeauducq pushed 1 new commit to master: http://git.io/w80fTw | 14:35 |
|---|---|---|
| GitHub124 | migen/master 4fb3e97 Sebastien Bourdeauducq: genlib/fsm: add entering/ongoing/leaving methods | 14:35 |
| sb0 | ftdi_eeprom is so incredibly bad ... | 15:42 |
| sb0 | for any practical purpose, you need to hack into its source to hardcode what you need because the normal behaviour is completely unusable | 15:43 |
| wpwrak | you're overly specific. ftdi sucks. it's as simple as that :) | 15:44 |
| sb0 | anyway, the mixxeo now enumerates correctly on USB :) | 15:45 |
| sb0 | about to load the first bitstream, after finding out why the urjtag svn won't compile | 15:46 |
| wpwrak | (ftdi avoidance) doing fast jtag is a little hard, but if all you use it for is flashing and serial anyway, you may as well use an MCU. keep the fpga tri-stated, then dfu to the flash through the MCU. | 15:46 |
| wpwrak | so you got the boards ? you ought to post about that, with pictures. keep people interested :) | 15:47 |
| sb0 | I have two fully assembled boards, and 8 more have gone through SMT and still need through-hole components | 15:48 |
| sb0 | need to find a camera somewhere. also, I'm on the plane every second day atm ... | 15:49 |
| sb0 | with, of course, maximum annoyance at airports regarding the contents and/or weight of my luggage. the mass spectrometer I had on one segment got my name called on the PA 5min after checking in the bag :) | 15:51 |
| wpwrak | ;-))) | 15:51 |
| wpwrak | you had that with you on then way into syria or out ? :) | 15:52 |
| sb0 | checking for LIBUSB... yes | 15:53 |
| sb0 | checking for LIBFTDI... no | 15:53 |
| sb0 | checking for LIBFTDI... yes | 15:53 |
| sb0 | ... | 15:53 |
| larsc | checking for LIBFTDI... maybe ;) | 15:55 |
| wpwrak | checking for LIBFTDI... maybe | 15:55 |
| larsc | ha! | 15:55 |
| wpwrak | (-:C | 15:55 |
| wpwrak | checking for LIBFTDI... [y/n] ? _ | 15:56 |
| sb0 | abort/retry/fail? | 15:56 |
| wpwrak | oh, do i WISH we could abort autoconf ... | 15:56 |
| sb0 | JTAG works :) FPGA is detected | 16:19 |
| sb0 | and yet another s6 stepping ... | 16:19 |
| sb0 | fjmem loaded | 16:22 |
| wpwrak | kewl | 16:23 |
| sb0 | hmm, and now this: http://pastebin.com/MtAn8cZS | 16:24 |
| wpwrak | i could kick myself for not thinking of the direct usb-to-flash approach earlier. that avoids the whole jtag and ftdi mess. | 16:24 |
| wpwrak | hmm, that's when you wish you had used spi flash ... | 16:25 |
| wpwrak | well, let's hope it's nothing too messy | 16:25 |
| sb0 | yes, and hopefully SPI flash would not have caused the corruption nightmare either | 16:34 |
| sb0 | I wanted an easy route from the ML401 and that's what I got ... | 16:35 |
| sb0 | interestingly enough, Xilinx seems to get away without reset chip. but not me. | 16:35 |
| wpwrak | the chip in question is also quite weak when it comes to protection features. there are better approaches. | 16:36 |
| sb0 | led is blinking :) | 16:36 |
| wpwrak | what i like best is "soft" protection plus a trapdoor: start with soft protection disabling all writes, then have "trapdoor" write-protect bits that can be set but are only cleared on reset. | 16:38 |
| wpwrak | that way, a boot loader can set up any protection scheme one wants, then pass control to the application. for a controlled shutdown, the application could then protect everything through the trapdoor mechanism. | 16:39 |
| wpwrak | since all the protection is volatile, you also don't have incremental tearing down of protections, like first clearing the (persistent) "lock" bit and later doing the actual corruption | 16:40 |
| wpwrak | the trap door mechanism does exist in some flash chips. i don't think any start with the "soft" protection set to read-only, though. (probably in order to be compatible with ancient chips that had none of this) | 16:42 |
| wpwrak | (led blinking) mission accomplished :) | 16:42 |
| cde | it's a small voltage drop for leds, but a giant step for sb0! | 16:56 |
| cde | or should I say: "#milkymist, this board has landed" ;) | 16:57 |
| wpwrak | is the "NORton, we have a problem" solved ? | 17:07 |
| sb0 | was in a (quick) meeting. forgot that the clock pin has been changed... | 17:16 |
| sb0 | recompiling fjmem ... | 17:16 |
| sb0 | "highly Zeitgeist-compatible" :)) | 17:21 |
| wpwrak | one's paranoia is another one's opportunity :) | 17:22 |
| sb0 | with the correct clock pin, flash detection works | 17:26 |
| sb0 | :) | 17:26 |
| sb0 | BIOS is running, now memtest fails | 17:30 |
| wpwrak | whee ! | 17:31 |
| sb0 | hmm, when bit-banging the SDRAM, it responds correctly though | 17:32 |
| sb0 | but memtest reports 100% failed words. sounds like a relatively easy logic design bug. | 17:32 |
| sb0 | memory reads from LM32 are all 0's | 17:33 |
| sb0 | hmm | 17:34 |
| sb0_ | ethernet is ok | 20:54 |
| wpwrak | HDMI ? :) | 20:59 |
| sb0_ | needs to fix SDRAM first... and with a solid 1hr runtime of the ISE shitware on my travel laptop, this takes a while | 21:01 |
| cde | have you tried turning it off and on again? | 21:01 |
| wpwrak | ;-)) | 21:03 |
| acathla | :) | 21:04 |
| GitHub172 | [mibuild] sbourdeauducq pushed 1 new commit to master: http://git.io/pNgjaA | 21:10 |
| GitHub172 | mibuild/master d57344b Sebastien Bourdeauducq: platforms/mixxeo: add LED | 21:10 |
| GitHub15 | [fjmem-m1] sbourdeauducq pushed 2 new commits to master: http://git.io/UfT5bw | 21:13 |
| GitHub15 | fjmem-m1/master 8417e28 Sebastien Bourdeauducq: Add build folder | 21:13 |
| GitHub15 | fjmem-m1/master 8c1ea67 Sebastien Bourdeauducq: add Mixxeo support | 21:13 |
| GitHub39 | [fjmem-m1] sbourdeauducq pushed 1 new commit to master: http://git.io/uFgYnQ | 21:19 |
| GitHub39 | fjmem-m1/master aff0207 Sebastien Bourdeauducq: README: update | 21:19 |
| sb0_ | found the problem with SDRAM. Florent's patch had broken it. | 21:36 |
| --- Sat Sep 7 2013 | 00:00 | |
Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!