On Mon, Oct 08, 2012 at 11:12:45PM +0200, Franck Jullien wrote: > Hi again, > > I've finally found why I had problem with IC cache enable on my board.... > > This is the code causing problem: > > 01fd3cf4 <xmalloc>: > 1fd3cf4: d7 e1 4f fc l.sw 0xfffffffc(r1),r9 > 1fd3cf8: 07 ff c4 9d l.jal 1fc4f6c <malloc> > 1fd3cfc: 9c 21 ff fc l.addi r1,r1,0xfffffffc > 1fd3d00: bc 2b 00 00 l.sfnei r11,0x0 > 1fd3d04: 10 00 00 04 l.bf 1fd3d14 <xmalloc+0x20> > > There is several conditions to see this bug: > > - instruction cache enable, > - 2nd instruction on the cache line trigger an lsu_stall, > - 3rd instruction on the cache line is a branch. > > When the or1200_genpc icpu_cycstb_o signal is triggered at the end of > cache line fetch, the address on icpu_adr_o is still equal to the > instruction after the delay slot (here it is 0x01fd3d00) and the next > data to be fetch will be 0xbc2b0000.... > By the time the ack is coming from the wishbone, the lsu_stall has > been removed and the icpu_adr_o is now equal to the branch destination > (0x01fc4f6c). However, the data to be fetched has to changed and > 0xbc2b0000 is fetched from address 0x01fc4f6c which is completely > wrong..... > > This patch fixes this wrong behavior forcing the or1200_genpc > icpu_cycstb_o signal to wait for the lsu_stall to be desaserted before > starting a cycle on the wishbone bus. > > On the attached image you'll see the patched waves on the top and the > wrong ones on the bottom. > > Franck.
Applied as r847 (or1200) and r850 (orpsocv2/or1200) Stefan _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
