| --- Log opened Wed Apr 08 00:00:56 2015 | ||
| daniele12457 | hi guys | 08:28 |
|---|---|---|
| daniele12457 | anyone has worked with riscV? | 08:29 |
| daniele12457 | or lowrisc? | 08:29 |
| bandvig | daniele12455: as I remember you aqsked us about that several days ago. Please find julzmb uswer here: http://juliusbaxter.net/openrisc-irc/%23openrisc.2015-04-03.log.html and mine one here: http://juliusbaxter.net/openrisc-irc/%23openrisc.2015-03-30.log.html | 08:48 |
| maxpaln | hi 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 |
| maxpaln | I 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 |
| stekern | maxpaln: yes, that sounds right | 08:54 |
| maxpaln | good - I'm on the right track | 08:54 |
| maxpaln | :-) | 08:54 |
| daniele12457 | bandvig: i know but i will be more specific | 09:01 |
| daniele12457 | bandvig: i want to know the bus used by riscV | 09:02 |
| daniele12457 | bandvig: i wonder if its axi or wishbone | 09:02 |
| maxpaln | one 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 |
| stekern | maxpaln: hmm, what do you mean? you see that address out on the memory bus? | 09:21 |
| maxpaln | stekern: good point - no | 09:28 |
| maxpaln | I am seeing these values stored in registers | 09:29 |
| maxpaln | such as: l.lwz r14,0x1c(r16) | 09:29 |
| maxpaln | r16 might contain 0xC7FFF754 | 09:29 |
| maxpaln | In 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 |
| maxpaln | but i am wondering if i should ever expect to see an access to this physical address (i.e. 0x07fff754) | 09:32 |
| stekern | but is that in kernel space or userspace? | 09:32 |
| maxpaln | hmmm, straying towards edge of my knowledge | 09:33 |
| maxpaln | physical memory runs up to 0x7ffffff | 09:33 |
| stekern | I mean, the code that is running, is it the kernel or an userspace application? | 09:33 |
| maxpaln | ah, this is kernel booting - so i am guessing it is part of the boot] | 09:34 |
| maxpaln | sorry - kernel | 09:34 |
| maxpaln | i get a familiar looking stack dump caused by an unaligned memory access - i'm trying to trace the cause | 09:35 |
| stekern | but, yes, that address doesn't sound invalid | 09:36 |
| stekern | I'm guessing you have 128MB of memory? | 09:36 |
| maxpaln | i 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 instructions | 09:36 |
| maxpaln | yes: 128MB is correct | 09:36 |
| maxpaln | ok, 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 |
| maxpaln | Grrrrrrr, just noticed I've grabbed the memory data bus not the address bus - what a doofus!! | 09:59 |
| maxpaln | that explains why i am not seeing any triggers!!!! | 10:02 |
| maxpaln | while I am rebuilding the logic analyser | 10:02 |
| maxpaln | Is it feasible to monitor the cache in the same way as monitoring the physical memory bus? | 10:04 |
| stekern | yes, you can peek into the address in the LSU | 10:09 |
| maxpaln | ah, 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 |
| stekern | dc_ldat | 10:33 |
| maxpaln | :-) tahnsk | 10:38 |
| maxpaln | or thanks, in english | 10:39 |
| maxpaln | Hmmm, 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 |
| olofk | maxpaln: Yeah, that's a known issue | 12:09 |
| olofk | I'm almost done integrating your stuf btw | 12:09 |
| maxpaln | neat! 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 |
| maxpaln | i 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 |
| olofk | Ask 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 irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!