IRC logs for #openrisc Wednesday, 2013-12-11

--- Log opened Wed Dec 11 00:00:03 2013
olofk_Good $timeofday everyone!08:57
serpawhi everyone09:02
serpawI'm trying to build my own board in orpsoc v3 for de0-nano... unfortunatelly only changing name of the de0-nano directory, .core, .system names and board name in .system file makes it not working with software...09:04
serpawany ideas?09:05
serpawas not working with software I mean - it compiles and synthesise properly, but then it fails to run even simple programs, which runs ok at original de0-nano09:05
serpawconnection from OpenOCD is ok - it sees OR1K CPU and communicate with them09:06
olofk_serpaw: How are you running the simulation?09:09
olofk_Or are you running it directly on an FPGA target?09:10
serpawI'm not running the simulation. I'm trying to run at de0-nano board09:10
olofk_So you can build the de0_nano system, but when you make a copy with changed names it no longer works? Is that right?09:13
olofk_Well that sounds strange09:13
serpawalso result of synthesis is different - it gaves a little bit more or less logic elements after fit09:14
olofk_Hmm.. can you send over logs from both builds? And the quartus project file09:14
olofk_the .qpf file IIRC09:14
serpawok, wait a moment09:15
serpawamm. yesterday I've removed whole orpsoc build directory. I will build it again, please wait a moment09:19
olofk_Did you rename data/de0_nano.sdc, and if so, did you change the path in the .system file?09:22
serpawyes and yes ;)09:22
olofk_Just checking :)09:23
serpawI've renamed .core, .system and .sdc... I've also changed name in .system file to new one and path to sdc09:24
serpawsure ;)09:24
serpawI was also differing builds and src in build dir ale identically - of course only name of board is different09:27
serpawbut I've found that also order of including paths in quartus project are different09:28
olofk_Looks like you have investigated this quite a bit. Hope we can come up with a good reason why this is happening09:28
olofk_ordering of include paths is interesting. There has been other bugs that were caused because python dictionaries are unordered09:30
serpawyes, but I think order of include paths shouldn't affect result of synthesis09:31
olofk_Hmm.. I'm not sure I can receive with DCC. I'm on a web based IRC client :/09:33
stekernNice article about running de0 nano by Andrew Back on your g+ page olofk_10:48
stekernor linked to from your g+ page10:48
olofk_stekern: Yes. It's good to see that things are working good enough to actually be usable now10:54
jonibonice writeup.... kudos to the orpsoc team for making things so incredibly easy10:56
iorivurHi, there11:55
iorivurI'm newbie to OpenRISC, and want to modify openrisc core for my research as interest, but I can't know which software build tools are newest and "HEAD" repo.11:56
iorivurI read this page:  , but this document seems to be obsolete and the repository this page refer is also old.11:57
iorivurThen I went github page: but I couldn't know which software tools are the newest and which hardware source is newest (and worth to clone),11:59
iorivurbecause there are so many repos and few documents.11:59
iorivurPlease tell me how and which, thanks.12:00
stekerniorivur: instructions for the "newest" toolchain is here:
iorivurOK, thanks, I'll read there12:02
olofk_jonibo: It would be great if you could update the instructions on (if they are outdate). Looks like a lot of people use that as an entry point12:02
joniboyes, it's on my todo list... that said, they're not that out of date12:04
olofk_Would an amazon ec3 micro instance be a sensible choice for hosting a web server?12:04
joniboi disagree with the above assertion that the document is obsolete12:04
stekernI think the only problem might be that the svn mirrors is not working, right?12:05
jonibosvn mirrors?12:05
stekernthe instructions per se are fine IMO12:06
olofk_It uses the or32- toolchain. Shouldn't we try to move away from that?12:06
joniboi haven't updated the repos that the instructions point to because I haven't been able to get the github toolchain to work fully12:06
jonibo...that said, I haven't had much time to put into figuring out what the problem is, either12:07
joniboor32-toolchain... yeah, that's a bit of a detail but it would be smart to get away from that12:07
stekernsvn mirrors: git://, git://
joniboah, those are derived from the SVN repos but aren't updated12:08
stekernexactly, but my point is - the "version" the instructions work against might be "wrong", but that doesn't make the instructions themselves outdated12:10
olofk_Maybe we should just use variables like $current_repo and $toolchain_prefix so we don't have to change that all the time :)12:11
stekernjonibo: what problems have you encountered with the or1k- toolchain, apart from that you can't compile linux with the or1k-linux-* toolchain, due to the libgcc dependency we discussed (a rather long while ago)12:11
stekern(that alone is kind of a showstopper itself though, I admit)12:12
jonibogit clone git://
jonibothat's the website... feel free to send me patches :)12:12
iorivurWell, I'm not sure but the repository "openrisc."NET"" points is old, at least git repository.12:12
jonibostekern: i've got a handle on the libgcc dependency and hope to have the upstream soon (which is like plus/minus a year given the current rate of change)12:13
iorivurThis is final commit on master.12:13
iorivurcommit f986c82f13372801a5bc6aab7ae4c1e3c0c4d62112:13
iorivurAuthor: Jonas Bonn <>12:13
iorivurDate: Tue Apr 5 10:40:06 2011 +020012:13
joniboiorivur: yes, the toolchain at is a "stable" version12:13
stekernjonibo: wow, that sounds great!12:13
jonibostekern: sarcasm?12:13
olofk_I think that we should keep the source code in a works document and store it in ClearCase. That would keep people from updating it all the time12:14
stekernactually no, slow change is always better than no change ;)12:14
jonibook... :)  wasn't quite sure there12:14
joniboyes, the libgcc problem is essentially fixed in my repo...12:14 private repo, for now12:14
iorivurstable.. but I couldn't build that "stable" tool chain with newest gcc. It has bugs in binutils like this one (I'm not sure it is exactly same or just like so):
joniboheh... ok, I see your point12:15
joniboI was perhaps being a bit facetious with my "stable" comment12:16
iorivurOK, I'll pastebin that error.12:17
stekerniorivur: I bet that problem exists in all of our or32- toolchains12:17
jonibostekern: toolchain problems... I can't remember exactly what the problem was off the top of my head but itdidn't build last time I tried... xgcc couldn't find libc??? some search path issue?  don't  recall exactly...12:17
joniboi'll admit i'm a bit wary to poke at the toolchain code... i haven't looked at the code for along time and I pretty much consider myself "clean" ... I have half a mind to rewrite the toolchain from scratch in order to get it upstreamable12:19
joniboi don't think I'm tainted by the current code anymore12:19
olofk_jonibo: Are there code issues, or are you referring to the problems with finding the owners of the current code?12:20
joniboand reluctance of current owners to push things upstream.... just f*ing do it12:20
jonibohow many years has this been discussed?12:20
olofk_I made a promise at orconf last year to track down people. Haven't lifted a finger yet :/12:20
joniboclean room rewrite is the way to go, I'd say12:21
joniboanyone who hasn't looked at the current code for a year (?) should be eligible12:21
olofk_Clean room rewrite is good for that, but I'm guessing it would require a lot more effort than upstreaming what we have (given that we have solved the ownership issues)12:22
jonibomaybe... I don't recall the GCC port  being particularly big12:22
joniboand binutils has been rewritten already (???) by julius12:23
olofk_But couldn't we start with something, like the BFD or some other basic stuff? Didn't juliusb_ rewrite that from scratch a year ago?12:23
joniboyes... I think that's what I just said12:23
olofk_smurf :)12:23
joniboI'm thinking of GCC mainly12:23
iorivurSorry I can't reproduce that err...12:23
joniboproblem solved then! :)12:23
olofk_What is the preferred order by GNU? binutils before GCC, or the other way around?12:23
jonibobinutils before GCC, I think12:24
stekernjonibo: yes, binutils ownership is down to a handful people, and all are people that are around12:24
iorivurYey, thanks12:24
olofk_That's good news. Sounds very solvable to me12:24
stekernjuliusb_, peter gavin, me, blueCmd and _franck_12:24
joniboand GCC, I think, works with just a handful of changes... the rest is optimizations, anyway12:24
olofk_Could someone with a bit of git/grep-fu sort out the people that need to give away their ownership?12:25
olofk_For binutils I mean.12:25
iorivurarr, it happens12:25
jonibono, I don't think so, because the source code history is a mess12:26
jonibofor binutils...12:26
olofk_iorivur: What happens?12:26
jonibosorry, yeah, that must be possible12:26
olofk_jonibo: I bet you don't have the skills to do it ;)12:26
olofk_(trying out my reverse psychology experiment)12:27
joniboI thought it sounded like a dare... I'll admit, I flinched!12:27
iorivursorry for late, this is log but this log is so long, the last part is essential:
iorivurerr sorry, it is ommited12:35
joniboi see just warnings there12:35
olofk_That looks like the dreaded Wunused* problems from gcc>=4.612:36
jonibonothing to worry about... that's all fixed in a later GCC12:36
olofk_Thread hijacking. What's my best options for a cheap host where I can set up a web server and run a few scripts?12:38
stekerndarn IT department, forced restart on a machine running regression tests...12:39
stekern2 hours down the drain12:39
olofk_stekern: I feel for you12:39
jonibowhat would be the best best architecture to copy if starting to rewrite the toolchain from scratch... arm?12:42
jonibowhich arch has the best maintainers?12:43
stekernI think it's best to look at all and take the approach that is most sane12:48
iorivurThis is the error log:12:48
stekernbut arm is usually messy, with all its options12:49
joniboyeah, arm feels like it might be too big... aarch64 is more compact12:49
stekernI think m32r is pretty similar to us (at least binutils is)12:49
stekernbut I don't know if it's "good"12:50
iorivurYes, that log I paste before is ommited because it is too long, and we can see just warnings there, but acctually there is error above. It is so long, so you may see this with "tail" command12:50
jonibothe "good" arches should be the ones where the arch maintainer is also a key GCC developer12:50
iorivurI think last error is caused by failing to build gcc.12:51
iorivurMakefile:4160: recipe for target 'gcc.pod' failed12:51
iorivurmake[3]: [gcc.pod] Error 255 (ignored)12:51
joniboiorivur: i'm not really sure what you've done to get to that point... are you using github toolchain?  if yes, the toolchain is called or1k-... these days, not or32...12:51
iorivurNo, it is happen with "old" edition on "", that you say it is not obsolete.12:52
stekerniorivur: the problem is that the latest texinfo in newer distributions isn't compatible with the older toolchain12:52
iorivurYes, it is. And I don't think it's stable12:53
jonibowhat distro are you building on?12:54
jonibois the PATH set up properly?12:54
joniboare you following the "build by hand' instructions?12:54
stekerniorivur: it's stable, as a toolchain... the problem is with texinfo, that they broke backwards compatibility12:55
iorivurI'm using archlinux... it does fast rollong release like gentoo.12:58
iorivurok, I understood it's texinfo problem12:59
stekerniorivur: I think you can "dirty-workaround-it" by replacing all the .texi files in the doc dir with empty files13:09
iorivurno, it seems everything is good in new repo from git:// (commit f7b8f174ad0c3d10850b7d65aa1a12a680955f8f )13:12
iorivurat least, for now13:12
stekernyes, that doesn't have that problem (although the problem you pasted was in gcc, not binutils)13:15
iorivursorry for much asking but which is source code of hardware part, or ? I have DE0, ML507 and atlys13:15
iorivurstekern: oh, gcc. I'll remember13:15
stekernbut the problem exists in both binutils and gcc, so you weren't that far off anyway ;)13:16
olofk_iorivur: For de0 you should use orpsocv3. You can follow the instructions from Andrew Back's article or the orconf workshop (have to look up the links)13:17
olofk_Atlys isn't supported by orpsocv3 yet, so you have to use orpsocv2 for that for now13:18
stekerniorivur: is that de0 or de0 nano you have?13:18
olofk_I'm not sure about the ML507 support13:18
iorivuroriginal de0, and atlys is preferable because I've already installed xilinx ISE. how about this one13:19
olofk_atlys is supported by orpsocv2. I haven't gotten around to implement Xilinx support in ORPSoCv3 yet, and I don't have my Atlys anymore :(13:20
olofk_Damn 24 hour days. I'm getting lots of out-of-time errors13:21
iorivurOh, how different with socv2 and v3?13:21
olofk_iorivur: It's quite different. orpsocv2 is a more or less monolithic repository with forked copies of a bunch of IP cores and the build/simulation environment integrated13:22
olofk_orpsocv3 collects the upstream versions of IP and has separated the tools and scripts from the code13:23
olofk_s/IP/the cores13:23
blueCmdbinutils \o/13:23
iorivurHow about architecture and convenience to develop?13:25
olofk_iorivur: Between orpsocv[2-3]?13:25
olofk_One of the key parameters when designing orpsocv3 was that it should be as easy as possible to make new board ports, so hopefully that is better than orpsocv213:26
olofk_And a more modular architecture should help with maintainability13:27
olofk_It's aiming to be a little bit like Gentoo for RTL code13:27
iorivurwell, it seems good to use v3 on de0, I'll install quartusII13:29
iorivurand can you tell me the instruction or installation note for hw part?13:29
olofk_iorivur: I didn't understand that de0 and de0_nano was different boards. de0_nano is the one supported board right now13:29
iorivurhow is porting troublesome?13:31
olofk_Depends on how much you know about FPGA13:31
iorivuryes, acctually I don't much play with FPGA, just small like as camera operation and so.13:32
iorivur(and it's a little past13:32
olofk_In the best case it should just be to copy an existing system and change the HW dependent parts (pin mapping, FPGA part number and things like that)13:32
olofk_and clock generation13:33
olofk_Hmm.. stekern might have put up a prebuilt image for the atlys board somewhere. If you just want a pre-built system you could probably use that13:35
iorivurI found this page,  but I couldn't get what it means because it's openrisc repo but under PPC-* directory.  Is it a config file for ML507?,filedetails?repname=openrisc&path=%2Fopenrisc%2Ftrunk%2Frtos%2Ffreertos-6.1.1%2FDemo%2FPPC440_SP_FPU_Xilinx_Virtex5_GCC%2Fsystem.mhs&rev=58613:36
olofk_That's a hardware description file for Xilinx' XPS tool. Looks like it's for one of the older Xilinx FPGAs that had built-in PPC cores13:39
stekerniorivur: it has nothing to do with openrisc, it's just a part of freertos13:39
iorivuroh got it13:39
iorivurit's for microblaze13:40
olofk_No, it's for a hard PPC core in a Xilinx FPGA, but the same file format is used to create MicroBlaze systems with Xilinx XPS13:43
iorivurwell, how to build and simulate v2? there no README or such document, I can see Makefile and configure file in doc/13:56
iorivurI got this error on make-ing to synthesising in orpsoc/boards/xilinx/atlys/syn/xst/run14:09
iorivurI tried to git submodule update or so14:12
iorivurhmm...  make in orpsoc/boards/xilinx/atlys/sim/run emmits such error  >ls: cannot access /home/iorivur/src/verilog/openrisc/orpsoc/boards/xilinx/atlys/sim/run/../../backend/rtl/verilog/*.v: No such file or directory14:55
olofk_iorivur: Where did you get that orpsocv2?14:56
iorivurthis one14:57
iorivurit's not true14:57
iorivur* remote origin14:58
iorivur  Fetch URL: git://
iorivur  Push  URL: git://
olofk_That was one of the other problematic things about orpsocv2. There were so many forks so no one had any clue about which did what14:59
olofk_So I'm sorry, but I don't know about the state of that repo :/15:01
iorivuroh ok15:01
iorivurso which is official working orpsocv2?15:01
olofk_The one at is the original, and I saw that it contains an atlys port15:02
iorivurgot it15:02
iorivurhow about github one?15:02
iorivuror the other one (acctually I can't find which is v2 or v315:05
olofk_That's orpsocv3 :)15:07
olofk_So the official orpsocv2 is in opencores SVN and the official orpsocv3 is
iorivurhow about  orpsoc-cores? It's simulation/synthesis tool , isn't? Could you point me the documents of this one?15:11
olofk_It's the other way around. contains the build/simulation scripts. orpsoc-cores contain description files that points out where to fetch the HDL code or in some cases, the HDL code itself15:13
olofk_So orpsoc-cores is used by orpsocv315:13
olofk_And there is no documentation except for orpsocv3 except for a blog post by Andrew Back, instructions for an orpsocv3-based workshop and my presentation material from the last two years OpenRISC conferences15:15
olofk_Also _franck_ is working on an updated tutorial15:16
olofk_So in your case you should try to get orpsocv2 from OpenCores SVN running, or we can try to dig up a pre-built atlys image that I think stekern has made15:17
stekernto confuse even more, the atlys board in my orpsoc repo on is probably a better bet...15:18
olofk_Thanks stekern. We lacked some confusion. Glad you could fix that :)15:19
stekernthat's what we rock at, confuse our users :/15:19
olofk_I was planning to go with fusesoc for the orpsoc renaming btw. (fusion, combining cores... get it?)15:20
olofk_But maybe confusesoc is better :)15:20
olofk_But what do you think? Is fusesoc a good idea? I wanted to go for something with fusion at first, but Actel got their SmartFusion stuff and I think there already exists some core fusion tool15:33
iorivurhi there I'm back16:06
iorivurWell, the in orpsocv2/sw set $(OR32_TOOL_PREFIX=or1k-elf-) val as or32-elf-, but I think it's renamed to r1k-elf-16:09
iorivurso I renamed it and building went well.16:09
iorivurIf it's official HEAD, somebody fix it16:09
iorivurThis is patch:
iorivurs/somebody fix/somebody should fix/16:11
maxpalnHi - progressing the Lattice ECP3 port of the ORSOC. Now adding the Ethernet MAC - having problems though. The standard simulation ethmac-tx fails after sending 17 packets. Before I dive down into the code to debug anyone got any tips on places to look. Ethernet is not my strong point!17:18
maxpalnit's worth mentioning that ethmac-rx works fine17:18
maxpalnI haven't bothered testing the others as I figured something as fundamental as the Tx failing will prevent the others from working.17:19
maxpalnAs a bit of background, I basically copied and pasted the Xilinx instantiation of the Eth Phy into my orpsoc_top and orpsoc_testbench then made the necessary ammendments to the parameters and arbiter_dbus module. It went smoothly enough until I get the Tx test failing!!17:20
maxpalnHmmm, thinking that it is the processing of the 17th packet that is the problem - this number is probably significant because OETH_TXBD_NUM in ethmac-tx.c is defined as 16. The packet that fails (the 17th) is the first one where next_tx_buf_num has reset to 0. Wondering if there is a buffer issue somewhere...18:58
maxpalnYep, confirmed this is the area around the problem - reduced OETH_TXBD_NUM to 8 and now the test doesn't progress beyond the 9th packet...19:00
maxpalnShould there be some cleanup of the TX Buffer when next_tx_buf_num wraps back to 0?19:00
olofkAh crap. Missed the lattice guy again19:36
--- Log closed Thu Dec 12 00:00:05 2013

Generated by 2.15.2 by Marius Gedminas - find it at!