IRC logs for #openrisc Wednesday, 2012-11-21

@olofk_franck_, You're around?00:02
-!- Netsplit *.net <-> *.split quits: ams00:14
-!- Netsplit *.net <-> *.split quits: orsoc1_00:24
@olofkDo you have commit rights to or1200, or should I apply the patch for you? It passes the or1200 tests in orpsocv200:36
@olofkfor bug 104 I mean00:38
_franck_no I don't have rights. However, wait a bit :)00:39
@olofkImprovements on the way? :)00:39
_franck_just looked at quartus logs and saw combinatorial loops00:39
_franck_and I think I'm involved in this :)00:39
_franck_so wait a bit00:40
@olofkYeah, I'll hold. That was a good catch. I guess that a test synthesis maybe should be a requirement00:40
@olofkAnd people better start using orpsocv3 soon, so we don't have to patch or1200 twice every time there's a bug ;)00:41
_franck_yeah that would be great ! any date planned for the orpsocv3 release ?00:42
@olofkNo, I'm still working on some basic stuff, but I'm trying to avoid adding new features and finishing off the ones that are in place00:44
_franck_ok fixed. needed to register du_flush_pipe in or1200_du00:44
_franck_I'll update my patch00:44
@olofkCan you rerun the or1200 tests, just in case, or do you want me to do that?00:44
_franck_if you are ready please do it. However, I need to test in hardaware to see if it still works :)00:45
_franck_because now I have one clock delay...00:45
_franck_so just wait and do nothing :)00:46
@olofkI'm probably off to bed soon, so there's no hurry for me. Just give a shout when you're ready.00:52
@juliusbolofk: (using orpsocv3 and not doing the or1200-patch-double-dance) hear hear!00:54
@juliusbI'm kinda the prime offender at the minute though00:56
@olofkmor1kx is supported already. Just need to clean it up a bit before I push it00:56
@juliusbnot even using orpsocv2, but a _forked_ version of it!!00:56
@olofkEveryone is currently using a forked version :)00:56
@juliusbif I patch OR1200 in there I have to apply it 3 places00:56
@juliusb(this is not going to happen)00:56
@olofkThere's one on opencores, a few on github, some on, stefan got some at his private repo and probably a few more that I don't know about00:57
@juliusbyeah i bet00:57
@juliusbimmitation (forking, in this case) is the sincerest form of flattery00:58
@olofkThat's the worst fucking excuse I have heard today ;)00:58
@olofkOh well. Time to sleep now.01:02
@juliusbhaha, not really an excuse01:02
@juliusbbut yeah, if anyone was saying they were flattering you by forking it, you'd ask them to flatter you with patches01:03
@juliusbor with flattr01:03
@juliusbmaybe we should set up a flattr as a beer fun01:03
@juliusbsplit it evenly between the contributors, based on number of lines submitted01:04
@olofkThat's a good idea. I got a flattr account, but I've only been on the giving end01:04
@olofkHmm.. that's not good for me. Most of my patches is removing lines by converting module headers to verilog 2001 :(01:04
@olofkSo I would be giving beer away01:04
@juliusbPerhaps we'll just do abs(lines added)01:18
@stekernolofk: you have the complete wrong attitude against "forking"05:55
@stekernthe double in svn is a problem, people forking of in their own repos is _not_05:55
@stekernwe're far behind this guy too ;)05:56
@stekern1502 forks only on github05:56
@stekernand it should of course be lines changed, removing stuff is a lot better than adding ;)06:01
@stekernre beer fund06:01
@stekernjeremybennett: I see that bug too, with or1k-gcc and or1k-clang and as you both deduced, the arguments to printf is correct, so something in printf is fishy08:33
@stekernand it would seem odd to use addc in a library call and not let gcc emit the instructions with it straight away08:34
@olofkstekern: I'm not against forking. I just prefer spooning, where we all cozy up and work on the code together08:38
@stekernI mean, it would be a bit like doing softmul with l.mul08:38
@stekernolofk: good, then we are in full agreement! ;)08:38
@stekernand sporking would be the ultimate thing then08:52
@olofksporking is always the ultimate thing :)08:54
@stekernhow nice, the "should be" comments in or1200-simple isn't even correct09:23
@stekernthat should have been: or1200-basic09:25
@stekernwhat is this test even doing, what exception is it supposed to return from here:09:42
@stekernnm, it writes epcr in the beginning of _T609:53
@juliusbjust saw these boards mentioned in a post on the forum:
@juliusbmaybe a little pricy, but still, not bad boards13:55
@stekernI'm more interested in the newer devices though14:10
_franck_juliusb: in openOCD, in or1k_bulk_write_memory you wrote:15:07
_franck_const unsigned int blocks_per_round = 64;15:07
_franck_Looks like this is max  with libftdi driver15:07
_franck_can you remember why such a comment ?15:07
-!- Netsplit *.net <-> *.split quits: thoron__, Amadiro15:34
LoneTechtrying out openocd now. not having much success with adv_debug_sys yet15:36
LoneTech_franck_: is openocd+virtual jtag+adv_debug_sys expected to work?15:40
LoneTechit looks like the adv_debug_sys documentation states that altera haven't documented virtual jtag, but they did in ug_virtualjtag15:41
@juliusb_franck_: I vaguely remember that, it was just some hard limit they have in their code for how many things it can handle per "go"15:49
_franck_LoneTech: yes15:50
_franck_LoneTech: which openOCd branch are yo using ?15:51
LoneTechgit from git:// merged with branch 'adv_debug_sys' back in June at the moment15:52
_franck_juliusb: because Marek tried to increase this value up to 1024 and it works perfectly, increasing the transfert speed15:52
_franck_the "official" one is now:
_franck_how did you configure openOCD ?15:53
LoneTech./configure --enable-maintainer-mode --enable-ftdi_cbus --enable-ft2232_libftdi --enable-usb_15:53
LoneTechblaster_libftdi --enable-adv_debug_sys15:53
LoneTechI'm going to try the github one now15:56
_franck_I'm looking for the configuration I'm using every day :)15:56
_franck_./configure --enable-usb_blaster_libftdi --enable-adv_debug_sys --enable-altera_vjtag--enable-maintainer-mode15:57
LoneTechthanks. looks like a missing space there though15:57
LoneTechodd, missing flyswatter_jtag_blink16:00
_franck_there is some change here, I saw this when merging16:02
LoneTechokay, this is a step up from crashing at least. mdw says target not halted, curstate says running, and halt causes a repeated "target state: halted" message16:04
LoneTechI do suspect my target isn't halting correctly, as I tried poking at the debug interface manually earlier and the status register didn't ever raise stall16:05
LoneTechwould prefer if virtual jtag was integrated into openocd16:06
_franck_how would yo do that ?16:07
LoneTechI guess as a fresh TAP16:12
LoneTechnot sure how hard it is, actually16:12
LoneTechin essence the virtual jtag system is a randomly adressable jtag tap16:13
LoneTechone can at least probe the number of devices and their IR lengths16:14
LoneTechwell, their maximum IR length16:14
_franck_yes, but the TAP is FPGA builtin, we can't change it16:15
LoneTech(the SLD framework forces the same width)16:15
-!- Netsplit *.net <-> *.split quits: Amadiro_16:16
LoneTechnot sure what you mean. I figure it ought to appear as a nested interface driver16:17
LoneTechbut it would rely on openocd being able to work with multiple jtag chains16:17
@juliusb_franck_: Ah Ok, great, perhaps it's been upped elsewhere in the code then.16:17
_franck_LoneTech: I don't understand :)16:18
LoneTechsorry. basically thinking out loud, but what I meant is moving the virtual jtag support into openocd's jtag layer, so it can be defined by the configuration files rather than compile time.16:19
LoneTechit seems there is something conceptually similar in the JTAG Route Controller support16:20
_franck_ah ok, we are talking software :) when you said "would prefer if virtual jtag was integrated into openocd" I was thinking about the vjtag hardware stuff16:21
_franck_using the vjtag is just calling a pre-init procedure to set the right virtual TAP16:23
_franck_so yes we could configure this at run time16:24
_franck_with config files16:24
LoneTechhm. something has gone wrong with the openocd I got from github - it sees the CPU but cannot halt it, apparently. the one I had from before does halt. (testing against mohor unit in orpsocv2)16:26
_franck_strange because me and Marek are using it...some bug around ?16:27
_franck_are you using the adv_dbg_if ?16:27
LoneTechno, this test was done with mohor's debug interface, because I wanted to compare a working baseline. haven't had adv_debug_sys work even once yet.16:28
_franck_ah yes, wait16:30
_franck_look at the pdf I posted in the ml16:31
_franck_if you don't use the adv_debug_if, your ./configure is wrong, you don't have to use --enable-avd_debug_sys16:41
LoneTechI am aware. I have matched that to the hardware tested each time.16:41
_franck_and then it won't work because the vjtag is not configured in or1k_jtag.c16:42
_franck_Marek did those changes here
_franck_but it's under tests and cleanup before I apply to the "official"16:43
LoneTech.. of course now I set up to properly bisect it the problem goes away. I must have made a mistake.16:49
_franck_ok great so what's your exact configuration now (hw/sw) ?16:50
LoneTechat the moment, hw is an ordinary orpsocv2 in an ordb2a running mohor's debug unit on a GPIO based TAP. sw is (flyswatter LED code disabled) configured with --enable-maintainer-mode --enable-ft2232_libftdi --enable-usb_blaster_libftdi --disable-adv_debug_sys --enable-jtag_vpi --disable-altera_vjtag16:52
LoneTechopenocd config is ft2232_layout redbee-usb ft2232_vid_pid 0x0403 0x6011 source tcl/target/or1k.cfg16:52
LoneTech(because redbee-usb uses the second interface, which is user jtag in ordb2a)16:53
_franck_--enable-jtag_vpi ?16:55
LoneTechjust had it in there. that's for verilog simulators.16:55
LoneTechas far as openocd is concerned, it's just another jtag interface driver16:56
_franck_yeah I know I wrote it :)16:57
_franck_I just don't enable two drivers at the same time16:57
LoneTechit should not be a problem, the config file activates one17:00
_franck_yes, you're right17:04
LoneTechrunning openocd in debug mode produced more interesting output for adv_debug_sys via vjtag. It's certainly talking to something, but complains of CRC errors all over. the first value read as CRC makes me think it's not a crc at all, being 0x8000000017:17
_franck_I can't help you that much since I've never used mohor tap + dbg_if17:22
_franck_I'm building an adapter right now to test this config17:23
LoneTechthat ended up working, but I'm trying to use adv_debug_sys and vjtag like you do :)17:24
LoneTechI found a suspicious detail in RTL, ADBG_USE_HISPEED was not defined.17:24
LoneTechafaik that would explain my issue perfectly17:25
_franck_yes afair, I agree17:25
_franck_you are confusing me jumping from jtag interface to jtag interface to dbg_if to vjtag to adv_dbg_if :)17:27
_franck_:) just kidding17:28
LoneTechhm, I'm afraid that didn't solve the entire problem. -d3 logs still show the same odd crc messages, still get a lot of "target state: halted" as well as "target not halted", but it sort of looks like it did manage to read a word once.17:34
LoneTechstill, progress is good17:34
_franck_so what is your test config now ? :)17:35
LoneTechan experimental orpsocv2 variant with adv_debug_sys, and same openOCD codebase this time with --enable-adv_debug_sys --enable-altera_vjtag17:35
LoneTechwhich openrisc system do you use?17:36
_franck_with an usb_blaster interface. Are you using an usb blaster or the orsoc jtag interface ?17:37
LoneTechorsoc (ftdi) jtag interface, which ought to work considering it never has a problem talking to the fpga itself17:37
LoneTechI'm a bit confused. orpsocv2 doesn't have any adv_debug_sys integrated afaik?17:38
_franck_I don't think so17:40
_franck_I used to start from the orpsocv2 from the stefan repo17:40
LoneTechah, that has adv_debugsys in the board directory. thanks :)17:42
_franck_but as I (we) never tried openOCD + adv_debug_if with anyother interface but usb_blaster....17:42
_franck_you may have problems :)17:43
LoneTechfrankly I believe that will be a non-issue17:43
LoneTechas long as it works through openocd's jtag interface drivers17:43
LoneTechI'll look into it tomorrow. Thank you for all the help!17:43
_franck_should not be an issue (but you knwo we always have surprises)17:44
_franck_you're welcome17:44
LoneTechI can probably deal with it if it does end up confused at that point17:44
_franck_anyway, good to hear you are using openOCD !17:45

Generated by 2.15.2 by Marius Gedminas - find it at!