IRC logs for #openrisc Thursday, 2012-05-03

-!- giuseppe` is now known as giuseppe08:47
stekernjuliusb: you around? I'm trying to compile the binutils from peter gavins or1k-src, but I run into some problems12:15
stekernfirst, I need to configure with: ../or1k-src/configure --target=or1k-elf --prefix=/opt/or1k-toolchain CC="gcc -fPIC" CXX="g++ -fPIC"12:16
stekernon my machine12:16
stekernbut then it still chokes on ./gdb12:17
stekernconfigure: error: configuration or1k-unknown-elf is unsupported.12:17
_franck_stekern: you are looking juliusb and I'm looking for you :)12:26
stekernat your service ;)12:27
_franck_do you think there could be a problem with buffer/cache in your sdram controller (de0 board) and atlys ddr2 controller ?12:27
_franck_I'm still working on the debug problem12:28
stekernI'm not betting money on the contrary ;)12:28
stekernwhat's your observations12:29
stekernI think they should be fine, but you never know12:29
stekern(you already helped me pinpoint one bug in the de0 sdram controller that I had missed) :P12:30
jeremybennettstekern: Looks like the top level config stuff is not set up properly.12:30
_franck_stekern: with signal tap, I can see the instruction wb add = 0x130 and value 0x2100....however, I've write/read back 0x11223344 at this address with another master12:31
_franck_Is there an easy way to disable bufferrs in the sdram controller ?12:32
_franck_just to make a quick test12:32
stekernhmm, not really, they are needed to hold the burst12:33
stekernyou could of course making them always dirty12:34
stekernthat would kind of disable them12:34
_franck_ah ok, I'll try this12:35
stekernI can take a look at what you need to change12:35
stekernhave you noticed that I've rewritten large parts of it btw?12:36
_franck_on the forum a guy has this debug problem and he's using atlys (and the ddr2 controller as your name on top of the files :))12:36
_franck_no I didn't12:36
stekernyeah yeah, just blame me for all your debug problems ;)12:37
_franck_I'll apply the changes12:38
stekernhmm, actually, if you haven't updated from the de0 nano version for a while this patch might solve your problems:
_franck_I'll try it12:39
stekernjeremybennett: possibly, I think gdb isn't even supposed to be supported in the or1k-src tree, I know too little to be sure what's the problem though12:59
stekernI think juliusb have used that tree (it contains his changes)13:01
stekernI have some (other) problems compiling his binutils-or1k too13:02
stekernthe good 'ol set-but-not-used error 13:03
jeremybennettstekern: The intention is that gdb forms part of a unified source tree. However it may take some setting up. The sourceware tree uses CVS modules, so is a set of overlapping file hierarchy subsets13:19
jeremybennettIt is significant that even Red Hat only try mirror individual CVS modules in git.13:20
jeremybennettIt may be that for git we have to do the same thing, and construct a unified build tree on the fly.13:20
stekernhmm, yeah, but presumably pgavin (and juliusb) have been able to build what's in there now13:25
stekernI'm maybe doing something wrong, I just followed juliusb's instructions in the README-O1K13:26
jeremybennettI presume so. The sourceware tree is a challenge. I currently have a customer who is using git for the entire GNU tool chain. When we have worked out the most effective way to do this, I'll write it up, since everyone seems determined to use git come what may!13:27
stekernyeah, the "problem" is that it is such a powerful programming aid that if you've got used to it you will want to use it whenever you program18:01
stekernreal life example: some weeks ago I introduced a bug in a project at work, I knew that the bug didn't exist couple of days before, running a git bisect on the commits between the "good day" and present solved the problem in 15 minutes18:04
stekernand I hadn't pushed the changes yet, so no-one even got bothered with my bug18:06
stekernjuliusb: after fixing the set-but-unused your binutils-or1k compiles fine19:45

Generated by 2.15.2 by Marius Gedminas - find it at!