--- Log opened Tue Apr 15 00:00:06 2014 | ||
stekern | Limb: umm, that shows "no timing constraints found" | 02:48 |
---|---|---|
Limb | stekern: you mean at line 19? | 03:27 |
Limb | Because the contraints file for the code that does work has the same line | 03:28 |
Limb | I assume it means no previous constraints were found? and it thus generates them? | 03:28 |
stekern | I'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 constraints | 03:37 |
stekern | can you show your .ucf? | 03:37 |
Limb | stekern: https://github.com/Limb/orpsoc-cores/blob/nexys4/systems/nexys4/data/nexys4.ucf | 03:39 |
stekern | hmm, you don't have any constraints at all in there, not even for the sys_clk_pad_i (they are commented out) | 03:40 |
Limb | stekern: https://github.com/Limb/orpsoc-cores/blob/nexys4/systems/nexys4/data/nexys4.ucf | 03:47 |
Limb | forgot to commit haha | 03:47 |
stekern | Limb: yes, but you still have no constraints: https://github.com/Limb/orpsoc-cores/blob/nexys4/systems/nexys4/data/nexys4.ucf#L8 | 04:54 |
Limb | stekern: 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 values | 04:58 |
stekern | because if you don't constrain that, how will it know what clock freq it is? | 04:59 |
Limb | stem | 05:01 |
Limb | stekern: that makes sense | 05:01 |
stekern | for reference, this are the constraints I'm using for the atlys board: https://github.com/skristiansson/orpsoc-cores/blob/master/systems/atlys/data/atlys.ucf#L319 | 05:01 |
Limb | stekern: you run your wb clock at 50, where as mine I believe runs at 100. is that a problem? | 05:03 |
stekern | I don't know how the fpga on your board compares to the spartan6 on the atlys board | 05:06 |
stekern | and the 50MHz is to be able use it for or1200 as well | 05:07 |
stekern | +to | 05:07 |
stekern | but, you'll find out now when you actually constraint your design if you'll get any timing errors | 05:07 |
stekern | that wb_clock constraint in my .ucf might be superflous btw, I think ISE will be able to figure it out by itself | 05:11 |
olofk_ | Limb: When you have added constraints, you can send over your .bld and .twr files again and we can help take another look | 06: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 directory | 06:27 |
stekern | sure | 06:34 |
stekern | I'm in the progress of pulling all the tests from mor1kx-devenv into or1k-tests | 06:34 |
olofk_ | stekern: Great! That poor repository has been empty and alone for far too long now | 07:04 |
stekern | yes, I know I felt so sorry for it | 07:06 |
stekern | I'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 submodules | 07:07 |
stekern | and then add some kind of wrappers around those to give a common interface | 07:08 |
olofk_ | Yeah, I've been thinking about how to handle those | 07:08 |
olofk_ | The or1ksim tests are part of the or1ksim repo, right? | 07:08 |
stekern | yes, so it would be checking out the whole or1ksim repo | 07:08 |
stekern | but it's not like that's huge, so I think that's fine | 07:09 |
olofk_ | Fair enough, as it's quite small. The GCC tests are a bigger problem | 07:09 |
olofk_ | Well, it's not a huge problem | 07:09 |
olofk_ | But again I miss the SVN ability to get a subtree from a repo :) | 07:10 |
stekern | I'm slightly leaning towards making the main 'engine' being driven by the python unittest framework | 07:10 |
stekern | but that's just grand plans at the moment, I think making the 'native' subfolder Makefile driven is a good idea for the moment | 07:11 |
stekern | ... I just suck at writing Makefiles... | 07:12 |
stekern | how do I get all .c files from a list of mixed files in a variable called SOURCES? | 07:13 |
olofk_ | stekern: Use wildcard | 07:15 |
olofk_ | And yes. Makefile good to get shit done now. unittest probably nice longterm solution | 07:15 |
olofk_ | https://www.gnu.org/software/make/manual/html_node/Wildcard-Function.html | 07:16 |
stekern | ok... but how? CSOURCES = $(wildcard *.c $(SOURCES) does not work | 07:16 |
stekern | the problem I'm having is that I already have the list of files in $(SOURCES), not in some directory | 07:17 |
stekern | because 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) sure | 07:19 |
olofk_ | stekern: A static list for now perhaps? | 07:21 |
olofk_ | Does that work? | 07:21 |
stekern | you mean that I'd have seperate .ctests and .stests files? | 07:21 |
stekern | that'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 done | 07:24 |
stekern | well, 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 files | 07:28 |
stekern | no, Makefiles are nice | 07: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 else | 07:30 |
stekern | I think you want Makefiles to build the tests either way | 07: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 |
stekern | olofk_: we have the same schedule for mor1kx | 08:36 |
stekern | fwiw, Linux has that kind of release schedule too... | 08:37 |
stekern | the only difference is that we have a lot more mood swings ;) | 08:37 |
stekern | I think there'll be a mor1kx 2.0 release when the atomics fall in place | 08:39 |
blueCmd | \o/ atomics | 10:09 |
stekern | blueCmd: have you already added them to glibc? | 10:29 |
blueCmd | stekern: the instructions? | 10:32 |
blueCmd | glibc uses syscalls | 10:32 |
stekern | that'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 |
stekern | dunno | 10:51 |
blueCmd | stekern: we have parts of xfce4 in or1k Debian now | 11:55 |
blueCmd | qemu doesn't do pthreads though so we're quickly running towards the hard wall where we cannot test stuff except on real hardware or or1ksim | 11:56 |
blueCmd | it would be nice to see how responsive stuff are on real hardware | 11:56 |
blueCmd | stekern: it would be nice if you could do a test on your dev kit | 11:57 |
blueCmd | we 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 HW | 11:57 |
stekern | (xfce) nice, that's my current favourite desktop | 11:58 |
stekern | right, my atlys board port | 11:58 |
stekern | it's done, so I should be able to test that | 11:59 |
stekern | I've got an attention span comparable to my 3-year old daughter... | 12:00 |
stekern | (weston) I never ran that, I think poke53281 did though | 12:04 |
stekern | https://www.ohloh.net/p/mor1kx/analyses/latest/languages_summary | 12:05 |
stekern | coq? | 12:05 |
olofk_ | Mind your language! | 12:07 |
stekern | =) | 12:07 |
stekern | you should watch the latest episode of Top Gear, they put their lips to a Black Co*k when they are in Thailand | 12:09 |
stekern | http://www.thailandunique.com/thai-black-cock-whiskey#.UyaBeQewock.reddit | 12:09 |
olofk_ | Linked from that page you can see who has most overall experience in coq | 12:27 |
olofk_ | I'm not very good myself. I suck at coq | 12:28 |
olofk_ | Maybee we should use coq instead of python for our test suite. I heard it's quite good at penetration testing | 12:30 |
stekern | lol | 12:31 |
stekern | https://www.ohloh.net/accounts/skristiansson <- I like how it says 'coq' right under my profile picture there ;) | 12:32 |
blueCmd | stekern: hahhaaa | 12:44 |
olofk_ | lol | 12:58 |
Limb | olofk, stekern: .bld: http://pastebin.com/RDyVGpzT ---- .twr: http://pastebin.com/Z1TcxYkp | 15:01 |
Limb | using this in the ucf: NET "sys_clk_pad_i" TNM_NET = sys_clk_pin; | 15:02 |
Limb | TIMESPEC TS_sys_clk_pin = PERIOD sys_clk_pin 100 MHz HIGH 50% | 15:02 |
stekern | hmm, I wonder why trce still doesn't find any constraints | 15:19 |
Limb | stekern: that would be because I copied them from the wrong build directory! -_- | 15:28 |
Limb | .bld: http://pastebin.com/JGGPdQgB --- .twr: http://pastebin.com/c24ZVep7 | 15:29 |
Limb | although that one says no constraints found either, hrmmm | 15:30 |
stekern | as a reference this is the 200 first lines of my .twr from the atlys board: http://pastie.org/9082470 | 15:45 |
stekern | olofk: seems like that default startup clk works for atlys | 15:49 |
Limb | well it appears I have to look into the clkgen because the primitive it uses is specific to spartan class chips | 15:59 |
poke53281 | blueCmd: To run weston you need libffi | 16:02 |
poke53281 | It's still very high on my list to finish the libffi port and send it to the maintainer | 16:03 |
poke53281 | so far this link will do it: https://github.com/s-macke/libffi | 16:04 |
Limb | stekern: I assigned the clocks directly to the inputs and it implemented the constraints... so I'll definitely have to look at the clkgen | 16:19 |
blueCmd | poke53281: yes, I have packaged that for my debian port | 16:32 |
blueCmd | poke53281: it does a stellar thing so far. some python packages invoke the skeleton functions, but other than that it keeps together just fine | 16:33 |
poke53281 | the libffi port is not complete. I stopped exactly at the point when weston started. | 16:47 |
poke53281 | Additional you need some special linux kernel options | 16:47 |
poke53281 | which are not available in menuconfig. | 16:47 |
blueCmd | poke53281: 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 soon | 16:48 |
poke53281 | But they compile fine. Just some messaging modules. Can't remember which one, but I can look up. | 16:48 |
poke53281 | Ok | 16:48 |
poke53281 | wait | 16:48 |
blueCmd | poke53281: I know it's not complete, but it's better than nothing and actually works quite well | 16:48 |
poke53281 | CONFIG_EPOLL=y | 16:50 |
poke53281 | CONFIG_SIGNALFD=y | 16:50 |
poke53281 | CONFIG_TIMERFD=y | 16:50 |
poke53281 | CONFIG_EVENTFD=y | 16:50 |
poke53281 | That should do it. | 16:51 |
blueCmd | thanks! | 16:51 |
stekern | blueCmd: I got my FSF letter back signed now | 16:53 |
blueCmd | stekern: sweet | 16:53 |
stekern | so, for my part, the paper turning exercise should be all done | 16:53 |
blueCmd | stekern: did you do GCC as well? | 16:54 |
blueCmd | otherwise, we're just getting started! :) | 16:54 |
stekern | yeah, well, no =) | 16:55 |
poke53281 | I 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 |
stekern | hmm, or1k-elf-gdb starts to eat up 16GB of memory every time I do: set $sr=1 | 19:19 |
olofk | ok. Making a FuseSoC 1.1 package now | 19:34 |
olofk | Yep. fusesoc 1.1 is released | 19:56 |
* juliusb applauds | 20:00 | |
juliusb | nice one olofk | 20:00 |
juliusb | I'll need to familiarise myself with this stuff, I'll write the next chiphack's tutorial for OpenRISC based on it | 20:01 |
juliusb | will need to familiarise myself with OpenRISC again, too. CPU architecture, right? | 20:02 |
juliusb | I hope you've finally got flexlm licensing for it | 20:03 |
juliusb | that was the one thing holding back ORPSoC, not enough restrictions on who could use it | 20:03 |
juliusb | I think we need a registration system which had a human in the loop to approve licenses we send out via email | 20:03 |
stekern | oh crap, either my atomic insns or wallentos lru stuff brakes mor1kx | 20:11 |
stekern | I think one human in the loop isn't enough, there should be at least 10 | 20:15 |
stekern | looks like it's the lru stuff | 20:20 |
stekern | 1-way caches still works... | 20:29 |
blueCmd | juliusb: hah, flexlm | 21:51 |
blueCmd | MS-PL and flexlm, I'll write a design document for that | 21:52 |
_franck_ | my NEEK board has now a beautiful openrisc powered pinguin: | 22:11 |
_franck_ | http://picpaste.com/pics/6036a97d12d68a117e4ad5771efb7140.1397599830.JPG | 22:11 |
blueCmd | _franck_: cool! | 22:12 |
blueCmd | _franck_: looks like a nice board | 22:13 |
_franck_ | it is. I only miss an USB host | 22:14 |
blueCmd | _franck_: http://storage.googleapis.com/bluecmd-openrisc/de0_orpsoc_asm.jpg like that? ;) | 22:27 |
* Limb is lost :( | 22:36 | |
--- Log closed Wed Apr 16 00:00:07 2014 |
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!