<ssvb>
vagrantc: but at the same time, the board manufacturer can take exactly the same firmware image (maybe even compiled by debian) and write it into the SPI flash before selling the board
<ssvb>
vagrantc: but board vendors can probably use some other method to initially program the SPI flash chip, which is better adapted to their production line
<ssvb>
BTW, the "spiflash-write" command of the sunxi-fel tool is not going to be used to update the firmware, but a more high level command will be introduced a bit later
<ssvb>
and the "spiflash-write" will refuse to work (unless specifically forced) in the case if the sunxi-fel tool can detect a valid firmware
<vagrantc>
sounds good to me
arossdotme-planb has joined #linux-sunxi
arossdotme has quit [Ping timeout: 250 seconds]
George__ has joined #linux-sunxi
vagrantc has quit [Ping timeout: 250 seconds]
iaglium has joined #linux-sunxi
stachhu has quit [Ping timeout: 260 seconds]
dh1tw has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
arossdotme-planb has quit [Ping timeout: 265 seconds]
nove has quit [Quit: nove]
arossdotme has joined #linux-sunxi
mzki has quit [Ping timeout: 252 seconds]
jernej has quit [Ping timeout: 256 seconds]
George__ has left #linux-sunxi ["Leaving"]
popolon has quit [Quit: WeeChat 1.4]
apritzel has quit [Ping timeout: 252 seconds]
Colani1200 has joined #linux-sunxi
<wens>
ssvb: the whole base address for a80 is different :|
chomwitt has quit [Ping timeout: 260 seconds]
Colani1210 has quit [Ping timeout: 244 seconds]
cnxsoft has joined #linux-sunxi
<wens>
tha hacker news thread is kind of depressing :(
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
arossdotme has quit [Ping timeout: 240 seconds]
jernej has joined #linux-sunxi
robogoat has joined #linux-sunxi
ninolein has quit [Ping timeout: 260 seconds]
ninolein_ has joined #linux-sunxi
arossdotme has joined #linux-sunxi
jernej has quit [Ping timeout: 256 seconds]
arossdotme has quit [Ping timeout: 248 seconds]
arossdotme has joined #linux-sunxi
cnxsoft has quit [Remote host closed the connection]
cnxsoft has joined #linux-sunxi
<MoeIcenowy>
wens: do you want to order any H2+/H5 board?
<MoeIcenowy>
apritzel: I'm wondering what firmware is shipped with the opipc2
<wens>
MoeIcenowy: don't think i have time for it :(
<wens>
my pine64 is still gathering dust
<MoeIcenowy>
mine is also so
<MoeIcenowy>
I still like my Q8 tablet :-) it is at least a full device with input device, graphical output device, battery, WLAN :-)
pg12 has quit [Ping timeout: 260 seconds]
pg12 has joined #linux-sunxi
Putti has quit [Quit: Leaving]
kido` has joined #linux-sunxi
vagrantc has joined #linux-sunxi
stk has quit [Ping timeout: 260 seconds]
TheSeven has quit [Disconnected by services]
[7] has joined #linux-sunxi
Nacho has quit [Ping timeout: 260 seconds]
Nacho has joined #linux-sunxi
stk has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
JohnDoe_71Rus has quit [Read error: Connection reset by peer]
<KotCzarny>
all boards on sunxi wiki should really use including generic templates from the soc pages, then differences and subtleties would follow
<KotCzarny>
and for xunlong's 'change one tiny part and release as a new device' it's especially true
yeoldetoast has joined #linux-sunxi
IgorPec has quit [Ping timeout: 260 seconds]
jernej has quit [Ping timeout: 246 seconds]
JohnDoe_71Rus has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
montjoie has quit [Ping timeout: 246 seconds]
IgorPec has joined #linux-sunxi
leviathanch has joined #linux-sunxi
dpg_ has joined #linux-sunxi
dh1tw has joined #linux-sunxi
stacchu has joined #linux-sunxi
dh1tw has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
codekipper has joined #linux-sunxi
<codekipper>
wens: Hi Wens, is your H3 singing yet?
<wens>
codekipper: it is
<wens>
i'm still waiting for all the a31 patches to get merged before i post it
<wens>
to avoid confusion among the similar drivers
<codekipper>
I tried your a23-h3-audio tree with my orange pi2 but I think I killed my device when I removed the audio jack
<codekipper>
no longer see the power LED
<wens>
huh? O.o
<codekipper>
I needed to enable codec and add a enable for the PA which the board has.
<codekipper>
when I removed the audio jack(i wasn't hearing anything) there was no more serial logging and I've not been able to get it to boot since
<codekipper>
did you enable anything in alsamixer(I ramped up the volume on lineout)
<wens>
just the normal controls
<wens>
yay, 4 cores on the a80
florianH has joined #linux-sunxi
Putti has joined #linux-sunxi
mrnuke has quit [Ping timeout: 260 seconds]
yann has quit [Ping timeout: 256 seconds]
gianMOD has joined #linux-sunxi
bnw has joined #linux-sunxi
mrnuke has joined #linux-sunxi
gianMOD has quit [Remote host closed the connection]
bugzc has quit [Ping timeout: 260 seconds]
gianMOD has joined #linux-sunxi
Putti has quit [Ping timeout: 244 seconds]
<ssvb>
wens: it's only different on A80, for example the A64 also uses a bit different memory map in general (the 0x10000 load address for the SPL) but still the SoC ID is located at the standard address
<ssvb>
somebody just made a bad decision with A80, hopefully they learned from it and will not do this again
dh1tw has joined #linux-sunxi
<ssvb>
things like the SID base address and different base addresses for peripherals do not cause much harm as long as we can at least derive them from the SoC ID and the SoC ID is at the standard place
<ssvb>
uart0-helloworld-sdboot uses a MIDR check hack for detecting A80 at runtime, but this only works if A80 forever remains the only Cortex-A15 based SoC from Allwinner
matthias_bgg has joined #linux-sunxi
<oliv3r>
any info on the H2 yet?
<oliv3r>
appearantly the opi zero uses it
<beeble>
ssvb: i don't think you will see another a15
apritzel has joined #linux-sunxi
<MoeIcenowy>
oliv3r: according to the init code of sun8i
<oliv3r>
ssvb: looksl ike 408 is the maximum frequency at maximum ambient temperature. I had one reboot in 4 days runtime, which happend during the weekend (so not sure if that was power related or freq. related)
<MoeIcenowy>
H2 is also sun8iw7p1, same as H3
<oliv3r>
what is the 'oldest and common' sun8i we currently have
<oliv3r>
ssvb: so at 'normal' ambient temperatures 456 - 432 seems 'fine', but raising it to tropical values makes those unstable. 408 is then the 'max' you'd set if your living on the edge. 384 thus seems to be quite sane
<ssvb>
oliv3r: do you have the a10-meminfo logs?
<oliv3r>
yeah, but temperature 'independant'
<oliv3r>
i'll run a few at diff temperatures in a few days on my super unstable board for your referene
dh1tw has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<ssvb>
is the reported dram_zq identical on all your boards when running at different ambient temperatures?
<oliv3r>
i'll check later
<oliv3r>
standup first; then checking all machines to see if they are still up :)
<oliv3r>
ssvb: in a few days (when i have confirmed the stability) i'll perform a few boots @ different temperatures to see how that influences memory timings
<oliv3r>
should be able to do quite a nice temperature range (-5 - 70
<KotCzarny>
dont forget to let it cool to that temperature before booting
<oliv3r>
ssvb: when i find time, i'll also put it in the wikified table :)
<Wizzup>
rellla: thank you - I was searching for it
<wens>
ssvb: i doubt they would, it seems a part of their toolchain
gianMOD has quit [Remote host closed the connection]
gianMOD has joined #linux-sunxi
gianMOD has quit [Remote host closed the connection]
gianMOD has joined #linux-sunxi
mzki has joined #linux-sunxi
IgorPec has quit [Read error: Connection reset by peer]
IgorPec has joined #linux-sunxi
gianMOD has quit [Remote host closed the connection]
gianMOD has joined #linux-sunxi
premoboss has joined #linux-sunxi
bnw has quit [Quit: Leaving]
codekipper has quit [Ping timeout: 260 seconds]
repka has quit [Quit: Leaving]
AneoX has joined #linux-sunxi
chomwitt has joined #linux-sunxi
station has quit [Remote host closed the connection]
Keziolio has joined #linux-sunxi
dpg_ has quit [Ping timeout: 256 seconds]
<wens>
can't figure out why the gic isn't properly setup for psci on the a80 :/
<apritzel>
wens: what's the issue?
premoboss has quit [Ping timeout: 260 seconds]
<wens>
apritzel: the ipi used to tell core0 to turn off the calling core isn't setup properly as a secure monitor fiq, so linux gets the interrupt :/
<apritzel>
wens: but you already checked that IGROUPR has a zero in there, I suppose?
<apritzel>
wens: also NSACR
<apritzel>
that's not the National Security Agency control register ;-)
<apritzel>
wens: but I guess this stuff already works for the other SoCs
<wens>
it already works on other socs, which is why i'm puzzled
<apritzel>
so I wonder if there are some isb's missing, the A15 may behave differently here due to its OoO execution
<wens>
i only have a7 cores up for now
<wens>
not even cci400 is configured
<apritzel>
so just little CPUs, one cluster?
<apritzel>
(where's the fun in that?)
gianMOD_ has joined #linux-sunxi
gianMOD has quit [Read error: Connection reset by peer]
<wens>
multi cluster management requires some more code
<MoeIcenowy>
mripard: do you have any idea on my sun4i-drm sun8i bug now?
tkaiser has joined #linux-sunxi
<tkaiser>
MoeIcenowy: H3 legacy kernel boots flawlessly on H2+
<MoeIcenowy>
tkaiser: you tested it?
<tkaiser>
MoeIcenowy: So it's more or less the same :) Nope, IgorPec did. His dev samples arrived this morning.
<MoeIcenowy>
So it's really H3- :-)
<IgorPec>
yes, it works fine :)
<KotCzarny>
4 or 2 cores?
<IgorPec>
4
<KotCzarny>
good
<MoeIcenowy>
KotCzarny: according to aw, it's 4
JohnDoe_71Rus has joined #linux-sunxi
JohnDoe_71Rus has quit [Changing host]
JohnDoe_71Rus has joined #linux-sunxi
<MoeIcenowy>
IgorPec: so what you need to do on opi0 of armbian is only porting xradio driver?
<KotCzarny>
MoeIcenowy: you never know with aw ;)
<MoeIcenowy>
KotCzarny: ?
<IgorPec>
Moeicenowy: exactly
<KotCzarny>
so, h2+ should be subsection of h3?
<tkaiser>
IgorPec: Is XR819 supposed to support BT also?
<IgorPec>
that we need to find out. do we have a docs?
<tkaiser>
KotCzarny: Most of 'recent' Allwinner SoCs are just different names for other SoCs. And this one doesn't feature GbE and 4K capabilities and seems to be otherwise an H3
<IgorPec>
tkaiser: i got few stuff today ... fwd
<tkaiser>
IgorPec: I don't see any UART connection to the chip in schematics. But I am not that good in reading this stuff :)
<IgorPec>
i haven't got that far yet. i had troubles with server migration. no more arm :(
<miasma>
KotCzarny: i could take a look at the generic templates for the wiki, but need to study how to use mediawiki a bit better first
<miasma>
don't people know about the sunxi community or why are they spreading this FUD that sunxi boards have a terrible support and no patches will be mainlined
<MoeIcenowy>
The drunk layout of Orange Pi PC 2 is now being a joke between my friends
<tkaiser>
IgorPec: Thanks. BTW: is this a Samsung EVO you're booting of?
lemonzest has joined #linux-sunxi
<miasma>
KotCzarny: yes but there's lots of hardware with no support fom the vendor, but still the community supports them
<miasma>
to me it looks like the forums are filled with some sockpuppets spreading FUD
<IgorPec>
yes, EVO 32
<MoeIcenowy>
I think Xunlong gets many free work from us :-)
<MoeIcenowy>
IgorPec: you're adding opi0 support to armbian?
<IgorPec>
MoeIcenowy: yes. tkaiser added conf yesterday, we need a wifi driver, few more fixes and we are almost there ...
<tkaiser>
MoeIcenowy: I tried to hack together the fex file based on available info and schematics, the board is more or less like OPi One or NanoPi NEO + SDIO Wi-Fi.
<apritzel>
so H5 has an internal 100Mbit PHY (like the H3), three (plus one) USB host controllers (like the H3), but the more capable MMC (5.1) from the A64
<montjoie>
arrgg H5 does not have RSA/ECC CE
<KotCzarny>
:)
<apritzel>
montjoie: but RSA is listed, or is that not enough?
<miasma>
do the nanopi neo and neo air work with the same u-boot and kernel settings?
<apritzel>
montjoie: argh, right, I had the A64 datasheet open as well ;-)
<miasma>
i could also update the wiki if someone knows what dtb/uboot defconfigs work with Orange Pi Mini 2 and Orange Pi Plus 2. apparently pcDuino4 Nano could also work with nanopi neo/orange pi one settings
<tkaiser>
miasma: Nope, Air needs one config line for eMMC and doesn't need Ethernet
<montjoie>
apritzel: my fear is that RSA/ECC is buggy and so removed (and so do not work in previous SoC)
<tkaiser>
miasma: And BTW: No H3 device can boot from USB or Ethernet ;)
<IgorPec>
tkaiser: i'll try
<tkaiser>
miasma: pcDuino4 Nano *is* a NanoPi M1 (which is an OPi One from u-boot perspective)
<miasma>
tkaiser: i need to fix that. i thought the latest uboots can netboot and load kernel from usb once they boot from some other media
<tkaiser>
miasma: Sure but still the 1st bootloader has to be on SPI flash, SD card or eMMC.
* jonkerj
was under the impression that with sun8i emac support in recent u-boot, H3 got DHCP/TFTP/NFS boot
<miasma>
jonkerj: yes but it can't boot without local media ffor u-boot
<jonkerj>
aah
<jonkerj>
you're right
<tkaiser>
jonkerj: Situation might/will change when all board vendors solder 8Mb SPI NOR flash on their boards ;)
<miasma>
tkaiser: so maybe i'll add that they should all work with orange pi one configs and are actually supported
<miasma>
just missing dedicated defconfigs and dtbs
<MoeIcenowy>
As I know, Banana Pi R2 is no longer a Allwinner board
<miasma>
tkaiser: what about the opi mini 2 / plus 2, is it safe to say they also work with opi one configs
<MoeIcenowy>
It's MT7623A
<tkaiser>
miasma: Nope, they have SY8106A voltage regulator!
<miasma>
so orange pi pc instead?
<MoeIcenowy>
I think the SPI NOR Flash may be the reason of the 30 degree placed H5 :-)
<tkaiser>
miasma: Mini 2 is like 2 and Plus 2 like Plus and I thought both are supported now by u-boot and mainline kernel?
<miasma>
tkaiser: i looked at the generated dtb files yesterday and they were still missing
cnxsoft has quit [Read error: Connection reset by peer]
<MoeIcenowy>
Someone of Banana Pi "officially leaked" something about BPI R2 on ##Orz (it's a Chinese channel)
cnxsoft has joined #linux-sunxi
<apritzel>
MoeIcenowy: anything you can share in English? Is that a successor to the BPi R1? Which SoC? which switch IC?
gianMOD has quit [Remote host closed the connection]
<tkaiser>
miasma: that's ok, Plus is suitable for 'Plus 2' also (just more DRAM and eMMC size) and Mini 2 or 2 Mini or whatever this discontuinued thingie is called can be used with OPi 2 settings
<MoeIcenowy>
apritzel: yes; the SoC is MT7623A; Switch is still unknown, but the SoC have two seperate MACs
<miasma>
tkaiser: by any chance, is there a link for nanopi neo air configs somewhere i could link to? the wiki or the friendlyarm pages don't mention how to enable the emmc/wifi in kernel/u-boot
<miasma>
it's the last missing part. after that it looks like the h3 boards are pretty much covered in the wiki
<tkaiser>
apritzel: So they will ship with a broken OpenWRT based on 3.10.x and trick users again into believing that all these Bananas would be compatible. And then customers start to try to install Bananian for A20 on it :)
<apritzel>
tkaiser: which should work with a multi_v7_defconfig kernel
<tkaiser>
apritzel: well, the tricky part is controlling the switch but if I understand correctly on MT7623A the switch is behind a separate RGMII interface (which is how it should be)
<apritzel>
tkaiser: my understanding as well
<tkaiser>
miasma: FriendlyARM folks never looked into mainline u-boot or kernel, they still fiddle around with Allwinner's u-boot 2011.09 (which reads this stuff from fex file)
<tkaiser>
apritzel: Anyway I wouldn't buy no new device from famous 'Team BPi' since... worst experience ever so far :)
<tkaiser>
Well, maybe BPi M2 Ultra to test R40 SATA performance (they still did not show a single performance result for R40)
<tkaiser>
miasma: Plus 2 *is* Plus just with twice the DRAM and eMMC size. There's nothing you could change in DT to address that. It's perfectly ok to point Plus 2 users to Plus.
<miasma>
ok
<tkaiser>
miasma: I wouldn't mention pcDuino4 Nano all the time as NanoPi M1 OEM since it is exactly that, they're 100% identical.
<tkaiser>
NanoPi M1 on the other hand is identical from a DT point of view with OPi One, just usb2/usb3 need to be enabled in DT and then *everything* already works as expected. Only 'difference' is then led color (blue vs. green)
<MoeIcenowy>
tkaiser, apritzel: From the picture from MTK
<MoeIcenowy>
on MT7623A switch is behind a TRGMII
<mripard>
tkaiser: sooo, not identical then.
<MoeIcenowy>
mripard: did you analysed my issue then?
<OtakuNekoP>
Uhm... BPI-R1 is designed as a "router-on-a-stick", and the performance of A20 is also not enough for the heavy load. So... U know...
<tkaiser>
mripard: From a end user's perspective they're identical and end users also don't understand why usb2/usb3 available on OPi One as solder pads (and *used* by users in real world scenarios) are not enabled in DT.
<Wizzup>
Are there any R40 boards yet?
<MoeIcenowy>
Wizzup: BPi M2 Ultra
<Wizzup>
it's supposed to be mostly a20 compatible, right?
* Wizzup
hopes for olimex boards
<mripard>
tkaiser: end users don't understand that if you modify the hardware, you should modify the software running on it too?
<miasma>
tkaiser: but the nanopi m1 page recommends using opi pc configs for u-boot, not opi one
eduardas_m has joined #linux-sunxi
<tkaiser>
mripard: No end users want to use hardware without having to fiddle around with dtc tool. It's really that way. They also don't understand why on NanoPi NEO only usb3 is defined since they use usb1/usb2 available on the GPIO header too.
<OtakuNekoP>
MoeIcenowy: M2U will maybe in stock at the end of Nov.
<tkaiser>
miasma: Reason is simple: Since in OPi One DT usb1 and usb2 are disabled!
<mripard>
and pointing to other random DT is not a really good idea anyway
<tkaiser>
miasma: Sorry, usb2 and usb3
eduardas_m has quit [Remote host closed the connection]
<miasma>
tkaiser, so the different regulator won't cause any issues with a different DT?
<tkaiser>
mripard: It's not that random since those board makers copy their own and other designs. I fiddled around with the DT equivalent (fex files) and required changes between those boards are minimal.
<mripard>
tkaiser: then too bad for them, because it really should be done that way.
<mripard>
tkaiser: minimal != 0
<MoeIcenowy>
mripard: end users don't know "if you modify the hardware, you should modify the software running on it too" today, because of the success of IBM-compatible PCs
<tkaiser>
miasma: It does and that's a problem. So until an own DT is available for this device users relying on unpatched mainline stuff have to choose between two sorts of misfunction.
<mripard>
and I see two majors issues with that. It creates a culture of "using other DT in general is fine" while it's really not
<MoeIcenowy>
maybe better to patch to add a dt.
<miasma>
i think even the DT stuff is going to be a mess without x86 pc like compatibility but it's really hard to keep track of all the minimal changes. would be easier if there were defconfigs for each board even they were identical
<mripard>
and it makes it impossible for us to fix that one issue when it turns out that it was not exactly the same thing after all
<mripard>
MoeIcenowy: that's a bogus argument. You can't add a non-discoverable device on a PC either
<tkaiser>
mripard: Sure, but Armbian has a quite huge user base and we get a lot of feedback if stuff doesn't work. And H3 boards are all more or less the same with the main exception being the voltage regulation which requires individual treatment.
<tkaiser>
I hope that situation with DT overlays will improve.
<apritzel>
I wonder if the DTs should be patched / generated in firmware then, given that we have board specific U-Boots anyway
<tkaiser>
Since *then* a NanoPi NEO user can use all 4 USB ports instead of just 2 as it's now for reasons I fail to understand.
<MoeIcenowy>
mripard: someone can, such as you and me and others here
<MoeIcenowy>
but we know the sentence
<mripard>
tkaiser: and I'm not sure how that relates to things that work or don't work
<mripard>
my point is we want one DT per board
<MoeIcenowy>
maybe we should say "one DT per compatibility board"
<tkaiser>
Just curious: new Orange Pi Zero exposes USB OTG and one host port as type A port and the other 2 USB host ports on a 13 pin header. How should DT look like? usb2/usb3 disabled by default or not?
<mripard>
I don't care how much they have in common, we can have as many includes as we want and share the common stuff that way
<tkaiser>
mripard: I fully agree with 'one DT per board'
<miasma>
mripard: so what would be the next step to reach there? someone posts the new stuff to linux arm ml? does the upstream know the exact list of missing h3 board DTs?
<MoeIcenowy>
miasma: mripard is the upstream maintainer of sunxi dts
<miasma>
:P
<MoeIcenowy>
and if there's a board that he do not know but you know, you can send your dt patch, and he will then know :-)
<mripard>
miasma: I don't but I'd be glad that you show me that list by sending patches :)
<tkaiser>
mripard: and who maintains u-boot patches for sunxi/H3 boards?
<mripard>
hans
<MoeIcenowy>
Hans de Goede
<MoeIcenowy>
You can retrieve his email in MAINTAINERS file of U-Boot
<MoeIcenowy>
he do not use IRC.
<miasma>
mripard: i tried to document the situation a bit by updating the wiki. hopefully it will help a bit so people don't need to ask tkaiser again and again :)
mhlavink_away has quit [Ping timeout: 245 seconds]
<MoeIcenowy>
you can try to send out a dt patch
<MoeIcenowy>
this may be your way to enter kernel contributing :-)
<tkaiser>
In Armbian we don't care about that at all since there we have now a mechanism which checks SDIO and if there's nothing then no Wi-Fi driver is loaded.
<MoeIcenowy>
in mainline SDIO can get autoprobed...
<mripard>
miasma: we won't maintain the armbian patches though
<MoeIcenowy>
miasma: you can try to mainlinize armbian patches
<MoeIcenowy>
it will be an advance for both armbian and mainline
<tkaiser>
mripard: MoeIcenowy: That's a perfect example: Are users allowed to use DT for OPi 2 on OPi 2 Mini (which *only* lacks the SDIO Wi-Fi chip is otherwise 100% identical)?
<miasma>
MoeIcenowy: i don't use armbian :)
<MoeIcenowy>
tkaiser: I think the answer is "yes", as it's the same situation we met on Q8s
<MoeIcenowy>
some Q8s use USB Wi-Fi, some SDIO Wi-Fi
<MoeIcenowy>
so on Q8 general dt, both is enabled
<tkaiser>
So stuff is enabled in DT that is missing in reality?
<MoeIcenowy>
only for autoprobed buses
<MoeIcenowy>
This is my own thoughts
<MoeIcenowy>
mripard may not agree
<tkaiser>
So why is then usb2/usb3 disabled in OPi One DT or now usb1/usb2 in NanoPi NEO DT (there the available USB port is usb3 for whatever reasons)?
<tkaiser>
And how to deal with OPi Zero with 2 USB ports available only on a populated pin header (I know already one guy currently buying a crimp tool for Dupont wires for exactly this reason)
<MoeIcenowy>
they are only available for high-level users which can solder a USB port.
<MoeIcenowy>
for example, the hardware destroyer, me, cannot use the USB ports :-)
<tkaiser>
MoeIcenowy: On OPi Zero if you want to connect the USB touch panel controller to the board you don't need to solder. Jumper wires are enough.
<MoeIcenowy>
My opinion is to enable it
<MoeIcenowy>
but the final result should be decided by mripard
<MoeIcenowy>
I think I can connect some USB Low Speed (1.2Mbps) devices on the bus with Dupont wires
<miasma>
so what's the main problem with usb ports enabled that are not physically accessible without soldering? too many usb root nodes that might confuse people?
<tkaiser>
miasma: The average users considers USB plug&play and is never confused by root nodes since he not even knows what that might be
paulk-minnie has joined #linux-sunxi
gianMOD has quit [Remote host closed the connection]
<KotCzarny>
hmm, is there a way to use usb without dt?
<KotCzarny>
via direct module param etc?
f0xx has quit [Quit: terminated!]
<KotCzarny>
would solve 'too many dts for single changes'
f0xx has joined #linux-sunxi
gianMOD has joined #linux-sunxi
<wens>
KotCzarny: nope
<KotCzarny>
wens, even without rewriting usb host driver?
<KotCzarny>
s/without/with/
<apritzel>
If you need to tinker with the DT, this could be done in U-Boot
<apritzel>
Because the kernel does not necessarily need to see the exact DT which is in the source tree
<KotCzarny>
nah, i was thinking moving detection to linux driver
<apritzel>
you can't reliably detect this
<apritzel>
but you can take short cuts in U-Boot, since this is confined to a small number of boards
<tkaiser>
apritzel: Yeah, but it's about defaults. When OPi One was available we started with all 3 USB host ports enabled (only 1 host port available as type A receptacle). Then I disabled the two available through solder pads and immediately Armbian users complained.
<KotCzarny>
apritzel, it could be easier to autodetect board type/model from linux
<KotCzarny>
then you can apply list of known configs in single driver
<apritzel>
KotCzarny: why so?
<KotCzarny>
single driver vs multitude of dts
<apritzel>
Linux is a portable OS, it shouldn't be bothered with detecting every crappy board out there
<tkaiser>
And the same 'problem' applies to NanoPi NEO, Air and now OPi Zero. They all have USB ports available on GPIO headers
<apritzel>
that's a task of firmware
<KotCzarny>
sure, but we dont have any firmware
<wens>
how are you supposed to detect it anyway?
<apritzel>
KotCzarny: U-Boot fills the gap (for 32-bit boards at least)
<tkaiser>
The problem is not a technical but one of the perspective: the tinkerer out there buys the board since he wants to use USB on the pin headers and kernel devs don't want that.
<KotCzarny>
apritzel, but technically, would it be possible ?
<apritzel>
the point is: the policy whether to not expose non-mounted connectors in the DT is a Linux policy
<tkaiser>
KotCzarny: There's nothing to detect, it's just different understandings about enabling hardware or not. The users want to use hardware but can't without tweaking defaults.
<apritzel>
surely U-Boot can override this, even by user's command
<apritzel>
you could set some env variables for that, for instance
<miasma>
apritzel: and the point of rpi zero / nanopi neo / opi zero is to expose crucial stuff via non-mounted connectors :P
f0xx has quit [Ping timeout: 268 seconds]
<apritzel>
miasma: barking at the wrong tree, I am not a big fan of not exposing non-mounted connectors either
<apritzel>
KotCzarny: you can detect some parts (like SDIO devices)
<apritzel>
for others (like USB connectors) you could either let the user select
<apritzel>
or you could patch the DT anyway
<KotCzarny>
but main difference between same-soc boards are usb ports and regulator circuits
<KotCzarny>
gpio and maybe some additional ports
<apritzel>
question is whether the USB pins are multiplexed with other pins on some headers
<ssvb>
mripard: should every revision of each board have its own dts?
<tkaiser>
apritzel: On the aforementioned H3 boards that's not the case
<KotCzarny>
ssvb: if they differ ;)
camh has quit [Ping timeout: 260 seconds]
gianMOD has quit [Remote host closed the connection]
<apritzel>
ssvb: the kernel should see a matching DT for the board
<wens>
apritzel: for allwinner, _most_ usb host pins are dedicated
<apritzel>
ssvb: whether we need separate DT files in the kernel source is a different question
<apritzel>
wens: I was thinking so
<apritzel>
So I don't see many issues with enabling them then
<KotCzarny>
imo usb driver should detect board model
<apritzel>
KotCzarny: no
<apritzel>
the USB driver drives some IP and must not be bothered with something like a board
<ssvb>
KotCzarny: ask mripard, being paranoid, he probably does not rule out the possibility that they might be different ;-)
<KotCzarny>
then welcome to the dts hell
<KotCzarny>
;)
<KotCzarny>
and image f*cktitude hell
<KotCzarny>
ssvb's installer could solve this if the idea caught on
<apritzel>
KotCzarny: we can do some form of detection, but not in Linux
<apritzel>
just do it in U-Boot, problem solved
<apritzel>
U-Boot builds are quite board specific anyway, so you can try to differentiate between a small number of board variants
<KotCzarny>
apritzel, im thinking from 'minimize the images count' perspective
<apritzel>
then patch the DT accordingly, by turning status="disabled" into status="okay"
<apritzel>
KotCzarny: sure, one U-Boot to support multiple board, where the exact model can be detected at runtime
gianMOD has joined #linux-sunxi
mhlavink has joined #linux-sunxi
<apritzel>
and: we don't explicitly load DTs on the U-Boot command line, but use the one the U-Boot already uses itself
<KotCzarny>
anyone tried such detection?
<apritzel>
and which it possibly patches
<apritzel>
KotCzarny: take for instance the Pine64: 512 MB model -> 100 MBit PHY, >= 1G: 1GBit PHY
<KotCzarny>
because all i've seen is one image -- one board
reinforce has joined #linux-sunxi
<apritzel>
we have one image for both boards (because DRAM can be autodetected), the derive the rest from there
<apritzel>
KotCzarny: yes, because this has been done for years :-(
<tkaiser>
KotCzarny: In case of Armbian and the flood of H3 devices we simply had to give up an _auto_ detection since the devices are too similar.
<tkaiser>
But ssvb's idea is different
<KotCzarny>
tkaiser, is it working? ie. from user's perspective
<tkaiser>
KotCzarny: What?
<KotCzarny>
or its still split in different makers/boards at places
<ssvb>
apritzel: and now imagine one more different Pine64 revision with 1GB RAM
<KotCzarny>
(in other words, how many images are there for h3 based boards)
<apritzel>
ssvb: we don't need to support every theoretically possible board under the sun
<tkaiser>
KotCzarny: For each H3 device on with the exceptions of 'Mini 2' (same as 2) and 'Plus 2' (same as Plus)
<apritzel>
ssvb: there is one image which supports known boards
<ssvb>
apritzel: the point is that in this case the DRAM based autodetection will fail
<KotCzarny>
heh
<apritzel>
ssvb: it is not the solution for every problem, but better than what we have today (one image for each known board)
<tkaiser>
KotCzarny: But we could provide 2 images and let the user decice on firstrun (which some like and others don't)
<miasma>
hmm, I didn't find any regulator related diffs between e.g. opi pc/one dts files. so apparently it's handled elsewhere
<ssvb>
apritzel: yes, it's a nice hack, but it does not scale
<apritzel>
one image per board does not scale at all
<tkaiser>
KotCzarny: And 2 images only since there's a bug in legacy kernel Ethernet driver which would lead to a crash when Fast Ethernet is activated but it's GbE and vice versa.
<apritzel>
ssvb: as I said: it's not mean to scale for _every_ board, just for a subset
f0xx has joined #linux-sunxi
<tkaiser>
miasma: dvfs/cpufreq scaling didn't arrive mainline so currently there's nothing.
<ssvb>
one image per board is what we have now and users are somewhat familiar with
<ssvb>
the right solution is having the board identifier stored in a built-in non-volatile memory
<tkaiser>
apritzel: Based on experiences with H3 this doesn't work. I second ssvb totally here.
<ssvb>
and with SPI flash we are probably moving there
<apritzel>
ssvb: sure, that should solve this even better
<apritzel>
ssvb: but that isn't reality yet, unfortunately
<mripard>
tkaiser: in my mind, no, you shouldn't enable something that is not physically available on the board
<mripard>
so, in your OPi2 vs OPi2 mini example, we'd need two DT.
<tkaiser>
mripard: And what about USB on OPi Zero? Physically available on a 13 pin header? The header is populated.
camh has joined #linux-sunxi
<ssvb>
mripard: I'm interpreting your silence as having no arguments against having a separate dts file for every possible board revision
<ssvb>
mripard: when are you going to implement this?
<mripard>
ssvb: you should interpret my silence for what it really is: being offline.
<ssvb>
:)
avph has quit [Ping timeout: 260 seconds]
<mripard>
ssvb: and if they are different, then yes, we'll probably have to have something like that at some point if we don't have a way to autodetect it
lamer14786200075 has joined #linux-sunxi
lamer14786200075 has quit [Client Quit]
paulk-minnie has quit [Quit: Leaving]
Gerwin_J has joined #linux-sunxi
<mripard>
tkaiser: and the question should really be: is it usable by default?
avph has joined #linux-sunxi
tkaiser has quit [Ping timeout: 260 seconds]
tkaiser has joined #linux-sunxi
The_Loko has joined #linux-sunxi
<tkaiser>
mripard: Sure, people started immediately to solder USB peripherals to NanoPi NEO (unpopulated) header, used pogo pins with OPi Lite and One and now they'll use jumper wires to control eg. the USB TS interface of an LCD (that's one use case I heard of)
<beeble>
if you solder something onto your board you should be able to change your dts
<beeble>
thats my opinion
<beeble>
because the dts describes your board and you have changed it
<tkaiser>
There's no need to solder anything, it's a populated pin header with 2 x USB 2.0 on it, also CVBS, Mic and line out
<tkaiser>
These ports are physically exposed and people buy these devices exactly for *this* reason.
<apritzel>
tkaiser: so those USB pins are not multiplexed with GPIOs?
<beeble>
tkaiser: i was just referring your "to solder USB peripherals to NanoPi NEO (unpopulated) header, used pogo pins [...]"
<tkaiser>
apritzel: Nope, on none of these H3 devices.
<apritzel>
tkaiser: then they qualify for a standard DT, I think
<ssvb>
since the USB pins can't be used for any other function (unless I'm mistaken), do we lose anything by just enabling them as USB?
<tkaiser>
beeble: But have you ever looked at the NanoPi NEO. This board is made for hardware tinkerers that do not even not how to enter single user mode in Linux.
<tkaiser>
They use smelly OS images from hardware vendors relying on crappy Android kernels and enjoy dealing with hardware. As soon as they switch to mainline kernel fun is over and a lot of stuff works any more for no apparent reason.
<ssvb>
are people worried about power consumption? or have some other concern?
<tkaiser>
That's the problem people experience with this 'RPi header' be it 40 or 26 pins
<beeble>
tkaiser: i'm ok with having the exposed pins in the default dts, especially if it's a single purpose function
<tkaiser>
ssvb: I measured consumption on H3 boards, regarding USB it's all or nothing. Only if you disable all USB ports you get some savings
<beeble>
but if you have i2c on your header for example you will change your dts for sure. as long as you don't just use it via sysfs usermode
<beeble>
same for spi
<tkaiser>
beeble: Sure, but those consumer oriented SBC that feature the RPi compatible header... there people expect these interfaces at the usual pins
<beeble>
mainline kernel even gives you a nice oops if you have spidev in the dts
<tkaiser>
beeble: Exactly
<wens>
apritzel: fyi i've no problem enabling dedicated perihperals available on pin headers
<apritzel>
wens: I think nobody has, the rationale was to avoid this if for instance GPIOs are multiplexed on those pins as well
deskwizard has quit [Remote host closed the connection]
deskwizard has joined #linux-sunxi
paulk-collins has joined #linux-sunxi
<wens>
apritzel: for those my view is if the vendor explicitly states that X pin is for Y function, then we enable it by default
<apritzel>
wens: I agree
<apritzel>
(it's a dedicated connector, just not a standard one)
<beeble>
tkaiser: having sane defaults for the header should be a goal imho
<wens>
apritzel: i was thinking the rpi-compatible headers
<apritzel>
wens: oh
* wens
&
<apritzel>
wens: well, I agree to a certain point as well, but I can see mripard's point as well (people could be using them as GPIOs)
<apritzel>
I had this discussion with him about UART pins, for instance
<miasma>
i don't think the xunlong's manuals for h3 boards show all the multiplexed functions for pins
<miasma>
maybe the schematics show, but i couldn't decipher them fully
<apritzel>
miasma: but the SoC's datasheet does
<NiteHawk>
the .dts arguments are especially relevant for boards that can take peripheral "shields" as add-ons, which might fulfil different functions and require a variety of (GPIO) pin assignments. in those cases, using dedicated .dts (or at least overlays) makes sense
<tkaiser>
But based on some experiences with Armbian users they expect at least the pin assignments on the RPi header are the same as they were back then when they used the vendor OS image relying on kernel 3.4 (and that's following RPi HAT defaults)
f0xx has quit [Ping timeout: 260 seconds]
<mripard>
tkaiser: my main worry with always enabling USB no matter what is that we'll never be able to do proper power management on most boards
<mripard>
because once it's in, there's no way to remove it
netlynx has joined #linux-sunxi
<tkaiser>
mripard: Ok, my previous testings were all done with BSP kernel (where it's 'all or nothing') so with mainline kernel if the nodes are defined then consumption increases?
<apritzel>
mripard: what do you mean with "it's in" and "remove it"? From the actual board DT?
paulk-collins has quit [Remote host closed the connection]
gianMOD has quit [Remote host closed the connection]
<ssvb>
mripard: lol, nice timing ^
<Wizzup>
ssvb: I think they have an internal revision replacing the phy
<ssvb>
if the PHY revision can be detected at runtime, do we still need a separate dts file for the whole board?
<Wizzup>
Rev I, I think, but maybe I am just being silly
paulk-collins has joined #linux-sunxi
<mripard>
apritzel: yes, if we enable the USB by default for those who might solder something on those headers to use USB, we have regulators enabled for nothing (for the rest of the users)
<mripard>
and if one day the time comes where we want to do proper power management, we can't disable them either because it used to be there
<ssvb>
x86 solves this particular problem by having a configuration option in the BIOS setup...
<MoeIcenowy>
ok we need a bios now :-)
<mripard>
or to apply an overlay with u-boot, which we can do now
<MoeIcenowy>
in fact the BIOS I mean is also a specially designed U-Boot bootmenu
<MoeIcenowy>
for example we can use uEnv to store the situations
<MoeIcenowy>
will a uEnv on SPI NOR Flash finally break the Flash block?
alexvf has joined #linux-sunxi
gianMOD has joined #linux-sunxi
<oliv3r>
ssvb: yeah the rev g. comes with an rtl8211E (i think). la performance is grray. 960 m it on iperf
<oliv3r>
(cold cold fingers here )
<oliv3r>
but with my patch we do not eed a sep. dtb as thry both speak rgmii with the same driver
<oliv3r>
i think it is a 'xilent upgrade' as users wont notice it
camh has quit [Ping timeout: 248 seconds]
gianMOD has quit [Remote host closed the connection]
<ssvb>
mripard: it's mostly the same thing, the point is that the firmware (u-boot and friends) updates the hardware description (the device tree)
<ssvb>
the rest is all about just making it user friendly
<Ixnus>
Please excuse me, but is the argument: the "crap" Allwinner BSP does it so copy it in the mainline ?
<ssvb>
MoeIcenowy: uEnv or maybe some UEFI variables
<MoeIcenowy>
yes
<Ixnus>
And the other argument is: there are 2 users of one distribution that are skillfull enough to read technical documentation and soldier but are annoyed to change one line of code ?
<Ixnus>
solder*
yann-kaelig has joined #linux-sunxi
<ssvb>
Ixnus: yeah, the BSP is "crap", so let's do exactly the opposite :)
<MoeIcenowy>
I think I can make a "Sunxi BIOS" PoC in several minutes, which can control one feature :-)
<MoeIcenowy>
and maybe the idea of "Sunxi BIOS" can solve the LCD panel problem of A33 Q8
<ssvb>
and when we get the Orange Pi PC 2 board, we can implement something
<MoeIcenowy>
even users without a SPI Flash can also benefit from such a BIOS
<MoeIcenowy>
my opipc2 should reach tomorrow
<ssvb>
well, you will have to deal with distro maintainers and convince them that using your "BIOS" is a good idea
<ssvb>
most likely they will just stick with the baseline U-Boot and not bother with anything else
<mripard>
and then convince your users that all the documentation written for all the other Allwinner boards doesn't apply here
<ssvb>
what do you mean?
<MoeIcenowy>
or maybe we can make it a plugin of baseline U-Boot
<MoeIcenowy>
for example, an enhanced boot.scr
<ssvb>
still with the SPI flash, we are decoupling the firmware from the distro and preferably shipping the firmware pre-installed on the board
<mripard>
ssvb: that having anything that deviates from the other boards will be a pain, because all the documentation written everywhere will not apply anymore
<MoeIcenowy>
ssvb: yes
<ssvb>
mripard: first - it does not have to deviate much, second - who said that it is not going to be documented?
<MoeIcenowy>
but there may also be users without SPI Flash want to install it
<MoeIcenowy>
for example, I use many boot.scr fdt command hacks recently to use sun8i-a33-q8-tablet.dtb to driver all my devices' capabilities possible
<mripard>
ssvb: I didn't say it wouldn't be. I said all the previous documentation, howto, tutorials, etc. would not apply anymore
Ixnus has quit [Quit: Page closed]
<MoeIcenowy>
we have kill so many documentations, and won't be worse to kill one more :-)
<ssvb>
mripard: the sunxi related U-Boot documentation is nonexistent anyway, Hans never bothered to write it :-)
<ssvb>
only apritzel has written some nice Pine64 installation readme for U-Boot
matthias_bgg has quit [Quit: Leaving]
<mripard>
ssvb: I was also talking about what is on the wiki, on the blog post out there
chomwitt has quit [Ping timeout: 250 seconds]
<mripard>
basically everything that shows up when you google "allwinner + <something>"
bugzc has joined #linux-sunxi
apritzel has quit [Ping timeout: 248 seconds]
gianMOD has joined #linux-sunxi
gianMOD has quit [Remote host closed the connection]
OtakuNekoP has quit [Quit: Page closed]
gianMOD has joined #linux-sunxi
gianMOD has quit [Remote host closed the connection]
leviathanch has joined #linux-sunxi
dpg_ has joined #linux-sunxi
<tkaiser>
IgorPec: In case you want to do today something related to OPi Zero: Just tried to fix Wi-Fi and led assignment in fex file. Would be nice if you could give it a try.
f0xx has joined #linux-sunxi
<tkaiser>
IgorPec: But either schematics are wrong regarding red led or vendor fex ;)
<IgorPec>
tkaiser: i am not sure i'll do this today, perhaps in the morning.
apritzel has joined #linux-sunxi
<IgorPec>
most likely something is mixed up
<IgorPec>
the driver code had also some syntax errors ... amazing
<IgorPec>
tkaiser: aha, i can try those fex changes
<tkaiser>
IgorPec: As you like. Might also be an idea to try out Xunlong's Lubuntu image before to see whether Wi-Fi works there. And then it would be great if you've an eye on the red led. They define it as PA17 but according to schematics it's PA15 as on every other H3 device out there except of Beelink X2
<IgorPec>
you might downloaded this Lubuntu? Google drive link is n/a .. Baidu rocks :)
<tkaiser>
IgorPec: Yeah I used also Baidu -- 4 MB/s :)
<jernej>
Please try to set up PA20 in u-boot and then load the kernel
<tkaiser>
IgorPec: And in case you've another 5 minutes I would be interested in output from armbianmonitor -m (pastebin) while 'sysbench --test=cpu --cpu-max-prime=20000 run --num-threads=4' is running.
<IgorPec>
how long do i wait?
<tkaiser>
IgorPec: this takes 5 minutes max and I'm interested in temperatures at the end of the sysbench run
<tkaiser>
IgorPec: Finished already? How long did sysbench run?
<IgorPec>
total time: 130.6576s
<tkaiser>
IgorPec: Thanks!
<IgorPec>
no problem. you are getting it tomorrow :) heeh
<jernej>
IgorPec: Can you try enabling PA20 in U-Boot and then booting normaly?
<IgorPec>
moment
netlynx has quit [Quit: Ex-Chat]
florianH has quit [Quit: Connection closed for inactivity]
<tkaiser>
IgorPec: You run Xenial, true?
<IgorPec>
yes
<tkaiser>
IgorPec: Ok, that explains the sysbench numbers. The binary in Xenial shows ~30% better scores compared to the one included in Jessie for example
<miasma>
tkaiser: thanks for the help. i made a more generic template for all h3 boards in the wiki. should be a lot easier to keep track of stuff now
<tkaiser>
miasma: Thank you! And what about all the H2 devices? ;)
<tkaiser>
At least we now know for sure that H2[+] is just a crippled H3 :)
<miasma>
maybe another template for those
<tkaiser>
miasma: Why not simply merging H3/H2+, it's really almost identical. And board vendors that now provide boards that only implement Fast Ethernet and are headless might switch to H2+ without notice anyway
<tkaiser>
BTW: In case anyone wants to have a look. That is Xunlong's vendor fex for OPi Zero extracted from their Lubuntu 14.04 image released today: http://pastebin.com/480BYtj3
vagrantc has joined #linux-sunxi
<tkaiser>
Some settings (eg. dvfs) make no sense, some other (eg. cooler_table, ths stuff) not that much
Gerwin_J has quit [Quit: Gerwin_J]
<miasma>
so are they planning to sell different variants with and without nor flash?
<tkaiser>
miasma: Who are 'they'?
<miasma>
xunlong
<tkaiser>
miasma: Well, Steven doesn't answer questions directly, he always just implements stuff ;)
<miasma>
ok
<tkaiser>
On PC 2 SPI is present, on OPi Zero optional. Maybe when we make some noise it get's soldered there too.
<tkaiser>
ssvb already said that this is currently just a chicken-egg problem.
<miasma>
although i'm not sure if i do anything with a board with 1 MB of flash :P it's nice to have, but I can fit my whole distro in say 128 MB :)
<miasma>
would be nice to have a compact system with everything builtin
<tkaiser>
miasma: This has been discussed today (again). It should already be sufficient if there's a device specific boot loader that can then start any device agnostic OS image from whereever
<ssvb>
miasma: the expensive high end boards are supposed to have eMMC, and we can probably use its boot partition for the firmware
<miasma>
sure
<ssvb>
the extreme low cost boards, such as the Orange Pi Zero, probably can't justify any price increase
<tkaiser>
To be honest, I really don't understand how that works: Selling an SBC for $7
<ssvb>
maybe it's also a loss leader for Xunlong?
<miasma>
aren't the chips quite cheap? i think you can buy ddr3 and h3 for few bucks (including shipping)
<miasma>
pin headers and other stuff is just few cents
<miasma>
all sbc stuff sold in western countries also have the VAT included
<beeble>
razor thin margins. it's only profitable because the sell quite a lot. and of course because they don't do any work around it
<beeble>
thats why you see only the allwinner sdk for it with no further support
<tkaiser>
beeble: To my surprise they started to do something around. There are at least two guys busy with kernel and OS image stuff. But results so far look scary.
<miasma>
sinovoip also had a repository, but it seemed pretty useless. they didn't bother updating their stuff
<beeble>
back to debugging why it matters what side of the usb cable i plug in first
Nacho has joined #linux-sunxi
<miasma>
why would it matter?
<beeble>
it shouldn't but it does :)
gianMOD has joined #linux-sunxi
<miasma>
one end is micro-usb and other is the larger one?
<beeble>
yes. i have already two working fixes. but i would like to find out the exact cause. unfortunately with standard probes the problem doesn't occur anymore. will need to get some active probes with high impedance for that
<nikre>
any big updates for opi pc in last 2 weeks?
<miasma>
the audio might work now with patches
VargaD has quit [Read error: Connection reset by peer]
jstein has quit [Remote host closed the connection]
dh1tw has joined #linux-sunxi
bonbons has quit [Quit: Leaving]
IgorPec has joined #linux-sunxi
whaf has quit [Remote host closed the connection]
paulk-collins has quit [Remote host closed the connection]
tkaiser has joined #linux-sunxi
nikre has quit [Remote host closed the connection]
tkaiser has quit [Ping timeout: 260 seconds]
<jernej>
for anyone who is interested: I have almost working U-Boot H3 HDMI driver here: https://github.com/jernejsk/u-boot It is good enough to be used instead serial cable, but needs some work in DE2.0 area (wrong colors).
IgorPec has quit [Ping timeout: 240 seconds]
<jernej>
needs a lot of clean up too...
<miasma>
is the boot rom inside the allwinner SoC open?
p_rossak has joined #linux-sunxi
<miasma>
some people worry that it might contain trojans
yann-kaelig has quit [Quit: Leaving]
gianMOD has quit [Remote host closed the connection]
The_Loko has quit [Quit: Leaving]
tkaiser has joined #linux-sunxi
tkaiser has quit [Ping timeout: 256 seconds]
gianMOD has joined #linux-sunxi
dpg_ has joined #linux-sunxi
tkaiser has joined #linux-sunxi
gianMOD has quit [Remote host closed the connection]