| --- Log opened Sat Apr 12 00:00:01 2014 | ||
| stekern | blueCmd: I'm pretty sure he meant module.h. and it's probably module.h in his example program that he has copy-pasted from, since it's probably this guy asking again: http://juliusbaxter.net/openrisc-irc/%23openrisc.2014-03-28.log.html#t16:29 | 04:22 |
|---|---|---|
| stekern | if it's not two guys working on the same school project, with terrible collaboration ;) | 04:23 |
| stekern | the problem is that he thinks it's a "program", when it's an example for a kernel module he has found | 04:24 |
| stekern | could of course be a coincident, I see that the other example "program" did something with ethernet, but in both cases the problem they're trying to solve were equally vague | 04:26 |
| dalias | stekern, hey | 04:27 |
| dalias | stekern, some ppl in #musl were asking if there's any progress/status on openrisc port | 04:28 |
| stekern | dalias: yes, there is | 04:30 |
| stekern | it's basically just the cas implementation left in atomic.h to do, then it's done | 04:31 |
| dalias | cool | 04:31 |
| dalias | i was under the impression that linux on openrisc omits all the "old" syscalls like open (i.e. you have to use openat, etc.) | 04:32 |
| dalias | is that wrong or do you have proposed changes to handle that? | 04:32 |
| stekern | ...and as you might remember, I got sidestepped into actually implementing the ll/sc instructions for or1k in binutils, simulators and rtl | 04:33 |
| dalias | :) | 04:33 |
| stekern | no, that's not wrong, but that's another thing I need to look into. | 04:33 |
| dalias | we're dealing with that issue in aarch64 port, so either way it needs to be handled | 04:33 |
| stekern | ok, yeah. I was actually wondering if musl had that sorted out. It caused a bit of churn in uClibc, but at this point they handle it | 04:34 |
| stekern | so, I was kind of hoping musl would too ;) | 04:35 |
| dalias | there's mixed opinion on whether we should #ifdef SYS_open etc. at each syscall site, define wrapper macros in internal/syscall.h like sys_open() and have them handle it, or do ugly remapping hidden in the __syscall macros like the hideous workaround for timespec on x32 | 04:35 |
| dalias | but we'll end up adopting one of these approaches (or maybe something better) soon | 04:36 |
| dalias | like i said, we already have another port pending (aarch64) that will need it | 04:36 |
| stekern | ok, good, and thanks for the headsup on it | 04:38 |
| blueCmd | stekern: so, I have this crash.c that crashes on native compilation but not cross compilation. I've told you about that before | 09:04 |
| blueCmd | I confirmed that it happens on both qemu and or1ksim | 09:04 |
| blueCmd | I'm trying to figure out the path with least amount of pain to find the issue | 09:05 |
| stekern | hmm, my favourite debugging method is or1ksim traces with l.nop 8 | 09:12 |
| stekern | it was gcc that segfaults, right? | 09:12 |
| blueCmd | cc1 but yes | 09:13 |
| blueCmd | http://www.askques.com/2103078/python-on-arm-illegal-instructions seems to be semi-related, it was triggered by the same code at least, so something special is done | 09:13 |
| stekern | so, surround the offending code with l.nop 8 and l.nop 9 | 09:14 |
| blueCmd | stekern: sure, it's between main() and return 0; | 09:14 |
| blueCmd | that's the issue | 09:14 |
| blueCmd | I have no idea where it can be, and gcc is quite huge | 09:14 |
| blueCmd | but I guess I'll just have to binary search | 09:15 |
| stekern | ah, but surely the segfault gives you some info about the pc where it happens? | 09:18 |
| blueCmd | well, in qemu it does | 09:19 |
| blueCmd | I guess i could look at the disass and see | 09:19 |
| blueCmd | in some cases it's in the stack though | 09:19 |
| stekern | if linux doesn't give you enough info, you'll have to modify it to do it then ;) | 09:21 |
| blueCmd | hah, I suppose. a core dump should contain that | 09:21 |
| stekern | you can add some printks in mm/fault.c do_page_fault() | 09:22 |
| blueCmd | stekern: http://storage.googleapis.com/bluecmd-openrisc/de0_orpsoc_asm.jpg | 12:41 |
| blueCmd | also olofk | 12:41 |
| szabolcsberki | hi | 12:53 |
| stekern | szabolcsberki: http://juliusbaxter.net/openrisc-irc/%23openrisc.2014-04-11.log.html#t19:47 | 13:42 |
| Findeton | so I'm trying to run linux with or1ksim | 16:34 |
| Findeton | I have built and installed the or1ksim and the toolchain (both the newlib and the uclibc) | 16:36 |
| Findeton | I'm following http://opencores.org/or1k/Linux | 16:36 |
| Findeton | but when I execute make menuconfig the menuconfig appers and I do not know what I am supposed to do! | 16:37 |
| Findeton | and of course when I execute $ make CROSS_COMPILER=or32-linux it gives me an error | 16:40 |
| Findeton | make: *** No rule to make target `include/config/auto.conf', needed by `include/config/kernel.release'. Stop | 16:41 |
| Findeton | btw I don't know if this is important, but there's no program installed called or32-linux, does it have a new or1k- name now or something like that? | 16:41 |
| stekern | Findeton: you can compile it with the or1k-elf- toolchain | 17:25 |
| Findeton | uhm how? just changing or32-linux- to or1k-elf- ? | 17:26 |
| stekern | yes, *but* you'll also need to change OUTPUT_FORMAT("elf32-or32", "elf32-or32", "elf32-or32") to OUTPUT_FORMAT("elf32-or1k", "elf32-or1k", "elf32-or1k") in arch/openrisc/kernel/vmlinux.lds.S | 17:27 |
| Findeton | uhm ok | 17:28 |
| stekern | that guide is slightly dated too, but most of it is still valid | 17:29 |
| stekern | it should be CROSS_COMPILER=or32-linux- (or or1k-elf-) in your case though | 17:31 |
| Findeton | uhm | 17:33 |
| Findeton | maybe I should update it (when I get it to work) | 17:34 |
| stekern | note the extra - | 17:34 |
| Findeton | yes I noticed :) | 17:34 |
| Findeton | stekern: I have made the changes in arch/openrisc/kernel/vmlinux.lds.S but it's still trying to use or32 for some reason | 18:03 |
| Findeton | /bin/sh: 1: or32-linux-gcc: not found | 18:04 |
| Findeton | make[1]: *** [kernel/bounds.s] Error 127 | 18:04 |
| Findeton | oh no | 18:06 |
| Findeton | it was my mistake | 18:06 |
| Findeton | nah it doesn't work | 18:07 |
| Findeton | http://pastebin.com/HSS6DcPP | 18:10 |
| Findeton | that's what I've done and the output | 18:10 |
| _franck_ | it's not CROSS_COMPILER | 18:24 |
| _franck_ | it's CROSS_COMPIL*E* | 18:25 |
| _franck_ | CROSS_COMPILE=or1k-elf- | 18:25 |
| stekern | ah, right, missed that R ;) | 18:26 |
| Findeton | well I got it working by using the make menuconfig! | 18:27 |
| Findeton | now I've started linux with the or32-elf-sim (it's the or1k version) | 18:27 |
| Findeton | but it has stopped loading while configuring the loopback device | 18:28 |
| stekern | it probably didn't stop loading | 18:28 |
| stekern | try: telnet localhost 10084 | 18:28 |
| stekern | or change your config to use xterm as the input/output device | 18:29 |
| Findeton | but I should get a console or something ? | 18:29 |
| Findeton | ah yeah | 18:29 |
| stekern | change in the or1ksim .cfg file that is | 18:30 |
| stekern | you can choose between a couple of different options | 18:30 |
| Findeton | yeah I'll do that | 18:38 |
| Findeton | well I did it, now I have to connect it to the internet | 18:48 |
| stekern | man this cgen stuff is hard... | 18:49 |
| Findeton | what's cgen? | 19:03 |
| stekern | https://sourceware.org/cgen/ | 19:14 |
| stekern | you describe your machine in a couple of scheme files, and in binutils it will generate the arch specific files for the assembler etc | 19:18 |
| stekern | and you get a simulator generated for you as well | 19:18 |
| Findeton | stekern: it looks interesting | 19:25 |
| Findeton | now I'm with the tun/tap thing | 20:01 |
| Findeton | do I need to create a bridge before using the brstart.sh script or does that script create the bridge? | 20:02 |
| Findeton | if there is anyone there | 22:14 |
| Findeton | I have the linux sim running | 22:14 |
| Findeton | and I run the brstart scripts to add the bridge and tap0 | 22:14 |
| Findeton | but the bridge IP on the host computer is something like 10.0.2.15 | 22:15 |
| Findeton | and the eth0 connection on the openrisc linux sim is 192.168.1.100 | 22:15 |
| Findeton | so something big is kind of failing, how can I solve it? | 22:16 |
| --- Log closed Sun Apr 13 00:00:03 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!
