| --- Log opened Fri Jun 14 00:00:42 2013 | ||
| stekern | hno: the AR100 SRAM is (as noted in the README), 64K + 1 byte for each exception vector | 02:14 |
|---|---|---|
| stekern | I haven't tested accessing the DRAM, I'll do that | 02:15 |
| stekern | I of course meant 64K + 4 bytes for each exception vector | 02:21 |
| stekern | read/write to DRAM doesn't seem to work, at least not out of the box | 02:38 |
| stekern | otoh, fel locks up when I try to read/write it from there... | 02:56 |
| juliusb | olofk: (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 properly | 10:07 |
| olofk | juliusb: There were a few easy-to-fix bugs. I'll see what I can do and post to mailing list | 10:08 |
| juliusb | stekern: great detective work on the ar100! | 10:10 |
| juliusb | cool | 10:20 |
| juliusb | i also got emailed a bug fix in the or1200 recently | 10:20 |
| juliusb | a typo in an ifdef which actually controls something important | 10:20 |
| olofk | juliusb: Please don't change that. I like the rough writes to the caches | 10:43 |
| stekern | rough writes? | 10:51 |
| stekern | ah, my e-mail fetching lags | 10:54 |
| stekern | olofk: it's only the h writes that are rough, the rest are performed with a touch of a feather | 10:56 |
| olofk | Ahh.. I see. My joke-fetching apparently lags too :) | 11:10 |
| olofk | OK... 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 |
| stekern | yes | 11:21 |
| olofk | But any other test works, and make rtl-test TEST="or1200-range" works | 11:22 |
| stekern | yes | 11:22 |
| olofk | Could range be treated like a reserved word somewhere perhaps? | 11:22 |
| stekern | make rtl-test TEST="or1200-range" runs the or1200-simple test | 11:23 |
| olofk | :) | 11:23 |
| olofk | Now that's a feature | 11:23 |
| stekern | yup, the range test is just failing anyway, better to run the nice simple test that passes | 11:24 |
| olofk | True. Failed tests doesn't make anyone happy | 11:25 |
| olofk | Ah 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 |
| olofk | this = https://github.com/Franck79/orpsocv2/commit/7f7cbeee6ee868e753fa39dcc5886d1a1a7ce48e | 12:32 |
| _franck_ | this fix is included in the this fix is included in the persion of the patch here: http://bugzilla.opencores.org/show_bug.cgi?id=104 | 12:40 |
| _franck_ | however, we never applied it.... | 12:40 |
| _franck_ | LoneTech told me he hasn't very satisfied of this patch | 12:40 |
| _franck_ | s/hasn't/wasn't | 12:41 |
| olofk | ahh.. ok, so that's what happened. I remember it vaguely now | 12:42 |
| olofk | Can anyone remember what the problem was? It's not stated anywhere in the bug report, and I can't find info on the mailing lists | 12: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 bugzilla | 12:47 |
| olofk | I mean, what was the problem with applying it | 12: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 much | 12:52 |
| _franck_ | however, I don't think there is any functionnal problem with this RTL patch | 12:52 |
| olofk | Hmm... 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 it | 12:58 |
| olofk | Yeah, it seems like it makes things work better, so I'm ok with applying it. | 12:59 |
| olofk | I updated the bug description, and if no one has any complaints in the next few days, I'll commit the patch | 13:03 |
| _franck_ | ok great | 13:07 |
| juliusb | olofk: great to read of progress on ORPSoCv3 man | 13: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 it | 13:30 |
| stekern | does that work for delay slots? | 13:49 |
| _franck_ | AFAIR, I would say yes | 14:10 |
| _franck_ | we we'll have openocd mainstream we should check all this debug thing again | 14:10 |
| stekern | so 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 sure | 14:25 |
| -!- Netsplit *.net <-> *.split quits: trevorman | 15:47 | |
| --- Log closed Sat Jun 15 00:00:44 2013 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!