rellla changed the topic of #linux-sunxi to: Allwinner/sunxi /development discussion - did you try looking at our wiki? https://linux-sunxi.org - Don't ask to ask. Just ask and wait! - https://github.com/linux-sunxi/ - Logs at http://irclog.whitequark.org/linux-sunxi - *only registered users can talk*
suprothunderbolt has joined #linux-sunxi
lurchi_ is now known as lurchi__
lurchi__ is now known as lurchi_
lurchi_ has quit [Quit: Konversation terminated!]
lurchi__ has joined #linux-sunxi
lurchi__ has quit [Quit: Konversation terminated!]
lurchi_ has joined #linux-sunxi
lurchi_ has quit [Quit: Konversation terminated!]
lurchi_ has joined #linux-sunxi
lurchi_ has quit [Quit: Konversation terminated!]
lurchi__ has joined #linux-sunxi
lurchi__ has quit [Quit: Konversation terminated!]
lurchi__ has joined #linux-sunxi
lurchi__ has quit [Quit: Konversation terminated!]
lurchi_ has joined #linux-sunxi
lurchi_ is now known as lurchi__
lurchi__ has quit [Quit: Konversation terminated!]
lurchi__ has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
<MoeIcenowy> jernej: don't worry, the chip won't hang if no ext losc is present
craigo has joined #linux-sunxi
<rr123> Write-error on swap-device (254:1:108360) -- uname -a Linux orangepizero 4.19.59-sunxi #5.91 SMP Mon Jul 15 14:09:32 CEST 2019 armv7l GNU/Linux
<rr123> sunxi-mmc 1c10000.mmc: data error, sending stop command
<rr123> xradio_wlan mmc1:0001:1: missed interrupt
<rr123> quite some concerning dmesgs from H2+ on orangepi zero lts
<rr123> the wifi will fail actually, the zram write-error could be ok or fatal
RichardG867 has joined #linux-sunxi
TheSeven has quit [Ping timeout: 252 seconds]
TheSeven has joined #linux-sunxi
NeuroScr has quit [Quit: NeuroScr]
NeuroScr has joined #linux-sunxi
Perlovka has joined #linux-sunxi
dddddd has quit [Remote host closed the connection]
<jernej> MoeIcenowy: wens: I'm not worried about hanging, but I'm researching why HDMI-CEC doesn't work on OrangePi PC2 (H5) and I noticed that it doesn't have 32 kHz crystal.
<jernej> I didn't do any tests, but that could be a reason
<jernej> it certainly was for Tanix TX6 (H6)
<jernej> I think we have to introduce a way to tell driver to select either internal or external 32 kHz source
night199uk has quit [Ping timeout: 245 seconds]
<jernej> easiest way would be by removing or adding ext losc phandle to RTC node
night199uk has joined #linux-sunxi
<jernej> but driver has a check for that and fails if no clock is specified
<jernej> maybe that can be changed
_whitelogger has joined #linux-sunxi
<MoeIcenowy> jernej: what clock accuracy is needed for HDMI-CEC?
<jernej> not sure, internal LOSC seems to be just fine
<MoeIcenowy> have you tried to remove the code to enable ext OSC?
<jernej> I'm more worried that auto switching might not work correctly
<MoeIcenowy> so first try to remove it
<MoeIcenowy> I think it should be working
<jernej> as I said, I didn't do any tests with H5 yet, but I plan to do these days
<jernej> but I think it's misleading to have ext LOSC specified in DT if there isn't any
<MoeIcenowy> BTW
<MoeIcenowy> I remember there's some SoC that have a wrongly tweaked internal OSC
<MoeIcenowy> but forgot whether it is H3, H5 or A64
<MoeIcenowy> the wrongly tweaked internal OSC runs at 22K rather than 32K
<jernej> are you sure?
<jernej> that could also explain why it doesn't work
<jernej> anyway, all A64 boards that I currently use have ext LOSC crystal and H5 one does not
<jernej> so I can't tell which one has the issue, but I would bet on H5 then
<jernej> hm... I could check frequency with the scope, but I have to prepare test image for that
<jernej> next week
<jernej> oh, it could be also H3, because I currently use bitbanged HDMI-CEC
<jernej> I'll test all three
_whitelogger has joined #linux-sunxi
vagrantc has joined #linux-sunxi
xqdzn has quit [Ping timeout: 260 seconds]
lurchi_ has joined #linux-sunxi
Putti has quit [Ping timeout: 268 seconds]
sunshavi has quit [Read error: Connection reset by peer]
lurchi__ has quit [Ping timeout: 246 seconds]
sunshavi has joined #linux-sunxi
tllim has joined #linux-sunxi
s_frit has quit [Remote host closed the connection]
s_frit has joined #linux-sunxi
airwind has joined #linux-sunxi
selfbg has joined #linux-sunxi
TheSeven has quit [Ping timeout: 245 seconds]
TheSeven has joined #linux-sunxi
vagrantc has quit [Quit: leaving]
reinforce has joined #linux-sunxi
ldevulder_ has joined #linux-sunxi
ldevulder has quit [Ping timeout: 246 seconds]
ldevulder_ is now known as ldevulder
warpme_ has joined #linux-sunxi
warpme_ has quit [Quit: warpme_]
tdebrouw has joined #linux-sunxi
matthias_bgg_ has joined #linux-sunxi
yann has quit [Ping timeout: 246 seconds]
nashpa has quit [Remote host closed the connection]
nashpa has joined #linux-sunxi
tllim has quit [Read error: Connection reset by peer]
NeuroScr has quit [Quit: NeuroScr]
tnovotny has joined #linux-sunxi
suprothunderbolt has quit [Ping timeout: 276 seconds]
suprothunderbolt has joined #linux-sunxi
yann|work has joined #linux-sunxi
netlynx has joined #linux-sunxi
netlynx has joined #linux-sunxi
diego71_ has joined #linux-sunxi
diego71 has quit [Ping timeout: 246 seconds]
warpme_ has joined #linux-sunxi
gaston1980 has joined #linux-sunxi
nexgen2 has joined #linux-sunxi
nexgen2 has quit [Ping timeout: 276 seconds]
ldevulder has quit [Quit: Leaving]
florian has quit [Read error: No route to host]
florian has joined #linux-sunxi
nexgen2 has joined #linux-sunxi
ldevulder has joined #linux-sunxi
AneoX has joined #linux-sunxi
<willmore> Is there an issue with H6 boards that cause them to take a long time to reboot? My Orange Pi One Plus takes several minutes to reboot. I guess I should hook a serial line off of it and see if it's saying anything...
<KotCzarny> bad value in hw watchdog?
<KotCzarny> getting interpreted as minues instead of seconds?
<KotCzarny> but that's assuming it's not an OS issue
nexgen2 has quit [Ping timeout: 265 seconds]
diego71_ has quit [Ping timeout: 245 seconds]
Mangy_Dog has joined #linux-sunxi
diego71 has joined #linux-sunxi
nexgen2 has joined #linux-sunxi
netlynx has quit [Quit: Ex-Chat]
<libv> willmore: plaes documented something about the latest debian version
<KotCzarny> libv: but that's about startup
<libv> http://linux-sunxi.org/Debootstrap#.28Optional.29_PRNG_entropy_seeding_speedups
<libv> oh, shutdown, ok
nexgen2 has quit [Ping timeout: 265 seconds]
<KotCzarny> although willmosre didnt specify where is it delaying
<KotCzarny> *willmore
random_yanek has quit [Ping timeout: 276 seconds]
random_yanek has joined #linux-sunxi
marekbelisko has joined #linux-sunxi
airwind has quit [Quit: airwind]
marekbelisko has quit [Quit: This computer has gone to sleep]
dddddd has joined #linux-sunxi
megi has joined #linux-sunxi
selfbg has quit [Remote host closed the connection]
\\Mr_C\\ has joined #linux-sunxi
aloo_shu has quit [Ping timeout: 240 seconds]
diego_r has joined #linux-sunxi
ldevulder_ has joined #linux-sunxi
florian has quit [Quit: Leaving]
ldevulder has quit [Ping timeout: 246 seconds]
Putti has joined #linux-sunxi
<tdebrouw> not sure where to ask this question:
<tdebrouw> I'm trying to dump the ddr registers on linux
<tdebrouw> of the V40
<tdebrouw> according to the uboot code, phys address 0x01c63000 (and following)
<tdebrouw> when trying devmem, the addresses all return 0
<tdebrouw> are these registers masked somehow?
<tdebrouw> ddr registers = ddr ctl registers
<KotCzarny> try dumping from uboot?
kaspter has quit [Read error: Connection reset by peer]
kaspter has joined #linux-sunxi
ldevulder_ is now known as ldevulder
vagrantc has joined #linux-sunxi
ldevulder_ has joined #linux-sunxi
<tdebrouw> the board is not using uboot :(
<tdebrouw> it's running android
<KotCzarny> android is using uboot too
ldevulder has quit [Ping timeout: 245 seconds]
<tdebrouw> i never see a boot prompt, or even a message
<KotCzarny> on uart?
<tdebrouw> yeah
<KotCzarny> that would be the first time of silent uboot
JohnDoe_71Rus has joined #linux-sunxi
suprothunderbolt has quit [Read error: Connection reset by peer]
<tdebrouw> I don't want disrupt the channel with crappy boot logs :|
<tdebrouw> since it isn't related to linux-sunxi
<KotCzarny> you can always use pastebin and drop single link
<libv> tdebrouw: one way is to silence things is to disable the uart
<libv> not that we in here see why, but i guess some android vendors might do so
<KotCzarny> libv: 2 reasons, 1/ hide something, 2/ speed up boot
<libv> true, but the delay there can be adjusted as well
<libv> and no uart will come back to bite you
<libv> unless you're a proper embedded developer... then, then, you use jtag
<tdebrouw> well, I'm trying to replace that unknown bootloader with uboot
<tdebrouw> but I need the register settings
<tdebrouw> for the ddr
<libv> and you have to first have the proper cable made and when you've gotten approval from your manager to spend the money, and completed the process, then your work is done for the next 2 weeks, as you wait for the cable to be crimped.
<libv> *sigh*
<libv> tdebrouw: it will be uboot
<KotCzarny> tdebrouw: have you tried booting mainline uboot from sdcard?
<KotCzarny> maybe r/v40 support is already good enough for your device
<libv> no-one goes out and develops its own bootloader for a single android tablet
<libv> i think some of the dashcam devices might do without uboot
<KotCzarny> i'm booting android on h3 using mainline uboot and it works well
reinforce has quit [Quit: Leaving.]
<KotCzarny> it might require few obscure settings in compilation/boot script though
florian_kc has joined #linux-sunxi
florian_kc is now known as florian
<jernej> tdebrouw: Currently U-Boot uses only one timing settings for each type of DRAM for each Allwinner SoC IIRC.
<jernej> as long as SoC and DRAM type combo is supported, it should just work
tobiasBora has joined #linux-sunxi
<jernej> well, there is adjustable frequency, but that should be relatively easy to find out from android logs
<tobiasBora> Hello,
<KotCzarny> or by reading memory markings
tnovotny has quit [Quit: Leaving]
<jernej> not necessarily, because frequency depends also on board routing
cnxsoft has quit [Quit: cnxsoft]
<tobiasBora> I have an orange pi that I bought a while ago. I used it for a few weeks without any issue, and then it suddently stoped working after some holidays. When I boot with uart I've an error ### ERROR ### Please RESET the board ###. I'm not even sure what "reset the board" means, so I tried to put on the sd card some other systems, and now, this error is not displayed, but I suspect that it's because the uart
<tobiasBora> interface is enabled only for uboot, and then when the kernel boot I think it's disabled
<tobiasBora> however, I'm not even sure to know how to enable uart to continue debuging
<KotCzarny> tobiasBora: unstable power?
<tobiasBora> I tried to look into the partition 1, there is a semi binary file containing a line with bootargs: setenv bootargs "console=ttyS0,115200 console=tty1 root=/dev/mmcblk0p2 init=/sbin/init rootwait rootfstype=ext4 panic=10 consoleblank=0 enforcing=0 loglevel=7"
<mru> probably a u-boot script file
<tobiasBora> KotCzarny: I was also thinking the same, and I tried to move from a phone power supply to a much better power supply (still on the OTG port however) I'm using for my raspberry pi
<mru> which is just text with a binary header added with mkimage
<tobiasBora> mru: so I can still modify this file by end?
<mru> what does the "file" command say it is?
<tobiasBora> mru: boot.scr: u-boot legacy uImage, , Linux/ARM, Script File (Not compressed), 471 bytes, Tue Nov 8 08:17:50 2016, Load Address: 0x00000000, Entry Point: 0x00000000, Header CRC: 0x70886F61, Data CRC: 0x5C1B4514
<jernej> tdebrouw: anyway, possible reason why you can't read controller registers from Linux is that kernel might have CONFIG_STRICT_DEVMEM=y set
<mru> yep, it's a u-boot script
<tobiasBora> I see some people mentionning overlays=sun8i-h3-uart1, but not sure where to add that in my case
<KotCzarny> mru, lack of uboot script doesnt result in internal uboot error
<tobiasBora> (and I have h2+, not h3, don't know if it can still work)
<KotCzarny> doesnt matter
<tobiasBora> KotCzarny: I'm interested by this script just to enable uart again to see if I still have the same error (I guess I do however because the orange pi does not connect to the network)
<KotCzarny> h2+ is marketing rebrand of h3
<tobiasBora> it's funny, h2+ sounds like h2+ < h3
<KotCzarny> nah
<KotCzarny> just marketing
<mru> that u-boot error is printed if something happens that shouldn't happen
<tobiasBora> ok
<mru> like an unexpected exception
<tobiasBora> and is it possible to know what kind of exception it is?
<KotCzarny> tobiasBora: write new armbian/h3droid to the card and boot?
<KotCzarny> might be faster
<KotCzarny> but i bet on power/sdcard troubles
<tobiasBora> I can try with armbian or h3droid sure
<tobiasBora> which one is the easier to setup/debug, or are you more familiar with?
<KotCzarny> you can also just write uboot part
<tobiasBora> (I remember using armbian when I first used it)
<tobiasBora> if it's enough sure. What file should I use for that? I still don't understand lot's of stuff concerning uboot
<tobiasBora> (even if last time you helped me a lot understanding new stuff)
<KotCzarny> uboot is first megabyte of sdcard skipping first 8kB
<KotCzarny> \ie. 8kb-1023kb
<tobiasBora> and to get it I should download armbian, and then dd only 1023kb?
<KotCzarny> do you have spare sdcard?
<KotCzarny> might be easier since you arent proficient with dd
<tobiasBora> you mean like another sd card?
<KotCzarny> yes
<tobiasBora> I have another one, but I don't really trust the other sd card, I had very strange errors with it...
matthias_bgg_ has quit [Read error: Connection reset by peer]
<KotCzarny> sdcard errors are often result of bad power
matthias_bgg_ has joined #linux-sunxi
<tobiasBora> well this error was on my desktop computer
<tdebrouw> I'm sorry for the late respons -> someone on the telephone
<tobiasBora> lot's of file were renamed with strange binary names
<tobiasBora> but I can use it if you want
<tdebrouw> i tried mainline uboot, as is, on a SD card
<tdebrouw> and I see the SPL line, and that's it
<tdebrouw> it should state something on memory, but I don't see it. :)
<tdebrouw> [ 0.33]HELLO! BOOT0 is starting!
<tdebrouw> I don't think uboot is outputting this. :]
<KotCzarny> boot0 is boot rom, loads uboot
<mru> the rom doesn't print anything
<mru> that "hello" message is from something else
<mru> some horrid allwinner bootloader, I guess
reinforce has joined #linux-sunxi
<tobiasBora> KotCzarny: so I put armlinux, I don't have any message after http://paste.debian.net/1100284
<jernej> tdebrouw: so you're not using mainline U-Boot?
florian has quit [Ping timeout: 245 seconds]
<tdebrouw> errr
<tobiasBora> and still does not appear with nmap
<tdebrouw> wait
<tdebrouw> the board comes with a bootloader on the emmc -> that is showing the BOOT0 thing
<tdebrouw> if I compile mainline uboot itself
<tdebrouw> it hangs after a SPL print
<jernej> and what RAM size SPL print reports?
<tdebrouw> it never gets to uboot itself
<tdebrouw> sec
<tdebrouw> U-Boot SPL 2018.09 (Sep 05 2019 - 17:51:15 +0200)
<tdebrouw> DRAM:
<tdebrouw> and then it hangs
<tdebrouw> errr
<tdebrouw> that's not the mainline one
<tdebrouw> wrong output
<tdebrouw> sec ^ 2
<tobiasBora> Ok, here is the full log or error http://paste.debian.net/1100285
<tobiasBora> mmc_load_image_raw_sector: mmc block read error
<tobiasBora> SPL: failed to boot from all boot devices
kaspter has quit [Read error: Connection reset by peer]
<KotCzarny> mmc read error usually means bad sdcard, bad power or bad sdcard slot seating
<tdebrouw> jernej: this is mainline with 1 patch (moving phy1 to different address)
<tdebrouw> U-Boot SPL 2019.10-rc3-00286-ge4499268dd (Sep 12 2019 - 17:33:14 +0200)
<tdebrouw> DRAM:
<tdebrouw> and then, it hangs
<jernej> ok, so it seems that wrong type of DRAM is selected in U-Boot config
kaspter has joined #linux-sunxi
<tdebrouw> but, when booting with the magic BOOT0 stuff, it works
<jernej> yeah, because it autodetects DRAM type
<jernej> while in mainline, you have to select correct one
diego_r has quit [Quit: Konversation terminated!]
<jernej> possible options for R40 - DDR2, DDR3 and LPDDR3
<tdebrouw> it's currently the DDR3 one
<jernej> and what kind of chips you have?
<mru> potato or tortilla?
<tdebrouw> ddr chip: AW52A8G32
<tdebrouw> also allwinner
<mru> google says that's lpddr3
<tdebrouw> you found a datasheet that fast?
<tdebrouw> I haven't found one yet
<tdebrouw> I'll just try the LPDDR settings
<KotCzarny> wow, allwinner does drams now
<tdebrouw> yeah
<jernej> for some time now
<tdebrouw> the previous version of this specific board
<tdebrouw> contained a different ddr (which was working with default settings)
<mru> tdebrouw: not a datasheet, but I found this page: https://world.taobao.com/item/40180729458.htm
<tdebrouw> lol
<tdebrouw> ....
<tdebrouw> it works
* tdebrouw goes hiding under his rock
<tdebrouw> jernej: any idea how the boot0 thingie detects the ddr type?
<tdebrouw> is there any source code for the BOOT0 loader?
<mru> could be as simple as trying all the types until one works
<jernej> in short, yes
<jernej> I think there are sources for some parts of BOOT0 loader
<jernej> dram initialization is mostly provided as a binary blob
<tobiasBora> KotCzarny: hum... I tried two sdcard, two power supply, and to put paper behind the sdcard to force better connecting... Still no change
<KotCzarny> tobiasBora: there is always a possibility your hardware dies
<tobiasBora> I think it's actually pretty likely, especially because it stoped working quite abruptely
<tobiasBora> anyway, thanks for you help!
<MoeIcenowy> tdebrouw: boot0 of what chip?
<MoeIcenowy> R40?
<tdebrouw> yea
<MoeIcenowy> I think on R40 boot0 doesn't probe DDR type
<MoeIcenowy> it relies on some data injected to the boot0 header
<MoeIcenowy> which is the DRAM configuration
<tdebrouw> crap
<MoeIcenowy> do you know FEX file of Allwinner?
<MoeIcenowy> it's the [dram_para] section of the FEX
<tdebrouw> no, I haven't heard of the FEX file (yet) -> but I just found it on the wiki.
<tdebrouw> I'll read it
<tdebrouw> is this some kind of config file for the boot0? (wild guess)
<KotCzarny> no, for legacy kernel
<KotCzarny> but contains config of the hardware
<KotCzarny> so is useful
yann|work has quit [Ping timeout: 245 seconds]
clonak has joined #linux-sunxi
forkbomb has quit [Ping timeout: 264 seconds]
clonak_ has quit [Ping timeout: 264 seconds]
forkbomb has joined #linux-sunxi
tllim has joined #linux-sunxi
AneoX has quit [Ping timeout: 276 seconds]
AneoX has joined #linux-sunxi
aalm has quit [Quit: xyz 2.3]
florian has joined #linux-sunxi
florian has quit [Ping timeout: 245 seconds]
yann|work has joined #linux-sunxi
aalm has joined #linux-sunxi
matthias_bgg_ has quit [Ping timeout: 245 seconds]
AneoX has quit [Quit: Textual IRC Client: www.textualapp.com]
<MoeIcenowy> KotCzarny: it's not only for legacy kernel
<MoeIcenowy> it's for the whole BSP
<MoeIcenowy> also contains config for BSP U-Boot and boot0
craigo has quit [Ping timeout: 246 seconds]
rah_ is now known as rah
return0e has quit [Read error: Connection reset by peer]
return0e has joined #linux-sunxi
Putti has quit [Remote host closed the connection]
tdebrouw has quit [Quit: Leaving.]
marekbelisko has joined #linux-sunxi
Putti has joined #linux-sunxi
marekbelisko has quit [Quit: This computer has gone to sleep]
marekbelisko has joined #linux-sunxi
<willmore> libv, it's on reboot, so without a serial console, I don't know if it's in the shutdown or startup side of things. I'll hook up serial and see what I get. Interestingly, I'm in the middle of debugging some serial adapter problems, so I have a bunch of them handy.
marekbelisko has quit [Quit: This computer has gone to sleep]
<Mangy_Dog> when sending and receiving USB data... is it handled in a similar way to standard serial like in arduino? just faster? So if i wanted to I could setup my USB HID to allow for receiving data as well as sending it. And on my host machine run a scrip that would send data through a serial.write type of command?
<Mangy_Dog> would i need to create an allownace for receiving data in the USBs disciptor?
JohnDoe_71Rus has quit [Quit: KVIrc 5.0.0 Aria http://www.kvirc.net/]
florian has joined #linux-sunxi
juri_ has quit [Ping timeout: 245 seconds]
<willmore> Mangy_Dog, do you mean to ask on #arduino or something?
<Mangy_Dog> no its a pi and usn HID question
<Mangy_Dog> just a more generalised question
vagrantc has quit [Quit: leaving]
<wens> willmore: Orange Pi seemed to have gotten a bad batch of chips, in that the normal watchdog does nothing
<wens> willmore: reboot on the Pine H64 works fine with either watchdog
<wens> willmore: IIRC we patched the DT to only use R_WDOG
ed_peguillan has joined #linux-sunxi
warpme_ has quit [Quit: warpme_]
<slapin> have anybody had success with X11 + silead touch? I try to make it work sanely on poky, it sort of works but inprecise and not linear.... and calibration seems to be ignored too; is there some tool I miss?
<slapin> looks like it multiplies coordinates by 2 and offsets for a few pixels on both dimentions
<slapin> the results are consistent though
<slapin> wens: ^
<wens> slapin: it might be the touchscreen dimension isn't the same as the display?
tdebrouw has joined #linux-sunxi
tdebrouw has quit [Client Quit]
<slapin> wens: dunno, it is strange, the fex data says 800x480 same as screen, I set it to that value
return0e has quit [Ping timeout: 246 seconds]
<slapin> the problem is that I use firmware which is not from driver tablet uses, but from another .ko in the same directory; but firmware I extract from driver tablet uses in Android for some reason does not work on mainline silead driver
tuxillo has quit [Remote host closed the connection]
<slapin> maybe I just need to hack silead.c's output values with hack patch
<slapin> will see about this
<willmore> wens, thank you for the heads up.
<willmore> slapin, I may be completely misremembering this, but the 'firmware' for that chip may just be calibration data--dimensions, resolution, etc.
<willmore> I'm probably wrong on that.
NeuroScr has joined #linux-sunxi
<wens> the mainline driver will not scale values for you. maybe the bsp one does
florian has quit [Ping timeout: 245 seconds]
<willmore> It strikes me that would be a good thing for the driver to do--with values from dts
florian has joined #linux-sunxi
reinforce has quit [Quit: Leaving.]
curlybracket has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
<slapin> willmore: I think the problem is dts, as it seems like when you switch x/y everything is messed up inconsistengly, so I will try to write resolution in revers and maybe it will fix scaling of coordinates
tuxillo has joined #linux-sunxi
curlybracket has joined #linux-sunxi
s_frit has quit [Remote host closed the connection]
s_frit has joined #linux-sunxi
ldevulder__ has joined #linux-sunxi
ldevulder_ has quit [Ping timeout: 265 seconds]
florian has quit [Ping timeout: 245 seconds]
<willmore> slapin, good luck.
return0e has joined #linux-sunxi
ganbold_ has joined #linux-sunxi
ganbold has quit [Ping timeout: 245 seconds]
Mangy_Dog has quit [Ping timeout: 265 seconds]
Mangy_Dog has joined #linux-sunxi
juri_ has joined #linux-sunxi
Mangy_Dog has quit [Remote host closed the connection]