| *** tpb has joined #tomu | 00:00 | |
| *** rohitksingh has joined #tomu | 03:21 | |
| *** rohitksingh has quit IRC | 04:16 | |
| daurnimator | okay back again | 06:52 |
|---|---|---|
| daurnimator | I wrote a little program that prints hello world in a loop while counting | 06:53 |
| daurnimator | it seems to stop at hello world 8539 | 06:53 |
| daurnimator | gdb tells me its in `#0 0x000015d8 in ?? ()` | 06:54 |
| daurnimator | Note: CPU is currently in a trap: Supervisor external interrupt at 0x00001390 | 06:54 |
| xobs | Hmm... Can't print out the debug symbols. | 07:10 |
| xobs | Try doing add-symbol-file on https://github.com/im-tomu/foboot/blob/master/releases/v2.0.3/pvt-foboot-v2.0.3.dfu | 07:11 |
| tpb | Title: foboot/pvt-foboot-v2.0.3.dfu at master · im-tomu/foboot · GitHub (at github.com) | 07:11 |
| xobs | Then add a breakpoint on trap_entry | 07:11 |
| xobs | I.e. Download the elf, then inside gdb run "add-symbol-file pvt-foboot-v2.0.3.elf 0" | 07:12 |
| xobs | Sorry, I probably shouldn't be doing this while on the train. I mean https://github.com/im-tomu/foboot/blob/master/releases/v2.0.3/pvt-bios-v2.0.3.elf | 07:12 |
| tpb | Title: foboot/pvt-bios-v2.0.3.elf at master · im-tomu/foboot · GitHub (at github.com) | 07:12 |
| daurnimator | Have you ever had an issue where the led is purple when trying to do a colour wheel | 07:19 |
| daurnimator | but then when I single step through it.... it goes blue? | 07:19 |
| daurnimator | (I'm working on two issues in parallel here) | 07:29 |
| daurnimator | going back to the debug mode issues: I'm having trouble even getting it stuck in that routine again. The device is now not responding to wishbone requests | 07:29 |
| xobs | When that happens, do you see it disappearing with "dmesg"? That's the sort of thing that'll happen when something else tries to request a descriptor from the device when it's in that mode. | 07:31 |
| *** krogozinski has quit IRC | 07:38 | |
| daurnimator | yes | 07:49 |
| *** krogozinski has joined #tomu | 08:02 | |
| daurnimator | xobs: so how do I debug that? | 08:03 |
| xobs | Does it happen after you type a command? Or is it something else that's trying to enumerate usb? | 08:22 |
| daurnimator | nope | 08:22 |
| daurnimator | happens after I dfu-util up my code. it *might* run for a few milliseconds, but then it drops off usb | 08:22 |
| xobs | Do you see error messages in dmesg about it not responding, or does it simply disconnect? | 08:23 |
| daurnimator | just disconnects | 08:24 |
| xobs | If you run "hexdump -C debug.bin | head" on the resulting binary, do you see the magic hex value anywhere in there? | 08:24 |
| xobs | See if "5a 07 69 b4" is anywhere in there. | 08:25 |
| daurnimator | its not there until `000011e0` | 08:26 |
| xobs | That's why it's disconnecting, thenm. You need to put that in the first 64 words (256 bytes). | 08:26 |
| daurnimator | hmmm... that's what I thought I was doing... I wonder wtf is before it | 08:26 |
| daurnimator | oops | 08:27 |
| daurnimator | sorry. I dumped the .elf file | 08:27 |
| daurnimator | its actually at 000001e0 | 08:28 |
| daurnimator | which I suppose isn't much better | 08:28 |
| xobs | Oh. ` for (i = 0; i < 32; i++) {`. Guess it needs to be in the first 32 words (128 bytes). | 08:28 |
| daurnimator | I still get to ask "wtf is before it" :P | 08:28 |
| daurnimator | okay found the problem.... somehow _start is getting placed at 200401e8 | 08:30 |
| daurnimator | maybe I was just getting lucky before as _start was my *only* symbol in an optimized build | 08:31 |
| daurnimator | xobs: this is where I need to know more about how linker scripts work... `*(.text.start)` => what does that do? | 08:31 |
| daurnimator | is that telling the linker to put the link section ".text.start" first? | 08:32 |
| daurnimator | or is it saying the symbol "start" in the .text section? | 08:32 |
| xobs | It says to insert everything in the ".text.start" section at that address. | 08:32 |
| daurnimator | or something else | 08:32 |
| daurnimator | okay so I at least guessed that correctly | 08:32 |
| daurnimator | so now..... why *isn't* that happening | 08:33 |
| daurnimator | o.o its like my linksection attribute is getting ignored | 08:34 |
| daurnimator | doh, I was silly somewhere else | 08:44 |
| daurnimator | btw, what is the symbol `_gp` for? | 08:44 |
| daurnimator | INFO [wishbone_tool::gdb] unrecognized GDB command: vCont;c:0 | 09:06 |
| xobs | I haven't seen that one myself. I'm assuming it means "continue (thread #0)". | 09:08 |
| xobs | There. I added it as an alias. Released v0.6.6. | 09:12 |
| daurnimator | Got when I tried to use `stepi` | 09:12 |
| xobs | Yes, that appears to be the command for "continue thread 0". | 09:14 |
| xobs | https://sourceware.org/gdb/onlinedocs/gdb/Packets.html#vCont-packet | 09:14 |
| tpb | Title: Debugging with GDB: Packets (at sourceware.org) | 09:14 |
| daurnimator | so now that I have a _start symbol in the right place | 09:16 |
| daurnimator | my setting of bss to 0 seems to be failing somehow? | 09:16 |
| daurnimator | or at least... getting stuck in a loop maybe? | 09:16 |
| daurnimator | but whenever break execution, it seems to be stuck in that loop | 09:17 |
| daurnimator | xobs: now that all patches I needed in zig are upstreamed... would you have time to have a go? | 09:18 |
| xobs | Is your bss aligned on 4-byte boundaries? You can try doing `p/x &_sbss` and `p/x &_ebss` in gdb. | 09:24 |
| daurnimator | yes.... and... they're both 0x10000000 | 09:26 |
| daurnimator | i.e. 0-length bss | 09:26 |
| daurnimator | why the fuck is it even in that loop | 09:26 |
| xobs | That's fine, it means you have no BSS. | 09:26 |
| daurnimator | okay something weird going on in linking.... all the linker things are 429496729 | 09:30 |
| xobs | That's a very strange number. 0x20000000-1. | 09:31 |
| daurnimator | my program sees them as 0x20000000-1. but gdb sees them as 0x10000000 | 09:33 |
| daurnimator | is there something obvious that might be causing that? | 09:33 |
| xobs | You should be looking at the address of them, not the actual value. | 09:33 |
| daurnimator | yes I'm looking at the address | 09:34 |
| xobs | What do you get in gdb when you do `p/x &_sbss` and `p/x _sbss`? Also, `x/x _sbss` | 09:35 |
| daurnimator | (FYI I called it _fbss) | 09:36 |
| daurnimator | 1. 0x10000000 | 09:37 |
| daurnimator | 2. '_fbss' has unknown type; cast it to its declared type | 09:37 |
| daurnimator | 3. same again | 09:37 |
| xobs | You could do `p/x (int)_fbss` | 09:37 |
| daurnimator | `x/x (u32)_fbss` I get: 0xa <_start+10>:0x00000013 | 09:38 |
| xobs | That makes sense. | 09:38 |
| daurnimator | `p/x (u32)_fbss` I get: 0xa | 09:38 |
| daurnimator | huh.... Note: CPU is currently in a trap: Misaligned load address of 0xffffffff at 0x20040904 | 09:39 |
| xobs | Well that looks promising. | 09:40 |
| xobs | What do you get when you do `disassemble 0x20040904`? | 09:40 |
| xobs | Or even `list *0x20040904`? | 09:40 |
| daurnimator | 0x20040904 <+24>:lwa3,0(a1) | 09:40 |
| xobs | You can also do `b 0x20040904` followed by `mon reset`, and then `cont` | 09:41 |
| xobs | That will reset and break on that particular line. | 09:41 |
| *** js has quit IRC | 09:42 | |
| daurnimator | okay... I'm on the line | 09:42 |
| xobs | And I'm guessing `p/x $a1` will give you `0xffffffff`. | 09:43 |
| xobs | What is the line? What does `list` give you? | 09:43 |
| daurnimator | It's in the zig standard library. zig/lib/std/io/out_stream.zig:39 | 09:44 |
| xobs | You can get a backtrace with `bt` and figure out how it got there. | 09:44 |
| xobs | You can go up the stack with `up`, to figure out where it is in your code (if anywhere). | 09:44 |
| daurnimator | I know how it got there... it should be there | 09:45 |
| xobs | But it sounds like it's printing something out, and there is no stdout. | 09:45 |
| daurnimator | I hooked it up to messible | 09:45 |
| xobs | What if you print "self"? | 09:46 |
| xobs | Or, actually, a1 is the "format" argument. | 09:47 |
| daurnimator | xobs: can I walk you through getting to exactly where I am? :) | 09:47 |
| xobs | So something there is printing, but giving you a NULL format string. | 09:48 |
| xobs | Sure. | 09:49 |
| daurnimator | xobs: 1. download and unpack zig master build: https://ziglang.org/download/ | 09:49 |
| tpb | Title: Releases · The Zig Programming Language (at ziglang.org) | 09:49 |
| xobs | Got it | 09:49 |
| daurnimator | checkout my PR https://github.com/im-tomu/fomu-workshop/pull/140/ e.g.: `cd fomu-workshop; git fetch origin refs/pull/140/head; git checkout FETCH_HEAD` | 09:50 |
| tpb | Title: Add zig example by daurnimator · Pull Request #140 · im-tomu/fomu-workshop · GitHub (at github.com) | 09:50 |
| daurnimator | 3. `cd riscv-zig-blink` then run: `../path/to/zig build run` | 09:51 |
| xobs | I get a ton of "error: PathAlreadyExists" messages | 09:52 |
| xobs | Oh, it's just one error, but it's three pages long. | 09:54 |
| daurnimator | huh? which path? | 09:55 |
| xobs | It doesn't specify. And the entirety of the backtrace is in lib\zig\std | 09:56 |
| daurnimator | can you share the output? | 09:56 |
| xobs | https://gist.github.com/xobs/d813a5b2d1161cd009edb22688dc7cdd | 09:57 |
| tpb | Title: zig build run · GitHub (at gist.github.com) | 09:57 |
| daurnimator | oh you're on windows, interesting | 09:57 |
| daurnimator | ugh, I actually have a PR that tidies up those code paths. | 10:02 |
| daurnimator | (but I didn't finish it for windows yet.... so it won't help you now) | 10:02 |
| daurnimator | I guess you don't have a linux system handy? | 10:02 |
| xobs | I'll try in a Linux window. | 10:03 |
| xobs | `Unable to spawn llvm-objcopy: FileNotFound`. Are there additional dependencies for zig? | 10:05 |
| daurnimator | ah no. that's in my build.zig file | 10:05 |
| daurnimator | I didn't have binutils riscv objcopy on my machine; but native llvm-objcopy worked | 10:06 |
| daurnimator | in build.zig you can just swap out "llvm-objcopy" for the objcopy you have | 10:07 |
| xobs | So there's this variable `bss` which is a thing, but has an address of 0xffffffc8. | 10:10 |
| xobs | Likewise, &data and &rodata are at really weird locations. | 10:10 |
| daurnimator | &data would be a pointer to the pointer | 10:11 |
| daurnimator | (`data` is what we call a 'slice': its a struct with a pointer `.ptr` and a length `.len`) | 10:12 |
| *** TheJJ has quit IRC | 10:15 | |
| xobs | &data should be the address of data, which is invalid because it looks like the stack pointer is pointing to 0x10020000 for some reason. I manually set it to 0x1001fffc and now at least I'm getting "PANIC: reached unreachable code" | 10:17 |
| xobs | Now, `p &data` gives 0x1001ff88, which looks like the right address for something that lives on the stack. | 10:18 |
| daurnimator | did the preceding `la sp, _fstack + 4` not work or something? | 10:18 |
| xobs | &_fstack is 0x1001fffc, so that's adding 4 to it. | 10:19 |
| xobs | Ah. | 10:24 |
| xobs | `assert(dest.len >= source.len);` -> `p dest: $14 = {ptr = 0x10000000 "\n", len = 0}` `p source: {ptr = 0x200413b4 <panic> "\260\002\004 ", len = 224}` | 10:25 |
| daurnimator | that length is the result of `&_erodata - &_frodata` | 10:27 |
| xobs | Right, but `dest.len` is 0, which is not >= 224. | 10:30 |
| daurnimator | correct: &_fdata and &_edata seem to be the same value? | 10:32 |
| daurnimator | xobs: so where do _fdata and _edata come from? is it metadata from the bootloader somehow? | 10:41 |
| daurnimator | no... they'd have to be hardcoded into the binary. they come from sram ORIGIN in the linker script | 10:42 |
| *** TheJJ has joined #tomu | 10:42 | |
| xobs | So _fdata is the address of the start of data in RAM, frodata is the start of the data as it exists on the storage medium. Since it's in the writable data section, you need to copy the entirety of the section from disk to RAM. | 10:43 |
| xobs | The length of both should be 224. You can ignore _edata since it's somewhat nonsensical. | 10:43 |
| xobs | _edata should be _fdata + (_eroata + _frodata) | 10:43 |
| xobs | * Er, _fdata + (_eroata - _frodata) | 10:44 |
| daurnimator | `.data : AT (ADDR(.rodata) + SIZEOF (.rodata))` <== is this meant to set the size of it somehow? | 10:45 |
| xobs | Ah, okay. So some confusion in the renaming of things. | 10:45 |
| xobs | There's readonly data (,rodata), read-write data (.data), executable data (.text), writable data that happens to be zero (.bss), and stack. | 10:46 |
| xobs | .rodata and .text are effectively the same thing. They live on SPI flash, and are XIP, so you can ignore them. | 10:46 |
| xobs | .bss is all zeroes, so you can ignore that, too. | 10:46 |
| daurnimator | I thought in the linker script it was trying to set .data to be at least the size of .rodata? | 10:46 |
| xobs | .data must live in RAM, but RAM is uninitialized. So pointers all point to the data as if it were in RAM, but the runtime needs to set that up. | 10:47 |
| daurnimator | okay.... so the issue as I see it is that _edata isn't set correctly? | 10:48 |
| xobs | So the linker script tells ld to place the physical bytes in the image just following .rodata, but to make all pointers look like they're in RAM. Specifically, it's setting it up so that the .data section is stored on disk immediately following .rodata. | 10:48 |
| xobs | I think it is, I think it's just that you have no symbols in your data section. | 10:49 |
| daurnimator | okay | 10:49 |
| xobs | That line is trying to copy the entirety of rodata into data, but it needs to copy 0 bytes from &(rodata+rodata.len) into data. | 10:50 |
| daurnimator | so why am I coping from rodata to data again? | 10:50 |
| daurnimator | ah, so I need to just copy from the end of rodata? | 10:50 |
| xobs | Because the data section is stored on flash just after rodata. | 10:50 |
| xobs | Yes. | 10:50 |
| daurnimator | okay, so what's the source slice? `{.ptr = _erodata, .len = &_edata - &_fdata }` ? | 10:51 |
| xobs | Should be. | 10:52 |
| xobs | If you define a variable and it's wrong, then you're off by some :) | 10:52 |
| daurnimator | going back to an earlier question: what's _gp? | 10:53 |
| daurnimator | guard page? | 10:53 |
| xobs | I'm guessing it's "global pointer". | 10:55 |
| xobs | The linker script has some history. | 10:55 |
| daurnimator | Should I remove the bits I don't use/need? | 10:55 |
| xobs | Looks like it came from the riscv group before 2017. | 10:55 |
| daurnimator | e.g. s/_gp/./ | 10:55 |
| xobs | I'd say so, yes. | 10:55 |
| daurnimator | xobs: in wishbone server, because the terminal output is raw, all the log messages don't get printed at the start of a line | 11:03 |
| daurnimator | i.e. after you enter raw mode, make sure you print log messages with \r\n instead of just \n | 11:03 |
| xobs | How do you mean? | 11:03 |
| daurnimator | xobs: e.g. http://sprunge.us/CrGYjY | 11:04 |
| xobs | Hmm... Wonder what I can do about that... | 11:05 |
| xobs | Also, I wonder why I don't see that problem on my systems. Bizarre. | 11:14 |
| daurnimator | pretty normal so far for me to see things like: http://sprunge.us/x4vF7Z | 11:26 |
| daurnimator | WOOOOOO disco | 11:29 |
| xobs | Woo! | 11:29 |
| daurnimator | (I think my sleep function is broken) | 11:31 |
| xobs | That happens. | 11:41 |
| xobs | Here's basically how you'd do msleep: https://github.com/im-tomu/foboot/blob/master/sw/third_party/libbase/time.c#L35-L43 | 11:43 |
| tpb | Title: foboot/time.c at master · im-tomu/foboot · GitHub (at github.com) | 11:43 |
| daurnimator | xobs: you'll see I already have that in src/main.zig | 11:45 |
| xobs | Ah, okay then! | 11:46 |
| daurnimator | pushed current code to same branch | 11:47 |
| daurnimator | if you re-pull you'll get a disco party too :P | 11:47 |
| xobs | It looks like you're treating it as a 32-bit register, but it's really four 8-bit registers, one at 0xe0002800, one at 0xe0002804, one at 0xe0002808, and one at 0xe000280c. | 11:48 |
| xobs | You're only setting the upper 8 bits: https://rm.fomu.im/timer0.html#timer0-load3 (unless `comptime` is somehow spreading it out to four individal writes) | 11:49 |
| tpb | Title: TIMER0 Fomu Bootloader documentation (at rm.fomu.im) | 11:49 |
| daurnimator | ah | 11:54 |
| daurnimator | why is it set out like that? seems very weird | 11:54 |
| xobs | Because on an FPGA, you're mostly routing-constrained. So the CSR bus is 8-bits, which means the router needs to only route 8 wires around. | 11:54 |
| xobs | A 32-bit CSR bus would work, it would just be more difficult to meet timing. | 11:55 |
| daurnimator | So if it does a 32 bit store... what ends up happening? | 11:55 |
| xobs | The upper 24 bits are simply not connected to anything. | 11:56 |
| xobs | Wishbone has all 32-bits hooked up, but all the peripherals are on the CSR bus, which is only 8 bits. So a 32-bit store from the CPU to main memory will send all bits to RAM. | 11:57 |
| daurnimator | okay | 11:58 |
| daurnimator | fixing now :) | 11:58 |
| xobs | But a 32-bit store to anything on the Litex CSR bus (i.e. anything documented on rm.fomu.im) will result in only 8 actual bits stored. | 11:58 |
| thaytan | lol, oops | 12:33 |
| thaytan | I just tracked down strange misbehaviour on my system to me adding /opt/fomu/fomu-toolchain-linux_x86_64-v1.5.3/bin to my PATH | 12:33 |
| thaytan | which gave me an extra, higher priority, copy of python3 | 12:34 |
| xobs | Python is hard. | 12:40 |
| *** rohitksingh has joined #tomu | 13:08 | |
| daurnimator | gdb crash :( https://sourceware.org/bugzilla/show_bug.cgi?id=25470 | 13:09 |
| tpb | Title: 25470 Assertion hit in maybe_negate_by_bytes (at sourceware.org) | 13:09 |
| daurnimator | xobs: my PR has been updated again. | 13:09 |
| daurnimator | before marking the PR ready for merge: how should I hook it up to travis? | 13:12 |
| xobs | daurnimator: gdb crashes a surprising amount :( | 13:16 |
| xobs | Also, will it work on Windows and Mac? | 13:16 |
| daurnimator | xobs: should. just need to fix that issue you hit on windows before | 13:16 |
| daurnimator | ( https://github.com/ziglang/zig/pull/4184 is the upstream issue that I'll fix it in ) | 13:17 |
| tpb | Title: Improvements to std.fs by daurnimator · Pull Request #4184 · ziglang/zig · GitHub (at github.com) | 13:17 |
| daurnimator | xobs: you may also note that I added a build option to specify the objcopy binary. long term that will be inside of zig itself too | 13:28 |
| xobs | Oh, cool! Users who are doing the workshop should have riscv64-unknown-elf-objcopy, and it's nice to know that it won't be needed in the future. | 13:37 |
| daurnimator | TBH I'm not sure why it blinks.... I set ` fomu.RGB.setRegister(.OFR, 0); // Amount of time to stay "off"` | 13:37 |
| daurnimator | ah, of course, I'll update the default so they don't need to pass an extra arg | 13:38 |
| xobs | I think you want IFR to be 0 as well. | 13:39 |
| xobs | Since that number is the time it takes to fade in/out. You don't want to have it fade at all. | 13:40 |
| xobs | That's what I ended up doing in https://github.com/xobs/circuitpython/blob/fomu/ports/litex/common-hal/neopixel_write/init.c#L69-L80 | 13:40 |
| daurnimator | hmm okay. I was copying from https://github.com/im-tomu/fomu-workshop/blob/53cffe1761e24e631d79143ff05f36c27bb86885/riscv-blink/src/rgb.c#L41-L42 | 13:41 |
| tpb | Title: fomu-workshop/rgb.c at 53cffe1761e24e631d79143ff05f36c27bb86885 · im-tomu/fomu-workshop · GitHub (at github.com) | 13:41 |
| daurnimator | xobs: I decided to stick with the C one | 14:04 |
| daurnimator | it is called "blink" after all | 14:04 |
| daurnimator | not "rainbow" | 14:04 |
| xobs | It may be worth it to rework it. I like rainbows, and as you've noted the fade behavior is somewhat unintuitive. | 14:07 |
| daurnimator | xobs: anything else you'd like me to add to the PR? | 14:08 |
| xobs | Eventually we should add it to the actual page as a section in the workshop. | 14:10 |
| xobs | Can you add information on how to install Zig? | 14:11 |
| daurnimator | "goto https://ziglang.org/download/ and follow the instructions you feel are most relevant for you" ? :p | 14:12 |
| tpb | Title: Releases · The Zig Programming Language (at ziglang.org) | 14:12 |
| daurnimator | added a little bit to the readme | 14:37 |
| *** rohitksingh has quit IRC | 14:50 | |
| daurnimator | Now moving on to the verilog part of the workshop :P | 14:52 |
| daurnimator | ==> it doesn't blink! | 14:52 |
| daurnimator | http://sprunge.us/VA78cn | 14:52 |
| xobs | I thought you had a PVT board and not a hacker board. | 14:53 |
| daurnimator | I do I think? | 14:55 |
| xobs | That command is using the PCF file for the hacker board. | 14:56 |
| xobs | The minimal blink example looks like it only works for Hacker boards, which probably should be considered a bug. | 14:58 |
| daurnimator | huzzah, the expanded example works | 15:04 |
| * daurnimator learnt vhdl in uni; verilog is new to me | 15:06 | |
| xobs | Eventually we'll have vhdl. I think. | 15:08 |
| *** emeb has joined #tomu | 15:20 | |
| daurnimator | xobs: thanks for helping me be stupid with linker files | 15:44 |
| daurnimator | I understand them better now :) | 15:44 |
| *** rohitksingh has joined #tomu | 15:48 | |
| *** im-tomu has left #tomu | 16:24 | |
| *** im-tomu has joined #tomu | 16:24 | |
| acathla | I broke my fomu :( where can I order a new one? xobs? | 16:42 |
| *** rohitksingh has quit IRC | 16:48 | |
| *** rohitksingh has joined #tomu | 16:57 | |
| *** im-tomu has left #tomu | 17:26 | |
| *** im-tomu has joined #tomu | 17:27 | |
| *** rohitksingh has quit IRC | 17:48 | |
| *** rohitksingh has joined #tomu | 17:49 | |
| *** im-tomu has left #tomu | 18:36 | |
| *** im-tomu has joined #tomu | 18:37 | |
| *** rohitksingh has quit IRC | 19:14 | |
| pollo | acathla: Crowdsupply: https://www.crowdsupply.com/sutajio-kosagi/fomu | 19:21 |
| pollo | because of manufacturing problems, there might be a delay before they get shipped though: https://www.crowdsupply.com/sutajio-kosagi/fomu/updates/pcbs-are-here | 19:22 |
| *** rohitksingh has joined #tomu | 19:31 | |
| *** rohitksingh has quit IRC | 19:47 | |
| *** coderobe3 has joined #tomu | 19:49 | |
| *** Vercas_ has joined #tomu | 19:50 | |
| *** coderobe has quit IRC | 19:51 | |
| *** coderobe3 is now known as coderobe | 19:51 | |
| *** Vercas has quit IRC | 19:51 | |
| *** rohitksingh has joined #tomu | 20:03 | |
| acathla | pollo, thank you. | 20:10 |
| *** rohitksingh has quit IRC | 20:16 | |
| *** js has joined #tomu | 20:23 | |
| *** spacekookie_ has joined #tomu | 20:26 | |
| *** xantoz has quit IRC | 20:27 | |
| *** pollo has quit IRC | 20:27 | |
| *** pollo has joined #tomu | 20:28 | |
| *** js has quit IRC | 20:28 | |
| *** spacekookie has quit IRC | 20:28 | |
| *** rohitksingh has joined #tomu | 20:29 | |
| *** xantoz has joined #tomu | 20:30 | |
| *** kgugala has quit IRC | 20:35 | |
| *** rohitksingh has quit IRC | 20:39 | |
| *** CarlFK has quit IRC | 21:47 | |
| *** rohitksingh has joined #tomu | 22:56 | |
| *** js has joined #tomu | 23:08 | |
| *** rohitksingh has quit IRC | 23:14 | |
| *** CarlFK has joined #tomu | 23:28 | |
| *** im-tomu has left #tomu | 23:30 | |
| *** im-tomu has joined #tomu | 23:30 | |
| *** CarlFK has quit IRC | 23:37 | |
| *** CarlFK has joined #tomu | 23:38 | |
| *** CarlFK has quit IRC | 23:44 | |
| *** Vercas_ is now known as Vercas | 23:44 | |
| *** GNUtoo has quit IRC | 23:51 | |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!