| @olofk | Gaah!! Autotools make me crazy. I've been trying to build or1ktrace now, and it just complains about missing .Tpo files and .Plo and fuck knows what else. Not a single message to tell me what the hell is wrong or what I'm supposed to do with those files | 02:20 |
|---|---|---|
| @olofk | And or1k-desc.h includes cgen.h which includes bfd_stdinth, which apparently is missing. There is a cryptic comment above the #include that says ??? IWBN to replace bfd in the name. | 02:24 |
| @olofk | I probably should have pursued a career in stripping instead. This stuff is too complicated for me | 02:26 |
| @stekern | olofk: I'm getting the stuff about missing .Tpo too | 05:29 |
| @stekern | I've got that in some other projects too, I've never been able to figure out what's wrong | 05:29 |
| @stekern | and usually it has just automatically gone away, so I've figured it's just autotools that is having a bad day | 05:30 |
| @stekern | I don't know why juliusb went through the trouble to have autotools in a ~1-file project, I guess he is a masochist ;) | 05:34 |
| @stekern | ah, looks like libbfd wants a config.h, perhaps that was the reason | 06:10 |
| @stekern | _franck_: It seems your change fixes the breakpoint+c bug when using or_debug_proxy | 08:04 |
| @stekern | stepping over jumps with openocd still doesn't work | 08:04 |
| @stekern | and singlestepping with or_debug_proxy doesn't work at all | 08:07 |
| @stekern | I still don't think this is a rtl problem, if not a very special corner case | 08:08 |
| @stekern | hmm, intersetin, now when I reverted your patch and tried again with or_debug_proxy, singlestepping over jumps fails with that as well... | 08:44 |
| @stekern | s/intersetin/interesting | 08:44 |
| _franck_ | stekern: :( too bad, I can't do more with VPI sim... | 09:05 |
| @stekern | :( | 09:46 |
| @stekern | I'll look into it some more | 09:46 |
| @stekern | I've got or1ktrace "up and running" against current or1k-src at least | 09:47 |
| @stekern | but I just manually compiled and statically linked against libopcodes.a libbfd.a and libiberty.a | 09:47 |
| @stekern | testasm doesn't like the printouts neither | 09:48 |
| @stekern | it's about immediates being printed as hex vs dec | 09:49 |
| @stekern | it expects l.sfXXui to be printed as hex | 10:21 |
| @stekern | so not really a big deal | 10:23 |
| @stekern | olofk: to get rid of the missing .Tpo error, run autoreconf -i | 11:01 |
| @stekern | ok, now I got or1ktrace and testasm building with ./configure and make | 13:48 |
| @stekern | it's still pretty ugly though | 13:48 |
| @stekern | the information we need is 1) the path where the toolchain is installed, we could default to /opt/or1k and let people override it | 13:49 |
| @stekern | 2) the "target", i.e. or1k-elf or or1k-linux | 13:49 |
| @stekern | since the lib directory path depends on that | 13:50 |
| @stekern | we could default to or1k-elf there | 13:50 |
| _franck_ | openocd +adv_dbg_if doesn't even jump when stepi over a branch ins | 18:04 |
| _franck_ | it's not related to breakpoint | 18:04 |
| _franck_ | I'll connect another JTAG interface on my Altera board so I could debug with signal tap | 18:05 |
| @stekern | _franck_: yes, that's the bug I've been speaking about. I see it with the "classic" debug if + openocd too | 19:33 |
| @stekern | and apperantly now with or_debug_proxy + classic debug if, but that has worked before | 19:33 |
| @juliusb | :) | 19:39 |
| @juliusb | I can't recall why I made or1ktrace use autotools | 19:40 |
| @juliusb | probably something to do with masochism (assumed, if you're doing this sort of stuff IMO :P) and probably easily handling dependencies | 19:41 |
| @juliusb | maybe.. i dunno | 19:41 |
| @juliusb | I'm going to check it out,it'd be nice to have tracing working in the cycle accurate stuff | 19:42 |
| @olofk | I'm planning to do a VPI wrapper for or1ktrace later tonight. There's not any logging at all in orpsocv3 at the moment | 20:00 |
| @stekern | juliusb: hehe, yes, you have to be a bit drawn to masochism to be involved in this project, I agree :) | 20:08 |
| @juliusb | olofk: that's the way to do it man | 20:15 |
| @juliusb | I read an interesting quote today though | 20:16 |
| @juliusb | was on Slashdot front page, quote from the SAS software guy, the context was programming later in life, but he goes: | 20:18 |
| @juliusb | 'I would be happy if I just stayed in my office and programmed all day, to tell you the truth. That is my one real love in life is programming. Programming is sort of like getting to work a puzzle all day long. I actually enjoy it. It's a lot of fun. It's not even work to me. It's just enjoyable. You get to shut out all your other thoughts and just concentrate on this little thing you're trying to do, to make work it. | 20:18 |
| @juliusb | It's kind of lame Slashdot blurb: http://developers.slashdot.org/story/12/11/04/027202/why-coding-at-fifty-may-be-nifty | 20:18 |
| @juliusb | but anyway, it's kind of like that for this project, you get to pick something and knock it over | 20:19 |
| @juliusb | no one really on your case (who is paying you, anyway hehe) about getting it done, so it's kinda relaxing problem solving but, in my opinion, with a good outcome too | 20:19 |
| @stekern | totally agree | 20:20 |
| @juliusb | I could sit around doing sudoku, or I could also figure out how to make the fetch stage of the prontoespresso pipeline 1 cycle quicker :) | 20:20 |
| @juliusb | or, you know, compile 1 C file against some random build of binutils using autotools-derived make infrastructure | 20:21 |
| @stekern | you'll have time for a sudoku while you're waiting for the sims to finish ;) | 20:21 |
| @juliusb | indeed! | 20:21 |
| @juliusb | anyway, it may be construed as masochism, but it's actually fun at the time, figuring out several months later what you meant at the time is the masochistic part often :/ | 20:24 |
| @stekern | haha | 20:33 |
| @stekern | anyways, olofk, regarding your other problem with the or1k-desc.h include, you don't need that. So just delete the line. | 20:34 |
| @juliusb | stekern: another thing I've found helpful in finding nasty corner cases with deassertion of ack here and there, is allowing the mor1kx_bus_if_wb32 module to have parameterised burst length. This was very easy to add, I'll push it soon, but it could increase performance from DRAM controllers which support 16-beat bursts, or anything which supports linear | 21:06 |
| @juliusb | but running the tests with burst length 4, 8, 16, and linear is kind of nice | 21:06 |
| @juliusb | gives a bit more confidence that it'll work with various memory controllers | 21:07 |
| _franck_ | at VPI experts: I'm new to this stuff and I think I'll like it :) Do you think we could use openOCD + a special jtag driver for VPI interconnect | 21:07 |
| _franck_ | is there anythin g I should know before my first VPI project ? :) | 21:07 |
| @juliusb | it would be nice to be able to specify a big list of tests somewhere with parameters for both software and the verilog, and when we run a regression, have it run through the various configs of pipeline, bus interface burst length, ALU config, etc | 21:08 |
| @juliusb | _franck_: I'm almost certain this can be done | 21:09 |
| @juliusb | it's a bloody good idea to, because then you can use the same debug stack against the software, it's a great idea | 21:09 |
| _franck_ | I think I'm going to try this | 21:09 |
| _franck_ | not a lot of work because openOCD is pretty well modular | 21:10 |
| @juliusb | I agree, but I suspect it may already exist. | 21:10 |
| @juliusb | there may already be some virtual JTAG thing | 21:11 |
| _franck_ | ah ok, let's see | 21:11 |
| _franck_ | grep vpi/VPI in openocd doesn't give anything ;) let's ask google | 21:13 |
| @juliusb | TBH it'd be a trivial task to add support for either bit-bang or whole transactions to be performed via commands over sockets | 21:14 |
| @juliusb | kinda like what we have now, but instead of a GDB RSP stub you just run a little bespoke stub, accepting "tms=1 tck=0 trst=1 tdo=0" | 21:15 |
| @juliusb | a whole heap | 21:15 |
| _franck_ | yes, you mean at an upper layer | 21:15 |
| @juliusb | :) | 21:15 |
| @juliusb | well, it's up to you as to where you draw the line | 21:15 |
| _franck_ | but that way we couldn't debug our or1k target implementation in openOCD | 21:16 |
| @juliusb | yes you could, you would just choose the "JTAG-to-RTL-sim" adapter | 21:16 |
| @juliusb | and the or1k architecture stuff would all stay the same | 21:17 |
| @juliusb | it might be pretty slow, though, doing bitbanging | 21:17 |
| @juliusb | that's why you may be better off doing it slightly higher | 21:17 |
| @juliusb | at a layer where you handle whole JTAG transactions | 21:17 |
| @juliusb | but I would advise against putting a special mode in for the the adv_jtag_bridge only | 21:17 |
| @juliusb | because, although it's useful for that, it means any other debug bridges, like the Mohor, and any others in the future, can't use it | 21:18 |
| @juliusb | and if it's any good, you may get it into OpenOCD mainline too | 21:18 |
| @juliusb | publish the VPI stub and a simple Verilog module with it | 21:18 |
| @juliusb | it'd be pretty cool | 21:18 |
| _franck_ | ok, I'll think about this | 21:19 |
| @juliusb | I just reckon you could create a new adapter, and as an argument provide a TCP socket address as the simulator's VPI stub to connect to | 21:20 |
| @juliusb | for the target | 21:20 |
| @juliusb | that would be very cool :) | 21:20 |
| _franck_ | I think I'll go for a new jtag_interface driver communicating with VPI with TCP | 21:32 |
| _franck_ | may be slow but more reusable than a new or1k_jtag interface at target level | 21:33 |
| _franck_ | where we could send a or1k_jtag_write_cpu to the VPI stub | 21:34 |
| @juliusb | well, i think you just want to be able to send a generic JTAG command to a VPI stub implementing a generic JTAG module | 22:05 |
| @juliusb | everything OR1K, and adv_jtag_bridge for that matter, should be above this level | 22:06 |
| _franck_ | we agree, so I put this on my TODO list :) | 22:14 |
| @juliusb | :) | 22:40 |
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!