IRC logs for #openrisc Saturday, 2015-04-18

--- Log opened Sat Apr 18 00:00:12 2015
daliasstekern, any register i should prefer to use instead of r16? is r10 ok?01:16
stekerndalias: take r1404:20
daliasstekern, too late -- did r20 :)04:20
daliasthat was the first register gcc picked04:20
daliasso i figured it was a reasonable choice04:20
daliasbtw if you get a chance to run libc-test's setjmp test on or1k it would be helpful :)04:21
stekernyeah, r20 is fine04:27
stekerndalias: sure, I'll do that today at some point04:28
-!- yang_ is now known as ang09:01
-!- ang is now known as yang09:01
olofkDo we have any protection for jumps in delay slots?12:15
olofkHmm.. can't figure out what type of Intel Hex that objcopy uses12:38
olofkassumed it would be i32hex, but it might be some hybrid12:41
olofkFound a bug in a wikipedia article :)12:50
olofkAnd objcopy sucks12:52
olofkMaybe I should just give up. Transferring a Linux kernel in hex will take about 75 minutes according to my calculations12:58
olofkKernel size in hex 52MB, baud rate 115200 (bit rate ~11520kB/s)13:00
olofkor wait... is that 7.5 minutes?13:00
olofkI should get out more13:02
bandvigolofk: 52*1024*1024*8 / 115200 / 60 ~= 63 minutes13:08
bandvigethernet forever ^)13:21
jvm3487I'm having difficulty using the or1k-linux-musl- toolchain.  I wasn't sure if this was the best place to ask for help14:07
mor1kx[mor1kx] bandvig tagged fpu32_v1.1 at 0e8566c:^...70303fa0ddf216:50
mor1kxmor1kx/fpu32_v1.1 5687a92 bandvig: Initial port of OF32S from OpenRISC-1200...16:50
mor1kxmor1kx/fpu32_v1.1 67f0644 bandvig: Fix float to integer conversion...16:50
mor1kxmor1kx/fpu32_v1.1 2d6af6c bandvig: Local list of mor1kx modules16:50
mor1kx[mor1kx] bandvig deleted fpu32_v2.0 at 8b75fa8:
stekernjvm3487: what's the problem?17:00
jvm3487so i'm able to boot the linux kernel on the atlys board using the or1k-elf- toolchain, but when I try to run something more complicated than a simple hello world with the or1k-linux-musl- toolchain, I get error a bus error or a signal 7 from linux17:32
jvm3487i'm not sure if this is a problem with my kernel build or some option I need to enable when compiling with the toolchain17:33
jvm3487i've also gotten an error mallocing memory in a similar context, so it might have something to do with the heap?17:36
jvm3487I was hoping for some insight on what the problem could possibly be because I'm not really sure where to start17:38
mor1kx[mor1kx] bandvig tagged fpu31_v1.1 at 83cf765:^...6bb10079887917:38
mor1kxmor1kx/fpu31_v1.1 5687a92 bandvig: Initial port of OF32S from OpenRISC-1200...17:38
mor1kxmor1kx/fpu31_v1.1 67f0644 bandvig: Fix float to integer conversion...17:38
mor1kxmor1kx/fpu31_v1.1 2d6af6c bandvig: Local list of mor1kx modules17:38
stekernjvm3487: does it work in or1ksim?19:34
stekerndalias: no problems with the setjmp test19:36
stekernbut there are a bunch of other tests that are failing19:36
olofkbandvig: Yeah. Ethernet is a hell of a lot better. Just figured that UARTs are more common than ethernet of19:42
olofkon dev boards19:42
olofkBut if _franck_ can get a tiny tftp loader working that would probably be the best solution for most cases19:42
bandvigolofk: As far as I understand a JTAG often uses proprietary protocols and any case it isn't much faster than UART. Am I right?19:55
jvm3487stekern: yes it works in or1ksim19:57
daliasstekern, which ones? the math ones are expected19:57
daliasi can show you the other expected failures19:58
stekerndalias: that would help. here's the list of fails:
daliasquick summary on i386:
daliasthe math fails vary between systems20:07
daliasthe rest are expected (known bugs)20:07
daliasmalloc-brk-fail-static.exe isn't really a bug, just lack of strategy for getting the most possible memory under near-oom situations when static linked20:07
stekernyeah, I remember that since last I ran the tests20:08
daliasthe snprintf/swprintf fails look like either outdated libc-test or outdated libc20:08
daliasthere was a bug that was fixed a while back where the test also expected the wrong result20:09
daliascrypt test just failed because your or1k is too slow :-p20:09
daliassame for sscanf_long20:09
stekernyes, the timed out ones can be ingnored20:09
daliasodd that strtol-static failed but not dynamic20:09
stekernI've successfully ran them with longer time outs before20:10
daliasactually those other failures were for static too20:10
daliasmaybe you don't have libc.a up-to-date20:10
daliasyeah it looks like you've got an old libc.a that's being linked to20:10
daliasbecause all the failures i'm seeing are static-only20:10
daliasso everything else looks ok20:13
stekernnicely spotted, I'll check that20:13
stekernthe libc.a that I *think* I'm linking against is up to date though20:15
daliasmaybe you have a -L path in config.mak for libc-test?20:19
daliasi often do that to test against an uninstalled version or something20:19
olofkbandvig: JTAG by itself is a standard protocol, but for some of the FPGA dev boards, they tunnel the JTAG protocol inside a proprietary protocol20:22
stekernmy libc-test should be pretty vanilla, the only diff I have is that I don't run the tests, just (cross-)compile them20:23
olofkbandvig: So if you get a JTAG adapter that is supported by OpenOCD you should be fine20:24
daliasstekern, do you have a good procedure for cross-compiling the tests on one system and deferring running them to the target system?20:25
daliasthis is something i've been wanting20:25
olofkI can't say that I really understand JTAG. Always felt that it's so complicated that I'm surprised it works at all20:25
daliasfor casual regression testing i use binfmt_misc and qemu :-p20:25
olofkI've pushed my work-in-progress IP-Xact experiments to github btw, if someone wants to play around with Kactus2 and IP-Xact20:27
olofkI'm curious to know if they work in Vivado. Vivado claims to be IP-Xact compatible at least20:27
stekerndalias: don't know about "good", but I just copy the compiled tests to the target system and run this:
stekernand this is the change to the Makefile:
daliasah :/20:33
daliasi was looking for a way to do it declaratively with the makefile20:33
daliasjust request all build (exes) but not runs (errs)20:33
daliasthen move the tree to the target to run make again for the errs20:33
stekernok, I found the error, the wrong libc.a indeed got linked20:41
stekernnow it looks a lot better, with the time outs and the expected failures filtered out, this is what's left:
jvm3487does or1k-linux-musl-gcc compile any instructions that or1200 does not implement?20:57
stekernjvm3487: yes, it uses the atomic instructions20:57
stekernbut this kernel should have emulation for it:
stekernor rather, *musl* use the atomic instructions20:59
olofkjvm3487: We generally recommend people to switch from or1200 to mor1kx nowadays as mor1kx is the one we are working on and thus is best supported21:02
olofkwe = stekern and bandvig at the moment :)21:02
stekernand wallento21:07
olofkah. sorry21:07
jvm3487sketern: ok, i had been using this kernel since it was already ported to the atlys board  Do you know if it is as easy as copying the configuration files over to the other one?21:08
jvm3487olofk: yeah I guess I didn't realize that.  I am finishing up a project on modifying the or1200 core for school, but I will remember that for the future21:09
stekernI think that should work without too much pain21:09
olofkIf someone has an atlys defconfig and dts it would be great to have them added to orpsoc-cores21:10
olofkjvm3487: Yeah. We have not been that good at advertising mor1kx, so it seems plenty of people have missed that21:10
jvm3487stekern: thanks for your help. I'll give that a shot early next week and see how it goes21:14
jvm3487olofk: I took the ones from that linux port for atlys and modified them based on
stekernignorance admittance, is f_files in the statvfs struct expected to be 0 when done on a NFS mount?21:19
olofkjvm3487: Interesting. Haven't seen that blog before21:31
olofkSome things are sadly outdated in that blog post though21:32
olofkThat's all for tonight. Good night21:33
--- Log closed Sun Apr 19 00:00:13 2015

Generated by 2.15.2 by Marius Gedminas - find it at!