| --- Log opened Sat May 10 00:00:42 2014 | ||
| stekern | _franck_: can you test with what's in my openrisc.net branch? | 05:21 |
|---|---|---|
| stekern | pgavin: (l.sf l.bf) heh, that kinda defeat the purpose of moving it then ;) | 05:22 |
| stekern | but nice to hear you've got some progress on that | 05:23 |
| Findeton | so | 06:38 |
| blueCmd | stekern: I want to discuss how to do 1, 2 and possibly 8 byte operations | 06:48 |
| blueCmd | I'm thinking of doing l.lwa rD, rA & ~3 and then shift and mask rD depending on rA & 3 | 06:49 |
| blueCmd | (or rather, doing this into a new rS or something, since rD is needed for the l.swa) | 06:50 |
| blueCmd | then compare rS with old, if set shift 0xff 'to' rA & 3, negate it, AND it with rD, shift 'new' with rA & 3 and OR it with rD | 06:54 |
| blueCmd | and set mem = rD | 06:54 |
| blueCmd | but it's a lot of insns | 06:54 |
| _franck_ | stekern: it doesn't work with your branch neither. I did not update my gcc. | 06:58 |
| stekern | _franck_: umm... very strange then, that I *know* worked with the old or32-elf-gcc and ethoc | 06:59 |
| stekern | blueCmd: I think I would understand better if you'd just spelled the instructions out ;) | 07:07 |
| blueCmd | stekern: I'm doing that atm | 07:07 |
| pgavin | stekern: I think I've fixed that problem | 07:10 |
| pgavin | it's looking pretty good | 07:10 |
| pgavin | is there a cycle-accurate simulator for the mor1kx? | 07:11 |
| pgavin | other than the verilog i mean :) | 07:11 |
| stekern | what's wrong with the verilog? ) | 07:15 |
| blueCmd | stekern: http://00b76f0ab3deec0f.paste.se/ | 07:17 |
| stekern | i.e., the answer is no, the best/fastest cycle-accurate simulator we have is verilated verilog | 07:18 |
| blueCmd | stekern: I'm going to move stuff around to make the distance between lwa and swa as small as possible | 07:18 |
| blueCmd | when implementing it | 07:18 |
| blueCmd | time to shower, brb | 07:19 |
| pgavin | stekern: nothing's wrong with it :) | 07:24 |
| pgavin | software simulators are just faster and sometimes have more flexibility | 07:25 |
| pgavin | so I was just wondering | 07:25 |
| stekern | yeah, there is or1ksim of course that goes more into the simulator genre, but it's not anywhere near cycle-accurate | 07:27 |
| pgavin | right | 07:27 |
| pgavin | are there scripts etc. for building the simulator? | 07:28 |
| stekern | with verilator you mean? | 07:29 |
| pgavin | or icarus is ok too I suppose | 07:29 |
| pgavin | whatever | 07:29 |
| blueCmd | stekern: l.sfeq rC, old ofc - not rD | 07:29 |
| pgavin | verilator *.v ? :) | 07:29 |
| stekern | fusesoc/orpsoc-cores and then the mor1kx-generic system | 07:30 |
| pgavin | ok | 07:30 |
| stekern | wait, I have an old Makefile recipe for setting stuff up | 07:30 |
| stekern | it was for my eco32 system, but should be easy to modify it for 'mainline' and mor1kx-generic | 07:31 |
| stekern | pgavin: http://pastie.org/9161521 | 07:36 |
| stekern | make checkout && make fusesoc && make mor1kx-generic | 07:36 |
| stekern | should be all you need | 07:36 |
| stekern | it expects two files in the same directory | 07:37 |
| stekern | fusesoc.conf that contains this: http://pastie.org/9161527 | 07:38 |
| stekern | dunno why I didn't make the Makefile generate that... | 07:38 |
| stekern | and vmlinux | 07:38 |
| blueCmd | stekern: second iteration, http://7d97efb392611ed2.paste.se/ - have a look when you have time, no hurry | 07:39 |
| pgavin | stekern: thanks :) | 07:39 |
| blueCmd | i'm thinking of making that an 'cmpxchg_mask' of the second part and reusing it for 1 and 2 byte operations | 07:41 |
| stekern | pgavin: ah, sorry you'll of course need - make verilator && make verilator-install too | 07:41 |
| stekern | but I have no doubt that you'll be able to figure stuff out on your own from that crude Makefile ;) | 07:42 |
| pgavin | yeah, it's pretty straighforward :) | 07:42 |
| pgavin | how long does it take to boot linux in the simulator? | 07:43 |
| stekern | blueCmd: maybe we should have speced the l.lwa to not generate align exceptions... | 07:43 |
| stekern | pgavin: in verilator - around 10-20 min, in icarus - 24h+ | 07:44 |
| pgavin | lol | 07:44 |
| pgavin | didn't realize icarus was that slow | 07:44 |
| pgavin | but I haven't used it for much | 07:44 |
| stekern | verilator is really fast enough to be useful | 07:44 |
| stekern | I get around 0.5MHz from it | 07:45 |
| pgavin | wow | 07:45 |
| pgavin | one core of the OpenSPARC T1 simulated at ~1kHz with Synopsys VCS | 07:46 |
| pgavin | I was amused by that | 07:47 |
| pgavin | but that was dumping lots of trace data IIRC | 07:47 |
| stekern | yes, if you turn on trace dumping or vcd generation, it's of course a lot slower | 07:48 |
| stekern | but usually you know around where you want the trace/vcd dumped, so you can just run it without those turned on up until that point | 07:48 |
| blueCmd | stekern: I don't know, it's not that much more of a hassle to mask the addr, right? | 07:49 |
| pgavin | stekern: basically I just want to benchmark some code to make sure my changes to the optimizer are effective | 07:51 |
| pgavin | so I shouldn't need any tracing, just some stats | 07:52 |
| stekern | right | 07:53 |
| -!- Netsplit *.net <-> *.split quits: hno` | 08:18 | |
| -!- Netsplit over, joins: hno` | 08:29 | |
| pgavin | hm... is there a way to make fusesoc *not* check out the sources again? | 08:31 |
| pgavin | like, if I make changes? | 08:31 |
| pgavin | or is there a better way to do it? | 08:31 |
| -!- Netsplit *.net <-> *.split quits: hno` | 09:25 | |
| -!- Netsplit over, joins: hno` | 09:36 | |
| Findeton | so | 10:00 |
| Findeton | I have openrisc linux sim compiled and installed from scratch, including newlib and uclibc tools | 10:01 |
| Findeton | now I want to compile a simple helloworld C++ program and run it on linux | 10:01 |
| Findeton | so I compiled it using or1k-elf-g++ helloworld helloworld.cpp | 10:02 |
| pgavin | that won't work | 10:02 |
| Findeton | and then I included it in the initramfs | 10:02 |
| Findeton | it doesn't work, you are right pgavin | 10:02 |
| pgavin | or1k-elf-g++ is for running on bare metal | 10:02 |
| Findeton | ahh | 10:03 |
| pgavin | use or1k-linux-g++ if you want to run in linux | 10:03 |
| Findeton | ahhh ok thanks! | 10:03 |
| pgavin | np :) | 10:03 |
| Findeton | although it will also be fun to run a helloworld on bare metal too | 10:03 |
| Findeton | :p | 10:03 |
| pgavin | sure, and that's easy | 10:03 |
| pgavin | just compile and do or1k-elf-sim $file | 10:03 |
| pgavin | you'll need the config file of course | 10:04 |
| Findeton | so it's not that easy then, I need to do a config file :p | 10:04 |
| Findeton | I'll do it later | 10:04 |
| Findeton | I need to learn to do it sooner or later anyway | 10:05 |
| Findeton | btw in my system it's or1k-linux-uclibc-g++, quite long! | 10:06 |
| pgavin | there's a usable config in the or1ksim tarball | 10:07 |
| pgavin | IIRC | 10:07 |
| pgavin | https://github.com/openrisc/or1ksim/blob/or1k-master/sim.cfg | 10:07 |
| Findeton | uhm, can I just use the same config file I use when I boot linux? | 10:08 |
| pgavin | yes | 10:08 |
| pgavin | should work find | 10:08 |
| pgavin | fine* | 10:08 |
| Findeton | that's good! | 10:09 |
| Findeton | also, it's a curious thing that I need to rebuild the kernel when I change the contents of initramfs, isnt there an easiest way? | 10:13 |
| Findeton | I mean, in the future I'll get an ext2 system configured and all the like but.. | 10:13 |
| pgavin | yeah, I haven't done a lot with that | 10:15 |
| pgavin | I'm sure someone else will be around that will know | 10:15 |
| Findeton | # ls | 10:17 |
| Findeton | has | 10:17 |
| Findeton | # ./has | 10:17 |
| Findeton | -sh: ./has: not found | 10:17 |
| Findeton | has is the helloworld app built with uclibc, what the hell is happening? | 10:17 |
| Findeton | (i'm executing that in the openrisc linux through a telnet session) | 10:18 |
| pgavin | is the file in the initramfs? | 10:24 |
| pgavin | oh | 10:24 |
| Findeton | yes it is | 10:24 |
| pgavin | um | 10:24 |
| pgavin | is it staticly linked? | 10:25 |
| Findeton | and I have tried and at least the bare metal version works | 10:25 |
| pgavin | the initramfs might not have the stuff for dynamic linking | 10:25 |
| pgavin | that not found might be referring to ld.so | 10:25 |
| Findeton | uhm, and how can I do the static linking while compiling? | 10:25 |
| pgavin | -static | 10:25 |
| pgavin | on the link line | 10:25 |
| Findeton | well I did it all in just one line | 10:26 |
| pgavin | ok, just add it to the one line | 10:26 |
| Findeton | ok lets do this! | 10:26 |
| Findeton | but it is strange that it works in the metal version | 10:28 |
| pgavin | wait | 10:28 |
| pgavin | you mean the has executable runs straight off or1ksim? | 10:28 |
| pgavin | that means you didn't use the right compiler | 10:28 |
| pgavin | you need to compile the executable using or1k-linux-gcc, then put it in your initramfs | 10:29 |
| Findeton | no, the has is the clibc version :) | 10:30 |
| pgavin | then it shouldn't run directly in the simulator i don't think | 10:31 |
| Findeton | now it works! | 10:31 |
| pgavin | ok | 10:32 |
| Findeton | pgavin: I compiled two versions, 'mas' is the baremetal and 'has' the linux version | 10:32 |
| Findeton | thanks for the help btw! | 10:32 |
| pgavin | sure, np :) | 10:33 |
| Findeton | now that I think about it I'll only need the bare metal thing but it's good to know how to compile it for linux! | 10:35 |
| Findeton | oh no, I must need both | 10:35 |
| pgavin | you should be able to compile the kernel with the linux toolchain now | 10:43 |
| pgavin | I'm pretty sure stefan fixed that anyways | 10:44 |
| -!- Netsplit *.net <-> *.split quits: hno` | 10:54 | |
| stekern | pgavin: fusesoc will cache the cores in .cache | 11:00 |
| stekern | i.e. it will only download them oncd | 11:01 |
| pgavin | ah | 11:02 |
| pgavin | so what if I want to make modifications? | 11:02 |
| pgavin | should I do them there? | 11:03 |
| stekern | now, the caching functionality could need some improvements. but thats high on the todo lust, right olofk ;) | 11:04 |
| pgavin | ok | 11:04 |
| pgavin | looks like it doesn't keep the .git stuff | 11:04 |
| stekern | yes, you can do them there. you can also prevent fusesoc from downloading and using a local version in the orpsoc-cores dir | 11:05 |
| pgavin | ok | 11:05 |
| pgavin | so I modify the corresponding file in orpsoc-cores to point to a local directory? | 11:05 |
| -!- Netsplit over, joins: hno` | 11:06 | |
| stekern | I usually do quick and dirty small in .cache and the latter for bigger stuff | 11:06 |
| pgavin | kk | 11:06 |
| pgavin | works for me :) | 11:06 |
| stekern | if you rwmove the provider entey it'll look in the dir the .core file is | 11:07 |
| pgavin | ok | 11:07 |
| pgavin | I only needed a small modification | 11:07 |
| pgavin | the testbench doesn't detect NOP_EXIT_SILENT | 11:07 |
| pgavin | just NOP_EXIT | 11:07 |
| stekern | ah, but tb.cpp is "local" anywat | 11:08 |
| * stekern writes with phone | 11:09 | |
| pgavin | lol | 11:09 |
| pgavin | ah, that's already in oprsoc-cores | 11:10 |
| pgavin | that makes it easy | 11:10 |
| pgavin | I was confused, I thought fusesoc was also pulling the testbench tree from somewhere :) | 11:14 |
| stekern | if you need the actual exit code, fusesoc will not return it as things currently stands | 11:32 |
| stekern | I noticed that the other day | 11:33 |
| stekern | you can however get it by running the simulator directly with the Vorpsoc_top exe after fusesoc built it for you | 11:34 |
| pgavin | ok | 11:57 |
| pgavin | I didnt realize I need gdb | 11:57 |
| pgavin | I guess I start the sim, then connect with gdb? | 11:57 |
| stekern | ah, you can do that, but you don't need to(?) | 11:58 |
| pgavin | ok | 11:59 |
| pgavin | trying to figure out what's going on them | 11:59 |
| pgavin | then* | 11:59 |
| stekern | you can load elfs with --elf-load=<file> | 11:59 |
| pgavin | yeah, I did that | 11:59 |
| pgavin | and it just hung | 11:59 |
| pgavin | but there might by a problem with the binary | 11:59 |
| stekern | ok, that's not how it's intended to work ;) | 12:00 |
| pgavin | ok | 12:01 |
| pgavin | well I ran it with --elf-load | 12:01 |
| pgavin | nothing happened | 12:01 |
| pgavin | I hit ctrl-c | 12:01 |
| pgavin | it says stopped at PC 00000000 | 12:01 |
| pgavin | oh, and the vcd was empty for some reason | 12:02 |
| stekern | hmm, that sound strange | 12:03 |
| stekern | did you run it with --vcd? | 12:03 |
| pgavin | yeah | 12:04 |
| pgavin | python fusesoc sim --sim=verilator mor1kx-generic --elf-load test -vtest.vcd | 12:04 |
| stekern | ok, I was just thinking if it creates an empty vcd when the --vcd commandline option isn't there | 12:05 |
| pgavin | the binary runs fine with or1ksim | 12:06 |
| pgavin | I'm rebuilding binutils because I didn't have gdb configured | 12:06 |
| pgavin | still waiting lol | 12:06 |
| pgavin | this will probably have to wait until monday though | 12:08 |
| pgavin | have to leave soon | 12:08 |
| stekern | I can sanity check the repos when I get home, to make sure nothing has broke by recent commits | 12:10 |
| pgavin | k | 12:11 |
| pgavin | well I telnetted to the jtag port | 12:11 |
| pgavin | and mashed some keys | 12:11 |
| pgavin | and it did *something* | 12:11 |
| pgavin | but I dont know what :) | 12:11 |
| blueCmd | olofk and I have now laid out the master plan for openrisc for the years to come | 13:43 |
| blueCmd | world domination is inevitable | 13:44 |
| Findeton | (15:43:57) blueCmd: olofk and I have now laid out the master plan for openrisc for the years to come | 14:09 |
| Findeton | I just joined the room and then you told that | 14:09 |
| Findeton | and now I don't know your plans, do you think that's fair? | 14:09 |
| blueCmd | Findeton: yes, it's fair :) | 14:09 |
| blueCmd | because only olofk and I know them! | 14:09 |
| blueCmd | as we did lay them out IRL | 14:09 |
| Findeton | it's not, but anyway I for one welcome the new openrisc overlords | 14:10 |
| Findeton | I think that a multicore openrisc system on a good fpga could bring us a usable openrisc computer | 14:11 |
| Findeton | :p | 14:11 |
| blueCmd | calculator* | 14:12 |
| blueCmd | no, but yes - a lot of cool things lately that will be very neat when polished | 14:12 |
| Findeton | and I mean, maybe you've read about all the snowden stuff, jacob appelbaum has explained it clearly: basically all computers are compromised | 14:14 |
| Findeton | and if the backdoor is not in the software, it is in the hardware | 14:14 |
| Findeton | firmware, ACPI too | 14:14 |
| Findeton | so I for one would love to have a openrisc desk pc that I can use daily | 14:15 |
| Findeton | you know, fuck the nsa and all that | 14:15 |
| blueCmd | right, but as heartbleed showed - that is only part of the solution | 14:16 |
| Findeton | well, I'm quoting appelbaum now, but security is a three poles system right now: the hardware, the software, and the specific configuration | 14:19 |
| Findeton | so we need to get free software, open/free hardware, and the know-how to maintain a proper configuration... just to get a chance at a secure computer | 14:20 |
| Findeton | of course security is not a black and white subject, security is more like a state of mind.. | 14:20 |
| blueCmd | yup | 14:22 |
| olofk | Yes. Ever since that Snowden thing I have made sure to double rot13-encrypt all my traffic. | 14:22 |
| Findeton | olofk: I don't know what kind of computer you use, but the most likely situation is that your computer is owned by the nsa anyway | 14:24 |
| Findeton | it doesn't matter if you encrypt it when your computer has a backdoor already | 14:25 |
| olofk | Not even using double encryption? Damn... I thought I would be safe | 14:26 |
| blueCmd | Findeton: do you know what rot13 is? :P | 14:26 |
| Findeton | now I know haha | 14:26 |
| Findeton | caesar encryption haha | 14:26 |
| olofk | :) | 14:26 |
| blueCmd | rot13(rot13(a)) = a | 14:27 |
| Findeton | i've been rick-rolled | 14:27 |
| blueCmd | fun times | 14:27 |
| Findeton | can we trust the makers of our fpga boards? :/ | 14:27 |
| olofk | Not more than we can trust intel or arm to make our CPUs | 14:28 |
| olofk | So I'm saying that an Open Source computer for the sake of security ain't that much of a win | 14:28 |
| Findeton | olofk: well there is the added advantage that a fpga is too general for them to be able to anticipate how we are going to use it and install backdoors... and we can also use different fpgas to implement the same open source computer | 14:30 |
| Findeton | so there IS a silver lining :p | 14:30 |
| blueCmd | Findeton: well, they make the synth tools | 14:33 |
| Findeton | is there any open source fpga board (and its tools too) ? | 14:34 |
| olofk | There are several boards with the PCB layout open source, but I don't think that would make any difference | 14:37 |
| olofk | And one could argue that a CPU is also too general to be used for planting back doors. I mean, how would you extract the data? | 14:38 |
| olofk | But I could have been bought by NSA to say this :) | 14:38 |
| olofk | Actually, I think that an open source keyboard would make more sense if someone is paranoid about security | 14:41 |
| olofk | Plenty of room to plant a transmitter, a lot smaller data set and everything is in clear text | 14:43 |
| olofk | Or in your monitor | 14:43 |
| olofk | But the old-fashioned way to retrieve data from someone is still the most effective http://xkcd.com/538/ | 14:44 |
| blueCmd | olofk: you seem to have a lot of experience in this! | 14:44 |
| olofk | blueCmd: Hand over your cell phone and computer to the guys in black suits that will enter your hotel room in 37 seconds. Please don't make any resistance | 14:45 |
| olofk | They are your friends | 14:46 |
| olofk | I have already scanned you today with my Multiple Automatic Java Analyzer (M.A.J.A) | 14:48 |
| olofk | Oh well. I'm still all for building an Open Source computer. | 14:57 |
| olofk | And now we can even use it to play Monkey Island without the NSA listening in on us :) | 14:57 |
| blueCmd | aha! she's a drone! | 15:00 |
| blueCmd | olofk: well... so I haven't exactly updated the openssl in our debian repository .. | 15:01 |
| olofk | blueCmd: OMG! HEARTBLEED!!!!! | 15:02 |
| olofk | Or is it using an 0.98 version? | 15:02 |
| olofk | blueCmd: Yes. She's a drone. Didn't you see when I extracted data from her back door? ;) | 15:03 |
| stekern | omg...euhhh | 15:11 |
| olofk | Sorry about that | 15:12 |
| stekern | how does all discussions in #openrisc end up in either: 1) discussions about autoexec.bat 2) onani 3) excrements ? | 15:13 |
| stekern | ;) | 15:13 |
| olofk | Indeed. Lots of shit talking here | 15:14 |
| stekern | indeed, there are gems when you dig through it though | 15:15 |
| olofk | autoexcrement.bat | 15:15 |
| stekern | literally lol | 15:16 |
| olofk | :) | 15:16 |
| stekern | is that what you cool parents call potty training nowdays? | 15:17 |
| olofk | Yep. It's automated to a batch job now | 15:19 |
| olofk | stekern: noob question #35472. How does the caches on e.g. mor1kx access the memories | 15:55 |
| olofk | ? | 15:55 |
| olofk | Is it always a burst of the same size (like cache lock size or whatever it's called | 15:56 |
| olofk | I'm interested in pursuing an idea that I saw in a MicroBlaze based SoC where they had made the memory bus really wide so that you could fill a cache line in one transaction | 15:57 |
| olofk | Because if you have a wide ddr2 bus you get a lot of data in paralell there | 15:58 |
| olofk | The atlys board for example has a 16-bit ddr2 IF, which means you get 4*16=64 bits of data for each mem access, but we can only read it into the CPU 32 bits at a time | 16:00 |
| stekern | yes, this is something I have been thinking about too, adding support for wider wishbone bus (like 64-bit, or even wider) | 16:03 |
| stekern | but, to answer your question - yes, it does bursts of the same size | 16:04 |
| stekern | actually, that is set in the bus interface | 16:04 |
| olofk | For a longer burst where latency has been amortized we would double the bandwidth | 16:04 |
| stekern | but that's just an implementation detail, the important part is that it's a fixed burst size | 16:05 |
| olofk | Not having checked the implementation, would it "just" be to edit the cache and wb_if parts | 16:05 |
| olofk | And let it be transparent for the CPU itself | 16:06 |
| stekern | I think it should be completely done in the bus if | 16:06 |
| olofk | cool | 16:06 |
| stekern | ...and I also think it should be possible to do that ;) | 16:06 |
| stekern | well, maybe you can make it even more efficient if you change the fetch and lsu bus interface ports | 16:07 |
| olofk | For the super fancy board that blueCmd has ordered it would make an even bigger impact since he will get 256 bits per access | 16:08 |
| olofk | (64 bit DDR3) | 16:08 |
| olofk | I haven't thought about how resize-friendly the wb bus is. We might have to make the CPU <-> MEM connection point to point without any arbiters | 16:09 |
| olofk | Ah no. It should just be to set the sel mask correctly, right? | 16:10 |
| stekern | but, thinking a bit more about it, it doesn't matter if the cache is actually filled in "one go" or word by word, as long as the burst can provide data at each clock cycle | 16:11 |
| stekern | since, the processor can't really process more data then a word at each clock cycle | 16:11 |
| stekern | let's just go dual issue, then we would be able | 16:12 |
| olofk | gtg. Let's think about this some more | 16:13 |
| stekern | that said, I think there's still performance gains to be able to use wider buses | 16:13 |
| -!- Netsplit *.net <-> *.split quits: hno` | 16:26 | |
| -!- Netsplit over, joins: hno` | 16:38 | |
| blueCmd | stekern: everybody knows that only the special kids ride the short buses | 16:39 |
| stekern | hmm, can't say I knew that... | 17:05 |
| stekern | what about the narrow buses then, what kind of kids ride those? | 17:06 |
| stekern | blueCmd: as promised to keep you in the loop, here's the first commit on "SMPing" Linux: http://git.openrisc.net/cgit.cgi/stefan/linux/commit/?h=smp&id=30979cdcfb442f4ed62c155cfe29edee8830afbc | 17:19 |
| stekern | the ned purpose of this is to get rid of the non-smp compatible exception reg stashing into fixed memory addresses in the 0x0-0x100 area | 17:20 |
| stekern | s/ned/end | 17:20 |
| blueCmd | stekern: it needs to be r10 in user space as well | 18:26 |
| blueCmd | or you will need to recompile everything | 18:26 |
| blueCmd | since TLS relocations are emitted as offsets to r10 | 18:28 |
| blueCmd | hopefully I'm missing something, but I'm not a big fan of changing tls from r10 in userspace unless it can be avoided or is very bad | 18:31 |
| stekern | blueCmd: hmm, ok... that sucks donkey *censured* | 18:55 |
| stekern | because... I've considered r10 as reserved for kernel use... | 18:55 |
| stekern | so the idea is that we'd be able to trash it without considering userspace | 18:56 |
| stekern | if it's used in userspace, that will of course not work... | 18:56 |
| -!- Netsplit *.net <-> *.split quits: hno` | 18:56 | |
| blueCmd | stekern: yeah, it's set in each thread and needs to be non-mutated, unless I missed something very fundamental | 18:58 |
| blueCmd | stekern: can't you just use r21 for the scratch reg and use -ffixed-r21 ? | 18:59 |
| blueCmd | or is user space clobbering a problem? | 18:59 |
| stekern | no, since I'm going to trash it in userspace | 18:59 |
| blueCmd | yes, that sucks | 18:59 |
| stekern | that was the beauty of r10, it was our only kernel reg, and you stole it! ;) | 18:59 |
| blueCmd | muhaha | 19:00 |
| blueCmd | I guess you could implement a winodw over r10 that makes it "two" registers, one for kernel space and one for user space | 19:01 |
| stekern | the options are not too bright neither... 1) reserve a couple of other kernel regs in gcc 2) go for the "scratch reg" sprs, or shadowed regs or whatever | 19:01 |
| stekern | 1) breaks userspace ABI | 19:02 |
| blueCmd | 1) it isn't _that_ huge of a problem | 19:02 |
| stekern | 2) sucks equally, since it breaks linux on about every prior implementation | 19:02 |
| blueCmd | I can agree on doing a survey of r21 usage and recompile packages that use it | 19:02 |
| blueCmd | changing r10 would be almost all packages, r21 probably not so much | 19:03 |
| stekern | unless you ifdef it into a hideous mess | 19:03 |
| stekern | if we're pinning down kernel scratch regs, I'd propose 2 | 19:03 |
| stekern | because that would make things a lot less messy | 19:04 |
| blueCmd | 2? as in two? | 19:04 |
| blueCmd | or r2? | 19:04 |
| stekern | yes as in two | 19:04 |
| blueCmd | because f* you if r2 :) | 19:04 |
| stekern | haha, no, I'm not that evil | 19:04 |
| blueCmd | sometimes I wonder.. | 19:05 |
| blueCmd | but yes, I'm all for pinning down more regs | 19:05 |
| blueCmd | I'll script something that objdumps all binaries and surveys which regs are best | 19:05 |
| -!- Netsplit over, joins: hno` | 19:07 | |
| blueCmd | stekern: btw, I think I have all __sync and __atomics covered now. seems implementing X_and_fetch, fetch_and_X and cas seems to be enough | 19:07 |
| stekern | nice! | 19:08 |
| blueCmd | I haven't written the implementation, but I'm emitting l.nop instead of the call now, and I've compiled the test suite without gcc throwing up in my face as it usually do, so it seems happy :) | 19:08 |
| blueCmd | I'm a bit worried how to tell gcc that it shouldn't move l.lwa and l.swa from eachother, I figure it might want to do that | 19:09 |
| stekern | hmm, but isn't the __sync and __atomics considered as an "entity"? | 19:10 |
| blueCmd | no! this might be the only part in gcc that is implemented sensibly | 19:11 |
| blueCmd | it tries __atomic first, the __sync, then tries to decompose it into an alternative implementation using __atomic, then __sync and failing that it will emit the libcall | 19:12 |
| blueCmd | and using those I listed as "tier 1", I haven't found any builtins that has reverted to libcalls | 19:12 |
| -!- Netsplit *.net <-> *.split quits: hno` | 19:21 | |
| stekern | but the biggest problem with 1) isn't actually that we'd have to rebuild a "couple" of packages, the bigger problem is that we break userspace. | 19:25 |
| stekern | ...maybe option 2 is the way forward anyway... | 19:30 |
| blueCmd | stekern: for option 1, what happens if I change the 'reserved' reg? | 19:31 |
| blueCmd | in userspace | 19:31 |
| stekern | for the tls stuff you mean? | 19:32 |
| blueCmd | stekern: forget tls | 19:32 |
| -!- Netsplit over, joins: hno` | 19:32 | |
| blueCmd | let's say someone clobbers the register while in userspace (which is possible) | 19:32 |
| stekern | which register? | 19:33 |
| blueCmd | r10, if you got it your way | 19:33 |
| stekern | ok, right | 19:33 |
| stekern | if someone clobbers it in userspace, then userspace will get sad | 19:33 |
| stekern | the kernel doesn't care what userspace does with it | 19:34 |
| blueCmd | ah right | 19:34 |
| blueCmd | so basically it's a reg that can get clobbered anytime, got it | 19:34 |
| blueCmd | yeah, special regs sounds like the way to go there - if we start reserving a lot of regs for stuff it feels like intruding on the ISA/spec | 19:35 |
| blueCmd | but I have no idea the amount of work involved for that | 19:35 |
| blueCmd | qemu shouldn't care if we do it that way, so there's that | 19:35 |
| blueCmd | now, dinner | 19:35 |
| -!- Netsplit *.net <-> *.split quits: hno` | 19:43 | |
| -!- Netsplit over, joins: hno` | 19:54 | |
| -!- FreezingAlt is now known as FreezingCold | 20:04 | |
| -!- Netsplit *.net <-> *.split quits: hno` | 20:10 | |
| olofk | About multicore interrupt handling. Not sure if I have understood the issue completely, but would it help to have an external interrupt controller here? | 20:22 |
| olofk | And just have a single interrupt line in to the CPU | 20:22 |
| olofk | Also, regarding wide buses. Wouldn't this be very helpful when you have multiple masters as each master spends less time on the bus | 20:23 |
| olofk | I'm thinking both multicore and DMA | 20:23 |
| olofk | IIRC we are already bandwidth starved with the VGA core, and adding ethernet to that might be making it worse | 20:24 |
| olofk | blueCmd: And what you said matches my experience too. My mom always said that I was special and I went on the short bus | 20:27 |
| _franck_ | anyone has ever used cfi_ctrl written by juliusb ? I had to fix something in it to make it work: http://pastie.org/private/occhrgyy7vth4xermm4zna | 20:34 |
| olofk | _franck_: Haven't tried it, but could it be that he hardcoded things for a certain width of the Flash interface perhaps? | 20:35 |
| olofk | Is that the one in orpsocv2 btw? | 20:36 |
| olofk | Or is it a separate core on OpenCores? | 20:36 |
| _franck_ | it took the one in opencores svn | 20:36 |
| _franck_ | s/it/I | 20:36 |
| _franck_ | the problem is how it handles 16bits access on a wb32 bus | 20:37 |
| olofk | Because there is one in orpsocv2. You should check if they differ | 20:37 |
| _franck_ | I'll do that | 20:38 |
| olofk | There were many bug fixes in the orpsocv2 copies of cores that were never upstreamed | 20:38 |
| olofk | If you find something I suggest you volunteer to become the cfi_ctrl co-maintainer (still looking for people who wants to take care of the poor orphaned cores :)) | 20:39 |
| _franck_ | :) is that how you reward guy who fix bugs ?? | 20:41 |
| olofk | lol | 20:41 |
| _franck_ | well, I might know why we don't have much bug fixes ;) | 20:42 |
| olofk | Yeah. No one wants to be the guy who touched it last | 20:42 |
| olofk | Oh well. This is why we have the patches directory in fusesoc | 20:43 |
| stekern | _franck_: hmm, that looks like it expects something like the wb_data_resize.v would have been attached on the bus | 20:56 |
| _franck_ | yeah I though about this | 20:56 |
| _franck_ | but here: http://code.metager.de/source/xref/opencores/openrisc/orpsocv2/boards/xilinx/ml501/rtl/verilog/orpsoc_top/orpsoc_top.v | 21:00 |
| _franck_ | I didn't see any width adapter. But I should look more carefully | 21:00 |
| stekern | have you tried with both mor1kx and or1200? | 21:02 |
| _franck_ | no, only mor1kx | 21:03 |
| stekern | because... might be that or1200 let the bits on [1:0] out | 21:03 |
| _franck_ | ah, may be, I'll try with or1200 | 21:04 |
| stekern | ...and mor1kx did too before my l.lwa/l.swa changes | 21:05 |
| stekern | but I considered that a bug... | 21:06 |
| stekern | http://code.metager.de/source/xref/opencores/openrisc/orpsocv2/boards/xilinx/ml501/rtl/verilog/orpsoc_top/orpsoc_top.v | 21:06 |
| stekern | bah... | 21:06 |
| stekern | https://github.com/openrisc/mor1kx/commit/aa77169b6a0f84633ea2ad82f7153860f01688ba#diff-f23a7b01b90edde7203b557b4345fcaeR544 | 21:06 |
| stekern | what does the wb-spec say about that? | 21:07 |
| _franck_ | let's try to find out | 21:07 |
| olofk | Ha! Good luck finding out anything from that document :) | 21:07 |
| stekern | "For example the array size on a 32-bit data port with BYTE | 21:08 |
| _franck_ | I wasn't expecting bit [1:0] to be different than '0' | 21:08 |
| stekern | granularity is [ADR_O(n..2)]." | 21:08 |
| olofk | Why don't you ask on the wishbone mailing list? | 21:08 |
| stekern | from chapter 2.2.3 under the ADR_O description | 21:09 |
| stekern | so, the cfi core lose ;) | 21:09 |
| _franck_ | :) | 21:09 |
| stekern | unless it claims to have a 16-bit wishbone interface | 21:11 |
| stekern | then orpsoc lose | 21:11 |
| _franck_ | no, it's a 32 bits interface | 21:11 |
| stekern | under all circumstances though, the one at most loss is _franck_ that needs to fix it :( | 21:12 |
| stekern | s/that/who | 21:12 |
| _franck_ | that's why I vote to have system private patches :) So you can patch a core without getting much attention | 21:13 |
| _franck_ | I fixed it and all tests passes (hopefully juliusb has done some good test bench) | 21:14 |
| olofk | _franck_: There's nothing stopping you from pulling a complete core locally in your system :) | 21:14 |
| _franck_ | true | 21:14 |
| _franck_ | but I could seems suspect :) | 21:14 |
| _franck_ | s/I/it | 21:15 |
| blueCmd | how would you guys implement nand? | 21:17 |
| blueCmd | since afaics we don't have a l.nand | 21:17 |
| stekern | c = a and b; c = c xor 0xffffffff; | 21:23 |
| stekern | ? | 21:23 |
| _franck_ | I was like: blueCmd wants to use a NAND device and he's joking telling us we don't have l.nand like he could have say "we don't have a l.spi or l.vga" | 21:25 |
| _franck_ | :) | 21:26 |
| stekern | haha, to be honest, that was my first thought too | 21:26 |
| _franck_ | or1200 let bits [1:0] on the bus while doing 32 bits access | 21:26 |
| stekern | at least I thought he was speaking about nand flash after the first sentence | 21:27 |
| --- Log closed Sun May 11 00:00:43 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!