IRC logs for #openrisc Wednesday, 2014-05-07

--- Log opened Wed May 07 00:00:37 2014
stekernI decided to push my proof-of-concept work on or1k-tests:
stekerncurrently it just contains the old mor1kx-devenv tests and let you define the tests you want to build in a plain textfile06:11
olofkstekern: Reading the backlog, I take it as the FuseSoC Vivado backend is covered now? ;)08:21
olofkAnd good job with getting the or1k-tests effort started08:27
olofkI'll test and see if I find anything to complain about :)08:28
stekernand killing atlys/ISE bugs? ;)08:28
stekern(or1k-tests) I've tried running mor1kx-generic against it, but iirc some tests failed08:28
stekernthe ones that are using the 'intgen' are of course easy to explain, don't know if there are others08:29
olofkThe orpsocv2 memory layout caused me some headaches when I run the orpsocv2 tests in fusesoc a year ago08:29
olofkAnd the mult test is insanely slow in an event sim08:30
stekernI 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
olofkYes. That's a goos thing so that mor1kx-devenv can be retired08:31
stekern(vivado) nah, not yet... I got so exhausted by the installing the license file...08:33
stekern-1 the08:33
stekernI'll give it a try when my parallella board arrives08:33
olofkSame here. They tried to deliver it this monday, but I was away. Grr...08:36
stekernoh, right... it's DHL, the most insane delivery company in the world08:37
olofktest suite finished now with or1200-generic. Got timeout on sfbf, tickrfforward and timer (with --timeout=1000000000). Haven't checked which ones fail yet08:40
stekernmy package is in Finland at least now, maybe it'll be delivered today then08:41
stekernhopefully our au pair is at home when they come08:42
stekerndriving out to the airport to pick up DHL packages is no fun...08:43
olofk23 tests ok, 7 fails and 11 that needs to be investigated a bit more08:46
stekernolofk: do you have some fancy stuff to iterate through the tests?08:53
stekernI only have this very sophisticated script:
stekernwhich doesn't even catch the failure, since fusesoc doesn't return the error code of the simulation08:55
olofkYours is slightly more sophisticated than mine :)08:56
olofkfor f in ../or1k-tests/native/build/or1k/or1k-*; do python ../fusesoc/bin/ sim or1200-generic --elf-load=$f --timeout=1000000000;done > results.txt08:56
stekernhehe, and here I was hoping for the reverse08:56
olofkIt would be nice to have something to parse the output and check for pass and fails08:58
olofkThen we could generate fancy HTML reports08:58
stekernor1ksim uses expect for that08:58
olofkah right08:59
stekernI think it'd make more sense to somehow integrate the python unittest framework into fusesoc and use that08:59
olofkI would rather have or1k-tests invoke FuseSoC than adding those features diretly to FuseSoC09:00
stekernyes, I (almost) agree09:01
stekernI don't think it's even a good idea to make or1k-tests depend on FuseSoC09:02
stekernbut, what I'm imagining in fusesoc, would be some kind of backend for the unittest framework09:03
stekerncompletely unrelated to or1k-tests09:03
stekern...but that could be utilised when running the tests in or1k-tests09:03
olofkWhat the hell are you talking about? ;)09:04
stekernumm, what's unclear? ;)09:04
olofkthe connection to unittest. Slash me feels stupid09:05
olofkOh, 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 printing09:07
olofkvlog_tb_utils could for example use it to choose a slightly more sexy name of the VCD dump09:08
stekernI 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 python09:10
olofkSo 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
olofkNote that I'm a master of misunderstanding :)09:14
stekern(it's not uncommon to drive tests that are *not* written in python with unittest btw)09:16
stekernin 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 there09:22
stekern$run_command I mean09:22
stekern...then I saw something shiny behind a rock and got completely distracted09:24
olofkI know the feeling09:27
stekernanyway, fusesoc should return the exit code of the simulation, agree?09:54
olofkNot sure if that's any useful. I have read a bit about that and in neither VHDL nor verilog has a standard for exit codes09:57
olofkSo simulators will probably report different things09:58
olofkNext VHDL revision will actually set aside a range of exit codes to use for these kind of things09:58
stekernanyway, fusesoc should return the exit code of the verilator simulations, agree?09:58
olofkYES! :)09:58
olofkAnd 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 ok09:59
stekernyeah, I see09:59
stekernwe print the exit(code) in our native tests anyway, so it's not a huge deal10:00
olofkblueCmd, 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 repo10:51
olofkOh.. and if we have any get-started guide that would be great as well10:51
stekernolofk: the list of packages seems to be reverse avalanching, but the latest number I heard was ~500010:52
olofkThen I'll quickly grab that number :)10:53
stekernI think there's a more exact number on the wannabuild site10:54
stekernand the get-started guide:
olofkAny noteworthy packages for a layman? I've written X server so far10:54
stekernapache (but it doesn't work)10:55
olofkHow about WMs? Fluxbox, xfce, lxde?10:55
stekernfluxbox I know (and it works), xfce I think10:56
stekernlxde, no idea10:56
stekernI think qt was somewhat working10:58
mohessaidhello with linker problems I don't get it but I am not well with linkers.:)11:10
mohessaidthis is my problem:
stekernyes, as it stands right now, it's not possible to build linux with the or1k-linux-* toolchain, only with the or1k-elf-* one11:14
stekernmohessaid: yes, as it stands right now, it's not possible to build linux with the or1k-linux-* toolchain, only with the or1k-elf-* one11:24
mohessaidbut I did it with a configuration file from blueCmd repository with some additions on it?11:26
mohessaidthere 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 files11:28
mohessaidjust 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
olofkmohessaid: Yes, that should work. Build linux with the or1k-elf-* toolchain, and then build your programs for linux with the or1k-linux-* toolchains11:32
stekern"but I did it with a configuration file" <- it being?11:35
stekernno, the sentence "but I did yes with a configuration file", doesn't make any sense at all ;)11:37
mohessaidhhhh, it = building linux with or1k-linux-gnu- as value to CROSS_COMPILE= but in the .config file directly and then write make in the terminal11:39
stekernyeah, no, that doesn't work11:39
mohessaidusing this method? the configuration file11:39
stekernusing or1k-linux-* toolchain to build the kernel11:40
stekernthe problem is that our Linux port links in libgcc, and the or1k-linux-* toolchains compiles that with -fPIC11:40
stekernafaik 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 -fPIC11:43
mohessaidor1k-elf you mean the newlib toolchain11:44
mohessaidI have this toolchaint too :) I builded all of them, I will give it a try, thank you for all this time.11:46
stekernactually, for 3) I think reverting the change that added the comments here should do it.
stekernthat will break no-delay configs though12:05
_franck__for 2) we "just" need to add modsi3, umodsi3, divsi3 and udivsi3 as we already have some of the missing functions here:;a=tree;f=arch/openrisc/lib;h=d56c7eb9ff53693242257cc0f20a33051792aab9;hb=HEAD12:07
stekernyes, and I think Jonas had some local changes where he's done that. but they haven't been applied anywhere...12:09
stekernfixing this to be compatible with no-delay shouldn't be hard neither:
stekernI think I'll do that right away12:24
wallentohi 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:
olofkHmm... do I have to fork a repo in github to make a pull request?18:40
stekernI think so...18:45
olofkNo big deal anyway. I will probably push more so having a fork will come in handy18:46
olofkSo... commit rules for or1k-tests? Whaddayasay?18:46
stekernyes, commits to or1k-tests rules!18:48
amsolofk: you can do a shallowo clone if bandwidth is scares18:48
olofkams: 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
amsstekern: no no, i strongly disagree...18:50
amsdrink BEER first, then commit.18:50
amsand 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
stekernok, but that is bound to be followed by 'ask for forgiveness'18:51
amsit is the future of sotware!18:51
stekernso, 'drink beer, commit, ask forgiveness'18:51
olofkcaptcha is a good idea. It could check for correct spelling of words like shallow, scarse and software :P18:52
olofkPushing a branch to a remote repo is
stekerngit push reomte_repo local_branch:remote_branch18:53
olofkremote_repo = origin?18:54
stekernnja... it can be whatever repo18:54
olofkorigin worked fine18:55
olofkI might have sent a pull request now18:55
stekernwell, if you wanted to push to origin, yes then that works fine ;)18:56
stekernthat wasn't clear by your question18:56
olofkAhh... 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
olofkIs origin like an alias?18:56
stekernno, it's 'one' of your remotes18:56
olofk(I suspect I'm missing some git nomenclature here)18:56
stekernsometimes the only one18:56
stekernyou can list your remotes with 'git remote -v'18:57
olofkah ok. Interesting18:57
olofkSeems like I can set it up to fetch and push to different repos by default18:58
stekernand add new ones with 'git remote add olofk'18:58
olofkIn this case, that's the only one I have :)18:59
stekernah, ok18:59
stekernso, 'git remote add openrisc' then ;)18:59
olofkI've mostly been on the receiving side of this git pushing nonsense :)18:59
olofkSo now I can do git push openrisc?19:00
stekernand then back to the original question: 'git push openrisc master'19:00
olofkah cool19:00
stekernas I said, 'git push remote_repo local_branch:remote_branch' is the canonical command for push, everything else is just shorthand19:01
stekernwhich 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:master19:03
olofkSlowly learning this19:04
olofkThat or1k-tests maintainer is so slooooow. He hasn't responded to my pull request yet19:05
stekern...and knowing *that*, makes the command for deleting a remote branch a lot more sense: git push remote_repo :branch_to_delete19:06
stekern(there's some syntactic sugar for that nowdays, but I can never remember that=19:06
stekernmaintainer for or1k-tests? would that be me? how did that happen?19:07
stekernI just drank beer, committed and looked around for someone to give forgiveness to :(19:08
olofkDamn. I knew being sober was a bad idea19:17
olofkYeah, I think we should try to avoid this pull request overhead and just push stuff as long as we know what we're doing19:18
stekernI'd say when forcing 1-year olds to drink penicillin is on the agenda, being sober is a pre-requisite ;)19:19
olofkalias 'man git'='wget -O -'19:21
stekernyay, I just built a kernel with a or1k-linux-* toolchain19:26
olofkThat's cool!19:27
olofkDoes it work? :)19:27
stekernlet's see =)19:27
stekernit's only a handful mul/div functions that should differ, so if it doesn't, it should be easy to track down19:28
stekernboots fine at least19:35
stekernblueCmd: you might want to cherry-pick this into your debian gcc:
stekernthen we can try to build a kernel natively ;)20:00
olofkI'm getting very weird results on or1k-lsu in or1200-generic20:34
olofkShould really 0xdeadbeef divided by 0xdeadbeef be 0xcb04603d ?20:36
olofkMy instinct as well as the testcase thinks that the result should be 120:37
stekernbah... my arlys 'fix' broke more than it fixed..20:41
stekernolofk: do you have a hard div enabled in or1200-generic?20:51
olofkehhmm... mor1kx-generic doesn't start at all for me20:51
olofkYes. At least I have the div instruction define set20: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
olofkcrap. Stupid cache20: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
stekernthe 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
stekernI picked the l.div, since that's the slowest alu instruction we have20:56
olofkI'm adding some nops to see if things changes20:56
olofkThere 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 instruction20:57
stekernhuh... my fixes to atlys actually do work in openrisc/orpsoc-cores, but they break stuff in my local branch...21:06
olofkHave you cleaned the cache? :)21:08
stekernheh.. got to be something else21:11
olofkyep. or1200 serial divider is broken21:13
olofkTested with both modelsim and icarus21:14
olofkI like this test suite already :)21:16
--- Log closed Thu May 08 00:00:39 2014

Generated by 2.15.2 by Marius Gedminas - find it at!