| -!- maximi89 is now known as maximi891 | 04:38 | |
| -!- maximi891 is now known as maximi892 | 04:39 | |
| -!- maximi892 is now known as maximi893 | 04:39 | |
| -!- maximi893 is now known as maximi89 | 04:39 | |
| -!- maximi89 is now known as maximi895 | 04:43 | |
| -!- maximi895 is now known as maximi89 | 04:44 | |
| -!- maximi89 is now known as maximi894 | 04:56 | |
| -!- maximi894 is now known as maximi89 | 05:04 | |
| -!- maximi89 is now known as MRY | 05:10 | |
| -!- MRY is now known as MRP | 05:10 | |
| -!- MRP is now known as MRT | 05:10 | |
| -!- MRT is now known as maximi89 | 05:12 | |
| stekern | some progress: http://pastie.org/4788824 | 06:00 |
|---|---|---|
| stekern | jeremybennett: you around? | 13:51 |
| stekern | I've been using your or32-linux-sim target board description to do linux/uclibc regression tests, but I've left out the "getip" stuff | 13:53 |
| stekern | and instead I pass the IP through an environment variable, but I wonder if that's the preferred way to do it? | 13:53 |
| stekern | (this of course disables the parallellism that you intended, but I don't feel like hassling with that) | 13:55 |
| jeremybennett | stekern: I am around | 13:55 |
| jeremybennett | That sounds a reasonable thing to do. It's a left over when Linux wouldn't stay up for very long, and so we had to be able to robustly restart sessions. | 13:56 |
| stekern | I'd also like to pass the path to gcc and g++ to the target board file, so I don't need that hardcoded in there | 13:56 |
| jeremybennett | Correct - that's an ancient historic legacy. | 13:56 |
| stekern | ok, good, so is passing stuff into the target board file through the env the right way to do that? | 13:57 |
| jeremybennett | Sometimes. Mostly it's through setting board parameters in the .exp file. | 13:58 |
| jeremybennett | set_board_info covers most things. | 13:58 |
| stekern | yes, but setting things in an .exp file is what I try to avoid | 14:00 |
| jeremybennett | set_board_info compiler "[find_gcc]" should suffice for the compiler. All the GCC_UNDER_TEST/GXX_UNDER_TEST stuff is not needed, nor do you need set_board_info for compiler and c++compiler | 14:00 |
| stekern | right now I run the regression suite by: make check RUNTESTFLAGS="--target_board=or1k-linux-sim --target_triplet=or1k-unknown-linux-gnu" OR1K_IP="192.168.255.200" | 14:01 |
| jeremybennett | The .exp file is where you define what the board does. | 14:01 |
| jeremybennett | So if it is a property of the board (for example if it supports interrupts) it does there. | 14:01 |
| jeremybennett | Fine to put variables like the specific IP address in the environment | 14:01 |
| jeremybennett | That's not a property of the board, but of the particular instance of a test run. | 14:02 |
| stekern | yes, exactly. | 14:02 |
| stekern | but [find_gcc] will use the just built gcc, right? | 14:03 |
| stekern | and not an installed one | 14:03 |
| jeremybennett | Which is usually what you want. My hacks were about forcing an installed one to be sued. | 14:03 |
| jeremybennett | used | 14:03 |
| jeremybennett | Which latterly was wrong! | 14:04 |
| stekern | ah, well if you do make && make install it shouldn't matter ;) | 14:04 |
| stekern | but if you've configured with --with-sysroot= it should find the right libs anyway | 14:05 |
| stekern | but I like that hack, since I'd like to try out running the regression suite with clang/llvm in the future and now I know how to do that ;) | 14:05 |
| jeremybennett | Yes - you'll need it for Clang/LLVM. We'll be interested in seeing how you get on with that. We can discuss in Sweden next month | 14:08 |
| stekern | definitely | 14:14 |
| stekern | another question: in what situations should crt0 and in what should crt1 be used? | 14:37 |
| stekern | googling for it gives mixed answers | 14:38 |
| jeremybennett | I don't know much about crt1. I've always used crt0. | 15:34 |
| stekern | i386 seems to use crt0 when -static is passed | 15:39 |
| stekern | we have a halfbaked crt1.S in uClibc too | 15:39 |
| stekern | either way, I've added PIC support in crt0.S (it's needed for PIE support), so I'll continue to use that for now | 15:40 |
| * _franck_ don't know with his de1 board being unstable | 18:44 | |
| _franck_ | sometimes it works sometimes not | 18:44 |
| _franck_ | SDRAM problem ? It works fine with NIOS.... | 18:44 |
| stekern | what sdram controller is used when you run nios? | 18:59 |
| stekern | can you try using that and see if it's unstable then too? | 18:59 |
| _franck_ | I can't because it is only available in sopc builder / qsys | 19:04 |
| _franck_ | I'll try your old version of sdram controller and versatile_mem_controller too | 19:05 |
| _franck_ | where is the versatile controller version in your de2-115 port coming from ? | 19:06 |
| _franck_ | not the opencores svn repo | 19:06 |
| stekern | from the actel board port | 19:06 |
| _franck_ | ah ok, the actel port is from opencores team | 19:07 |
| stekern | what is the output from sopc? | 19:08 |
| _franck_ | a blackbox | 19:08 |
| _franck_ | may be I could only put the sdram controller and export all signals | 19:09 |
| _franck_ | I don't know if it works | 19:09 |
| stekern | yeah, that what I was thinking | 19:09 |
| stekern | I think I've done something like that | 19:09 |
| _franck_ | then I need use an arbiter and no burst | 19:10 |
| stekern | true, perhaps it's not worth the trouble | 19:12 |
| _franck_ | qsys is happy with a clock source and the sdram controller only... | 19:14 |
| -!- Netsplit *.net <-> *.split quits: tawm, esg | 21:47 | |
| -!- Netsplit over, joins: tawm | 21:48 | |
| -!- Netsplit *.net <-> *.split quits: juliusb, larks, Fallenou, orsoc1_, gxti, O01eg, kristianpaul, tawm, simoncook, heroux, (+2 more, use /NETSPLIT to show all of them) | 23:54 | |
| -!- Netsplit *.net <-> *.split quits: esg_, derRichard, jonibo | 23:55 | |
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!