<apritzel>
for now I'd use ATF, because it's already there
<apritzel>
in the long run we may move this to the arisc
<apritzel>
ideally we can do this later without changing anything in Linux
<MoeIcenowy>
Oh it's a standard...
<apritzel>
kind of, yes
<apritzel>
it has a generic interface, you just say: please set regulator x to voltage y
<apritzel>
and firmware does this
<apritzel>
which allows both abstraction (PHY regulator is always number 5, for instance) and also security (we disallow any illegal or harmful voltages)
<MoeIcenowy>
The sh*tty ARM64 power manager has finally a standard!
<MoeIcenowy>
Good job!
<apritzel>
good thing is also: it's already upstream
<apritzel>
all we need to do is to provide the firmware implementation for one specific SoC and add a DT node
<MoeIcenowy>
Thus... we won't enable RSB in kernel?
<MoeIcenowy>
(As it's used to communicate with AXP by ATF/ARISC
<apritzel>
I don't want to
<apritzel>
we should keep the RSB confined to the secure side (firmware, so either ATF or arisc)
<MoeIcenowy>
but it will be a trouble if a ACxxx chip is imported in further design...
<MoeIcenowy>
ACxxx uses also RSB
<apritzel>
why is that troublesome? In fact you can totally hide this from Linux by implementing the stuff in the firmware
<apritzel>
which is by definition device specific
<MoeIcenowy>
we're importing more and more drivers to ATF/ARISC...
yann has quit [Ping timeout: 260 seconds]
<apritzel>
I'd rather have them there than in Linux
<MoeIcenowy>
if we import too many things to arisc
IgorPec2 has joined #linux-sunxi
<MoeIcenowy>
it will finally not fit SRAM A2
IgorPec has quit [Ping timeout: 240 seconds]
<apritzel>
I don't think that's a problem, the code is very easy actually:
<apritzel>
listen to the mailbox (either IRQ or polling)
<apritzel>
read from the shared memory
<apritzel>
dispatch to a simple handler by the function number
<apritzel>
sanitise the voltage / frequency and write to the register
<apritzel>
don't see how this should exceed 32KB
<longsleep>
MoeIcenowy: Somebody working on mainlining HDMI support for Pine64 would be nice. Not sure how feasable though as they did not release all the code
<MoeIcenowy>
longsleep: or you'd say "they release no code"
<MoeIcenowy>
only a blob
<longsleep>
MoeIcenowy: sure what they release is terrible - but thats what we have to work with no matter what
<MoeIcenowy>
maybe we should use IDA Pro :-)
<apritzel>
isn't there already stuff partly reverse engineered?
<MoeIcenowy>
yes
<MoeIcenowy>
but the HDMI phy is yet far from being fully explained
<MoeIcenowy>
(what we should firstly pray is the source of libdram
<longsleep>
MoeIcenowy: did you look at their latest bit of "source" aka the sunxi-drm driver?
arete74 has quit [Quit: Lost terminal]
<MoeIcenowy>
I'll check it
<MoeIcenowy>
but the note says "Using drm driver not able to coexist with display driver，due to utilize display relate BSP section"
<longsleep>
Yes its just a wrapper around the existing disp2 driver
<KotCzarny>
i can understand not posting hw designs, but not posting any reference for operation of the chips? what could be the reason?
yann has joined #linux-sunxi
<MoeIcenowy>
I at least can be not careful to the HDMI, as I lent my HDMI screen to another person who has a rpi2
lemonzest has quit [Quit: Leaving]
lemonzest has joined #linux-sunxi
<MoeIcenowy>
apritzel: I have seen you switched RSB and SRAM A2 to secure -only...
<apritzel>
yes
<apritzel>
though that actually doesn't work ;-)
<apritzel>
as you can still access it
<wens>
:S
<apritzel>
it seems we are missing something in that security setting
<apritzel>
I am not even sure it works at all on the A64
<apritzel>
because I see it being enabled on the H64
<wens>
it's best to just ask them :)
OverCR has joined #linux-sunxi
* apritzel
would laugh if it wouldn't be so sad ;-)
<MoeIcenowy>
apritzel: can ARISC access them after switching the secure mode?
<apritzel>
that's a bit unclear, but it looks like
<apritzel>
I think the arisc is always running "secure"
kaspter has joined #linux-sunxi
<apritzel>
means all arisc bus accesses are tagged as secure
<wens>
makes sense if the secure sram it's suppose to run from is secure only
<apritzel>
indeed
<apritzel>
but as mentioned this whole secure scheme is a bit confusing
* apritzel
is off for lunch
arete74 has joined #linux-sunxi
<arete74>
hi try to use kernel 4.7-rc7 wih cpugfreq support,
<arete74>
but the command ls /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
<arete74>
ls: cannot access '/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq': No such file or directory
<_stephan>
arete74, is cpufreq configured in your kernel? gunzip -c /proc/config.gz | grep CPU_FREQ
<apritzel>
that doesn't look very upstreamable to me
<MoeIcenowy>
and USB Host-only controller should at least be enabled
<MoeIcenowy>
(Thus we can get EHCI running
<apritzel>
MoeIcenowy: there are some bits missing
<apritzel>
for USB
<MoeIcenowy>
?
<MoeIcenowy>
missing in the driver?
<apritzel>
minor differences in the registers
<MoeIcenowy>
ah-oh
<apritzel>
I could mount a pen drive the other day
<apritzel>
with some hacks
<apritzel>
but hotplug didn't work
<apritzel>
also I had to disable OHCI
<apritzel>
MoeIcenowy: but you are very welcome to fix this!
<MoeIcenowy>
ok
<apritzel>
I can push the bits I have so far somewhere
<MoeIcenowy>
I will do usermanual diff on A33 and A64
<apritzel>
there is this one register which is annoying
<MoeIcenowy>
apritzel: which one?
<apritzel>
because I think it cannot be expressed with the current driver
<apritzel>
just a sec ..
Michal has quit [Ping timeout: 244 seconds]
<MoeIcenowy>
thx
<apritzel>
that's USBPHY config register (0x00cc in the CCU)
<apritzel>
bits 17:16
<MoeIcenowy>
ccu... I diffed "Interfaces -> USB"
<apritzel>
the driver only supports single bits, AFAICT
<MoeIcenowy>
it's out of my thought
vagrantc has quit [Ping timeout: 246 seconds]
<apritzel>
but we need to set this to '11'
<apritzel>
also the PHY control registers are not documented properly
<apritzel>
and seem to be slightly different from the other SoCs
<apritzel>
H3 is of no help here, because the USB part is too different
<apritzel>
MoeIcenowy: your best bet is to look at the BSP kernel, I am afraid
<MoeIcenowy>
ok it's the allwinner style
<MoeIcenowy>
unclear user manual
iamfrankenstein1 has joined #linux-sunxi
iamfrankenstein1 has quit [Read error: Connection reset by peer]
vagrantc has joined #linux-sunxi
<apritzel>
no, no, it's all meant as a challenge to spot upcoming Linux talents ;-)
<KotCzarny>
hehe
zumbi has quit [Quit: brb]
fire219 has joined #linux-sunxi
zumbi has joined #linux-sunxi
cnxsoft has quit [Quit: cnxsoft]
pietrushnic has quit [Ping timeout: 240 seconds]
dearfibonacci_ has quit [Quit: Leaving]
pietrushnic has joined #linux-sunxi
Mr__Anderson has joined #linux-sunxi
nove has joined #linux-sunxi
IgorPec has quit [Ping timeout: 276 seconds]
reinforce has quit [Quit: Leaving.]
arete74 has quit [Quit: Lost terminal]
<nove>
this is about "added value", if there is a working hdmi driver in mailline, there is "no value" because will be in equal stance to other socs with already mainline driver, with no driver the consumer has to rely in the vendor, creating "added value"
<nove>
as can be seen, the only point to shuffle registers, is to create this "added value"
<KotCzarny>
nove, wouldn't it be better for vendor to have added value of 'stuff works and has good software/drivers' value?
<wens>
obfuscating stuff normally means you're trying to hide something
<nove>
i don't know
<nove>
and i am certain that the hardware design holders, also have competent people that can easy see beyond any obfuscation
<nove>
so shuffling is not to hide, but to make hard
<nove>
the reuse of any existent driver
<apritzel>
I think that's pointless unless you are into some kind of software business
<apritzel>
and to me being able to point customers to existing distributions would be much more tempting than having to provide my own crap
<KotCzarny>
especially that they skimp on software anyway
<apritzel>
AW could still download $distro, add something and put it on a pen drive
<MoeIcenowy>
consider the fact that there's nothing about HDMI in the user manual.
<apritzel>
In fact HDMI is a good example why you shouldn't do your own stuff
<apritzel>
because you have to then test, adjust and fix your h/w and s/w with the gazillions of TVs and monitors out there
<apritzel>
which you could just avoid by using something that has been tested before
<apritzel>
just like the (first) Pine64 Android image just produced (some kind of) image on one of my three monitors
zuikis has joined #linux-sunxi
aalm has quit [Ping timeout: 246 seconds]
jernej has joined #linux-sunxi
vagrantc has quit [Ping timeout: 276 seconds]
vagrantc has joined #linux-sunxi
Netlynx has joined #linux-sunxi
Michal has joined #linux-sunxi
reinforce has joined #linux-sunxi
yann has quit [Ping timeout: 258 seconds]
BenG83 has joined #linux-sunxi
|Jeroen| has joined #linux-sunxi
montjoie has quit [Ping timeout: 276 seconds]
montjoie has joined #linux-sunxi
BenG83 has quit [Quit: Leaving]
Mr__Anderson has quit [Remote host closed the connection]
Mr__Anderson has joined #linux-sunxi
Mr__Anderson has quit [Quit: Leaving.]
IgorPec has joined #linux-sunxi
vagrantc has quit [Quit: leaving]
apritzel has quit [Ping timeout: 244 seconds]
BenG83 has joined #linux-sunxi
matthias_bgg has quit [Quit: Leaving]
enrico_ has quit [Quit: Bye]
agraf` is now known as agraf
fdcx has quit [Ping timeout: 250 seconds]
IgorPec has quit [Ping timeout: 252 seconds]
IgorPec has joined #linux-sunxi
fdcx has joined #linux-sunxi
ricardocrudo has quit [Remote host closed the connection]