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
[7] has quit [Disconnected by services]
TheSeven has joined #linux-sunxi
vagrantc has joined #linux-sunxi
arossdotme has quit [Quit: Ex-Chat]
cosm has quit [Ping timeout: 276 seconds]
cosm has joined #linux-sunxi
apritzel has quit [Ping timeout: 244 seconds]
_whitelogger has joined #linux-sunxi
arossdotme has joined #linux-sunxi
ninolein_ has quit [Ping timeout: 272 seconds]
ninolein has joined #linux-sunxi
Zliba has quit [Ping timeout: 240 seconds]
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
nixdork has quit [Quit: EliteBNC free bnc service - http://elitebnc.org/]
nixdork has joined #linux-sunxi
naobsd has quit [Remote host closed the connection]
naobsd has joined #linux-sunxi
ganbold has quit [Ping timeout: 244 seconds]
ganbold has joined #linux-sunxi
p1u3sch1 has quit [Ping timeout: 272 seconds]
p1u3sch1_ has joined #linux-sunxi
Zliba has joined #linux-sunxi
reev has joined #linux-sunxi
heffer has quit [Remote host closed the connection]
heffer has joined #linux-sunxi
tkoskine has quit [Ping timeout: 252 seconds]
tkoskine has joined #linux-sunxi
<MoeIcenowy> does anyone know when can the pre-ordered CHIP ship...
<MoeIcenowy> It's said to be shipped "by June 2016"
gzamboni has quit [Ping timeout: 276 seconds]
cnxsoft has quit [Read error: Connection reset by peer]
cnxsoft has joined #linux-sunxi
kaspter has joined #linux-sunxi
IgorPec has joined #linux-sunxi
gzamboni has joined #linux-sunxi
reev has quit [Read error: Connection reset by peer]
datagutt has quit [Ping timeout: 260 seconds]
datagutt has joined #linux-sunxi
datagutt has joined #linux-sunxi
datagutt has quit [Changing host]
zuikis has joined #linux-sunxi
luoyi has quit [Ping timeout: 250 seconds]
reev has joined #linux-sunxi
reev has quit [Max SendQ exceeded]
reev has joined #linux-sunxi
vagrantc has quit [Quit: leaving]
rookie has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
rookie has quit [Quit: Page closed]
cosm has quit [Ping timeout: 246 seconds]
zuikis has left #linux-sunxi [#linux-sunxi]
IgorPec has quit [Quit: Nettalk6 - www.ntalk.de]
cosm has joined #linux-sunxi
reinforce has joined #linux-sunxi
IgorPec111118 has joined #linux-sunxi
IgorPec111119 has joined #linux-sunxi
IgorPec111118 has quit [Ping timeout: 276 seconds]
IgorPec111119 has quit [Ping timeout: 240 seconds]
IgorPec has joined #linux-sunxi
<mripard> MoeIcenowy: then June looks like a nice estimate
al1o has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
al1o has joined #linux-sunxi
al1o has quit [Remote host closed the connection]
reev has quit [Ping timeout: 276 seconds]
reev has joined #linux-sunxi
<codekipper> mripard: no worries...your punishment will be having to push it!
iamfrankenstein1 has joined #linux-sunxi
iamfrankenstein has quit [Ping timeout: 260 seconds]
iamfrankenstein1 is now known as iamfrankenstein
<mripard> codekipper: almost ready ;)
tkoskine has quit [Quit: hop]
premoboss has joined #linux-sunxi
Dodger78_ has joined #linux-sunxi
<Dodger78_> \o
<Dodger78_> does anyone know if A80 mainlining is still being worked on ?
<wens> Dodger78_: very slowly
merbanan has quit [Ping timeout: 260 seconds]
massi has joined #linux-sunxi
merbanan has joined #linux-sunxi
<plaes> ssvb: my spi flash arrived in 3 days o_O
Mr__Anderson has joined #linux-sunxi
apritzel has joined #linux-sunxi
premoboss has quit [Ping timeout: 276 seconds]
IgorPec111119 has joined #linux-sunxi
IgorPec1111110 has joined #linux-sunxi
IgorPec1111111 has joined #linux-sunxi
premoboss has joined #linux-sunxi
IgorPec111119 has quit [Ping timeout: 244 seconds]
IgorPec1111110 has quit [Ping timeout: 244 seconds]
IgorPec1111111 has quit [Client Quit]
ricardocrudo has joined #linux-sunxi
<Dodger78_> i dont really know what i bought this board for :-) maybe the A80 is my last allwinner . the cubietruck was kind of ok, but A80 is just catchin dust ^^
<plaes> Dodger78_: A13, A20, A10 are slowly getting proper mainline support
<plaes> only few bits missing
<Dodger78_> yes but A20 is outdated :-)
<plaes> define outdated
<Dodger78_> A80 is around for 2 years
<plaes> so is A20
<KotCzarny> outdated doesnt mean obsolete
<KotCzarny> you should say 'mature'
<KotCzarny> ;)
<wens> :)
<KotCzarny> im very happy with my banana audio center
<Dodger78_> the mature allwinner stuff is "OLD" hehe
<Dodger78_> for audio its ok. for server stuff you want a80 cause of usb3
<KotCzarny> sure, as long it lives to the bandwidth transfers :P
<plaes> server and usb?
<plaes> A20 has SATA :P
<Dodger78_> but usb3 support takes another 5 years
<Dodger78_> and is far too slow
<wens> mripard: about vga detection, seems the tv encoder dac has some sensing capabilities? (i saw some registers)
staplr has joined #linux-sunxi
<JohnDoe_71Rus> A20 SATA not the same SATA, "big PC"
<KotCzarny> if you want server capable board dont look at allwinner
<MoeIcenowy> In my memory
<Dodger78_> A80 has 3-4 times the single thread cpu power , A20 is too slow
<wens> get a TX1 maybe? :p
<KotCzarny> google: clearfog
<MoeIcenowy> Allwinner now declares A20 to be classical
<Dodger78_> well , which low power arm board , FOSS do you think of ?
<TheLinuxBug> For storage unless your buying marvell , A20 is the best I have found overall other than an x86 board. i.MX6 has SATA too and while read/write are closer to 100M/ each way, the nic is stil limited to 400mbit, so really for network storage purposes is exactly the same as A20.
<Wizzup> I love the A20 - really nice and well supported.
<apritzel> does anyone know more about this mysterious A20e?
<KotCzarny> Dodger78_: clearfog
<MoeIcenowy> oh A20 is not declared classical
<MoeIcenowy> it's A10, 13, 10s
<wens> apritzel: where did you hear about it?
<apritzel> I saw tkaiser mentioning it in some forum, I think
<MoeIcenowy> A20e... WHAT THE HELL...
<plaes> ?
<TheLinuxBug> well olimex had mad a blog post on April 1
<TheLinuxBug> which if to be believe said something about that I thought?
<KotCzarny> hehe
<wens> TheLinuxBug: April 1 posts are not to be taken seriously :)
<Dodger78_> clearfog is FOSS and completely mainline supported ?
<TheLinuxBug> well im saying thats where I remember reading something like that
fredy has quit [Excess Flood]
<TheLinuxBug> can't find it again though at quick glance
<apritzel> but this post was about a fake "A20M", wasn't it?
<apritzel> which was indeed a joke
<KotCzarny> Dodger78_: dont know about its state, but armbian has an image for it
<KotCzarny> with 4.5.5 kernel too
<TheLinuxBug> ahh I was incorrect, it was actually what they called the 'A20M' so maybe the A20e is a real thing?
<ssvb> apritzel: but presumably it was supposed to be a pin compatible quad core
fredy has joined #linux-sunxi
<TheLinuxBug> ahh
<TheLinuxBug> thats it
<TheLinuxBug> !!
<TheLinuxBug> ssvb: was still searching
<TheLinuxBug> had got to the april 1 post
<mripard> wens: we're discussing the VGA converters that are found on the CHIP or A13-Olinuxino
<mripard> wens: not the VGA that is part of the TV encoder on some SoCs
<mripard> wens: (and yes, but no one found how it was working)
IgorPec has quit [Ping timeout: 276 seconds]
<wens> mripard: ah, i see
<wens> the bridge makes the internal sensing stuff unusable
<KotCzarny> A20E (based on .dts stuff available through A64 BSP)
<ssvb> apritzel: also tkaiser identified some pieces of code for some new yet unannounced SoC in the Allwinner's BSP kernel, which has SATA support
<ssvb> apritzel: so people have started speculating that this must be it :-)
<KotCzarny> :)
<mripard> wens: mostly the bridge doesn't use the TV encoder at all
<apritzel> ssvb: ah, I see, thansk for the info
<mripard> it's an RGB to VGA bridge
<mripard> so it uses the same interface than the panels
<wens> ok
<apritzel> in fact I was hoping that it's not just a quad-A20, more an H3 with native SATA
* apritzel doesn't dare to dream about cheap ARMv8 chips with SATA
<phiplii> heh
<arete74_> the allwinner plan they were first an A64 and next A64+sata
<phiplii> Hum. OPi Lite is playing silly buggers. Was working fine when I shut it down last night
<KotCzarny> well, sata or minipcie
<KotCzarny> that would be awesome
<MoeIcenowy> the Allwinner never clean their BSP up :-)
<Dodger78_> is the A388 clearfog in mainline kernel ?
<jelle> Dodger78_: checked the wiki?
<Dodger78_> where can i find it ? does it have sata ? usb3 in linux supported ?
<MoeIcenowy> mripard: I remembered seeing an option for VGA over RGB in uboot menuconfig...
<mripard> this is for linux
<wens> Dodger78_: see armada-388-clearfog.dts under mainline
<wens> MoeIcenowy: yeah, that was mostly for A31 boards that don't have the tv encoder, and end up with an external encoder chip on the LCD interface
<wens> mripard: interesting that they are using a resistor network to do the conversion though
<wens> kinda think the waveform won't be as smooth
<mripard> Dodger78_: yes, and PCI-E, and true gigabit interfaces
<mripard> wens: it's pretty smooth actually
<phiplii> using a resistor network as an DAC?
<mripard> even under a scope, it's looking good
<mripard> phiplii: yes
<wens> cool
<phiplii> it works well as long as you have good resistor values
<phiplii> the issue is that most people doing things on the cheep use that method, and then skimp on resistors
<phiplii> If I remember, this guy is using a resistor network. If you look when he has the waveform on the display it is quite smooth despite the small number of bits used
apritzel1 has joined #linux-sunxi
<phiplii> actually
<phiplii> ignore me
<phiplii> haven't shaken off sleep yet
<phiplii> the display is only showing the waveform -as set-
* phiplii goes looking for a brew to wake up
tkaiser has joined #linux-sunxi
<tkaiser> ssvb: nove spotted A20E in BSP sources some weeks ago. And looked at the pin mappings to come to the conclusion that it looks nearly identical to A20. So the rumoured quad core successor might be dual core instead (with different IP blocks causing driver issues as usual)
<tkaiser> Dodger78_: Regarding Clearfog you find also many information here: http://forum.armbian.com/index.php/topic/590-quick-review-of-solidruns-clearfog/ (Solid-Run engineers also provide some info there, eg. to drop the idea to use crappy USB since there you get 3 x SATA 3.0!)
<ssvb> tkaiser: if it is still dual core, then what's the point?
<apritzel> ssvb: you beat me by a second with this question ;-)
<tkaiser> ssvb: Hoping for a surprise (two more cpu nodes in .dts ;)
<ssvb> tkaiser: or is it the same story as with R8, which is an exact clone A13?
<tkaiser> ssvb: No, according to .dts many IP blocks seem to be different. Also THS/cpufreq/dvfs stuff seems like dual core H3
<tkaiser> apritzel: ssvb: And maybe be get rid of the SATA sequential write speed limitation (currently maxes out at 45MB/s)
<apritzel> tkaiser: still a dual core A7 @ 1GHz is getting a bit long in the tooth these days
<tkaiser> So unless this new SoC can be tested it's somewhat useless to think about :)
<KotCzarny> if they fixed inner bus speed, then its not
<tkaiser> apritzel: For NAS use cases CPU speed doesn't matter that much. See Marvell SoCs. They're pretty slow but both I/O and network bandwidth are pretty high
<tkaiser> ARMADA 38x is single or dual core Cortex-A9 but they are able to saturate 3 SATA lines with +500 MB/s each concurrently.
<apritzel> tkaiser: yeah, but on those older Allwinner SoCs it's _both_ the CPU and I/O that is slow ...
<tkaiser> While you can saturate the three GBit Ethernet interfaces too
<tkaiser> apritzel: I know. And I fear anything will change regarding SATA since I still think it's there more by accident than by design.
<apritzel> tkaiser: unfortunately I agree :-(
<apritzel> It could be from that time when there were set top boxes with hard disks for PVR usage
<tkaiser> apritzel: Gonna search for 3 2.5" disks right now to do some tests with OPi Plus 2E. With mainline kernel and UASP capable enclosures ~39.5MB/s per disk are possible and by using some weird mdraid stuff combined with btrfs raid GbE should be the bottleneck while having full disk redundancy
<Dodger78_> the dual cortex m9 of the clearfrog isnt a big improvement over cubietruck ?
<ssvb> plaes: nice, welcome to the club :-) have you also got this SPI flash module shipped from Poland?
<tkaiser> apritzel: In fact one of the first MeLE OTT boxes made use of it. And then they journey started: http://guillaumeplayground.net/allwinner-a10-cluster-mele-a2000/ (this was the moment when I ordered a MeLE and a Cubitruck back then and got infected with sunxi virus)
<tkaiser> Dodger78_: You look at the wrong place. You think CPU is important but it isn't. Bandwidth is important. BTW: http://linux-sunxi.org/Sunxi_devices_as_NAS
<tkaiser> Dodger78_: CPU becomes important if you want to do encryption and can't use HW acceleration and stuff like that. But for normal use cases A20 suffers from both limited GbE performance and SATA (unfortunately unbalanced performance in different directions)
<wens> hmm, the "vga-connector" driver seems omap specific
<mripard> wens: omap ?
<mripard> it's only used by renesas
<Dodger78_> f.e. for owncloud , a20 is too slow
<Dodger78_> i got alot of pics from my family to upload and it takes long.
<ssvb> apritzel: there is one thing that puzzles me, where did you find an old revision of my uart0-helloworld-sdboot.sunxi patch for sunxi-tools?
<tkaiser> Dodger78_: I don't believe so. Apart from being a horrible piece of software OC is limited by slow random I/O (for reasons unknown to me since with buffering this shouldn't be an issue)
<apritzel> ssvb: mmh, on my harddisk, I guess ;-)
<apritzel> ssvb: I think I pulled it yesterday, but could also have been some days ago
<Dodger78_> can you mention a better solution than OC ?
<ssvb> apritzel: the github workflow seems to encourage doing force push in the pull request branches, which I don't quite feel comfortable with
<ssvb> apritzel: but there might be some reference to the original commits too
<tkaiser> Dodger78_: Some folks recommend SeaFile. No idea. Just if you want to get a clue where's the bottleneck: Install sysstat package and run 'iostat 5' while uploading stuff
<tkaiser> Dodger78_: And check performance settings. Eg. using 'ondemand' governor without necessary IO switches you end up with a slow A20 device. Everything outlined in the aforementioned 'sunxi devices as NAS' wiki article
<wens> mripard: sorry, had dvi/hdmi/analog-tv connectors in mind :(
<plaes> ssvb: yup, Poland
<ssvb> apritzel: could you please tell me the commit id of that uart0-helloworld-sdboot.sunxi v1 patch from your local git copy?
<apritzel> ssvb: 53f7f146bed21531481185b154dc62ed80ad064c
<ssvb> apritzel: thanks! edited the first message in the pull request to reference it - https://github.com/linux-sunxi/sunxi-tools/pull/44
<ssvb> apritzel: it's good that we can have references to all older patch revisions with the github workflow too (hopefully github does not garbage collect them as long as there is a reference from one of the comments)
Dodger78_ has quit [Read error: Connection reset by peer]
kaspter has quit [Ping timeout: 244 seconds]
<ssvb> apritzel: or maybe not, "ls-remote" does not show it, there are only "refs/pull/44/head" and "refs/pull/44/merge" references
<apritzel> ssvb: frankly: I don't care so much about the github workflow, I just found this bug yesterday (and wondered how it worked for you)
<NiteHawk> ssvb: if you know the commit sha1 and the repo, you can construct the URL manually - https://github.com/ssvb/sunxi-tools/commit/53f7f146bed21531481185b154dc62ed80ad064c
<ssvb> NiteHawk: yes, I'm only worried about preserving full history of the pull request and making sure that the dangling commits (overwritten by force push) are not garbage collected
<ssvb> NiteHawk: I have also edited the first comment in the pull request to have the v1 patch reference there, but this is also a bit scary (I mean rewriting the old comments)
<ssvb> apritzel: it still makes sense to care about the tools we are using :-) github is one of the tools
<NiteHawk> afaik, github preserves those commits (i'm not sure if at least one 'active' reference is needed). otherwise stuff like merging inactive PRs would be impossible: https://help.github.com/articles/checking-out-pull-requests-locally/
<NiteHawk> githubs workflow may not be ideal, yes. but the alternative to force-pushing into PRs seems to be closing and recreating PRs all the time for the same feature - which to me looks even less desirable
Gerwin_J has joined #linux-sunxi
<NiteHawk> look at the top of https://github.com/linux-sunxi/sunxi-tools/pull/49 - where i later pushed a revised commit. the 'outdated' commit comments are still available as a "drop down" choice (as well as the commit itself). that's how it should work out most of the time if folks raise specific concerns with certain changes
<NiteHawk> but yes, if there are no comments/references for a commit that gets overwritten, it will just be "dangling"...
<NiteHawk> ssvb: can you think of other approaches? e.g. collecting all the changes successively in a PR / working branch and then do a "squash commit" for the merge?
<ssvb> NiteHawk: squashing multiple commits is bad, because we can't reference an individual commit in the future when discussing problems in it
<NiteHawk> you can also refer to issues and pr in your commit messages, and the commit will get auto-appended / referenced from there. unfortunately, that has some problems of its own... example: https://github.com/linux-sunxi/sunxi-tools/issues/51
<ssvb> NiteHawk: so far it seems like it's best to just provide a changelog and mention the commit id in the pull request comment when doing force pushes
<plaes> ssvb: git reflog
<NiteHawk> ssvb: probably. and i also agree that editing older comments may not be ideal
<ssvb> NiteHawk: it's actually very good for fixing typos, but it also means that the workflow is based on trust and respect (assuming that nobody edits old comments for despicable purposes)
<apritzel> bah, typos, jsut do'nt make then in the frist palce ;-)
<ssvb> NiteHawk: the continuous integration on github at least solved the GCC warnings issue (mostly the wrong printf format specifiers), which used to be problematic with git send-email based workflow in the past :-)
<ssvb> NiteHawk: so it's a very nice improvement, thanks
kaspter has joined #linux-sunxi
<NiteHawk> ssvb: did you note that those with admin access obviously could even edit other's posts/comments? :D as for CI: yes, i consider that very useful too. next stop will be running functional tests on all sunxi-boards files ;)
<NiteHawk> (but first i have to iron out the fexc kinks)
<NiteHawk> i also like that we now have osx build testing "for free", which i suspect got always neglected in the past
Gerwin_J has quit [Ping timeout: 244 seconds]
mosterta has joined #linux-sunxi
<phiplii> You can edit your previous messages in Skype (or could, I don't use it much) - great for messing with peoples heads
<phiplii> ask a question with a predictable answer... get the answer... edit the question to something slightly different for which their answer means something completely different
<phiplii> watch them flail
ninolein has quit [Quit: No Ping reply in 180 seconds.]
ninolein has joined #linux-sunxi
<KotCzarny> added bananas
premoboss has quit [Quit: Sto andando via]
<KotCzarny> that page is so poor
<NiteHawk> KotCzarny: the BPi M1 should probably read "SD" instead of "µSD"? the slot is regular size, not TF
kaspter has quit [Remote host closed the connection]
<KotCzarny> nitehawk: thx, will edit in a moment
<KotCzarny> adding cubietechs
<plaes> why no olimex?
<KotCzarny> because i only have 2 hands?
<KotCzarny> just wait 10 minutes
<KotCzarny> k, now olimexes
kivutar has quit [Ping timeout: 252 seconds]
kaspter has joined #linux-sunxi
kivutar has joined #linux-sunxi
fredy has quit [Excess Flood]
fredy has joined #linux-sunxi
<apritzel> KotCzarny: this is great stuff, thank you!
<wens> huh... i left it TODO for over a year :(
<KotCzarny> done olimexes
<KotCzarny> but as nove yesterday mentioned, it could be generated automatically if infoboxes were entered correctly on device pages
<KotCzarny> and by correctly i mean consistently
<KotCzarny> k, pcduinos time
<plaes> I'm in favor on fixing infoboxes..
<plaes> because this table should be generated automatically
<KotCzarny> k, you've volunteered! good!
<KotCzarny> ping me when they are done, i'll fix the table ;)
<KotCzarny> pcduinos done, now on to mars
<KotCzarny> done, any other boards i've missed?
<KotCzarny> its not done by linksprite?
<tkaiser> KotCzarny: It's Linksprite. Regarding voltage regulators: All H3 boards from Xunlong have SY8106A expect of One/Lite (SY8113B). For SoCs with PMU maybe PMU type should be listed (A10/A13/A20 --> AXP209). And many boards are still missing
<KotCzarny> btw. i've missed the right word, PMU is Vreg
<KotCzarny> let me update
reev has quit [Ping timeout: 260 seconds]
<tkaiser> KotCzarny: Regarding 'PMU is Vreg'. A PMU is something different than a programmable voltage regulator (important criteria: battery/UPS mode)
<KotCzarny> as for the missing boards, if you list them i'll add them
<KotCzarny> nitehawk, original banana pi was made by a few companies
<KotCzarny> disregard, read the log wrong
<tkaiser> KotCzarny: Nope, since I don't find the table useful. As already said: table for H3 boards would've been ok, as it's now it's IMO not useful (since it contains already a lot of mistakes and will get unmaintained rather sooner than later)
<KotCzarny> mistakes are taken from device pages themselves
<KotCzarny> so at least you know what to fix
<KotCzarny> (and fix the table at the same time)
mosterta has quit [Ping timeout: 272 seconds]
cosm has quit [Quit: Leaving]
<ssvb> KotCzarny: the point is that we get a duplication of information here, and any redundant duplication tends to get out of sync
<KotCzarny> yes
<KotCzarny> but as i said earlier, there is not proper source of info now for proper table
<montjoie> there are no RTC on A83T ?
<wens> montjoie: rtc is in the external chip
JohnDoe_71Rus has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
<montjoie> wens: do you know which model it is ?
<montjoie> my googling seems to say "I need to buy one"
IgorPec has joined #linux-sunxi
akaizen has joined #linux-sunxi
<longsleep> woot, root@pine64:~# lsmod
<longsleep> Module Size Used by
<longsleep> zfs 2519102 0
<longsleep> zunicode 324517 1 zfs
<longsleep> zavl 13125 1 zfs
<longsleep> zcommon 40274 1 zfs
<longsleep> znvpair 58887 2 zfs,zcommon
<longsleep> spl 69937 3 zfs,zcommon,znvpair
<wens> montjoie: the axp pmic is a pmic and an ac100 combined
<montjoie> :(
<tkaiser> longsleep: Nice, where do get ECC RAM now for Pine64? ;)
<longsleep> tkaiser: yeah ..
<KotCzarny> ask the makers?
<KotCzarny> pine64-server edition
<KotCzarny> ;)
<montjoie> wens: at least the emac driver work on bpim3 with tx-delay
<tkaiser> KotCzarny: The sad thing is: ARMADA A38x supports ECC RAM but I've not seen a single design so far using it
<longsleep> tkaiser: anyhow, i just took zfs as excercise to fix DKMS support with my famous Kernel non-packaging :)
apritzel1 has quit [Ping timeout: 244 seconds]
<wens> montjoie: :)
<wens> montjoie: i actually have a wip driver for rtc part of ac100
<wens> need to finish the clock bits
kaspter has quit [Ping timeout: 244 seconds]
<montjoie> wens: in fact txdelay does not write anything, does allwinner,tx-delay = "3" is the right syntax ?
<wens> <3>
<wens> integers don't have quotes
cnxsoft has quit [Quit: cnxsoft]
rZr is now known as RzR
<ssvb> tkaiser, IgorPec: have you seen this - https://www.youtube.com/watch?v=TEyU1zSqFwU ?
<IgorPec> hehe, yes i did
<apritzel> wens: so you have montjoie's driver running on an A83T with the RTL8211E PHY?
nove has joined #linux-sunxi
<montjoie> apritzel: yes on a bpim3
<apritzel> but a wrong tx-delay setting does not prevent the driver from initializing, right?
<montjoie> wens: SC_ETXDC_SHIFT was off by one too much
<montjoie> apritzel: no all is perfectly init with a bad txdelay
<montjoie> it is what I got now
<montjoie> but network doesnt work
<montjoie> wens: sorry forget about SC_ETXDC_SHIFT
<wens> montjoie: sorry, i hadn't tested the new version on the a83t
<montjoie> wens: it was my fault, the good value is 6:) not 3
<ssvb> IgorPec: that was a rather weird review with some strange bashing of aliexpress for no reason (I did not have any problems with it), complaining about a barrel power jack and claiming that using non-vendor "third party" software is a disadvantage
<montjoie> wens: so it work perfectly on bpim3
<apritzel> montjoie: that is with your current branch on github? Or with wens' version?
<montjoie> my current branch
<IgorPec> ssvb: it's weird, yes I agree. The guy is not very much in technical stuff I would say
<montjoie> but both should be nearly the same
<ssvb> IgorPec: since when running "third party" software from kernel.org is bad? ;) also surprise surprise, https://www.raspbian.org/ says that "Raspbian is not affiliated with the Raspberry Pi Foundation"
<IgorPec> yeah, there are quite some strange / wrong data and assumtion
<apritzel> montjoie: but your branch does not have the DT bits for A83T, right?
<ssvb> IgorPec: still Xunlong could surely improve their website
<montjoie> apritzel: yes
reinforce has quit [Quit: Leaving.]
<montjoie> apritzel: do you want it ?
<apritzel> I was just wondering if the A83T is actually closer to the A64 in terms of Ethernet than the H3
<apritzel> so I wanted to double check if I got the DT bits right
<wens> they should be the same for the DT bits
<apritzel> right, so I was copying them, but still I get this weird PHY init error
<montjoie> and it seems that I cannot send the driver already (crash when stopping interface:))
<apritzel> montjoie: Ethernet is so great, you don't want to turn it off ;-)
<montjoie> apritzel: I will publish a new version with your remark
<montjoie> apritzel: it is put off when you reboot
<apritzel> I know, it's just that I'd be happy if it just would turn on for me ...
<wens> montjoie: funny, i remember using a value of 3...
<wens> a83t is still missing the whole clock driver
<montjoie> with 3 my board doesnt work
<wens> :/
<apritzel> oh, montjoie, wens: do you know if the Ethernet MAC retains a MAC address in the SUN8I_EMAC_MACADDR_* registers across initialisation?
<apritzel> so can firmware write a MAC address in there and it stays until the driver comes up?
<tkaiser> ssvb: I didn't manage to watch the 'review' to the end. Too weird. And what you're summarize sounds again just like that :)
<wens> apritzel: don't think so, and shouldn't firmware pass the MAC address via the DT?
<apritzel> "has to on most boards" would be the right phrase here, I guess
<apritzel> I wonder if one could avoid this, though of course it's a possiblity
<apritzel> the BSP software stack seems to use the SID to generate a MAC, but this is secure-only, so EL2 U-Boot cannot easily read this value, if I am not mistaken
<apritzel> so it would have to be done by ATF, which currently doesn't even know about DT at all
<montjoie> apritzel: dont know
<apritzel> or ATF passes the SID or MAC somehow down to U-Boot
<ssvb> apritzel: the SID can be probably passed to U-Boot in the SPL header
<ssvb> apritzel: did you manage to toggle the secure/non-secure access permissions for SRAM?
Michal has quit [Ping timeout: 244 seconds]
JohnDoe_71Rus has joined #linux-sunxi
<apritzel> ssvb: I set the bits in ATF, but it didn't change anything
<apritzel> at least on the Pine64
apritzel1 has joined #linux-sunxi
<apritzel> but on the Remix I can't touch SRAM A2, even the l.nop instructions aren't visible
<apritzel> and this was with upstream U-Boot booted via FEL
<apritzel> so no magic Allwinner bits in the loop - apart from BROM
<ssvb> so that's why you suspect that A64 and H64 are different
<apritzel> that's why I was wondering about differences between H64 and A64 the other day
<apritzel> exactly
<ssvb> it might make sense to dump the BROM code and compare it between A64 and H64
<apritzel> and I couldn't find a pin or so that would toggle this security feature per board
<apritzel> ssvb: yes, will do this
<apritzel> also the BROM code could look at the SID and make different decisions based on that
reinforce has joined #linux-sunxi
<tkaiser> apritzel: ssvb: At least with H8 and A83T it's already confirmed that they have different 'IC ID' which gets checked by boot0 BLOB: http://forum.linksprite.com/index.php?/topic/4516-lm-sensors-no-worky/#entry12084
<ssvb> tkaiser: that's a good point, thanks
<ssvb> tkaiser: is the detection done by something like this - https://patchwork.ozlabs.org/patch/622854 ?
<tkaiser> Additional info (from @sinovoip): The Android SDKs Allwinner provides use encryption and rely on this ID. So A83T gets Android 5.5 support and H8 only 4.4 max (not confirmed, just quoting a weird forum communication)
<tkaiser> ssvb: No idea, I just tried it out and boot got stuck with that message. And after exchanging the boot0 BLOB everything was fine
<tkaiser> s/5.5/5.x/
<KotCzarny> hmm, can we get https://www.mediawiki.org/wiki/Extension:PageVariable or similar on sunxi wiki?
<KotCzarny> libv, nighthawk, plaes, apritzel, wens ^
<jrg> bitcoind up to 15GB of blockchain and still going on the bpi
<jrg> good stuff
apritzel1 has quit [Ping timeout: 244 seconds]
<jrg> quoting weird forum communication?
jernej has joined #linux-sunxi
<jrg> from...... where?
<jrg> does the android image use hw gpu accel?
<tkaiser> ssvb: Just to confirm: This 'boot0' thingie is what's also called the libdram blob?
<apritzel> tkaiser: AFAIK libdram is usually part of boot0
<NiteHawk> iow: boot0 makes uses of libdram functions during initial setup
<longsleep> boot0 links with libdram and needs its symbols
<longsleep> see https://github.com/longsleep/u-boot-pine64/commit/231822598b1da5d4ea9a89b672e3cdca530f69b6 which is boot0 for A64 source code including libdram binary
mpmc has quit [Ping timeout: 240 seconds]
<NiteHawk> KotCzarny: i have no administrative authority in that reign. libv or turl should know more
<plaes> neither do I
lamer14642780767 has joined #linux-sunxi
staplr has quit [Remote host closed the connection]
apritzel1 has joined #linux-sunxi
tkaiser has quit [Ping timeout: 240 seconds]
Netlynx has joined #linux-sunxi
Netlynx has quit [Changing host]
Netlynx has joined #linux-sunxi
lamer14642780767 has quit [Quit: jIRCii - http://www.oldschoolirc.com]
staplr has joined #linux-sunxi
cosm has joined #linux-sunxi
zuikis has joined #linux-sunxi
apritzel1 has quit [Ping timeout: 244 seconds]
mosterta has joined #linux-sunxi
mpmc has joined #linux-sunxi
Michal has joined #linux-sunxi
Mr__Anderson has quit [Quit: Leaving.]
zuikis has left #linux-sunxi [#linux-sunxi]
diego_r has quit [Quit: Konversation terminated!]
apritzel has quit [Ping timeout: 244 seconds]
massi has quit [Quit: Leaving]
ricardocrudo has quit [Remote host closed the connection]
pietrushnic is now known as pietrushnic`away
pietrushnic`away is now known as pietrushnic
tsuggs has joined #linux-sunxi
matthias_bgg has quit [Quit: Leaving]
apritzel has joined #linux-sunxi
jrg has quit [Ping timeout: 244 seconds]
ganbold has quit [Ping timeout: 276 seconds]
gzamboni has quit [Read error: No route to host]
fredy has quit [Excess Flood]
fredy has joined #linux-sunxi
afaerber has quit [Quit: Ex-Chat]
jrg has joined #linux-sunxi
<jrg> and so dies the bananapi again
<jrg> :/
<jrg> and im not home again to see why
apritzel has quit [Ping timeout: 244 seconds]
<jrg> blah let ne gead home and see where it all came off the hinges.. seems like the bpi is just dying due to thermal issues even with the cores shutting off, throttling, and a heatsink
<jrg> In case you improve heat dissipation be prepared for shut-offs unless you solder a sane DC-IN solution and use 5V/3A at least (won't help with micro USB due to the tiny contacts)
<jrg> oh
<jrg> so youre telling me it is better to run it without a heatsink unless i put a barrel connector on it?
gzamboni has joined #linux-sunxi
<longsleep> jrg: interesting, how hot does it get?
<longsleep> it should not get that hot with only one core
<jrg> it shuts off 4 cores
<jrg> cant remember.. think it hovers at 70C
<jrg> maybe the heat sink i have on it sucks ill finger test it when i get home
<jrg> too nice outside to play with a banana pi
<TheLinuxBug> take your banana pi outside and play with it
<TheLinuxBug> Just be careful who you play with it in front of, some people might give you a confused look
<TheLinuxBug> jrg: I believe most USB only support 1.8v reliably, or something like that, so the reason they suggest soldier a barrel connector or use GPIO is to remove that limitation and give better power at full rate.
<TheLinuxBug> er 1.8a
<TheLinuxBug> whichever it is
<TheLinuxBug> eesh
<TheLinuxBug> If a USB device is connected to a dedicated charger, maximum current drawn by the device may be as high as 1.8 A. (Note that this document is not distributed with USB 2.0 specification package, only USB 3.0 and USB On-The-Go.)
<TheLinuxBug> so you are needing more current, need barrel connector or gpio power
Mr__Anderson has joined #linux-sunxi
cosm has quit [Ping timeout: 240 seconds]
reinforce has quit [Quit: Leaving.]
arossdotme has quit [Quit: Ex-Chat]
p1u3sch1_ has quit [Ping timeout: 240 seconds]
p1u3sch1 has joined #linux-sunxi
mosterta has quit [Ping timeout: 276 seconds]
JohnDoe8 has joined #linux-sunxi
JohnDoe_71Rus has quit [Ping timeout: 258 seconds]
arossdotme has joined #linux-sunxi
mosterta has joined #linux-sunxi
pietrushnic is now known as pietrushnic`away
apritzel has joined #linux-sunxi
jstein has joined #linux-sunxi
IgorPec has quit [Ping timeout: 240 seconds]
<jrg> TheLinuxBug: yah. i'm going to have to edit the .fex
<jrg> and remove the higher speeds
<jrg> it's running at a steady 80C
<jrg> it runs for like... 2 minutes under load
<jrg> then the temp spikes to a ridiculous level
<jrg> 15:45:08: 1800MHz 6.33 17% 2% 12% 0% 0% 0% 81°C
<jrg> 81C ?!
<jrg> that can't be right
<jrg> i opened the case and have it in the air with a heatsink on it
<longsleep> jrg: why shouldnt that tbe right? 81C sounds quite normal to me
<willmore> Anyone got a favorite aliexpress barrel connector vendor? I think I need to get a few. Powering via the GPIO is akward.
<jrg> longsleep: not a bit too high?
iamfrankenstein1 has joined #linux-sunxi
iamfrankenstein has quit [Ping timeout: 244 seconds]
iamfrankenstein1 is now known as iamfrankenstein
<longsleep> jrg: not when its under load
<KotCzarny> you can just set cpu freq max speed?
<jrg> KotCzarny: you can? where?
<longsleep> jrg: check the trip points in the device tree or whatever fex
<jrg> i was going to edit the fex and remove the higher freqs
<jrg> is there an easier way.. maybe run it at 1.2GHz max?
<KotCzarny> jrg, if there is cpufreq in /sys supported for your board
<longsleep> jrg: why? you can just change it via procfs
<longsleep> jrg: but if it crashes at high temperatures the whatever Kernel you are running has bad thermal settings
<KotCzarny> try: cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
tkaiser has joined #linux-sunxi
<jrg> 1800000
<KotCzarny> also, if you need 4.0/1.7mm barrel then you can order one when you will be ordering orange pi
<KotCzarny> try echo 1200 >/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
<tkaiser> 1200000
<KotCzarny> right
<KotCzarny> echo 1200000 >/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
<KotCzarny> also check /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
<longsleep> jrg: what system are you running? Are there really Linux images out there with crappy thermal defaults?
<jrg> it died again
<jrg> lol
<jrg> let me restart it :/
<jrg> it just hangs too. that's not fun
<longsleep> jrg: are you sure its a thermal issue?
<KotCzarny> gotta go, nite!
<tkaiser> jrg: Micro USB or barrel plug?
* willmore will not be buying any SBCs for a while. Time to play with smaller boards. STM32, here I come!
<jrg> tkaiser: usb
<tkaiser> longsleep: That's Allwinner's defaults for A83T. SinoVoip didn't change a single bit since they're clueless
<jrg> 2.5A
<longsleep> ah
<tkaiser> jrg: That's the problem. Forget about temperature, it's most likely undervoltage or undercurrent.
<longsleep> well, why are people running it then?
<jrg> tkaiser: would slowing the freq help?
<tkaiser> longsleep: Since customers have no clue either?
<longsleep> jrg: well by all means use the barrel plug if the thing has one
<tkaiser> jrg: Of course. You might be able to set it in /etc/default/cpufreq-utils
<tkaiser> longsleep: The pre-production samples of M3 had a barrel plug, then they exchanged it with Micro USB with the first production batch.
<jrg> i'll try 1.2GHz
<longsleep> lol
<longsleep> totday someone posted a link to a youtube video of some guy checking out some new whatever pi and complaining about it that the thing cannot be powered through micro usb
<longsleep> Orange Pi One was it
<willmore> You can please everyone.
<jrg> longsleep: it doesn't
<jrg> banana pi m3 has only usb. i'd have to solder one on.. and i'm not that good at soldering heh
<tkaiser> jrg: They switched back to barrel plug in the meantime. Since Micro USB with A83T is simply *fail*
<longsleep> well i guess theire website is just wrong then optional 5V DC port (center positive 1,6 x 4,4mm)
<jrg> tkaiser: well.. glad to see they did it after i bought an m3 :/
<longsleep> what does it cost?
<jrg> ...
<jrg> US$79 from amazon
<jrg> ok. i have it set to 1200MHz
<tkaiser> longsleep: They never provide correct information. Unfortunately.
<jrg> the cores are still on. so that's good heh
<longsleep> mhm ok - not that cheap then, does it have usb connected sata and 1000M nic or direct ones?
<longsleep> well the picture shows a power supply barrel plug http://www.banana-pi.org/images/bpi-images/M3/m3-hdw-label.jpg
<tkaiser> longsleep: The slowest USB-to-SATA bridge in the world: GL830. GbE is like H3/A64
<longsleep> thats wrong?
<longsleep> ok, then it costs too much
<tkaiser> longsleep: That's wrong for the first batch. Now it's correct again. But if you bought any of the M3 that were produced the last few months then you're lost without soldering
<jrg> i don't need the sata tho
<jrg> but i think the nic has an actual controller doesn't it?
<longsleep> jrg: no its on the SoC and just uses an external if its the same as for A64.
<longsleep> external connector
<jrg> ah so it's just part of the A83t
<jrg> guess that makes sense
<tkaiser> jrg: GbE is ok, you could have a look into schematic whether the board can be powered through GPIO pins 2/4/6: http://linux-sunxi.org/Banana_Pi_M3#See_also
<longsleep> jrg: why did you buy that particular board - i am really curious how people know which 'whatever pi' they should buy
<jrg> longsleep: i just went off specs. in hindsight i'd have done differently
<jrg> but didn't find this channel until after i bought it lol
<jrg> i have an orange pi on the way too
<jrg> i wanted the gbit more than anything. otherwise i'd have bought a rpi3
<jrg> but it's still 100mbit
<longsleep> arent there a gazillion different orange pi variants and only few of those useful?
<jrg> blah. it killed the cores again
iamfrankenstein has quit [Quit: iamfrankenstein]
<longsleep> i do not pay much attention
<longsleep> jrg: i think your course is hopeless with their crappy Kernel and settings
<jrg> longsleep: lol
<jrg> yeah probably
<jrg> i'll see how it acts at 1.2GHz tho
<jrg> maybe it will at least not hang :/
<longsleep> jrg: well, do you have a AWG20 30cm USB cable?
<longsleep> jrg: if not that might help a bit on that
<tkaiser> longsleep: SinoVoip/Foxconn had some success with the original A20 based Banana Pi. LeMaker built the community around. Then LeMaker got greedy and tried to get trademarks and lost. And since then SinoVoip/Foxconn sell incompatible crap under the label 'Banana Pi' and people believe they get well supported boards.
<longsleep> tkaiser: oh my what a mess
<jrg> tkaiser: how is the orange pi plus 2e?
<jrg> have you tinkered with it much yet?
<tkaiser> jrg: Great so far. As expected. There were no surprises left since all H3 based Orange Pi use the same components more or less
<tkaiser> To my surprise the size of the PCB (or the material) does matter regarding heat dissipation.
<jrg> do you have armbian images out and about for it ?
<tkaiser> jrg: Sure, Plus 2E is yet not officially supported but it's just exchanging .fex/.dts and you're done
<longsleep> mhm 49$ for Orange Pi Plus 2 H3
<longsleep> tkaiser: does it also have that slow sata bridge?
<tkaiser> longsleep: This board is crap, we're talking about Orange Pi Plus 2E! ;)
<longsleep> ah lol
<nove> where does this idea comes from, that there are phones with allwinner socs? likes in a comment in the above link, but not only there, i already notice from some time now, that some people post this as begin a true
<tkaiser> Plus 2 has GL830 and internal USB hub, Plus 2E exposes all USB host ports without crappy SATA.
<longsleep> when i google for orange pi plus 2e it shows matches for Plus 2 H3
<longsleep> no wonder that people get confused
<tkaiser> longsleep: True
<TheLinuxBug> 16gb emmc, don't forget ;p
jernej_ has joined #linux-sunxi
<longsleep> mhm impossible to be found by google, no problem to find on aliexpress though
<longsleep> $35 Orange Pi Plus 2E H3
<longsleep> yeah, people like us know where to search but everyone else will just get the Plus 2 H3
jernej_ has quit [Client Quit]
jernej_ has joined #linux-sunxi
jernej has quit [Ping timeout: 276 seconds]
<longsleep> how is mainline kernel support for H3 and Orange Pi Plus 2E?
jernej has joined #linux-sunxi
<tkaiser> If Xunlong would make an Orange Pi PC Plus Turbo (like PC Plus which is like PC but with 8GB eMMC and WiFi ;) with external RTL8211E GbE then this would be my best buy (below EU VAT redemption)
<jrg> that made me laugh
<jrg> Orange Pi Plus raspberry pi 2 cubieboard banana pi
<tkaiser> longsleep: Pretty good. But most patches didn't land yet.
<NiteHawk> apritzel: don't know if you noticed already, but the sunxi-next patchset apparently found its way upstream now
jernej_ has quit [Ping timeout: 252 seconds]
Zliba has left #linux-sunxi ["Leaving"]
nove has quit [Quit: nove]
tkaiser has quit [Quit: jIRCii - http://www.oldschoolirc.com]
<apritzel> NiteHawk: yeah, saw that
<apritzel> so we are "Trying to boot from FEL" now?
<apritzel> ;-)
<NiteHawk> galore! :D
Mr__Anderson has quit [Remote host closed the connection]
pietrushnic`away is now known as pietrushnic
Netlynx has quit [Quit: Leaving]
Ultrasauce has quit [Read error: Connection reset by peer]
jstein has quit [Ping timeout: 240 seconds]
<jrg> well.. banana pi seems a lot more stable at 1.2GHz
<jrg> that's a shame i lose 800MHz/core... well .. realistically 600
xcasex has quit [Changing host]
xcasex has joined #linux-sunxi
jrg has quit [Quit: ZNC - http://znc.in]
jrg has joined #linux-sunxi
Ultrasauce has joined #linux-sunxi
naobsd has quit [Remote host closed the connection]
naobsd has joined #linux-sunxi
keh has joined #linux-sunxi
<apritzel> NiteHawk: ssvb: this rmr64 is really great: ./sunxi-fel -v -p u-boot-3264.bin rmr64 0x4a000000
<apritzel> works as well as:./sunxi-fel -v -p u-boot-3264.bin write 0x44000 bl31.bin rmr64 0x44000
JohnDoe8 has quit [Quit: KVIrc 4.9.2 Aria http://www.kvirc.net/]
ganbold has joined #linux-sunxi