IRC logs for #openrisc Thursday, 2012-11-29

olofkAlright. First lines of documentation submitted for orpsocv300:54
_franck_I pushed Marek's patches to openOCD on github01:42
_franck_you should test it and see how fast it goes01:42
_franck_he did a really great job01:42
_franck_(still have a patch from him improving usb blaster speed)01:43
stekernjuliusb: thanks for the explanation, so basically what you are saying is that an exception can't happen in a delay-slot except when the instruction in the delay-slot caused the exception08:07
stekernthat's probably fine, but I'd like to try to just mark the delay-slot and update epcr to the pc accordingly (i.e. if (delay-slot) epcr = pc - 4 else epcr = pc)08:13
stekernbecause that sounds like a lot simpler logic to me08:13
stekernI might be wrong, could be that that's not going to work08:14
stekernbut a final question to how it is implemented now, consider this: l.sfeqi r0,1; some_place; l.sw 1(r0),r0 08:18
stekernwhat will epcr be set to?08:18
stekernsince you are only detecting delay-slots when branches are taken, right?08:18
-!- X-Scale` is now known as X-Scale08:46
@juliusbstekern: is that a coremark for the newly re-pipelined cappuccino?10:32
stekernyup, running at 80MHz on atlys10:33
stekernI get the same score on de0-nano10:33
@juliusbahh 80, very nice though, 1.5coremarks :)10:34
stekernit's actually slightly slower than the old cappuccino10:34
@juliusbi thought it was 50MHz and somehow you'd gotten 2.410:34
@juliusboh right, but synthesises faster?>10:34
stekernI get ~75 coremark when running 50MHz10:34
stekernit's expected, load/stores are still kind of handled like in old cappucino10:36
@juliusbregarding EPCR, thoguh10:36
stekernI'm happy it scales linearly with the cpu-freq, that means working towards increasing fmax wasn't in vain ;)10:37
@juliusbyes, only thing which can cause an exception in delay slot is thta instruction, otherwise PIC and timer are held off until that instruction completes (ie the padv signals go high, I think for execute stage, causing the writeback to occur)10:37
@juliusbregarding trying the new EPCR calculation, by all means, go ahead and try it - that's what the regression test suite is for :)10:38
@juliusbfor your example, EPCR would point to the some_place insn because it was the insn in the delay slot causing alignment exception10:38
@juliusbif you weren't branching, then EPCR points to l.sw10:39
@juliusbit's not a delay slot10:39
@juliusbit's the next instruction10:39
@juliusbthat's my understanding anyway10:39
@juliusbthere's no point re-evaluting the because it won't change because the flag won't have changed10:39
stekernwell, it _is_ a delay-slot regardless of if the branch have been taken or not, if that definition has any practical difference is another story10:47
stekernbtw, in my example, i wasn't branching ;)10:55
stekernthe definition is not so important though, I'm mostly interested in simplifying the logic, ctrl_branch_occur is pretty critical, so if we can avoid using that wherever possible, I reckon it's good10:58
stekernbut it's a bit weird if my example (l.sfeqi r0,1; some_place; l.sw 1(r0),r0) isn't handled consistantly10:59
stekernjuliusb: (there's no point re-evaluting the but there's really no harm neither, right?11:41
stekernI'm just fishing for a "yeah, but have you thought about this!?" here, before I start poking ;)11:42
@juliusbmy interpretation is that it becomes the delay slot when you are taking the branch, otherwise it's just the next instruction12:28
@juliusband yes, I realised I hadn't fully thought through your example until after I typed what I did, but in any case it's worth while talking through both cases12:29
stekernspeak first, think later, that's the way to do it! ;)12:29
@juliusbwhat do you mean your example isn't handled consistently?12:29
@juliusbbasically, in a pipelined design, you're going to be evaluating the branch instruction (if it's a conditional branch) as you're getting ready to process the delay slot12:30
stekernI mean if I change the logic so that a delay slot is always a delay slot, regardless if the branch was taken or not12:30
@juliusb(whether it becomes officially a delay slot instruction or not depends on whether the branch is taken, so it's a bit annoying)12:30
@juliusbwell, I argue that's not good12:31
stekernso perhaps the definition is important after all12:31
@juliusband I have designed it so that if you're about to take a branch, the only way you can get into a situation where you'll get an exception with the PC in the delay slot is if that delay slot instruction causes the exception12:31
@juliusbin that case, you must have EPCR pointing to the preceeding instruction12:32
@juliusband if it's a tick or PIC exception during the delay slot, then you should finish the delay slot instruction and (supposing it doesn't cause an exception) set EPCR to the new branch location and service the tick/PIC exception12:33
stekernyes, but that only holds for your definition of a delay slot12:33
@juliusbbut if it's not a delay slot (ie the conditional branch isn't being taken) and the instruction causes an exception then the EPCR should point to that instruction, not the preceeding branch12:34
stekernI'm not saying my definition is 100% right, that's just how I have thought about it12:34
@juliusbyep, fair enough12:34
stekernsome 3rd part, please chime in! ;)12:34
@juliusbso, I think my way is going to be most efficient execution wise because you're not re-executing a branch you know you won't take12:34
@juliusbhowever, my way may not be most efficient implementation wise because you need logic to account for that situation12:35
@juliusbi'm quite sure, though, that the delay slot only exists when a branch is being taken, otherwise that following instruction is just the next instruction12:35
stekernI mean, you could think of a as a 2-way branch instruction, one way going to some_place and the other is going to pc+812:35
@juliusbmmm, you could, but I prefer thinking of it the other way, which just takes a branch or not, other wise your nice, simple linear execution continues12:36
@juliusbso, I guess this doesn't matter except for the case you've brought up12:37
stekernyeah, probably not12:37
@juliusbwhich actually doesn't matter whether EPCR points to the branch or not12:37
@juliusbso long as the flag remains the same12:38
@juliusbwhich it should12:38
stekernand I'm not sure that actually matter in practice neither12:38
@juliusbwell, it must, if you're going to re-play that bit of code and expect the same execution path (without exceptions) then you'll need the flag the same12:38
stekernbut SR[DSX] and epcr will differ for the 2 cases12:38
@juliusbi think if you're setting EPCR to the branch you need to set DSX12:39
@juliusbto indicate the actual instruction causing the exception was the next one12:39
@juliusbwhether the branch was taken or not12:39
@juliusband where I differ with this is that I think the exception, if caused by the instruction following a conditional branch which was not taken, should cause the EPCR to be set to that instruction and without DSX set12:40
@juliusbbut, to, restate, I'm not sure this matters, and if it doesn't then it should be cool if we do it either way12:41
@juliusbbut then again, maybe it's something which should be standard12:41
@juliusband stated in the arch spec12:41
@juliusband tested for12:41
stekernthe big Q is "what defines a delay-slot" :)12:42
stekernlet's just forget about that stupid delay-slot and pretend it never was there12:42
@juliusbit's what I've been trying to do ;)12:45
_franck_olofk: I think it is time to apply
@juliusbawesome debugging effort on your part here _franck_12:49
_franck_I love debug :) more than development12:50
@juliusbthat patch looks good12:51
_franck_I set up an JTAG connector on my altera board so I can use an "external", not vjtag JTAG interface12:55
_franck_I'm going to do an exhaustive testing of all combination for debug i and tap12:55
@juliusboh wow12:55
@juliusbhardcore :)12:56
@juliusbi've always had to set up the external JTAG connector, though12:56
@juliusbit's not so bad :)12:56
@juliusbjust get some flywires and a few pins somewhere, hey presto12:56
_franck_well we just have deb_if, adv_dbg_if, opencores tap, altera vjtag tap12:56
_franck_I wasn't talking about testing JTAG interfaces12:57
_franck_I'm using an Olimex ARM-USB-blabla right now12:57
_franck_I works good after a patch due to some problem in the openocd ftdi driver12:58
@juliusbhah, someone needs to inform Xilinx what "open" means to a lot of people. From this document:
@juliusb"Vivado Design Suite is an open design environment that embraces industry standards to leverage the designer’s experience while broadening third-party support.13:00
@juliusbI bet it's really open13:01
@juliusb_franck_: yeah I know what you mean, you're testing the various combos of stuff inside the chip?13:01
_franck_it's open to cash, credit card and paypal :)13:01
@juliusbhaha yep13:01
@juliusb_franck_: great. All using OpenOCD I guess?13:02
@juliusbhad much of a chance to use the dbg_if? (Mohor one)13:02
_franck_It's working but still have a "bit shift due to TDO register" problem13:02
_franck_I need to take a closer look13:02
_franck_for now, just remove the register in dbg_if13:03
_franck_this old thread:13:03
@juliusbI'm not the biggest fan of that - too many ads13:06
@juliusbyou'll find the post here also:13:06
@juliusbFor the entire archive:
@juliusbanyway, did you find a way around it?13:07
_franck_no, still have that patch13:08
@juliusbis it something you have to hack the mohor debug unit driver for in OpenOCD?13:08
_franck_for vjtag + mohor debug unit13:08
@juliusbthat's annoying :-/13:09
_franck_openocd + opencores tap + dbg_if *should* be ok13:09
@juliusbyeah I use that a bit13:09
_franck_that why I want to test every combination13:09
stekern_franck_: I agree with the fun of debugging, that's why I constantly go in and break stuff ;)13:09
@juliusbbtw where is the main openocd repo we use these days?
_franck_openrisc github13:10
stekernjuliusb: you agreed on moving it to github some week ago13:10
@juliusbok cool, just curious if it happened13:15
@juliusbactually, i'd forgotten that particular fact :) but knew it was up in the air a little bit13:16
@juliusbis it me or are there a couple of typos in the which is showing up here:
@juliusb"JAG VIP driver"13:18
@juliusbis that meant to be "JTAG VPI driver"?13:18
@juliusbanyway, small issue :)13:18
@juliusbvery cool, i'll be sure to grab that version next time I run openocd13:26
@juliusb_franck_: you mentioned something about attempting to merge with upstream a while back13:26
@juliusbany luck with it more recently?13:27
@juliusbor are my GDB hacks too incompatible?13:27
@juliusbah, I see the next branch has the latest stuff?13:28
_franck_yes, use the next branch and feel fre to correct typos as you have admin rights on the repo :)14:31
_franck_about merging upstream, I've never really looked at what you're telling is a hack14:31
_franck_if I want to work on gdb, which repo should I use ?14:39
_franck_I guess or1k-src...Anything to know before a try to compile it ?14:41
@juliusbThis is my hack:
@juliusbthose things are used in or1k.c:
@juliusbso, it's something along the lines of not sending "OK" to the query packets16:22
@juliusbI think there's more hackery on this file, though....16:22
@juliusbactually, no the entire readspr/writespr function is based on this hackery, that's right - so for our qRcmd (query remote command or something)16:26
@juliusbwe just send a string of either "writespr <addr> <data>" or "readspr <addr>"16:26
@juliusband then we respond with the value in ASCII or whatever16:26
@juliusband that's it16:27
@juliusbthere's no "OK"16:27
@juliusbbut by default the qRcmd stuff responds with "OK"16:27
@juliusbso all I did was something which, in the or1k port, makes sure we only send the data, and not the "OK"16:27
@juliusbactually, the or1k GDB shouldn't be using qRcmd to do the SPR reads and wrties16:27
@juliusbthere's other mechanisms which are more appropriate16:27
jeremybennettqRcmd is the general "communicate with the server" packet.16:27
jeremybennettLook at how the monitor commands are implemented may be helpful.16:27
@juliusband it's this workaround in the server which is probably not going to allow us to be merged upstream with OpenOCD16:28
@juliusbjeremybennett: yes, from what I gather it's more of a sideband communication thing16:28
@juliusbnot really intended for debug target comms16:28
@juliusbconfiguring things\16:28
@juliusbanyway, it's another thing for the list of things TODO which we seem to be getting through lately :)16:29
@juliusbwell, actually, i'm kinda wrong:
@juliusb`qRcmd,command': command (hex encoded) is passed to the local interpreter for execution.16:30
_franck_so qRcmd ends up to .commands handler in the target file in openocd ? right ?16:31
@juliusbqXfer is probably what we want16:31
@juliusb_franck_: yes16:31
@juliusbthat "writespr" in the field in that struct corresponds to what the GDB client sends16:32
@juliusbits' pretty cool, stuff like that which OpenOCD just handles for you and provides nice macros and the like16:32
@juliusbanyway, for anyone playing with the GDB port in future...16:32
_franck_and normally it uses which handler ? in orther arch ? when reading spr16:32
* juliusb looks to see if aws is around...16:32
@juliusb_franck_: I don't know how other arches do it to be honest16:33
@juliusbbut for or1k I think it makes sense to use teh qXfer stuff a bit more16:33
@juliusb`qXfer:object:read:annex:offset,length': Read uninterpreted bytes from the target's special data area identified by the keyword object. Request length bytes starting at offset bytes into the data.16:33
_franck_so jeremybennett do you have the answer to my question about which gdb repo to use ?16:34
jeremybennett_franck_: Sorry missed that questions16:34
jeremybennettLet me check where we fork for ARC16:34
_franck_it's wasn't especially for you :)16:35
_franck_I meant gdb for or1k16:36
jeremybennettThere are mirrors for all the main sourceware modules there, with the exception of CGEN, which you can find at
jeremybennettI haven't made a GDB one yet. I thought Pete Gavin had done that.16:37
jeremybennettThe problem is the sourceware upstream (i.e. everything except GCC itself) is in CVS, and uses the CVS module feature to present different slices of one great master repository.16:38
_franck_can I compile this ?16:38
jeremybennettAt present there are only mirrors of particular modules, not the entire source tree.16:38
jeremybennettWhat Pete did, was to take a snaphot of the src tree into GitHub, but I don't know that he regularly updates it from upstream, so it may be out of date.16:39
jeremybennettI haven't tried compiling it.16:39
jeremybennettWe're hoping to put a proper mirror of the entire src tree up in the coming weeks, which will be dynamically updated, and that will the right thing to be forking from. When we do that, I'll try to update the openrisc to be a fork of that.16:40
_franck_I could use this:
jeremybennettSo that is the stable SVN version. I haven't worked on it for a year or so though.16:42
_franck_no problem, that's the one I'm using right now16:42
_franck_can I go the the gdb directory and just ./configure ?16:43
_franck_or I should use the build script from the root directory16:44
jeremybennettNone of the GNU tools recommend building in place. Create a build sub-directory (e.g. bd), go there and run ../configure followed by make16:45
jeremybennettBut using is safer. I think we've sorted out most of hte common pitfalls. It's based on Mike Frysinger's gentoo scripts.16:45
jeremybennettcompiling the linux tool chain requires some care, because of hte need to bring in the Linux headers correctly.16:46
_franck_ok I'll do that, I just wanted to save some time while compiling gdb over and over if I'm working on it16:46
_franck_from what I could see in 30 sec, all this hack juliusb did is to handle a special "spr" command in gdb16:53
_franck_add_info ("spr", or32_info_spr_command,16:53
_franck_"Show the value of a special purpose register");16:54
_franck_I didn't even know we had a spr command in gdb16:54
LoneTechI think I nearly have virtual jtag working in openocd (independent of or1k module)16:54
_franck_LoneTech: great16:54
_franck_is it enabled via TCL console ?16:56
_franck_I meant TCL script16:57
_franck_jeremybennett: you answered to me:
_franck_LoneTech: when will we have the chance to test it ? :)17:04
jeremybennettThere was always a "spr" command in OpenRISC GDB.17:04
_franck_I didn't know....17:04
jeremybennettand "info spr" to read the SPR.17:04
jeremybennettThey are not really what should be used, it would be better IMHO to ahve "set spr" and "show spr" commands. But that's history for you.17:05
_franck_now I understand the whole thing :) the readspr and writespr in openocd are not the problem17:06
_franck_the only problem is the gdb commmand it uses17:06
jeremybennettIf you use the build script the first time, it will create (from memory) bd-elf-gdb and bd-linux-gdb directories. You can then rebuild just gdb any time, by going to those directories and using "make all-gdb" and "make install-gdb".17:06
_franck_qRcmd and not a another more appropriate17:06
jeremybennettThat's what I do when working on GDB.17:06
_franck_jeremybennett: ok thanks for the gdb compile info17:07
jeremybennettWhen we moved to use Remote Serial Protocol, I did something to implement the spr and info spr instructions, but I can't remember if it was to use qRcmd. You should be able to see by looking at or32-tdep.c in the SVN copy.17:07
_franck_target_rcmd (cmd, uibuf);17:09
jeremybennettLooks like it using qRcmd then.17:10
_franck_so we just need to chnage this to a more appropriate cmd17:11
_franck_qXfer for example like juliusb suggested it17:11
LoneTechwell, it can now probe the virtual jtag hub (although there's no mapping of instance id to tcl), but I seem to have some mismatch between the mohor module and openocd still17:11
_franck_LoneTech: yes there is a bit shift in between those two17:12
LoneTechalso, I think there's an issue with IR readback verification since VIR must be selected in an odd manner if it is to be read17:12
_franck_the vjtag as to be set up once at the beginning then it is transparent17:13
_franck_look at the current code using it17:13
LoneTechI've seen it. it's just that I'm trying a configuration that I haven't tested before with mohor behind vjtag17:14
LoneTechhm, that extra register might be an issue17:15
_franck_it is17:16
LoneTechlooks to me like that register probably belongs in the gpio jtag tap module instead17:17
LoneTechsince we can't really remove one from the virtual jtag module17:17
jeremybennett_franck_: I haven't followed the full discussion as to why qRcmd is not appropriate. But GDB does have the concept of "auxilliary register", and we should use the commands to handle those for SPRs.17:17
jeremybennettActually we should be using the XML functionality to allow the user to describe the target features.17:18
_franck_qRcmd should responf with "OK" but we are responding with a value17:21
LoneTechremoving that register didn't really help. I think there's a slightly bigger mismatch involved.17:22
LoneTechError:  received CRC (0x002bfd47) not same as calculated CRC (0xfff06cbb)17:22
LoneTechError:  received CRC (0x00000000) not same as calculated CRC (0xbc16f9b6)17:22
_franck_does it work with the openOCD version in the openrisc github repo ?17:23
_franck_(it does work when removing this reg in dbg_if)17:24
LoneTechI tested gpio jtag without removing that register before, which did work17:25
_franck_because they are working well together17:25
_franck_the is a gpio tap version along with adv_debug_if:17:26
_franck_there is a tdo register mismach, Marek Czerski is preparing a patch to fix this17:27
LoneTechwell, the 4-bit status carries an invalid value per the mohor debug module documentation. I guess that's something.17:35
LoneTechafaict the virtual jtag layer itself is working (albeit misplaced and a crude hack)17:37
LoneTechbut the only combination of openocd I got to work is mohor with gpio jtag so far17:37
_franck_:( too bad17:38
LoneTechsome part of me feels a 32-bit crc for a 4-bit packet is a bit overkill.17:38
olofkGreat to hear some gdb talk.19:56
olofkAnd regarding the mohor debug unit. There is some bit shift patch applied to the orpsocv2 copy that isn't in the upstream version19:57
olofkBut as everyone soon will be using orpsocv3, those differences won't be a problem :)19:58
_franck_jeremybennett: I'm going to use this xml thing in gdb. I now understand it :)21:11

Generated by 2.15.2 by Marius Gedminas - find it at!