| --- Log opened Wed May 14 00:00:47 2014 | ||
| pgavin | I have a small pull request for orpsoc-cores if anyone is able to check it :) | 01:17 |
|---|---|---|
| JakeUSC | Anyone available to answer a quick question? | 02:47 |
| pgavin | JakeUSC: do you still have that question? | 02:55 |
| JakeUSC | Yes I do. | 02:55 |
| pgavin | shoot | 02:55 |
| JakeUSC | I am trying to get a soc running on my atlys board for a project, but I am getting into a snag. | 02:56 |
| JakeUSC | I built all the toolchains and synthed the fusesoc but I am not sure how to get a program into it | 02:56 |
| pgavin | have you simulated the program with fusesoc? | 02:57 |
| JakeUSC | I see there is a rom.v that I should put a bootloader in but I cannot figure out how to convert the u-boot.bin into something I can add to the rom. | 02:57 |
| pgavin | yeah, I haven't done that | 02:57 |
| pgavin | but one sec, I can look | 02:57 |
| JakeUSC | No, I have not simulated. I am trying to get the u-boot standalone example into a format that I can load | 03:02 |
| pgavin | ok | 03:02 |
| pgavin | well first try booting it in the simulator | 03:03 |
| pgavin | if you have an elf file you can use the --elf-load flag | 03:03 |
| pgavin | erm | 03:03 |
| pgavin | you have a bin, so use the --bin-load | 03:03 |
| JakeUSC | ok, Thanks. I am building the simulator right now. I'll have to read up on how to run it. | 03:04 |
| pgavin | something like: fusesoc sim --sim=modelsim atlsys --bin-load foo.bin | 03:05 |
| pgavin | actually I think only icarus is supported in simulation for that board | 03:09 |
| JakeUSC | Yeah, it is giving me problems. Going to install that | 03:10 |
| JakeUSC | WARN: File ../orpsoc-cores/systems/atlys/bench/orpsoc_tb.v doesn't exist | 03:19 |
| JakeUSC | WARN: File ../orpsoc-cores/systems/atlys/bench/uart_decoder.v doesn't exist | 03:19 |
| JakeUSC | ERROR: Failed to build simulation model | 03:19 |
| JakeUSC | ERROR: Failed to compile VPI library elf-loader | 03:19 |
| JakeUSC | I think I may have to write a test bench | 03:19 |
| pgavin | perhaps | 03:21 |
| pgavin | not sure about that one, sorry | 03:21 |
| JakeUSC | so assuming that I am able to get this sorted out, what is the best way to get a program on the soc? | 03:22 |
| pgavin | I think fusesoc will do it | 03:24 |
| JakeUSC | Ok, thank. I appreciate the help. Going to work on this a little more tomorrow. Have a good one. | 03:27 |
| pgavin | gnight | 03:28 |
| stekern | for the record and our listeners on the irc weblogs, there are two issues that lacks proper support in the atlys fusesoc board port 1) simulation 2) boot rom | 03:47 |
| stekern | for 1), the problem is, to properly simulate the complete soc, you need to use xilinx encrypted sim libs and AFAIK you can only do that with modelsim | 03:49 |
| stekern | my own access to modelsim is very limited these days, so I can't really implement it myself... | 03:49 |
| stekern | for 2), I think blueCmd started some support on this in | 03:50 |
| stekern | pgavin: thanks for the mor1kx-generic fix, I completely forgot to check that as I had promised :( | 03:55 |
| stekern | I pulled your request now | 03:55 |
| stekern | would you mind checking if or1200-generic have the same issue? | 03:56 |
| stekern | nvm... your fix should of course cover that as well | 03:58 |
| stekern | good that I was pushing on having most of the code in verilator_tb_utils ;) | 03:58 |
| pgavin | seems the changes I made to the gcc optimizer didn't help | 04:16 |
| pgavin | even though the code looked better | 04:16 |
| pgavin | trying to figure out why | 04:16 |
| pgavin | the code was bigger for some reason | 04:16 |
| stekern | :( | 04:19 |
| pgavin | I'm having to keep two copies of gcc to test it of course | 04:20 |
| pgavin | so I may have messed up somewhere | 04:20 |
| pgavin | so I'm rebuilding everything now | 04:20 |
| pgavin | hm | 04:21 |
| pgavin | does mor1kx test the caches etc. | 04:21 |
| pgavin | ok, it appears that it does | 04:25 |
| pgavin | but the memory only has 1 cycle latency | 04:25 |
| pgavin | but that shouldn't matter for this | 04:25 |
| stekern | pgavin: yes, we had some "random memory latency" in one of the simulation models for the block rams | 05:00 |
| stekern | not sure if that made it into orpsoc-cores though | 05:01 |
| stekern | it was mostly to "mix things up" when running the tests | 05:02 |
| pgavin | right | 05:04 |
| stekern | but.. as you say, your point with the gcc optimizations shouldn't have anything to do with mem latencies, since it's the interlock you want to avoid, right? | 05:05 |
| pgavin | right | 05:06 |
| pgavin | I changed the timing on the multiply | 05:06 |
| pgavin | I'm checking if that's what caused it | 05:06 |
| pgavin | it was originally set to 16 cycles | 05:06 |
| pgavin | I changed it to 2 cycles because the pipeline stalls anyways | 05:07 |
| pgavin | and can't execute past multiplies | 05:07 |
| pgavin | but that might mean gcc is using multiplies instead of shifts etc. | 05:07 |
| stekern | ok, is that a bad thing? | 05:08 |
| stekern | ...reminds me that I should fix that, the pipeline shouldn't stall on mul... | 05:08 |
| stekern | at least not cappuccino | 05:09 |
| pgavin | if gcc thinks a multiply only takes 2 cycles, when it actually takes more than that, it might not substitute cheaper operations | 05:09 |
| stekern | well, it doesn't take longer | 05:09 |
| pgavin | oh, how many cycles is multiply? | 05:09 |
| stekern | (not on mor1kx) | 05:10 |
| stekern | 2 | 05:10 |
| pgavin | ok | 05:10 |
| pgavin | same as add or one more? | 05:10 |
| stekern | it's more, add is single-cycle | 05:11 |
| pgavin | k | 05:11 |
| stekern | but it might be 3 now when I start to think about | 05:11 |
| stekern | but it really should only be 1 cycle, the result should be pipelined and written straight into the register file in wb stage, instead of stalling the pipeline | 05:11 |
| stekern | ...that of course means that you'll need to insert bubbles on instructions after the mul that needs the result | 05:12 |
| pgavin | right | 05:12 |
| pgavin | that's how mine works | 05:12 |
| pgavin | except the multiply can be n cycles | 05:13 |
| pgavin | because I'm going to simulate asic | 05:13 |
| stekern | ah, I see | 05:14 |
| stekern | hmm, interesting... I always considered changing mor1kx to have multi-cycle (well, more than three, that can go along with the pipeline into wb) as stalling the pipeline (as it does now) | 05:15 |
| pgavin | well, mine still stalls | 05:15 |
| pgavin | I guess it wouldn't be too expensive to make it go past | 05:16 |
| stekern | aha, so you stall and the result is bypassed into wb stage? | 05:16 |
| pgavin | yeah | 05:16 |
| pgavin | it can't be forwarded back to the ALU | 05:16 |
| pgavin | it just goes to the RF | 05:16 |
| pgavin | same for load result and divide | 05:16 |
| pgavin | except load result can be forwarded to a store | 05:16 |
| stekern | right, that's what I want, but I also want the pipeline to not stall ;) | 05:17 |
| pgavin | yeah, that's extra state to track | 05:18 |
| pgavin | so I didn't do it :) | 05:18 |
| pgavin | probably would be easy though | 05:18 |
| stekern | hmm, it's not that much overhead, I did it like that in my eco32 implementation | 05:18 |
| pgavin | I guess you only need to track the register number | 05:18 |
| pgavin | but.. then when the result is ready you need to stall the pipe 1 cycle for the write | 05:19 |
| pgavin | unless the instruction isn't writing | 05:19 |
| stekern | hmm, not following you? | 05:19 |
| pgavin | RF only has 1 write port | 05:19 |
| stekern | when the result is ready, the mul is in wb stage | 05:20 |
| stekern | nothing else is trying to write to the rf then | 05:20 |
| pgavin | I guess mine is a bit different | 05:20 |
| pgavin | I have F D E M W | 05:21 |
| pgavin | result for RF is muxed at end of M | 05:21 |
| pgavin | ALU is at E, and caches are synchronous | 05:21 |
| stekern | https://github.com/skristiansson/eco32f/blob/master/rtl/verilog/eco32f_alu.v#L198 | 05:21 |
| pgavin | so address and store data are ready at end of E | 05:21 |
| stekern | that's the multiplier in my eco32f | 05:22 |
| stekern | then there's this to handle the hazards: https://github.com/skristiansson/eco32f/blob/master/rtl/verilog/eco32f_decode.v#L367 | 05:22 |
| stekern | and here | 05:23 |
| stekern | 's the mux into the rf: https://github.com/skristiansson/eco32f/blob/master/rtl/verilog/eco32f_writeback.v#L68 | 05:23 |
| stekern | that's it ;) | 05:23 |
| pgavin | I guess I mean if the multiply lasts longer than 2-3 cycles | 05:24 |
| pgavin | then you have to store the destination reg number | 05:24 |
| pgavin | and other instructions will get to writeback before it finishes | 05:24 |
| pgavin | I think you have 1 more pipe stage than me | 05:25 |
| stekern | ah, yes, in the case it stalls... | 05:25 |
| pgavin | yeah, if other instructions can get to writeback before the mul completes, then you'll have to stall them | 05:25 |
| stekern | I do, but it's in the very beginning of the pipeline, before fetch, so it shouldn't make any difference | 05:25 |
| pgavin | I have that too | 05:26 |
| pgavin | because the icache is synchronous | 05:26 |
| pgavin | but I don't really have a W stage | 05:26 |
| pgavin | well, sorta | 05:26 |
| pgavin | I think I forward from there actually | 05:26 |
| stekern | well, you can do without the extra stage before fetch even if the icache is synchronous | 05:27 |
| pgavin | it's not really a full stage | 05:28 |
| stekern | the whole F stage is the icache read | 05:28 |
| pgavin | it doesn't have driving registers | 05:28 |
| pgavin | yes | 05:28 |
| pgavin | during BF the PC is muxed | 05:28 |
| pgavin | then F is the cache read and way select | 05:28 |
| pgavin | D is decode & RF read | 05:29 |
| pgavin | then E is alu, M is dcache & way select | 05:29 |
| pgavin | I haven't checked timing so it might not be very good | 05:29 |
| pgavin | I suppose I should do that soon :) | 05:29 |
| stekern | ok, I did the eco32f like that at first, but the timing was awful | 05:30 |
| stekern | but it's a slightly different arch | 05:30 |
| pgavin | yeah | 05:30 |
| pgavin | we'll see | 05:30 |
| pgavin | the PC mux is huge | 05:30 |
| pgavin | I bet that's where the critical path is | 05:30 |
| stekern | it doesn't have a separate set-flag insn, so the compare is in the branch instructions | 05:31 |
| pgavin | I have a few things in mind if that's the case | 05:31 |
| stekern | ...PC mux is a problem in mor1kx at least ;) | 05:31 |
| pgavin | yeah, the branch resolution is practically straight off the register | 05:31 |
| pgavin | I have a way to trim off a couple of inputs to the PC mux but it means changing some things | 05:32 |
| pgavin | basically to do with exceptions | 05:32 |
| stekern | yeah, you have to be careful with those, they can create some nasty paths | 05:46 |
| stekern | but, still a question about the mul, so are you letting other instructions "past" the mul? At first, I thought your implementation stalled the rest of the pipeline when the mul arrives to wb, but it's not ready | 05:48 |
| stekern | but your latter comments suggests otherwise | 05:48 |
| pgavin | it stalls in M if it's not ready | 05:50 |
| pgavin | the operation is fed to the multiplier early in E | 05:50 |
| pgavin | oh, that reminds me of something | 05:51 |
| pgavin | exceptions will be difficult if you go past the multiply | 05:51 |
| pgavin | so you can only do it if OVE is off | 05:52 |
| stekern | ok, but that's just a small detail, if it stalls in M or WB. The real question was if other instructions proceed "past" the mul | 05:52 |
| pgavin | no | 05:52 |
| pgavin | I don't have that yet | 05:52 |
| stekern | ok | 05:53 |
| pgavin | can your dcache handle a load immediately after a store without stalling? | 05:54 |
| pgavin | that took me forever to get right | 05:54 |
| stekern | does all these overflow flags and exceptions actually make sense to have, does anyone really use them? | 05:55 |
| pgavin | no | 05:55 |
| pgavin | lol | 05:55 |
| pgavin | well, maybe | 05:55 |
| pgavin | tiny dsp stuff could use it I suppose | 05:55 |
| stekern | yeah, I suppose... | 05:55 |
| pgavin | but it's not hard to check if OVE is off | 05:55 |
| stekern | well, at least they are optional, but they make some nice optimizations harder to do when you want to be able to opt them in | 05:56 |
| pgavin | yeah | 05:56 |
| pgavin | like I was thinking about the mac | 05:57 |
| stekern | (load right after store) hmm, good question, might be that we stall on that situation | 05:57 |
| pgavin | the mac has exceptions now... so it has the same problem | 05:57 |
| pgavin | we could change the spec to postpone exceptions until l.macrc though | 05:57 |
| stekern | or what did you mean, any load after store, or a load from the same address? | 05:58 |
| pgavin | any load immediately after a store | 05:58 |
| pgavin | because the store takes 2 cycles no matter what | 05:58 |
| pgavin | it might be worth putting that into gcc if not | 06:01 |
| stekern | yeah, no, we don't stall on that | 06:02 |
| pgavin | so you buffer the store somehow? | 06:02 |
| stekern | we check for the write in ex stage, perform the write in mem, and then load is ready in the next cycle | 06:02 |
| pgavin | oh | 06:03 |
| pgavin | ok | 06:03 |
| pgavin | so when do you calculate the address | 06:03 |
| stekern | the virtual address comes from ex | 06:03 |
| stekern | and the physical is ready in mem | 06:04 |
| pgavin | ok, I misunderstood | 06:04 |
| stekern | ...but, yes, we do have a storebuffer | 06:04 |
| pgavin | but is that on the memory side? | 06:04 |
| stekern | the storebuffer? | 06:05 |
| pgavin | yeah | 06:05 |
| pgavin | https://github.com/openrisc/mor1kx/blob/master/rtl/verilog/mor1kx_store_buffer.v | 06:06 |
| pgavin | right? | 06:06 |
| pgavin | so how does it catch loads to a store in the buffer? | 06:07 |
| pgavin | if it doesn't use a cam | 06:07 |
| stekern | so... sorry, yes, of course it will stall... | 06:08 |
| stekern | ;) | 06:08 |
| pgavin | ah, ok | 06:08 |
| stekern | since we don't track the addresses in the storebuffer | 06:08 |
| pgavin | ok, so as long as there's something there it stalls loads | 06:08 |
| stekern | right | 06:08 |
| pgavin | so on mine, loads access tags + data at the same time | 06:09 |
| stekern | I was only looking at the cache logic, there's nothing there that'd stall a load after store, but the actual memory access will | 06:10 |
| pgavin | and stores do tags then write to store buffer, then data whenever it's free | 06:10 |
| pgavin | and a 1 entry store buffer seems to be enough, so I just use registers | 06:11 |
| stekern | ah, cool | 06:11 |
| stekern | I tried to make the storebuffer in mor1kx as modular as possible, so it shouldn't be too hard to play with something similar there | 06:12 |
| pgavin | it will be easier because your cache is pipelined | 06:12 |
| pgavin | but I needed to reuse the cache on another architecture | 06:12 |
| stekern | ...since usually when you implement something, the real pain is the pipeline control logic | 06:12 |
| pgavin | lol | 06:12 |
| pgavin | well | 06:12 |
| pgavin | it was hard to coordinate access to the cache structures with the store buffer there | 06:13 |
| pgavin | because you have in-flight stores that can be bypassed by later loads | 06:13 |
| stekern | so, is your cache after the store-buffer? | 06:14 |
| pgavin | and you have to keep track of whether the store was a hit... and a later load can pull the cache line out from under the store, so you have to watch for that | 06:14 |
| stekern | or am I just misunderstanding now? | 06:14 |
| pgavin | it checks the tags, then writes to the store buffer the cycle after | 06:15 |
| pgavin | and it *always* writes to the store buffer | 06:15 |
| pgavin | but it can be forwarded straight to the cache if the store buffer is empty and it was a hit and there's not an incoming load | 06:16 |
| pgavin | so it's complicated :) | 06:16 |
| stekern | hmm, yeah, sounds like it ;) | 06:16 |
| pgavin | the dcache is about half the number of lines of RTL as the cpu control logic... | 06:17 |
| pgavin | I may have overdone it | 06:17 |
| stekern | mmm... the one in mor1kx is overly large too... | 06:17 |
| stekern | https://github.com/skristiansson/eco32f/blob/master/rtl/verilog/eco32f_cache.v | 06:18 |
| stekern | that's more spartan ;) | 06:18 |
| pgavin | yes that's small :) | 06:18 |
| stekern | ...but has a lot less features too ;) | 06:18 |
| pgavin | I guess the fill control logic is in another file? | 06:19 |
| stekern | yeah, https://github.com/skristiansson/eco32f/blob/master/rtl/verilog/eco32f_lsu.v | 06:19 |
| pgavin | ah | 06:20 |
| pgavin | ok I need to go to bed before I mess up my sleep schedule again :) | 06:20 |
| stekern | olofk: using the cygwin version of svn worked better | 07:26 |
| stekern | but, now I can confirm the issue that other user had | 07:27 |
| stekern | with the paths | 07:27 |
| olofk | Oh for fuck sake. I haven't been away that long, but I'm treated with the back log from hell | 07:59 |
| rah | olofk: respond to my questions first! :-) | 08:09 |
| rah | me! me! me! :-) | 08:09 |
| ysionneau | I wonder if there is any point on having a license on a file containing only #defines :o | 08:18 |
| ysionneau | basically I could just copy paste everything, change a bit the define names and relicense it? | 08:18 |
| ysionneau | there is no intelligence at all in such a file, right? | 08:18 |
| olofk | rah: ahh.. right, you were talking about the ztex board, right? | 08:27 |
| rah | olofk: I was | 08:28 |
| rah | olofk: well, I was more interested in getting them to produce a board for OpenRISC | 08:28 |
| rah | that is, an FPGA board with high-speed transceivers, intended to be used for an OpenRISC ASIC as well | 08:30 |
| rah | they could be interested in putting something together | 08:30 |
| ams | morning | 08:31 |
| olofk | rah: Could be worth talking to them about it. Their current boards aren't really suited for what I'm interested in | 08:31 |
| olofk | ams: Morning | 08:31 |
| rah | olofk: if you want to put together that list of requirements, I'd be happy to contact them | 08:32 |
| olofk | rah: But it's interesting to see the price tag. I guess that the board I'm looking for will be quite expensive. Not sure how expensive though. $1000? $2000? | 08:32 |
| rah | O_o | 08:32 |
| rah | really? | 08:32 |
| olofk | rah: Sure. I'll do a brain dump when I have some time | 08:32 |
| rah | ok | 08:33 |
| olofk | juliusb: The plusargs scraping is pretty cool, right? I'm damn proud of that part :) | 08:34 |
| _franck__ | olofk: rah I would be very interested to work on an OpenRISC board (that's my job, I can do schematics and layout) | 08:35 |
| olofk | And way to go with the or1k-headers proposal. I think we have discussed it before, but it never took off | 08:35 |
| olofk | _franck__: That's awesome! We should think a bit about what we would want on a board | 08:36 |
| _franck__ | sure. I don't use free EDA tools, would it be a problem if I had to design something ? | 08:37 |
| olofk | I wouldn't care if you use dead puppies do design the board as long as it gets done :) | 08:38 |
| _franck__ | :) | 08:38 |
| olofk | blueCmd: Good news about gentoo, and of course there's room for one more on our short family bus | 08:40 |
| olofk | Can someone help me with git-allocate-origin btw? I'm not sure why it's not returning COMMANDEER_REMOTE_SUBMODULE | 08:40 |
| olofk | http://git-man-page-generator.lokaltog.net/#e5ed9b67c89ed9b7c44562b11335e72b | 08:40 |
| stekern | ysionneau: I completely agree with you on that... | 08:41 |
| olofk | stekern, pgavin: I've been planning to do a smarter memory slave based on wb_bfm that can be used to simulate various delays and error conditions | 08:41 |
| stekern | olofk: I see you then treat us the ame way, I just went for lunch and you managed to fill a whole page of backlog... | 08:42 |
| stekern | +s | 08:42 |
| olofk | haha | 08:42 |
| olofk | pgavin, stekern: There's a wb_bfm_memory.v in wb_bfm that could be extended, preferably with run-time parametrization | 08:44 |
| stekern | _franck__: it would be fun if it could be done with kicad, but yeah, dead puppies are ok too ;) | 08:46 |
| _franck__ | stekern: well, it would be way more work for me. I'm working with orcad and Cadence Allegro for years | 08:51 |
| _franck__ | however, I did an orcad netlist to kicad converter some times ago....but still | 08:52 |
| rah | _franck__: cool :-) | 09:02 |
| rah | is anybody here buying a Novena "laptop"? | 09:04 |
| stekern | not me | 09:20 |
| stekern | honestly, I think they made a mistake moving away from the conventional "laptop" layout | 09:20 |
| stekern | now it's just a dev-board in a box | 09:21 |
| ysionneau | ahah olofk nice website :) | 09:21 |
| stekern | I got: git-skirt-upstream | 09:24 |
| rah | stekern: I completely agree | 09:25 |
| rah | I was bitterly disappointed when they came out with their final design | 09:26 |
| rah | I was looking forward to a free hardware (clam-shell) laptop | 09:26 |
| stekern | yeah, I think I actually could have considered buying such | 09:27 |
| stekern | I don't know if I actually *would* have, but the current design I'm not even considering | 09:27 |
| rah | I definitely would have :-) | 09:27 |
| rah | but I'm not with the current design | 09:27 |
| stekern | I want a clam-shell laptop with the 10" ipad screen... | 09:28 |
| stekern | well, maybe it's not a "laptop" then... but I want the conventional design with keyboard | 09:29 |
| rah | I spoke to bunnie in their IRC channel, he said the reason they didn't do a clam-shell was because a clam-shell would have required four molds for the injection molding, which cost $100,000s each; it would have made it four times as expensive so they did something that would be reasonably achieved with a crowd-funding campaign | 09:29 |
| stekern | ok, I guess that's a fair reason then. | 09:30 |
| stekern | still a pity | 09:30 |
| rah | well, I asked him why he didn't make a clam-shell lid using aluminium instead of injection-molded ABS since it's obviously not necessary for the stiffness as the current design has an aluminium lid | 09:30 |
| _franck__ | with 3D printing you could avoid injection molding | 09:30 |
| rah | he didn't respond to that :-/ | 09:31 |
| rah | _franck__: good point | 09:33 |
| stekern | ysionneau: to get back to your comment on spr-defs.h, even if I agree with what you said, that's not how copyright law works. It doesn't care about logic, even comments are covered by copyright. | 09:58 |
| olofk | ysionneau: Yep. Guess who's twitter account I have to thank for that link :) | 10:34 |
| ysionneau | ;) | 10:44 |
| ysionneau | stekern: is it OK with copyright law to copy the file, remove comments and rename macros ? | 10:44 |
| ysionneau | because I don't know how else you can do | 10:45 |
| rah | ysionneau: no, that would not be OK | 10:45 |
| ysionneau | if that does not work, then it's the same as saying you are copyrighting the values of the defines | 10:45 |
| ysionneau | which is really strange | 10:45 |
| rah | ysionneau: the critical word there is the "copy" in "copy the file" :-) | 10:45 |
| ysionneau | ok, let say I don't copy the file, but I write with my hands one by one the same defines but with other names :) | 10:46 |
| stekern | law is strange ;) | 10:46 |
| rah | what is copyrighted is the output of someone's actions | 10:46 |
| rah | so the contents of this particular file is different from an identical file produced by someone else typing the file from scratch | 10:46 |
| rah | unless they're typing the content of the other file, in which case it's copying :-) | 10:47 |
| rah | I mean, if they look at the other file and just type it in again, that's copying | 10:47 |
| ysionneau | that's just total nonsense :( | 10:47 |
| ysionneau | I prefer not understanding | 10:47 |
| rah | if they know the values and write them out into a new file, which ends up being identical to the original, then in copyright law that's OK | 10:47 |
| ysionneau | sorry for bringing this topic :) | 10:48 |
| ysionneau | rah: ah, interesting | 10:48 |
| ams | rah: uhm, removing comments and renaming macros if perfectly fine under copyright law | 10:48 |
| rah | although, proving to a court that you actually created an identical file would be an interesting challenge :-) | 10:48 |
| rah | ams: it is | 10:48 |
| ams | uhm, no, it isn't. | 10:49 |
| rah | ams: but you can't then change the license of the result, on account of not being the copyright holder | 10:49 |
| ams | rah: who said anything about changing the license? | 10:49 |
| ams | under copyright LAW it is perfectly fine. | 10:49 |
| stekern | ams: that's what the discussion is about | 10:49 |
| ams | you can have a particular LICENSE that prohibits such things; a non-free software license for example. | 10:49 |
| stekern | but since the license is built upon copyright law, it is related | 10:49 |
| ams | and since a copyright license falls under copyright law, it means that it is allowed to do so under copyright law. | 10:50 |
| rah | ams: there would appear to be a misunderstanding about what the word "that" referred to when I said "that's OK" | 10:51 |
| ams | thus, copyright law does allow you to modify comments, remove them if you so wish, and rename macros. | 10:51 |
| ams | 12:44 <ysionneau> stekern: is it OK with copyright law to copy the file, remove comments and rename macros ? | 10:51 |
| ams | 12:45 <rah> ysionneau: no, that would not be OK | 10:52 |
| ams | it is perfectly ok under copyright law to do so. | 10:52 |
| rah | ams: you're missing the context I think | 10:52 |
| stekern | yes, but the underlying original question doesn't show in that, which was *and change the license* | 10:52 |
| rah | ams: there is, in effect, tacit knowledge that isn't evident in the question or the answer | 10:53 |
| rah | ams: http://lists.openrisc.net/pipermail/openrisc/2014-May/002168.html | 10:53 |
| ysionneau | yes sorry, I meant then change the license | 10:57 |
| ams | rah: the context is the question, and your answer is wrong. | 10:59 |
| stekern | fine, if the only point of discussion is being right, you're right | 11:00 |
| olofk | If this is a problem in practice, could juliusb relicense mor1kx-sprs.v to some ultra-liberal open source license and we can scrape the SPR info from there? | 11:01 |
| ams | i would call the file trivial in either case ... it is just definitions | 11:02 |
| stekern | olofk: it's already pretty much 'ultra-liberal' I think | 11:02 |
| ams | i.e. if you can mechanically generate that file anyway, then it cannot be copyrightable since it is just a list of "facts" or something... | 11:03 |
| stekern | ams: yes, I agree, but I think *just* taking that exact file and slam another license on it might raise some eye-brows, even if the complaints would just be theoretical | 11:03 |
| stekern | personally, I'd be perfectly fine with it ;) | 11:03 |
| olofk | stekern: Right. I haven't looked at the OHDL really. Sorry juliusb | 11:03 |
| ams | stekern: i'd just contact all people listed and get an ok; it isn't hard ... this discussion takes longer. | 11:04 |
| stekern | it's hard... because all people listed don't tend to respond to openrisc related things | 11:04 |
| ams | i only see two copyright holders listed. | 11:04 |
| olofk | ams: Which file? We got like twenty slightly different spr-defs in our tools | 11:05 |
| ams | olofk: only did a quick look, and only found two copyright holders listed ... could be missing something. | 11:06 |
| rah | I should point out that the GPL is limited when it comes to headers | 11:07 |
| olofk | otoh you could be completely right. Just wondering whih file you looked at :) | 11:07 |
| ams | rah: what do you mean? | 11:07 |
| rah | no sorry it's the LGPL that's limited | 11:10 |
| stekern | ams: two is enough, if one of them is the non-responding part ;) besides, copyright isn't limited to names listed (even though it probably will be *damn* hard to enforce it without your name listed) | 11:10 |
| olofk | blueCmd, stekern: Did you check binutils in opencores bugzilla during the upstreaming? | 11:11 |
| rah | "If such an object file uses only numerical parameters, data structure layouts and accessors, and small macros and small inline functions (ten lines or less in length), then the use of the object file is unrestricted" | 11:11 |
| rah | (LGPL v2 section 5) | 11:11 |
| ams | rah: nothing to do with headers. | 11:11 |
| rah | ams: I disagree | 11:11 |
| stekern | olofk: don't think we did, is there something particular? | 11:11 |
| ams | rah: and the lgpl agrees with me. | 11:11 |
| rah | ams: I don't think it does | 11:11 |
| olofk | Bug 31 for example. | 11:11 |
| ams | rah: it says right so, "then the use of the OBJECT file is unrestricted" | 11:11 |
| ams | rah: and there is no word of header in the whole license afair | 11:12 |
| rah | ams: "When a "work that uses the Library" uses material from a header file that is part of the Library, the object code for the work may be a derivative work of the Library even though the source code is not. Whether this is true is especially significant if the work can be linked without the Library, or if the work is itself a library. The threshold for this to be true is not precisely defined by law. If such an object file uses only numerical parameters, d | 11:12 |
| ams | (there cannot be, since numerical constants could be in a .c file ..) | 11:12 |
| olofk | It's probably not fixed in or32, but we could point people to or1k if it's fixed there | 11:12 |
| ams | the whole concept of header files is alien to the lgpl. | 11:12 |
| olofk | And blueCmd told me that Dwarf2 is done, which should close #25 | 11:13 |
| ams | olofk: cool | 11:13 |
| stekern | olofk: ah, right | 11:13 |
| rah | ams: I think you're wrong on this one I'm afraid | 11:13 |
| ams | rah: uhm, no, the lgpl cannot talk about headers, simply beacuse headers are an artifical invention. | 11:14 |
| rah | ams: the lgpl can and does talk about headers | 11:14 |
| olofk | Got a few more here that should be checked http://bugzilla.opencores.org/buglist.cgi?product=binutils&component=gas&resolution=--- | 11:14 |
| rah | ams: if you read the quote I pasted above, you will see the word "header" | 11:14 |
| ams | rah: the lgpl uses header as something vastly different than what you mean, i mean headers in the C sense. | 11:15 |
| ams | and in that setting, there is no difference between including a .c file or a .h file. | 11:16 |
| ams | anyway... | 11:16 |
| ams | back to work. | 11:16 |
| rah | ams: in what sense does the lgpl use "header" that is vastly different from what I mean? | 11:16 |
| rah | ams: I think the lgpl uses "header" in exactly the same way that both you and I use it | 11:17 |
| rah | O_o | 11:18 |
| olofk | stekern, blueCmd : Would be awesome if you could take a quick look at bugs 20, 21, 25, 31, 61, 62 and 63 | 11:24 |
| stekern | olofk: I'll try to remember to take a closer look | 11:24 |
| olofk | _franck_, ams : You're the gdb gurus, right? Do you have anything to say about http://bugzilla.opencores.org/show_bug.cgi?id=14 ? | 11:25 |
| olofk | LoneTech: We should probably make some noise on the list about http://bugzilla.opencores.org/show_bug.cgi?id=18 . That's a pretty bad bug, right? | 11:25 |
| stekern | 25 is definitely fixed in or1k, I remember that I looked at that and confirmed that the 'workaround (disabled)' could be removed | 11:26 |
| * olofk calmly steps away from OpenCores bugzilla | 11:26 | |
| olofk | stekern: Great. Will you do the honours? | 11:26 |
| ams | olofk: not the same libraries used for binutils/gdb? | 11:27 |
| olofk | ams: Haven't got a fucking clue :) | 11:27 |
| ams | isuspect that is the case, gdb was compiled against bfd/whatever/else that does not coincide with the one for gas/objdump | 11:27 |
| ams | hence why gas/objdump wrok, and hdb disassemble does not. | 11:28 |
| stekern | olofk: so what should I write there? that it's fixed in or1k, and leave it open? | 12:02 |
| stekern | since the bug is directed towards a certain binutils version and has or32 written over it | 12:03 |
| LoneTech | olofk: perhaps. but I don't think I have much to add to the comment | 12:13 |
| LoneTech | the MAC function itself is a rather odd addon, reminescent of how the FPU attaches in x86 | 12:13 |
| olofk | stekern: Or maybe set it to resolved wontfix. I don't think anything more will be done with the or32 port | 12:49 |
| stekern | ok, yeah, that's probably the best option | 12:49 |
| stekern | umm, I don't know how to log in to the bugzilla... =/ | 12:50 |
| olofk | should be your opencores account with email as username | 12:51 |
| stekern | right | 12:52 |
| stekern | I don't think I'm allowed to change the status of it though | 12:52 |
| olofk | Sounds fair. I wouldn't trust you with such sensitive matters | 13:21 |
| olofk | stekern: Write a comment and ping jeremypbennett. Looks like he's the owner on all of the bugs | 13:25 |
| stekern | bug-owner, that's a fany title, aint it? | 13:39 |
| stekern | +c | 13:39 |
| jeremypbennett | olofk: stekern: I thought you were also Bugzilla admins. I can make you admins | 14:24 |
| rah | http://hardware.slashdot.org/story/14/05/14/1213239/openrisc-gains-atomic-operations-and-multicore-support | 15:02 |
| stekern | I don't get slashdots commenting system, there seems like there's always missing comments, even when you click 'all' | 15:22 |
| stekern | ah, you have to move the lever... | 15:23 |
| fotis2 | hey there... anybody here in the Benelux vicinity and attending a meeting? | 15:34 |
| fotis2 | or, just feeling like demoing experience with OpenRISC builds? | 15:35 |
| rah | http://hardware.slashdot.org/comments.pl?sid=5157973&cid=46999815 | 16:03 |
| * rah <- Node | 16:04 | |
| rah | stekern: I'm not sure fiddling with the lever is such a good idea :-) | 16:04 |
| stekern | heh | 16:13 |
| pgavin | arah: yeah, it's really frustrating to read near-sighted comments such as this one: Absolutely nothing over any of the well supported and understood open source MIPS implementations. This is just another cause-we-can hobby project on the front page of Slashdot. | 17:39 |
| juliusb | olofk: wow, that was such a good update you made it to slashdot! well done mate | 18:54 |
| juliusb | \m/ | 18:55 |
| mor1kx | [mor1kx] wallento opened pull request #12: bus_if_wb32: Don't access bus on reset (master...master) https://github.com/openrisc/mor1kx/pull/12 | 19:37 |
| mor1kx | [mor1kx] wallento closed pull request #12: bus_if_wb32: Don't access bus on reset (master...master) https://github.com/openrisc/mor1kx/pull/12 | 19:53 |
| ysionneau | crazyly full of non-sensical comments | 20:05 |
| ysionneau | on a more serious topic, I'm not sure you really need atomic ops (as some suggest in the comments in slashdot) | 20:06 |
| ysionneau | I guess you can always use the suboptimal RAS CAS, right ? | 20:06 |
| stekern | CAS as in compare-and-swap? RAS as in ...? | 20:11 |
| LoneTech | those sound like address strobe lines for SDRAM to me | 20:12 |
| LoneTech | the epiphany uses a test-and-set instruction for atomics | 20:13 |
| LoneTech | there are a few different solutions, load-linked/store-conditional is one | 20:14 |
| ysionneau | RAS as in Restartable Atomic Sequence | 20:14 |
| ysionneau | you have a symbol "ras_begin" noting the start of the RAS code | 20:15 |
| ysionneau | then a "ras_end" | 20:15 |
| ysionneau | upon preemption, when you resume the code, you check if PC is inside [ras_begin:ras_end] | 20:15 |
| stekern | quick read-up on that suggest it's only for uniprocessor systems | 20:16 |
| ysionneau | if it is, then instead of restarting where you were, you restart at "ras_begin" | 20:16 |
| ysionneau | ah yes, I guess indeed | 20:16 |
| ysionneau | it's just to allow preemption without having atomic ops | 20:16 |
| ysionneau | when you start going multi core ... maybe it's more complex to use that | 20:17 |
| ysionneau | or impossible :) | 20:17 |
| ysionneau | that's what I used for my NetBSD port | 20:17 |
| stekern | multi-core, that's what we're aiming for atm ;) | 20:17 |
| ysionneau | but I only have uni CPU :p | 20:17 |
| ysionneau | yes sure :) | 20:17 |
| LoneTech | it's the same concept. ll/sc (called l.lwa/l.swa in openrisc) are the detection method for that preemption done by other hardware | 20:18 |
| ysionneau | was just reacting to all those comments "how did you do before without atomic ops ? / you don't need them / yes you need them if you want preemption/ etc" | 20:18 |
| stekern | right, at least for uniprocessor, you definitely can get by without them. | 20:20 |
| ysionneau | yep | 20:20 |
| stekern | blueCmd: your prophecy about a plethora of different types of implementations have came true in the form of spinlocks | 20:28 |
| stekern | some archs use ticket spinlocks, some don't, some use negative values, some use 0 and 1 to indicate if the lock is taken or not. | 20:30 |
| olofk | Wow... Slashdot. Never imagined that. Even though Slashdot is getting crappier for every year, the geek in me feels very proud | 22:04 |
| olofk | Oh.. and it did wonders for my statistics :) | 22:04 |
| olofk | I'm so going to get laid when I tell the chicks about this! | 22:06 |
| skip__ | congratuations olofk :) | 22:11 |
| _franck_ | stekern: blueCmd : is that a reason why we don't have __HAVE_ARCH_MEMCPY (with an asm version of memcpy doing word transfert and handling aligment) in the kernel ? | 22:13 |
| _franck_ | s/that/there | 22:13 |
| olofk | _franck_: I know that we have discussed that before, but I can't remember what was said | 22:14 |
| olofk | http://www.juliusbaxter.net/openrisc-irc/search?q=memcpy | 22:14 |
| _franck_ | I would have said that the Kernel doesn't use the GCC memcpy but now I'm not sure. It is linked with libgcc right ? | 22:19 |
| --- Log closed Thu May 15 00:00:49 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!