IRC logs for #openrisc Wednesday, 2015-09-30

--- Log opened Wed Sep 30 00:00:05 2015
stekernandrzejr_: is that 128 bit or 128 byte you are speaking about?07:14
stekernbecause, 128 bit (16 byte) is expected to work, 128 byte is not supported07:15
-!- orsonmmz|away is now known as orsonmmz07: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
stekernhmm, that sounds like a regression, I'm fairly certain that has worked in the past07: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 well07:34
stekernso where does it get stuck? while invalidating it?07:36
stekernor right after it switches the enable knob?07:36
stekernand is it dcache or icache?07:36
andrzejr_Yes. While invalidating it. Don't remember which cache.07:37
stekernthat's odd07:37
stekernthat would indicate some problem with the spr bus07:37
stekernbecause, all that is happening in the invalidate loop is spr accesses07:38
stekernunless there is some other problem in the setup that is actually causing the infinite loop07: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
stekerndoes 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
stekernok, that's good data points07: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
olofkandrzejr_: Lighting leds on pass/fail is an interesting idea. It still requires the test to be run manually though to see the result07: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
_franck___andrzejr_: we could run or1k-tests on hardware using openocd and an appropriate tcl script11: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 0x111:39
_franck___does hardware aware of l.nop codes anyhow ?11:39
stekern_franck___: no, but it be useful if it could be12:01
-!- orsonmmz is now known as orsonmmz|away16:41
andrzejr_$99 board from digilent, if anyone is interested. Could reuse a big chunk of my nexys4ddr design19:19
andrzejr_although, I'm seriously considering switching to Lattice parts. For anything more than orpsoc development Xilinx parts are just too expensive19: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
blueCmdolofk: booked Nash now, so we can tell lies in the Hotel Bar and whatnot19: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 2.15.2 by Marius Gedminas - find it at!