| --- Log opened Sun May 08 00:00:56 2016 | ||
| -!- shorne_ is now known as shorne | 04:12 | |
| shorne | Sim update, I looked at how a few other sims handle breakpoints (also how breakpoints work at low level accross gdb) | 08:50 |
|---|---|---|
| shorne | basically, for every breakpoint gdb inserts a program instruction at the break address. In openrisc case it enters a l.trap 0x1 instrction. | 08:51 |
| shorne | When the instruction is hit, it throws the machine into the exception handler. The handler should give control back to gdb | 08:52 |
| shorne | For the or1ksim, this is done via the debug unit, where there cpu stalls | 08:53 |
| shorne | For or1k and newlib, it goes into the exception handler (not implemented and crashes) | 08:53 |
| shorne | For 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 stoppage | 08:57 |
| shorne | So... I am playing with calling sim_engine_halt (about 5 line changes in sim/or1k/traps.c) | 08:57 |
| shorne | and it seems to work | 09:03 |
| shorne | Looks like the testsuite is making good progress now | 09:07 |
| shorne | https://gist.github.com/stffrdhrn/92d00a25973f90cc235c2c91692c40ca - results 504 failures out of 15k tests | 09: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 |
| olofk | shorne: This is excellent news. Sounds like you're making great progress | 17:08 |
| olofk | Dan__: Thanks for the info. Out of curiosity, which CPU have you been working on? | 17:08 |
| shorne | Dan__: 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 memory | 17:12 |
| shorne | For 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 |
| shorne | Do you agree? | 17:15 |
| shorne | For 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 |
| shorne | olofk: Yeah, I think its pretty much ready for others to try out. | 17:16 |
| shorne | I havent tried a program with 'printf' yet... | 17:17 |
| shorne | also, need to try a non newlib toolchain build | 17:18 |
| shorne | yeah... with a printf I get "core: 4 byte write to unmapped address 0x1ffdffc at 0x66fc" | 17:19 |
| shorne | which I believe is the uart address | 17:20 |
| shorne | no... thats not uart in newlib (_or1k_board_uart_base: .long 0x90000000) | 17:23 |
| shorne | oh, that bin was built for de0 nano, with default board printf does work | 17:34 |
| olofk | shorne: The best supported non-newlib toolchain would probably be musl | 17:59 |
| shorne | olofk: thanks, ill try to build that next | 18: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!