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*
<apritzel> smaeul: hi, do you have the addresses/bits for the CPUIDLE hardware on the H616 handy?
<smaeul> apritzel: I believe it's the same as H6
<apritzel> smaeul: thanks, will try that
sunshavi has joined #linux-sunxi
ChriChri has quit [Ping timeout: 256 seconds]
ChriChri has joined #linux-sunxi
dev1990 has quit [Excess Flood]
dev1990 has joined #linux-sunxi
ChriChri_ has joined #linux-sunxi
apritzel has quit [Ping timeout: 264 seconds]
ChriChri has quit [Ping timeout: 256 seconds]
ChriChri_ is now known as ChriChri
Mangy_Dog has quit [Ping timeout: 264 seconds]
ChriChri_ has joined #linux-sunxi
ChriChri- has joined #linux-sunxi
ChriChri has quit [Ping timeout: 265 seconds]
ChriChri has joined #linux-sunxi
ChriChri_ has quit [Ping timeout: 264 seconds]
ChriChri- has quit [Ping timeout: 264 seconds]
ChriChri_ has joined #linux-sunxi
ChriChri has quit [Ping timeout: 240 seconds]
ChriChri_ is now known as ChriChri
lucascastro has joined #linux-sunxi
ChriChri_ has joined #linux-sunxi
ChriChri has quit [Ping timeout: 272 seconds]
ChriChri_ is now known as ChriChri
warpme_ has quit [Quit: Connection closed for inactivity]
ChriChri_ has joined #linux-sunxi
ChriChri has quit [Ping timeout: 240 seconds]
ChriChri_ is now known as ChriChri
ChriChri_ has joined #linux-sunxi
ChriChri has quit [Ping timeout: 265 seconds]
ChriChri_ is now known as ChriChri
karaokes has joined #linux-sunxi
tuxillo has quit [Ping timeout: 256 seconds]
ChriChri_ has joined #linux-sunxi
ChriChri has quit [Ping timeout: 265 seconds]
ChriChri_ is now known as ChriChri
ChriChri_ has joined #linux-sunxi
ChriChri has quit [Ping timeout: 240 seconds]
ChriChri_ is now known as ChriChri
tuxillo has joined #linux-sunxi
gediz0x539 has joined #linux-sunxi
aliosa27_ has quit [Read error: Connection reset by peer]
narmstrong has quit [Ping timeout: 240 seconds]
aliosa27_ has joined #linux-sunxi
steev has quit [Read error: Connection reset by peer]
narmstrong has joined #linux-sunxi
steev has joined #linux-sunxi
lurchi__ has joined #linux-sunxi
lurchi_ has quit [Ping timeout: 240 seconds]
reinforce has joined #linux-sunxi
apritzel has joined #linux-sunxi
asdf28 has joined #linux-sunxi
prefixcactus has quit [Ping timeout: 256 seconds]
apritzel has quit [Ping timeout: 240 seconds]
s_frit has joined #linux-sunxi
hlauer has joined #linux-sunxi
pCactus has joined #linux-sunxi
netlynx has joined #linux-sunxi
chewitt has quit [Quit: Adios!]
ChriChri_ has joined #linux-sunxi
ChriChri has quit [Ping timeout: 240 seconds]
ChriChri_ is now known as ChriChri
ChriChri_ has joined #linux-sunxi
ChriChri has quit [Ping timeout: 264 seconds]
gediz539 has joined #linux-sunxi
<megi> anyone seen a bunch of these in 5.11? "mmc_erase: group start error -110, status 0x0"
<megi> they only happen on H5/H6 mmc0 so far
<megi> H3 boards are fine, somehow
ChriChri_ has quit [Ping timeout: 240 seconds]
ChriChri has joined #linux-sunxi
gediz0x539 has quit [Ping timeout: 264 seconds]
<megi> looks like trim timeouts
cmeerw has joined #linux-sunxi
ChriChri has quit [Ping timeout: 256 seconds]
ChriChri has joined #linux-sunxi
<montjoie> I seek this log in my board farm, no evidence yet
ChriChri has quit [Ping timeout: 240 seconds]
karaokes has quit [Remote host closed the connection]
cmeerw has quit [Ping timeout: 272 seconds]
gediz539 has quit [Ping timeout: 240 seconds]
gediz0x539 has joined #linux-sunxi
prefixcactus has joined #linux-sunxi
mmarc__ has joined #linux-sunxi
pCactus has quit [Ping timeout: 256 seconds]
<megi> you'd probably need something that does trim on the background, like f2fs
<megi> anyway, I've completely patched out PM out of mmc, and it stopped happening
qCactus has joined #linux-sunxi
<megi> with PM included my dmesg on H5/H6 looks like this https://megous.com/dl/tmp/14b4f6b393e68b2b.png
<megi> I wonder why that is, because I don't have these issues on A64 for example
s_frit has quit [Remote host closed the connection]
s_frit has joined #linux-sunxi
ldevulder__ is now known as ldevulder
lurchi__ is now known as lurchi_
megi has quit [Quit: WeeChat 3.0]
megi has joined #linux-sunxi
mmarc__ has quit [Remote host closed the connection]
<qCactus> Good morning, chat
<asdf28> :->
<qCactus> Why might u-boot not detect the SD card?
<qCactus> (SPL does successfully load u-boot from it, so it definitely works there...)
<KotCzarny> some boards have sd-card detect pin unwired
<KotCzarny> so one has to configure sdcard as always present (ie. ignore sd detect status)
<qCactus> is this the pin labeled as "CD"?
<KotCzarny> probably
<qCactus> if so, I've already run into that in the SPL, and after specifying the right pin in .config it does detect the card and load uboot from it
<qCactus> Could it be that the pin is configured in different places for the SPL and u-boot proper?
netlynx has quit [Quit: Ex-Chat]
JohnDoe_71Rus has joined #linux-sunxi
Net147 has quit [Quit: Quit]
Net147 has joined #linux-sunxi
lkcl has quit [Ping timeout: 272 seconds]
ldevulder_ has joined #linux-sunxi
mmarc__ has joined #linux-sunxi
ganbold_ has joined #linux-sunxi
laj_ has quit [Remote host closed the connection]
laj_ has joined #linux-sunxi
ldevulder has quit [Ping timeout: 240 seconds]
mmarc__ has quit [Ping timeout: 264 seconds]
ganbold has quit [Ping timeout: 265 seconds]
lkcl has joined #linux-sunxi
pCactus has joined #linux-sunxi
prefixcactus has quit [Read error: Connection reset by peer]
daregap has joined #linux-sunxi
jstein has quit [Quit: quit]
matthias_bgg has joined #linux-sunxi
Mangy_Dog has joined #linux-sunxi
gediz0x539 has quit [Read error: Connection reset by peer]
gediz539 has joined #linux-sunxi
apritzel has joined #linux-sunxi
<apritzel> qCactus: U-Boot takes the CD pin from the DT, whereas the SPL uses a config variable
<apritzel> qCactus: where is your CD pin? PF6?
<qCactus> I suspected that might be the case...
<qCactus> My CD pin is on V24
<apritzel> the BPi-M2-Ultra uses a different one (PH13), which is in the DT node
<apritzel> which GPIO is this?
<apritzel> what do you have in the SPL config variable?
<qCactus> AFAIK, V24 is the GPIO name
<apritzel> so V24 wouldn't be parsed correctly by the SPL, I guess we need to improve our error reporting there
<apritzel> can you check the schematic for any other name associated with this pin?
<apritzel> and since you have a U-Boot prompt now: you can verify this: "gpio input PI11"
<apritzel> once with and once without a card inserted
<qCactus> It's labeled "V24_SDC0_DET"
<apritzel> but where does it lead to? is that the pin name on the SoM?
<qCactus> apritzel: pin PI11 (gpio 267) value is 0
<qCactus> the pinout of the SoM labels it the same
<apritzel> always? you would need to look for a change when you remove the card (or insert it again)
<qCactus> It flips to 1 without the card
<apritzel> so there you have it
<apritzel> use "PI11" in the U-Boot config, and <&pio 8 11 GPIO_ACTIVE_LOW>; in the DT
<apritzel> and yeah, the other pin names on the SoM module look like ball names as well (AA13 = SDC0_CMD)
<qCactus> oh, by the way
<qCactus> how do I find the CD pin for the eMMC?
<apritzel> there is no CD pin for eMMC - by the very nature of an *e*MMC it's not necessary ;-)
<qCactus> well, yes, but I suspect the detection code is the same, so it must probe something...
<apritzel> eMMC DT nodes typically have a "non-removable" property in their DT, to skip the card detection code
<qCactus> hm, renaming the pin in the defconfig was enough
<qCactus> ah, no, sorry, it was me enabling CONFIG_MMC_BROKEN_CD in .config
<apritzel> qCactus: I would recommend you copy the M2-Ultra .dts file, and go over every single node, checking whether it applies to your board or not, and if in doubt, removing it
elros1 has joined #linux-sunxi
ldevulder_ is now known as ldevulder
mmarc__ has joined #linux-sunxi
mmarc__ has quit [Remote host closed the connection]
<apritzel> qCactus: btw: if you need to know the GPIO names for those ball names, check the R40 *datasheet* (on the R40 wiki page)
<qCactus> Thanks, will do
<apritzel> that's the one from MoeIcenowy which should add proper dual rank support for the R40 (click on the "diff" button in the top right corner to download)
<qCactus> Sure, I'll try it.
<qCactus> I wanna try booting something first, however
<apritzel> pfft, booting ...
mmarc__ has joined #linux-sunxi
lurchi_ is now known as lurchi__
lurchi__ is now known as lurchi_
<MoeIcenowy> apritzel: what's CPUIDLE?
<apritzel> MoeIcenowy: some hardware state machine in H6 and newer, which does the CPU power off sequence, without needing the ARISC
<apritzel> smaeul discovered this recently
<apritzel> so you put in some magics, then say with core you want to power off, and the hardware waits for that core to enter WFI
<apritzel> then it (presumably) does the proper A53 power down sequence, which we did on the OpenRISC so far
lkcl has quit [Ping timeout: 264 seconds]
<ullbeking> Are we basically at the end of the road for Allwinner SBC's? Will there ever be a time that I can create a proper NAS with one...
<ullbeking> Or have USB3?
<ullbeking> Or SATA? Or 2x NICs?
<ullbeking> I've had a lot of use from my OPi +2E's, but for IO, forget it
<apritzel> H6 has USB3.0
<ullbeking> apritzel: ty
<apritzel> and some SoCs have two MACs, though one is 100MBit/s only
<ullbeking> Loading 2 NIC's and 2 SATA converters onto an H6's USB3 bus.... Is that feasible?
<apritzel> but I think as we have discussed here before, it simply may not be a fit
<ullbeking> Indeed. This conversation is happening all over the place by many folks
<apritzel> Allwinner is clearly moving into specialising their SoCs (automotive, camera, smart speaker, tablet)
<ullbeking> I'm getting deja vu
<apritzel> the A20 was one-SoC-to-rule-them-all, with SATA, Gigabit-MAC, HDMI, and what not all in one chip
<apritzel> but newer tablet chips for instance drop Ethernet and HDMI (b/c not needed in a tablet)
<ullbeking> I tend to find that mini ITX Atom boards are the best value for me
<apritzel> and to be honest: those SBCs (and especially those "I make a NAS out of it b/c I can't afford a real one") was always some kind of hack, if you like
<ullbeking> I agreed
<ullbeking> Agree*
tnovotny has joined #linux-sunxi
mmarc__ has quit [Remote host closed the connection]
<ullbeking> I just can't wrap my head around NAND flash surviving any real use cases over time (firewall, etc) where the OS needs to read/write....
<ullbeking> Before the nand flash dies
<ullbeking> I've missed some bit of info along the way
<ullbeking> I'll drop the topic now
lkcl has joined #linux-sunxi
mmarc__ has joined #linux-sunxi
<qCactus> apritzel: I applied the patch and now make complains at me that "Device Tree Source is not correctly specified."
<apritzel> qCactus: you changed arch/arm/dts/Makefile, right? If yes, make sure you have the backslashes right at the end of the lines
JohnDoe_71Rus has quit [Quit: KVIrc 5.0.1 Aria http://www.kvirc.net/]
<qCactus> apritzel: I diffed it with the bananapi dts, and the only differences are a couple blocks commented out and the CD0 pin changed. There are no backslashes in either.
<apritzel> I mean in the Makefile, you would need to add your file in there, also name it in the defconfig, as CONFIG_DEFAULT_DEVICE_TREE
<qCactus> well, it says DRAM: 0 MiB :)
<apritzel> well, good to know, at least
asdf28 has quit [Ping timeout: 246 seconds]
<qCactus> apritzel: I figured it out now. It was due to my reverting to vanilla 2020.10 before applying the patch, with para.dual_rank hardcoded to 0. Now the patched branch works and boots to uboot console as before
reinforce has quit [Quit: Leaving.]
asdf28 has joined #linux-sunxi
<MoeIcenowy> apritzel: BTW even w/o dual rank support I think the DRAM should still work (but with half capacity)
<MoeIcenowy> qCactus: well yes my patch didn't drop the hardcode of dual_rank
JohnDoe_71Rus has joined #linux-sunxi
<qCactus> MoeIcenowy: Seems like it should, but for some reason it doesn't with this board
<MoeIcenowy> qCactus: then it's mysterious
<MoeIcenowy> but with dual rank enabled the DRAM is initialized properly?
lurchi_ is now known as lurchi__
<apritzel> MoeIcenowy: it even worked before, by just disabling the R40 dual rank panic bits
<MoeIcenowy> apritzel: w/ the hardcode it should not trigger the dual rank panic bits, right?
<apritzel> in this case all four chips are equal, so no special treatment needed for rank1
<MoeIcenowy> apritzel: well yes
<MoeIcenowy> my patch is only needed for the quirky situation
<qCactus> MoeIcenowy: If you remove just the hardcode, then the panic bits *are* triggered. If you remove both, it works fine
<MoeIcenowy> BTW I'm thinking about whether it's safe to just remove the panic
<qCactus> at least fine enough to not get any errors reading/writing different patterns across the whole memory
<MoeIcenowy> (because we may search dual rank configuration first, and if we're sure that it's single rank, enable A15 then
<MoeIcenowy> (I think A15 is used by the DRAM chip of BPi M2U, right?
<MoeIcenowy> if it is then we can do a regression test
<apritzel> MoeIcenowy: looks like a good point, just checked the datasheet of the M2U DRAM, they have indeed 16 rows, and use A0-A15
elros1 has quit [Remote host closed the connection]
<apritzel> I only have the M2 Berry, which uses 15 rows
warpme_ has joined #linux-sunxi
<MoeIcenowy> apritzel: I have a M2U, but my storage is a mess that I need some time to find it
<apritzel> MoeIcenowy: no worries, take your time
<apritzel> so do I get this right that we would try dual rank first, which would configure A15 as CS1, so this would somehow work, but obviously isn't right?
<MoeIcenowy> apritzel: I think so
<MoeIcenowy> our detection routine is current:
<MoeIcenowy> detect rank + DQ width by doing train, then detect bank, row, column
<MoeIcenowy> detect rank+DQ is done by
<MoeIcenowy> mctl_channel_init
<MoeIcenowy> and the bank/row/col detection is done by mctl_auto_detect_dram_size
<MoeIcenowy> when doing the rank+DQ detection, the bank/row/col values are just placeholders
<MoeIcenowy> (BTW my patch is designed to do bank/row/col detection for both ranks
<MoeIcenowy> (in case they're not equal
matthias_bgg has quit [Ping timeout: 240 seconds]
<bauen1> pine64 is planning to build a linux-capable risc-v board (https://www.pine64.org/2021/02/15/february-update-show-and-tell/) using a risc-v core made by allwinner in a partnership with alibaba if i'm understanding things correctly (https://www.cnx-software.com/2020/11/09/xuantie-c906-based-allwinner-risc-v-processor-to-power-12-linux-sbcs/)
<apritzel> MoeIcenowy: yeah, it's hard to guess what would happen, the DRAM controller would think there are more chips, so would issue more refresh commands, for instance
<MoeIcenowy> bauen1: yes, you got it correctly
cmeerw has joined #linux-sunxi
<MoeIcenowy> apritzel: we hope the DRAM controller can differienate a wire connected to A15 with it connected to CS1
<bauen1> but details on the security side of the risc-v core are pretty non-existent over the web as far as i can find
<apritzel> bauen1: but that's mostly an integration choice anyway, isn't it?
lurchi__ is now known as lurchi_
<bauen1> true true, and allwinner doesn't just give out details for free :/
<apritzel> and *Allwinner* integrating a RISC-V core doesn't change exactly nothing for the community, because the core is the least of our problems
<apritzel> (it just saves *them* the license fees and royalties for the cores)
<mripard> apritzel: I assume you took your ARM hat off to say that one ? :)
<apritzel> mripard: I am certainly biased, but don't really understand the excitement about that, because the problems will be the same, we will just have new bugs ;-)
* karlp does the peripherals, peripherals, peripherals dance wearing his ballmer outfit...
<mripard> apritzel: yeah, I don't totally get the hype around risc-v either
<mripard> I mean, sure, having a free ISA is nice
<mripard> but at the end of the day, you'll still have to trust whatever entity has designed and produced the core
<mripard> and it's not like you could do it in your home either
<bauen1> a free ISA should make it easier, still not practical but easier
<apritzel> yes, and nothing prevents people from using openly documented and well supported peripherals with ARM cores
<karlp> do those exist? ;)
<apritzel> karlp: that's my point: I don't see how RISC-V would change that
<karlp> I'm on your side, I was just teasing abotu the quality of periphs in general.
<zumbi> royalties story might change
<mripard> bauen1: I don't really see how the "freeness" of the ISA changes things compared to a public one like the ARM ISA is
<apritzel> that's the only point I see: it gets cheaper for Allwinner
<mripard> (as a user I mean, for a CPU designer, I definitely see the appeal)
<apritzel> I mean I get this stinginess was probably the reason they chose an OpenRISC core for the ARISC back then
<bauen1> mripard: with a "free" ISA there is nothing legally preventing you from implementing your own CPU (or softcore) and there for also makes it easier (but a pipe dream probably) to open source the hardware, at least i think so
qCactus has quit [Ping timeout: 264 seconds]
<mripard> yeah, I agree with that
<mripard> what I don't really get is the general sentiment that it's going to be the norm, and it will "save" us like the free software did
<mripard> I can recompile the software if I want to, it's going to be difficult to do for an ISA
<mripard> (except if it's a softcore)
prefixcactus has joined #linux-sunxi
<apritzel> plus I wonder how many companies would actually open source their *kick-ass* micro-arch
pCactus has quit [Ping timeout: 265 seconds]
<jernej> I'm pretty sure there will be countless proprietary RV cores popping out all over the place, mostly because toolchain already exists and it's maintained
<jernej> apritzel: smaeul: Is it possible R40 has CPUIDLE functionality? How can this be checked? It doesn't have ARISC core, so maybe they implemented some other way for standby
<smaeul> jernej: dump R_CPUCFG registers, and look for the CPU power switch sequence at offset 0x150
<smaeul> it's documented in the T3 and A40i manuals, so R40 most likely has it
<jernej> yeah, it's same die as T3 afaik
<jernej> smaeul: is this something we can use?
<smaeul> oh, the sequence is at offset 0x160 on the 32-bit chips
<smaeul> jernej: that's what I'm looking at. only the power-down function is documented, but obviously there is a power-up function as well
<smaeul> and there are at least two idle states implemented
<jernej> I assume wakeup is just interrupt based?
<apritzel> we could get rid of the ugly secure IPI core-off implementation in U-Boot
<apritzel> (but probably just for R40, so there would be little point)
<smaeul> the other A33+ cores could use an ARISC shim like in TF-A
<smaeul> so only A20 needs the IPI
<smaeul> jernej: at least one idle state is, yes. since AW uses GICv2, the IRQ/FIQ signals are visible outside the cluster
<smaeul> there are some GIC-related status/mask registers in CPU_SUBSYS_CFG, but AW doesn't use them, and they appear to do nothing
<smaeul> if the CPUIDLE status allows the ARISC to see pending IRQs, then I can implement DRAM idle in crust as well (check IRQ status and resume DRAM before powering any cores back on)
<smaeul> though I'm not sure how to check other MBUS master status
<jernej> oh, if only we could peak into HDL :)
<apritzel> jernej: even if that would be twice as good as their software, you probably *don't* want to have a look ;-)
<jernej> oh, I'm quiet accustomed reading HDL for documentation purposes
<smaeul> apritzel: while I'm still investigating, to answer "what bits does CLOSE_CORE[0:3] touch?", it is 1) DBGPWRDUP, 2) gating / output clamps, and 3) power switch
<smaeul> so it doesn't touch any resets, but that should be fine as long as the resets are asserted during power-up (which they are)
<apritzel> smaeul: the A53 TRM doesn't mention any resets on power down, so that seems to be fine
<smaeul> its funny how we go through this effort to handle DBGPWRDUP when I doubt anyone (using mainline) has ever tried to use CoreSight on these SoCs :)
<apritzel> smaeul: yeah, I guess just pulling the plug (remove power) would actually already work, as long as we do the powerup correctly
<apritzel> I wonder if using the CPUIDLE h/w for U-Boot's PSCI implementation on the R40 would still make sense, as we don't pull other cores out of Linux, also allow core0 to be powered off
<apritzel> and we seem to already have quite some #ifdef R40 in the code anyway
<smaeul> core0 hotplug on 32-bit has never worked, because it requres the additional hotplug flag (... also which is broken on H3 at least)
<smaeul> thankfully Linux inhibits it by default
<apritzel> oh, it is like on the A64, where there is no separate "power switch" for core0?
<smaeul> no, I'm meaning in the BROM -- if you don't set the CPU0 hotplug flag (like you do for return to FEL), CPU0 will run through the normal boot-up path
<smaeul> I have an M2U, so I will throw R40/A40i CPUIDLE on the todo pile, after H3 SCPI
<apritzel> smaeul: how is that going with 32-bit TF-A? Any problems?
vagrantc has joined #linux-sunxi
<smaeul> apritzel: the main problem with 32-bit TF-A is that it doesn't fit in SRAM A2
<smaeul> so I was thinking I would rather clean up the U-Boot PSCI implementation
<smaeul> the big SRAM wasters are MMU and dynamic service registration. and since TF-A unconditionally uses spinlocks (ldrex/strex), I can't run it with MMU off
<apritzel> yeah, I was wondering about that ...
<apritzel> smaeul: funny enough the requirement for MMU on is not really documented nor enforced
<apritzel> there is just this silent reliance of exclusives to work
<apritzel> s/of/on/
<smaeul> maybe they would accept a config option to avoid use of ldrex/strex? I'd have to check if sp_min would fit in 16k even with no MMU
<apritzel> smaeul: and yeah, I thought already that PSCI in U-Boot is much smaller in size
<apritzel> and since most of the size is about data structure requiring page granularity, Thumb2 doesn't help here
mmarc__ has quit [Remote host closed the connection]
<apritzel> smaeul: oh, also: I pushed a new version of the H616 TF-A support here: https://github.com/apritzel/arm-trusted-firmware/commits/h616-v3
<apritzel> smaeul: there are still some smaller bits left to fix (and it needs some testing), but it's based on your patches now
mmarc__ has joined #linux-sunxi
matthias_bgg has joined #linux-sunxi
pCactus has joined #linux-sunxi
prefixcactus has quit [Ping timeout: 264 seconds]
lurchi_ is now known as lurchi__
asdf28 has quit [Ping timeout: 240 seconds]
asdf28 has joined #linux-sunxi
BenG83 has joined #linux-sunxi
warpme_ has quit [Quit: Connection closed for inactivity]
tnovotny has quit [Quit: Leaving]
matthias_bgg has quit [Ping timeout: 264 seconds]
JohnDoe_71Rus has quit [Quit: KVIrc 5.0.1 Aria http://www.kvirc.net/]
BenG83 has quit [Quit: Leaving]
mmarc__ has quit [Remote host closed the connection]
mmarc__ has joined #linux-sunxi
matthias_bgg has joined #linux-sunxi
matthias_bgg has quit [Ping timeout: 240 seconds]
s_frit has quit [Remote host closed the connection]
s_frit has joined #linux-sunxi
jbrown has quit [Ping timeout: 240 seconds]
matthias_bgg has joined #linux-sunxi
fevv8[m] has joined #linux-sunxi
cmeerw has quit [Ping timeout: 264 seconds]
mmarc__ has quit [Remote host closed the connection]
hlauer has quit [Ping timeout: 240 seconds]
jbrown has joined #linux-sunxi
luke-jr has quit [Ping timeout: 264 seconds]
sunshavi has quit [Read error: Connection reset by peer]
asdf28 has quit [Ping timeout: 240 seconds]
luke-jr has joined #linux-sunxi
sunshavi has joined #linux-sunxi
dev1990 has quit [Quit: Konversation terminated!]
matthias_bgg has quit [Quit: Leaving]