2013/12/16 Michael Walle <[email protected]> > Am 2013-12-15 16:28, schrieb Yann Sionneau: > > Le 05/12/13 13:48, Yann Sionneau a écrit : >> >>> Hi M-labs, >>> >>> [...] >>> >>> For now I am fighting against an issue when running on the Milkymist One >>> board, I would appreciate if someone could give me some help on finding >>> what's going on :) >>> >>> I don't know yet if it's software or gateware bug, here it is: >>> >>> I'm booting the (modified) Milkymist One BIOS on the gateware with MMU >>> ans ASID enabled in the LM32 config file: >>> >>> BIOS> rcsr psw >>> 00000003 # that's already not normal, should have been >>> 0xC3 since dtlb was activated early in crt0.S >>> BIOS> wcsr psw 0x43 # let's activate it back! >>> BIOS> rcsr psw >>> 000000c3 # OK thats better... >>> BIOS> asid 5 # let's switch ASID from 0 to 5! >>> old PSW: 0x000000C3 >>> switching to ASID 0x00000005 >>> after shifting: asid2 == 0x00005000 >>> new simulated PSW: 0x000050C3 >>> new PSW: 0x000050C3 # OK the PSW is correct at the end of >>> switch_asid() >>> BIOS> rcsr psw >>> 00005003 # damn it! someone turned DTLB off again :-( >>> BIOS> wcsr psw 0x5043 # let's turn it back on! >>> BIOS> rcsr psw >>> 000050c3 # Ok... good... >>> BIOS> help # let's run some stuff! >>> Milkymist(tm) BIOS (bootloader) >>> Don't know what to do? Try 'flashboot'. >>> >>> Available commands: >>> cons - switch console mode >>> flush - flush FML bridge cache >>> mr - read address space >>> mw - write address space >>> mc - copy address space >>> crc - compute CRC32 of a part of the address space >>> rcsr - read processor CSR >>> wcsr - write processor CSR >>> ls - list files on the filesystem >>> load - load a file from the filesystem >>> netboot - boot via TFTP >>> serialboot - boot via SFL >>> fsboot - boot from the filesystem >>> flashboot - boot from flash >>> mdior - read MDIO register >>> mdiow - write MDIO register >>> version - display version >>> reboot - system reset >>> reconf - reload FPGA configuration >>> asid - switch ASID >>> BIOS> rcsr psw >>> 00005003 # Ok there's something going on! DTLB is off >>> again :( >>> BIOS> >>> >>> [...] >>> >> Hi, >> >> Anyone has any idea about this issue? >> What could cause a reset of PSW.DTLBE (and PSW.EDTLBE)? >> The CPU is definitely not resetting itself since the BIOS keeps >> executing, and it cannot come from the dtlb miss exception handler >> since it only *reads* from PSW and never writes to it. >> I'm kinda stuck on this one... :) >> > > Hi yann, > > mh, all exceptions should disable the tlb, right? so maybe the exception > handlers does something wrong, or the return from interrupt instruction is > not working correctly. > > -michael >
Hi Michael :) Yes, all exceptions will(at least should) disable TLB and save the status in PSW and then restore it back upon eret. upon exception: PSW.EDTLBE = PSW.DTLBE; /* backup DTLB state */ PSW.DTLBE = 0; /* disable DTLB */ upon eret: PSW.DTLBE = PSW.EDTLBE; /* restore DTLB state */ So indeed it seems like maybe there is a bug in the eret instruction and the exception backup because even PSW.EDTLBE is 0 :/ I cannot find it by looking at the source code, I will try to look at the waveforms during unit test simulations but I don't remember having seen such issues with eret and exceptions (cf the unit tests I added which use eret instead of ret in exception vectors: https://github.com/fallen/lm32/blob/asid/test/unittests/test_mmu_eret.S https://github.com/fallen/lm32/blob/asid/test/unittests/crt2.S ) -- Yann Sionneau
_______________________________________________ Devel mailing list [email protected] https://ssl.serverraum.org/lists/listinfo/devel
