| --- Log opened Tue Jul 11 00:00:09 2017 | ||
| stekern | shorne: AFAIR that needs to be enabled for multicore, but I need to take a look to refresh my memory | 02:19 |
|---|---|---|
| promach | stekern: would your ILA be able to do something like Figure 1 of http://zipcpu.com/blog/2017/06/08/simple-scope.html ? | 02:33 |
| stekern | yes, by modifying the "post trigger count" | 02:49 |
| promach | stekern: but in the README | 02:53 |
| promach | Set trigger and start logging | 02:53 |
| promach | Figure 1 is looking 'back' into the *past* | 02:54 |
| promach | stekern: how does modifying the "post trigger count" will emulate Figure 1 ? | 02:57 |
| shorne | stekern: thanks, thats what I see too. I just couldn't find any orpsoc-cores examples where you have it enabled, so I thought a bit strange | 03:16 |
| shorne | Ill another look | 03:16 |
| shorne | stekern: interesting, I found OPTION_DCACHE_SNOOP enabled in only one project, optimsoc | 03:35 |
| shorne | Interestingly they also have FEATURE_DATACACHE set to NONE | 03:36 |
| shorne | wallento: Do you remember why the datacache is disabled in optimsoc? | 03:36 |
| shorne | (the commit log says, temporarily) | 03:36 |
| -!- psychotr1pe is now known as psychotrope | 04:03 | |
| stekern | promach, by setting it to 0 | 04:18 |
| promach | In the README: Set trigger and start logging | 04:18 |
| promach | how is that possible to look back into past ? | 04:19 |
| stekern | "After that, data is logged into a circular buffer, until the trigger | 04:19 |
| stekern | condition is met. At this point, logging will continue for the amount | 04:19 |
| stekern | of samples that have been configured in address 0x0001." | 04:19 |
| promach | wait, writing into different addresses have different meaning ? | 04:20 |
| stekern | address 0x1 == "post trigger count" | 04:20 |
| stekern | if you set it to 0, the logging stops at the trigger | 04:20 |
| promach | stekern: ok | 04:20 |
| promach | one more question: does your circular buffer allows address space wrapping around ? | 04:21 |
| promach | or you only fill in the circular buffer until it is full ? | 04:21 |
| promach | then stop | 04:22 |
| promach | and then, you will read data out of the buffer ? | 04:22 |
| promach | let me rephrase my question: does dilla write and read the circular buffer simultaneously ? | 04:23 |
| stekern | shorne: I changed the logic to be disabled by default here: https://github.com/openrisc/mor1kx/commit/e27b9e6d1afdbd0b9f8c79b8426cfbb28ec5e0ba | 04:26 |
| stekern | shorne: so, the reason you're not seeing it in my multicore repos is that it was enabled by default then | 04:26 |
| stekern | promach: the definition of a circular buffer is that you wrap around | 04:27 |
| promach | stekern: do you stop writing into circular buffer *before* you could read the data out of the circular buffer ? | 04:32 |
| promach | does your circular buffer have read pointer ? | 04:33 |
| stekern | it stops writing when a trigger condition is met. you can read data out of it while it is still running though. | 04:35 |
| promach | so, you do have a read pointer in your implementation of circular buffer | 04:37 |
| promach | what about buffer overflow ? | 04:37 |
| stekern | ? | 04:39 |
| stekern | yes, it has a read address. when a trigger condition is met, the read address is offset by the memory position that was written to when the trigger occurred | 04:41 |
| stekern | ...as well as the post trigger count | 04:42 |
| stekern | so you will get the oldest data at read address 0 | 04:42 |
| promach | stekern: buffer overflow is possible if writing rate > reading rate | 04:53 |
| stekern | well, it's not really designed to be used like that | 04:53 |
| promach | not to be used like that ? huh ? | 04:57 |
| stekern | writing rate will always be > reading rate | 04:57 |
| stekern | yeah, it is not designed to be read before the trigger has occured | 04:57 |
| stekern | it's possible to do that, but it's not a very useful thing to do | 04:58 |
| promach | wait, I have the message that your circular buffer implementation *will never* have buffer overflow issue, right ? | 05:00 |
| stekern | do you know how a circular buffer works? | 05:01 |
| promach | buffer with read and write pointer and address space could wrap around | 05:01 |
| promach | I am concerned about buffer overflow in the case of writing rate > reading rate | 05:02 |
| stekern | I'm telling you that you should read after the trigger has happened, when writing has stopped | 05:03 |
| promach | ok | 05:04 |
| stekern | the "read pointer" is updated when that happen | 05:04 |
| promach | ok | 05:04 |
| stekern | if you read before, the read pointer is 0, and you read out the memory from that offset | 05:05 |
| wallento | shorne: yes it is temporarily | 09:59 |
| wallento | we had issues with aliasing and then some other bugs | 09:59 |
| wallento | and wanted to rule out thats the issue | 09:59 |
| wallento | but we can re-activate it now | 10:00 |
| shorne | wallento: thanks, if you re-enable it let me know how you get along. I tried to enable it and was getting crashes. Ill start looking into it | 17:06 |
| wallento | oh, good datapoint | 17:06 |
| wallento | is there any indication what goes wrong? | 17:07 |
| shorne | fyi, I disabled datacache and now my issue goes away (I was seeing aliasing too) | 17:19 |
| shorne | [ 1.200000] Synchronize counters for CPU 1: done. | 17:19 |
| shorne | [ 1.330000] smp: Brought up 1 node, 2 CPUs | 17:19 |
| shorne | But I was seeing aliasing because I had dcache_snoop off | 17:20 |
| shorne | when enabling dcache_snoop (and of cource datacache) as well I got failures | 17:20 |
| shorne | wallento: however, I did not get any indicators, I just saw the kernel was not booting to give any serial | 17:21 |
| shorne | when I checked the PC / stack via gdb I just saw it running around in 0x200 and 0x800 (if I remember correctly) exceptions | 17:22 |
| shorne | 0x200 is bus error | 17:22 |
| shorne | so maybe some issue with the snoop refil/invalidate | 17:23 |
| wallento | oh, I see | 17:23 |
| wallento | lets hope not | 17:23 |
| shorne | yes, it looked very complicated | 17:23 |
| shorne | :) | 17:23 |
| shorne | Disabled for now, and got my smp patches booting on the fpga | 17:24 |
| shorne | which is first (previously it was on qemu) | 17:24 |
| shorne | but.. now I am getting some serial issue | 17:24 |
| shorne | # ls | 17:25 |
| shorne | b k 1;34mlib e 32mstrac | 17:25 |
| shorne | minit oot [1;34msy[1;34met ftests34mproc 0m 4musr | 17:25 |
| shorne | (that is the output of ls command) | 17:25 |
| shorne | looks like something wrong with my serial timer setup | 17:25 |
| shorne | I am going through jtag serial | 17:25 |
| shorne | stekern: the timer sync stuff seems to work well so far (which would mean no need for the separate global timer), however a global clocksource would be a nice thing to have | 17:28 |
| shorne | I am just trying to minimize the patch set | 17:29 |
| -!- simpsota_ is now known as simpsota | 18:19 | |
| --- Log closed Wed Jul 12 00:00:10 2017 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!