IRC logs for #openrisc Friday, 2013-06-14

--- Log opened Fri Jun 14 00:00:42 2013
stekernhno: the AR100 SRAM is (as noted in the README), 64K + 1 byte for each exception vector02:14
stekernI haven't tested accessing the DRAM, I'll do that02:15
stekernI of course meant 64K + 4 bytes for each exception vector02:21
stekernread/write to DRAM doesn't seem to work, at least not out of the box02:38
stekernotoh, fel locks up when I try to read/write it from there...02:56
juliusbolofk: (or1200-except thing) yeah that happens now and then - subtle changes to the system mean the test won't pass :( sorry that's not documented properly10:07
olofkjuliusb: There were a few easy-to-fix bugs. I'll see what I can do and post to mailing list10:08
juliusbstekern: great detective work on the ar100!10:10
juliusbi also got emailed a bug fix in the or1200 recently10:20
juliusba typo in an ifdef which actually controls something important10:20
olofkjuliusb: Please don't change that. I like the rough writes to the caches10:43
stekernrough writes?10:51
stekernah, my e-mail fetching lags10:54
stekernolofk: it's only the h writes that are rough, the rest are performed with a touch of a feather10:56
olofkAhh.. I see. My joke-fetching apparently lags too :)11:10
olofkOK... I found something very weird in orpsocv2 now. Could someone please try to run make rtl-tests TEST="or1200-range or1200-rfe" and tell me if that fails in check-test-log?11:19
olofk..or just make rtl-tests TESTS="or1200-range"11:20
olofkBut any other test works, and make rtl-test TEST="or1200-range" works11:22
olofkCould range be treated like a reserved word somewhere perhaps?11:22
stekern make rtl-test TEST="or1200-range" runs the or1200-simple test11:23
olofkNow that's a feature11:23
stekernyup, the range test is just failing anyway, better to run the nice simple test that passes11:24
olofkTrue. Failed tests doesn't make anyone happy11:25
olofkAh great. Just ran all or1200 tests from orpsocv2 (except for intsyscall, since I don't have intgen in orpsocv3 right now). Finishes in 6:41 minutes in orpsocv2 and 4.47 in orpsocv3. Built for speed! :)11:46
olofk_franck_: I found an applied patch in a local or1200 checkout that I could trace back to this. Is this a patch that we have forgotten to apply, or what happened with it?12:32
olofkthis =
_franck_this fix is included in the this fix is included in the persion of the patch here:
_franck_however, we never applied it....12:40
_franck_LoneTech told me he hasn't very satisfied of this patch12:40
olofkahh..  ok, so that's what happened. I remember it vaguely now12:42
olofkCan anyone remember what the problem was? It's not stated anywhere in the bug report, and I can't find info on the mailing lists12:45
_franck_When the instruction replaced by a trap instruction is restored by the debugger, this instruction is not executed.12:45
_franck_the description is in bugzilla12:47
olofkI mean, what was the problem with applying it12:50
_franck_it just add complexity. And the problem could be fixed with a software workaround (like writing the npc again with its current value)12:51
_franck_I did it and it seems to work but I did not test it that much12:52
_franck_however, I don't think there is any functionnal problem with this RTL patch12:52
olofkHmm... I can't really comment on which is the best way to solve it, but if we would choose to add the software workaround, does that mean patching all debug proxies (openocd, or_debug_proxy, adv_jtag_bridge)?12:54
_franck_not sure but this make me think if it doesn't break anything in the RTL we should apply it12:58
olofkYeah, it seems like it makes things work better, so I'm ok with applying it.12:59
olofkI updated the bug description, and if no one has any complaints in the next few days, I'll commit the patch13:03
_franck_ok great13:07
juliusbolofk: great to read of progress on ORPSoCv3 man13:27
juliusb(_franck_'s patch) I think it looks fine too. Perhaps adding complexity, but if it makes the system seem more "normal" (ie. requires less software workarounds for basic stuff like restarting a stalled CPU) then I'm all for it13:30
stekerndoes that work for delay slots?13:49
_franck_AFAIR, I would say yes14:10
_franck_we we'll have openocd mainstream we should check all this debug thing again14:10
stekernso what is npc when a trap occurs in a delay slot? the branch dest?14:18
_franck_can't remember but the case has been tested for sure14:25
-!- Netsplit *.net <-> *.split quits: trevorman15:47
--- Log closed Sat Jun 15 00:00:44 2013

Generated by 2.15.2 by Marius Gedminas - find it at!