Mr__Anderson has quit [Remote host closed the connection]
hramrach has quit [Ping timeout: 240 seconds]
bonbons has quit [Quit: Leaving]
_hramrach has joined #linux-sunxi
<TheLinuxBug>
https://hardware.slashdot.org/story/17/01/21/2025232/raspberry-pi-gets-competitors - So what are the chances of the Asus board with the RK3288 actually meeting the advertised 1.8Ghz? I am thinking much like H3/H5/Amlogic you will be happy to get 90% of that speed? iIf so, is it really anything to write home about?
jstein has quit [Remote host closed the connection]
chomwitt4 has joined #linux-sunxi
Keziolio has quit [Changing host]
Keziolio has joined #linux-sunxi
chomwitt3 has quit [Ping timeout: 240 seconds]
interrobangd has joined #linux-sunxi
<apritzel>
TheLinuxBug: the RK3288 has Cortex-A17 cores though, so even at the same frequency they are much faster than the A7 or the A53
<apritzel>
and the A17s are also more power efficient, so they could actually reach that frequency
apritzel has quit [Ping timeout: 240 seconds]
lkcl has joined #linux-sunxi
Ntemis has joined #linux-sunxi
__hramrach has joined #linux-sunxi
_hramrach has quit [Ping timeout: 240 seconds]
__hramrach has quit [Ping timeout: 245 seconds]
reinforce has quit [Quit: Leaving.]
__hramrach has joined #linux-sunxi
Andy-D has quit [Ping timeout: 240 seconds]
ninolein has quit [Ping timeout: 240 seconds]
ninolein has joined #linux-sunxi
BenG83 has quit [Ping timeout: 276 seconds]
hp197 has quit [Ping timeout: 240 seconds]
arete74_ has quit [Ping timeout: 252 seconds]
hp197 has joined #linux-sunxi
dr1337 has quit [Ping timeout: 260 seconds]
chomwitt4 has quit [Ping timeout: 248 seconds]
lkcl has quit [Ping timeout: 264 seconds]
GrimKriegor_ has quit [Quit: oh bai bai bai]
victhor has quit [Ping timeout: 255 seconds]
GrimKriegor has joined #linux-sunxi
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
interrobangd has quit [Quit: Leaving]
Ntemis has quit [Remote host closed the connection]
hramrach_ has joined #linux-sunxi
__hramrach has quit [Ping timeout: 240 seconds]
GrimKriegor has quit [Ping timeout: 255 seconds]
cnxsoft has joined #linux-sunxi
GrimKriegor has joined #linux-sunxi
hramrach_ has quit [Ping timeout: 245 seconds]
GrimKriegor_ has joined #linux-sunxi
GrimKriegor has quit [Ping timeout: 240 seconds]
hramrach_ has joined #linux-sunxi
<willmore>
1.8GHz quad A17 and no heatsink? Yeah, good luck.
<willmore>
That GPU alone needs a heatsink
<willmore>
TheLinuxBug, the ODROID boards except the C2 made advertised clocks and then some. I guess the lesson is to stick with Korean chips if you want what you're promised.
hramrach_ has quit [Ping timeout: 255 seconds]
* vagrantc
hasn't had too much trouble running firefly-rk3288 boards without a heatsink
<vagrantc>
well, one of the three is kinda flaky
<willmore>
vagrantc, cpuburn?
<vagrantc>
part of a build farm ... which admittedly does have some slow periods
<vagrantc>
according to cpufreq they're running in the upper three cpu states for over 60% of the time
<willmore>
yeah, for bursty loads, you can get away with a nice chunk of thermal mass even if you don't bleed heat quickly.
<willmore>
vagrantc, try cpuburn. :)
<vagrantc>
really, i should just put a heat sink on them, they'll probably perform better...
<willmore>
Doesn't look like ssvb has a cpuburn for A17. :(
<willmore>
do they do any kind of thermal throttling? Do you have any way of logging when it happens?
<willmore>
Anyone know what process the rk3288 is fab'ed on?
<willmore>
I'm guessing it's 28nm of some variety.
<vagrantc>
yeah, don't have sophisticated logging
<willmore>
If it's getting to 1.8 GHz, then it's pretty safe to guess it's not 40nm.
<willmore>
vagrantc, try some of the cpuburn variants and see if you can get it to thermal throttle
<willmore>
There's only A7-9 and 53 and Krait 300/400, but one of them might be close. I'd guess the krait as it's a three wide chip as well.
<willmore>
that's ssvb's baby, so they would know better.
<willmore>
Oh, my order of another OpiZ, NAS board, and OpiPC shipped. Yay! I wasn't sure they were going to get out before the spring festival.
hramrach__ has joined #linux-sunxi
<vagrantc>
i think it caps out at 1.6GHz, but i haven't really tried to max it out or anything
<vagrantc>
well, 1.61GHz, but who's counting?
<willmore>
Hey, that's a whole 10 extra MHz!
<willmore>
You overclocking madman!
* vagrantc
just uses the defaults
GrimKriegor_ has quit [Quit: oh bai bai bai]
GrimKriegor has joined #linux-sunxi
pg12 has quit [Ping timeout: 252 seconds]
pg12 has joined #linux-sunxi
cnxsoft has quit [Ping timeout: 264 seconds]
cnxsoft has joined #linux-sunxi
TheSeven has quit [Disconnected by services]
[7] has joined #linux-sunxi
chomwitt4 has joined #linux-sunxi
GrimKriegor has quit [Quit: oh bai bai bai]
GrimKriegor has joined #linux-sunxi
chomwitt has joined #linux-sunxi
chomwitt4 has quit [Ping timeout: 240 seconds]
vagrantc has quit [Quit: leaving]
dave0x6d has quit [Quit: Connection closed for inactivity]
terra854 has joined #linux-sunxi
IgorPec has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
montjoie has quit [Ping timeout: 240 seconds]
montjoie has joined #linux-sunxi
f0xx has joined #linux-sunxi
Macer has joined #linux-sunxi
cnxsoft has quit [Read error: Connection reset by peer]
cnxsoft has joined #linux-sunxi
|Jeroen| has joined #linux-sunxi
Amit_T has joined #linux-sunxi
scream has joined #linux-sunxi
my123_ has joined #linux-sunxi
my123_ has joined #linux-sunxi
my123_ has quit [Changing host]
my123 has quit [Ping timeout: 259 seconds]
chomwitt1 has joined #linux-sunxi
chomwitt has quit [Ping timeout: 240 seconds]
dave0x6d has joined #linux-sunxi
lemonzest has joined #linux-sunxi
f0xx has quit [Quit: terminated!]
f0xx has joined #linux-sunxi
ErwinH has joined #linux-sunxi
leviathan_ has joined #linux-sunxi
ErwinH has quit [Remote host closed the connection]
<apritzel>
willmore: why do you expect a board to run at full frequency for a prolonged period of time with a load like cpuburn?
<apritzel>
Most PCs wouldn't do this, my notebook certainly throttles at loads way below the nastiness of cpuburn
<apritzel>
cpuburn is a "thermal bug", so the worst possible scenario in terms of heat dissipation
jernej has joined #linux-sunxi
<apritzel>
which is good to see the limits of the cooling solution and to check if throttling works
<apritzel>
but for a real user it doesn't really matter: if your workload can make use of the full frequency, that should be good enough
<apritzel>
the problem with Allwinner chips seems to be that they don't even achieve this: running at the advertised 1.2 GHz or 1.6 GHz with a parallel compile, for instance
<apritzel>
willmore: and have you checked the A17, specifically?
<apritzel>
willmore: it should be much more efficient than an A15, for instance
<apritzel>
which was seriously limited in terms of achievable clock frequency due to thermal issues
jernej has quit [Ping timeout: 240 seconds]
jernej has joined #linux-sunxi
JohnDoe_71Rus has quit [Quit: KVIrc KVIrc Aria 4.9.2, revision: git-7050-g88980badc, build type: debug, sources date: 20160102, built on: 2017-01-20 07:18:15 UTC git-7050-g88980badc http://www.kvirc.net/]
jernej has quit [Quit: Konversation terminated!]
jernej has joined #linux-sunxi
<philectro>
A cpu who can't handle fullload fulltime need some heatsink lol
<philectro>
and i don't agree, only on crappy pc you can't maintain full load without throttles
<philectro>
throttles is defective design
<philectro>
(i know some throttles are not from the chip but from the vrm who can't handle the load, on crappy motherboards)
<philectro>
and on this subject, cubieboard to my eyes is deffective product as it's over 70 at full load for few minutes
<philectro>
i'm never going to buy next time a board without a heatsink
<philectro>
(that's why i like c2)
Mr__Anderson has quit [Remote host closed the connection]
<philectro>
and yes it's true that on many laptop, the heatsink/pipe circuit is too little for support real load
<philectro>
Intel xeon have special frequencies for AVX
<philectro>
The consumer equivalent is heating a lot when avx is in full load
<philectro>
because they are so little that it makes difficult to cool it
<philectro>
cooling?
jernej has quit [Ping timeout: 240 seconds]
Andy-D has joined #linux-sunxi
The_Loko has joined #linux-sunxi
tkaiser has joined #linux-sunxi
<tkaiser>
willmore: Regarding RK3288 and clockspeeds just do a search for 'Willy Tarreau' combined with RK3288 or cluster or MiQi (MiQi board uses the same SoC). Both the ASUS board and the MiQi use Micro USB for DC-IN so unless you power the boards more reliable you can't run them at high clockspeeds anyway.
bugzc has quit [Ping timeout: 245 seconds]
jernej has joined #linux-sunxi
<philectro>
i have get lot of trouble with powering via usb
<philectro>
the usb is not really reliable for stability
<philectro>
i wish my usb power was easily openable so i can solder wire in
<philectro>
the most crashes my cubieboard is doing are because of usb
BenG83_ has quit [Quit: Bye]
florianH has joined #linux-sunxi
IgorPec has joined #linux-sunxi
interrobangd has joined #linux-sunxi
ErwinH has joined #linux-sunxi
cnxsoft has quit [Remote host closed the connection]
victhor has joined #linux-sunxi
freemangordon has quit [Ping timeout: 240 seconds]
cnxsoft has joined #linux-sunxi
juri_ has quit [Ping timeout: 264 seconds]
iaglium has quit [Ping timeout: 264 seconds]
INdek has quit [Quit: leaving]
INdek has joined #linux-sunxi
juri_ has joined #linux-sunxi
Ntemis has joined #linux-sunxi
iaglium has joined #linux-sunxi
netlynx has joined #linux-sunxi
netlynx has joined #linux-sunxi
netlynx has quit [Changing host]
interrobangd has quit [Read error: Connection reset by peer]
cnxsoft has quit [Remote host closed the connection]
ErwinH has quit [Remote host closed the connection]
cnxsoft has joined #linux-sunxi
jernej has quit [Ping timeout: 245 seconds]
Amit_T has quit [Ping timeout: 248 seconds]
apritzel has quit [Ping timeout: 260 seconds]
<TheLinuxBug>
willmore: RE: <willmore> TheLinuxBug, the ODROID boards except the C2 made advertised clocks and then some. I guess the lesson is to stick with Korean chips if you want what you're promised.
<TheLinuxBug>
I was in odroid channel the other day
<TheLinuxBug>
and mdrjr was complaining they won't use Amlogic chips anymore because they are NOT reaching their advertised speed
<TheLinuxBug>
several people were discussing it.. and i had asked if they were gonna make a board with the S905x
ErwinH has joined #linux-sunxi
<TheLinuxBug>
and for the reason that they couldn't trust the chip speeds he said they had not considered it
<TheLinuxBug>
I am guessing that is waht you meant by all but the c2
<TheLinuxBug>
re-reading that now makes more sense
<TheLinuxBug>
I don't think I understood correctly the first time I read your statement :Z
leviathan_ has quit [Remote host closed the connection]
<philectro>
is any chip able to use advertised frequency?
<philectro>
all i have see until now is lies.
<philectro>
so for me it's not really important
<philectro>
i prefer to see good upstream support
JohnDoe_71Rus has joined #linux-sunxi
noblock has quit [Ping timeout: 240 seconds]
cnxsoft has quit [Quit: cnxsoft]
nik123 has joined #linux-sunxi
quinward has quit [Quit: WeeChat 1.5]
ErwinH has quit [Remote host closed the connection]
naobsd has quit [Remote host closed the connection]
ErwinH has joined #linux-sunxi
<TheLinuxBug>
philectro: its not lies to the extent it may be possible to reach those speeds, even if for a short time, however, they have used semi-dishonest practices of advertising the maximum possible frequency instead of what the chip 'normally' runs at. This is why when Xunlong released Orange Pi PC2 you will see they include no GHz rating for the CPU just said its quadcore A53
naobsd has joined #linux-sunxi
<TheLinuxBug>
in my experience the H5 seems to run slower GHz speed than H3 did, but you do get a faster mmc reader and better neon support in the H5 which does help a bit, as well as better graphics engine I believe
<BenG83>
the Azpen Hybrx is still advertised with 1.3Ghz, that is maybe the most outrageous claim I saw for A64 so far
ErwinH has quit [Ping timeout: 255 seconds]
leviathan_ has joined #linux-sunxi
<terra854>
It might be possible to clock the A64 at 1.3 Ghz, if you get the settings right.
ErwinH has joined #linux-sunxi
leviathan_ has quit [Ping timeout: 260 seconds]
<TheLinuxBug>
I had a hard enough time with Xunlong's images trying to accomplish 1.2Ghz out of the h5
<TheLinuxBug>
they seem to use fex settings that limit things to 1Ghz as that seemed to be where it kept maxing for me, but only played with it for about 20 minutes...
<TheLinuxBug>
so maybe I need to switch govenor and such to see the higher speeds
<TheLinuxBug>
anyone have a baidu account willing to download the Debian XFCE image for me for the PC2
<TheLinuxBug>
seems I have no way to download it since I am not from China and can't seem to figure out how to sign-up
Andy-D has quit [Remote host closed the connection]
<TheLinuxBug>
well if someones willing to grab it and send it to me just let me know, would be awesome :D
ErwinH has joined #linux-sunxi
IgorPec has quit [Ping timeout: 252 seconds]
ErwinH has quit [Ping timeout: 258 seconds]
leviathan_ has joined #linux-sunxi
naobsd has quit [Remote host closed the connection]
<tkaiser>
BenG83: The 1.3 GHz is the number Allwinner's Android 'reports' and that's displayed by stupid benchmarks like Geekbench or CPU-Z. And this is the result of cpufreq settings up to 1.3 GHz while THS settings prevent exceeding 1152 MHz. But that's not the real problem.
<tkaiser>
BenG83: The main problem with Allwinner's Android or RemixOS is that THS settings kill CPU cores. So as soon as A64 overheats the SoC runs on 3, 2 or only 1 CPU core. And the use in front of the device still gets '4 CPU cores at 1.3 GHz displayed'
<tkaiser>
TheLinuxBug: The problem with H5 is that Xunlong with Allwinner's BSP kernel still did not manage to get DVFS working. So H5 is fed with 1.1V VDD_CPUX only which prevents any cpufreq above 1008 MHz reliably. Funnily with mainline kernel it's working. ErwinH reported success after applying megi's H3 DVFS/THS patches
naobsd has joined #linux-sunxi
<BenG83>
how is DFVS working on the H5 without a PMIC?
<BenG83>
do they have a digitally programmed DC/DC ?
<tkaiser>
BenG83: SY8106A -- check linux-sunxi wiki
<BenG83>
ah ok
<tkaiser>
BenG83: On the smaller H3 boards a GPIO driven approach is used. Driver toggles a GPIO and two resistors let the voltage regulator switch between 1.1V and 1.3V (on all H3 boards except of Banana Pi M2+ where they forgot to enable the GPIO switching)
<BenG83>
heh ok
<BenG83>
then let's hope the settling time of those regulators is fast enough
IgorPec has joined #linux-sunxi
naobsd has quit [Remote host closed the connection]
naobsd has joined #linux-sunxi
yann-kaelig has joined #linux-sunxi
apritzel has joined #linux-sunxi
nik123 has quit [Quit: nik123]
<TheLinuxBug>
tkaiser: okay, hate to ask a stupid question as I feel I could probably look and find it, but can you point me to the information for compiling mainline for h5 so I can give it a try?
lkcl has quit [Ping timeout: 276 seconds]
<TheLinuxBug>
tkaiser: also that explains why when I was trying to bump up the cpu speed using govenor changes and such why it wouldn't ever go over 1.01Ghz or whatever, thanks for that info
lkcl has joined #linux-sunxi
<TheLinuxBug>
tkaiser: will that link you provided re: baidu work on the ones that say they need the 'network client' or is that what aria2 is? I wasn't very clear on that
f0xx has quit [Ping timeout: 248 seconds]
<TheLinuxBug>
tkaiser: as always thanks for your help/input/direction :) its always appriciated.
LargePrime has quit [Quit: Leaving]
<tkaiser>
TheLinuxBug: I did just an 'apt install aria2' and then baidu worked like a charme with this downloader.
<TheLinuxBug>
k ill give it a go here shortly then
<TheLinuxBug>
:)
<TheLinuxBug>
is there a specific wiki page that would be helpful if I wanted to attempt compiling mainline for h5?
<tkaiser>
TheLinuxBug: ErwinH said he tried to integrate the necessary patches/setup into Armbian's build system. Maybe you find working stuff here: https://github.com/ehoutsma?tab=repositories
Pepe has joined #linux-sunxi
apritzel has quit [Ping timeout: 255 seconds]
<TheLinuxBug>
thanks!
jernej has joined #linux-sunxi
dh1tw has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
netlynx has quit [Quit: Ex-Chat]
LargePrime has joined #linux-sunxi
dh1tw has joined #linux-sunxi
<igraltist>
hi
<igraltist>
sofar the opipc runs well on mainline stable kernel. except i have some lags on editing files. its hung often for a short period
<TheLinuxBug>
tkaiser: :D Sweet its downloading
<tkaiser>
igraltist: Accessing files on SD card?
deskwizard has quit [Quit: disapeared.]
<igraltist>
yes
<kristina>
are most of the drivers for sun50i mainlined?
<kristina>
or is there a special fork that i need to check out for full sun50i support.
apritzel has joined #linux-sunxi
<kristina>
apritzel :D
<kristina>
do you know if most of the sun50i (especially for A64) stuff has been mainlined or not?
<kristina>
going to build the SPL later and mess around with TZ peripherals a bit.
<kristina>
well, TZ memory rather since TZ peripherals don't work :X
<kristina>
might look at BROM as well as see if it may just be disabling security based on a fuse setting and if it can be reenabled later.
blackandwhitetux has joined #linux-sunxi
philectro has quit [Quit: Leaving]
jernej has quit [Ping timeout: 245 seconds]
<tkaiser>
igraltist: Well, then it's time to check the SD card or even switch to btrfs to run scrubs from time to time
<apritzel>
kristina: A64 mainline> do you mean Linux or U-Boot?
<martinayotte>
MoeIcenowy : For the "large transfer SPI", today, for fun, I've added to my Pine64 tree and discovered that A64 is also a sun8i-h3-spi, not sun6i-a31-spi, it has only 64 bytes FIFO.
<kristina>
apritzel: well you told me that uboot spl already works fine on a64 so my question was about linux.
<apritzel>
kristina: Linux has the basic bits since 4.10-rc1, USB and MMC are queued for 4.11
<apritzel>
kristina: also U-Boot has SPL support in master, but this setup is missing ATF
<apritzel>
for which I send an RFC series a few days ago
<willmore>
apritzel, I'm not sure you understood what I was asking. I wanted to see if the chip *could* maintain full clocks with a pathalogical load. And, if not, what kind of clocks it could maintain.
<apritzel>
willmore: but that's also a matter of cooling, isn't it?
<willmore>
tkaiser, thanks for the tip. Ugg, micro-USB for power *again*? *sigh*
<apritzel>
willmore: for instance my notebook can't maintain 2.8 GHz on every core with a load >= 4
<kristina>
apritzel: is https://github.com/apritzel/u-boot the most up to date SPL then? where would i get the most up-to-date linux fork (with stuff like kernel drivers for video etc)?
<apritzel>
willmore: so it's not so much a matter of a certain _chip_, but more about a certain machine (board and cooling)
<apritzel>
kristina: spl-fit-rfc is the best branch available there
<apritzel>
kristina: which roughly matches what would be the 4.11 features
<kristina>
apritzel: i was planning to run something else in place of ATF actually.
<apritzel>
kristina: why?
<kristina>
basically a secure rtos that does some things.
<apritzel>
on the ARM cores in EL3?
<apritzel>
or on the OpenRISC core?
<kristina>
on the arm core.
<willmore>
TheLinuxBug, Yeah, the C1 hit target speed. The C2 didn't--that whole 905 family seems to be flawed in that way. All of the older ODROIDS met target clocks. Heck, most of the Samsung chips would overclock a bit if you're crazy that way. :)
<apritzel>
kristina: what is "some things"?
<apritzel>
setup only or used at runtime?
<kristina>
runtime.
<apritzel>
triggered by non-secure world?
<apritzel>
or by periodic timer IRQs?
<kristina>
both actually.
<kristina>
and i remember the secure peripherals issue.
<kristina>
but as long as dram can be secured i guess that's half okay.
<apritzel>
kristina: is that just for experimentation?
<kristina>
well it's used in production but in my case it's pretty much for experiementation yeah.
<willmore>
And, yeah, it seem the lies from AmLogic about their chip clock speeds burnt their relationship with HK and maybe more companies. I don't know if Allwinner has done the same to anyone.
<kristina>
apritzel: so yeah the goal is to have a resident secure OS that does "certain things", i'm assuming ATF fork for sun50i doesn't really do anything important as far as AW hardware init goes, does it?
Amit_T has joined #linux-sunxi
<apritzel>
kristina: not much AW related, yes
<apritzel>
kristina: one _could_ go in this direction and eventually replace the SPL with some ATF code (DRAM setup and MMC load routines), but I don't see why this would be useful apart from going more in the way ATF is meant to be
<apritzel>
kristina: but "resident secure OS" sounds more like secure EL1 to me
<willmore>
apritzel, yes, it is. The tinker board by ASUS shows it with no thermal solution at all other than the included metal cap on the chip. Yet they claim 1.8GHz for it. I remain doubtful.
<willmore>
My laptop can maintain 3.2GHz on all cores running Prime95. ;)
<kristina>
apritzel: yes but don't SMCs trap to EL3?
<apritzel>
kristina: ATF has some quite some infrastructure to forward them to a secure EL1
<apritzel>
that's how is usually done (or meant to be done): ATF sits on top and manages things
<apritzel>
any secure OS code wouldn't be part of ATF, but just some "secure payload"
<apritzel>
willmore: I was just wondering if you would extrapolate the bad experiences from A53 cores @ 40nm to some other SoCs
<kristina>
apritzel: so does the OS stack that i want to run on it (it's actually a microkernel) that has parts in EL3/EL1/EL0.
<willmore>
TheLinuxBug, one confounding factor that differentiates HK and the Opi maker (who's name I am blanking on) is that HK doesn't just make dev boards, they make boards for professional applications--sort of like Olimex does. So, they hold themselves to a different standard.
<kristina>
i'd need to tweak it slightly so it works on sun50i as opposed to what it was intended to work on.
<apritzel>
kristina: I am not so keen of the idea to have a special firmware stack for a certain OS
<apritzel>
kristina: that's the idea of ATF: it provides a framework to load any non-secure/secure OS combination
ErwinH has joined #linux-sunxi
<apritzel>
kristina: so if you could abstract your EL3 needs in a generic way and upstream them into ATF
<kristina>
well it's all proprietary.
<apritzel>
kristina: well, at least merge them into ATF
<apritzel>
which is BSD licensed
<kristina>
why, the stack that's currently used already does what ATF EL3 stuff would do.
<kristina>
what i wanted to do is have SPL load that instead of ATF.
<apritzel>
the SPL has no special assumption about ATF, it just loads some code into some SRAM and jumps to it
<kristina>
ah, so no device tree dependencies or anything either?
<apritzel>
the SPL code picks one DT and appends it to the U-Boot binary at the moment, but one could add some code to make this optional easily
<apritzel>
for instance to skip this if there is no fdt node in the configuration section
<apritzel>
so in your case you could use the SPL, which does the dirty work for you: basic clock setup, DRAM init, UART init
<apritzel>
then drop the actual U-Boot proper and ATF totally and just load your own code
<MoeIcenowy>
oh I think I now also must care FIT support...
<apritzel>
MoeIcenowy: for what?
chomwitt1 has quit [Ping timeout: 258 seconds]
<MoeIcenowy>
my leader on work suggests to do a hardware with A33
<MoeIcenowy>
(something like USB Armory
<MoeIcenowy>
and if it's done, it will run some trusted os in EL3
<MoeIcenowy>
not simply the U-Boot PSCI stub
<apritzel>
MoeIcenowy: conceptually a secure OS would run in secure EL1, not EL3
<kristina>
MoeIcenowy: if i understand correctly, you need to get docs from allwinner if you want to have proper security.
<MoeIcenowy>
kristina: for A33 it has even no Secure Boot feature
<MoeIcenowy>
apritzel: oh it's secure SVC...
<apritzel>
EL3 is just the monitor to propagate stuff between the non-secure and secure world
<MoeIcenowy>
thanks for telling me that ;-)
<apritzel>
MoeIcenowy: yes, because a secure OS isn't exactly expected to mess up the whole non-secure world as well ;-)
tsuggs has joined #linux-sunxi
<apritzel>
EL3 has this power, secure EL1 not necessarily
chomwitt1 has joined #linux-sunxi
<kristina>
MoeIcenowy: well as i said, if you want proper security, you'd need docs from AW on it.
<apritzel>
kristina: depends on whether he need secure peripheral access or not
<MoeIcenowy>
oh but for A7 it do not have EL...
<MoeIcenowy>
apritzel: A33 do not have TZPC at all
<apritzel>
I was wondering why you would choose A33 in the first place ...
<MoeIcenowy>
cheap ;-)
<kristina>
apritzel: well on a real secure system, if you don't secure the peripherals, your secure OS isn't really secure at all.
<apritzel>
MoeIcenowy: but if it doesn't meet your requirement, that doesn't really matter ;-)
<MoeIcenowy>
so maybe H3 instead?
<MoeIcenowy>
then try out the secure boot feature?
<MoeIcenowy>
in size H3 is just like A33
<kristina>
if you don't have the bootrom verify boot0 for example, non trusted code could overwrite your secure os and reboot.
deskwizard has joined #linux-sunxi
<MoeIcenowy>
apritzel: there seems to be some sbrom source code in H3 lichee...
<MoeIcenowy>
although I do not know whether they're only reference code
<apritzel>
kristina: sure, that's an issue, but if at least secure DRAM works, you should be able to implement some encryption in secure EL1, for instance
<apritzel>
kristina: and if you can otherwise prevent non-secure from accessing the boot media
<kristina>
apritzel: wouldn't that rely on secure peripherals working correctly and actually honouring axprot[1].
<MoeIcenowy>
apritzel: do you still have the boot log of Remix Mini?
<apritzel>
kristina: if you for instance boot from a special partition in eMMC, which you can turn off after boot
<apritzel>
kristina: but I agree: without secure peripherals that probably wouldn't be bullet proof
<kristina>
apritzel: how would you turn it off exactly? :P
<apritzel>
one time write in the controller which can't be reversed until reboot
<kristina>
you mean using an external controller? or does whatever AW use as their MMC controller support that?
<apritzel>
kristina: I thought that was something that an actual eMMC chip provides ...
<MoeIcenowy>
but TF won't have it...
<apritzel>
kristina: or you have some extra circuitry on your board which provides this "keep me high until reboot" feature and connect that to the CS of the SPI flash
<willmore>
apritzel, Nope, not really. I was just thinking that claiming 1.8GHz was wildly ambitious for an air cooled chip with four cores. Given how the A53 chips on 40nm have been behaving, I was wondering if they're fabbing the rk3288 on 28nm or some variety. That would explain 1.8 being a possible clock speed.
blackandwhitetux has quit [Ping timeout: 255 seconds]
<apritzel>
kristina: like an flip flop with the reset line not being exposed
<kristina>
apritzel: huh i don't recall emmc controllers supporting that functionality, from a glance at the docs of the one AW uses it doesn't seem to support anything for securing stuff after boot.
<MoeIcenowy>
willmore: I think I saw the rk3288's describe somewhere
<MoeIcenowy>
it's 28nm.
<apritzel>
kristina: not the MMC controller in the SoC, but some parts in the actual eMMC chip
<apritzel>
kristina: I dimly remember something with boot partitions and stuff
<apritzel>
kristina: but I could be wrong here
<kristina>
apritzel: you mean like in the SD/MMC spec?
<apritzel>
yes
<kristina>
you could power cycle the card.
<kristina>
unless you wire it in such a way that it's always on i guess.
<willmore>
MoeIcenowy, cool, thanks. That makes the 1.8GHz seem possible at least.
<kristina>
but i think the idle command resets the card's state machine?
<MoeIcenowy>
It's 28nm HKMG process
nik123 has joined #linux-sunxi
<willmore>
MoeIcenowy, do you know the fab?
<MoeIcenowy>
I do not know
<MoeIcenowy>
maybe TSMC...
<willmore>
Okay. Thanks. Then there's at least three 28nm processes at TSMC.
<apritzel>
willmore: I believe ARM officially recommends 28nm for the A53, so AW using 40nm is already deviating
<willmore>
apritzel, I wasn't aware of that guidance from ARM. I know they provide different levels of designs and some are already tuned for different fab setups while others are more generic--RTL level specs.
<buZz>
does allwinner have a A73 soc yet?
<MoeIcenowy>
buZz: nearly impossible
<willmore>
LOL
<MoeIcenowy>
after the failure of A80
<MoeIcenowy>
I don't think Allwinner will make any more big-core SoCs
<buZz>
:)
<willmore>
A53-A57-A72-A73. They're three steps behind that.
<MoeIcenowy>
willmore: A53 is always the little core
<apritzel>
willmore: actually I believe it's even more than a recommendation for ARM ;-)
<willmore>
That's not really the market segment for them.
<MoeIcenowy>
yes... not the market segment
<MoeIcenowy>
but for acceptable price A72 we can expcet Rockchip RK3399
<MoeIcenowy>
RK is no longer the low-price tablet SoC producer.
<willmore>
They did some A15 designs, so they have used cores that aren't 'little'. So, they have some experience with 'big' cores.
<MoeIcenowy>
willmore: A80 is a commercial failure
<kristina>
apritzel: actually you're right but i don't think all emmc controllers support it?
<MoeIcenowy>
allwinner cannot afford the production line that have big core
<willmore>
MoeIcenowy, yes, I didnt' say their experience with 'big' cores was a good one. :)
<willmore>
Where's the A35? Get rid of thoese A7 cores and move to the A35. Then stop supporting 32 bit. :)
* willmore
doesn't want to wake up from that dream
<apritzel>
willmore: well, many people do that: replacing A7s with A53s
<apritzel>
willmore: but AW seems to hunt for bargains here: ancient cores on ancient processes
<apritzel>
willmore: which brings me to my favourite quote again
<apritzel>
"You get what you pay for"
<willmore>
apritzel, I think it's a fab issue. I'm only seeing A35's on 10nm or about. Could be there's just not an A35 for 28nm.
<willmore>
apritzel, "you never get more than you pay for". Because, you don't always even get as much as you paid for. :)
<willmore>
You're too optimistic. ;)
<kristina>
apritzel: you're making me want to mess around with A64 less and less :P
<willmore>
apritzel, there goes your sales commission. :)
<kristina>
i hope to god it isn't as much of a trainwreck as bcm283x is.
<willmore>
kristina, you're going to find a lot of warts on chips in this price range.
<kristina>
willmore: well my best experiences are with tegra so far and cyclone+ families but they're fairly pricey or not generally available to public in open forms.
<apritzel>
kristina: I see the A64 as a cheap way to get your feet wet with AArch64, but not much more
terra854 has quit [Quit: Connection closed for inactivity]
<willmore>
kristina, this is the problem you will face in this market segment. You can have cheap, readily available, and probably flawed or you can have expensive, hard to get, but well made.
<kristina>
like i generally enjoy porting certain proprietary software to different boards.
<kristina>
but i quickly lose interest if those boards suddenly start doing weird things.
<willmore>
buZz, I think another reason you won't see A73 from allwinner is the fab issue. You're not going to see an A73 on older fab processes--like AW uses.
<buZz>
right, ok
yann-kaelig has quit [Quit: Leaving]
<willmore>
kristina, you're going to be going into territory with little guidance considering the more unusual stuff you're doing.
apritzel has quit [Ping timeout: 258 seconds]
<willmore>
With a SoC like we see from AW that has a lot of I/O, the benefits of using a more modern (smaller) process aren't that profound because most of the area quickly becomes dominated by the I/O drivers which do not scale smaller with the improved process. So, basically, you have a fixed chip area for your I/O and only the core (CPU/GPU and other logic) that scales with the new process.
<willmore>
So, what's the point of paying to fab that fixed chunk of I/O on a more expensive process *that you cannot take advantage of*.
<kristina>
willmore: well tegra tx1 was actually very nice, had well documented boot processes and tz stuff and not covered in warts and i actually enjoyed working with it.
<willmore>
As much as I'd like to see faster chips in this segment, I have to realize that what AW (and others) are doing is trying to optimize their chips for the reality of the world they live in.
<willmore>
kristina, right, but that's an expensive chip.
<willmore>
Which you're not going to see on $20 boards from China.
<willmore>
That goes to apritzel's "you get what you pay for".
<kristina>
by far the most pleasant (barring cyclone+ but that's a special case) SoC i've ported $thing to with extremely high quality documentation.
<willmore>
kristina, I am just trying to help adjust your expectations WRT this lower cost range of chips.
<kristina>
willmore: i mean a64 isn't terrible, it actually has secure peripherals and AW even documents them but for some reason they won't work because of either something bootrom has to explicitly enable based on an efuse configuration (good case since that can be done in sw) or the efuse itself being used in hw logic.
<kristina>
omap3 was solid, omap5 was buggy as fuck.
<willmore>
I wish you the best of luck!
mzki has quit [Ping timeout: 264 seconds]
<kristina>
"problem: TLB invalidation from a virtualized guest svc os can cause memory corruption. solution: don't use hw virtualization"
<ssvb>
kristina: the early omap3 was not so good, it had way too many errata
<ssvb>
thumb2 was particularly bad
<kristina>
but nowhere near as bad as omap5 was.
<kristina>
omap5 was pretty much "unfinished" when it was released, extremely poor testing, and some bugs didn't even have errata aside from "don't use these featuers at all".
leviathan_ has quit [Remote host closed the connection]
<MoeIcenowy>
what the hell happened on omap5?
<willmore>
TI gave up on OMAP.
<MoeIcenowy>
yes...
<willmore>
Management knew they were going to cut it and didn't put the resources on it to do it right.
<willmore>
I'm not a huge OMAP fan, but I do have a few devices based off of it and I followed what was going on at TI. It was sad.
<MoeIcenowy>
but currently consumer-level ARM Application Processor only chips do not sell well
<willmore>
tablets and phones are flying off the shelves. Set top boxes are doing okay. I'm not sure what you mean, MoeIcenowy.
<MoeIcenowy>
mainly portable device market ;-)
<MoeIcenowy>
for OTT Amlogic really do something
<willmore>
So you mean non-portable ARM devices like NAS and STB?
apritzel has joined #linux-sunxi
<MoeIcenowy>
I mean portable
<MoeIcenowy>
in non-portable devices market some AP-only vendors still live well
sensiblemn has joined #linux-sunxi
bugzc has joined #linux-sunxi
Amit_T has quit [Quit: ChatZilla 0.9.93 [Firefox 46.0.1/20160511224619]]