IRC logs for #openrisc Thursday, 2014-03-20

--- Log opened Thu Mar 20 00:00:28 2014
blueCmdolofk: would you consider using git submodules instead of refering to github in core files?00:08
blueCmdit makes it less dependant on fusesoc and it uses a nice built-in thing in git00:09
blueCmdolofk: it shows up like this: https://github.com/bluecmd/mexiko/tree/master/rtl00:31
julzmbolofk, blueCmd: Yeah It already has a good OOP SV testbench so this is mostly an academic exercisen01:59
stekernblueCmd: it has been suggested before (also by me too at some point), but olofk fights against it tooth and nail03:47
stekernI've come to agree with him that not using it might be the better way though03:47
stekern1) it gives each core provider the same interface03:49
stekern2) it adds some features that are not provided by submodules (following HEAD of a branch for instance)03:51
stekern3) 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
stekern4) 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
HeshamHi, I am working on porting RTEMS to or1k. I have some questions regarding that project.07:30
stekernHesham: let us hear them07:31
HeshamSome of gcc requirements is to make ssize_t symmetric to size_t (int), it's needed that each target typedef this ssize_t07:31
HeshamWhen 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 or1k07:32
HeshamWhere should I redefine it ?07:33
stekernHesham: humm, what does our ssize_t get defined to then?07:59
stekernHesham: 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.h08:01
stekernI bet that's where you should add or1k08:01
Heshamstekern: Thanks, I will see what can I do and discuss this solution with them.08:03
HeshamThere are other problems regarding POSIX and thread in newlib port08:04
HeshamI got compilation errors relate to these issues when trying to build gcc with newlib08:05
stekernnewlib for rtems?08:05
stekernor just baremetal newlib too?08:05
HeshamShould I be more specific ?08:05
stekernbeing precise always helps ;)08:06
HeshamI have generated patches from or1k-src/newlib to newlib-2.1.008:06
HeshamI met some problems like the previous ssize_t (which rtems/crt0.c uses)08:07
HeshamAnother major problems are related to POSIX, like undeclared NAME_MAX08:07
HeshamWhich I had to declare manually to get over this problem08:08
HeshamFor threads, when I disable thread when configuring gcc, I got no errors, but I believe it's something like the previous NAME_MAX error08:09
daliashesham, ssize_t must be a signed type and size_t must be an unsigned type. they cannot be the same08:10
stekernHesham: yes, but that's all related to when you try to build it for the rtems target?08:17
Heshamdalias: this issue is discussed there http://sourceware.org/ml/newlib/2013/msg00107.html08:17
Heshamstekern: Yes !08:17
HeshamI have added some changes to build binutils, newlib, gcc for RTEMS08:17
HeshamThe process of building or1k-rtems4.11-* toolchain goes well without enabling threads08:18
stekernyeah, threads have probably never been used in the or1k and newlib combination before08:21
HeshamIf threads are a critical requirement for RTEMS, I will have to add support to or1k/newlib to enable building it for RTEMS08:23
stekernyup08:27
HeshamAnyway, I think I will have sometime with you guys since the project is in its early stages :)08:29
HeshamblueCmd: should be my mentor if I have been accepted in GSoC this year.08:32
stekernolofk: I just found out that 'verilator -V' gives this output: http://pastie.org/895382016:15
stekernso, we should get VERILATOR_ROOT from that if it's not set16:15
stekern...and the verilator 'binary' detection from verilator.py should be used to get the actual verilator to run that command.16:16
jungmaI'm not able to build the OR-toolchain on CentOS, can somebody help me? :)16:28
stekernjungma: which, the or1k or or32 toolchain?16:48
stekernthe or32 one have known issues to build on newer Linux distributions16:48
jungmastekern: I'm a little bit lost, because there are so many possibilities17:11
jungmastekern: http://opencores.org/or1k/OpenRISC_GNU_tool_chain17:11
jungmastekern: which path here i should take?17:11
stekernjungma: if you don't have any particular reason to pick the or32 toolchain, go for the or1k one17:52
stekernand if it's baremetal you're after, or1k-elf is the one you want17:53
stekernso: http://opencores.org/or1k/OpenRISC_GNU_tool_chain#Newlib_toolchain_.28or1k-elf.2917:53
jungmastekern: okay, this i also tried, and there I beaome this error: configure: error: no usable dependency style found, IIRC18:21
stekernhmm, haven't seen that ever18:40
stekernat what stage?18:40
jungmastekern: i will reproduce it tomorrow ;)18:47
stekernlooking forward to that ;)19:01
blueCmdstekern: do you happen to know which IP core is 'teh shit' to use for USB?19:20
stekerndon't know if it's 'teh shit', but this is the one that has been used in orpsocv2 http://opencores.org/project,usbhostslave19:23
stekernyou probably want to pick it from some orpsocv2 repo though, I suspect it's heavily patched there19:24
stekernthere's u-boot and Linux drivers available for it19:24
blueCmdhttp://git.opencores.org/?a=summary&p=orpsoc what is that? I cannot find any reference in the docs that that would be the latest orpsocv219:35
blueCmdthe docs point to a very outdated SVN19:35
stekernthat's the latest orpsocv3, before olofk switched to github19:36
stekernhttp://opencores.org/websvn,listing?repname=openrisc&path=%2Fopenrisc%2Ftrunk%2Forpsocv2%2Frtl%2Fverilog%2Fusbhostslave%2F#path_openrisc_trunk_orpsocv2_rtl_verilog_usbhostslave_19:38
stekernolofk: can't I capture output from a command launched by the Launcher?19:40
blueCmdstekern: I'm having trouble finding the pin constraints file for ordb2a, and I'm getting pretty annoyed over the state of the old code19:51
blueCmdIf 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 to19:52
stekernI have no idea about anything about ordb2a19:52
blueCmddeleting code like that is not OK. aurgh19:52
blueCmdstekern: sorry, this isn't aimed at you, I'm just venting19:52
stekernI think the orpsocv2 ordb2a code is in a virtual box image19:53
stekernI'm having the same problem as _franck__ had the other day, I can't import verilator to sections20:57
stekernI'm moving my stuff to utils in the meantime, they semi belong there anyway20:59
analognoiseHi 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 designs22:38
blueCmdanalognoise: this very IRC channel!22:40
analognoiseAh well, I've come to the right place!22:41
blueCmdindeed :)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-de122:41
analognoiseIs 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 them22:45
blueCmdTBH 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
blueCmda 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: agree22:47
analognoiseWhat are the bad things with opencores?22:56
analognoiseAs someone wading through the information trying to get started, a fresh portal might be very useful22:57
blueCmdanalognoise: it requires you to be a member to access some stuff for one22:57
blueCmdanalognoise: it contains a lot of old source code that we no longer use22:57
blueCmdand the wiki format is a bit of a pain to use22:57
analognoiseI thought the wiki was pretty painful.22:58
analognoiseHm. I had wondered about this.22:58
analognoiseTo an outsider it looked like there wasn't much project movement22:58
analognoiseI tried the IRC channel on a lark.22:58
blueCmdanalognoise: which is a bit of an understatement, we are moving quicker than ever I think22:59
blueCmdfusesoc 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 about23:01
analognoiseYeah, it sounds like a fresh portal would be really awesome.23:08
analognoiseI was looking for a mailing list of some kind23:09
blueCmdwe have two23:09
blueCmdand you have to use both :P23:10
blueCmdI 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!