**** BEGIN LOGGING AT Wed Feb 22 03:00:02 2017 Feb 22 03:48:08 greetings. Feb 22 03:48:20 would anyone here happen to have experience with baremetal programming on the beaglebone black? Feb 22 03:55:07 * fouric should probably actually ask his question to lure in unsuspecting hardware hackers Feb 22 03:55:29 i'm a university student who had the opporunity to play around with a bbb last term for a computer engineering class Feb 22 03:56:12 the setup that we used was ti's usb100v2 (i think, there's also an xds100v2?), a beaglebone black, and ti's codecomposer studio on the software studio Feb 22 03:56:59 ...unfortunately, ccs is kind of...not a very good ide, to say the least Feb 22 03:57:34 i managed to track down the linaro gcc toolchain that ccs installed on my machine, so now i can (theoretically) compile code for the bbb Feb 22 03:57:43 however Feb 22 03:58:23 i haven't actually been able to find a way to *load* code onto the bbb without using u-boot, which would necessitate a power-cycling of the bbb *every time i wanted to reload my code* Feb 22 03:59:09 ti's setup appears to merely plop the object code into the sram of the bbb and reset the instruction pointer to point to the entry point without doing any powercycling at all Feb 22 03:59:56 ...but i haven't been able to replicate that using openocd (as afaik there aren't any other debugging toolchains than openocd and ccs) using either ti's usb100v2 OR tin can tools' flyswatter2 Feb 22 04:00:54 have any of you done this (loading code onto a bbb without either ccs or powercycling) before? Feb 22 04:00:59 if so, how? if not, why? Feb 22 04:01:15 * fouric has been trolling the internet and throwing various configuration files at openocd for about two weeks now Feb 22 06:11:04 hi guys.... I have lost SD card from my BBB. It was working fine last night. But now its like SD card not exist in BBB Feb 22 06:11:20 no traces in fdisk -l or df -h Feb 22 06:11:42 I checked and verified fstab file in etc but all configs are same as expected Feb 22 06:11:48 what could have happened. Feb 22 06:11:51 Any suggestion Feb 22 06:11:52 ?? Feb 22 06:14:05 dmesg? Feb 22 06:15:41 anything in particular i should be looking for Feb 22 06:15:42 ?? Feb 22 06:16:09 I suggest anything to do with *mmcblk* Feb 22 06:16:42 you're definitely sure its securely plugged in? Feb 22 06:17:00 yep its plugged in Feb 22 06:17:07 checking log Feb 22 06:28:43 here is my dmesg output with mmcblk Feb 22 06:28:44 http://pastebin.com/tEMMPDtj Feb 22 06:45:08 ver|laptop: any idea Feb 22 06:45:08 ?? Feb 22 07:05:59 how to connect bb black with blackhawk usb 560m Feb 22 07:11:41 hello Feb 22 07:14:06 fouric: hold on, lemme read back what you said Feb 22 07:18:27 fouric: my suggestion for baremetal development: let the bbb's bootrom or u-boot (either choice has pros and cons) fetch your application from your computer over the network (bootp/tftp). when you recompile, just reset the bbb (e.g. via jtag) and it'll fetch and run the new version Feb 22 07:21:33 when not using u-boot, this whole process (reset, acquire ip via bootp, fetch code via tftp) happens essentially instantly. Feb 22 07:21:46 hi guys.... I have lost SD card from my BBB. It was working fine last night. But now its like SD card not exist in BBB. no traces in fdisk -l or df -h. I checked and verified fstab file in etc but all configs are same as expected. what could have happened. Any suggestion ?? Feb 22 07:23:45 SAK: that's.. weird. you probably tried rebooting already? can you paste kernel log? Feb 22 07:24:02 yep I have tried many times Feb 22 07:24:33 yep i have restarted manuy times Feb 22 07:24:47 kernel logs.... you mean dmesg Feb 22 07:24:47 ?? Feb 22 07:25:30 fouric: here's a tiny tiny application along with info on various ways the bbb can load it btw => https://github.com/mvduin/bbb-asm-demo Feb 22 07:25:33 SAK: yes Feb 22 07:27:11 here it is http://pastebin.com/ZccdJqFH Feb 22 07:29:19 it's like it's literally not seeing any card Feb 22 07:30:03 yep I noticed that same behavior in df -h and fdisk -l Feb 22 07:31:28 those might not show anything if there was an error, but the kernel log it also not showing any errors for it. in fact it detected the card slot since I see it requested the CD (card detect) gpio Feb 22 07:33:06 seems like card just crashed or something Feb 22 07:33:24 SAK: can you check on the status of that card-detect gpio? e.g. using my show-pins utility ( https://github.com/mvduin/bbb-pin-utils ) you can do: show-pins -v | grep cd Feb 22 07:33:57 it should show "gpio 0.06 << hi" if no card is inserted and "<< lo" if a card is inserted Feb 22 07:36:54 can you think of anything you did/changed between the last time the card slot was working and the first time it wasn't working Feb 22 07:36:57 ? Feb 22 07:39:30 how can i use pin-utils Feb 22 07:39:50 nothing was changed much since last time it worked good and first time it didn't Feb 22 07:40:09 I had a desktop utility which ssh some command and closed it Feb 22 07:40:20 later on cd /card it shows only one file Feb 22 07:40:34 i had 20 files atleast in sd card names as /card Feb 22 07:41:08 also yesterday's kernel log shows card present Feb 22 07:41:15 it is 8 GB card Feb 22 07:59:56 ok.... I was unable to run that show-pins. but upon debugging the script i went directly into /sys/kernel/debug/gpio Feb 22 08:00:16 I foung gpio 6 (cd hi Feb 22 08:00:26 it emans there is no sd card atached Feb 22 08:00:44 zmatt: am i correct Feb 22 08:00:52 ?? Feb 22 08:01:31 this it the exact line " gpio-6 (cd ) in hi IRQ" Feb 22 13:21:49 hello :) Feb 22 13:28:15 echo :) **** BEGIN LOGGING AT Wed Feb 22 13:31:50 2017 Feb 22 14:07:00 I am using beagle board 2008 version.It has DVI-D output to connect to dvi displays.can i use DVI to hdmi connector to connect it to hdmi display?? Feb 22 16:10:12 zmatt: thank you for your response! :D Feb 22 16:12:21 hm...does "reset halt" in OpenOCD reset the bbb in the way that you were suggesting? Feb 22 16:18:14 fouric: reset halt should not be used. in general, openocd behaves in ways that are much more appropriate for microcontrollers than for something as big as the AM335x Feb 22 16:18:55 the problem with reset halt is that it halts the core immediately after reset Feb 22 16:19:37 that will be at 0x20000 at the start of public ROM Feb 22 16:19:47 (you can't halt the core while executing secure ROM( Feb 22 16:19:50 ) Feb 22 16:20:49 if you'd try to upload a program into SRAM you'll immediately get errors since the L3 SRAM hasn't been enabled yet in PRCM Feb 22 16:21:27 because you've halted the core before public ROM code could do the necessary SoC initialization Feb 22 16:21:51 which also includes e.g. the PLLs Feb 22 16:22:44 hence my suggestion to just let the core run and just let ROM fetch your program Feb 22 16:23:03 or let ROM fetch u-boot and let u-boot fetch your program Feb 22 16:23:04 * fouric scribbles furiously Feb 22 16:23:17 i didn't even know that there was a public/private division in rom Feb 22 16:23:37 or that there was a difference between resetting the core and powercycling it Feb 22 16:23:44 the docs mostly pretend secure ROM doesn't exist :) Feb 22 16:24:00 security by obscurity :P Feb 22 16:24:19 hm, i have the feeling that this process would be a lot easier if i knew more about it Feb 22 16:24:32 you also can't read its contents, although they fucked up that protection on a related SoC so I have a pretty good idea what it does Feb 22 16:24:40 (on GP targets: very little) Feb 22 16:24:52 do you have a suggestion other than just reading through the am335x docs? Feb 22 16:25:57 zmatt: does your github code include a little rom program that does that? Feb 22 16:26:12 (fetches my code from my dev machine) Feb 22 16:26:21 ...or is it already built-in? Feb 22 16:26:45 well, for the most part you can indeed pretend secure ROM doesn't exist... it just explains why the cortex-a8 after reset seems to come up in public world at 0x20000 instead of in secure world at 0x0 Feb 22 16:27:28 the ROM bootloader can do bootp/tftp boot yes Feb 22 16:27:47 neet Feb 22 16:27:49 note that ROM here really means ROM, i.e. not something you could add afterwards anyway Feb 22 16:28:00 ah k Feb 22 16:28:10 * fouric has heard "rom" be used to mean everything from true rom to flash Feb 22 16:28:20 good to know Feb 22 16:28:43 I've never seen flash memory embedded in a large SoC from any manufacturer... apparently those processes just don't combine Feb 22 16:29:04 (i didn't know it was actually on the processor though) Feb 22 16:29:07 I've only seen flash+ram Feb 22 16:29:14 * fouric (perhaps foolishly) assumed that it could be on the board Feb 22 16:30:06 fouric: using what interface? how would it be initialized? how would it know the timings to use? :) Feb 22 16:30:26 yup, 100% foolishly Feb 22 16:30:40 actually it was NAND+eMMC+RAM that they put on top of the OMAP3 in the N9 Feb 22 16:30:45 in my defense, (1) it's too early in the morning and (2) i haven't gotten enough sleep over the past few weeks Feb 22 16:30:49 n9? Feb 22 16:30:52 tbr: that's not integrated into the SoC, that's sitting on top of the SoC Feb 22 16:31:05 fouric: psh, who needs sleep Feb 22 16:31:10 zmatt: yes, but presumably RAM+NAND+eMMC were on one die Feb 22 16:31:13 tbr: no Feb 22 16:31:15 zmatt: i dearly wish *i* didn't Feb 22 16:31:29 tbr: it's PoP Feb 22 16:31:41 zmatt: yes, I know. just not sure how many layers Feb 22 16:31:56 oh wait I misread Feb 22 16:32:08 although I also very seriously doubt RAM+NAND are one die Feb 22 16:32:13 probably they're separate dies in one package Feb 22 16:32:45 it might have been NAND+eMMC and RAM on a third die Feb 22 16:32:46 my memory on that is hazy Feb 22 16:33:20 zmatt: afk, thank you very much for your help, kind internet denizen Feb 22 16:33:21 that sounds possible since eMMC is just NAND+controller... not sure why anyone would want NAND+eMMC anyhow Feb 22 16:33:30 fouric: I think I had more info to share.. Feb 22 16:33:38 please do! Feb 22 16:33:53 i have my irc client on a bastion that i keep running through screen Feb 22 16:34:09 fouric: not many people are into trying baremetal dev on big SoCs like this, so I'm glad to give a bit of support to those adventurous enough to try it :) Feb 22 16:34:11 i gotta go afk now but in a few hours i'll be back to look through everything Feb 22 16:34:14 Nokia ran the system and related partitions out of NAND with UBIfs, while user storage was on eMMC Feb 22 16:34:15 :D Feb 22 16:34:21 * fouric -> emag homework Feb 22 16:34:32 fouric: I should probably do shopping first anyway Feb 22 16:35:45 I guess they wanted to avoid a situation where eMMC wear would b0rk the system prematurely. That happened to me on a cheap nokia X (that I got for free), the eMMC barfed during an OTA update and the whole device b0rked. Feb 22 16:37:44 tbr: hmm, eMMC supports hard-partitioning already for that reason... though it's possibly you're describing stuff from an era that predates support for this in eMMC Feb 22 16:37:56 *possible Feb 22 16:40:09 see you folks ;) Feb 22 16:40:42 zmatt: yeah, also Nokia is not necessarily known for the sanest decisions Feb 22 16:40:58 anyway, NAND dies and RAM dies have their own state-of-the-art production lines so you can be certain that any managed NAND (e.g. eMMC or SD) or weird RAM + flash chips use separate dies for those Feb 22 16:41:19 yup Feb 22 16:41:51 the whole MLC/TLC/ETC story is quite funky and probably doesn't lend itself to sharing die with RAM Feb 22 16:42:12 well even if it did, a combined die would mean a custom low-volume die Feb 22 16:42:31 that means you'll be crazy expensive Feb 22 16:42:33 *it'll Feb 22 16:42:50 for the amount of RAM and flash you'll get Feb 22 16:45:13 flash and DRAM are just crazy high-volume near-zero-margin production lines Feb 22 16:45:33 so the latest fabs produce basically only those things Feb 22 16:54:35 zmatt: nokia did crazy things and sometimes managed to convince suppliers to do crazy things. I'm not sure if that particular PoP part was used ever in any other product. That means it's also quite possible that there are still a few hundred thousand or even more of those somewhere in a Salo warehouse or by now in a landfill. Feb 22 16:56:04 Can anybody help me with how to start learning cross-compiling? Feb 22 16:57:15 tbr: which sounds ironic since iirc the beagleboard had issues with finding any supply of suitable PoP memory Feb 22 16:57:44 aman935: same as normal compiling, except with arm-linux-gnueabihf-gcc instead of gcc :) Feb 22 16:58:36 if you use debian or ubuntu you can get a suitable cross-compiler with apt-get install gcc-arm-linux-gnueabihf Feb 22 16:58:52 I use fedoora Feb 22 16:58:57 *fedora Feb 22 17:00:02 they probably have a similar thing, I'm not just familiar with it. you can also get a linaro toolchain: those are portable, i.e. just untar it add its bin-dir to your PATH Feb 22 17:00:16 https://releases.linaro.org/components/toolchain/binaries/latest-5/arm-linux-gnueabihf/ Feb 22 17:00:52 Thanks. @zmatt Feb 22 17:01:20 zmatt: on the other hand the Necro900 people were trying to buy up BBxm to use for their thing. Feb 22 17:02:44 aman935: projects which have taken care to support cross-compiling (e.g. the linux kernel) support a make variable 'CROSS_COMPILE' which should be set to whatever should be prefixed to tools like gcc or ld to get the target version Feb 22 17:03:20 i.e. make CROSS_COMPILE=arm-linux-gnueabihf- ..other arguments... Feb 22 17:04:48 the fun starts if a program depends on any libraries other than libgcc and libc (and libstdc++ in case of C++ programs) Feb 22 17:05:42 tbr: necro900 ? Feb 22 17:06:01 zmatt: http://neo900.org/ Feb 22 17:07:23 I mean who wouldn't want a device with an OMAP3 (3630/3730), 512M and an OS that had 5 years to bit rot into meaninglessness and a resistive touch screen to boot Feb 22 17:08:59 I might have considered it interesting if I weren't already involved in the Pyra Feb 22 17:12:46 it might be that the omap3 is the only reasonable choice, due to the amount of stuff that's already out there for it. the omap5 would be the alternative, but it would be a gamble since no smartphone with it has ever been marketed (afaik) so you may end up discovering the fun surprises that the smartphone vendors otherwise would have dealt with Feb 22 17:13:23 omap4 seems more dead than either of those two, and other smartphone SoC vendors are as closed as an epoxy-sealed oyster Feb 22 17:21:16 I think it's pretty cool that projects like this exist though, pushing the boundaries of what a rag-tag band of crazy nerds can produce Feb 22 17:24:44 even if luck is still required... I'm very glad Pyra managed to get a volunteer who has the tools and knowledge to do full board 3d electromagnetic simulations Feb 22 17:34:56 Hi. Is there an image available for the beagle bone green which gives direct access to the GPIO without using file system calls? Feb 22 17:35:52 NTQ: that's not really dependent on the image Feb 22 17:36:26 as long as you have root privileges you can open /dev/mem and Do It Yourself, just keep in mind that: Feb 22 17:36:41 zmatt: I know I have to use the PRU. Feb 22 17:36:54 PRU is unrelated to this Feb 22 17:37:31 1. there's no protection of any kind, so keep in mind that one "whoops" could fry the hardware (especially if that whoops involves the direction register) Feb 22 17:38:33 2. the kernel normally performs power-management of peripherals, including the GPIO controllers. if you're bypassing the kernel by using /dev/mem then it won't know that you need it enabled Feb 22 17:38:52 a fix for that is disabling power management for the GPIO controllers, e.g. via device-tree or via sysfs Feb 22 17:40:57 3. beware of race conditions w.r.t. the direction register: when you update it, you need to read it, set or clear some bits, write the updated value. if more than one application does this (or one application and the kernel) then a ill-timed context switch could cause one or more updates to be lost Feb 22 17:41:59 zmatt: Sounds good. I want to connect a FPGA which has an internal FIFO buffer so timing should not be a big issue. Also there should be no other application/kernel process which uses the GPIOs I want the FPGA connect to. Feb 22 17:42:44 well for the race condition what matters is it anyone is changing direction of any gpios on the same gpio controller Feb 22 17:43:24 using GPIOs to interface with an FPGA sounds awful though... Feb 22 17:44:16 you might indeed want to consider using the PRUs Feb 22 17:45:03 I need a 16 bit wide interface and between 5 and 7 other pins to talk with the FPGA. What do you recommend? Feb 22 17:45:12 brb phone Feb 22 17:45:20 np Feb 22 17:52:16 so, obviously it depends on what exactly you mean by "16-bit wide interface", how you want to use it from a software pov, etc... PRUSS is useful since it's designed to use fast deterministic GPIO to speak all sorts of bus protocols Feb 22 17:53:38 note that unlike regular GPIO, the fast PRU GPIO is limited to specific pins, so check that Feb 22 17:54:45 alternatives include LCDC, which can speak cpu-like (6800 and 8608) bus protocols up to 16-bit wide and supports DMA for data transmission Feb 22 17:56:34 LCDC in raster mode can probably also be abused to transmit an array of 16-bit values across its 16 data pins Feb 22 17:57:50 I know people often use GPMC for interfacing with FPGAs, but it conflicts with using eMMC on the beaglebone black (and derivatives like the green) Feb 22 17:58:57 of mentioned alternatives the GPMC is the only way to get the FPGA interface visible like a memory-mapped region Feb 22 17:59:17 i.e. you could mmap() it on linux and have reads and writes within that region be turned into accesses to the FPGA Feb 22 18:01:38 PRUSS has the greatest flexibility but requires programming the PRU cores with some code that speaks your protocol to the FPGAs Feb 22 18:02:06 hlo Feb 22 18:03:00 actually i am interested in an idea proposed for gsoc this year can anyone please guide me for the same Feb 22 18:03:36 shanu: there's a separate channel, #beagle-gsoc Feb 22 18:04:10 ya i posted there but no one is replying back Feb 22 18:04:33 that just means you'll have to be patient. people here who know or care about gsoc will also be there Feb 22 18:11:58 NTQ: if you use regular GPIOs, keep in mind that the "ping time" from the cortex-a8 to the GPIO controller is around 150ns. when writes are buffered (true for PRU, can be made true for cortex-a8) then iirc you end up with 40ns per write if you fill up the FIFOs Feb 22 18:13:00 PRU's fast GPIOs can in principle toggle every cycle, i.e. 5ns Feb 22 18:13:50 (though not sustained since it would take up all execution time of that PRU core) Feb 22 18:14:44 NTQ: you'll need to research the options to choose the one most suited for your application Feb 22 18:16:09 zmatt: I'm back. I need a pin for a clock and a read frame. If both is high the FPGA sets data to the 16 bit bus. And then I can read that to the beagle bone. The clock speed hasn't to be constant. Feb 22 18:17:39 Also I need two other input pins which tell me if the buffer is nearly full or empty. Feb 22 18:18:31 ok so you need bulk transfer from FPGA rather than to FPGA ? Feb 22 18:19:42 yes Feb 22 18:19:59 (getting good performance is trickier for FPGA->AM335x than for AM335x->FPGA) Feb 22 18:20:20 what are your performance requirements? Feb 22 18:21:09 3,2 MByte/s Feb 22 18:23:44 I want to process the data and then send them through ethernet to a client. Feb 22 18:24:10 ok, so not very high, but enough that you do need to pay attention to what you're doing Feb 22 18:26:22 e.g. if you just do it with GPIO from the cortex-a8, then toggling a clock pin (two writes) and reading all pins of one gpio controller (1 read) will cost you around 450 ns with the default kernel or probably around 230 ns with a patched kernel Feb 22 18:27:22 That sounds fast enough. Feb 22 18:27:59 Do you know if there is a tutorial or example somewhere which I can test and modify? Feb 22 18:28:09 it is, but not by a huge margin. if my calculation is correct you have about 600 ns Feb 22 18:28:39 and you still need to offload the data in the time remaining Feb 22 18:28:56 (of course that part is batched) Feb 22 18:30:13 Basically I need a simple process that retrieves the data from the FPGA and adds it to a FIFO. Then an other "normal" process can process that data from the FIFO Feb 22 18:30:33 I guess PRU would be the best choice for this. Feb 22 18:31:50 if you use only the cortex-a8 then your process needs to gather the data into packets and send those, and then hopefully *maybe* it might reach your performance target. inserting a fifo and another process almost certainly would make it too slow Feb 22 18:32:31 using PRU could speed things up Feb 22 18:33:36 Is it correct that the only to compile programs for the PRU is TI's Code Composer Studio which unfortunality was discontinued? Feb 22 18:33:44 *only way Feb 22 18:35:11 uh, no. people use either the PRU Assembler (pasm) or if performance is not very relevant TI's C compiler (part of Code Generation Tools for PRU) Feb 22 18:35:16 none of it is discontinued Feb 22 18:35:57 Hello Feb 22 18:35:57 well, pasm might not be maintained, but it doesn't really require maintenance Feb 22 18:36:45 code generation tools for PRU can be installed and used from within Code Composer Studio, or it can be installed and used standalone Feb 22 18:37:21 I prefer C. ;-) Okay, I found the C compiler but is there also an IDE available for this? I am using Linux (Ubuntu). Feb 22 18:39:23 beware that the PRU instruction set doesn't match C very well, so some seemingly trivial things may require several instructions Feb 22 18:39:40 avoid signed integers whenever unsigned integers are usable Feb 22 18:40:08 okay. I understand. Feb 22 18:41:27 and dunno about IDEs, can't they simply be configured to use an existing makefile? Feb 22 18:41:48 CCS will obviously have built-in support for it Feb 22 18:42:01 I never looked at it though, I don't start CCS unless I absolutely have to Feb 22 18:42:57 At the moment I am using CCS for developing programs for the Tiva C Connected Launchpad. Feb 22 18:43:10 note btw that PRU's instruction set is pretty nice and the PRU assembler has a number of features to make it friendlier to humans, including support for structs Feb 22 18:43:44 Sounds nice Feb 22 18:43:55 Maybe I will give it a try Feb 22 18:44:05 lemme see if I can find the latest pasm link Feb 22 18:44:14 thx Feb 22 18:45:07 https://github.com/beagleboard/am335x_pru_package/tree/master/pru_sw/utils Feb 22 18:46:01 don't forget to pass the -V3 option to select the pru core version (pasm defaults to -V1) Feb 22 18:46:23 there are examples elsewhere in that git repo Feb 22 18:47:46 ok, I' Feb 22 18:47:49 ok, I'm afk for a bit Feb 22 19:14:38 hi hello Feb 22 19:14:52 i am looking to purchase an Beagle board Feb 22 19:15:17 which i can not find where to inquire Feb 22 19:15:45 would anybody be able to give me a phone nr to call pls Feb 22 19:15:46 BBB-C Feb 22 19:16:32 i need 1GB micron DDR3L, and 8GB Micron V5 eMMC Feb 22 19:20:54 and apparently he needed that custom BBB in less than 5 minutes Feb 22 19:21:00 oh well, afk Feb 22 19:21:06 :-D Feb 22 19:57:54 Hello Feb 22 20:12:27 When using a ZCE package there seems to be only one PRU available. How would it be possible to use GPIO in the same time as ethernet in this case? Do I need to program this in my PRU code as well? Feb 22 20:15:53 earlier you were asking for the beaglebone green, it doesn't use a ZCE package Feb 22 20:16:51 I know. We are using the BBG for development and want to shift to ZCE package for convenience in PCB design. Feb 22 20:17:57 the number of PRU cores doesn't depend on package, although the signals available may be limited. if all 17 inputs of one PRU core available then that's all you need (you can use regular GPIO for other status signals). I don't understand what your question has to do with ethernet Feb 22 20:19:32 MII is wired to the PRU and that led us to this assumption. Feb 22 20:19:46 you're using EtherCAT ? Feb 22 20:19:56 no you aren't, since you're using a BBG for prototyping Feb 22 20:20:02 then mii is entirely unrelated to PRU Feb 22 20:20:16 thanks Feb 22 21:21:46 http://settrans.net/~rah/gta04-sale/gta04-bundle-for-sale.txt Feb 22 23:46:57 hi there! may I ask just a quick tip? Feb 22 23:47:12 why beaglebone for industrial IoT? is it about robustness? Feb 23 00:50:00 zmatt: i have returned! Feb 23 00:50:07 you said that you had more to tell me? Feb 23 00:55:22 fouric: i'm pretty sure he is asleep now Feb 23 00:56:09 KotH: oh ty Feb 23 00:56:19 UTC+4 or something similar? Feb 23 00:56:59 * fouric is on UTC-8, it's 1656 for him Feb 23 00:59:46 UTC+1 Feb 23 01:07:22 * fouric nods **** ENDING LOGGING AT Thu Feb 23 03:00:02 2017