IRC logs for #openrisc Thursday, 2013-02-14

blueCmd_franck_: *facepalm* sorry for not looking there first00:23
_franck_:) no problem00:28
_franck_irc is faster sometimes00:28
_franck_about this:
_franck_do you think we should change this and always add -lboard-or1ksim without condiction on -static ?00:29
_franck_I mean -lboard-%*00:29
_franck_is there any reason for not doing it ?00:29
blueCmddoes it work?00:44
blueCmdif so, add it00:44
blueCmdi can't see any reason not to add it00:44
_franck_yes it works00:44
_franck_me too, I'll it00:44
_franck_unexpected failures from 227 to 122 ! :)00:57
_franck_better than the stable GDB 7.200:58
blueCmd_franck_: great work!01:06
blueCmd_franck_: any reason not to commit these groups to git?01:07
_franck_well I was waiting for my openocd work to be applied...01:08
_franck_but as those openocd folks are not the kind of person willing to apply other people patchs I'm not sure or1k openocd will be official some day01:08
_franck_I'll push my openocd or1k v2 port (because it is so different from the version on openrisc github)01:09
_franck_then I'll commit my tdesc patches to gdb01:09
blueCmd_franck_: ah ok. well I'm basing my linux port around this xml stuff now so It would be nice to have in the repo i think01:11
_franck_ok, I'll push that01:12
_franck_you'll show me what you did to use the xml file in place (I mean I always got it from the remote)01:13
blueCmd_franck_: i haven't figured it all out, but the XML files are used to generate tdesc-c-files I use01:14
_franck_yes and it's just matter of adding some lines in makefiles to get this tdesc c file generated ?01:15
blueCmdhah, fixing a few things in my testsuite environment shows gcc regressions are also down - all those uClibc-related + TLS now pass with eglibc \o/02:38
poke53281I am looking forward to compile some more complex stuff for my javascript or1k emulator.02:48
blueCmdpoke53281: :D cool!10:32
LoneTechI do not recall any or1200-elf toolchain10:53
blueCmdjonibo: do you remember if you ever implemented orig_r11 ? all I see now is the skeleton and no code that fills it12:36
joniboblueCmd: orig_r11 is implemented...13:55
joniboI think you've got an old kernel... 3.4 or so right?13:56
joniboit's not in there13:56
joniboI've got a complete rework of the signal handling out of tree (or in "wip" directory, maybe?)13:56
joniboI noticed you were on an old kernel yesterday when looking at your patch13:56
joniboI was going to get you to move to a later one, but I wanted to get one showstopper fixed before directing you to it13:57
jonibo...and it took all evening and all morning to sort out13:57
jonibonow that's almost done... so I'll hopefully direct you toward a newer kernel later today13:57
jonibothere's a lot of churn in the signal handling right now due to upstream changes13:58
stekernblueCmd: regarding cgen, this is the history behind the toolchain in one sentence (from my understaning when I did digging on it last): around 2000 Johan Rydberg submitted the openrisc target, that was cgen based. Around a year after that Ivan Guzvinec submitted the or32 target, that was completely decoupled from the work already started by Rydberg for some reason. Then Julius picked up the old openrisc toolchain, fixed it up so we again have a cgen based toolchain.16:36
stekern(ok, it was a bit more than one sentence, but almost)16:37
stekernjonibo: blueCmd was sniffing on a newer kernel earlier (I adviced him to), but he had some problems with ethoc on that iirc.16:39
LoneTechstekern: got cut off at "fixed it up so we again h"16:54
stekernave a cgen based toolchain17:12
stekernjuliusb: looks like the or1k-timer test gives a false negative if bus accesses are slow17:14
stekernthe tickloop has similiar problems, to that I already have a patch17:15
blueCmdjonibo: in the kernel it's implemented yes, but it's not exported via ptrace, right?17:17
blueCmdstekern: jonibo: that's right, never got eth0 to work. i patched the kernel so it was detected but never succeeded in negotations17:19
blueCmdjonibo: I started working with 3.6.10 but had to move down to 3.4 since that worked with ethoc17:20
blueCmd_franck_: I have a rundamentary gdbserver for or1k*linux working quite nicely now17:40
blueCmd_franck_: if you could merge your things to mainline so I can merge mine upon that, that would be stellar17:41
_franck_blueCmd: ok, I'll try to do that asap18:36
poke53281jonibo: Thanks for the patch of the self modifying code. Otherwise I would have send a similar patch myself in the next few days.19:12
blueCmdjonibo: i always need to patch this from mainline: "arch/openrisc/kernel/entry.S:1053: Error: unresolved expression that must be resolved"20:28
blueCmdit's a compile error and I'm surprised noone has removed it20:29
blueCmd*sigh* my bad, this was something else. I just assumed it was the same old thing I needed patch in the old kernel20:30
blueCmdjonibo: the TI_STACK macro, maybe I'm just blind (and/or tierd) - but I cant find it defined anywhere20:32
blueCmd(that's the compile error)20:43

Generated by 2.15.2 by Marius Gedminas - find it at!