| --- Log opened Thu Oct 03 00:00:23 2013 | ||
| stekern | juliusb: https://github.com/openrisc/or1k-src/commit/91b66cfebad3af4240248ac0f250b8caf4b8eb8a | 02:58 |
|---|---|---|
| stekern | oh, and just to make sure we still have a known "good" or1k-src, I tagged the commit before the upstream merge: https://github.com/openrisc/or1k-src/tree/or1k-pre-upstream-merge-20130930 | 04:49 |
| olofk | Morning | 05:52 |
| stekern | morning | 05:52 |
| Powermaniac | Good Afternoon xD | 05:52 |
| stekern | ah, right, there down under you live in the future! | 05:53 |
| Powermaniac | Haha yeah... | 05:53 |
| Powermaniac | Funny when people talk about the end of the world being on a specific date but don't say what time/timezone | 05:54 |
| Powermaniac | It's like nope we are still here | 05:54 |
| stekern | _franck_: http://pastie.org/8373934 | 06:03 |
| stekern | ? | 06:03 |
| stekern | olofk: that's a major missing feature, ignore parsing (or at least don't except out on) other boards than the one you are currently building | 06:04 |
| stekern | otoh, you find bugs faster this way ;) | 06:04 |
| stekern | a WARNING might have the same effect though | 06:05 |
| stekern | juliusb: I get that weird tick timer behaviour now as well... | 07:03 |
| _franck_ | stekern: yeah I know, it works with python 3.3 | 07:03 |
| _franck_ | you need to remove leading spaces | 07:03 |
| stekern | *I* need to remove? =) | 07:04 |
| _franck_ | :) | 07:04 |
| _franck_ | I'll push something today ;) | 07:05 |
| stekern | juliusb: I mean, the SR has some weird value so the tick timer interrupt isn't being enabled | 07:05 |
| stekern | but I can write sr to 1 and then restart the program to cure that | 07:05 |
| stekern | so it's no real showstopper I guess, but will take a closer look at that at some point | 07:06 |
| olofk | stekern: Yes, I remember you mentioned that bug earlier. I know what to fix, but haven't had time to do it | 07:09 |
| olofk | It's an unhandled exception configparser.readfp | 07:10 |
| olofk | so line 30 in orpsocconfigparser should be something like try; self.readfp(f); except <WhateverTheErrorIs>; raise SyntaxError("Malformed statement in " + config_file) | 07:15 |
| stekern | but wouldn't that make it bail out with a SyntaxError then? | 07:24 |
| stekern | juliusb: here's a microwaveable linux image for de0_nano orpsocv3 edition | 07:50 |
| stekern | http://oompa.chokladfabriken.org/openrisc/vmlinux-de0_nano | 07:50 |
| stekern | it's minimal, but it's got some heartbeat led blinking going on | 07:54 |
| stekern | and you should be able to control the leds through /sys/class/leds/ledX/brightness | 07:54 |
| stekern | and coremark is included | 07:55 |
| olofk | stekern: That is taken care of already. If orpsocconfigparser returns SyntaxError, the core is ignored | 07:56 |
| stekern | ah, I see | 07:56 |
| olofk | ...I think :) | 07:57 |
| _franck_ | pull request ready | 07:57 |
| juliusb | stekern: excellent, thanks so much | 08:13 |
| juliusb | i came across that syntax error last night in ORPSoCv3 too in the de1 board, I tried to have a hack to make it completely ignore any board port it couldn't parse properly but couldn't quite make it work properly | 08:14 |
| juliusb | so, I caught the configparser.pareseerror or whatever it is, raised a Syntax error and it didn't fall over there but there were other bits of the scripts which fell over, still | 08:16 |
| stekern | juliusb: so, you reckon the debug reset should be included in the mor1kx reset? | 08:30 |
| juliusb | mmm, maybe | 08:30 |
| juliusb | it works for me | 08:30 |
| juliusb | basically you should reset everything except the debug core with it (although not the PLL, I don't think I'm doing that with it) | 08:30 |
| stekern | I'm still using an old openocd for the de0_nano (I have different config in the new one I have) and that one doesn't support the reset command | 08:33 |
| stekern | I should fix so I can use the new one with both... but right now it didn't feel like the moment | 08:34 |
| juliusb | hehe fair enough | 08:34 |
| stekern | but it didn't seem to break anything to add that reset (it shouldn't since it doesn't get asserted I presume) in my setup | 08:34 |
| stekern | I agree that it should reset the whole system, because just resetting the cpu might leave the rest in a funny state | 08:36 |
| stekern | especially if its reset in the middle of a wishbone transaction | 08:36 |
| stekern | which is pretty likely to happen | 08:37 |
| juliusb | hmm, downloading the kernel and then htiting resume doesn't run it, I have to hit reset | 08:37 |
| juliusb | ... but I can do that :) | 08:38 |
| stekern | that doesn't sound surprising, loading the kernel with gdb have always been troublesome I think | 08:38 |
| juliusb | haa | 08:38 |
| juliusb | well, baremetal stuff works | 08:38 |
| juliusb | why not this big guy? anyway, it's going to work for the workshop :) | 08:38 |
| juliusb | got it booting fine now | 08:38 |
| juliusb | thanks so much stekern | 08:39 |
| stekern | I'm not sure, but it's probably that the cpu is in some state that it doesn't like | 08:39 |
| juliusb | linux seems a lot more responsive now | 08:39 |
| _franck_ | juliusb: another thing with openocd, you can read/write registers with "reg" command | 08:39 |
| juliusb | is it the hw tlb stuff? | 08:39 |
| juliusb | _franck_: cool, I have been doing that to set the npc with "reg npc 0x100" before trying "resume" | 08:39 |
| _franck_ | ok | 08:40 |
| stekern | so, this is the sequence I usually do, and it's pretty foolproof: reset board (by push button or reloading the fpga image), set sr to 1, load image, set npc to 0x100, go! | 08:41 |
| stekern | actually, to make it even more foolproof, you should write 0 to 0x100 and 0x104 before resetting the board too | 08:42 |
| stekern | to make sure it not start anything funny until you've connected the debugger | 08:43 |
| stekern | juliusb: no, the hw-tlb reload isn't enabled | 08:43 |
| jeremybennett | I see we have a sudden flurry of sign-ups for ORCONF - now 30 people attending! | 08:43 |
| stekern | but what are you comparing to? | 08:44 |
| juliusb | stekern: that usually works well? | 08:44 |
| juliusb | stekern: im comparing to Linuxes of the past | 08:45 |
| juliusb | it could be the mor1kx is just a better processor than or1200 ever was now :) | 08:45 |
| juliusb | jeremybennett: that's great news! | 08:45 |
| juliusb | A new guy at work who's posted some work online on OpenCores is coming along | 08:45 |
| juliusb | jeremybennett: I'm wondering if we need a mail shot to those attending to ask them to do the workshop preparation | 08:46 |
| stekern | juliusb: yes, it works well, but it's not enabled in the de0 nano config by default. | 08:46 |
| juliusb | ah right | 08:47 |
| juliusb | does the kernel automatically detect it and use it if it's there? | 08:47 |
| stekern | and yes, of course it's a lot better processor than or1200 ever was ;) | 08:47 |
| juliusb | because it'd be a simple case of updating the de0 nano port in my tree (which we'll use for the workshop) | 08:47 |
| stekern | In my patches to make it work you have to enable a config option to turn it on in the kernel too | 08:48 |
| jeremybennett | juliusb: Good reminder I'll get Andrew to do that today. Could you make sure he has a copy of the latest details. | 08:49 |
| juliusb | they're available on the workshop page: http://opencores.org/or1k/ORCONF2013_Workshop_ORPSoC_On_DE0_Nano#Tool_installation | 08:50 |
| stekern | it would be possible to autodetect it, but for now I wanted the possibility to manually control if it's used or not (regardless whether the hw supports it or not) | 08:50 |
| juliusb | ok, cool | 08:51 |
| stekern | but, for anything included in the de0 nano image, you wouldn't notice any difference with it anyways, the memory usage is just too low | 08:51 |
| juliusb | fair enugh | 08:51 |
| jeremybennett | juliusb: Are you available for a call just to check we have everything ready for the weekend. Sometime this afternoon or early evening. | 08:52 |
| stekern | juliusb: can you test if the led controlling works? or did you leave the board already? | 08:52 |
| stekern | I have never actually tested that | 08:52 |
| stekern | via the /sys/class/ interface I mean | 08:53 |
| juliusb | stekern: no, still here, really should go though (been getting to work very late this week!) | 08:53 |
| juliusb | is it easy? | 08:53 |
| stekern | as easy as: echo 255 > /sys/class/leds/led7/brightness | 08:54 |
| juliusb | that turned 1 on | 08:54 |
| stekern | \o/ | 08:54 |
| juliusb | LED7 | 08:55 |
| stekern | what happens if you alter the value? | 08:55 |
| juliusb | nothing... | 08:55 |
| juliusb | no PWM | 08:55 |
| juliusb | I like the heartbeat btw | 08:55 |
| stekern | ok, but on/off is good enough still | 08:56 |
| juliusb | yep :) | 08:56 |
| juliusb | ok got to run, more hacking to come tonight! | 08:57 |
| stekern | cya | 09:02 |
| hansfbaier | stekern: http://pastebin.com/ejzcdVQY | 09:03 |
| hansfbaier | uses gui. | 09:03 |
| hansfbaier | stekern: what would be the build workflow: orpsoc build -> error, run qsys -> orpsoc build again? | 09:05 |
| stekern | currently yes, but I want to make orpsoc run qsys when there is no qsys/ directory under build/.../src/ | 09:11 |
| stekern | and then a 'generate' command of some sort to force regenerate it (you could of course do that by simply deleting the qsys/ dir) | 09:12 |
| stekern | so, did you change dash->bash now? | 09:13 |
| hansfbaier | stekern: I fixed it in the one script, but I can try change the system | 09:16 |
| stekern | I would, iirc it just causes more pain than gain to keep dash | 09:16 |
| stekern | s/iirc/imo | 09:17 |
| stekern | I think xilinx scripts barf too when you use dash | 09:17 |
| stekern | for example | 09:17 |
| hansfbaier | stekern: OK, going to reboot | 09:17 |
| hansfbaier | stekern: i switched default shall to bash with dpkg-reconfigure, and rebooted, still same error. weird: | 09:35 |
| hansfbaier | $ sudo debconf-show dash | 09:35 |
| hansfbaier | * dash/sh: false | 09:35 |
| hansfbaier | Now i removed the build/ dir altogether, try starting from scratch | 09:36 |
| stekern | check 'ls -al /bin/sh' too, just to be sure | 09:37 |
| stekern | but what you did check should be enough | 09:37 |
| hansfbaier | lrwxrwxrwx 1 root root 4 Okt 3 16:17 /bin/sh -> bash | 09:37 |
| hansfbaier | grrr | 09:37 |
| hansfbaier | let's wait how the current qsys build turns out | 09:38 |
| hansfbaier | takes forever | 09:38 |
| stekern | yes, that's why I want it to *only* be done when there's no qsys/ dir | 09:38 |
| stekern | or as a forced regeneration | 09:39 |
| juliusb | stekern: did you look at my attempt to get the adv debug sys's reset signal to reset the entire system? | 10:01 |
| stekern | juliusb: ah, sorry, I just noticed that you had pushed changes to your repo | 10:12 |
| stekern | juliusb: that looks right, but I think it'd be nicer to have the "logic" in clkgen | 10:16 |
| olofk | hansfbaier: Are you using the --force swich with orpsoc build? | 10:17 |
| stekern | i.e. a debug_rst input that get connected to wb_rst and a debug_if_rst output to reset the debug_if | 10:17 |
| stekern | https://github.com/juliusbaxter/orpsoc-cores/commit/73c16ace37c888c58c0878f93d853a2e4f764a83#diff-7198d4c7fee4af0516d0fc0b35b4c01dR549 <- I like when the coment says one thing and the code another ;) | 10:19 |
| hansfbaier | olofk: No. didn't know | 10:21 |
| olofk | hansfbaier: It's a pretty crappy feature right now, but build/<system_name> isn't cleaned out unless you run with --force | 10:22 |
| olofk | The idea is that eventually orpsoc will detect if the build directory needs to be cleaned out, but I haven't gotten around to implement that yet | 10:23 |
| stekern | olofk: but that isn't relevant right now, since he has problems before he runs orpsoc build | 10:23 |
| olofk | Not sure if it helps you with your problem, but it might be good to know | 10:23 |
| hansfbaier | olofk: I did rm -rf build before rerunning | 10:23 |
| olofk | That's basically the same thing | 10:23 |
| hansfbaier | stekern: still same error here | 10:23 |
| stekern | hansfbaier: have you tried google? (since this is a quartus failure, chances are that you are not alone experiencing it) | 10:31 |
| stekern | http://macnicatech.com/quartus-make-requirement/ | 10:32 |
| stekern | I assume you have 'make' installed, but there is a comment in the end that might be relevant | 10:33 |
| hansfbaier | stekern: would be difficult to build a linux kernel without make, wouldn't it? ;) | 10:37 |
| stekern | =) | 10:38 |
| hansfbaier | stekern: How would you build orpsoc without make? | 10:38 |
| hansfbaier | stekern: But you are right, I am too lazy | 10:39 |
| stekern | as I said, don't pay attention to the make thing, that's unrelated. the comment in the end might not be | 10:40 |
| hansfbaier | stekern: ah, | 10:41 |
| hansfbaier | I sure am still tired.... Should get more sleep 'ts been 1:30 pm tonight X-] | 10:41 |
| hansfbaier | stekern: It was a path issue obviously. Now I ran Qsys from inside quartus, and then it worked | 11:21 |
| hansfbaier | stekern: the unset DISPLAY did not work | 11:21 |
| stekern | ah, ok | 11:22 |
| stekern | wait a sec... | 11:22 |
| stekern | I've got this in my PATH: $ALTERA_PATH/quartus/sopc_builder/bin | 11:23 |
| hansfbaier | stekern: I did too, but that wasn't enough | 11:23 |
| stekern | odd... I don't have anything else | 11:24 |
| hansfbaier | stekern: weird | 11:24 |
| stekern | do you have ALTERA_PATH exported too? | 11:24 |
| hansfbaier | stekern: it's in my openrisk_env.sh | 11:25 |
| hansfbaier | that means yes | 11:25 |
| stekern | ah, well perhaps we'll find out what's the missing link later, you've got the qsys system generated now at least | 11:26 |
| hansfbaier | orpsoc build is fitting now. Looks good. | 11:26 |
| _franck_ | stekern: running the testsuit on the sync toolchain, I get a lot of these http://pastie.org/8374519 | 11:39 |
| _franck_ | stekern: do you think it's because I didn't compile/install the toolchain correctly ? | 11:39 |
| hansfbaier | stekern: I looks like it's not going to work on a 32bit-machine :( | 11:40 |
| hansfbaier | Out of memory in module quartus_fit (2136 megabytes used) | 11:41 |
| hansfbaier | I have 8G RAM but looks like address space is the problem | 11:41 |
| hansfbaier | http://www.altera.com/support/kdb/solutions/rd11102009_495.html | 11:42 |
| hansfbaier | first time in my life I can't do something without 64bit | 11:43 |
| hansfbaier | grrrrrrr | 11:43 |
| hansfbaier | don't feel like reinstalling everything :( | 11:43 |
| LoneTech | you should not need to. quartus installs with a 64bit version iirc, so you only need some libraries and a 64 bit capable kernel | 11:43 |
| LoneTech | unless you are running on a 32-bit PAE machine.. that would require a cpu replacement | 11:44 |
| hansfbaier | LoneTech: My whole system is 32bit | 11:45 |
| hansfbaier | LoneTech: everything | 11:45 |
| hansfbaier | LoneTech: I installed quartus/32bit | 11:46 |
| LoneTech | really? no quartus/linux64 directory? | 11:47 |
| hansfbaier | LoneTech: Oh there it is, you're right | 11:47 |
| hansfbaier | But the whole Linux system is 32-bit | 11:48 |
| hansfbaier | so how would I run it? | 11:48 |
| hansfbaier | compile a 64bit kernel by hand since the distro (ubuntu precise) does not provide one? | 11:48 |
| LoneTech | I'd be surprised if you don't have a 64bit kernel available | 11:49 |
| LoneTech | start by running uname -a; if it says x86_64 your kernel is already 64bit | 11:49 |
| hansfbaier | LoneTech: No, i686 | 11:49 |
| hansfbaier | LoneTech: I did by default. Since the distro is smaller, saves disk and ram | 11:50 |
| LoneTech | ok, apt-cache search linux-image could show you available kernels; you can likely install linux-image-amd64 | 11:50 |
| * LoneTech uses debian, not too familiar with ubuntu | 11:50 | |
| LoneTech | ideally you could use multiarch to add 64bit libraries | 11:51 |
| LoneTech | but if not, quartus looks for its libraries in the linux64 directory so you could copy them manually there. it's a rather painful process but possible | 11:52 |
| hansfbaier | LoneTech: but i will need a 64 bit kernel | 11:53 |
| LoneTech | yes. was there not one available to install? | 11:54 |
| hansfbaier | LoneTech: No | 11:54 |
| hansfbaier | LoneTech: wait a minute | 11:55 |
| hansfbaier | LoneTech: no | 11:57 |
| LoneTech | perhaps you'd need to enable multiarch first and simply install a 64-bit version of a kernel package | 11:57 |
| hansfbaier | LoneTech: Did not hear about multiarch before. Thanks. Will look | 11:58 |
| LoneTech | multiarch is debian's infrastructure to allow mixing of precisely this sort. most programs don't gain much from running 64bit | 11:59 |
| hansfbaier | LoneTech: As I understand it multiarch still needs a 64 bit system/kernel. You can't run 64 on 32 | 12:02 |
| hansfbaier | https://help.ubuntu.com/community/MultiArch | 12:02 |
| hansfbaier | This is not very helpful | 12:02 |
| LoneTech | yes, you need a 64bit kernel. however, enabling multiarch allows you to install one | 12:02 |
| hansfbaier | LoneTech: How do you do that in debian? | 12:02 |
| hansfbaier | LoneTech: ah got it | 12:03 |
| stekern | _franck_: is that the gdb testsuite? | 12:03 |
| stekern | I think all those are defined in unistd.h | 12:06 |
| stekern | but all your errors are in generic code, nothing in or1k specific code | 12:07 |
| stekern | or is it just that it can't find our definitions of them? | 12:07 |
| hansfbaier | stekern: what distro do you use? ubuntu precise 64bit? | 12:08 |
| stekern | how do you run the gdb testsuite? | 12:08 |
| _franck_ | export DEJAGNU=/home/franck/openrisc/or1k-src-new/site.exp | 12:09 |
| _franck_ | make check RUNTESTFLAGS="--target_board=or1k-elf-sim" | 12:09 |
| stekern | hansfbaier: http://pastie.org/8374607 | 12:09 |
| stekern | 64-bit, yes | 12:10 |
| _franck_ | stekern: I think it can't find our definition of read, write,... | 12:10 |
| _franck_ | stekern: your start the testsuite in ..../bld-or1k-src-new/gdb | 12:11 |
| _franck_ | you have to compile gdb whith --enable-sim and not --disable-or1ksim | 12:12 |
| stekern | _franck_: care to share that site.exp? | 12:13 |
| _franck_ | it's in the repo already | 12:13 |
| _franck_ | you'll need this: http://pastie.org/8374616 | 12:14 |
| hansfbaier | LoneTech: multiarch only works if the system is 64 bit | 12:16 |
| hansfbaier | LoneTech: I can install a 64-Bit VirtualBox VM on the 32 Bit-Sys since my CPU has hardware VIRT | 12:18 |
| stekern | I think you still have to have a 64-bit kernel for that to work? | 12:18 |
| LoneTech | I think you're just seeing bad guides to it. multiarch itself has no such limit | 12:19 |
| LoneTech | dpkg --add-architecture amd64 | 12:20 |
| LoneTech | oh, ubuntu is different. still should be possible. https://wiki.debian.org/Multiarch/HOWTO | 12:21 |
| LoneTech | a foreign-architecture line in /etc/dpkg/dpkg.cfg.d/architectures should do it | 12:21 |
| _franck_ | stekern: http://pastie.org/8374632 | 12:22 |
| stekern | _franck_: feel free to commit that obvious fix pastied above | 12:22 |
| stekern | _franck_: what does that test_read.c look like? | 12:23 |
| _franck_ | http://pastie.org/8374644 | 12:24 |
| stekern | _franck_: compiles fine here | 12:27 |
| stekern | ...and *links* fine too ;) | 12:27 |
| _franck_ | ok, that's what I thought, I'll reinstall the toolchain | 12:27 |
| hansfbaier | LoneTech: # dpkg --add-architecture amd64 | 12:42 |
| hansfbaier | dpkg: error: unknown option --add-architecture | 12:42 |
| LoneTech | yes, the howto I linked noted that ubuntu lacks that option but can be configured with a file | 12:54 |
| jeremybennett | juliusb: You there? | 13:31 |
| _franck_ | stekern: compiled and installed again, same thing.... | 13:53 |
| _franck_ | could you run the gdb testsuite ? | 13:53 |
| _franck_ | (some day, no hurry) | 13:54 |
| stekern | _franck_: I get this kind of errors when I don't have --disable-or1ksim | 14:06 |
| stekern | undefined reference to `or1ksim_read_mem' | 14:06 |
| stekern | I assume I nead some or1ksim libs | 14:06 |
| stekern | *need | 14:06 |
| stekern | can you run 'or1k-elf-gcc -v test.c -o test' on your test program and give me the output? | 14:08 |
| _franck_ | http://pastie.org/8374890 | 14:13 |
| _franck_ | do you still have --enable-sim ? I don't have this error... | 14:13 |
| _franck_ | ah yes, you need or1ksim in the default location | 14:14 |
| stekern | "default location" is? | 14:14 |
| _franck_ | /opt/or1ksim | 14:15 |
| _franck_ | you can also specify the path | 14:15 |
| _franck_ | --with-or1ksim=PATH | 14:15 |
| stekern | ok | 14:16 |
| _franck_ | specify the or1ksim installation directory | 14:16 |
| stekern | why are you calling or1k-elf-gcc with the full path? | 14:17 |
| _franck_ | because I have both installed and my default PTAH is /opt/or1k-toolchain/bin | 14:18 |
| _franck_ | I want to be sure to use the good one | 14:18 |
| stekern | do the new path override the old path still? | 14:19 |
| _franck_ | ? | 14:20 |
| stekern | I mean, is your PATH=/newtoolchain/bin:/oldtoolchain/bin | 14:22 |
| _franck_ | I exported only /opt/or1k-toolchain_new/bin only and run or1k-elf-gcc -v -o test test_read.c | 14:22 |
| _franck_ | same thing | 14:22 |
| stekern | ok | 14:23 |
| stekern | what do you get if you do: or1k-elf-objdump -d 'libc.a' | grep '<close>:' | 14:25 |
| stekern | or '<read>:' for that matter | 14:26 |
| _franck_ | no close nor read | 14:28 |
| stekern | odd | 14:28 |
| _franck_ | I have fopen, fclose | 14:28 |
| _franck_ | I miss a lot of files in libc.a, I'll do a diff | 14:34 |
| _franck_ | http://pastie.org/8374936 | 14:35 |
| olofk | Looks like everything that starts with "sys" is missing | 14:37 |
| _franck_ | all syscalls | 14:45 |
| _franck_ | in my build dir, or1k-elf/newlib/libc/syscalls/ is empty ..... | 14:46 |
| stekern | weird... | 15:15 |
| stekern | I'll try rebuilding here too to make sure... | 15:16 |
| _franck_ | http://pastie.org/8375081 | 15:28 |
| _franck_ | can't fix and test, I need to go | 15:28 |
| poke53282 | My mailbox is filled with 10 mails regarding two patches in QEMU. Crazy process. | 17:53 |
| stekern | _franck_: bah, that was the missmerge I fixed the last... obviously I screwed that up | 18:07 |
| stekern | http://pastie.org/8375539 | 18:21 |
| stekern | that should fix it | 18:21 |
| stekern | I'm rebuilding now and testing (and remembering to delete the install dir before starting this time...) | 18:21 |
| stekern | Thanks for tracking it down so quickly, should we call it even since you broke my orpsoc this morning? =) | 18:23 |
| _franck_ | we're all settled up now :) | 18:57 |
| stekern | _franck_: great! ;) | 19:50 |
| stekern | rebuilt and tested now, at least everything seems fine here(tm) | 19:51 |
| stekern | I'll push that fix then | 19:51 |
| _franck_ | where can I find the upstream repo we are synchronizing to ? | 19:52 |
| _franck_ | I wanted to take a look at configure.host but couldn't find it in newlib official | 19:53 |
| stekern | https://sourceware.org/cgi-bin/cvsweb.cgi/src/?cvsroot=src#dirlist | 19:54 |
| _franck_ | is there a gnu/src with all inside ? | 19:54 |
| _franck_ | ok thanks | 19:54 |
| stekern | I also pushed the "clean" cvs update branch | 19:59 |
| stekern | https://github.com/openrisc/or1k-src/tree/upstream-cvs | 20:00 |
| stekern | so that is the cvs tree at the snapshot moment | 20:00 |
| stekern | I just finished off my slides for the mor1kx cappuccino presentation too! | 20:02 |
| juliusb | stekern: nice. I haven't done anything yet :( | 22:28 |
| --- Log closed Fri Oct 04 00:00:24 2013 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!