| --- Log opened Mon Jul 14 00:00:18 2014 | ||
| stekern | blueCmd_: I've noticed that too, it's a regression, introduced by wallento's multiway cache stuff | 04:16 |
|---|---|---|
| stekern | haven't got to look at it closer if it's really a circular path, verilator sometimes get confused and marks paths that really aren't circular | 04:18 |
| stekern | sometimes just changing a 'always @(*) sig1 = sig2;' to 'assign sig1 = sig2' can remove them | 04:19 |
| stekern | the statements aren't that simple of course | 04:20 |
| stekern | there are a couple of ternary muxes where a case-statement would be more readable in mor1kx just because of that | 04:21 |
| stekern | for instance: https://github.com/openrisc/mor1kx/commit/97b7b9953991858d89856d53bc8058fbbc085105 | 04:26 |
| stekern | dalias: I've implemented futex_atomic_* in Linux to be able to use robust_list, but I'm still having some problems with the pthread_robust test. The problem is that when the kernel starts to walk the list, it ends in a 0 pointer. | 05:04 |
| stekern | I'm probably misunderstanding something, but looking at the code that 'generates' the list: | 05:05 |
| stekern | http://git.musl-libc.org/cgit/musl/tree/src/thread/pthread_mutex_trylock.c#n39 | 05:05 |
| stekern | isn't that expected to happen if m->m_next is zero? | 05:06 |
| stekern | (i.e. when self->robust_list.head is zero at line 39) | 05:07 |
| stekern | hmm, maybe I start to understand this now... | 05:56 |
| jtdesousa | Does anybody know how can programs do printf in the verilog and verilator testbenches for the fusesoc mor1x-generic system? | 10:23 |
| jtdesousa | ok I see orpsoc_top | 10:26 |
| jtdesousa | #(.UART_SIM (1)) | 10:26 |
| jtdesousa | dut | 10:26 |
| jtdesousa | what's the best way to make it scanf rather than just printf ? | 10:38 |
| stekern | jtdesousa: you can look how it used to work in the old sysc tb | 10:57 |
| stekern | https://github.com/juliusbaxter/mor1kx-dev-env/blob/master/bench/sysc/src/UartSC.cpp | 10:57 |
| jtdesousa | I have done that and it is working | 10:58 |
| jtdesousa | in that way | 10:58 |
| jtdesousa | I was hoping there would be a way forward with the new testbenches | 10:59 |
| olofk | jtdesousa: The support for simulated UARTs are still a bit unfinished unfortunately | 11:24 |
| blueCmd_ | that would be quite easy to build though | 12:47 |
| blueCmd_ | I want that for my project so I can sit down and build that tonight I think | 12:47 |
| olofk | blueCmd_: Awesome | 13:18 |
| olofk | Bonus points if you make a VPI wrapper for it as well so that we can reuse it in the event driven sims | 13:18 |
| olofk | Kind of like what is done for the elf-loader | 13:20 |
| blueCmd_ | olofk: I will if you can tell me what VPI is | 13:21 |
| olofk | It's the foreign language interface for verilog | 13:23 |
| olofk | It allows you to register new system commands | 13:23 |
| olofk | And implement them in a .so | 13:23 |
| olofk | I think that Mr Milkymist uses it to embed a whole python interpreter in some clever way that I haven't investigated further :) | 13:25 |
| olofk | In the OpenRISC project we use it for the JTAG server and Elf loading | 13:27 |
| blueCmd_ | oh. I think I used something like that in modelsim before, but specific for modelsim | 13:39 |
| blueCmd_ | I hooked up python to it as well | 13:39 |
| olofk | blueCmd_: Did you forget to include wb_axi_slave in your pull request? | 14:33 |
| blueCmd_ | olofk: no, it's not written yet | 14:48 |
| blueCmd_ | :) | 14:48 |
| olofk | ahh | 14:48 |
| olofk | Well, the python code looks nice | 14:48 |
| blueCmd_ | I have the skeletons for the cores but they will need a bunch of testing and stuff. I have a special repo for that (bluecmd/wb-axi) | 14:49 |
| olofk | cool | 14:49 |
| blueCmd_ | avalon should work though | 14:49 |
| olofk | In that case, I think we should remove the axi stuff from VALID_BUS_TYPES for now | 14:51 |
| olofk | We can keep the rest if you're somewhat confident that the converters will work out | 14:51 |
| olofk | I'm a bit worried about the full axi4 conversion | 14:52 |
| olofk | Not "It will never work"-worried, but more like "It will be very inefficient"-worried | 14:53 |
| olofk | But please prove me wrong. It would be awesome to have that bridge :) | 14:53 |
| olofk | And wb_intercon_gen will need a serious refactoring soon | 14:54 |
| olofk | I'm getting more and more eager to implement arbitrary width conversions. I think it will do wonders for performance | 14:54 |
| olofk | The whole thing should probably be reimplemented with some graph helper library | 14:55 |
| olofk | So we can drop in blocks easier | 14:56 |
| olofk | Like resizers, bridges, watchdogs and things like that | 14:56 |
| jeremy_bennett | blueCmd_: Just seen your comments from yesterday. Well done tracking down authors. The challenge will be some of the older authors who have fallen out with OpenCores. So characterizing what individual contributions they have made will be really useufl. | 15:33 |
| jeremy_bennett | I'm slightly surprised Rich D'Addio doesn't appear in the list, since he was the GCC maintainer for quite a while. | 15:33 |
| blueCmd_ | jeremy_bennett: as for their individual contributions I'm not sure that's possible | 15:47 |
| blueCmd_ | jeremy_bennett: for stuff that's older than we have revision history logs for I grabed copyright information from headers, I don't know of any other way to identify persons before that | 15:50 |
| blueCmd_ | olofk: sure, we can drop it from valid for now | 15:51 |
| blueCmd_ | olofk: I'm curious though, why would full AXI4 be slow? | 18:20 |
| olofk | blueCmd_: Because axi4 has separate channels for the data going in each direction. It's basically four AXI4-Stream ports | 18:29 |
| olofk | So you usually send a burst of requests and get a burst of acks back | 18:30 |
| olofk | For wishbone, we need every transaction to be acked | 18:30 |
| olofk | before we can start a new one | 18:30 |
| olofk | wishbone b4 remedies this somewhat | 18:31 |
| olofk | So it's not really that axi4 will be slow, but it will not reach it's full potential | 18:32 |
| blueCmd_ | olofk: right, WB is half-duplex and AXI4 is full | 18:33 |
| blueCmd_ | AXI4 also supports transactions and out-of-order things | 18:33 |
| blueCmd_ | but I don't think either is used that much | 18:33 |
| olofk | Yeah, I never seen out-of-order been used | 18:34 |
| blueCmd_ | maybe I'm wrong - but in any case it doesn't matter much since the CPU can probably only execute one thing at a time and having a WB<->AXI interface just at the CPU level and using an AXI interconnect would solve that issue if you were worried about that | 18:34 |
| olofk | True | 18:34 |
| olofk | Then you only have to worry about the indefinite wishbone burst lengths | 18:35 |
| olofk | For most masters it's probably ok though, since they only generate fixed-size bursts in practice | 18:35 |
| olofk | Wishbone masters | 18:35 |
| blueCmd_ | yeah, there ought to be some issues - but for a first version it doesn't really matter much | 18:35 |
| olofk | No, I agree. We can worry about that later | 18:36 |
| olofk | But it will be tricky to have a complete generic wb<->axi4 bridge | 18:36 |
| blueCmd_ | ofc, it might not even be possible to be 100% compatible | 18:37 |
| olofk | Not without resorting to FIFOs or RAMs to hold the data until all properties are known | 18:38 |
| blueCmd_ | olofk: DPI or VPI for my uart? | 18:38 |
| olofk | Enough about that now. Start implementing :) | 18:38 |
| olofk | DPI is nicer, but it's a system verilog thing, and all tools don't speak system verilog good enough yet | 18:39 |
| blueCmd_ | right, DPI it is. verilator seems to work with it | 18:39 |
| olofk | I was going to say VPI :) | 18:39 |
| blueCmd_ | ok | 18:39 |
| blueCmd_ | I'll make it easy enought support both | 18:40 |
| olofk | But if you do it like the elf-loader, you can implement all the business logic and just add thin wrappers for the different cases | 18:40 |
| blueCmd_ | yeah, that's how I would do it anyway | 18:40 |
| olofk | We're soon reaching the point where we don't have to worry about sv support, which will be awesome since we can then use modports, records, multi dimensional ports and other things that would take verilog from the stone age | 18:41 |
| blueCmd_ | into the bronze age | 18:43 |
| blueCmd_ | but yes, that's why I use systemverilog in mexiko | 18:43 |
| blueCmd_ | multi-dimensional ports mostly | 18:43 |
| blueCmd_ | ugha, vpi is ugly :P | 18:44 |
| olofk | Yeah, that's probably the biggest annoyance, and the reason why I decided to autogenerate the wb_intercon top-level | 18:44 |
| blueCmd_ | what simulators does not support dpi? | 18:44 |
| olofk | modelsim doesn't suport sv | 18:44 |
| blueCmd_ | ah. | 18:44 |
| olofk | The big brother, questa sim does, but that costs ~50% more than modelsim | 18:44 |
| olofk | And there's no free version that supports it at all | 18:45 |
| blueCmd_ | hm it does appear to support it | 18:45 |
| olofk | Icarus and verilator have been working on sv for the last couple of years. Not sure how much of the standard they have implemented yet | 18:45 |
| olofk | Quartus and ISE supports part of the standard as well | 18:46 |
| olofk | hmm.. are you sure about that? Do you mean the free version? | 18:47 |
| blueCmd_ | free version doesn't support anything | 18:47 |
| blueCmd_ | but the non-questasim one | 18:47 |
| blueCmd_ | this random blog: http://hdfpga.blogspot.ie/2011/04/systemverilog-dpi-dpi-c-tutorial_18.html | 18:48 |
| olofk | ah ok. It will stilly require a separate add-on license | 18:48 |
| blueCmd_ | and that is not the case for vpi? | 18:49 |
| olofk | Nope. VPI is part of the verilog standard and is supported by all modelsim versions as well as icarus | 18:49 |
| olofk | verilator implements some parts of VPI as well, but I haven't tried that | 18:50 |
| olofk | Hmm.. looks like I'm wrong here. Keep reading that modelsim supports the design features of system verilog, but not the verification features | 18:54 |
| olofk | So all the things I mentioned previous might actually be supported | 18:54 |
| blueCmd_ | i'd mucher implement it in DPI I think | 18:55 |
| blueCmd_ | just looking at example code | 18:55 |
| olofk | Yeah, it's a lot nicer | 18:55 |
| olofk | Do the DPI implementation first then, and try it with different simulators to see if it works | 18:55 |
| blueCmd_ | ack | 18:56 |
| olofk | Just remembered that if you're using fusesoc, you will need to hack in DPI support. Only VPI is supported right now | 19:07 |
| blueCmd_ | olofk: glad I'm not using fusesoc then ;) | 19:38 |
| olofk | haha. Then you should be alright :) | 19:45 |
| olofk | blueCmd_: You could also push the uart data through a socket. That's also on my TODO list :) | 19:53 |
| olofk | So you can telnet into the simulation | 19:54 |
| olofk | Useful if you're having the simulation on a different machine, or if you want to write debug info on stdout | 19:54 |
| blueCmd_ | olofk: that's just piping to nc | 20:41 |
| blueCmd_ | or no, not really | 20:42 |
| blueCmd_ | hm, yeah - that's up for someone else. I just run it over ssh | 20:42 |
| blueCmd_ | it supports different streams for in / out, it doesn't need to be stdin/stdout but writing reliable socket stuff is a pain | 20:42 |
| olofk | Is it really that hard? I've used it in some VPI code at work and _franck_ uses it for the JTAG server | 20:48 |
| olofk | I'm pretty green when it comes to sockets though, so most probably there are things I'm not seeing | 20:49 |
| blueCmd_ | olofk: yes, it is hard. have you ever wondered why telnet prompts suck and ssh is much nicer? | 20:54 |
| blueCmd_ | not to discuss ipv6 | 20:54 |
| olofk | Yeah, telnet isn't all that nice, but you can use netcat instead | 20:55 |
| blueCmd_ | still same | 20:55 |
| olofk | And I never thought it had anything to do with the underlying socket implementation | 20:55 |
| blueCmd_ | i'm talking about real terminal control | 20:55 |
| olofk | And ssh must still use sockets, right? | 20:55 |
| olofk | Ah ok | 20:55 |
| olofk | Yes, I admit I ignored that part | 20:56 |
| blueCmd_ | yes, ofc it uses sockets. | 20:56 |
| blueCmd_ | http://blog.cmd.nu/2013/02/protocol-agnostic-socket-programming.html | 20:56 |
| blueCmd_ | that's socket boilerplate | 20:57 |
| blueCmd_ | that's just for the setting up the socket | 20:57 |
| blueCmd_ | never mind handling all the signals and special conditions you have | 20:57 |
| olofk | ah cool. I've actually considered adding that kind of boilerplate to a vpi_socket core that can be used to implement pushing different protocols over sockets. It's on my TODO list :) | 20:58 |
| blueCmd_ | :) | 20:58 |
| olofk | But ok, I see that it can be a bit problematic to use for stdio, since we have to catch all escape sequences | 21:00 |
| olofk | For well-behaved data it shouldn't be any problems though, right? | 21:00 |
| blueCmd_ | data is never well-behaved | 21:02 |
| blueCmd_ | you can do it for basic stuff yes, but it will suck for anything prompt-related | 21:03 |
| olofk | Time to wrap an SSH client into VPI then :) | 21:04 |
| olofk | Or use dbus :) | 21:04 |
| olofk | I could probably come up with even worse ideas if you give me some time :) | 21:04 |
| blueCmd_ | IMHO, just dump the debug data to text files or whatever | 21:05 |
| olofk | What annoys me the most is that it would all be very simple if just verilog's getc wasn't line buffered | 21:06 |
| blueCmd_ | which is exactly my point | 21:06 |
| blueCmd_ | that is not verilogs fault | 21:06 |
| blueCmd_ | you would have the same problems with using sockets | 21:06 |
| blueCmd_ | because it's the terminals fault | 21:06 |
| olofk | really? | 21:07 |
| blueCmd_ | you have to t.c_lflag &= ~(ICANON | ECHO); | 21:07 |
| blueCmd_ | yes | 21:07 |
| blueCmd_ | to tell it to flush without newline | 21:07 |
| blueCmd_ | I do stuff like that in my uart DPI module to make it nice and smooth | 21:07 |
| olofk | hmm | 21:07 |
| olofk | But then it can't be the terminal's fault. It must be the $fgetc implementation in the various verilog sims that do it wrong | 21:07 |
| blueCmd_ | no | 21:08 |
| olofk | And/or the LRM that doesn't specify how it should be done, or provide alternative ways to do buffering | 21:08 |
| blueCmd_ | if you do fgetc in C by default it will not catch single characters | 21:08 |
| olofk | is that getchar then? | 21:10 |
| blueCmd_ | hm? | 21:12 |
| olofk | I admit learning C from an early 80's edition of "Vägen till C", so my knowledge might be a bit outdated :) | 21:13 |
| blueCmd_ | olofk: https://github.com/bluecmd/sim-uart | 21:17 |
| blueCmd_ | olofk: hah, yeah getchar isn't really a thing | 21:17 |
| blueCmd_ | it sucks in that you don't know what you get | 21:18 |
| blueCmd_ | if you turn on non-blocking mode (so that you can read every character without newline) it returns 0 - so if you want to read actual \00 you cannot | 21:18 |
| olofk | Does the cryptic line you pasted above solve that? | 21:19 |
| blueCmd_ | olofk: it makes it not block | 21:20 |
| blueCmd_ | olofk: no matter what you try, every read call targeted at stdin will block until you hit return | 21:20 |
| blueCmd_ | i.e. the key (a.ka. enter), not "return 0;" | 21:20 |
| blueCmd_ | you _need_ to set stdin in non-blocking mode for that, as well as tell it to not wait for newline (which is the funky line) | 21:21 |
| olofk | Oh well. Then the verilog $fgetc is probably the easiest way to do it anyway then? | 21:21 |
| blueCmd_ | olofk: https://github.com/bluecmd/sim-uart/blob/master/dpi_uart.cpp#L22 | 21:21 |
| olofk | ah ok | 21:21 |
| blueCmd_ | olofk: so what you _can_ do is that in your testbench.cpp or in your DPI module you run the things I do in uart_init | 21:22 |
| blueCmd_ | you can potentially even make a program that does these things and then exec's the simulator so that the simulator gets the modified stdin | 21:23 |
| blueCmd_ | jtdesousa: for UART in testbenches: https://github.com/bluecmd/sim-uart | 21:23 |
| stekern | interesting, openrisc Linux doesn't complain about this: http://pastie.org/9390341 | 21:35 |
| blueCmd_ | olofk: I submitted a commit to my pull request for wb_intercon_gen to disable axi4 and axi4-lite for now | 21:39 |
| blueCmd_ | oh | 21:39 |
| blueCmd_ | you _just_ commented | 21:39 |
| blueCmd_ | hah | 21:39 |
| olofk | haha | 21:40 |
| blueCmd_ | olofk: done | 21:44 |
| blueCmd_ | stekern: if you could have a look at the Verilog part of https://github.com/openrisc/orpsoc-cores/pull/74/files that would be stellar | 21:45 |
| blueCmd_ | since I'm changing your poor avalon bridges | 21:45 |
| blueCmd_ | stekern: also, that's odd (the pastie) | 21:45 |
| stekern | yeah, I took a look earlier, I think it looks fine | 21:49 |
| olofk | blueCmd_: I'm not very hot on the submodules idea (surprise! :)) | 21:49 |
| blueCmd_ | stekern: i was prepared to fight you on 'master input' = 'slave'! | 21:49 |
| blueCmd_ | olofk: yeah, lucky for you that I'm here to convince you! | 21:50 |
| olofk | :) | 21:50 |
| stekern | it's changing the de-facto-standard avalon signal names, but I guess that's to fit better into wb_intercon? | 21:50 |
| blueCmd_ | stekern: in wb_intercon every direction is either m2s or s2m, it kind of makes sense to keep it that way | 21:50 |
| olofk | I'm not very hot on changing de-facto standard names either (except for the stupid wishbone data from slave signal) | 21:51 |
| blueCmd_ | stekern: ah for avalon | 21:51 |
| blueCmd_ | stekern: so the signal names are generated "m/s_bus_port_dir" or something like that, so yes - that makes it fit nice and snug | 21:51 |
| blueCmd_ | that said, it can be a format string per bus type as well | 21:52 |
| blueCmd_ | so it's certainly not impossible | 21:52 |
| stekern | but you're just changing the prefix, so I'm not going to make a big fuss about it if it makes life easier elsewhere | 21:52 |
| blueCmd_ | right. it does make it easier (if not easier to read I think) | 21:53 |
| olofk | blueCmd_: The reasons I'm against the submodules are: | 21:53 |
| olofk | Very nice! | 21:53 |
| olofk | I would like to see the exceptions being caught in main, and not adding the new bus types to VALID_BUS_TYPES until we have implementations for the bridges. Other than that it looks good | 21:53 |
| blueCmd_ | for axi there is yet another format so | 21:53 |
| olofk | fuck | 21:53 |
| blueCmd_ | olofk: ! :D | 21:53 |
| blueCmd_ | 22:53 < olofk> blueCmd_: The reasons I'm against the submodules are: | | 21:53 |
| blueCmd_ | 22:53 < olofk> Very nice! | 21:53 |
| blueCmd_ | you're really selling it | 21:54 |
| olofk | 1) I don't want to tie this to a particular VCS without any great benefits | 21:54 |
| stekern | olofk: you're already screwed there, you're tied to svn | 21:54 |
| olofk | 2) I want the repo to be read-only for use on shared systems | 21:54 |
| blueCmd_ | (and github) | 21:54 |
| olofk | 3) It might clash with the work I'm doing on versioning support | 21:54 |
| blueCmd_ | 2) git submodules update --recursive --remote should check everything out at once | 21:55 |
| blueCmd_ | or something like that | 21:55 |
| blueCmd_ | and submodules will not update themselves once they have been fetched once, as it is now | 21:55 |
| blueCmd_ | 3) how so? | 21:55 |
| stekern | it's actually not so odd that Linux doesn't complain about the 0 pointer derefencing I think, after all, we are running our code in that page | 21:55 |
| olofk | 4) I want to move most of the actual code away from orpsoc-cores, and then it would be easy for anyone to set up their own meta repository with the cores they want anyway | 21:55 |
| blueCmd_ | stekern: yes, but it shouldn't be mapped in userspace, right? | 21:56 |
| stekern | umm, how would you otherwise run the code? | 21:56 |
| blueCmd_ | 4) submodules makes that easier :P | 21:56 |
| blueCmd_ | stekern: not from page 0? :P | 21:56 |
| olofk | blueCmd_: 4) Yes. But not with orpsoc-cores as the meta repo | 21:57 |
| stekern | blueCmd_: but the code is in page 0 | 21:57 |
| blueCmd_ | olofk: why? | 21:57 |
| blueCmd_ | stekern: why? | 21:57 |
| olofk | god: why? | 21:57 |
| stekern | well, that's perhaps a good question ;) | 21:57 |
| blueCmd_ | :) | 21:58 |
| blueCmd_ | :) | 21:58 |
| blueCmd_ | olofk: I mean, how is it any harder / easier with/without submodules to set up a new meta repository? | 21:58 |
| stekern | but it's not really Linux fault | 21:58 |
| olofk | blueCmd_: Well, for fusesoc users, we're not gaining anything by changing to submodules | 21:59 |
| blueCmd_ | yes we are | 21:59 |
| blueCmd_ | we gain support for repositories not on git | 21:59 |
| olofk | ? | 21:59 |
| blueCmd_ | github provider doesn't play well with repositories outside of github | 21:59 |
| stekern | s/not on git/not on github | 22:00 |
| stekern | ? | 22:00 |
| blueCmd_ | yes | 22:00 |
| blueCmd_ | sorry | 22:00 |
| olofk | No, that's true. Especially since I replaced the code to get an archive instead of cloning | 22:00 |
| olofk | But I always intended to add a generic git provider whenever that was needed | 22:00 |
| Hesham | Hi all, I have a problem regarding gdb, any help? | 22:00 |
| blueCmd_ | hi Hesham ! | 22:00 |
| Hesham | hi Christian | 22:01 |
| blueCmd_ | must be in the middle of the night where you are | 22:01 |
| Hesham | Yeah, it's :) | 22:01 |
| blueCmd_ | what's up with gdb? | 22:01 |
| blueCmd_ | (we're having multiple conversations here, so try not to be confused! :) ) | 22:01 |
| Hesham | First I am writing as assembly function let's call it _OR1K_Exception_Process | 22:01 |
| blueCmd_ | olofk: honestly, with submodules you're better than opencores for a central core repository | 22:02 |
| Hesham | I am calling this function from the exception entry using l.jal register from another assembly file | 22:02 |
| Hesham | The _OR1K_Exception_Process allocate space of 128 byte for registers to be saved on stack | 22:03 |
| Hesham | The problem is when I try to set a break point at _OR1K_Exception_Process from gdb | 22:03 |
| Hesham | I got gdb internal error | 22:03 |
| Hesham | ../../gdb-7.7/gdb/or1k-tdep.c:1016: internal-error: or1k_skip_prologue: Assertion `or1k_analyse_l_addi (inst, &rd, &ra, &simm) && (OR1K_FP_REGNUM == rd) && (OR1K_SP_REGNUM == ra) && (simm == frame_size)' failed. | 22:03 |
| Hesham | This piece of code is the problem I think "(simm == frame_size)" | 22:04 |
| Hesham | Is there something wrong I may have in my code that causes this error ? | 22:04 |
| blueCmd_ | does this only occur for exceptions? | 22:04 |
| olofk | blueCmd_: I have to think a bit about it, but I'm still not convinced | 22:05 |
| Hesham | It only happens with this function | 22:05 |
| Hesham | I used to set a break point at _timer: (0x500) | 22:05 |
| Hesham | and it works fine | 22:05 |
| blueCmd_ | olofk: well, you keep talking about being decoupled and not depending on stuff | 22:05 |
| blueCmd_ | olofk: if you reject this idea you're being a hypocrit, the repository is a git repository and not using its features is not being decoupled | 22:06 |
| stekern | I would guess that it's the stack manipulation that throws it off | 22:07 |
| Hesham | stekern: I think so, but why? | 22:07 |
| blueCmd_ | what stekern said, have you tried with "our" newlib to see if you can register a function for exception entry and break on it? | 22:07 |
| blueCmd_ | if that works you can work from the differences on the stack I guess | 22:08 |
| Hesham | But why or1k_skip_prologue assert of frame size ? | 22:09 |
| Hesham | on | 22:10 |
| blueCmd_ | as stekern said, if gdb tries to reconstruct the frame and call stack and the registers are messed up - it will fail | 22:10 |
| stekern | can you show your _OR1K_Exception_Process? | 22:11 |
| olofk | blueCmd_: It would still work without the changes to the .core files, right? | 22:11 |
| blueCmd_ | olofk: that is correct | 22:11 |
| Hesham | stekern: Sure, one second .. | 22:12 |
| olofk | I say we start with that. I really need to write down the ideas for versioning support before I change the provider stuff | 22:12 |
| blueCmd_ | olofk: it's also possible to infer the github provider information from the .gitsubmodules file | 22:12 |
| blueCmd_ | sorry, .gitmodules * | 22:12 |
| blueCmd_ | olofk: what is better than to do versioning with git revisions? | 22:13 |
| olofk | blueCmd_: human readable version tags so that you know which versions that comes after another | 22:14 |
| blueCmd_ | olofk: sure, but that needs to map to a revision some way or another | 22:14 |
| olofk | Like you have in all package formats. Package A depends on package B>=version | 22:14 |
| olofk | Yes. With tags | 22:15 |
| blueCmd_ | I'm just saying that instead of downloading a tar archive from github you can just pull the git repository and check out that version | 22:15 |
| olofk | Absolutely | 22:15 |
| olofk | fusesoc used to do that | 22:15 |
| blueCmd_ | What changed? | 22:15 |
| olofk | I changed it to get an archive to avoid a hard dependency on git | 22:15 |
| Hesham | stekern: Here it's https://github.com/heshamelmatary/rtems-gsoc2014/blob/or1k/cpukit/score/cpu/or1k/or1k-exception-handler-low.S | 22:16 |
| Hesham | And that's the file from which this function is called https://github.com/heshamelmatary/rtems-gsoc2014/blob/or1k/c/src/lib/libbsp/or1k/or1ksim/start/start.S | 22:17 |
| blueCmd_ | olofk: how would it have been a hard dependency? | 22:17 |
| Hesham | line 14 | 22:17 |
| blueCmd_ | have had been* | 22:18 |
| olofk | blueCmd_: You would have needed git to get the repos on github. | 22:18 |
| blueCmd_ | olofk: just like you need svn to get svn | 22:18 |
| olofk | Very true, but I couldn't avoid that | 22:18 |
| blueCmd_ | just like you need git to get fusesoc | 22:18 |
| olofk | blueCmd_: No, there are versioned tar balls on the opencores ftp | 22:18 |
| blueCmd_ | (well I guess you can tarball it as well) | 22:18 |
| stekern | Hesham: ok, so gdb thinks that that looks like a function prologue that gcc would emit | 22:19 |
| blueCmd_ | I'm just saying that avoiding git is a mistake. Hardware community needs more inovation, not less | 22:19 |
| olofk | I don't think it's any point to actually avoid depending on git, but I saw that I could get around it back then, so I did it | 22:19 |
| stekern | you can workaround it by moving the 'l.sw 8(r1),r2' after 'l.sw 20(r1),r5' | 22:20 |
| stekern | (or we should just remove that assert) | 22:20 |
| Hesham | stekern: yes, I also deleted @type function and have the same problem | 22:20 |
| blueCmd_ | olofk: I totally understand that, but to change from depending on git to only allowing github repos, is it worth it? | 22:20 |
| stekern | olofk: rather ditch the svn dependency and only depend on git then... | 22:20 |
| blueCmd_ | stekern: +1 | 22:20 |
| olofk | blueCmd_: No, but since I started the project, there hasn't been a single core outside of opencores SVN or github that has been of interest, so I never wrote the generic git provider | 22:21 |
| blueCmd_ | olofk: I know that _franck_ has some stuff on assembla | 22:21 |
| olofk | stekern: Yeah, considering the recent opencores instability I think we should clone the interesting repos to github | 22:21 |
| olofk | And of course, I'm more inclined to have a hard dep on git than on svn | 22:22 |
| stekern | you can also use git as a svn client | 22:22 |
| olofk | stekern: Depends on which use flags you have provided when you compiled git :) | 22:22 |
| olofk | Installed versions: 1.8.5.5(12:10:21 2014-06-19)(blksha1 curl gnome-keyring gpg iconv threads webdav -cgi -cvs -doc -emacs -gtk -highlight -mediawiki -nls -pcre -perl -ppcsha1 -python -subversion -test -tk -xinetd | 22:23 |
| Hesham | stekern: Great, that works! | 22:23 |
| stekern | fair enough, you can always fall back to a 'pure' svn client if some poor sole needs that then ;) | 22:23 |
| Hesham | Thanks stekern and blueCmd_ | 22:24 |
| blueCmd_ | Hesham: np, I did a lot of helping! ;-) take care :-) | 22:25 |
| olofk | anyway. My arguments still stand that I need to figure out how this will work with the upcoming versioning support, and I would prefer orpsoc-cores to be put in a read-only location | 22:25 |
| blueCmd_ | olofk: tbh, it should be the other way around :P | 22:25 |
| Hesham | Ah, blueCmd_ you should, you are my mentor ;) :D | 22:25 |
| blueCmd_ | olofk: i.e, make it nice then add versioning - and this will help you | 22:26 |
| Hesham | blueCmd_: BTW, Joel asked me to keep up with you about the binutils patch, would you submit it, or should I ? | 22:26 |
| olofk | blueCmd_: I don't see it that way | 22:26 |
| blueCmd_ | Hesham: I can merge it if you feel like it's done. | 22:26 |
| Hesham | I believe it's now after your comments | 22:27 |
| olofk | But I don't mind adding the .gitmodules file | 22:27 |
| blueCmd_ | olofk: fair enough, if you feel like brainstorming how versioning will work I can try to convince you how git will Solve Everything (TM) there as well | 22:27 |
| blueCmd_ | olofk: do you mind adding the _support_ for submodules in fusesoc? | 22:27 |
| blueCmd_ | i.e. my fusesoc pull request | 22:28 |
| olofk | blueCmd_: Ah yes. I like the idea. Just haven't looked at the code yet | 22:29 |
| blueCmd_ | olofk: I can accept your compromise until you're back from your versioning hippie vision quest | 22:29 |
| olofk | haha | 22:31 |
| olofk | I'll take a closer look tomorrow. Got to sleep now | 22:33 |
| blueCmd_ | olofk: good night :) | 22:35 |
| --- Log closed Tue Jul 15 00:00:20 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!