IRC logs for #openrisc Monday, 2014-01-27

--- Log opened Mon Jan 27 00:00:12 2014
powermaniacblueCmd: So I've moved forward with getting or1k-qemu running and encountered some new problems. 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 log07: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 that07:16
olofk_If you don't want to do it yourself you could try the VHDL preprocessor from the git version of Icarus07:16
olofk_I've been playing with that a bit07:16
olofk_jeremybennett, stekern: Was the whole always-enabled-malloc-debacle sorted out, btw?07:24
jeremybennettolofk_: 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
jeremybennettAnd malloc does not seem to be automatically included.07:26
jeremybennettIt may be that upstream reverted the weak reference change for malloc.07:26
blueCmdpowermaniac: the first one about m68k is not an error but a warning, and since we're using or1k and not m68k it's fine07:29
olofk_Finally found the bug report
blueCmdpowermaniac: 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 values07:31
blueCmdolofk_: yeah, nice that it's well received!07:31
olofk_Now if we only could get the basic stuff like binutils upstreamed...07:35
blueCmdyeah, that would be sweet07: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
blueCmdit's a mix and not based on a stable version07:45
blueCmdwhen I made the debian packages I rebased it upon a stable version though and used only the relevant parts07:46
stekernjeremybennett: yeah, I've got to the same conclusion, it must have been solved in some way.07:48
stekernyeah... we should fix our or1k-src repo...07:49
stekernit's just been regularly rebased against CVS code-dump check-outs, we should use the git repos and rebase our work upon those instead07:51
stekernand have release branches like in our gcc repo07:51
stekernI'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
stekernbut, I'm only here for 4 more days, then a month in Thailand, perhaps there will be rain there ;)07:53
blueCmdMmm, perhaps.07:56
blueCmdIs the case "we need to hunt down every single comitter" still true for binutils?07:56
blueCmdOr is that "only" for GCC?07:56
stekernno, I think it's the same for binutils07:56
blueCmdWe should get that started.07:57
stekernbut we're not so many and not so inactive07:57
stekernso binutils is easier than gcc07:57
joniboblueCmd: what was it you wanted to host?  apt repo?07:57
blueCmdjonibo: yes07:57
joniboi'd be happy to let you host it at,  if you want07:57
joniboit's really just a matter of giving you SSH access to the machine07:58
blueCmdjonibo: cool stuff! it's about 1.6 GB right now, it will grow though07:58
blueCmdso around 10GB perhaps if that's alright07:58
joniboI think storage shouldn't be an issue07:58
jonibobut I'll double check that07:58
jonibohow about sending me an SSH key and i'll set up an account for you07:59
blueCmdjonibo: priv08:00
_franck_web_stange coincidence:,OpenRISC,0,538808: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 then08:37
olofk_blueCmd: Where is your rebased binutils repo?09:00
olofk_I would like to figure out whose permissions we need for upstreaming09:00
stekernolofk_: and _franck_web_, that's not related...09:04
stekernit's the libgloss startup code that pulls those in09:04
olofk_oh.. perhaps I shouldn't have responded so quickly then09:04
_franck_web_ok :) I wasn't sure09: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 problem09:06
powermaniacSo I need to update to Debian Unstable/Sid do I?09:10
powermaniacHopefully this time everything doesn't break as I've tried updating to Debian Sid a couple times with everything just become unusable09:11
powermaniacIs just updating to Debian Unstable/Sid enough or is there more to it then that?09:12
stekernolofk_: the libgloss startup code is always used when you compile with newlib, but why would that make it the same problem?09:35
stekernmemset and the uart functions *are* used, they don't get pulled in unused09:36
olofk_stekern: ok, I see, but are they required? Seems like the complaint here is that the minimum size could be made smaller09:54
stekernthey are, unless you modify the libgloss startup code to not use it, or write your own startup code for your baremetal application09:56
stekernbut I answered the forum post, and there is another issue we have with or1k that bloats the binaries09:57
stekernthe exception vectors09:57
olofk_ahh.. those dreaded exception vectors10:01
olofk_That's harder to fix10:02
stekernyou, can... at a SoC level10:03
stekernbut that will break most of our sw ;)10:03
blueCmdolofk_: 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
blueCmdvery meta I know10:04
blueCmdi have a full source package but i cant upload it atm10:05
olofk_That was a good comment. More of those :)13:20
stekernthe ocfb driver is in Linus' tree now btw13: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. Awesome13:40
olofk_[14:36] <stekern> the ocfb driver is in Linus' tree now btw13:40
_franck_web_ah ok, cool. And no, I won't print it :)13:41
stekernon phoronix?14:35
stekernman 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
maxpalnHi, 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
maxpalnHas anyone investigated pipelining the processor to allow performance improvements -15:22
maxpalnthe following path is consistently the bottleneck at around 19 or 20 logic levels:15:23
maxpalngenpc -> immu -> exception handler15:23
maxpalnnot 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 up15:24
maxpalnI appreciate this probably isn't a trivial task but I'd be interested to get your thoughts on it15:26
maxpalnIt is, at least, an area I am more comfortable so it appeals as a challenge :-)15:27
ciscoskiHi there15:39
ciscoskiIs there any resource for porting OR1K on Virtex 7 ?15:39
ciscoskiok nevermind15:40
stekernmaxpaln: we went further than that, we wrote an alternative implementation15:41
stekernthat's more pipelined than or120015:41
maxpalnoooh, really?15:44
maxpalnhow did it go?15:44
stekernit's doing fine15:50
stekernyou can use it in orpsocv315:51
stekernwell, in orpsocv2 too, but it's more "plug-n-play" in orpsocv315:52
maxpalnah, excellent - that is good news.15:53
stekern <- watch that if you want to know more15:53
maxpalnwill 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 started15:54
stekernyes, orpsocv3 moved up to the preferable system pretty recently15:56
maxpalnah, that explains it - if I can get a better Fmax I think shifting to v3 now moves up my priority list :-)15:57
maxpalnout 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
stekernbut dropping mor1kx into orpsocv2 isn't hard, you can use this as an example:
maxpalnah, maybe that's an easier path as an interim - i'll take a look15:59
stekernwell, or1200 that you are using is pipelined as well.16:01
stekernbut Fmax increase about 50% have been seen on some FPGAs16:01
maxpalnah, well that would be worth the effort :-)16:02
maxpalnI'll give it a go and let you know what improvement I get -16:02
stekernand as importantly, performance at the same clock speed should be about a 50% increase as well16:02
maxpalnah, great - that is good news - all in all a big improvement16:03
stekernand, you can get it from here:
maxpalnWell, this is a good news Monday! :-)16:08
joaocfernandesQuit See ya!16:54
_franck_web_olofk_: did you see this commit here: ?16:59
_franck_web_it somehow stayed silent17:00
olofk_franck_: I just answered that pull request before I checked in here20:02
olofkHaven't had any time to work on this, but I have been thinking a lot and I have come up with a plan20:02
olofkI'll try to spell it out here, and if that doesn't work, I'll write a small spec instead :)20:03
olofkok, 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 cores20:04
olofkI 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 sucks20:05
olofkSo first of all, all tools (icarus, verilator, quartus) will have to implement some extra tags: verilog.src_files, verilog.private_src_files and depend20:06
olofkTo 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 on20:07
olofkOh... 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 them20:07
olofkSo if every tool except for one uses a file, you can set verilog.src_files = -badfile.v in that tool's section20:08
olofkan 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
olofkI think that will solve all the use cases20:11
olofkSo 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 sections20:12
olofkThe 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 problem21:05
stekernolofk: that sounds cool, but I need to ask about the -core_name:badfile.v21:05
stekernso, is it some other core that will do that?21:06
stekernI'm worried it could cause "why isn't it using my changes I've done to this file" situations21:06
stekernthat will be subtle to track down21:07
stekernbut maybe I haven't got the full picture of your master plan (go write some specs boy!) =)21:08
olofkstekern: 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 dependencies21:21
olofkI think I had an actual use case for it now, but I forgot what that was so I won't implement it now anyways21:22
stekernah, ok, so a bit like c++ overloading21:25
stekern...which in the same way is a powerful tool but can bite you in subtle ways21: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
olofkhmm.. I realize now that I need to do some refactoring to make this work21:41
stekernyou better delete the repo and start over from scratch ;)21:47
olofkI think you're right. The biggest problem is that I chose python. I will now redo it in javascript instead21:48
olofkand the latest web 2.0 technologies21:48
olofkI'll be back in a year when I'm done21:48
stekernwe've heard about web 2.0 for a long time now, I'm waiting for web 3.021:49
olofkI think they're still trying to fix the bugs in 2.021:52
olofkLike the back button in browsers suddenly become useless21:52
stekernis that a feature or a bug?21:54
stekernor more correctly, what do you mean? =)21:55
olofkhard to tell21:55
stekernmy back button isn't useless21:56
olofkJust a common annoyance that the back button in browser were designed for stateless web pages, and doesn't work very well on many fancy pages21:56
stekernah, I don't visit fancy pages21:57
_franck_olofk: you scares me with your plans, you're going to break everything :)21:58
stekernbut I understand what you mean, my internet bank has just recently fixed that21:58
olofk_franck_: Yeah I know. I explained my evil plans hoping that someone would stop me :)21:59
olofkhmm.. there is already a simulator section in the core files. I had forgotten about that22:00
stekernjust like a kid, trying it's boundaries =)22:00
_franck_olofk: you see, you don't even know how orpsoc works !22:00
_franck_ask some info to the maintainer first22:00
_franck_then study the code22:01
olofk_franck_: There is no MAINTAINERS file in the repo, so I don't know who I should contact22:01
olofkI give up for today.22:04
olofkBefore I start to make things more complicated :)22:04
-!- FreezingAlt is now known as FreezingCold22:50
--- Log closed Tue Jan 28 00:00:13 2014

Generated by 2.15.2 by Marius Gedminas - find it at!