IRC logs for #openrisc Wednesday, 2015-04-08

--- Log opened Wed Apr 08 00:00:56 2015
daniele12457hi guys08:28
daniele12457anyone has worked with riscV?08:29
daniele12457or lowrisc?08:29
bandvigdaniele12455: as I remember you aqsked us about that several days ago. Please find julzmb uswer here: and mine one here:
maxpalnhi all, I'm back in the world of Linux boot debug (again) - it seems the maintenance on my memory controller to support LPDDR3 has broken something. (Dull!)08:52
maxpalnI have a question on the operation of MOR1KX - I am seeing a l.lwz instruction executed without any visible access from memory (I've traced back a few hundred clock cycles just to make sure). I am assuming this means the value has been cached and there was no need to fetch from memory. Does this sound right?08:53
stekernmaxpaln: yes, that sounds right08:54
maxpalngood - I'm on the right track08:54
daniele12457bandvig: i know but i will be more specific09:01
daniele12457bandvig: i want to know the bus used by riscV09:02
daniele12457bandvig: i wonder if its axi or wishbone09:02
maxpalnone more, I am seeing a lot of accesses to what appears to be the top of  the physical memory space (i.e. 0xC7fff754 for example) - I know the 0xC denotes the virtual address, but should I expect to see accesses to this memory space to result in a read/write from physical memory?09:18
stekernmaxpaln: hmm, what do you mean? you see that address out on the memory bus?09:21
maxpalnstekern: good point - no09:28
maxpalnI am seeing these values stored in registers09:29
maxpalnsuch as: l.lwz r14,0x1c(r16)09:29
maxpalnr16 might contain 0xC7FFF75409:29
maxpalnIn this case, r14 gets stored with what I believe to be a corrupt value - but I don't see a memory read from 0x1c(r16) (hence my earlier question about cached values)09:31
maxpalnbut i am wondering if i should ever expect to see an access to this physical address (i.e. 0x07fff754)09:32
stekernbut is that in kernel space or userspace?09:32
maxpalnhmmm, straying towards edge of my knowledge09:33
maxpalnphysical memory runs up to 0x7ffffff09:33
stekernI mean, the code that is running, is it the kernel or an userspace application?09:33
maxpalnah, this is kernel booting - so i am guessing it is part of the boot]09:34
maxpalnsorry - kernel09:34
maxpalni get a familiar looking stack dump caused by an unaligned memory access - i'm trying to trace the cause09:35
stekernbut, yes, that address doesn't sound invalid09:36
stekernI'm guessing you have 128MB of memory?09:36
maxpalni can find the point where it goes wrong easy enough - but tracing back to where the memory location gets corrupted is proving tricky because i am struggl;ing to correlate memory accesses with l.lwz and l.sw instructions09:36
maxpalnyes: 128MB is correct09:36
maxpalnok, so I think I just need to search harder - it sounds as though those load word instructions must have been cache'd at some point - I'll try tracing on the memory address...09:39
maxpalnGrrrrrrr, just noticed I've grabbed the memory data bus not the address bus - what a doofus!!09:59
maxpalnthat explains why i am not seeing any triggers!!!!10:02
maxpalnwhile I am rebuilding the logic analyser10:02
maxpalnIs it feasible to monitor the cache in the same way as monitoring the physical memory bus?10:04
stekernyes, you can peek into the address in the LSU10:09
maxpalnah, great. I'm not familiar with the LSU at all - it appears to handle more than cache's. What signals would provide a cache hit result?10:16
maxpaln(if you can remember)10:16
maxpaln:-) tahnsk10:38
maxpalnor thanks, in english10:39
maxpalnHmmm, I think I may have come up against another weakness in the BFM - it doesn't do any transactions with wb_sel at anything other than 0xF. I suspect my memory controller doesn't quite handle byte reads/writes correctly in some corner cases.12:02
olofkmaxpaln: Yeah, that's a known issue12:09
olofkI'm almost done integrating your stuf btw12:09
maxpalnneat! Having looked a little deeper I'm going off that hypothesis. The BFM should definitely support byte reads/writes but I am thinking my problem is elsewhere....12:10
maxpalni was right all along - it is a byte related issue!! Found it now - that's the hard bit done. Need to fix - and then I really should add byte support to the BFM - it shouldn't be too tricky and it would have saved me a day of staring at the logic analyser output!15:18
olofkAsk me ANY git question, and I will give you an answer! I'm invincible now!16:45
--- Log closed Thu Apr 09 00:00:58 2015

Generated by 2.15.2 by Marius Gedminas - find it at!