IRC logs for #openrisc Friday, 2013-12-13

--- Log opened Fri Dec 13 00:00:06 2013
* olofk_ is waiting for Fedex to show up with a shiny new Jolla phone09:22
* _franck_web_ is waiting for olofk_ to take a look at his github pull request :)09:36
_franck_web_thanks :)09:47
olofk_Nice and clean patches09:55
_franck_web_olofk_: why do we have tb_*private*_src_files ?10:01
olofk_For example to avoid compiling a lot of block level test benches when we simulate larger system10:02
_franck_web_aren't tb_src_files files build anyway ? let me look at the code10:03
olofk_There might be some bugs there10:03
olofk_But the idea is that things like test bench helper code (wb_bfm, uart_models...) shall go in tb_src_files, so that other cores can use them if we depend on them10:04
_franck_web_your code should be right. Now I understand why10:07
olofk_I should probably put a link to the IRC logs in orpsoc's doc directory :)10:12
_franck_web_:) BTW, tb_private_src_files in not in capi.txt10:13
olofk_Don't study that file too hard. I'm sure you will find plenty of missing stuff :)10:18
maxpalnHi all - progress is being made11:58
maxpalnthe ethmax tx, rx and rxtx tests are all passing11:58
maxpalnbut the other two tests - rxtxoverflow and rxtxcallresponse do not complete the simulation11:59
maxpalnin the callresponse the simulation is waiting here:11:59
maxpalnin main() in ethmac-rxtxoverflow.c: while(1); // Sit and wait for test to finish in interrupt-triggered code11:59
maxpalnso I am guessing something is not working with the interrupts -12:00
maxpalnI fixed the interrupt problem that was preventing the tx and rxtx test from working - so this must be another interrupt related issue12:01
maxpalnbut here is the problem - I am struggling to understand how the interrupt will trigger the end of the test12:01
maxpalnor put another way, I am struggling to work out how to debug this one!12:01
maxpalnany clues?12:01
maxpalnok, tracked one of them back to a bug in the ethmac-extxcallresponse.c file - main() contains this:12:33
maxpaln  for(num_to_check=0;num_to_check=1000;num_to_check++);12:33
maxpalnthe for loop syntax is never ending because the comparison is an assignment - I presume it was supposed to be a '<='12:34
maxpalnmaybe this was fixed in orpscov312:34
olofk_Woohoo! My phone has arrived12:47
olofk_maxpaln: orpsocv3 doesn't contain any test cases. We have decided to move test cases to a separate repository12:48
maxpalnah, ok12:56
maxpalnwell you should probably check that the syntax error is fixed in ethmax-rxtxcallresponse.c :-)12:56
olofk_Definitiely. Thanks for reporting it12:57
maxpalnno worries - if I knew what I was doing I'd fix it myself, maybe i'll get there soon enough :-)12:57
maxpalnout of interest - how long should ethmax-rxtxoverflow take to run12:59
maxpalnI presume minutes at most -12:59
maxpalncan you give me a quick pointer at how the interrupt process should work - I am trying to workout why the rxtxoverflow test isn't completing?13:04
maxpalnIn simulation I can see the interrupt being issued by the ethmac13:05
maxpalnbut I am struggling to see how this would ultimately result in the simulation ending -13:05
maxpalnI presume, from the name of the test, that the or1200 unit should somehow issue an error tot eh ethmac interface or something similar13:06
maxpalnbut it isn't clear13:06
olofk_maxpaln: When I used the orpsocv2 tests for regression testing in orpsocv3 I noticed that some of the test cases were quite picky and could end up in infinite loops if the RTL wasn't set up as the test case expected13:32
maxpalnI guess that is what I am finding13:32
olofk_Haven't run the orpsocv2 eth tests though, but I'm afraid that you shouldn't trust the test cases compeletely13:32
olofk_One thing you could do is to run the tests against a known good system13:32
maxpalnI am trying to decide if it means there is a problem in the RTL (which I definitely want to fix) or whether it is just that the test isn't quite set correctly13:32
olofk_Lack of time. Would have loved to help out more otherwise :/13:33
maxpalnUnfortunately I don't have a vanilla install here - at least not one that includes the ethmax13:33
maxpalnno worries - I understand13:33
maxpalnwell, I'm inclined to assume that the RTL is ok - but I might spend another half an hour or so walking through the process to try and understand it a little more13:34
olofk_There is an extremely large test bench for ethmac in the upstream repo. Might that be of any help?13:38
maxpalnvery possibly -13:38
maxpalnthanks - I'll look into that13:39
maxpalnhmmm ok so I've concluded that the test must be wrong - it appears to exit with success if 4 packets are sent OR if four buffers are identified that have the interrupt enabled13:50
maxpalnbut the test only sends one packet - so neither of these conditions are met13:51
maxpalnNot being an ethernet man, I am not sure what conditions constitute an overflow - but this test doesn't appear to exercise anything other than a standard Tx packet test. I'm gonna move on - I thinkthis test should probably be review and fixed or removed.13:52
_franck_web_wouldn't be great to have a ork1sim peripheral acting like a whishbone master thru a vpi interface ? Am I clear ? We could test real RTL device with or1ksim running Linux14:12
olofk__franck_web_: Yes. I have been thinking about similar things too14:54
_franck_web_or even more cool, a bridge to the hardware via a JTAG connection14:56
olofk_I wonder if etherbone could be used ther15:00
olofk_It's the guys at CERN who have made something that I think is wishbone over ethernet. There's support for it in the later Linux kernels15:01
-!- Netsplit *.net <-> *.split quits: larmbr16:37
-!- Netsplit *.net <-> *.split quits: larmbr16:49
--- Log closed Sat Dec 14 00:00:08 2013

Generated by 2.15.2 by Marius Gedminas - find it at!