| wolfspraul | lekernel: hmm, bot is here | 18:27 |
|---|---|---|
| wolfspraul | now we need to get the logs to the milkymist.org server | 18:28 |
| lekernel | how can the bot do that? | 18:28 |
| lekernel | scp? | 18:28 |
| lekernel | larsc: done | 18:32 |
| lekernel | mwalle: should we keep mcs at all? | 18:33 |
| lekernel | flickernoise doesn't use it | 18:33 |
| lekernel | urjtag neither | 18:33 |
| lekernel | only the xilinx tools do | 18:33 |
| lekernel | instead of having tons of formats for the flash images, we can simply use raw binary everywhere | 18:34 |
| lekernel | then convert them to mcs in the rare cases when you need the xilinx bloatware | 18:34 |
| mwalle | lekernel: i dont care, the only advantage is that the addresses are saved with the file | 18:35 |
| lekernel | that's not always an advantage, for example it complicates a bit making the backup flickernoise image | 18:35 |
| mwalle | ok so drop it :) | 18:36 |
| lekernel | we'd also need to unify the bitstream format too | 18:36 |
| lekernel | flickernoise uses raw bit-swapped when flashing | 18:37 |
| lekernel | urjtag uses *.bit (with xilinx header) when loading | 18:37 |
| lekernel | and raw non-bit-swapped when flashing | 18:37 |
| lekernel | that's a bit of a mess | 18:37 |
| mwalle | why does flickernoise use bit-swapped binaries? | 18:39 |
| lekernel | because that's how it's laid out in the flash in the end | 18:39 |
| lekernel | btw it's a bit surprising that urjtag didn't need bit swapping at all | 18:39 |
| mwalle | bit swap or LE<->BE? | 18:40 |
| lekernel | flickernoise writes all flash images in "natural" order | 18:40 |
| lekernel | i.e. big endian, and no bit swapping | 18:41 |
| lekernel | bit swap | 18:41 |
| lekernel | I thought urjtag did that too, because that's what is needed for the BIOS image as well | 18:41 |
| mwalle | what do you mean by bit swapping? | 18:42 |
| lekernel | sometimes, the xilinx tools (bitgen, promgen, ...) bit-swap stuff without telling you, adding to the confusion... | 18:42 |
| lekernel | replacing msb with lsb and vice versa | 18:42 |
| mwalle | bytewise? | 18:43 |
| lekernel | word-wise | 18:43 |
| lekernel | so 16-bit in our case | 18:43 |
| lekernel | (flash bus width) | 18:43 |
| mwalle | urjtag does that only for the bit file | 18:43 |
| lekernel | yeah | 18:44 |
| mwalle | ah | 18:44 |
| mwalle | the fjmem could swap it ;) | 18:44 |
| lekernel | btw 16-bit is also the width of the words for the fpga configuration engine, so you can expect 16-bit bit-swaps even when not dealing with a particular flash bus width | 18:45 |
| mwalle | so maybe the nor flash should be the other way around? | 18:45 |
| mwalle | *core | 18:45 |
| lekernel | (it should be fun to write a wireshark dissector for said fpga configuration engine btw) | 18:45 |
| mwalle | i think i had that issue with umon too | 18:45 |
| lekernel | hm? | 18:46 |
| wolfspraul | lekernel: there are a few more details with css and search script | 18:46 |
| wolfspraul | let me think about it | 18:46 |
| mwalle | lekernel: if you swap the nor flash core data bus lines, you wont need to swap, do you? | 18:46 |
| lekernel | i'll need to swap the bios and other images, no? | 18:47 |
| lekernel | and flash commands... | 18:47 |
| mwalle | mh indeed | 18:47 |
| lekernel | imo the nor flash core has the correct order. the only problem is the fpga reads its bitstream lsb first | 18:48 |
| lekernel | and xilinx tried to fix that by swapping bits in various tools, creating a massive confusion | 18:49 |
| lekernel | it makes perfect sense to load a bit reversed bitstream into the flash | 18:50 |
| lekernel | because that's addressing exactly the problem that the fpga reverses the bits again when reading it | 18:50 |
| lekernel | we can use bit-reversed bitstream images everywhere, and when loading into the fpga directly, take the 16-bit commands and load them lsb first | 18:53 |
| mwalle | arg | 19:11 |
| mwalle | /home/mw/local/lm32-linux/lib/gcc/lm32-uclinux/4.5.2/../../../../lm32-uclinux/bin/ld: unrecognized option '--eh-frame-hdr' | 19:12 |
| mwalle | [mw@thanatos b-l-2-gcc]$ lm32-uclinux-ld --help|grep eh-frame | 19:27 |
| mwalle | --eh-frame-hdr Create .eh_frame_hdr section | 19:27 |
| mwalle | [mw@thanatos b-l-2-gcc]$ lm32-uclinux-ld --eh-frame-hdr | 19:27 |
| mwalle | lm32-uclinux-ld: unrecognized option '--eh-frame-hdr' | 19:27 |
| mwalle | lm32-uclinux-ld: use the --help option for usage information | 19:27 |
| mwalle | [mw@thanatos b-l-2-gcc]$ | 19:27 |
| mwalle | wtf .. | 19:27 |
| mwalle | nice and the autotools check for that option by grepping the help | 19:27 |
| mwalle | gn8 | 19:32 |
| mwalle | lol, every bfd can add options to ld.. but not every emulation can use that options (in my case fdpic adds the --eh-frame-hdr option) but im using elf as bfd | 19:38 |
| mwalle | very clever to use --help to get the supported options | 19:38 |
| kristianpaul | flashmem... | 21:45 |
| kristianpaul | so slow.. | 21:45 |
| kristianpaul | wee i bricked the m1 :p | 21:56 |
| --- Sun Jan 16 2011 | 00:00 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!