Turl 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
mosterta|2 has quit [Ping timeout: 244 seconds]
mosterta|2 has joined #linux-sunxi
TheSeven has quit [Ping timeout: 250 seconds]
TheSeven has joined #linux-sunxi
Wizzup has quit [Ping timeout: 240 seconds]
cosm has quit [Ping timeout: 244 seconds]
tipo has quit [Ping timeout: 244 seconds]
cosm has joined #linux-sunxi
tipo has joined #linux-sunxi
<lennyraposo> nope
<lennyraposo> lvrp16
<lennyraposo> I will post results of my tests with audio files as soon as I am done testing
Wizzup has joined #linux-sunxi
ninolein has quit [Ping timeout: 268 seconds]
ninolein has joined #linux-sunxi
tgaz has quit [Ping timeout: 260 seconds]
tgaz has joined #linux-sunxi
cosm has quit [Ping timeout: 252 seconds]
servili007 has quit [Quit: Leaving]
tgaz has quit [Ping timeout: 240 seconds]
cosm has joined #linux-sunxi
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
cosm has quit [Ping timeout: 244 seconds]
cosm has joined #linux-sunxi
mosterta has joined #linux-sunxi
mosterta|2 has quit [Ping timeout: 240 seconds]
<lennyraposo> lvrp16
<lennyraposo> do you have a pine?
<lennyraposo> streaming audio from accuradio in iceweasel
<lennyraposo> no hiccups
<lennyraposo> 3% cpu usage
<lennyraposo> the only thing that take sup processing power is the gui rendering elements
<lennyraposo> in other words gpu needs work ;)
orly_owl has quit [Ping timeout: 268 seconds]
<bwarff> do some folks actually have a pine
<wens> i ordered cases to go along with, seems they will be delayed
<lennyraposo> I do
<lennyraposo> must be the ABS cases
<lennyraposo> the acryllics are ready ;)
<bwarff> i just order a board and get regular updates on why its no coming :)
<bwarff> nice to see some people did get them.
<wens> lennyraposo: don't remember which
<wens> don't even remember they had 2 kinds
<lennyraposo> the clear one is the good one
<lennyraposo> the other one they are having manufacturing issues
<lennyraposo> hdmi port is the issue
<lennyraposo> if all goes well audio is no longer an issue with pine
<lennyraposo> there was stuttering audio playback with pine in linux
<wens> hmm, mine are acrylic
tgaz has joined #linux-sunxi
<wens> but it hasn't shipped yet
<lennyraposo> I got a tester board
<lennyraposo> I ordered 6 more plus the pledge
<lennyraposo> 2 x 2gb 5 x 1gb
<lennyraposo> this test unit has been performing well
orly_owl has joined #linux-sunxi
cosm has quit [Ping timeout: 240 seconds]
p1u3sch1 has quit [Ping timeout: 276 seconds]
p1u3sch1_ has joined #linux-sunxi
IgorPec has joined #linux-sunxi
Shirasaka-Hazumi has quit [Ping timeout: 260 seconds]
IgorPec has quit [Ping timeout: 240 seconds]
mosterta has quit [Ping timeout: 248 seconds]
Shirasaka-Hazumi has joined #linux-sunxi
p1u3sch1_ has quit [Ping timeout: 240 seconds]
p1u3sch1 has joined #linux-sunxi
zuikis has joined #linux-sunxi
<ssvb> longsleep: not everything is great in the AArch64 world - https://github.com/ssvb/xf86-video-fbturbo/commit/8e6d248b92189271b6978c3c2c9d6094b72b9dbc
<ssvb> longsleep: I'll try a few more tricks to make scrolling performance more competitive with the shadow framebuffer layer
<ssvb> longsleep: if we had G2D, then scrolling would become a non-issue for A64, but I want to be sure that the generic device independent code path in xf86-video-fbturbo is also fast :-)
<lennyraposo> kewl ssvb
<lennyraposo> btw
<lennyraposo> you have a pine?
<ssvb> lennyraposo: yes
<lennyraposo> DE installed?
<lennyraposo> pulseaudio etc?
<lennyraposo> gonna assume yes
<lennyraposo> got audio working without stutters
<lennyraposo> but I cannot pu tmy finger on what is happening
<lennyraposo> it's definitely a pulseaudio thing
<ssvb> I'm not into pulseaudio and don't have it installed
<lennyraposo> no worries then
<lennyraposo> has audio been working without stutters for you?
IgorPec has joined #linux-sunxi
<lennyraposo> basically withou issue?
<ssvb> haven't tried sound on my pine64 yet
<lennyraposo> when you do let me know if oyu get any sound issues
mossroy has joined #linux-sunxi
IgorPec has quit [Ping timeout: 250 seconds]
merbzt has quit [Ping timeout: 244 seconds]
<lennyraposo> well
<lennyraposo> mp3 wav and ogg files are playing without issues now
foudubassan has joined #linux-sunxi
<plaes> mainline?
merbzt has joined #linux-sunxi
cptG has joined #linux-sunxi
cptG_ has quit [Ping timeout: 248 seconds]
cnxsoft1 has joined #linux-sunxi
zuikis has left #linux-sunxi [#linux-sunxi]
cnxsoft has quit [Ping timeout: 250 seconds]
cnxsoft1 is now known as cnxsoft
<ssvb> plaes: audio on pine64? probably not
<lennyraposo> nope
<lennyraposo> not mainline plaes
<lennyraposo> bsp
<plaes> ok
<plaes> high hopes :)
tkaiser has joined #linux-sunxi
<tkaiser> lvrp16: If you want to do io benchmarks then it's not about SBCs but the used storage and driver situation. So results can't be used the usual moronic Phoronix style.
<tkaiser> lvrp16: And the tools normally used to measure things are wrong anyway: http://forum.armbian.com/index.php/topic/838-best-budget-device-as-torrent-box/page-2#entry7004
<lvrp16> tkaiser: still awake? damn
<tkaiser> lvrp16: You could choose a really cheap crap SD card, 16/32/64 GB 'middle class' (Samsung EVO) and eMMC 5.0 as used on ODROID-C2.
<lvrp16> i'm in san diego, landed in orange county and had to drive down :(
<tkaiser> I'm drinking my coffee ;)
<lvrp16> tkaiser: i would only use samsung pro+
<lvrp16> tkaiser: i have a dozen or so 64GB around
reinforce has joined #linux-sunxi
<tkaiser> lvrp16: Anyway. These sorts of benchmarks are crap. Since they again produce only numbers without meaning. It would be important for people to learn the influence of their SD card on overall user experience (that's random I/O with small record sizes!)
<tkaiser> Testing sequential transfer speeds is pretty useless for this purpose. Benchmarks could be used to raise awareness for these issues. But they're misused to produce numbers/graphs without meaning.
<tkaiser> Again and again...
* plaes agrees with tkaiser
<lvrp16> well, sequential tests determine the bandwidth from the SoC to the SD card
<lvrp16> you can do a seek test as well to determine the state of the IO driver
<tkaiser> A cheap SD card and a Samsung Pro+ or SanDisk Extreme Plus might differ 100 times or even more regarding random I/O while their sequantial transfer speeds are identical.
<lvrp16> assuming that the SD card is not the bottleneck
<tkaiser> lvrp16: Yes, benchmarks could be used to show where the bottlenecks are: Sequential speeds: Interface from board to card, random I/O: Only card.
<lvrp16> tkaiser: i only care about the board to card...
<tkaiser> Who does this? No one? Larabel even produces numbers where he only tests random I/O of different SD cards and says later 'that's the board in question'. Unbelievable
<tkaiser> lvrp16: These numbers are already known. And pretty irrelevant when it's about real world usage scenarios
<tkaiser> It's simply wrong to use these numbers since a fast card showing high IOPS will speed 'normal use' up
<lvrp16> well not really, some the hubs are tied to ethernet, some are not
<lvrp16> i would cover all of the cases by maxing out all the buses
<tkaiser> lvrp16: It's well known that you should avoid any RPi when it's about I/O or networking
<tkaiser> That's not a benchmark case that's a 'don't use RPi if you want to...' case
<lvrp16> i don't even care about raspberries at this point...rpi is just slow
<tkaiser> There's nothing to test. Simply switching on the brain is enough. But since all these crap benchmarks comparing useless integer and FP algorithms people will never get that
IgorPec has joined #linux-sunxi
<lvrp16> they are good for their expandability at this point
<lvrp16> i plan to bundle GPU, GPIO, IO bandwidth
<lvrp16> into one article
<lvrp16> bought some 200mhz scopes and all
<plaes> um.. for what?
<lvrp16> GPIO testing
<lvrp16> see how fast their GPIO pins can be driven
<tkaiser> lvrp16: Good luck. I would do it differently but as long as people blindly believe in crap benchmarks the Phoronix style it's useless to try to educate them about these differences. Since people hate thinking and like looking at simple graphs telling nothing relevant
mossroy has quit [Remote host closed the connection]
<lvrp16> tkaiser, it's not about those people. they're already lost
<lvrp16> but some people might genuinely want to know certain performance characteristics without having to buy each board and test themselves
<lvrp16> it's an aid, not the ends
IgorPec has quit [Ping timeout: 248 seconds]
<tkaiser> lvrp16: But still there's nothing to test but a lot to explain. Orange Pi PC with mainline kernel, a fast SSD and an UASP capable enclosure performs way better (IOPS) as when having to rely on 3.4.x kernel
<tkaiser> Just one example. Same things might happen when you measure 'GPIO speed'
<lvrp16> yeah but the benchmarks are not simply a reflection of hardware capability. they are also a reflection of software capability. if i go and try to do something, i will be limited by both
<tkaiser> Benchmarks could be used to provide _explanations_ but instead they're misused to produce numbers, rankings and a lot of other stuff that prevents people from starting to think about the 'performance issue'
<lvrp16> yes the software capability changes, but that does not make the information about the current state irrelevant
<lvrp16> tkaiser, you're being too logical
<tkaiser> lvrp16: True, but then you have to explain that you now tested hardware+software and things might change next week since device xy will then be supported by mainline kernel
<tkaiser> And so on...
<lvrp16> and then next week, you release a new set of numbers ;)
<bwarff> it only affects the im building my own smart-tv crowd :P
<lvrp16> have a little faith
<tkaiser> lvrp16: My 'problem' with benchmarks is when the results are misleading. Especially when end-users are concerned since they lack understanding. When I produce a benchmark run where all contestants perform nearly identical (25% variation) then I don't publish numbers but say 'integer performance is close enough, no numbers needed, let's focus on the things that matter' (like random I/O for example)
<tkaiser> To produce useful numbers with today's SBC you would have to re-run each set of tests three times with each board: 1st with no heatsink, then with a 'standard' heatsink and then with heatsink and fan. Just to show what people can expect when they refrain from using an annoying fan (with A83T for example: 50%-60% of top performance compared to heatsink+fan)
<tkaiser> And then you would have to explain that these numbers are also meaningless unless you run all the time demanding multithreaded stuff on the board. Normal workloads need most of the times only singlethreaded top performance. And so on.
<bwarff> the kernel it comes with and the sandisk the local office supplies sells is the metric of champions
<tkaiser> You could use benchmarks to educate people what really matters. Why a ODROID-C1+ feels faster than a Pine64 even if the usual PTS crap tells a different story.
<bwarff> cause odroid has nice emmc and people havent learnt that yet
<tkaiser> bwarff: Yes, that's one reason. eMMC does really matter for many use cases. And then it's about GUI acceleration.
<tkaiser> The eMMC issue can't be 'fixed' with Pine64 (only with a new hardware rev since they use the eMMC pins already for something else), the GUI acceleration might improve over time
<bwarff> people compare prices without comparing things like emmc, its all down to a price bullshit and people get what they deserve.
reev has joined #linux-sunxi
yann|work has quit [Ping timeout: 240 seconds]
IgorPec has joined #linux-sunxi
massi has joined #linux-sunxi
IgorPec has quit [Ping timeout: 248 seconds]
<tkaiser> bwarff: It's even worse since people are confused by benchmark numbers and 'common knowledge' they start to slow storage down on boards with onboard eMMC. Banana Pi M3 has onboard eMMC (not that fast and they use different modules on the first and subsequent production batches).
<tkaiser> And a horribly slow USB-to-SATA bridge. Since most people believe this is 'true SATA' they try to move the rootfs to a connected disk that will be accessed multiple times slower compared to internal eMMC.
<bwarff> yes, not knowing the real io path on the unit and which have dedicated channels and which just ram everything through usb2
<tkaiser> bwarff: It's not just USB2.0, the GL830 used there (and on Cubietruck 5/Plus and Orange Pi Plus) is horribly slow. By avoiding the 'SATA port' on these boards and using any cheap external USB disk enclosure performance improves a lot. And with mainline kernel and an UASP capable USB-to-SATA bridge performance will be more than 2 times better compared to the 'onboard SATA'. That's something worth to mention but no benchmark
<tkaiser> so far tests stuff like this.
ricardocrudo has quit [Ping timeout: 246 seconds]
mane has joined #linux-sunxi
gzamboni has quit [Ping timeout: 268 seconds]
gzamboni has joined #linux-sunxi
whitesn has quit [Ping timeout: 250 seconds]
Shirasaka-Hazumi has quit [Quit: ZNC 1.6.2+deb2+b1 - http://znc.in]
tsuggs has quit [Ping timeout: 250 seconds]
Shirasaka-Hazumi has joined #linux-sunxi
camh has quit [Ping timeout: 268 seconds]
<agraf> ssvb: there's a good chance you could just use caches for the frame buffer
<agraf> ssvb: btw, have you managed to get hdmi working with an upstream u-boot yet?
<agraf> ssvb: the downstream bsp de linux code seems to fail to initialize something
<ssvb> agraf: the enabled cache would break so many assumptions in various pieces of code
jbrown has quit [Ping timeout: 268 seconds]
<agraf> ssvb: when booted with preinitialized hdmi (downstream u-boot) everything works, when booting without initialized hdmi (upstream u-boot), i can make it show a single solid color on the screen
<agraf> ssvb: well, you can always use a shadow fb and copy into a cached real frame buffer
<agraf> ssvb: then all your assumptions rely on the shadow fb which stays the same as before
tsuggs has joined #linux-sunxi
<ssvb> but yes, I have also evaluated the cached solution in the past, some ARM processors even supported write-through cache which is perfect for this task
<agraf> all modern arm cpus support write-through, no?
jbrown has joined #linux-sunxi
whitesn has joined #linux-sunxi
whitesn has quit [Changing host]
whitesn has joined #linux-sunxi
<ssvb> modern arm processors tend to treat write-through attribute as uncached with write combining
<maz> agraf: as usual, write through is just a hint. it may or may not be implemented.
<agraf> ah, ok
yann|work has joined #linux-sunxi
<agraf> either way, with shadow fb you don't ever have to read back, no?
<agraf> unless you want to screen capture 3d, hm
<ssvb> the whole point is to get rid of shadow fb, because it is slow
mane_ has joined #linux-sunxi
<agraf> oh? ok
<agraf> also, i guess you're running with the bsp kernel (because you do have graphics at all)
<agraf> in that case, you also have access to mali
<ssvb> I'm more interested in high performance software rendering
<agraf> how come?
<ssvb> because that's what provides the best performance at the moment?
mane has quit [Ping timeout: 268 seconds]
<ssvb> glamor has been under development since a long time ago, it is slow, buggy and requires working GL drivers
<ssvb> maybe some day it will work fine with freedreno or vc4
<Seppoz> where would i check out the most recent version of the sunxi kernel?
<agraf> i see, i figured it would be the best thing to target for things like the pine
<agraf> but then again, i can see why mali makes it hard
<agraf> either way, i first need to get any display output at all
<ssvb> there is work in progress drm/kms driver for h3
<agraf> it looked like licensing fears stopped that one, no?
<ssvb> I haven't tracked its progress lately
<agraf> i just stumbled over the email thread a few days ago
<Seppoz> which is the best branch to use for A20? sunxi3-4?
<ssvb> agraf: jemk has more details, but we probably don't need the Allwinner's code with unclear licensing terms for HDMI on A64
<agraf> ssvb: yeah, that would be best
<agraf> ssvb: I'm happy to leave graphics enablement to others too :)
<ssvb> the HDMI PHY story is not quite clear for me though
IgorPec has joined #linux-sunxi
<agraf> ssvb: no idea, there's also a binary blob in the bsp, but the u-boot code contains sources that seem to match the blob pretty closely
<tkaiser> Seppoz: Either use https://github.com/igorpecovnik/lib/blob/master/configuration.sh#L409-L410 or mainline (kernel.org) for A20
matthias_bgg has joined #linux-sunxi
<Seppoz> i was just hoping for a newer version as i am having massive issues with WIFI drivers in this release
<Seppoz> and i dont want to switch to mainline
<ssvb> Seppoz: "this release"?
<Seppoz> sorry this branch
<agraf> ssvb: also looks like i was wrong about the licensing problems
<Seppoz> sunxi-3.4
premoboss has joined #linux-sunxi
<Seppoz> for some reason using the most commong rtl wifi drivers causes a crash
<tkaiser> Seppoz: I should add that we use in Armbian a 'few' more patches then: https://github.com/igorpecovnik/lib/tree/master/patch/kernel/sun7i-default (and have no such reports)
<tkaiser> Seppoz: But using cheap RealTek dongles is almost always asking for trouble anyway...
mane_ has quit []
<Seppoz> problem is its with 80% of all wifi devices
<Seppoz> its very hard to get one that actually works
<Seppoz> so far i found 1
<Seppoz> anyone experienced this before?
camh has joined #linux-sunxi
<bwarff> my experience with wifi on arm sbc's has been woeful
<tkaiser> Seppoz: I tried RTL8192CU used on Lamobo R1. Led to the simply decision to not waste time with these sorts of cheap chips again in my live.
tkaiser has quit [Quit: jIRCii - http://www.oldschoolirc.com]
<Seppoz> RTL8192CU is the only one i got working here so far
<Seppoz> but none of the more modern
<bwarff> RTL8188CUS is the one im currently having most success in (not for bandwidth) as much as reliable up/down
ricardocrudo has joined #linux-sunxi
tkaiser has joined #linux-sunxi
<tkaiser> Seppoz: Have you tried mt7601 instead? In Armbian we include the driver from here https://github.com/porjo/mt7601/ and it's reported to work ok.
tkaiser has quit [Client Quit]
<Seppoz> tkaiser: actually the RTL8188CU is te one crashing
<Seppoz> here is the crash log
<Seppoz> ~$ uname -r
<Seppoz> 3.4.103
enrico_ has joined #linux-sunxi
<Seppoz> anyone has any idea why?
<plaes> for mainline there's new rtl8xxxu driver for realteks
<Seppoz> not using mainline
<ssvb> agraf: doing framebuffer readback from two threads improves the performance only by a factor of ~1.5x, but still ~30 FPS are better than ~20 FPS
<ssvb> I guess, adding even more threads does not make much sense
<agraf> ssvb: so which frame buffer are you reading back from?
<agraf> ssvb: the one that layer0 points to?
<agraf> ssvb: because that one just resides in ram, no?
<agraf> ssvb: I still haven't managed to fully get my head around how the display engine works
<ssvb> just mmap of /dev/fb0, whatever it is
<agraf> ssvb: yeah, /dev/fb0 is just an in-ram frame buffer that gets mapped to layer0
<ssvb> yes, most ARM devices have their framebuffers stored in system memory
paulk-collins has joined #linux-sunxi
<agraf> ssvb: which then gets associated with some mgr code and mapped onto some overlay and scaled into the actual output picture iiuc
<agraf> ssvb: so it's at the beginning of your chain, 3d for example won't ever get written back to that fb
<agraf> ssvb: because that comes in another layer later on
<ssvb> the display controller scans out the framebuffer via DMA
<agraf> ssvb: i guess you'd also implement xv through layers if you wanted to do it correctly
<agraf> ssvb: right
mane has joined #linux-sunxi
<ssvb> oh, in fact the display controller can scan out multiple layers and is compositing them on the fly
<agraf> exactly
<agraf> up to 4 i think
<agraf> with different zorders and overlapping
<agraf> not sure if it can do alpha blending
<agraf> it might
<agraf> ssvb: but that means that mapping it as cached is probably not a bad idea at all
<agraf> ssvb: you get 64byte reads rather than your average 8-byte memcpy ones
<agraf> ssvb: and you get readahead
<agraf> ssvb: it should be a massive speed boost, just invalidate the dcache for the fb region before you read
<ssvb> cached framebuffers mean coherency issues, there must be cache flushes explicitly added
<ssvb> and such cache flushes need damage tracking, similar to shadow framebuffer
<agraf> could you map it twice?
<agraf> preferably WC for writes and cached for reads
<ssvb> ARM can't make up their mind about mapping the same memory with different caching attributes
<ssvb> they had some description in the ARMv7 architecture manual about the implications, so in theory this can be done
hansg has joined #linux-sunxi
<ssvb> however mapping the same memory with different attributes is forbidden in the linux kernel
<ssvb> maybe maz can say something about it
tipo has quit [Remote host closed the connection]
<ssvb> nobody wants to deal with this stuff, because it is potentially dangerous
tipo has joined #linux-sunxi
orly_owl has quit [Ping timeout: 244 seconds]
<ssvb> agraf: anyway, the uncached framebuffer readback using the CPU is a generic solution, which does not need anything special in the kernel and works everywhere
<agraf> ssvb: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0024a/CHDBDIDF.html
<agraf> ssvb: is it mapped G?
<ssvb> can be also multithreaded to boost the speed a little bit
orly_owl has joined #linux-sunxi
<agraf> ssvb: IIRC all device memory is mapped nGnRnE by default
<ssvb> but a much better solution for fast scrolling is some sort of DMA acceleration
<agraf> ssvb: there was something in the sunxi de driver
<maz> ssvb: more than just "potentially", unfortunately.
<ssvb> agraf: on the Raspberry Pi, there is a custom ioctl for this - https://github.com/ssvb/xf86-video-fbturbo/blob/master/src/fb_copyarea.c
<ssvb> agraf: maybe longsleep can implement something like this in the BSP kernel :-)
<ssvb> maz: various errata and implementation dependent differences?
<maz> ssvb: not only. add virtualization to the mix, and you're in for a *very* rough ride.
<maz> ssvb: because at that point, you are not in control of the memory attributes anymore.
leilei has joined #linux-sunxi
scream has joined #linux-sunxi
<Seppoz> how would i apply this patch if the patch file is located in the linux-sunxi root dir
<Seppoz> patch < file wont work
<Seppoz> nevermind
<Seppoz> missed p1
<Seppoz> grrr
bwarff has quit [Ping timeout: 244 seconds]
leilei has quit [Changing host]
leilei has joined #linux-sunxi
leilei has quit [Quit: Leaving]
leilei has joined #linux-sunxi
<Seppoz> who is in chrge of http://www.armbian.com/ ?
<Seppoz> the patch https://github.com/igorpecovnik/lib/blob/master/patch/kernel/sun7i-default/0026-rt8192cu-missing-case.patch misses to update the /drivers/net/wireless/rtlwifi/rtl8192c/fw_common.h to add #define H2C_92C_KEEP_ALIVE_CTRL
<Seppoz> as well as HW_VAR_KEEP_ALIVE
<Seppoz> so if you git pull the original 104 and apply the patch series the build for this driver fails
<Seppoz> linux-sunxi/drivers/net/wireless/rtlwifi/rtl8192cu/hw.c:1983:7: error: 'HW_VAR_KEEP_ALIVE' undeclared (first use in this function)
<NiteHawk> IgorPec: ^
tkaiser has joined #linux-sunxi
<Seppoz> kaiser: ping
<tkaiser> Seppoz: pong. Not interested in this RTL8192 crap at all and since users aren
<IgorPec> nitehawk: uff , what was about that patch?
<tkaiser> 't complaining it obviously works
<NiteHawk> IgorPec: dunno, ask Seppoz :) looks like he's experiencing a build breakage when cherry-picking the patch
<Seppoz> IgorPec: i think those defines are missing
<tkaiser> Seppoz: You should be aware that the Armbian build system applies all these patches in an automated fashion and if a patch breaks usually one of us fixes this within hours. So no need for further investigation unless you report that the patch breaks when used from within Armbian build system
jemk has quit [Quit: Lost terminal]
<Seppoz> all i did was git pull and apply ALL the patches that are not marked disabled. as i suppose armbian does the same a build for sun7i should fail atm
<IgorPec> and you need to apply them in this order too
<Seppoz> i did
<IgorPec> mmm
<Seppoz> all succeeded
<IgorPec> this driver is fu*** up anyway (rtl8192) and i think those were some last tries to fix it
<Seppoz> ok
<IgorPec> this one, it works better, but not perfect
<tkaiser> IgorPec: And what about https://github.com/dz0ny/rt8192cu (MISC3)?
<IgorPec> could be good too, i lost track which one is better :)
<Seppoz> i hate fuc**** wifi
<Seppoz> its so stupid with all its firmware crap
<IgorPec> agree
<Seppoz> anyone know a stick that works for sure and has good availability?
<tkaiser> Seppoz: I live in a crowded area and trying here anything in 2.4GHz band doesn't work anyway. Only 5GHz (and 802.11ac) is ok
<Seppoz> you have any recommendation that work with built in drivers?
<vickycq> AR9271 maybe?
<Seppoz> any retail product in particular?
<tkaiser> Seppoz: The recommended by vickqcq and me maybe? ;)
<Seppoz> TL-WN721N i got here
<Seppoz> sec
<Seppoz> let me check if i have that driver enabled
<tkaiser> Seppoz: But I wouldn't use anything like this since it's way too slow for my use cases. YMMV
<Seppoz> for my application it wont matter
<Seppoz> as long as it fu*** works
<tkaiser> Seppoz: Then try out AR9271
<Seppoz> TP-LINK TL-WN721N AR9271
<Seppoz> on it
<vickycq> And what about Ralink RT5370
<Seppoz> i think thats the one that worked for me
<Seppoz> tho i didnt find any product yet that i can get in larger quantitys
<Seppoz> i was actually hoping to get the standard series working of tplink and so on
<Seppoz> but since that is not happening..
<vickycq> Make sure it's actually the chipset we want. TPLINK may change chipset in later batches.
<vickycq> Since most customers wont care anyway.
<Seppoz> yea they even change chipsets within the same series
<Seppoz> which really sucks
<vickycq> One example is substitute the good old RT5370 with MT7601
<Seppoz> is there any "common" stick that is LTS or so with a working chipset?
<vickycq> ...the latter being nearly unusable for me :-(
bwarff has joined #linux-sunxi
* vickycq goes out for a walk
<plaes> o_O it's my patch :)
<Seppoz> good ;P
<tkaiser> Seppoz: Olimex cares about stuff like this.
<Seppoz> ok let me bring up the kernel first and we go from there
<Seppoz> needed to recompile + merge my changes
tkaiser has quit [Quit: jIRCii - http://www.oldschoolirc.com]
Net147 has quit [Ping timeout: 244 seconds]
Net147 has joined #linux-sunxi
leilei has quit [Remote host closed the connection]
Net147 has quit [Ping timeout: 268 seconds]
Net147 has joined #linux-sunxi
<montjoie> I begin to understand why EMAC BSP driver use only NAPI
cosm has joined #linux-sunxi
<Amit_T> why ?
<plaes> um.. it doesn't fall back to polling?
jemk has joined #linux-sunxi
cosm has quit [Client Quit]
paulk-collins has quit [Remote host closed the connection]
<montjoie> because it is hard to know if a frame is sent or in preparation
<montjoie> and I hit some case where interrupt fire when preparing a frame
<montjoie> the design of setting a bit (dma can work on this) and the same bit at 0 said it is sent is bad
<montjoie> because 0 is also the value for (I am setting all values on other part of descriptor)
<Seppoz> the tplink i have is not loading with the at9k driver
<montjoie> but I need to clean all frames, if I hit a case where I left a skb and no network during 5s ... boum
<Seppoz> P: Vendor=148f ProdID=7601 Rev=00.00
<Seppoz> S: Manufacturer=MediaTek
<montjoie> but I am near from a solution (49minute of iperf without problem)
<Seppoz> S: Product=802.11 n WLAN
<Seppoz> wow i love this
<Seppoz> this is amazing
<Seppoz> anyone used ATH9271 with a20 before?
clonak has quit [Ping timeout: 240 seconds]
clonak has joined #linux-sunxi
<montjoie> testing my last try, champagne for 3h of iperf without problem
<jelle> cool!
<plaes> yeah :)
<jelle> I love the progress for the H3 :)
<montjoie> I think the best way(suggestive) is to set all error bit to said "dont touch it"
<montjoie> the probability of a frame with all errors is too low:)
<montjoie> apart from that 95Mbit/s in reception and 85Mbit/s transmittion (not bad)
reev has quit [Ping timeout: 248 seconds]
IgorPec has quit [Quit: Nettalk6 - www.ntalk.de]
PietreLinux has joined #linux-sunxi
<PietreLinux> Hi all, because I spent the day compiling the kernel sunxi , the u- boot and tools sunxi , I created a script that sets the system to work with this. Download the dependencies to compile and tools like adb and others, anyone can use https://github.com/pietrelinux/scksunxi.git
<plaes> uhh.. sudo
<PietreLinux> I've just done to give me things and not have to download one or the same again , any advice or help is welcome
<PietreLinux> I have a tablet woxter ( a10 ) where I could run Ubuntu 14.04 from the micro -sd , this added to the wiki http://linux-sunxi.org/Woxter_PC97
leio has quit [Remote host closed the connection]
leio has joined #linux-sunxi
sirblackheart has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
tomboy64 has quit [Ping timeout: 248 seconds]
sirblackheart has quit [Quit: sirblackheart]
tomboy64 has joined #linux-sunxi
cnxsoft has quit [Quit: cnxsoft]
premoboss has quit [Read error: Connection timed out]
premoboss has joined #linux-sunxi
iamfrankenstein1 has joined #linux-sunxi
tomboy64 has quit [Ping timeout: 260 seconds]
tomboy64 has joined #linux-sunxi
<scream> montjoie, nice! can you share the patches?
<montjoie> scream: yes, since it seems working for more than one hour I will release them
<scream> cool! I'll have to reflash the card though. messed with openelec for a while. suprising how well it works :D
tipo has quit [Remote host closed the connection]
tipo has joined #linux-sunxi
apritzel has joined #linux-sunxi
nove has joined #linux-sunxi
hansg has quit [Quit: Leaving]
premoboss has quit [Ping timeout: 276 seconds]
reinforce has quit [Quit: Leaving.]
apritzel has quit [Ping timeout: 244 seconds]
<Seppoz> omfg
<Seppoz> the reason why it DID NOT work was because i had both the C and the CU driver selected
<Seppoz> i mean wtf
merbzt has quit [Ping timeout: 276 seconds]
<montjoie> scream: I just need a final test after removing debug and some memory barrier
bwarff has quit [Ping timeout: 248 seconds]
afaerber has quit [Quit: Ex-Chat]
merbzt has joined #linux-sunxi
afaerber has joined #linux-sunxi
IgorPec has joined #linux-sunxi
paulk-collins has joined #linux-sunxi
cosm has joined #linux-sunxi
p1u3sch1 has quit [Ping timeout: 240 seconds]
p1u3sch1 has joined #linux-sunxi
apritzel has joined #linux-sunxi
cosm has quit [Quit: Leaving]
Netlynx has joined #linux-sunxi
Netlynx has joined #linux-sunxi
hulu1522 has joined #linux-sunxi
zuikis has joined #linux-sunxi
jernej has joined #linux-sunxi
p1u3sch1 has quit [Ping timeout: 240 seconds]
sirblackheart has joined #linux-sunxi
p1u3sch1 has joined #linux-sunxi
apritzel has quit [Ping timeout: 244 seconds]
IgorPec has quit [Quit: Nettalk6 - www.ntalk.de]
alain__ has joined #linux-sunxi
orly_owl has quit [Ping timeout: 260 seconds]
JohnDoe5 has joined #linux-sunxi
JohnDoe_71Rus has quit [Ping timeout: 276 seconds]
<alain__> montjoie: any changes to the emac external PHY code?
<wens> external PHY?
<alain__> on the OPI Plus
yann|work has quit [Ping timeout: 276 seconds]
<jernej> alain_: I just remembered what the problem with external PHY is
<jernej> alain_: there is a special GPIO to turn it on/off
<jernej> AFAIK, that is not implemented?
<jernej> at least that is my guess
<montjoie> alain__: sorry no work at all on rgmii, too busy debuging tx timeout
<montjoie> but the tx queue seems very stable now, I need to publish latest patch
avph has quit [Ping timeout: 246 seconds]
khuey|away is now known as khuey
reinforce has joined #linux-sunxi
Andy-D has joined #linux-sunxi
avph has joined #linux-sunxi
<alain__> jernej: interesting, I guess that's not something I can hack without touching the driver code?
Nacho has quit [Ping timeout: 252 seconds]
<jernej> alain_: maybe it is possible if you just set pin high with standard gpio interface
Nacho has joined #linux-sunxi
orly_owl has joined #linux-sunxi
vagrantc has joined #linux-sunxi
doppo has quit [Ping timeout: 248 seconds]
doppo has joined #linux-sunxi
mossroy has joined #linux-sunxi
IgorPec has joined #linux-sunxi
massi has quit [Quit: Leaving]
<jelle> orangepi.org is that the official forum?
<jelle> oh it is, but wow it's faster now
enrico_ has quit [Quit: Bye]
<jernej> jelle: when it is slow, you can use some web proxy page to access it
<jelle> yeah....
<jernej> I figured out, that speed depends on ISP, at least for me
<jelle> jernej: I just assumed it was hosted on an orange pi :p
<jernej> jelle: which overheats :D
<jelle> I wonder if there are overheating topics on their forum
<jernej> yes, they are
<jelle> "open source hardware" topic
<jernej> tkaiser a.k.a. bronco discussed it
deskwizard has joined #linux-sunxi
<jelle> do they actually respond to documentation requests?
<alain__> nope :(
<jernej> who? steven?
<jelle> would be nice to get the hdmi controller docs
<alain__> looks like steven has kind of disappeared
<jernej> jelle: I asked steven about it and he said it will try to get it
<jelle> jernej: nice
<alain__> must be busy working on orange pi 2 plus 2 + v2
<jernej> *he
<jernej> but that was more than two weeks ago
<alain__> looks like u-boot can set gpio pins
<jernej> alain__: but GPIO state doesn't survive kernel boot
<jernej> I will try with dts hack
<alain__> hahah you just saved me 30 minutes trying thanks
tkaiser has joined #linux-sunxi
<jernej> tkaiser: You are right. Pin PD6 is part of RGMII interface.
<jernej> so the main question is how to set pin PD6 to 1 while it is also part of RGMII interface but unused
avph has quit [Ping timeout: 246 seconds]
<lennyraposo> completed my audio tests with Pine64
avph has joined #linux-sunxi
Netlynx has quit [Quit: Leaving]
PietreLinux has quit [Quit: Page closed]
<lennyraposo> the issue is with pulse and alsa default setup
sirblackheart has quit [Quit: sirblackheart]
<jelle> nice!
<montjoie> 5h of iperf without problem
<tkaiser> montjoie: Also with -d?
<montjoie> with -d
<montjoie> for testing tx
<tkaiser> montjoie: So no more lockups when testing bidirectional traffic? Nice
tipo has quit [Remote host closed the connection]
tipo has joined #linux-sunxi
<montjoie> iperf in parallel with compile on NFS
JohnDoe5 has quit [Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/]
JohnDoe_71Rus has joined #linux-sunxi
mane has quit []
<deskwizard> good job guys !
<jernej> alain__: I manage to get it working on PLUS :)
<alain__> brillant
<alain__> by tweaking the dtsi file ?
<jernej> just remove PD6 definition from emac_rgmii_pins
<jernej> and then execute "gpio set PD6" in u-boot
<jernej> ofc, this is quick workaround
<alain__> ah ok and then the kernel does not touch it
<jernej> yes
<jernej> and now I'm going to test new version of driver :)
<alain__> same here :)
<tkaiser> jernej: alain_: First test should be an iperf -c -t60 $server -d (since if this doesn't lock up then everything's perfect from the very beginning ;)
<jelle> nice
IgorPec has quit [Ping timeout: 246 seconds]
IgorPec has joined #linux-sunxi
matthias_bgg has quit [Quit: Leaving]
afaerber has quit [Quit: Ex-Chat]
<jernej> montjoie: probably you should remove pins PD6, PD11 and PD14 from emac_rgmii_pins definition, because they don't have any functionality (RGMII_NULL) and at least PD6 is used for other stuff
<alain__> jernej: would you happen to have a dtsi file that has both the eMMC and emac for the OPI Plus ?
<jernej> alain__: yes, I applied emac patches on top of mripard's sunxi/for-next branch, which already has eMMC bits
<alain__> is it accessible on github? that's exactly what I am after
<jernej> which part? eMMC?
<jernej> or my changes?
<alain__> eMMC + emac merged
<jernej> no, I didn't upload it yet
<jernej> anyway, I'm using build system which is using patches, so to speak, changes get merged only during build
<alain__> I'll just play around with the emac driver on a SD card for now, I guess the updated driver will somehow trickle to Hans' tree
<jernej> but I can always put it on pastebin if you want
<alain__> that would be nice :)
<jernej> here you have: http://pastebin.com/Qzxkn33t
<jernej> just be aware that opiplus dts is based on opi2
<alain__> yes i've seen that change a few days ago
<alain__> montjoie: btw I'm getting errors when building the kernel straight from your tree
<tkaiser> IgorPec: Will you look into this if tests results reported by jernej and alain_ look already promising? Talking about adding this to vanilla for OPi+
<alain__> montjoie: http://pastebin.com/sqQQqp1h
dev1990 has joined #linux-sunxi
premoboss has joined #linux-sunxi
<alain__> tkaiser: only partially applies
<alain__> hunks 15 & 17 fail
cosm has joined #linux-sunxi
<montjoie> alain__: because you miss usb patch
<montjoie> you could just remove ehci ohci node
<alain__> I'll wait a few days that everything is merged properly rather than building my own frankenstein kernel
<alain__> :)
alain___ has joined #linux-sunxi
alain__ has quit [Ping timeout: 250 seconds]
<IgorPec> tkaiser: mmc under 4.4 @opi+ ?
<tkaiser> IgorPec: According to jernej it should work after adding the eMMC bits to .dts?
afaerber has joined #linux-sunxi
<jernej> IgorPec: tkaiser: eMMC works, but I'm using mripard's sunxi/for-next branch
<jernej> it has dts files for plus, pc and 2
yann|work has joined #linux-sunxi
Seppoz has quit [Remote host closed the connection]
<wens> montjoie: still a lot of rx errors?
<montjoie> no
<montjoie> alain___: you need patch 108 and 109 from http://sunxi.montjoie.ovh/ethernet/
<montjoie> wens: sorry I misread you. Still rx errors
<montjoie> but tx is stabble, no timeout
<plaes> montjoie: You don't have permission to access /ethernet/0108-ARM-dts-sun8i-Add-support-for-H3-usb-clocks.patch on this server.
<plaes> same for 109
<montjoie> solved
iamfrankenstein1 has quit [Quit: iamfrankenstein1]
khuey is now known as khuey|away
iamfrankenstein1 has joined #linux-sunxi
<wens> montjoie: ok
jernej has quit [Ping timeout: 244 seconds]
jernej has joined #linux-sunxi
<wens> montjoie: updated both my a83t and h3 branches
ricardocrudo has quit [Ping timeout: 248 seconds]
<longsleep> ssvb: Hey, does it make sense to roll a new f86-video-fbturbo deb package from your aarch64 branch already or should i wait a couple of days?
<ssvb> longsleep: please wait, I'll push the patches to the master branch when they are ready
<longsleep> ssvb: ok - just browsed your repository and was wondering :)
tkaiser has quit [Ping timeout: 248 seconds]
tkaiser has joined #linux-sunxi
<lennyraposo> I will give that a try next longsleep
<longsleep> lennyraposo: what exactly?
<lennyraposo> longsleep
<lennyraposo> the fbturbo stuffs ;)
<lennyraposo> also
<lennyraposo> audio issue is to do with alsa/pulseaudio
<lennyraposo> config
<longsleep> lennyraposo: well, what X11 driver do you use now?
<longsleep> lennyraposo: yes i know, but i have no wish to learn about pulse alsa and all that to fix it :)
<lennyraposo> would have to check
<lennyraposo> whatever came with arm64 debian ports
<lennyraposo> installed flawlessy through tasksel
<lennyraposo> mate/xfce/lxde
<lennyraposo> tv is occupied by daughter now
<longsleep> heh
alain___ has quit [Ping timeout: 250 seconds]
<lennyraposo> so I got mp3 wv ogg files
<lennyraposo> plus youtube working audio
<lennyraposo> no issues ;)
<longsleep> lennyraposo: use the files from http://www.kozco.com/tech/soundtests.html for testing
<lennyraposo> will do
<lennyraposo> bookmarking
<lennyraposo> I will record video showing what I did
<lennyraposo> and the playback
<longsleep> lennyraposo: so you added some alsa config?
<tkaiser> jernej: Did you succeed in testing GbE on the Plus?
<lennyraposo> changed the default card to sndhdmi
iamfrankenstein1 has quit [Ping timeout: 250 seconds]
<longsleep> tkaiser: dont give up on the pine64 board please, i have a lot of fun reading :)
<lennyraposo> then in pulse disabled the audiocodec device ;)
<longsleep> lennyraposo: hum ok
<jernej> tkaiser: I didn't do iperf if that's what you mean
<lennyraposo> installed pavucontrol
<lennyraposo> to do so
<tkaiser> longsleep: Nope, for the moment it's enough. Unless the Pine64 folks provide some sort of a FAQ it's just a waste of time and efforts (and nerves)
<jernej> tkaiser: I'm trying to enable PD6 without u-boot
<tkaiser> jernej: ok
<lennyraposo> goonna write up the config manually as alsactl store seems ot do nothing and resetsw the config on reboot
<jernej> tkaiser: through dts, but phy-supply doesn't work for some reason or I mess something up
<lennyraposo> btw
<longsleep> tkaiser: i have confined myself to the developer threads, especially the ones i created myself
<lennyraposo> the only display option is 1080p for now right?
<longsleep> lennyraposo: no, ther are other options but they have to be set in FTD
<lennyraposo> I can ask tllim what resolutions are fully supported
<tkaiser> longsleep: Yes, but I've been still in the 'parse collective weirdness' mode to provide you with some helpful insights what's really happening regarding the Ethernet bug. But this is solved fortunately now
<longsleep> tkaiser: yes, not for Android though
<tkaiser> longsleep: Who cares? They have to take their fix and deploy a new image
<tkaiser> s/their/your/
<longsleep> lennyraposo: well, just look into the BSP to see what is supported, with my Kernels max is 1080p@32bpp
<lennyraposo> I can put a selection method/hierchy in there correct
<lennyraposo> still learning as you know ;)
<longsleep> lennyraposo: that needs testing, U-Boot is initializing HDMI very early and it is unknown if the Linux Kernel driver can change the HDMI resultion later on
<longsleep> lennyraposo: you can change the fb resolution with fbset easily
<tkaiser> longsleep: lennyraposo: I did some tests yesterday and modifications to the .dts worked in u-boot but kernel seemed to use 'hardcoded' 1080p60
<tkaiser> jernej: just realized that I never saw any iperf numbers for the OPi Plus with BSP kernel. But I would suspect they should be similar to A83T (Banana Pi M3)
<longsleep> tkaiser: mhm, i managed to get it running with 720p while getting HDMI running in February
<tkaiser> longsleep: Did you zeroed out sysconfig.fex stuff back then already?
<longsleep> tkaiser: mhm no idea :)
<jernej> tkaiser: I could do it, but some other day
<tkaiser> longsleep: Ok, will remain a miracle (or an exercise for others ;) )
<tkaiser> jernej: No need to. SinoVoip sent a Banana Pi M2+ out (for whatever reasons) so I will have a look myself.
<tkaiser> BPi M2+ needs config from Orange Pi Plus and only USB config has to be slightly adjusted. Pretty identical clone
<lennyraposo> good to know guys
<lennyraposo> btw
<jernej> tkaiser: Ok. Which emac patchset do you plan to use on Armbian?
<lennyraposo> longsleep have you been using gcc 4.8 for u-boot and 5.2 for kernel?
<jernej> tkaiser: If I create patch for phy-supply, it would be nice if it would work on both systems
<tkaiser> lennyraposo: Sure (RTFM ;) )
<longsleep> lennyraposo: yes
<lennyraposo> :D
<lennyraposo> awesome
<lennyraposo> btw
<tkaiser> jernej: Agreed. ATM I would stay with wens' branch (since it worked out of the box and he also has Cubietruck + in his hands)
<lennyraposo> if ther eare any resources you guys need like hosting storage feel free to ask ;)
<tkaiser> jernej: But I do not really know. Maybe leaving it up to IgorPec since he tests with OPi + :)
<IgorPec> i am compiling right now ,)
tomboy64 has quit [Ping timeout: 264 seconds]
foudubassan has quit [Ping timeout: 248 seconds]
apritzel has joined #linux-sunxi
<IgorPec> tkaiser: uboot stucks at USB0
vagrantc has quit [Quit: leaving]
<tkaiser> IgorPec: Remember the report from yesterday in the forums?
<IgorPec> nope, i am in half sleep mode :(
<lennyraposo> you think th e2gb model will be good enough for stand alone compiling in the future longsleep
<lennyraposo> cause I ordered an additional for those purposes
tomboy64 has joined #linux-sunxi
<IgorPec> tkaiser: ahaa, will try to resolv this
tomboy64 has quit [Read error: Connection reset by peer]
<tkaiser> IgorPec: Notable difference. Branch dev: 'Trying to boot from MMC1' vs. 'MMC' when he tried next (which can't work)
<tkaiser> IgorPec: So most probably I f*cked something up on Saturday.
<jelle> I could try the emac driver on the orange pi one
tipo has quit [Remote host closed the connection]
tomboy64 has joined #linux-sunxi
<IgorPec> hehe, i'll check up in the morning. i am to wasted
<tkaiser> IgorPec: Sleep well :)
tipo has joined #linux-sunxi
<IgorPec> 10x
IgorPec has quit [Quit: Nettalk6 - www.ntalk.de]
<tkaiser> longsleep: We had a reported issue with H3 BSP kernel that corrupted AppleTalk multicast packets. I tried it out just for fun with your Xenial image: Also broken (maybe at Allwinner nobody knows that there exist other protocols than IP? ;)
<tkaiser> longsleep: Should I open an issue on Github? ;)
khuey|away is now known as khuey
apritzel has quit [Ping timeout: 244 seconds]
cosm has quit [Ping timeout: 246 seconds]
megi has joined #linux-sunxi
tkaiser has quit [Ping timeout: 252 seconds]
mossroy has quit [Remote host closed the connection]
tkaiser has joined #linux-sunxi
reinforce has quit [Quit: Leaving.]
<megi> Hi, I've been working on power regulation for Orange PI PC and Orange PI One. Here's the branch: https://github.com/megous/linux/commits/orangepi-cpufreq
<megi> I used atalax's THS patch and cleaned it up a bit based on the mailing list review. This seems to work with an exception that on boot, some initial readouts are wrong (271°C), so I needed to disable critical temperature trip point in thermal zone, because otherwise kernel panics immediately on boot.
<megi> OrangePI One stuff works quite well. It's just a simple GPIO based regulator. I hooked it up to cpufreq-dt and thermal_zone, and frequency/voltage changes work.
<megi> OrangePI PC is giving me a bit of trouble. I wrote SY8106A regulator driver, and figured out how to enable TWI_R (I2C) interface on PL0/1 pins. I can set voltages correctly using this driver (verified using voltmeter).
<megi> But I have trouble hooking this up with cpufreq-dt. Board boot fails when cpufreq should be intializing. I can see using voltmeter that cpufreq selects the 1.3GHz/1.32V mode. But then I loose UART connection to the board shortly after. It looks like some kind of a power failure.
<megi> Any ideas on how to debug this? I'm at loss at this point. I have Orange PI PC connected to 5V/30A power supply over a good cable.
zuikis has left #linux-sunxi [#linux-sunxi]
Nacho has quit [Ping timeout: 244 seconds]
Nacho has joined #linux-sunxi
tkaiser has quit [Quit: jIRCii - http://www.oldschoolirc.com]
jstein has joined #linux-sunxi
jernej has quit [Ping timeout: 276 seconds]
Nacho has quit [Ping timeout: 248 seconds]
fredy has quit [Excess Flood]
fredy has joined #linux-sunxi
nove has quit [Quit: nove]
paulk-collins has quit [Quit: Leaving]
Nacho has joined #linux-sunxi
jernej has joined #linux-sunxi
vagrantc has joined #linux-sunxi
cosm has joined #linux-sunxi
tomboy64 has quit [Ping timeout: 240 seconds]
tomboy64 has joined #linux-sunxi
Keziolio has quit [Ping timeout: 244 seconds]
<wens> montjoie: the rx error rate is quite high :|
deskwizard has quit [Remote host closed the connection]
JohnDoe_71Rus has quit [Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/]
a|3x has joined #linux-sunxi
phylophyl has left #linux-sunxi ["http://quassel-irc.org - Discuter simplement. Partout."]
jstein has quit [Remote host closed the connection]
megi has quit [Quit: Odcházím]
bwarff has joined #linux-sunxi
Andy-D has quit [Ping timeout: 250 seconds]
scream has quit [Remote host closed the connection]
dev1990 has quit [Quit: Konversation terminated!]
Andy-D has joined #linux-sunxi
pekka10 has quit [Quit: WeeChat 1.2]
pekka10 has joined #linux-sunxi
p1u3sch1 has quit [Ping timeout: 240 seconds]
p1u3sch1 has joined #linux-sunxi
vagrantc has quit [Quit: leaving]
<[Awaxx]> hello Thx for the wiki, I made a tuto about tftpboot with a bananapi