<terpstra_>
mwalle, what reference material did you write your gdbstub.c with?
<terpstra_>
mwalle, i'm translating it into something that drives the monitor, but don't know what some of the packets you send mean.
<aw_>
xiangfu, when i flashed msd-dec2010/soc-1.0RC2.fpg from msd-apr2011/soc-1.0RC3.fpg; once flash completed, if i used "Shutdown" to select "Reboot", the info will still show SoC 1.0RC3.fpg.
<aw_>
xiangfu, only exactly power off and power on board again, then platform version info is correct though.
<aw_>
lekernel, i think that this is because fpga needs to be driven a real signal trigger on PROGRAM_B pins a low level. which h/w RC2 version won't be have this function. right?
<xiangfu>
aw_: that is normal I think. no need warry about that. :)
<aw_>
xiangfu, um..i know. but this should can be done by s/w? well..i don't know.
<aw_>
xiangfu, :-)
<aw_>
xiangfu, hm..it's reasonable now I think. the soc bitstream needs to be load during fpga configuration stage which only LED1 lights after power cycling. :-) good this is the reason. :-)
<aw_>
so whenever you see the info shows rightly is because address starts from 0x80860000 is regular BIOS/splash/APP(Flickernoise)/data partition. All of them can be directly changed/reloaded by "Reboot" button. :-)
<xiangfu>
hmm...
<xiangfu>
aw_: need look into a little why it's not change after software reboot
<xiangfu>
aw_: the SOC string is read from "0xe000103c". but I don't know why after software reboot. ti's still the old.
<xiangfu>
need lekernel  to answer this question :)
<lekernel>
simply, software reboot doesn't reload the bitstream
<lekernel>
mwalle: it seems that the QEMU VNC server doesn't take into account the resolution changes... at 1024x768 the picture is messed up
<lekernel>
who wants to submit a CCC camp talk with me?
<larsc>
mwalle: is bwalle related to you?
<CIA-8>
rtems-milkymist: Sebastien Bourdeauducq master * r860d0b4 / c/src/lib/libbsp/lm32/shared/milkymist_networking/network.c : Ethernet: get rid of ipalign - http://bit.ly/dVwPAm
<lekernel>
?! wireshark shows outgoing frames of 2962 bytes from my computer (which obviously trigger rtems/milkymist ethernet bugs)
<mwalle>
larsc: nope
<lekernel>
ifconfig shows my mtu is set to 1500 ...wtf?
<lekernel>
hmm... ifconfig mtu 1000 reduced those frames to 1962
<lekernel>
let me try with a very small mtu :)
<lekernel>
argh... breaks netboot which doesn't handle fragmented UDP
<lekernel>
I don't get it. why does TCP seems to send frames larger than the MTU?
<lekernel>
but not UDP?
<lekernel>
is sick of bugs
<larsc>
arn't we all
<mwalle>
lekernel: it seems that your vncclient doesnt support resizing
<lekernel>
it works for you?
<lekernel>
I connected after resizing
<lekernel>
mwalle: btw ethernet is completely broken for you?
<lekernel>
for me about 1/3 of the "large" (several hundred bytes) frames appear somewhat truncated, maybe by hardware
<lekernel>
instead of having 1500 bytes, they have a random length between 650 and 750 bytes
<mwalle>
lekernel: (vnc) no it doesnt work
<mwalle>
ping works, bot nothing else
<lekernel>
{#~{[! adding printk() in the ethernet ISR RX makes the bug disappear
<mwalle>
lekernel: you could try to print in a buffer
<lekernel>
it could be because printk() makes the ISR a bit slower
<lekernel>
if this is the case and when i'm pissed off enough about that, i'll just add a dummy loop in the ISR lol ;)
<mwalle>
so writing into a buffer wont change the timing too much
<lekernel>
mhahaha yeah, adding 80K NOPs into the ethernet ISR makes it work
<Fallenou>
what's the point of having non-copy things like mbuf if it's to lose time in useless loops
<Fallenou>
does not get it
<lekernel>
mwalle: btw for some reason the bug is never triggered for ping packets, no matter the size and frequency
<lekernel>
Fallenou: making a copy free driver takes one hour. fixing pesky bugs like that take one month or more.
<mwalle>
qemu will have opengl disabled by default
<lekernel>
mwalle: what's the problem btw? linking the opengl nvidia library breaks the x86 emulator?
<lekernel>
can't you only link qemu-system-lm32?
<mwalle>
lekernel: yes seems to break some amd64 archs
<lekernel>
just link the lm32 arch against opengl?
<mwalle>
nah, i dont think thats a good idea
<lekernel>
why not? the other archs don't need it anyway
<mwalle>
that would just be another workaround..
<mwalle>
which requires more changes
<mwalle>
disabling opengl by default is only a oneliner
<mwalle>
and --enable-opengl wont hurt much
<mwalle>
and maybe there are the same problems for lm32 on amd64
<lekernel>
ok, but i'm worried that distros would just build the QEMU package with the default options and all will ship qemu-system-lm32 without opengl
<mwalle>
mh, i c
<lekernel>
I have an nvidia card, and opengl+qemu works for me...
<mwalle>
lekernel: are you subscribed to qemu-devel?
<lekernel>
nope... too much traffic
<mwalle>
yeah, lol :)
<mwalle>
almost 30k unread mails in my inbox ;)
<mwalle>
lekernel: ok i suggest to disable opengl by default except for lm32 targets
<mwalle>
this will be an ugly configure hack, arg
<CIA-8>
milkymist: Sebastien Bourdeauducq master * ref32be1 / (7 files in 2 dirs): Ethernet: simplifications and fixes - http://bit.ly/dNQJDo