<topi`>
well, the title for cheapest NAS soc still goes to A20 :)
<topi`>
and Rockchip hasn't shown any willingness to implement SATA in silicon
FlorianH has joined #linux-sunxi
apritzel has joined #linux-sunxi
<MoeIcenowy>
@mripard Where can I find sunxi kms code now?
<wens>
plaes: i dont have push permission to mripard's repo :p
<wens>
his git.kernel.org next branch only carries sunxi stuff for linux-next
<wens>
sunxi-next over on linux-sunxi is for everyone who want latest stuff but doesn't want to use linux-next
<KotCzarny>
cheapest and bestest
<MoeIcenowy>
but it seems that no pre-configured A20 NASes available
<KotCzarny>
um, apt-get install samba ?
<KotCzarny>
apt-get install nfsd ?
<NiteHawk>
no no, "emerge samba" ;)
JohnDoe_71Rus has quit [Quit: KVIrc KVIrc Equilibrium 4.2.0, revision: 42021, sources date: 20120701, built on: 2013-10-21 12:25:22 UTC 42021 http://www.kvirc.net/]
reinforce has joined #linux-sunxi
<MoeIcenowy>
NiteHawk: and wait for a heat A20
<MoeIcenowy>
:-)
<NiteHawk>
bah, that's not really an issue on A20 :)
<topi`>
agreed, according to a blog post in Olimex.com, it seems the H3 is otherwise
<topi`>
for some reason, the H3 seems to excel at heat production
apritzel has quit [Ping timeout: 246 seconds]
<MoeIcenowy>
cpufreq-utils can solve most problems :p
viccuad has joined #linux-sunxi
FlorianH has quit [Ping timeout: 276 seconds]
paulk-collins has joined #linux-sunxi
Ueno_Otoko has joined #linux-sunxi
FlorianH has joined #linux-sunxi
domidumont has joined #linux-sunxi
domidumont has quit [Remote host closed the connection]
domidumont has joined #linux-sunxi
Netlynx has joined #linux-sunxi
reinforce has quit [Ping timeout: 255 seconds]
apritzel has joined #linux-sunxi
<diego71>
topi`: only because most of the board overclock it (or believe in aw marketing, and use it at very high clock frequency)
<tkaiser>
To sum it up: Use sane dvfs and 'cooler table' settings and take care of heat dissipation and you're done
<ssvb>
topi`: olimex encountered overheating problems with their h3 board, but we have no reasons to generalize this information
Gerwin_J has quit [Quit: Gerwin_J]
reinforce has joined #linux-sunxi
<ssvb>
moreover, they suspect DRAM clock speed being the culprit, but I tried to ask in their blog about the type of DRAM they use and did not get any answer
<ssvb>
and the "Compatible with Raspberry Pi 2" claim is also fishy
<ssvb>
I guess, it is probably normal for Chinese marketing if everyone is doing exactly the same
<tkaiser>
Regarding the 1.6 Ghz in our wiki we still 'share' the same 'information' at many places ;)
<ssvb>
being honest would put them at a disadvantage
<tkaiser>
At least true for SinoVoip and LeMaker regarding cpufreq stuff
<ssvb>
do you mean that the linux-sunxi wiki still lists 1.6GHz for H3 somewhere?
<tkaiser>
The voltage regulatur on the new Orange Pi One/Lite is only able to adjust between 1.1V and 1.3V and they seem to take your recommended frequencies: 624 MHz @ 1.1V and 1200 MHz @ 1.3V
<tkaiser>
Most of the stuff on the other Orange Pi pages is outdated/incomplete since most of us seem to focus on the PC only
<KotCzarny>
is 1.5GHz stable with radiator+fan ?
<tkaiser>
It's beyond specs. Again: Read the link to the linux-sunxi list, ssvb explained everything :)
<ssvb>
KotCzarny: 1.5GHz needs high voltage, which is out of the valid range specified by the H3 datasheet
interrobangd has joined #linux-sunxi
apritzel has quit [Ping timeout: 246 seconds]
<ssvb>
about the H3 CPU clock frequency, probably it's safe to assume that the nominal speed is 1.2GHz and it also can be "turbo boosted" up to 1.3GHz if you can provide good heat dissipation or tolerate occasional throttling
<MoeIcenowy>
yes
<MoeIcenowy>
1.5 may be too high
<MoeIcenowy>
The processor architecture in H3 should be the same as A33
<MoeIcenowy>
(s/should//
JohnDoe_71Rus has joined #linux-sunxi
<ssvb>
don't know, maybe something closer to 1.4GHz at 1.4V is also possible
<MoeIcenowy>
or say "1.5Ghz at your own risk
<MoeIcenowy>
cpufreq-utils can solve all problems
<MoeIcenowy>
:p
pmattern has joined #linux-sunxi
<ssvb>
MoeIcenowy: A33 is supposedly using 40 nm manufacturing process and H3 is using 28 nm, this means that H3 can probably run at a higher clock speed
<tkaiser>
MoeIcenowy: cpufreq-utils alone won't help. The contents of the dvfs table are even more important.
<tkaiser>
In Orange Pi's case just two table entries existed leading to the CPU cores being fed with 1.3V all the times even when clocking at 60 MHz
<tkaiser>
Based on my tests heat scales more or less linearly with core voltage
<MoeIcenowy>
tkaiser: it's the vendor's fault
<MoeIcenowy>
but luckily script.bin.is changable
<KotCzarny>
which mean oranges are the shittiest of them all
<MoeIcenowy>
orange pi is a good guy
<MoeIcenowy>
for rmb 100
<tkaiser>
I won't expect software/support at that price
<MoeIcenowy>
yes
<ssvb>
KotCzarny: "which mean oranges are the shittiest of them all" - and this is based on what?
<MoeIcenowy>
i did everything on my former a33 tablet
<MoeIcenowy>
it's 460 rmb ($80-)
<ssvb>
KotCzarny: the hardware seems to be ok, the software support is nonexistent but this is easily fixable
<MoeIcenowy>
with a 10inch 20
<KotCzarny>
ssvb: on the added value of false advertising
<MoeIcenowy>
1024x768 ips screen
<KotCzarny>
apart from usual aw woes
<ssvb>
KotCzarny: that's probably just a cultural difference thing, which is hard to comprehend by the westerners
<MoeIcenowy>
what's the price of orange pi pc outside PRC?
<MoeIcenowy>
in PRC it's 100rmb ($17-
<tkaiser>
$15 + $3.5 worldwide shipping
<MoeIcenowy>
tkaiset: also so cheap
<MoeIcenowy>
shipping is also cheap
<KotCzarny>
i bought opipc for ~30usd
<tkaiser>
Yes, and shipping was also fast!
<MoeIcenowy>
my CHIP costs $15 for shipping
<ssvb>
yep, and the price is also below the VAT threshold in Europe (~22 euro I think), which is very nice
<MoeIcenowy>
(and it won't be shipped until jul
<ssvb>
I mean for the Orange Pi PC
<tkaiser>
I'm curious whether they increase shipping costs for the 2 new Orange Pis (shipping should start on 25th)
<MoeIcenowy>
Who have enough time can use Orange Pi to get 2 times better CPU performance/price value than Raspberry Pi 2
<MoeIcenowy>
In China shipping services are very good
<MoeIcenowy>
(if use the standard outside China
<MoeIcenowy>
I bought my uSD breakout at Tue. afternoon
<MoeIcenowy>
and get it at 9:00 on Wed
<MoeIcenowy>
But I cannot also understand why Orange Pi will add a dangerous frequency
<MoeIcenowy>
maybe it's only a bug
<MoeIcenowy>
We'd report it to Xunlong
<ssvb>
KotCzarny: 30usd seems a bit expensive, maybe you got it not directly from Xunlong but from some fishy reseller?
<tkaiser>
Their settings weren't that dangerous since the 'cooler table' prevented using the highest clock speeds
<MoeIcenowy>
tkaiser: ?
<MoeIcenowy>
cooler table?
<tkaiser>
In loboris' OS images these settings were then 'unlocked' and some values even higher. With Xunlong settings CPU cores were disabled (and never came back until reboot)
<KotCzarny>
ssvb: yeah, local buy
<tkaiser>
With loboris' settings throttling occured
<MoeIcenowy>
In Huaqiang North the price of Allwinner devices can be 1/3 of the price on Amazon
<tkaiser>
'cooler table', budget cooling. That's what we've to deal with with most (or even all) recent SoCs. At least quad core or more
<MoeIcenowy>
(I means Amazon not in China
<MoeIcenowy>
At least my A33 is safe for 1.34GHz * 4
<MoeIcenowy>
But maybe a tablet's board is more stable than a development board
<vinifr>
hi, Has anyone tested the sunxi-next mainline with Cubieboard-v1?
<ssvb>
MoeIcenowy: how did you test that it is stable? also are you sure that it does not get throttled?
cnxsoft has quit [Quit: cnxsoft]
<MoeIcenowy>
ssvb: I used it to build mesa and llvm
<tkaiser>
MoeIcenowy: And you always checked cpu frequency?
<MoeIcenowy>
tkaiser: I didn't always check it
<ssvb>
MoeIcenowy: gcc is not the most demanding workload
<MoeIcenowy>
ssvb: then how?
<MoeIcenowy>
(I may test now
<tkaiser>
cpuburn-a7
<MoeIcenowy>
(The device is currently in GNU/Linux
<tkaiser>
You could also use stress and sysbench in parallel
<tkaiser>
In my tests SoC temperatures increased even a bit compared to only running cpuburn on all cores.
<ssvb>
vinifr: Cubieboard-v1 is supported by the mainline kernel since a very long time ago
<MoeIcenowy>
cpufreq-ljt-stress-test will build a libjpeg-turbo, interesting...
<tkaiser>
But this 'measurement thing' is difficult. Until you spend a lot of time on it and always check everything twice you run into wrong conclusions pretty fast
<tkaiser>
s/until/unless
<MoeIcenowy>
How can I judge whether the CPU goes wrong?
<ssvb>
vinifr: do you mean that you have some problems with the *current* sunxi-next branch?
<MoeIcenowy>
(And it seems that my tablet's DRAM runs at 360MHz
<ssvb>
MoeIcenowy: if the CPU is having troubles, then the decoded JPEG images may be become corrupted and this gets detected by the test
<MoeIcenowy>
oh
<MoeIcenowy>
libjpeg-turbo is still being compiled
<ssvb>
MoeIcenowy: the script checks that the cjpeg and djpeg are from libjpeg-turbo, which has NEON optimizations. And NEON code is a much more demanding workload than the regular non-optimized C based jpeg decoder
<ssvb>
MoeIcenowy: how much RAM do you have on your device?
<MoeIcenowy>
512m
<MoeIcenowy>
ssvb: mozjpeg have also neon
<ssvb>
512m should be enough
<ssvb>
is it used up by something?
<MoeIcenowy>
oh a xfce
<MoeIcenowy>
ssvb: Should I do more stress test when ./cpufreq-ljt-stress-test is running?
<MoeIcenowy>
it may be too easy in 1344MHz
<ssvb>
run cpuburn-a7 in parallel (cpuburn-a7 is heating up the cpu, and libjpeg-turbo is detecting potential corruption)
<MoeIcenowy>
run one or four?
<MoeIcenowy>
or three?
<ssvb>
cpuburn-a7 is already forking to load all cpu cores
<ssvb>
also try to tweak voltages in the cpufreq table to see if you have any safety headroom
<MoeIcenowy>
1344 passed
<MoeIcenowy>
my device runs on 1.46V on 1344
<vinifr>
ssvb, Yes, it hangs here: Starting kernel ...
<tkaiser>
ssvb: BTW: On the A83T cpuburn forks only 4 threads not 8
<ssvb>
MoeIcenowy: the recommended maximum is 1.4V according to the A33 datasheet, so you are already in a dangerous territory
<ssvb>
topi`: cortex-a7 is still pipelined, the square root calculation runs for many cycles in the background while the cpu can do other things
<topi`>
ok, then my solution would be to buy 5x OPi PC for $15 apiece and then 5x camera modules
<tkaiser>
No, you want to buy 5 Orange Pi One for $10 each ;)
<topi`>
ssvb: yes, it works like that, *however* if another instruction is causing a data dependency on the result of that sqrt, then a pipeline stall occurs
<MoeIcenowy>
tkaiser: is sunxi isp code in H3 SDK blobs?
<MoeIcenowy>
In A33 SDK it is
<topi`>
tkaiser: I need the camera-boards to have Wifi
<tkaiser>
topi`: Then OPi Lite for $13 ;)
<ssvb>
topi`: yes, these are the trivial basic things which every assembly programmer knows
<MoeIcenowy>
need the camera-boards to have Wifi?
<topi`>
btw is there any other way to buy Orange PI stuff than the aliexpress store? AE doesn't work for me since they don't take Paypal
<topi`>
MoeIcenowy: to transfer the images in real-time :)
<MoeIcenowy>
Maybe no other ways
<topi`>
tkaiser: from my point of view, that product doesn't exist yet
<tkaiser>
And if you really care about quality and want to record video in high resolution I would better go with Raspberry Pi A+ and its camera module
JohnDoe8 has joined #linux-sunxi
Ueno_Otoko has quit [Ping timeout: 265 seconds]
<topi`>
but the camera modules for RPi are expensive
<topi`>
all RPi modules are :
JohnDoe_71Rus has quit [Ping timeout: 260 seconds]
Gerwin_J has joined #linux-sunxi
<tkaiser>
Yes, but you get 1080p video encoded on the VideoCore VPU
<tkaiser>
Instead of 640x480 @ 4 fps ;)
<KotCzarny>
;)
<MoeIcenowy>
tkaiser: try libvdpau-sunxi
<MoeIcenowy>
although experimental
<tkaiser>
It's about encoding
<MoeIcenowy>
sunxi also supports encoding
<MoeIcenowy>
although no suitable framework to implement it
<MoeIcenowy>
·Supports H.264 1080p@30fps video encoding
<mawe242>
mripard: I'm about to update the SPI word wait patch series with more fixes. Do I send the whole series to a combined recipient list for all patches/subsystems, or each patch in the series to a separate recipient list?
<robogoat>
Does anybody have a link to a good document on USB OTG on the A20? I have a few pcduino3 nano lites, and I would like to use the serial and/or rndis gadgets,,
<robogoat>
I think I have done most of that, but let me doublecheck.
<mripard>
mawe242: if it's just fixes, it doesn't need to be part of any series, just send them alone
<mawe242>
mripard: ok, but if the series depends on some of those patches?
<mawe242>
just add a note that the series depends on those?
<robogoat>
mawe242: Hmm, I am trying to use a 4.3 kernel,
<robogoat>
mainline,
<robogoat>
and some of those configs don't match up.
<mawe242>
mripard: but the question still remains... if the series contains patches that touches different subsystems, do I send the whole series to all recipients for all subsystem, or each patch with a separate recipient list?
<robogoat>
Anybody have thoughts?
mosterta has joined #linux-sunxi
<robogoat>
I am wondering if I am missing something for otg in sun7i-a20-pcduino3-nano.dts .
<ssvb>
and maybe CONFIG_MUSB_PIO_ONLY=y is still necessary
<robogoat>
Ok, yes, I think I have gathered some of this info from research earlier.
mawe242 has quit [Quit: Leaving]
<robogoat>
I am currently testing some things with several pcduino3-nano-lites that I picked up on amazon.
<robogoat>
Going full diskless.
<ssvb>
moreover, the 'device' vs. 'host' role is selected once (based on the id pin of the connected cable) and if you try to change role at runtime, then everything fails
<robogoat>
My current development process involves u-boot over spl, a serial cable and an ethernet cable.
<robogoat>
spl/fel.
libv_ has joined #linux-sunxi
<robogoat>
If I could do the serial/ethernet over the otg port as well as fel bootloading, I could cut 3 cables and an adapter down to 1 cable.
<robogoat>
I think.
<ssvb>
you can do this, that was exactly the use case I tested :-)