--- Log opened Fri Feb 28 00:00:59 2014 | ||
--- Log closed Fri Feb 28 00:47:36 2014 | ||
--- Log opened Fri Feb 28 00:56:03 2014 | ||
-!- ServerMode/#openrisc [+ns] by cameron.freenode.net | 00:56 | |
-!- Irssi: #openrisc: Total of 1 nicks [1 ops, 0 halfops, 0 voices, 0 normal] | 00:56 | |
-!- Irssi: Join to #openrisc was synced in 316 secs | 01:01 | |
-!- ServerMode/#openrisc [-o juliusb] by cameron.freenode.net | 01:08 | |
!cameron.freenode.net *** Notice -- TS for #openrisc changed from 1393548963 to 1301926790 | 01:08 | |
-!- ServerMode/#openrisc [+ct-s] by cameron.freenode.net | 01:08 | |
-!- cameron.freenode.net changed the topic of #openrisc to: Official OpenRISC Project channel | http://opencores.org/or1k | http://openrisc.net | wiki: http://opencores.org/or1k/OR1K:Community_portal | Mailing lists: http://lists.openrisc.net/ http://lists.opencores.org/ | forum: http://opencores.org/forum,OpenRISC | git: https://github.com/openrisc | IRC log: http://juliusbaxter.net/openrisc-irc/ | OpenCores in #opencores | 01:08 | |
stekern | blueCmd: haha. nice! | 04:25 |
---|---|---|
dalias | hi | 04:35 |
stekern | dalias: hi | 04:35 |
dalias | i've seen news about openrisc a couple times recently and thought i'd stop by to see if anybody would be interested in helping add an openrisc target for musl libc | 04:37 |
stekern | dalias: that sounds very interesting, and something that has been on my (long) list of things to do | 04:55 |
dalias | aside from bits headers for types/kernel structs, there are only ~13 mandatory files for a port | 04:56 |
dalias | so it's pretty easy as long as you know the target ISA and ABI decently | 04:57 |
stekern | yeah, I can't imagine it being a much larger task than porting an arch to for example uclibc? | 04:57 |
stekern | and that I recently did in about a week for another arch | 04:57 |
dalias | it's a smaller task than for uclibc i think | 04:58 |
stekern | ok, so even better ;) | 04:58 |
dalias | yeah slightly less than uclibc which seems to have around 25-30 such files | 05:00 |
dalias | well if you do get around to it, we're always available on #musl to answer questions, or you can contact me directly | 05:31 |
stekern | dalias: thanks, don't be surprised if I take up on that offer =) | 05:42 |
stekern | _franck__: I tested your verilator WIP patch, the problem with the -lelf being inserted "at the wrong place" still exist with that | 06:14 |
stekern | olofk__: how did you get that to work in or1200-generic? | 06:16 |
stekern | _franck__: this slightly hacky incremental patch fixes it: http://pastie.org/8811190 | 06:26 |
stekern | I've got a feeling that it's hard to solve it in a less hacky way though... | 06:26 |
olofk_ | stekern: Hmm... I don't know really. It just worked™ | 07:01 |
olofk_ | blueCmd: Congrats on the slashdotting | 07:01 |
olofk_ | Does anyone know other soft CPUs have been running debian before? It would be fun to claim that this is the first time | 07:02 |
stekern | olofk_: did you remove the "custom" or1k-elf-loader that's in the or1200-generic verilator testbench? | 07:03 |
olofk_ | stekern: yep. And then I removed the extern declarations in tb.cpp and included #or1k-elf-loader.h and changed a few types | 07:04 |
olofk_ | I think that was all | 07:04 |
olofk_ | shameless linkedin+twitter promo for OpenRISC on Debian posted | 07:05 |
dalias | olofk_, i think this is a first | 07:06 |
dalias | see https://www.debian.org/ports/ | 07:07 |
olofk_ | stekern: What is the linking problem you see with verilator/fusesoc? | 07:08 |
stekern | the problem is that when the final linking is done, I get: "-lelf /path/to/or1k-elf-loader.o" instead of "/path/to/or1k-elf-loader.o -lelf" | 07:09 |
stekern | and then the references to libelf can't be resolved | 07:10 |
olofk_ | hmm... maybe someone who actually knows a bit about linking and stuff should have designed this instead of me :) | 07:12 |
olofk_ | What's the common thing to do here? Like in makefiles and stuff like that? | 07:13 |
stekern | hmm, I don't know, but don't you usually have the '-l' last? | 07:34 |
stekern | it's just that verilator put anything in the -LDFLAGS command line option first | 07:35 |
stekern | (and the whole -LDFLAGS thing is introduced with _franck__'s patch, so no need to worry about taking the blame olofk_ =)) | 07:39 |
stekern | I think I agree about keeping the orpsoc-cores name | 07:42 |
stekern | if anything, it could actually be renamed to orpsoc | 07:42 |
stekern | just to see if we can confuse our users any more | 07:43 |
stekern | because it's essentially what orpsoc-cores is, orpsoc, which utilize the fusesoc tool, just like the old orpsocv2 utilized 'gnu make' | 07:44 |
olofk_ | stekern: Yes, I've been thinking about that too, but I'm thinking of taking the consusion one step further by renaming one of the systems (like or1200-generic) to orpsoc instead | 08:08 |
olofk_ | stekern: Good to hear about the elf-loader. Did you get it running eco32 elfs? | 08:09 |
-!- rah_ is now known as rah | 08:15 | |
stekern | olofk_: yes, it works like a charm with eco32 elfs | 08:25 |
stekern | I got my core to do a "Hello world" in the verilated environment two days ago | 08:25 |
olofk_ | c00l | 08:30 |
_franck_web_ | stekern: I don't know why I don't have this linking problem | 08:33 |
olofk_ | Me neither | 08:34 |
stekern | what verilator version are you using? | 08:35 |
olofk_ | 3.850 I think | 08:35 |
olofk_ | Which linker are you using? | 08:35 |
stekern | GNU ld (GNU Binutils for Ubuntu) 2.23.52.20130913 | 08:37 |
olofk_ | I'm using the binutils one too. Not sure which version though | 08:38 |
stekern | what's the output of the last g++ command when you run the 'fusesoc' command? | 08:39 |
stekern | does the -lelf come before the or1k-elf-loader.o or after? | 08:39 |
stekern | my verilator version is: Verilator 3.855 2014-01-18 rev verilator_3_854-13-g470f12f | 08:39 |
_franck_web_ | however, if it still works on our configuration with your patch, let's push it. That would make fusesoc more error proof. (however, still be good to know _why_ ) | 08:40 |
stekern | to be clear, this is how that line looks for me *when it works*: http://pastie.org/8811503 | 08:44 |
stekern | maybe, to be bullet-proof, the LDFLAGS should be surrounded by start-group, end-group too... | 08:50 |
Megaf | Hi all | 13:37 |
Megaf | Can one simulate or emulate OpenRisc using QEMU? | 13:37 |
olofk_ | Megaf: Yes we can! | 13:42 |
Megaf | cool | 13:43 |
Megaf | Phoronix made me know or remember about OpenRisc yesterday and I found it pretty interesting | 13:44 |
Megaf | There is an article about a Debian port to OpenRISC and I'm really curious about the actuall performance of OpenRISC, either on QEMU, FPGA and on actual hardware | 13:47 |
Megaf | I know theres still no actual hardware | 13:48 |
Megaf | olofk_: ping | 13:49 |
olofk_ | Megaf: I would count our FPGA implementations as actual hardware, but it seems like many people don't | 13:50 |
olofk_ | anyway, you can give OpenRISC a spin on an FPGA, in a RTL simulator, on or1ksim (the reference ISA simulator), jor1k (the javascript implementation) or in qemu | 13:51 |
Megaf | I'm going to compile orlksim | 13:52 |
Megaf | red | 13:53 |
Megaf | oops | 13:53 |
Megaf | compiling, I hope it doesnt take too long | 13:54 |
Megaf | done, compiled (I'm using ARM here by the way) | 13:57 |
Megaf | blueCmd: Ping | 13:59 |
Megaf | I'm looking for you | 13:59 |
Megaf | blueCmd: where can I get your initramfs or vmlinuz | 14:01 |
Megaf | I just compiled the simulator here | 14:01 |
blueCmd | :( | 16:59 |
blueCmd | he's gone | 17:00 |
-!- Netsplit *.net <-> *.split quits: doomlord_, ssvb_, knz | 17:42 | |
-!- pi___ is now known as MegafRaspberryPi | 19:36 | |
-!- Netsplit *.net <-> *.split quits: knz, doomlord_, FreezingCold | 22:08 | |
-!- Netsplit over, joins: FreezingCold | 22:15 | |
--- Log closed Sat Mar 01 00:00:00 2014 |
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!