| --- Log opened Thu Dec 12 00:00:05 2013 | ||
| maxpaln | Not sure how to send a message to one person (new to IRC) but I am now online olofk | 10:19 |
|---|---|---|
| _franck_web_ | you can highlight olofk_ putting his nick in your sentense (and you can type "olo" then tab) | 10:25 |
| stekern | maxpaln: /query or /msg would do that | 10:25 |
| stekern | but keeping conversion public and pinging him like _franck_web_ said is usually better | 10:26 |
| maxpaln | ok, that would work - so I guess my first message with his nickname at the end would have worked | 10:27 |
| maxpaln | I checked ont he logs and saw olofk was trying to catch me onlone | 10:27 |
| maxpaln | online | 10:27 |
| maxpaln | Out of interest, do either of you know much about the ethmac implementation - I am trying to debug why it isn't working in the ORPSOC I am porting to our ECP3 family | 10:28 |
| stekern | I think olofk_ knows a bit, I've looked at it and got afraid... :/ | 10:28 |
| maxpaln | :-) yeah, I am diving down into it now - | 10:29 |
| stekern | it's one of those cores that has a nice infrastructure around it (linux driver, widely used), but the implementation itself is pretty crapish | 10:30 |
| maxpaln | I am assuming the code works (a fair assumption I think) and that there is a problem in how I have plugged it into the ORSOC. | 10:30 |
| stekern | the thought of rewriting it completely from the spec on several occasions | 10:30 |
| stekern | but yes, it works. I think it has a fair amount of CDC problems though | 10:31 |
| maxpaln | At the moment I am just trying to get the basic simulation working: ethmac-tx | 10:31 |
| stekern | ok, I think that should work at least | 10:32 |
| maxpaln | I got as far as noticing that that the issue seems to be when the TX buffer loops back to 0 - there is a check in the C code to wait until the core is no longer 'busy' | 10:32 |
| maxpaln | for the first n packets this works fine | 10:32 |
| maxpaln | but as soon as the number of packets is greater than the buffer size - as defined by OETH_TXBD_NUM in ethmac-tx.c - the check for 'busy' never returns false, i.e. the core is always busy | 10:33 |
| stekern | maxpaln: were you working with orpsocv2 or orpsocv3? | 10:44 |
| maxpaln | currently orpsocv2 - will be porting over to v3 soon enough but I'm right in them middle of getting everything working right now | 10:46 |
| maxpaln | that is unless you tell me that this test doesn't work in v2 :-) | 10:46 |
| stekern | no, I think it should work. We are in the transit of moving stuff over to orpsocv3, but the ethmac have been used a lot more in v2 than v3 | 10:52 |
| maxpaln | yeah - i thought it was a safe assumption | 10:52 |
| stekern | that said, I'm not sure if that particular test have been excercised well enough | 10:53 |
| maxpaln | ok | 10:54 |
| maxpaln | I can see that out of the box it should try and transmit about 46 packets (1024-40)/21 - not sure why those values were chose, maybe it's an ethernet thing | 10:54 |
| maxpaln | but as I've said the test just sits at this test when the 17th packet is about to be sent: | 10:55 |
| maxpaln | while ((tx_bd->len_status & OETH_TX_BD_IRQ)) | 10:55 |
| stekern | because, the test you are speaking about, it's the orpsocv2 test, right? | 10:56 |
| stekern | since you are speaking about .c code | 10:56 |
| maxpaln | yep - there are 5 tests I think | 10:56 |
| maxpaln | ethmac-rx, ethmac-tx, ethmac-rxtx.. | 10:57 |
| stekern | juliusb_ might have some insight on those | 10:57 |
| maxpaln | ethmac-rx works fine | 10:57 |
| maxpaln | the fact that it all works fine until the buffer loops back to zero is very interesting - I am wondering if there is supposed to be some 'clean up' of the buffer after the packets have been trasmitted. | 10:58 |
| stekern | hmm, could it be so simple that the tight loop that is reading the tx_bd->len_status prevents the ethmac from writing to it? | 11:07 |
| stekern | isn't the buffer descriptors in RAM? | 11:07 |
| stekern | maybe not | 11:10 |
| maxpaln | well, it pass through this check on each of the previous packets | 11:11 |
| maxpaln | as a double check, I can vary the size of the buffer (by varying OETH_TXBD_NUM) and see the number of successful bytes sent vary accorindly | 11:12 |
| stekern | yes, but didn't you say that it's when you run out of buffer descriptors that it hangs? | 11:12 |
| maxpaln | yep - | 11:13 |
| maxpaln | or at least it never clears that check | 11:13 |
| maxpaln | I have got as far as understanding that the ethmac wishbone interface includes a buffer ram | 11:13 |
| stekern | so, my theory would be sound for that, it's not going to be busy if it has never been used. | 11:14 |
| maxpaln | I *think* this is where the buffer descriptors are cached - so when the C code checks for tx_bd->len_status & OETH_TX_BD_IRQ it reads the relevant address from this RAM | 11:15 |
| stekern | that said, I don't believe in my theory, since it seems like the buffer descriptors are not in RAM (only the buffers themselves are) | 11:15 |
| stekern | and when I say RAM, I mean main RAM, not some internal RAM specific to the ethmac | 11:16 |
| maxpaln | ah, ok - | 11:17 |
| maxpaln | I would agree that as long as the buffer descriptor has not been used it is fine - | 11:17 |
| maxpaln | the problems occur when reuse of an existing buffer descriptor is attempted | 11:18 |
| maxpaln | I got as far as (last night) checking to see what might clean up the buffer descriptor once the packet was sent - | 11:18 |
| maxpaln | I am now multi-tasking about 4 things so I haven't got to the bottom of it yet | 11:18 |
| stekern | maxpaln: ah, reading the code a bit more, I think I might know what's the problem | 11:22 |
| maxpaln | <waits with baited breath> | 11:22 |
| stekern | have you connected the interrupt properly, and if so, is it executed? | 11:22 |
| maxpaln | this is a very good question - | 11:22 |
| maxpaln | how should it be connected? | 11:22 |
| maxpaln | <is my naivety obvious enough> | 11:23 |
| stekern | not sure from the top of my head ;) | 11:23 |
| stekern | but the flag that you get stuck on is cleared in the interrupt handler in ethmac-tx.c | 11:23 |
| stekern | so the loop is basically waiting for an irq to happen | 11:23 |
| maxpaln | ah, ok | 11:24 |
| maxpaln | This looks VERY promising | 11:25 |
| maxpaln | I think you have spotted the core problem - let me do a little fixing and I'll report back | 11:27 |
| stekern | soudns good | 11:27 |
| stekern | sounds too | 11:38 |
| maxpaln | looking very good - it's working through the packets now | 11:43 |
| maxpaln | perfect - all done. Many Thanks - you've saved me alot of debug there | 11:46 |
| maxpaln | :-) | 11:46 |
| stekern | my pleasure | 11:47 |
| mathias` | Hello, I am currently using orpsocv3 together with a DE1 FPGA and am trying to add a new gpio slave. I've found the wb_intercon.conf file and read that there may be a generator that reads this configuration file. Is that true? Because I am unable to find it | 11:54 |
| stekern | maxpaln: the generator is here: https://github.com/openrisc/orpsoc-cores/blob/master/cores/wb_intercon/sw/wb_intercon_gen | 11:58 |
| stekern | err... mathias` | 11:58 |
| mathias` | stekern: Thanks | 12:02 |
| olofk_ | maxpaln: I mostly wanted to say that it's good to see Lattice involvement, check in on the progress and offer my help as ethmac and orpsocv3 maintainer | 12:39 |
| olofk_ | But it looks like stekern provided you with good guidance | 12:40 |
| olofk_ | Oh.. and I was interested in how you build the stuff for your (was it ECP3?) board. It would be awesome to have a scripted workflow for the Lattice toolchain | 12:41 |
| olofk_ | No one has sent me any boards (hint, hint) so I haven't prioritized in getting those parts running | 12:42 |
| maxpaln | yep - got good advice from stekern - just running through the other tests now | 12:44 |
| maxpaln | noticed I am getting a Bus Error exception on the overflow test | 12:44 |
| maxpaln | need to investigate that one | 12:44 |
| maxpaln | I am targetting an ECP3 versa board at the moment | 12:45 |
| maxpaln | My aim is to have a Linux build running on the uP for a customer | 12:45 |
| maxpaln | I am very close to having the HW working, the Ethernet MAC is the last portion to fix | 12:46 |
| maxpaln | then I need to work out how to build the linux kernel for the processor - I haven't tried that yet but I am sure it isn't too difficult. | 12:46 |
| olofk_ | It shouldn't be that hard. Hopefully we can guide you through potential issues | 12:47 |
| maxpaln | I am sure - but first I need to fix the Bus Error problems. Last time it was because the internal RAM I was using was too small, but that's unlikely to be the cause this time. | 12:48 |
| maxpaln | not started to debug yet though - something for this afternoon. Fisrt I need to run a few errands. | 12:49 |
| maxpaln | back online now! | 15:54 |
| maxpaln | anyone got a good idea for how to start debugging a Bus Error during simulation: | 15:55 |
| maxpaln | # KERNEL: (1107869.00 ns)(orpsoc_testbench.eth_phy0)MIIM - received correct PHY ADDRESS: 00 | 15:55 |
| maxpaln | # KERNEL: (1107869.00 ns)(orpsoc_testbench.eth_phy0)MIIM - WRITING to register 00 COMPLETED! | 15:55 |
| maxpaln | # KERNEL: EPC = 0x0000020c | 15:55 |
| maxpaln | # KERNEL: A Bus Error exception occured. | 15:55 |
| maxpaln | # KERNEL: EPC = 0x0000140c | 15:55 |
| maxpaln | # KERNEL: report(0x0000020c); | 15:55 |
| maxpaln | # KERNEL: report(0x0000140c); | 15:55 |
| maxpaln | # KERNEL: exit(5132) | 15:55 |
| maxpaln | it's during the ethmac-rxtxoverflow | 15:55 |
| maxpaln | standard simulation test - the bus error isn't reported with a time so it's difficult to trace back what exactly caused the Bus Error! | 15:56 |
| _franck_web_ | you could watch the or1200 bus exception signal (which is ?) | 15:58 |
| maxpaln | ah, good idea | 15:58 |
| maxpaln | I think it is or1200_pic_ints in the orpsoc_top.v | 15:59 |
| _franck_web_ | should be here | 15:59 |
| maxpaln | ok, no activcity on or1200_pic_ints | 16:00 |
| maxpaln | hang on - that's the interrupt signal not the exception signal | 16:00 |
| stekern | exactly | 16:02 |
| maxpaln | the wishbone error signal from the or1200 is probably a good bet though | 16:02 |
| maxpaln | it gets asserted at around the point where Iwould expect the error to have occurred - | 16:03 |
| maxpaln | this should point me in the right direction | 16:03 |
| stekern | yes, or watch 0x200 on PC | 16:03 |
| maxpaln | thanks | 16:04 |
| maxpaln | ok got there - EthMac requires at least 32MByte of memory space. I only had 8 MByte! | 16:26 |
| maxpaln | interestingly the Xilinx board design (which I used as my template) has a RAM_WB component (which is selectable even though it makes no sense from a HW point of view) includes the ethmac and sets the RAM size to 8 MB - this should probably be modified - or at least change depending on whether the ethmac is included | 16:27 |
| maxpaln | something like: | 16:27 |
| maxpaln | `ifdef ETH0 | 16:27 |
| maxpaln | defparam ram_wb0.mem_size_bytes = (32768*1024); // 32MB | 16:27 |
| maxpaln | defparam ram_wb0.mem_adr_width = 25; // log2(32768*1024) `else | 16:27 |
| maxpaln | defparam ram_wb0.mem_size_bytes = (8192*1024); // 8MB | 16:27 |
| maxpaln | defparam ram_wb0.mem_adr_width = 23; // log2(8192*1024) `endif | 16:27 |
| _franck_ | olofk: what is the idea behind having tb_private_src_files in orpsoc ? | 22:00 |
| --- Log closed Fri Dec 13 00:00:06 2013 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!