IRC logs for #openrisc Wednesday, 2012-10-31

stekern_franck_: did you see that message on the ml? have you been able to single step with openocd + adv_debug_sys?05:22
stekernI thought LoneTech's patch fixed that, but perhaps those are seperate issues...05:23
stekernolofk: yes, one user per repo (they could of course be named the same). You can also choose to monitor specific branches (i.e. only master)05:46
stekernif we set -n on the channel the user wouldn't need to join/quit for the announcements neither05:47
stekernbut it seems we lost op over this channel ;)05:47
-!- _franck_2_ is now known as _franck_web_11:25
root`Hello everyone11:45
jeremybennettstekern: juliusb has op on this channel I think12:04
jeremybennettI'm not a channel operator. Perhaps we ought to get juliusb to add a few of us.12:04
juliusbI have to remember how to get it12:11
-!- mode/#openrisc [+o juliusb] by ChanServ12:12
@juliusbthat's it12:12
-!- mode/#openrisc [+o stekern] by ChanServ12:14
-!- mode/#openrisc [+o jeremybennett] by ChanServ12:15
-!- mode/#openrisc [+o olofk] by ChanServ12:15
ConXhello all! Can you please tell me why I am getting the following when trying to compile or1200's trunk version: or1200/rtl/verilog/or1200_genpc.v" line 281 'pcreg_boot' has not been declared12:45
@stekernConX: what are you trying to compile it with?13:36
ConXI am using minsoc's build system13:39
@stekernok, but what is the target? xilinx fpga, altera, simulation (which simulator)?13:40
@stekernolofk: you are using pcreg_boot before you have declared it13:42
@stekernConX: quick fix: add a13:43
@stekernwire [31:0] pcreg_boot;13:43
@stekernaround line 12513:44
@stekernand change line 294 from13:44
@stekern wire [31:0] pcreg_boot = boot_adr;13:44
@stekernassign  pcreg_boot = boot_adr;13:44
ConXdid the first and I was getting errors at the second (I am still learning Verilog)13:45
ConXthank you stekern !13:45
@stekern... and then diff it and send it as a patch to the mailinglists ;)13:45
@stekernalthough, now I see the simpler fix would be to just move line 294 to line 26713:54
_franck_stekern: no, I didn't try to single step with openocd + adv_debug_sys19:51
_franck_I'll give it a try19:52
_franck_but like you I was sure LoneTech fixed this issue with his patch19:52
@olofkSorry about the genpc problem. I discovered it myself yesterday when I was adding modelsim support for orpsocv320:00
@olofkIcarus didn't complain, so I missed that one20:00
@jeremybennettolofk: Did it get through Verilator - it can be quite picky.20:16
@stekernolofk: no worries, we are as guilty, we should have picked it up in the review ;) luckily we have good testers reporting back (ConX)20:17
@stekernI think quartus allows that as well, but not 100% sure20:18
_franck_stekern: I confirm, stepi after a breakpoint on a branch instruction doesn't branch...20:34
_franck_I'm using openOCD20:34
_franck_LoneTech patch was about a stall not a wrong branch behavior20:35
@jeremybennett_franck_: Do you believe that is a hardware fault or a fault in the GDB logic?20:40
_franck_I would say it's hardware because (I never did it) I think gdb has worked in some hardware configuration20:40
@jeremybennettI don't recall seeing this behaviour before, but it is quite specific, so I may not have tested it.20:42
@jeremybennettI remember the logic for breakpoints on branches or in branch delay slots is quite tricky.20:42
_franck_static int or1k_resume_or_step(struct target *target, int current, uint32_t address, int handle_breakpoints,  int debug_execution, int step)20:49
_franck_current ? continue on current pc : continue at <address>20:49
_franck_<address> is coming from gdb...20:49
_franck_need to put some printfs :)20:49
_franck_stupid me, I didn't apply LoneTech's patch on the RTL I'm using ! (However, it souldn't change anything)20:52
LoneTechsorry, fixing one bug does not imply the absence of others21:43
@jeremybennettLoneTech: Damn - I knew there was something I had been missing all these years :)21:59

Generated by 2.15.2 by Marius Gedminas - find it at!