<terpstra>
mwalle, yes - i made my own firmware loading and debugging tool using altera's tcl interpretter
<terpstra>
it speaks the JTAG to the cyclone3 for me
<terpstra>
however, i'm replacing that now with a modularized C++ program that connects all the components from USB->FTDI->USB-Blaster->JTAG state machine->Cyclone3 regmap->Altera SLD hub->LM32 remap->debug rom uart->RAM/CSR/GDB interface
<terpstra>
the idea being that you can plug the pieces together to support other devices
<terpstra>
if i had more time, i'd make it have a clicky-gui where you could drag and drop the components together and then double-click on things like a RAM/gdb interface in the picture to launch some interface to the chain you built
<terpstra>
the part i've been working on so far has been how to run messages inside the interconnection DAG whilst maximizing the size of buffer processed at a each step
<Fallenou>
lekernel: RMS is doing a talk in London this afternoon
<Fallenou>
do you want me to plant a bomb ? :p
<lekernel>
no but if you can talk him into supporting our stuff it'd be great
<lekernel>
we _need_ advertisement
<Fallenou>
what could I say for example ?
<Fallenou>
(I didn't plan on attending btw)
<lekernel>
I don't know, and it probably won't be easy since mm soc points out problems with the arbitrary hw/sw partitioning of the FSF
<lekernel>
iirc rms did try to make some free HDL designs at some point, you might want to read up on this
<lekernel>
"Firmware such as programs for programmable logic devices or microcoded machines are software, and can be copylefted like any other software"
<lekernel>
yeah well
<lekernel>
you can start with that
<lekernel>
and mention LLHDL/Antares, since that's something Opencores never thought about doing (so he doesn't think we're the next openrisk)
<kristianpaul>
Fallenou may talk to him about copyleft ASICs but is kind of early for that
<kristianpaul>
Also point him how hardware is getting more close to be a lockware system, and how that can affect the free software that run on it.
<kristianpaul>
well just some random ideas..
<Fallenou>
humm I guess he knows that
<Fallenou>
it's kind of in the text
<kristianpaul>
ah, let me read..
<Fallenou>
I think I won't go
<kristianpaul>
stop reading
<Fallenou>
I prefer taking the time to prepare the slides for OSHUG
<kristianpaul>
copying, he is very extremist on that part of course is not posible, but dunno what he things about manufacture
<kristianpaul>
Fallenou: if add a new driver to rtems bsdp for mm1 or just modify some lines in one, DO i need do the whole boostraping again? or it can be specific?
<kristianpaul>
for the part of the code changed
<kristianpaul>
the boostraping script detect that changes or i must tell it?
<Fallenou>
if you add C files
<Fallenou>
you have to redo the bootstrapping
<Fallenou>
but only for the subtree you modified
<Fallenou>
for example you could just redo the bootstrap from c/src/lib/libbsp/lm32/
<Fallenou>
it is MUCH faster than redo the entire bootstrap
<kristianpaul>
ie boostrap last chnages Fallenou did on the ethernet driver
<Fallenou>
oh, if you just modified the content of an already existing C/H file
<Fallenou>
don't need to bootstrap
<Fallenou>
just type make
<kristianpaul>
but if i add a new driver, i need to do the _whole_ boostrap?
<Fallenou>
nop
<Fallenou>
just do the bootstrap for the subtree you modified
<kristianpaul>
just the tree
<kristianpaul>
ah ok
<Fallenou>
you can do like ../../../../bootstrap -option
<Fallenou>
I recommand doing the bootstrap -c then -p then without argument
<Fallenou>
to get everything cleaned up
<Fallenou>
but *from* the subtree
<Fallenou>
no the root of the tree
<kristianpaul>
hehe sure
<kristianpaul>
i dont want more coffe ;-)
<Fallenou>
if you add a driver do not forget to add it to the driver array in your application
<kristianpaul>
whats the driver array? an include?
<Fallenou>
and to add the c/h files to the bsp Makefile.am
<kristianpaul>
ok
<Fallenou>
well for some drivers you can just activate them using something like
<scrts>
I see that milkymist has vga output.. was here a discusion to implement DVI or not? :)
<lekernel>
you're only seeing that now?
<scrts>
no
<scrts>
I saw that... would be a better beginning of the sentence? :)
<Fallenou>
lekernel: I don't understand in your slides of the 26C3 why the vga framebuffer would take only 900 Mbps and not 1800 Mbps
<Fallenou>
I guess it's because of the "double buffering"
<lekernel>
hm?
<Fallenou>
but I still don't understand why
<lekernel>
no, double buffering doesn't have anything to do with that
<Fallenou>
ok
<Fallenou>
so if we have a 3 MB framebuffer
<Fallenou>
and 75 MHz
<Fallenou>
or refresh rate
<lekernel>
formula is hres * vres * screen refresh rate * bits per pixel
<scrts>
emm, so why not DVI? expensive interface chips? harder to implement?
<lekernel>
scrts: because no one has DVI except for monitors
<Fallenou>
lekernel: ok so it's the 3 MB that I don"t understand
<scrts>
ah, didn't think that most projectors also use standard vga cable :)
<Fallenou>
1024*768*2 ?
<lekernel>
I cannot count how many times I had to answer that question... should be in the faq
<lekernel>
damn this faq needs some update
<Fallenou>
I get 1.5 MB
<Fallenou>
just the half
<lekernel>
Fallenou: the size takes is impacted by the double buffer, but not the bandwidth
<Fallenou>
ok right
<Fallenou>
I get it now :)
<Fallenou>
sorry
<Fallenou>
and I guess distorsion is 1024*768*30*16*2 because it needs to read and to write
<Fallenou>
distortion*
<lekernel>
yes
<Fallenou>
lekernel: at page 24 (the two triangles and about cache and bursts), on the left triangle if I understand correctly you say that a pixel is at first a cache miss, then the next one is a cache hit (because of the burst+cache), right ?
<lekernel>
yes
<Fallenou>
and then what about the second triangle ?
<Fallenou>
and the fact that it's rotated
<Fallenou>
is there something to understand on this second triangle ?
<Fallenou>
and the scanlines
<Fallenou>
(sorry for all the questions but I'm just making sure I understand what I will be talking about :))
<lekernel>
the second triangle is the triangle that is drawn
<lekernel>
as output
<Fallenou>
yes
<Fallenou>
no optimization to explain on the second  one then ?
<lekernel>
huh?
<lekernel>
the point of the figure is to explain how a cache can improve memory read performance on this example
<lekernel>
so, no
<Fallenou>
ok so the main idea is presented by the triangle on the left
<Fallenou>
ok thanks :)
<Fallenou>
wanted to make sure I didn't miss something important
<lekernel>
yeah but the triangle on the right explains why the sequence of reads in the triangle on the left is like that
<Fallenou>
the sequence of read is always for left to right, no ?
<Fallenou>
form*
<Fallenou>
from*
<lekernel>
larsc: mwalle: do you want to mentor the linux port stuff?
<lekernel>
for gsoc
<larsc>
lekernel: at least not officially. i want to participate in gsoc as a student and you can't be mentor for one project and student at another one