#milkymist IRC log for Saturday, 2012-06-23

lekernelazonenberg: how many DQ bits do you have between the dram chip and the fpga?07:26
lekerneland it's DDR (DDR1), right?07:26
lekernelwpwrak: 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.07:29
wpwraklekernel: well, so he's got an opportunity to learn a lot about the art of debugging memory controllers :)10:19
Fallenouwell now the SoC does not crash anymore while running itlb test, it just "reboots" to the bios entry point14:17
Fallenouweird14:17
FallenouI 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"14:38
wpwrakdoes the core retry the instruction fetch ?15:13
Fallenouat the end of the instruction page fault exception handler there is "eret" instruction15:15
Fallenouwhich does PC = EA15:15
FallenouEA being the virtual address which caused the exception15:15
wpwraksounds good then15:15
Fallenouit should then try to fetch again the faulty instruction15:15
Fallenouit's working correctly in ISim15:15
Fallenoushould be a minor - but boring - bug15:16
wpwrak;-)15:16
wpwrakif you preload the itlb with the correct value, does that code segment work ?15:17
Fallenouhttp://pastebin.com/2WmEiyKZ15:17
Fallenoulet's try not invalidating the itlb :)15:17
Fallenougood idea15:17
Fallenoubecause right now I set up ITLB mapping, then invalidate it, then use it (in order to trigger a beautiful exception)15:18
Fallenoulet's try the "normal way"15:19
wpwrakhmm .. your pastebin looks strange: f() is located at 0x00865a4415:19
wpwrakMapping f() into virtual memory at 0x44004000 [physical == 0x44005000]15:19
Fallenouf must be somewhere in 0x008XXXXX because it's a bios function15:20
Fallenoubut I copy it into 0x4400400015:20
wpwrakah, you copy the function. i see15:20
Fallenouand then I map 0x44004000 to 0x4400500015:20
Fallenouerr15:20
wpwrakand it's PIC ? well, you'll find out soon enough :)15:20
FallenouI copy it to 0x44005000 :)15:21
wpwrakand you're sure the code is relocatable ?15:21
Fallenouyes15:21
Fallenoulet me paste it to you15:21
Fallenouhttp://pastebin.com/eUB1GkaB15:22
Fallenouit's just a load and a store, no call or branch15:23
wpwrakhmm, doesn't that code produce a few warnings ? (when compiling with -Wall)15:25
Fallenouthe same paste with assembly code http://pastebin.com/YbzcP8AQ15:26
Fallenouhum yes a bunch of warnings ^^"15:26
Fallenoufirst arg of mmu_map() makes integer from pointer without a cast15:27
Fallenouexpected unsigned int but argument is of type 'void (*)(void)'15:27
wpwrakalso  p = f15:27
wpwrakand pdest = 0x...15:28
Fallenouyes15:28
wpwrakbut at least you've enabled warnings at all :)15:28
FallenouI agree the code is kind of ugly :)15:29
Fallenoubut the values are correct (at least it seems)15:29
Fallenouyes I have all the warnings printed I guess I will take the time to clean all this mess up someday15:29
wpwrakyes, 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
Fallenouoh ok15:30
wpwrakknown warnings may still mask unexpected problems (simply because you get used to seeing warnings, and don't notice when a new one pops up), though15:31
Fallenougood point15:32
FallenouI agree15:32
Fallenouwpwrak: without invalidating the itlb line before using it : f() is called and it prints '@' and then nothing more15:33
Fallenouit should have returned to itlbtest() and printed 'DONE' and "BIOS>" etc15:34
Fallenouit's not totally desperate :'15:34
Fallenouneed to shave and to run, see you !15:36
wpwrakhmm. not sure what would cause the return to go wrong15:40
wpwrakmaybe try it without any relocation, just calling f directly15:40
lekernelFallenou: maybe you have an outdated copy of the function's code in the instruction cache?19:04
lekernelyou should flush the instruction cache after writing some code to memory19:04
Fallenoulekernel: I'm flushing both D and Icache actually21:40
Fallenouit must be something else, timing related problem21:40
Fallenouthe software seems correct21:40
--- Sun Jun 24 201200:00

Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!