| --- Log opened Wed Sep 30 00:00:05 2015 | ||
| stekern | andrzejr_: is that 128 bit or 128 byte you are speaking about? | 07:14 |
|---|---|---|
| stekern | because, 128 bit (16 byte) is expected to work, 128 byte is not supported | 07:15 |
| -!- orsonmmz|away is now known as orsonmmz | 07:29 | |
| andrzejr_ | stekern, 128 bit (16 byte). I posted mor1kx settings a couple of days ago. 16B does indeed work once the cache is enabled, but for some reason newlib's procedure for enabling it gets stuck in an infinite loop. | 07:31 |
| stekern | hmm, that sounds like a regression, I'm fairly certain that has worked in the past | 07:32 |
| andrzejr_ | that only happens in HW (tested on a 7 series Xilinx device synthesized with ISE), simulation works fine. | 07:32 |
| andrzejr_ | *rtl simulation in icarus and afair in xsim as well | 07:34 |
| stekern | so where does it get stuck? while invalidating it? | 07:36 |
| stekern | or right after it switches the enable knob? | 07:36 |
| stekern | and is it dcache or icache? | 07:36 |
| andrzejr_ | Yes. While invalidating it. Don't remember which cache. | 07:37 |
| stekern | that's odd | 07:37 |
| stekern | that would indicate some problem with the spr bus | 07:37 |
| stekern | s/would/could | 07:37 |
| stekern | because, all that is happening in the invalidate loop is spr accesses | 07:38 |
| stekern | unless there is some other problem in the setup that is actually causing the infinite loop | 07:38 |
| andrzejr_ | Now I know how to work it around I will try to reproduce this issue again specifically looking at that part. I only had 1 day to play with it after I managed to make the debug toolchain work, and I fairly quickly found a workaround. | 07:39 |
| stekern | does your setup work reliably if you don't enable caches at all? | 07:39 |
| andrzejr_ | Yes, it does. Also, it worked reliably with my assembly code which enabled the cache without detecting the cache sizes. | 07:40 |
| andrzejr_ | (right, so that may not be invalidate loop after all) | 07:41 |
| stekern | ok, that's good data points | 07:41 |
| andrzejr_ | BTW, my icarus sim uses a bfm model of Xilinx DDR controller so there may be discrepancies in this part. I'll redo the simulation in xsim (although I think I tried it before at some stage) | 07:43 |
| olofk | andrzejr_: Lighting leds on pass/fail is an interesting idea. It still requires the test to be run manually though to see the result | 07:53 |
| andrzejr_ | I run the code via gdb so simply looping around distinct "pass" and "fail" labels would be enough for me. LEDs are more for "in-field" HW tests. | 08:00 |
| andrzejr_ | gtg | 08:00 |
| _franck___ | andrzejr_: we could run or1k-tests on hardware using openocd and an appropriate tcl script | 11:37 |
| _franck___ | humm, the problem would be how to detect a test has finished. Hardware could tell the debug unit it has executed a l.nop 0x1 | 11:39 |
| _franck___ | does hardware aware of l.nop codes anyhow ? | 11:39 |
| stekern | _franck___: no, but it be useful if it could be | 12:01 |
| -!- orsonmmz is now known as orsonmmz|away | 16:41 | |
| andrzejr_ | $99 board from digilent, if anyone is interested. Could reuse a big chunk of my nexys4ddr design | 19:19 |
| andrzejr_ | http://www.digilentinc.com/Products/Detail.cfm?NavPath=2,719,1486&Prod=ARTY | 19:19 |
| andrzejr_ | although, I'm seriously considering switching to Lattice parts. For anything more than orpsoc development Xilinx parts are just too expensive | 19:21 |
| andrzejr_ | not to mention the amount of time I lost because of the "secret" JTAG cable, encrypted SERDES and arbitrary limitations in the free version of simulators. | 19:22 |
| blueCmd | olofk: booked Nash now, so we can tell lies in the Hotel Bar and whatnot | 19:37 |
| andrzejr_ | stekern, I've re-synthesized the design with 128b cache lines and this time the hello.c example from newlib works just fine. Very confusing, I made some minor changes to the design meanwhile but none of them seems related. | 21:37 |
| andrzejr_ | stekern, the error is triggered by .IBUS_WB_TYPE ("B3_READ_BURSTING") (my previous workaround included .IBUS_WB_TYPE ("B3_REGISTERED_FEEDBACK"), which solves the problem) | 22:25 |
| andrzejr_ | as such, it may be caused by my DDR2 interface. I have previously verified the interface with wb_bfm_transactor but maybe it hasn't caught all errors. If someone could try this option on another hardware that could be helpful. | 22:31 |
| andrzejr_ | the code hangs in _cache_init, in a loop starting from: l.mtspr r0,r6,0x2002. r6 value *toggles* between two values: 0x8201 and 0x8211, with r5=0x1000 and r14=0x10. | 22:38 |
| --- Log closed Thu Oct 01 00:00:07 2015 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!