| --- Log opened Mon Jul 28 00:00:39 2014 | ||
| -!- knz_ is now known as knz | 11:18 | |
| stekern | cool, my fake phy works now | 13:02 |
|---|---|---|
| stekern | i.e. the mdio id regs can be read | 13:03 |
| blueCmd | so apparently libgc and libffi is the gist of what is needed for java | 17:34 |
| blueCmd | poke53281 ^^ | 17:34 |
| blueCmd | a debian maintainer even suggested that it might be easier to just port libgc and libffi and thus get java support than to work around it in debian | 17:35 |
| poke53281 | I know that libffi is needed for Java. | 17:58 |
| poke53281 | Still have to finish libffi. Thanks to qemu-user the test suite should run without problems. | 17:59 |
| poke53281 | blueCmd: Were did you find a Linux patch to use 9p as root filesystem? | 19:11 |
| poke53281 | I found one, but only in form of a shell script. | 19:13 |
| poke53281 | after booting | 19:13 |
| blueCmd | poke53281: "[PATCH] 9p/trans_virtio.c: Fix broken zero-copy on vmalloc() buffers | 19:15 |
| blueCmd | but re-reading it (I only skimmed it first time) seems it was only to load modules from the FS | 19:15 |
| blueCmd | so no cigar | 19:16 |
| blueCmd | weird, rebuilding gcc to gcc-4.9 causes __umodsi3 to change in some regard and crash stuff | 19:18 |
| blueCmd | working: 107: 00008b9c 60 FUNC GLOBAL DEFAULT 12 __umodsi3@@GCC_3.0 | 19:19 |
| blueCmd | failing: 105: 00002624 0 NOTYPE GLOBAL DEFAULT 12 __umodsi3@@GCC_3.0 | 19:20 |
| blueCmd | the NOTYPE does indeed seem worying | 19:20 |
| poke53281 | blueCmd: http://unix.stackexchange.com/questions/90423/can-virtfs-9p-be-used-as-root-file-system | 19:30 |
| poke53281 | Looks like, it is already possible with some special kernel commands. | 19:31 |
| poke53281 | I didn't know, that this is possible | 19:31 |
| poke53281 | "root=r ro rootfstype=9p rootflags=trans=virtio" | 19:31 |
| blueCmd | poke53281: are you sure? I think that might only be for the initrd to know what to mount | 19:33 |
| poke53281 | hmm, possible. But they don't mention any specific Linux distribution in the article. | 19:35 |
| poke53281 | rootfstype and rootflags are valid kernel parameters | 19:41 |
| blueCmd | cool! let me know what you find out! | 19:43 |
| poke53281 | blueCmd: Almost, the kernel at least tries to mount it, but fails. But the error makes no sense. | 20:12 |
| poke53281 | "root=host rootfstype=9p" should be equivalent to "mount -t 9p host /" | 20:13 |
| poke53281 | The error message I get is "9pnet_virtio: no channels available" | 20:13 |
| poke53281 | This is the same error message I get when I try to mount with an unknown root "mount -t 9p xxxx /" | 20:14 |
| poke53281 | So in some way the "root=host" parameter seems to be interpreted differently. | 20:15 |
| poke53281 | Is it possible that it tries /dev/host ? | 20:20 |
| poke53281 | blueCmd: I think it is possible. Currently I have no time to find the (tiny) error. But I am pretty sure, that it will work. | 20:39 |
| poke53281 | blueCmd: Hmm, the kernel tries to mount with "/dev/root" instead of "host" | 21:25 |
| blueCmd | I think /dev/root is "aliased" to whatever you have configured | 21:30 |
| poke53281 | Ok, the mount tag is given by the device in a configspace. | 21:30 |
| poke53281 | Here I use "host" | 21:30 |
| poke53281 | Therefore I mount with "mount -t 9p host /mnt" | 21:31 |
| poke53281 | the kernel does not seem to understand "root=host". | 21:31 |
| blueCmd | right | 21:31 |
| blueCmd | no idea :( | 21:31 |
| poke53281 | But the other parameters are treated correctly. | 21:31 |
| poke53281 | It works, when I chane my mount tag given by the device to "/dev/root". | 21:33 |
| poke53281 | That, means: Yes, I can have the plan 9 filesystem as root filesystem. :) | 21:34 |
| blueCmd | cool! :) | 21:44 |
| dalias | working 9p root fs?? | 21:47 |
| poke53281 | YES | 21:47 |
| dalias | YAY! | 21:48 |
| blueCmd | poke53281: so in the end, what was required? | 21:48 |
| poke53281 | the 9p kernel modules and the kernel parameter "root=host rootfstype=9p rootflags=trans=virtio" | 21:49 |
| blueCmd | I thought "root=host" didn't work? | 21:49 |
| poke53281 | For now the mount tag must be "/dev/root" | 21:49 |
| blueCmd | mount tag? you mean mount -t 9p /dev/root / ? | 21:50 |
| poke53281 | Yes, but this is the exact answer to your question. This are my options. root=host is ignored and substituted by "/dev/root" | 21:50 |
| blueCmd | aaaah | 21:51 |
| blueCmd | Now I understand | 21:51 |
| poke53281 | Yes, the equivalent mount option would be "mount -t 9p /dev/root /" | 21:51 |
| poke53281 | But here I am not sure if /dev/root is not misunderstand by the mount command. | 21:51 |
| blueCmd | (which is what I guess the kernel does, so that would be why it needs to be called that I guess) | 21:51 |
| poke53281 | So, it is only a tiny hack. And maybe there is a trivial solution for the "root=host" problem | 21:52 |
| poke53281 | Yes, ther kenel does this | 21:52 |
| poke53281 | in the file "/init/do_mounts.c" | 21:52 |
| poke53281 | acccording to this webpage http://unix.stackexchange.com/questions/90423/can-virtfs-9p-be-used-as-root-file-system it should work with root=host | 21:55 |
| poke53281 | Hmm, what is the qemu device option "fsdev=r" | 21:56 |
| poke53281 | They use the options "fsdev=r,mount_tag=r" | 21:56 |
| poke53281 | "fsdev option is used along with -device driver "virtio-9p-pci". " | 22:04 |
| poke53281 | And the most useless option description of the day goes to "QEMU" | 22:04 |
| blueCmd | poke53281: I think fsdev is used to associate an fsdev and a device | 22:09 |
| blueCmd | https://github.com/bluecmd/or1k-devel/blob/master/tests/qemu-system < there I match then 1:1 at least | 22:09 |
| poke53281 | Yes, you are right | 22:10 |
| poke53281 | https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=696292 | 22:10 |
| poke53281 | Someone else had already the problem | 22:11 |
| poke53281 | Now I find the problem several times. | 22:14 |
| poke53281 | Looks like it is not fixed yet. | 22:14 |
| poke53281 | And you might not be able to use it in QEMU because of the special sign "/" in the command line | 22:16 |
| blueCmd | hm really? weird | 22:16 |
| poke53281 | Might be patched already. | 22:16 |
| poke53281 | The forum entries are from 2011-2012 | 22:16 |
| blueCmd | *sigh* cleaning up gcc, cleaning up glibc and now libgc and libffi. once thing at the time blueCmd, or you will explode | 22:22 |
| blueCmd | there are a million things I want to do, but I keep telling myself that having the state of gcc and glibc in order will help a lot so focus on that | 22:23 |
| blueCmd | I hope I'm correct | 22:23 |
| blueCmd | stekern: I *think* https://github.com/openrisc/or1k-gcc/commit/bdd3ad496930c61218ea683b9fd3dbcc093b9a14 is to blame for that __udivsi3 with friends do not seem to exist anymore | 22:27 |
| poke53281 | blueCmd: Yes, you are | 22:27 |
| blueCmd | stekern: I'm curious why the entry points to the functions are #ifdef'd | 22:29 |
| blueCmd | poke53281: thanks | 22:29 |
| blueCmd | In my inbox I have 3 non-OpenRISC emails of 20 total emails, fun - but it really consumes you | 22:31 |
| blueCmd | it's quite interesting when people tell you "why don't you spend an hour fixing this thing?" and you have to honestly tell them "I'm sorry, but I don't have time - I swear!" because you really cannot juggle yet another patch series to upstream | 22:32 |
| blueCmd | anyway, it's great fun - but sometimes it gets a bit much | 22:32 |
| blueCmd | poke53281: let me know if you want to make a joint effort on upstreaming qemu in the future | 22:33 |
| poke53281 | Ok, that means revisit all patches which got not accepted by the maintainer 7 month ago. | 22:37 |
| blueCmd | poke53281: or dropping them, push the first series and then push for the more "weird" patches | 22:38 |
| blueCmd | but yes, if we can push everything at once that would be ideal | 22:38 |
| poke53281 | Actually, there were only one "weird" patch. And that was the cpu noflags option. | 22:38 |
| blueCmd | qemu is not ment to be a cycle acurate simulator, atomic cannot be implemented as the specification says for example | 22:39 |
| poke53281 | don't tell this me, tell this the maintainer. | 22:40 |
| poke53281 | the upstream qemu openrisc emulation is still in a very bad shape. | 22:40 |
| poke53281 | But there is no alternative to QEMU. | 22:40 |
| poke53281 | The qemu-user emulation is so fantastic. | 22:41 |
| blueCmd | indeed | 22:41 |
| blueCmd | stekern: seems that GCC -DL__x on the assembly for those, so I understand why the #ifdefs are there now | 22:53 |
| blueCmd | stekern: https://github.com/bluecmd/or1k-gcc/commit/c8d8f384777c7181adb6a282531a128ef7056b6f for fix | 23:37 |
| blueCmd | ignore the "jrrr9" thing | 23:37 |
| --- Log closed Tue Jul 29 00:00:40 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!