IRC logs for #openrisc Thursday, 2013-12-12

--- Log opened Thu Dec 12 00:00:05 2013
maxpalnNot sure how to send a message to one person (new to IRC) but I am now online olofk10:19
_franck_web_you can highlight olofk_ putting his nick in your sentense (and you can type "olo" then tab)10:25
stekernmaxpaln: /query or /msg would do that10:25
stekernbut keeping conversion public and pinging him like _franck_web_ said is usually better10:26
maxpalnok, that would work - so I guess my first message with his nickname at the end would have worked10:27
maxpalnI checked ont he logs and saw olofk was trying to catch me onlone10:27
maxpalnOut 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 family10:28
stekernI 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
stekernit's one of those cores that has a nice infrastructure around it (linux driver, widely used), but the implementation itself is pretty crapish10:30
maxpalnI 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
stekernthe thought of rewriting it completely from the spec on several occasions10:30
stekernbut yes, it works. I think it has a fair amount of CDC problems though10:31
maxpalnAt the moment I am just trying to get the basic simulation working: ethmac-tx10:31
stekernok, I think that should work at least10:32
maxpalnI 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
maxpalnfor the first n packets this works fine10:32
maxpalnbut 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 busy10:33
stekernmaxpaln: were you working with orpsocv2 or orpsocv3?10:44
maxpalncurrently orpsocv2 - will be porting over to v3 soon enough but I'm right in them middle of getting everything working right now10:46
maxpalnthat is unless you tell me that this test doesn't work in v2 :-)10:46
stekernno, 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 v310:52
maxpalnyeah - i thought it was a safe assumption10:52
stekernthat said, I'm not sure if that particular test have been excercised well enough10:53
maxpalnI 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 thing10:54
maxpalnbut as I've said the test just sits at this test when the 17th packet is about to be sent:10:55
maxpalnwhile ((tx_bd->len_status & OETH_TX_BD_IRQ))10:55
stekernbecause, the test you are speaking about, it's the orpsocv2 test, right?10:56
stekernsince you are speaking about .c code10:56
maxpalnyep - there are 5 tests I think10:56
maxpalnethmac-rx, ethmac-tx, ethmac-rxtx..10:57
stekernjuliusb_ might have some insight on those10:57
maxpalnethmac-rx works fine10:57
maxpalnthe 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
stekernhmm, 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
stekernisn't the buffer descriptors in RAM?11:07
stekernmaybe not11:10
maxpalnwell, it pass through this check on each of the previous packets11:11
maxpalnas 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 accorindly11:12
stekernyes, but didn't you say that it's when you run out of buffer descriptors that it hangs?11:12
maxpalnyep -11:13
maxpalnor at least it never clears that check11:13
maxpalnI have got as far as understanding that the ethmac wishbone interface includes a buffer ram11:13
stekernso, my theory would be sound for that, it's not going to be busy if it has never been used.11:14
maxpalnI *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 RAM11:15
stekernthat 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
stekernand when I say RAM, I mean main RAM, not some internal RAM specific to the ethmac11:16
maxpalnah, ok -11:17
maxpalnI would agree that as long as the buffer descriptor has not been used it is fine -11:17
maxpalnthe problems occur when reuse of an existing buffer descriptor is attempted11:18
maxpalnI got as far as (last night) checking to see what might clean up the buffer descriptor once the packet was sent -11:18
maxpalnI am now multi-tasking about 4 things so I haven't got to the bottom of it yet11:18
stekernmaxpaln: ah, reading the code a bit more, I think I might know what's the problem11:22
maxpaln<waits with baited breath>11:22
stekernhave you connected the interrupt properly, and if so, is it executed?11:22
maxpalnthis is a very good question -11:22
maxpalnhow should it be connected?11:22
maxpaln<is my naivety obvious enough>11:23
stekernnot sure from the top of my head ;)11:23
stekernbut the flag that you get stuck on is cleared in the interrupt handler in ethmac-tx.c11:23
stekernso the loop is basically waiting for an irq to happen11:23
maxpalnah, ok11:24
maxpalnThis looks VERY promising11:25
maxpalnI think you have spotted the core problem - let me do a little fixing and I'll report back11:27
stekernsoudns good11:27
stekernsounds too11:38
maxpalnlooking very good - it's working through the packets now11:43
maxpalnperfect - all done. Many Thanks - you've saved me alot of debug there11:46
stekernmy pleasure11: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 it11:54
stekernmaxpaln: the generator is here:
stekernerr... mathias`11:58
mathias`stekern: Thanks12: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 maintainer12:39
olofk_But it looks like stekern provided you with good guidance12: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 toolchain12:41
olofk_No one has sent me any boards (hint, hint) so I haven't prioritized in getting those parts running12:42
maxpalnyep - got good advice from stekern - just running through the other tests now12:44
maxpalnnoticed I am getting a Bus Error exception on the overflow test12:44
maxpalnneed to investigate that one12:44
maxpalnI am targetting an ECP3 versa board at the moment12:45
maxpalnMy aim is to have a Linux build running on the uP for a customer12:45
maxpalnI am very close to having the HW working, the Ethernet MAC is the last portion to fix12:46
maxpalnthen 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 issues12:47
maxpalnI 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
maxpalnnot started to debug yet though - something for this afternoon. Fisrt I need to run a few errands.12:49
maxpalnback online now!15:54
maxpalnanyone 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: 0015:55
maxpaln# KERNEL: (1107869.00 ns)(orpsoc_testbench.eth_phy0)MIIM - WRITING to register 00 COMPLETED!15:55
maxpaln# KERNEL: EPC = 0x0000020c15:55
maxpaln# KERNEL: A Bus Error exception occured.15:55
maxpaln# KERNEL: EPC = 0x0000140c15:55
maxpaln# KERNEL: report(0x0000020c);15:55
maxpaln# KERNEL: report(0x0000140c);15:55
maxpaln# KERNEL: exit(5132)15:55
maxpalnit's during the ethmac-rxtxoverflow15:55
maxpalnstandard 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
maxpalnah, good idea15:58
maxpalnI think it is or1200_pic_ints in the orpsoc_top.v15:59
_franck_web_should be here15:59
maxpalnok, no activcity on or1200_pic_ints16:00
maxpalnhang on - that's the interrupt signal not the exception signal16:00
maxpalnthe wishbone error signal from the or1200 is probably a good bet though16:02
maxpalnit gets asserted at around the point where Iwould expect the error to have occurred -16:03
maxpalnthis should point me in the right direction16:03
stekernyes, or watch 0x200 on PC16:03
maxpalnok got there - EthMac requires at least 32MByte of memory space. I only had 8 MByte!16:26
maxpalninterestingly 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 included16:27
maxpalnsomething like:16:27
maxpaln`ifdef ETH016:27
maxpaln   defparam ram_wb0.mem_size_bytes = (32768*1024); // 32MB16:27
maxpaln   defparam ram_wb0.mem_adr_width = 25; // log2(32768*1024) `else16:27
maxpaln   defparam ram_wb0.mem_size_bytes = (8192*1024); // 8MB16:27
maxpaln   defparam ram_wb0.mem_adr_width = 23; // log2(8192*1024) `endif16: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 2.15.2 by Marius Gedminas - find it at!