<kristianpaul>
Fallenou: MAXIMUM_FRAME_SIZE is not implemented on your driver, why? how do you handle the  ethernet frames then?
<Fallenou>
in the driver I use MLEN as the max len
<kristianpaul>
in wich part fo the netwroking documentation is MLEN mentioned?
<Fallenou>
MLEN = MSIZE - sizeof(struct m_hdr)
<kristianpaul>
hmm may be mine is outdate.. Edition 4.10.99.0, for RTEMS 4.10.99.0
<Fallenou>
is grepping through the source code, 1 min
<Fallenou>
hum hum cannot find MSIZE
<Fallenou>
but I am pretty sure MLEN is something like 1500
<Fallenou>
damn I cannot find any #define MSIZE anywhere
<Fallenou>
can you ?
<Fallenou>
maybe it's in the compiler header :o
<Fallenou>
is having a look
<Fallenou>
ok yes it is
<Fallenou>
MSIZE = 128
<Fallenou>
hum hum so it's the starting size of an mbuf
<Fallenou>
I guess it grows afterward
<Fallenou>
looking at his code
<Fallenou>
hum hum strange I cannot find where I allocate memory inside the mbuf :o
<Fallenou>
could be our bug :)
<Fallenou>
maybe we just have the basic 128 bytes
<Fallenou>
and bigger frames will just overwrite memory
<Fallenou>
I will ask Joel about that :)
<Fallenou>
why the hell am I using MLEN in the packet structure instead of ETHERNET_FRAME_LENGTH
<Fallenou>
let  fix that
<CIA-40>
rtems-milkymist: Yann Sionneau master * r73572ad / c/src/lib/libbsp/lm32/shared/milkymist_networking/network.c : fixed length of data member of mm_packet struct to be ETHERNET_FRAME_LENGTH instead of MLEN - http://bit.ly/gTn785
<Fallenou>
kristianpaul: I pushed a fix for the ethernet driver
<Fallenou>
I don't know if it will fix the FIFO problem
<Fallenou>
but it surely was a big issue
<Fallenou>
that would corrupt memory
<Fallenou>
kristianpaul: please compile the bsp and try again to make it crash :)
<Fallenou>
I emailed the rtems ML about that
<Fallenou>
thanks for the feed back kristianpaul :)
<kristianpaul>
Fallenou: he, i hope i works, i'll try it tomorrow or later midnight
<kristianpaul>
I need sump to work on the avnet, but thanks to jevin that will be quick i think :-)
<kristianpaul>
ergg i mean jackgassett:
<Fallenou>
ok great, keep me posted on your tests :)
<Fallenou>
I think this fix fixes something, but it may not be the problem you are talking about :)
<Fallenou>
we'll see !
<kristianpaul>
what is something?
<Fallenou>
well I think it fixes a big memory corruption issue
<Fallenou>
inside the ethernet driver
<Fallenou>
when packets were > 128 bytes memory was overwritten somewhere
<Fallenou>
which isn't really cool :)
<kristianpaul>
heh
<Fallenou>
look at the patch, it's a one-liner-patch
<adamw_>
larsc, last time I used: modprobe ftdi_sio vendor=0x20b7 product=0x0713
<adamw_>
to activate the JTAG/Serial pod
<larsc>
adamw_?
<adamw_>
if I erased VID/PID info, then I use UrJtag tool & tried to 'cable milkymist', but I got 'Couldn't connect to suitable USB device.
<adamw_>
Error: usbconn/libftdi.c:372 usbconn_ftdi_common_open() ftdi/ftd2xx error: ftdi_usb_open_desc() failed: device not found
<adamw_>
hmm...with 'dmesg', I can see two device attached to ttyUSB0 and ttyUSB1
<kristianpaul>
hmm
<adamw_>
so I found that strange things that if I used "modprobe ftdi_sio vendor=0x20b7 product=0x0713" & programmed ftdi to be correct '0x20b7' & '0x0713'
<adamw_>
then I just got only ttyUSB0 only, ttyUSB1 disappeared...what could cause this?
<kristianpaul>
ttyUSB1 is actually jtag so should be okay
<kristianpaul>
does it said too "Ignoring serial port reserved for JTAG" ?
<adamw_>
so I erased VID/PID then 'dmesg'...i got two device attached!
<larsc>
should be fine. there is code in the driver which tells to don't create a ttyUSB for the jtag port, when VID/PID matches those of the milkymist jtag adapter
<adamw_>
but i got failed while running 'jtag''s 'cable milkymist'. :-) hope you understand my descriptions.
<kristianpaul>
why you erased VID/PID? you mean in the eeprom?
<larsc>
adamw_: did it fail for the MM VID/PID or the default VID/PID or both?
<adamw_>
i didn't see the replied msg of 'dmsg' about attaching two device, so after I erased VID/PID then my laptop can detect both.
<kristianpaul>
you dont need reply about attaching two devices
<adamw_>
with MM VID/PID, I got ttyUSB0 only; with default VID/PDI, i got both.
<larsc>
adamw_: thats the correct result
<adamw_>
so what action I need to do now?
<kristianpaul>
jtag
<kristianpaul>
cable milkymist
<kristianpaul>
detect
<adamw_>
erase back to MM VID/PID...then jtag..cable milkymist ..detect ?
<larsc>
yes
<kristianpaul>
yes
<larsc>
that should work
<adamw_>
good...second.
<kristianpaul>
nice bug fix btw :-)
<roh>
at openmoko we always had 2 serials as far i can remember... and one vanished as soon as openocd was started
<larsc>
urjtag checks the VID/PID and if it doesn't match you'll get the error you've seen
<kristianpaul>
larsc: did you finally try openocd with lm32?
<kristianpaul>
or was mwalle ..
<larsc>
kristianpaul:Â Â i couldn't getit to work
<kristianpaul>
adamw_: does it works?
<adamw_>
good, jtag port/coonection surely work well.
<adamw_>
but my ttyUSB1 can't work well since I need to use it to test serial port connected to M1.
<kristianpaul>
well i just ram some already made scripts for jtag to both flash bitstream and the app
<kristianpaul>
it works as usual, now a bit faster it seems
<kristianpaul>
ok, bed time now
<kristianpaul>
chao !
<adamw_>
cu!
<wpwrak>
hmm, regarding that jtag fix, did anyone actually measure what the difference between full-speed and high-speed mm1 jtag is ?
<lekernel>
rejon: playing with Ron a bit? ;)
<wpwrak>
heh, ron isn't here. that's kinda convenient ;-)
<rejon>
hahahah
<rejon>
its good to expose what we need to be working on
<rejon>
:)
<rejon>
bbiab gotta eat
<wpwrak>
rejon: i wouldn't mind the _exposing_ part. but if you had a limp, would you truly appreciate it if everyone you meet would mention it in every other sentence ?
<wpwrak>
rejon: or, for that matter, if most people would drop that topic after a while, but there's one guy who keeps on with it.
<Fallenou>
Is the minimac ethernet driver working well on Linux ?
<Fallenou>
can someone give me the link of the repository ?