<mw1> terpstra: do you write your own tool to use the lm32 jtag port with gdb? (that would be cool, even cooler if it was gpl :) )
<scrts> btw, how much time does it take to synthesize/p&r/etc milkymist? :)
<kristianpaul> 35 minutes or so in my one core machine
<kristianpaul> lekernel: (pastebin) first routing it seems, nice !!, does it worK? or you got a short cicuit else where? ;-)
<lekernel> can't test on fpga yet... but the result looks coherent
<kristianpaul> indeed
<kristianpaul> xiangfu: hi
<kristianpaul> xiangfu: You should join #rtems as well, and i dont know if already rtems mail lists?
<kristianpaul> (can't test on fpga yet) because missing part for a xilinx-like compliance bitstream generation?
<lekernel> I could feed that back into the xilinx toolchain using xdl, but the problem is I don't handle I/O yet
<lekernel> so no observable thing would happen
<wolfspraul> lekernel: just fyi, it seems China uses mostly PAL
<lekernel> ok, good
<lekernel> but taiwan is ntsc iirc
<lekernel> Fallenou: the rxbuff's should go to the softc too
<lekernel> http://pastebin.com/VkpJbC08 what's that?
<wolfspraul> lekernel: sorry if this is a crazy question, but is it theoretically possible to process 3 different composite video signals over the 3 video-in jacks we have?
<lekernel> no at the same time, but by switching them maybe
<wolfspraul> this needs to be supported/driven by the video codec chip?
<wolfspraul> video decoder I mean...
<wolfspraul> the ad pdf says "includes a 6-channel input mux that enables multiple video signals..."
<wolfspraul> ok anyway, I think I got it. maybe it's possible, but it's experimental and there may be limitations.
<kristianpaul> haha, just i realize now we have 3 vide in jacks, i was thinking the other two were for audio..
<aeris> lekernel tu veux toujours que le firmware soit mono-fichier ?
<aeris> Pas d'image à coté ?
<lekernel> quel firmware?
<aeris> flikernoise
<lekernel> tant que c'est pas le fouillis... il y a un système yaffs2 de toutes façons
<lekernel> c'est pour quoi?
<aeris> Des icones, entre autre
<mwalle> a further source for chip interna?
<lekernel> yup
<lekernel> btw the current antares router simply dumps the complete interconnect graph from the tools, which makes it rather memory hungry but means I don't have to understand all of this (and irregularities e.g. I/O, DSP blocks, etc.)
<lekernel> the complete representation for the xc6slx4 uses about 70M
<lekernel> oh, and I tried routing several signals with antares and fpga editor, both give exactly the same PIP lists now :)
<mwalle> nice :)
<CIA-31> qemu-lm32: michael master * rf543d138 /target-lm32/ (lm32-decode.h translate.c): lm32: use lookup table for opcodes http://tinyurl.com/62n3aau
<CIA-31> qemu-lm32: michael master * rc9fb6df5 /target-lm32/translate.c: lm32: rename raise opcode to scall http://tinyurl.com/6d6n55q
<lekernel> mwalle: btw, do you happen to know if each value of the bitstream's frame address register (FAR) represents one tile in the FPGA?
<mwalle> lol, no :)
<lekernel> knowing the FAR<=>tile mapping should make it rather easy to figure out the bitstream format
<lekernel> maybe I can get this information by playing with the partial reconfiguration features in ISE
<lekernel> kristianpaul: might be fun to read it back :)
<lekernel> though there's probably lot of stuff in it... and maybe even not ASCII
<lekernel> s/lot/not a lot/
<lekernel> I guess there are cheaper ones too...
<kristianpaul> Why ac97 core have a dma irq for r/w ?
<lekernel> like with any irq: to avoid polling
<kristianpaul> yeah, but in mean in system.v ac97dmar_irq
<kristianpaul> read more before ask again
<kristianpaul> I mean ac97 also have ac97crreply_irq and  ac97crrequest_irq wires
<kristianpaul> So i noticed this for me *extra* wires labeled asac97dmar_irq and ac97dmaw_irq
<kristianpaul> I should guess is something specific for the ac97 driver internals and i should read the datasheet also :-)
<Fallenou> 16:32 < lekernel> http://pastebin.com/VkpJbC08 what's that? < well it's the equivalent of the code that was there before, but it's in the softc now, I had a global array with registers addresses, in order to loop over it, now the array is in the softc, I initialize the array at registering time of the driver
<lekernel> ah, ok
<lekernel> for the rx buffers, I guess you can safely assume that malloc() returns an address aligned to a 32 bit boundary
<lekernel> otherwise posix_memalign() is like malloc() but lets you specify the alignment
<Fallenou> oh ok
<Fallenou> finally I did allocation with "static"
<Fallenou> is it OK ?
<lekernel> it's like a global variable.. better put that in the softc
<lekernel> or use global variables everywhere, that works too
<kristianpaul> lekernel: FML is transparently accesed from wishbone thanks to the fml bridge, right?
<lekernel> but just avoid a misleading softc/global variable mix
<lekernel> kristianpaul: yes
<Fallenou> lekernel: when you say "put that in the softc" you mean sc->rxbuffers[i] = malloc(); ?
<lekernel> yes
<Fallenou> because it's in the softc now in the last version
<Fallenou> well the static declaration is not in the softc
<Fallenou> but the pointer is in it
<Fallenou> and it's used through the softc
<kristianpaul> so, the video-in, vga-out and tmu are already maped in fml also?
<kristianpaul> Fallenou: what is softc?
<Fallenou> kristianpaul: the structure that holds all the driver-related pointers/data
<kristianpaul> Fallenou: oh, nice to know :-)
<Fallenou> struct minimac_softc in network.c
<Fallenou> gn8
<kristianpaul> n8
<Fallenou> thx
<lekernel> kristianpaul: the only thing which is mapped in FML is the SDRAM. the other devices connected to it are masters (accessors)