dev1990 has quit [Remote host closed the connection]
cubear has joined #linux-sunxi
selfbg has joined #linux-sunxi
premoboss has quit [Quit: Sto andando via]
domidumont has joined #linux-sunxi
<wens>
has anyone considered moving the mailing list over to infradead.org?
<wens>
mnemoc: ^
domidumont has quit [Remote host closed the connection]
HeHoPMaJIeH has joined #linux-sunxi
domidumont has joined #linux-sunxi
7JTACI3BR has quit [Quit: Leaving]
sehraf has joined #linux-sunxi
aballier has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
Andy-D has joined #linux-sunxi
diego71 has joined #linux-sunxi
_massi has joined #linux-sunxi
prz has joined #linux-sunxi
<mripard_>
wens: I asked some time ago for kernel.org, mnemoc was against it
lerc has joined #linux-sunxi
setkeh has quit [Ping timeout: 245 seconds]
a1d3s295 has joined #linux-sunxi
book` has quit [*.net *.split]
a1d3s|away has quit [*.net *.split]
setkeh has joined #linux-sunxi
book` has joined #linux-sunxi
hipboi_ has joined #linux-sunxi
leviathancn has joined #linux-sunxi
hipboi has quit [Ping timeout: 264 seconds]
FR^2 has joined #linux-sunxi
premoboss has joined #linux-sunxi
leviathancn has quit [Ping timeout: 250 seconds]
<plaes>
wens: AXP20x PEK seems to be merged
leviathancn has joined #linux-sunxi
<wens>
plaes: but the bindings aren't
<wens>
which i need for axp221 patches
naobsd1 has quit [Quit: naobsd1]
<plaes>
hmm..
<plaes>
I have missed these when updating the Mainlining status wiki page
jemk has joined #linux-sunxi
reinforce has joined #linux-sunxi
FreezingAlt has joined #linux-sunxi
naobsd has joined #linux-sunxi
TheQuestionmark has quit [Quit: "PRESS STOP ON TAPE"]
ricardocrudo has joined #linux-sunxi
leviathancn has quit [Ping timeout: 246 seconds]
TheQuestionmark has joined #linux-sunxi
FreezingAlt has quit [Ping timeout: 240 seconds]
simosx has joined #linux-sunxi
<mnemoc>
wens: initially it was the first I tried. Moving MLs is problematic in general, and G does a great job containing spam on an open ML. I was going to try to extend a bit the infrastructure to be able to host (own-domain) MLs, forwards, wiki, dl, and maybe a phabricator to any project similar to this
<mnemoc>
wens: I'm finally settled here in UK so I will have time, and it will be simpler that catching up with all the sunxi development that has happened since I left :p
<mnemoc>
wens: are you having troubles with the current ML or the issue is only that it is hosted by G?
<wens>
i think the biggest issue would be google is blocked in China
<mnemoc>
also smtp?
<mnemoc>
or only the archive?
<wens>
not sure about smtp
<wens>
i think leviathanch did some testing
naobsd has quit [Quit: naobsd]
<mnemoc>
wens: do you know if cloudflare in front of the wiki brings troubles in china?
<wens>
no idea
naobsd has joined #linux-sunxi
domidumont has quit [Read error: Connection reset by peer]
naobsd has quit [Quit: naobsd]
kz1 has joined #linux-sunxi
Net147 has joined #linux-sunxi
premoboss has quit [Quit: Sto andando via]
orly_owl has quit [Quit: Lost terminal]
orly_owl has joined #linux-sunxi
Renard has joined #linux-sunxi
leviathancn has joined #linux-sunxi
Renard has quit [Ping timeout: 245 seconds]
Black_Horseman has quit [Ping timeout: 272 seconds]
<mripard_>
mnemoc: fwiw, I'm really *not* in favor of a linux-sunxi hosted ML.
ganbold_ has joined #linux-sunxi
<mnemoc>
mripard_: veto granted
ssvb has quit [Ping timeout: 264 seconds]
Renard has joined #linux-sunxi
jinzo has joined #linux-sunxi
FreezingAlt has joined #linux-sunxi
<mripard_>
archives are really too important, and the bus factor is way too high
FreezingAlt is now known as FreezingCold
<mripard_>
that apart, I really don't care about wether it's on infradead or kernel.org or whatever.
<mnemoc>
i believe we have third-party archives already
naobsd has joined #linux-sunxi
domidumont has joined #linux-sunxi
domidumont has quit [Client Quit]
arossdotme has quit [Quit: Leaving.]
Black_Horseman has joined #linux-sunxi
domidumont has joined #linux-sunxi
leviathancn has quit [Ping timeout: 256 seconds]
Black_Horseman has quit [Ping timeout: 256 seconds]
leviathancn has quit [Remote host closed the connection]
leviathancn has joined #linux-sunxi
reinforce has joined #linux-sunxi
Renard has quit [Ping timeout: 264 seconds]
FreezingCold has quit [Ping timeout: 252 seconds]
Renard has joined #linux-sunxi
afaerber_ is now known as afaerber
HeHoPMaJIeH has quit [Quit: Konversation terminated!]
afaerber has quit [Quit: Verlassend]
linux_salonica has quit [Remote host closed the connection]
FreezingCold has joined #linux-sunxi
linux_salonica has joined #linux-sunxi
iamfrankenstein has joined #linux-sunxi
afaerber has joined #linux-sunxi
reinforce has quit [Remote host closed the connection]
Renard has quit [Ping timeout: 255 seconds]
simosx has quit [Quit: Leaving]
skaag has joined #linux-sunxi
skaag has quit [Max SendQ exceeded]
skaag has joined #linux-sunxi
skaag has quit [Max SendQ exceeded]
skaag has joined #linux-sunxi
skaag has quit [Max SendQ exceeded]
skaag has joined #linux-sunxi
skaag has quit [Max SendQ exceeded]
skaag has joined #linux-sunxi
quitte has joined #linux-sunxi
skaag has quit [Max SendQ exceeded]
skaag has joined #linux-sunxi
skaag has quit [Max SendQ exceeded]
skaag has joined #linux-sunxi
skaag has quit [Max SendQ exceeded]
skaag has joined #linux-sunxi
skaag has quit [Max SendQ exceeded]
skaag has joined #linux-sunxi
skaag has quit [Max SendQ exceeded]
skaag has joined #linux-sunxi
skaag has quit [Max SendQ exceeded]
deffrag__ has quit [Read error: Connection reset by peer]
skaag has joined #linux-sunxi
skaag has quit [Max SendQ exceeded]
skaag has joined #linux-sunxi
skaag has quit [Max SendQ exceeded]
skaag has joined #linux-sunxi
skaag has quit [Max SendQ exceeded]
skaag has joined #linux-sunxi
skaag has quit [Max SendQ exceeded]
skaag has joined #linux-sunxi
skaag has quit [Max SendQ exceeded]
leviathancn has quit [Ping timeout: 272 seconds]
skaag has joined #linux-sunxi
skaag has quit [Max SendQ exceeded]
skaag has joined #linux-sunxi
skaag has quit [Max SendQ exceeded]
skaag has joined #linux-sunxi
skaag has quit [Max SendQ exceeded]
Renard has joined #linux-sunxi
skaag has joined #linux-sunxi
skaag has quit [Max SendQ exceeded]
skaag has joined #linux-sunxi
skaag has quit [Max SendQ exceeded]
skaag has joined #linux-sunxi
skaag has quit [Max SendQ exceeded]
skaag has joined #linux-sunxi
skaag has quit [Max SendQ exceeded]
skaag has joined #linux-sunxi
skaag has quit [Max SendQ exceeded]
FR^2 has quit [Quit: Connection reset by peer]
mmarker has joined #linux-sunxi
bonbons has joined #linux-sunxi
naobsd has quit [Remote host closed the connection]
reinforce has joined #linux-sunxi
quitte has quit [Ping timeout: 252 seconds]
_massi has quit [Quit: Leaving]
prz has quit [Quit: Leaving.]
reinforce has quit [Remote host closed the connection]
quitte has joined #linux-sunxi
Netlynx has joined #linux-sunxi
Froolap has joined #linux-sunxi
khuey|away is now known as khuey
cooper__ has joined #linux-sunxi
<cooper__>
I've been trying various kernel configs to see which setting is causing memory corruption on my PcDuino3 Nanos and I've currently narrowed it down to 1 setting which, incidentally, wasn't what I expected.
<cooper__>
CONFIG_ARM_THUMB
<cooper__>
When I remove thumb support, I get errors recompiling glibc with more concurrent jobs than cores.
<cooper__>
I'm going to test this on the 'feature complete' kernel atsampson uses for his DDR work to see if it's really just that one setting, or if there's some interaction with other parts of the kernel I switched off.
<cooper__>
And before you ask, I know for a fact that no thumb binaries exist on my platform since I've compiled every program on it myself (Gentoo).
paulk-collins has quit [Ping timeout: 252 seconds]
ricardocrudo has quit [Ping timeout: 264 seconds]
FreezingCold has quit [Ping timeout: 244 seconds]
Nyuutwo has quit [Ping timeout: 272 seconds]
Nyuutwo has joined #linux-sunxi
khuey is now known as khuey|away
<leviathanch>
Hey everyone!
<leviathanch>
little question
<leviathanch>
what would you prefer more?
<leviathanch>
that we get rid of media-codec and develop libvdpau-sunxi instead?
premoboss has joined #linux-sunxi
<leviathanch>
or that we partially release media-codec?
<leviathanch>
actually the question we have to discuss at Allwinner now
<leviathanch>
because there were some voices which were totally against only a partial release
<leviathanch>
but there are some developers at AW who don't wanna give their copyright to a copyleft
<leviathanch>
which means a full code disclosure isn't possible
<mripard_>
leviathanch: I'd say that you don't really have the choice.
<mripard_>
you shipped code that was using (L)GPL licensed code
<leviathanch>
yes
<leviathanch>
uhm
<mripard_>
wether you want to release or not is not debattable
<mripard_>
and wether it is (L)GPL or not is not either
<mripard_>
the question you ask might be legitimate for future developments
<mripard_>
but it really isn't for the developments that already happened
<leviathanch>
I told them to have a look into libvdpau-sunxi
<mripard_>
that's good
<mripard_>
but it really doesn't change the fact that you have to release that code
<jemk>
that's not that good, v4l2 would be better
FDCX_ has joined #linux-sunxi
<mripard_>
and the developers that don't feel like releasing their code under a copyleft license should have thought about that before copying/using such code
protoCall7 has joined #linux-sunxi
<leviathanch>
actually the LGPL *does* allow of the delivery binary-only parts...
f15h has joined #linux-sunxi
<leviathanch>
as far as I'm informed
<leviathanch>
but however
<mripard_>
true. If your application/library is just linked to that LGPL component
<ssvb>
mripard_: they really need to consult a real lawyer before taking any actions
<mripard_>
and if you provide a way to upgrade the LGPL component
<leviathanch>
frankly, I'm personally also convinced that this so-solution is ugly and crappy
<leviathanch>
but I also wanna keep a good relation with Allwinner because the food in China is better and the jobs are cooler
premoboss has quit [Remote host closed the connection]
<mripard_>
and you still have to provide the code of that LGPL component
<leviathanch>
and I like the people :)
<leviathanch>
yes
<leviathanch>
anyway
<mripard_>
so there's still a lot of ifs.
<mripard_>
ssvb: indeed
<leviathanch>
okey, I'm trying to convince the folks from AW to just drop this game with so files and so on
<leviathanch>
and just integrate the relevant pieces of code into the existing open source projects
<leviathanch>
because sunxi project is already reverse engineering their chipsets
<mripard_>
leviathanch: or like ssvb suggested
<mripard_>
leviathanch: just make them hire a lawyer / legal consultant for an audit
<mripard_>
maybe they'll trust him more.
<ssvb>
mripard_: I'm not so sure (and I'm not a lawyer), but I believe that just stopping the distribution of the infringing software might be ok too
<leviathanch>
mripard_: yes, that's what I'm saying
<leviathanch>
instead we just extract the parts which are actually required for functionality
<leviathanch>
and put it into the already existing FOSS projects
<ssvb>
mripard_: which means that old cedar blobs might be not a big issue because the old hardware is not being sold anymore
paulk-collins has joined #linux-sunxi
<atsampson>
Cooper__: heh -- excellent! I wonder if there's some bit of threading code in glibc that uses THUMB mode or something...
<ssvb>
mripard_: however it is clear that the current software needs to become compliant for sure
<atsampson>
Cooper__: it's certainly something you want enabled, since there are bits of hand-tweaked code that are substantially more efficient in THUMB mode (since you can fit more in the icache, for example)
<ssvb>
mripard_: but then again, it is not a legal advice and they need to consult with the professionals :)
f15h has quit [Quit: Leaving]
<cooper__>
atsampson: And where would this code reside? In kernel or on the application side of things? For typical gcc you'd have to provide -mthumb or -mthumb-interwork to even get thumb code built.
<cooper__>
atsampson: And I know for a fact nothinig on this machine is built with that.
<cooper__>
atsampson: Could be some ASM provided separately within the app code, but due to the sheer randomness of things I still believe it's somewhere within the kernel
<cooper__>
atsampson: If something in the kernel depends on thumb, it shouldn't allow me to turn off kernel support for it.
<ssvb>
Cooper__: why is thumb suspected now? have I missed something?
<cooper__>
atsampson: I started disabling thumb sometime ago when I was playing with an Odroid-U2 (Samsung ??ynox 4412 prime)
<cooper__>
ssvb: Started out with atsampson's kernel he used for his DDR work to have a working starting point. Then incrementally changed stuff until my build of glibc started failing. Honed in that way.
reinforce has joined #linux-sunxi
<atsampson>
Cooper__: in userspace, I'm thinking; the CPU will always support switching to THUMB mode, so a bit of assembly somewhere could do it, but if the kernel (for example) doesn't save the processor state correctly when handling signals, then your code can randomly blow up if it happens to be executing in THUMB mode and the kernel does something...
<cooper__>
I'm currently building a kernel with the multi_v7_defconfig and the extra's he's using, but without thumb support and with the marvell chips unsupported so I can also turn of thumbee.
<atsampson>
-mthumb/-mthumb-interwork affect C/C++, but there's plenty of hand-coded ARM assembler out there
<cooper__>
If that shows to cause build problems, I'm calling it.
<cooper__>
But I have 2 configs here whose only difference is that one thumb support option. One works, the other doesn't.
<atsampson>
but why would you *want* to turn off THUMB support?
<cooper__>
atsampson: Well, that started when I was trying to squeeze the kernel I was running on my U2.
<cooper__>
I needed a performance test, which included one that relied on GMP.
<cooper__>
Problem was, GMP doesn't build as a thumb binary.
<ssvb>
I would first suggest to disable the newish Cortex-A7 features and stick with the baseline armv7 + neon
<cooper__>
Filed a bug for it and they returned saying it wasn't supported.
FreezingCold has joined #linux-sunxi
<ssvb>
thumb is rather old and most of the bugs related to thumb have been ironed out
<cooper__>
Combine that with the general consensus on the gcc mailinglist that thumb binaries, while smaller, typically run 5% slower and the fact that I build all my binaries myself anyways, I figured why bother providing support for it?
<ssvb>
the cortex-a7 errata list also does not seem to contain anything interesting related to thumb
<atsampson>
well, because "typically" isn't "always" -- if you've got a bit of code that will be more efficient in THUMB mode (remember you can freely switch between the two modes; it's just a BX instruction) then it can be faster
<atsampson>
you wouldn't want to build everything in THUMB mode, but having the option can be useful
<cooper__>
atsampson: Yeah, *now* he tells me...
<cooper__>
:-p
<ssvb>
Cooper__: if you are trying to disable thumb support in the kernel, then this is a very bad idea
<cooper__>
ssvb: Yeah, I'm starting to get that.
<atsampson>
looking at the glibc source, there's some fairly hairy conditional code in sysdeps/arm that decides when to use THUMB for some of the string intrinsics
<cooper__>
I'm just surprised that this stuff a) is causing memory corruption, particularly on multi-job compiles and b) it's even possible to select since it's such a bad idea to begin with.
<ssvb>
Cooper__: which stuff was it again? have you identified the offending option which makes the difference?
<cooper__>
CONFIG_ARM_THUMB
<ssvb>
hmm
<cooper__>
Flip that and a make -j3 on glibc fails before completion.
<cooper__>
... on a dual-core machine.
<cooper__>
I'm still building that multi_v7_defconfig + extras - thumb - marvell - thumbee kernel to confirm.
<ssvb>
Cooper__: disabling CONFIG_ARM_THUMB only makes the kernel pretend that thumb does not exist and does not need special handling, and encountering thumb code in the userland will make some really bad things happen
<ssvb>
Cooper__: it just looks like your kernel might be miscompiled due to some GCC bug, this is not particularly uncommon
<cooper__>
But then I would expect the build to fail reliably at the same point. It's awfully errattic...
<cooper__>
Current compiler: gcc (Gentoo 4.9.2 p1.2, pie-0.6.2) 4.9.2
<ssvb>
you can't expect anything when the code is miscompiled
<cooper__>
True.
<cooper__>
But the only variable is the kernel itself...
<ssvb>
try to compile the kernel with gcc 4.7 or 4.8 and check if this helps
<cooper__>
Once I confirm with this kernel I'll do that.
<cooper__>
I've got a 4.8.4 on here aswell. Should be latest 4.8 version available.
<ssvb>
one other possibility is that the old code (is it the 3.4 kernel?) might be not exactly C standard compliant and the new optimizations in GCC 4.9 just expose this bug
<cooper__>
Mainline.
<cooper__>
But I had the same problem while on 3.4
<cooper__>
Mainline is 4.0-rc1 from march 2.
<cooper__>
mripard's branch
Andy-D has quit [Read error: Connection reset by peer]
tomcheng76 has quit [Read error: Connection reset by peer]
tomcheng76 has joined #linux-sunxi
afaerber has quit [Quit: Verlassend]
dev1990 has joined #linux-sunxi
dev1990 has quit [Client Quit]
<cooper__>
Setting confirmed to cause the build error on a fully featured kernel.
<cooper__>
Let me rephrase that.
<cooper__>
I just confirmed that disabling thumb support on this fully featured kernel causes a build error (segfault) when building glibc with more concurrent jobs than cores available on this platform.
<cooper__>
I'll rebuild this kernel with my other GCC to see if that helps in any way.
<cooper__>
The other GCC is: gcc (Gentoo 4.8.4 p1.0, pie-0.6.1) 4.8.4
<Froolap>
I'm going to cry.
<ssvb>
Cooper__: just to confirm something, are you saying that *disabling* CONFIG_ARM_THUMB kernel option makes the system unstable?
<cooper__>
Correct.
<ssvb>
now everything becomes perfectly clear
<cooper__>
A zen moment?
Black_Horseman has joined #linux-sunxi
<ssvb>
Cooper__: just don't disable CONFIG_ARM_THUMB, it is *very* wrong and having problems in this setup is totally expected
<cooper__>
No sense in testing this with another compiler as you previously suggested?
<ssvb>
yes, it does not make sense doing any other tests, this looks like a very clear culprit
<Nyuutwo>
Cooper__: have you seen help in menuconfig for this option?
<cooper__>
Of course. Read it even.
* ssvb
earlier thought that Cooper__ originally had problems with CONFIG_ARM_THUMB enabled, because that would be in fact quite a mystery to investigate
<cooper__>
But being advised to leave it on doesn't mean "death awaits those who venture into the murky shadows of the world where it's not turned on".
<ssvb>
well, this warning should be probably added there
<Nyuutwo>
Cooper__: so if you DISABLE this option, kernel WILL bork on any THUMB code when it will switch contexts
<cooper__>
I was expecting GCC to not produce thumb code since I'm not telling it to.
<cooper__>
And all code on this platform was compiled by me with that setting.
<ssvb>
it's kind of like the "Do not put pets in the microwave to dry them" warning :)
<cooper__>
So I assumed it was safe.
<Nyuutwo>
not for hand assembly
<Nyuutwo>
and why you want to disable it?
<cooper__>
Because I decided I didn't want any thumb binaries on my system (5% performance drop and another package explicitly not supporting it made me question its usefulness and, thus, just drop it altogether) I figured it made no sense to include kernel support for that too.
<cooper__>
Felt like buying a canister of high-octane gasoline when I'm driving a diesel.
<cooper__>
Didn't expect some mixed-mode asm funkiness to be in place.
<cooper__>
And, and this might just be my personal brain damage, when the option exists to not do something, I don't expect that something to be a requirement for a stable system.
<cooper__>
Work or not work, that I can deal with.
<cooper__>
General instability... That's just unexpected.
<cooper__>
To be honest, it does feel like a relief to me that I understand to some extent what's going on.
<cooper__>
But I guess ssvb was right in the end - I was ricing too much. ;-)
<ssvb>
:-)
<cooper__>
Just reading through the text for the option. There's some room for improvement there given this experience.
<cooper__>
"[If you don't understand that thumb binaries are smaller but slower programs] saying y is a safe choice"
<Nyuutwo>
I'm not sure if always slower
<cooper__>
Doesn't quite have the same ring to it as "Random instabilities occur when set to n. Don't flip unless you're willing to accept the consequences"
<cooper__>
Nyuutwo: Indeed, atsampson suggested that aswell.
<cooper__>
The statement came from the gcc developers mailing list as a general statement.
<Nyuutwo>
smaller code means better cache usage
<cooper__>
In the sense of "if you build everything as thumb to reduce space requirements, your binaries end up slightly slower"
<cooper__>
I'm sure there are places where it does more good than harm.
<Turl>
doesn't it end up being a bit faster?
<Turl>
because more of your binary fits on cache
<atsampson>
can do, yes -- although more so on older/smaller ARM chips...
<ssvb>
for example, Qualcomm Krait has troubles decoding 3 instructions per cycle in Thumb2 mode
<ssvb>
yes, the code in ARM mode is generally a bit faster
<cooper__>
This was a test I did with ffmpeg on my Odroid-U2 (A9) with 3 different compilers: http://forum.odroid.com/viewtopic.php?p=11838#p11838 End result was about 3% performance difference in favor of ARM.
gianMOD has joined #linux-sunxi
rz2k has joined #linux-sunxi
<ssvb>
on the other hand, huge binaries without clearly isolated performance hot spots may load and run faster in Thumb2 mode
<ssvb>
things like browsers
<cooper__>
The point with the U2 was that is was damned close for a lot of people to get smooth playback with most of their videos. The general consensus there seemed to be that with just a bit more optimisation, it would be flawless (at the time).
<cooper__>
So a lot of talk was about how to best configure mplayer to squeeze the most out of it, with a lot of heated debates about the virtues of which compiler options.
<Turl>
you'll get more performance out of neon than arm vs thumb :p
<ssvb>
well, also disabling autovectorization could have helped too
<cooper__>
I figured, since unlike everybody else there I was sporting a Gentoo install, I was in a good position to test the various compiler options and see if there was any truth to the madness.
bonbons has quit [Quit: Leaving]
<cooper__>
Turl: Absolutely.
<cooper__>
Anybody know what the "Dummy virtual machine" option is within the "System type" section of 'make menuconfig'?
<ssvb>
by default you get autovectorization as an extra payload with -O3, and it typically degrades performance on properly written code
<ssvb>
Cooper__: are you trying to find more kernel options to disable and shoot your (remaining) foot too? ;-)
<cooper__>
ssvb: More like wondering what else I turned off too much.
toddinpal has joined #linux-sunxi
iamfrankenstein has joined #linux-sunxi
<toddinpal>
OK, so I'm a newbie to linux-sunxi. I'm trying to figure out why the kernels for this chip are so old. It seems as 3.4 is the recommended kernel, which is a nearly 3 years old at this point in time.
rz2k has quit []
<cooper__>
toddinpal: Think of it more as a 3.4 LTS release. It's been patched left and right considerably during those 3 years.
<Nyuutwo>
toddinpal: it is hacked by Allwiner and then hacked to make it work better which supports most features of chps
<cooper__>
toddinpal: Also, you can run mainline on it if you choose to. It just takes a bit of work.
<ssvb>
toddinpal: because the old kernels still exist, but newer kernels exist too
naobsd has joined #linux-sunxi
<toddinpal>
Well what I'm looking for is relatively current support for btrfs
<atsampson>
Nyuutwo: the impression I get from the btrfs mailing list is that it's reasonably solid provided you aren't doing anything fancy (e.g. RAID5) with it
<toddinpal>
lol, of course, which is what I want to do, raid5... or mdraid style support of raid10, which btrfs doesn't yet suport
<toddinpal>
Thanks ssvb, I'll look at the mainline kernel howto
<Nyuutwo>
is it possible to use mainline for tablet as low-end linux desktop?
<Nyuutwo>
I know that there is only basic framebuffer
<ssvb>
Nyuutwo: it depends, you would want to connect a keyboard, a mouse and maybe also a usb ethernet dongle to it (unless fully relying on wifi)
<ssvb>
Nyuutwo: if you have a USB HOST port, then this is possible
<ssvb>
that's an open source reverse engineered implementation
<rpirea>
ssvb but media-codec provides something important for libvdpau-sunxi ?
<ssvb>
the proprietary media-codec works standalone, supports video encoding and a bit more formats
Zotan has joined #linux-sunxi
<rpirea>
ssvb ok tnx
rpirea has quit [Quit: Leaving]
gianMOD has quit [Remote host closed the connection]
FreezingCold has quit [Ping timeout: 252 seconds]
FreezingCold has joined #linux-sunxi
<toddinpal>
ok, so I'm totally out of my element here. I'm trying to set up a Banana Pi to use a root file system using btrfs. Any ideas how to start? I'm currently using Bananian 15.01 which uses a 3.19 kernel. But when I switch the uEnv.txt rootfs to a device containing a btrfs, I can't boot.
gianMOD has joined #linux-sunxi
<ssvb>
Nyuutwo: the page had a reference to the mainline u-boot, but now I have added a really big warning header on top
<atsampson>
toddinpal: can you see the kernel messages on boot? it'll print some status messages while it's trying to mount the root filesystem
<atsampson>
it might be that they've only built btrfs as a module (and there isn't an initrd)