IRC logs for #openrisc Monday, 2013-07-15

--- Log opened Mon Jul 15 00:00:27 2013
stekernpoke53281: I think franck has some patches in his repo that enables it for linux02:17
stekernat least I have a or1k-linux-uclibc-gdb02:17
stekernbut IIRC, debugging with gdbserver didn't work completely02:18
poke53281Ok, I will have a look02:44
poke53281The touchscreen is now working too. Programs to test are fox example ts_test and df_window02:47
stekerncool, I have a physical touchscreen + 7" lcd attached to one of my boards, so again things I like to do on hw02:52
stekernright now it freezes for me at: ata1.00: configured for PIO02:54
stekernnow it worked02:55
stekernI was thinking, would it be at all possible to get network emulation working in jor1k?02:56
stekernI presume it would not be trivial...03:02
stekernI pushed the unaligned R_OR1K_32 fix to uclibc now03:04
poke53281thanks I will test it03:52
poke53281well, let's say it this way. The emulation is easy. In principle exactly the same as or1ksim is doing. The problem is: what to do with the data.03:53
poke53281At the moment the program is client only. Ok, it retrieves the hard drive image but this is done by the standard GET method of http03:55
poke53281So at the moment it run standalone on every webserver.03:55
poke53281The probem with html is, that it allows only to communicate with the server.03:56
poke53281So I need a script on the server which sends the ethernet packets to a tun/tap device.03:56
poke53281Also this is in principle no problem.03:56
poke53281But I would never activate it for all website of course.03:57
poke53281It would no longer work on github of course03:59
stekernyeah, that's about how I figured it would need to work03:59
stekernI just thought it'd be fun to run the gcc testsuite against it, but perhaps it'd be easier tomount a hard drive image on the host and write a dejagnu script that interracts with the browser04:02
poke53281Yes, would be nice. But I think or1ksim is already very suited for running the testsuite this.04:13
poke53281I can reduce the splitsize of the harddrive image 0.5MB to 256kB. Then there should be no longer timeouts04:15
stekernyes, I agree or1ksim is good for this, it would just be for the fun of it04:17
stekernI've tested running it against qemu04:17
stekernsurprisingly, that was slower than running against or1ksim04:17
poke53281really? wtf04:18
stekernI suspect that slow ethernet emulation was the cause there though04:18
stekernso, doing a dejagnu script similiar to what I described for qemu/or1ksim would be beneficial too I think04:19
stekernI would really want to be able to run the testsuite faster, it's not feasible to have it running 1-2 days04:21
stekernthere is of course jeremybennett's way with running several or1ksim, but it's a bit messy setup04:23
poke53281qemu should be the better way. You should find the real reason why it is so slow.04:24
poke53281And or1ksim can be optimized in a lot of ways I think. It is a very exact simulation.04:25
stekernI agree, on both =P04:27
stekernbut either way, the ftp/telnet communicating is a bottle neck04:28
poke53281or1ksim with samba?04:29
poke53281of nfs04:29
poke53281or nfs04:29
stekernyeah, nfs04:29
stekernI actually run my rootfs of nfs04:29
poke53281tmp would directly link to a nfs folder. Then you no longer need all the ftp stuff.04:30
stekernthe only problem is, that IIRC I tracked down the slowness of qemu to ethernet emulation, so it'll not really help there04:31
stekernor, of course it might help, but there might still be a bottle neck04:32
stekernand then there is still the telnet open/close bottle neck04:33
poke53281How fast is qemu's calculation speed in comparison to or1ksim? I have never checked it04:35
poke53281Did you try the different options of qemu to establish a connection?04:35
stekernhaven't checked, IIRC I did run some benchmark software (like coremark), but or1ksim and qemu isn't really emulating the tick timer in the same way04:37
poke53281Well, you can try a real clock04:37
stekernI think I did test different connection options, but none really stood out04:38
stekernbut it was a while ago, so I might remember wrong04:38
stekernyeah, I should take another look at it04:39
poke53281qemu should be ten times faster04:40
stekernright after I'm done with my time freeze device =P04:40
poke53281I would buy two of them when you are finished. :)04:43
stekernyeah, it's going to make me rich04:49
stekernit's a bit of a catch 22 though, I need the time freeze device to have more time to work on the time freeze device04:50
jeremybennettstekern: poke53281: the problem with FTP is the C++ tests which load huge files. However our hugely parallel solution should work fine.05:05
jeremybennettThe problem is that standard GNU "make check" does not parallelize suffiiently, so the difficulty of our approach was to parallelise enough.05:06
jeremybennettThere also used to be the problem of OR1K Linux freezing, but I think that is no longer an issue.05:06
jeremybennettAs it happens there was a good session on the future of DejaGnu with Rob Savoye at the GNU Tools Cauldron this afternooon. Support for serious parallelism is a high priority for the new version of DejaGnu05:07
stekernjeremybennett: IMO, the problem with ftp/telnet is more with the large amount of *small* testcases05:08
stekerntransferring a large file over ftp to or1ksim is "fast" in my setup at least05:09
poke53281Because of the shared libs if should be even faster right now05:09
stekerngood point poke5328105:09
poke53281stekern: what is the command to start qemu-system-or32. For some reason my old command no longer works and I get no error messages. Maybe my Qemu is broken05:11
stekernmainline git head qemu still boots an openrisc linux05:11
poke53281I am curious, who programmed this port to qemu. Fabrice Bellard himself?05:12
stekernI just run: qemu-system-or32 -nographic -kernel /path/to/vmlinux05:12
poke53281Ok, then something is wrong with my machine05:12
stekernno, a guy called Jia Liu05:13
stekernjeremybennett: "was" and "this afternoon", where are you?05:26
simoncookstekern: At the GNU Tools Cauldron in California05:50
stekernah, I guess I should have figured that out by what he wrote and googling where the GNU Tools Cauldron is held ;)05:59
poke53281nice, at google headquarters05:59
poke53281Ok, here is the patch for the new varargs treatment. Tomorrow I will run the testsuite.06:50
stekernI wonder how we should proceed with it though.07:24
stekernI guess we could make it as a "new abi" conditional07:25
stekernbut I think if we do that, there are others things in the "old abi" that we would want to fix in the "new abi"07:25
stekerngcc tests, pretty much identical with what I had on 4.8.0 last time I ran, new fails are related to plugins and tls, things that weren't support or tested last time09:30
stekernvhdls lack of else in generate statements is really annoying09:32
stekernman this sucks: Fitter requires 1557 LABs to implement the project, but the device contains only 1539 LABs11:21
LoneTechstekern: yep, sucks. you might be able to substitute RAMs for a handful12:38
stekernLoneTech: sadly, the RAMs are pretty much used up...13:13
LoneTechthen I guess it's down to trying to reduce the size of something13:16
stekernyup, but that's for tomorrow :)13:19
stekernI'm a bit tied down though, ~90% of the design is an encrypted netlist and the rest ~10% is a 1500 LE uart (yes, it's bloated)13:20
LoneTechso it's basically chipping away at that U.13:21
stekernplenty of fun it'll be...13:24
LoneTechcompiling a 1.3G gzipped SDF currently13:28
poke53281stekern: I know this is a problem. It is off specification.17:21
poke53281But even in the current ABI there was a trick to solve this17:21
poke53281at least for uClibc (In line 73 of my patch). So for now we17:21
poke53281know 3 big software packages which rely on such a varargs17:21
poke53281handling: uClibc, gcc, Directfb and probably many more.17:21
poke53281These should be enough reasons to change this part of the ABI.17:21
poke53281Of course the patch should not be applied if the llvm compiler is not17:21
poke53281changed at the same time. All programs have to be recompiled after this patch.17:21
poke53281We can write it also in the Proposed Changes part on the website17:21
poke53281For now I have to test this patch a little bit more with the testsuite.17:21
poke53281And after my patch is fine let's see what the others are saying on the mailing list17:22
stekernsupporting several ABIs aren't very uncommon, several archs do that. It adds a bit of maintainance overhead of course17:50
stekernI can (and will be happy to) whip up a patch for llvm, don't worry about that ;)17:52
stekernbut doing some more testing and hearing what others think sounds like a good plan17:52
poke53281I don't like idea with several ABIs. This would be necessary if the architecture would have a huge community. And actually in the end this would break only stuff for people who are using the stable and unstable toolchain at the same time. Everyone using the experimental toolchain must be aware of changes of such type that you have to recompile everything.18:10
poke53281In the end we could wait for the until specification 1.1 is out.18:10
stekernI don't particularly like the idea of several ABIs, but I don't like the idea of breaking the current neither.18:21
stekernbut I hear what you're saying, this particular ABI break is rather "soft", it will only affect compiled code (I can't imagine anyone doing vararg functions in asm)18:22
stekernon a unrelated note, I can't seem to get qemu tap networking to work... I know I've done this before18:23
stekernbah, I was missing the -net nic argument18:27
stekernyeah, this is insanely slow, and inetd takes close to 100% cpu18:50
poke53281kernel time or user mode time? I think inetd is written in such a way that it sleeps if it has to wait for TCP packets. I would wonder if not.18:57
poke53281Does the driver has an endless loop somewhere. The driver for the touchscreen I implemented yesterday had something like this.18:58
poke53281So maybe the kernel driver is waiting for some reaction of the ethernet device.18:59
stekernI'm looking at it now18:59
stekernsounds plausible18:59
poke53281and I am not sure how qemu works. Especially about the timings. Could be that in this translation mode of qemu the hardware is only treated several ten thousands of steps. This would mean that the kernel driver waits forever for nothing.19:01
stekerncan't say I'm familiar how qemu works neither19:02
poke53281In or1ksim the devices are treated every step for an exact simulation. I don't think qemu is doing this because it would be slow down everything dramatically.19:04
poke53281Arghh, Linux crashes again in or1ksim. The third time that I have the problem.19:21
poke53281No error message, just no response.19:23
poke53281I use the current git repository from jonas.19:23
poke53281no specialties19:24
poke53281FAIL: gcc.c-torture/execute/20071213-1.c21:19
poke53281varargs with long long int21:20
--- Log closed Tue Jul 16 00:00:29 2013

Generated by 2.15.2 by Marius Gedminas - find it at!