| --- Log opened Thu Mar 17 00:00:38 2016 | ||
| wallento | shorne: It is write-through | 02:32 |
|---|---|---|
| wallento | the reason you don't see this in the code is that the cache and the store path are in parallel, I had the same problem in the beginning | 02:32 |
| wallento | so, actually it should not be too hard changing to write back, but it needs some more rework than simply changing the cache state machine | 02:33 |
| wallento | plus the cache coherency needs an update then to emit writes on a snoop bus | 02:34 |
| wallento | I have been thinking to add write back when doing the cache coherency, but decided against at this time | 02:35 |
| bandvig | wallento: Do you think that write-back cache could improve performance versus write-through+store_buffer? If "yes" how much the improvement could be in, say, CoreMark? | 02:38 |
| wallento | I don't know. The advantage of write-back vs. store buffer is on the bus load. So in a multicore system is becomes maybe more relevant | 02:39 |
| wallento | also the number of ways plays into it | 02:40 |
| wallento | and of course the application | 02:40 |
| wallento | I will have a look to find some numbers | 02:40 |
| wallento | for other architectures | 02:40 |
| wallento | I have updated the newlib build instructions: http://openrisc.io/newlib/building.html | 04:06 |
| wallento | linking in mpc, mpfr and gmp into the gcc source tree saves us the necessity to release different versions for different Linux distributions | 04:06 |
| olofk | wallento: That's good, but I really don't like bundled libs | 04:12 |
| wallento | then you should build it yourself ;) | 04:12 |
| olofk | Oh, it's only for the binary? | 04:13 |
| wallento | yep | 04:13 |
| olofk | ah ok. That's great then | 04:13 |
| wallento | its compiled into cc1 | 04:13 |
| wallento | thats also how linaro builds their stuff. I was actually wondering how they make it simple to just download one tar file | 04:14 |
| wallento | one thing thats left is relocation | 04:14 |
| wallento | libopcodes is not found automatically | 04:14 |
| wallento | It needs LD_LIBRARY_PATH pointing there | 04:14 |
| wallento | but this should also possible to work out | 04:15 |
| andrzejr | olofk, I've added a new generator (xilinx logicore) https://github.com/andrzej-r/fusesoc/commit/e8bb8e0c02e19322de0ee6e7189ece3518c70fd9 | 04:55 |
| andrzejr | and a core using it: https://github.com/andrzej-r/orpsoc-cores/commit/aac2f8ad816baa0d913da7321dc00c6e0105357f | 04:56 |
| andrzejr | afair that core synthesized correctly but I was unable to simulate it (mix of verilog/vhdl). What is the "correct" way of handling vhdl sources in fusesoc? | 05:00 |
| olofk | andrzejr: Filesets | 05:16 |
| olofk | andrzejr: I'm trying to move away from the verilog/vhdl sections | 05:16 |
| olofk | Here's and example https://github.com/openrisc/orpsoc-cores/blob/master/cores/pulpino/apb_uart.core | 05:17 |
| olofk | But if you only have a single vhdl file together with a lot of verilog files, you can set file_type = verilogSource for the whole fileset and override it for just that file, like file.vhd[file_type=vhdlSource] | 05:19 |
| shorne | wallento: thanks the reason I ask is that in ther kernel there is an option for "write through cache?" and we use it in the code. It looks related to stekern smp work | 06:36 |
| shorne | hmm, I was doing some kernel recompiling and testing, and I wiped my .config. now I cant get it to work again | 06:39 |
| shorne | the vmlinux its creating is 11mb, the old one I had was 7mb | 06:39 |
| shorne | anyone know what would cause 4m increase? using just make ARCH=openrisc de0_nano_defconfig | 06:40 |
| shorne | I think before I additionally disabled a couple things to get it down to 7mb, but whatever I try now its about 11mb | 06:40 |
| shorne | olofk: for your fileset change in wb_sdram_ctrl it looks like you missed file_type | 07:10 |
| shorne | I got an error | 07:10 |
| shorne | but fixed now | 07:10 |
| stekern | shorne: the "write through cache" actually comes from a patch that I pulled in that fixes an issue with coherency between dcache and icache | 07:21 |
| stekern | I haven't had time to fully evaluate it, but from a quick look it looked good and it doesn't seem to break anything at least | 07:22 |
| stekern | so, I decided to pull it in before it starts to bitrot | 07:22 |
| shorne | stekern: yeah I read the code, it looks good, its just that is seems to allow support for write back cache, which was a bit confusing | 07:22 |
| shorne | i.e. if we write "code" to memory through dcache, it will flush the dcache to make sure icach will not have issues when reading it | 07:23 |
| stekern | yeah, well, openrisc as an architecture supoort write back, it's just that mor1kx doesn't implement it | 07:23 |
| shorne | but is a bit strange if we dont have write back caches, but might make sense for SMP | 07:23 |
| shorne | I see | 07:23 |
| stekern | the actual issue that the patch fix is that you need to invalidate icache when you write something to memory that is intended to be executed | 07:25 |
| shorne | ah, right, so event if its write through, the icache might have thought something else was there so need to be invalidated | 07:39 |
| shorne | stekern: any thoughts of kernel upstreaming? I know you dont have much time... | 07:40 |
| stekern | shorne: yeah, I'm a bit hesitant stepping up as a maintainer, knowing I might not have the time needed as things are now... | 07:43 |
| stekern | but there are a set of patches that contains critical bugfixes, it's important to at least get those upstream | 07:44 |
| stekern | I'll try to find the time in the weekend to split out a branch with only those patches | 07:45 |
| shorne | stekern: alright, if you need I can help. Its a pretty big backlog some things should go upstream some shouldnt | 07:47 |
| shorne | its going to take some time to sort them | 07:47 |
| stekern | yep, but I kinda know which patches are critical and which are not, so shouldn't be that much work | 07:48 |
| shorne | yup, i guess you would, the MAINTAINERS file update will be a good step as well. The new mailing list should be updated there too | 07:51 |
| shorne | good my vmlinux image is down to 6mb (I must have enabled gzip before) | 07:52 |
| shorne | boot time is 7 seconds on de0 nano | 07:53 |
| shorne | seems long time between NET: Register, and futex hash table init | 07:53 |
| shorne | maybe thats the time the kernel is unzipped and moved | 07:54 |
| GeneralStupid | Ok :D | 11:19 |
| olofk | shorne: Ah crap. You're right sorry about that | 11:57 |
| olofk | shorne: Pushed a patch now | 12:01 |
| shorne | olofk: thanks I had one ready... didnt get time to push last night :) | 18:38 |
| --- Log closed Fri Mar 18 00:00:39 2016 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!