| --- Log opened Wed Dec 17 00:00:14 2014 | ||
| stekern | olofk: I think that should be possible | 05:16 |
|---|---|---|
| olofk | stekern: 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 chain | 07:55 |
| stekern | olofk: but does that matter? can't you have several taps in the chain? | 07:58 |
| * stekern suck at JTAG too | 07:58 | |
| olofk | I guess I can have several taps. Just felt easier to just route it through | 08:00 |
| olofk | newlib upstreaming is going forward. | 08:02 |
| stekern | iirc sockit has a header connected to the jtag lines | 08:02 |
| olofk | stekern: A standard 2x5 header? | 08:03 |
| stekern | if that's the standard 'blaster' connection, yes | 08:04 |
| olofk | Great that I just let a guy borrow my Sockit a week ago. | 08:05 |
| olofk | Otherwise I could have at least tested the adapter on that | 08:05 |
| olofk | stekern: Can't find a 3.1 tag for mor1kx on github | 10:03 |
| ysionneau | git fetch --tags | 10:08 |
| ysionneau | ? | 10:08 |
| ysionneau | ah on github | 10:08 |
| stekern | try nows | 10:09 |
| stekern | -s | 10:09 |
| mor1kx | [mor1kx] skristiansson tagged v3.1 at mor1kx_v3: https://github.com/openrisc/mor1kx/commits/v3.1 | 10:09 |
| olofk | yep. Great. Thanks | 10:11 |
| stekern | had forgot to push the tag... | 10:13 |
| olofk | Don't be so hard on yourself. Even a git master such as I forget do to that sometimes | 10:18 |
| stekern | that's comforting | 11:27 |
| olofk | I completely forgot how to set up JTAG VPI in OpenOCD | 13:01 |
| olofk | Ah.. just -f interface/jtag_vpi.cfg perhaps | 13:01 |
| olofk | Almost. Probably need to check the connections in the code | 13:04 |
| olofk | I realize that I don't really have a clue about what I am supposed to see | 13:37 |
| olofk | Arrgh!! When I became the ruler of the world I will outlaw inverted signals! | 13:46 |
| olofk | assign async_rst = pll_lock; <= Not the first time this happened | 13:47 |
| olofk | _franck_: Help! | 13:57 |
| olofk | Do I have to change the JTAG ID in or1k_generic.cfg, or can I override that somehow? | 13:58 |
| olofk | And 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 ./tcl | 14:00 |
| olofk | haha | 14:00 |
| olofk | thanks | 14:00 |
| _franck__ | JTAG ID doesn't matter | 14:01 |
| olofk | Ah ok. It's just a warning? | 14:02 |
| _franck__ | AFAIR yes | 14:03 |
| olofk | Fucking fuck! It works! | 14:03 |
| _franck__ | :) | 14:03 |
| _franck__ | are you using verilator ? | 14:03 |
| olofk | icarus | 14:03 |
| _franck__ | ok, sloooow | 14:04 |
| olofk | Yep. Especially with a DDR2 model in the system :) | 14:04 |
| olofk | I want to write a DFI model. Then I can simulate the whole thing including my memory controller in verilator | 14:05 |
| olofk | Oh god. Please kill me. I don't have gdb | 14:05 |
| _franck__ | are you using openocd to download something in the memory ? | 14:05 |
| _franck__ | if so, you don't need gdb | 14:05 |
| olofk | Ahh.. right. Forgot about port 4444 | 14:06 |
| olofk | or is it 3333 | 14:06 |
| _franck__ | you don't need telnet neither | 14:06 |
| olofk | Can I do it with the cloud?!?!?!? | 14:06 |
| _franck__ | just do -c "halt;load_image ....;reset" | 14:06 |
| olofk | c00l. Do you know if that accepts all elf files? I'm thinking of the weird bug that refused elfs made with the assembler | 14:07 |
| olofk | Will reset take the PC to 0x100 btw? | 14:08 |
| _franck__ | I mean halt; load_image ...;reg npc 0x100;resume" | 14:08 |
| olofk | cool | 14:08 |
| _franck__ | elf must be out of or1k-elf-ld | 14:08 |
| _franck__ | so the have a program header | 14:08 |
| olofk | Sure. I'll find a good image | 14:09 |
| _franck__ | http://juliusbaxter.net/openrisc-irc/%23openrisc.2014-04-11.log.html | 14:10 |
| _franck__ | at 14:20 | 14:10 |
| _franck__ | olofk: try this: http://openocd.zylin.com/#/c/2164/ | 14:13 |
| _franck__ | you'll have a nice progress bar | 14:13 |
| maxpaln | olofk: I have been working on a few enhancements for the BFM. | 14:19 |
| maxpaln | Probably 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 |
| maxpaln | I have a few other useability and reporting enhancements to add too - stuff I've added as I have been using it more. | 14:21 |
| maxpaln | I should be able to share later by Christmas I think - | 14:21 |
| olofk | maxpaln: 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 much | 15:05 |
| olofk | maxpaln: And the BFM doesn't test classic cycles at all IIRC. | 15:15 |
| stekern | end of burst cycles == classic cycles | 15:20 |
| olofk | aha | 15:20 |
| olofk | But what is CTI=000 then? | 15:20 |
| maxpaln | Actually that is a good point - the BFM really should inject true Classic cycles. | 16:53 |
| maxpaln | I was referring to the pseudo classic cycle where the burst length is 1 | 16:53 |
| maxpaln | Since 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 length | 16:55 |
| maxpaln | At 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 |
| maxpaln | at least not in all my testing... | 16:59 |
| stekern | olofk: I'm not sure why they decided to designate between CTI=000 and CTI=111, they are essentially the same | 17:32 |
| --- Log closed Thu Dec 18 00:00:16 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!