| --- Log opened Mon Jul 15 00:00:27 2013 | ||
| stekern | poke53281: I think franck has some patches in his repo that enables it for linux | 02:17 |
|---|---|---|
| stekern | at least I have a or1k-linux-uclibc-gdb | 02:17 |
| stekern | but IIRC, debugging with gdbserver didn't work completely | 02:18 |
| poke53281 | Ok, I will have a look | 02:44 |
| poke53281 | The touchscreen is now working too. Programs to test are fox example ts_test and df_window | 02:47 |
| stekern | cool, I have a physical touchscreen + 7" lcd attached to one of my boards, so again things I like to do on hw | 02:52 |
| stekern | right now it freezes for me at: ata1.00: configured for PIO | 02:54 |
| stekern | now it worked | 02:55 |
| stekern | I was thinking, would it be at all possible to get network emulation working in jor1k? | 02:56 |
| stekern | I presume it would not be trivial... | 03:02 |
| stekern | I pushed the unaligned R_OR1K_32 fix to uclibc now | 03:04 |
| poke53281 | thanks I will test it | 03:52 |
| poke53281 | well, 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 |
| poke53281 | At the moment the program is client only. Ok, it retrieves the hard drive image but this is done by the standard GET method of http | 03:55 |
| poke53281 | So at the moment it run standalone on every webserver. | 03:55 |
| poke53281 | The probem with html is, that it allows only to communicate with the server. | 03:56 |
| poke53281 | So I need a script on the server which sends the ethernet packets to a tun/tap device. | 03:56 |
| poke53281 | Also this is in principle no problem. | 03:56 |
| poke53281 | But I would never activate it for all website of course. | 03:57 |
| poke53281 | It would no longer work on github of course | 03:59 |
| stekern | yeah, that's about how I figured it would need to work | 03:59 |
| stekern | I 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 browser | 04:02 |
| poke53281 | Yes, would be nice. But I think or1ksim is already very suited for running the testsuite this. | 04:13 |
| poke53281 | I can reduce the splitsize of the harddrive image 0.5MB to 256kB. Then there should be no longer timeouts | 04:15 |
| stekern | yes, I agree or1ksim is good for this, it would just be for the fun of it | 04:17 |
| stekern | I've tested running it against qemu | 04:17 |
| stekern | surprisingly, that was slower than running against or1ksim | 04:17 |
| poke53281 | really? wtf | 04:18 |
| stekern | I suspect that slow ethernet emulation was the cause there though | 04:18 |
| stekern | so, doing a dejagnu script similiar to what I described for qemu/or1ksim would be beneficial too I think | 04:19 |
| stekern | I would really want to be able to run the testsuite faster, it's not feasible to have it running 1-2 days | 04:21 |
| stekern | there is of course jeremybennett's way with running several or1ksim, but it's a bit messy setup | 04:23 |
| poke53281 | qemu should be the better way. You should find the real reason why it is so slow. | 04:24 |
| poke53281 | And or1ksim can be optimized in a lot of ways I think. It is a very exact simulation. | 04:25 |
| stekern | I agree, on both =P | 04:27 |
| stekern | but either way, the ftp/telnet communicating is a bottle neck | 04:28 |
| poke53281 | or1ksim with samba? | 04:29 |
| poke53281 | of nfs | 04:29 |
| poke53281 | or nfs | 04:29 |
| stekern | yeah, nfs | 04:29 |
| stekern | I actually run my rootfs of nfs | 04:29 |
| poke53281 | tmp would directly link to a nfs folder. Then you no longer need all the ftp stuff. | 04:30 |
| stekern | the only problem is, that IIRC I tracked down the slowness of qemu to ethernet emulation, so it'll not really help there | 04:31 |
| stekern | or, of course it might help, but there might still be a bottle neck | 04:32 |
| stekern | and then there is still the telnet open/close bottle neck | 04:33 |
| poke53281 | How fast is qemu's calculation speed in comparison to or1ksim? I have never checked it | 04:35 |
| poke53281 | Did you try the different options of qemu to establish a connection? | 04:35 |
| stekern | haven'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 way | 04:37 |
| poke53281 | Well, you can try a real clock | 04:37 |
| stekern | I think I did test different connection options, but none really stood out | 04:38 |
| stekern | but it was a while ago, so I might remember wrong | 04:38 |
| stekern | yeah, I should take another look at it | 04:39 |
| poke53281 | qemu should be ten times faster | 04:40 |
| stekern | right after I'm done with my time freeze device =P | 04:40 |
| poke53281 | I would buy two of them when you are finished. :) | 04:43 |
| stekern | yeah, it's going to make me rich | 04:49 |
| stekern | it's a bit of a catch 22 though, I need the time freeze device to have more time to work on the time freeze device | 04:50 |
| jeremybennett | stekern: poke53281: the problem with FTP is the C++ tests which load huge files. However our hugely parallel solution should work fine. | 05:05 |
| jeremybennett | The problem is that standard GNU "make check" does not parallelize suffiiently, so the difficulty of our approach was to parallelise enough. | 05:06 |
| jeremybennett | There also used to be the problem of OR1K Linux freezing, but I think that is no longer an issue. | 05:06 |
| jeremybennett | As 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 DejaGnu | 05:07 |
| stekern | jeremybennett: IMO, the problem with ftp/telnet is more with the large amount of *small* testcases | 05:08 |
| stekern | transferring a large file over ftp to or1ksim is "fast" in my setup at least | 05:09 |
| poke53281 | Because of the shared libs if should be even faster right now | 05:09 |
| stekern | good point poke53281 | 05:09 |
| poke53281 | stekern: 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 broken | 05:11 |
| stekern | mainline git head qemu still boots an openrisc linux | 05:11 |
| poke53281 | I am curious, who programmed this port to qemu. Fabrice Bellard himself? | 05:12 |
| stekern | I just run: qemu-system-or32 -nographic -kernel /path/to/vmlinux | 05:12 |
| poke53281 | Ok, then something is wrong with my machine | 05:12 |
| stekern | no, a guy called Jia Liu | 05:13 |
| stekern | jeremybennett: "was" and "this afternoon", where are you? | 05:26 |
| simoncook | stekern: At the GNU Tools Cauldron in California | 05:50 |
| stekern | ah, I guess I should have figured that out by what he wrote and googling where the GNU Tools Cauldron is held ;) | 05:59 |
| poke53281 | nice, at google headquarters | 05:59 |
| poke53281 | http://pastie.org/8141895 | 06:49 |
| poke53281 | Ok, here is the patch for the new varargs treatment. Tomorrow I will run the testsuite. | 06:50 |
| stekern | nice | 07:19 |
| stekern | I wonder how we should proceed with it though. | 07:24 |
| stekern | I guess we could make it as a "new abi" conditional | 07:25 |
| stekern | but 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 |
| stekern | http://pastie.org/8142196 | 09:24 |
| stekern | gcc 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 time | 09:30 |
| stekern | vhdls lack of else in generate statements is really annoying | 09:32 |
| stekern | man this sucks: Fitter requires 1557 LABs to implement the project, but the device contains only 1539 LABs | 11:21 |
| LoneTech | stekern: yep, sucks. you might be able to substitute RAMs for a handful | 12:38 |
| stekern | LoneTech: sadly, the RAMs are pretty much used up... | 13:13 |
| LoneTech | then I guess it's down to trying to reduce the size of something | 13:16 |
| stekern | yup, but that's for tomorrow :) | 13:19 |
| stekern | I'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 |
| LoneTech | so it's basically chipping away at that U. | 13:21 |
| stekern | yup | 13:21 |
| stekern | plenty of fun it'll be... | 13:24 |
| LoneTech | compiling a 1.3G gzipped SDF currently | 13:28 |
| poke53281 | stekern: I know this is a problem. It is off specification. | 17:21 |
| poke53281 | But even in the current ABI there was a trick to solve this | 17:21 |
| poke53281 | at least for uClibc (In line 73 of my patch). So for now we | 17:21 |
| poke53281 | know 3 big software packages which rely on such a varargs | 17:21 |
| poke53281 | handling: uClibc, gcc, Directfb and probably many more. | 17:21 |
| poke53281 | These should be enough reasons to change this part of the ABI. | 17:21 |
| poke53281 | Of course the patch should not be applied if the llvm compiler is not | 17:21 |
| poke53281 | changed at the same time. All programs have to be recompiled after this patch. | 17:21 |
| poke53281 | We can write it also in the Proposed Changes part on the website | 17:21 |
| poke53281 | http://opencores.org/or1k/Architecture_Specification#Download_OR1K_1.0_Specification | 17:21 |
| poke53281 | For now I have to test this patch a little bit more with the testsuite. | 17:21 |
| poke53281 | And after my patch is fine let's see what the others are saying on the mailing list | 17:22 |
| stekern | supporting several ABIs aren't very uncommon, several archs do that. It adds a bit of maintainance overhead of course | 17:50 |
| stekern | I can (and will be happy to) whip up a patch for llvm, don't worry about that ;) | 17:52 |
| stekern | but doing some more testing and hearing what others think sounds like a good plan | 17:52 |
| poke53281 | I 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 |
| poke53281 | In the end we could wait for the until specification 1.1 is out. | 18:10 |
| stekern | I don't particularly like the idea of several ABIs, but I don't like the idea of breaking the current neither. | 18:21 |
| stekern | but 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 |
| stekern | on a unrelated note, I can't seem to get qemu tap networking to work... I know I've done this before | 18:23 |
| stekern | bah, I was missing the -net nic argument | 18:27 |
| stekern | yeah, this is insanely slow, and inetd takes close to 100% cpu | 18:50 |
| poke53281 | kernel 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 |
| poke53281 | Does the driver has an endless loop somewhere. The driver for the touchscreen I implemented yesterday had something like this. | 18:58 |
| poke53281 | So maybe the kernel driver is waiting for some reaction of the ethernet device. | 18:59 |
| stekern | I'm looking at it now | 18:59 |
| stekern | sounds plausible | 18:59 |
| poke53281 | and 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 |
| stekern | can't say I'm familiar how qemu works neither | 19:02 |
| poke53281 | In 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 |
| poke53281 | Arghh, Linux crashes again in or1ksim. The third time that I have the problem. | 19:21 |
| poke53281 | No error message, just no response. | 19:23 |
| poke53281 | I use the current git repository from jonas. | 19:23 |
| poke53281 | no specialties | 19:24 |
| poke53281 | FAIL: gcc.c-torture/execute/20071213-1.c | 21:19 |
| poke53281 | varargs with long long int | 21:20 |
| --- Log closed Tue Jul 16 00:00:29 2013 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!