| --- Log opened Mon Jan 27 00:00:12 2014 | ||
| powermaniac | blueCmd: So I've moved forward with getting or1k-qemu running and encountered some new problems. http://pastebin.com/VpagswVd Whenever you are there just leave a message as I will check the logs later. The main 'errors' are: "Please check cpu value and header information for m68k!" which later may have resulted in this: "FATAL: kernel too old" after this step: "sudo chroot initramfs /usr/local/bin/qemu-or32 -E PATH=/bin:/sbin: | 01:35 |
|---|---|---|
| powermaniac | /usr/bin:/usr/sbin:/usr/local/bin bin/bash /debootstrap/debootstrap --second-stage" | 01:35 |
| olofk_ | Jesus christ. I have never had such a reaction to a tweet before. Seems like that debian-thingy is quite popular :) | 07:14 |
| olofk_ | And it looks like it was a busy weekend judging from the IRC back log | 07:15 |
| olofk_ | _franck_: I remember my colleagues at ORSoC also discovered that some Altera cores generated a single VHDL file even when they used verilog. They never found a way around that | 07:16 |
| olofk_ | If you don't want to do it yourself you could try the VHDL preprocessor from the git version of Icarus | 07:16 |
| olofk_ | I've been playing with that a bit | 07:16 |
| olofk_ | jeremybennett, stekern: Was the whole always-enabled-malloc-debacle sorted out, btw? | 07:24 |
| jeremybennett | olofk_: Haven't seen anything, but I haven't been completely watching this IRC. Looking back, it looks like it may have already been solved (I haven't looked at newlib recently). stekern couldn't find the SPEC changes I originally made. | 07:26 |
| jeremybennett | And malloc does not seem to be automatically included. | 07:26 |
| jeremybennett | It may be that upstream reverted the weak reference change for malloc. | 07:26 |
| blueCmd | powermaniac: the first one about m68k is not an error but a warning, and since we're using or1k and not m68k it's fine | 07:29 |
| olofk_ | Finally found the bug report http://bugzilla.opencores.org/show_bug.cgi?id=45 | 07:29 |
| blueCmd | powermaniac: the one about kernel too old is a problem though, you will need to install a kernel from Sid. I don't have time to go into details about that, but if you ask around how to do that someone should be able to help you. it's basically editing your sources.list to have sid/unstable or something, doing apt-get update, upgrading linux-image and reverting source.list to the old values | 07:31 |
| blueCmd | olofk_: yeah, nice that it's well received! | 07:31 |
| olofk_ | Now if we only could get the basic stuff like binutils upstreamed... | 07:35 |
| blueCmd | yeah, that would be sweet | 07:36 |
| olofk_ | Is our or1k-src tree a union of binutils and other stuff (gdb perhaps?), and is it based on a stable binutils release or just randomly fetched from upstream VCS? | 07:43 |
| blueCmd | it's a mix and not based on a stable version | 07:45 |
| blueCmd | when I made the debian packages I rebased it upon a stable version though and used only the relevant parts | 07:46 |
| stekern | jeremybennett: yeah, I've got to the same conclusion, it must have been solved in some way. | 07:48 |
| stekern | yeah... we should fix our or1k-src repo... | 07:49 |
| stekern | it's just been regularly rebased against CVS code-dump check-outs, we should use the git repos and rebase our work upon those instead | 07:51 |
| stekern | and have release branches like in our gcc repo | 07:51 |
| stekern | I've said it's for a rainy day, but then winter "finally" came to finland, so it's just been snowy and cold here... | 07:52 |
| stekern | but, I'm only here for 4 more days, then a month in Thailand, perhaps there will be rain there ;) | 07:53 |
| blueCmd | Mmm, perhaps. | 07:56 |
| blueCmd | Is the case "we need to hunt down every single comitter" still true for binutils? | 07:56 |
| blueCmd | Or is that "only" for GCC? | 07:56 |
| stekern | no, I think it's the same for binutils | 07:56 |
| blueCmd | We should get that started. | 07:57 |
| stekern | but we're not so many and not so inactive | 07:57 |
| stekern | so binutils is easier than gcc | 07:57 |
| jonibo | blueCmd: what was it you wanted to host? apt repo? | 07:57 |
| blueCmd | jonibo: yes | 07:57 |
| jonibo | i'd be happy to let you host it at openrisc.net, if you want | 07:57 |
| jonibo | it's really just a matter of giving you SSH access to the machine | 07:58 |
| blueCmd | jonibo: cool stuff! it's about 1.6 GB right now, it will grow though | 07:58 |
| jonibo | ok | 07:58 |
| blueCmd | so around 10GB perhaps if that's alright | 07:58 |
| jonibo | I think storage shouldn't be an issue | 07:58 |
| jonibo | but I'll double check that | 07:58 |
| jonibo | how about sending me an SSH key and i'll set up an account for you | 07:59 |
| blueCmd | jonibo: priv | 08:00 |
| _franck_web_ | stange coincidence: http://opencores.org/forum,OpenRISC,0,5388 | 08:21 |
| _franck_web_ | this guy ask why the binary is so large. And when you look at the file, you can see there is memset, uart functions,.... even if you don't use them. | 08:22 |
| olofk_ | _franck_web_: Interesting. So it might not be fixed then | 08:37 |
| olofk_ | blueCmd: Where is your rebased binutils repo? | 09:00 |
| olofk_ | I would like to figure out whose permissions we need for upstreaming | 09:00 |
| stekern | olofk_: and _franck_web_, that's not related... | 09:04 |
| stekern | it's the libgloss startup code that pulls those in | 09:04 |
| olofk_ | oh.. perhaps I shouldn't have responded so quickly then | 09:04 |
| _franck_web_ | ok :) I wasn't sure | 09:04 |
| olofk_ | You know what they say about knowing a little about things :) | 09:04 |
| olofk_ | But isn't the libgloss startup code basically always used when you're compiling with or1k-elf? In that case, it would be the same problem | 09:06 |
| powermaniac | So I need to update to Debian Unstable/Sid do I? | 09:10 |
| powermaniac | Hopefully this time everything doesn't break as I've tried updating to Debian Sid a couple times with everything just become unusable | 09:11 |
| powermaniac | Is just updating to Debian Unstable/Sid enough or is there more to it then that? | 09:12 |
| stekern | olofk_: the libgloss startup code is always used when you compile with newlib, but why would that make it the same problem? | 09:35 |
| stekern | memset and the uart functions *are* used, they don't get pulled in unused | 09:36 |
| olofk_ | stekern: ok, I see, but are they required? Seems like the complaint here is that the minimum size could be made smaller | 09:54 |
| stekern | they are, unless you modify the libgloss startup code to not use it, or write your own startup code for your baremetal application | 09:56 |
| stekern | but I answered the forum post, and there is another issue we have with or1k that bloats the binaries | 09:57 |
| stekern | the exception vectors | 09:57 |
| olofk_ | ahh.. those dreaded exception vectors | 10:01 |
| olofk_ | That's harder to fix | 10:02 |
| stekern | you, can... at a SoC level | 10:03 |
| stekern | but that will break most of our sw ;) | 10:03 |
| blueCmd | olofk_: if you look at my or1k-debian github repo in the patches directory you should find a patch for the debian patch for binutils :) | 10:03 |
| blueCmd | very meta I know | 10:04 |
| blueCmd | i have a full source package but i cant upload it atm | 10:05 |
| olofk_ | comments? https://www.dropbox.com/s/b8t2zx0kbhv9cl3/or1k%20stack.png | 13:18 |
| stekern | magnificient | 13:20 |
| olofk_ | That was a good comment. More of those :) | 13:20 |
| stekern | the ocfb driver is in Linus' tree now btw | 13:36 |
| _franck_web_ | I'm printing it right now and will stick it to my office wall :) | 13:38 |
| olofk_ | _franck_web_: The ocfb driver? | 13:39 |
| _franck_web_ | ?? something might happened between you posted you chart and the moment I reconnected :) | 13:40 |
| olofk_ | stekern: Yeah, I saw that on phoronix. Awesome | 13:40 |
| olofk_ | [14:36] <stekern> the ocfb driver is in Linus' tree now btw | 13:40 |
| _franck_web_ | ah ok, cool. And no, I won't print it :) | 13:41 |
| olofk_ | :) | 13:41 |
| stekern | on phoronix? | 14:35 |
| stekern | man do they dig up every little piece of information to write about... | 14:39 |
| olofk_ | stekern: That guy knows how to scan commit logs for anything remotely news worthy :) | 14:53 |
| maxpaln | Hi, now the functionality is stabilising in the ECP3 port, I was looking to grt an idea of how quickly I can clock the processor. | 15:22 |
| maxpaln | Has anyone investigated pipelining the processor to allow performance improvements - | 15:22 |
| maxpaln | the following path is consistently the bottleneck at around 19 or 20 logic levels: | 15:23 |
| maxpaln | genpc -> immu -> exception handler | 15:23 |
| maxpaln | not knowing the architecture that well I don't know if I am on a hiding to nothing considering trying to pipeline any of this or whether there is scope to add some latency in here to allow the clock rate to come up | 15:24 |
| maxpaln | I appreciate this probably isn't a trivial task but I'd be interested to get your thoughts on it | 15:26 |
| maxpaln | It is, at least, an area I am more comfortable so it appeals as a challenge :-) | 15:27 |
| ciscoski | Hi there | 15:39 |
| ciscoski | Is there any resource for porting OR1K on Virtex 7 ? | 15:39 |
| ciscoski | ok nevermind | 15:40 |
| ciscoski | thanks | 15:40 |
| stekern | maxpaln: we went further than that, we wrote an alternative implementation | 15:41 |
| stekern | that's more pipelined than or1200 | 15:41 |
| maxpaln | oooh, really? | 15:44 |
| maxpaln | how did it go? | 15:44 |
| stekern | it's doing fine | 15:50 |
| stekern | you can use it in orpsocv3 | 15:51 |
| stekern | well, in orpsocv2 too, but it's more "plug-n-play" in orpsocv3 | 15:52 |
| maxpaln | ah, excellent - that is good news. | 15:53 |
| stekern | http://www.youtube.com/watch?v=8CwbNGXKrjI <- watch that if you want to know more | 15:53 |
| maxpaln | will do :-) When I get a chance I need to port my work to orpsocv3 - for some reason I started my work on orpsocv2, it is possible v3 wasn't advertised when I started | 15:54 |
| stekern | yes, orpsocv3 moved up to the preferable system pretty recently | 15:56 |
| maxpaln | ah, that explains it - if I can get a better Fmax I think shifting to v3 now moves up my priority list :-) | 15:57 |
| maxpaln | out of interest do you have any rough numbers to compare Fmax with and without pipelining (or put another way comparing the improved core vs the core I am working on) | 15:59 |
| stekern | but dropping mor1kx into orpsocv2 isn't hard, you can use this as an example: http://git.openrisc.net/cgit.cgi/stefan/orpsoc/tree/boards/altera/de0_nano/rtl/verilog/orpsoc_top/orpsoc_top.v#n1258 | 15:59 |
| maxpaln | ah, maybe that's an easier path as an interim - i'll take a look | 15:59 |
| stekern | well, or1200 that you are using is pipelined as well. | 16:01 |
| stekern | but Fmax increase about 50% have been seen on some FPGAs | 16:01 |
| maxpaln | ah, well that would be worth the effort :-) | 16:02 |
| maxpaln | I'll give it a go and let you know what improvement I get - | 16:02 |
| stekern | and as importantly, performance at the same clock speed should be about a 50% increase as well | 16:02 |
| maxpaln | ah, great - that is good news - all in all a big improvement | 16:03 |
| stekern | and, you can get it from here: https://github.com/openrisc/mor1kx | 16:03 |
| maxpaln | Well, this is a good news Monday! :-) | 16:08 |
| joaocfernandes | Quit See ya! | 16:54 |
| _franck_web_ | olofk_: did you see this commit here: https://github.com/openrisc/orpsoc/pull/20 ? | 16:59 |
| _franck_web_ | it somehow stayed silent | 17:00 |
| olofk | _franck_: I just answered that pull request before I checked in here | 20:02 |
| olofk | :) | 20:02 |
| olofk | Haven't had any time to work on this, but I have been thinking a lot and I have come up with a plan | 20:02 |
| olofk | I'll try to spell it out here, and if that doesn't work, I'll write a small spec instead :) | 20:03 |
| olofk | ok, so the problem is that some files or dependencies can only be used with certain tools, I want to support VHDL in the near future and I want to have files that are private to the cores | 20:04 |
| olofk | I don't want to mix VHDL and verilog files in the same configuration option, because then I have to look at the file endings and that sucks | 20:05 |
| olofk | So first of all, all tools (icarus, verilator, quartus) will have to implement some extra tags: verilog.src_files, verilog.private_src_files and depend | 20:06 |
| olofk | To make things more consistent, I'll probably drop the verilog section (but still keep it supported for some time) and replace it with verilog.src_files, verilog.private_src_files, verilog.include_files and so on | 20:07 |
| olofk | Oh... and another thing. In the tool-specific configuration options you will be able to exclude files that you don't want by setting - in front of them | 20:07 |
| olofk | So if every tool except for one uses a file, you can set verilog.src_files = -badfile.v in that tool's section | 20:08 |
| olofk | an even cooler feature is that you can also exclude files from another core if they are causing problems with -core_name:badfile.v (syntax is not yet defined) | 20:11 |
| olofk | I think that will solve all the use cases | 20:11 |
| olofk | So for now, the simulators will have to implement support for some new tags and then we can start move things from tb_src_files, tb_private_src_files and tb_include_files to the tool sections | 20:12 |
| olofk | The biggest drawback is that all test bench files will need to be repeated for both modelsim and icarus, but I'm sure we can figure something out here :) | 20:12 |
| _franck_ | olofk: if I understand it correctly, that sould solve the problem | 21:05 |
| stekern | olofk: that sounds cool, but I need to ask about the -core_name:badfile.v | 21:05 |
| stekern | so, is it some other core that will do that? | 21:06 |
| stekern | I'm worried it could cause "why isn't it using my changes I've done to this file" situations | 21:06 |
| stekern | that will be subtle to track down | 21:07 |
| stekern | but maybe I haven't got the full picture of your master plan (go write some specs boy!) =) | 21:08 |
| olofk | stekern: Yes, it is meant for other cores to use. It's mostly meant as an override feature, for example to replace a fifo with your own version or remove files that for some weird reason doesn't compile and was just pulled in but not used because of recursive dependencies | 21:21 |
| olofk | I think I had an actual use case for it now, but I forgot what that was so I won't implement it now anyways | 21:22 |
| stekern | ah, ok, so a bit like c++ overloading | 21:25 |
| stekern | ...which in the same way is a powerful tool but can bite you in subtle ways | 21:26 |
| olofk | _franck_: I think that I should do something for icarus and modelsim that is quite similar to what you did with your proposed patch for improved verilator support. | 21:39 |
| olofk | hmm.. I realize now that I need to do some refactoring to make this work | 21:41 |
| stekern | you better delete the repo and start over from scratch ;) | 21:47 |
| stekern | O | 21:48 |
| stekern | oops | 21:48 |
| olofk | I think you're right. The biggest problem is that I chose python. I will now redo it in javascript instead | 21:48 |
| olofk | and the latest web 2.0 technologies | 21:48 |
| olofk | I'll be back in a year when I'm done | 21:48 |
| stekern | we've heard about web 2.0 for a long time now, I'm waiting for web 3.0 | 21:49 |
| olofk | I think they're still trying to fix the bugs in 2.0 | 21:52 |
| olofk | Like the back button in browsers suddenly become useless | 21:52 |
| stekern | is that a feature or a bug? | 21:54 |
| stekern | or more correctly, what do you mean? =) | 21:55 |
| olofk | hard to tell | 21:55 |
| olofk | :) | 21:55 |
| stekern | my back button isn't useless | 21:56 |
| olofk | Just a common annoyance that the back button in browser were designed for stateless web pages, and doesn't work very well on many fancy pages | 21:56 |
| stekern | ah, I don't visit fancy pages | 21:57 |
| olofk | :) | 21:57 |
| _franck_ | olofk: you scares me with your plans, you're going to break everything :) | 21:58 |
| stekern | but I understand what you mean, my internet bank has just recently fixed that | 21:58 |
| olofk | _franck_: Yeah I know. I explained my evil plans hoping that someone would stop me :) | 21:59 |
| olofk | hmm.. there is already a simulator section in the core files. I had forgotten about that | 22:00 |
| stekern | just like a kid, trying it's boundaries =) | 22:00 |
| stekern | s/it's/its | 22:00 |
| _franck_ | olofk: you see, you don't even know how orpsoc works ! | 22:00 |
| _franck_ | ask some info to the maintainer first | 22:00 |
| _franck_ | then study the code | 22:01 |
| olofk | :) | 22:01 |
| stekern | haha | 22:01 |
| olofk | _franck_: There is no MAINTAINERS file in the repo, so I don't know who I should contact | 22:01 |
| _franck_ | right | 22:02 |
| _franck_ | :) | 22:02 |
| olofk | I give up for today. | 22:04 |
| olofk | Before I start to make things more complicated :) | 22:04 |
| -!- FreezingAlt is now known as FreezingCold | 22:50 | |
| --- Log closed Tue Jan 28 00:00:13 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!
