| --- Log opened Wed Dec 11 00:00:03 2013 | ||
| olofk_ | Good $timeofday everyone! | 08:57 |
|---|---|---|
| serpaw | hi everyone | 09:02 |
| serpaw | I'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 |
| serpaw | any ideas? | 09:05 |
| serpaw | as 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-nano | 09:05 |
| serpaw | connection from OpenOCD is ok - it sees OR1K CPU and communicate with them | 09:06 |
| olofk_ | serpaw: How are you running the simulation? | 09:09 |
| olofk_ | Or are you running it directly on an FPGA target? | 09:10 |
| serpaw | I'm not running the simulation. I'm trying to run at de0-nano board | 09: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 |
| serpaw | yes | 09:13 |
| olofk_ | Well that sounds strange | 09:13 |
| serpaw | also result of synthesis is different - it gaves a little bit more or less logic elements after fit | 09:14 |
| olofk_ | Hmm.. can you send over logs from both builds? And the quartus project file | 09:14 |
| olofk_ | the .qpf file IIRC | 09:14 |
| serpaw | ok, wait a moment | 09:15 |
| serpaw | amm. yesterday I've removed whole orpsoc build directory. I will build it again, please wait a moment | 09:19 |
| olofk_ | Did you rename data/de0_nano.sdc, and if so, did you change the path in the .system file? | 09:22 |
| serpaw | yes and yes ;) | 09:22 |
| olofk_ | Just checking :) | 09:23 |
| serpaw | I've renamed .core, .system and .sdc... I've also changed name in .system file to new one and path to sdc | 09:24 |
| serpaw | sure ;) | 09:24 |
| serpaw | I was also differing builds and src in build dir ale identically - of course only name of board is different | 09:27 |
| serpaw | but I've found that also order of including paths in quartus project are different | 09:28 |
| olofk_ | Looks like you have investigated this quite a bit. Hope we can come up with a good reason why this is happening | 09:28 |
| olofk_ | ordering of include paths is interesting. There has been other bugs that were caused because python dictionaries are unordered | 09:30 |
| serpaw | yes, but I think order of include paths shouldn't affect result of synthesis | 09:31 |
| olofk_ | Hmm.. I'm not sure I can receive with DCC. I'm on a web based IRC client :/ | 09:33 |
| stekern | Nice article about running de0 nano by Andrew Back on your g+ page olofk_ | 10:48 |
| stekern | or linked to from your g+ page | 10:48 |
| olofk_ | stekern: Yes. It's good to see that things are working good enough to actually be usable now | 10:54 |
| jonibo | nice writeup.... kudos to the orpsoc team for making things so incredibly easy | 10:56 |
| iorivur | Hi, there | 11:55 |
| iorivur | I'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 |
| iorivur | I read this page: http://openrisc.net/toolchain-build.html , but this document seems to be obsolete and the repository this page refer is also old. | 11:57 |
| iorivur | Then I went github page: https://github.com/openrisc but I couldn't know which software tools are the newest and which hardware source is newest (and worth to clone), | 11:59 |
| iorivur | because there are so many repos and few documents. | 11:59 |
| iorivur | Please tell me how and which, thanks. | 12:00 |
| stekern | iorivur: instructions for the "newest" toolchain is here: http://opencores.org/or1k/OpenRISC_GNU_tool_chain#Installation_of_development_versions | 12:00 |
| iorivur | OK, thanks, I'll read there | 12:02 |
| olofk_ | jonibo: It would be great if you could update the instructions on openrisc.net (if they are outdate). Looks like a lot of people use that as an entry point | 12:02 |
| jonibo | yes, it's on my todo list... that said, they're not that out of date | 12:04 |
| olofk_ | Would an amazon ec3 micro instance be a sensible choice for hosting a web server? | 12:04 |
| jonibo | i disagree with the above assertion that the document is obsolete | 12:04 |
| stekern | I think the only problem might be that the svn mirrors is not working, right? | 12:05 |
| jonibo | svn mirrors? | 12:05 |
| stekern | the instructions per se are fine IMO | 12:06 |
| olofk_ | It uses the or32- toolchain. Shouldn't we try to move away from that? | 12:06 |
| jonibo | i haven't updated the repos that the instructions point to because I haven't been able to get the github toolchain to work fully | 12:06 |
| jonibo | ...that said, I haven't had much time to put into figuring out what the problem is, either | 12:07 |
| jonibo | or32-toolchain... yeah, that's a bit of a detail but it would be smart to get away from that | 12:07 |
| stekern | svn mirrors: git://openrisc.net/jonas/binutils-svn, git://openrisc.net/jonas/gcc-svn | 12:08 |
| jonibo | ah, those are derived from the SVN repos but aren't updated | 12:08 |
| stekern | exactly, but my point is - the "version" the instructions work against might be "wrong", but that doesn't make the instructions themselves outdated | 12: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 |
| stekern | jonibo: 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 |
| jonibo | git clone git://openrisc.net/jonas/openrisc-doc | 12:12 |
| jonibo | that's the openrisc.net website... feel free to send me patches :) | 12:12 |
| iorivur | Well, I'm not sure but the repository "openrisc."NET"" points is old, at least git repository. | 12:12 |
| jonibo | stekern: 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 |
| iorivur | This is final commit on master. | 12:13 |
| iorivur | commit f986c82f13372801a5bc6aab7ae4c1e3c0c4d621 | 12:13 |
| iorivur | Author: Jonas Bonn <jonas.bonn@gmail.com> | 12:13 |
| iorivur | Date: Tue Apr 5 10:40:06 2011 +0200 | 12:13 |
| jonibo | iorivur: yes, the toolchain at openrisc.net is a "stable" version | 12:13 |
| stekern | jonibo: wow, that sounds great! | 12:13 |
| jonibo | stekern: 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 time | 12:14 |
| stekern | actually no, slow change is always better than no change ;) | 12:14 |
| jonibo | ok... :) wasn't quite sure there | 12:14 |
| jonibo | yes, the libgcc problem is essentially fixed in my repo... | 12:14 |
| jonibo | ...my private repo, for now | 12:14 |
| iorivur | stable.. 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): http://www.mail-archive.com/bug-binutils@gnu.org/msg14429.html | 12:15 |
| jonibo | heh... ok, I see your point | 12:15 |
| jonibo | I was perhaps being a bit facetious with my "stable" comment | 12:16 |
| iorivur | OK, I'll pastebin that error. | 12:17 |
| stekern | iorivur: I bet that problem exists in all of our or32- toolchains | 12:17 |
| jonibo | stekern: 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 |
| jonibo | i'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 upstreamable | 12:19 |
| jonibo | i don't think I'm tainted by the current code anymore | 12:19 |
| olofk_ | jonibo: Are there code issues, or are you referring to the problems with finding the owners of the current code? | 12:20 |
| jonibo | owners | 12:20 |
| jonibo | and reluctance of current owners to push things upstream.... just f*ing do it | 12:20 |
| jonibo | how 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 |
| jonibo | clean room rewrite is the way to go, I'd say | 12:21 |
| jonibo | anyone who hasn't looked at the current code for a year (?) should be eligible | 12: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 |
| jonibo | maybe... I don't recall the GCC port being particularly big | 12:22 |
| jonibo | and binutils has been rewritten already (???) by julius | 12: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 |
| jonibo | yes... I think that's what I just said | 12:23 |
| olofk_ | smurf :) | 12:23 |
| jonibo | I'm thinking of GCC mainly | 12:23 |
| iorivur | Sorry I can't reproduce that err... | 12:23 |
| iorivur | hmmm... | 12:23 |
| jonibo | problem solved then! :) | 12:23 |
| olofk_ | What is the preferred order by GNU? binutils before GCC, or the other way around? | 12:23 |
| jonibo | binutils before GCC, I think | 12:24 |
| stekern | jonibo: yes, binutils ownership is down to a handful people, and all are people that are around | 12:24 |
| iorivur | Yey, thanks | 12:24 |
| olofk_ | That's good news. Sounds very solvable to me | 12:24 |
| stekern | juliusb_, peter gavin, me, blueCmd and _franck_ | 12:24 |
| jonibo | and GCC, I think, works with just a handful of changes... the rest is optimizations, anyway | 12: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 |
| iorivur | arr, it happens | 12:25 |
| jonibo | no, I don't think so, because the source code history is a mess | 12:26 |
| jonibo | for binutils... | 12:26 |
| olofk_ | iorivur: What happens? | 12:26 |
| jonibo | sorry, yeah, that must be possible | 12:26 |
| olofk_ | jonibo: I bet you don't have the skills to do it ;) | 12:26 |
| jonibo | heh! | 12:27 |
| olofk_ | (trying out my reverse psychology experiment) | 12:27 |
| jonibo | I thought it sounded like a dare... I'll admit, I flinched! | 12:27 |
| iorivur | sorry for late, this is log but this log is so long, the last part is essential: http://pastebin.com/zfeFddvt | 12:34 |
| iorivur | err sorry, it is ommited | 12:35 |
| jonibo | i see just warnings there | 12:35 |
| olofk_ | That looks like the dreaded Wunused* problems from gcc>=4.6 | 12:36 |
| jonibo | nothing to worry about... that's all fixed in a later GCC | 12: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 |
| stekern | darn IT department, forced restart on a machine running regression tests... | 12:39 |
| stekern | 2 hours down the drain | 12:39 |
| olofk_ | stekern: I feel for you | 12:39 |
| jonibo | what would be the best best architecture to copy if starting to rewrite the toolchain from scratch... arm? | 12:42 |
| jonibo | which arch has the best maintainers? | 12:43 |
| stekern | I think it's best to look at all and take the approach that is most sane | 12:48 |
| iorivur | This is the error log: | 12:48 |
| iorivur | http://iorivur.ac-room.org/fail.txt | 12:48 |
| stekern | but arm is usually messy, with all its options | 12:49 |
| jonibo | yeah, arm feels like it might be too big... aarch64 is more compact | 12:49 |
| stekern | I think m32r is pretty similar to us (at least binutils is) | 12:49 |
| stekern | but I don't know if it's "good" | 12:50 |
| iorivur | Yes, 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" command | 12:50 |
| jonibo | the "good" arches should be the ones where the arch maintainer is also a key GCC developer | 12:50 |
| iorivur | I think last error is caused by failing to build gcc. | 12:51 |
| iorivur | Makefile:4160: recipe for target 'gcc.pod' failed | 12:51 |
| iorivur | make[3]: [gcc.pod] Error 255 (ignored) | 12:51 |
| jonibo | iorivur: 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 |
| iorivur | No, it is happen with "old" edition on "openrisc.net", that you say it is not obsolete. | 12:52 |
| stekern | iorivur: the problem is that the latest texinfo in newer distributions isn't compatible with the older toolchain | 12:52 |
| iorivur | Yes, it is. And I don't think it's stable | 12:53 |
| jonibo | what distro are you building on? | 12:54 |
| jonibo | is the PATH set up properly? | 12:54 |
| jonibo | are you following the "build by hand' instructions? | 12:54 |
| stekern | iorivur: it's stable, as a toolchain... the problem is with texinfo, that they broke backwards compatibility | 12:55 |
| iorivur | I'm using archlinux... it does fast rollong release like gentoo. | 12:58 |
| iorivur | ok, I understood it's texinfo problem | 12:59 |
| stekern | iorivur: I think you can "dirty-workaround-it" by replacing all the .texi files in the doc dir with empty files | 13:09 |
| iorivur | no, it seems everything is good in new repo from git://github.com/openrisc/or1k-src.git (commit f7b8f174ad0c3d10850b7d65aa1a12a680955f8f ) | 13:12 |
| iorivur | at least, for now | 13:12 |
| stekern | yes, that doesn't have that problem (although the problem you pasted was in gcc, not binutils) | 13:15 |
| iorivur | sorry for much asking but which is source code of hardware part, https://github.com/openrisc/mor1kx or https://github.com/openrisc/orpsoc-cores/tree/master/cores ? I have DE0, ML507 and atlys | 13:15 |
| iorivur | stekern: oh, gcc. I'll remember | 13:15 |
| stekern | but 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 now | 13:18 |
| stekern | iorivur: is that de0 or de0 nano you have? | 13:18 |
| olofk_ | I'm not sure about the ML507 support | 13:18 |
| iorivur | original de0, and atlys is preferable because I've already installed xilinx ISE. how about this one | 13: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 errors | 13:21 |
| iorivur | Oh, 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 integrated | 13:22 |
| olofk_ | orpsocv3 collects the upstream versions of IP and has separated the tools and scripts from the code | 13:23 |
| olofk_ | s/IP/the cores | 13:23 |
| blueCmd | binutils \o/ | 13:23 |
| iorivur | Ah-huh | 13:24 |
| iorivur | How about architecture and convenience to develop? | 13:25 |
| olofk_ | iorivur: Between orpsocv[2-3]? | 13:25 |
| iorivur | yep | 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 orpsocv2 | 13:26 |
| olofk_ | And a more modular architecture should help with maintainability | 13:27 |
| olofk_ | It's aiming to be a little bit like Gentoo for RTL code | 13:27 |
| iorivur | well, it seems good to use v3 on de0, I'll install quartusII | 13:29 |
| iorivur | and 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 now | 13:29 |
| iorivur | ar,, | 13:30 |
| iorivur | how is porting troublesome? | 13:31 |
| olofk_ | Depends on how much you know about FPGA | 13:31 |
| iorivur | yes, acctually I don't much play with FPGA, just small like as camera operation and so. | 13:32 |
| iorivur | (and it's a little past | 13: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 generation | 13: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 that | 13:35 |
| iorivur | I 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? http://opencores.org/websvn,filedetails?repname=openrisc&path=%2Fopenrisc%2Ftrunk%2Frtos%2Ffreertos-6.1.1%2FDemo%2FPPC440_SP_FPU_Xilinx_Virtex5_GCC%2Fsystem.mhs&rev=586 | 13: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 cores | 13:39 |
| stekern | iorivur: it has nothing to do with openrisc, it's just a part of freertos | 13:39 |
| iorivur | oh got it | 13:39 |
| iorivur | it's for microblaze | 13: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 XPS | 13:43 |
| iorivur | ahhuh | 13:51 |
| iorivur | well, how to build and simulate v2? there no README or such document, I can see Makefile and configure file in doc/ | 13:56 |
| iorivur | I got this error on make-ing to synthesising in orpsoc/boards/xilinx/atlys/syn/xst/run | 14:09 |
| iorivur | http://sprunge.us/bPBI?l | 14:09 |
| iorivur | I tried to git submodule update or so | 14:12 |
| iorivur | hmm... 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 directory | 14:55 |
| olofk_ | iorivur: Where did you get that orpsocv2? | 14:56 |
| iorivur | github | 14:56 |
| iorivur | https://github.com/openrisc/orpsoc | 14:57 |
| iorivur | this one | 14:57 |
| iorivur | oh | 14:57 |
| iorivur | it's not true | 14:57 |
| iorivur | * remote origin | 14:58 |
| iorivur | Fetch URL: git://openrisc.net/stefan/orpsoc | 14:58 |
| iorivur | Push URL: git://openrisc.net/stefan/orpsoc | 14:58 |
| iorivur | hre | 14:58 |
| 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 what | 14:59 |
| olofk_ | So I'm sorry, but I don't know about the state of that repo :/ | 15:01 |
| iorivur | oh ok | 15:01 |
| iorivur | so which is official working orpsocv2? | 15:01 |
| olofk_ | The one at opencores.org is the original, and I saw that it contains an atlys port | 15:02 |
| iorivur | got it | 15:02 |
| iorivur | how about github one? | 15:02 |
| olofk_ | github.com/openrisc/orpsoc? | 15:02 |
| iorivur | yes | 15:04 |
| iorivur | or the other one (acctually I can't find which is v2 or v3 | 15:05 |
| olofk_ | That's orpsocv3 :) | 15:07 |
| olofk_ | So the official orpsocv2 is in opencores SVN and the official orpsocv3 is github.com/openrisc/orpsoc | 15:07 |
| iorivur | how 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. github.com/openrisc/orpsoc 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 itself | 15:13 |
| olofk_ | So orpsoc-cores is used by orpsocv3 | 15: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 conferences | 15:15 |
| olofk_ | Also _franck_ is working on an updated tutorial | 15: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 made | 15:17 |
| stekern | to confuse even more, the atlys board in my orpsoc repo on openrisc.net is probably a better bet... | 15:18 |
| olofk_ | Thanks stekern. We lacked some confusion. Glad you could fix that :) | 15:19 |
| stekern | that'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 |
| stekern | soconfusing | 15:25 |
| olofk_ | :) | 15:32 |
| 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 tool | 15:33 |
| iorivur | hi there I'm back | 16:06 |
| iorivur | Well, the Makefile.inc in orpsocv2/sw set $(OR32_TOOL_PREFIX=or1k-elf-) val as or32-elf-, but I think it's renamed to r1k-elf- | 16:09 |
| iorivur | so I renamed it and building went well. | 16:09 |
| iorivur | If it's official HEAD, somebody fix it | 16:09 |
| iorivur | This is patch: http://sprunge.us/SVDA | 16:10 |
| iorivur | s/somebody fix/somebody should fix/ | 16:11 |
| maxpaln | Hi - 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 |
| maxpaln | it's worth mentioning that ethmac-rx works fine | 17:18 |
| maxpaln | I haven't bothered testing the others as I figured something as fundamental as the Tx failing will prevent the others from working. | 17:19 |
| maxpaln | As 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 |
| maxpaln | Hmmm, 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 |
| maxpaln | Yep, 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 |
| maxpaln | Should there be some cleanup of the TX Buffer when next_tx_buf_num wraps back to 0? | 19:00 |
| olofk | Ah crap. Missed the lattice guy again | 19:36 |
| --- Log closed Thu Dec 12 00:00:05 2013 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!