IRC logs for #openrisc Monday, 2014-07-28

--- Log opened Mon Jul 28 00:00:39 2014
-!- knz_ is now known as knz11:18
stekerncool, my fake phy works now13:02
stekerni.e. the mdio id regs can be read13:03
blueCmdso apparently libgc and libffi is the gist of what is needed for java17:34
blueCmdpoke53281 ^^17:34
blueCmda 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 debian17:35
poke53281I know that libffi is needed for Java.17:58
poke53281Still have to finish libffi. Thanks to qemu-user the test suite should run without problems.17:59
poke53281blueCmd: Were did you find a Linux patch to use 9p as root filesystem?19:11
poke53281I found one, but only in form of a shell script.19:13
poke53281after booting19:13
blueCmdpoke53281: "[PATCH] 9p/trans_virtio.c: Fix broken zero-copy on vmalloc() buffers19:15
blueCmdbut re-reading it (I only skimmed it first time) seems it was only to load modules from the FS19:15
blueCmdso no cigar19:16
blueCmdweird, rebuilding gcc to gcc-4.9 causes __umodsi3 to change in some regard and crash stuff19:18
blueCmdworking:    107: 00008b9c    60 FUNC    GLOBAL DEFAULT   12 __umodsi3@@GCC_3.019:19
blueCmdfailing:    105: 00002624     0 NOTYPE  GLOBAL DEFAULT   12 __umodsi3@@GCC_3.019:20
blueCmdthe NOTYPE does indeed seem worying19:20
poke53281Looks like, it is already possible with some special kernel commands.19:31
poke53281I didn't know, that this is possible19:31
poke53281"root=r ro rootfstype=9p rootflags=trans=virtio"19:31
blueCmdpoke53281: are you sure? I think that might only be for the initrd to know what to mount19:33
poke53281hmm, possible. But they don't mention any specific Linux distribution in the article.19:35
poke53281rootfstype and rootflags are valid kernel parameters19:41
blueCmdcool! let me know what you find out!19:43
poke53281blueCmd: 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
poke53281The error message I get is "9pnet_virtio: no channels available"20:13
poke53281This is the same error message I get when I try to mount with an unknown root "mount -t 9p xxxx /"20:14
poke53281So in some way the "root=host" parameter seems to be interpreted differently.20:15
poke53281Is it possible that it tries /dev/host ?20:20
poke53281blueCmd: 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
poke53281blueCmd: Hmm, the kernel tries to mount with "/dev/root" instead of "host"21:25
blueCmdI think /dev/root is "aliased" to whatever you have configured21:30
poke53281Ok, the mount tag is given by the device in a configspace.21:30
poke53281Here I use "host"21:30
poke53281Therefore I mount with "mount -t 9p host /mnt"21:31
poke53281the kernel does not seem to understand "root=host".21:31
blueCmdno idea :(21:31
poke53281But the other parameters are treated correctly.21:31
poke53281It works, when I chane my mount tag given by the device to "/dev/root".21:33
poke53281That, means: Yes, I can have the plan 9 filesystem as root filesystem. :)21:34
blueCmdcool! :)21:44
daliasworking 9p root fs??21:47
blueCmdpoke53281: so in the end, what was required?21:48
poke53281the 9p kernel modules and the kernel parameter "root=host rootfstype=9p rootflags=trans=virtio"21:49
blueCmdI thought "root=host" didn't work?21:49
poke53281For now the mount tag must be "/dev/root"21:49
blueCmdmount tag? you mean mount -t 9p /dev/root / ?21:50
poke53281Yes, but this is the exact answer to your question. This are my options. root=host is ignored and substituted by "/dev/root"21:50
blueCmdNow I understand21:51
poke53281Yes, the equivalent mount option would be "mount -t 9p /dev/root /"21:51
poke53281But 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
poke53281So, it is only a tiny hack. And maybe there is a trivial solution for the "root=host" problem21:52
poke53281Yes, ther kenel does this21:52
poke53281in the file "/init/do_mounts.c"21:52
poke53281acccording to this webpage it should work with root=host21:55
poke53281Hmm, what is the qemu device option "fsdev=r"21:56
poke53281They use the options "fsdev=r,mount_tag=r"21:56
poke53281"fsdev option is used along with -device driver "virtio-9p-pci". "22:04
poke53281And the most useless option description of the day goes to "QEMU"22:04
blueCmdpoke53281: I think fsdev is used to associate an fsdev and a device22:09
blueCmd < there I match then 1:1 at least22:09
poke53281Yes, you are right22:10
poke53281Someone else had already the problem22:11
poke53281Now I find the problem several times.22:14
poke53281Looks like it is not fixed yet.22:14
poke53281And you might not be able to use it in QEMU because of the special sign "/" in the command line22:16
blueCmdhm really? weird22:16
poke53281Might be patched already.22:16
poke53281The forum entries are from 2011-201222:16
blueCmd*sigh* cleaning up gcc, cleaning up glibc and now libgc and libffi. once thing at the time blueCmd, or you will explode22:22
blueCmdthere 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 that22:23
blueCmdI hope I'm correct22:23
blueCmdstekern: I *think* is to blame for that  __udivsi3 with friends do not seem to exist anymore22:27
poke53281blueCmd: Yes, you are22:27
blueCmdstekern: I'm curious why the entry points to the functions are #ifdef'd22:29
blueCmdpoke53281: thanks22:29
blueCmdIn my inbox I have 3 non-OpenRISC emails of 20 total emails, fun - but it really consumes you22:31
blueCmdit'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 upstream22:32
blueCmdanyway, it's great fun - but sometimes it gets a bit much22:32
blueCmdpoke53281: let me know if you want to make a joint effort on upstreaming qemu in the future22:33
poke53281Ok, that means revisit all patches which got not accepted by the maintainer 7 month ago.22:37
blueCmdpoke53281: or dropping them, push the first series and then push for the more "weird" patches22:38
blueCmdbut yes, if we can push everything at once that would be ideal22:38
poke53281Actually, there were only one "weird" patch. And that was the cpu noflags option.22:38
blueCmdqemu is not ment to be a cycle acurate simulator, atomic cannot be implemented as the specification says for example22:39
poke53281don't tell this me, tell this the maintainer.22:40
poke53281the upstream qemu openrisc emulation is still in a very bad shape.22:40
poke53281But there is no alternative to QEMU.22:40
poke53281The qemu-user emulation is so fantastic.22:41
blueCmdstekern: seems that GCC -DL__x on the assembly for those, so I understand why the #ifdefs are there now22:53
blueCmdstekern: for fix23:37
blueCmdignore the "jrrr9" thing23:37
--- Log closed Tue Jul 29 00:00:40 2014

Generated by 2.15.2 by Marius Gedminas - find it at!