<kristianpaul>
xiangfu: not boot after powercycle?
<lekernel>
bash supports "set -e", so either you're not using bash (or a version of it that would be appropriate for a computer museum) or it's another problem
<kristianpaul>
sure
<xiangfu>
I have tried change the ../src/flickernoise.fbiz to ../src/flickernoise.fbi.  after flash flickernoise.fbi or ../src/flickernoise.fbiz. the MM1 stop at "Booting ..."
<xiangfu>
try to update BIOS now.
<kristianpaul>
hmm
<kristianpaul>
better
<kristianpaul>
update
<kristianpaul>
or ash..
<kristianpaul>
oh debian..
<lekernel>
last time I used it, debian shipped with dash
<kristianpaul>
s/ash/dash
<lekernel>
hm, then maybe I should replace the shebang line with bash...
<kristianpaul>
think that makefiles are more universal
<lekernel>
not really, there are bsd make vs. gnu make problems as well
<kristianpaul>
arghh, yeah
<kristianpaul>
bsd uses bash?
<kristianpaul>
ok, lets complicate things a bit and better use a scripting language not from gnu ;-)
<kristianpaul>
now i see why people use perl
<kristianpaul>
or used too ;-)
<mwalle>
bah perl :b
<mwalle>
worst syntax ever
<kristianpaul>
yeah..
<kristianpaul>
learning lua
<mwalle>
ok lisp and tcl is horrible too :)
<lekernel>
yeah, surprisingly tcl is very popular in the EDA world
<lekernel>
all big FPGA/ASIC software has TCL scripting
<kristianpaul>
ah,yes quartus for example
<mwalle>
our ixia network tester has an tcl binding too..
<kristianpaul>
dammit, csr bus run out of slaves...
<kristianpaul>
ok, add other CSR bus or make this bigger..
<kristianpaul>
let see
<lekernel>
yeah, the csr bus is packed
<lekernel>
you'd need to add an extra decoder bit on it, or remove a peripheral you don't need
<lekernel>
mwalle: btw I saw you sent some milkymist peripheral support code to QEMU lists. how did it go?
<mwalle>
lekernel: no reply yet
<kristianpaul>
boot rom is intended to be a bootloader?
<kristianpaul>
i mean for saving a bootloader there
<kristianpaul>
ergha
<kristianpaul>
never mind
<kristianpaul>
that comment do not present the module instatiation :-)
<kristianpaul>
okay may be rom, if lekernel have plans of using microsd as data disk
<lekernel>
what is boot rom?
<kristianpaul>
A comment in system.v in wich  norflash module ins instatiated
<kristianpaul>
s/ins/is
<lekernel>
well, this just maps the flashrom into the wishbone address space, which is used, among other things, as a boot rom to run the bios
<kristianpaul>
boot flickernoise from external memory will be neat (of course not my priority or from other that i'm aware)
<lekernel>
what is "external memory"?
<mwalle>
lekernel: what are the blockram sizes for a spartan6? multiples of 2kb?
<lekernel>
mwalle: it's implemented at the chip level with RAMB8BWER and RAMB16BWER sites... checking
<kristianpaul>
s/external memory/memory card
<lekernel>
RAMB16BWER is 16Kb Data + 2Kb Parity (nb. that's kilobit, not kilobyte)
<kristianpaul>
Sorry is a mind typo, is okay if call it as 8:10 memory too  here?
<lekernel>
and the other is half the size
<lekernel>
kristianpaul: it already works
<mwalle>
ok so its 2kbyte
<kristianpaul>
lekernel: works mean boots flickernoise?
<lekernel>
mwalle: when using RAMB16BWER yes, but you can have 1kbyte granularity with the other
<kristianpaul>
also i dint work with my 1Gb kinsgstone memory :/
<lekernel>
kristianpaul: try "cardboot", and if it doesn't work look at the code
<kristianpaul>
oh
<lekernel>
mwalle: and initializing the contents of RAMB8BWER's doesn't work reliably... lol
<lekernel>
but still their Xst software will still infer RAMB8BWER when you specify an initialization file. what a mess
<kristianpaul>
i dont understand well, "cardboot" is bios command, cause grep dont found it..
<mwalle>
lekernel: the gdb stub uses binary transfers too. what do you think about a self clearing enable bit for the breakin statemachine?
<lekernel>
so the debug ROM would reactivate break when returning?
<Fallenou>
kristianpaul: I guess it has been removed
<mwalle>
lekernel: exactly
<lekernel>
mwalle: sounds good
<Fallenou>
kristianpaul: git log -S'cardboot'
<Fallenou>
will show you  the commits which have "cardboot" in the diff
<lekernel>
is it OK to use multiple return values of multiple calls to strtok_r? e.g. a = strtok_r(...); b = strtok_r(...); do_something(a, b);
<Fallenou>
does the do_something modifies a or b ?
<lekernel>
no
<Fallenou>
seems ok :o
<Fallenou>
as long as you provide a different context pointer for each call
<Fallenou>
oh maybe it's the same context you are talking about
<Fallenou>
I think the return value is  a pointer into the memory area you provided
<Fallenou>
not one allocated inside strtok_r
<Fallenou>
so it should stay valid even if you call again strtok_r
<Fallenou>
and since it's thread safe I guess it's the case
<lekernel>
ah, no, it's the same context pointer of course
<Fallenou>
ok but I think you're still ok
<Fallenou>
lekernel: I am thinking about the "rx buffer pool" for the ethernet driver
<Fallenou>
it would make us do as follow
<Fallenou>
in the interrupt top half handler : we copy data into a rx_buffer
<Fallenou>
and then in the bottom half we ask for a m_buff and we copy the data inside the mbuff and pass it to tcp ip stack
<Fallenou>
which makes two memcopy
<Fallenou>
instead of one for the moment
<Fallenou>
am I correct ?
<lekernel>
no
<lekernel>
what you should do instead is maintain a pool of pre-allocated buffers of the maximum ethernet frame length
<Fallenou>
yes that's what i'm talking about
<lekernel>
in the interrupt handler, all you do is forward the addresses of the buffers that were DMA-written by the core to the bottom half, and immediately refill the ethernet core with buffers from the pool
<lekernel>
without any copy
<Fallenou>
oh yes
<Fallenou>
ok
<lekernel>
all the pool contains is buffer addresses
<Fallenou>
I just save the address and give another address to the minimac rx slot
<lekernel>
yes
<Fallenou>
and then I can memcopy from this address to a m_buff
<Fallenou>
I get it now
<Fallenou>
I am writting the patch
<lekernel>
yup, and as soon as you're done writing the mbuf, you put the buffer address back into the pool
<lekernel>
(all with appropriate locking ofc)
<Fallenou>
yes
<lekernel>
maybe you can use a rtems queue for the buffer pool
<Fallenou>
I will just put a uint8_t
<Fallenou>
to say if the buff is busy or not
<lekernel>
that's a non-portable way of doing it (btw you can simply use int), but it should be ok
<Fallenou>
why not portable ?
<lekernel>
maybe it has less overhead than the rtems queue
<Fallenou>
we only have one cpu core
<Fallenou>
and one ethernet card
<Fallenou>
the driver is only for Milkymist
<lekernel>
yeah, that's why i'm saying it should be ok
<Fallenou>
ok :)
<lekernel>
and use int - it's a 32-bit cpu
<Fallenou>
let's try to get over this rx fifo overflow first
<Fallenou>
and then maybe clean the code :p
<scrts>
sorry for offtopic: lekernel afaik in the past, You were creating a logic analyzer. Did You use any special algorithms to save memory? i.e. when the data is 10MHz and You sample it with 100Mhz, the memory will be filled with 10 same samples
<Fallenou>
lekernel: what will it change to use int instead of uint8_t ?
<lekernel>
fyi: there are several problems that lead to a "rx overflow" message, and one of them is definitely a hardware bug
<Fallenou>
oh ? you think there is a hardware bug too ?
<lekernel>
so we may not get rid entirely of it by just fixing the driver
<Fallenou>
ok
<Fallenou>
at least the software part will be better
<Fallenou>
it may help track the hardware bug down
<lekernel>
yeah, I guess so... sometimes I get rx overflow with the ethernet cable disconnected
<Fallenou>
humm ok
<lekernel>
while the driver should clear this flag
<lekernel>
and the hardware should not set it again
<Fallenou>
I was thinking about something else
<Fallenou>
in the if (rx buffer overflow)
<Fallenou>
in the driver
<mwalle>
can gcc calculate the max stack usage?
<lekernel>
but it could also be that the driver doesn't clear the flag
<Fallenou>
maybe I should ack for ethTX irq too ?
<lekernel>
mwalle: how could it do that?
<Fallenou>
and re activate this irq
<Fallenou>
since i reset the ethernet code
<Fallenou>
core*
<Fallenou>
i don't know
<mwalle>
lekernel: static analysis, of course w/o recursion
<lekernel>
and things like alloca()...
<mwalle>
i dont use that :)
<lekernel>
Fallenou: hmm... I don't remember. hopefully, it's in the minimac doc, otherwise i'd need to have a look at the verilog source
<lekernel>
mwalle: i'm not aware that gcc does any static analysis
<Fallenou>
kristianpaul: you will be able to test it like tomorrow ?
<Fallenou>
btw the statistics I gave were with a huge printk() debug
<Fallenou>
without the debug it's even better
<Fallenou>
98% in IDLE
<Fallenou>
I commit, let me know if it's better or worse
<CIA-37>
rtems-milkymist: Yann Sionneau master * r07ec7cb / c/src/lib/libbsp/lm32/shared/milkymist_networking/network.c : rx buffers' memory is now alloced via malloc - http://bit.ly/hbtZly
<CIA-37>
rtems-milkymist: Yann Sionneau master * r44402f3 / c/src/lib/libbsp/lm32/shared/milkymist_networking/network.c : Ethernet driver now has a 10 reception buffers pool and should empty the rx fifo faster - http://bit.ly/dHPfHP