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
<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)
<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>
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_: 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?
<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)
<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>
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.]
<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 :)
<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
<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
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
<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
<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>
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>
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)