rellla changed the topic of #linux-sunxi to: Allwinner/sunxi /development discussion - did you try looking at our wiki? - Don't ask to ask. Just ask and wait! - - Logs at - *only registered users can talk*
specing_ has joined #linux-sunxi
specing has quit [Ping timeout: 252 seconds]
matthias_bgg has quit [Ping timeout: 265 seconds]
specing_ is now known as specing
kaspter has quit [Ping timeout: 240 seconds]
kaspter has joined #linux-sunxi
lkcl has quit [Ping timeout: 246 seconds]
vagrantc has quit [Quit: leaving]
<pnill> "<apritzel> at the end of the day it remains a hack: if you want a game console, buy one
<pnill> <apritzel> or use any other, well supported SBC and some gaming distro" well exactly it's fun unlocking hardware to do more especially closed hardware haha.
<pnill> I didn't think it'd be a walk in the park was just curious if there was another option and I'm perfectly fine with booting a totally different OS over USB
<pnill> which I think would be possible over U-Boot
lkcl has joined #linux-sunxi
rzerres has quit [Ping timeout: 260 seconds]
rzerres has joined #linux-sunxi
<smaeul> yes, U-Boot can boot from USB. U-Boot itself still has to be on the NAND, and that is supported for mainline, I believe
Mangy_Dog has quit [Ping timeout: 246 seconds]
victhor has quit [Remote host closed the connection]
cnxsoft has joined #linux-sunxi
libv has quit [Ping timeout: 245 seconds]
libv has joined #linux-sunxi
camus has joined #linux-sunxi
kaspter has quit [Ping timeout: 268 seconds]
camus is now known as kaspter
buzzmarshall has quit [Remote host closed the connection]
gediz0x539 has joined #linux-sunxi
faruk has joined #linux-sunxi
hlauer has joined #linux-sunxi
shailangsa has quit [Ping timeout: 265 seconds]
asdf28 has joined #linux-sunxi
apritzel has joined #linux-sunxi
cmeerw has joined #linux-sunxi
apritzel has quit [Ping timeout: 240 seconds]
kaspter has quit [Ping timeout: 252 seconds]
kaspter has joined #linux-sunxi
cmeerw has quit [Ping timeout: 245 seconds]
Shailangsa_ has joined #linux-sunxi
Shailangsa_ has quit [Ping timeout: 252 seconds]
shailangsa has joined #linux-sunxi
matthias_bgg has joined #linux-sunxi
chewitt has quit [Quit: Adios!]
reinforce has joined #linux-sunxi
tnovotny has joined #linux-sunxi
apritzel has joined #linux-sunxi
warpme_ has joined #linux-sunxi
<hlauer> apritzel: Thanks for updating the R40 wiki. btw: banana M2 Ultra SATA works fine
<apritzel> hlauer: Was there ever a doubt or problem over the M2U's SATA?
<hlauer> Not seen anything here, it's solid since I bought the device and put mainline on it :-)
simosx has joined #linux-sunxi
simosx has quit [Quit: Yakkety Bye!]
prefixcactus has joined #linux-sunxi
<apritzel> mripard: wens: so do I get this correctly that this new timing mode in the later MMC controllers requires the mod clock to be programmed *4* times higher than it actually should be?
<apritzel> at least for the eMMC HighSpeed DDR mode (50 MHz)?
<wens> no idea
<apritzel> I see clk_summary saying 100 MHz, but the divider in the mod clock is 6, so it's actually 200 MHz (the PLL running at 1200)?
<apritzel> trying to sort out the U-Boot situation, where we apparently miss some of those "quirks"
<mripard> the parent should be the pll-periph (pll6?) that runs at 600MHz?
<apritzel> on the H6 the parent is PLL-Periph0(2x), so 1200 MHz
<apritzel> pll-periph0-2x 1 1 0 1200000000 0 0 50000 Y
<apritzel> mmc2 0 0 0 100000000 0 0 50000 N
<mripard> ah right
<mripard> if I remember well (and it's a bit fuzzy honestly)
<mripard> the new mode requires that we double the clock
<mripard> and DDR does too
<mripard> so for HS DDR we end up with x4
<apritzel> right, makes sense
<apritzel> is the DDR doubling a general MMC thing, or another Allwinner speciality?
<mripard> something specific to the controller
<apritzel> I see, many thanks, that clears it up!
<mripard> with DDR you sample on rising and falling edges, but the clock rate stays the same
<apritzel> yeah, that's why I would expect the actual SDC_CLK line really running at 50 MHz
<mripard> I guess it depends on how the device is designed :)
<mripard> the FIFOs and internal logic would need to run at twice the speed
<apritzel> indeed, I guess the controller has twice the work to do, so it needs more speed
<wens> IIRC there's an internal divider for SDC_CLK
uis has quit [Quit: ZNC 1.7.5 -]
uis has joined #linux-sunxi
<apritzel> Allwinner must have got some "remaining stock" on the A73 ;-) really? in 2022? But then again they still use A7s all over the place ...
<apritzel> But I guess they realised that A76 does AArch32 only in EL0, so they would have to rewrite the BROM (and port U-Boot)
Mangy_Dog has joined #linux-sunxi
Mangy_Dog has quit [Changing host]
Mangy_Dog has joined #linux-sunxi
victhor has joined #linux-sunxi
kaspter has quit [Ping timeout: 252 seconds]
kaspter has joined #linux-sunxi
vbmithr_ has quit [Ping timeout: 248 seconds]
vbmithr has joined #linux-sunxi
elros1 has joined #linux-sunxi
<maz> apritzel: the answer is obvious: broken timers are a feature for AW. So picking A73 is an obvious choice, as they don't even have to fsck-up the integration!
victhor has quit [Remote host closed the connection]
<apritzel> maz: right, good point, keep compatibility to the A64 ;-)
Net147 has quit [Quit: Quit]
Irenes has quit [Ping timeout: 245 seconds]
DrFrankensteinUK has quit [Ping timeout: 240 seconds]
camus has joined #linux-sunxi
DrFrankensteinUK has joined #linux-sunxi
kaspter has quit [Ping timeout: 268 seconds]
camus is now known as kaspter
Irenes has joined #linux-sunxi
specing_ has joined #linux-sunxi
specing has quit [Ping timeout: 252 seconds]
specing_ is now known as specing
Net147 has joined #linux-sunxi
Net147 has quit [Client Quit]
Net147 has joined #linux-sunxi
Net147 has quit [Remote host closed the connection]
Net147 has joined #linux-sunxi
netlynx has joined #linux-sunxi
netlynx has quit [Changing host]
netlynx has joined #linux-sunxi
chewitt has joined #linux-sunxi
elros1 has quit [Read error: Connection reset by peer]
elros1 has joined #linux-sunxi
elros1 has quit [Read error: Connection reset by peer]
s_frit has quit [Remote host closed the connection]
s_frit has joined #linux-sunxi
faruk has quit [Quit: Leaving]
tnovotny has quit [Quit: Leaving]
buzzmarshall has joined #linux-sunxi
reinforce has quit [Quit: Leaving.]
elros1 has joined #linux-sunxi
cnxsoft has quit [Quit: cnxsoft]
JohnDoe_71Rus has joined #linux-sunxi
cmeerw has joined #linux-sunxi
<jernej> apritzel: if it gets job done, why not
<jernej> I think that many times peripherals are just as important as core, ocassionally even more
<apritzel> jernej: yeah, I was just disappointed - and was hoping for at least an A75 or A76
<apritzel> I know
<jernej> (I'm working with 8-bit soft-core MCUs last few years, which are better suited for the job than off the shelf 32-bit MCUs)
<apritzel> yeah, many times you just need some kind of better DMA controller
popolon has joined #linux-sunxi
elros1 has quit [Remote host closed the connection]
<apritzel> bauen1: smaeul: there was this "felreset" trick for the H6, where we write the magic plus address into RTC_BASE + 0x1b8/0x1bc, then do a watchdog reset
<apritzel> but the H616 seems to use different addresses, do you know which?
<apritzel> we use R_CPUCFG_BASE + 0x1c0 in the SPL, but that does not work this way
<apritzel> I guess this location do not survive the watchdog reset? (For the H6 it's in the RTC registers)
<apritzel> and writes to the H6 addresses (0x70001b8) do not stick on the H616
rzerres has quit [Ping timeout: 252 seconds]
<apritzel> bauen1: smaeul: and this super standby is different right, both in terms of the key and trigger mechanism and also that it requires an eGON image in memory?
jstein has joined #linux-sunxi
clementp[m] has quit [Quit: Idle for 30+ days]
rzerres has joined #linux-sunxi
rzerres has quit [Ping timeout: 260 seconds]
kevans91_ is now known as kevans91
<bauen1> apritzel: i don't have a h616 and haven't taken a look at its brom yet
<bauen1> but iirc the super standby detection is in very very early boot, so the magic values / addresses should be easy to find out
<bauen1> it's actually been quite a while since i last touched my h6 :/
choozy has joined #linux-sunxi
elros1 has joined #linux-sunxi
camus has joined #linux-sunxi
kaspter has quit [Ping timeout: 252 seconds]
camus is now known as kaspter
prefixcactus has quit [Ping timeout: 268 seconds]
kaspter has quit [Ping timeout: 265 seconds]
kaspter has joined #linux-sunxi
elros1 has quit [Remote host closed the connection]
elros1 has joined #linux-sunxi
lukedashjr has joined #linux-sunxi
luke-jr has quit [Ping timeout: 260 seconds]
lukedashjr is now known as luke-jr
jernej is now known as jerSTART_CODEnej
jerSTART_CODEnej is now known as jernej
jstefanop has joined #linux-sunxi
apritzel has quit [Ping timeout: 260 seconds]
sunshavi has quit [Remote host closed the connection]
kaspter has quit [Ping timeout: 240 seconds]
kaspter has joined #linux-sunxi
gaston1980 has quit [Ping timeout: 246 seconds]
apritzel has joined #linux-sunxi
elros1 has quit [Remote host closed the connection]
shailangsa has quit [Ping timeout: 246 seconds]
chewitt has quit [Quit: Zzz..]
choozy has quit [Quit: - Chat comfortably. Anywhere.]
JohnDoe_71Rus has quit [Quit: KVIrc 5.0.1 Aria]
shailangsa has joined #linux-sunxi
<apritzel> bauen1: so the first thing the H616 BROM checks, is bit 15 at 0x070001a0, but it just writes something different back, depending on the result
<apritzel> then it checks the MPIDR to sort out the secondaries
tuxillo has quit [Ping timeout: 252 seconds]
thefloweringash has quit [Ping timeout: 245 seconds]
<apritzel> and then cores 0 checks the first standby register at 0x70005c0 for the magic, if that matches, it branches to the address in 0x70005c4
<apritzel> which is the mechanism we use for the SPL FEL return
<apritzel> so this is very early, but does not survive a watchdog reset
<apritzel> (I guess because it's in R_CPUCFG, and not in the RTC)
thefloweringash has joined #linux-sunxi
<apritzel> I keep looking, but this BROM code makes me cringe everytime I read it
<megi> some of my notes on mmc
ullbeking has joined #linux-sunxi
ullbeking has joined #linux-sunxi
ullbeking has quit [Changing host]
<megi> mainline u-boot has that a bit messed up, with H6 running at half the speed for no reason or whatever
<megi> I don't remember anymore
<apritzel> megi: I see, many thanks, that looks like a good summary
<megi> that branch in general has some good stuff, like DMA support, and support for DDR
<apritzel> that was my next question ...
<apritzel> any chance you could send that to the list?
<apritzel> or at least provide a summary of what you fixed in there?
<megi> I tried once, but setting up CI for u-boot was too much of a bother
<apritzel> why would you need that?
<megi> I was told to do that
<apritzel> really? interesting ...
<megi> to verify it compiles on I don't know with how many configs
<apritzel> that's solved
<megi> it was loong time ago, though, so maybe things changed
<apritzel> it just grab one of my servers, do: "tools/buildman/buildman sunxi"
<apritzel> and a few minutes later it returns a summary of all 156 sunxi boards
<apritzel> and I believe Tom Rini does this as well before actually merging stuff into master
<apritzel> anyway, I believe in good ol' review being more valuable than those sophisticated CI systems ...
<apritzel> mmh, DMA for MMC, what does that give you?
<apritzel> do you care so much about the speed increagse?
<megi> with DDR eMMC, it gives 80MiB/s load speeds
<megi> kernel loaded in 100ms :) and booting
<megi> at that point U-Boot has other code that wastes much more time
<megi> but the same mmc code in p-boot just gives 150ms boot times
<megi> from eMMC
<megi> it's still the longest part of the bootloader process
<apritzel> megi: I can believe that it's faster, but do you have the number for the PIO transfers (at the same fixed MMC clock speed)?
<megi> for regular SD card speeds, it's not that interesting
<megi> maybe 5% rise in speed
netlynx has quit [Quit: Ex-Chat]
<megi> also it's async, you start it and you can do other stuff for those 100ms on your boot CPU, so that's other reason I implemented it
<apritzel> so you hit an MMIO penalty wall if you do faster (e)MMC modes?
<megi> I don't think I tested with eMMC
<megi> because I implemented DDR support after having DMA already working
<megi> s/tested/comapred DMA vs PIO/
shailangsa has quit [Ping timeout: 268 seconds]
<megi> I guess I can send some of the patches, but I don't update U-Boot anymore, so I'd have to first rebase over several releases and then re-test... so it's probably not going to be anytime soon
<apritzel> well, I will have a look and might pick some fixes
<megi> great :)
<apritzel> and that's the advantage of being mainline: you don't need to rebase ;-)
<megi> I did a quick rebase to 2021.04 but it probably doesn't compile, but it should at least have some obvious conflicts fixed
<megi> not updating also works :)
<megi> all I need from U-Boot is to load kernel from SD card on most of my boards, and it does that already quite well
<megi> that's basically the reason for many of my patches in that branch, to get U-Boot out of the way as soon as possible
<megi> mmc speed improvements, CPU data cache enablement in SPL, etc.
<megi> on that note, did anyone ever get falcon mode to work with sunxi SPL?
<apritzel> megi: I once experimented on the A64, with Trusted Firmware's direct kernel boot feature
<apritzel> SPL loads TF-A and the kernel, branches into TF-A, which then drops directly into the kernel
<apritzel> so no U-Boot proper
<megi> that's what I do in p-boot
<megi> it works nicely :)
<megi> I think the trouble probably is that SPL can't fit FAT driver
<megi> so the payload would have to be in something simpler
<megi> or SPL would need some trimdown, like simpler page table management code, to make space for more useful stuff
<apritzel> megi: newer SoCs actually don't have the 32KB SPL limit anymore, but I think the A64 still has
<megi> oh, nice
<apritzel> starting with H6, I think
<apritzel> on the H616 we actually produce a bigger SPL by default (48K)
<apritzel> megi: did you use a 64-bit SPL for that test?
<megi> yes I use 64-bit spl
<apritzel> megi: I had a 32-bit SPL branch for A64/H5/H6 for a while
<apritzel> the usual size as on the 32-bit SoCs (<24KB)
<apritzel> at the very end it switches to AArch64
<megi> using thumb may help even more
<apritzel> it does this automatically
<apritzel> all 32-bit sunxi builds do, I believe
<megi> U-Boot spl can still be optimized quite a bit
<apritzel> sure, but I prefer it to be maintainable and correct ;-)
<megi> on A64 at the very least it maps SRAM as IO space
<megi> so it's not cached even when CPU caches are enabled
<megi> makeing a simple memcpy of a few hundred kB take 500ms
<megi> and it does a bit of memcpy around loading FIT images
<megi> page table management code, being generic is also quite slow, when you want to map things properly
<megi> it will easily takes 200ms to just build a page table
<apritzel> this is all a LOT of changes for a slight speed improvement on booting, which I am not sure is really worth
<apritzel> you seem to be all about saving a few hundred ms here, which I don't believe really matters
<megi> yeah, that's why I gave up on generic fixes in U-Boot, and just wrote a special purpose SPL for pinephone :)
<apritzel> as you say: boot load speed is a niche competition :-D
<megi> it does to me, it's kinda nice that I can press a button, and be in linux userspace GUI in 2s on a smartphone
<megi> but yeah, it's just a fun obsession
<apritzel> it's nice, but I wonder if suspend wouldn't be a much better solution (even faster)
<megi> also it's not that bad that when I do kernel dev and need to reboot a lot
<apritzel> I have more of a server background, so if it boots faster than in 5 minutes, I am happy
<megi> :D
<megi> I imagined a smartphone booting 5 mintues, and also doing all those fighter jet sounds in the process
<megi> like with a rack server
<apritzel> this approach is a bit too embedded for my taste: it optimises the crap out of the *boot time* for a very specific device
<megi> anyway, some of the lessons learned are bacportable to SPL, so that it at least doesn't do completely wasteful things
<apritzel> sure, and it's definitely good to have the discussion
<apritzel> and be it for the fixes
<megi> yeah, some of that was already fixed independently. the useless mdelay(500) was too
<apritzel> med
<apritzel> megi: you don't have any H6 U-Boot HDMI patches, by any chance?
<megi> no
dev1990 has quit [Quit: Konversation terminated!]
dev1990 has joined #linux-sunxi
<apritzel> megi: actually I was wondering the other day how much useful the code sharing between SPL and U-Boot proper really is
<apritzel> I mean these days, with DM driver in proper, and non-DM hacks on top, for the SPL
<apritzel> for instance sunxi_mmc.c is somewhat of a mess because of this, and we can't do much about it
<apritzel> but I think that's actually one of the few places where we actually share code between SPL and U-Boot proper
<apritzel> and we have somewhat clean interface between the SPL and proper (via FIT or the legacy image)
shailangsa has joined #linux-sunxi
cmeerw has quit [Ping timeout: 250 seconds]
<megi> I don't have any ideas about that
warpme_ has quit [Quit: Connection closed for inactivity]
<apritzel> I mean we could have a more lean SPL replacement, just being able to load U-Boot proper (or a kernel directly)
<megi> oh, right, it would only have to understand mmc and dram init, and bunch other smaller things :)
<apritzel> we would just need basic clock setup, DRAM init, MMC read and SPI flash support, and could then possibly afford a FAT read driver
<apritzel> ah, yes
<apritzel> we already have this for the SPI flash
<apritzel> where the drivers for SPL and proper are actually separate
<megi> mmc one is kinda big though
<apritzel> but I agree that for the SPL purpose we go through quite some unnecessary U-Boot churn
<megi> so sharing that is useful
<apritzel> well, somewhat
<apritzel> for instance we need only raw reads
<apritzel> as I said, this is indeed probably the only place where we really share code
<apritzel> so that would be a sacrifice to make
<apritzel> but maybe it's worth it, if we can get FAT support, for instance
<apritzel> but I don't know, just some thoughts ....
<megi> well, having a simple sunxi mmc specific code for raw reads would be nice (instead of generic mmc.c/sunxi_mmc.c split that contains quite a bit of abstraction), I though about making one for p-boot, just to save space and to have more control
<megi> but it seems like a largish amount of work :)
<megi> and p-boot is basically just a SPL
<megi> so I guess whoever gets to that project first will be able to share the other's code ;)
<megi> it would also probably allow some fun stuff in U-Boot spl too, if it implemented DMA... like starting the transfer and do some other stuff not waiting for it to finish
<megi> sunxi mmc can basically DMA the whole kernel at once if it's stored in a single consecutive amount of blocks on the card
<megi> in a single transaction :)
<apritzel> well, the whole design idea of U-Boot is to be single threaded and linear, so no multi tasking, not even interrupt driven DMA in the background
<megi> no need for interrupts
<apritzel> so not sure what U-Boot would do meanwhile
<megi> just start DMA do something else, and once you have that done, poll for end of DMA
<apritzel> I understand, but what would this "else" be?
tuxillo has joined #linux-sunxi
<megi> not sure what in U-Boot, but p-boot has display support and loads 4MiB image backgrounds for menu items, etc. so being able to do that asynchronously would be good
<apritzel> I see, I was wondering about U-Boot in particular
<megi> currently the u-boots mmc code doesn't allow that
<apritzel> so in p-boot you pull in the MMC code from U-Boot?
<apritzel> and this is part of the blob loaded by the BROM?
<megi> you can still do some HW init that takes some time, or whatever in the meantime, but for SPL that aims to only do minimum necessary, I don't know
<megi> yes
matthias_bgg has quit [Ping timeout: 268 seconds]
<megi> p-boot has copy of mmc code from u-boot + my perf patches
<apritzel> so how big is your eGON image then?
<megi> it's ~32kib
<apritzel> IIUC you search for a special boot partition, and load the rest from there?
<megi> yes
<megi> with display support disabled it's around 25KiB
<megi> so without display support there would be enough for FAT support
<megi> enough space
<apritzel> ah, I was just wondering what makes up the space you save ...
<apritzel> DE2 & LCD?
<megi> DE2,LCD,DSI driver,DPHY,panel driver,menu GUI,bunch of other things
<megi> fonts
<apritzel> do you actually need that in the SPL? Is that already interactive?
<megi> yes
<apritzel> have you tried compiling this as Arm32 Thumb2?
<megi> I was thinking about it :)
<apritzel> the 32-bit "mainline" SPL shrunk from 32KiB to ~20KiB
<apritzel> so there is quite something to gain
<apritzel> (I was once playing around with ILP32, was this wasn't worth the hassle, there was not much saving)
<megi> yeah, I expect it to be :)
<megi> there's no way forward without that, because 32kib are already used up, so that's the next thing to do
<apritzel> megi: do you have an idea of how much HDMI would add?
<megi> depending on how it's done
<megi> p-boot uses some tricks to achieve small size of display init code
<megi> you probably don't want something like that in generic U-Boot spl
<apritzel> yeah, I see ;-)
<megi> it has full display code too, but it's larger in size when compiled
<megi> I enable DUMP_DSI_INIT define to make p-boot print register writes it would do with generic code
<megi> and then just put those in the table
<apritzel> lol
<megi> it works, because there's no readback necessary for display init
<megi> :D
<apritzel> I see
<megi> optimization at its best
<megi> :D
<apritzel> so I was playing around with the idea of a generic boot image
<apritzel> that boots multiple boards
<apritzel> and part of that would be a menu, in SPL, to select your board from a list
<apritzel> which would be much more accessible over HDMI than over serial
<apritzel> but this wouldn't work anyway, since the HDMI power is mostly board specific
<megi> yeah
<apritzel> so you would need to know the board already, before starting the display
<megi> I'd probably want to hardcode the board choice somewhere if I was using this on one board...
<megi> though RTC data regs are a useful place for that
<apritzel> yeah, but the idea would be to have one SD card (image), to get as many boards as possible to boot
<megi> you could use SID to identify the board by its soc
<megi> but it would just be generic for your boards :)
<apritzel> I once hacked up one combined image for Pine64+, Pine64-LTS, Pinebook
<apritzel> which can be autodetected (DRAM type, and the lid switch GPIO on the PineBook vs. this GPIO floating on the LTS)
<apritzel> but unless you restrict yourself to a subset of boards, you cannot autodetect boards, that's why the idea of a menu
<megi> it could still work over serial, if all the boards use the same serial port
<apritzel> yeah, they do
<apritzel> and modern sunxi U-Boot proper is really DT driven, so you could just basically select one DTBs
<apritzel> and share one U-Boot proper image
sunshavi has joined #linux-sunxi
<apritzel> quite easily for one SoC, and with some more efforts for multiple SoCs
<megi> I like that, except for U-Boot carrying it's own DT
<apritzel> what do you mean with "own DT", exactly?
<megi> a copy of device tree different from the kernel one
<apritzel> well, for once we sync it regularly
<apritzel> I just copied the 5.12 DT for all A64 boards into U-Boot
<apritzel> the other problem is that one-DT-to-rule-them-all doesn't work for sunxi, since the kernel DT is not stable
<megi> it's also probably a recursive problem, you need the DT to init enough of the device to get the kernel DT
<apritzel> so newer DTs fail for older kernels
<megi> from SD card or wherever
<apritzel> well, you could have the DTs in a FAT partition
<apritzel> U-Boot actually doesn't insist on its "own DT"
<apritzel> it just takes whatever it finds after its image
<apritzel> and the SPL actually selects DTs already
<apritzel> for the Pine64 vs Pine64+, for instance
<apritzel> based on the DRAM size
<megi> yeah, I saw that, it does for pipephone too based on some gpios
<apritzel> exactly, same idea
<megi> basically the similar hack you described few minutes ago
<apritzel> so if you can read FAT, you can list all DTs that you find, and ask the user to choose one
<apritzel> and then boot with that
<apritzel> FAT support would make that easier, at the moment you would need to add all DTs to the FIT image
<megi> hmm, true
hlauer has quit [Ping timeout: 268 seconds]
asdf28 has quit [Ping timeout: 265 seconds]
Net147 has quit [Ping timeout: 268 seconds]
jstefano_ has joined #linux-sunxi
jstefanop has quit [Ping timeout: 268 seconds]
shailangsa has quit []
popolon has quit [Quit: WeeChat 3.1]
nashpa_ is now known as nashpa
jstein has quit [Quit: quit]