--- Log opened Thu Mar 20 00:00:28 2014 | ||
blueCmd | olofk: would you consider using git submodules instead of refering to github in core files? | 00:08 |
---|---|---|
blueCmd | it makes it less dependant on fusesoc and it uses a nice built-in thing in git | 00:09 |
blueCmd | olofk: it shows up like this: https://github.com/bluecmd/mexiko/tree/master/rtl | 00:31 |
julzmb | olofk, blueCmd: Yeah It already has a good OOP SV testbench so this is mostly an academic exercisen | 01:59 |
stekern | blueCmd: it has been suggested before (also by me too at some point), but olofk fights against it tooth and nail | 03:47 |
stekern | I've come to agree with him that not using it might be the better way though | 03:47 |
stekern | 1) it gives each core provider the same interface | 03:49 |
stekern | 2) it adds some features that are not provided by submodules (following HEAD of a branch for instance) | 03:51 |
stekern | 3) this is something I just came to think about - does git submodules work when the project is detached from it's 'main' git repo? | 03:52 |
stekern | 4) if you really want to use git submodules for your cores, you can, just use a local provider (i.e. leave the provider field empty). | 03:53 |
Hesham | Hi, I am working on porting RTEMS to or1k. I have some questions regarding that project. | 07:30 |
stekern | Hesham: let us hear them | 07:31 |
Hesham | Some of gcc requirements is to make ssize_t symmetric to size_t (int), it's needed that each target typedef this ssize_t | 07:31 |
Hesham | When I try to build newlib, I got an error because of mismatch of ssize_t definition, RTEMS developers asked me to define ssize_t as size_t for or1k | 07:32 |
Hesham | Where should I redefine it ? | 07:33 |
stekern | Hesham: humm, what does our ssize_t get defined to then? | 07:59 |
stekern | Hesham: nevermind, I get what they are speaking about now. RTEMS have it's own file which defines _ssize_t depending on the arch: newlib/libc/sys/rtems/machine/_types.h | 08:01 |
stekern | I bet that's where you should add or1k | 08:01 |
Hesham | stekern: Thanks, I will see what can I do and discuss this solution with them. | 08:03 |
Hesham | There are other problems regarding POSIX and thread in newlib port | 08:04 |
Hesham | I got compilation errors relate to these issues when trying to build gcc with newlib | 08:05 |
stekern | newlib for rtems? | 08:05 |
stekern | or just baremetal newlib too? | 08:05 |
Hesham | Should I be more specific ? | 08:05 |
stekern | being precise always helps ;) | 08:06 |
Hesham | I have generated patches from or1k-src/newlib to newlib-2.1.0 | 08:06 |
Hesham | I met some problems like the previous ssize_t (which rtems/crt0.c uses) | 08:07 |
Hesham | Another major problems are related to POSIX, like undeclared NAME_MAX | 08:07 |
Hesham | Which I had to declare manually to get over this problem | 08:08 |
Hesham | For threads, when I disable thread when configuring gcc, I got no errors, but I believe it's something like the previous NAME_MAX error | 08:09 |
dalias | hesham, ssize_t must be a signed type and size_t must be an unsigned type. they cannot be the same | 08:10 |
stekern | Hesham: yes, but that's all related to when you try to build it for the rtems target? | 08:17 |
Hesham | dalias: this issue is discussed there http://sourceware.org/ml/newlib/2013/msg00107.html | 08:17 |
Hesham | stekern: Yes ! | 08:17 |
Hesham | I have added some changes to build binutils, newlib, gcc for RTEMS | 08:17 |
Hesham | The process of building or1k-rtems4.11-* toolchain goes well without enabling threads | 08:18 |
stekern | yeah, threads have probably never been used in the or1k and newlib combination before | 08:21 |
Hesham | If threads are a critical requirement for RTEMS, I will have to add support to or1k/newlib to enable building it for RTEMS | 08:23 |
stekern | yup | 08:27 |
Hesham | Anyway, I think I will have sometime with you guys since the project is in its early stages :) | 08:29 |
Hesham | blueCmd: should be my mentor if I have been accepted in GSoC this year. | 08:32 |
stekern | olofk: I just found out that 'verilator -V' gives this output: http://pastie.org/8953820 | 16:15 |
stekern | so, we should get VERILATOR_ROOT from that if it's not set | 16:15 |
stekern | ...and the verilator 'binary' detection from verilator.py should be used to get the actual verilator to run that command. | 16:16 |
jungma | I'm not able to build the OR-toolchain on CentOS, can somebody help me? :) | 16:28 |
stekern | jungma: which, the or1k or or32 toolchain? | 16:48 |
stekern | the or32 one have known issues to build on newer Linux distributions | 16:48 |
jungma | stekern: I'm a little bit lost, because there are so many possibilities | 17:11 |
jungma | stekern: http://opencores.org/or1k/OpenRISC_GNU_tool_chain | 17:11 |
jungma | stekern: which path here i should take? | 17:11 |
stekern | jungma: if you don't have any particular reason to pick the or32 toolchain, go for the or1k one | 17:52 |
stekern | and if it's baremetal you're after, or1k-elf is the one you want | 17:53 |
stekern | so: http://opencores.org/or1k/OpenRISC_GNU_tool_chain#Newlib_toolchain_.28or1k-elf.29 | 17:53 |
jungma | stekern: okay, this i also tried, and there I beaome this error: configure: error: no usable dependency style found, IIRC | 18:21 |
stekern | hmm, haven't seen that ever | 18:40 |
stekern | at what stage? | 18:40 |
jungma | stekern: i will reproduce it tomorrow ;) | 18:47 |
stekern | looking forward to that ;) | 19:01 |
blueCmd | stekern: do you happen to know which IP core is 'teh shit' to use for USB? | 19:20 |
stekern | don't know if it's 'teh shit', but this is the one that has been used in orpsocv2 http://opencores.org/project,usbhostslave | 19:23 |
stekern | you probably want to pick it from some orpsocv2 repo though, I suspect it's heavily patched there | 19:24 |
stekern | there's u-boot and Linux drivers available for it | 19:24 |
blueCmd | http://git.opencores.org/?a=summary&p=orpsoc what is that? I cannot find any reference in the docs that that would be the latest orpsocv2 | 19:35 |
blueCmd | the docs point to a very outdated SVN | 19:35 |
stekern | that's the latest orpsocv3, before olofk switched to github | 19:36 |
stekern | http://opencores.org/websvn,listing?repname=openrisc&path=%2Fopenrisc%2Ftrunk%2Forpsocv2%2Frtl%2Fverilog%2Fusbhostslave%2F#path_openrisc_trunk_orpsocv2_rtl_verilog_usbhostslave_ | 19:38 |
stekern | olofk: can't I capture output from a command launched by the Launcher? | 19:40 |
blueCmd | stekern: I'm having trouble finding the pin constraints file for ordb2a, and I'm getting pretty annoyed over the state of the old code | 19:51 |
blueCmd | If I download the latest code in the repository it contains nothing, if I look at the SVN it isn't there, the only way I found it was to google and find a _specific_ revision to back the repository to | 19:52 |
stekern | I have no idea about anything about ordb2a | 19:52 |
blueCmd | deleting code like that is not OK. aurgh | 19:52 |
blueCmd | stekern: sorry, this isn't aimed at you, I'm just venting | 19:52 |
stekern | I think the orpsocv2 ordb2a code is in a virtual box image | 19:53 |
stekern | I'm having the same problem as _franck__ had the other day, I can't import verilator to sections | 20:57 |
stekern | I'm moving my stuff to utils in the meantime, they semi belong there anyway | 20:59 |
analognoise | Hi everyone. I've recently started working with FuseSOC cloned from Github. As a (very) new user, what are the best resources to get started? I want to use Openrisc in some FPGA designs | 22:38 |
blueCmd | analognoise: this very IRC channel! | 22:40 |
analognoise | Ah well, I've come to the right place! | 22:41 |
blueCmd | indeed :) | 22:41 |
_franck__ | analognoise: I did wrote a small article about fusesoc (was orpsocv3) | 22:41 |
_franck__ | http://www.elec4fun.fr/2011-03-30-10-16-30/2012-08-22-20-50-31/or1200-barebox-on-de1 | 22:41 |
analognoise | Is there a way that the Github page for Fusesoc could include a wiki directly? I thought it might be useful to leave notes for others as I run into issues and (hopefully) solve them | 22:45 |
blueCmd | TBH I think we should move out from opencores.org to something better that we can use. | 22:45 |
_franck__ | could be a way if someone writes it ;) | 22:45 |
blueCmd | a lot of bad things are tied to opencores atm. it has served us well, but a fresh portal and a (_one_) mailinglist wouldn't hurt :) | 22:46 |
_franck__ | blueCmd: agree | 22:47 |
analognoise | What are the bad things with opencores? | 22:56 |
analognoise | As someone wading through the information trying to get started, a fresh portal might be very useful | 22:57 |
blueCmd | analognoise: it requires you to be a member to access some stuff for one | 22:57 |
blueCmd | analognoise: it contains a lot of old source code that we no longer use | 22:57 |
blueCmd | and the wiki format is a bit of a pain to use | 22:57 |
analognoise | I thought the wiki was pretty painful. | 22:58 |
analognoise | Hm. I had wondered about this. | 22:58 |
analognoise | To an outsider it looked like there wasn't much project movement | 22:58 |
analognoise | I tried the IRC channel on a lark. | 22:58 |
blueCmd | analognoise: which is a bit of an understatement, we are moving quicker than ever I think | 22:59 |
blueCmd | fusesoc is making great progress, mor1kx is getting really good, Linux is very close to be perfect from mainline, we are upstreaming our toolchains to make it easier to develop for it, I'm porting Debian to OpenRISC, RTEMS is being ported to OpenRISC, s-macke is doing qemu and x11 optimizations and a bunch of other stuff that I have no idea about | 23:01 |
analognoise | Yeah, it sounds like a fresh portal would be really awesome. | 23:08 |
analognoise | I was looking for a mailing list of some kind | 23:09 |
blueCmd | we have two | 23:09 |
blueCmd | and you have to use both :P | 23:10 |
blueCmd | I want openrisc to have something like https://www.archlinux.org/ | 23:11 |
--- Log closed Fri Mar 21 00:00:29 2014 |
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!