<wolfspraul>
now we need to get the logs to the milkymist.org server
<lekernel>
how can the bot do that?
<lekernel>
scp?
<lekernel>
larsc: done
<lekernel>
mwalle: should we keep mcs at all?
<lekernel>
flickernoise doesn't use it
<lekernel>
urjtag neither
<lekernel>
only the xilinx tools do
<lekernel>
instead of having tons of formats for the flash images, we can simply use raw binary everywhere
<lekernel>
then convert them to mcs in the rare cases when you need the xilinx bloatware
<mwalle>
lekernel: i dont care, the only advantage is that the addresses are saved with the file
<lekernel>
that's not always an advantage, for example it complicates a bit making the backup flickernoise image
<mwalle>
ok so drop it :)
<lekernel>
we'd also need to unify the bitstream format too
<lekernel>
flickernoise uses raw bit-swapped when flashing
<lekernel>
urjtag uses *.bit (with xilinx header) when loading
<lekernel>
and raw non-bit-swapped when flashing
<lekernel>
that's a bit of a mess
<mwalle>
why does flickernoise use bit-swapped binaries?
<lekernel>
because that's how it's laid out in the flash in the end
<lekernel>
btw it's a bit surprising that urjtag didn't need bit swapping at all
<mwalle>
bit swap or LE<->BE?
<lekernel>
flickernoise writes all flash images in "natural" order
<lekernel>
i.e. big endian, and no bit swapping
<lekernel>
bit swap
<lekernel>
I thought urjtag did that too, because that's what is needed for the BIOS image as well
<mwalle>
what do you mean by bit swapping?
<lekernel>
sometimes, the xilinx tools (bitgen, promgen, ...) bit-swap stuff without telling you, adding to the confusion...
<lekernel>
replacing msb with lsb and vice versa
<mwalle>
bytewise?
<lekernel>
word-wise
<lekernel>
so 16-bit in our case
<lekernel>
(flash bus width)
<mwalle>
urjtag does that only for the bit file
<lekernel>
yeah
<mwalle>
ah
<mwalle>
the fjmem could swap it ;)
<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
<mwalle>
so maybe the nor flash should be the other way around?
<mwalle>
*core
<lekernel>
(it should be fun to write a wireshark dissector for said fpga configuration engine btw)
<mwalle>
i think i had that issue with umon too
<lekernel>
hm?
<wolfspraul>
lekernel: there are a few more details with css and search script
<wolfspraul>
let me think about it
<mwalle>
lekernel: if you swap the nor flash core data bus lines, you wont need to swap, do you?
<lekernel>
i'll need to swap the bios and other images, no?
<lekernel>
and flash commands...
<mwalle>
mh indeed
<lekernel>
imo the nor flash core has the correct order. the only problem is the fpga reads its bitstream lsb first
<lekernel>
and xilinx tried to fix that by swapping bits in various tools, creating a massive confusion
<lekernel>
it makes perfect sense to load a bit reversed bitstream into the flash
<lekernel>
because that's addressing exactly the problem that the fpga reverses the bits again when reading it
<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
<mwalle>
lm32-uclinux-ld: use the --help option for usage information
<mwalle>
[mw@thanatos b-l-2-gcc]$
<mwalle>
wtf ..
<mwalle>
nice and the autotools check for that option by grepping the help
<mwalle>
gn8
<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
<mwalle>
very clever to use --help to get the supported options