IRC logs for #openrisc Sunday, 2016-05-08

--- Log opened Sun May 08 00:00:56 2016
-!- shorne_ is now known as shorne04:12
shorneSim update, I looked at how a few other sims handle breakpoints (also how breakpoints work at low level accross gdb)08:50
shornebasically, for every breakpoint gdb inserts a program instruction at the break address. In openrisc case it enters a l.trap 0x1 instrction.08:51
shorneWhen the instruction is hit, it throws the machine into the exception handler.  The handler should give control back to gdb08:52
shorneFor the or1ksim, this is done via the debug unit, where there cpu stalls08:53
shorneFor or1k and newlib, it goes into the exception handler (not implemented and crashes)08:53
shorneFor some other archs though, they simulator has some c code that implements the trap instruction which will call, sim_engine_halt SIM_SIGTRAP. Which directly hands control back to gdb for breakpoint stoppage08:57
shorneSo... I am playing with calling sim_engine_halt (about 5 line changes in sim/or1k/traps.c)08:57
shorneand it seems to work09:03
shorneLooks like the testsuite is making good progress now09:07
shornehttps://gist.github.com/stffrdhrn/92d00a25973f90cc235c2c91692c40ca - results 504 failures out of 15k tests09:14
Dan__shorne: Hello!  I have worked with one of those "other" debug interfaces for another computer.  While I have built a breakpoint interface, it isn't complete.  I basically found it to be more difficult than just changing one instruction.13:23
Dan__Sure, I've got a "breakpoint" or "BREAK" instruction as I call it.  Given a "BREAK" instruction, the CPU halts without executing the instruction.13:24
Dan__If in "User" mode, the "supervisor" (kernel) can catch the breakpoint, and the CPU will read as ready to execute the "BREAK" instruction.13:24
Dan__If in "supervisor" mode, the whole CPU comes to a halt waiting on the debugger.13:25
Dan__But there was a tricky part I wasn't anticipating: the cache.  The CPU needs to be able to flush its instruction cache, and force it to reload itself.13:25
Dan__Right now, the external debugger has the interface to flush the cache (on the CPU implementation I've been working on--not OpenRISC),13:26
Dan__but the internal debugger interface does not.13:26
Dan__Just thought I'd try to share some of my own experiences.13:26
olofkshorne: This is excellent news. Sounds like you're making great progress17:08
olofkDan__: Thanks for the info. Out of curiosity, which CPU have you been working on?17:08
shorneDan__: thanks for the info. To summarize there are 2 things to consider. 1) supervisor vs user mode handling of the "break" instruction. 2) ensuring the flush instruction cache after instructions are written to memory17:12
shorneFor 1) I think because this or1k interface a software simulator, I actually implement the handling of "break" implementation in the c code. So whether in suprevisor or user I think its the same. But I agree if this was really hardware or remote simulator it would be different.17:15
shorneDo you agree?17:15
shorneFor 2) Ill check if this simulator has a instruction cache.  I am thinking not, but as its in the same process as gdb, it would be pretty easy to flush.17:16
shorneolofk: Yeah, I think its pretty much ready for others to try out.17:16
shorneI havent tried a program with 'printf' yet...17:17
shornealso, need to try a non newlib toolchain build17:18
shorneyeah... with a printf I get "core: 4 byte write to unmapped address 0x1ffdffc at 0x66fc"17:19
shornewhich I believe is the uart address17:20
shorneno... thats not uart in newlib (_or1k_board_uart_base:  .long   0x90000000)17:23
shorneoh, that bin was built for de0 nano, with default board printf does work17:34
olofkshorne: The best supported non-newlib toolchain would probably be musl17:59
shorneolofk: thanks, ill try to build that next18:45
Dan__olofk shorne: I've been working on the ZipCPU.  It's posted on OpenCores.  I have two implementations of it, also posted on OpenCores, one of which is for the XuLA2-LX25 board, and another for the CMod-S6 board.20:10
Dan__[shorne], back to your summary, there's another thing to think of as well: the debugger needs access to memory to be able to change the BREAK instruction back into the one it replaced.  You might consider this granted, but ... still, it needs to be able to do so.20:11
Dan__(Actually, I have a third implementation that isn't posted, which is on the Basys-3 board ... it's quite the versatile CPU.)20:13
Dan__I should point out some of the RAM's provided by these boards.  In my Basys-3 implementation, the CPU has only 128 kB of RAM (block RAM within the FPGA),21:03
Dan__The XuLA2 board has 8kB block RAM, 32 MB SDRAM, and the CMod S6 has only 16 kB.  Given that the ZipCPU supports only word access, these translate into ...21:04
Dan__32kW (kilo Words, or thousands of uniquely addressable words), 2kW/8kW, and 4kW respectively.21:05
Dan__Getting an O/S to run inside of 4kW has been a ... fun challenge.21:06
--- Log closed Mon May 09 00:00:58 2016

Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!