07:26 <lekernel> azonenberg: how many DQ bits do you have between the dram chip and the fpga?

07:26 <lekernel> and it's DDR (DDR1), right?

07:29 <lekernel> wpwrak: the problem with DRAM is that you can have many other sources, e.g. violations of internal timing parameters, wrong array geometry, read problem vs. write problem, etc. if he used the milkymist dram controller, there would have been a nice way to eliminate those possible problem sources: bit-bang the DRAM from software, disable refresh, and just access the page buffer.

10:19 <wpwrak> lekernel: well, so he's got an opportunity to learn a lot about the art of debugging memory controllers :)

14:17 <Fallenou> well now the SoC does not crash anymore while running itlb test, it just "reboots" to the bios entry point

14:17 <Fallenou> weird

14:38 <Fallenou> I forgot to add the exception handler in crt0.S now it's going into the exception handler, setting up the itlb mapping and then "freeze"

15:13 <wpwrak> does the core retry the instruction fetch ?

15:15 <Fallenou> at the end of the instruction page fault exception handler there is "eret" instruction

15:15 <Fallenou> which does PC = EA

15:15 <Fallenou> EA being the virtual address which caused the exception

15:15 <wpwrak> sounds good then

15:15 <Fallenou> it should then try to fetch again the faulty instruction

15:15 <Fallenou> it's working correctly in ISim

15:16 <Fallenou> should be a minor - but boring - bug

15:16 <wpwrak> ;-)

15:17 <wpwrak> if you preload the itlb with the correct value, does that code segment work ?

15:17 <Fallenou> http://pastebin.com/2WmEiyKZ

15:17 <Fallenou> let's try not invalidating the itlb :)

15:17 <Fallenou> good idea

15:18 <Fallenou> because right now I set up ITLB mapping, then invalidate it, then use it (in order to trigger a beautiful exception)

15:19 <Fallenou> let's try the "normal way"

15:19 <wpwrak> hmm .. your pastebin looks strange: f() is located at 0x00865a44

15:19 <wpwrak> Mapping f() into virtual memory at 0x44004000 [physical == 0x44005000]

15:20 <Fallenou> f must be somewhere in 0x008XXXXX because it's a bios function

15:20 <Fallenou> but I copy it into 0x44004000

15:20 <wpwrak> ah, you copy the function. i see

15:20 <Fallenou> and then I map 0x44004000 to 0x44005000

15:20 <Fallenou> err

15:20 <wpwrak> and it's PIC ? well, you'll find out soon enough :)

15:21 <Fallenou> I copy it to 0x44005000 :)

15:21 <wpwrak> and you're sure the code is relocatable ?

15:21 <Fallenou> yes

15:21 <Fallenou> let me paste it to you

15:22 <Fallenou> http://pastebin.com/eUB1GkaB

15:23 <Fallenou> it's just a load and a store, no call or branch

15:25 <wpwrak> hmm, doesn't that code produce a few warnings ? (when compiling with -Wall)

15:26 <Fallenou> the same paste with assembly code http://pastebin.com/YbzcP8AQ

15:26 <Fallenou> hum yes a bunch of warnings ^^"

15:27 <Fallenou> first arg of mmu_map() makes integer from pointer without a cast

15:27 <Fallenou> expected unsigned int but argument is of type 'void (*)(void)'

15:27 <wpwrak> also p = f

15:28 <wpwrak> and pdest = 0x...

15:28 <Fallenou> yes

15:28 <wpwrak> but at least you've enabled warnings at all :)

15:29 <Fallenou> I agree the code is kind of ugly :)

15:29 <Fallenou> but the values are correct (at least it seems)

15:29 <Fallenou> yes I have all the warnings printed I guess I will take the time to clean all this mess up someday

15:30 <wpwrak> yes, looks correct. that was my review pattern "this should produce a warning" -> "did he enable them at all ?" -> "if not, there may be undetected more serious problems"

15:30 <Fallenou> oh ok

15:31 <wpwrak> known warnings may still mask unexpected problems (simply because you get used to seeing warnings, and don't notice when a new one pops up), though

15:32 <Fallenou> good point

15:32 <Fallenou> I agree

15:33 <Fallenou> wpwrak: without invalidating the itlb line before using it : f() is called and it prints '@' and then nothing more

15:34 <Fallenou> it should have returned to itlbtest() and printed 'DONE' and "BIOS>" etc

15:34 <Fallenou> it's not totally desperate :'

15:36 <Fallenou> need to shave and to run, see you !

15:40 <wpwrak> hmm. not sure what would cause the return to go wrong

15:40 <wpwrak> maybe try it without any relocation, just calling f directly

19:04 <lekernel> Fallenou: maybe you have an outdated copy of the function's code in the instruction cache?

19:04 <lekernel> you should flush the instruction cache after writing some code to memory

21:40 <Fallenou> lekernel: I'm flushing both D and Icache actually

21:40 <Fallenou> it must be something else, timing related problem

21:40 <Fallenou> the software seems correct