IRC logs for #openrisc Friday, 2012-05-04

jeremybennettstekern: Excellent - Clive Maxfield picking up on OpenRISC in EE Times.10:42
stekernyup, with the help of lobbying from our friend Sven-Åke ;)10:45
jeremybennettOf course - I've updated the tutorials entry on the Wiki, to give explicit credit to Sven-Åke10:53
jeremybennettI ought to update the Wikipedia entry as well.10:53
jeremybennettWikipedia updated:
juliusbstekern: sorry, been a few things on around here lately, have been monitoring the room but not had time to respond :(13:09
juliusbI have been building that binutils with the script (so unisrc method) from the opencores SVN, and just specifying the path to that binutils dir13:10
juliusbso however that configured binutils is how I've been doing it13:10
juliusbyes, very cool to see sven ake's work13:12
juliusbso, long weekend comign up here in the UK13:12
juliusbI plan on buying a desk and doing some more openrisc hackery13:13
stekern"that binutils dir" = or1k-src binutils dir?13:13
juliusbit's horrible weather as usual13:13
juliusbumm, no, i just pointed it to my git checkout13:13
juliusbi haven't looked at the or1k-src stuff yet13:13
stekernbuying a desk? don't you own a desk?13:13
juliusbbut I presume pgavin has pushed the latest stuff13:14
stekernah, ok I thought you had13:14
juliusbno desk yet, no, I moved house about a month ago and still haven't got one! hence not much FPGA action and so no testing of openocd stuff13:14
stekernI guess I have to ask pgavin about that then13:15
juliusbmy last bit of work I pushed to pgavin's binutils tree on github and the idea was to put it on the opencores svn under the gnu-dev dir or whatever13:15
juliusbin fact, it was mostly gcc fixes I think, which got us to the gcc regression test results I documented on the wiki a few weeks ago13:15
stekernyeah, I saw that13:16
stekernI was mostly interested in binutils, wanted to try doing llvm+binutils without gcc as the middle man13:17
stekernturns out it's a bit of a hassle, you have to pipe the assembler output to as and then ld the output13:18
stekernusing gcc as a shell for as and ld is a bit "cleaner"13:18
juliusbah yea13:20
juliusbso one of my projects last weekend was to fix up my or1ktrace libraryt hing13:20
juliusbi got it working using the latest binutils, nicely13:20
juliusbso that'l be handy for the mor1kx testbench stuff13:22
juliusbi'm hoping to address that this weekend, actually, neaten it all up ready for release13:22
stekernwill there be a release party? ;)13:27
juliusbhaha, we'll see :)13:53
pgavinjuliusb: are you here?13:59
pgavin :)13:59
stekernhello, just the guy I was waiting for ;)13:59
juliusbwhat's up?13:59
pgavinI wanted to ask you:  do you know if there's a way to use or1ksim with the gcc testsuite?13:59
juliusbpgavin: ah yes - to run it directly against or1ksim instead of using GDB?14:00
juliusbor, rather, the gdb sim?14:00
juliusbthat's what I've been doing14:00
pgavinok, and my gcc tree works with that?14:00
juliusbso basically, it's doable as long as you can get or1ksim to return the the return code of the simulated program14:00
juliusbyep, that's how I ran all of the regression tests for the recent set of results I got14:00
pgavinright, that's what I thought14:00
juliusband my patch I've been banging on about for or1ksim adds that feature to or1ksim14:00
juliusbbut it's not committed yet because for the life of me I can't get that bloody tcl except junk to test the actual return code of or1ksim, as simple as it iseems14:01
juliusband i've sort of given up and have half a mind to just commit it without a test14:01
juliusbi can post the patch and you can build or1ksim easily enough with this feature14:01
juliusband then i've been using the gnu regression harness scripts from the opencores svn14:01
juliusband just told it to call or1ksim instead of or32-elf-run or whatever14:02
juliusband that appears to work fine14:02
stekernpgavin: I tried compiling or1k-src yesterday, but it gave up in ./gdb with a: configure: error: configuration or1k-unknown-elf is unsupported.14:02
stekernhow are you supposed to build that thing?14:02
juliusbi can provide all of the details on the wiki tomorrow or perhaps tonight14:02
pgavinstekern: yeah, gdb isn't working yet :)14:02
pgavinstekern: you have to do --disable-gdb14:02
pgavinand --disable-sim14:03
pgavinstekern: I have a bunch of in-progress gdb stuff that I haven't pushed to the tree14:03
stekernok, nice14:04
pgavinbut I've had lots of other things to take care of, so I haven't done much on it in the last week or so14:04
stekernand thanks, I try rebuilding14:04
pgavinyou can use --disable-[dirname] to keep it from building anything you don't care about, like tcl, tk, and so on14:05
pgavinit speeds up the build14:05
stekernah, ok, thanks for the pointer14:05
pgavinbut binutils, gas, ld, newlib should all work14:05
pgavinif they don't let me know :)14:05
stekernI have to configure with CC="gcc -fPIC" and CXX="g++ -fPIC" for it to compile on my machine too14:06
pgavinthis is what I use:  --target=or1k-elf --enable-cgen-maint --disable-shared --disable-itcl --disable-tk --disable-tcl --disable-winsup --disable-libgui --disable-rda --disable-sid --disable-sim --disable-gdb --with-sysroot14:07
pgavinand if you haven't compiled gcc yet you need --disable-newlib --disable-libgloss14:07
pgavinonce you have gcc compiled, you can go back and rebuild it with newlib enabled14:08
stekernok, I'll try those options14:10
stekernhmm, now it complains about some guile.scm14:21
pgavinif you don't have guile installed, remove the --enable-cgen-maint option14:37
pgavinor just install guile :)14:37
pgavinbut you shouldn't need the --enable-cgen-maint option unless you change the files under cpu/14:37
stekernis some particular version guile version required?14:38
pgavindon't think so14:38
stekernyes, the removing --enable-cgen-maint works14:38
pgavingood :)14:38
stekernI installed, since it first complained about not finding it, but then it choked on guile.scm14:39
stekernbut I'll settle for without --enable-cgen-maint for now ;)14:40
pgavinyeah, you shouldn't need it14:41
pgavinbut I actually think you'd need guile-1.6 or better, since you asked14:41
--- Log closed Fri May 04 14:47:49 2012
--- Log opened Fri May 04 14:48:02 2012
-!- Irssi: #openrisc: Total of 18 nicks [0 ops, 0 halfops, 0 voices, 18 normal]14:48
stekernI installed guile-2.014:48
-!- Irssi: Join to #openrisc was synced in 25 secs14:48
stekernbut maybe guile-1.6 is needed then14:48
pgavinguile-1.8 workds14:49
stekernok, I can look into that closer (if I ever need to)14:51
pgavinif it doesn't work with guile-2.0, then it's because the upstream doesn't support it14:52
pgavinso I wouldn't worry14:52
stekernyeah, look into = remove guile-2.0 and install guile-1.8 ;)14:53
pgavinok :)14:53
stekernok, gas seems to work fine14:54
_franck_is there a way to invalidate the whole icache in one go (I think there was a topic on this point on the mailing list or forum, can't remember) ?15:00
jonibo|laptop_franck_: no15:02
_franck_ok thanks :)15:02
jonibo|laptopif you're on the or1200 you can use a trick...15:02
_franck_yes I am, so tell me please15:03
jonibo|laptopthe or1200 implementation is a bit broken15:03
jonibo|laptopso it will invalidate a cacheline if just the low bits in the effective address match the line15:03
jonibo|laptopso it's enough to loop over the low addresses (in 16 byte increments) in order to clear the cache15:03
_franck_low how ?15:04
jonibo|laptopit's a bit quicker than looping over the entire memory space15:04
_franck_the 16 low bits ?15:05
jonibo|laptopyeah, only the low 15 bits match for 32kB cache15:05
jonibo|laptopit doesn't matter what high bits you have in the effective address you try to invalidate15:05
_franck_ok.....thanks for the info15:06
jonibo|laptopi.e. invalidating 0x0 and  0x8000 clear the same cacheline, irregardless of what address is really cached there15:07
jonibo|laptopgood luck15:07
_franck_it would be good to have an invalidate all. Becaause when you download a progrm via gdb, then you download another one you should invalidate the whole thing15:07
_franck_we don't do it in openocd (I didn't look at the or_debug_proxy)15:08
jonibo|laptopi agree... others don't.. it's been a topic of discussion on several occasions15:08
_franck_and it is a waste of time to loop for invalidate15:08
jonibo|laptopespecially if you do it correctly and do the entire 32-bit memory space15:09
_franck_yes I think I've seen such discussion but couldn't fin dit15:09
pgavinanyone happen to know why l.rfe has l.nops immediately after it (as if it has a delay slot) in the newlib sources?15:09
jonibo|laptopit's often unclear whether rfe has a delay slot or not15:09
jonibo|laptopi know it doesn't, but i've got l.nop after it here and there, too15:10
pgavinunclear in what way?15:10
jonibo|laptophard to remember :)15:10
jonibo|laptopit feels like a jump!15:10
pgavinlol, sorta15:10
_franck_may be that can help:
_franck_arf you posted it15:11
_franck_sorry :)15:11
pgavinwell, I posted in that thread :)15:11
_franck_yeah I've seen it after I clicked "paste" :D15:11

Generated by 2.15.2 by Marius Gedminas - find it at!