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
TheSeven has quit [Ping timeout: 250 seconds]
TheSeven has joined #linux-sunxi
<apritzel> oh hacky days ...
* apritzel convinced sunxi-fel to load a 32-bit SPL alongside a 64-bit U-Boot (plus a 64-bit ATF) on the Pine64
<apritzel> using a "magic" ARM/AArch64 switch ;-)
<apritzel> AArch64: "tst x0, x0" is "b #0x84" in ARM
<apritzel> the first is almost-a-NOP in AArch64, but branches away if executed in AArch32
<apritzel> so sunxi-fel starts the 64-bit U-Boot in 32-bit mode, but this one detects this and does the RMR switch to 64-bit (into ATF)
apritzel has quit [Ping timeout: 244 seconds]
<willmore> Magic!
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
andoma has quit [Ping timeout: 260 seconds]
andoma has joined #linux-sunxi
ninolein has quit [Ping timeout: 260 seconds]
ninolein_ has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
luoyi has joined #linux-sunxi
staplr has quit [Ping timeout: 264 seconds]
glass has joined #linux-sunxi
glass has quit [Quit: Leaving]
book` has quit [Quit: Leaving]
book` has joined #linux-sunxi
<luoyi> wens: does it possible merge the i2s device tree patch to the mainline in 4.7? I've created a patch as: https://github.com/luoyi/Sunxi-A20-Audio-Driver/commit/1402e7b565f910c287266c0e0a59267704302d5d
reev has joined #linux-sunxi
Branson2k has quit [Remote host closed the connection]
p1u3sch1 has quit [Ping timeout: 246 seconds]
p1u3sch1 has joined #linux-sunxi
<wens> luoyi: normally they are submitted together with the driver and the bindings
<wens> the dt changes depend on the bindings, which normally come with the driver
<wens> and you need all three for a thorough review and test
<luoyi> wens: I've created a new repo to split the driver code patch. commit log is : https://github.com/luoyi/Sunxi-A20-Audio-Driver/commits/master
<luoyi> so can we combine this driver and the device tree patch togother to merge into the mainline ?
<wens> yes, and someone should :)
iamfrankenstein has quit [Quit: iamfrankenstein]
cnxsoft1 has joined #linux-sunxi
cnxsoft has quit [Ping timeout: 250 seconds]
cnxsoft1 is now known as cnxsoft
iamfrankenstein has joined #linux-sunxi
luoyi has quit [Ping timeout: 250 seconds]
p1u3sch1 has quit [Ping timeout: 260 seconds]
p1u3sch1 has joined #linux-sunxi
leio has joined #linux-sunxi
IgorPec has joined #linux-sunxi
engideavr has joined #linux-sunxi
reev has quit [Read error: Connection reset by peer]
reev has joined #linux-sunxi
reev has quit [Ping timeout: 260 seconds]
<wens> seems like it was the opi cases that were sold out
engideavr has quit [Quit: Konversation terminated!]
zuikis has joined #linux-sunxi
engideavr has joined #linux-sunxi
zuikis has left #linux-sunxi [#linux-sunxi]
reev has joined #linux-sunxi
reev has quit [Read error: Connection reset by peer]
JohnDoe_71Rus has joined #linux-sunxi
luoyi has joined #linux-sunxi
<luoyi> wens: you mean for now, all things I need to do is just wait for *someone* to merge these patches ?
<plaes> luoyi: no, you need to submit them to mailinglist
<plaes> ..for review
IgorPec has quit [Ping timeout: 272 seconds]
JohnDoe_71Rus has quit [Read error: Connection reset by peer]
reev has joined #linux-sunxi
reev has quit [Max SendQ exceeded]
<wens> if you have time to pick up the work, then submitting them yourself is probably the quickest way
reev has joined #linux-sunxi
<luoyi> OK. which mailinglist is prefer ?
<luoyi> linux-sunxi@googlegroups.com is the right place ?
<wens> nope
<wens> use scripts/get_maintainers.pl to figure out who to send the patches to
<wens> and i mean the whole driver and dt changes, not just your fixes
<wens> also read Documentation/SubmittingPatches
JohnDoe_71Rus has joined #linux-sunxi
yann|work has quit [Ping timeout: 260 seconds]
codekipper has joined #linux-sunxi
p1u3sch1 has quit [Ping timeout: 260 seconds]
p1u3sch1 has joined #linux-sunxi
<codekipper> luoyi: I was looking at starting pushing of the i2s patches very soon....if you wanna take the helm then it would be wise to work from a kernel repo
reinforce has joined #linux-sunxi
<luoyi> codekipper: glad to see you
<luoyi> codekipper: I'm not familiar with such process, so I think maybe you submit the patch is a good idea :-)
<codekipper> the patches you're pushing are meaningless to me but welcome to the i2s playback club
<codekipper> check out the kernel documentation and also links in the wiki
<codekipper> you can also look at the history of my pushing of the spdif patches
<luoyi> I should start with linux-sunxi master branch or linus master branch ?
<codekipper> thing is I only know of one commercially available device with i2s so it's unlikely that we'll be pushing anything into the dts.
<luoyi> codekipper: there are many DAC with i2s interface
<codekipper> I would work with linux-next...others work from the latest rc tag
<codekipper> yeah but none of them are sold with sunxi products
<codekipper> I've just got delivery of a PCM5102 device so I'll test that as soon as I can
<codekipper> just got a lot going on outside of hacking to speed this process up.
<luoyi> you mean we can't commit simple-card section into the repo ?
<wens> luoyi: we don't enable anything that's not integrated on the board or in the device
<codekipper> you can have it in your repo by all means but I doubt that it's something that can be pushed to mainline
<wens> luoyi: so for an add-on card, maybe not
<wens> codekipper: i was thinking of getting one of those rasbperry pi dacs, and hook it up w/ short wires
<luoyi> ok. so the spdif is ok. because the spdif interface is integrated in the chip. but pcm510x simple-card is not
<codekipper> that's what I've just bought....
<codekipper> spdif optical connector appears on quite a few products.....
<codekipper> i2s output is only available on one product that I know of
<luoyi> codekipper: ok. now I know the point. but looks like the spdif can't work correctly with the mainline kernle now. because of the mod1 clock bug.
<wens> codekipper: is there a driver for pcm510x? i only see pcm512x.c
<luoyi> codekipper: the bananapi m1+ is a good choice .
<codekipper> there is in my repo!
reev has quit [Remote host closed the connection]
wazzup has quit [Remote host closed the connection]
<codekipper> but it's just a simple codec
<codekipper> it's probably also in the raspberry pi repo
<codekipper> luoyi: I have different repos for different things....for example upstreaming a put my patches ontop of linux-next whereas general hacking I commit ontop of hans sunxi-wip branch
<luoyi> codekipper: your 5102 DAC is looks like this ? http://imgur.com/1LY2S3L
<luoyi> I've used this DAC with my driver for about 2 days. hears very good.
reev has joined #linux-sunxi
<luoyi> A20's audio quality maybe better then rpi
<codekipper> but first things first I would cherry-pick the missing patches from hans sunxi-wip branch...
<codekipper> we also shouldn't forget maxime's for_next branch which is patches which have been applied and are awaiting to be merged into mainline
<codekipper> this is my DAC(although could be a cheap chinese copy) http://www.geekroo.com/1034
<codekipper> I also have a couple of UDA1380's
IgorPec has joined #linux-sunxi
<luoyi> codekipper: so your plan is test the driver with your new 5102 dac, and if ok, we can send it to sunxi-wip branch ?
<luoyi> these repo confuse me now ....
<wens> codekipper: i was a bit unsure about the uda13xx, but it seems there's a mainline driver for it
<codekipper> wip is work in progress so I test a develop ontop of this. But this isn't a good place to be delivering stuff from(especially dtsi changes)...
<luoyi> the rpi's method to support these DAC is dt-overlay, does sunxi kernel have any plan to support dt overlay ?
<luoyi> so we can put the simple-card section just in a overlay file
<codekipper> I usually dev on sunxi-wip then when happy cherry pick the changes I need onto linux-next (fix any conflicts) and then push
<wens> luoyi: there definitely will be, as the CHIP is depending on it
<wens> you can also base stuff on sunxi-next, i typically merge anything sunxi related in
<codekipper> wens: yep...uda1380 has been in mainline for a while
<codekipper> wens: overlays has been mention quite a bit recently...is anybody working on it
<codekipper> nope 2secs
tkaiser has joined #linux-sunxi
<codekipper> luoyi: ignore that......like a said we all have our ways of working!
<wens> luoyi: yes
<wens> sunxi-next is a subset of linux-next
<wens> basically me, mripard or hans will look out for drivers that have been merged for -next, and we merge the maintainer's -next tree into sunxi-next
<wens> that will also include mripard's sunxi/for-next, which is mostly sunxi DT or clock patches
<luoyi> codekipper: why pinctrl-0 = <&i2s0_bclk> , <&i2s0_lrclk> , <&i2s0_sdo0>; doesn't contain mclk ?
<luoyi> does this disable the mclk output ?
<wens> codekipper: kind of want to go with PiFi DAC+ 2.0, but can't seem to find a vendor page :(
massi_ has joined #linux-sunxi
<luoyi> wens: you can send your address to me. I can send you some DACs through international mail package
<tkaiser> jrg: In case you're dealing with BPi-M3 and any of the crappy SinoVoip OS images please keep in mind that they try to provide images that boot on Raspberry Pi, BPi M2, M2+ and M3. So on the 1st FAT partition there's a lot of stuff and for M3 you have to look below bananapi/bpi-m3/linux/ (uEnv.txt and script.bin)
yann|work has joined #linux-sunxi
<luoyi> changed the pcm5102 to a tda1543 one. and still hear ok
<wens> too bad the *pi headers aren't truely rpi compatible
<wens> the i2s pins are off
<luoyi> rpi's i2s doesn't have mclk output
<luoyi> and only left-justified support
<luoyi> wens: which board are you using now ?
<wens> i have a whole collection of boards, but for this particular test i will probably have to use one of the cubies
<wens> i don't have a bpi m1 (+) atm, but i will ask for one
<plaes> cubie has 2mm pin header
<wens> plaes: yeah, which is a bit problematic, as i cannot get pre-made wires
<plaes> I actually managed to find 2mm -> 2.54mm
IgorPec has quit [Ping timeout: 244 seconds]
<wens> i can get ones that have either 2mm or 2.54mm on one end, but i have to crimp the other end myself
<wens> didn't find ones pre-made :(
<wens> ships from HK, does not ship to taiwan lol
<plaes> wat? :D
<plaes> anyway, these exist :)
<wens> good to know
<wens> i should dig harder at the local hardware store
<JohnDoe_71Rus> you can grab old pc case, wire to front pannel
<wens> i don't have room for a pc case though :(
<codekipper> luoyi: it worked without mclk
<codekipper> I'm trying to i2s capture working but don't see anyting coming off the codec
<codekipper> may get one of those knowles i2s mics to simplify my capture setup
reev has quit [Read error: Connection reset by peer]
<luoyi> codekipper: some codec need mclk input, some doesn't
<luoyi> with i2s capture you will need ADC but ont DAC
<codekipper> uda1380 has mic and line in
<luoyi> my UDA1380 boards have line in on it, how about yours ?
<luoyi> does yours board alsa the waveshare's brand ?
<codekipper> yep
<luoyi> I haven't tried it yet
<luoyi> do you just plug a mic in the line in port of the board ?
<codekipper> I'll update my github with my current dev branch if you wanna have a play
<codekipper> there is a mic onboard
<codekipper> plans was to plug radio into it
<luoyi> radio ?
<codekipper> could be a mux issue...but looking on scope no activity on i2s out
<luoyi> you want to record the FM radio ?
<codekipper> radio -> line in -> i2s input
<codekipper> just want some NOOIIISSEEEE
<luoyi> there are a mic on the board . no need with line in
<wens> is that the one from waveshare?
<luoyi> codekipper: you mean the mic on this board doesn't send any signal ?
<codekipper> I don't know....looking on my scope I've yet to see any pulses coming from the codec
<luoyi> codekipper: you've done the uda1380 register setting ?
<codekipper> It's from mainline so should be well tested.....I did put together a patch to read the registers back but I don't think I've tested it yet
<codekipper> I sort of more interested in seeing if I can get i2s working on the H3...think everything is now in place to get it to work
<tkaiser> codekipper: You're talking about mainline kernel, I2S and H3?
<codekipper> tkaiser: I only work with mainline....with the dma patches now in I think we've enough to test with
reev has joined #linux-sunxi
reev has quit [Max SendQ exceeded]
reev has joined #linux-sunxi
<tkaiser> codekipper: Ok, I just remembered that someone posted a tutorial in H3 Armbian forum regarding I2S with BSP kernel. And there only a few tweaks were needed to remove SPI from GPIO pins und use I2S instead
<codekipper> yeah...I guess the board is set up for spi on the header....
<codekipper> with mainline I don't think any of the header pins are configured....
<tkaiser> codekipper: Yes, but in fex file most of the pin mappings try to be compatible to RPi header definition (not true for everything)
<codekipper> this will only be my test platform....if anything I'll be posting just changes to the h3 dtsi
IgorPec has joined #linux-sunxi
apritzel has joined #linux-sunxi
vagrantc has quit [Quit: leaving]
Mr__Anderson has joined #linux-sunxi
ricardocrudo has joined #linux-sunxi
caog has joined #linux-sunxi
caog has quit [Client Quit]
caog has joined #linux-sunxi
<Amit_T> apritzel: Hello, are you able to load ATF+U-BOOT from EFL on pine64, right ?
<apritzel> Amit_T: yes, but it's a bit hacky
<Amit_T> apritzel: I am ready to try as long as My board is safe :)
<apritzel> because I compile U-Boot twice, once with CPU_V7 (32-bit) to get sunxi-spl.bin and once with ARM64 to get the main U-Boot binary
<Amit_T> ok, is it documented anywhere ?
<apritzel> so you need two patches for (upstream) U-Boot: the first one to enable SPL (which also switches the port to 32-bit), and the second one to do the RMR switch
<apritzel> Amit_T: no, not yet, and I only have the patches at home
<apritzel> I just managed to do it and then went to bed ;-)
<Amit_T> too hackyy then :P
<Amit_T> apritzel: One doubt , did you make changes in FEL source ?
<apritzel> no
<apritzel> also ATF is unchanged
caog has left #linux-sunxi ["Ex-Chat"]
<apritzel> one could change the FEL source to do the RMR switch and get rid of that one U-Boot patch then
<NiteHawk> apritzel: i'm all ears :)
matthias_bgg has joined #linux-sunxi
<apritzel> NiteHawk: either: sunxi-fel sees that the u-boot.img is an arm64 image, thus injects the RMR sequence to start in AArch64
<apritzel> or: we introduce a special "rmr" command in sunxi-fel which allows to specifiy the address to which the RMR switch branches
<NiteHawk> apritzel: may be safer to have an option for that? future SPLs/SoCs could do a 64-bit transition on their own, or even start completely as 64-bit without sunxi-fel intervening
<apritzel> the first one has two problems: a) currently U-Boot wraps an arm64 U-boot build in an _32bit_ U-Boot image (the architecture flag is set to arm, not aarch64)
The_Loko has joined #linux-sunxi
<apritzel> b) we need to enter ATF in 64-bit, not U-Boot
<apritzel> so yes: I am more for the option
<NiteHawk> "rmr" command sounds suitable
<apritzel> NiteHawk: so something like: sunxi-fel uboot u-boot-with-spl.bin write 40080000 kernel rmr 44000 bl31.bin
<apritzel> maybe spl instead of uboot as the first command, not sure about that
<apritzel> so that would mean: load and execute the SPL, load the kernel, load ATF (bl31.bin) and execute that in 64-bit (with the RMR switch)
<NiteHawk> yes, spl should do - "uboot" would just request to start it (execute the entry address) - that's pointless with rmr
<apritzel> NiteHawk: does that make sense?
<apritzel> NiteHawk: I am still a noob with sunxi-fel, just looked at the code yesterday ...
<NiteHawk> apritzel: yes, it makes sense. maybe we split the bl32 transfer into "write" and "rmr"... does the ATF go to address 0x44000 (i.e. load address = rmr entry)?
<apritzel> NiteHawk: yes
<apritzel> at the moment I put the ATF in SRAM A2
<apritzel> could be SRAM C as well, but I had issues with that
<apritzel> and SRAM A2 is much easier with boot0
<NiteHawk> i'm aiming to keep maximum flexibility, so i'm thinking we might separate the "write" (upload operation) from "rmr <entry>"
<apritzel> NiteHawk: sure
<NiteHawk> let me know if you publish your RMR setup code / u-boot patch somewhere. i'm sure it can be integrated into fel.c without too much effort
<NiteHawk> for testing, i'd need both 32-bit and 64-bit toolchains right? (i'd use the latter "native" on the pine64)
<apritzel> NiteHawk: yes, that's the problem at the moment
<apritzel> NiteHawk: if you use Debian or Ubuntu, you should be able to just apt-get a cross toolchain
<apritzel> NiteHawk: the flesh of the RMR switch is here: https://github.com/apritzel/u-boot/commit/fda6bd1bf285c44f30ea15c7e6231bf53c31d4a8
<NiteHawk> not too much of an issue for me - i need 32-bit anyway for the A20 (have gentoo cross-compiler in place), and the A64 should be able to take care of itself (native gcc)
<apritzel> so the RMR switch is basically: you write the entry address to 0x017000A0, then set bit 0 and 1 in the RMR system register
<NiteHawk> nice, thx. i think i'll need some time to setup my rig properly and have a look at that - will give it a try tonight
cnxsoft has quit [Remote host closed the connection]
cnxsoft has joined #linux-sunxi
ricardocrudo has quit [Remote host closed the connection]
ricardocrudo has joined #linux-sunxi
tkaiser has quit [Quit: jIRCii - http://www.oldschoolirc.com]
Worf has joined #linux-sunxi
<mripard> codekipper: I can take care of it
<mripard> I just have to get this thing running here
<mripard> It's driving me nuts
<codekipper> mripard: OK...there are a few patches I think you need to squash into it first but it's pretty much good to go.
<mripard> yes, I've seen your branch
<mripard> but even your branch doesn't work on my side
<codekipper> can you post a photo of your setup?
Worf has quit [Quit: Konversation terminated!]
<mripard> yes
<mripard> but it's probably not going to help, I'm having a different board than you do
<wens> codekipper: i see you have some a31 audio bits in your tree?
<codekipper> I'll look up where they're going
<wens> i did a comparison of some clock bits over the weekend, and they are different
<codekipper> wens: yeah...I've playing with my I7...not singing yet but close I think
<mripard> codekipper: schematics are here http://wiki.in-circuit.de/images/0/04/610000286A.pdf
<wens> codekipper: the pll2 bit fields are different
<codekipper> but that would only affect playback speed
<mripard> codekipper: I just sent it to your gmail account
<codekipper> merci
<wens> mripard: on the topic about clocks, are we going to add the video/audio clocks for the old socs?
<codekipper> is that a mars board?
<codekipper> and how does your dts look?
<mripard> wens: I don't know :/
<mripard> it's something i wanted to discuss with you actually
<mripard> I don't really want to merge new drivers now
<mripard> but I don't want to slow development down by waiting on something we probably won't enable on all SoCs before a few releases
<mripard> I guess we have two cases
<mripard> the first one is that we just enable a new clock that already has a driver
<mripard> and I don't really see what could be wrong with that
<mripard> the second, and more problematic, would be to enable a clock that doesn't have a driver yet
<mripard> and we basically have two solutions here
<mripard> either we refuse any new driver
<mripard> or we start using the new infrastructure for the new clocks
<mripard> I actually did it that way to do the bring up on the H3
<mripard> you start replacing gradually clocks by the new framework
<mripard> and I haven't experienced anything weird
<mripard> I think I'd prefer the second option
<mripard> but I don't know your feeling about it
<mripard> codekipper: it's an in-circuit ICnova
<codekipper> yeah..just seen it on the wiki
<mripard> I'm pasting you the DT
<KotCzarny> enable new clocks but add /sys node to disable them?
<mripard> KotCzarny: clocks are initialised way before you have userspace, or even /sys
<KotCzarny> is there any negative impact of enabling them? (apart from power drain)
<codekipper> mripard: looking at the schematic the pins you require are 18-20(I2SO0, LRCK, BCK) whereas you're plugged into 21-23 http://wiki.in-circuit.de/images/0/04/610000286A.pdf
<codekipper> dt looks correct
<mripard> KotCzarny: the issue is not really about enabling them
<mripard> but more about computing and applying proper rates and parents
<mripard> codekipper: did I?
<mripard> damn.
<mripard> I've rechecked like a hundred times
<mripard> I have to leave, I'll check when I'll be back
staplr has joined #linux-sunxi
<wens> mripard: seeing as we have of_io_request_and_map with some of the new drivers, it's unlikely we can have both at the same time
<wens> yup, simple-gates, mod0, mod1, display, video, audio...
reinforce has quit [Quit: Leaving.]
<wens> i guess we could use of_iomap for the new framework, then switch to of_io_request_and_map after all the clocks have been converted
reinforce has joined #linux-sunxi
staplr has quit [Remote host closed the connection]
<luoyi> codekipper: mainline uda1380 driver only support 16bit/48KHz. but the datasheet says that the chip can run up to 24Bit/96Khz
<codekipper> yeah..that change should be in my branch...I've tested 24bit/96K
<luoyi> the playback work well ?
<codekipper> seemed ok but I was playing through a shitty speaker. However, fixed the setup for a client who was very happy with the results at 192Khz
fl_0 has quit [Ping timeout: 260 seconds]
<luoyi> does playback use the tx group ? and i2c is empty ?
<luoyi> I just connect the txmclk txbclk .. hear no sound
<MoeIcenowy> wens: I want to try porting the SDK driver of soundcodec of A33
<MoeIcenowy> to mainline
IgorPec has quit [Ping timeout: 264 seconds]
The_Loko has quit [Quit: Leaving]
<wens> MoeIcenowy: the whole thing? or the analog bits?
<wens> the digital part is an i2s block
<luoyi> codekipper: after I connect the sda/scl, the kernel stoped at: [ 3.350258] cpufreq: cpufreq_online: CPU0: Running at unlisted freq: 384000 KHz [ 3.363193] cpufreq: cpufreq_online: CPU0: Unlisted initial frequency changed to: 528000 KHz [ 3.381397] Unable to handle kernel NULL pointer dereference at virtual address 00000004
<codekipper> http://imgur.com/nyqyrxK for my setup
<codekipper> you don't have to bother with the blue cable for mclk or grey cable on the header
<luoyi> your setup is for capture ?
<codekipper> luoyi: no proper logs then it never happened!
<codekipper> no for playback...capture just adds one cable for i2s tx
<MoeIcenowy> wens: maybe the whole
IgorPec has joined #linux-sunxi
<luoyi> codekipper: where is your uda1380's driver code?
<luoyi> the mainline uda1380 driver doesn't have the device tree support
<codekipper> I'll update my work branch soon....just a bit busy with other things at the moment
<codekipper> been rebasing when I can but haven't switch on a device in a few weeks.
<luoyi> still no sound
<codekipper> do you have a photo of your setup...is this capture or playback?
<luoyi> and modprobe uda1380
<MoeIcenowy> wens: oh... sound/soc/sunxi/audiocodec/sunxi_codec.c seems to be a audiocodec version of sound/soc/sunxi/i2s0/sunxi-i2s0.c
<luoyi> codekipper: my setup is for playback
<MoeIcenowy> and sunxi_codecdma.c seems to be like sunxi-i2s0dma.c
<wens> MoeIcenowy: yeah, and we are currently discussing i2s
<MoeIcenowy> wens: seems that sun8iw5_sndcodec.c is the codec-specified code
<MoeIcenowy> and sunxi_codec.c sunxi_codecdma.c is i2s code
<codekipper> you've not changed the cables on the Bpi header?
<codekipper> I thought it was Rpi compatible so was under the impression that bclk, sync were higher up
<codekipper> logs would really help
<luoyi> does uda1380 i2c address is i2c-1 0x18 ?
<codekipper> should be as in my evb dts
<luoyi> but the driver doesn't have device tree related things
<luoyi> [root@alarm uda1380]# grep 'nxp,uda1380' uda1380.c give empty result.
montjoie has quit [Ping timeout: 260 seconds]
montjoie has joined #linux-sunxi
reev has quit [Quit: Leaving]
<wens> luoyi: just adding a node with "nxp,uda1380" and the right address might work
<wens> the i2c core seems to do some magic
akaizen has joined #linux-sunxi
<codekipper> luoyi: can you post your dts?...are the i2c pins available to be used?
<mripard> wens: that's why I had of_iomap in the v1 of my patches
<mripard> wens: it's going to be moved away from the common function though
<luoyi> &i2s0 { pinctrl-names = "default"; pinctrl-0 = <&i2s0_bclk> , <&i2s0_lrclk> , <&i2s0_sdo0>; status = "okay"; };
<luoyi> does this need mclk ?
<mripard> wens: so we can have that for older SoCs that we slowly convert
<mripard> and when it's done, switch to of_io_request_and_map
<wens> ah, i see
<luoyi> codekipper: http://pastebin.com/LZVBin7E
wigyori has quit [Remote host closed the connection]
<codekipper> luoyi: are those i2c pins on the header i2c2 not i2c1?
<wens> codekipper: that platform data gpio handling seems wrong
wigyori has joined #linux-sunxi
JohnDoe_71Rus has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
<Amit_T> montjoie: Thanks for the comments but I am bit confused do you want to have mmio region upto 10000 or I should cut it down ?
libv_ has joined #linux-sunxi
<wens> Amit_T: i would cut it down to perhaps 0x2000
<wens> iirc the register set is repeated once, but after that there's nothing
libv has quit [Ping timeout: 276 seconds]
<Amit_T> wens: ok , Thanks. in kernel it uses 1054 , right ?
libv has joined #linux-sunxi
<montjoie> Amit_T: my first comment on too big was due to wens already said that to me:)
<wens> the register sets are not nearly the size of the range seen in the memory map
libv_ has quit [Ping timeout: 276 seconds]
<Amit_T> ok, got it.
libv_ has joined #linux-sunxi
libv has quit [Ping timeout: 244 seconds]
libv_ has quit [Ping timeout: 244 seconds]
libv has joined #linux-sunxi
libv has quit [Ping timeout: 260 seconds]
paulk-collins has joined #linux-sunxi
cnxsoft has quit [Remote host closed the connection]
jrg has quit [Quit: ZNC - http://znc.in]
jrg has joined #linux-sunxi
nove has joined #linux-sunxi
reinforce has quit [Quit: Leaving.]
libv has joined #linux-sunxi
cosm has joined #linux-sunxi
<wens> mripard: i think i've gone through all the bits of the new clock framework
<wens> the h3 bits are going to take a bit more time
IgorPec has quit [Ping timeout: 244 seconds]
yann|work has quit [Remote host closed the connection]
libv_ has joined #linux-sunxi
libv has quit [Ping timeout: 240 seconds]
libv has joined #linux-sunxi
avph has quit [Ping timeout: 260 seconds]
bmeneg has joined #linux-sunxi
libv_ has quit [Ping timeout: 244 seconds]
JohnDoe_71Rus has joined #linux-sunxi
JohnDoe9 has joined #linux-sunxi
avph has joined #linux-sunxi
<bmeneg> hello everyone, I would like to know if is there any default value of gpios on expansion pad to the old kernel version (3.x).
<bmeneg> I am using cubietruck with kernel v3.49 and a bootloader which passes hardware info through .fex file.
<bmeneg> mainline kernel supports a specific formula, but on old version kernels it's purely dependent from .fex file, right?
IgorPec111116 has joined #linux-sunxi
IgorPec111117 has joined #linux-sunxi
IgorPec111116 has quit [Ping timeout: 252 seconds]
<mripard> codekipper: you were right with the pins :/
<mripard> stupid me
jernej has joined #linux-sunxi
codekipper_ has joined #linux-sunxi
<codekipper_> mripard: so do we have audio yet?
<mripard> no
<codekipper_> don't worry your secret is safe with me
<mripard> it would have been too easy :)
<mripard> yeah
<mripard> my secret is safe on internet ;)
<codekipper_> do you have a way of looking at the signals?
<mripard> not here
<mripard> I checked the muxing and it's ok
<mripard> I sometimes have some noise out of the headphone
<mripard> so I'm guessing the codec is ok
<mripard> and the issue lies somewhere in the i2s driver / signals
reinforce has joined #linux-sunxi
<codekipper_> do you have any logs you can dump somewhere?
<mripard> yep, 2s
codekipper_ has quit [Ping timeout: 250 seconds]
IgorPec has joined #linux-sunxi
codekipper_ has joined #linux-sunxi
<codekipper_> mripard: looks ok...I would play with alsamixer....I've not worked out the correct settings at startup for playback
IgorPec has quit [Ping timeout: 276 seconds]
IgorPec111117 has quit [Ping timeout: 252 seconds]
<codekipper_> I just go along the playback settings and adjust them (obvious things that shouldn't be changed I change back to the original setting)
zuikis has joined #linux-sunxi
<mripard> I tried, but I couldn't really find a combination that was working
<mripard> which board have you used with the PCM5122 codec, the PiFi DAC+
<mripard> ?
Shirasaka-Hazumi has quit [Ping timeout: 276 seconds]
Shirasaka-Hazumi has joined #linux-sunxi
engideavr has quit [Quit: Konversation terminated!]
<codekipper_> mripard: I've got a chinese copy of this board http://www.geekroo.com/1034
<codekipper_> on the board it's called PIFI DAC V1.0
<codekipper_> it has a PCM5102A on board(well I think it has..can't find magnifying glass to confirm)
<codekipper_> confirmed it is a pcm5102A
IgorPec111117 has joined #linux-sunxi
jukivili has joined #linux-sunxi
<mripard> ok, I don't have the same one
<mripard> I have this one http://code.bulix.org/qn0kwo-99154?raw
<mripard> grmbl
<mripard> not that link
<mripard> this one
Mr__Anderson has quit [Remote host closed the connection]
<codekipper_> ok...that's i2s + i2c...so there's drivers that need to be enabled(it's supported by mainline)
<codekipper_> I would just copy the settings from the raspberry pi github...they should support this device
<mripard> yeah, I just checked, there's a driver for that codec
<mripard> how did you wire yours ?
<codekipper_> i'm in the process of moving so I've not had the time to start any new setups
<codekipper_> but it should be fairly straight fwd...same as uda1380
<mripard> ok
pekka10 has joined #linux-sunxi
IgorPec111118 has joined #linux-sunxi
IgorPec111117 has quit [Ping timeout: 260 seconds]
akaizen has quit [Remote host closed the connection]
vagrantc has joined #linux-sunxi
libv_ has joined #linux-sunxi
libv has quit [Ping timeout: 246 seconds]
staplr has joined #linux-sunxi
Netlynx has joined #linux-sunxi
libv has joined #linux-sunxi
libv_ has quit [Ping timeout: 252 seconds]
apritzel has quit [Ping timeout: 244 seconds]
libv_ has joined #linux-sunxi
libv has quit [Ping timeout: 264 seconds]
libv_ has quit [Ping timeout: 264 seconds]
ricardocrudo has quit [Remote host closed the connection]
libv has joined #linux-sunxi
libv has quit [Ping timeout: 272 seconds]
mnr has joined #linux-sunxi
matthias_bgg has quit [Ping timeout: 244 seconds]
IgorPec has joined #linux-sunxi
IgorPec111118 has quit [Ping timeout: 264 seconds]
libv has joined #linux-sunxi
fl_0 has joined #linux-sunxi
Amit_T has quit [Ping timeout: 260 seconds]
cosm_ has joined #linux-sunxi
akaizen has joined #linux-sunxi
massi_ has quit [Remote host closed the connection]
Nacho_ has quit [Ping timeout: 260 seconds]
Nacho has joined #linux-sunxi
codekipper_ has quit [Ping timeout: 250 seconds]
Netlynx has quit [Quit: Leaving]
akaizen has quit [Remote host closed the connection]
avph has quit [Ping timeout: 260 seconds]
avph has joined #linux-sunxi
willmore has quit [Ping timeout: 240 seconds]
willmore has joined #linux-sunxi
JohnDoe7 has joined #linux-sunxi
JohnDoe_71Rus has quit [Ping timeout: 272 seconds]
susan33 has joined #linux-sunxi
<susan33> hi, is it the good channel for the odroid xu4 kernel ?
apritzel has joined #linux-sunxi
<KotCzarny> does it use allwinner soc ?
<susan33> i have a xu4 and i'm building a self distribution. I use the kernel from https://github.com/hardkernel/linux. the xu3-3.10 works well and include the drivers/gpu drivers. the xu4-4.2 works but seems to not include the gpu drivers. can somebody tell me if i'm wrong ? and if i want to use the xu4 with a framebuffer i'm blocked at kernel 3.10 ?
<susan33> KotCzarny, yes, allwinner soc.
<KotCzarny> then probably yeah
reinforce has quit [Quit: Leaving.]
<KotCzarny> which soc it uses?
<susan33> * Samsung Exynos5422 Cortex™-A15 2Ghz and Cortex™-A7 Octa core CPUs
<KotCzarny> um, samsung is part of allwinner now?
<KotCzarny> :>
<longsleep> susan33: odroids do not use allwinner soc, so this is fc :)
<susan33> ok
<susan33> so, same question about the pine64. i don't find a kernel with the framebuffer and opengl acceleration. Where can i found it please ?
<longsleep> does not exist
IgorPec has quit [Ping timeout: 260 seconds]
<susan33> longsleep, is there a good reason ? or something to do ?
<KotCzarny> reason being no one did it yet
<susan33> KotCzarny, sorry, pine64 and odroid have in common the mali gpu, not the soc
<longsleep> susan33: well thats a question for allwinner, they need to release the required software preferably as opensource, they have not - thus no support
<KotCzarny> if you just want to read about mali
<longsleep> susan33: if i rememer correctly i told you the same in february or something :)
<susan33> longsleep, yes, but at this time, i was completly a beginner and didn't understand all. now, i'm stil a beginner, but i manage to make my odroid card working
<susan33> so, i'm back on the pine64 to try to understand what was missing.
<longsleep> susan33: odroid situation is not much diffrent
zuikis has left #linux-sunxi [#linux-sunxi]
<susan33> for odroid, i found a (old) kernel proposed by hardkernel which has the mali kernel drivre
<longsleep> susan33: sure, Pine64 kernel has the mali kernel driver aswell
<susan33> for the pine64, somebody gave me this url in february : https://github.com/longsleep/linux-pine64
<longsleep> sure
<longsleep> thats the one
<susan33> but there is something i don't understand.
<KotCzarny> when you dont understand something, its about money
<susan33> in the odroid kernel, i think but i'm perhaps wrong, that the driver is in drivers/gpu
<susan33> in the pine64, i don't found it or something similar
<longsleep> mali kernel driver does not help you though, mali binary blobs for arm64 for mali 400 is no available and i will only tell something else when they have released something
<longsleep> susan33: its out of tree, see the modules director
<longsleep> y
<apritzel> btw:
<apritzel> I asked around
<apritzel> apparently the mali450 drivers could work for the mali400 as well
<apritzel> because the 450 is basically the 400 with more cores
<apritzel> so has anyone tried it?
<longsleep> apritzel: yeah - but i think ssvb said that the ones available for download are only for framebuffer and not for x11 or something
<longsleep> apritzel: but i have not tried it, so cant tell much more
<susan33> i would like to be on arm 32 bits. is it available for 32 bits ?
<susan33> anyway, i understand that your kernel has the mali drivers. and that i should be able to load the 32 bits 400 or 450 userland drivers for opengl. Am i definitively wrong ?
<longsleep> susan33: yes, that kernel is 64 bit
<longsleep> but honestly i have not much a clue or care about mali
<susan33> ok
<apritzel> susan33: it's a _really_ complex topic, there are many driver parts involved
<susan33> so the mali drivers are here because there are in the mainline kernel ?
<apritzel> susan33: what exactly do you refer to with "mali drivers"?
<susan33> apritzel, ok. but you advise me to give up ? (because i'm too beginner for example which would be a good answer)
<susan33> my aim is to have a framebuffer with opengl.
<susan33> i understand that there are 2 parts :
<susan33> kernel driver and userland binary drivers
<susan33> (and a sdk to compile)
<apritzel> please don't give, but you first need to understand the whole graphics stack
<apritzel> *give up*
<susan33> on the odroid xu4, i've the 3 components and things works
<susan33> but because people probably did some job so that it because easy to me and i don't see the difficuly.
<apritzel> but the odroid has a mali t628, right?
<apritzel> also it's a 32-bit SoC
<longsleep> susan33: yes, for the hardkernel odroid image they mostly have all the mali bits for that particular soc/board in place (mostly)
<susan33> so, i would like to be sure on the picture that the kernel has the green "Device Driver"
<apritzel> susan33: your best chance is to look for the Hikey board
<apritzel> this has A53 cores and Mali 450
<apritzel> I saw demos with 3D graphics
<apritzel> and AFAIK Linaro is pushing for that to be as OpenSource as possible
<apritzel> so if you find information about how Linaro set this up, it may give you a clue about what's left to do for the Pine64
<susan33> hehe, yet another board. however, somebody (i don't know who in fact) sent me a pine64 board (and someone else an odroid xu4 board)
<susan33> and i'm just trying to make them work for my distribution
<susan33> ah ok
<susan33> thanks
<apritzel> susan33: I don't mean you should get this board, just google for this
<susan33> apritzel, yes, ok, sorry, i didn't understand in a first time.
<apritzel> though the kernel may be different, the Hikey kernel is much closer to upstream than the Pine64 BSP kernel
<apritzel> and the close-to-mainline Pine64 does not even have a framebuffer yet :-(
<apritzel> though please feel free to be my guest here and fix that ;-)
JohnDoe7 has quit [Quit: KVIrc 4.9.2 Aria http://www.kvirc.net/]
<susan33> ;-)
<apritzel> and also feel free to complain to ARM and Allwinner about that situation
<susan33> and this is only the down part.
<susan33> just imagine that the mali gpu are a hell
<susan33> i've to patch application to do some ioctl on /dev/fb0 so that they work... crappy mali too.
<apritzel> I think the Mali400 series is the cheapest you can get ... and you get what you pay for
<susan33> in the link http://linux-sunxi.org/Mali_binary_driver : what it mean then that they support fbdev ?
<apritzel> my understanding is that it works without X11 - so you can write an application that runs directly on the framebuffer and can have 3D graphics there
<apritzel> which is probably OK for some embedded applications, but not for a general Linux use case
<apritzel> and if I got longsleep correctly, the 64-bit Mali450 blob is only for fbdev :-(
The_Loko has joined #linux-sunxi
mnr has quit [Quit: leaving]
Nyuutwo has quit [Ping timeout: 240 seconds]
Nyuutwo has joined #linux-sunxi
<susan33> apritzel, thus, this is exatly what i want. i want a 32bit linux framebuffer.
<susan33> no x11 server
<apritzel> why 32-bit?
<susan33> because my distribution is about emulator which have a lot of troubles in 64 bits
<apritzel> because the code base is not 64-bit safe?
<apritzel> well, you can always run a legacy 32-bit ARM binary on any 64-bit kernel run
<susan33> i don't know. people of the team said me that on rpi3 64 bit, some fails, so to keep on 32 bits for the moment.
<apritzel> but that's a general rpi3 problem (booting in 64-bit is a bit more involved)
Nyuutwo has quit [Ping timeout: 240 seconds]
<apritzel> also there is no official Raspi-kernel for 64-bit, AFAIK
<apritzel> so if the emulators are Open Source and used to run on commodity PC hardware, chances are that recompiling them for arm64 should work
<susan33> yes possibly. i agree. However, you told me that binary are not available in 64 bits, so, i just said that 32 bits is not a problem to me.
<apritzel> well, no, there is 64-bit binary driver to the 450
<apritzel> (because of the HiKey board)
<apritzel> and I cannot find a 32-bit Mali400 driver there
<apritzel> I guess it's up to the SoC vendors to get them from ARM and ship them with the board
<willmore> The XU4 is handled over in #odroid, susan33.
<susan33> willmore, nice thanks. i will use it for my odroid questions ;-)
Nyuutwo has joined #linux-sunxi
<willmore> You're welcome. Friendly people here and there. :)
<apritzel> susan33: have you looked at what's in here yet? http://malideveloper.arm.com/resources/drivers/arm-mali-utgard-gpu-user-space-drivers/
<susan33> yes, that's is what i intend to use
<susan33> but because that point, i wanted to know if the mali kernel stack was there. it seem to be true. so i'll try that with the longsleep kernel.
Nyuutwo has quit [Ping timeout: 240 seconds]
paulk-collins has quit [Quit: Leaving]
nove has quit [Quit: nove]
Nyuutwo has joined #linux-sunxi
akaizen has joined #linux-sunxi
ajeandet has joined #linux-sunxi
ajeandet is now known as jeandet
susan33 has left #linux-sunxi ["Quitte"]
cosm_ has quit [Quit: Leaving]
jeandet has quit [Quit: jeandet]
Nyuutwo has quit [Ping timeout: 240 seconds]
<lennyraposo> aptritzel
<lennyraposo> and ssvb
<lennyraposo> news on the mali front from allwinner
Nyuutwo has joined #linux-sunxi
<lennyraposo> also longsleep
<lennyraposo> they are gonna test their implementation on the Debian Mate I put together
<lennyraposo> based on longsleep's kernel
dev1990 has joined #linux-sunxi
<apritzel> lennyraposo: so are they going to ship Linux X11 Mali userland blobs eventually?
<lennyraposo> yeppers
<lennyraposo> nope
<lennyraposo> noep to the question apritzel
<lennyraposo> yeppers was for someoen else
<lennyraposo> the nope is because it is unknown at this point
<lennyraposo> they are apparently working on a DMA Buf implementation
<lennyraposo> for Ubuntu/Debian
<apritzel> but what is that exercise for then?
<lennyraposo> once they are done I would imagine they will release it
<lennyraposo> as it is the only thing they haven't released thus far for the A64
<lennyraposo> binary wise
<apritzel> that's what I meant: so they will ship 64-bit Mali blobs?
<lennyraposo> the mali blobs
<lennyraposo> in the future yes
pitelpan has joined #linux-sunxi
<lennyraposo> as of now no as they are working on it
<lennyraposo> there has been a lot of back and forth regarding the subject
<lennyraposo> originally it wasw gonna be released with their BSP 2
<lennyraposo> but wasn't
<lennyraposo> then it became they need to start working on it
<lennyraposo> and now they are working on it
<lennyraposo> the moment I get the news on it myself or tllim from Pine64 is gonna post it
<apritzel> still this is going in the wrong direction
<apritzel> nobody should waste their time on that doomed BSP kernel
<lennyraposo> that's what they are testing against
<lennyraposo> this is coming from tllim at pine64
<lennyraposo> question apritzel as you are knowledgeable on the matter
<lennyraposo> they release the blobs
<lennyraposo> and their source for implementation
<lennyraposo> what woudl the difficulty be in providing it outside the BSP?
<apritzel> chances are that their kernel bits don't work anymore on an upstream kernel
The_Loko has quit [Remote host closed the connection]
<lennyraposo> let me get the rest of the back and forth
<lennyraposo> especially from allwinner's side
<lennyraposo> 1. UMP will not be support on A64 (ARM only support 32 but UMP and not 64 bit), this means cannot using UMP method to drive USER driver layer which is common implementation method in pass.
<lennyraposo> 2. Need to use dma_buffer method to implement USER layer and DRM driver.
<lennyraposo> 3. The KMS portion on the DRM driver related to display (DE, TCON, HDMI hardware related) needs Allwinner engineerign team to implement. The GEM portion coding can achieve by dma_buffer method, whcih is easy to accomplish.
<lennyraposo> 4. Allwinner will provide a interim solution, KMS portion using display driver and DE, TCON, and HDMI can become part of BSP parameter for KMS implementation.
<lennyraposo> 5. Allwinner will also privide DRM driver, same as using DE, TCON related BSP for KMS implementation. They are working on now and expected should be able to link up with Ubuntu upper layer driver on end of May.
<lennyraposo> 6. User layer driver implementation can reference at http://cgit.freedesktop.org/xorg/driver/xf86-video-armsoc/
<lennyraposo> make any sense apritzel?
<lennyraposo> be back in 5
<lennyraposo> back
<lennyraposo> from what I can decipher aprtizel it is for the BSP
<apritzel> lennyraposo: frankly: I have no clue what they are talking about ;-)
<apritzel> which doesn't mean that it doesn't make sense
<lennyraposo> I understand the removal of UMP
<apritzel> well, yes
<lennyraposo> not becaus eof the 32 bit ordeal but because it is an old implmentation
<apritzel> which is connected ;-)
<lennyraposo> it's wait and see what they release at this point
<lennyraposo> hopefully they will provide documentation
<lennyraposo> and the blobs provided for the mali can be used outsid eof the BSP stuff
<jrg> can someone tell me what's going on here? ...
<lennyraposo> encryption?
<jrg> that is a full one. eventually rm stops trying because it thinks the host is down
* jrg stares at arm based mount.cifs
<lennyraposo> what are you mounting anyways
Andy-D has quit [Ping timeout: 244 seconds]
dev1990 has quit [Quit: Konversation terminated!]
<jrg> a cifs/smb share from a freenas box
<jrg> some files i copy to the share will rm.. some won't with the above strace :/ i've been trying to figure it out for 2 days.. i just don't get it.
<jrg> seems to only happen on the bpi and rpi
<lennyraposo> I wanna say permissions
<lennyraposo> but it sound sliek you just have a simple share going out of the nas
<lennyraposo> it's just the removal that is causing issues
<jrg> yeah. that's what i thought too but i've tried everythign. i can create / rm files on the bpi tiself
<jrg> and some files i cp from a windows or osx box work.. and some don't. have no idea why
<lennyraposo> are they opened elsewhere on the network
<jrg> i thought maybe an oplock issue but i disabled oplocks and it still does it.. i'm at a loss
<lennyraposo> being accessed?
<jrg> no
<jrg> just a cp ... then i try to rm
<jrg> that is one that works
<jrg> from the same dir.. on the same windows box going to the freenas share... then rm from the pi
rZr is now known as rZr
<lennyraposo> so every device but the one works
<lennyraposo> or the pi's
heffer has joined #linux-sunxi
Andy-D has joined #linux-sunxi
<lennyraposo> question what happens if you try rm as sudo?
arete74_ has joined #linux-sunxi
speakman_ has joined #linux-sunxi
<lennyraposo> jrg
doppo_ has joined #linux-sunxi
souther_ has joined #linux-sunxi
<jrg> let me try...
<KotCzarny> jrg, if thats freenas, why dont you just mount it as nfs?
<jrg> KotCzarny: because i want to map domain users to it
<jrg> i authenticate agains the freenas AD DC
<jrg> i haven't found a sane way to do that with nfs
<KotCzarny> if you just want a working solution, xargs may help?
<KotCzarny> (for rm issue)
MoeIcenowy_ has joined #linux-sunxi
<jrg> lennyraposo: yah just sits there again
<jrg> even as root
ninolein has joined #linux-sunxi
dave0x4d has joined #linux-sunxi
diego71_ has joined #linux-sunxi
<jrg> KotCzarny: or sshfs? :)
staplr has quit [*.net *.split]
jukivili has quit [*.net *.split]
bmeneg has quit [*.net *.split]
ninolein_ has quit [*.net *.split]
phiplii has quit [*.net *.split]
diego71 has quit [*.net *.split]
robogoat has quit [*.net *.split]
doppo has quit [*.net *.split]
indy has quit [*.net *.split]
MoeIcenowy has quit [*.net *.split]
heffer_ has quit [*.net *.split]
vpeter has quit [*.net *.split]
cajg has quit [*.net *.split]
klarrt has quit [*.net *.split]
dave0x6d has quit [*.net *.split]
arete74 has quit [*.net *.split]
souther has quit [*.net *.split]
speakman has quit [*.net *.split]
doppo_ is now known as doppo
souther_ is now known as souther
<jrg> i was hoping for just a cleean smb/cifs method across all the operating systems
<jrg> everything was great until i noticed this issue with rm files
robogoat has joined #linux-sunxi
<KotCzarny> rsync?
<jrg> rsync isn't really much of a filesystem heh
dave0x4d is now known as dave0x6d
<jrg> jrg@pi:/mnt/Media$ touch testing
<jrg> jrg@pi:/mnt/Media$ ls -l testing
<jrg> -rw-r--r-- 1 jrg domain snobs 0 May 23 17:54 testing
<jrg> i can write just fine to the cifs share
<jrg> jrg@pi:/mnt/Media$ rm testing
<jrg> jrg@pi:/mnt/Media$
<jrg> no issues
indy_ has joined #linux-sunxi
<jrg> if i touch testing to the share. and delete it on a windows or osx box the file goes away just fine. there has to be something wrong with the debian arm mount.cifs bin or something
<jrg> i'll make a vm soon and see if i get the same problem on an x86 box
tlwoerner has quit [Quit: Leaving]
<jrg> think I'll just resort to sshfs and keep the box separate from everything.
<jrg> that kind of sucks.
Amit_T has joined #linux-sunxi
orly_owl has quit [Quit: leaving]
staplr has joined #linux-sunxi
phiplii has joined #linux-sunxi
bmeneg has joined #linux-sunxi
jukivili has joined #linux-sunxi
orly_owl has joined #linux-sunxi