| --- Log opened Wed May 07 00:00:37 2014 | ||
| stekern | I decided to push my proof-of-concept work on or1k-tests: https://github.com/openrisc/or1k-tests/commit/a5ebc2c1802695a0e5b8e0980deeab67f84c4d4f | 06:11 |
|---|---|---|
| stekern | currently it just contains the old mor1kx-devenv tests and let you define the tests you want to build in a plain textfile | 06:11 |
| olofk | stekern: Reading the backlog, I take it as the FuseSoC Vivado backend is covered now? ;) | 08:21 |
| olofk | And good job with getting the or1k-tests effort started | 08:27 |
| olofk | I'll test and see if I find anything to complain about :) | 08:28 |
| stekern | and killing atlys/ISE bugs? ;) | 08:28 |
| stekern | (or1k-tests) I've tried running mor1kx-generic against it, but iirc some tests failed | 08:28 |
| stekern | the ones that are using the 'intgen' are of course easy to explain, don't know if there are others | 08:29 |
| olofk | The orpsocv2 memory layout caused me some headaches when I run the orpsocv2 tests in fusesoc a year ago | 08:29 |
| olofk | And the mult test is insanely slow in an event sim | 08:30 |
| stekern | yeah | 08:30 |
| stekern | I think most of my effort was concentrated on just pulling the tests out of mor1kx-devenv and be able to build them 'standalone' | 08:31 |
| olofk | Yes. That's a goos thing so that mor1kx-devenv can be retired | 08:31 |
| olofk | s/s/d | 08:31 |
| stekern | (vivado) nah, not yet... I got so exhausted by the installing the license file... | 08:33 |
| stekern | -1 the | 08:33 |
| stekern | I'll give it a try when my parallella board arrives | 08:33 |
| olofk | Same here. They tried to deliver it this monday, but I was away. Grr... | 08:36 |
| stekern | oh, right... it's DHL, the most insane delivery company in the world | 08:37 |
| olofk | test suite finished now with or1200-generic. Got timeout on sfbf, tickrfforward and timer (with --timeout=1000000000). Haven't checked which ones fail yet | 08:40 |
| stekern | my package is in Finland at least now, maybe it'll be delivered today then | 08:41 |
| stekern | hopefully our au pair is at home when they come | 08:42 |
| stekern | driving out to the airport to pick up DHL packages is no fun... | 08:43 |
| olofk | 23 tests ok, 7 fails and 11 that needs to be investigated a bit more | 08:46 |
| stekern | olofk: do you have some fancy stuff to iterate through the tests? | 08:53 |
| stekern | I only have this very sophisticated script: http://pastie.org/9148258 | 08:54 |
| stekern | which doesn't even catch the failure, since fusesoc doesn't return the error code of the simulation | 08:55 |
| olofk | Yours is slightly more sophisticated than mine :) | 08:56 |
| olofk | for f in ../or1k-tests/native/build/or1k/or1k-*; do python ../fusesoc/bin/fusesoc.in sim or1200-generic --elf-load=$f --timeout=1000000000;done > results.txt | 08:56 |
| stekern | hehe, and here I was hoping for the reverse | 08:56 |
| olofk | It would be nice to have something to parse the output and check for pass and fails | 08:58 |
| olofk | Then we could generate fancy HTML reports | 08:58 |
| stekern | or1ksim uses expect for that | 08:58 |
| olofk | ah right | 08:59 |
| stekern | I think it'd make more sense to somehow integrate the python unittest framework into fusesoc and use that | 08:59 |
| olofk | I would rather have or1k-tests invoke FuseSoC than adding those features diretly to FuseSoC | 09:00 |
| stekern | yes, I (almost) agree | 09:01 |
| stekern | I don't think it's even a good idea to make or1k-tests depend on FuseSoC | 09:02 |
| stekern | but, what I'm imagining in fusesoc, would be some kind of backend for the unittest framework | 09:03 |
| stekern | completely unrelated to or1k-tests | 09:03 |
| stekern | ...but that could be utilised when running the tests in or1k-tests | 09:03 |
| olofk | What the hell are you talking about? ;) | 09:04 |
| stekern | umm, what's unclear? ;) | 09:04 |
| olofk | the connection to unittest. Slash me feels stupid | 09:05 |
| olofk | Oh, slightly related. I've been meaning to add a reserved command line parameter called testcase that will be translated into a plusarg, generic which the test bench can look for and use for things like filenames and printing | 09:07 |
| olofk | vlog_tb_utils could for example use it to choose a slightly more sexy name of the VCD dump | 09:08 |
| stekern | I don't have anything well thought out, just thinking that it could be nice to have a more lightweight interface to unittest than writing testcases in python | 09:10 |
| olofk | So you want (somehow) to use unittest infrastructure to run test cases, since you get a lot of things for free, but use the c/asm tests instead of python? | 09:14 |
| olofk | Note that I'm a master of misunderstanding :) | 09:14 |
| stekern | yes | 09:15 |
| stekern | (it's not uncommon to drive tests that are *not* written in python with unittest btw) | 09:16 |
| stekern | in my high level imaginary implementation it could be something in line with: "do this *give list of things to do*" and "check that it outputs *give list of things to expect*" | 09:19 |
| stekern | ...but actually, I think my original idea with or1k-tests was to have a $build_command variable and do all that stuff in there | 09:22 |
| stekern | $run_command I mean | 09:22 |
| stekern | ...then I saw something shiny behind a rock and got completely distracted | 09:24 |
| olofk | haha | 09:27 |
| olofk | I know the feeling | 09:27 |
| stekern | anyway, fusesoc should return the exit code of the simulation, agree? | 09:54 |
| olofk | Not sure if that's any useful. I have read a bit about that and in neither VHDL nor verilog has a standard for exit codes | 09:57 |
| olofk | So simulators will probably report different things | 09:58 |
| stekern | ok... | 09:58 |
| olofk | Next VHDL revision will actually set aside a range of exit codes to use for these kind of things | 09:58 |
| stekern | anyway, fusesoc should return the exit code of the verilator simulations, agree? | 09:58 |
| olofk | YES! :) | 09:58 |
| stekern | =) | 09:58 |
| olofk | And it should probably return the exit codes for the other sims too. It's just that we can't use it to determine if the test went ok | 09:59 |
| stekern | yeah, I see | 09:59 |
| stekern | we print the exit(code) in our native tests anyway, so it's not a huge deal | 10:00 |
| olofk | blueCmd, stekern: I'm writing some lines about the OpenRISC debian ports. Can you give me some mind blowing figures, like the amount of packages in the repo | 10:51 |
| olofk | Oh.. and if we have any get-started guide that would be great as well | 10:51 |
| stekern | olofk: the list of packages seems to be reverse avalanching, but the latest number I heard was ~5000 | 10:52 |
| olofk | Then I'll quickly grab that number :) | 10:53 |
| stekern | I think there's a more exact number on the wannabuild site | 10:54 |
| stekern | and the get-started guide: https://github.com/bluecmd/or1k-debian | 10:54 |
| olofk | Any noteworthy packages for a layman? I've written X server so far | 10:54 |
| olofk | thanks | 10:55 |
| stekern | scummvm! | 10:55 |
| stekern | ;) | 10:55 |
| stekern | irssi | 10:55 |
| olofk | Hurray! | 10:55 |
| stekern | apache (but it doesn't work) | 10:55 |
| olofk | How about WMs? Fluxbox, xfce, lxde? | 10:55 |
| stekern | fluxbox I know (and it works), xfce I think | 10:56 |
| stekern | lxde, no idea | 10:56 |
| stekern | I think qt was somewhat working | 10:58 |
| mohessaid | hello with linker problems I don't get it but I am not well with linkers.:) | 11:10 |
| mohessaid | this is my problem: http://goo.gl/mjAtcN | 11:11 |
| stekern | yes, as it stands right now, it's not possible to build linux with the or1k-linux-* toolchain, only with the or1k-elf-* one | 11:14 |
| stekern | mohessaid: yes, as it stands right now, it's not possible to build linux with the or1k-linux-* toolchain, only with the or1k-elf-* one | 11:24 |
| mohessaid | but I did it with a configuration file from blueCmd repository with some additions on it? | 11:26 |
| mohessaid | there is a message in producing vmlinux in both toolchains that begin with or1k (uClibc and glibc) about efl32-or32 not such ...... I don't know but we can fix this by replacing or32 with or1k in vmlinux.dts files | 11:28 |
| mohessaid | just a question if I build a program with glibc toolchains, and the put in linux and build linux with another toolchain well the program work in it? | 11:30 |
| olofk | mohessaid: Yes, that should work. Build linux with the or1k-elf-* toolchain, and then build your programs for linux with the or1k-linux-* toolchains | 11:32 |
| stekern | "but I did it with a configuration file" <- it being? | 11:35 |
| mohessaid | yes | 11:35 |
| stekern | no, the sentence "but I did yes with a configuration file", doesn't make any sense at all ;) | 11:37 |
| mohessaid | hhhh, it = building linux with or1k-linux-gnu- as value to CROSS_COMPILE= but in the .config file directly and then write make in the terminal | 11:39 |
| stekern | yeah, no, that doesn't work | 11:39 |
| mohessaid | using this method? the configuration file | 11:39 |
| stekern | using or1k-linux-* toolchain to build the kernel | 11:40 |
| stekern | the problem is that our Linux port links in libgcc, and the or1k-linux-* toolchains compiles that with -fPIC | 11:40 |
| stekern | afaik there are 3 ways around the problem: 1) use or1k-elf-* toolchain to compile the kernel 2) remove the dependency on libgcc in the kernel 3) make sure that there are no references to .got in libgcc, even when compiled with -fPIC | 11:43 |
| mohessaid | or1k-elf you mean the newlib toolchain | 11:44 |
| stekern | yes | 11:45 |
| mohessaid | I have this toolchaint too :) I builded all of them, I will give it a try, thank you for all this time. | 11:46 |
| stekern | actually, for 3) I think reverting the change that added the comments here should do it. https://github.com/openrisc/or1k-gcc/blob/or1k/libgcc/config/or1k/t-or1k#L22 | 12:05 |
| stekern | that will break no-delay configs though | 12:05 |
| _franck__ | for 2) we "just" need to add modsi3, umodsi3, divsi3 and udivsi3 as we already have some of the missing functions here: http://git.pengutronix.de/?p=barebox.git;a=tree;f=arch/openrisc/lib;h=d56c7eb9ff53693242257cc0f20a33051792aab9;hb=HEAD | 12:07 |
| stekern | yes, and I think Jonas had some local changes where he's done that. but they haven't been applied anywhere... | 12:09 |
| stekern | fixing this to be compatible with no-delay shouldn't be hard neither: https://github.com/openrisc/or1k-gcc/blob/or1k/libgcc/config/or1k/or1k.S | 12:18 |
| stekern | I think I'll do that right away | 12:24 |
| wallento | hi all, I have a tutorial in our lecture "Chip Multicore Processors" today where I explain C runtime in general and for multicore, with example newlib for OpenRISC. Here are the slides: http://lis.ei.tum.de/pub-download/CMP_Tutorial04.pdf | 13:14 |
| olofk | Hmm... do I have to fork a repo in github to make a pull request? | 18:40 |
| stekern | I think so... | 18:45 |
| olofk | No big deal anyway. I will probably push more so having a fork will come in handy | 18:46 |
| olofk | So... commit rules for or1k-tests? Whaddayasay? | 18:46 |
| stekern | yes, commits to or1k-tests rules! | 18:48 |
| ams | YES! | 18:48 |
| ams | olofk: you can do a shallowo clone if bandwidth is scares | 18:48 |
| olofk | ams: ah.. yes. That's a good idea. In this case though, the shallow clone = the full clone since it's only one commit :) | 18:49 |
| stekern | ...more seriously, let's have a 'commit first ask for forgiveness later' approach to that, at least until it's actually usable ;) | 18:50 |
| ams | stekern: no no, i strongly disagree... | 18:50 |
| ams | drink BEER first, then commit. | 18:50 |
| ams | and i think it should be in the rule, wiith one of those .. captcha? whatever thingies ... to check for soberness ... and if you are sober, you cannot commit! | 18:51 |
| stekern | ok, but that is bound to be followed by 'ask for forgiveness' | 18:51 |
| ams | it is the future of sotware! | 18:51 |
| stekern | so, 'drink beer, commit, ask forgiveness' | 18:51 |
| olofk | captcha is a good idea. It could check for correct spelling of words like shallow, scarse and software :P | 18:52 |
| olofk | Pushing a branch to a remote repo is done...how? | 18:53 |
| stekern | git push reomte_repo local_branch:remote_branch | 18:53 |
| olofk | remote_repo = origin? | 18:54 |
| stekern | nja... it can be whatever repo | 18:54 |
| olofk | origin worked fine | 18:55 |
| olofk | I might have sent a pull request now | 18:55 |
| stekern | well, if you wanted to push to origin, yes then that works fine ;) | 18:56 |
| stekern | that wasn't clear by your question | 18:56 |
| olofk | Ahh... only 15 minutes until I have to wake my 1 year old up to force her to drink penicillin. Best part of the day! | 18:56 |
| olofk | Is origin like an alias? | 18:56 |
| stekern | no, it's 'one' of your remotes | 18:56 |
| olofk | (I suspect I'm missing some git nomenclature here) | 18:56 |
| stekern | sometimes the only one | 18:56 |
| stekern | you can list your remotes with 'git remote -v' | 18:57 |
| olofk | ah ok. Interesting | 18:57 |
| olofk | Seems like I can set it up to fetch and push to different repos by default | 18:58 |
| stekern | and add new ones with 'git remote add olofk https://github.com/olofk/or1k-tests' | 18:58 |
| olofk | In this case, that's the only one I have :) | 18:59 |
| stekern | ah, ok | 18:59 |
| stekern | so, 'git remote add openrisc https://github.com/openrisc/or1k-tests' then ;) | 18:59 |
| olofk | I've mostly been on the receiving side of this git pushing nonsense :) | 18:59 |
| olofk | So now I can do git push openrisc? | 19:00 |
| stekern | and then back to the original question: 'git push openrisc master' | 19:00 |
| olofk | ah cool | 19:00 |
| stekern | as I said, 'git push remote_repo local_branch:remote_branch' is the canonical command for push, everything else is just shorthand | 19:01 |
| stekern | which means that if you are working on a branch (let's say 'stuff'), you can push that directly to the master branch of openrisc by: git push openrisc stuff:master | 19:03 |
| olofk | Slowly learning this | 19:04 |
| olofk | That or1k-tests maintainer is so slooooow. He hasn't responded to my pull request yet | 19:05 |
| stekern | ...and knowing *that*, makes the command for deleting a remote branch a lot more sense: git push remote_repo :branch_to_delete | 19:06 |
| stekern | (there's some syntactic sugar for that nowdays, but I can never remember that= | 19:06 |
| stekern | maintainer for or1k-tests? would that be me? how did that happen? | 19:07 |
| stekern | I just drank beer, committed and looked around for someone to give forgiveness to :( | 19:08 |
| olofk | Damn. I knew being sober was a bad idea | 19:17 |
| olofk | Yeah, I think we should try to avoid this pull request overhead and just push stuff as long as we know what we're doing | 19:18 |
| stekern | I'd say when forcing 1-year olds to drink penicillin is on the agenda, being sober is a pre-requisite ;) | 19:19 |
| olofk | alias 'man git'='wget http://www.juliusbaxter.net/openrisc-irc/search?q=git -O -' | 19:21 |
| stekern | yay, I just built a kernel with a or1k-linux-* toolchain | 19:26 |
| olofk | That's cool! | 19:27 |
| olofk | Does it work? :) | 19:27 |
| stekern | let's see =) | 19:27 |
| stekern | it's only a handful mul/div functions that should differ, so if it doesn't, it should be easy to track down | 19:28 |
| stekern | boots fine at least | 19:35 |
| stekern | blueCmd: you might want to cherry-pick this into your debian gcc: https://github.com/openrisc/or1k-gcc/commit/bdd3ad496930c61218ea683b9fd3dbcc093b9a14 | 19:59 |
| stekern | then we can try to build a kernel natively ;) | 20:00 |
| olofk | stekern: http://6c09e837da52e7d8.paste.se/ | 20:20 |
| olofk | I'm getting very weird results on or1k-lsu in or1200-generic | 20:34 |
| olofk | Should really 0xdeadbeef divided by 0xdeadbeef be 0xcb04603d ? | 20:36 |
| olofk | My instinct as well as the testcase thinks that the result should be 1 | 20:37 |
| stekern | bah... my arlys 'fix' broke more than it fixed.. | 20:41 |
| stekern | atlys | 20:41 |
| stekern | olofk: do you have a hard div enabled in or1200-generic? | 20:51 |
| olofk | ehhmm... mor1kx-generic doesn't start at all for me | 20:51 |
| olofk | Yes. At least I have the div instruction define set | 20:52 |
| stekern | k | 20:52 |
| stekern | (mor1kx-generic) did you flush the .cache to pull in the fixes to mor1kx for that? | 20:53 |
| stekern | (or1k-lsu) maybe the testcase actually exposes a bug in or1200 then ;) | 20:54 |
| olofk | crap. Stupid cache | 20:54 |
| olofk | (or1k-lsu) Yes. I'm actually thinking that might be the case since this was a test case written by you especially for mor1kx, right? | 20:55 |
| stekern | the point with the l.div there was to test the case in mor1kx where a load (in mem stage) is stalled by a div (from execute stage) | 20:55 |
| stekern | I picked the l.div, since that's the slowest alu instruction we have | 20:56 |
| olofk | I'm adding some nops to see if things changes | 20:56 |
| olofk | There was a weird thing as well before that. During one instruction, the value of r4 changed from 0xdeadbeef to 0xdead0000, but went back again after the next instruction | 20:57 |
| stekern | huh... my fixes to atlys actually do work in openrisc/orpsoc-cores, but they break stuff in my local branch... | 21:06 |
| olofk | Have you cleaned the cache? :) | 21:08 |
| stekern | heh.. got to be something else | 21:11 |
| olofk | yep. or1200 serial divider is broken | 21:13 |
| olofk | Tested with both modelsim and icarus | 21:14 |
| olofk | I like this test suite already :) | 21:16 |
| --- Log closed Thu May 08 00:00:39 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!