IRC logs for #openrisc Wednesday, 2014-12-17

--- Log opened Wed Dec 17 00:00:14 2014
stekernolofk: I think that should be possible05:16
olofkstekern: I suck at JTAG, but I would need to repurpose the dedicated pins as regular I/O pins, right? Otherwise there will be two taps in my chain07:55
stekernolofk: but does that matter? can't you have several taps in the chain?07:58
* stekern suck at JTAG too07:58
olofkI guess I can have several taps. Just felt easier to just route it through08:00
olofknewlib upstreaming is going forward.08:02
stekerniirc sockit has a header connected to the jtag lines08:02
olofkstekern: A standard 2x5 header?08:03
stekernif that's the standard 'blaster' connection, yes08:04
olofkGreat that I just let a guy borrow my Sockit a week ago.08:05
olofkOtherwise I could have at least tested the adapter on that08:05
olofkstekern: Can't find a 3.1 tag for mor1kx on github10:03
ysionneaugit fetch --tags10:08
ysionneauah on github10:08
stekerntry nows10:09
mor1kx[mor1kx] skristiansson tagged v3.1 at mor1kx_v3:
olofkyep. Great. Thanks10:11
stekernhad forgot to push the tag...10:13
olofkDon't be so hard on yourself. Even a git master such as I forget do to that sometimes10:18
stekernthat's comforting11:27
olofkI completely forgot how to set up JTAG VPI in OpenOCD13:01
olofkAh.. just -f interface/jtag_vpi.cfg perhaps13:01
olofkAlmost. Probably need to check the connections in the code13:04
olofkI realize that I don't really have a clue about what I am supposed to see13:37
olofkArrgh!! When I became the ruler of the world I will outlaw inverted signals!13:46
olofkassign async_rst = pll_lock; <= Not the first time this happened13:47
olofk_franck_: Help!13:57
olofkDo I have to change the JTAG ID in or1k_generic.cfg, or can I override that somehow?13:58
olofkAnd what's the syntax for overriding TAP_TYPE?13:59
_franck__hmmm, wait, I'm looking in IRC archives ;)13:59
_franck__./src/openocd -f ./tcl/interface/jtag_vpi.cfg -c "set TAP_TYPE MOHOR" -f ./tcl/board/or1k_generic.cfg -s ./tcl14:00
_franck__JTAG ID doesn't matter14:01
olofkAh ok. It's just a warning?14:02
_franck__AFAIR yes14:03
olofkFucking fuck! It works!14:03
_franck__are you using verilator ?14:03
_franck__ok, sloooow14:04
olofkYep. Especially with a DDR2 model in the system :)14:04
olofkI want to write a DFI model. Then I can simulate the whole thing including my memory controller in verilator14:05
olofkOh god. Please kill me. I don't have gdb14:05
_franck__are you using openocd to download something in the memory ?14:05
_franck__if so, you don't need gdb14:05
olofkAhh.. right. Forgot about port 444414:06
olofkor is it 333314:06
_franck__you don't need telnet neither14:06
olofkCan I do it with the cloud?!?!?!?14:06
_franck__just do -c "halt;load_image ....;reset"14:06
olofkc00l. Do you know if that accepts all elf files? I'm thinking of the weird bug that refused elfs made with the assembler14:07
olofkWill reset take the PC to 0x100 btw?14:08
_franck__I mean halt; load_image ...;reg npc 0x100;resume"14:08
_franck__elf must be out of or1k-elf-ld14:08
_franck__so the have a program header14:08
olofkSure. I'll find a good image14:09
_franck__at 14:2014:10
_franck__olofk: try this:
_franck__you'll have a nice progress bar14:13
maxpalnolofk: I have been working on a few enhancements for the BFM.14:19
maxpalnProbably the most notable is that as you increase the maximum burst length it becomes less and less likely you will get any classic cycles generated by the BFM. They only get generated when the burst length is 1 - since the classic cycle is a bit of a special case I think it is worth modifying the cycle generation logic to make a classic cycle more likely to occur.14:21
maxpalnI have a few other useability and reporting enhancements to add too - stuff I've added as I have been using it more.14:21
maxpalnI should be able to share later by Christmas I think -14:21
olofkmaxpaln: Sounds great. I've done some modifications of your stuff here on my part. I think we should merge things ASAP, to avoid a complete mess when they diverge too much15:05
olofkmaxpaln: And the BFM doesn't test classic cycles at all IIRC.15:15
stekernend of burst cycles == classic cycles15:20
olofkBut what is CTI=000 then?15:20
maxpalnActually that is a good point - the BFM really should inject true Classic cycles.16:53
maxpalnI was referring to the pseudo classic cycle where the burst length is 116:53
maxpalnSince CTI=111 at the start of the cycle this certainly produces some neat corner cases in my code. But since the burst length is just a random distribution between 1 and 'MAX_BURST_LEN' it becomes decreasingly likely that you'll get one of these pseudo Classic Cycles as you increase the burst length16:55
maxpalnAt the moment the BFM fixes cycle_type to 'BURST_CYCLE' and CTI gets a value depending on whether the remaining burst length is 1 or greater. So CTI=000 will never happen from the BFM - it so happens that this never occurs from MOR1KX either :-)16:58
maxpalnat least not in all my testing...16:59
stekernolofk: I'm not sure why they decided to designate between CTI=000 and CTI=111, they are essentially the same17:32
--- Log closed Thu Dec 18 00:00:16 2014

Generated by 2.15.2 by Marius Gedminas - find it at!