<wens>
montjoie: did you get hans' reply on h3 emac internal phy?
cnxsoft has joined #linux-sunxi
sdschulze has quit [Ping timeout: 244 seconds]
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
ninolein has quit [Ping timeout: 240 seconds]
ninolein has joined #linux-sunxi
lvrp16 has joined #linux-sunxi
kurain has quit [Quit: Ex-Chat]
<lvrp16>
has any1 tried 4k30 on the pi pc or pi one?
<lvrp16>
orange*
<lennyraposo>
dunno as i am boardless
orly_owl_ has quit [Quit: leaving]
orly_owl has joined #linux-sunxi
<lennyraposo>
is it suppose to support 4k at 30fps?
<lvrp16>
apparently
<lvrp16>
i haven't taken a good enough look myself, project for this weekend
lvrp16 has quit [Ping timeout: 252 seconds]
lvrp16 has joined #linux-sunxi
p1u3sch1 has quit [Ping timeout: 240 seconds]
p1u3sch1 has joined #linux-sunxi
souther has quit [Ping timeout: 240 seconds]
<montjoie>
wens: yes
<wens>
i can take care of that bit if you want
IgorPec has joined #linux-sunxi
reev has joined #linux-sunxi
mozzwald has quit [Ping timeout: 240 seconds]
JohnDoe_71Rus has joined #linux-sunxi
reev has quit [Quit: Leaving]
mozzwald has joined #linux-sunxi
reev has joined #linux-sunxi
reinforce has joined #linux-sunxi
<montjoie>
wens: if you want, but I am not convinced that a phy driver is the best
<montjoie>
I will answer the mail
<montjoie>
we speak about the systemcontrol registe rigth ?
<wens>
yes
<wens>
i'm up for suggestions, hence the email :)
<montjoie>
for me we just use it for choosing PHY interface, so it is not a PHY driver (handling a specific PHY ID)
<montjoie>
the only weird bit is the LED_POL that is not really a part of aclk_driver
<montjoie>
or we can simply give a second iomem to the EMAC driver
<montjoie>
I will write that on the email
<montjoie>
but H3 and a83t is different
Incursion has joined #linux-sunxi
<wens>
montjoie: for a83t it is simple, just use the gmac clk driver
<wens>
for h3, sharing the system control register between 2 drivers is a pain
<wens>
and PHY driver probably means generic PHY (drivers/phy), not ethernet PHY (drivers/net/phy)
<wens>
it is not matched by PHY ID, but by DT node
<wens>
i.e. a platform driver
<montjoie>
I will read them
premoboss has quit [Ping timeout: 244 seconds]
premoboss has joined #linux-sunxi
<lennyraposo>
I thought you were tackling just the mac not the ethernet phy?
<lennyraposo>
is there an android / bsp release for the h3?
<lennyraposo>
to get the dt from and help decipher it further ( from what I noticed the dts seems pretty bare)
<lennyraposo>
?
<lennyraposo>
exxcus eme if I sound lie a totla newb in these matters
<lennyraposo>
figured it would be a good starting point
<wens>
lennyraposo: the orange pi's use the internal phy, so you need to configure it to test the mac :p
<lennyraposo>
unlike the pine in otherwords which has the realek phy
<lennyraposo>
and mac handled by soc
<lennyraposo>
realtek
<lennyraposo>
sorry
<lennyraposo>
I keep missing keys here
<lennyraposo>
on the lappy
premoboss has quit [Read error: No route to host]
tomboy64 has quit [Ping timeout: 246 seconds]
tomboy64 has joined #linux-sunxi
hansg has joined #linux-sunxi
<hansg>
mripard_, wens about the axp209 gpio driver vs pinctrl, have you seen my later mail in the thread ?
<hansg>
Basically we already have a problem with this now, since the axp20x-regulator drivers already supports the ldoio regulators and it bangs the mux bits on regulator on/off
<hansg>
This means that any settings done through the gpio interface are undone at the end of kernel init when unused regulators get turned off
<wens>
my initial idea is that each ldo_io regulator would have on/off pinctrl settings, and toggle those, instead of touching the gpio register
tomboy64 has quit [Ping timeout: 244 seconds]
yann|work has quit [Ping timeout: 260 seconds]
<hansg>
Ok, I've no idea how that would look like, or if it will work, bit it may be a potential solution :)
<hansg>
mripard_, unrelated, can you push your current dt queue as a branch somewhere I would like to do a fixup for the led / gpio keys for the orangepi plus and I want to avoid conflicts
<hansg>
I tried rebasing my set on top of sunxi/dt-for-4.6 but that becomes a bit of a mess
Worf has joined #linux-sunxi
diego_r has joined #linux-sunxi
<wens>
yikes, explosion at brussels airport
<plaes>
:(
<hansg>
Ugh, Brussels is less then 2 hours by train from here ...
alain_ has joined #linux-sunxi
<alain_>
montjoie: hi, let me know if you want to do further tests with the emac driver on the orange pi plus
reinforce has quit [Remote host closed the connection]
avph has quit [Ping timeout: 246 seconds]
reinforce has joined #linux-sunxi
avph has joined #linux-sunxi
yann|work has joined #linux-sunxi
The_Loko has joined #linux-sunxi
ricardocrudo has joined #linux-sunxi
paulk-leonov has joined #linux-sunxi
libv_ is now known as libv
JohnDoe_71Rus has quit [Ping timeout: 246 seconds]
<tipo>
what is a mainline bsp? it doesn't really explain what it is
simosx has joined #linux-sunxi
<tipo>
can I use this to get kernel 4.2 and run debian sid? i'd really like to run sid, regardless of kernel
<rellla>
tipo: ask sinovoip
<plaes>
it's basically an ugly hack ;)
apritzel has joined #linux-sunxi
lamer14586414127 has joined #linux-sunxi
lamer14585850198 has quit [Ping timeout: 244 seconds]
enrico_ has joined #linux-sunxi
<mripard_>
hansg: pushing right now
<mripard_>
beware, it's going to be rebased
iamfrankenstein has quit [Quit: iamfrankenstein]
Worf has quit [Quit: Konversation terminated!]
<mripard_>
hansg: and I was going to reply later today, but yeah
tomboy65 has joined #linux-sunxi
<mripard_>
I think your ptaches to mark the regultors disabled were a good idea to work around that
<mripard_>
in combination with pinctrl
sdschulze has joined #linux-sunxi
tomboy64 has quit [Ping timeout: 264 seconds]
bgardner has quit [Quit: leaving]
alain_ has quit [Ping timeout: 252 seconds]
bgardner has joined #linux-sunxi
iamfrankenstein has joined #linux-sunxi
lamer14586439992 has joined #linux-sunxi
hansg has quit [Remote host closed the connection]
hansg has joined #linux-sunxi
lamer14586414127 has quit [Ping timeout: 244 seconds]
<hansg>
mripard_, thanks for pushing the branch.
alain_ has joined #linux-sunxi
<mripard_>
hansg: while you're there, do you know what the auto detection registers in the TV encoder are about ?
<alain_>
hansg: can I just take your latest u-boot-sunxi and dd it to my Orange Pi Plus emmc and expect it to work? (It already sees the emmc when booted from a SD card)
<montjoie>
alain_: sorry I lag, I need to check that I get all wens patchs
FlorianH has quit [Ping timeout: 276 seconds]
<alain_>
Mainline support for the Orange PI Plus is coming along quite nicely, I'll soon be able to ditch the ugly Allwinner 3.4.39 kernel
<montjoie>
I have setup a github repo for releasing my patchs http://github.com/montjoie/linux/ I will put it EMAC patchs this afternoon
<alain_>
montjoie: thanks a lot, I'll check this out tonight and will let you know how it goes
FlorianH has joined #linux-sunxi
paulk-leonov has quit [Quit: Quitte]
hp197 has joined #linux-sunxi
sdschulze has quit [Ping timeout: 252 seconds]
kaspter has quit [Ping timeout: 250 seconds]
alain_ has quit [Ping timeout: 252 seconds]
nemunaire has quit [Quit: quit]
iamfrankenstein has quit [Quit: iamfrankenstein]
nemunaire has joined #linux-sunxi
Gerwin_J has joined #linux-sunxi
apritzel has quit [Read error: Connection reset by peer]
sdschulze has joined #linux-sunxi
rtp has joined #linux-sunxi
afaerber has quit [Quit: Ex-Chat]
<hansg>
mripard_, I *think* they are load detection bits and can be used to detect if a vga resp. composite cable is plugged in.
<mripard_>
yeah, it's what I was thinking too
<mripard_>
but I can't have it to work
<hansg>
Same for me, I tried but I couldn't get them to work either
<mripard_>
ie report the composite cable as plugged when it's actually plugged
<tkaiser>
Seppoz: No, not even a maintainer willing to keep track of changes. There are mostly identical patches available in jernej's OpenELEC repo and in Armbian's
<Seppoz>
ok
<Seppoz>
any news about allwinner a40 availiable?
<willmore>
montjoie, the datasheet that jernej mentions says "v1.2 Add the programming guide of crypto engine", FYI.
<willmore>
Oh, wait, you were doing crypto on a Pine?
<willmore>
Oh, no, it was cubieboard2--had to scroll.
<tkaiser>
jernej: Thx, uploaded and added the datasheet to H3 page
<NiteHawk>
tkaiser: you beat me to it :P
<jernej>
tkaiser: No problem.
<lvrp16>
probably useful for montjoie?
<lvrp16>
"v1.2 Add the programming guide of crypto engine"
<lvrp16>
oh sorry didn't see ur thing willmore
<willmore>
lvrp16, LOL.
<lvrp16>
ADD
<willmore>
It's all good.
IgorPec has joined #linux-sunxi
<tkaiser>
BTW: Orange Pi PC Plus (what a naming scheme) is also announced with '8 GB Flash + wifi' (using 8189ftv) for $5-$6 more than OPi PC
<lvrp16>
i've spoken with steven a dozen times about his naming convention
<lvrp16>
he refuses to listen to me
<lvrp16>
*smh*
<jernej>
They also removed bit 23 and 22 description in chapter 5.3.7.8 SD Command Argument Register.
<vagrantc>
tkaiser: is that not to be confused with the Orange Pi Plus (or Orange Pi Plus2) ?
* willmore
is waiting for the plus plus
<vagrantc>
double plus good
<lvrp16>
chinese people...
<willmore>
Remember, the plus plus two and the two plus plus are different boards...
<lvrp16>
stubborn as hell
<lvrp16>
mostly talking about myself...
IgorPec has quit [Ping timeout: 246 seconds]
mozzwald has quit [Quit: leaving]
LostSoul_ has quit [Ping timeout: 244 seconds]
<NiteHawk>
lvrp16: do you know of an 'official' M2 EOL announcement? or asked differently: is the M2+ intended to replace the previous M2?
<tkaiser>
vagrantc: Xunlong has then 8 H3 based boards all called Orange Pi and still people are confused since before there were 2 other A20 based Orange Pis available
LostSoul has joined #linux-sunxi
avph has quit [Ping timeout: 246 seconds]
<lvrp16>
allwinner still has tons of a31s left, as for boards, sinovoip is slow to build boards because sales have been mediocre
<lvrp16>
they're only making small batches available
<lvrp16>
M2+ is more cost effective to build than the M2, i think they're phasing it out just like the M1 with the M1+
<lvrp16>
but i don't think it's EOL
<lvrp16>
well, it depends on what you consider EOL...you can say the product was EOL when it launched
<lvrp16>
asking their engineer for anything is like pulling teeth
Gerwin_J has quit [Quit: Gerwin_J]
<NiteHawk>
i see - so you were primarily referring to Allwinner no longer producing new A31(s)
<tkaiser>
lvpr16: But they still sell the M1? And also LeMaker sells still the same model (without 'M1' in its name)
<lvrp16>
i mean from sinovoip's end
<lvrp16>
lemaker is completely different
<tkaiser>
I know, but it seems they had some strange contracts (at least last year). When I bought the crappy M2 it was only possible through the german LeMaker distributor
avph has joined #linux-sunxi
LostSoul has quit [Ping timeout: 276 seconds]
<lvrp16>
they have very limited inventory
<lvrp16>
like VERY
mozzwald has joined #linux-sunxi
<lvrp16>
from my experience with them, they had under 3k boards at all time. their M3 boards were limited production run too
LostSoul has joined #linux-sunxi
<lvrp16>
when it was launched, only 200 boards hand soldered
<lvrp16>
their first production run was 1-2k
<tkaiser>
Now they announced to produce a 10k batch (with barrel plug connector for DC-IN)
<lvrp16>
now that odroid c2 is out, not much market for m3
<lvrp16>
god damn, they keep switching it
<lvrp16>
i constantly have to change my stock photos
<tkaiser>
lvrp16: Since pictures from M2+ pre-release samples showed a barrel connector I'm almost sure they replace it with Micro USB before production starts ;)
<tkaiser>
Just to annoy customers :)
<lvrp16>
US market is full of Raspberry Pi based power supplies
<lvrp16>
there's no high quality barrel power supplies
<lvrp16>
we make an adapter from microusb to 4.0x1.7mm as a hack
<tkaiser>
But that's also insufficient for a BPi M3, too powerful
<lvrp16>
have you measured the current for the M3?
<tkaiser>
BTW: Same story now with Pine64, many complaints about instabilities all caused by crappy USB cables and Micro USB for DC-IN
diego_r has quit [Ping timeout: 276 seconds]
<zoobab>
there is a reason why Olimex prefers barrel connectors
<lvrp16>
I made power supplies that can handle 2.5A burst and 2A consistent via microUSB
<lvrp16>
to prevent issues
<lvrp16>
starting voltage is a little high at 5.4V
<lvrp16>
but at 2.5A, it only drops to 4.9V
<tkaiser>
And people use cellphone chargers and cables from hell. And have no idea why freezes/crashes occur :)
<lvrp16>
haha exactly, i put many social media noticies about current draw of this generation of SBC
<lvrp16>
i see why lemaker is doing 9v and higher
<lvrp16>
for their boards, i can't wait for AMD's boards
<lvrp16>
these little suckers are going to replace traditional PCs soon
<edolnx>
I've already ordered two of the AMD boards to replace servers with. So excited.
<edolnx>
Does anyone have power numbers for the Pine64 yet? I'm building a headless cluster, so my use case is a bit odd
<lvrp16>
~1A
<lvrp16>
without peripherals and without driving a long ethernet run
HeavyMetal has joined #linux-sunxi
HeavyMetal has joined #linux-sunxi
<tkaiser>
edolnx: Depends on what you want to run on the board. Using ssvb's cpuburn-a53 you can demonstrate the crappyness of Micro USB within milliseconds
<edolnx>
OK, good to know. I'm building a custom power management system for all 20-40 Pine64s I'm going to have in a chassis. It's going to be a short CAT5e run (2ft), MicroSD card, and a Serial console.
<tkaiser>
Emergency shutdown. I had to use the Euler connector for our test runs.
<willmore>
Ahh, okay. I just bought some boards from you last week. ;)
<edolnx>
Not yet, but my order locked. The official posts in the forum say March locked orders are shipping within 2 weeks.
<willmore>
Very fast shipping, thanks!
<lvrp16>
glad you enjoy our service
<lvrp16>
we mostly sell into schools
<tkaiser>
lvrp16: the new Orange Pi uses H64 or A64?
<lvrp16>
aren't they the same silicon?
<edolnx>
tkaiser, Yeah, the chassis is going to have a lot of air movement and be in a data center so I should be good for now. Power Management and cooling has been problematic with every ARM board I've used so I'm over engineering the chassis to compensate. I also need to find some heatsinks for these boards.
bonbons has joined #linux-sunxi
<tkaiser>
That's what I would suspect
<tkaiser>
edolnx: I made some tests and even a cheap heatsink is way more efficient than blowing air from here to there. In the Pine64 forums, Linux development, Benchmark thread
<lvrp16>
tkaiser: not sure, i always thought they were the same
<edolnx>
tkaiser, good to know, thanks for the tip!
<edolnx>
I believe the H64 was the pre-release name for the A64, at least that's what I've found.
<tkaiser>
edolnx: I tested worst case conditions (crappy enclosures) and with a heatsink performeance (throttling jumping in way later) improved a lot.
<lvrp16>
tkaiser, you're in germany?
<lvrp16>
what do you do professionally?
<tkaiser>
Yes
<tkaiser>
Server stuff and optimisations for the graphical industry
yann|work has quit [Ping timeout: 246 seconds]
<lvrp16>
amd/nvidia/intel?
<lvrp16>
imagination?
<tkaiser>
And now starting with SBC stuff in a professional way.
<tkaiser>
Neither/nor/don't care ;)
jernej has quit [*.net *.split]
alain_ has quit [*.net *.split]
<lvrp16>
i started the SBC business because i see a convergence point in the near future, plenty of opportunities in this space
<lvrp16>
i know you and igor work on armbian
<lvrp16>
could follow the mozilla model and make nice coin
<lvrp16>
idk if thats your motive at all or you just like this stuff
<tkaiser>
Still don't know. At least it's fun
<lvrp16>
i'm just waiting for linux to crush windows in the next 5 years
nove has joined #linux-sunxi
khuey is now known as khuey|away
<lennyraposo>
intersting statement lcrp16
<lennyraposo>
linux is crushing windows in many ways
<lvrp16>
most x86 vendors see the light
<lennyraposo>
the problem area is desktop environment
<lvrp16>
idk why ARM and Imagination are still backwards
<lennyraposo>
there si way too much vendor lock
khuey|away is now known as khuey
<lvrp16>
google and cloud are moving traditional services onto the web
<lvrp16>
so the browser is essentially becoming the OS
bwarff_ has joined #linux-sunxi
<lennyraposo>
something I always found to be frightening
<lvrp16>
the actual underlying OS is slowly becoming irrelevant
<lennyraposo>
not really
<lvrp16>
plus, microsoft constantly decides to shoot itself in the foot
<lennyraposo>
very true
<lvrp16>
with DX12, with their constant invasion of privacy
<lennyraposo>
agreed there
<lvrp16>
they're trying vendor lock when they're the minority
<lennyraposo>
sor tof like ccanonical and the whole amazon/web search integration
<lvrp16>
yeah thats the first thing i disable
<lennyraposo>
forgot disabling just avoid it
<lennyraposo>
use the os that it is based off Debian
<lennyraposo>
;)
fredy has quit [Excess Flood]
<lennyraposo>
I ran a cluster of ubuntu 12.04
<lvrp16>
yes, but ubuntu is good for some things
IgorPec has joined #linux-sunxi
<lennyraposo>
well with it's exposure it has attracted lots to come over
<lennyraposo>
introduces linux to the masses in many ways
fredy has joined #linux-sunxi
<lvrp16>
yes, although i still need to work my head around systemd
<lennyraposo>
same here
<lvrp16>
the last 5 years of startup scripts are upstart based haha
<lvrp16>
so i know that inside outside and backwards
<lvrp16>
systemd does many many things, so many many learning curves
<lennyraposo>
it's nto difficult but still when you get use to something and then it is changed it's a bummer to relearn something your were proficient in
<lennyraposo>
but that's the ecosphere ;)
<lvrp16>
how do you run ssvb's cpu burn?
<lvrp16>
oh nvm
<lennyraposo>
but comparing 12.04 with wheezy (same hardware and same setup) I found debian ran more smoothly and was less resource intensive
<lennyraposo>
generally snappier
bwarff_ has quit [Ping timeout: 244 seconds]
<lvrp16>
desktop or server?
<lennyraposo>
server wise
<lennyraposo>
even desktop I noticed performance gains when comparing desktop enviros
<lennyraposo>
debian mate vs ubuntu mate
<lvrp16>
i constantly get memory leaks because of nvidia/compiz
<lvrp16>
14.04 unity
<lennyraposo>
unity is pretty ugly at times
<lennyraposo>
well nvidia has been a bit of pain in recent times
<lvrp16>
amdgpu is a step in the right direction
<lennyraposo>
which thankfully has brought AMD a little mroe in the spotlight
mzki has quit [Quit: leaving]
<lvrp16>
now if only arm would do the same
<lvrp16>
because mali gpu's are used everywhere except in iphones
<lvrp16>
and now apple might buy imagination
<lvrp16>
which leaves linux support improbable
<edolnx>
tkaiser, what are you using for generating these benchmark and monitoring charts? Is it just a built-in for PTS?
<lvrp16>
environment variables
<lvrp16>
MONITOR=gpu.temp,sys.power,cpu.temp
<lvrp16>
when you run pts
<edolnx>
thanks
<lennyraposo>
if all goes well I should have a pine64 board as tomorrow
<lennyraposo>
keeping fingers crossed
<lennyraposo>
I will then be able to get into the fight and start testing
<tkaiser>
You will be surprised how bad your cpuminer scores get when you chose the wrong thermal 'design' ;)
sdschulze has quit [Ping timeout: 240 seconds]
<tkaiser>
The PTS does only monitor temperature as far as I know and forgets to monitor the most important part as well: how throttling starts to render the results useless
<tkaiser>
But I might be wrong since most of the benchmarks are crap anyway
bwarff_ has joined #linux-sunxi
enrico_ has quit [Quit: Bye]
<tkaiser>
So I didn't had a closer look at the PTS at all
apritzel has joined #linux-sunxi
jernej has joined #linux-sunxi
tomboy64 has joined #linux-sunxi
Netlynx has joined #linux-sunxi
apritzel has quit [Ping timeout: 244 seconds]
<montjoie>
Interesting the crypt engine guide in 1.2 datasheet
<montjoie>
thanks willmore
bwarff_ has quit [Ping timeout: 244 seconds]
lamer14586714001 has joined #linux-sunxi
lamer14586714001 has quit [Client Quit]
lamer14586714324 has joined #linux-sunxi
tkaiser has quit [Ping timeout: 276 seconds]
dev1990 has joined #linux-sunxi
yann|work has joined #linux-sunxi
<jernej>
They also removed any reference to async crypto
The_Loko has quit [Quit: Leaving]
<montjoie>
in which page ? since H3 have only DMA it will be async
FlorianH has quit [Read error: Connection reset by peer]
<montjoie>
oh ok, no more RSA
<jernej>
oh, I mean asymetric like RSA, etc. Sorry for confusion
<montjoie>
that's a huge remove of functionnality
<jernej>
Did you experience some problems with asymetric crypto?
<montjoie>
I didnt start to work on it, my basic driver for aes didnt work
alain_ has joined #linux-sunxi
afaerber has quit [Quit: Ex-Chat]
ricardocrudo has quit [Remote host closed the connection]
jstein has joined #linux-sunxi
avph has quit [Ping timeout: 246 seconds]
<longsleep>
tkaiser: did you get any more emergency shutdowns with 108C Pine64 critical trip point?
avph has joined #linux-sunxi
lamer14586714324 has quit [Ping timeout: 240 seconds]
lamer14586714324 has joined #linux-sunxi
alain_ has quit [Ping timeout: 250 seconds]
mossroy has joined #linux-sunxi
<willmore>
montjoie, you're welcome. I look for things...
<lvrp16>
does the a64 suffer from the same hot spot issue as the pi 3?
iamfrankenstein1 has joined #linux-sunxi
<lvrp16>
pine a64
iamfrankenstein1 has quit [Client Quit]
<lvrp16>
where the a53 cluster gets really hot?
<lvrp16>
while the rest of the chip is 20C lower
iamfrankenstein has quit [Ping timeout: 244 seconds]
iamfrankenstein has joined #linux-sunxi
<tkaiser>
lvrp16: AFAIR the only thermal considerations so far can be read in this aforementioned Github thread solely relying on the thermal sensor _somewhere_ inside A64
akaizen has joined #linux-sunxi
<tkaiser>
Since the thermal throttling code takes care of both 'GPU' and CPU I hope they placed the sensor somewhere in between
<lennyraposo>
who knows
<lennyraposo>
was reading about the linux foundation and AllWinner
<lennyraposo>
makes me laugh
<lennyraposo>
not at AW but the foundation
<lennyraposo>
seems like a useless entity/group
<lvrp16>
wow the trottling mechanism on armbian5.05 for orange pi one is near perfect
<lvrp16>
goes to 90C, then trottles immediately, not like the rpi3 crap where it shoots to 100C+
<lvrp16>
just tested with my flir camera
<lennyraposo>
here you have AW not really complying with LF's standards but gets to keep it's membership
<lvrp16>
allwinner is chinese company, if they don't get sued, they're going to continue what they do
bonbons has quit [Quit: Leaving]
<lvrp16>
it's basics of business in china
<lvrp16>
until the cost exceeds the cost of compliance, they're going to pay the cost
<tkaiser>
lvrp16: I would suspect you could adjust the throttling behaviour also on RPi 3. It's just adjusting a few numbers (after spending hours/days of testing)
<lennyraposo>
is the rpi3 really that bad?
<lvrp16>
the pi 3 thermal sensor is misplaced...
<lvrp16>
not much you can do when you can't sense the real temp
<tkaiser>
lvrp16: Ok, then I understand. But it could also be a software issue. When I played with Pine64 undervolting I f*cked up longsleep's throttling settings completely ending up with a board doing emergency shutdowns
<lennyraposo>
other than adding fine print of + or - 10 degrees to the documentation
<lennyraposo>
;)
bwarff_ has joined #linux-sunxi
avph has quit [Ping timeout: 246 seconds]
<longsleep>
i tried to replace a RPi1 with a RPi3 - was total fail as the thing got so hot inside the IKEA box i have (together with other things which get hot as well)
<longsleep>
so ambient temperature above 50C no good
<tkaiser>
longsleep: Underclocking to the limit!
<tkaiser>
Seriously that's what we do with most of the H3 boards around. Limiting max cpufreq to either 600 or 648 (on the One)
<longsleep>
yeah, i stick to the RPi 1 and might eventually replace it with a ODROID-C2 which stays at 70C max no throttling what so ever
mossroy has quit [Quit: Quitte]
avph has joined #linux-sunxi
<longsleep>
or the Pine64 2GB model when i get it
<apritzel>
longsleep: so the Odroid-C2 stays cool even under full (quad-core) load at 2 GHz?
<lvrp16>
tkaiser: the pi 3 temp sensor can be 25C off from the A53 cluster temp. I think it's located around the GPU.
<lvrp16>
apritzel, the c2 will throttle to 1.2GHz
<tkaiser>
apritzel: Nope, no one tried cpuburn-a53 so far ;)
<lvrp16>
i can try it right now
<longsleep>
apritzel: well i wouldnt say cool, but yes cpuburn-a53 is below 70C in my testing with a good heat sink
<lvrp16>
maybe later
<willmore>
lvrp16, my Opi1 boards throttle and then drop cores. They don't ever seem to re-enable those cores.
<tkaiser>
willmore: You're using the wrong software/settings
iamfrankenstein has quit [Quit: iamfrankenstein]
akaizen has quit [Remote host closed the connection]
<longsleep>
apritzel: did not have time for a real long test run yet though
<willmore>
tkaiser, that's what I figured. I read on the armbian forum how cores are supposed to get re-enabled after things cool down, so I was surprised mine didn't behave that way.
<tkaiser>
longsleep: apritzel: If the Pine64 folks would also ship with a huge heatsink like Hardkernel we might not even notice these problems ;)
<willmore>
I'm using 5.05 with current packages.
<longsleep>
tkaiser: yes, did tllim ship you one of their sample heatsinks already?
<tkaiser>
willmore: Killing cores is only the last resort so you ran into really heavy overheating problems. Do you use a heatsink?
<willmore>
apritzel, the c2 stays under 80C even with all cores running burncpu.
<tkaiser>
longsleep: Nope, he didn't answer my question in the forums whether the heatsink takes care of the different height of DRAM and SoC (it it does not it's rather useless)
<longsleep>
tkaiser: mhm i think they want to use two different pads
<willmore>
Are the Allwinner chips 28nm or 40?
bwarff_ has quit [Ping timeout: 244 seconds]
<lvrp16>
28nm
<apritzel>
willmore: that's the million dollar question ;-)
<apritzel>
they advertise the A64 as 28nm, but we suppose it's really 40nm
<willmore>
Okay, that might be another factor against the Pi3 which is at 40nm--the die is a lot larger and the temp sensor will be 'farther away'.
<willmore>
apritzel, ahh, okay, didn't realize there was that kind of issue.
<tkaiser>
willmore: According to TL Lim A64 is 40nm (cites an Allwinner PM) and I would suspect the same is true for H3. And Allwinner never said anything regarding this, only 3rd parties
<willmore>
tkaiser, thanks for the clarification.
<longsleep>
well, the SoC package RPi3 vs A64 as on the Pine64 are of similar size
<longsleep>
(physical)
<willmore>
tkaiser, what bit of code is responsible for re-enabling cores on armbian? I'll go see if mine are setup correctly.
<longsleep>
RPi3 is a little smaller looking at it side by side
<willmore>
longsleep, that is probably just driver by I/O needs.
<tkaiser>
willmore: There is none, you'll have to look into longsleep's A64 images since he coded a q&d core-keeper service bringing back the cores.
<tkaiser>
willmore: The settings can be read out using bin2fex using /boot/script.bin. But I would suspect using a cheap heatsink will solve the problem instead
<lvrp16>
tkaiser, are you sure h3 is 40nm? because a31 was huge
<lvrp16>
almost 2x the size of h3
<lvrp16>
i thought h3 was just a glorified a33
<longsleep>
tkaiser: btw, the C2 switches off at 110C, i think we can go there for the Pine64 as well
<tkaiser>
lvrp16: I'm not sure but clueless :) I just thought about A64 being an H3 with less USB ports and Cortex-A53 instead of A7
<lennyraposo>
wonder how they got the frequencies to 2ghz
<tkaiser>
longsleep: So what do you propose? Increasing the 108¡C to 110¡C?
<lvrp16>
giant heatsink :D
<lvrp16>
theres LP processes and HP processes
<lennyraposo>
the rpi3 is at 1.2 ghz too
<longsleep>
tkaiser: yes and increate the trip point before by 5C
<lennyraposo>
so 110 105 100 95 and 90
<lennyraposo>
?
<lvrp16>
the allwinner h3 should be built on the tsmc 28nm lp process
<lvrp16>
amlogic s905 probably on the hpl
<tkaiser>
longsleep: I would wait for an answer from ssvb since 'tuning' the stuff he mentioned seems to be worth a look. And I won't start my test setup (noisy as hell) unless really needed
<lennyraposo>
is this powered thru the micro usb or other?
<lennyraposo>
with the current trip points?
<longsleep>
lennyraposo: no, t3 is currently at 95, i want to increase this to 100
<tkaiser>
lennyraposo: That's unrelated. Using Micro USB just means that load peaks might power off the board immediately
<longsleep>
lennyraposo: its more like 110, 100, 90, 85, 80
<lennyraposo>
oh
nove has quit [Quit: nove]
<lennyraposo>
som from 90 onwards you are increasing by 10c not by increments of 5
<longsleep>
tkaiser: agreed, it works good for normal use in my heat box with the current settings
bwarff_ has quit [Ping timeout: 244 seconds]
<longsleep>
lennyraposo: yes, currently its 108, 95, 90, 85, 80
tkaiser has quit [Ping timeout: 244 seconds]
bwarff_ has joined #linux-sunxi
tkaiser has joined #linux-sunxi
<longsleep>
Regarding the PSU issues people have with Pine64, is it just my impression or is that a bigger problem with the Pine64 than it was before with other boards?
<lennyraposo>
having no experience with the actual board at this moment I wouldn't know
<lennyraposo>
but from what I ahve been reading it appears to be an issue
<tkaiser>
longsleep: At least with BPi M3 the same happened. People complaining about sudden freezes, reboots, corrupted SD cards. I think that's quite normal (also with RPi where this Micro USB mess started)
<willmore>
tkaiser, okay, I will go look.
<willmore>
tkaiser, I have the heatsink that lvrp16 ships with their Opi1 boards and it made little difference vs the naked one.
<lennyraposo>
should build an adapter for the pins
<lennyraposo>
to provide power in that manner
<lennyraposo>
seems liek it is stable
<tkaiser>
Add display problems on top and that the Pine folks exchanged the green led with a red one for the production samples (red == something's wrong) and you get the idea
<longsleep>
tkaiser: mhm yeah probably just me then as i got more involved and reading about it
<willmore>
The A905 is 28nm.
<longsleep>
tkaiser: yeah i find that red vs green particularly funny, did not even notice that one was green and the other red until i saw that people are complaining that the LED is red
<tkaiser>
willmore: In case you have a multimeter you could measure test point TP1
<tkaiser>
Should show 1.1V at 648MHz and 1.3V at higher clockspeeds.
<willmore>
tkaiser, I do and I will.
<willmore>
Heading out the door right now, though. :)
<lennyraposo>
I have a multimeter too
<lennyraposo>
messaged regarding trackign number fo rdev board shipment
<lennyraposo>
hopefully I cna trakc it tomorrow as it should be in canadian borders by now
<longsleep>
tkaiser: btw, i am pretty sure the ODROID-Cs also have a red power LED - so thats not so uncommon
<tkaiser>
longsleep: Sure, with Orange Pis it is/was also like this. We just recently changed that to green in Armbian since we wanted to remain compatible to the H3 OpenELEC fork.
<tkaiser>
And the colour doesn't matter if you successfully booted the board a few times. But if you don't see any progress then red is a warning signal
ricardocrudo has joined #linux-sunxi
<longsleep>
tkaiser: Orange Pis have a RGB LED or what?
<lvrp16>
willmore: the heatsink increases the surface area by 6x, but if there's no air flow, it will not make much difference
<lennyraposo>
whcih is another issue we face with pine
<lennyraposo>
those enclosures shoudl anyoen go for them regarding linux boxes
<tkaiser>
longsleep: A green and a red one. And the red one was set to be active on all OS images so far until jernej changed this in his OpenELEC fork. Now we both activate the green one to signal 'power on' and use the red one for 'suspend to RAM'. Or at least we used it since Jernej removed all the suspend/resume stuff since it seemed to be responsible for stuttering video
<longsleep>
tkaiser: ah interesting, thanks for the details
<lennyraposo>
also
<lennyraposo>
battery for the pine
<lennyraposo>
if I read correctly will not be charged by the board currently?
<lennyraposo>
or is it entirely useless
<tkaiser>
lennyraposo: A64 is accompanied by a PMIC that will be responsible for power management and also charging the battery. At least it works this way on every other Allwinner SoC so far with PMIC
<tkaiser>
longsleep: That's nice on all the 7 or 8 different Orange Pi boards: Xunlong/Steven is smart enough to use identical pin mappings where it's reasonable
<longsleep>
tkaiser: i never tried any of the Pi clones :/
<tkaiser>
Therefore mainline u-boot settings for the PC work on all boards except the Plus and regarding DT stuff it's almost the same (just Orange Pi 2/Mini being the exception since here USB config is a bit different but otherwise identical to PC settings)
bwarff_ has quit [Ping timeout: 244 seconds]
bwarff_ has joined #linux-sunxi
paulk-collins has quit [Remote host closed the connection]
<tkaiser>
longsleep: Out of curiosity: You said you will use a couple of Pine64 as cluster?
iamfrankenstein has joined #linux-sunxi
<longsleep>
tkaiser: yes for arm and arm64 compiling
<longsleep>
tkaiser: in clean environment via qemu with kvm
<longsleep>
tkaiser: actually doing it already (with a single board)
ricardocrudo has quit [Remote host closed the connection]
<tkaiser>
Why not cross-compiling on x86?
<longsleep>
tkaiser: does not work for everything
<tkaiser>
Ok, understood
<longsleep>
tkaiser: in addition i use it for automated image testing and packaging testing
<longsleep>
tkaiser: running on x86 in qemu takes about 20 hours - running on Pine64 in KVM is about 1 hour for the same amount of tests
<lvrp16>
longsleep, i usually keep around 100 units of every board i sell
<lvrp16>
if you ever need a cluster, i can give you remote ssh access
<lvrp16>
if that's sufficient for your need, so you dont' have to build a cluster ;)
<longsleep>
lvrp16: well, i need to have full control of the platform for security reasons
<lvrp16>
ah ok
<tkaiser>
longsleep: I start to understand (spreedbox), thx
<longsleep>
lvrp16: what do you do with those 100 boards usually, i am especially interested in how you (rack) mount them and supply them with power
<longsleep>
tkaiser: yes for example
<tkaiser>
longsleep: LOL, and now I understand also your concerns about heatsink by default on the ODROIDs
<longsleep>
tkaiser: :) yeah really annoying
<lennyraposo>
400 core cluster
<lennyraposo>
interesting
<lennyraposo>
I was just aimign for a simple hsoting cluster
<lennyraposo>
maybe 10 boards
<lennyraposo>
is all
bwarff_ has quit [Ping timeout: 244 seconds]
<tkaiser>
longsleep: Slightly off-topic. But does this 'massive heatsink' really shows better thermal results compared to using the standard heatsink on ODROIC-C1/C2 and leaving enough airflow around?
<longsleep>
tkaiser: mhm well it barely gets above 60C with cpuburn-a53 in some quick tests we did with C2 in the Spreedbox enclosure
<tkaiser>
Impressive :)
<lvrp16>
longsleep, usually non-defective RMA, i'm too lazy to resell so they're sitting there.
<lvrp16>
it's easy enough to rack them using standoffs (~10-15 a column) hooked up to a PC PSU to power 30 at a time sitting in a blank u3 chassis.
<lvrp16>
you put a few transistors and resistors together for an active current limit circuit for each board for short circuit protection.
<lvrp16>
gotta be careful picking the power supply because some of them are tied to the v3.3 and v12 rails
<lvrp16>
and will not simply do 20A of v5
<lennyraposo>
I was thinking because of the microusb power connector simple charging hubs myself