| --- Log opened Sat Apr 18 00:00:12 2015 | ||
| dalias | stekern, any register i should prefer to use instead of r16? is r10 ok? | 01:16 |
|---|---|---|
| stekern | dalias: take r14 | 04:20 |
| dalias | stekern, too late -- did r20 :) | 04:20 |
| dalias | that was the first register gcc picked | 04:20 |
| dalias | so i figured it was a reasonable choice | 04:20 |
| dalias | btw if you get a chance to run libc-test's setjmp test on or1k it would be helpful :) | 04:21 |
| stekern | yeah, r20 is fine | 04:27 |
| stekern | dalias: sure, I'll do that today at some point | 04:28 |
| -!- yang_ is now known as ang | 09:01 | |
| -!- ang is now known as yang | 09:01 | |
| olofk | Do we have any protection for jumps in delay slots? | 12:15 |
| olofk | Hmm.. can't figure out what type of Intel Hex that objcopy uses | 12:38 |
| olofk | assumed it would be i32hex, but it might be some hybrid | 12:41 |
| olofk | Found a bug in a wikipedia article :) | 12:50 |
| olofk | And objcopy sucks | 12:52 |
| olofk | Maybe I should just give up. Transferring a Linux kernel in hex will take about 75 minutes according to my calculations | 12:58 |
| olofk | Kernel size in hex 52MB, baud rate 115200 (bit rate ~11520kB/s) | 13:00 |
| olofk | or wait... is that 7.5 minutes? | 13:00 |
| olofk | I should get out more | 13:02 |
| bandvig | olofk: 52*1024*1024*8 / 115200 / 60 ~= 63 minutes | 13:08 |
| bandvig | ethernet forever ^) | 13:21 |
| jvm3487 | I'm having difficulty using the or1k-linux-musl- toolchain. I wasn't sure if this was the best place to ask for help | 14:07 |
| mor1kx | [mor1kx] bandvig tagged fpu32_v1.1 at 0e8566c: https://github.com/openrisc/mor1kx/compare/5687a92e4f35^...70303fa0ddf2 | 16:50 |
| mor1kx | mor1kx/fpu32_v1.1 5687a92 bandvig: Initial port of OF32S from OpenRISC-1200... | 16:50 |
| mor1kx | mor1kx/fpu32_v1.1 67f0644 bandvig: Fix float to integer conversion... | 16:50 |
| mor1kx | mor1kx/fpu32_v1.1 2d6af6c bandvig: Local list of mor1kx modules | 16:50 |
| mor1kx | [mor1kx] bandvig deleted fpu32_v2.0 at 8b75fa8: https://github.com/openrisc/mor1kx/commit/8b75fa8 | 17:00 |
| stekern | jvm3487: what's the problem? | 17:00 |
| jvm3487 | so 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 linux | 17:32 |
| jvm3487 | i'm not sure if this is a problem with my kernel build or some option I need to enable when compiling with the toolchain | 17:33 |
| jvm3487 | i've also gotten an error mallocing memory in a similar context, so it might have something to do with the heap? | 17:36 |
| jvm3487 | I was hoping for some insight on what the problem could possibly be because I'm not really sure where to start | 17:38 |
| mor1kx | [mor1kx] bandvig tagged fpu31_v1.1 at 83cf765: https://github.com/openrisc/mor1kx/compare/5687a92e4f35^...6bb100798879 | 17:38 |
| mor1kx | mor1kx/fpu31_v1.1 5687a92 bandvig: Initial port of OF32S from OpenRISC-1200... | 17:38 |
| mor1kx | mor1kx/fpu31_v1.1 67f0644 bandvig: Fix float to integer conversion... | 17:38 |
| mor1kx | mor1kx/fpu31_v1.1 2d6af6c bandvig: Local list of mor1kx modules | 17:38 |
| stekern | jvm3487: does it work in or1ksim? | 19:34 |
| stekern | dalias: no problems with the setjmp test | 19:36 |
| stekern | but there are a bunch of other tests that are failing | 19:36 |
| olofk | bandvig: Yeah. Ethernet is a hell of a lot better. Just figured that UARTs are more common than ethernet of | 19:42 |
| olofk | on dev boards | 19:42 |
| olofk | But if _franck_ can get a tiny tftp loader working that would probably be the best solution for most cases | 19:42 |
| bandvig | olofk: 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 |
| jvm3487 | stekern: yes it works in or1ksim | 19:57 |
| dalias | stekern, which ones? the math ones are expected | 19:57 |
| dalias | i can show you the other expected failures | 19:58 |
| stekern | dalias: that would help. here's the list of fails: http://pastie.org/10100373 | 20:02 |
| dalias | quick summary on i386: http://sprunge.us/HNAa | 20:06 |
| dalias | the math fails vary between systems | 20:07 |
| dalias | the rest are expected (known bugs) | 20:07 |
| dalias | malloc-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 linked | 20:07 |
| stekern | yeah, I remember that since last I ran the tests | 20:08 |
| dalias | the snprintf/swprintf fails look like either outdated libc-test or outdated libc | 20:08 |
| dalias | there was a bug that was fixed a while back where the test also expected the wrong result | 20:09 |
| dalias | crypt test just failed because your or1k is too slow :-p | 20:09 |
| dalias | same for sscanf_long | 20:09 |
| stekern | yes, the timed out ones can be ingnored | 20:09 |
| dalias | odd that strtol-static failed but not dynamic | 20:09 |
| stekern | I've successfully ran them with longer time outs before | 20:10 |
| dalias | actually those other failures were for static too | 20:10 |
| dalias | maybe you don't have libc.a up-to-date | 20:10 |
| dalias | yeah it looks like you've got an old libc.a that's being linked to | 20:10 |
| dalias | because all the failures i'm seeing are static-only | 20:10 |
| dalias | so everything else looks ok | 20:13 |
| stekern | nicely spotted, I'll check that | 20:13 |
| stekern | the libc.a that I *think* I'm linking against is up to date though | 20:15 |
| dalias | :-p | 20:19 |
| dalias | maybe you have a -L path in config.mak for libc-test? | 20:19 |
| dalias | i often do that to test against an uninstalled version or something | 20:19 |
| olofk | bandvig: JTAG by itself is a standard protocol, but for some of the FPGA dev boards, they tunnel the JTAG protocol inside a proprietary protocol | 20:22 |
| stekern | my libc-test should be pretty vanilla, the only diff I have is that I don't run the tests, just (cross-)compile them | 20:23 |
| olofk | bandvig: So if you get a JTAG adapter that is supported by OpenOCD you should be fine | 20:24 |
| dalias | stekern, do you have a good procedure for cross-compiling the tests on one system and deferring running them to the target system? | 20:25 |
| dalias | this is something i've been wanting | 20:25 |
| olofk | I can't say that I really understand JTAG. Always felt that it's so complicated that I'm surprised it works at all | 20:25 |
| dalias | for casual regression testing i use binfmt_misc and qemu :-p | 20:25 |
| olofk | I've pushed my work-in-progress IP-Xact experiments to github btw, if someone wants to play around with Kactus2 and IP-Xact | 20:27 |
| olofk | I'm curious to know if they work in Vivado. Vivado claims to be IP-Xact compatible at least | 20:27 |
| stekern | dalias: don't know about "good", but I just copy the compiled tests to the target system and run this: http://pastie.org/10100444 | 20:28 |
| stekern | and this is the change to the Makefile: http://pastie.org/10100446 | 20:29 |
| dalias | ah :/ | 20:33 |
| dalias | i was looking for a way to do it declaratively with the makefile | 20:33 |
| dalias | just request all build (exes) but not runs (errs) | 20:33 |
| dalias | then move the tree to the target to run make again for the errs | 20:33 |
| stekern | ok, I found the error, the wrong libc.a indeed got linked | 20:41 |
| dalias | :) | 20:42 |
| stekern | now it looks a lot better, with the time outs and the expected failures filtered out, this is what's left: http://pastie.org/10100468 | 20:48 |
| jvm3487 | does or1k-linux-musl-gcc compile any instructions that or1200 does not implement? | 20:57 |
| stekern | jvm3487: yes, it uses the atomic instructions | 20:57 |
| stekern | but this kernel should have emulation for it: https://github.com/openrisc/linux | 20:58 |
| stekern | or rather, *musl* use the atomic instructions | 20:59 |
| olofk | jvm3487: We generally recommend people to switch from or1200 to mor1kx nowadays as mor1kx is the one we are working on and thus is best supported | 21:02 |
| olofk | we = stekern and bandvig at the moment :) | 21:02 |
| stekern | and wallento | 21:07 |
| olofk | ah. sorry | 21:07 |
| jvm3487 | sketern: ok, i had been using this kernel since it was already ported to the atlys board https://github.com/lohith-bellad/OpenRISC-linux. Do you know if it is as easy as copying the configuration files over to the other one? | 21:08 |
| jvm3487 | olofk: 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 future | 21:09 |
| stekern | I think that should work without too much pain | 21:09 |
| olofk | If someone has an atlys defconfig and dts it would be great to have them added to orpsoc-cores | 21:10 |
| olofk | jvm3487: Yeah. We have not been that good at advertising mor1kx, so it seems plenty of people have missed that | 21:10 |
| jvm3487 | stekern: thanks for your help. I'll give that a shot early next week and see how it goes | 21:14 |
| jvm3487 | olofk: I took the ones from that linux port for atlys and modified them based on http://openrisclinux.blogspot.com/2014_06_01_archive.html | 21:16 |
| stekern | ignorance admittance, is f_files in the statvfs struct expected to be 0 when done on a NFS mount? | 21:19 |
| olofk | jvm3487: Interesting. Haven't seen that blog before | 21:31 |
| olofk | Some things are sadly outdated in that blog post though | 21:32 |
| olofk | That's all for tonight. Good night | 21:33 |
| --- Log closed Sun Apr 19 00:00:13 2015 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!