IRC logs for #openrisc Tuesday, 2014-04-15

--- Log opened Tue Apr 15 00:00:06 2014
stekernLimb: umm, that shows "no timing constraints found"02:48
Limbstekern: you mean at line 19?03:27
LimbBecause the contraints file for the code that does work has the same line03:28
LimbI assume it means no previous constraints were found? and it thus generates them?03:28
stekernI'm not sure why it does not ind any constraints, either it's trce that isn't executed like it should, or you actually don't have any constraints03:37
stekerncan you show your .ucf?03:37
stekernhmm, you don't have any constraints at all in there, not even for the sys_clk_pad_i (they are commented out)03:40
Limbforgot to commit haha03:47
stekernLimb: yes, but you still have no constraints:
Limbstekern: Ah. How do I know what pins need constraints and what they should be? or would it be just the clock pin in this case?04:56
stekern_at_least_ that incoming clock needs to be constrained, the other ones ise might be able to figure out from the PLL/DCM multiply/divide values04:58
stekernbecause if you don't constrain that, how will it know what clock freq it is?04:59
Limbstekern: that makes sense05:01
stekernfor reference, this are the constraints I'm using for the atlys board:
Limbstekern: you run your wb clock at 50, where as mine I believe runs at 100. is that a problem?05:03
stekernI don't know how the fpga on your board compares to the spartan6 on the atlys board05:06
stekernand the 50MHz is to be able use it for or1200 as well05:07
stekernbut, you'll find out now when you actually constraint your design if you'll get any timing errors05:07
stekernthat wb_clock constraint in my .ucf might be superflous btw, I think ISE will be able to figure it out by itself05:11
olofk_Limb: When you have added constraints, you can send over your .bld and .twr files again and we can help take another look06:26
olofk_stekern, _franck_ anyone else with de* boards: It would be great if you could add .dts files to the fusesoc systems. Just dump them in the data directory06:27
stekernI'm in the progress of pulling all the tests from mor1kx-devenv into or1k-tests06:34
olofk_stekern: Great! That poor repository has been empty and alone for far too long now07:04
stekernyes, I know I felt so sorry for it07:06
stekernI'm calling the old mor1kx_devenv (which is essentially orpsocv2++) tests 'native' tests, then I plan to add pgavins or1k-test and the or1ksim tests as git submodules07:07
stekernand then add some kind of wrappers around those to give a common interface07:08
olofk_Yeah, I've been thinking about how to handle those07:08
olofk_The or1ksim tests are part of the or1ksim repo, right?07:08
stekernyes, so it would be checking out the whole or1ksim repo07:08
stekernbut it's not like that's huge, so I think that's fine07:09
olofk_Fair enough, as it's quite small. The GCC tests are a bigger problem07:09
olofk_Well, it's not a huge problem07:09
olofk_But again I miss the SVN ability to get a subtree from a repo :)07:10
stekernI'm slightly leaning towards making the main 'engine' being driven by the python unittest framework07:10
stekernbut that's just grand plans at the moment, I think making the 'native' subfolder Makefile driven is a good idea for the moment07:11
stekern... I just suck at writing Makefiles...07:12
stekernhow do I get all .c files from a list of mixed files in a variable called SOURCES?07:13
olofk_stekern: Use wildcard07:15
olofk_And yes. Makefile good to get shit done now. unittest probably nice longterm solution07:15
stekernok... but how? CSOURCES = $(wildcard *.c $(SOURCES) does not work07:16
stekernthe problem I'm having is that I already have the list of files in $(SOURCES), not in some directory07:17
stekernbecause I want to keep around target dependent .tests lists, that lists only the tests that are relevant for the current target (where target can be mor1kx_cappuccino, or1200, mor1kx_espresso etc)07:18
_franck_web_olofk_: (dts) sure07:19
olofk_stekern: A static list for now perhaps?07:21
olofk_Does that work?07:21
stekernyou mean that I'd have seperate .ctests and .stests files?07:21
stekernthat'd probably work, but would mostly serve as a demonstration of my Makefile incompetence I think ;)07:22
olofk_Well I suck at makefiles as well, so you should probably listen to someone else's advice :)07:23
olofk_I got my share of makefile writing with the first version of orpsocv3. Dropping that code was the best thing I could have done07:24
stekernwell, I'm actually using 'shell cat' to build $(SOURCES), so I could just as well through in a grep into the mix there too...07:28
_franck_web_stekern: yeah, don't use Makefiles, do something with python and some config files07:28
stekernno, Makefiles are nice07:28
_franck_web_they are when you do understand it ;) (not like me)07:29
_franck_web_well, understand is one thing, writing them is something else07:30
stekernI think you want Makefiles to build the tests either way07:35
olofk_I think I'll release FuseSoC 1.2 any day now. Any last minute patches you want added?08:01
olofk_I'm using a mood based release schedule for FuseSoC. I'll release a new version when I feel for it :)08:02
stekernolofk_: we have the same schedule for mor1kx08:36
stekernfwiw, Linux has that kind of release schedule too...08:37
stekernthe only difference is that we have a lot more mood swings ;)08:37
stekernI think there'll be a mor1kx 2.0 release when the atomics fall in place08:39
blueCmd\o/ atomics10:09
stekernblueCmd: have you already added them to glibc?10:29
blueCmdstekern: the instructions?10:32
blueCmdglibc uses syscalls10:32
stekernthat's so last week =)10:36
olofk_stekern: Ok.. so you're raising the bar. Then I will release FuseSoC 3.0 when you do that!10:45
olofk_stekern: Are there any benchmarks that could indicate any performance increases with the atomic instructions?10:50
blueCmdstekern: we have parts of xfce4 in or1k Debian now11:55
blueCmdqemu doesn't do pthreads though so we're quickly running towards the hard wall where we cannot test stuff except on real hardware or or1ksim11:56
blueCmdit would be nice to see how responsive stuff are on real hardware11:56
blueCmdstekern: it would be nice if you could do a test on your dev kit11:57
blueCmdwe have weston packaged (which I guess is what you were using last time)11:57
olofk_Things that are memory bound will probably be a lot slower on real HW11:57
stekern(xfce) nice, that's my current favourite desktop11:58
stekernright, my atlys board port11:58
stekernit's done, so I should be able to test that11:59
stekernI've got an attention span comparable to my 3-year old daughter...12:00
stekern(weston) I never ran that, I think poke53281 did though12:04
olofk_Mind your language!12:07
stekernyou should watch the latest episode of Top Gear, they put their lips to a Black Co*k when they are in Thailand12:09
olofk_Linked from that page you can see who has most overall experience in coq12:27
olofk_I'm not very good myself. I suck at coq12:28
olofk_Maybee we should use coq instead of python for our test suite. I heard it's quite good at penetration testing12:30
stekern <- I like how it says 'coq' right under my profile picture there ;)12:32
blueCmdstekern: hahhaaa12:44
Limbolofk, stekern: .bld: ---- .twr:
Limbusing this in the ucf: NET "sys_clk_pad_i" TNM_NET = sys_clk_pin;15:02
LimbTIMESPEC TS_sys_clk_pin = PERIOD sys_clk_pin 100 MHz HIGH 50%15:02
stekernhmm, I wonder why trce still doesn't find any constraints15:19
Limbstekern: that would be because I copied them from the wrong build directory! -_-15:28
Limb.bld: --- .twr:
Limbalthough that one says no constraints found either, hrmmm15:30
stekernas a reference this is the 200 first lines of my .twr from the atlys board:
stekernolofk: seems like that default startup clk works for atlys15:49
Limbwell it appears I have to look into the clkgen because the primitive it uses is specific to spartan class chips15:59
poke53281blueCmd: To run weston you need libffi16:02
poke53281It's still very high on my list to finish the libffi port and send it to the maintainer16:03
poke53281so far this link will do it:
Limbstekern: I assigned the clocks directly to the inputs and it implemented the constraints... so I'll definitely have to look at the clkgen16:19
blueCmdpoke53281: yes, I have packaged that for my debian port16:32
blueCmdpoke53281: it does a stellar thing so far. some python packages invoke the skeleton functions, but other than that it keeps together just fine16:33
poke53281the libffi port is not complete. I stopped exactly at the point when weston started.16:47
poke53281Additional you need some special linux kernel options16:47
poke53281which are not available in menuconfig.16:47
blueCmdpoke53281: right, but I'm using qemu at the moment so it wouldn't be affected - but I'm interested in knowing which ones anyway, since I'm going to run it on hardware soon16:48
poke53281But they compile fine.  Just some messaging modules. Can't remember which one, but I can look up.16:48
blueCmdpoke53281: I know it's not complete, but it's better than nothing and actually works quite well16:48
poke53281That should do it.16:51
stekernblueCmd: I got my FSF letter back signed now16:53
blueCmdstekern: sweet16:53
stekernso, for my part, the paper turning exercise should be all done16:53
blueCmdstekern: did you do GCC as well?16:54
blueCmdotherwise, we're just getting started! :)16:54
stekernyeah, well, no =)16:55
poke53281I can't remember if there were other problems compiling weston. Of course, you have to disable a lot like drm and I had some problems with uClibc, But otherwise it compiles fine.16:55
stekernhmm, or1k-elf-gdb starts to eat up 16GB of memory every time I do: set $sr=119:19
olofkok. Making a FuseSoC 1.1 package now19:34
olofkYep. fusesoc 1.1 is released19:56
* juliusb applauds20:00
juliusbnice one olofk 20:00
juliusbI'll need to familiarise myself with this stuff, I'll write the next chiphack's tutorial for OpenRISC based on it20:01
juliusbwill need to familiarise myself with OpenRISC again, too. CPU architecture, right?20:02
juliusbI hope you've finally got flexlm licensing for it20:03
juliusbthat was the one thing holding back ORPSoC, not enough restrictions on who could use it20:03
juliusbI think we need a registration system which had a human in the loop to approve licenses we send out via email20:03
stekernoh crap, either my atomic insns or wallentos lru stuff brakes mor1kx20:11
stekernI think one human in the loop isn't enough, there should be at least 1020:15
stekernlooks like it's the lru stuff20:20
stekern1-way caches still works...20:29
blueCmdjuliusb: hah, flexlm21:51
blueCmdMS-PL and flexlm, I'll write a design document for that21:52
_franck_my NEEK board has now a beautiful openrisc powered pinguin:22:11
blueCmd_franck_: cool!22:12
blueCmd_franck_: looks like a nice board22:13
_franck_it is. I only miss an USB host22:14
blueCmd_franck_: like that? ;)22:27
* Limb is lost :(22:36
--- Log closed Wed Apr 16 00:00:07 2014

Generated by 2.15.2 by Marius Gedminas - find it at!