| stekern | now it seems I've fixed it so it works when both caches are enabled | 10:06 |
|---|---|---|
| stekern | bah, poking the (linux) code a bit and I get UNHANDLED_EXCEPTION... | 13:01 |
| stekern | but this I think is unrelated to the bug I just fixed | 13:01 |
| stekern | putting in a printk right at where the problems occurs makes it go away too | 13:01 |
| stekern | I think I'm going to implement an assertion of a signal on some l.nop k | 13:02 |
| stekern | maybe a trace_on on l.nop 8 | 13:02 |
| stekern | so I can trigger on that and easier investigate what's happening | 13:03 |
| stekern | juliusb: on another note, what would you say about a global SIMULATION parameter? | 13:03 |
| stekern | I've got a couple of things in there that only should conditionally be in there when simulating | 13:03 |
| stekern | one could actually be handled in the Linux kernel though | 13:04 |
| stekern | the kernel only zeroes out the mmu match registers, not the translation registers | 13:04 |
| stekern | that's ok in real hw, since it doesn't matter what's in the translation registers as long as the valid bit is zero | 13:05 |
| stekern | but in simulation we get 'x' coming out of the translation registers | 13:05 |
| juliusb | stekern: sure, yuo're talking about `ifdef or whatnot? | 13:24 |
| juliusb | Most synthesis tools define SYNTHESIS | 13:24 |
| juliusb | so you could `ifndef SYNTHESIS around stuff which is only good for simulation\ | 13:25 |
| juliusb | (I might have already done that in some cases?) | 13:25 |
| juliusb | a trace-on,trace-off l.nop is a good idea too | 13:25 |
| stekern | using the SYNTHESIS define would work, yes | 13:32 |
| stekern | actually, the l.nop comment was a bit silly of me, I could just put the l.nop 8 there and trigger on the PC | 13:45 |
| stekern | but could nevertheless be a good idea to bring such out | 13:45 |
| stekern | at least, now when putting in debug printk's the kernel boots, and not crashing in some other way ;) | 13:49 |
| stekern | so I'm (hopefully) moving in the right direction | 13:49 |
| juliusb | sounds like it :) | 14:00 |
| stekern | I devoted some time in the morning to clean a couple of things up, so I could push it to https://github.com/skristiansson/mor1kx without loosing my face completely | 14:14 |
| stekern | I'll take a look at the bug at hand right now, then I'm going to start move things over to openrisc/mor1kx | 14:15 |
| juliusb | cool cool | 14:15 |
| stekern | this beauty I have to do something about... https://github.com/skristiansson/mor1kx/commit/06363edc91a2596c0619a2b674e05a7be80268a4 | 14:16 |
| stekern | I probably should reverse the logic on it, preventing the lsu op when a tick/irq exception is pending | 14:19 |
| stekern | but I fear the critical path that might create | 14:20 |
| stekern | I think I've found the bug now anyway | 14:28 |
| stekern | I get a load from stack into r9 that says 0xc00d5bcc but the l.jr r9 jumps to 0xc00dc000 | 14:31 |
| stekern | can't say I understand how that would happen from the top of my head | 14:32 |
| stekern | maybe some forwarding logic, but the load and jr is 8 instructions apart, so shouldn't be | 14:41 |
| stekern | this would be so/too easy if I'd have unlimited blockrams on the cyclone... | 14:42 |
| stekern | hmm, could it be the branch target that has been saved and the wrong (last) one is used... | 14:45 |
| stekern | the value of r9 at the l.jr r9 is at least c00d5bcc | 14:55 |
| stekern | how silly of me, 0xc0dc00 was the instruction after the delay slot of l.jr r9... | 15:03 |
| stekern | 0xc00dc000 | 15:03 |
| stekern | we really should move all jumps to be resolved in decode stage, that would make some of the logic in the fetcher more simple | 15:04 |
| juliusb | hmm, that'd mean you have to instantiate another full adder there :-0 | 17:59 |
| juliusb | but, doable, certainly | 18:00 |
| juliusb | something for cappuccino then | 18:00 |
| juliusb | but not the other smaller guys | 18:00 |
| stekern | yeah, I know, certainly only for cappuccino | 19:55 |
| stekern | and the the register file address ports will be connected straight to the instruction memory | 19:58 |
| mor1kx | [mor1kx] juliusbaxter pushed 4 new commits to master: https://github.com/openrisc/mor1kx/compare/ec2045f69a85...9dc8c8d5c278 | 19:58 |
| mor1kx | mor1kx/master 5f0a5cd Julius Baxter: mor1kx-sprs: add DRR definitions | 19:58 |
| mor1kx | mor1kx/master c22108b Julius Baxter: ctrl prontoespresso: add DRR functionality, fix NPC writing logic... | 19:58 |
| mor1kx | mor1kx/master 6e71c4a Julius Baxter: ctrl espresso: add software breakpoint functionality... | 19:58 |
| stekern | but that's the "normal" way to do it (MIPS way) | 19:59 |
| stekern | but getting those bugs I'm fighting ironed out has higher priority right now | 20:02 |
| stekern | and after that, dcache rework | 20:03 |
| stekern | so that we get 1-cycle load/stores | 20:03 |
| juliusb | :) | 20:42 |
| juliusb | sounds good | 20:42 |
| juliusb | i'm double checking software breakpoints in delay slots | 20:43 |
| juliusb | my test didn't actually test it | 20:43 |
| juliusb | I figure Is hould | 20:43 |
| juliusb | nice, it all works for the espresso CPU | 21:01 |
| juliusb | there's actually a really handy thing in OR1k I never fully knew about until I was doing this debugger work | 22:31 |
| juliusb | basically you can make the CPU stall on any exception occuring | 22:32 |
| juliusb | so, illegal insn, bus error, alignment error etc | 22:32 |
| juliusb | why hvaen't we ever used this before? It'd be massively handy for bare metal debugging! | 22:32 |
| juliusb | it'd be dead easy to add support for, too, in the espressos, and probably cappuccino too | 22:32 |
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!