<terpstra_>
so far i have reliable access to the lm32's registers, start/stop/step, and break+watch points
<terpstra_>
however, i've not attached it to a gdb socket yet
<terpstra_>
i have not yet looked into supporting the xilinx jtag cable, but don't expect it would be too hard in my framework
<terpstra_>
as for the patches i made to the jtag connection in the lm32, i'm not 100% certain they will be necessary
<terpstra_>
they were at least partly needed to work around what turned out to be bugs in the altera jtag cable's software
<terpstra_>
since i no longer use their software, their bugs don't matter to me ;)
<xiangfu>
kristianpaul: hi. I bought one 1GB memcard. works fine in my m1.
<lekernel>
omap is just one more proprietary SoC. you could compare it to the apple a4, for example. if it makes a bit of noise in the FOSS world, it's only because of TI's marketing of the beagleboard.
<lekernel>
If a device is not yet described, the user may assemble a driver out of the reusable software components. For example, an Altera USB-Blaster
<lekernel>
driver is just a FTDI device chained with a byte packeter and a JTAG bit banger. Once the design has been graphically assembled, it is automatically scanned for attached JTAG devices and the USB cable design is shared online with any future users of the same cable.
<lekernel>
interesting
<lekernel>
the xilinx jtag cables use a custom protocol... how will you implement that? new component?
<lekernel>
basically, you're sending packets TMS/TDO samples on a bulk endpoint, and you get TDI packets back
<xiangfu>
lekernel: why I flash 19M(0x12E0000 the length of flash5) 0xFF file to /dev/flash5. make all file lose. but not 5M?
<lekernel>
it depends where YAFFS2 places the lists of filenames
<lekernel>
nothing tells you this should be at the beginning of the flash, no?
<lekernel>
especially if you have made several operations before
<lekernel>
YAFFS2 tries to minimize the number of sector erases, so it would rather write new data to an erased sector at the end instead of erasing a previously used sector at the beginning
<xiangfu>
thanks. so when I make the yaffs image. I have to make it 19M. right?
<lekernel>
yes
<lekernel>
but I'd guess the end would be filled with 0xFF
<terpstra_>
that's where i connect all the components to talk to the jtag on altera
<terpstra_>
you can basically hook up a directed acyclic graph of components where each speaks a protocol from inputs to outputs
<terpstra_>
then you 'wire them up' and it makes a driver
<methril_work>
interesting
<terpstra_>
i'm in the middle of restructuring the codebase so you don't have the lm32 component code visible in there yet
<methril_work>
i like more than OpenOCD tcl scripts :)
<terpstra_>
well, i want it to be done with a GUI
<terpstra_>
and autoconnect components depending on what it detects
<methril_work>
but is the gui being mandatory? sometimes i prefer console sw
<terpstra_>
i think for connecting components a gui is best... but if i get so far, i surely will have passed through some xml format that you can launch it with
<terpstra_>
so if you have configured the device already in the gui, you could save your chain and drive it from the command-line
<terpstra_>
but that's vaporware
<terpstra_>
no gui, only manual c++ atm
<terpstra_>
lekernel, so your ml401-flasher.c should be easy to integrate
<lekernel>
if you want... but it's quite a hack
<terpstra_>
you could probably just write it like the 'ftdi-byte-mode.cpp' code
<terpstra_>
and then re-use my jtag bitbanger
<lekernel>
well I don't have a xilinx cable anymore :)
<terpstra_>
we do, actualyl
<terpstra_>
but i want/eed to get gdb running perfectly before next wednesday
<lekernel>
I use the milkymist pods now
<terpstra_>
so that's my priority
<lekernel>
btw, if you want some of our jtag pods, they're cheaper and faster than the xilinx cables
<methril_work>
they work with all xillinx FPGAs?
<lekernel>
yeah, they should
<lekernel>
it's the same pinout as the xilinx cable
<terpstra_>
lekernel, the altera jtag cables are nice too
<methril_work>
nice, i`ve a cheap xiinx cable :)
<terpstra_>
how fast is fast?
<lekernel>
we don't have the ribbon cable though, so I don't know how easily they could plug to other boards
<lekernel>
30Mbps
<terpstra_>
oh
<terpstra_>
that's better than the altera one!
<lekernel>
it's merely a ft2232h breakout board
<terpstra_>
although i'm not sure if the ftdi driver is what makes it slow
<wolfspra1l>
xiangfu: wow
<wolfspra1l>
I bought my 3rd keyboard today
<wolfspra1l>
another cheap china keyboard
<wolfspra1l>
and now I have new weird bugs
<xiangfu>
:)
<wolfspra1l>
the keypresses kind of work in the Flickernoise GUI (I'm using your build)
<wolfspra1l>
but as soon as I connect the keyboard, I cannot click buttons with the mouse anymore
<wolfspra1l>
I can move the cursor around, but clicking won't work
<wolfspra1l>
<tab> with the keyboard also doesn't really move me to the next control
<wolfspra1l>
I almost feel it's some software problem where the focus remains in the edit control
<wolfspra1l>
maybe I'm just too dumb to use the software?
<wolfspra1l>
if I have both keyboard and mouse attached at boot time, I cannot boot
<wolfspra1l>
that may be another (separate) bug
<wolfspra1l>
yes so when I start typing, the mouse focus gets stuck in the text
<wolfspra1l>
I can move the mouse, but that will only move the text selection
<wolfspra1l>
I cannot press buttons anymore
<wolfspra1l>
that seems to be bug #1
<wolfspra1l>
bug #2 - if I have this latest kbd connected when plugging in the m1 dc jack, the m1 will immediately go to an unbootable state (2 leds dimly lit)
<wolfspra1l>
I need to first plug dc jack in, then connect the keyboard, then bootup
<xiangfu>
(bug 1) did your 'enter' key have problem. like always pressed?
<wolfspra1l>
no <enter> works normally
<wolfspra1l>
I'm in the patch editor now
<wolfspra1l>
the problem is that the mouse focus is stuck in the text
<wolfspra1l>
as if the mouse is always pressed down
<terpstra_>
lekernel, what is it you dislike about the xilinx cable besides the speed? afaict, i can support it for my debug chain with like 30 lines of code.
<terpstra_>
that makes me quite happy.
<lekernel>
uh. price
<terpstra_>
ahh
<terpstra_>
you called it a "mess" i thought
<lekernel>
and yeah, technically it's a mess (but it works)
<terpstra_>
but all i need is two commands to read/write the jtag pins
<terpstra_>
that's quite simple
<lekernel>
which partly explains the price I think
<wolfspra1l>
xiangfu: it's an apple mouse, maybe there is a mouse problem that is separate from the keyboard?
<terpstra_>
what would you consider not a mess?
<lekernel>
one small FTDI chip
<wolfspra1l>
terpstra_: we've made a little board
<lekernel>
or similar
<wolfspra1l>
I can sell it to you :-)
<terpstra_>
wolfspra1l,  ;P
<xiangfu>
wolfspra1l: maybe
<wolfspra1l>
29 USD or so (never thought about it)
<wolfspra1l>
terpstra_: actually you should buy a complete Milkymist One, of course
<wolfspra1l>
make it to the next level :-)
<terpstra_>
well, i am working with our own fpgas here
<lekernel>
with that Xilinx cable, you have a 8051, that the host computer has to program at every connection (with the xilinx software this is a major source of cable problems btw), then you have a fat FPGA or CPLD and everything to do....? JTAG bit banging.
<terpstra_>
don't want a music dj thing :)
<lekernel>
that's a bit ridiculous
<wolfspra1l>
terpstra_: what is your thing doing?
<terpstra_>
lekernel, you obviously haven't seen the altera cable then... that's far more complicated.
<wolfspra1l>
xiangfu: should I buy another keyboard? :-)
<terpstra_>
wolfspra1l, controlling the particle accelerator at GSI
<wolfspra1l>
get an m1, rock the place
<terpstra_>
(but we will possibly be using the lm32 in our fpgas)
<wolfspra1l>
will lift morale
<xiangfu>
wolfspra1l: you really meet a lot of bugs :D,
<wolfspra1l>
yes a lot
<wolfspra1l>
I will demo you
<wolfspra1l>
good that I like bugs
<wolfspra1l>
maybe I should get another mouse
<lekernel>
wolfspra1l: keyboard (usb) bugs?
<wolfspra1l>
lekernel: don't know, it's my 3rd kbd now
<wolfspra1l>
first one had usb hub
<wolfspra1l>
second one greenasia ic, who knows
<wolfspra1l>
third one kinda works, but the 2 problems as described above
<wolfspra1l>
first one is easy to workaround - plug it in only after applying dc power to m1
<wolfspra1l>
second one not so easy, the mouse focus gets stuck in the text when I start typing
<wolfspra1l>
so when I move the mouse, i move the selection
<lekernel>
huh, I have never seen that one
<wolfspra1l>
clicking will only remove the selection, but immediately start another selection
<wolfspra1l>
so I cannot click buttons anymore
<lekernel>
the keyboard detection issue with the greenasia issue was more common
<wolfspra1l>
which means - as soon as I start typing the gui is completely unusable
<lekernel>
I've never seen a bug like that
<wolfspra1l>
it could be my mouse of course, not the kbd
<wolfspra1l>
lekernel: yes, almost looks like that pic
<lekernel>
if you press ESC at boot it should give you the console
<wolfspra1l>
just the side button is white, not grey. maybe a bit older still.
<wolfspra1l>
it's also strange that I cannot power the m1 with this kbd attached
<wolfspra1l>
it will immediately go to unbootable state (dimly lit leds)
<wolfspra1l>
but let's put that aside now
<lekernel>
even with the reset IC?
<lekernel>
the reset IC should definitely fix that one bug
<wolfspra1l>
I don't have such a board
<wolfspra1l>
now my m1 won't boot right now - waiting time
<wolfspra1l>
leds dimly lit... (even without kbd)
<lekernel>
just use the JTAG cable to load the bitstream... and don't wait
<wolfspra1l>
well. I like to experience our users pain :-)
<wolfspra1l>
I'm asking for money for this thing...
<lekernel>
they have a JTAG cable too. that's why it says "developer kit"
<wolfspra1l>
wow yes, looks like cannot boot now
<wolfspra1l>
that's definitely not end user ready...
<wolfspra1l>
imagine this would happen at a party/event
<lekernel>
try with that damn reset IC...
<wolfspra1l>
one by one
<wolfspra1l>
I don't have such a board here, but I try jtag now
<wolfspra1l>
I know we already fixed/improved this
<wolfspra1l>
it's good to see that the fix is valuable :-)
<wolfspra1l>
I'm just reflashing the whole thing now
<lekernel>
you shouldn't need to (unless the reset bug damaged the contents of your flash, but this was extremely rare)
<wolfspra1l>
now it boots :-)
<lekernel>
maybe you could also just do 'pld reconfigure' when the bug manifests itself
<wolfspra1l>
lekernel: am I supposed to press <esc> on the usb keyboard?
<lekernel>
yes
<wolfspra1l>
I did and nothing happened
<lekernel>
or the serial console. both are connected
<wolfspra1l>
I'm sure it's another problem with my keyboard
<lekernel>
worksforme
<wolfspra1l>
don't worry
<wolfspra1l>
yes sure
<wolfspra1l>
my feeling is this kbd has more weirdness
<lekernel>
did you do it repeatedly?
<wolfspra1l>
oh sure
<wolfspra1l>
all the time
<lekernel>
hm, ok
<lekernel>
maybe have a look at the serial output
<lekernel>
and/or abort boot from serial, then try to use the USB keyboard
<wolfspra1l>
as soon as the keyboard is connected, mouse clicks don
<wolfspra1l>
don't work anymore
<wolfspra1l>
anyway
<lekernel>
the BIOS prints more USB debug messages on serial than flickernoise
<wolfspra1l>
it's either a problem in xiangfu's binaries, or with that specific kbd I bought
<lekernel>
do you have a USB bus analyzer?
<wolfspra1l>
lekernel: is it possible that kbd & mouse attached at dc-jack insertion time makes the 'unbootable state' problem more likely? is there a possible connection?
<wolfspra1l>
no, unfortunately not [usb bus analyzer]
<lekernel>
yeah, absolutely, it could change the power ramp speed and affect reset timing (and trigger the bug)
<lekernel>
but that should be sorted out with the addition of the reset IC as well
<wolfspra1l>
I would not worry about those bugs right now, I really buy cheap crap keyboards on the street.
<wolfspra1l>
those keyboards will go to xiangfu, then him or you can decide whether it's worth to fix those bugs
<wolfspra1l>
if we can source a rubber kbd for a few usd, we may well include on in rc3, as proposed by xiangfu
<lekernel>
does xiangfu have a usb analyzer?
<lekernel>
I have a totalphase analyzer, but it's quite a piece of junk
<lekernel>
definitely not worth its price
<wolfspra1l>
what about the Beagle USB 480 / USB 12 thingies?
<lekernel>
that's what i'm talking about
<wolfspra1l>
which one of the two do you have?
<lekernel>
usb 12
<lekernel>
the software works great when your devices talk USB correctly
<lekernel>
but it breaks easily when you have some garbage
<lekernel>
which is rather cretinous for a debug tool
<lekernel>
btw the usb 480 uses the same crap software
<xiangfu>
lekernel: I don't have :(
<lekernel>
also both these devices lack the ability to observe waveforms of failed USB transmissions
<lekernel>
the software will just tell you "this packet has a problem" but you won't know more
<lekernel>
iirc wpwrak has made some USB decoding stuff
<lekernel>
it could be better and cheaper than totalphase's proprietary crap
<lekernel>
the saelae logic analyzer also does a decent job at capturing the USB waveforms but you won't get high level protocol decoding
<wolfspra1l>
I don't think these keyboard problems should be our #1 priority right now
<wolfspra1l>
I will eventually find one that just works
<wolfspra1l>
and we see whether we can include a cheap rubber one in rc3
<wolfspra1l>
that will give us time to fix usb bugs one by one
<wolfspra1l>
kristianpaul: you still don't have any memory card that works, right?
<xiangfu>
already order 4 rubber keyboards in tobao today. will get them in 2~3days
<wolfspra1l>
maybe xiangfu can mail you one with an airmail letter, just so we get another option on the way
<kristianpaul>
lekernel: please can you please pusblish a bitstream for last flickernoise ?
<lekernel>
for the memory card I think the way to go is to copy linux/bsd code
<lekernel>
memory cards are messy, let's use proven code
<kristianpaul>
(copy linux/bsd code) agree
<lekernel>
kristianpaul: coming
<kristianpaul>
i dont have time to compile it know at lasbsurlab, have workshop tomorrow
<kristianpaul>
s/know/now
<kristianpaul>
thanks !
<kristianpaul>
wolfspra1l: hi, yes
<lekernel>
i'll try to fix some ethernet bugs before
<wolfspra1l>
xiangfu: can you airmail a memory card that works for you to kristianpaul?
<lekernel>
what time is your workshop?
<wolfspra1l>
just into a regular letter (attach with tape to normal paper, should be fine)
<xiangfu>
wolfspra1l: sure.
<kristianpaul>
tomorrow
<wolfspra1l>
it may still not work for kristianpaul, but it's another attempt we try in parallel to the other attempts
<xiangfu>
kristianpaul: no brand in the memcard. bought at street small shop.
<wolfspra1l>
it doesn't even matter how fast the letter arrives, or whether it arrives at all
<kristianpaul>
xiangfu: :-)
<lekernel>
wolfspra1l: otoh it would be rather interesting to fix the problems that prevent kristianpaul's card from working instead
<wolfspra1l>
but considering the cost and all, maybe it can unfreeze kristianpaul from this stuckness
<wolfspra1l>
lekernel: oh sure, absolutely. I say _parallel_
<wolfspra1l>
I try to remove some stuckness.
<lekernel>
kristianpaul: can't you use the flash disk instead?
<kristianpaul>
lekernel: yes sure
<kristianpaul>
i do
<wolfspra1l>
that way we could also rule out an issue with kristianpaul's board
<kristianpaul>
just ethernet stuck at ramdon.. :/
<wolfspra1l>
it's just more hard data, if xiangfu sends a card that worked for him to kpaul
<kristianpaul>
i agree, will be a nice test
<lekernel>
yeah, ethernet bugs are the #1 pain for me atm
<wolfspra1l>
those cards are so cheap, plus a cheap airmail letter, let's just get it on the way...
<lekernel>
i'll fix them
<wolfspra1l>
lekernel: I have a question about the patch 'language'
<wolfspra1l>
are you following a standard?
<kristianpaul>
workshipt is tomorrow afaik is not about milkymsit, but i have dorkbot presentation same days (april 6)
<lekernel>
wolfspra1l: it's the milkdrop language
<wolfspra1l>
do you want to talk about this as being some sort of 'api'?
<kristianpaul>
and saturday i have a meeting with some local VJing people
<wolfspra1l>
does it have a version number?
<lekernel>
no
<wolfspra1l>
is it 100% milkdrop?
<wolfspra1l>
or with m1 specific extensions, or incomplete milkdrop?
<lekernel>
it's milkdrop with extensions
<lekernel>
and otoh some details from milkdrop are missing too
<lekernel>
we can say it's a milkdrop 'derivative'
<wolfspra1l>
maybe we should give it a new name, and version number, and declare 'stable' at some point?
<wolfspra1l>
important to get the message out that that's a stable 'API' that will stay stable for years. I think.
<lekernel>
about one third of the original milkdrop patches work in flickernoise
<lekernel>
the main reason for non-working milkdrop patches is custom waves and shapes which aren't supported atm
<wolfspra1l>
the milkdrop things are called 'presets'?
<wolfspra1l>
where does 'patches' come from?
<wolfspra1l>
maybe you want to call this 'Milkymist Patches 1.0' at some point? (the API)
<kristianpaul>
i gotta go, have a semnira to assist in 30 minutes..
<wolfspra1l>
or 0.1, or whatever
<lekernel>
yeah, patch == milkdrop preset
<xiangfu>
kristianpaul: please send me your address and phone number. I will send you two. 512MB and 1GB memcard
<wolfspra1l>
why 'patch'?
<wolfspra1l>
you created that name?
<lekernel>
no, it's used in other AV software too
<lekernel>
puredata and maxmsp for example
<lekernel>
as a matter of fact, it doesn't come from me. someone who's into music (and little into tech) called that a "patch" when I showed it to her
<lekernel>
and I thought that was a good name
<wolfspra1l>
oh sure, I'm just curious so if I talk about it it's not total nonsense
<wolfspra1l>
maybe we should call that 'Milkymist Patches API'?
<lekernel>
scratch API
<wolfspra1l>
yes, agreed
<wolfspra1l>
just to get my point across
<wolfspra1l>
but then 'P'atches with capital 'P' has a verison number, and is stable or not, and backward compatibility is guaranteed or not
<wolfspra1l>
at least if someone asks "why should I get into this Milkymist Patches stuff - will it be around in a few years?"
<wolfspra1l>
we need a straight answer
<wolfspra1l>
I will start to capitalize patches, and talk about it as some form of stable interface.
<lekernel>
well
<wolfspra1l>
unless you don't like that for some reason
<lekernel>
many of the flickernoise patches are imported milkdrop presets which were written in 2000-2002
<wolfspra1l>
ok that's all history
<wolfspra1l>
I talk about Milkymist now
<lekernel>
I think that can be called stable :)
<wolfspra1l>
we want people to join
<lekernel>
I see no reason for breaking backward compatibility
<wolfspra1l>
you just wrote video-in patches a few days ago
<wolfspra1l>
you are missing my point
<lekernel>
video-in support is an extension over milkdrop
<wolfspra1l>
the backward compatibility is to our own stuff
<wolfspra1l>
midi, dmx, video-in
<wolfspra1l>
people want to know that 'we' = Milkymist, stand behind this 'Patches' thing
<wolfspra1l>
that it's not some random programming language that will change every 6 months
<wolfspra1l>
without proper documentation, breaking backward compatibility, etc.
<wolfspra1l>
if we can say 'no' to all these things, it's good - more people will join I think
<lekernel>
we can say 'no'
<wolfspra1l>
that's what I'm trying to understand with my questions
<wolfspra1l>
cool, perfect
<lekernel>
I'm documenting it, too
<wolfspra1l>
we need to think about versioning then, at some point (not urgent)
<wolfspra1l>
to get the message across
<wolfspra1l>
another quick question - you are working on llhdl
<wolfspra1l>
is it already possible to create the m1 bitstream with llhdl?
<lekernel>
no, not yet
<lekernel>
it will take time. and LLHDL is just a side project, my main priorities are on m1 and flickernoise
<lekernel>
there are many things to sort out in LLHDL before it can handle something as complex as MM SoC
<lekernel>
also, the p&r tools (which aren't part of llhdl) would need some work too. and I don't like the current antares architecture and am thinking about redoing it completely
<lekernel>
but anyway. those are hobby projects :-)
<wolfspra1l>
lekernel: got it. thanks.
<lekernel>
btw, software with functionality equivalent to what LLHDL aims for have ~30k¬ licenses. it's non-trivial stuff to write that won't get done over a few weeks :-)
<wolfspra1l>
sure, fully understood. I was just curious where it stands.
<wolfspra1l>
calling it a day, n8
<lekernel>
Fallenou: what is CPU_U32_FIX and ipalign() ?
<Fallenou>
something I pasted from the tsmac driver
<Fallenou>
from lm32_evr bsp
<lekernel>
extern void *malloc(size_t); ? can't use stdlib.h?
<Fallenou>
lekernel: don't remember why I've put that
<Fallenou>
I guess I needed it
<Fallenou>
malloc was some kind of a define I has to #undef
<Fallenou>
line 37
<Fallenou>
I had*
<lekernel>
ok
<lekernel>
      txq = 2048;
<lekernel>
      if (txq < ifp->if_mtu)
<lekernel>
        break;
<lekernel>
what is that doing? txq isn't used elsewhere
<lekernel>
(in txdaemon)
<lekernel>
also I guess the MTU will always be less than 2048, no?
<lekernel>
is there a reason for having this code, or is it just copy and paste cruft that should be removed?
<Fallenou>
it's clearly copy pasted from tsmac
<lekernel>
ok, removing
<Fallenou>
yep
<lekernel>
from my understanding it does nothing anyway
<Fallenou>
I think it's useless
<Fallenou>
and it does no do more in tsmac code :)
<Fallenou>
Maybe they copy pasted it too
<lekernel>
btw are braces on the line after if/for a requirement for rtems code?
<Fallenou>
don't remember
<lekernel>
yeah there is a lot of copy and paste and cruft in rtems bsp's unfortunately
<lekernel>
same with filesystems, but people more often need new BSPs than new filesystems
<lekernel>
and can also be put off by crap like eval_path
<lekernel>
Fallenou: why do you check for sc->txDaemonTid == 0 in minimac_init()? isn't that condition always verified?
<lekernel>
btw, as far as I remember, 0 is a valid RTEMS task ID
<lekernel>
i'm removing this cruft
<lekernel>
this driver will be half the size when i'm done :)
<lekernel>
Fallenou: interrupt handler routines can (and should) be static in general
<Fallenou>
lekernel: I think this "if" is there just to do some things only once
<lekernel>
no need to export them
<lekernel>
Fallenou: minimac_init() is called only once, no?
<Fallenou>
like creating the bsdnet_newproc
<lekernel>
it would break anyway when called twice
<Fallenou>
I'm not sure
<Fallenou>
with the ifconfig up/down stuff
<lekernel>
do we have to support ifconfig down? what does that bring to the user?
<lekernel>
it's a lot less valuable than stable, simple and quickly developed ethernet
<Fallenou>
anyway i'm not sure minimac_init() is just called once
<lekernel>
that's an easy check, just add printf at the beginning
<Fallenou>
the real init, called *once* is rtems_minimac_driver_attach
<lekernel>
a bit like replacing the CRC btw
<lekernel>
ah, yeah, there's this stop thing
<Fallenou>
if there is a check, it's surely because it's called afterward somehow and we don't want to create extra proc
<Fallenou>
for the txq I agree it was nonsens
<lekernel>
let's leave that aside, it's an unimportant feature (especially compared to stability)
<Fallenou>
but I would let the if if I were you
<lekernel>
no, i'll just strip out all that ifconfig up/down support that makes things a bit more complex for a near-zero value
<Fallenou>
ok
<lekernel>
btw, what is the purpose of the RX daemon? can't we just call ether_input() from the interrupt handler?
<lekernel>
what does ether_input() do anyway? are there compute-intensive parts that should go into the daemon?
<lekernel>
hm...
<lekernel>
do {
<lekernel>
      unsigned int mlen;
<lekernel>
      mlen = nm->m_len;
<lekernel>
      if (nm->m_len > 0) {
<lekernel>
        m_copydata(nm, 0, mlen, p->raw_data + len);
<lekernel>
        len += nm->m_len;
<lekernel>
      }
<lekernel>
  } while((nm = nm->m_next) != 0);
<lekernel>
can't we replace that with a single call to m_copydata()?
<Fallenou>
ether_input() is passing the packet to the tcp ip stack
<lekernel>
m_copydata(mbuf, offset, len, buf)
<lekernel>
  Copy data from an _mbuf chain_
<lekernel>
so clearly, m_copydata() already handles chained mbuf's
<lekernel>
no need to re-do it by hand
<Fallenou>
strange that it works so :o
<lekernel>
well that code works
<lekernel>
it's just unnecessarily complex, bloated and bug-prone
<lekernel>
nm->m_len is the length of that one particular mbuf, not of the chain
<Fallenou>
oh ok
<Fallenou>
so we can put the total length?
<lekernel>
m_length(mbuf, last)
<lekernel>
  Return the length of the mbuf chain
<lekernel>
where did you get that m_copydata code from?
<Fallenou>
lekernel: ether_input *cannot* be called from interrupt handler
<Fallenou>
impossible
<lekernel>
why not?
<Fallenou>
it's the whole tcp ip stack
<Fallenou>
behind ether_input()
<lekernel>
so what?
<Fallenou>
so if you put that in the handler
<Fallenou>
it will take forever to compute
<xiangfu>
make the 'mkyaffs2image' works :)
<Fallenou>
wo :)
<lekernel>
what does that do anyway? decode packets, then fill the applications' socket buffers?
<Fallenou>
it's much more complex than that
<Fallenou>
you have decoding several layers
<Fallenou>
and a tcp state machine
<Fallenou>
which merge packets together, re order them
<lekernel>
there must be some kind of locking too
<Fallenou>
i'm pretty sure this can sleep
<Fallenou>
and we should not sleep in the handler :)
<lekernel>
sleep on what?
<Fallenou>
don't know
<lekernel>
hmm... the rtems bsp guide also recommends using a RX task
<Fallenou>
well yes I read the guides, documentations, and other bsp drivers to write the milkymist one :)
<lekernel>
well, having some critical thinking helps too :)
<Fallenou>
let's ask Joel maybe you're right
<Fallenou>
and ether_input() just feels a buffer
<lekernel>
i'll check the code
<Fallenou>
and the complex tcp ip stack reads this buffer
<lekernel>
this is merely calling IF_ENQUEUE()
<lekernel>
with splimp() and splx() calls for locking
<lekernel>
there's also a call to schednetisr(NETISR_{IP,ARP}) which I guess triggers another "daemon" with the TCP/IP task
<lekernel>
no need to stack daemons...
<Fallenou>
isn't schednetisr some kind of scheduler call ?
<lekernel>
no, it's just calling rtems_event_send()
<lekernel>
and I guess IF_ENQUEUE wouldn't sleep/block either, since it's preceded by
<lekernel>
if (IF_QFULL(inq)) {
<lekernel>
IF_DROP(inq);
<lekernel>
m_freem(m);
<lekernel>
}
<lekernel>
to me the only possible troublemaker is the spl* functions
<Fallenou>
so I forgot to use the proper locking :x
<lekernel>
hmm ok... we don't really need malloc anyway
<lekernel>
Fallenou: the Ethernet core always assert its interrupt line when a slot is in state PENDING
<lekernel>
so when you do printk("No rx buffers left in the pool! We are in big troubles!\n"); and then ack the interrupt without emptying the slot before, the interrupt stays asserted forever and the board runs the ISR in a loop without having time to refill RX buffer
<lekernel>
so, yes, in fact we are in big trouble as everything crashes then :-)
<Fallenou>
so the message is correct :'
<Fallenou>
has a look
<Fallenou>
oh ok
<Fallenou>
I didn't give that much thought about that case
<Fallenou>
because it is not meant to happen
<Fallenou>
if this happens we are not servicing interrupt fast enough
<lekernel>
btw you shouldn't call bsp_interrupt_vector_{disable,enable} in the ISRs
<lekernel>
lots of bugs I'm unrooting here it seems :-)
<Fallenou>
well there is no need for the interrupt_vector_{disable,enable} anymore indeed
<Fallenou>
lekernel: it was needed before, when the unloading of the slot was done in the rxDaemon
<Fallenou>
the handler disabled the interrupt
<Fallenou>
and the daemon reEnabled the interrupt
<Fallenou>
so that the handler doesn't get called in an infinite loop
<Fallenou>
but now it's unneeded
<lekernel>
i'm actually wondering if bsp_interrupt_vector_enable wouldn't re-enable interrupts globally, resulting in more bugs and breakage when a packet is received
<lekernel>
anyway
<lekernel>
it shouldn't be put in the isr, period
<Fallenou>
yes
<lekernel>
Fallenou: you shouldn't either read the packet slot status in rxdaemon when you already do that in the isr...
<lekernel>
and even less ack interrupts in the daemon
<Fallenou>
oh that's in the case of a RX FIFO overflow
<Fallenou>
I never really knew what to do in this case
<Fallenou>
where do I read slot status in the rxDaemon ?
<Fallenou>
don't have that in my code :o
<lekernel>
in this case, writing hopelessly broken code doesn't look like much of a solution :-p
<Fallenou>
well I guess I asked there what to do if a fifo overflow happens
<Fallenou>
but this code comes from the first version of the driver
<lekernel>
you don't read slot status, but in case of FIFO overflow you print a warning and clear the reset bit, which is the good thing to do except that it should be done in the ISR before checking the slot status
<lekernel>
then you mess up the interrupts
<Fallenou>
yes I do again the wrong vector_enable
<Fallenou>
It's a good thing to have multiple people looking at the code ^^
<Fallenou>
well ok I should have moved the check for fifo overflow to the handler too
<Fallenou>
what is the benefit of checking for fifo overflow inside the handler ?
<lekernel>
usually I could get away quickly and without much hassle from those situations by using rm -f on the invoked binary that I never needed, but I guess my system wouldn't work very good without cat ...
<lekernel>
this is super annoying. it breaks the serial cable
<lekernel>
and I need it just now
<lekernel>
ah... it's not fedora... it's xiangfu's script that was still running in the background somehow
<mwalle>
although gdb supports 480xxx baud out of the box
<lekernel>
maybe for later versions of the soc, it would make sense to support very high baudrate
<lekernel>
like 20Mbps on serial
<mwalle>
there are macros for baudrates up to 4mbit
<mwalle>
the chip supports 12mbit
<lekernel>
such baudrates would probably need something more clever than the current plain clock divider though
<mwalle>
and wont work with 16times oversamlping :)
<mwalle>
80/16/1 =Â Â 5mbit.. but i could not get it to work
<lekernel>
no... I have tried with the ML401... even some 400kbps had problems
<lekernel>
(but they could have been related to the level shifters or cable)
<mwalle>
480xxx worked at least with flterm the last time i tried
<mwalle>
lekernel: could you try gdb again, enabling remote debug? (set debug remote on)
<mwalle>
should print you the packets and responses
<lekernel>
sure. need to figure out again how to compile it first :p
<mwalle>
if you see sth like 'qSupported' with the same response, break hasnt worked and you are still on a shell (or some other echo service :)
<lekernel>
ok to use gdb 7.2?
<mwalle>
i hope so :)
<lekernel>
ok, let's find out :)
<mwalle>
breakpoints and watchpoints work too, but watchpoint wont advance the PC, dunno why. or who is responsible to advance it. so i suggest to use singleshot watchpoints only :)
<lekernel>
ah, much better :)
<lekernel>
congratz :)
<lekernel>
btw, if I use gcc -g and not strip the binary, the additional info should be removed by objcopy -Obinary, no?
<lekernel>
I'm thinking about always using -g for flickernoise builds, so we can fully exploit gdb :)
<lekernel>
if it doesn't bloat the final image that's perfect
<lekernel>
seems ok in fact :)
<lekernel>
wow, seems all gdb commands work
<lekernel>
that's mighty cool
<lekernel>
even p, step, etc. :))
<lekernel>
excellent
<mwalle>
lekernel: you specify the sections you want to copy, doesnt you?
<lekernel>
no
<lekernel>
but still it seems to omit the debug info automatically
<lekernel>
so I'll just always put them in the ELF image I think
<mwalle>
$(OBJCOPY) $(SEGMENTS) -O binary $< $@
<mwalle>
for bios.bin
<mwalle>
SEGMENTS=-j .text -j .data -j .rodata
<lekernel>
flickernoise doesn't have this
<lekernel>
in fact I think it could be removed from the BIOS too :-)
<mwalle>
mh ok, dunno what -Obinary copies by default :)
<lekernel>
gdb works really great in flickernoise
<lekernel>
with symbols etc.
<lekernel>
thanks for that :)
<mwalle>
unfortunately theres no threadig support ;)
<lekernel>
it's still usable
<mwalle>
btw theres a pycon video about gdb and python support