| --- Log opened Fri Dec 13 00:00:06 2013 | ||
| * olofk_ is waiting for Fedex to show up with a shiny new Jolla phone | 09:22 | |
| * _franck_web_ is waiting for olofk_ to take a look at his github pull request :) | 09:36 | |
| olofk_ | :( | 09:37 |
|---|---|---|
| _franck_web_ | thanks :) | 09:47 |
| olofk_ | Nice and clean patches | 09: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 system | 10:02 |
| _franck_web_ | aren't tb_src_files files build anyway ? let me look at the code | 10:03 |
| olofk_ | There might be some bugs there | 10: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 them | 10:04 |
| _franck_web_ | ok | 10:05 |
| _franck_web_ | your code should be right. Now I understand why | 10: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.txt | 10:13 |
| olofk_ | Don't study that file too hard. I'm sure you will find plenty of missing stuff :) | 10:18 |
| maxpaln | Hi all - progress is being made | 11:58 |
| maxpaln | the ethmax tx, rx and rxtx tests are all passing | 11:58 |
| maxpaln | but the other two tests - rxtxoverflow and rxtxcallresponse do not complete the simulation | 11:59 |
| maxpaln | in the callresponse the simulation is waiting here: | 11:59 |
| maxpaln | in main() in ethmac-rxtxoverflow.c: while(1); // Sit and wait for test to finish in interrupt-triggered code | 11:59 |
| maxpaln | so I am guessing something is not working with the interrupts - | 12:00 |
| maxpaln | I fixed the interrupt problem that was preventing the tx and rxtx test from working - so this must be another interrupt related issue | 12:01 |
| maxpaln | but here is the problem - I am struggling to understand how the interrupt will trigger the end of the test | 12:01 |
| maxpaln | or put another way, I am struggling to work out how to debug this one! | 12:01 |
| maxpaln | any clues? | 12:01 |
| maxpaln | ok, 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 |
| maxpaln | the for loop syntax is never ending because the comparison is an assignment - I presume it was supposed to be a '<=' | 12:34 |
| maxpaln | maybe this was fixed in orpscov3 | 12:34 |
| olofk_ | Woohoo! My phone has arrived | 12:47 |
| olofk_ | maxpaln: orpsocv3 doesn't contain any test cases. We have decided to move test cases to a separate repository | 12:48 |
| maxpaln | ah, ok | 12:56 |
| maxpaln | well you should probably check that the syntax error is fixed in ethmax-rxtxcallresponse.c :-) | 12:56 |
| olofk_ | Definitiely. Thanks for reporting it | 12:57 |
| maxpaln | no worries - if I knew what I was doing I'd fix it myself, maybe i'll get there soon enough :-) | 12:57 |
| maxpaln | out of interest - how long should ethmax-rxtxoverflow take to run | 12:59 |
| maxpaln | I presume minutes at most - | 12:59 |
| maxpaln | can 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 |
| maxpaln | In simulation I can see the interrupt being issued by the ethmac | 13:05 |
| maxpaln | but I am struggling to see how this would ultimately result in the simulation ending - | 13:05 |
| maxpaln | I presume, from the name of the test, that the or1200 unit should somehow issue an error tot eh ethmac interface or something similar | 13:06 |
| maxpaln | but it isn't clear | 13: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 expected | 13:32 |
| maxpaln | I guess that is what I am finding | 13:32 |
| olofk_ | Haven't run the orpsocv2 eth tests though, but I'm afraid that you shouldn't trust the test cases compeletely | 13:32 |
| olofk_ | One thing you could do is to run the tests against a known good system | 13:32 |
| maxpaln | I 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 correctly | 13:32 |
| olofk_ | Lack of time. Would have loved to help out more otherwise :/ | 13:33 |
| maxpaln | Unfortunately I don't have a vanilla install here - at least not one that includes the ethmax | 13:33 |
| maxpaln | ethmac | 13:33 |
| maxpaln | no worries - I understand | 13:33 |
| maxpaln | well, 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 more | 13:34 |
| olofk_ | There is an extremely large test bench for ethmac in the upstream repo. Might that be of any help? | 13:38 |
| maxpaln | very possibly - | 13:38 |
| maxpaln | thanks - I'll look into that | 13:39 |
| maxpaln | hmmm 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 enabled | 13:50 |
| maxpaln | but the test only sends one packet - so neither of these conditions are met | 13:51 |
| maxpaln | Not 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 Linux | 14:12 |
| olofk_ | _franck_web_: Yes. I have been thinking about similar things too | 14:54 |
| _franck_web_ | or even more cool, a bridge to the hardware via a JTAG connection | 14:56 |
| olofk_ | I wonder if etherbone could be used ther | 15: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 kernels | 15:01 |
| -!- Netsplit *.net <-> *.split quits: larmbr | 16:37 | |
| -!- Netsplit *.net <-> *.split quits: larmbr | 16:49 | |
| --- Log closed Sat Dec 14 00:00:08 2013 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!