IRC logs for #openrisc Sunday, 2012-11-04

@olofkGaah!! 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 files02:20
@olofkAnd 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
@olofkI probably should have pursued a career in stripping instead. This stuff is too complicated for me02:26
@stekernolofk: I'm getting the stuff about missing .Tpo too05:29
@stekernI've got that in some other projects too, I've never been able to figure out what's wrong05:29
@stekernand usually it has just automatically gone away, so I've figured it's just autotools that is having a bad day05:30
@stekernI 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
@stekernah, looks like libbfd wants a config.h, perhaps that was the reason06:10
@stekern_franck_: It seems your change fixes the breakpoint+c bug when using or_debug_proxy08:04
@stekernstepping over jumps with openocd still doesn't work08:04
@stekernand singlestepping with or_debug_proxy doesn't work at all08:07
@stekernI still don't think this is a rtl problem, if not a very special corner case08:08
@stekernhmm, intersetin, now when I reverted your patch and tried again with or_debug_proxy, singlestepping over jumps fails with that as well...08:44
_franck_stekern: :( too bad, I can't do more with VPI sim...09:05
@stekernI'll look into it some more09:46
@stekernI've got or1ktrace "up and running" against current or1k-src at least09:47
@stekernbut I just manually compiled and statically linked against libopcodes.a libbfd.a and libiberty.a09:47
@stekerntestasm doesn't like the printouts neither09:48
@stekernit's about immediates being printed as hex vs dec09:49
@stekernit expects l.sfXXui to be printed as hex10:21
@stekernso not really a big deal10:23
@stekernolofk: to get rid of the missing .Tpo error, run autoreconf -i11:01
@stekernok, now I got or1ktrace and testasm building with ./configure and make13:48
@stekernit's still pretty ugly though13:48
@stekernthe information we need is 1) the path where the toolchain is installed, we could default to /opt/or1k and let people override it13:49
@stekern2) the "target", i.e. or1k-elf or or1k-linux13:49
@stekernsince the lib directory path depends on that13:50
@stekernwe could default to or1k-elf there13:50
_franck_openocd +adv_dbg_if doesn't even jump when stepi over a branch ins18:04
_franck_it's not related to breakpoint18:04
_franck_I'll connect another JTAG interface on my Altera board so I could debug with signal tap18:05
@stekern_franck_: yes, that's the bug I've been speaking about. I see it with the "classic" debug if + openocd too19:33
@stekernand apperantly now with or_debug_proxy + classic debug if, but that has worked before19:33
@juliusbI can't recall why I made or1ktrace use autotools19:40
@juliusbprobably something to do with masochism (assumed, if you're doing this sort of stuff IMO :P) and probably easily handling dependencies19:41
@juliusbmaybe.. i dunno19:41
@juliusbI'm going to check it out,it'd be nice to have tracing working in the cycle accurate stuff19:42
@olofkI'm planning to do a VPI wrapper for or1ktrace later tonight. There's not any logging at all in orpsocv3 at the moment20:00
@stekernjuliusb: hehe, yes, you have to be a bit drawn to masochism to be involved in this project, I agree :)20:08
@juliusbolofk: that's the way to do it man20:15
@juliusbI read an interesting quote today though20:16
@juliusbwas 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
@juliusbIt's kind of lame Slashdot blurb:
@juliusbbut anyway, it's kind of like that for this project, you get to pick something and knock it over20:19
@juliusbno 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 too20:19
@stekerntotally agree20:20
@juliusbI 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
@juliusbor, you know, compile 1 C file against some random build of binutils using autotools-derived make infrastructure20:21
@stekernyou'll have time for a sudoku while you're waiting for the sims to finish ;)20:21
@juliusbanyway, 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
@stekernanyways, olofk, regarding your other problem with the or1k-desc.h include, you don't need that. So just delete the line.20:34
@juliusbstekern: 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 linear21:06
@juliusbbut running the tests with burst length 4, 8, 16, and linear is kind of nice21:06
@juliusbgives a bit more confidence that it'll work with various memory controllers21: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 interconnect21:07
_franck_is there anythin g I should know before my first VPI project ? :)21:07
@juliusbit 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, etc21:08
@juliusb_franck_: I'm almost certain this can be done21:09
@juliusbit's a bloody good idea to, because then you can use the same debug stack against the software, it's a great idea21:09
_franck_I think I'm going to try this21:09
_franck_not a lot of work because openOCD is pretty well modular21:10
@juliusbI agree, but I suspect it may already exist.21:10
@juliusbthere may already be some virtual JTAG thing21:11
_franck_ah ok, let's see21:11
_franck_grep vpi/VPI in openocd doesn't give anything ;) let's ask google21:13
@juliusbTBH it'd be a trivial task to add support for either bit-bang or whole transactions to be performed via commands over sockets21:14
@juliusbkinda 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
@juliusba whole heap21:15
_franck_yes, you mean at an upper layer21:15
@juliusbwell, it's up to you as to where you draw the line21:15
_franck_but that way we couldn't debug our or1k target implementation in openOCD21:16
@juliusbyes you could, you would just choose the "JTAG-to-RTL-sim" adapter21:16
@juliusband the or1k architecture stuff would all stay the same21:17
@juliusbit might be pretty slow, though, doing bitbanging21:17
@juliusbthat's why you may be better off doing it slightly higher21:17
@juliusbat a layer where you handle whole JTAG transactions21:17
@juliusbbut I would advise against putting a special mode in for the the adv_jtag_bridge only21:17
@juliusbbecause, although it's useful for that, it means any other debug bridges, like the Mohor, and any others in the future, can't use it21:18
@juliusband if it's any good, you may get it into OpenOCD mainline too21:18
@juliusbpublish the VPI stub and a simple Verilog module with it21:18
@juliusbit'd be pretty cool21:18
_franck_ok, I'll think about this21:19
@juliusbI 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 to21:20
@juliusbfor the target21:20
@juliusbthat would be very cool :)21:20
_franck_I think I'll go for a new jtag_interface driver communicating with VPI with TCP21:32
_franck_may be slow but more reusable than a new or1k_jtag interface at target level21:33
_franck_where we could send a or1k_jtag_write_cpu to the VPI stub21:34
@juliusbwell, i think you just want to be able to send a generic JTAG command to a VPI stub implementing a generic JTAG module22:05
@juliusbeverything OR1K, and adv_jtag_bridge for that matter, should be above this level22:06
_franck_we agree, so I put this on my TODO list :)22:14

Generated by 2.15.2 by Marius Gedminas - find it at!