IRC logs for #openrisc Thursday, 2016-03-17

--- Log opened Thu Mar 17 00:00:38 2016
wallentoshorne: It is write-through02:32
wallentothe 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 beginning02:32
wallentoso, actually it should not be too hard changing to write back, but it needs some more rework than simply changing the cache state machine02:33
wallentoplus the cache coherency needs an update then to emit writes on a snoop bus02:34
wallentoI have been thinking to add write back when doing the cache coherency, but decided against at this time02:35
bandvigwallento: 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
wallentoI 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 relevant02:39
wallentoalso the number of ways plays into it02:40
wallentoand of course the application02:40
wallentoI will have a look to find some numbers02:40
wallentofor other architectures02:40
wallentoI have updated the newlib build instructions:
wallentolinking in mpc, mpfr and gmp into the gcc source tree saves us the necessity to release different versions for different Linux distributions04:06
olofkwallento: That's good, but I really don't like bundled libs04:12
wallentothen you should build it yourself ;)04:12
olofkOh, it's only for the binary?04:13
olofkah  ok. That's great then04:13
wallentoits compiled into cc104:13
wallentothats also how linaro builds their stuff. I was actually wondering how they make it simple to just download one tar file04:14
wallentoone thing thats left is relocation04:14
wallentolibopcodes is not found automatically04:14
wallentoIt needs LD_LIBRARY_PATH pointing there04:14
wallentobut this should also possible to work out04:15
andrzejrolofk, I've added a new generator (xilinx logicore)
andrzejrand a core using it:
andrzejrafair 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
olofkandrzejr: Filesets05:16
olofkandrzejr: I'm trying to move away from the verilog/vhdl sections05:16
olofkHere's and example
olofkBut 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
shornewallento: 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 work06:36
shornehmm, I was doing some kernel recompiling and testing, and I wiped my .config.  now I cant get it to work again06:39
shornethe vmlinux its creating is 11mb, the old one I had was 7mb06:39
shorneanyone know what would cause 4m increase? using just make ARCH=openrisc de0_nano_defconfig06:40
shorneI think before I additionally disabled a couple things to get it down to 7mb, but whatever I try now its about 11mb06:40
shorneolofk: for your fileset change in wb_sdram_ctrl it looks like you missed file_type07:10
shorneI got an error07:10
shornebut fixed now07:10
stekernshorne: the "write through cache" actually comes from a patch that I pulled in that fixes an issue with coherency between dcache and icache07:21
stekernI 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 least07:22
stekernso, I decided to pull it in before it starts to bitrot07:22
shornestekern: yeah I read the code, it looks good, its just that is seems to allow support for write back cache, which was a bit confusing07:22
shornei.e. if we write "code" to memory through dcache, it will flush the dcache to make sure icach will not have issues when reading it07:23
stekernyeah, well, openrisc as an architecture supoort write back, it's just that mor1kx doesn't implement it07:23
shornebut is a bit strange if we dont have write back caches, but might make sense for SMP07:23
shorneI see07:23
stekernthe actual issue that the patch fix is that you need to invalidate icache when you write something to memory that is intended to be executed07:25
shorneah, right, so event if its write through, the icache might have thought something else was there so need to be invalidated07:39
shornestekern: any thoughts of kernel upstreaming? I know you dont have much time...07:40
stekernshorne: 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
stekernbut there are a set of patches that contains critical bugfixes, it's important to at least get those upstream07:44
stekernI'll try to find the time in the weekend to split out a branch with only those patches07:45
shornestekern: alright, if you need I can help. Its a pretty big backlog some things should go upstream some shouldnt07:47
shorneits going to take some time to sort them07:47
stekernyep, but I kinda know which patches are critical and which are not, so shouldn't be that much work07:48
shorneyup, i guess you would, the MAINTAINERS file update will be a good step as well.  The new mailing list should be updated there too07:51
shornegood my vmlinux image is down to 6mb (I must have enabled gzip before)07:52
shorneboot time is 7 seconds on de0 nano07:53
shorneseems long time between NET: Register, and futex hash table init07:53
shornemaybe thats the time the kernel is unzipped and moved07:54
GeneralStupidOk :D11:19
olofkshorne: Ah crap. You're right sorry about that11:57
olofkshorne: Pushed a patch now12:01
shorneolofk: 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 2.15.2 by Marius Gedminas - find it at!